draft-ietf-mmusic-file-transfer-mech-04.txt   draft-ietf-mmusic-file-transfer-mech-05.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: April 26, 2008 Nokia Expires: May 19, 2008 Nokia
G. Camarillo G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
October 24, 2007 P. Kyzivat
Cisco Systems
November 16, 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-04.txt draft-ietf-mmusic-file-transfer-mech-05.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 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 April 26, 2008. This Internet-Draft will expire on May 19, 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 23 skipping to change at page 3, line 23
6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9
7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 15 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 15
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 16 8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . 20 8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 21
8.4. Indicating File Transfer Offer/Answer Capability . . . . . 22 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 . . . . . . 24
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
skipping to change at page 10, line 33 skipping to change at page 10, line 33
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 4234 ; HEXDIG defined in RFC 4234
file-tr-id-attr = "file-transfer-id:" file-transfer-id-value file-tr-id-attr = "file-transfer-id:" file-tr-id-value
file-transfer-value = token file-tr-id-value = token
file-disp-attr = "file-disposition:" file-disp-value file-disp-attr = "file-disposition:" file-disp-value
file-disp-value = token file-disp-value = token
file-date-attr = "file-date:" date-param *(SP date-param) file-date-attr = "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 files. ; DQUOTE defined in RFC 4234 files.
file-icon-attr = "file-icon:" file-icon-value file-icon-attr = "file-icon:" file-icon-value
file-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:" start-range "-" end-range file-range-attr = "file-range:" start-offset "-" stop-offset
start-range = integer ;integer defined in RFC 4566 start-offset = integer ;integer defined in RFC 4566
end-range = integer / "*" stop-offset = integer / "*"
Figure 1: Syntax of the SDP extension Figure 1: Syntax of the SDP extension
When used for capability query (see Section 8.4), the 'file-selector' When used for capability query (see Section 8.4), the 'file-selector'
attribute MUST NOT contain any selector, because its presence merely attribute MUST NOT contain any selector, because its presence merely
indicates compliance to this specification. 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
MUST contain at least one selector. Selectors characterize the file MUST contain at least one selector. Selectors characterize the file
to be transferred. There are four selectors in this attribute: to be transferred. There are four selectors in this attribute:
skipping to change at page 12, line 33 skipping to change at page 12, line 33
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 support the US Secure Hash Algorithm 1 (SHA1) specification MUST add a US Secure Hash Algorithm 1 (SHA1) [RFC3174]
[RFC3174]. If need arises, extensions can be drafted to support value if the 'hash' selector is present. If need arises, extensions
several hashing algorithms. Therefore, implementations according to can be drafted to support several hashing algorithms. Therefore,
this specification MUST be prepared to receive SDP containing more implementations according to this specification MUST be prepared to
than a single 'hash' selector in the 'file-selector' attribute. 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 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 unique identification to The 'file-transfer-id' attribute provides a unique identification to
the actual file transfer. It is used to distinguish a new file the actual file transfer. It is used to distinguish a new file
transfer request from a repetition of the SDP (or the fraction of the transfer request from a repetition of the SDP (or the fraction of the
SDP that deals with the file description). This attribute is SDP that deals with the file description). This attribute is
skipping to change at page 14, line 4 skipping to change at page 14, line 5
that includes a small preview icon representing the contents of the that includes a small preview icon representing the contents of the
file to be transferred, which the file receiver can use to determine file to be transferred, which the file receiver can use to determine
whether it wants to receive such file. The 'file-icon' attribute whether it wants to receive such file. The 'file-icon' attribute
contains a Content-ID URL, which is specified in RFC 2392 [RFC2392]. contains a Content-ID URL, which is specified in RFC 2392 [RFC2392].
Section 8.7 contains further considerations about the 'file-icon' Section 8.7 contains further considerations about the 'file-icon'
attribute. attribute.
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 contains the start of the endpoints. The 'file-range' attribute contains the "start
range and end range of the file, separated by a dash "-". The start offset" and "stop offset" of the file, separated by a dash "-". The
range value refers to the position of the file where the file "start offset" value refers to the position of the file where the
transfer should start. The first byte of a file gets the ordinal file transfer should start. The first byte of a file is denoted by
number "1". The end range value refers position of the file where the ordinal number "1". The "stop offset" value refers position of
the file transfer should stop. The end range value MAY contain a "*" the file where the file transfer should stop. The "stop offset"
if the total size of the file is not known in advance. The absence value MAY contain a "*" if the total size of the file is not known in
of this attribute indicates a complete file, i.e., as if the 'file- advance. The absence of this attribute indicates a complete file,
range' attribute would have been present with a value 1-*. The i.e., as if the 'file-range' attribute would have been present with a
'file-range' attribute must not be confused with the Byte-Range value "1-*". The 'file-range' attribute must not be confused with
header in MSRP. The former indicates the portion of a file that the the Byte-Range header in MSRP. The former indicates the portion of a
application would read and pass onto the MSRP stack for file that the application would read and pass onto the MSRP stack for
transportation. From the point of view of MSRP, the portion of the transportation. From the point of view of MSRP, the portion of the
file is viewed as a whole message. The latter indicates the number file is viewed as a whole message. The latter indicates the number
of bytes of that message that are carried in a chunk and the total of bytes of that message that are carried in a chunk and the total
size of the message. Therefore, MSRP starts counting the delivered size of the message. Therefore, MSRP starts counting the delivered
message at byte number 1, independently of position of that byte in message at byte number 1, independently of position of that byte in
the file. the file.
The following is an example of an SDP body that contains the The following is an example of an SDP body that contains the
extensions defined in this memo: extensions defined in this memo:
skipping to change at page 16, line 42 skipping to change at page 16, line 42
etc.) MUST be included as well. For each file to be transferred etc.) MUST be included as well. For each file to be transferred
there MUST be a separate "m=" line. there MUST be a separate "m=" line.
8.1.1. The Offerer is a File Sender 8.1.1. The Offerer is a File Sender
In a push operation, the file sender creates and SDP offer describing In a push operation, the file sender creates and SDP offer describing
the file to be sent. The file sender MUST add a 'file-selector' the file to be sent. The file sender MUST add a 'file-selector'
attribute media line containing at least one of the 'type', 'size', attribute media line containing at least one of the 'type', 'size',
'hash' selectors in indicating the type, size, or hash of the file, 'hash' selectors in indicating the type, size, or hash of the file,
respectively. The file sender MUST add a 'file-transfer-id' respectively. The file sender MUST add a 'file-transfer-id'
attribute containing a new identifier value, i.e., not used within attribute containing a new randomly chosen identifier value, which
the current session. Additionally, the file sender MUST add a does not clash with other previously used values in the same
session or media 'sendonly' attribute to the SDP offer. Then the attribute. Additionally, the file sender MUST add a session or media
file sender sends the SDP offer to the file receiver. 'sendonly' attribute to the SDP offer. Then the file sender sends
the SDP offer to the file receiver.
Not all the selectors in the 'file-selector' attribute might be Not all the selectors in the 'file-selector' attribute might be
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' selector in the 'file-selector' attribute contains The 'hash' selector 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. file is already available and need not be transmitted.
The file sender MAY also add a 'name' selector in the 'file-selector' The file sender MAY also add a 'name' selector in the 'file-selector'
skipping to change at page 18, line 19 skipping to change at page 18, line 23
generates an "m=" line per file along with the file attributes generates an "m=" line per file along with the file attributes
described in this specification. This way, the answerer can reject described in this specification. This way, the answerer can reject
individual files by setting the port number of their associated "m=" individual files by setting the port number of their associated "m="
lines to zero, as per regular SDP [RFC4566] procedures. Each file lines to zero, as per regular SDP [RFC4566] procedures. Each file
has its own file transfer identifier, which uniquely identifies each has its own file transfer identifier, which uniquely identifies each
file transfer. file transfer.
Using an "m=" line per file implies that different files are Using an "m=" line per file implies that different files are
transferred using different MSRP sessions. However, all those MSRP transferred using different MSRP sessions. However, all those MSRP
sessions can be set up to run over a single TCP connection, as sessions can be set up to run over a single TCP connection, as
described in Section 8.1 of RFC 4975 [RFC4975]. described in Section 8.1 of RFC 4975 [RFC4975]. The same TCP
connection can also be re-used for sequential file transfers.
8.2. Answerer's Behavior 8.2. Answerer's Behavior
If the answerer wishes to reject a file offered by the offerer, it If the answerer wishes to reject a file offered by the offerer, it
sets the port number of the "m=" line associated with the file to sets the port number of the "m=" line associated with the file to
zero, as per regular SDP [RFC4566] procedures. The rejected answer zero, as per regular SDP [RFC4566] procedures. The rejected answer
MUST contained a 'file-selector' and 'file-transfer-id' attributes MUST contained a 'file-selector' and 'file-transfer-id' attributes
whose values mirror the corresponding values of the SDP offer. whose values mirror the corresponding values of the SDP offer.
If the answerer decides to accept the file, it proceeds as per If the answerer decides to accept the file, it proceeds as per
regular MSRP [RFC4975] and SDP [RFC4566] procedures. regular MSRP [RFC4975] and SDP [RFC4566] procedures.
8.2.1. The Answerer is a File Receiver 8.2.1. The Answerer is a File Receiver
In a push operation the SDP answerer is the file receiver. When the In a push operation the SDP answerer is the file receiver. When the
file receiver gets the SDP offer, it extracts the attributes and file receiver gets the SDP offer, it first examines the 'file-
parameters that describe the file and typically requests permission transfer-id' attribute. If the value of the 'file-transfer-id'
from the user to accept or reject the reception of the file. If the attribute has been previously used then the existing session remains
file transfer operation is accepted, the file receiver MUST create an without changes, perhaps the file transfer is still in progress, or
SDP answer according to the procedures specified in RFC 3264 perhaps it has concluded, but there are no change with respect the
[RFC3264]. If the offer contains 'name', 'type', 'size' selectors in current status. The SDP answerer creates a regular SDP answer and
the 'file-selector' attribute, the answerer MUST copy them into the sends it to the offerer.
answer. The file receiver copies the value of the 'file-transfer-id'
attribute to the SDP answer. Then the file receiver MUST add a If the SDP offer contains a new 'file-transfer-id' attribute, then
session or media 'recvonly' attribute according to the procedures this signals a request for a new file transfer. The SDP answerer
specified in RFC 3264 [RFC3264]. The file receiver MUST NOT include extracts the attributes and parameters that describe the file and
'file-icon', 'file-disposition', or 'file-date' attributes in the SDP typically requests permission from the user to accept or reject the
answer. reception of the file. If the file transfer operation is accepted,
the file receiver MUST create an SDP answer according to the
procedures specified in RFC 3264 [RFC3264]. If the offer contains
'name', 'type', 'size' selectors in the 'file-selector' attribute,
the answerer MUST copy them into the answer. The file receiver
copies the value of the 'file-transfer-id' attribute to the SDP
answer. Then the file receiver MUST add a session or media
'recvonly' attribute according to the procedures specified in RFC
3264 [RFC3264]. The file receiver MUST NOT include 'file-icon',
'file-disposition', or 'file-date' attributes in the SDP answer.
The file receiver can use the hash to find out if a local file with The file receiver can use the hash to find out if a local file with
the same hash is already available, in which case, this could imply the same hash is already available, in which case, this could imply
the reception of a duplicated file. It is up to the answerer to the reception of a duplicated file. It is up to the answerer to
determine whether the file transfer is accepted or not in case of a determine whether the file transfer is accepted or not in case of a
duplicated file. 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
receiver accepts to receive the range of bytes declared in there, the receiver accepts to receive the range of bytes declared in there, the
file receiver MUST include a 'file-range' attribute in the SDP answer file receiver MUST include a 'file-range' attribute in the SDP answer
skipping to change at page 24, line 15 skipping to change at page 24, line 29
once more the definition of "MSRP message"). File receivers MAY add once more the definition of "MSRP message"). File receivers MAY add
a 'max-size' attribute to the MSRP m= line that specifies the file, a 'max-size' attribute to the MSRP m= line that specifies the file,
indicating the maximum number of octets of an MSRP message. File indicating the maximum number of octets of an MSRP message. File
senders MUST NOT exceed the 'max-size' limit for any message sent in senders MUST NOT exceed the 'max-size' limit for any message sent in
the resulting session. the resulting session.
In the absence of a 'file-range' attribute in the SDP, the MSRP file In the absence of a 'file-range' attribute in the SDP, the MSRP file
transfer MUST start with the first byte of the file and end with the transfer MUST start with the first byte of the file and end with the
last byte (i.e., the whole file is transferred). If a 'file-range' last byte (i.e., the whole file is transferred). If a 'file-range'
attribute is present in SDP, the file sender application MUST extract attribute is present in SDP, the file sender application MUST extract
the indicated range of bytes from the file (start and stop bytes). the indicated range of bytes from the file (start and stop offset
Then the file sender application MAY wrap those bytes in an bytes). Then the file sender application MAY wrap those bytes in an
appropriate wrapper. MSRP mandates implementations to implement the appropriate wrapper. MSRP mandates implementations to implement the
message/cpim wrapper [RFC3862]. Usage of a wrapper is negotiated in message/cpim wrapper [RFC3862]. Usage of a wrapper is negotiated in
the SDP (see Section 8.6 in RFC 4975 [RFC4975]). Last, the file the SDP (see Section 8.6 in RFC 4975 [RFC4975]). Last, the file
sender application delivers the content (e.g., the message/cpim body) sender application delivers the content (e.g., the message/cpim body)
to MSRP for transportation. MSRP will consider the delivered content to MSRP for transportation. MSRP will consider the delivered content
as a whole message, and will start numbering bytes with the number 1. as a whole message, and will start numbering bytes with the number 1.
Note that the default content disposition of MSRP bodies is 'render'. Note that the default content disposition of MSRP bodies is 'render'.
When MSRP is used to transfer files, the MSRP Content-Disposition When MSRP is used to transfer files, the MSRP Content-Disposition
header can also take the value 'attachment' as indicated in header can also take the value 'attachment' as indicated in
skipping to change at page 33, line 29 skipping to change at page 33, line 29
Figure 12: SDP answer accepting the SDP offer for file transfer Figure 12: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split NOTE: The 'file-selector' attribute in the above figure is split
in two lines for formatting purposes. Real implementations will in two lines for formatting purposes. Real implementations will
encode it in a single line. encode it in a single line.
F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP
SEND request that contains the file. SEND request that contains the file.
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7654/iau39;tcp To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Byte-Range: 1-2027/2027 Byte-Range: 1-2027/2027
Content-Type: message/cpim Content-Type: message/cpim
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00 DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool photo.jpg"; Content-Disposition: render; filename="My cool photo.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300"; creation-date="Mon, 15 May 2006 15:01:31 +0300";
skipping to change at page 34, line 7 skipping to change at page 34, line 7
...binary JPEG image... ...binary JPEG image...
-------d93kswow$ -------d93kswow$
Figure 13: MSRP SEND request containing the actual file Figure 13: MSRP SEND request containing the actual file
F5: Alice acknowledges the reception of the SEND request. F5: Alice acknowledges the reception of the SEND request.
MSRP d93kswow 200 OK MSRP d93kswow 200 OK
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
Byte-Range: 1-2027/2027 Byte-Range: 1-2027/2027
-------d93kswow$ -------d93kswow$
Figure 14: MSRP 200 OK response Figure 14: MSRP 200 OK response
F6: Alice re-uses the existing SDP media line inserting the F6: Alice re-uses the existing SDP media line inserting the
description of the file to be sent and attaches it to a SIP re-INVITE description of the file to be sent and attaches it to a SIP re-INVITE
request addressed to Bob. request addressed to Bob. Alice reuses the TCP port number for the
MSRP stream, but changes the MSRP session and the 'file-transfer-id'
value according to this specification.
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>;tag=1928323431 To: Bob <sip:bob@example.com>;tag=1928323431
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 2 INVITE CSeq: 2 INVITE
Max-Forwards: 70 Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:33 GMT Date: Sun, 21 May 2006 13:02:33 GMT
Contact: <sip:alice@alicepc.example.com> Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp"; Content-Type: multipart/related; type="application/sdp";
skipping to change at page 35, line 26 skipping to change at page 35, line 26
--boundary71 --boundary71
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: [length of SDP] Content-Length: [length of SDP]
v=0 v=0
o=alice 2890844526 2890844527 IN IP4 alicepc.example.com o=alice 2890844526 2890844527 IN IP4 alicepc.example.com
s= s=
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 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:5670/iau39;tcp a=path:msrp://alicepc.example.com:7654/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: size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F 58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render a=file-disposition:render
a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300" a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300"
a=file-icon:cid:id3@alicepc.example.com a=file-icon:cid:id3@alicepc.example.com
--boundary71 --boundary71
Content-Type: image/jpeg Content-Type: image/jpeg
skipping to change at page 36, line 11 skipping to change at page 36, line 11
--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 Content-Type header field and the 'file-selector' NOTE: The Content-Type header field and the 'file-selector'
attribute in the above figure are split in several lines for attribute in the above figure are split in several lines for
formatting purposes. Real implementations will encode it in a formatting purposes. Real implementations will encode it in a
single line. 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
extracts the icon body, checks the creation date and file size, and extracts the icon body, checks the creation date and file size, and
decides to accept the file transfer. So Bob creates the following decides to accept the file transfer. So Bob creates an SDP answer
SDP answer: where he reuses the same TCP port number, but changes his MSRP
session, according to the procedures of this specification.
v=0 v=0
o=bob 2890844656 2890855440 IN IP4 bobpc.example.com o=bob 2890844656 2890855440 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 9999 TCP/MSRP * m=message 8888 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:8888/eh10dsk;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1: size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F 58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-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 NOTE: The 'file-selector' attribute in the above figure is split
in three lines for formatting purposes. Real implementations will in three lines for formatting purposes. Real implementations will
encode it in a single line. encode it in a single line.
F9: Alice opens a new TCP connection to Bob and creates an MSRP SEND F9: If a TCP connection towards Bob is already open, Alice re-uses
request that contains the file. that TCP connection to send an MSRP SEND request that contains the
file.
MSRP d95ksxox SEND MSRP d95ksxox SEND
To-Path: msrp://bobpc.example.com:9999/9an4ea;tcp To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
From-Path: msrp://alicepc.example.com:5670/iau39;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 13449sdqwer Message-ID: 13449sdqwer
Byte-Range: 1-2027/2027 Byte-Range: 1-2027/2027
Content-Type: message/cpim Content-Type: message/cpim
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
DateTime: 2006-05-21T13:02:15-03:00 DateTime: 2006-05-21T13:02:15-03:00
Content-Disposition: render; filename="Sunset.jpg"; Content-Disposition: render; filename="Sunset.jpg";
creation-date="Sun, 21 May 2006 13:02:15 -0300"; creation-date="Sun, 21 May 2006 13:02:15 -0300";
size=1931 size=1931
Content-Type: image/jpeg Content-Type: image/jpeg
...binary JPEG image... ...binary JPEG image...
-------d95ksxox+ -------d95ksxox+
Figure 17: MSRP SEND request containing the actual file Figure 17: MSRP SEND request containing the actual file
F10: Bob acknowledges the reception of the SEND request. F10: Bob acknowledges the reception of the SEND request.
MSRP d95ksxox 200 OK MSRP d95ksxox 200 OK
To-Path: msrp://alicepc.example.com:5670/iau39;tcp To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:9999/9an4ea;tcp From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
Byte-Range: 1-2027/2027 Byte-Range: 1-2027/2027
-------d95ksxox$ -------d95ksxox$
Figure 18: MSRP 200 OK response Figure 18: MSRP 200 OK response
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.
skipping to change at page 38, line 32 skipping to change at page 38, line 32
m=message 0 TCP/MSRP * m=message 0 TCP/MSRP *
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=max-size:20000 a=max-size:20000
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 attributes defined in this specification identify a file to
be transferred between two endpoints. An endpoint can offer to send be transferred 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
SDP attributes could cheat the receiver making it think that the file SDP attributes could cheat the receiver making it think that the file
to be transferred was a different one. In the latter case, the to be transferred was a different one. In the latter case, the
attacker could make the sender send a different file than the one attacker could make the sender send a different file than the one
requested by the receiver. Consequently, it is RECOMMENDED that requested by the receiver. Consequently, it is RECOMMENDED that
integrity protection be applied to the SDP session descriptions integrity protection be applied to the SDP session descriptions
carrying the attributes specified in this specification. carrying the attributes specified in this specification.
skipping to change at page 43, line 15 skipping to change at page 43, line 15
[RFC4483] Burger, E., "A Mechanism for Content Indirection in [RFC4483] Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483, Session Initiation Protocol (SIP) Messages", RFC 4483,
May 2006. May 2006.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976, for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007. September 2007.
[I-D.ietf-rmt-flute-revised] [I-D.ietf-rmt-flute-revised]
Paila, T., "FLUTE - File Delivery over Unidirectional Paila, T., "FLUTE - File Delivery over Unidirectional
Transport", draft-ietf-rmt-flute-revised-04 (work in Transport", draft-ietf-rmt-flute-revised-05 (work in
progress), October 2007. progress), October 2007.
URIs URIs
[1] <http://www.iana.org/assignments/media-types/> [1] <http://www.iana.org/assignments/media-types/>
[2] <http://www.iana.org/assignments/hash-function-text-names> [2] <http://www.iana.org/assignments/hash-function-text-names>
[3] <http://www.iana.org/assignments/mail-cont-disp> [3] <http://www.iana.org/assignments/mail-cont-disp>
skipping to change at page 45, line 5 skipping to change at page 44, line 20
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Salvatore Loreto Salvatore Loreto
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Salvatore.Loreto@ericsson.com Email: Salvatore.Loreto@ericsson.com
Paul H. Kyzivat
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Email: pkyzivat@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 27 change blocks. 
65 lines changed or deleted 91 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/