draft-ietf-mmusic-file-transfer-mech-10.txt   draft-ietf-mmusic-file-transfer-mech-11.txt 
MMUSIC Working Group M. Garcia-Martin MMUSIC Working Group M. Garcia-Martin
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track M. Isomaki Intended status: Standards Track M. Isomaki
Expires: July 26, 2009 Nokia Expires: August 21, 2009 Nokia
G. Camarillo G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
January 22, 2009 February 17, 2009
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-10.txt draft-ietf-mmusic-file-transfer-mech-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 July 26, 2009. This Internet-Draft will expire on August 21, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7 5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8
7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14 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. 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.2. The Offerer is a File Receiver . . . . . . . . . . . . 18
8.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 19 8.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 19
8.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 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.3.2. The Answerer is a File Sender . . . . . . . . . . . . 21
8.4. Aborting an ongoing file transfer operation . . . . . . . 22 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.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 26
8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 26 8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 26
8.8. Considerations about the 'file-icon' attribute . . . . . . 28 8.8. Considerations about the 'file-icon' attribute . . . . . . 28
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 9.2. Offerer requests a file from the Answerer and second
file transfer . . . . . . . . . . . . . . . . . . . . . . 33 file transfer . . . . . . . . . . . . . . . . . . . . . . 33
9.3. Example of a capability indication . . . . . . . . . . . . 40 9.3. Example of a capability indication . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11.1. Registration of new SDP attributes . . . . . . . . . . . . 42 11.1. Registration of new SDP attributes . . . . . . . . . . . . 42
11.1.1. Registration of the file-selector attribute . . . . . 43 11.1.1. Registration of the file-selector attribute . . . . . 43
11.1.2. Registration of the file-transfer-id 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.3. Registration of the file-disposition attribute . . . . 43
11.1.4. Registration of the file-date attribute . . . . . . . 43 11.1.4. Registration of the file-date attribute . . . . . . . 43
skipping to change at page 8, line 20 skipping to change at page 8, line 20
6. Extensions to SDP 6. Extensions to SDP
We define a number of new SDP [RFC4566] attributes that provide the We define a number of new SDP [RFC4566] attributes that provide the
required information to describe the transfer of a file with MSRP. required information to describe the transfer of a file with MSRP.
These are all media level only attributes in SDP. The following is These are all media level only attributes in SDP. The following is
the formal ABNF syntax [RFC5234] of these new attributes. It is the formal ABNF syntax [RFC5234] of these new attributes. It is
built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183 built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183
[RFC2183], RFC 2392 [RFC2392], and RFC 5322 [RFC5322]. [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-tr-id-attr / file-date-attr /
file-icon-attr / file-range-attr file-icon-attr / file-range-attr
;attribute is defined in RFC 4566 ;attribute is defined in RFC 4566
file-selector-attr = "file-selector" [":" selector *(SP selector)] file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector = filename-selector / filesize-selector / selector = filename-selector / filesize-selector /
filetype-selector / hash-selector filetype-selector / hash-selector
filename-selector = "name:" DQUOTE filename-string DQUOTE filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE defined in RFC 5234 ; DQUOTE defined in RFC 5234
filename-string = 1*(filename-char/percent-encoded) filename-string = 1*(filename-char/percent-encoded)
filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF
;any byte except NUL, CR, LF, ;any byte except NUL, CR, LF,
;double quotes, or percent ;double quotes, or percent
percent-encoded = "%" HEXDIG HEXDIG percent-encoded = "%" HEXDIG HEXDIG
; HEXDIG defined in RFC 5234 ; HEXDIG defined in RFC 5234
filesize-selector = "size:" filesize-value filesize-selector = "size:" filesize-value
filesize-value = integer ;integer defined in RFC 4566 filesize-value = integer ;integer defined in RFC 4566
filetype-selector = "type:" type "/" subtype *(";"parameter) filetype-selector = "type:" type "/" subtype *(";" ft-parameter)
; parameter defined in RFC 2045
type = token ; token defined in RFC 4566
subtype = token
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-selector = "hash:" hash-algorithm ":" hash-value
hash-algorithm = token ;see IANA Hash Function hash-algorithm = token ;see IANA Hash Function
;Textual Names registry ;Textual Names registry
;only "sha-1" currently supported ;only "sha-1" currently supported
hash-value = 2HEXDIG *(":" 2HEXDIG) hash-value = 2HEXDIG *(":" 2HEXDIG)
; Each byte in upper-case hex, separated ; Each byte in upper-case hex, separated
; by colons. ; by colons.
; HEXDIG defined in RFC 5234 ; HEXDIG defined in RFC 5234
file-tr-id-attr = "file-transfer-id:" file-tr-id-value file-tr-id-attr = "file-transfer-id:" file-tr-id-value
skipping to change at page 10, line 30 skipping to change at page 10, line 35
field [RFC2183] that would be signaled by the actual file transfer. field [RFC2183] that would be signaled by the actual file transfer.
Note that the 'size' selector merely includes the file size, and does Note that the 'size' selector merely includes the file size, and does
not include any potential overhead added by a wrapper, such as not include any potential overhead added by a wrapper, such as
message/cpim [RFC3862]. message/cpim [RFC3862].
The 'type' selector in the 'file-selector' attribute contains the The 'type' selector in the 'file-selector' attribute contains the
MIME media and submedia types of the content. In general, anything MIME media and submedia types of the content. In general, anything
that can be expressed in a Content-Type header field (see RFC 2045 that can be expressed in a Content-Type header field (see RFC 2045
[RFC2045]) can also be expressed with the 'type' selectors. Possible [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 Type values are the ones listed in the IANA registry for
MIME Media Types [1]. Zero or more parameters can follow. The MIME Media Types [1]. Zero or more parameters can follow. When
syntax of 'parameter' is specified in RFC 2045 [RFC2045] . 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 The 'hash' selector in the 'file-selector' attribute provides a hash
computation of the file to be transferred. This is commonly used by computation of the file to be transferred. This is commonly used by
file transfer protocols. For example, FLUTE file transfer protocols. For example, FLUTE
[I-D.ietf-rmt-flute-revised] uses hashes (called message digests) to [I-D.ietf-rmt-flute-revised] uses hashes (called message digests) to
verify the contents of the transfer. The purpose of the 'hash' verify the contents of the transfer. The purpose of the 'hash'
selector is two-fold: On one side, in pull operations, it allows the 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 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 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, of the remote file by some out-of-band mechanism. On the other side,
skipping to change at page 11, line 9 skipping to change at page 11, line 17
any collision in hash computations in between two endpoints. When any collision in hash computations in between two endpoints. When
transferring files, the actual file transfer protocol should transferring files, the actual file transfer protocol should
provide reliable transmission of data, so verifications of provide reliable transmission of data, so verifications of
received files should always succeed. However, if endpoints need received files should always succeed. However, if endpoints need
to protect the integrity of a file, they should use some other to protect the integrity of a file, they should use some other
mechanism than the 'hash' selector specified in this memo. mechanism than the 'hash' selector specified in this memo.
The 'hash' selector includes the hash algorithm and its value. The 'hash' selector includes the hash algorithm and its value.
Possible hash algorithms are those defined in the IANA registry of Possible hash algorithms are those defined in the IANA registry of
Hash Function Textual Names [2]. Implementations according to this Hash Function Textual Names [2]. Implementations according to this
specification MUST add a US Secure Hash Algorithm 1 (SHA1) [RFC3174] specification MUST add a 160-bit string resulting from the
value if the 'hash' selector is present. If need arises, extensions computation of US Secure Hash Algorithm 1 (SHA1) [RFC3174] if the
can be drafted to support several hashing algorithms. Therefore, '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 implementations according to this specification MUST be prepared to
receive SDP containing more than a single 'hash' selector in the receive SDP containing more than a single 'hash' selector in the
'file-selector' attribute. 'file-selector' attribute.
The value of the 'hash' selector is the byte string resulting of The value of the 'hash' selector is the byte string resulting of
applying the hash algorithm to the content of the whole file, even 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 when the file transfer is limited to a number of octets (i.e., the
'file-range' attribute is indicated). 'file-range' attribute is indicated).
The 'file-transfer-id' attribute provides a randomly chosen globally The 'file-transfer-id' attribute provides a randomly chosen globally
skipping to change at page 42, line 39 skipping to change at page 42, line 39
File receivers MUST also sanitize all input, such as the local file 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. 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 This is to prevent the existence of meaningful characters to the
local operating system that could damage it. local operating system that could damage it.
Once a file has been transferred the file receiver must take care of Once a file has been transferred the file receiver must take care of
it. Typically file transfer is a commonly used mechanism for it. Typically file transfer is a commonly used mechanism for
transmitting computer virus, spyware, and other types of malware. transmitting computer virus, spyware, and other types of malware.
File receivers should apply all possible security technologies (e.g., 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. host.
11. IANA Considerations 11. IANA Considerations
This document instructs IANA to register a number of SDP attributes This document instructs IANA to register a number of SDP attributes
according to the following: according to the following:
11.1. Registration of new SDP attributes 11.1. Registration of new SDP attributes
This memo provides instructions to IANA to register a number of media This memo provides instructions to IANA to register a number of media
skipping to change at page 44, line 46 skipping to change at page 44, line 46
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, Sudhakar An, Peter Saint-Andre, Jonathan Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan
Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, and Richard Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, Richard
Barnes discussed and provided comments and improvements to this Barnes, and Chris Newman discussed and provided comments and
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. 16 change blocks. 
23 lines changed or deleted 32 lines changed or added

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