Subject: [MMUSIC] File transfer verrsion -02

From: Miguel Garcia <[email-masked]>
Date: Fri, 18 May 2007 16:04:06 +0300

I have submitted version -02 of the file transfer draft.

Until it appears in the repository, you can fetch a copy from:

http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-02.txt
http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-02.html

and a diff version:
http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-02-from-1.html

The changes in this version are:
- Rename of attributes:
   s/icon/file-icon
   s/disposition/file-disposition

- Fixed SDP in example in Section 9.3 to include mime types.

With this, I think the document is complete. I am not aware of any 
further open issues.

Regards,

     Miguel
-- 
Please note my new e-mail address: miguel.garcia at nsn.com
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Helsinki, Finland

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 May 2007 12:33:01 -0400

This is looking pretty good - much improved over the last version I 
looked at. I have an assortment of comments, mostly nits or issues with 
wording:

Section 5:

    Specially in case the SDP offer is generated by the file receiver,
    the offer needs a mechanism to unambiguously identify the requested
    file.  For this purpose, the file transfer mechanism introduces the
    concept of a file selector, which is defined as the combination of
    the 4-tuple composed of the name, size, type, and hash of the file.
    We call each of these individual items a selector.

I find the above confusing. Is the selector the individual item, or the 
tuple of all the items? Also, is the combination always a 4-tuple, or 
may it have a subset of the items? If it may have a subset I guess it 
may still considered a 4-tuple that may contain null entries.

Section 6:

     file-icon-value      = cid-url        ;cid-url defined in RFC 2392

I don't really have a problem with the syntax, but this implies that 
there must be a multipart body. The use of SDP attributes rather than an 
external body was justified on the assumption that many UAs don't 
support multipart. There is an inconsistency here.

Section 7:

    To indicate that a file should be automatically rendered, this memo
    uses the existing 'render' value of the Content Disposition type in
    the new 'file-disposition' attribute in SDP.  To indicate that a file
    should not be automatically rendered, this memo defines a new value
    'not-render' of the Content Disposition type.  The default value is
    'render', i.e., the absence of a 'file-disposition' attribute in the
    SDP has the same semantics as 'render'.

The "not-render" disposition seems strange, because it is a negative. 
IMO something positive would be preferable - perhaps "storage" or 
"recipient-discretion".

Section 8.2.2:

    If the SDP offer included several
    'hash' parameters, the file sender SHOULD include at least one in the
    SDP answer, selected among those present in the offer and, at the
    same time, supported by the file sender.  If the SDP offer did not
    include a 'hash' parameter, the file sender SHOULD add one or more
    'hash' parameters, according to the supported hashing algorithms.

What should the file sender do if it supports multiple hash algorithms 
but the hashes supplied are not all consistent? Namely a file that 
matches one of them doesn't match the others. E.g. suppose the offer 
contained:

     a=file-selector:hash:sha-1:ABC hash:md5:DEF

and the matching file matches the sha-1 hash but not the md5 hash.

It could treat this as an error and reject the request, or it could 
treat this as ok as long as one of the hashes matches. The latter seems 
better. In that case, I think it should only return the hashes that 
actually match the file being returned. This does imply that if it 
supports multiple hashes then it needs to test the file against all of 
those supplied. Alternatively, perhaps it should only return those 
hashes that it has actually tested against the file being returned.

Section 8.4.  Re-usage of Existing m= Lines in SDP

    The SDP Offer/Answer Model [7] provides rules that allow SDP offerers
    and answerers to modify an existing media line, i.e., re-use an
    existing media line with different attributes.  The same is also
    possible when SDP signals a file transfer operation according to the
    rules of this memo.  Therefore, the procedures defined in RFC 3264
    [7], in particular those defined in Section 8.3, MUST apply for file
    transfer operations.

What does this mean? In other usage, a reinvite will cause another o/a 
exchange. In some cases the SDP is unchanged in this o/a and the result 
is that things remain as they are.

When using the procedures of this draft, if a new o/a exchange is made 
where there are no changes in the SDP, does it initiate a new transfer 
of the file that was previously exchanged? Or does it do nothing?

There will be cases following a file transfer when there is need to do 
another o/a without repeating the transfer. And there may also be cases 
when there is an explicit desire to repeat the transmission. (Maybe via 
other means it is known that the file has changed.)

Either the port must be set to zero in the subsequent o/a if 
retransmission is not desired, or else something must be changed (e.g. 
the msrp url) if retransmission is desired.

	That's it,
	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 May 2007 16:35:52 +0300

Hi Paul:

Thanks for your comments. Rather than answering in a very long e-mail, I 
have decided to chunk your e-mail on a per issue basis. I will be 
posting each of them separately, along with an issue number. Keep tuned.

/Miguel

Paul Kyzivat wrote:
> tuple of all the items?

---

From: Mahesh Anjanappa <[email-masked]>
Date: Mon, 21 May 2007 19:27:28 +0530

hi Miguel,
A File  Receiver should be given the provision to indicate to the File
Sender as to
what is the maximum File size it is capable of receiving. This will be
especially
useful if the File Sneder does NOT provide the File-Size in the INVITE(SDP).

For this i suggest the following
"A Receiver MAY indicate the maximum size MSRP message(translates to max
File Size) that it wishes to
receive by including  the max-size a-line attribute in the SDP of
200OK(INVITE).
Max-size refers to the complete message in octets, not the size of any one
chunk.
Senders  SHALL NOT exceed the max-size limit for any message sent in the
resulting session".

regards
Mahesh

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 May 2007 17:29:30 +0300

Hi Mahesh:

Thanks for the comment.

I took a look at the vanilla MSRP draft 
(draft-ietf-simple-message-sessions) and it already offers a 'max-size' 
attribute with similar (mostly the same) semantics that you mention.

    An endpoint MAY indicate the maximum size message they wish to
    receive using the max-size a-line attribute.  Max-size refers to the
    complete message in octets, not the size of any one chunk.  Senders
    SHOULD NOT exceed the max-size limit for any message sent in the
    resulting session.  However, the receiver should consider max-size
    value as a hint.

The difference between MSRP max-size and your proposed max-file-size is 
that max-size comprises the CPIM overhead whereas max-file-size do not.

Honestly, I think the difference is on the order of hundreds of bytes at 
maximum. I think we shouldn't be defining a new attribute for it.
Which other view do we have on this one?

/Miguel

---

From: Mahesh Anjanappa <[email-masked]>
Date: Mon, 21 May 2007 20:39:28 +0530

hi Miguel,
Actually , my Comment was with reference to the excerpt in MSRP draft
itself,
i dont intend to introduce a new attribute(i should have mentioned the MSRP
draft).
In MSRP draft, it does not enforce a "shall" for Senders to adhere to
max-size a-line attribute
value if the Receiver specified one.

But in File Transfer draft, i think it can be explicitly recommended to use
the max-size
a-line attribute and make it mandatory for Sender to adhere IF  the Receiver
specifies
a max-size.
It will be useful for File Transfer applications to refrain from sending
file sizes more than that
the Receiver can receive.

regards
Mahesh

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 May 2007 20:56:31 +0300

Hi Mahesh:

Ah, ok... So, if the comment is to refer to the max-size in MSRP, I 
think it is fine to mention something.

I have added the following paragraph to Section 8.5:

    The MSRP specification [13] defines a 'max-size' SDP attribute.  This
    attribute specifies the maximum number of octets of an MSRP message
    that the creator of the SDP is willing to receive (notice once more
    the definition of "MSRP message").  File receivers MAY add a 'max-
    size' attribute to the MSRP m= line that specifies the file,
    indicating the maximum number of octets of an MSRP message.  File
    senders MUST NOT exceed the 'max-size' limit for any message sent in
    the resulting session.

I hope this is OK.

/Miguel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 May 2007 13:51:18 +0300

Hi,

I agree we should keep it simple and refrain from defining a new attribute.

Cheers,

Gonzalo

Miguel Garcia wrote:
>> ----- Original Message ----- From: "Miguel Garcia" 
>> <[email-masked]>

---

From: Mahesh Anjanappa <[email-masked]>
Date: Thu, 24 May 2007 15:38:29 +0530

hi Miguel,
>From Sec 8.1.3, i understand that in order for a Sender to send mulitple
Files,
an "m=" line per file needs to be introduced in the SDP.

So there will be a single SIP Session and multiple associated MSRP Sessions
(however, Single COnnection)
, each File being transferred over separate MSRP Session.

Please clarify how to Stop/Abort a Particular File Transfer among the 'n'
File Transfers
running.

regards
Mahesh

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 24 May 2007 15:38:55 +0300

Hi Mahesh:

Some inline discussion.

> an "m=" line per file needs to be introduced in the SDP.

Correct.

> , each File being transferred over separate MSRP Session.

Correct: One SIP session, composed of several MSRP sessions, which may 
or may not be bound to the same TCP connection (I guess typically the 
will all share the same TCP connection).

> Please clarify how to Stop/Abort a Particular File Transfer among the 'n'

The sender can always abort an ongoing transfer by using regular MSRP 
procedures: sending an MSRP SEND message that contains the '#' 
continuation flag at the end of the end-line. Since this is part of an 
MSRP session, the MSRP session will be present in the From-Path, To-Path 
  headers. This allow to demultiplex this MSRP session from the rest.

If the receiving side wants to abort a transfer, I guess it should 
re-INVITE and set the appropriate port in the m= line to 0. The sending 
side should abort (as described in the previous paragraph).

/Miguel