draft-ietf-mmusic-file-transfer-mech-11.txt   rfc5547.txt 
MMUSIC Working Group M. Garcia-Martin Network Working Group M. Garcia-Martin
Internet-Draft Ericsson Request for Comments: 5547 Ericsson
Intended status: Standards Track M. Isomaki Category: Standards Track M. Isomaki
Expires: August 21, 2009 Nokia Nokia
G. Camarillo G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
February 17, 2009 A Session Description Protocol (SDP) Offer/Answer Mechanism
to Enable File Transfer
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable
File Transfer
draft-ietf-mmusic-file-transfer-mech-11.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2009. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 describe either 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions .....................................................4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Operation ...........................................5
5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7 5. File Selector ...................................................6
6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8 6. Extensions to SDP ...............................................7
7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13 7. File Disposition Types .........................................13
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14 8. Protocol Operation .............................................13
8.1. The 'file-transfer-id' attribute . . . . . . . . . . . . . 15 8.1. The 'file-transfer-id' Attribute ..........................14
8.2. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 17 8.2. Offerer's Behavior ........................................17
8.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 18 8.2.1. The Offerer Is a File Sender .......................17
8.2.2. The Offerer is a File Receiver . . . . . . . . . . . . 18 8.2.2. The Offerer Is a File Receiver .....................18
8.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 19 8.2.3. SDP Offer for Several Files ........................18
8.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 19 8.3. Answerer's Behavior .......................................19
8.3.1. The Answerer is a File Receiver . . . . . . . . . . . 20 8.3.1. The Answerer Is a File Receiver ....................19
8.3.2. The Answerer is a File Sender . . . . . . . . . . . . 21 8.3.2. The Answerer Is a File Sender ......................20
8.4. Aborting an ongoing file transfer operation . . . . . . . 22 8.4. Aborting an Ongoing File Transfer Operation ...............22
8.5. Indicating File Transfer Offer/Answer Capability . . . . . 26 8.5. Indicating File Transfer Offer/Answer Capability ..........25
8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 26 8.6. Reusage of Existing "m=" Lines in SDP .....................26
8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 26 8.7. MSRP Usage ................................................26
8.8. Considerations about the 'file-icon' attribute . . . . . . 28 8.8. Considerations about the 'file-icon' Attribute ............28
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Examples .......................................................28
9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 29 9.1. Offerer Sends a File to the Answerer ......................28
9.2. Offerer requests a file from the Answerer and second 9.2. Offerer Requests a File from the Answerer and
file transfer . . . . . . . . . . . . . . . . . . . . . . 33 Second File Transfer ......................................33
9.3. Example of a capability indication . . . . . . . . . . . . 40 9.3. Example of a Capability Indication ........................40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations .......................................41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations ...........................................42
11.1. Registration of new SDP attributes . . . . . . . . . . . . 42 11.1. Registration of New SDP Attributes .......................42
11.1.1. Registration of the file-selector attribute . . . . . 43 11.1.1. Registration of the file-selector Attribute .......43
11.1.2. Registration of the file-transfer-id attribute . . . . 43 11.1.2. Registration of the file-transfer-id Attribute ....43
11.1.3. Registration of the file-disposition attribute . . . . 43 11.1.3. Registration of the file-disposition Attribute ....43
11.1.4. Registration of the file-date attribute . . . . . . . 43 11.1.4. Registration of the file-date Attribute ...........44
11.1.5. Registration of the file-icon attribute . . . . . . . 44 11.1.5. Registration of the file-icon Attribute ...........44
11.1.6. Registration of the file-range attribute . . . . . . . 44 11.1.6. Registration of the file-range Attribute ..........45
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgments ...............................................45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 13. References ....................................................45
13.1. Normative References . . . . . . . . . . . . . . . . . . . 45 13.1. Normative References .....................................45
13.2. Informational References . . . . . . . . . . . . . . . . . 46 13.2. Informative References ...................................46
Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 46 Appendix A. Alternatives Considered ..............................48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
The Session Description Protocol (SDP) Offer/Answer [RFC3264] The Session Description Protocol (SDP) offer/answer [RFC3264]
provides a mechanism for two endpoints to arrive at a common view of provides a mechanism for two endpoints to arrive at a common view of
a multimedia session between them. These sessions often contain a multimedia session between them. These sessions often contain
real-time media streams such as voice and video, but are not limited real-time media streams such as voice and video, but are not limited
to that. Basically, any media component type can be supported, as to that. Basically, any media component type can be supported, as
long as there is a specification how to negotiate it within the SDP long as there is a specification how to negotiate it within the SDP
offer/answer exchange. offer/answer exchange.
The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for
transmitting instant messages (IM) in the context of a session. The transmitting instant messages (IMs) in the context of a session. The
protocol specification describes the usage of SDP for establishing a protocol specification describes the usage of SDP for establishing an
MSRP sessions. In addition to plain text messages, MSRP is able to MSRP session. In addition to plain text messages, MSRP is able to
carry arbitrary (binary) Multipurpose Internet Mail Extensions (MIME) carry arbitrary (binary) Multipurpose Internet Mail Extensions (MIME)
[RFC2045] compliant content, such as images or video clips. [RFC2045] compliant 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
that are useful for file transfer. Message chunking enables the that are useful for file transfer. Message chunking enables the
sharing of the same transport connection between the transfer of a sharing of the same transport connection between the transfer of a
large file and interactive IM exchange without blocking the IM. MSRP large file and interactive IM exchange without blocking the IM. MSRP
relays [RFC4976] provide a mechanism for Network Address Translator relays [RFC4976] provide a mechanism for Network Address Translator
(NAT) traversal. Finally, Secure MIME (S/MIME) [RFC3851] can be used (NAT) traversal. Finally, Secure MIME (S/MIME) [RFC3851] can be used
for ensuring the integrity and confidentiality of the transferred for ensuring the integrity and confidentiality of the transferred
content. content.
However, the baseline MSRP does not readily meet all the requirements However, the baseline MSRP does not readily meet all the requirements
skipping to change at page 4, line 41 skipping to change at page 3, line 41
for ensuring the integrity and confidentiality of the transferred for ensuring the integrity and confidentiality of the transferred
content. content.
However, the baseline MSRP does not readily meet all the requirements However, the baseline MSRP does not readily meet all the requirements
for file transfer services within multimedia sessions. There are for file transfer services within multimedia sessions. There are
four main missing features: four main missing features:
o The recipient must be able to distinguish "file transfer" from o The recipient must be able to distinguish "file transfer" from
"file attached to IM", allowing the recipient to treat the cases "file attached to IM", allowing the recipient to treat the cases
differently. differently.
o It must be possible for the sender to send the request for a file o It must be possible for the sender to send the request for a file
transfer. It must be possible for the recipient to accept or transfer. It must be possible for the recipient to accept or
decline it, using the meta information in the request. The actual decline it, using the meta information in the request. The actual
transfer must take place only after acceptance by the recipient. transfer must take place only after acceptance by the recipient.
o It must be possible for the sender to pass some meta information o It must be possible for the sender to pass some meta information
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,
well as a short (human readable) description. as 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. Section 5 introduces the concept of the file selector. of operation. Section 5 introduces the concept of the file selector.
The detailed syntax and semantics of the new SDP attributes and The detailed syntax and semantics of the new SDP attributes and
conventions on how the existing ones are used is defined in conventions on how the existing ones are used are defined in
Section 6. Section 7 discusses the file disposition types. Section 6. Section 7 discusses the file disposition types.
Section 8 describes the protocol operation involving SDP and MSRP. Section 8 describes the protocol operation involving SDP and MSRP.
Finally, some examples are given in Section 9. Finally, some examples are given in Section 9.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
skipping to change at page 5, line 27 skipping to change at page 4, line 32
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
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 [RFC3264] apply: in RFC 3264 [RFC3264] apply:
o Answer o Answer
o Answerer o Answerer
o Offer 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
file receiver. 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.
Push operation: A file transfer operation where the SDP offerer Push operation: A file transfer operation where the SDP offerer
takes the role of the file sender and the SDP answerer takes role takes the role of the file sender and the SDP answerer takes the
of the file receiver. role of the file receiver.
Pull operation: A file transfer operation where the SDP offerer Pull operation: A file transfer operation where the SDP offerer
takes the role of the file receiver and the SDP answerer takes the takes the role of the file receiver and the SDP answerer takes the
role of the file sender. role of the file sender.
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 separately. can accept or reject the transfer of each of those files separately.
skipping to change at page 6, line 36 skipping to change at page 5, line 48
which case the offer is rejected. which case the offer is rejected.
The attributes describing each file are provided in SDP by a set of The attributes describing each file are provided in SDP by a set of
new SDP attributes, most of which have been directly borrowed from new SDP attributes, most of which have been directly borrowed from
MIME. This way, user agents can decide whether or not to accept a MIME. This way, user agents can decide whether or not to accept a
given file transfer based on the file's name, size, description, given file transfer based on the file's name, size, description,
hash, icon (e.g., if the file is a picture), etc. hash, icon (e.g., if the file is a picture), etc.
SDP direction attributes (e.g., 'sendonly', 'recvonly') are used to SDP direction attributes (e.g., 'sendonly', 'recvonly') are used to
indicate the direction of the transfer, i.e., whether the SDP offerer indicate the direction of the transfer, i.e., whether the SDP offerer
is willing to send of receive the file. Assuming that the answerer is willing to send or receive the file. Assuming that the answerer
accepts the file transfer, the actual transfer of the files takes accepts the file transfer, the actual transfer of the files takes
place with ordinary MSRP. Note that the 'sendonly' and 'recvonly' place with ordinary MSRP. Note that the 'sendonly' and 'recvonly'
attributes refer to the direction of MSRP SEND requests and do not attributes refer to the direction of MSRP SEND requests and do not
preclude other protocol elements (such as 200 responses, REPORT preclude other protocol elements (such as 200 responses, REPORT
requests, etc.). requests, etc.).
In principle the file transfer can work even with an endpoint In principle the file transfer can work even with an endpoint
supporting only regular MSRP without understanding the extensions supporting only regular MSRP without understanding the extensions
defined herein, in a particular case where that endpoint is both defined herein, in a particular case where that endpoint is both
the SDP answerer and the file receiver. The regular MSRP endpoint the SDP answerer and the file receiver. The regular MSRP endpoint
answers the offer as it would answer any ordinary MSRP offer answers the offer as it would answer any ordinary MSRP offer
without paying attention to the extension attributes. In such a without paying attention to the extension attributes. In such a
scenario the user experience would, however, be reduced, since the scenario, the user experience would, however, be reduced, since
recipient would not know (by any protocol means) the reason for the recipient would not know (by any protocol means) the reason
the session and would not be able to accept/reject it based on the for the session and would not be able to accept/reject it based on
file attributes. the file attributes.
5. File selector 5. File Selector
When the file receiver generates the SDP offer, this SDP offer needs When the file receiver generates the SDP offer, this SDP offer needs
to unambiguously identify the requested file at the file sender. For to unambiguously identify the requested file at the file sender. For
this purpose we introduce the notion of a file selector, which is a this purpose, we introduce the notion of a file selector, which is a
tuple composed of one or more of the following individual selectors: tuple composed of one or more of the following individual selectors:
the name, size, type, and hash of the file. The file selector can the name, size, type, and hash of the file. The file selector can
include any number of selectors, so all four of them do not always include any number of selectors, so all four of them do not always
need to be present. need to be present.
The purpose of the file selector is to provide enough information The purpose of the file selector is to provide enough information
about the file to the remote entity, so that both the local and the about the file to the remote entity, so that both the local and the
remote entity can refer to the same file. The file selector is remote entity can refer to the same file. The file selector is
encoded in a 'file-selector' media attribute in SDP. The formal encoded in a 'file-selector' media attribute in SDP. The formal
syntax of the 'file-selector' media attribute is described in syntax of the 'file-selector' media attribute is described in
Figure 1. Figure 1.
The file selection process is applied to all the available files at The file selection process is applied to all the available files at
the host. The process selects those file that match each of the the host. The process selects those files that match each of the
selectors present in the 'file-selector' attribute. The result can selectors present in the 'file-selector' attribute. The result can
be zero, one, or more files, depending on the presence of the be zero, one, or more files, depending on the presence of the
mentioned selectors in the SDP and depending on the available files mentioned selectors in the SDP and depending on the available files
in a host. The file transfer mechanism specified in this document in a host. The file transfer mechanism specified in this document
requires that a file selector eventually results at most in a single requires that a file selector eventually results at most in a single
file to be chosen. Typically, if the hash selector is known, it is file to be chosen. Typically, if the hash selector is known, it is
enough to produce a file selector that points to exactly zero or one enough to produce a file selector that points to exactly zero or one
file. However, a file selector that selects a unique file is not file. However, a file selector that selects a unique file is not
always known by the offerer. Sometimes only the name, size or type always known by the offerer. Sometimes only the name, size, or type
of file are known, so the file selector may result in selecting more of file is known, so the file selector may result in selecting more
than one file, which is an undesired case. The opposite is also than one file, which is an undesired case. The opposite is also
true: if the file selector contains a hash selector and a name true: if the file selector contains a hash selector and a name
selector, there is a risk that the remote host has renamed the file, selector, there is a risk that the remote host has renamed the file,
in which case, although a file whose computed hash equals the hash in which case, although a file whose computed hash equals the hash
selector exists, the file name does not match that of the name selector exists, the file name does not match that of the name
selector, thus, the file selection process will result in the selector. Thus, in this case, the file selection process will result
selection of zero files. in the selection of zero files.
This specification uses the Secure Hash Algorithm 1, SHA-1 [RFC3174]. This specification uses the Secure Hash Algorithm 1, SHA-1 [RFC3174].
If future needs require adding support for different hashing If future needs require adding support for different hashing
algorithms, they will be specified as extensions to this document. algorithms, they will be specified as extensions to this document.
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 The 'file-selector' media attribute is also useful when learning the
support of the file transfer offer/answer capability that this support of the file transfer offer/answer capability that this
document specifies. This is further explained in Section 8.5. document specifies. This is further explained in Section 8.5.
6. Extensions to SDP 6. Extensions to SDP
We define a number of new SDP [RFC4566] attributes that provide the We define a number of new SDP [RFC4566] attributes that provide the
required information to describe the transfer of a file with MSRP. required information to describe the transfer of a file with MSRP.
These are all media level only attributes in SDP. The following is These are all media-level-only attributes in SDP. The following is
the formal ABNF syntax [RFC5234] of these new attributes. It is the formal ABNF syntax [RFC5234] of these new attributes. It is
built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183 built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183
[RFC2183], RFC 2392 [RFC2392], and RFC 5322 [RFC5322]. [RFC2183], RFC 2392 [RFC2392], and RFC 5322 [RFC5322].
attribute /= file-selector-attr / file-disp-attr / attribute =/ file-selector-attr / file-disp-attr /
file-tr-id-attr / file-date-attr / file-tr-id-attr / file-date-attr /
file-icon-attr / file-range-attr file-icon-attr / file-range-attr
;attribute is defined in RFC 4566 ;attribute is defined in RFC 4566
file-selector-attr = "file-selector" [":" selector *(SP selector)] file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector = filename-selector / filesize-selector / selector = filename-selector / filesize-selector /
filetype-selector / hash-selector filetype-selector / hash-selector
filename-selector = "name:" DQUOTE filename-string DQUOTE filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE defined in RFC 5234 ; DQUOTE defined in RFC 5234
skipping to change at page 10, line 35 skipping to change at page 9, line 48
field [RFC2183] that would be signaled by the actual file transfer. field [RFC2183] that would be signaled by the actual file transfer.
Note that the 'size' selector merely includes the file size, and does Note that the 'size' selector merely includes the file size, and does
not include any potential overhead added by a wrapper, such as not include any potential overhead added by a wrapper, such as
message/cpim [RFC3862]. message/cpim [RFC3862].
The 'type' selector in the 'file-selector' attribute contains the The 'type' selector in the 'file-selector' attribute contains the
MIME media and submedia types of the content. In general, anything MIME media and submedia types of the content. In general, anything
that can be expressed in a Content-Type header field (see RFC 2045 that can be expressed in a Content-Type header field (see RFC 2045
[RFC2045]) can also be expressed with the 'type' selectors. Possible [RFC2045]) can also be expressed with the 'type' selectors. Possible
MIME Media Type values are the ones listed in the IANA registry for MIME Media Type values are the ones listed in the IANA registry for
MIME Media Types [1]. Zero or more parameters can follow. When MIME Media Types [IANA]. Zero or more parameters can follow. When
translating parameters from a Content-Type header and a 'type' translating parameters from a Content-Type header and a 'type'
selector, the parameter has to be re-encoded prior to its selector, the parameter has to be re-encoded prior to its
accommodation as a parameter of the 'type' selector (see the ABNF accommodation as a parameter of the 'type' selector (see the ABNF
syntax of 'ft-parameter'). syntax of 'ft-parameter').
The 'hash' selector in the 'file-selector' attribute provides a hash The 'hash' selector in the 'file-selector' attribute provides a hash
computation of the file to be transferred. This is commonly used by computation of the file to be transferred. This is commonly used by
file transfer protocols. For example, FLUTE file transfer protocols. For example, FLUTE [FLUTE-REV] uses hashes
[I-D.ietf-rmt-flute-revised] uses hashes (called message digests) to (called message digests) to verify the contents of the transfer. The
verify the contents of the transfer. The purpose of the 'hash' purpose of the 'hash' selector is two-fold: On one side, in pull
selector is two-fold: On one side, in pull operations, it allows the operations, it allows the file receiver to identify a remote file by
file receiver to identify a remote file by its hash rather than by its hash rather than by its file name, providing that the file
its file name, providing that the file receiver has learned the hash receiver has learned the hash of the remote file by some out-of-band
of the remote file by some out-of-band mechanism. On the other side, mechanism. On the other side, in either push or pull operations, it
in either push or pull operations, it allows the file receiver to allows the file receiver to verify the contents of the received file,
verify the contents of the received file, or even avoid unnecessary or even avoid unnecessary transmission of an existing file.
transmission of an existing file.
The address space of the SHA-1 algorithm is big enough to avoid The address space of the SHA-1 algorithm is big enough to avoid
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 [IANA]. Implementations according to
specification MUST add a 160-bit string resulting from the this specification MUST add a 160-bit string resulting from the
computation of US Secure Hash Algorithm 1 (SHA1) [RFC3174] if the computation of US Secure Hash Algorithm 1 (SHA1) [RFC3174] if the
'hash' selector is present. If need arises, extensions can be 'hash' selector is present. If need arises, extensions can be
drafted to support several hashing algorithms. Therefore, drafted to support several hashing algorithms. Therefore,
implementations according to this specification MUST be prepared to implementations according to this specification MUST be prepared to
receive SDP containing more than a single 'hash' selector in the receive SDP containing more than a single 'hash' selector in the
'file-selector' attribute. 'file-selector' attribute.
The value of the 'hash' selector is the byte string resulting of The value of the 'hash' selector is the byte string resulting from
applying the hash algorithm to the content of the whole file, even applying the hash algorithm to the content of the whole file, even
when the file transfer is limited to a number of octets (i.e., the when the file transfer is limited to a number of octets (i.e., the
'file-range' attribute is indicated). 'file-range' attribute is indicated).
The 'file-transfer-id' attribute provides a randomly chosen globally The 'file-transfer-id' attribute provides a randomly chosen globally
unique identification to the actual file transfer. It is used to unique identification to the actual file transfer. It is used to
distinguish a new file transfer request from a repetition of the SDP distinguish a new file transfer request from a repetition of the SDP
(or the fraction of the SDP that deals with the file description). (or the fraction of the SDP that deals with the file description).
This attribute is described in much greater detail in Section 8.1. This attribute is described in much greater detail in Section 8.1.
The 'file-disposition' attribute provides a suggestion to the other The 'file-disposition' attribute provides a suggestion to the other
endpoint about the intended disposition of the file. Section 7 endpoint about the intended disposition of the file. Section 7
provides further discussion of the possible values. The value of provides further discussion of the possible values. The value of
this attribute SHOULD be the same as the disposition type parameter this attribute SHOULD be the same as the disposition type parameter
of the Content-Disposition header field [RFC2183] that would be of the Content-Disposition header field [RFC2183] that would be
signaled by the actual file transfer protocol. signaled by the actual file transfer protocol.
The 'file-date' attribute indicates the dates at which the file was The 'file-date' attribute indicates the dates on which the file was
created, modified, or last read. This attribute MAY contain a created, modified, or last read. This attribute MAY contain a
combination of the 'creation', 'modification', and 'read' parameters, combination of the 'creation', 'modification', and 'read' parameters,
but MUST NOT contain more than one of each type . but MUST NOT contain more than one of each type .
The 'creation' parameter indicates the date at which the file was The 'creation' parameter indicates the date on which the file was
created. The value MUST be a quoted string which contains a created. The value MUST be a quoted string that contains a
representation of the creation date of the file in RFC 5322 [RFC5322] representation of the creation date of the file in RFC 5322 [RFC5322]
'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used.
The value of this parameter SHOULD be the same as the 'creation-date' The value of this parameter SHOULD be the same as the 'creation-date'
parameter of the Content-Disposition header field [RFC2183] that parameter of the Content-Disposition header field [RFC2183] that
would be signaled by the actual file transfer protocol. would be signaled by the actual file transfer protocol.
The 'modification' parameter indicates the date at which the file was The 'modification' parameter indicates the date on which the file was
last modified. The value MUST be a quoted string which contains a last modified. The value MUST be a quoted string that contains a
representation of the last modification date to the file in RFC 5322 representation of the last modification date to the file in RFC 5322
[RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM)
MUST be used. The value of this parameter SHOULD be the same as the MUST be used. The value of this parameter SHOULD be the same as the
'modification-date' parameter of the Content-Disposition header field 'modification-date' parameter of the Content-Disposition header field
[RFC2183] that would be signaled by the actual file transfer [RFC2183] that would be signaled by the actual file transfer
protocol. protocol.
The 'read' parameter indicates the date at which the file was last The 'read' parameter indicates the date on which the file was last
read. The value MUST be a quoted string which contains a read. The value MUST be a quoted string that contains a
representation of the last date the file was read in RFC 5322 representation of the last date the file was read in RFC 5322
[RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM)
MUST be used. The value of this parameter SHOULD be the same as the MUST be used. The value of this parameter SHOULD be the same as the
'read-date' parameter of the Content-Disposition header field 'read-date' parameter of the Content-Disposition header field
[RFC2183] that would be signaled by the actual file transfer [RFC2183] that would be signaled by the actual file transfer
protocol. protocol.
The 'file-icon' attribute can be useful with certain file types such The 'file-icon' attribute can be useful with certain file types such
as images. It allows the file sender to include a pointer to a body as images. It allows the file sender to include a pointer to a body
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.8 contains further considerations about the 'file-icon' Section 8.8 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 enables use cases where a
file transfer can be interrupted, resumed, even perhaps changing one file transfer can be interrupted and resumed, even perhaps changing
of the endpoints. The 'file-range' attribute contains the "start one of the endpoints. The 'file-range' attribute contains the "start
offset" and "stop offset" of the file, separated by a dash "-". The offset" and "stop offset" of the file, separated by a dash "-". The
"start offset" value refers to the octet position of the file where "start offset" value refers to the octet position of the file where
the file transfer should start. The first octet of a file is denoted the file transfer should start. The first octet of a file is denoted
by the ordinal number "1". The "stop offset" value refers to the by the ordinal number "1". The "stop offset" value refers to the
octet position of the file where the file transfer should stop, octet position of the file where the file transfer should stop,
inclusive of this octet. The "stop offset" value MAY contain a "*" inclusive of this octet. The "stop offset" value MAY contain a "*"
if the total size of the file is not known in advance. The absence if the total size of the file is not known in advance. The absence
of this attribute indicates a complete file, i.e., as if the 'file- of this attribute indicates a complete file, i.e., as if the 'file-
range' attribute would have been present with a value "1-*". The range' attribute would have been present with a value "1-*". The
'file-range' attribute must not be confused with the Byte-Range 'file-range' attribute must not be confused with the Byte-Range
header in MSRP. The former indicates the portion of a file that the header in MSRP. The former indicates the portion of a file that the
application would read and pass onto the MSRP stack for 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 octet number 1, independently of position of that octet in message at octet number 1, independently of the position of that
the file. octet in 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:
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 *
skipping to change at page 13, line 34 skipping to change at page 13, line 4
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: size:32349 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd a=file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=file-disposition:attachment a=file-disposition:attachment
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300" a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com a=file-icon:cid:id2@alicepc.example.com
a=file-range:1-32349 a=file-range:1-32349
Figure 2: Example of SDP describing a file transfer Figure 2: Example of SDP describing a file transfer
NOTE: The 'file-selector' attribute in the above figure is split 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.
7. File Disposition Types 7. File Disposition Types
The SDP Offer/Answer for file transfer allows the file sender to The SDP offer/answer for file transfer allows the file sender to
indicate a preferred disposition of the file to be transferred in a indicate a preferred disposition of the file to be transferred in a
new 'file-disposition' attribute. In principle, any value listed in new 'file-disposition' attribute. In principle, any value listed in
the IANA registry for Mail Content Disposition Values [3] is the IANA registry for Mail Content Disposition Values [IANA] is
acceptable, however, most of them may not be applicable. acceptable; however, most of them may not be applicable.
There are two content dispositions of interest for file transfer There are two content dispositions of interest for file transfer
operations. On one hand, the file sender may just want the file to operations. On one hand, the file sender may just want the file to
be rendered immediately in the file receiver's device. On the other be rendered immediately in the file receiver's device. On the other
hand, the file sender may just want to indicate to the file receiver hand, the file sender may just want to indicate to the file receiver
that the file should not be rendered at the reception of the file. that the file should not be rendered at the reception of the file.
The recipient's user agent may want to interact with the user The recipient's user agent may want to interact with the user
regarding the file disposition or it may save the file until the user regarding the file disposition or it may save the file until the user
takes an action. In any case, the exact actions are implementation takes an action. In any case, the exact actions are implementation
dependent. dependent.
To indicate that a file should be automatically rendered, this memo To indicate that a file should be automatically rendered, this memo
uses the existing 'render' value of the Content Disposition type in uses the existing 'render' value of the Content Disposition type in
the new 'file-disposition' attribute in SDP. To indicate that a file the new 'file-disposition' attribute in SDP. To indicate that a file
should not be automatically rendered, this memo users the existing should not be automatically rendered, this memo uses the existing
'attachment' value of the Content-Disposition type in the new 'file- 'attachment' value of the Content-Disposition type in the new 'file-
disposition' attribute in SDP. The default value is 'render', i.e., disposition' attribute in SDP. The default value is 'render', i.e.,
the absence of a 'file-disposition' attribute in the SDP has the same the absence of a 'file-disposition' attribute in the SDP has the same
semantics as 'render'. semantics as 'render'.
The disposition value 'attachment' is specified in RFC 2183 The disposition value 'attachment' is specified in RFC 2183
[RFC2183] with the following definition: [RFC2183] with the following definition:
"Body parts can be designated 'attachment' to indicate that "Body parts can be designated 'attachment' to indicate that
they are separate from the main body of the mail message, and they are separate from the main body of the mail message, and
skipping to change at page 14, line 44 skipping to change at page 14, line 13
this section also discusses the behavior of the endpoints using MSRP. this section also discusses the behavior of the endpoints using MSRP.
A file transfer session is initiated by the offerer sending an SDP A file transfer session is initiated by the offerer sending an SDP
offer to the answerer. The answerer either accepts or rejects the offer to the answerer. The answerer either accepts or rejects the
file transfer session and sends an SDP answer to the offerer. file transfer session and sends an SDP answer to the offerer.
We can differentiate two use cases, depending on whether the offerer We can differentiate two use cases, depending on whether the offerer
is the file sender or file receiver: is the file sender or file receiver:
1. The offerer is the file sender, i.e., the offerer wants to 1. The offerer is the file sender, i.e., the offerer wants to
transmit a file to the answerer. Consequently the answerer is transmit a file to the answerer. Consequently, the answerer is
the file receiver. In this case the SDP offer contains a the file receiver. In this case, the SDP offer contains a
'sendonly' attribute, and accordingly the SDP answer contains a 'sendonly' attribute, and accordingly the SDP answer contains a
'recvonly' attribute. 'recvonly' attribute.
2. The offerer is the file receiver, i.e., the offerer wants to 2. The offerer is the file receiver, i.e., the offerer wants to
fetch a file from the answerer. Consequently the answerer is the fetch a file from the answerer. Consequently, the answerer is
file sender. In this case the SDP offer contains a session or the file sender. In this case, the SDP offer contains a session
media 'recvonly' attribute, and accordingly the SDP answer or media 'recvonly' attribute, and accordingly the SDP answer
contains a session or media 'sendonly' attribute. contains a session or media 'sendonly' attribute.
8.1. The 'file-transfer-id' attribute 8.1. The 'file-transfer-id' Attribute
This specification creates an extension to the SDP Offer/Answer Model This specification creates an extension to the SDP offer/answer model
[RFC3264], and because of that, it is assumed that the existing SDP [RFC3264], and because of that, it is assumed that the existing SDP
behavior is kept intact. The SDP behavior requires, for example, behavior is kept intact. The SDP behavior requires, for example,
that SDP is sent again to the remote party in situations where the that SDP is sent again to the remote party in situations where the
media description or perhaps other SDP parameters have not changed media description or perhaps other SDP parameters have not changed
with respect a previous offer/answer exchange. Let's consider the with respect to a previous offer/answer exchange. Let's consider the
SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITE requests SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITE requests
to refresh sessions. RFC 4028 recommends to send unmodified SDP in a to refresh sessions. RFC 4028 recommends to send unmodified SDP in a
re-INVITE to refresh the session. Should this re-INVITE contain SDP re-INVITE to refresh the session. Should this re-INVITE contain SDP
describing a file transfer operation and occur while the file describing a file transfer operation and occur while the file
transfer was still going on, there would be no means to detect transfer was still going on, there would be no means to detect
whether the SDP creator wanted to abort the current file transfer whether the SDP creator wanted to abort the current file transfer
operation and initiate a new one or the SDP file description was operation and initiate a new one or the SDP file description was
included in the SDP due to other reasons (e.g., session timer included in the SDP due to other reasons (e.g., session timer
refresh). refresh).
A similar scenario occurs when two endpoints have successfully agreed A similar scenario occurs when two endpoints have successfully agreed
on a file transfer, which is currently taking place when one of the on a file transfer, which is currently taking place when one of the
endpoints wants to add additional media streams to the existing endpoints wants to add additional media streams to the existing
session. In this case, the endpoint sends a re-INVITE request that session. In this case, the endpoint sends a re-INVITE request that
contains SDP. The SDP needs to maintain the media descriptions for contains the SDP. The SDP needs to maintain the media descriptions
the current ongoing file transfer and add the new media descriptions. for the current ongoing file transfer and add the new media
The problem is that, the other endpoint is not able to determine if a descriptions. The problem is that the other endpoint is not able to
new file transfer is requested or not. determine whether or not a new file transfer is requested.
In other cases, a file transfer was successfully completed. Then, if In other cases, a file transfer was successfully completed. Then, if
an endpoint re-sends the SDP offer with the media stream for the file an endpoint resends the SDP offer with the media stream for the file
transfer, then the other endpoint wouldn't be able to determine transfer, then the other endpoint wouldn't be able to determine
whether a new file transfer should start or not. whether or not a new file transfer should start.
To address these scenarios this specification defines the 'file- To address these scenarios, this specification defines the 'file-
transfer-id' attribute which contains a globally unique random transfer-id' attribute, which contains a globally unique random
identifier allocated to the file transfer operation. The file identifier allocated to the file transfer operation. The file
transfer identifier helps both endpoints to determine whether the SDP transfer identifier helps both endpoints to determine whether the SDP
offer is requesting a new file transfer or it is a repetition of the offer is requesting a new file transfer or it is a repetition of the
SDP. A new file transfer is one that, in case of acceptance, will SDP. A new file transfer is one that, in case of acceptance, will
provoke the actual transfer of a file. This is typically the case of provoke the actual transfer of a file. This is typically the case of
new offer/answer exchanges, or in cases where an endpoint wants to new offer/answer exchanges, or in cases where an endpoint wants to
abort the existing file transfer and re-start the file transfer once abort the existing file transfer and restart the file transfer once
more. On the other hand, the repetition of the SDP does not lead to more. On the other hand, the repetition of the SDP does not lead to
any actual file to be transferred, potentially because the file any actual file to be transferred, potentially because the file
transfer is still going on or because it has already finished. This transfer is still going on or because it has already finished. This
is the case of repeated offer/answer exchanges, which can be due to a is the case of repeated offer/answer exchanges, which can be due to a
number of reasons (session timer, addition/removal of other media number of reasons (session timer, addition/removal of other media
types in the SDP, update in SDP due to changes in other session types in the SDP, update in SDP due to changes in other session
parameters, etc.). parameters, etc.).
Implementations according to this specification MUST include a 'file- Implementations according to this specification MUST include a 'file-
transfer-id' attribute in SDP offers and answers. The SDP offerer transfer-id' attribute in SDP offers and answers. The SDP offerer
skipping to change at page 16, line 24 skipping to change at page 15, line 43
The file transfer identifier MUST be unique within the current The file transfer identifier MUST be unique within the current
session (never used before in this session), and it is RECOMMENDED to session (never used before in this session), and it is RECOMMENDED to
be unique across different sessions. It is RECOMMENDED to select a be unique across different sessions. It is RECOMMENDED to select a
relatively big random identifier (e.g., 32 characters) to avoid relatively big random identifier (e.g., 32 characters) to avoid
duplications. The SDP answerer MUST keep track of the proposed file duplications. The SDP answerer MUST keep track of the proposed file
transfer identifiers in each session and copy the value of the transfer identifiers in each session and copy the value of the
received file transfer identifier in the SDP answer. received file transfer identifier in the SDP answer.
If a file transfer is suspended and resumed at a later time, the If a file transfer is suspended and resumed at a later time, the
resumption is considered a new file transfer (even when the file to resumption is considered a new file transfer (even when the file to
be transferred is the same), therefore, the SDP offerer MUST choose a be transferred is the same); therefore, the SDP offerer MUST choose a
new file transfer identifier. new file transfer identifier.
If an endpoint sets the port number to zero in the media description If an endpoint sets the port number to zero in the media description
of a file transfer, for example because it wants to reject the file of a file transfer, for example, because it wants to reject the file
transfer operation, then the SDP answer MUST mirror the value of the transfer operation, then the SDP answer MUST mirror the value of the
'file-transfer-id' attribute included in the SDP offer. This 'file-transfer-id' attribute included in the SDP offer. This
effectively means that setting a media stream to zero has higher effectively means that setting a media stream to zero has higher
precedence than any value that the 'file-transfer-id' attribute can precedence than any value that the 'file-transfer-id' attribute can
take. take.
As a side effect, the 'file-transfer-id' attribute can be used for As a side effect, the 'file-transfer-id' attribute can be used for
aborting and restarting again an ongoing file transfer. Assume that aborting and restarting again an ongoing file transfer. Assume that
two endpoints agree on a file transfer and the actual transfer of the two endpoints agree on a file transfer and the actual transfer of the
file is taking place. At some point in time in the middle of the file is taking place. At some point in time in the middle of the
file transfer, one endpoint sends a new SDP offer, equal to the file transfer, one endpoint sends a new SDP offer, equal to the
initial one except for the value of the 'file-transfer-id' attribute, initial one except for the value of the 'file-transfer-id' attribute,
which is a new globally unique random value. This indicates that the which is a new globally unique random value. This indicates that the
offerer wants to abort the existing transfer and start a new one, offerer wants to abort the existing transfer and start a new one,
according to the SDP parameters. The SDP answerer SHOULD abort the according to the SDP parameters. The SDP answerer SHOULD abort the
ongoing file transfer, according to the procedures of the file ongoing file transfer, according to the procedures of the file
transfer protocol (e.g., MSRP), and start sending file once more from transfer protocol (e.g., MSRP), and start sending file once more from
the initial requested octet. Section 8.4 further discusses file the initial requested octet. Section 8.4 further discusses aborting
transfer abortion. a file transfer.
If an endpoint creates an SDP offer where the 'file-transfer-id' If an endpoint creates an SDP offer where the 'file-transfer-id'
attribute value does not change with respect a previously sent one, attribute value does not change with respect to a previously sent
but the file selector changes so that a new file is selected, then one, but the file selector changes so that a new file is selected,
this is considered and error, and the SDP answerer MUST abort the then this is considered an error, and the SDP answerer MUST abort the
file transfer operation (e.g., by setting the port number to zero in file transfer operation (e.g., by setting the port number to zero in
the SDP answer). Note that endpoints MAY change the 'file-selector' the SDP answer). Note that endpoints MAY change the 'file-selector'
attribute as long as the selected file does not change (e.g., by attribute as long as the selected file does not change (e.g., by
adding a hash selector), however it is RECOMMENDED that endpoints do adding a hash selector); however, it is RECOMMENDED that endpoints do
not change the value of the 'file-selector' attribute if it is not change the value of the 'file-selector' attribute if it is
requested to transfer the same file described in a previous SDP requested to transfer the same file described in a previous SDP
offer/answer exchange. offer/answer exchange.
Figure 3 summarizes the relation of the 'file-transfer-id' attribute Figure 3 summarizes the relation of the 'file-transfer-id' attribute
with the file selector in subsequent SDP exchanges. with the file selector in subsequent SDP exchanges.
\ | | | \ | | |
\ file selector | different | same | \ file selector | different | same |
'file-transfer-id' \ | file | file | 'file-transfer-id' \ | file | file |
skipping to change at page 17, line 49 skipping to change at page 17, line 18
8.2. Offerer's Behavior 8.2. Offerer's Behavior
An offerer who wishes to send or receive one or more files to or from An offerer who wishes to send or receive one or more files to or from
an answerer MUST build an SDP [RFC4566] description of a session an answerer MUST build an SDP [RFC4566] description of a session
containing one "m=" line per file. When MSRP is used as the transfer containing one "m=" line per file. When MSRP is used as the transfer
mechanism, each "m=" line also describes a single MSRP session, mechanism, each "m=" line also describes a single MSRP session,
according to the MSRP [RFC4975] procedures. Any "m=" lines that may according to the MSRP [RFC4975] procedures. Any "m=" lines that may
have already been present in a previous SDP exchange are normally have already been present in a previous SDP exchange are normally
kept unmodified; the new "m=" lines are added afterwards (Section 8.6 kept unmodified; the new "m=" lines are added afterwards (Section 8.6
describes cases when "m=" lines are re-used). All the media line describes cases when "m=" lines are reused). All the media line
attributes specified and required by MSRP [RFC4975] (e.g., "a=path", attributes specified and required by MSRP [RFC4975] (e.g., "a=path",
"a=accept-types", etc.) MUST be included as well. "a=accept-types", etc.) MUST be included as well.
8.2.1. The Offerer is a File Sender 8.2.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 an 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, or 'hash' selectors in indicating the type, size, or hash of the
respectively. If the file sender wishes to start a new file file, respectively. If the file sender wishes to start a new file
transfer, the file sender MUST add a 'file-transfer-id' attribute transfer, the file sender MUST add a 'file-transfer-id' attribute
containing a new globally unique random identifier value. containing a new globally unique random identifier value.
Additionally, the file sender MUST add a session or media 'sendonly' Additionally, the file sender MUST add a session or media 'sendonly'
attribute to the SDP offer. Then the file sender sends the SDP offer attribute to the SDP offer. Then the file sender sends the SDP offer
to the file receiver. 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 for 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'
attribute, and a 'file-icon', 'file-disposition', and 'file-date' attribute, and 'file-icon', 'file-disposition', and 'file-date'
attributes further describing the file to be transferred. The 'file- attributes further describing the file to be transferred. The 'file-
disposition' attribute provides a presentation suggestion, (for disposition' attribute provides a presentation suggestion (for
example: the file sender would like the file receiver to render the example: the file sender would like the file receiver to render the
file or not). The three date attributes provide the answerer with an file or not). The three date attributes provide the answerer with an
indication of the age of the file. The file sender MAY also add a indication of the age of the file. The file sender MAY also add a
'file-range' attribute indicating the start and stop offsets of the 'file-range' attribute indicating the start and stop offsets of the
file. file.
When the file sender receives the SDP answer, if the port number of When the file sender receives the SDP answer, if the port number of
the answer for a file request is non-zero, the file sender starts the the answer for a file request is non-zero, the file sender starts the
transfer of the file according to the negotiated parameters in SDP. transfer of the file according to the negotiated parameters in SDP.
8.2.2. The Offerer is a File Receiver 8.2.2. The Offerer Is a File Receiver
In a pull operation, the file receiver creates the SDP offer and In a pull operation, the file receiver creates the SDP offer and
sends it to the file sender. The file receiver MUST include a 'file- sends it to the file sender. The file receiver MUST include a 'file-
selector' attribute and MUST include, at least, one of the selectors selector' attribute and MUST include, at least, one of the selectors
defined for such attribute (i.e., 'name', 'type', 'size', or 'hash'). defined for such attribute (i.e., 'name', 'type', 'size', or 'hash').
In many cases, if the hash of the file is known, that is enough to In many cases, if the hash of the file is known, that is enough to
identify the file, therefore, the offerer can include only a 'hash' identify the file; therefore, the offerer can include only a 'hash'
selector. However, specially in cases where the hash of the file is selector. However, particularly in cases where the hash of the file
unknown, the file name, size, and type can provide a description of is unknown, the file name, size, and type can provide a description
the file to be fetched. If the file receiver wishes to start a new of the file to be fetched. If the file receiver wishes to start a
file transfer it MUST add a 'file-transfer-id' attribute containing a new file transfer, it MUST add a 'file-transfer-id' attribute
new globally unique random value. The file receiver MAY also add a containing a new globally unique random value. The file receiver MAY
'file-range' attribute indicating the start and stop offsets of the also add a 'file-range' attribute indicating the start and stop
file. There is no need to for the file receiver to include further offsets of the file. There is no need for the file receiver to
file attributes in the SDP offer, thus it is RECOMMENDED that SDP include further file attributes in the SDP offer; thus, it is
offerers do not include any other file attribute defined by this RECOMMENDED that SDP offerers do not include any other file attribute
specification (other than the mandatory ones). Additionally, the defined by this specification (other than the mandatory ones).
file receiver MUST add a session or media 'recvonly' attribute in the Additionally, the file receiver MUST add a session or media
SDP offer. Then file receiver sends the SDP offer to the file 'recvonly' attribute in the SDP offer. Then, the file receiver sends
sender. the SDP offer to the file sender.
When the file receiver receives the SDP answer, if the port number of When the file receiver receives the SDP answer, if the port number of
the answer for a file request is non-zero, then the file receiver the answer for a file request is non-zero, then the file receiver
should receive the file using the protocol indicated in the "m=" should receive the file using the protocol indicated in the "m="
line. If the SDP answer contains a supported hashing algorithm in line. If the SDP answer contains a supported hashing algorithm in
the 'hash' selectors of the 'file-selector' attribute, then the file the 'hash' selectors of the 'file-selector' attribute, then the file
receiver SHOULD compute the hash of the file after its reception and receiver SHOULD compute the hash of the file after its reception and
check it against the hash received in the answer. In case the check it against the hash received in the answer. In case the
computed hash does not match the one contained in the SDP answer, the computed hash does not match the one contained in the SDP answer, the
file receiver SHOULD consider that the file transfer failed and file receiver SHOULD consider that the file transfer failed and
skipping to change at page 19, line 43 skipping to change at page 19, line 12
lines to zero, as per regular SDP [RFC4566] procedures. Similarly, lines to zero, as per regular SDP [RFC4566] procedures. Similarly,
the answerer can accept each individual file separately by setting the answerer can accept each individual file separately by setting
the port number of their associated "m=" lines to non-zero value. the port number of their associated "m=" lines to non-zero value.
Each file has its own file transfer identifier, which uniquely Each file has its own file transfer identifier, which uniquely
identifies each file transfer. identifies each 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]. The same TCP described in Section 8.1 of RFC 4975 [RFC4975]. The same TCP
connection can also be re-used for sequential file transfers. connection can also be reused for sequential file transfers.
8.3. Answerer's Behavior 8.3. 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.3.1. The Answerer is a File Receiver 8.3.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 first examines the port number. file receiver gets the SDP offer, it first examines the port number.
If the port number is set to zero, the file transfer operation is If the port number is set to zero, the file transfer operation is
closed, and no more data is expected over the media stream. Then, if closed, and no more data is expected over the media stream. Then, if
the port number is different than zero, the file receiver inspects the port number is different than zero, the file receiver inspects
the 'file-transfer-id' attribute. If the value of the 'file- the 'file-transfer-id' attribute. If the value of the 'file-
transfer-id' attribute has been previously used then the existing transfer-id' attribute has been previously used, then the existing
session remains without changes, perhaps the file transfer is still session remains without changes; perhaps the file transfer is still
in progress, or perhaps it has concluded, but there are no change in progress, or perhaps it has concluded, but there are no changes
with respect the current status. In any case, independently of the with respect to the current status. In any case, independently of
port number, the SDP answerer creates a regular SDP answer and sends the port number, the SDP answerer creates a regular SDP answer and
it to the offerer. sends it to the offerer.
If the port number is different than zero and the SDP offer contains If the port number is different than zero and the SDP offer contains
a new 'file-transfer-id' attribute, then it is signaling a request a new 'file-transfer-id' attribute, then it is signaling a request
for a new file transfer. The SDP answerer extracts the attributes for a new file transfer. The SDP answerer extracts the attributes
and parameters that describe the file and typically requests and parameters that describe the file and typically requests
permission from the user to accept or reject the reception of the permission from the user to accept or reject the reception of the
file. If the file transfer operation is accepted, the file receiver file. If the file transfer operation is accepted, the file receiver
MUST create an SDP answer according to the procedures specified in MUST create an SDP answer according to the procedures specified in
RFC 3264 [RFC3264]. If the offer contains 'name', 'type', 'size' RFC 3264 [RFC3264]. If the offer contains 'name', 'type', or 'size'
selectors in the 'file-selector' attribute, the answerer MUST copy selectors in the 'file-selector' attribute, the answerer MUST copy
them into the answer. The file receiver copies the value of the them into the answer. The file receiver copies the value of the
'file-transfer-id' attribute to the SDP answer. Then the file 'file-transfer-id' attribute to the SDP answer. Then the file
receiver MUST add a session or media 'recvonly' attribute according receiver MUST add a session or media 'recvonly' attribute according
to the procedures specified in RFC 3264 [RFC3264]. The file receiver to the procedures specified in RFC 3264 [RFC3264]. The file receiver
MUST NOT include 'file-icon', 'file-disposition', or 'file-date' MUST NOT include 'file-icon', 'file-disposition', or 'file-date'
attributes in the SDP answer. 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 or not the file transfer is accepted 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 octets declared in there, receiver accepts to receive the range of octets declared in there,
the file receiver MUST include a 'file-range' attribute in the SDP the file receiver MUST include a 'file-range' attribute in the SDP
answer with the same range of values. If the file receiver does not answer with the same range of values. If the file receiver does not
accept the reception of that range of octets, it SHOULD reject the accept the reception of that range of octets, it SHOULD reject the
transfer of the file. transfer of the file.
When the file transfer operation is complete, the file receiver When the file transfer operation is complete, the file receiver
computes the hash of the file and SHOULD verify that it matches the computes the hash of the file and SHOULD verify that it matches the
hash declared in the SDP. If they do not match, the file receiver hash declared in the SDP. If they do not match, the file receiver
SHOULD consider that the file transfer failed and SHOULD inform the SHOULD consider that the file transfer failed and SHOULD inform the
user. Similarly, the file receiver SHOULD also verify that the other user. Similarly, the file receiver SHOULD also verify that the other
selectors declared in the SDP match the file properties, otherwise, selectors declared in the SDP match the file properties; otherwise,
the file receiver SHOULD consider that the file transfer failed and the file receiver SHOULD consider that the file transfer failed and
SHOULD inform the user. SHOULD inform the user.
8.3.2. The Answerer is a File Sender 8.3.2. The Answerer Is a File Sender
In a pull operation the answerer is the file sender. In this case, In a pull operation the answerer is the file sender. In this case,
the SDP answerer MUST first inspect the value of the the SDP answerer MUST first inspect the value of the
'file-transfer-id' attribute. If it has not been previously been 'file-transfer-id' attribute. If it has not been previously used
used throughout the session, then acceptance of the file MUST provoke throughout the session, then acceptance of the file MUST provoke the
the transfer of the file over the negotiated protocol. However, if transfer of the file over the negotiated protocol. However, if the
the value has been previously used by another file transfer operation value has been previously used by another file transfer operation
within the session, then the file sender MUST NOT alert the user and within the session, then the file sender MUST NOT alert the user and
MUST NOT start a new transfer of the file. No matter whether an MUST NOT start a new transfer of the file. No matter whether or not
actual file transfer is initiated or not, the file sender MUST create an actual file transfer is initiated, the file sender MUST create a
a proper SDP answer that contains the 'file-transfer-id' attribute proper SDP answer that contains the 'file-transfer-id' attribute with
with the same value received in the SDP offer, and then it MUST the same value received in the SDP offer, and then it MUST continue
continue processing the SDP answer. processing the SDP answer.
The file sender MUST always create an SDP answer according to the SDP The file sender MUST always create an SDP answer according to the SDP
offer/answer procedures specified in RFC 3264 [RFC3264]. The file offer/answer procedures specified in RFC 3264 [RFC3264]. The file
sender inspects the file selector of the received SDP offer, which is sender inspects the file selector of the received SDP offer, which is
encoded in the 'file-selector' media attribute line. Then the file encoded in the 'file-selector' media attribute line. Then the file
sender applies the file selector, which implies selecting those files sender applies the file selector, which implies selecting those files
that match one by one with the 'name', 'type', 'size', and 'hash' that match one by one with the 'name', 'type', 'size', and 'hash'
selectors of the 'file-selector' attribute line (if they are selectors of the 'file-selector' attribute line (if they are
present). The file selector identifies zero or more candidate files present). The file selector identifies zero or more candidate files
to be sent. If the file selector is unable to identify any file, to be sent. If the file selector is unable to identify any file,
then the answerer MUST reject the MSRP stream for file transfer by then the answerer MUST reject the MSRP stream for file transfer by
setting the port number to zero, and then the answerer SHOULD also setting the port number to zero, and then the answerer SHOULD also
reject the SDP as per procedures in RFC 3264 [RFC3264], if this is reject the SDP as per procedures in RFC 3264 [RFC3264], if this is
the only stream described in the SDP offer. the only stream described in the SDP offer.
If the file selector points to a single file and the file sender If the file selector points to a single file and the file sender
decides to accept the file transfer, the file sender MUST create an decides to accept the file transfer, the file sender MUST create an
SDP answer that contains a 'sendonly' attribute, according to the SDP answer that contains a 'sendonly' attribute, according to the
procedures described RFC 3264 [RFC3264]. The file sender SHOULD add procedures described in RFC 3264 [RFC3264]. The file sender SHOULD
a 'hash' selector in the answer with the locally computed SHA-1 hash add a 'hash' selector in the answer with the locally computed SHA-1
over the complete file. If a hash value computed by the file sender hash over the complete file. If a hash value computed by the file
differs from that specified by the file receiver, the file sender can sender differs from that specified by the file receiver, the file
either send the file without that hash value or reject the request by sender can either send the file without that hash value or reject the
setting the port in the media stream to zero. The file sender MAY request by setting the port in the media stream to zero. The file
also include a 'type' selector in the 'file-selector' attribute line sender MAY also include a 'type' selector in the 'file-selector'
of the SDP answer. The answerer MAY also include a 'file-icon' and attribute line of the SDP answer. The answerer MAY also include
'file-disposition' attributes to further describe the file. Although 'file-icon' and 'file-disposition' attributes to further describe the
the answerer MAY also include a 'name' and 'size' selectors in the file. Although the answerer MAY also include a 'name' and 'size'
'file-selector' attribute, and a 'file-date' attribute, it is selectors in the 'file-selector' attribute, and a 'file-date'
RECOMMENDED not to include them in the SDP answer if the actual file attribute, it is RECOMMENDED not to include them in the SDP answer if
transfer protocol (e.g., MSRP [RFC4975]) can accommodate a Content- the actual file transfer protocol (e.g., MSRP [RFC4975]) can
Disposition header field [RFC2183] with the equivalent parameters. accommodate a Content-Disposition header field [RFC2183] 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 signaled start. Adding any SDP attributes that are otherwise signaled
later in the file transfer protocol would just duplicate the later in the file transfer protocol would just duplicate the
information, but will not provide any information to the offerer information, but will not provide any information to the offerer
to accept or reject the file transfer (note that the offerer is to accept or reject the file transfer (note that the offerer is
requesting a file). requesting a file).
Last, if the file selector points to multiple candidate files, the Last, if the file selector points to multiple candidate files, the
answerer MAY use some local policy, e.g. consulting the user, to answerer MAY use some local policy, e.g., consulting the user, to
choose one of them to be defined in the SDP answer. If that choice choose one of them to be defined in the SDP answer. If that choice
cannot be done, the answerer SHOULD reject the MSRP media stream for cannot be done, the answerer SHOULD reject the MSRP media stream for
file transfer (by setting the port number to zero). file transfer (by setting the port number to zero).
If the need arises, future specifications can provide a suitable If the need arises, future specifications can provide a suitable
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 octets declared in there, the sender accepts to send the range of octets declared in there, the
file sender MUST include a 'file-range' attribute in the SDP answer file sender MUST include a 'file-range' attribute in the SDP answer
with the same range of values. If the file sender does not accept with the same range of values. If the file sender does not accept
sending that range of octets, it SHOULD reject the transfer of the sending that range of octets, it SHOULD reject the transfer of the
file. file.
8.4. Aborting an ongoing file transfer operation 8.4. Aborting an Ongoing File Transfer Operation
Either the file sender or the file receiver can abort an ongoing file Either the file sender or the file receiver can abort an ongoing file
transfer at any time. Unless otherwise noted, the entity that aborts transfer at any time. Unless otherwise noted, the entity that aborts
an ongoing file transfer operation MUST follow the procedures at the an ongoing file transfer operation MUST follow the procedures at the
media level (e.g., MSRP) and at the signaling level (SDP Offer/ media level (e.g., MSRP) and at the signaling level (SDP offer/
answer), as described below. answer), as described below.
Assume the scenario depicted in Figure 4 where a file sender wishes Assume the scenario depicted in Figure 4 where a file sender wishes
to abort an ongoing file transfer without initiating an alternative to abort an ongoing file transfer without initiating an alternative
file transfer. Assume that an ongoing MSRP SEND request is being file transfer. Assume that an ongoing MSRP SEND request is being
transmitted. The file sender aborts the MSRP message by including transmitted. The file sender aborts the MSRP message by including
the '#' character in the continuation field of the end-line of a SEND the '#' character in the continuation field of the end-line of a SEND
request, according to the MSRP procedures (see Section 7.1 of RFC request, according to the MSRP procedures (see Section 7.1 of RFC
4975 [RFC4975]). Since a file is transmitted as one MSRP message, 4975 [RFC4975]). Since a file is transmitted as one MSRP message,
aborting the MSRP message effectively aborts the file transfer. The aborting the MSRP message effectively aborts the file transfer. The
file receiver acknowledges the MSRP SEND request with a 200 response. file receiver acknowledges the MSRP SEND request with a 200 response.
Then the file sender SHOULD close the MSRP session by creating a new Then the file sender SHOULD close the MSRP session by creating a new
SDP offer that sets the port number to zero in the related "m=" line SDP offer that sets the port number to zero in the related "m=" line
that describes the file transfer (see Section 8.2 of RFC 3264 that describes the file transfer (see Section 8.2 of RFC 3264
[RFC3264]). This SDP offer MUST conform with the requirements of [RFC3264]). This SDP offer MUST conform with the requirements of
Section 8.2.1. The 'file-transfer-id' attribute MUST be the same Section 8.2.1. The 'file-transfer-id' attribute MUST be the same
that identifies the ongoing transfer. Then the file sender sends attribute that identifies the ongoing transfer. Then the file sender
this SDP offer to the file receiver. sends this SDP offer to the file receiver.
Rather than close the MSRP session by setting the port number to Rather than close the MSRP session by setting the port number to
zero in the related "m=" line, the file sender could also tear zero in the related "m=" line, the file sender could also tear
down the whole session, e.g., by sending a SIP BYE request. down the whole session, e.g., by sending a SIP BYE request.
Note that it is responsibility of the file sender to tear down the Note that it is the responsibility of the file sender to tear down
MSRP session. Implementations should be prepared for misbehaviors the MSRP session. Implementations should be prepared for
and implement measures to avoid hang states. For example, upon misbehaviors and implement measures to avoid hang states. For
expiration of a timer the file receiver can close the aborted MSRP example, upon expiration of a timer the file receiver can close the
session by using regular MSRP procedures. aborted MSRP session by using regular MSRP procedures.
A file receiver that receives the above SDP offer creates an SDP A file receiver that receives the above SDP offer creates an SDP
answer according to the procedures of the SDP offer/answer (RFC 3264 answer according to the procedures of the SDP offer/answer (RFC 3264
[RFC3264]). This SDP answer MUST conform with the requirements of [RFC3264]). This SDP answer MUST conform with the requirements of
Section 8.3.1. Then the file receiver sends this SDP answer to the Section 8.3.1. Then the file receiver sends this SDP answer to the
file sender. file sender.
File sender File receiver File sender File receiver
| | | |
|\ | |\ |
skipping to change at page 24, line 16 skipping to change at page 23, line 39
header in the ongoing MSRP SEND request. Assume now the scenario header in the ongoing MSRP SEND request. Assume now the scenario
depicted in Figure 5 where the MSRP SEND request includes a Failure- depicted in Figure 5 where the MSRP SEND request includes a Failure-
Report header set to a value different than "no". When the file Report header set to a value different than "no". When the file
receiver wishes to abort the ongoing file transfer, the file receiver receiver wishes to abort the ongoing file transfer, the file receiver
generates an MSRP 413 response to the current MSRP SEND request (see generates an MSRP 413 response to the current MSRP SEND request (see
Section 10.5 of RFC 4975 [RFC4975]). Then the file receiver MUST Section 10.5 of RFC 4975 [RFC4975]). Then the file receiver MUST
close the MSRP session by generating a new SDP offer that sets the close the MSRP session by generating a new SDP offer that sets the
port number to zero in the related "m=" line that describes the file port number to zero in the related "m=" line that describes the file
transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer
MUST conform with the requirements expressed in Section 8.2.2. The MUST conform with the requirements expressed in Section 8.2.2. The
'file-transfer-id' attribute MUST be the same that identifies the 'file-transfer-id' attribute MUST be the same attribute that
ongoing transfer. Then the file receiver sends this SDP offer to the identifies the ongoing transfer. Then the file receiver sends this
file sender. SDP offer to the file sender.
File sender File receiver File sender File receiver
| | | |
|\ | |\ |
| \ MSRP SEND | | \ MSRP SEND |
| \ Failure-Report: yes | | \ Failure-Report: yes |
| \ | | \ |
| \ | | \ |
| \ | | \ |
| \ | | \ |
skipping to change at page 24, line 49 skipping to change at page 24, line 34
| SIP ACK | | SIP ACK |
|<-----------------------| |<-----------------------|
| | | |
Figure 5: File receiver aborts an ongoing file transfer. Failure- Figure 5: File receiver aborts an ongoing file transfer. Failure-
Report set to a value different than "no" in MSRP Report set to a value different than "no" in MSRP
In another scenario, depicted in Figure 6, an ongoing file transfer In another scenario, depicted in Figure 6, an ongoing file transfer
is taking place, where the MSRP SEND request contains a Failure- is taking place, where the MSRP SEND request contains a Failure-
Report header set to the value "no". When the file receiver wants to Report header set to the value "no". When the file receiver wants to
abort the ongoing transfer, it MUST close MSRP session by generating abort the ongoing transfer, it MUST close the MSRP session by
a new SDP offer that sets the port number to zero in the related "m=" generating a new SDP offer that sets the port number to zero in the
line that describes the file transfer (see Section 8.2 of RFC 3264 related "m=" line that describes the file transfer (see Section 8.2
[RFC3264]). This SDP offer MUST conform with the requirements of RFC 3264 [RFC3264]). This SDP offer MUST conform with the
expressed in Section 8.2.2. The 'file-transfer-id' attribute MUST be requirements expressed in Section 8.2.2. The 'file-transfer-id'
the same that identifies the ongoing transfer. Then the file attribute MUST be the same attribute that identifies the ongoing
receiver sends this SDP offer to the file sender. transfer. Then the file receiver sends this SDP offer to the file
sender.
File sender File receiver File sender File receiver
| | | |
|\ | |\ |
| \ MSRP SEND | | \ MSRP SEND |
| \ Failure-Report: no | | \ Failure-Report: no |
| \ | | \ |
| \ | | \ |
| \ | | \ |
| \ | | \ |
skipping to change at page 25, line 38 skipping to change at page 25, line 33
|----------------------->| |----------------------->|
| SIP ACK | | SIP ACK |
|<-----------------------| |<-----------------------|
| | | |
Figure 6: File receiver aborts an ongoing file transfer. Failure- Figure 6: File receiver aborts an ongoing file transfer. Failure-
Report set to "no" in MSRP Report set to "no" in MSRP
A file sender that receives an SDP offer setting the port number to A file sender that receives an SDP offer setting the port number to
zero in the related "m=" line for file transfer, first, if an ongoing zero in the related "m=" line for file transfer, first, if an ongoing
MSRP SEND request is being transmitted, it aborts the MSRP message by MSRP SEND request is being transmitted, aborts the MSRP message by
including the '#' character in the continuation field of the end-line including the '#' character in the continuation field of the end-line
of a SEND request, according to the MSRP procedures (see Section 7.1 of a SEND request, according to the MSRP procedures (see Section 7.1
of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP
message, aborting the MSRP message effectively aborts the file message, aborting the MSRP message effectively aborts the file
transfer. Then the file sender creates an SDP answer according to transfer. Then the file sender creates an SDP answer according to
the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This
SDP answer MUST conform with the requirements of Section 8.3.2. Then SDP answer MUST conform with the requirements of Section 8.3.2. Then
the file sender sends this SDP answer to the file receiver. the file sender sends this SDP answer to the file receiver.
8.5. Indicating File Transfer Offer/Answer Capability 8.5. Indicating File Transfer Offer/Answer Capability
The SDP Offer/Answer Model [RFC3264] provides provisions for The SDP offer/answer model [RFC3264] provides provisions for
indicating a capability to another endpoint (see Section 9 of RFC indicating a capability to another endpoint (see Section 9 of RFC
3264 [RFC3264]). The mechanism assumes a high-level protocol, such 3264 [RFC3264]). The mechanism assumes a high-level protocol, such
as SIP [RFC3261], that provides a capability query (such as a SIP as SIP [RFC3261], that provides a capability query (such as a SIP
OPTIONS request). RFC 3264 [RFC3264] indicates how to build the SDP OPTIONS request). RFC 3264 [RFC3264] indicates how to build the SDP
that is included in the response to such capability query. As such, that is included in the response to such capability query. As such,
RFC 3264 indicates that an endpoint builds an SDP body that contains RFC 3264 indicates that an endpoint builds an SDP body that contains
an "m=" line containing the media type (message, for MSRP). An an "m=" line containing the media type (message, for MSRP). An
endpoint that implements the procedures specified in this document endpoint that implements the procedures specified in this document
SHOULD also add a 'file-selector' media attribute for the "m=message" SHOULD also add a 'file-selector' media attribute for the "m=message"
line. The 'file-selector' media attribute MUST be empty, i.e., it line. The 'file-selector' media attribute MUST be empty, i.e., it
MUST NOT contain any selector. The endpoint MUST NOT add any of the MUST NOT contain any selector. The endpoint MUST NOT add any of the
other file attributes defined in this specification. other file attributes defined in this specification.
8.6. Re-usage of Existing "m=" Lines in SDP 8.6. Reusage of Existing "m=" Lines in SDP
The SDP Offer/Answer Model [RFC3264] provides rules that allow SDP The SDP offer/answer model [RFC3264] provides rules that allow SDP
offerers and answerers to modify an existing media line, i.e., re-use offerers and answerers to modify an existing media line, i.e., reuse
an existing media line with different attributes. The same is also an 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
[RFC3264], in particular those defined in Section 8.3, MUST apply for [RFC3264], in particular those defined in Section 8.3, MUST apply for
file transfer operations. An endpoint that wants to re-use an file transfer operations. An endpoint that wants to reuse an
existing "m=" line to start the file transfer of another file creates existing "m=" line to start the file transfer of another file creates
a different 'file-selector' attribute and selects a new globally a different 'file-selector' attribute and selects a new globally
unique random value of the 'file-transfer-id' attribute. unique random value of the 'file-transfer-id' attribute.
If the file offerer re-sends an SDP offer with a port different than If the file offerer resends an SDP offer with a port different than
zero, then the 'file-transfer-id' attribute determines whether a new zero, then the 'file-transfer-id' attribute determines whether a new
file transfer will start or whether the file transfer does not need file transfer will start or whether the file transfer does not need
to start. If the SDP answerer accepts the SDP, then file transfer to start. If the SDP answerer accepts the SDP, then file transfer
starts from the indicated octet (if a 'file-range' attribute is starts from the indicated octet (if a 'file-range' attribute is
present). present).
8.7. MSRP Usage 8.7. MSRP Usage
The file transfer service specified in this document uses "m=" lines The file transfer service specified in this document uses "m=" lines
in SDP to describe the unidirectional transfer of a file. in SDP to describe the unidirectional transfer of a file.
Consequently, each MSRP session established following the procedures Consequently, each MSRP session established following the procedures
in Section 8.2 and Section 8.3 is only used to transfer a single in Section 8.2 and Section 8.3 is only used to transfer a single
file. So, senders MUST only use the dedicated MSRP session to send file. So, senders MUST only use the dedicated MSRP session to send
the file described in the SDP offer or answer. That is, senders MUST the file described in the SDP offer or answer. That is, senders MUST
NOT send additional files over the same MSRP session. NOT send additional files over the same MSRP session.
File transfer may be accomplished using a new multimedia session File transfer may be accomplished using a new multimedia session
established for the purpose. Alternatively a file transfer may be established for the purpose. Alternatively, a file transfer may be
conducted within an existing multimedia session, without regard for conducted within an existing multimedia session, without regard for
the media in use within that session. Of particular note, file the media in use within that session. Of particular note, file
transfer may be done within a multimedia session containing an MSRP transfer may be done within a multimedia session containing an MSRP
session used for regular instant messaging. If file transfer is session used for regular instant messaging. If file transfer is
initiated within an existing multimedia session, the SDP offerer MUST initiated within an existing multimedia session, the SDP offerer MUST
NOT reuse an existing "m=" line that is still being used by MSRP NOT reuse an existing "m=" line that is still being used by MSRP
(either regular MSRP for instant messaging or an ongoing file (either regular MSRP for instant messaging or an ongoing file
transfer). Rather it MUST add an addtional "m=" line or else reuse transfer). Rather, it MUST add an additional "m=" line or else reuse
an "m=" line that is no longer being used. an "m=" line that is no longer being used.
Additionally, implementations according to this specification MUST Additionally, implementations according to this specification MUST
include a single file in a single MSRP message. Notice that the MSRP include a single file in a single MSRP message. Notice that the MSRP
specification defines "MSRP message" as a complete unit of MIME or specification defines "MSRP message" as a complete unit of MIME or
text content, which can be split and delivered in more than one MSRP 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 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 "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 from the MSRP point of view, all the chunks together form an MSRP
message: the CPIM message that wraps the file. When chunking is message: the Common Presence and Instant Messaging (CPIM) message
used, it should be noticed that MSRP does not require to wait for a that wraps the file. When chunking is used, it should be noticed
200-class response for a chunk before sending the following one. that MSRP does not require to wait for a 200-class response for a
Therefore, it is valid to send pipelined MSRP SEND requests chunk before sending the following one. Therefore, it is valid to
containing chunks of the same MSRP message (the file). Section 9.1 send pipelined MSRP SEND requests containing chunks of the same MSRP
contains an example of a file transfer using pipelined MSRP requests. message (the file). Section 9.1 contains an example of a file
transfer using pipelined MSRP requests.
The MSRP specification [RFC4975] defines a 'max-size' SDP attribute. The MSRP specification [RFC4975] defines a 'max-size' SDP attribute.
This attribute specifies the maximum number of octets of an MSRP This attribute specifies the maximum number of octets of an MSRP
message that the creator of the SDP is willing to receive (notice message that the creator of the SDP is willing to receive (notice
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.
skipping to change at page 28, line 16 skipping to change at page 28, line 8
header can also take the value 'attachment' as indicated in header can also take the value 'attachment' as indicated in
Section 7. Section 7.
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 [RFC4975] MSRP session and MUST behave according to the MSRP [RFC4975]
procedures with respect to closing MSRP sessions. Note that MSRP procedures with respect to closing MSRP sessions. Note that MSRP
session management is not related to TCP connection management. As a session management is not related to TCP connection management. As a
matter of fact, MSRP allows multiple MSRP sessions to share the same matter of fact, MSRP allows multiple MSRP sessions to share the same
TCP connection. TCP connection.
8.8. Considerations about the 'file-icon' attribute 8.8. Considerations about the 'file-icon' Attribute
This specification allows a file sender to include a small preview of This specification allows a file sender to include a small preview of
an image file: an icon. A 'file-icon' attribute contains a CID URL an image file: an icon. A 'file-icon' attribute contains a
[RFC2392] pointing to an additional body that contains the actual Content-ID (CID) URL [RFC2392] pointing to an additional body that
icon. Since the icon is sent as a separate body along the SDP body, contains the actual icon. Since the icon is sent as a separate body
the file sender MUST wrap the SDP body and the icon bodies in a MIME along the SDP body, the file sender MUST wrap the SDP body and the
multipart/related body. Therefore, implementations according to this icon bodies in a MIME multipart/related body. Therefore,
specification MUST implement the multipart/related MIME type implementations according to this specification MUST implement the
[RFC2387]. When creating a multipart/related MIME wrapper, the SDP multipart/related MIME type [RFC2387]. When creating a multipart/
body MUST be the root body, which according to RFC 2387 [RFC2387] is related MIME wrapper, the SDP body MUST be the root body, which
identified as the first body in the multipart/related MIME wrapper or according to RFC 2387 [RFC2387] is identified as the first body in
explicitly identified by the 'start' parameter. According to RFC the multipart/related MIME wrapper or explicitly identified by the
2387 [RFC2387], the 'type' parameter MUST be present and point to the 'start' parameter. According to RFC 2387 [RFC2387], the 'type'
root body, i.e., the SDP body. parameter MUST be present and point to the root body, i.e., the SDP
body.
Assume that an endpoint behaving according to this specification Assume that an endpoint behaving according to this specification
tries to send a file to a remote endpoint that neither implements tries to send a file to a remote endpoint that neither implements
this specification nor implements multipart MIME bodies. The file this specification nor implements multipart MIME bodies. The file
sender sends an SDP offer that contains a multipart/related MIME body sender sends an SDP offer that contains a multipart/related MIME body
that includes an SDP body part and an icon body part. The file that includes an SDP body part and an icon body part. The file
receiver, not supporting multipart MIME types, will reject the SDP receiver, not supporting multipart MIME types, will reject the SDP
offer via a higher protocol mechanism (e.g., SIP). In this case, it offer via a higher protocol mechanism (e.g., SIP). In this case, it
is RECOMMENDED that the file sender removes the icon body part, is RECOMMENDED that the file sender removes the icon body part,
creates a single SDP body (i.e., without multipart MIME) and re-sends creates a single SDP body (i.e., without multipart MIME), and resends
the SDP offer again. This provides some backwards compatibility with the SDP offer. This provides some backwards compatibility with file
file receives that do not implement this specification and increases receives that do not implement this specification and increases the
the chances of getting the SDP accepted at the file receiver. chances of getting the SDP accepted at the file receiver.
Since the icon is sent as part of the signaling, it is RECOMMENDED to Since the icon is sent as part of the signaling, it is RECOMMENDED to
keep the size of icons restricted to the minimum number of octets keep the size of icons restricted to the minimum number of octets
that provide significance. that provide significance.
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 [RFC3261] is used to transport the SDP example assumes that SIP [RFC3261] is used to transport the SDP
offer/answer exchange, although the SIP details are briefly shown for offer/answer exchange, although the SIP details are briefly shown for
the sake of brevity. the 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
skipping to change at page 33, line 4 skipping to change at page 32, line 50
Figure 11: MSRP SEND request containing the second chunk of actual Figure 11: MSRP SEND request containing the second chunk of actual
file file
F6: Bob acknowledges the reception of the first chunk. F6: Bob acknowledges the reception of the first chunk.
MSRP d93kswow 200 OK MSRP d93kswow 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: 1-2048/4385 Byte-Range: 1-2048/4385
-------d93kswow$ -------d93kswow$
Figure 12: MSRP 200 OK response
Figure 12: 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 13: MSRP 200 OK response Figure 13: MSRP 200 OK response
F8: Alice terminates the SIP session by sending a SIP BYE request. F8: Alice terminates the SIP session by sending a SIP BYE request.
F9: Bob acknowledges the reception of the BYE request and sends a 200 F9: Bob acknowledges the reception of the BYE request and sends a 200
(OK) response. (OK) response.
9.2. Offerer requests a file from the Answerer and second file transfer 9.2. Offerer Requests a File from the Answerer and Second File Transfer
In this example Alice, the SDP offerer, first wishes to fetch a file In this example, Alice, the SDP offerer, first wishes to fetch a file
from Bob, the SDP answerer. Alice knows that Bob has a specific file from Bob, the SDP answerer. Alice knows that Bob has a specific file
she wants to download. She has learned the hash of the file by some she wants to download. She has learned the hash of the file by some
out-of-band mechanism. The hash selector is enough to produce a file out-of-band mechanism. The hash selector is enough to produce a file
selector that points to the specific file. So, Alice creates an SDP selector that points to the specific file. So, Alice creates an SDP
offer that contains the file descriptor. Bob accepts the file offer that contains the file descriptor. Bob accepts the file
transfer and sends the file to Alice. When Alice has completely transfer and sends the file to Alice. When Alice has completely
received Bob's file, she intends to send a new image file to Bob. received Bob's file, she intends to send a new image file to Bob.
Therefore Alice re-uses the existing SDP media line with different Therefore, Alice reuses the existing SDP media line with different
attributes and updates the description of the new file she wants to attributes and updates the description of the new file she wants to
send to Bob's User Agent Server (UAS). In particular, Alice creates send to Bob's User Agent Server (UAS). In particular, Alice creates
a new file transfer identifier since this is a new file transfer a new file transfer identifier since this is a new file transfer
operation. Figure 14 shows the sequence flow. operation. Figure 14 shows the sequence flow.
Alice's UAC Bob's UAS Alice's UAC Bob's UAS
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
|----------------------->| |----------------------->|
|(2) (SIP) 200 OK | |(2) (SIP) 200 OK |
skipping to change at page 35, line 39 skipping to change at page 35, line 39
Figure 15: INVITE request containing an SDP offer for file transfer Figure 15: INVITE request containing an 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.
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 transfer and creates an indicated in the SDP. Bob accepts the file transfer and creates an
SDP answer as follows: 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
skipping to change at page 37, line 13 skipping to change at page 37, line 13
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/jshA7we;tcp From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
Byte-Range: 1-2027/2027 Byte-Range: 1-2027/2027
-------d93kswow$ -------d93kswow$
Figure 18: MSRP 200 OK response Figure 18: MSRP 200 OK response
F6: Alice re-uses the existing SDP media line inserting the F6: Alice reuses 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. Alice reuses the TCP port number for the request addressed to Bob. Alice reuses the TCP port number for the
MSRP stream, but changes the MSRP session and the 'file-transfer-id' MSRP stream, but changes the MSRP session and the 'file-transfer-id'
value according to this specification. 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
skipping to change at page 39, line 37 skipping to change at page 39, line 37
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 20: SDP answer accepting the SDP offer for file transfer Figure 20: 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: If a TCP connection towards Bob is already open, Alice re-uses F9: If a TCP connection towards Bob is already open, Alice reuses
that TCP connection to send an MSRP SEND request that contains the that TCP connection to send an MSRP SEND request that contains the
file. file.
MSRP d95ksxox SEND MSRP d95ksxox SEND
To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
From-Path: msrp://alicepc.example.com:7654/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
skipping to change at page 40, line 41 skipping to change at page 40, line 41
-------d95ksxox$ -------d95ksxox$
Figure 22: MSRP 200 OK response Figure 22: 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 9.3. Example of a Capability Indication
Alice sends an OPTIONS request to Bob (this request does not contain Alice sends an OPTIONS request to Bob (this request does not contain
SDP). Bob answers with a 200 (OK) response that contain the SDP SDP). Bob answers with a 200 (OK) response that contain the SDP
shown in Figure 24. The SDP indicates support for CPIM messages that shown in Figure 24. The SDP indicates support for CPIM messages that
can contain other MIME types. The maximum MSRP message size that the can contain other MIME types. The maximum MSRP message size that the
endpoint can receive is 20000 octets. The presence of the 'file- endpoint can receive is 20000 octets. The presence of the 'file-
selector' attribute indicates support for the file transfer offer/ selector' attribute indicates support for the file transfer offer/
answer mechanism. answer mechanism.
Alice's UAC Bob's UAS Alice's UAC Bob's UAS
skipping to change at page 42, line 9 skipping to change at page 42, line 8
reveal information the endpoints may consider confidential. reveal information the endpoints may consider confidential.
Therefore, it is RECOMMENDED that SDP session descriptions carrying Therefore, it is RECOMMENDED that SDP session descriptions carrying
the attributes specified in this specification are encrypted. the attributes specified in this specification are encrypted.
TLS and S/MIME are the natural choices to provide offer/answer TLS and S/MIME are the natural choices to provide offer/answer
exchanges with integrity protection and confidentiality. exchanges with integrity protection and confidentiality.
When an SDP offer contains the description of a file to be sent or When an SDP offer contains the description of a file to be sent or
received, the SDP answerer MUST first authenticate the SDP offerer received, the SDP answerer MUST first authenticate the SDP offerer
and then it MUST authorize the file transfer operation, typically and then it MUST authorize the file transfer operation, typically
according to a local policy. Typically these functions are according to a local policy. Typically, these functions are
integrated in the high-level protocol that carries SDP (e.g., SIP), integrated in the high-level protocol that carries SDP (e.g., SIP),
and in the file transfer protocol (e.g., MSRP). If SIP [RFC3261] and and in the file transfer protocol (e.g., MSRP). If SIP [RFC3261] and
MSRP [RFC4975] are used, the standard mechanisms for user MSRP [RFC4975] are used, the standard mechanisms for user
authentication and authorization are sufficient. authentication and authorization are sufficient.
It is possible that a malicious or misbehaving implementation tries It is possible that a malicious or misbehaving implementation tries
to exhaust the resources of the remote endpoint, e.g., the internal to exhaust the resources of the remote endpoint, e.g., the internal
memory or the file system, by sending very large files. To protect memory or the file system, by sending very large files. To protect
from this attack, an SDP answer SHOULD first verify the identity of from this attack, an SDP answer SHOULD first verify the identity of
the SDP offerer, and perhaps only accept file transfers from trusted the SDP offerer, and perhaps only accept file transfers from trusted
skipping to change at page 42, line 35 skipping to change at page 42, line 34
attacks on resource exhaustion, for example, by limiting the size of attacks on resource exhaustion, for example, by limiting the size of
received files, verifying that there is enough space in the file received files, verifying that there is enough space in the file
system to store the file prior to its reception, or limiting the system to store the file prior to its reception, or limiting the
number of simultaneous file transfers. number of simultaneous file transfers.
File receivers MUST also sanitize all input, such as the local file File receivers MUST also sanitize all input, such as the local file
name, prior to making calls to the local file system to store a file. name, prior to making calls to the local file system to store a file.
This is to prevent the existence of meaningful characters to the This is to prevent the existence of meaningful characters to the
local operating system that could damage it. local operating system that could damage it.
Once a file has been transferred the file receiver must take care of Once a file has been transferred, the file receiver must take care of
it. Typically file transfer is a commonly used mechanism for it. Typically, file transfer is a commonly used mechanism for
transmitting computer virus, spyware, and other types of malware. transmitting computer virus, spyware, and other types of malware.
File receivers should apply all possible security technologies (e.g., File receivers should apply all possible security technologies (e.g.,
antivirus, antispyware, etc.) to mitigate the risk of damage at their anti-virus, anti-spyware) to mitigate the risk of damage at their
host. host.
11. IANA Considerations 11. IANA Considerations
This document instructs IANA to register a number of SDP attributes IANA has registered a number of SDP attributes according to the
according to the following: following.
11.1. Registration of new SDP attributes
This memo provides instructions to IANA to register a number of media 11.1. Registration of New SDP Attributes
level only attributes in the Session Description Protocol Parameters
registry [4]. The registration data, according to RFC 4566 [RFC4566]
follows.
Note to the RFC Editor: replace "RFC XXXX" with the RFC number of IANA has registered a number of media-level-only attributes in the
this specification. Session Description Protocol Parameters registry [IANA]. The
registration data, according to RFC 4566 [RFC4566], follows.
11.1.1. Registration of the file-selector attribute 11.1.1. Registration of the file-selector Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000 Phone: +34 91 339 1000
Attribute name: file-selector Attribute name: file-selector
Long-form attribute name: File Selector Long-form attribute name: File Selector
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 identifies 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
11.1.2. Registration of the file-transfer-id attribute Specification: RFC 5547
11.1.2. Registration of the file-transfer-id Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000 Phone: +34 91 339 1000
Attribute name: file-transfer-id Attribute name: file-transfer-id
Long-form attribute name: File Transfer Identifier Long-form attribute name: File Transfer Identifier
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 contains a unique identifier of the
file transfer operation within the session.
Specification: RFC XXXX
11.1.3. Registration of the file-disposition attribute Description: This attribute contains a unique identifier of the file
transfer operation within the session.
Specification: RFC 5547
11.1.3. Registration of the file-disposition Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000 Phone: +34 91 339 1000
Attribute name: file-disposition Attribute name: file-disposition
Long-form attribute name: File Disposition Long-form attribute name: File Disposition
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
11.1.4. Registration of the file-date attribute Specification: RFC 5547
11.1.4. Registration of the file-date Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000 Phone: +34 91 339 1000
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 on which the file
was created, modified, or last read. was created, modified, or last read.
Specification: RFC XXXX
11.1.5. Registration of the file-icon attribute Specification: RFC 5547
11.1.5. Registration of the file-icon Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000 Phone: +34 91 339 1000
Attribute name: file-icon Attribute name: file-icon
Long-form attribute name: File Icon Long-form attribute name: File Icon
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
a body that includes a small preview icon representing the
contents of the file to be transferred
Specification: RFC XXXX
11.1.6. Registration of the file-range attribute Description: For image files, this attribute contains a pointer to a
body that includes a small preview icon representing the contents
of the file to be transferred.
Specification: RFC 5547
11.1.6. Registration of the file-range Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000 Phone: +34 91 339 1000
Attribute name: file-range Attribute name: file-range
Long-form attribute name: File Range Long-form attribute name: File Range
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 octets of the
file
Specification: RFC XXXX
12. Acknowledgements Description: This attribute contains the range of transferred octets
of the file.
Specification: RFC 5547
12. Acknowledgments
The authors would like to thank Mats Stille, Nancy Greene, Adamu The authors would like to thank Mats Stille, Nancy Greene, Adamu
Haruna, and Arto Leppisaari for discussing initial concepts described Haruna, and Arto Leppisaari for discussing initial concepts described
in this memo. Thanks to Pekka Kuure for reviewing initial versions in this memo. Thanks to Pekka Kuure for reviewing initial versions
this document and providing helpful comments. Joerg Ott, Jiwey Wang, of this document and providing helpful comments. Joerg Ott, Jiwey
Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Wang, Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis-
Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan
Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, Richard Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, Richard
Barnes, and Chris Newman discussed and provided comments and Barnes, and Chris Newman discussed and provided comments and
improvements to this document. improvements to this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997. Content-Disposition Header Field", RFC 2183,
August 1997.
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2387, August 1998. RFC 2387, August 1998.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform
Locators", RFC 2392, August 1998. Resource Locators", RFC 2392, August 1998.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001. (SHA1)", RFC 3174, September 2001.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August 2004. Messaging (CPIM): Message Format", RFC 3862,
August 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975,
September 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
13.2. Informational References 13.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Session Initiation Protocol (SIP)", RFC 4028, April 2005. Session Initiation Protocol (SIP)", RFC 4028,
April 2005.
[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)",
September 2007. RFC 4976, September 2007.
[I-D.ietf-rmt-flute-revised]
Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE -
File Delivery over Unidirectional Transport",
draft-ietf-rmt-flute-revised-06 (work in progress),
September 2008.
URIs
[1] <http://www.iana.org/assignments/media-types/>
[2] <http://www.iana.org/assignments/hash-function-text-names>
[3] <http://www.iana.org/assignments/mail-cont-disp> [IANA] IANA, "Internet Assigned Numbers Authority",
<http://www.iana.org>.
[4] <http://www.iana.org/assignments/sdp-parameters> [FLUTE-REV] Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE -
File Delivery over Unidirectional Transport", Work
in Progress, September 2008.
Appendix A. Alternatives Considered Appendix A. 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 that 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) [RFC4483]. Both mechanisms allow a user agent to decide (SIP) [RFC4483]. Both mechanisms allow a user agent to decide
whether or not to download a file based on information about the whether or not to download a file based on information about the
file. However, there are some differences. With content file. However, there are some differences. With content
indirection, it is not possible for the other endpoint to explicitly indirection, it is not possible for the other endpoint to explicitly
accept or reject the file transfer. Also, it is not possible for an accept or reject the file transfer. Also, it is not possible for an
endpoint to request a file from another endpoint. Furthermore, endpoint to request a file from another endpoint. Furthermore,
content indirection is not tied to the context of a media session, content indirection is not tied to the context of a media session,
which is sometimes a desirable property. Finally, content which is sometimes a desirable property. Finally, content
indirection typically requires some server infrastructure, which may indirection typically requires some server infrastructure, which may
skipping to change at page 47, line 28 skipping to change at page 48, line 40
directly between the endpoints too, but in that case there is no directly between the endpoints too, but in that case there is no
definition for how it works for endpoints behind NATs. The level of definition for how it works for endpoints behind NATs. The level of
requirements in implementations decides which solution meets the requirements in implementations decides which solution meets the
requirements. requirements.
Based on the argumentation above, this document defines the SDP Based on the argumentation above, this document defines the SDP
attribute extensions and usage conventions needed for meeting the attribute extensions and usage conventions needed for meeting the
requirements on file transfer services with the SDP offer/answer requirements on file transfer services with the SDP offer/answer
model, using MSRP as the transfer protocol within the session. model, using MSRP as the transfer protocol within the session.
In principle it is possible to use the SDP extensions defined here In principle, it is possible to use the SDP extensions defined
and replace MSRP with any other similar protocol that can carry here and replace MSRP with any other similar protocol that can
MIME objects. This kind of specification can be written as a carry MIME objects. This kind of specification can be written as
separate document if the need arises. Essentially, such protocol a separate document if the need arises. Essentially, such a
should be able to be negotiated on an SDP offer/answer exchange protocol should be able to be negotiated on an SDP offer/answer
(RFC 3264 [RFC3264]), be able to describe the file to be exchange (RFC 3264 [RFC3264]), be able to describe the file to be
transferred in SDP offer/answer exchange, be able to carry MIME transferred in SDP offer/answer exchange, be able to carry MIME
objects between two endpoints, and use a reliable transport objects between two endpoints, and use a reliable transport
protocol (e.g., TCP). protocol (e.g., TCP).
This specification defines a set of SDP attributes that describe a This specification defines a set of SDP attributes that describe a
file to be transferred between two endpoints. The information needed file to be transferred between two endpoints. The information needed
to describe a file could be potentially encoded in a few different to describe a file could be potentially encoded in a few different
ways. The MMUSIC working group considered a few alternative ways. The MMUSIC working group considered a few alternative
approaches before deciding to use the encoding described in approaches before deciding to use the encoding described in
Section 6. In particular, the working group looked at the MIME Section 6. In particular, the working group looked at the MIME
skipping to change at page 48, line 24 skipping to change at page 50, line 13
redefined specifically for that parameter. redefined specifically for that parameter.
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Ericsson Ericsson
Calle Via de los Poblados 13 Calle Via de los Poblados 13
Madrid, ES 28033 Madrid, ES 28033
Spain Spain
Email: miguel.a.garcia@ericsson.com EMail: miguel.a.garcia@ericsson.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
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Salvatore.Loreto@ericsson.com EMail: Salvatore.Loreto@ericsson.com
Paul H. Kyzivat Paul H. Kyzivat
Cisco Systems Cisco Systems
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: pkyzivat@cisco.com EMail: pkyzivat@cisco.com
 End of changes. 174 change blocks. 
354 lines changed or deleted 374 lines changed or added

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