draft-ietf-mmusic-file-transfer-mech-01.txt   draft-ietf-mmusic-file-transfer-mech-02.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: October 29, 2007 Nokia Expires: November 19, 2007 Nokia
G. Camarillo G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
April 27, 2007 May 18, 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-01.txt draft-ietf-mmusic-file-transfer-mech-02.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 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 October 29, 2007. This Internet-Draft will expire on November 19, 2007.
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 25 skipping to change at page 3, line 25
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 15 8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 15
8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 15 8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 15
8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 16 8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 16
8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 17 8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 17
8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 17 8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 17
8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 17 8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 17
8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 18 8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 18
8.3. Indicating File Transfer Offer/Answer Capability . . . . . 19 8.3. Indicating File Transfer Offer/Answer Capability . . . . . 19
8.4. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 19 8.4. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 19
8.5. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 19 8.5. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 20 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 21
9.2. Offerer requests a file from the Answerer and second 9.2. Offerer requests a file from the Answerer and second
file transfer . . . . . . . . . . . . . . . . . . . . . . 25 file transfer . . . . . . . . . . . . . . . . . . . . . . 25
9.3. Example of a capability indication . . . . . . . . . . . . 31 9.3. Example of a capability indication . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1. Registration of new SDP attributes . . . . . . . . . . . . 33 11.1. Registration of new SDP attributes . . . . . . . . . . . . 33
11.1.1. Registration of the file-selector attribute . . . . . 33 11.1.1. Registration of the file-selector attribute . . . . . 33
11.1.2. Registration of the disposition attribute . . . . . . 33 11.1.2. Registration of the file-disposition attribute . . . . 33
11.1.3. Registration of the file-date attribute . . . . . . . 33 11.1.3. Registration of the file-date attribute . . . . . . . 33
11.1.4. Registration of the icon attribute . . . . . . . . . . 34 11.1.4. Registration of the file-icon attribute . . . . . . . 34
11.1.5. Registration of the file-range attribute . . . . . . . 34 11.1.5. Registration of the file-range attribute . . . . . . . 34
11.2. Registration of new Content Disposition value . . . . . . 34 11.2. Registration of new Content Disposition value . . . . . . 34
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.1. Normative References . . . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
13.2. Informational References . . . . . . . . . . . . . . . . . 36 13.2. Informational References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
skipping to change at page 10, line 5 skipping to change at page 10, line 5
6. Extensions to SDP 6. Extensions to SDP
We define a number of new SDP [10] attributes that provide the We define a number of new SDP [10] 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 [9] of these new attributes. It is built the formal ABNF syntax [9] of these new attributes. It is built
above the SDP [10] grammar, RFC 2045 [2], RFC 2183 [3], and RFC 2392 above the SDP [10] grammar, RFC 2045 [2], RFC 2183 [3], and RFC 2392
[4]. [4].
attribute = file-selector-attr / disposition-attr / attribute = file-selector-attr / file-disp-attr /
file-date-attr / icon-attr / file-date-attr / file-icon-attr /
file-range-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 4234 ; DQUOTE defined in RFC 4234
filename-string = byte-string ;byte-string defined in RFC 4566 filename-string = byte-string ;byte-string defined in RFC 4566
skipping to change at page 10, line 31 skipping to change at page 10, line 31
filetype-selector = "type:" type "/" subtype *(";"parameter) filetype-selector = "type:" type "/" subtype *(";"parameter)
; parameter defined in RFC 2045 ; parameter defined in RFC 2045
type = token type = token
subtype = token subtype = token
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
hash-value = hex-val ;hex-val defined in RFC 4234 hash-value = hex-val ;hex-val defined in RFC 4234
disposition-attr = "disposition:" disposition-value file-disp-attr = "file-disposition:" file-disp-value
disposition-value = token file-disp-value = token
file-date = "file-date:" date-param *(SP date-param) file-date = "file-date:" date-param *(SP date-param)
date-param = c-date-param / m-date-param / r-date-param date-param = c-date-param / m-date-param / r-date-param
c-date-param = "creation:" DQUOTE date-time DQUOTE c-date-param = "creation:" DQUOTE date-time DQUOTE
m-date-param = "modification:" DQUOTE date-time DQUOTE m-date-param = "modification:" DQUOTE date-time DQUOTE
r-date-param = "read:" DQUOTE date-time DQUOTE r-date-param = "read:" DQUOTE date-time DQUOTE
; date-time is defined in RFC 2822 ; date-time is defined in RFC 2822
; numeric timezones (+HHMM or -HHMM) ; numeric timezones (+HHMM or -HHMM)
; must be used ; must be used
; DQUOTE defined in RFC 4234 ; DQUOTE defined in RFC 4234
icon-attr = "icon:" icon-value file-icon-attr = "file-icon:" file-icon-value
icon-value = cid-url ;cid-url defined in RFC 2392 file-icon-value = cid-url ;cid-url defined in RFC 2392
file-range-attr = "file-range:" integer "-" integer file-range-attr = "file-range:" integer "-" integer
;integer defined in RFC 4566 ;integer defined in RFC 4566
Figure 1: Syntax of the SDP extension Figure 1: Syntax of the SDP extension
When used for capability query (see Section 8.3), the 'file-selector' When used for capability query (see Section 8.3), the 'file-selector'
attribute MUST NOT not contain any selector, because its presence attribute MUST NOT not contain any selector, because its presence
merely indicates compliance to this specification. merely indicates compliance to this specification.
When used in an SDP offer or answer, the 'file-selector' attribute When used in an SDP offer or answer, the 'file-selector' attribute
skipping to change at page 12, line 21 skipping to change at page 12, line 21
The 'hash' selector includes the hash algorithm and its value. In The 'hash' selector includes the hash algorithm and its value. In
fact, since there are several hashing algorithms, the SDP MAY contain fact, since there are several hashing algorithms, the SDP MAY contain
several 'hash' selectors with different algorithms. Possible hash several 'hash' selectors with different algorithms. Possible hash
algorithms are those defined in the IANA registry of Hash Function algorithms are those defined in the IANA registry of Hash Function
Textual Names [18]. Implementations according to this specification Textual Names [18]. Implementations according to this specification
MUST support the US Secure Hash Algorithm 1 (SHA1) [6] and MAY MUST support the US Secure Hash Algorithm 1 (SHA1) [6] and MAY
support other hashing algorithms. The value is the byte string support other hashing algorithms. The value is the byte string
resulting of applying the hash algorithm to the content of the whole resulting of applying the hash algorithm to the content of the whole
file. file.
The 'disposition' attribute provides a suggestion to the other The 'file-disposition' attribute provides a suggestion to the other
endpoint about the intended disposition of the file. Section 7 endpoint about the intended disposition of the file. Section 7
provides further discussion of the possible values. The value of provides further discussion of the possible values. The value of
this attribute SHOULD be the same of the disposition type parameter this attribute SHOULD be the same of the disposition type parameter
of the Content-Disposition header field [3] that could be signalled of the Content-Disposition header field [3] that could be signalled
by the actual file transfer. by the actual file transfer protocol.
The 'file-date' attribute indicates the dates at which the file was The 'file-date' attribute indicates the dates at which the file was
created, modified, or last read. This attribute MAY contain a created, modified, or last read. This attribute MAY contain a
combination of the 'creation', 'modification', and 'read' parameters. combination of the 'creation', 'modification', and 'read' parameters.
Only one parameter of each type (creation, modification, or read) Only one parameter of each type (creation, modification, or read)
MUST be present in a 'file-date' attribute. MUST be present in a 'file-date' attribute.
The 'creation' parameter indicates the date at which the file was The 'creation' parameter indicates the date at which the file was
created. The value MUST be a quoted string which contains a created. The value MUST be a quoted string which contains a
representation of the creation date of the file in RFC 2822 [5] representation of the creation date of the file in RFC 2822 [5]
'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used.
The value of this parameter SHOULD be the same of the 'creation-date' The value of this parameter SHOULD be the same of the 'creation-date'
parameter of Content-Disposition header field [3] that could be parameter of Content-Disposition header field [3] that could be
signalled by the actual file transfer. signalled by the actual file transfer protocol.
The 'modification' parameter indicates the date at which the file was The 'modification' parameter indicates the date at which the file was
last modified. The value MUST be a quoted string which contains a last modified. The value MUST be a quoted string which contains a
representation of the last modification date to the file in RFC 2822 representation of the last modification date to the file in RFC 2822
[5] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be [5] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be
used. The value of this parameter SHOULD be the same of the used. The value of this parameter SHOULD be the same of the
'modification-date' parameter of Content-Disposition header field [3] 'modification-date' parameter of Content-Disposition header field [3]
that could be signalled by the actual file transfer. that could be signalled by the actual file transfer protocol.
The 'read' parameter indicates the date at which the file was last The 'read' parameter indicates the date at which the file was last
read. The value MUST be a quoted string which contains a read. The value MUST be a quoted string which contains a
representation of the last date the file was read in RFC 2822 [5] representation of the last date the file was read in RFC 2822 [5]
'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used.
The value of this parameter SHOULD be the same of the 'read-date' The value of this parameter SHOULD be the same of the 'read-date'
parameter of Content-Disposition header field [3] that could be parameter of Content-Disposition header field [3] that could be
signalled by the actual file transfer. signalled by the actual file transfer protocol.
The 'icon' attribute can be useful with certain file types such as The 'file-icon' attribute can be useful with certain file types such
images. It allows the sender to include a pointer to a body that as images. It allows the sender to include a pointer to a body that
includes a small preview icon representing the contents of the file includes a small preview icon representing the contents of the file
to be transferred. This allows the sender to include the icon as to be transferred. This allows the sender to include the icon as
another body accompanying the SDP, and to the recipient to get the another body accompanying the SDP, and to the recipient to get the
icon of the file to be transferred. It is recommended to keep icons icon of the file to be transferred. It is recommended to keep icons
restricted to the minimum number of bytes that provide significance. restricted to the minimum number of bytes that provide significance.
The 'icon' attribute contains a Content-ID URL, which is specified in The 'file-icon' attribute contains a Content-ID URL, which is
RFC 2392 [4]. specified in RFC 2392 [4].
The 'file-range' attribute provides a mechanism to signal a chunk of The 'file-range' attribute provides a mechanism to signal a chunk of
a file rather than the complete file. This enable use cases where a a file rather than the complete file. This enable use cases where a
file transfer can be interrupted, resumed, even perhaps changing one file transfer can be interrupted, resumed, even perhaps changing one
of the endpoints. The 'file-range' attribute is composed to two of the endpoints. The 'file-range' attribute is composed to two
integer values separated by a dash "-". The first integer value integer values separated by a dash "-". The first integer value
refers to the first byte of the file to be transferred. The second refers to the first byte of the file to be transferred. The second
integer value refers to the last byte of the file to be transferred. integer value refers to the last byte of the file to be transferred.
The first byte of a file is indicated with "1". The absence of this The first byte of a file is indicated with "1". The absence of this
attribute indicates a complete file, i.e., like if the 'file-range' attribute indicates a complete file, i.e., like if the 'file-range'
skipping to change at page 14, line 18 skipping to change at page 14, line 18
c=IN IP4 host.atlanta.example.com c=IN IP4 host.atlanta.example.com
t=0 0 t=0 0
m=message 7654 TCP/MSRP * m=message 7654 TCP/MSRP *
i=This is my latest picture i=This is my latest picture
a=sendonly a=sendonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:32349 hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E size:32349 hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E
a=disposition:not-render a=file-disposition:not-render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00" a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00"
a=icon:cid:id2@alicepc.example.com a=file-icon:cid:id2@alicepc.example.com
a=file-range:1-32349 a=file-range:1-32349
Figure 2: Example of SDP describing a file transfer Figure 2: Example of SDP describing a file transfer
NOTE: The 'file-selector' attribute in the above figure is split in NOTE: The 'file-selector' attribute in the above figure is split in
two lines for formatting purposes. Real implementations will encode two lines for formatting purposes. Real implementations will encode
it in a single line. it in a single line.
7. File Disposition Types 7. File Disposition Types
The SDP Offer/Answer for file transfer allows the file sender to The SDP Offer/Answer for file transfer allows the file sender to
indicate a preferred disposition of the file to be transferred in a indicate a preferred disposition of the file to be transferred in a
new 'disposition' attribute. In principle, any value listed in the new 'file-disposition' attribute. In principle, any value listed in
IANA registry for Mail Content Disposition Values [19] is acceptable, the IANA registry for Mail Content Disposition Values [19] is
however, most of them may not be applicable. acceptable, however, most of them may not be applicable.
There are two content dispositions of interest for file transfer There are two content dispositions of interest for file transfer
operations. On one hand, the file sender may just want the file to operations. On one hand, the file sender may just want the file to
be rendered immediately in the file receiver's device. On the other be rendered immediately in the file receiver's device. On the other
hand, the file sender may just want to indicate the file recipient hand, the file sender may just want to indicate the file recipient
that the file should not be rendered at the reception of the file. that the file should not be rendered at the reception of the file.
The recipient's user agent may want to interact with the user The recipient's user agent may want to interact with the user
regarding the file disposition or it may save the file until the user regarding the file disposition or it may save the file until the user
takes an action. In any case, the exact actions are implementation takes an action. In any case, the exact actions are implementation
dependent. dependent.
To indicate that a file should be automatically rendered, this memo To indicate that a file should be automatically rendered, this memo
uses the existing 'render' value of the Content Disposition type in uses the existing 'render' value of the Content Disposition type in
the new 'disposition' attribute in SDP. To indicate that a file the new 'file-disposition' attribute in SDP. To indicate that a file
should not be automatically rendered, this memo defines a new value should not be automatically rendered, this memo defines a new value
'not-render' of the Content Disposition type. The default value is 'not-render' of the Content Disposition type. The default value is
'render', i.e., the absence of a 'disposition' attribute in the SDP 'render', i.e., the absence of a 'file-disposition' attribute in the
has the same semantics as 'render'. SDP has the same semantics as 'render'.
8. Protocol Operation 8. Protocol Operation
This Section discusses how to use the parameters defined in Section 6 This Section discusses how to use the parameters defined in Section 6
in the context of an offer/answer [7] exchange. Additionally, this in the context of an offer/answer [7] exchange. Additionally, this
section also discusses the behavior of the endpoints using MSRP. section also discusses the behavior of the endpoints using MSRP.
Usually the file transfer session is initiated when the offerer sends Usually the file transfer session is initiated when the offerer sends
an SDP offer to the answerer. The answerer either accepts or rejects an SDP offer to the answerer. The answerer either accepts or rejects
the file transfer session and sends an SDP answer to the offerer. the file transfer session and sends an SDP answer to the offerer.
skipping to change at page 16, line 19 skipping to change at page 16, line 19
known when the file sender creates the SDP offer, for example, known when the file sender creates the SDP offer, for example,
because the host is still processing the file. because the host is still processing the file.
The 'hash' parameter in the 'file-selector' attribute contains The 'hash' parameter in the 'file-selector' attribute contains
valuable information to the file receiver to identify whether the valuable information to the file receiver to identify whether the
file is already available and need not be transmitted. If the file is already available and need not be transmitted. If the
sender supports several hashing algorithms, then several 'hash' sender supports several hashing algorithms, then several 'hash'
parameters can be included. parameters can be included.
The file sender MAY also add a 'name' parameter in the 'file- The file sender MAY also add a 'name' parameter in the 'file-
selector' attribute, and an 'icon', 'disposition', and 'file-date' selector' attribute, and a 'file-icon', 'file-disposition', and
attributes further describing the file to be transferred. The 'file-date' attributes further describing the file to be transferred.
'disposition' attribute provides a presentation suggestion, (for The 'file-disposition' attribute provides a presentation suggestion,
example: the file sender would like the file receiver to render the (for example: the file sender would like the file receiver to render
file or not). The three date attributes provide the answerer with an the file or not). The three date attributes provide the answerer
indication of the age of the file. The file sender MAY also add a with an indication of the age of the file. The file sender MAY also
'file-range' attribute indicating the start and stop offset of the add a 'file-range' attribute indicating the start and stop offset of
file transfer. the file transfer.
8.1.2. The Offerer is a File Receiver 8.1.2. The Offerer is a File Receiver
In a pull operation, the file receiver creates the SDP offer and In a pull operation, the file receiver creates the SDP offer and
sends it to the file sender. The file receiver MUST include a 'file- sends it to the file sender. The file receiver MUST include a 'file-
selector' attribute and SHOULD add, at least, one of the parameters selector' attribute and SHOULD add, at least, one of the parameters
defined for such attribute (i.e., 'name', 'type', 'size', or 'hash'). defined for such attribute (i.e., 'name', 'type', 'size', or 'hash').
Several 'hash' parameters MAY be included if each 'hash' parameter is Several 'hash' parameters MAY be included if each 'hash' parameter is
computed with a different hashing algorithm. In many cases, if the computed with a different hashing algorithm. In many cases, if the
hash of the file is known, that is enough to identify the file, hash of the file is known, that is enough to identify the file,
skipping to change at page 17, line 41 skipping to change at page 17, line 41
file transfer operation is accepted, the file receiver MUST create an file transfer operation is accepted, the file receiver MUST create an
SDP answer according to the procedures specified in RFC 3264 [7]. If SDP answer according to the procedures specified in RFC 3264 [7]. If
the offer contains 'name', 'type', 'size', parameters in the 'file- the offer contains 'name', 'type', 'size', parameters in the 'file-
selector' attribute, the answerer MUST copy them into the answer. If selector' attribute, the answerer MUST copy them into the answer. If
the offer contains one ore more 'hash' parameters in the 'file- the offer contains one ore more 'hash' parameters in the 'file-
selector' attribute, the answerer discards those with non-supported selector' attribute, the answerer discards those with non-supported
hashing algorithms and MUST copy the remaining (if any) to the 'file- hashing algorithms and MUST copy the remaining (if any) to the 'file-
selector' attribute of the answer. This informs the offerer that the selector' attribute of the answer. This informs the offerer that the
answerer supports this specification. Then the file receiver MUST answerer supports this specification. Then the file receiver MUST
add a 'recvonly' attribute according to the procedures specified in add a 'recvonly' attribute according to the procedures specified in
RFC 3264 [7]. The file receiver MUST NOT include 'icon', RFC 3264 [7]. The file receiver MUST NOT include 'file-icon', 'file-
'disposition', or 'file-date' attributes in the SDP answer. disposition', or 'file-date' attributes in the SDP answer.
If the SDP offer contains one or more 'hash' parameters in the 'file- If the SDP offer contains one or more 'hash' parameters in the 'file-
selector' attribute, the answerer discards those with unsupported selector' attribute, the answerer discards those with unsupported
hashing algorithms. The file receiver can use the remaining hashes hashing algorithms. The file receiver can use the remaining hashes
to find out if a local file with the same hash is already available, to find out if a local file with the same hash is already available,
in which case, this could imply the reception of a duplicated file. in which case, this could imply the reception of a duplicated file.
It is up to the answerer to determine whether the file transfer is It is up to the answerer to determine whether the file transfer is
accepted or not in case of a duplicated file. accepted or not in case of a duplicated file.
If the SDP offer contains a 'file-range' attribute and the file If the SDP offer contains a 'file-range' attribute and the file
skipping to change at page 18, line 39 skipping to change at page 18, line 39
decides to accept the file transfer, the file sender MUST create an decides to accept the file transfer, the file sender MUST create an
SDP answer that contains a 'sendonly' attribute, according to the SDP answer that contains a 'sendonly' attribute, according to the
procedures described RFC 3264 [7]. If the SDP offer included several procedures described RFC 3264 [7]. If the SDP offer included several
'hash' parameters, the file sender SHOULD include at least one in the 'hash' parameters, the file sender SHOULD include at least one in the
SDP answer, selected among those present in the offer and, at 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 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 include a 'hash' parameter, the file sender SHOULD add one or more
'hash' parameters, according to the supported hashing algorithms. 'hash' parameters, according to the supported hashing algorithms.
The file sender MAY also include a 'type' parameter in the 'file- The file sender MAY also include a 'type' parameter in the 'file-
selector' attribute line of the SDP answer. The answerer MAY also selector' attribute line of the SDP answer. The answerer MAY also
include an 'icon' and 'disposition' attributes to further describe include a 'file-icon' and 'file-disposition' attributes to further
the file. Although the answerer MAY also include a 'name' and 'size' describe the file. Although the answerer MAY also include a 'name'
parameters in the 'file-selector' attribute, and a 'file-date' and 'size' parameters in the 'file-selector' attribute, and a 'file-
attribute, it is RECOMMENDED not to include them in the SDP answer if date' attribute, it is RECOMMENDED not to include them in the SDP
the actual file transfer protocol (e.g., MSRP [11]) can accommodate a answer if the actual file transfer protocol (e.g., MSRP [11]) can
Content-Disposition header field [3] with the equivalent parameters. accommodate a Content-Disposition header field [3] with the
equivalent parameters.
The whole idea of adding file descriptors to SDP is to provide a The whole idea of adding file descriptors to SDP is to provide a
mechanism where a file transfer can be accepted prior to its mechanism where a file transfer can be accepted prior to its
start. Adding any SDP attributes that are otherwise signalled start. Adding any SDP attributes that are otherwise signalled
later in the file transfer protocol would just duplicate the later in the file transfer protocol would just duplicate the
information, but will not provide any information to the offerer information, but will not provide any information to the offerer
to accept or reject the file transfer (note that the offerer is to accept or reject the file transfer (note that the offerer is
requesting a file). requesting a file).
Last, if the file selector points to multiple candidate files, the Last, if the file selector points to multiple candidate files, the
skipping to change at page 22, line 33 skipping to change at page 22, line 33
c=IN IP4 alicepc.example.com c=IN IP4 alicepc.example.com
t=0 0 t=0 0
m=message 7654 TCP/MSRP * m=message 7654 TCP/MSRP *
i=This is my latest picture i=This is my latest picture
a=sendonly a=sendonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:4092 hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E size:4092 hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E
a=disposition:render a=file-disposition:render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00" a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00"
a=icon:cid:id2@alicepc.example.com a=file-icon:cid:id2@alicepc.example.com
--boundary71 --boundary71
Content-Type: image/jpeg Content-Type: image/jpeg
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.example.com> Content-ID: <id2@alicepc.example.com>
Content-Length: [length of image] Content-Length: [length of image]
Content-Disposition: icon Content-Disposition: icon
...small preview icon of the file... [...small preview icon of the file...]
--boundary71-- --boundary71--
Figure 4: INVITE request containing an SDP offer for file transfer Figure 4: INVITE request containing an SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split in NOTE: The 'file-selector' attribute in the above figure is split in
two lines for formatting purposes. Real implementations will encode two lines for formatting purposes. Real implementations will encode
it in a single line. it in a single line.
From now on we omit the SIP details for the sake of brevity. From now on we omit the SIP details for the sake of brevity.
skipping to change at page 29, line 33 skipping to change at page 29, line 33
c=IN IP4 alicepc.example.com c=IN IP4 alicepc.example.com
t=0 0 t=0 0
m=message 5670 TCP/MSRP * m=message 5670 TCP/MSRP *
i=This is my latest picture i=This is my latest picture
a=sendonly a=sendonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:5670/iau39;tcp a=path:msrp://alicepc.example.com:5670/iau39;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:58231FE8653BBCF371362F86D471913EE4B1DF2F size:4096 hash:sha-1:58231FE8653BBCF371362F86D471913EE4B1DF2F
a=disposition:render a=file-disposition:render
a=file-date:creation:"Sun, 21 May 2006 13:02:15 +03:00" a=file-date:creation:"Sun, 21 May 2006 13:02:15 +03:00"
a=icon:cid:id3@alicepc.example.com a=file-icon:cid:id3@alicepc.example.com
--boundary71 --boundary71
Content-Type: image/jpeg Content-Type: image/jpeg
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <id3@alicepc.example.com> Content-ID: <id3@alicepc.example.com>
Content-Length: [length of image] Content-Length: [length of image]
Content-Disposition: icon Content-Disposition: icon
...small preview icon... [..small preview icon...]
--boundary71-- --boundary71--
Figure 15: Reuse of the SDP in a second file transfer Figure 15: Reuse of the SDP in a second file transfer
NOTE: The 'file-selector' attribute in the above figure is split in NOTE: The 'file-selector' attribute in the above figure is split in
two lines for formatting purposes. Real implementations will encode two lines for formatting purposes. Real implementations will encode
it in a single line. it in a single line.
F7: Bob receives the re-INVITE request, inspects the SDP offer and F7: Bob receives the re-INVITE request, inspects the SDP offer and
skipping to change at page 30, line 23 skipping to change at page 30, line 23
s= s=
c=IN IP4 bobpc.example.com c=IN IP4 bobpc.example.com
t=0 0 t=0 0
m=message 9999 TCP/MSRP * m=message 9999 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:9999/9an4ea;tcp a=path:msrp://bobpc.example.com:9999/9an4ea;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:58231FE8653BBCF371362F86D471913EE4B1DF2F size:4096 hash:sha-1:58231FE8653BBCF371362F86D471913EE4B1DF2F
a=disposition:render a=file-disposition:render
Figure 16: SDP answer accepting the SDP offer for file transfer Figure 16: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split in NOTE: The 'file-selector' attribute in the above figure is split in
two lines for formatting purposes. Real implementations will encode two lines for formatting purposes. Real implementations will encode
it in a single line. it in a single line.
F9: Alice opens a new TCP connection to Bob and creates an MSRP SEND F9: Alice opens a new TCP connection to Bob and creates an MSRP SEND
request that contains the file. request that contains the file.
skipping to change at page 31, line 45 skipping to change at page 31, line 45
F11: Then Bob terminates the SIP session by sending a SIP BYE F11: Then Bob terminates the SIP session by sending a SIP BYE
request. request.
F12: Alice acknowledges the reception of the BYE request and sends a F12: Alice acknowledges the reception of the BYE request and sends a
200 (OK) response. 200 (OK) response.
9.3. Example of a capability indication 9.3. Example of a capability indication
Alice sends an OPTIONS request to Bob (this request does not contain Alice sends an OPTIONS request to Bob (this request does not contain
SDP). Bob answers with a 200 (OK) response that contain the SDP SDP). Bob answers with a 200 (OK) response that contain the SDP
shown in Figure . shown in Figure 20. The SDP indicates support for CPIM messages that
can contain other few MIME types. The presence of the 'file-
selector' attribute indicates support for the file transfer offer/
answer mechanism.
Alice's UAC Bob's UAS Alice's UAC Bob's UAS
| | | |
|(1) (SIP) OPTIONS | |(1) (SIP) OPTIONS |
|----------------------->| |----------------------->|
|(2) (SIP) 200 OK | |(2) (SIP) 200 OK |
| with SDP | | with SDP |
|<-----------------------| |<-----------------------|
| | | |
| | | |
Figure 19: Flow diagram of a capability request Figure 19: Flow diagram of a capability request
v=0 v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=- s=-
c=IN IP4 bobpc.example.com c=IN IP4 bobpc.example.com
t=0 0 t=0 0
m=message 0 TCP/MSRP * m=message 0 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html image/jpeg image/gif
a=file-selector a=file-selector
Figure 20: SDP of the 200 (OK) response to an OPTIONS request Figure 20: SDP of the 200 (OK) response to an OPTIONS request
10. Security Considerations 10. Security Considerations
The SDP attributed defined in this specification identify a file to The SDP attributed defined in this specification identify a file to
be transfered between two endpoints. An endpoint can offer to send be transfered between two endpoints. An endpoint can offer to send
the file to the other endpoint or request to receive the file from the file to the other endpoint or request to receive the file from
the other endpoint. In the former case, an attacker modifying those the other endpoint. In the former case, an attacker modifying those
skipping to change at page 33, line 24 skipping to change at page 33, line 24
registry [20]. The registration data, according to RFC 4566 [10] registry [20]. The registration data, according to RFC 4566 [10]
follows. follows.
Note to the RFC Editor: replace "RFC XXXX" with the RFC number of Note to the RFC Editor: replace "RFC XXXX" with the RFC number of
this specification. this specification.
11.1.1. Registration of the file-selector attribute 11.1.1. Registration of the file-selector attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: file-sector Attribute name: file-selector
Long-form attribute name: Long-form attribute name:
Type of attribute: media level only Type of attribute: media level only
This attribute is subject to the charset attribute This attribute is subject to the charset attribute
Description: This attribute unambiguously identify a file by Description: This attribute unambiguously identify a file by
indicating a combination of the 4-tuple composed of the name, indicating a combination of the 4-tuple composed of the name,
size, type, and hash of the file. size, type, and hash of the file.
Specification: RFC XXXX Specification: RFC XXXX
11.1.2. Registration of the disposition attribute 11.1.2. Registration of the file-disposition attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: disposition Attribute name: file-disposition
Long-form attribute name: Long-form attribute name:
Type of attribute: media level only Type of attribute: media level only
This attribute is not subject to the charset attribute This attribute is not subject to the charset attribute
Description: This attribute provides a suggestion to the other Description: This attribute provides a suggestion to the other
endpoint about the intended disposition of the file endpoint about the intended disposition of the file
Specification: RFC XXXX Specification: RFC XXXX
11.1.3. Registration of the file-date attribute 11.1.3. Registration of the file-date attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: file-date Attribute name: file-date
Long-form attribute name: Long-form attribute name:
Type of attribute: media level only Type of attribute: media level only
This attribute is not subject to the charset attribute This attribute is not subject to the charset attribute
Description: This attribute indicates the dates at which the file Description: This attribute indicates the dates at which the file
was created, modified, or last read. was created, modified, or last read.
Specification: RFC XXXX Specification: RFC XXXX
11.1.4. Registration of the icon attribute 11.1.4. Registration of the file-icon attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: icon Attribute name: file-icon
Long-form attribute name: Long-form attribute name:
Type of attribute: media level only Type of attribute: media level only
This attribute is not subject to the charset attribute This attribute is not subject to the charset attribute
Description: For image files, this attribute contains a pointer to Description: For image files, this attribute contains a pointer to
a body that includes a small preview icon representing the a body that includes a small preview icon representing the
contents of the file to be transferred contents of the file to be transferred
Specification: RFC XXXX Specification: RFC XXXX
11.1.5. Registration of the file-range attribute 11.1.5. Registration of the file-range attribute
skipping to change at page 35, line 12 skipping to change at page 35, line 12
Note to the RFC Editor: Please replace RFCXXXX with the RFC number of Note to the RFC Editor: Please replace RFCXXXX with the RFC number of
this specification. this specification.
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 discussed and provided comments and improvements to this Courmont, and Colin Perkins discussed and provided comments and
document. improvements to this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
 End of changes. 41 change blocks. 
62 lines changed or deleted 68 lines changed or added

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