Subject: [MMUSIC] File transfer draft -04

From: Miguel Garcia <[email-masked]>
Date: Wed, 24 Oct 2007 09:23:28 +0300

As you probably noticed, I have just posted a new version of the file 
transfer draft. There is an HTML version and a diff at:

http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-04.html
http://people.nokia.net/~miguel/drafts/draft-ietf-mmusic-file-transfer-mech-04-from-3.html

We are getting very close to finish the draft, so, I would like people 
to take a look at the list of changes (at least), and see if they have 
been properly documented.

List of changes:

- Added the notion of a file-transfer identifier, which is materialized
in the 'file-transfer-id' attribute. It contains a new identifier per
new file transfer. This is to avoid that a repetition of the SDP (due to
session timers, or adding new media streams) causes a new file transfer
and aborts the ongoing one. The 'file-transfer-id' attribute replaces
the existing 'file-transfer' attribute.

- The existing draft had a lot of complexity for dealing with several
hashing algorithms. Since we use the has just for file transfer
verification and file identification, just using a single algorithm
seems to serve the purpose. So, the current version uses SHA-1 and
leaves the door open for future extensions that can define new hashing
algorithms.

- Clarified the requirements that other protocol than MSRP should
fulfill in order to be used for the file transfer.

- Clarified that 'sendonly' and 'recvonly' refers to the direction of
MSRP SEND request, and does not preclude other MSRP messages (200, REPORT).

- The name selector syntax allows percent encoding.

- Fixed an error with the hash value syntax

- The 'file-range' attribute allows to signal the
"last-byte-of-the-file" with a "*" character (like in MSRP).

- The 'file-range' terminology has made it consistent: now the terms
"start range" and "end range" are used to refer to the two integers that
define the file range.

- Clarified that it is mandatory to implement message/cpim, but its
usage is negotiated in SDP.

- Clarified the use case that involves a non-supporting endpoint wwhich
does not also support multipart MIME and receives an SDP offer with a
side-by icon body.

- Noted that the hash is not used for strong integrity verification.

- Several other minor clarifications.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

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