draft-ietf-mmusic-file-transfer-mech-05.txt   draft-ietf-mmusic-file-transfer-mech-06.txt 
MMUSIC Working Group M. Garcia-Martin MMUSIC Working Group M. Garcia-Martin
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Standards Track M. Isomaki Intended status: Standards Track M. Isomaki
Expires: May 19, 2008 Nokia Expires: June 23, 2008 Nokia
G. Camarillo G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
November 16, 2007 December 21, 2007
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable
File Transfer File Transfer
draft-ietf-mmusic-file-transfer-mech-05.txt draft-ietf-mmusic-file-transfer-mech-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008. This Internet-Draft will expire on June 23, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides a mechanism to negotiate the transfer of one This document provides a mechanism to negotiate the transfer of one
or more files between two endpoints by using the Session Description or more files between two endpoints by using the Session Description
Protocol (SDP) offer/answer model specified in RFC 3264. SDP is Protocol (SDP) offer/answer model specified in RFC 3264. SDP is
skipping to change at page 3, line 27 skipping to change at page 3, line 27
8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 16 8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 16
8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 17 8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 17
8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 18 8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 18
8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 18 8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 18
8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 18 8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 18
8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 19 8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 19
8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 21 8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 21
8.4. Indicating File Transfer Offer/Answer Capability . . . . . 23 8.4. Indicating File Transfer Offer/Answer Capability . . . . . 23
8.5. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 23 8.5. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 23
8.6. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23 8.6. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23
8.7. Considerations about the 'file-icon' attribute . . . . . . 24 8.7. Considerations about the 'file-icon' attribute . . . . . . 25
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 25 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 25
9.2. Offerer requests a file from the Answerer and second 9.2. Offerer requests a file from the Answerer and second
file transfer . . . . . . . . . . . . . . . . . . . . . . 30 file transfer . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Example of a capability indication . . . . . . . . . . . . 37 9.3. Example of a capability indication . . . . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. Registration of new SDP attributes . . . . . . . . . . . . 39 11.1. Registration of new SDP attributes . . . . . . . . . . . . 39
11.1.1. Registration of the file-selector attribute . . . . . 39 11.1.1. Registration of the file-selector attribute . . . . . 39
11.1.2. Registration of the file-transfer-id attribute . . . . 40 11.1.2. Registration of the file-transfer-id attribute . . . . 40
skipping to change at page 11, line 26 skipping to change at page 11, line 26
to be transferred. There are four selectors in this attribute: to be transferred. There are four selectors in this attribute:
'name', 'size', 'type', and 'hash'. 'name', 'size', 'type', and 'hash'.
The 'name' selector in the 'file-selector' attribute contains the The 'name' selector in the 'file-selector' attribute contains the
filename of the content enclosed in double quotes. The filename is filename of the content enclosed in double quotes. The filename is
encoded in UTF-8 [RFC3629]. Its value SHOULD be the same as the encoded in UTF-8 [RFC3629]. Its value SHOULD be the same as the
'filename' parameter of the Content-Disposition header field 'filename' parameter of the Content-Disposition header field
[RFC2183] that would be signaled by the actual file transfer. If a [RFC2183] that would be signaled by the actual file transfer. If a
file name contains double quotes or any other character that the file name contains double quotes or any other character that the
syntax does not allow in the 'name' selector, they MUST be percent- syntax does not allow in the 'name' selector, they MUST be percent-
encoded. The 'name' selector MUST not contain characters that can be encoded. The 'name' selector MUST NOT contain characters that can be
interpreted as directory structure by the local operating system. If interpreted as directory structure by the local operating system. If
such characters are present in the file name, they MUST be percent- such characters are present in the file name, they MUST be percent-
encoded. encoded.
Note that the 'name' selector might still contain characters that, Note that the 'name' selector might still contain characters that,
although not meaningful for the local operating system, might although not meaningful for the local operating system, might
still be meaningful to the remote operating system (e.g., '\', still be meaningful to the remote operating system (e.g., '\',
'/', ':'). Therefore, implementations are responsible for '/', ':'). Therefore, implementations are responsible for
sanitizing the input received from the remote endpoint before sanitizing the input received from the remote endpoint before
doing a local operation in the local file system, such as the doing a local operation in the local file system, such as the
skipping to change at page 23, line 51 skipping to change at page 23, line 51
8.6. MSRP Usage 8.6. MSRP Usage
The file transfer service specified in this document uses "m=" lines The file transfer service specified in this document uses "m=" lines
to describe the unidirectional transfer of a file. Consequently, to describe the unidirectional transfer of a file. Consequently,
each MSRP session established following the procedures in Section 8.1 each MSRP session established following the procedures in Section 8.1
and Section 8.2 is only used to transfer a single file. So, senders and Section 8.2 is only used to transfer a single file. So, senders
MUST only use the dedicated MSRP session to send the file described MUST only use the dedicated MSRP session to send the file described
in the SDP offer or answer. That is, senders MUST NOT send in the SDP offer or answer. That is, senders MUST NOT send
additional files over the same MSRP session. additional files over the same MSRP session.
File transfer may be accomplished using a new multimedia session
established for the purpose. Alternatively a file transfer may be
conducted within an existing multimedia session, without regard for
the media in use within that session. Of particular note, file
transfer may be done within a multimedia session containing an MSRP
session used for regular instant messaging. If file transfer is
initiated within an existing multimedia session, the SDP offerer MUST
NOT reuse an existing "m=" line that is still being used by MSRP
(either regular MSRP for instant messaging or an ongoing file
transfer). Rather it MUST add an addtional "m=" line or else reuse
an "m=" line that is no longer being used.
Additionally, implementations according to this specification MUST Additionally, implementations according to this specification MUST
include a single file in a single MSRP message. Notice that the MSRP include a single file in a single MSRP message. Notice that the MSRP
specification defines "MSRP message" as a complete unit of MIME or specification defines "MSRP message" as a complete unit of MIME or
text content, which can be split and delivered in more than one MSRP text content, which can be split and delivered in more than one MSRP
request; each of these portions of the complete message is called a request; each of these portions of the complete message is called a
"chunk". So, it is still valid to send a file in several chunks, but "chunk". So, it is still valid to send a file in several chunks, but
from the MSRP point of view, all the chunks together form an MSRP from the MSRP point of view, all the chunks together form an MSRP
message: the CPIM message that wraps the file. When chunking, notice message: the CPIM message that wraps the file. When chunking, notice
that MSRP does not require to wait for a 200-class response for a that MSRP does not require to wait for a 200-class response for a
chunk before sending the following one. Therefore, it is valid to chunk before sending the following one. Therefore, it is valid to
skipping to change at page 41, line 37 skipping to change at page 41, line 37
file file
Specification: RFC XXXX Specification: RFC XXXX
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Mats Stille, Nancy Greene, Adamu The authors would like to thank Mats Stille, Nancy Greene, Adamu
Haruna, and Arto Leppisaari for discussing initial concepts described Haruna, and Arto Leppisaari for discussing initial concepts described
in this memo. Thanks to Pekka Kuure for reviewing initial versions in this memo. Thanks to Pekka Kuure for reviewing initial versions
this document and providing helpful comments. Joerg Ott, Jiwey Wang, this document and providing helpful comments. Joerg Ott, Jiwey Wang,
Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis-
Courmont, Colin Perkins, Paul Kyzivat, Sudhakar An, Peter Saint- Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan
Andre, Jonathan Rosenberg, and Eric Rescorla discussed and provided Rosenberg, and Eric Rescorla discussed and provided comments and
comments and improvements to this document. improvements to this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
 End of changes. 8 change blocks. 
9 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/