draft-ietf-mmusic-file-transfer-mech-02.txt   draft-ietf-mmusic-file-transfer-mech-03.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: November 19, 2007 Nokia Expires: December 7, 2007 Nokia
G. Camarillo G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
May 18, 2007 June 5, 2007
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable
File Transfer File Transfer
draft-ietf-mmusic-file-transfer-mech-02.txt draft-ietf-mmusic-file-transfer-mech-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 19, 2007. This Internet-Draft will expire on December 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document provides a mechanism to negotiate the transfer of one This document provides a mechanism to negotiate the transfer of one
or more files between two endpoints by using the Session Description or more files between two endpoints by using the Session Description
Protocol (SDP) offer/answer model specified in RFC 3264. SDP is Protocol (SDP) offer/answer model specified in RFC 3264. SDP is
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Alternatives Considered . . . . . . . . . . . . . . . . . 5 1.1. Alternatives Considered . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 8 5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9
7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 14 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 14
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . 16 8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 17
8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 17 8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 18
8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 17 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. Indicating File Transfer Offer/Answer Capability . . . . . 19 8.3. The 'file-transfer' attribute . . . . . . . . . . . . . . 20
8.4. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 19 8.4. Indicating File Transfer Offer/Answer Capability . . . . . 22
8.5. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 20 8.5. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 22
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.6. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 21 8.7. Considerations about the 'file-icon' attribute . . . . . . 24
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 25 file transfer . . . . . . . . . . . . . . . . . . . . . . 29
9.3. Example of a capability indication . . . . . . . . . . . . 31 9.3. Example of a capability indication . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
11.1. Registration of new SDP attributes . . . . . . . . . . . . 33 11.1. Registration of new SDP attributes . . . . . . . . . . . . 38
11.1.1. Registration of the file-selector attribute . . . . . 33 11.1.1. Registration of the file-selector attribute . . . . . 38
11.1.2. Registration of the file-disposition attribute . . . . 33 11.1.2. Registration of the file-transfer attribute . . . . . 38
11.1.3. Registration of the file-date attribute . . . . . . . 33 11.1.3. Registration of the file-disposition attribute . . . . 38
11.1.4. Registration of the file-icon attribute . . . . . . . 34 11.1.4. Registration of the file-date attribute . . . . . . . 39
11.1.5. Registration of the file-range attribute . . . . . . . 34 11.1.5. Registration of the file-icon attribute . . . . . . . 39
11.2. Registration of new Content Disposition value . . . . . . 34 11.1.6. Registration of the file-range attribute . . . . . . . 39
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . . 40
13.2. Informational References . . . . . . . . . . . . . . . . . 36 13.2. Informational References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 43
1. Introduction 1. Introduction
The Session Description Protocol (SDP) Offer/Answer [7] provides a The Session Description Protocol (SDP) Offer/Answer [RFC3264]
mechanism for two endpoints to arrive at a common view of a provides a mechanism for two endpoints to arrive at a common view of
multimedia session between them. These sessions often contain real- a multimedia session between them. These sessions often contain
time media streams such as voice and video, but are not limited to real-time media streams such as voice and video, but are not limited
that. Basically, any media component type can be supported, as long to that. Basically, any media component type can be supported, as
as there is a specification how to negotiate it within the SDP offer/ long as there is a specification how to negotiate it within the SDP
answer exchange. offer/answer exchange.
The Message Session Relay Protocol (MSRP) [11] is a protocol for The Message Session Relay Protocol (MSRP)
transmitting instant messages (IM) in the context of a session. The [I-D.ietf-simple-message-sessions] is a protocol for transmitting
protocol specification includes a description how to use it with SDP. instant messages (IM) in the context of a session. The protocol
In addition to plain text messages, MSRP is able to carry arbitrary specification includes a description how to use it with SDP. In
(binary) Multipurpose Internet Mail Extensions (MIME) [2] compliant addition to plain text messages, MSRP is able to carry arbitrary
content, such as images or video clips. (binary) Multipurpose Internet Mail Extensions (MIME) [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 [15] provide a mechanism for Network Address Translator (NAT) relays [I-D.ietf-simple-msrp-relays] provide a mechanism for Network
traversal. Finally, Secure MIME (S/MIME) [8] can be used for Address Translator (NAT) traversal. Finally, Secure MIME (S/MIME)
ensuring the integrity and confidentiality of the transfered content. [RFC3851] can be used for ensuring the integrity and confidentiality
of the transfered 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
skipping to change at page 5, line 12 skipping to change at page 5, line 13
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 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.
Section 8.3 describes the mechanism whereby a user can learn the Section 8.4 describes the mechanism whereby a user can learn the
support for the functionality described in this specification at a support for the functionality described in this specification at a
remote endpoint. Finally, some examples are given in Section 9. remote endpoint. Finally, some examples are given in Section 9.
1.1. Alternatives Considered 1.1. Alternatives Considered
The requirements are related to the description and negotiation of The requirements are related to the description and negotiation of
the session, not to the actual file transfer mechanism. Thus, it is the session, not to the actual file transfer mechanism. Thus, it is
natural that in order to meet them it is enough to define attribute natural that in order to meet them it is enough to define attribute
extensions and usage conventions to SDP, while MSRP itself needs no extensions and usage conventions to SDP, while MSRP itself needs no
extensions and can be used as it is. This is effectively the extensions and can be used as it is. This is effectively the
approach taken in this specification. Another goal has been to approach taken in this specification. Another goal has been to
specify the SDP extensions in such a way that a regular MSRP endpoint specify the SDP extensions in such a way that a regular MSRP endpoint
which does not support them could still in some cases act as an which does not support them could still in some cases act as an
endpoint in a file transfer session, albeit with a somewhat reduced endpoint in a file transfer session, albeit with a somewhat reduced
functionality. functionality.
In some ways the aim of this specification is similar to the aim of In some ways the aim of this specification is similar to the aim of
content indirection mechanism in the Session Initiation Protocol content indirection mechanism in the Session Initiation Protocol
(SIP) [13]. Both mechanisms allow a user agent to decide whether or (SIP) [RFC4483]. Both mechanisms allow a user agent to decide
not to download a file based on information about the file. However, whether or not to download a file based on information about the
there are some differences. With content indirection, it is not file. However, there are some differences. With content
possible for the other endpoint to explicitly accpet or reject the indirection, it is not possible for the other endpoint to explicitly
file transfer. Also, it is not possible for an endpoint to request a accpet or reject the file transfer. Also, it is not possible for an
file from another endpoint. Furthermore, content indirection is not endpoint to request a file from another endpoint. Furthermore,
tied to the context of a media session, which is sometimes a content indirection is not tied to the context of a media session,
desirable property. Finally, content indirection typically requires which is sometimes a desirable property. Finally, content
some server infrastructure, which may not always be available. (It indirection typically requires some server infrastructure, which may
is possible to use content indirection directly between the endpoints not always be available. (It is possible to use content indirection
too, but in that case there is no definition for how it works for directly between the endpoints too, but in that case there is no
endpoints behind NATs.) definition for how it works for endpoints behind NATs.)
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 here
and replace MSRP with any other similar protocol that can carry and replace MSRP with any other similar protocol that can carry
MIME objects. This kind of specification can be written as a MIME objects. This kind of specification can be written as a
separate document if the need arises. separate document if the need arises.
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 transfered between two endpoits. The information needed file to be transfered between two endpoits. 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
'external-body' type and the use of a single SDP parameter. '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 A MIME 'external-body' could potentially be used to describe the file
to be transfered. In fact, many of the SDP parameters this to be transfered. In fact, many of the SDP parameters this
specification defines are also supported by 'external-body' body specification defines are also supported by 'external-body' body
parts. The MMUSIC working group decided not to use 'external-body' parts. The MMUSIC working group decided not to use 'external-body'
body parts because a number of existing offer/answer implementations body parts because a number of existing offer/answer implementations
do not support multipart bodies. do not support multipart bodies.
The information carried in the SDP attributes defined in Section 6 The information carried in the SDP attributes defined in Section 6
could potentially be encoded in a single SDP attribute. The MMUSIC could potentially be encoded in a single SDP attribute. The MMUSIC
skipping to change at page 6, line 39 skipping to change at page 6, line 40
defined in Section 6. Those implementations will be able to use defined in Section 6. Those implementations will be able to use
regular SDP rules in order to ignore non-supported SDP parameters. regular SDP rules in order to ignore non-supported SDP parameters.
If all the information was encoded in a single SDP attribute, those If all the information was encoded in a single SDP attribute, those
rules, which relate to backwards compatibility, would need to be rules, which relate to backwards compatibility, would need to be
redefined specifically for that parameter. redefined specifically for that parameter.
2. Terminology 2. Terminology
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 [1]. document are to be interpreted as described in BCP 14, RFC 2119
[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 [7] 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 receiver. file receiver.
File receiver: The endpoint that is willing to receive a file from File receiver: The endpoint that is willing to receive a file from
the file sender. the file sender.
File selector: A tuple of file attributes that the SDP offerer File selector: A tuple of file attributes that the SDP offerer
includes in the SDP in order to select a file at the SDP answerer. includes in the SDP in order to select a file at the SDP answerer.
This is described in more detail in Section 5. This is described in more detail in Section 5.
Push operation: A file transfer operation where the SDP offerer
takes the role of the file sender and the SDP answerer takes role
of the file receiver.
Pull operation: A file transfer operation where the SDP offerer
takes the role of the file receiver and the SDP answerer takes the
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. can accept or reject the transfer of each of those files.
The actual file transfer is carried out using the Message Session The actual file transfer is carried out using the Message Session
Relay Protocol (MSRP) [11]. Each SDP "m=" line describes an MSRP Relay Protocol (MSRP) [I-D.ietf-simple-message-sessions]. Each SDP
media stream used to transfer a single file. That is, the transfer "m=" line describes an MSRP media stream used to transfer a single
of multiple simultaneous files requires multiple "m=" lines and file. That is, the transfer of multiple simultaneous files requires
corresponding MSRP media streams. It should be noted that multiple multiple "m=" lines and corresponding MSRP media streams. It should
MSRP media streams can share a single transport layer connection, so be noted that multiple MSRP media streams can share a single
this mechanism will not lead to excessive use of transport resources. transport layer connection, so this mechanism will not lead to
excessive use of transport resources.
Each "m=" line for an MSRP media stream is accompanied with a few Each "m=" line for an MSRP media stream is accompanied with a few
attributes describing the file to be transferred. If the file sender attributes describing the file to be transferred. If the file sender
generates the SDP offer, the attributes describe a local file to be generates the SDP offer, the attributes describe a local file to be
sent (push), and the file receiver can use this information to either sent (push), and the file receiver can use this information to either
accept or reject the transfer. However, if the SDP offer is accept or reject the transfer. However, if the SDP offer is
generated by the file receiver, the attributes are intended to generated by the file receiver, the attributes are intended to
characterize a particular file that the file receiver is willing to characterize a particular file that the file receiver is willing to
get (pull) from the file sender. It is possible that the file sender get (pull) from the file sender. It is possible that the file sender
does not have a matching file or does not want to send the file, in does not have a matching file or does not want to send the file, in
skipping to change at page 8, line 25 skipping to change at page 8, line 35
would not be able to accept/reject it based on the file would not be able to accept/reject it based on the file
attributes. attributes.
5. File selector 5. File selector
Specially in case the SDP offer is generated by the file receiver, Specially in case the SDP offer is generated by the file receiver,
the offer needs a mechanism to unambiguously identify the requested the offer needs a mechanism to unambiguously identify the requested
file. For this purpose, the file transfer mechanism introduces the file. For this purpose, the file transfer mechanism introduces the
concept of a file selector, which is defined as the combination of concept of a file selector, which is defined as the combination of
the 4-tuple composed of the name, size, type, and hash of the file. the 4-tuple composed of the name, size, type, and hash of the file.
We call each of these individual items a selector. We call each of these individual items a selector. The file selector
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 that characterizes a file to the remote entity, so that both the
local and the remote entity can refer to the same file. The file local and the remote entity can refer to the same file. The file
selector is encoded in a 'file-selector' media attribute in SDP. The selector is encoded in a 'file-selector' media attribute in SDP. The
formal syntax of the 'file-selector' media attribute is described in formal 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
skipping to change at page 8, line 49 skipping to change at page 9, line 13
available files in a host. The file transfer mechanism specified in available files in a host. The file transfer mechanism specified in
this document requires that a file selector eventually results at this document requires that a file selector eventually results at
most in a single file to be chosen. Typically, if the hash selector most in a single file to be chosen. Typically, if the hash selector
is known, it is enough to produce a file selector that points to is known, it is enough to produce a file selector that points to
exactly zero or one file. However, a file selector that selects a exactly zero or one file. However, a file selector that selects a
unique file is not always known by the offerer. Sometimes only the unique file is not always known by the offerer. Sometimes only the
name, size or type of file are known, so the file selector may result name, size or type of file are known, so the file selector may result
in selecting more than one file, which is an undesired case. The in selecting more than one file, which is an undesired case. The
opposite is also true: if the file selector contains a hash and a opposite is also true: if the file selector contains a hash and a
name selectors, there is a risk that the remote host has renamed the name selectors, there is a risk that the remote host has renamed the
file, although there is a file with the indicated hash, the file name file, in which case, although a file whose computed hash equals the
does not match, thus, the file selector will result in the selection hash selector exists, the file name does not match that of the name
of zero files. selector, thus, the file selection process will result in the
selection of zero files.
Since there are several hashing algorithms, such as SHA-1 [6], SHA- Since there are several hashing algorithms, such as SHA-1 [RFC3174],
256, SHA-384, SHA-512 [14], etc., a file selector MAY contain several SHA-256, SHA-384, SHA-512 [RFC4634], etc., a file selector MAY
hashes, each one describing the hash of the file with a different contain several hashes, each one describing the hash of the file with
hashing algorithm. Implementations that make use of the hash SHOULD a different hashing algorithm. Implementations that make use of the
select one among the supported ones before selecting a file. So, hash SHOULD select one among the supported hashes before selecting a
when several hashes are present in the SDP, the file selector file. So, when several hashes are present in the SDP, the file
consists of the union of the name, size, type, and any of the selector consists of the union of the name, size, type, and any of
supported hash algorithms. the supported hash algorithms.
Implementations according to this specification MUST implement the Implementations according to this specification MUST implement the
'file-selector' attribute and MAY implement any of the other 'file-selector' attribute and MAY implement any of the other
attributes specified in this specification. SDP offers and answers attributes specified in this specification. SDP offers and answers
for file transfer MUST contain a 'file-selector' media attribute that for file transfer MUST contain a 'file-selector' media attribute that
selects the file to be transferred and MAY contain any of the other selects the file to be transferred and MAY contain any of the other
attributes specified in this specification. attributes specified in this specification.
The 'file-selector' media attribute is also useful when learning the 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.3. document specifies. This is further explained in Section 8.4.
6. Extensions to SDP 6. Extensions to SDP
We define a number of new SDP [10] attributes that provide the We define a number of new SDP [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 [9] of these new attributes. It is built the formal ABNF syntax [RFC4234] of these new attributes. It is
above the SDP [10] grammar, RFC 2045 [2], RFC 2183 [3], and RFC 2392 built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183
[4]. [RFC2183], and RFC 2392 [RFC2392].
attribute = file-selector-attr / file-disp-attr / attribute = file-selector-attr / file-disp-attr /
file-date-attr / file-icon-attr / file-date-attr / file-icon-attr /
file-range-attr file-range-attr
;attribute is defined in RFC 4566 ;attribute is defined in RFC 4566
file-selector-attr = "file-selector" [":" selector *(SP selector)] file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector = filename-selector / filesize-selector / selector = filename-selector / filesize-selector /
filetype-selector / hash-selector filetype-selector / hash-selector
filename-selector = "name:" DQUOTE filename-string DQUOTE filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE defined in RFC 4234 ; DQUOTE defined in RFC 4234
filename-string = byte-string ;byte-string defined in RFC 4566 filename-string = 1*(%x01-09/%x0B-0C/%x0E-21/%x23-FF)
;any byte except NUL, CR, LF, or double quotes
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 type = token
subtype = token subtype = token
hash-selector = "hash:" hash-algorithm ":" hash-value hash-selector = "hash:" hash-algorithm ":" hash-value
hash-algorithm = token ;see IANA Hash Function hash-algorithm = token ;see IANA Hash Function
;Textual Names registry ;Textual Names registry
hash-value = hex-val ;hex-val defined in RFC 4234 hash-value = 2UHEX *(":" 2UHEX)
; Each byte in upper-case hex, separated
; by colons.
file-transfer = "file-transfer:" file-transfer-value
file-transfer-value = "new" / "existing" / 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 = "file-date:" date-param *(SP date-param) file-date = "file-date:" date-param *(SP date-param)
date-param = c-date-param / m-date-param / r-date-param date-param = c-date-param / m-date-param / r-date-param
c-date-param = "creation:" DQUOTE date-time DQUOTE c-date-param = "creation:" DQUOTE date-time DQUOTE
m-date-param = "modification:" DQUOTE date-time DQUOTE m-date-param = "modification:" DQUOTE date-time DQUOTE
r-date-param = "read:" DQUOTE date-time DQUOTE r-date-param = "read:" DQUOTE date-time DQUOTE
skipping to change at page 10, line 50 skipping to change at page 11, line 4
; date-time is defined in RFC 2822 ; date-time is defined in RFC 2822
; numeric timezones (+HHMM or -HHMM) ; numeric timezones (+HHMM or -HHMM)
; must be used ; must be used
; DQUOTE defined in RFC 4234 ; DQUOTE defined in RFC 4234
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:" integer "-" integer file-range-attr = "file-range:" integer "-" integer
;integer defined in RFC 4566 ;integer defined in RFC 4566
Figure 1: Syntax of the SDP extension Figure 1: Syntax of the SDP extension
When used for capability query (see Section 8.3), the 'file-selector'
When used for capability query (see Section 8.4), the 'file-selector'
attribute MUST NOT not contain any selector, because its presence attribute MUST NOT not contain any selector, because its presence
merely indicates compliance to this specification. merely indicates compliance to this specification.
When used in an SDP offer or answer, the 'file-selector' attribute When used in an SDP offer or answer, the 'file-selector' attribute
MUST contain at least one selector. Selectors parametrize the file MUST contain at least one selector. Selectors parametrize 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
encoded in UTF-8. Its value SHOULD be the same as the 'filename' encoded in UTF-8 [RFC3629]. Its value SHOULD be the same as the
parameter of Content-Disposition header field [3] that could be 'filename' parameter of the Content-Disposition header field
signalled by the actual file transfer. The 'name' selector MUST not [RFC2183] that could be signalled by the actual file transfer. If a
contain characters that can be interpreted as directory structure by file name contains double quotes, they MUST be percent-encoded. The
the local operating system. If such characters are present in the 'name' selector MUST not contain characters that can be interpreted
file name, they MUST be escaped. as directory structure by the local operating system. If such
characters are present in the file name, they MUST be percent-
encoded.
Note that the 'name' selector might still contain characters that, Note that the 'name' selector might still contain characters that,
although not meaningful for the local operating system, might although not meaningful for the local operating system, might
still be meaningful to the remote operating system (e.g., '\', still be meaningful to the remote operating system (e.g., '\',
'/', ':'). Therefore, implementations are responsible for '/', ':'). Therefore, implementations are responsible for
sanitizing the input received from the remote endpoint before sanitizing the input received from the remote endpoint before
doing a local operation, such as the creation of a local file. doing a local operation, such as the creation of a local file.
Among other things, implementations can escape characters that are Among other things, implementations can percent-encode characters
meaningful to the local operating system before doing file system that are meaningful to the local operating system before doing
local calls. file system local calls.
The 'size' selector in the 'file-selector' attribute indicates the The 'size' selector in the 'file-selector' attribute indicates the
size of the file in octets. The value of this attribute SHOULD be size of the file in octets. The value of this attribute SHOULD be
the same of the 'size' parameter of Content-Disposition header field the same as the 'size' parameter of the Content-Disposition header
[3] that could be signalled by the actual file transfer. Note that field [RFC2183] that could be signalled by the actual file transfer.
the 'size' selector merely includes the file size, and does not Note that the 'size' selector merely includes the file size, and does
include any potential overhead added by a wrapper, such as message/ not include any potential overhead added by a wrapper, such as
cpim. message/cpim.
The 'type' selector in the 'file-selector' attribute contains the The 'type' selector in the 'file-selector' attribute contains the
MIME media type of the content. In general, anything that can be MIME media type of the content. In general, anything that can be
expressed in a Content-Type header field (see RFC 2045 [2]) can also expressed in a Content-Type header field (see RFC 2045 [RFC2045]) can
be expressed with the 'type' selectors. Possible MIME Media Type also be expressed with the 'type' selectors. Possible MIME Media
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 [17]. Zero or more parameters can follow. The syntax of Types [1]. Zero or more parameters can follow. The syntax of
'parameter' is specified in RFC 2045 [2] . 'parameter' is specified in RFC 2045 [RFC2045] .
The 'hash' selector in the 'file-selector' attribute provides a hash The 'hash' selector in the 'file-selector' attribute provides a hash
of the file to be transferred. This is commonly used by file computation of the file to be transferred. This is commonly used by
transfer protocols. For example, FLUTE [16] uses hashes (called file transfer protocols. For example, FLUTE
message digests) to verify the contents of the transfer. The purpose [I-D.ietf-rmt-flute-revised] uses hashes (called message digests) to
of the 'hash' selector is two-fold: On one side, it allows the file verify the contents of the transfer. The purpose of the 'hash'
receiver to identify a file by its hash rather than by its file name, selector is two-fold: On one side, in pull operations, it allows the
providing that the file receiver has learned the hash of the file by file receiver to identify a remote file by its hash rather than by
some out-of-band mechanism. On the other side, it allows the file its file name, providing that the file receiver has learned the hash
sender to provide the hash of the file to be transmitted, which can of the remote file by some out-of-band mechanism. On the other side,
be used by the file receiver for verification of its contents or to in either push or pull operations, it allows the file sender to
avoid the unnecessary transmission of a file that already exists. provide the hash of the file to be transmitted, which can be used by
the file receiver for verification of its contents or to avoid the
unnecessary transmission of a file that already exists.
The 'file-transfer' attribute provides a mechanism for distinguishing
new file transfers from existing ones. A new file transfer is one
that, in case of acceptance, will provoke the transfer of a file.
This is typically the case of new INVITE requests. On the contrary,
an existing file transfer is one that is declared in the SDP, but
does not lead to any file to be transferred, potentially because the
file transfer is still going on or because it has already finished.
This is the case of a re-INVITE request, which can be due to a number
of reasons (session timer, addition/removal of other media types in
the SDP, update in SDP due to changes in other session parameters,
etc.). Implementations according to this specification MUST include
a 'file-transfer' attribute in SDP answers and offers. The 'file-
transfer' attribute can take any of two values: "new" or "existing".
The "new" value indicates that a file transfer will start once the
SDP negotiation is successfully concluded. The "existing" value
indicates that the file transfer MUST NOT start at the end of the SDP
negotiation. Section 8 and Section 8.3 provide further details.
The 'hash' selector includes the hash algorithm and its value. In The 'hash' selector includes the hash algorithm and its value. In
fact, since there are several hashing algorithms, the SDP MAY contain fact, since there are several hashing algorithms, the 'file-selector'
several 'hash' selectors with different algorithms. Possible hash attribute in SDP MAY contain several 'hash' selectors with different
algorithms are those defined in the IANA registry of Hash Function algorithms. Possible hash algorithms are those defined in the IANA
Textual Names [18]. Implementations according to this specification registry of Hash Function Textual Names [2]. Implementations
MUST support the US Secure Hash Algorithm 1 (SHA1) [6] and MAY according to this specification MUST support the US Secure Hash
support other hashing algorithms. The value is the byte string Algorithm 1 (SHA1) [RFC3174] and MAY support other hashing
resulting of applying the hash algorithm to the content of the whole algorithms. The value is the byte string resulting of applying the
file. hash algorithm to the content of the whole file.
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 of the disposition type parameter this attribute SHOULD be the same of the disposition type parameter
of the Content-Disposition header field [3] that could be signalled of the Content-Disposition header field [RFC2183] that could be
by the actual file transfer protocol. signalled by the actual file transfer protocol.
The 'file-date' attribute indicates the dates at which the file was The 'file-date' attribute indicates the dates at which the file was
created, modified, or last read. This attribute MAY contain a created, modified, or last read. This attribute MAY contain a
combination of the 'creation', 'modification', and 'read' parameters. combination of the 'creation', 'modification', and 'read' parameters.
Only one parameter of each type (creation, modification, or read) Only one parameter of each type (creation, modification, or read)
MUST be present in a 'file-date' attribute. MUST be present in a 'file-date' attribute.
The 'creation' parameter indicates the date at which the file was The 'creation' parameter indicates the date at which the file was
created. The value MUST be a quoted string which contains a created. The value MUST be a quoted string which contains a
representation of the creation date of the file in RFC 2822 [5] representation of the creation date of the file in RFC 2822 [RFC2822]
'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used.
The value of this parameter SHOULD be the same of the 'creation-date' The value of this parameter SHOULD be the same as the 'creation-date'
parameter of Content-Disposition header field [3] that could be parameter of the Content-Disposition header field [RFC2183] that
signalled by the actual file transfer protocol. could be signalled by the actual file transfer protocol.
The 'modification' parameter indicates the date at which the file was The 'modification' parameter indicates the date at which the file was
last modified. The value MUST be a quoted string which contains a last modified. The value MUST be a quoted string which contains a
representation of the last modification date to the file in RFC 2822 representation of the last modification date to the file in RFC 2822
[5] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be [RFC2822] 'date-time' format. Numeric timezones (+HHMM or -HHMM)
used. The value of this parameter SHOULD be the same of the MUST be used. The value of this parameter SHOULD be the same as the
'modification-date' parameter of Content-Disposition header field [3] 'modification-date' parameter of the Content-Disposition header field
that could be signalled by the actual file transfer protocol. [RFC2183] that could be signalled by the actual file transfer
protocol.
The 'read' parameter indicates the date at which the file was last The 'read' parameter indicates the date at which the file was last
read. The value MUST be a quoted string which contains a read. The value MUST be a quoted string which contains a
representation of the last date the file was read in RFC 2822 [5] representation of the last date the file was read in RFC 2822
'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. [RFC2822] 'date-time' format. Numeric timezones (+HHMM or -HHMM)
The value of this parameter SHOULD be the same of the 'read-date' MUST be used. The value of this parameter SHOULD be the same as the
parameter of Content-Disposition header field [3] that could be 'read-date' parameter of the Content-Disposition header field
signalled by the actual file transfer protocol. [RFC2183] that could be signalled by the actual file transfer
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 sender to include a pointer to a body that as images. It allows the sender to include a pointer to a body that
includes a small preview icon representing the contents of the file includes a small preview icon representing the contents of the file
to be transferred. This allows the sender to include the icon as to be transferred. This allows the sender to include the icon as
another body accompanying the SDP, and to the recipient to get the another body accompanying the SDP, and to the recipient to get the
icon of the file to be transferred. It is recommended to keep icons icon of the file to be transferred. The 'file-icon' attribute
restricted to the minimum number of bytes that provide significance. contains a Content-ID URL, which is specified in RFC 2392 [RFC2392].
The 'file-icon' attribute contains a Content-ID URL, which is Section 8.7 contains further considerations about the 'file-icon'
specified in RFC 2392 [4]. 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 is composed to two of the endpoints. The 'file-range' attribute is composed to two
integer values separated by a dash "-". The first integer value integer values separated by a dash "-". The first integer value
refers to the first byte of the file to be transferred. The second refers to the first byte of the file to be transferred. The second
integer value refers to the last byte of the file to be transferred. integer value refers to the last byte of the file to be transferred.
The first byte of a file is indicated with "1". The absence of this The first byte of a file is indicated with "1". The absence of this
attribute indicates a complete file, i.e., like if the 'file-range' attribute indicates a complete file, i.e., like if the 'file-range'
skipping to change at page 14, line 17 skipping to change at page 14, line 33
s= s=
c=IN IP4 host.atlanta.example.com c=IN IP4 host.atlanta.example.com
t=0 0 t=0 0
m=message 7654 TCP/MSRP * m=message 7654 TCP/MSRP *
i=This is my latest picture i=This is my latest picture
a=sendonly a=sendonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:32349 hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E size:32349 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer:new
a=file-disposition:not-render a=file-disposition:not-render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00" a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00"
a=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 in NOTE: The 'file-selector' attribute in the above figure is split
two lines for formatting purposes. Real implementations will encode in three lines for formatting purposes. Real implementations will
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 [19] is the IANA registry for Mail Content Disposition Values [3] 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 the file recipient hand, the file sender may just want to indicate the file recipient
that the file should not be rendered at the reception of the file. that the file should not be rendered at the reception of the file.
The recipient's user agent may want to interact with the user The recipient's user agent may want to interact with the user
regarding the file disposition or it may save the file until the user regarding the file disposition or it may save the file until the user
takes an action. In any case, the exact actions are implementation takes an action. In any case, the exact actions are implementation
dependent. dependent.
To indicate that a file should be automatically rendered, this memo To indicate that a file should be automatically rendered, this memo
uses the existing 'render' value of the Content Disposition type in uses the existing 'render' value of the Content Disposition type in
the new '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 defines a new value should not be automatically rendered, this memo users the existing
'not-render' of the Content Disposition type. The default value is 'attachment' value of the Content-Disposition type in the new 'file-
'render', i.e., the absence of a 'file-disposition' attribute in the disposition' attribute in SDP. The default value is 'render', i.e.,
SDP has the same semantics as 'render'. the absence of a 'file-disposition' attribute in the SDP has the same
semantics as 'render'.
The disposition value 'attachment' is specified in RFC 2183
[RFC2183] with the following definition:
"Bodyparts can be designated 'attachment' to indicate that they
are separate from the main body of the mail message, and that
their display should not be automatic, but contingent upon some
further action of the user."
In the case of this specification, the 'attachment' disposition
type is used o indicate that the display of the file should not 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 [7] exchange. Additionally, this in the context of an offer/answer [RFC3264] exchange. Additionally,
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 Usually the file transfer session is initiated when the offerer sends
an SDP offer to the answerer. The answerer either accepts or rejects an SDP offer to the answerer. The answerer either accepts or rejects
the file transfer session and sends an SDP answer to the offerer. the file transfer session and sends an SDP answer to the offerer.
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 'recvonly' file sender. In this case the SDP offer contains a session or
attribute, and accordingly the SDP answer contains a 'sendonly' media 'recvonly' attribute, and accordingly the SDP answer
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 that wishes to send or receive one or more files to or
from an answerer MUST build an SDP [10] description of a session from an answerer MUST build an SDP [RFC4566] description of a session
containing one or more "m=" lines, each one describing an MSRP containing one or more "m=" lines, each one describing an MSRP
session (and thus, one file transfer operation), according to the session (and thus, one file transfer operation), according to the
MSRP [11] procedures. All the media line attributes specified and MSRP [I-D.ietf-simple-message-sessions] procedures. All the media
required by MSRP [11] (e.g., "a=path", "a=accept-types", etc.) MUST line attributes specified and required by MSRP
be included as well. For each file to be transferred there MUST be a [I-D.ietf-simple-message-sessions] (e.g., "a=path", "a=accept-types",
separate "m=" line. etc.) MUST be included as well. For each file to be transferred
there MUST be a separate "m=" line.
8.1.1. The Offerer is a File Sender 8.1.1. The Offerer is a File Sender
In a push operation, the file sender creates and SDP offer describing In a push operation, the file sender creates and SDP offer describing
the file to be sent. Then it sends the SDP offer to the file the file to be sent. The file sender MUST add a 'file-selector'
receiver. The file sender MUST add a 'file-selector' attribute media attribute media line containing at least one of the 'type', 'size',
line containing at least one of the 'type', 'size', 'hash', 'hash' selectors in indicating the type, size, or hash of the file,
parameters in indicating the type, size, or hash of the file,
respectively. If the file sender is able to compute the hash of the respectively. If the file sender is able to compute the hash of the
file with different hashing algorithms, it MAY add several 'hash' file with different hashing algorithms, it MAY add several 'hash'
parameters, each one referring to a different hashing algorithm. selectors, each one referring to a different hashing algorithm. The
Additionally, the file sender MUST add a session or media 'sendonly' file sender MUST add a 'file-transfer' attribute with a value that
attribute to the SDP offer. indicates whether a new file transfer should start ("new" value), or
whether the SDP merely indicates an existing file transfer
("existing" value), in which case a new file transfer should not
start. Additionally, the file sender MUST add a session or media
'sendonly' attribute to the SDP offer. Then the file sender sends
the SDP offer to the file receiver.
Not all the selectors in the 'file-selector' attribute might be Not all the selectors in the 'file-selector' attribute might be
known when the file sender creates the SDP offer, for example, known when the file sender creates the SDP offer, for example,
because the host is still processing the file. because the host is still processing the file.
The 'hash' parameter 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. If the file is already available and need not be transmitted. If the
sender supports several hashing algorithms, then several 'hash' sender supports several hashing algorithms, then several 'hash'
parameters can be included. selector can be included.
The file sender MAY also add a 'name' parameter in the 'file- The file sender MAY also add a 'name' selector in the 'file-selector'
selector' attribute, and a 'file-icon', 'file-disposition', and attribute, and a 'file-icon', 'file-disposition', and 'file-date'
'file-date' attributes further describing the file to be transferred. attributes further describing the file to be transferred. The 'file-
The 'file-disposition' attribute provides a presentation suggestion, disposition' attribute provides a presentation suggestion, (for
(for example: the file sender would like the file receiver to render example: the file sender would like the file receiver to render the
the file or not). The three date attributes provide the answerer file or not). The three date attributes provide the answerer with an
with an indication of the age of the file. The file sender MAY also indication of the age of the file. The file sender MAY also add a
add a 'file-range' attribute indicating the start and stop offset of 'file-range' attribute indicating the start and stop offset of the
the file transfer. file transfer.
8.1.2. The Offerer is a File Receiver 8.1.2. The Offerer is a File Receiver
In a pull operation, the file receiver creates the SDP offer and In a pull operation, the file receiver creates the SDP offer and
sends it to the file sender. The file receiver MUST include a 'file- sends it to the file sender. The file receiver MUST include a 'file-
selector' attribute and SHOULD add, at least, one of the parameters selector' attribute and SHOULD add, at least, one of the selector
defined for such attribute (i.e., 'name', 'type', 'size', or 'hash'). defined for that attribute (i.e., 'name', 'type', 'size', or 'hash').
Several 'hash' parameters MAY be included if each 'hash' parameter is Several 'hash' selectors MAY be included if each 'hash' selector is
computed with a different hashing algorithm. In many cases, if the computed with a different hashing algorithm. In many cases, if the
hash of the file is known, that is enough to identify the file, hash of the file is known, that is enough to identify the file,
therefore, the offerer can include only a 'hash' attribute. However, therefore, the offerer can include only a 'hash' selector. However,
specially in cases where the hash of the file is unknown, the file specially in cases where the hash of the file is unknown, the file
name, size, and type can provide a description of the file to be name, size, and type can provide a description of the file to be
fetched. There is no need to for the file offerer to include further fetched. The file receiver MUST also add a 'file-transfer' attribute
file attributes in the SDP offer, thus it is RECOMMENDED that SDP with a value that indicates whether a new file transfer should start
offerers do not include any other file attribute defined by this ("new" value), or whether the SDP merely indicates an existing file
transfer ("existing" value), in which case a new file transfer should
not start. There is no need to for the file offerer to include
further file attributes in the SDP offer, thus it is RECOMMENDED that
SDP offerers do not include any other file attribute defined by this
specification (other than the mandatory ones). Additionally, the specification (other than the mandatory ones). Additionally, the
file receiver MUST create an SDP offer that contains a session or file receiver MUST create an SDP offer that contains a session or
media 'recvonly' attribute. media 'recvonly' attribute.
The file receiver MAY also add a 'file-range' attribute indicating The file receiver MAY also add a 'file-range' attribute indicating
the start and stop offset of the file transfer. the start and stop offset of the file transfer.
When the file receiver receives the SDP answer, if the port number of
the answer for a file request is non-zero and if the 'file-transfer'
attribute is set to "new", then the file receiver should receive the
file using the protocol indicated in the m= line. If the SDP answer
contains a supported hashing algorithm in the 'hash' selectors of the
'file-selector' attribute, then the file receiver SHOULD compute the
hash of the file after receipt and check against the hash received in
the answer. In case the computed hash does not match the one
contained in the SDP answer, the file receiver SHOULD consider that
the file transfer failed and 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. This way, the answerer can reject generates an "m=" line per file along with the file attributes
described in this specification. This way, the answerer can reject
individual files by setting the port number of their associated "m=" individual files by setting the port number of their associated "m="
lines to zero, as per regular SDP [10] procedures. lines to zero, as per regular SDP [RFC4566] procedures.
Using an "m=" line per file implies that different files are Using an "m=" line per file implies that different files are
transferred using different MSRP sessions. However, all those MSRP transferred using different MSRP sessions. However, all those MSRP
sessions can be set up to run over a single TCP connection, as sessions can be set up to run over a single TCP connection, as
described in Section 8.1 of [11]. described in Section 8.1 of [I-D.ietf-simple-message-sessions].
8.2. Answerer's Behavior 8.2. Answerer's Behavior
If the answerer wishes to reject a file offered by the offerer, it If the answerer wishes to reject a file offered by the offerer, it
sets the port number of the "m=" line associated with the file to sets the port number of the "m=" line associated with the file to
zero, as per regular SDP [10] procedures. If the answerer decides to zero, as per regular SDP [RFC4566] procedures and MUST set the 'file-
accept the file, it proceeds as per regular MSRP [11] and SDP [10] transfer' attribute that mirrors the value received in the SDP offer.
If the answerer decides to accept the file, it proceeds as per
regular MSRP [I-D.ietf-simple-message-sessions] and SDP [RFC4566]
procedures. procedures.
8.2.1. The Answerer is a File Receiver 8.2.1. The Answerer is a File Receiver
In a push operation the answerer is the file receiver. When the file In a push operation the answerer is the file receiver. When the file
receiver gets the SDP answer, it extracts the attributes and receiver gets the SDP offer, it extracts the attributes and
parameters that describe the file and typically requests permission parameters that describe the file and typically requests permission
to the user to accept or reject the reception of the file. If the to the user to accept or reject the reception of the file. If the
file transfer operation is accepted, the file receiver MUST create an file transfer operation is accepted, the file receiver MUST create an
SDP answer according to the procedures specified in RFC 3264 [7]. If SDP answer according to the procedures specified in RFC 3264
the offer contains 'name', 'type', 'size', parameters in the 'file- [RFC3264]. If the offer contains 'name', 'type', 'size' selectors in
selector' attribute, the answerer MUST copy them into the answer. If the 'file-selector' attribute, the answerer MUST copy them into the
the offer contains one ore more 'hash' parameters in the 'file- answer. If the offer contains one ore more 'hash' selectors in the
selector' attribute, the answerer discards those with non-supported 'file-selector' attribute, the answerer discards those with non-
hashing algorithms and MUST copy the remaining (if any) to the 'file- supported hashing algorithms and MUST copy the remaining (if any) to
selector' attribute of the answer. This informs the offerer that the the 'file-selector' attribute of the answer. This informs the
answerer supports this specification. Then the file receiver MUST offerer that the answerer supports this specification. The file
add a 'recvonly' attribute according to the procedures specified in receiver then adds a 'file-transfer' attribute with an appropriate
RFC 3264 [7]. The file receiver MUST NOT include 'file-icon', 'file- value. Then the file receiver MUST add a session or media 'recvonly'
attribute according to the procedures specified in RFC 3264
[RFC3264]. The file receiver MUST NOT include 'file-icon', 'file-
disposition', or 'file-date' attributes in the SDP answer. disposition', or 'file-date' attributes in the SDP answer.
If the SDP offer contains one or more 'hash' parameters in the 'file- If the SDP offer contains one or more 'hash' selectors in the 'file-
selector' attribute, the answerer discards those with unsupported selector' attribute, the answerer discards those with unsupported
hashing algorithms. The file receiver can use the remaining hashes hashing algorithms. The file receiver can use the remaining hashes
to find out if a local file with the same hash is already available, to find out if a local file with the same hash is already available,
in which case, this could imply the reception of a duplicated file. in which case, this could imply the reception of a duplicated file.
It is up to the answerer to determine whether the file transfer is It is up to the answerer to determine whether the file transfer is
accepted or not in case of a duplicated file. accepted or not in case of a duplicated file.
If the SDP offer contains a 'file-range' attribute and the file If the SDP offer contains a 'file-range' attribute and the file
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 18, line 20 skipping to change at page 19, line 31
8.2.2. The Answerer is a File Sender 8.2.2. The Answerer is a File Sender
In a pull operation the answerer is a file sender. In this case, the In a pull operation the answerer is a file sender. In this case, the
file sender MUST first inspect the received SDP offer and apply the file sender MUST first inspect the received SDP offer and apply the
file selector. The file selector is encoded in the 'file-selector' file selector. The file selector is encoded in the 'file-selector'
media attribute line in SDP. First, if the file selector contains media attribute line in SDP. First, if the file selector contains
several hashes, the file sender MUST select one of them which several hashes, the file sender MUST select one of them which
contains a supported hashing algorithm and discard the rest. Then contains a supported hashing algorithm and discard the rest. Then
the file sender applies the file selector, which implies selecting the file sender applies the file selector, which implies selecting
those files that match one by one with the 'name', 'type', 'size', those files that match one by one with the 'name', 'type', 'size',
and 'hash' parameters of the 'file-selector' attribute line (if they and 'hash' selectors of the 'file-selector' attribute line (if they
are present). The file selector identifies zero or more candidate are present). The file selector identifies zero or more candidate
files to be sent. If the file selector is unable to identify any files to be sent. If the file selector is unable to identify any
file, then the answerer MUST reject the MSRP stream for file transfer file, then the answerer MUST reject the MSRP stream for file transfer
by setting the port number to zero, and then the file sender SHOULD by setting the port number to zero, and then the file sender SHOULD
also reject the SDP as per procedures in RFC 3264 [7], if this is the also reject the SDP as per procedures in RFC 3264 [RFC3264], if this
only stream described in the SDP offer. is 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 [7]. If the SDP offer included several procedures described RFC 3264 [RFC3264]. The file sender SHOULD add
'hash' parameters, the file sender SHOULD include at least one in the one or more 'hash' selectors in the answer, with algorithms supported
SDP answer, selected among those present in the offer and, at the by the file sender and values locally computed by the file sender,
same time, supported by the file sender. If the SDP offer did not and SHOULD include at least one with a hash algorithm selected among
include a 'hash' parameter, the file sender SHOULD add one or more those present in the offer. The file sender MUST NOT include a
'hash' parameters, according to the supported hashing algorithms. 'hash' selector with an algorithm that was present in the offer and a
The file sender MAY also include a 'type' parameter in the 'file- value that differs from what was in the offer. If a hash value
selector' attribute line of the SDP answer. The answerer MAY also computed by the file sender differs from that specified by the file
include a 'file-icon' and 'file-disposition' attributes to further receiver, the file sender can either send the file without that hash
describe the file. Although the answerer MAY also include a 'name' value or reject the request by setting the port in the media stream
and 'size' parameters in the 'file-selector' attribute, and a 'file- to zero. The file sender MAY also include a 'type' selector in the
date' attribute, it is RECOMMENDED not to include them in the SDP 'file-selector' attribute line of the SDP answer. The file sender
answer if the actual file transfer protocol (e.g., MSRP [11]) can MUST add a 'file-transfer' attribute with the appropriate value. The
accommodate a Content-Disposition header field [3] with the answerer MAY also include a 'file-icon' and 'file-disposition'
equivalent parameters. attributes to further describe the file. Although the answerer MAY
also include a 'name' and 'size' selectors in the 'file-selector'
attribute, and a 'file-date' attribute, it is RECOMMENDED not to
include them in the SDP answer if the actual file transfer protocol
(e.g., MSRP [I-D.ietf-simple-message-sessions]) can 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 signalled start. Adding any SDP attributes that are otherwise signalled
later in the file transfer protocol would just duplicate the later in the file transfer protocol would just duplicate the
information, but will not provide any information to the offerer information, but will not provide any information to the offerer
to accept or reject the file transfer (note that the offerer is to accept or reject the file transfer (note that the offerer is
requesting a file). requesting a file).
Last, if the file selector points to multiple candidate files, the Last, if the file selector points to multiple candidate files, the
skipping to change at page 19, line 24 skipping to change at page 20, line 41
mechanism that allows to either select multiple files or, e.g., mechanism that allows to either select multiple files or, e.g.,
resolve ambiguities by returning a list of files that match the resolve ambiguities by returning a list of files that match the
file selector. file selector.
If the SDP offer contains a 'file-range' attribute and the file If the SDP offer contains a 'file-range' attribute and the file
sender accepts to send the range of bytes declared in there, the file sender accepts to send the range of bytes declared in there, the file
sender MUST include a 'file-range' attribute in the SDP answer with sender MUST include a 'file-range' attribute in the SDP answer with
the same range of values. If the file sender does not accept sending the same range of values. If the file sender does not accept sending
that range of bytes, it SHOULD reject the transfer of the file. that range of bytes, it SHOULD reject the transfer of the file.
8.3. Indicating File Transfer Offer/Answer Capability 8.3. The 'file-transfer' attribute
The SDP Offer/Answer Model [7] provides provisions for indicating a This specification creates an extension to the SDP Offer/Answer Model
capability to another endpoint (see Section 9 of RFC 3264 [7]). The [RFC3264], and because of that, it is assumed that the existing SDP
mechanism assumes a high-level protocol, such as SIP [12], that behaviour is kept intact. The SDP behaviour requires, for example,
provides a capability query (such as a SIP OPTIONS request). RFC that SDP is sent again to the remote party in situations where the
3264 [7] indicates how to build the SDP that is included in the media description or perhaps other SDP parameters have not changed
response to such request. As such, RFC 3264 indicates that and with respect a previous offer/answer exchange. Let's consider the
endpoint builds an SDP body that contains an "m=" line that contains SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITEs to
the media type (message, for MSRP). An endpoint that implements the refresh sessions. RFC 4028 recommends to send unmodified SDP in a
procedures specified in this document SHOULD also add a 'file- re-INVITE to refresh the session. Should this re-INVITE contain SDP
selector' media attribute for the "m=message" line. The 'file- describing a file transfer operation and occur while the file
selector' media attribute MUST be empty, i.e., it MUST NOT contain transfer was still going on, there would be no means to detect
any selector. whether the SDP creator wanted to abort the current file transfer
operation and initiate a new one or the SDP file description was
included in the SDP due to other reasons (e.g., session timer
refresh).
8.4. Re-usage of Existing m= Lines in SDP A similar scenario occurs when two endpoints have successfully agreed
on a file transfer, which is currently taking place when one of the
endpoints wants to add additional media streams to the existing
session. In this case, the endpoint sends a re-INVITE request that
contains SDP. The SDP needs to maintain the media descriptions for
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
new file transfer is requested or not.
The SDP Offer/Answer Model [7] provides rules that allow SDP offerers In other cases, a file transfer was successfully completed. Then, if
and answerers to modify an existing media line, i.e., re-use an an endpoint re-sends the SDP offer with the media stream for the file
existing media line with different attributes. The same is also transfer, then the other endpoint wouldn't be able to determine
whether a new file transfer should start or not.
To address these scenarios this specification defines the 'file-
transfer' attribute, which can take any of two values: "new" or
"existing". A "new" value in the 'file-transfer' attribute indicates
that the endpoint wants to create a new file transfer. This is the
case of initial offer/answer exchanges, or in cases where an endpoint
wants to abort the existing file transfer an re-start the file
transfer once more. An "existing" value in the 'file-transfer'
attribute indicates that the endpoint is already involved or has
concluded the actual file transfer, consequently, a new additional
file transfer MUST NOT start.
Endpoints MUST include a 'file-transfer' attribute in any SDP offer
or answer that defines a file transfer operation, according to this
specification. An SDP answer that MUST not downgrade the offered
'file-transfer' value. Table 1 shows the possible combination of
'file-transfer' values in SDP offers and answers both for pull and
push file transfer operations.
+----------+----------------+
| Offerer | Answerer |
+----------+----------------+
| new | new |
| existing | new / existing |
+----------+----------------+
Table 1: 'file-transfer' attribute values
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
transfer operation, then the SDP answer should mirror the value of
the 'file-transfer' attribute included in the SDP offer. This
effectively means that setting a media stream to zero has higher
precedence than any value that the 'file-transfer' attribute can
take.
As a side effect, the 'file-transfer' attribute can be used for
aborting and restarting again an ongoing file transfer. Assume that
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 transfer, one endpoint sends a new SDP offer, equal to the
initial one, where the 'file-transfer' attribute is set to "new".
This indicates that the offerer wants to abort the existing transfer
and start a new one, according to the SDP parameters. The SDP
answerer SHOULD abort the ongoing file transfer, according to the
procedures of the file transfer protocol (e.g., MSRP), and start
sending file once more from the initial requested octet.
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. The SDP offerer creates an SDP file that maintains the media
description line corresponding to the file transfer. The SDP offerer
MUST then set the port number to zero and MUST set the 'file-
transfer' attribute to "existing" to indicate that the media stream
is offered but must not be used.
8.4. Indicating File Transfer Offer/Answer Capability
The SDP Offer/Answer Model [RFC3264] provides provisions for
indicating a capability to another endpoint (see Section 9 of RFC
3264 [RFC3264]). The mechanism assumes a high-level protocol, such
as SIP [RFC3261], that provides a capability query (such as a SIP
OPTIONS request). RFC 3264 [RFC3264] indicates how to build the SDP
that is included in the response to such request. As such, RFC 3264
indicates that and endpoint builds an SDP body that contains an "m="
line that contains the media type (message, for MSRP). An endpoint
that implements the procedures specified in this document SHOULD also
add a 'file-selector' media attribute for the "m=message" line. The
'file-selector' media attribute MUST be empty, i.e., it MUST NOT
contain any selector. The endpoint MUST NOT add any of the other
file attributes defined in this specification.
8.5. Re-usage of Existing m= Lines in 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
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
[7], in particular those defined in Section 8.3, MUST apply for file [RFC3264], in particular those defined in Section 8.3, MUST apply for
transfer operations. file transfer operations. An endpoint that wants to re-use an
existing m= line to start the file transfer of another file creates a
different 'file-selector' attribute and sends the 'file-transfer' to
the value "new".
8.5. MSRP Usage If the file offerer re-sends an SDP offer with a port different than
zero, then the 'file-transfer' attribute determines whether a new
file transfer will start or whether the file transfer does not need
to start. If the SDP answerer accepts the SDP, then file transfer
starts from the indicated byte (if a 'file-range' attribute is
present).
8.6. MSRP Usage
The file transfer service specified in this document uses "m=" lines The file transfer service specified in this document uses "m=" lines
to describe the unidirectional transfer of a file. Consequently, to describe the unidirectional transfer of a file. Consequently,
each MSRP session established following the procedures in Section 8.1 each MSRP session established following the procedures in Section 8.1
and Section 8.2 is only used to transfer a single file. So, senders and Section 8.2 is only used to transfer a single file. So, senders
MUST only use the dedicated MSRP session to send the file described MUST only use the dedicated MSRP session to send the file described
in the SDP offer or answer. That is, senders MUST NOT send in the SDP offer or answer. That is, senders MUST NOT send
additional files over the same MSRP session. additional files over the same MSRP session.
Additionally, implementations according to this specification MUST 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 file. When chunking, notice that MSRP does not require message: the CPIM message that wraps the file. When chunking, notice
to wait for a 200-class response for a chunk before sending the that MSRP does not require to wait for a 200-class response for a
following one. Therefore, it is valid to send pipelined MSRP SEND chunk before sending the following one. Therefore, it is valid to
requests containing chunks of the same MSRP message (the file). send pipelined MSRP SEND requests containing chunks of the same MSRP
Section 9.1 contains an example of a file transfer using pipelined message (the file). Section 9.1 contains an example of a file
MSRP requests. transfer using pipelined MSRP requests.
The MSRP specification [I-D.ietf-simple-message-sessions] defines a
'max-size' SDP attribute. This attribute specifies the maximum
number of octets of an MSRP message that the creator of the SDP is
willing to receive (notice once more the definition of "MSRP
message"). File receivers MAY add a 'max-size' attribute to the MSRP
m= line that specifies the 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 the resulting session.
In the absence of a 'file-range' attribute in the SDP, the MSRP file In the absence of a 'file-range' attribute in the SDP, the MSRP file
transfer MUST start with the first byte of the file and end with the transfer MUST start with the first byte of the file and end with the
last byte (i.e., the whole file is transferred). If a 'file-range' last byte (i.e., the whole file is transferred). If a 'file-range'
attribute is present in SDP, the file sender application MUST extract attribute is present in SDP, the file sender application MUST extract
the indicated range of bytes from the file (start and stop bytes). the indicated range of bytes from the file (start and stop bytes).
Then the file sender application SHOULD wrap those bytes in an Then the file sender application SHOULD wrap those bytes in an
appropriate wrapper, such as message/cpim. Last, the file sender appropriate wrapper, such as message/cpim. Last, the file sender
application delivers the message/cpim to MSRP for transportation. application delivers the message/cpim to MSRP for transportation.
MSRP will consider the message/cpim as a whole message, and will MSRP will consider the message/cpim as a whole message, and will
start numbering bytes at number 1. start numbering bytes at number 1.
Note that the default content disposition of MSRP bodies is 'render'. Note that the default content disposition of MSRP bodies is 'render'.
When MSRP is used to transfer files, the MSRP Content-Disposition When MSRP is used to transfer files, the MSRP Content-Disposition
header can also take the value 'not-render' defined by this memo. header can also take the value 'attachment' as indicated in
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 [11] procedures MSRP session, and MUST behave according to the MSRP
with respect closing MSRP sessions. [I-D.ietf-simple-message-sessions] procedures with respect closing
MSRP sessions.
8.7. Considerations about the 'file-icon' attribute
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
[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,
the file sender has to use a MIME multipart/mixed body that contains
an SDP body part and the icon body part. Therefore, implementations
according to this specification MUST implement the multipart/mix MIME
type [RFC2046].
However, if the file sender sends a request that contains a
multipart/mix MIME body that includes an SDP body part and an icon
body part, and the file receiver does not support multipart MIME
types, then the file receiver will reject, via a higher protocol
mechanism (e.g., SIP), the request. In this case, it is RECOMMENDED
that the file sender removes the icon body part, creates a single SDP
body (i.e., without multipart MIME) and re-tries the request again.
This increases the chances of getting the SDP accepted at the file
receiver (albeit the file receiver will not implement this
specification, which mandates the implementation of multipart MIME
bodies).
Since the icon is sent as part of the signalling, it is recommended
to keep icons restricted to the minimum number of bytes 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 [12] is used to transport the SDP offer/ example assumes that SIP [RFC3261] is used to transport the SDP
answer exchange, although the SIP details are briefly shown in the offer/answer exchange, although the SIP details are briefly shown in
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
an icon representing the contents of the file to be transferred. The an icon representing the contents of the file to be transferred. The
sequence flow is shown in Figure 3. sequence flow is shown in Figure 3.
Alice's UAC Bob's UAS Alice's UAC Bob's UAS
| | | |
skipping to change at page 22, line 32 skipping to change at page 26, line 32
s= s=
c=IN IP4 alicepc.example.com c=IN IP4 alicepc.example.com
t=0 0 t=0 0
m=message 7654 TCP/MSRP * m=message 7654 TCP/MSRP *
i=This is my latest picture i=This is my latest picture
a=sendonly a=sendonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:4092 hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E size:4092 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer:new
a=file-disposition:render a=file-disposition:render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00" a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00"
a=file-icon:cid:id2@alicepc.example.com a=file-icon:cid:id2@alicepc.example.com
--boundary71 --boundary71
Content-Type: image/jpeg Content-Type: image/jpeg
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.example.com> Content-ID: <id2@alicepc.example.com>
Content-Length: [length of image] Content-Length: [length of image]
Content-Disposition: icon Content-Disposition: icon
[...small preview icon of the file...] [...small preview icon of the file...]
--boundary71-- --boundary71--
Figure 4: INVITE request containing an SDP offer for file transfer Figure 4: INVITE request containing an SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split
NOTE: The 'file-selector' attribute in the above figure is split in in three lines for formatting purposes. Real implementations will
two lines for formatting purposes. Real implementations will encode encode it in a single line.
it in a single line.
From now on we omit the SIP details for the sake of brevity. From now on we omit the SIP details for the sake of brevity.
F2: Bob receives the INVITE request, inspects the SDP offer and F2: Bob receives the INVITE request, inspects the SDP offer and
extracts the icon body, checks the creation date and file size, and extracts the icon body, checks the creation date and file size, and
decides to accept the file transfer. So Bob creates the following decides to accept the file transfer. So Bob creates the following
SDP answer: SDP answer:
v=0 v=0
o=bob 2890844656 2890844656 IN IP4 bobpc.example.com o=bob 2890844656 2890844656 IN IP4 bobpc.example.com
s= s=
c=IN IP4 bobpc.example.com c=IN IP4 bobpc.example.com
t=0 0 t=0 0
m=message 8888 TCP/MSRP * m=message 8888 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:4092 hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E size:4092 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer:new
Figure 5: SDP answer accepting the SDP offer for file transfer Figure 5: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split in NOTE: The 'file-selector' attribute in the above figure is split
two lines for formatting purposes. Real implementations will encode in three lines for formatting purposes. Real implementations will
it in a single line. encode it in a single line.
F4: Alice opens a TCP connection to Bob and creates an MSRP SEND F4: Alice opens a TCP connection to Bob and creates an MSRP SEND
request. This SEND request contains the first chunk of the file. request. This SEND request contains the first chunk of the file.
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Byte-Range: 1-2048/4385 Byte-Range: 1-2048/4385
Content-Type: message/cpim Content-Type: message/cpim
skipping to change at page 25, line 26 skipping to change at page 29, line 26
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 attribute is enough to produce a out-of-band mechanism. The hash selector is enough to produce a file
file selector that points to the specific file. So, Alice creates an selector that points to the specific file. So, Alice creates an SDP
SDP offer that contains the file descriptor. Bob accepts the offer that contains the file descriptor. Bob accepts the
transmission and sends the file to Alice. When Alice has completely transmission 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 re-uses 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). Figure 10 shows the sequence send to Bob's User Agent Server (UAS). Figure 10 shows the sequence
flow. flow.
Alice's UAC Bob's UAS Alice's UAC Bob's UAS
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
skipping to change at page 27, line 26 skipping to change at page 31, line 26
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
s= s=
c=IN IP4 alicepc.example.com c=IN IP4 alicepc.example.com
t=0 0 t=0 0
m=message 7654 TCP/MSRP * m=message 7654 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:image/jpeg a=accept-wrapped-types:image/jpeg
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E a=file-selector:hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer:new
Figure 11: INVITE request containing an SDP offer for file transfer Figure 11: INVITE request containing an SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split
in two lines for formatting purposes. Real implementations will
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 transmission and creates indicated in the SDP. Bob accepts the file transmission and creates
an SDP answer as follows: an SDP answer as follows:
v=0 v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s= s=
c=IN IP4 bobpc.example.com c=IN IP4 bobpc.example.com
t=0 0 t=0 0
m=message 8888 TCP/MSRP * m=message 8888 TCP/MSRP *
a=sendonly a=sendonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E a=file-selector:type:image/jpeg hash:sha-1:
type:image/jpeg 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer:new
Figure 12: SDP answer accepting the SDP offer for file transfer Figure 12: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split
in two lines for formatting purposes. Real implementations will
encode it in a single line.
F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP
SEND request that contains the file. SEND request that contains the file.
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7654/iau39;tcp To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Byte-Range: 1-2027/2027 Byte-Range: 1-2027/2027
Content-Type: message/cpim Content-Type: message/cpim
skipping to change at page 29, line 32 skipping to change at page 34, line 32
s= s=
c=IN IP4 alicepc.example.com c=IN IP4 alicepc.example.com
t=0 0 t=0 0
m=message 5670 TCP/MSRP * m=message 5670 TCP/MSRP *
i=This is my latest picture i=This is my latest picture
a=sendonly a=sendonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:5670/iau39;tcp a=path:msrp://alicepc.example.com:5670/iau39;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:58231FE8653BBCF371362F86D471913EE4B1DF2F size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer:new
a=file-disposition:render a=file-disposition:render
a=file-date:creation:"Sun, 21 May 2006 13:02:15 +03:00" a=file-date:creation:"Sun, 21 May 2006 13:02:15 +03:00"
a=file-icon:cid:id3@alicepc.example.com a=file-icon:cid:id3@alicepc.example.com
--boundary71 --boundary71
Content-Type: image/jpeg Content-Type: image/jpeg
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <id3@alicepc.example.com> Content-ID: <id3@alicepc.example.com>
Content-Length: [length of image] Content-Length: [length of image]
Content-Disposition: icon Content-Disposition: icon
[..small preview icon...] [..small preview icon...]
--boundary71-- --boundary71--
Figure 15: Reuse of the SDP in a second file transfer Figure 15: Reuse of the SDP in a second file transfer
NOTE: The 'file-selector' attribute in the above figure is split
NOTE: The 'file-selector' attribute in the above figure is split in in three lines for formatting purposes. Real implementations will
two lines for formatting purposes. Real implementations will encode encode it in a single line.
it in a single line.
F7: Bob receives the re-INVITE request, inspects the SDP offer and F7: Bob receives the re-INVITE request, inspects the SDP offer and
extracts the icon body, checks the creation date and file size, and extracts the icon body, checks the creation date and file size, and
decides to accept the file transfer. So Bob creates the following decides to accept the file transfer. So Bob creates the following
SDP answer: SDP answer:
v=0 v=0
o=bob 2890844656 2890855440 IN IP4 bobpc.example.com o=bob 2890844656 2890855440 IN IP4 bobpc.example.com
s= s=
c=IN IP4 bobpc.example.com c=IN IP4 bobpc.example.com
t=0 0 t=0 0
m=message 9999 TCP/MSRP * m=message 9999 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:9999/9an4ea;tcp a=path:msrp://bobpc.example.com:9999/9an4ea;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:58231FE8653BBCF371362F86D471913EE4B1DF2F size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer:new
a=file-disposition:render a=file-disposition:render
Figure 16: SDP answer accepting the SDP offer for file transfer Figure 16: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split in NOTE: The 'file-selector' attribute in the above figure is split
two lines for formatting purposes. Real implementations will encode in three lines for formatting purposes. Real implementations will
it in a single line. encode it in a single line.
F9: Alice opens a new TCP connection to Bob and creates an MSRP SEND F9: Alice opens a new TCP connection to Bob and creates an MSRP SEND
request that contains the file. request that contains the file.
MSRP d95ksxox SEND MSRP d95ksxox SEND
To-Path: msrp://bobpc.example.com:9999/9an4ea;tcp To-Path: msrp://bobpc.example.com:9999/9an4ea;tcp
From-Path: msrp://alicepc.example.com:5670/iau39;tcp From-Path: msrp://alicepc.example.com:5670/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 31, line 46 skipping to change at page 36, line 46
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 20. The SDP indicates support for CPIM messages that shown in Figure 20. The SDP indicates support for CPIM messages that
can contain other few MIME types. The presence of the 'file- can contain other few MIME types. The maximum MSRP message size that
the 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
| | | |
|(1) (SIP) OPTIONS | |(1) (SIP) OPTIONS |
|----------------------->| |----------------------->|
|(2) (SIP) 200 OK | |(2) (SIP) 200 OK |
| with SDP | | with SDP |
|<-----------------------| |<-----------------------|
skipping to change at page 32, line 25 skipping to change at page 37, line 25
Figure 19: Flow diagram of a capability request Figure 19: Flow diagram of a capability request
v=0 v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=- s=-
c=IN IP4 bobpc.example.com c=IN IP4 bobpc.example.com
t=0 0 t=0 0
m=message 0 TCP/MSRP * m=message 0 TCP/MSRP *
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html image/jpeg image/gif a=accept-wrapped-types:text/plain text/html image/jpeg image/gif
a=max-size:20000
a=file-selector a=file-selector
Figure 20: SDP of the 200 (OK) response to an OPTIONS request Figure 20: SDP of the 200 (OK) response to an OPTIONS request
10. Security Considerations 10. Security Considerations
The SDP attributed defined in this specification identify a file to The SDP attributed defined in this specification identify a file to
be transfered between two endpoints. An endpoint can offer to send be transfered between two endpoints. An endpoint can offer to send
the file to the other endpoint or request to receive the file from the file to the other endpoint or request to receive the file from
the other endpoint. In the former case, an attacker modifying those the other endpoint. In the former case, an attacker modifying those
skipping to change at page 33, line 8 skipping to change at page 38, 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 be encrypted. the attributes specified in this specification be 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.
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
an a new Content Disposition value, 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
registry [20]. The registration data, according to RFC 4566 [10] registry [4]. The registration data, according to RFC 4566 [RFC4566]
follows. follows.
Note to the RFC Editor: replace "RFC XXXX" with the RFC number of Note to the RFC Editor: replace "RFC XXXX" with the RFC number of
this specification. this specification.
11.1.1. Registration of the file-selector attribute 11.1.1. Registration of the file-selector attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: file-selector Attribute name: file-selector
Long-form attribute name: 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 identify a file by
indicating a combination of the 4-tuple composed of the name, indicating a combination of the 4-tuple composed of the name,
size, type, and hash of the file. size, type, and hash of the file.
Specification: RFC XXXX Specification: RFC XXXX
11.1.2. Registration of the file-disposition attribute 11.1.2. Registration of the file-transfer attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000
Attribute name: file-transfer
Long-form attribute name: File Transfer
Type of attribute: media level only
This attribute is subject to the charset attribute
Description: This attribute indicates whether the SDP requests a
new file transfer or indicates an existing file transfer.
Specification: RFC XXXX
11.1.3. Registration of the file-disposition attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: file-disposition Attribute name: file-disposition
Long-form attribute name: 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 Specification: RFC XXXX
11.1.3. Registration of the file-date attribute 11.1.4. Registration of the file-date attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: file-date Attribute name: file-date
Long-form attribute name: Long-form attribute name:
Type of attribute: media level only Type of attribute: media level only
This attribute is not subject to the charset attribute This attribute is not subject to the charset attribute
Description: This attribute indicates the dates at which the file Description: This attribute indicates the dates at which the file
was created, modified, or last read. was created, modified, or last read.
Specification: RFC XXXX Specification: RFC XXXX
11.1.4. Registration of the file-icon attribute 11.1.5. Registration of the file-icon attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: file-icon Attribute name: file-icon
Long-form attribute name: 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 Description: For image files, this attribute contains a pointer to
a body that includes a small preview icon representing the a body that includes a small preview icon representing the
contents of the file to be transferred contents of the file to be transferred
Specification: RFC XXXX Specification: RFC XXXX
11.1.5. Registration of the file-range attribute 11.1.6. Registration of the file-range attribute
Contact: Miguel Garcia <miguel.garcia@nsn.com> Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71800 8000 Phone: +358 71800 8000
Attribute name: file-range Attribute name: file-range
Long-form attribute name: 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 bytes of the Description: it contains the range of transferred bytes of the
file file
Specification: RFC XXXX Specification: RFC XXXX
11.2. Registration of new Content Disposition value
This document requests IANA to act on Mail Content Disposition Values
and Parameters registry [19] and register a new Mail Content
Disposition Value according to the following data:
Name Description Reference
----- ------------ ---------
not-render the body should not be rendered to the user [RFCXXXX]
Note to the RFC Editor: Please replace RFCXXXX with the RFC number of
this specification.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Mats Stille, Nancy Greene, Adamu The authors would like to thank Mats Stille, Nancy Greene, Adamu
Haruna, and Arto Leppisaari for discussing initial concepts described Haruna, and Arto Leppisaari for discussing initial concepts described
in this memo. Thanks to Pekka Kuure for reviewing initial versions in this memo. Thanks to Pekka Kuure for reviewing initial versions
this document and providing helpful comments. Joerg Ott, Jiwey Wang, this document and providing helpful comments. Joerg Ott, Jiwey Wang,
Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis-
Courmont, and Colin Perkins discussed and provided comments and Courmont, Colin Perkins, Paul Kyzivat, and Sudhakar An discussed and
improvements to this document. provided comments and improvements to this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] 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 Bodies", Extensions (MIME) Part One: Format of Internet Message
RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[3] Troost, R., Dorner, S., and K. Moore, "Communicating [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Presentation Information in Internet Messages: The Content- Extensions (MIME) Part Two: Media Types", RFC 2046,
Disposition Header Field", RFC 2183, August 1997. November 1996.
[4] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
[5] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[6] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
RFC 3174, September 2001. (SHA1)", RFC 3174, September 2001.
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Session Description Protocol (SDP)", RFC 3264, June 2002. with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
(S/MIME) Version 3.1 Message Specification", RFC 3851, 10646", STD 63, RFC 3629, November 2003.
July 2004.
[9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[11] Campbell, B., "The Message Session Relay Protocol", [I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-19 (work in progress), draft-ietf-simple-message-sessions-19 (work in progress),
February 2007. February 2007.
13.2. Informational References 13.2. Informational References
[12] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[13] Burger, E., "A Mechanism for Content Indirection in Session [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Initiation Protocol (SIP) Messages", RFC 4483, May 2006. Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[14] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and [RFC4483] Burger, E., "A Mechanism for Content Indirection in
HMAC-SHA)", RFC 4634, August 2006. Session Initiation Protocol (SIP) Messages", RFC 4483,
May 2006.
[15] Jennings, C., "Relay Extensions for the Message Sessions Relay [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
Protocol (MSRP)", draft-ietf-simple-msrp-relays-10 (work in (SHA and HMAC-SHA)", RFC 4634, August 2006.
progress), December 2006.
[16] Paila, T., "FLUTE - File Delivery over Unidirectional [I-D.ietf-simple-msrp-relays]
Transport", draft-ietf-rmt-flute-revised-03 (work in progress), Jennings, C., "Relay Extensions for the Message Sessions
January 2007. Relay Protocol (MSRP)", draft-ietf-simple-msrp-relays-10
(work in progress), December 2006.
[I-D.ietf-rmt-flute-revised]
Paila, T., "FLUTE - File Delivery over Unidirectional
Transport", draft-ietf-rmt-flute-revised-03 (work in
progress), January 2007.
URIs URIs
[17] <http://www.iana.org/assignments/media-types/> [1] <http://www.iana.org/assignments/media-types/>
[18] <http://www.iana.org/assignments/hash-function-text-names> [2] <http://www.iana.org/assignments/hash-function-text-names>
[19] <http://www.iana.org/assignments/mail-cont-disp> [3] <http://www.iana.org/assignments/mail-cont-disp>
[20] <http://www.iana.org/assignments/sdp-parameters> [4] <http://www.iana.org/assignments/sdp-parameters>
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
Email: miguel.garcia@nsn.com Email: miguel.garcia@nsn.com
 End of changes. 124 change blocks. 
348 lines changed or deleted 609 lines changed or added

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