--- 1/draft-ietf-mmusic-file-transfer-mech-10.txt 2009-02-17 16:12:03.000000000 +0100 +++ 2/draft-ietf-mmusic-file-transfer-mech-11.txt 2009-02-17 16:12:03.000000000 +0100 @@ -1,25 +1,25 @@ MMUSIC Working Group M. Garcia-Martin Internet-Draft Ericsson Intended status: Standards Track M. Isomaki -Expires: July 26, 2009 Nokia +Expires: August 21, 2009 Nokia G. Camarillo S. Loreto Ericsson P. Kyzivat Cisco Systems - January 22, 2009 + February 17, 2009 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer - draft-ietf-mmusic-file-transfer-mech-10.txt + draft-ietf-mmusic-file-transfer-mech-11.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -28,21 +28,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 26, 2009. + This Internet-Draft will expire on August 21, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -67,35 +67,35 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14 - 8.1. The 'file-transfer-id' attribute . . . . . . . . . . . . . 14 + 8.1. The 'file-transfer-id' attribute . . . . . . . . . . . . . 15 8.2. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 17 - 8.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 17 + 8.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 18 8.2.2. The Offerer is a File Receiver . . . . . . . . . . . . 18 8.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 19 8.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 19 - 8.3.1. The Answerer is a File Receiver . . . . . . . . . . . 19 + 8.3.1. The Answerer is a File Receiver . . . . . . . . . . . 20 8.3.2. The Answerer is a File Sender . . . . . . . . . . . . 21 8.4. Aborting an ongoing file transfer operation . . . . . . . 22 - 8.5. Indicating File Transfer Offer/Answer Capability . . . . . 25 + 8.5. Indicating File Transfer Offer/Answer Capability . . . . . 26 8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 26 8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 26 8.8. Considerations about the 'file-icon' attribute . . . . . . 28 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 28 + 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 29 9.2. Offerer requests a file from the Answerer and second file transfer . . . . . . . . . . . . . . . . . . . . . . 33 9.3. Example of a capability indication . . . . . . . . . . . . 40 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11.1. Registration of new SDP attributes . . . . . . . . . . . . 42 11.1.1. Registration of the file-selector attribute . . . . . 43 11.1.2. Registration of the file-transfer-id attribute . . . . 43 11.1.3. Registration of the file-disposition attribute . . . . 43 11.1.4. Registration of the file-date attribute . . . . . . . 43 @@ -306,46 +306,51 @@ 6. Extensions to SDP We define a number of new SDP [RFC4566] attributes that provide the required information to describe the transfer of a file with MSRP. These are all media level only attributes in SDP. The following is the formal ABNF syntax [RFC5234] of these new attributes. It is built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183 [RFC2183], RFC 2392 [RFC2392], and RFC 5322 [RFC5322]. - attribute = file-selector-attr / file-disp-attr / + attribute /= file-selector-attr / file-disp-attr / file-tr-id-attr / file-date-attr / file-icon-attr / file-range-attr ;attribute is defined in RFC 4566 file-selector-attr = "file-selector" [":" selector *(SP selector)] selector = filename-selector / filesize-selector / filetype-selector / hash-selector filename-selector = "name:" DQUOTE filename-string DQUOTE ; DQUOTE defined in RFC 5234 filename-string = 1*(filename-char/percent-encoded) filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF ;any byte except NUL, CR, LF, ;double quotes, or percent percent-encoded = "%" HEXDIG HEXDIG ; HEXDIG defined in RFC 5234 filesize-selector = "size:" filesize-value filesize-value = integer ;integer defined in RFC 4566 - filetype-selector = "type:" type "/" subtype *(";"parameter) - ; parameter defined in RFC 2045 - type = token ; token defined in RFC 4566 - subtype = token + filetype-selector = "type:" type "/" subtype *(";" ft-parameter) + ft-parameter = attribute "=" DQUOTE value-string DQUOTE + ; attribute is defined in RFC 2045 + ; free insertion of linear-white-space is not + ; permitted in this context. + ; note: value-string has to be re-encoded + ; when translating between this and a + ; Content-Type header. + value-string = filename-string hash-selector = "hash:" hash-algorithm ":" hash-value hash-algorithm = token ;see IANA Hash Function ;Textual Names registry ;only "sha-1" currently supported hash-value = 2HEXDIG *(":" 2HEXDIG) ; Each byte in upper-case hex, separated ; by colons. ; HEXDIG defined in RFC 5234 file-tr-id-attr = "file-transfer-id:" file-tr-id-value @@ -411,22 +416,25 @@ field [RFC2183] that would be signaled by the actual file transfer. Note that the 'size' selector merely includes the file size, and does not include any potential overhead added by a wrapper, such as message/cpim [RFC3862]. The 'type' selector in the 'file-selector' attribute contains the MIME media and submedia types of the content. In general, anything that can be expressed in a Content-Type header field (see RFC 2045 [RFC2045]) can also be expressed with the 'type' selectors. Possible MIME Media Type values are the ones listed in the IANA registry for - MIME Media Types [1]. Zero or more parameters can follow. The - syntax of 'parameter' is specified in RFC 2045 [RFC2045] . + MIME Media Types [1]. Zero or more parameters can follow. When + translating parameters from a Content-Type header and a 'type' + selector, the parameter has to be re-encoded prior to its + accommodation as a parameter of the 'type' selector (see the ABNF + syntax of 'ft-parameter'). The 'hash' selector in the 'file-selector' attribute provides a hash computation of the file to be transferred. This is commonly used by file transfer protocols. For example, FLUTE [I-D.ietf-rmt-flute-revised] uses hashes (called message digests) to verify the contents of the transfer. The purpose of the 'hash' selector is two-fold: On one side, in pull operations, it allows the file receiver to identify a remote file by its hash rather than by its file name, providing that the file receiver has learned the hash of the remote file by some out-of-band mechanism. On the other side, @@ -438,23 +446,24 @@ any collision in hash computations in between two endpoints. When transferring files, the actual file transfer protocol should provide reliable transmission of data, so verifications of received files should always succeed. However, if endpoints need to protect the integrity of a file, they should use some other mechanism than the 'hash' selector specified in this memo. The 'hash' selector includes the hash algorithm and its value. Possible hash algorithms are those defined in the IANA registry of Hash Function Textual Names [2]. Implementations according to this - specification MUST add a US Secure Hash Algorithm 1 (SHA1) [RFC3174] - value if the 'hash' selector is present. If need arises, extensions - can be drafted to support several hashing algorithms. Therefore, + specification MUST add a 160-bit string resulting from the + computation of US Secure Hash Algorithm 1 (SHA1) [RFC3174] if the + 'hash' selector is present. If need arises, extensions can be + drafted to support several hashing algorithms. Therefore, implementations according to this specification MUST be prepared to receive SDP containing more than a single 'hash' selector in the 'file-selector' attribute. The value of the 'hash' selector is the byte string resulting of applying the hash algorithm to the content of the whole file, even when the file transfer is limited to a number of octets (i.e., the 'file-range' attribute is indicated). The 'file-transfer-id' attribute provides a randomly chosen globally @@ -1837,21 +1846,21 @@ File receivers MUST also sanitize all input, such as the local file name, prior to making calls to the local file system to store a file. This is to prevent the existence of meaningful characters to the local operating system that could damage it. Once a file has been transferred the file receiver must take care of it. Typically file transfer is a commonly used mechanism for transmitting computer virus, spyware, and other types of malware. File receivers should apply all possible security technologies (e.g., - antivirus, antispyware, etc.) to dismiss the risk of damage at their + antivirus, antispyware, etc.) to mitigate the risk of damage at their host. 11. IANA Considerations This document instructs IANA to register a number of SDP attributes according to the following: 11.1. Registration of new SDP attributes This memo provides instructions to IANA to register a number of media @@ -1937,23 +1946,23 @@ Specification: RFC XXXX 12. Acknowledgements The authors would like to thank Mats Stille, Nancy Greene, Adamu Haruna, and Arto Leppisaari for discussing initial concepts described in this memo. Thanks to Pekka Kuure for reviewing initial versions this document and providing helpful comments. Joerg Ott, Jiwey Wang, Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan - Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, and Richard - Barnes discussed and provided comments and improvements to this - document. + Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, Richard + Barnes, and Chris Newman discussed and provided comments and + improvements to this document. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message