draft-ietf-mmusic-file-transfer-mech-00.txt   draft-ietf-mmusic-file-transfer-mech-01.txt 
MMUSIC Working Group M. Garcia-Martin MMUSIC Working Group M. Garcia-Martin
Internet-Draft M. Isomaki Internet-Draft Nokia Siemens Networks
Intended status: Standards Track Nokia Intended status: Standards Track M. Isomaki
Expires: June 21, 2007 G. Camarillo Expires: October 29, 2007 Nokia
G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
December 18, 2006 April 27, 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-00.txt draft-ietf-mmusic-file-transfer-mech-01.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 38 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 June 21, 2007. This Internet-Draft will expire on October 29, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). 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
extended to describe the attributes of the files to be transferred. extended to describe the attributes of the files to be transferred.
The offerer can either describe the files it wants to send, or the The offerer can either describe the files it wants to send, or the
files it would like to receive. The answerer can either accept or files it would like to receive. The answerer can either accept or
reject the offer separately for each individual file . The transfer reject the offer separately for each individual file . The transfer
of one or more files is initiated after a successful negotiation. of one or more files is initiated after a successful negotiation.
The Message Session Relay Protocol (MSRP) is defined as the default The Message Session Relay Protocol (MSRP) is defined as the default
mechanism to actually carry the files between the endpoints. The mechanism to actually carry the files between the endpoints. The
conventions on how to use MSRP for file transfer are also provided in conventions on how to use MSRP for file transfer are also provided in
this document. this document.
Table of Contents Table of Contents
skipping to change at page 2, line 23 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Alternatives Considered . . . . . . . . . . . . . . . . . 5 1.1. Alternatives Considered . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 8 5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9
7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 14
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . 15 8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 16
8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 16 8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 17
8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 16 8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 17
8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 16 8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 17
8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 17 8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 18
8.3. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 18 8.3. Indicating File Transfer Offer/Answer Capability . . . . . 19
8.4. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 19 8.4. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 19
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.5. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 19 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 20
9.2. Offerer requests a file from the Answerer and second 9.2. Offerer requests a file from the Answerer and second
file transfer . . . . . . . . . . . . . . . . . . . . . . 23 file transfer . . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9.3. Example of a capability indication . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11.1. Registration of new SDP attributes . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
11.1.1. Registration of the file-selector attribute . . . . . 30 11.1. Registration of new SDP attributes . . . . . . . . . . . . 33
11.1.2. Registration of the disposition attribute . . . . . . 30 11.1.1. Registration of the file-selector attribute . . . . . 33
11.1.3. Registration of the file-date attribute . . . . . . . 30 11.1.2. Registration of the disposition attribute . . . . . . 33
11.1.4. Registration of the icon attribute . . . . . . . . . . 30 11.1.3. Registration of the file-date attribute . . . . . . . 33
11.1.5. Registration of the file-range attribute . . . . . . . 31 11.1.4. Registration of the icon attribute . . . . . . . . . . 34
11.2. Registration of new Content Disposition value . . . . . . 31 11.1.5. Registration of the file-range attribute . . . . . . . 34
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 11.2. Registration of new Content Disposition value . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.2. Informational References . . . . . . . . . . . . . . . . . 32 13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 13.2. Informational References . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
The Session Description Protocol (SDP) Offer/Answer [7] provides a The Session Description Protocol (SDP) Offer/Answer [7] provides a
mechanism for two endpoints to arrive at a common view of a mechanism for two endpoints to arrive at a common view of a
multimedia session between them. These sessions often contain real- multimedia session between them. These sessions often contain real-
time media streams such as voice and video, but are not limited to time media streams such as voice and video, but are not limited to
that. Basically, any media component type can be supported, as long that. Basically, any media component type can be supported, as long
as there is a specification how to negotiate it within the SDP offer/ as there is a specification how to negotiate it within the SDP offer/
answer exchange. answer exchange.
The Message Session Relay Protocol (MSRP) [12] is a protocol for The Message Session Relay Protocol (MSRP) [11] is a protocol for
transmitting instant messages (IM) in the context of a session. The transmitting instant messages (IM) in the context of a session. The
protocol specification includes a description how to use it with SDP. protocol specification includes a description how to use it with SDP.
In addition to plain text messages, MSRP is able to carry arbitrary In addition to plain text messages, MSRP is able to carry arbitrary
(binary) Multipurpose Internet Mail Extensions (MIME) [2] compliant (binary) Multipurpose Internet Mail Extensions (MIME) [2] compliant
content, such as images or video clips. content, such as images or video clips.
There are many cases where the endpoints involved in a multimedia There are many cases where the endpoints involved in a multimedia
session would like to exchange files within the context of that session would like to exchange files within the context of that
session. With MSRP it is possible to embed files as MIME objects session. With MSRP it is possible to embed files as MIME objects
inside the stream of instant messages. MSRP also has other features inside the stream of instant messages. MSRP also has other features
skipping to change at page 5, line 7 skipping to change at page 5, line 7
on the file before the actual transfer. This MUST be able to on the file before the actual transfer. This MUST be able to
include at least content type, size, hash and name of the file, as include at least content type, size, hash and name of the file, as
well as a short (human readable) description. well as a short (human readable) description.
o It MUST be possible for the recipient to request a file from the o It MUST be possible for the recipient to request a file from the
sender, providing meta information about the file. The sender sender, providing meta information about the file. The sender
MUST be able to decide whether to send a file matching the MUST be able to decide whether to send a file matching the
request. request.
The rest of this document is organized as follows. Section 3 defines The rest of this document is organized as follows. Section 3 defines
a few terms used in this document. Section 4 provides the overview a few terms used in this document. Section 4 provides the overview
of operation. The detailed syntax and semantics of the new SDP of operation. Section 5 introduces the concept of the file selector.
attributes and conventions on how the existing ones are used is The detailed syntax and semantics of the new SDP attributes and
defined in Section 6. Section 8 describes the protocol operation conventions on how the existing ones are used is defined in
involving SDP and MSRP. Finally, some examples are given in Section 6. Section 7 discusses the file disposition types.
Section 9. Section 8 describes the protocol operation involving SDP and MSRP.
Section 8.3 describes the mechanism whereby a user can learn the
support for the functionality described in this specification at a
remote endpoint. Finally, some examples are given in Section 9.
1.1. Alternatives Considered 1.1. Alternatives Considered
The requirements are related to the description and negotiation of The requirements are related to the description and negotiation of
the session, not to the actual file transfer mechanism. Thus, it is the session, not to the actual file transfer mechanism. Thus, it is
natural that in order to meet them it is enough to define attribute natural that in order to meet them it is enough to define attribute
extensions and usage conventions to SDP, while MSRP itself needs no extensions and usage conventions to SDP, while MSRP itself needs no
extensions and can be used as it is. This is effectively the extensions and can be used as it is. This is effectively the
approach taken in this specification. Another goal has been to approach taken in this specification. Another goal has been to
specify the SDP extensions in such a way that a regular MSRP endpoint specify the SDP extensions in such a way that a regular MSRP endpoint
which does not support them could still in some cases act as an which does not support them could still in some cases act as an
endpoint in a file transfer session, albeit with a somewhat reduced endpoint in a file transfer session, albeit with a somewhat reduced
functionality. functionality.
In some ways the aim of this specification is similar to the aim of In some ways the aim of this specification is similar to the aim of
content indirection mechanism in the Session Initiation Protocol content indirection mechanism in the Session Initiation Protocol
(SIP) [14]. Both mechanisms allow a user agent to decide whether or (SIP) [13]. Both mechanisms allow a user agent to decide whether or
not to download a file based on information about the file. However, not to download a file based on information about the file. However,
there are some differences. With content indirection, it is not there are some differences. With content indirection, it is not
possible for the other endpoint to explicitly accpet or reject the possible for the other endpoint to explicitly accpet or reject the
file transfer. Also, it is not possible for an endpoint to request a file transfer. Also, it is not possible for an endpoint to request a
file from another endpoint. Furthermore, content indirection is not file from another endpoint. Furthermore, content indirection is not
tied to the context of a media session, which is sometimes a tied to the context of a media session, which is sometimes a
desirable property. Finally, content indirection typically requires desirable property. Finally, content indirection typically requires
some server infrastructure, which may not always be available. (It some server infrastructure, which may not always be available. (It
is possible to use content indirection directly between the endpoints is possible to use content indirection directly between the endpoints
too, but in that case there is no definition for how it works for too, but in that case there is no definition for how it works for
skipping to change at page 6, line 29 skipping to change at page 6, line 37
working group decided not to follow this approach because it is working group decided not to follow this approach because it is
expected that implementations support only a subset of the parameters expected that implementations support only a subset of the parameters
defined in Section 6. Those implementations will be able to use defined in Section 6. Those implementations will be able to use
regular SDP rules in order to ignore non-supported SDP parameters. regular SDP rules in order to ignore non-supported SDP parameters.
If all the information was encoded in a single SDP attribute, those If all the information was encoded in a single SDP attribute, those
rules, which relate to backwards compatibility, would need to be rules, which relate to backwards compatibility, would need to be
redefined specifically for that parameter. redefined specifically for that parameter.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as document are to be interpreted as described in BCP 14, RFC 2119 [1].
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. Definitions 3. Definitions
For the purpose of this document, the following definitions specified For the purpose of this document, the following definitions specified
in RFC 3264 [7] apply: in RFC 3264 [7] apply:
o Answer
o Answerer o Answerer
o Offer
o Offerer o Offerer
Additionally, we define the following terms: Additionally, we define the following terms:
File sender: The endpoint that is willing to send a file to the File sender: The endpoint that is willing to send a file to the
file receiver. file receiver.
File receiver: The endpoint that is willing to receive a file from File receiver: The endpoint that is willing to receive a file from
the file sender. the file sender.
File selector: A tuple of file attributes that the SDP offerer File selector: A tuple of file attributes that the SDP offerer
includes in the SDP in order to select a file at the SDP answerer. includes in the SDP in order to select a file at the SDP answerer.
This is described in more detail in Section 5. This is described in more detail in Section 5.
4. Overview of Operation 4. Overview of Operation
An SDP offerer creates an SDP body that contains the description of An SDP offerer creates an SDP body that contains the description of
one or more files that the offerer wants to send or receive. The one or more files that the offerer wants to send or receive. The
skipping to change at page 7, line 19 skipping to change at page 7, line 24
This is described in more detail in Section 5. This is described in more detail in Section 5.
4. Overview of Operation 4. Overview of Operation
An SDP offerer creates an SDP body that contains the description of An SDP offerer creates an SDP body that contains the description of
one or more files that the offerer wants to send or receive. The one or more files that the offerer wants to send or receive. The
offerer sends the SDP offer to the remote endpoint. The SDP answerer offerer sends the SDP offer to the remote endpoint. The SDP answerer
can accept or reject the transfer of each of those files. can accept or reject the transfer of each of those files.
The actual file transfer is carried out using the Message Session The actual file transfer is carried out using the Message Session
Relay Protocol (MSRP) [12]. Each SDP "m=" line describes an MSRP Relay Protocol (MSRP) [11]. Each SDP "m=" line describes an MSRP
media stream used to transfer a single file. That is, the transfer media stream used to transfer a single file. That is, the transfer
of multiple simultaneous files requires multiple "m=" lines and of multiple simultaneous files requires multiple "m=" lines and
corresponding MSRP media streams. It should be noted that multiple corresponding MSRP media streams. It should be noted that multiple
MSRP media streams can share a single transport layer connection, so MSRP media streams can share a single transport layer connection, so
this mechanism will not lead to excessive use of transport resources. this mechanism will not lead to excessive use of transport resources.
Each "m=" line for an MSRP media stream is accompanied with a few Each "m=" line for an MSRP media stream is accompanied with a few
attributes describing the file to be transferred. If the file sender attributes describing the file to be transferred. If the file sender
generates the SDP offer, the attributes describe a local file to be generates the SDP offer, the attributes describe a local file to be
sent (push), and the file receiver can use this information to either sent (push), and the file receiver can use this information to either
skipping to change at page 9, line 4 skipping to change at page 9, line 7
unique file is not always known by the offerer. Sometimes only the unique file is not always known by the offerer. Sometimes only the
name, size or type of file are known, so the file selector may result name, size or type of file are known, so the file selector may result
in selecting more than one file, which is an undesired case. The in selecting more than one file, which is an undesired case. The
opposite is also true: if the file selector contains a hash and a opposite is also true: if the file selector contains a hash and a
name selectors, there is a risk that the remote host has renamed the name selectors, there is a risk that the remote host has renamed the
file, although there is a file with the indicated hash, the file name file, although there is a file with the indicated hash, the file name
does not match, thus, the file selector will result in the selection does not match, thus, the file selector will result in the selection
of zero files. of zero files.
Since there are several hashing algorithms, such as SHA-1 [6], SHA- Since there are several hashing algorithms, such as SHA-1 [6], SHA-
256, SHA-384, SHA-512 [11], etc., a file selector MAY contain several 256, SHA-384, SHA-512 [14], etc., a file selector MAY contain several
hashes, each one describing the hash of the file with a different hashes, each one describing the hash of the file with a different
hashing algorithm. Implementations that make use of the hash SHOULD hashing algorithm. Implementations that make use of the hash SHOULD
select one among the supported ones before selecting a file. So, select one among the supported ones before selecting a file. So,
when several hashes are present in the SDP, the file selector when several hashes are present in the SDP, the file selector
consists of the union of the name, size, type, and any of the consists of the union of the name, size, type, and any of the
supported hash algorithms. supported hash algorithms.
Implementations according to this specification MUST implement the Implementations according to this specification MUST implement the
'file-selector' attribute and MAY implement any of the other 'file-selector' attribute and MAY implement any of the other
attributes specified in this specification. SDP offers and answers attributes specified in this specification. SDP offers and answers
for file transfer MUST contain a 'file-selector' media attribute that for file transfer MUST contain a 'file-selector' media attribute that
selects the file to be transferred and MAY contain any of the other selects the file to be transferred and MAY contain any of the other
attributes specified in this specification. attributes specified in this specification.
The 'file-selector' media attribute is also useful when learning the
support of the file transfer offer/answer capability that this
document specifies. This is further explained in Section 8.3.
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 / disposition-attr /
file-date-attr / icon-attr / file-date-attr / 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
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
skipping to change at page 11, line 4 skipping to change at page 11, line 4
; must be used ; must be used
; DQUOTE defined in RFC 4234 ; DQUOTE defined in RFC 4234
icon-attr = "icon:" icon-value icon-attr = "icon:" icon-value
icon-value = cid-url ;cid-url defined in RFC 2392 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
The 'file-selector' attribute is composed of one or more selectors When used for capability query (see Section 8.3), the 'file-selector'
which parametrize the file to be transferred. There are four attribute MUST NOT not contain any selector, because its presence
selectors in this attribute: 'name', 'size', 'type', and 'hash'. merely indicates compliance to this specification.
When used in an SDP offer or answer, the 'file-selector' attribute
MUST contain at least one selector. Selectors parametrize the file
to be transferred. There are four selectors in this attribute:
'name', 'size', 'type', and 'hash'.
The 'name' selector in the 'file-selector' attribute contains the The 'name' selector in the 'file-selector' attribute contains the
filename of the content enclosed in double quotes. The filename is filename of the content enclosed in double quotes. The filename is
encoded in UTF-8. Its value SHOULD be the same as the 'filename' encoded in UTF-8. Its value SHOULD be the same as the 'filename'
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. The 'name' selector MUST not
contain characters that can be interpreted as directory structure by
the local operating system. If such characters are present in the
file name, they MUST be escaped.
Note that the 'name' selector might still contain characters that,
although not meaningful for the local operating system, might
still be meaningful to the remote operating system (e.g., '\',
'/', ':'). Therefore, implementations are responsible for
sanitizing the input received from the remote endpoint before
doing a local operation, such as the creation of a local file.
Among other things, implementations can escape characters that are
meaningful to the local operating system before doing file system
local calls.
The 'size' selector in the 'file-selector' attribute indicates the The 'size' selector in the 'file-selector' attribute indicates the
size of the file in octets. The value of this attribute SHOULD be size of the file in octets. The value of this attribute SHOULD be
the same of the 'size' parameter of Content-Disposition header field the same of the 'size' parameter of Content-Disposition header field
[3] that could be signalled by the actual file transfer. Note that [3] that could be signalled by the actual file transfer. Note that
the 'size' selector merely includes the file size, and does not the 'size' selector merely includes the file size, and does not
include any potential overhead added by a wrapper, such as message/ include any potential overhead added by a wrapper, such as message/
cpim. cpim.
The 'type' selector in the 'file-selector' attribute contains the The 'type' selector in the 'file-selector' attribute contains the
skipping to change at page 13, line 33 skipping to change at page 14, line 13
extensions defined in this memo: extensions defined in this memo:
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s= s=
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:* a=accept-types:message/cpim
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=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=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
skipping to change at page 15, line 11 skipping to change at page 15, line 37
file sender. In this case the SDP offer contains a 'recvonly' file sender. In this case the SDP offer contains a 'recvonly'
attribute, and accordingly the SDP answer contains a 'sendonly' attribute, and accordingly the SDP answer contains a 'sendonly'
attribute. attribute.
8.1. Offerer's Behavior 8.1. Offerer's Behavior
An offerer that wishes to send or receive one or more files to or An offerer that wishes to send or receive one or more files to or
from an answerer MUST build an SDP [10] description of a session from an answerer MUST build an SDP [10] description of a session
containing one or more "m=" lines, each one describing an MSRP containing one or more "m=" lines, each one describing an MSRP
session (and thus, one file transfer operation), according to the session (and thus, one file transfer operation), according to the
MSRP [12] procedures. All the media line attributes specified and MSRP [11] procedures. All the media line attributes specified and
required by MSRP [12] (e.g., "a=path", "a=accept-types", etc.) MUST required by MSRP [11] (e.g., "a=path", "a=accept-types", etc.) MUST
be included as well. For each file to be transferred there MUST be a be included as well. For each file to be transferred there MUST be a
separate "m=" line. 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. Then it sends the SDP offer to the file the file to be sent. Then it sends the SDP offer to the file
receiver. The file sender MUST add a 'file-selector' attribute media receiver. The file sender MUST add a 'file-selector' attribute media
line containing at least one of the 'type', 'size', 'hash', line containing at least one of the 'type', 'size', 'hash',
parameters in indicating the type, size, or hash of the file, parameters in indicating the type, size, or hash of the file,
skipping to change at page 16, line 32 skipping to change at page 17, line 15
8.1.3. SDP Offer for Several Files 8.1.3. SDP Offer for Several Files
An offerer that wishes to send or receive more than one file An offerer that wishes to send or receive more than one file
generates an "m=" line per file. This way, the answerer can reject generates an "m=" line per file. 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 [10] procedures. lines to zero, as per regular SDP [10] procedures.
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 [12]. described in Section 8.1 of [11].
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 [10] procedures. If the answerer decides to zero, as per regular SDP [10] procedures. If the answerer decides to
accept the file, it proceeds as per regular MSRP [12] and SDP [10] accept the file, it proceeds as per regular MSRP [11] and SDP [10]
procedures. procedures.
8.2.1. The Answerer is a File Receiver 8.2.1. The Answerer is a File Receiver
In a push operation the answerer is the file receiver. When the file In a push operation the answerer is the file receiver. When the file
receiver gets the SDP answer, it extracts the attributes and receiver gets the SDP answer, it extracts the attributes and
parameters that describe the file and typically requests permission parameters that describe the file and typically requests permission
to the user to accept or reject the reception of the file. If the to the user to accept or reject the reception of the file. If the
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
skipping to change at page 18, line 13 skipping to change at page 18, line 43
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 an 'icon' and 'disposition' attributes to further describe
the file. Although the answerer MAY also include a 'name' and 'size' the file. Although the answerer MAY also include a 'name' and 'size'
parameters in the 'file-selector' attribute, and a 'file-date' parameters in the 'file-selector' attribute, and a 'file-date'
attribute, it is RECOMMENDED not to include them in the SDP answer if attribute, it is RECOMMENDED not to include them in the SDP answer if
the actual file transfer protocol (e.g., MSRP [12]) can accommodate a the actual file transfer protocol (e.g., MSRP [11]) can accommodate a
Content-Disposition header field [3] with the equivalent parameters. 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).
skipping to change at page 18, line 41 skipping to change at page 19, line 23
mechanism that allows to either select multiple files or, e.g., mechanism that allows to either select multiple files or, e.g.,
resolve ambiguities by returning a list of files that match the resolve ambiguities by returning a list of files that match the
file selector. file selector.
If the SDP offer contains a 'file-range' attribute and the file If the SDP offer contains a 'file-range' attribute and the file
sender accepts to send the range of bytes declared in there, the file sender accepts to send the range of bytes declared in there, the file
sender MUST include a 'file-range' attribute in the SDP answer with sender MUST include a 'file-range' attribute in the SDP answer with
the same range of values. If the file sender does not accept sending the same range of values. If the file sender does not accept sending
that range of bytes, it SHOULD reject the transfer of the file. that range of bytes, it SHOULD reject the transfer of the file.
8.3. Re-usage of Existing m= Lines in SDP 8.3. Indicating File Transfer Offer/Answer Capability
The SDP Offer/Answer Model [7] provides provisions for indicating a
capability to another endpoint (see Section 9 of RFC 3264 [7]). The
mechanism assumes a high-level protocol, such as SIP [12], that
provides a capability query (such as a SIP OPTIONS request). RFC
3264 [7] indicates how to build the SDP that is included in the
response to such request. As such, RFC 3264 indicates that and
endpoint builds an SDP body that contains an "m=" line that contains
the media type (message, for MSRP). An endpoint that implements the
procedures specified in this document SHOULD also add a 'file-
selector' media attribute for the "m=message" line. The 'file-
selector' media attribute MUST be empty, i.e., it MUST NOT contain
any selector.
8.4. Re-usage of Existing m= Lines in SDP
The SDP Offer/Answer Model [7] provides rules that allow SDP offerers The SDP Offer/Answer Model [7] provides rules that allow SDP offerers
and answerers to modify an existing media line, i.e., re-use an and answerers to modify an existing media line, i.e., re-use an
existing media line with different attributes. The same is also existing media line with different attributes. The same is also
possible when SDP signals a file transfer operation according to the possible when SDP signals a file transfer operation according to the
rules of this memo. Therefore, the procedures defined in RFC 3264 rules of this memo. Therefore, the procedures defined in RFC 3264
[7], in particular those defined in Section 8.3, MUST apply for file [7], in particular those defined in Section 8.3, MUST apply for file
transfer operations. transfer operations.
8.4. MSRP Usage 8.5. MSRP Usage
The file transfer service specified in this document uses "m=" lines The file transfer service specified in this document uses "m=" lines
to describe the unidirectional transfer of a file. Consequently, to describe the unidirectional transfer of a file. Consequently,
each MSRP session established following the procedures in Section 8.1 each MSRP session established following the procedures in Section 8.1
and Section 8.2 is only used to transfer a single file. So, senders and Section 8.2 is only used to transfer a single file. So, senders
MUST only use the dedicated MSRP session to send the file described MUST only use the dedicated MSRP session to send the file described
in the SDP offer or answer. That is, senders MUST NOT send in the SDP offer or answer. That is, senders MUST NOT send
additional files over the same MSRP session. additional files over the same MSRP session.
Additionally, implementations according to this specification MUST
include a single file in a single MSRP message. Notice that the MSRP
specification defines "MSRP message" as a complete unit of MIME or
text content, which can be split and delivered in more than one MSRP
request; each of these portions of the complete message is called a
"chunk". So, it is still valid to send a file in several chunks, but
from the MSRP point of view, all the chunks together form an MSRP
message: the file. When chunking, notice that MSRP does not require
to wait for a 200-class response for a chunk before sending the
following one. Therefore, it is valid to send pipelined MSRP SEND
requests containing chunks of the same MSRP message (the file).
Section 9.1 contains an example of a file transfer using pipelined
MSRP requests.
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 bytes).
Then the file sender application SHOULD wrap those bytes in an Then the file sender application SHOULD wrap those bytes in an
appropriate wrapper, such as message/cpim. Last, the file sender appropriate wrapper, such as message/cpim. Last, the file sender
application delivers the message/cpim to MSRP for transportation. application delivers the message/cpim to MSRP for transportation.
MSRP will consider the message/cpim as a whole message, and will MSRP will consider the message/cpim as a whole message, and will
start numbering bytes at number 1. start numbering bytes at 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 'not-render' defined by this memo. header can also take the value 'not-render' defined by this memo.
Once the file transfer is completed, the file sender SHOULD close the Once the file transfer is completed, the file sender SHOULD close the
MSRP session, and MUST behave according to the MSRP [12] procedures MSRP session, and MUST behave according to the MSRP [11] procedures
with respect closing MSRP sessions. with respect closing MSRP sessions.
9. Examples 9. Examples
9.1. Offerer sends a file to the Answerer 9.1. Offerer sends a file to the Answerer
This section shows an example flow for a file transfer scenario. The This section shows an example flow for a file transfer scenario. The
example assumes that SIP [13] is used to transport the SDP offer/ example assumes that SIP [12] is used to transport the SDP offer/
answer exchange, although the SIP details are briefly shown in the answer exchange, although the SIP details are briefly shown in the
sake of brevity. sake of brevity.
Alice, the SDP offerer, wishes to send an image file to Bob (the Alice, the SDP offerer, wishes to send an image file to Bob (the
answerer). Alice's User Agent Client (UAC) creates a unidirectional answerer). Alice's User Agent Client (UAC) creates a unidirectional
SDP offer that contains the description of the file that she wants to SDP offer that contains the description of the file that she wants to
send to Bob's User Agent Server (UAS). The description also includes send to Bob's User Agent Server (UAS). The description also includes
an icon representing the contents of the file to be transferred. The an icon representing the contents of the file to be transferred. The
sequence flow is shown in Figure 3. sequence flow is shown in Figure 3.
skipping to change at page 20, line 16 skipping to change at page 21, line 23
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
|----------------------->| |----------------------->|
|(2) (SIP) 200 OK | |(2) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
|(3) (SIP) ACK | |(3) (SIP) ACK |
|----------------------->| |----------------------->|
| | | |
|(4) (MSRP) SEND (chunk) | |(4) (MSRP) SEND (chunk) |
|----------------------->| |----------------------->|
|(5) (MSRP) 200 OK | |(5) (MSRP) SEND (chunk) |
|<-----------------------|
|(6) (MSRP) SEND (chunk) |
|----------------------->| |----------------------->|
|(6) (MSRP) 200 OK |
|<-----------------------|
|(7) (MSRP) 200 OK | |(7) (MSRP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
|(8) (SIP) BYE | |(8) (SIP) BYE |
|----------------------->| |----------------------->|
|(9) (SIP) 200 OK | |(9) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
| | | |
skipping to change at page 21, line 28 skipping to change at page 22, line 28
Content-Length: [length of SDP] Content-Length: [length of SDP]
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com o=alice 2890844526 2890844526 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 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: * a=accept-types:message/cpim
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=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=icon:cid:id2@alicepc.example.com
--boundary71 --boundary71
Content-Type: image/jpeg Content-Type: image/jpeg
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
skipping to change at page 22, line 19 skipping to change at page 23, line 20
decides to accept the file transfer. So Bob creates the following decides to accept the file transfer. So Bob creates the following
SDP answer: SDP answer:
v=0 v=0
o=bob 2890844656 2890844656 IN IP4 bobpc.example.com o=bob 2890844656 2890844656 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 8888 TCP/MSRP * m=message 8888 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types: * a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=path:msrp://bobpc.example.com:8888/9di4ea;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
Figure 5: SDP answer accepting the SDP offer for file transfer Figure 5: 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.
skipping to change at page 23, line 4 skipping to change at page 24, line 24
DateTime: 2006-05-15T15:02:31-03:00 DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool picture.jpg"; Content-Disposition: render; filename="My cool picture.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +03:00"; creation-date="Mon, 15 May 2006 15:01:31 +03:00";
size=4092 size=4092
Content-Type: image/jpeg Content-Type: image/jpeg
... first set of bytes of the JPEG image ... ... first set of bytes of the JPEG image ...
-------d93kswow+ -------d93kswow+
Figure 6: MSRP SEND request containing the first chunk of actual file Figure 6: MSRP SEND request containing the first chunk of actual file
F5: Bob acknowledges the reception of the first chunk.
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4385
-------d93kswow$
Figure 7: MSRP 200 OK response F5: Alice sends the second and last chunk. Note that MSRP allows to
send pipelined chunks, so there is no need to wait for the 200 (OK)
F6: Alice sends the second and last chunk. response from the previous chunk.
MSRP op2nc9a SEND MSRP op2nc9a SEND
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/iau39;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Byte-Range: 2049-4385/4385 Byte-Range: 2049-4385/4385
Content-Type: message/cpim Content-Type: message/cpim
... second set of bytes of the JPEG image ... ... second set of bytes of the JPEG image ...
-------op2nc9a$ -------op2nc9a$
Figure 8: MSRP SEND request containing the second chunk of actual Figure 7: MSRP SEND request containing the second chunk of actual
file file
F6: Bob acknowledges the reception of the first chunk.
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4385
-------d93kswow$
Figure 8: MSRP 200 OK response
F7: Bob acknowledges the reception of the second chunk. F7: Bob acknowledges the reception of the second chunk.
MSRP op2nc9a 200 OK MSRP op2nc9a 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 2049-4385/4385 Byte-Range: 2049-4385/4385
-------op2nc9a$ -------op2nc9a$
Figure 9: MSRP 200 OK response Figure 9: MSRP 200 OK response
skipping to change at page 25, line 23 skipping to change at page 27, line 23
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 2890844526 IN IP4 alicepc.example.com o=alice 2890844526 2890844526 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 7654 TCP/MSRP * m=message 7654 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types:image/jpeg a=accept-types:message/cpim
a=accept-wrapped-types:image/jpeg
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E a=file-selector:hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E
Figure 11: INVITE request containing an SDP offer for file transfer Figure 11: INVITE request containing an SDP offer for file transfer
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.
F2: Bob receives the INVITE request, inspects the SDP offer, computes F2: Bob receives the INVITE request, inspects the SDP offer, computes
the file descriptor and finds a local file whose hash equals the one the file descriptor and finds a local file whose hash equals the one
indicated in the SDP. Bob accepts the file transmission and creates indicated in the SDP. Bob accepts the file transmission and creates
an SDP answer as follows: an SDP answer as follows:
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 8888 TCP/MSRP * m=message 8888 TCP/MSRP *
a=sendonly a=sendonly
a=accept-types:* a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E a=file-selector:hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E
type:image/jpeg type:image/jpeg
Figure 12: SDP answer accepting the SDP offer for file transfer Figure 12: SDP answer accepting the SDP offer for file transfer
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
skipping to change at page 27, line 28 skipping to change at page 29, line 28
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 5670 TCP/MSRP *
i=This is my latest picture i=This is my latest picture
a=sendonly a=sendonly
a=accept-types:* a=accept-types:message/cpim
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=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=icon:cid:id3@alicepc.example.com
--boundary71 --boundary71
Content-Type: image/jpeg Content-Type: image/jpeg
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
skipping to change at page 28, line 17 skipping to change at page 30, line 18
decides to accept the file transfer. So Bob creates the following decides to accept the file transfer. So Bob creates the following
SDP answer: SDP answer:
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 9999 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types:* a=accept-types:message/cpim
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=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.
skipping to change at page 29, line 19 skipping to change at page 31, line 41
-------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.
9.3. Example of a capability indication
Alice sends an OPTIONS request to Bob (this request does not contain
SDP). Bob answers with a 200 (OK) response that contain the SDP
shown in Figure .
Alice's UAC Bob's UAS
| |
|(1) (SIP) OPTIONS |
|----------------------->|
|(2) (SIP) 200 OK |
| with SDP |
|<-----------------------|
| |
| |
Figure 19: Flow diagram of a capability request
v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=-
c=IN IP4 bobpc.example.com
t=0 0
m=message 0 TCP/MSRP *
a=file-selector
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
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 transfered was a different one. In the latter case, the to be transfered 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
skipping to change at page 30, line 10 skipping to change at page 33, line 22
This memo provides instructions to IANA to register a number of media This memo provides instructions to IANA to register a number of media
level only attributes in the Session Description Protocol Parameters level only attributes in the Session Description Protocol Parameters
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.an.garcia@nokia.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: file-sector Attribute name: file-sector
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 disposition attribute
Contact: Miguel Garcia <miguel.an.garcia@nokia.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: disposition Attribute name: 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.an.garcia@nokia.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 icon attribute
Contact: Miguel Garcia <miguel.an.garcia@nokia.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: icon Attribute name: 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
Contact: Miguel Garcia <miguel.an.garcia@nokia.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: file-range Attribute name: file-range
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: it contains the range of transferred bytes of the Description: it contains the range of transferred bytes of the
file file
Specification: RFC XXXX Specification: RFC XXXX
11.2. Registration of new Content Disposition value 11.2. Registration of new Content Disposition value
IANA acts on Mail Content Disposition Values and Parameters This document requests IANA to act on Mail Content Disposition Values
registry [19] and registers a new Mail Content Disposition Value and Parameters registry [19] and register a new Mail Content
according to the following data: Disposition Value according to the following data:
Name Description Reference Name Description Reference
----- ------------ --------- ----- ------------ ---------
not-render the body should not be rendered to the user [RFCXXXX] not-render the body should not be rendered to the user [RFCXXXX]
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
skipping to change at page 32, line 39 skipping to change at page 35, line 51
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, (S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004. July 2004.
[9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[11] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and [11] Campbell, B., "The Message Session Relay Protocol",
HMAC-SHA)", RFC 4634, August 2006. draft-ietf-simple-message-sessions-19 (work in progress),
February 2007.
[12] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-18 (work in progress),
December 2006.
13.2. Informational References 13.2. Informational References
[13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [12] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[14] Burger, E., "A Mechanism for Content Indirection in Session [13] Burger, E., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", RFC 4483, May 2006. Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[14] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and
HMAC-SHA)", RFC 4634, August 2006.
[15] Jennings, C., "Relay Extensions for the Message Sessions Relay [15] Jennings, C., "Relay Extensions for the Message Sessions Relay
Protocol (MSRP)", draft-ietf-simple-msrp-relays-08 (work in Protocol (MSRP)", draft-ietf-simple-msrp-relays-10 (work in
progress), July 2006. progress), December 2006.
[16] Paila, T., "FLUTE - File Delivery over Unidirectional [16] Paila, T., "FLUTE - File Delivery over Unidirectional
Transport", draft-ietf-rmt-flute-revised-02 (work in progress), Transport", draft-ietf-rmt-flute-revised-03 (work in progress),
August 2006. January 2007.
URIs URIs
[17] <http://www.iana.org/assignments/media-types/> [17] <http://www.iana.org/assignments/media-types/>
[18] <http://www.iana.org/assignments/hash-function-text-names> [18] <http://www.iana.org/assignments/hash-function-text-names>
[19] <http://www.iana.org/assignments/mail-cont-disp> [19] <http://www.iana.org/assignments/mail-cont-disp>
[20] <http://www.iana.org/assignments/sdp-parameters> [20] <http://www.iana.org/assignments/sdp-parameters>
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Nokia Nokia Siemens Networks
P.O.Box 407 P.O.Box 6
NOKIA GROUP, FIN 00045 Nokia Siemens Networks, FIN 02022
Finland Finland
Email: miguel.an.garcia@nokia.com Email: miguel.garcia@nsn.com
Markus Isomaki Markus Isomaki
Nokia Nokia
Keilalahdentie 2-4 Keilalahdentie 2-4
Espoo 02150 Espoo 02150
Finland Finland
Email: markus.isomaki@nokia.com Email: markus.isomaki@nokia.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Salvatore Loreto Salvatore Loreto
Ericsson Ericsson
skipping to change at page 35, line 7 skipping to change at page 38, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). 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
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 63 change blocks. 
112 lines changed or deleted 204 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/