draft-ietf-mmusic-file-transfer-mech-06.txt   draft-ietf-mmusic-file-transfer-mech-07.txt 
MMUSIC Working Group M. Garcia-Martin MMUSIC Working Group M. Garcia-Martin
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Standards Track M. Isomaki Intended status: Standards Track M. Isomaki
Expires: June 23, 2008 Nokia Expires: September 28, 2008 Nokia
G. Camarillo G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
December 21, 2007 March 27, 2008
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable
File Transfer File Transfer
draft-ietf-mmusic-file-transfer-mech-06.txt draft-ietf-mmusic-file-transfer-mech-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 23, 2008. This Internet-Draft will expire on September 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides a mechanism to negotiate the transfer of one This document provides a mechanism to negotiate the transfer of one
or more files between two endpoints by using the Session Description or more files between two endpoints by using the Session Description
Protocol (SDP) offer/answer model specified in RFC 3264. SDP is Protocol (SDP) offer/answer model specified in RFC 3264. SDP is
extended to describe the attributes of the files to be transferred. extended to describe the attributes of the files to be transferred.
The offerer can either describe the files it wants to send, or the The offerer can either describe the files it wants to send, or the
files it would like to receive. The answerer can either accept or files it would like to receive. The answerer can either accept or
reject the offer separately for each individual file. The transfer reject the offer separately for each individual file. The transfer
of one or more files is initiated after a successful negotiation. of one or more files is initiated after a successful negotiation.
The Message Session Relay Protocol (MSRP) is defined as the default The Message Session Relay Protocol (MSRP) is defined as the default
mechanism to actually carry the files between the endpoints. The mechanism to actually carry the files between the endpoints. The
conventions on how to use MSRP for file transfer are also provided in conventions on how to use MSRP for file transfer are also provided in
this document. this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Alternatives Considered . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7
5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8
6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13
7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 15 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 14
8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 16 8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 15
8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 16 8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 15
8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 17 8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 16
8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 18 8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 16
8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 18 8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 17
8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 18 8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 18
8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 19 8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 19
8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 21 8.4. Aborting an ongoing file transfer operation . . . . . . . 21
8.4. Indicating File Transfer Offer/Answer Capability . . . . . 23 8.5. Indicating File Transfer Offer/Answer Capability . . . . . 22
8.5. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 23 8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 22
8.6. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23 8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23
8.7. Considerations about the 'file-icon' attribute . . . . . . 25 8.8. Considerations about the 'file-icon' attribute . . . . . . 24
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 25 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 25
9.2. Offerer requests a file from the Answerer and second 9.2. Offerer requests a file from the Answerer and second
file transfer . . . . . . . . . . . . . . . . . . . . . . 30 file transfer . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Example of a capability indication . . . . . . . . . . . . 37 9.3. Example of a capability indication . . . . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. Registration of new SDP attributes . . . . . . . . . . . . 39 11.1. Registration of new SDP attributes . . . . . . . . . . . . 39
11.1.1. Registration of the file-selector attribute . . . . . 39 11.1.1. Registration of the file-selector attribute . . . . . 39
11.1.2. Registration of the file-transfer-id attribute . . . . 40 11.1.2. Registration of the file-transfer-id attribute . . . . 40
11.1.3. Registration of the file-disposition attribute . . . . 40 11.1.3. Registration of the file-disposition attribute . . . . 40
11.1.4. Registration of the file-date attribute . . . . . . . 40 11.1.4. Registration of the file-date attribute . . . . . . . 40
11.1.5. Registration of the file-icon attribute . . . . . . . 41 11.1.5. Registration of the file-icon attribute . . . . . . . 41
11.1.6. Registration of the file-range attribute . . . . . . . 41 11.1.6. Registration of the file-range attribute . . . . . . . 41
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
13.2. Informational References . . . . . . . . . . . . . . . . . 42 13.2. Informational References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 46
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.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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 is 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.
1.1. Alternatives Considered
The requirements are related to the description and negotiation of
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
extensions and usage conventions to SDP, while MSRP itself needs no
extensions and can be used as it is. This is effectively the
approach taken in this specification. Another goal has been to
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
endpoint in a file transfer session, albeit with a somewhat reduced
functionality.
In some ways the aim of this specification is similar to the aim of
content indirection mechanism in the Session Initiation Protocol
(SIP) [RFC4483]. Both mechanisms allow a user agent to decide
whether or not to download a file based on information about the
file. However, there are some differences. With content
indirection, it is not possible for the other endpoint to explicitly
accept or reject the file transfer. Also, it is not possible for an
endpoint to request a file from another endpoint. Furthermore,
content indirection is not tied to the context of a media session,
which is sometimes a desirable property. Finally, content
indirection typically requires some server infrastructure, which may
not always be available. It is possible to use content indirection
directly between the endpoints too, but in that case there is no
definition for how it works for endpoints behind NATs. The level of
requirements in implementations decides which solution meets the
requirements.
Based on the argumentation above, this document defines the SDP
attribute extensions and usage conventions needed for meeting the
requirements on file transfer services with the SDP offer/answer
model, using MSRP as the transfer protocol within the session.
In principle it is possible to use the SDP extensions defined here
and replace MSRP with any other similar protocol that can carry
MIME objects. This kind of specification can be written as a
separate document if the need arises. Essentially, such protocol
should be able to be negotiated on an SDP offer/answer exchange
(RFC 3264 [RFC3264]), be able to carry MIME objects between two
endpoints, and use a reliable transport protocol (e.g., TCP).
This specification defines a set of SDP attributes that describe a
file to be transferred between two endpoints. The information needed
to describe a file could be potentially encoded in a few different
ways. The MMUSIC working group considered a few alternative
approaches before deciding to use the encoding described in
Section 6. In particular, the working group looked at the MIME
'external-body' type and the use of a single SDP attribute or
parameter.
A MIME 'external-body' could potentially be used to describe the file
to be transferred. In fact, many of the SDP parameters this
specification defines are also supported by 'external-body' body
parts. The MMUSIC working group decided not to use 'external-body'
body parts because a number of existing offer/answer implementations
do not support multipart bodies.
The information carried in the SDP attributes defined in Section 6
could potentially be encoded in a single SDP attribute. The MMUSIC
working group decided not to follow this approach because it is
expected that implementations support only a subset of the parameters
defined in Section 6. Those implementations will be able to use
regular SDP rules in order to ignore non-supported SDP parameters.
If all the information was encoded in a single SDP attribute, those
rules, which relate to backwards compatibility, would need to be
redefined specifically for that parameter.
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].
3. Definitions 3. Definitions
For the purpose of this document, the following definitions specified For the purpose of this document, the following definitions specified
skipping to change at page 8, line 22 skipping to change at page 6, line 45
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 of 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 special case where that endpoint is the defined herein, in a particular case where that endpoint is both
recipient of the file. The regular MSRP endpoint answers the the SDP answerer and the file receiver. The regular MSRP endpoint
offer as it would answer any ordinary MSRP offer without paying answers the offer as it would answer any ordinary MSRP offer
attention to the extension attributes. In such a scenario the without paying attention to the extension attributes. In such a
user experience would however be reduced, as the recipient would scenario the user experience would, however, be reduced, since the
not know (by any protocol means) the reason for the session and recipient would not know (by any protocol means) the reason for
would not be able to accept/reject it based on the file the session and would not be able to accept/reject it based on the
attributes. file attributes.
5. File selector 5. File selector
Specially in case the SDP offer is generated by the file receiver, When the SDP offerer is the file the offer needs to unambiguously
the offer needs a mechanism to unambiguously identify the requested identify the requested file. For this purpose we introduce the
file. For this purpose, the file transfer mechanism introduces the notion of a file selector, which is a tuple composed of one or more
notion of a file selector, which is defined as the combination of the of the following individual selectors: the name, size, type, and hash
4-tuple composed of the name, size, type, and hash of the file. We of the file. The file selector can include any number of selectors,
call each of these individual items a selector. The file selector so all four of them do not always need to be present.
can be composed of any number of selectors, so, it does not require
that all four selectors are present at the same time.
The purpose of the file selector is to provide enough information The purpose of the file selector is to provide enough information
that characterizes a file to the remote entity, so that both the about the file to the remote entity, so that both the local and the
local and the remote entity can refer to the same file. The file remote entity can refer to the same file. The file selector is
selector is encoded in a 'file-selector' media attribute in SDP. The encoded in a 'file-selector' media attribute in SDP. The formal
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 file that match each of the
4-tuple selectors present in the 'file-selector' attribute. Thus, a selectors present in the 'file-selector' attribute. The result can
file selector can point to zero, one, or more files, depending on the be zero, one, or more files, depending on the presence of the
presence of the mentioned selectors in the SDP and depending on the mentioned selectors in the SDP and depending on the available files
available files in a host. The file transfer mechanism specified in in a host. The file transfer mechanism specified in this document
this document requires that a file selector eventually results at requires that a file selector eventually results at most in a single
most in a single file to be chosen. Typically, if the hash selector file to be chosen. Typically, if the hash selector is known, it is
is known, it is enough to produce a file selector that points to enough to produce a file selector that points to exactly zero or one
exactly zero or one file. However, a file selector that selects a file. However, a file selector that selects a unique file is not
unique file is not always known by the offerer. Sometimes only the always known by the offerer. Sometimes only the name, size or type
name, size or type of file are known, so the file selector may result of file are known, so the file selector may result in selecting more
in selecting more than one file, which is an undesired case. The than one file, which is an undesired case. The opposite is also
opposite is also true: if the file selector contains a hash selector true: if the file selector contains a hash selector and a name
and a name selector, there is a risk that the remote host has renamed selector, there is a risk that the remote host has renamed the file,
the file, in which case, although a file whose computed hash equals in which case, although a file whose computed hash equals the hash
the hash selector exists, the file name does not match that of the selector exists, the file name does not match that of the name
name selector, thus, the file selection process will result in the selector, thus, the file selection process will result in the
selection of zero files. 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.4. 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 [RFC4234] 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 2822 [RFC2822]. [RFC2183], RFC 2392 [RFC2392], and RFC 2822 [RFC2822].
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 4234 ; DQUOTE defined in RFC 5234
filename-string = 1*(filename-char/percent-encoded) filename-string = 1*(filename-char/percent-encoded)
filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%26-FF) filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%26-FF)
;any byte except NUL, CR, LF, ;any byte except NUL, CR, LF,
;double quotes, or percent ;double quotes, or percent
percent-encoded = "%" HEXDIG HEXDIG percent-encoded = "%" HEXDIG HEXDIG
; HEXDIG defined in RFC 4234 ; HEXDIG defined in RFC 5234
filesize-selector = "size:" filesize-value filesize-selector = "size:" filesize-value
filesize-value = integer ;integer defined in RFC 4566 filesize-value = integer ;integer defined in RFC 4566
filetype-selector = "type:" type "/" subtype *(";"parameter) filetype-selector = "type:" type "/" subtype *(";"parameter)
; parameter defined in RFC 2045 ; parameter defined in RFC 2045
type = token ; token defined in RFC 4566 type = token ; token defined in RFC 4566
subtype = token subtype = token
hash-selector = "hash:" hash-algorithm ":" hash-value hash-selector = "hash:" hash-algorithm ":" hash-value
hash-algorithm = token ;see IANA Hash Function hash-algorithm = token ;see IANA Hash Function
;Textual Names registry ;Textual Names registry
;only "sha-1" currently supported ;only "sha-1" currently supported
hash-value = 2HEXDIG *(":" 2HEXDIG) hash-value = 2HEXDIG *(":" 2HEXDIG)
; Each byte in upper-case hex, separated ; Each byte in upper-case hex, separated
; by colons. ; by colons.
; HEXDIG defined in RFC 4234 ; HEXDIG defined in RFC 5234
file-tr-id-attr = "file-transfer-id:" file-tr-id-value file-tr-id-attr = "file-transfer-id:" file-tr-id-value
file-tr-id-value = token file-tr-id-value = token
file-disp-attr = "file-disposition:" file-disp-value file-disp-attr = "file-disposition:" file-disp-value
file-disp-value = token file-disp-value = token
file-date-attr = "file-date:" date-param *(SP date-param) file-date-attr = "file-date:" date-param *(SP date-param)
date-param = c-date-param / m-date-param / r-date-param date-param = c-date-param / m-date-param / r-date-param
c-date-param = "creation:" DQUOTE date-time DQUOTE c-date-param = "creation:" DQUOTE date-time DQUOTE
m-date-param = "modification:" DQUOTE date-time DQUOTE m-date-param = "modification:" DQUOTE date-time DQUOTE
r-date-param = "read:" DQUOTE date-time DQUOTE r-date-param = "read:" DQUOTE date-time DQUOTE
; date-time is defined in RFC 2822 ; date-time is defined in RFC 2822
; numeric timezones (+HHMM or -HHMM) ; numeric timezones (+HHMM or -HHMM)
; must be used ; must be used
; DQUOTE defined in RFC 4234 files. ; DQUOTE defined in RFC 5234 files.
file-icon-attr = "file-icon:" file-icon-value file-icon-attr = "file-icon:" file-icon-value
file-icon-value = cid-url ;cid-url defined in RFC 2392 file-icon-value = cid-url ;cid-url defined in RFC 2392
file-range-attr = "file-range:" start-offset "-" stop-offset file-range-attr = "file-range:" start-offset "-" stop-offset
start-offset = integer ;integer defined in RFC 4566 start-offset = integer ;integer defined in RFC 4566
stop-offset = integer / "*" stop-offset = integer / "*"
Figure 1: Syntax of the SDP extension Figure 1: Syntax of the SDP extension
When used for capability query (see Section 8.4), the 'file-selector' When used for capability query (see Section 8.5), the 'file-selector'
attribute MUST NOT contain any selector, because its presence merely attribute MUST NOT contain any selector, because its presence merely
indicates compliance to this specification. indicates compliance to this specification.
When used in an SDP offer or answer, the 'file-selector' attribute When used in an SDP offer or answer, the 'file-selector' attribute
MUST contain at least one selector. Selectors characterize the file MUST contain at least one selector. Selectors characterize the file
to be transferred. There are four selectors in this attribute: to be transferred. There are four selectors in this attribute:
'name', 'size', 'type', and 'hash'. 'name', 'size', 'type', and 'hash'.
The 'name' selector in the 'file-selector' attribute contains the The 'name' selector in the 'file-selector' attribute contains the
filename of the content enclosed in double quotes. The filename is filename of the content enclosed in double quotes. The filename is
skipping to change at page 12, line 45 skipping to change at page 11, line 20
can be drafted to support several hashing algorithms. Therefore, can be drafted to support several hashing algorithms. Therefore,
implementations according to this specification MUST be prepared to implementations according to this specification MUST be prepared to
receive SDP containing more than a single 'hash' selector in the receive SDP containing more than a single 'hash' selector in the
'file-selector' attribute. 'file-selector' attribute.
The value of the 'hash' selector is the byte string resulting of The value of the 'hash' selector is the byte string resulting of
applying the hash algorithm to the content of the whole file, even applying the hash algorithm to the content of the whole file, even
when the file transfer is limited to a number of octets (i.e., the when the file transfer is limited to a number of octets (i.e., the
'file-range' attribute is indicated). 'file-range' attribute is indicated).
The 'file-transfer-id' attribute provides a unique identification to The 'file-transfer-id' attribute provides a randomly chosen globally
the actual file transfer. It is used to distinguish a new file unique identification to the actual file transfer. It is used to
transfer request from a repetition of the SDP (or the fraction of the distinguish a new file transfer request from a repetition of the SDP
SDP that deals with the file description). This attribute is (or the fraction of the SDP that deals with the file description).
described in much greater detail in Section 8.3. This attribute is described in much greater detail in Section 8.3.
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 at which the file was
created, modified, or last read. This attribute MAY contain a created, modified, or last read. This attribute MAY contain a
skipping to change at page 13, line 47 skipping to change at page 12, line 21
'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.7 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 enable use cases where a
file transfer can be interrupted, resumed, even perhaps changing one file transfer can be interrupted, resumed, even perhaps changing one
of the endpoints. The 'file-range' attribute contains the "start of the endpoints. The 'file-range' attribute contains the "start
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 position of the file where the "start offset" value refers to the position of the file where the
file transfer should start. The first byte of a file is denoted by file transfer should start. The first byte of a file is denoted by
the ordinal number "1". The "stop offset" value refers position of the ordinal number "1". The "stop offset" value refers position of
skipping to change at page 15, line 48 skipping to change at page 14, line 23
"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
that their display should not be automatic, but contingent upon that their display should not be automatic, but contingent upon
some further action of the user." some further action of the user."
In the case of this specification, the 'attachment' disposition In the case of this specification, the 'attachment' disposition
type is used to indicate that the display of the file should not type is used to indicate that the display of the file should not
be automatic, but contingent upon some further action of the user. be automatic, but contingent upon some further action of the user.
8. Protocol Operation 8. Protocol Operation
This Section discusses how to use the parameters defined in Section 6 This section discusses how to use the parameters defined in Section 6
in the context of an offer/answer [RFC3264] exchange. Additionally, in the context of an offer/answer [RFC3264] exchange. Additionally,
this section also discusses the behavior of the endpoints using MSRP. this section also discusses the behavior of the endpoints using MSRP.
Usually the file transfer session is initiated when the offerer sends A file transfer session is initiated by the offerer sending an SDP
an SDP offer to the answerer. The answerer either accepts or rejects offer to the answerer. The answerer either accepts or rejects the
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 the
file sender. In this case the SDP offer contains a session or file sender. In this case the SDP offer contains a session or
media 'recvonly' attribute, and accordingly the SDP answer media 'recvonly' attribute, and accordingly the SDP answer
contains a session or media 'sendonly' attribute. contains a session or media 'sendonly' attribute.
8.1. Offerer's Behavior 8.1. Offerer's Behavior
An offerer that wishes to send or receive one or more files to or An offerer who wishes to send or receive one or more files to or from
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 or more "m=" lines, each one describing an MSRP containing one "m=" line per file. When MSRP is used as the transfer
session (and thus, one file transfer operation), according to the mechanism, each "m=" line also describes a single MSRP session,
MSRP [RFC4975] procedures. All the media line attributes specified according to the MSRP [RFC4975] procedures. Any "m=" lines that may
and required by MSRP [RFC4975] (e.g., "a=path", "a=accept-types", have already been present in a previous SDP exchange are normally
etc.) MUST be included as well. For each file to be transferred kept unmodified; the new "m=" lines are added afterwards (Section 8.6
there MUST be a separate "m=" line. describes cases when "m=" lines are re-used). All the media line
attributes specified and required by MSRP [RFC4975] (e.g., "a=path",
"a=accept-types", etc.) MUST be included as well.
8.1.1. The Offerer is a File Sender 8.1.1. The Offerer is a File Sender
In a push operation, the file sender creates and SDP offer describing In a push operation, the file sender creates and SDP offer describing
the file to be sent. The file sender MUST add a 'file-selector' the file to be sent. The file sender MUST add a 'file-selector'
attribute media line containing at least one of the 'type', 'size', attribute media line containing at least one of the 'type', 'size',
'hash' selectors in indicating the type, size, or hash of the file, 'hash' selectors in indicating the type, size, or hash of the file,
respectively. The file sender MUST add a 'file-transfer-id' respectively. If the file sender wishes to start a new file
attribute containing a new randomly chosen identifier value, which transfer, the file sender MUST add a 'file-transfer-id' attribute
does not clash with other previously used values in the same containing a new globally unique random identifier value.
attribute. Additionally, the file sender MUST add a session or media Additionally, the file sender MUST add a session or media 'sendonly'
'sendonly' attribute to the SDP offer. Then the file sender sends attribute to the SDP offer. Then the file sender sends the SDP offer
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 to the file receiver to identify whether the
file is already available and need not be transmitted. file is already available and need not be transmitted.
The file sender MAY also add a 'name' selector in the 'file-selector' The file sender MAY also add a 'name' selector in the 'file-selector'
skipping to change at page 17, line 33 skipping to change at page 16, line 4
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.1.2. The Offerer is a File Receiver 8.1.2. The Offerer is a File Receiver
In a pull operation, the file receiver creates the SDP offer and In a pull operation, the file receiver creates the SDP offer and
sends it to the file sender. The file receiver MUST include a 'file- sends it to the file sender. The file receiver MUST include a 'file-
selector' attribute and SHOULD add, at least, one of the selector selector' attribute and SHOULD add, at least, one of the selector
defined for that attribute (i.e., 'name', 'type', 'size', or 'hash'). defined for that 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, specially in cases where the hash of the file is
unknown, the file name, size, and type can provide a description of unknown, the file name, size, and type can provide a description of
the file to be fetched. The file receiver MUST also add a 'file- the file to be fetched. If the file receiver wishes to start a new
transfer-id' attribute with a newly created random value (new within file transfer it MUST add a 'file-transfer-id' attribute containing a
the current session). The file receiver MAY also add a 'file-range' new globally unique random value. The file receiver MAY also add a
attribute indicating the start and stop offsets of the file. There 'file-range' attribute indicating the start and stop offsets of the
is no need to for the file receiver to include further file file. There is no need to for the file receiver to include further
attributes in the SDP offer, thus it is RECOMMENDED that SDP offerers file attributes in the SDP offer, thus it is RECOMMENDED that SDP
do not include any other file attribute defined by this specification offerers do not include any other file attribute defined by this
(other than the mandatory ones). Additionally, the file receiver specification (other than the mandatory ones). Additionally, the
MUST create an SDP offer that contains a session or media 'recvonly' file receiver MUST create an SDP offer that contains a session or
attribute. media 'recvonly' attribute.
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= line. should receive the file using the protocol indicated in the "m="
If the SDP answer contains a supported hashing algorithm in the line. If the SDP answer contains a supported hashing algorithm in
'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
SHOULD inform the user. SHOULD inform the user.
8.1.3. SDP Offer for Several Files 8.1.3. SDP Offer for Several Files
An offerer that wishes to send or receive more than one file An offerer that wishes to send or receive more than one file
generates an "m=" line per file along with the file attributes generates an "m=" line per file along with the file attributes
skipping to change at page 18, line 40 skipping to change at page 17, line 12
zero, as per regular SDP [RFC4566] procedures. The rejected answer zero, as per regular SDP [RFC4566] procedures. The rejected answer
MUST contained a 'file-selector' and 'file-transfer-id' attributes MUST contained a 'file-selector' and 'file-transfer-id' attributes
whose values mirror the corresponding values of the SDP offer. whose values mirror the corresponding values of the SDP offer.
If the answerer decides to accept the file, it proceeds as per If the answerer decides to accept the file, it proceeds as per
regular MSRP [RFC4975] and SDP [RFC4566] procedures. regular MSRP [RFC4975] and SDP [RFC4566] procedures.
8.2.1. The Answerer is a File Receiver 8.2.1. The Answerer is a File Receiver
In a push operation the SDP answerer is the file receiver. When the In a push operation the SDP answerer is the file receiver. When the
file receiver gets the SDP offer, it first examines the 'file- file receiver gets the SDP offer, it first examines the port number.
transfer-id' attribute. If the value of the 'file-transfer-id' If the port number is set to zero, the file transfer operation is
attribute has been previously used then the existing session remains closed, and no more data is expected over the media stream. Then, if
without changes, perhaps the file transfer is still in progress, or the port number is different than zero, the file receiver inspects
perhaps it has concluded, but there are no change with respect the the 'file-transfer-id' attribute. If the value of the 'file-
current status. The SDP answerer creates a regular SDP answer and transfer-id' attribute has been previously used then the existing
sends it to the offerer. session remains without changes, perhaps the file transfer is still
in progress, or perhaps it has concluded, but there are no change
with respect the current status. In any case, independently of the
port number, the SDP answerer creates a regular SDP answer and sends
it to the offerer.
If the SDP offer contains a new 'file-transfer-id' attribute, then If the port number is different than zero and the SDP offer contains
this signals a request for a new file transfer. The SDP answerer a new 'file-transfer-id' attribute, then this signals a request for a
extracts the attributes and parameters that describe the file and new file transfer. The SDP answerer extracts the attributes and
typically requests permission from the user to accept or reject the parameters that describe the file and typically requests permission
reception of the file. If the file transfer operation is accepted, from the user to accept or reject the reception of the file. If the
the file receiver MUST create an SDP answer according to the file transfer operation is accepted, the file receiver MUST create an
procedures specified in RFC 3264 [RFC3264]. If the offer contains SDP answer according to the procedures specified in RFC 3264
'name', 'type', 'size' selectors in the 'file-selector' attribute, [RFC3264]. If the offer contains 'name', 'type', 'size' selectors in
the answerer MUST copy them into the answer. The file receiver the 'file-selector' attribute, the answerer MUST copy them into the
copies the value of the 'file-transfer-id' attribute to the SDP answer. The file receiver copies the value of the 'file-transfer-id'
answer. Then the file receiver MUST add a session or media attribute to the SDP answer. Then the file receiver MUST add a
'recvonly' attribute according to the procedures specified in RFC session or media 'recvonly' attribute according to the procedures
3264 [RFC3264]. The file receiver MUST NOT include 'file-icon', specified in RFC 3264 [RFC3264]. The file receiver MUST NOT include
'file-disposition', or 'file-date' attributes in the SDP answer. 'file-icon', 'file-disposition', or 'file-date' attributes in the SDP
answer.
The file receiver can use the hash to find out if a local file with The file receiver can use the hash to find out if a local file with
the same hash is already available, in which case, this could imply the same hash is already available, in which case, this could imply
the reception of a duplicated file. It is up to the answerer to the reception of a duplicated file. It is up to the answerer to
determine whether the file transfer is accepted or not in case of a determine whether the file transfer is accepted or not in case of a
duplicated file. duplicated file.
If the SDP offer contains a 'file-range' attribute and the file If the SDP offer contains a 'file-range' attribute and the file
receiver accepts to receive the range of bytes declared in there, the receiver accepts to receive the range of bytes declared in there, the
file receiver MUST include a 'file-range' attribute in the SDP answer file receiver MUST include a 'file-range' attribute in the SDP answer
skipping to change at page 21, line 38 skipping to change at page 20, line 14
the current ongoing file transfer and add the new media descriptions. the current ongoing file transfer and add the new media descriptions.
The problem is that, the other endpoint is not able to determine if a The problem is that, the other endpoint is not able to determine if a
new file transfer is requested or not. new file transfer is requested or not.
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 re-sends 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 a new file transfer should start or not.
To address these scenarios this specification defines the 'file- To address these scenarios this specification defines the 'file-
transfer-id' attribute which contains a unique file transfer transfer-id' attribute which contains a globally unique random
identifier. The file transfer identifier helps both endpoints to identifier allocated to the file transfer operation. The file
determine whether the SDP offer is requesting a new file transfer or transfer identifier helps both endpoints to determine whether the SDP
it is a repetition of the SDP. A new file transfer is one that, in offer is requesting a new file transfer or it is a repetition of the
case of acceptance, will provoke the actual transfer of a file. This SDP. A new file transfer is one that, in case of acceptance, will
is typically the case of new offer/answer exchanges, or in cases provoke the actual transfer of a file. This is typically the case of
where an endpoint wants to abort the existing file transfer and re- new offer/answer exchanges, or in cases where an endpoint wants to
start the file transfer once more. On the other hand, the repetition abort the existing file transfer and re-start the file transfer once
of the SDP does not lead to any actual file to be transferred, more. On the other hand, the repetition of the SDP does not lead to
potentially because the file transfer is still going on or because it any actual file to be transferred, potentially because the file
has already finished. This is the case of a repeated offer/answer transfer is still going on or because it has already finished. This
exchanges, which can be due to a number of reasons (session timer, is the case of a repeated offer/answer exchanges, which can be due to
addition/removal of other media types in the SDP, update in SDP due a number of reasons (session timer, addition/removal of other media
to changes in other session parameters, etc.). types in the SDP, update in SDP due to changes in other session
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
MUST select a file transfer identifier according to the syntax and MUST select a file transfer identifier according to the syntax and
add it to the 'file-transfer-id' attribute. The SDP answerer MUST add it to the 'file-transfer-id' attribute. The SDP answerer MUST
copy the value of the 'file-transfer-id' attribute in the SDP answer. copy the value of the 'file-transfer-id' attribute in the SDP answer.
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
skipping to change at page 22, line 26 skipping to change at page 20, line 51
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 should mirror the value of transfer operation, then the SDP answer MUST mirror the value of the
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' initial one except for the value of the 'file-transfer-id' attribute,
attribute, which is a new value within the session. This indicates which is a new globally unique random value. This indicates that the
that the offerer wants to abort the existing transfer and start a new offerer wants to abort the existing transfer and start a new one,
one, according to the SDP parameters. The SDP answerer SHOULD abort according to the SDP parameters. The SDP answerer SHOULD abort the
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. the initial requested octet. Section 8.4 further discusses file
transfer abortion.
In another scenario, an endpoint that has successfully transferred a In another scenario, an endpoint that has successfully transferred a
file wants to send an SDP due to other reasons than the transfer of a file wants to send an SDP due to other reasons than the transfer of a
file. The SDP offerer creates an SDP file description that maintains file. The SDP offerer creates an SDP file description that maintains
the media description line corresponding to the file transfer. The the media description line corresponding to the file transfer. The
SDP offerer MUST then set the port number to zero and MUST keep the SDP offerer MUST then set the port number to zero and MUST keep the
same value of the 'file-transfer-id' attribute that the initial file same value of the 'file-transfer-id' attribute that the initial file
transfer got. transfer got.
8.4. Indicating File Transfer Offer/Answer Capability 8.4. Aborting an ongoing file transfer operation
A file sender that wishes to abort an ongoing file transfer operation
without initiating an alternative file transfer, if an ongoing MSRP
SEND request is being transmitted, aborts the MSRP message by
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 RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP
message, aborting the MSRP message effectively aborts the file
transfer. Then the file sender SHOULD close the MSRP session. This
is done by sending a new 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 [RFC3264]). This SDP offer MUST conform with
the requirements of Section 8.1.1. The 'file-transfer-id' attribute
MUST be the same that identifies the ongoing transfer. Then the file
sender sends the SDP offer to the file recipient.
A file receiver that receives the above SDP offer creates an SDP
answer according to the procedures of the SDP offer/answer (RFC 3264
[RFC3264]). This SDP answer MUST conform with the requirements of
Section 8.2.1. Then the file recipient sends this SDP answer to the
file sender.
A file receiver that wishes to abort an ongoing transfer first must
determine if the MSRP sender wishes to receive failure reports. If
the current MSRP SEND request sets the Failure-Report header to a
value different than "no", then the file receiver generates an MSRP
413 response to the current MSRP SEND request (see Section 10.5 of
RFC 4975 [RFC4975]). Then the file receiver SHOULD close the MSRP
session. This is done by sending a new 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 [RFC3264]). This SDP offer
MUST conform with the requirements expressed in Section 8.1.2. The
'file-transfer-id' attribute MUST be the same that identifies the
ongoing transfer. Then the file sender sends the SDP offer to the
file receiver.
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
MSRP SEND request is being transmitted, it aborts the MSRP message by
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 RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP
message, aborting the MSRP message effectively aborts the file
transfer. Then the file sender creates an SDP answer according to
the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This
SDP answer MUST conform with the requirements of Section 8.2.2. Then
the file sender sends this SDP answer to the file receiver.
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 request. As such, RFC 3264 that is included in the response to such request. As such, RFC 3264
indicates that and endpoint builds an SDP body that contains an "m=" indicates that and endpoint builds an SDP body that contains an "m="
line that contains the media type (message, for MSRP). An endpoint line that contains the media type (message, for MSRP). An endpoint
that implements the procedures specified in this document SHOULD also that implements the procedures specified in this document SHOULD also
add a 'file-selector' media attribute for the "m=message" line. The add a 'file-selector' media attribute for the "m=message" line. The
'file-selector' media attribute MUST be empty, i.e., it MUST NOT 'file-selector' media attribute MUST be empty, i.e., it MUST NOT
contain any selector. The endpoint MUST NOT add any of the other contain any selector. The endpoint MUST NOT add any of the other
file attributes defined in this specification. file attributes defined in this specification.
8.5. Re-usage of Existing m= Lines in SDP 8.6. Re-usage 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., re-use
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 re-use an
existing m= line to start the file transfer of another file creates a existing "m=" line to start the file transfer of another file creates
different 'file-selector' attribute and a different value of the a different 'file-selector' attribute and selects a new globally
'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 re-sends 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 byte (if a 'file-range' attribute is starts from the indicated byte (if a 'file-range' attribute is
present). present).
8.6. 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
to describe the unidirectional transfer of a file. Consequently, to describe the unidirectional transfer of a file. Consequently,
each MSRP session established following the procedures in Section 8.1 each MSRP session established following the procedures in Section 8.1
and Section 8.2 is only used to transfer a single file. So, senders and Section 8.2 is only used to transfer a single file. So, senders
MUST only use the dedicated MSRP session to send the file described MUST only use the dedicated MSRP session to send the file described
in the SDP offer or answer. That is, senders MUST NOT send in the SDP offer or answer. That is, senders MUST NOT send
additional files over the same MSRP session. additional files over the same MSRP session.
File transfer may be accomplished using a new multimedia session File transfer may be accomplished using a new multimedia session
skipping to change at page 24, line 32 skipping to change at page 24, line 12
that MSRP does not require to wait for a 200-class response for a that MSRP does not require to wait for a 200-class response for a
chunk before sending the following one. Therefore, it is valid to chunk before sending the following one. Therefore, it is valid to
send pipelined MSRP SEND requests containing chunks of the same MSRP send pipelined MSRP SEND requests containing chunks of the same MSRP
message (the file). Section 9.1 contains an example of a file message (the file). Section 9.1 contains an example of a file
transfer using pipelined MSRP requests. 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.
In the absence of a 'file-range' attribute in the SDP, the MSRP file In the absence of a 'file-range' attribute in the SDP, the MSRP file
transfer MUST start with the first byte of the file and end with the transfer MUST start with the first byte of the file and end with the
last byte (i.e., the whole file is transferred). If a 'file-range' last byte (i.e., the whole file is transferred). If a 'file-range'
attribute is present in SDP, the file sender application MUST extract attribute is present in SDP, the file sender application MUST extract
the indicated range of bytes from the file (start and stop offset the indicated range of bytes from the file (start and stop offset
bytes). Then the file sender application MAY wrap those bytes in an bytes). Then the file sender application MAY wrap those bytes in an
skipping to change at page 25, line 8 skipping to change at page 24, line 36
sender application delivers the content (e.g., the message/cpim body) sender application delivers the content (e.g., the message/cpim body)
to MSRP for transportation. MSRP will consider the delivered content to MSRP for transportation. MSRP will consider the delivered content
as a whole message, and will start numbering bytes with the number 1. as a whole message, and will start numbering bytes with the number 1.
Note that the default content disposition of MSRP bodies is 'render'. Note that the default content disposition of MSRP bodies is 'render'.
When MSRP is used to transfer files, the MSRP Content-Disposition When MSRP is used to transfer files, the MSRP Content-Disposition
header can also take the value 'attachment' as indicated in header can also take the value 'attachment' as indicated in
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 closing MSRP sessions. procedures with respect closing MSRP sessions. Note that MSRP
session management is not related to TCP connection management. As a
matter of fact, MSRP allows multiple MSRP sessions to share the same
TCP connection.
8.7. 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 CID URL
[RFC2392] that points to an additional body that contains the actual [RFC2392] that points to an additional body that contains the actual
icon. Since the icon is sent as a separate body along the SDP body, icon. Since the icon is sent as a separate body along the SDP body,
the file sender MUST wrap the SDP body and the icon bodies in a MIME the file sender MUST wrap the SDP body and the icon bodies in a MIME
multipart/related body. Therefore, implementations according to this multipart/related body. Therefore, implementations according to this
specification MUST implement the multipart/related MIME type specification MUST implement the multipart/related MIME type
[RFC2387]. When creating a multipart/related MIME wrapper, the SDP [RFC2387]. When creating a multipart/related MIME wrapper, the SDP
body MUST be the root body, which according to RFC 2387 [RFC2387] is body MUST be the root body, which according to RFC 2387 [RFC2387] is
skipping to change at page 39, line 28 skipping to change at page 39, line 28
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 Once a file has been transferred the file receiver must take care
with it. Typically file transfer is a commonly used mechanism for with 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 recipients should apply all possible security technologies File receivers should apply all possible security technologies (e.g.,
(e.g., antivirus, antispaware, etc.) to dismiss the risk of damage at antivirus, antispaware, etc.) to dismiss the risk of damage at their
their host. host.
11. IANA Considerations 11. IANA Considerations
This document instructs IANA to register a number of SDP attributes This document instructs IANA to register a number of SDP attributes
according to the following: according to the following:
11.1. Registration of new SDP attributes 11.1. Registration of new SDP attributes
This memo provides instructions to IANA to register a number of media This memo provides instructions to IANA to register a number of media
level only attributes in the Session Description Protocol Parameters level only attributes in the Session Description Protocol Parameters
skipping to change at page 41, line 38 skipping to change at page 41, line 38
Specification: RFC XXXX Specification: RFC XXXX
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Mats Stille, Nancy Greene, Adamu The authors would like to thank Mats Stille, Nancy Greene, Adamu
Haruna, and Arto Leppisaari for discussing initial concepts described Haruna, and Arto Leppisaari for discussing initial concepts described
in this memo. Thanks to Pekka Kuure for reviewing initial versions in this memo. Thanks to Pekka Kuure for reviewing initial versions
this document and providing helpful comments. Joerg Ott, Jiwey Wang, this document and providing helpful comments. Joerg Ott, Jiwey Wang,
Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis-
Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan
Rosenberg, and Eric Rescorla discussed and provided comments and Rosenberg, Eric Rescorla, and Vikram Chhibber discussed and provided
improvements to this document. comments and 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
skipping to change at page 42, line 35 skipping to change at page 42, line 35
[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.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[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
Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informational References 13.2. Informational 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.
skipping to change at page 43, line 28 skipping to change at page 43, line 28
URIs URIs
[1] <http://www.iana.org/assignments/media-types/> [1] <http://www.iana.org/assignments/media-types/>
[2] <http://www.iana.org/assignments/hash-function-text-names> [2] <http://www.iana.org/assignments/hash-function-text-names>
[3] <http://www.iana.org/assignments/mail-cont-disp> [3] <http://www.iana.org/assignments/mail-cont-disp>
[4] <http://www.iana.org/assignments/sdp-parameters> [4] <http://www.iana.org/assignments/sdp-parameters>
Appendix A. Alternatives Considered
The requirements are related to the description and negotiation of
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
extensions and usage conventions to SDP, while MSRP itself needs no
extensions and can be used as it is. This is effectively the
approach taken in this specification. Another goal has been to
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
endpoint in a file transfer session, albeit with a somewhat reduced
functionality.
In some ways the aim of this specification is similar to the aim of
content indirection mechanism in the Session Initiation Protocol
(SIP) [RFC4483]. Both mechanisms allow a user agent to decide
whether or not to download a file based on information about the
file. However, there are some differences. With content
indirection, it is not possible for the other endpoint to explicitly
accept or reject the file transfer. Also, it is not possible for an
endpoint to request a file from another endpoint. Furthermore,
content indirection is not tied to the context of a media session,
which is sometimes a desirable property. Finally, content
indirection typically requires some server infrastructure, which may
not always be available. It is possible to use content indirection
directly between the endpoints too, but in that case there is no
definition for how it works for endpoints behind NATs. The level of
requirements in implementations decides which solution meets the
requirements.
Based on the argumentation above, this document defines the SDP
attribute extensions and usage conventions needed for meeting the
requirements on file transfer services with the SDP offer/answer
model, using MSRP as the transfer protocol within the session.
In principle it is possible to use the SDP extensions defined here
and replace MSRP with any other similar protocol that can carry
MIME objects. This kind of specification can be written as a
separate document if the need arises. Essentially, such protocol
should be able to be negotiated on an SDP offer/answer exchange
(RFC 3264 [RFC3264]), be able to describe the file to be
transferred in SDP offer/answer exchange, be able to carry MIME
objects between two endpoints, and use a reliable transport
protocol (e.g., TCP).
This specification defines a set of SDP attributes that describe a
file to be transferred between two endpoints. The information needed
to describe a file could be potentially encoded in a few different
ways. The MMUSIC working group considered a few alternative
approaches before deciding to use the encoding described in
Section 6. In particular, the working group looked at the MIME
'external-body' type and the use of a single SDP attribute or
parameter.
A MIME 'external-body' could potentially be used to describe the file
to be transferred. In fact, many of the SDP parameters this
specification defines are also supported by 'external-body' body
parts. The MMUSIC working group decided not to use 'external-body'
body parts because a number of existing offer/answer implementations
do not support multipart bodies.
The information carried in the SDP attributes defined in Section 6
could potentially be encoded in a single SDP attribute. The MMUSIC
working group decided not to follow this approach because it is
expected that implementations support only a subset of the parameters
defined in Section 6. Those implementations will be able to use
regular SDP rules in order to ignore non-supported SDP parameters.
If all the information was encoded in a single SDP attribute, those
rules, which relate to backwards compatibility, would need to be
redefined specifically for that parameter.
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Nokia Siemens Networks Nokia Siemens Networks
P.O.Box 6 P.O.Box 6
Nokia Siemens Networks, FIN 02022 Nokia Siemens Networks, FIN 02022
Finland Finland
Phone: +358-71400-4000 Phone: +358-71400-4000
Email: miguel.garcia@nsn.com Email: miguel.garcia@nsn.com
skipping to change at page 45, line 7 skipping to change at page 46, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 45, line 44 skipping to change at line 2010
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 48 change blocks. 
241 lines changed or deleted 301 lines changed or added

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