One document matched: draft-ietf-mmusic-file-transfer-mech-06.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc symrefs="yes" ?>
<rfc ipr="full3978"
docName="draft-ietf-mmusic-file-transfer-mech-06.txt" category="std">
<front>
<title abbrev="SDP offer/answer for file transfer">
A Session Description Protocol (SDP) Offer/Answer Mechanism to
Enable File Transfer
</title>
<author initials="M." surname="Garcia-Martin" fullname="Miguel A. Garcia-Martin">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>P.O.Box 6</street>
<city>Nokia Siemens Networks</city>
<region>FIN</region>
<code>02022</code>
<country>Finland</country>
</postal>
<phone>+358-71400-4000</phone>
<email>miguel.garcia@nsn.com</email>
</address>
</author>
<author initials="M." surname="Isomaki" fullname="Markus Isomaki">
<organization>Nokia</organization>
<address>
<postal>
<street>Keilalahdentie 2-4</street>
<code>02150</code>
<city>Espoo</city>
<country>Finland</country>
</postal>
<email>markus.isomaki@nokia.com</email>
</address>
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Gonzalo.Camarillo@ericsson.com</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Salvatore.Loreto@ericsson.com</email>
</address>
</author>
<author initials="P." surname="Kyzivat" fullname="Paul H. Kyzivat">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1414 Massachusetts Avenue</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<email>pkyzivat@cisco.com</email>
</address>
</author>
<date day="21" month="December" year="2007" />
<area>RAI</area>
<workgroup>MMUSIC Working Group</workgroup>
<keyword>SDP</keyword>
<keyword>file</keyword>
<keyword>transfer</keyword>
<abstract>
<t>
This document provides a mechanism to negotiate the transfer of
one or more files between two endpoints by using the Session
Description Protocol (SDP) offer/answer model specified in RFC
3264. SDP is extended to describe the attributes of the files to
be transferred. The offerer can either describe the files it
wants to send, or the files it would like to receive. The
answerer can either accept or reject the offer separately for
each individual file. The transfer of one or more files is
initiated after a successful negotiation. The Message Session
Relay Protocol (MSRP) is defined as the default mechanism to
actually carry the files between the endpoints. The conventions
on how to use MSRP for file transfer are also provided in this
document.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="RFC3264">The Session Description Protocol (SDP)
Offer/Answer </xref> provides a mechanism for two endpoints to
arrive at a common view of a multimedia session between
them. These sessions often contain real-time media streams such
as voice and video, but are not limited to that. Basically, any
media component type can be supported, as long as there is a
specification how to negotiate it within the SDP offer/answer
exchange.
</t>
<t>
The <xref target="RFC4975">Message Session Relay Protocol (MSRP)
</xref> is a protocol for transmitting instant messages (IM) in
the context of a session. The protocol specification describes
the usage of SDP for establishing a MSRP sessions. In addition to
plain text messages, MSRP is able to carry arbitrary (binary)
<xref target="RFC2045">Multipurpose Internet Mail Extensions
(MIME) </xref> compliant content, such as images or video clips.
</t>
<t>
There are many cases where the endpoints involved in a
multimedia session would like to exchange files within the
context of that session. With MSRP it is possible to embed files
as MIME objects inside the stream of instant messages. MSRP also
has other features that are useful for file transfer. Message
chunking enables the sharing of the same transport connection
between the transfer of a large file and interactive IM exchange
without blocking the IM. <xref
target="RFC4976">MSRP relays </xref> provide
a mechanism for Network Address Translator (NAT)
traversal. Finally, <xref target="RFC3851">Secure MIME (S/MIME)
</xref> can be used for ensuring the integrity and
confidentiality of the transferred content.
</t>
<t>
However, the baseline MSRP does not readily meet all the
requirements for file transfer services within multimedia
sessions. There are four main missing features:
</t>
<t>
<list style="symbols">
<t>
The recipient must be able to distinguish "file transfer"
from "file attached to IM", allowing the recipient to treat
the cases differently.
</t>
<t>
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 decline it, using the meta information in the
request. The actual transfer must take place only after
acceptance by the recipient.
</t>
<t>
It must be possible for the sender to pass some meta
information on the file before the actual transfer. This
must be able to include at least content type, size, hash
and name of the file, as well as a short (human readable)
description.
</t>
<t>
It must be possible for the recipient to request a file from
the sender, providing meta information about the file. The
sender must be able to decide whether to send a file
matching the request.
</t>
</list>
</t>
<t>
The rest of this document is organized as follows. <xref
target="sec-definitions" /> defines a few terms used in this
document. <xref target="sec-overview" /> provides the overview
of operation. <xref target="sec-protocol-file-selector"/>
introduces the concept of the file selector. The detailed syntax
and semantics of the new SDP attributes and conventions on how
the existing ones are used is defined in <xref
target="sec-sdp-extensions" />. <xref
target="sec-disposition"/> discusses the file disposition
types. <xref target="sec-protocol"/> describes the protocol
operation involving SDP and MSRP. Finally, some examples are
given in <xref target="sec-examples" />.
</t>
<section title="Alternatives Considered">
<t>
The requirements are related to the description and
negotiation of the session, not to the actual file transfer
mechanism. Thus, it is natural that in order to meet them it
is enough to define attribute extensions and usage conventions
to SDP, while MSRP itself needs no extensions and can be used
as it is. This is effectively the approach taken in this
specification. Another goal has been to specify the SDP
extensions in such a way that a regular MSRP endpoint which
does not support them could still in some cases act as an
endpoint in a file transfer session, albeit with a somewhat
reduced functionality.
</t>
<t>
In some ways the aim of this specification is similar to the
aim of <xref target="RFC4483">content indirection mechanism in
the Session Initiation Protocol (SIP) </xref>. Both mechanisms
allow a user agent to decide whether or not to download a file
based on information about the file. However, there are some
differences. With content indirection, it is not possible for
the other endpoint to explicitly accept or reject the file
transfer. Also, it is not possible for an endpoint to request
a file from another endpoint. Furthermore, content indirection
is not tied to the context of a media session, which is
sometimes a desirable property. Finally, content indirection
typically requires some server infrastructure, which may not
always be available. It is possible to use content indirection
directly between the endpoints too, but in that case there is
no definition for how it works for endpoints behind NATs. The
level of requirements in implementations decides which solution
meets the requirements.
</t>
<t>
Based on the argumentation above, this document defines the
SDP attribute extensions and usage conventions needed for
meeting the requirements on file transfer services with the
SDP offer/answer model, using MSRP as the transfer protocol
within the session.
</t>
<t>
<list style="hanging">
<t>
In principle it is possible to use the SDP extensions
defined here and replace MSRP with any other similar
protocol that can carry MIME objects. This kind of
specification can be written as a separate document if the
need arises. Essentially, such protocol should be able to
be negotiated on an SDP offer/answer exchange (<xref
target="RFC3264">RFC 3264 </xref>), be able to carry
MIME objects between two endpoints, and use a reliable
transport protocol (e.g., TCP).
</t>
</list>
</t>
<t>
This specification defines a set of SDP attributes that
describe a file to be transferred between two endpoints. The
information needed to describe a file could be potentially
encoded in a few different ways. The MMUSIC working group
considered a few alternative approaches before deciding to use
the encoding described in <xref
target="sec-sdp-extensions"/>. In particular, the working
group looked at the MIME 'external-body' type and the use of a
single SDP attribute or parameter.
</t>
<t>
A MIME 'external-body' could potentially be used to describe
the file to be transferred. In fact, many of the SDP parameters
this specification defines are also supported by
'external-body' body parts. The MMUSIC working group decided
not to use 'external-body' body parts because a number of
existing offer/answer implementations do not support multipart
bodies.
</t>
<t>
The information carried in the SDP attributes defined in <xref
target="sec-sdp-extensions"/> could potentially be encoded in
a single SDP attribute. The MMUSIC working group decided not
to follow this approach because it is expected that
implementations support only a subset of the parameters
defined in <xref target="sec-sdp-extensions"/>. Those
implementations will be able to use regular SDP rules in order
to ignore non-supported SDP parameters. If all the information
was encoded in a single SDP attribute, those rules, which
relate to backwards compatibility, would need to be redefined
specifically for that parameter.
</t>
</section>
</section>
<section title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in BCP 14, <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Definitions" anchor="sec-definitions">
<t>
For the purpose of this document, the following definitions
specified in <xref target="RFC3264">RFC 3264 </xref> apply:
</t>
<t>
<list style="symbols">
<t>Answer</t>
<t>Answerer</t>
<t>Offer</t>
<t>Offerer</t>
</list>
</t>
<t>
Additionally, we define the following terms:
</t>
<t>
<list style="hanging">
<t hangText="File sender: ">The endpoint that is willing to
send a file to the file receiver.</t>
<t hangText="File receiver: ">The endpoint that is willing to
receive a file from the file sender.</t>
<t hangText="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. This is described in more detail in <xref
target="sec-protocol-file-selector" />.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>
</t>
</section>
<section title="Overview of Operation" anchor="sec-overview">
<t>
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 offerer sends the SDP offer to the remote
endpoint. The SDP answerer can accept or reject the transfer of
each of those files.
</t>
<t>
The actual file transfer is carried out using the <xref
target="RFC4975">Message Session Relay Protocol (MSRP)
</xref>. Each SDP "m=" line describes an MSRP media stream used
to transfer a single file at a time. That is, the transfer of
multiple simultaneous files requires multiple "m=" lines and
corresponding MSRP media streams. It should be noted that
multiple MSRP media streams can share a single transport layer
connection, so this mechanism will not lead to excessive use of
transport resources.
</t>
<t>
Each "m=" line for an MSRP media stream is accompanied with a
few attributes describing the file to be transferred. If the
file sender generates the SDP offer, the attributes describe a
local file to be sent (push), and the file receiver can use this
information to either accept or reject the transfer. However, if
the SDP offer is generated by the file receiver, the attributes
are intended 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 does not have a matching file or
does not want to send the file, in which case the offer is
rejected.
</t>
<t>
The attributes describing each file are provided in SDP by a set
of new SDP attributes, most of which have been directly borrowed
from MIME. This way, user agents can decide whether or not to
accept a given file transfer based on the file's name, size,
description, hash, icon (e.g., if the file is a picture), etc.
</t>
<t>
SDP direction attributes (e.g., 'sendonly', 'recvonly') are used
to indicate the direction of the transfer, i.e., whether the SDP
offerer is willing to send of receive the file. Assuming that
the answerer accepts the file transfer, the actual transfer of
the files takes place with ordinary MSRP. Note that the
'sendonly' and 'recvonly' attributes refer to the direction of
MSRP SEND requests and do not preclude other protocol elements
(such as 200 responses, REPORT requests, etc.).
</t>
<t>
<list style="hanging">
<t>
In principle the file transfer can work even with an
endpoint supporting only regular MSRP without understanding
the extensions defined herein, in a special case where that
endpoint is the recipient of the file. The regular MSRP
endpoint answers the offer as it would answer any ordinary
MSRP offer without paying attention to the extension
attributes. In such a scenario the user experience would
however be reduced, as the recipient would not know (by any
protocol means) the reason for the session and would not be
able to accept/reject it based on the file attributes.
</t>
</list>
</t>
</section>
<section title="File selector" anchor="sec-protocol-file-selector">
<t>
Specially in case the SDP offer is generated by the file
receiver, the offer needs a mechanism to unambiguously identify
the requested file. For this purpose, the file transfer
mechanism introduces the notion 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. 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.
</t>
<t>
The purpose of the file selector is to provide enough
information 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 selector is encoded in a 'file-selector' media
attribute in SDP. The formal syntax of the 'file-selector' media
attribute is described in <xref target="sdp-syntax" />.
</t>
<t>
The file selection process is applied to all the available files
at the host. The process selects those file that match each of
the 4-tuple selectors present in the 'file-selector'
attribute. Thus, a file selector can point to zero, one, or more
files, depending on the presence of the mentioned selectors in
the SDP and depending on the available files in a host. The file
transfer mechanism specified in this document requires that a
file selector eventually results at most in a single file to be
chosen. Typically, if the hash selector is known, it is enough
to produce a file selector that points to exactly zero or one
file. However, a file selector that selects a unique file is not
always known by the offerer. Sometimes only the name, size or
type of file are known, so the file selector may result in
selecting more than one file, which is an undesired case. The
opposite is also true: if the file selector contains a hash
selector and a name selector, there is a risk that the remote
host has renamed the file, in which case, although a file whose
computed hash equals the hash selector exists, the file name
does not match that of the name selector, thus, the file
selection process will result in the selection of zero files.
</t>
<t>
This specification uses the Secure Hash Algorithm 1, <xref
target="RFC3174">SHA-1</xref>. If future needs require adding
support for different hashing algorithms, they will be
specified as extensions to this document.
</t>
<t>
Implementations according to this specification MUST implement
the 'file-selector' attribute and MAY implement any of the other
attributes specified in this specification. SDP offers and
answers for file transfer MUST contain a 'file-selector' media
attribute that selects the file to be transferred and MAY
contain any of the other attributes specified in this
specification.
</t>
<t>
The 'file-selector' media attribute is also useful when learning
the support of the file transfer offer/answer capability that
this document specifies. This is further explained in <xref
target="sec-capability" />.
</t>
</section>
<section title="Extensions to SDP" anchor="sec-sdp-extensions">
<t>
We define a number of new <xref target="RFC4566">SDP </xref>
attributes that provide the required information to describe the
transfer of a file with MSRP. These are all media level only
attributes in SDP. The following is the formal <xref
target="RFC4234">ABNF syntax </xref> of these new attributes. It
is built above the <xref target="RFC4566">SDP </xref> grammar,
<xref target="RFC2045">RFC 2045 </xref>, <xref
target="RFC2183">RFC 2183 </xref>, <xref target="RFC2392">RFC
2392 </xref>, and <xref target="RFC2822">RFC 2822 </xref>.
</t>
<figure anchor="sdp-syntax" title="Syntax of the SDP
extension"><artwork><![CDATA[
attribute = file-selector-attr / file-disp-attr /
file-tr-id-attr / file-date-attr /
file-icon-attr / file-range-attr
;attribute is defined in RFC 4566
file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector = filename-selector / filesize-selector /
filetype-selector / hash-selector
filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE defined in RFC 4234
filename-string = 1*(filename-char/percent-encoded)
filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%26-FF)
;any byte except NUL, CR, LF,
;double quotes, or percent
percent-encoded = "%" HEXDIG HEXDIG
; HEXDIG defined in RFC 4234
filesize-selector = "size:" filesize-value
filesize-value = integer ;integer defined in RFC 4566
filetype-selector = "type:" type "/" subtype *(";"parameter)
; parameter defined in RFC 2045
type = token ; token defined in RFC 4566
subtype = token
hash-selector = "hash:" hash-algorithm ":" hash-value
hash-algorithm = token ;see IANA Hash Function
;Textual Names registry
;only "sha-1" currently supported
hash-value = 2HEXDIG *(":" 2HEXDIG)
; Each byte in upper-case hex, separated
; by colons.
; HEXDIG defined in RFC 4234
file-tr-id-attr = "file-transfer-id:" file-tr-id-value
file-tr-id-value = token
file-disp-attr = "file-disposition:" file-disp-value
file-disp-value = token
file-date-attr = "file-date:" date-param *(SP date-param)
date-param = c-date-param / m-date-param / r-date-param
c-date-param = "creation:" DQUOTE date-time DQUOTE
m-date-param = "modification:" DQUOTE date-time DQUOTE
r-date-param = "read:" DQUOTE date-time DQUOTE
; date-time is defined in RFC 2822
; numeric timezones (+HHMM or -HHMM)
; must be used
; DQUOTE defined in RFC 4234 files.
file-icon-attr = "file-icon:" file-icon-value
file-icon-value = cid-url ;cid-url defined in RFC 2392
file-range-attr = "file-range:" start-offset "-" stop-offset
start-offset = integer ;integer defined in RFC 4566
stop-offset = integer / "*"
]]></artwork></figure>
<t>
When used for capability query (see <xref
target="sec-capability"/>), the 'file-selector' attribute MUST NOT
contain any selector, because its presence merely indicates
compliance to this specification.
</t>
<t>
When used in an SDP offer or answer, the 'file-selector'
attribute MUST contain at least one selector. Selectors
characterize the file to be transferred. There are four
selectors in this attribute: 'name', 'size', 'type', and 'hash'.
</t>
<t>
The 'name' selector in the 'file-selector' attribute contains
the filename of the content enclosed in double quotes. The
filename is encoded in <xref target="RFC3629">UTF-8 </xref>. Its
value SHOULD be the same as the 'filename' parameter of the
<xref target="RFC2183">Content-Disposition header field </xref>
that would be signaled by the actual file transfer. If a file
name contains double quotes or any other character that the
syntax does not allow in the 'name' selector, they MUST be
percent-encoded. The 'name' selector MUST NOT contain characters
that can be interpreted as directory structure by the local
operating system. If such characters are present in the file
name, they MUST be percent-encoded.
</t>
<t>
<list style="hanging">
<t>
Note that the 'name' selector might still contain characters
that, although not meaningful for the local operating
system, might still be meaningful to the remote operating
system (e.g., '\', '/', ':'). Therefore, implementations are
responsible for sanitizing the input received from the
remote endpoint before doing a local operation in the local
file system, such as the creation of a local file. Among
other things, implementations can percent-encode characters
that are meaningful to the local operating system before
doing file system local calls.
</t>
</list>
</t>
<t>
The 'size' selector in the 'file-selector' attribute indicates
the size of the file in octets. The value of this attribute
SHOULD be the same as the 'size' parameter of the <xref
target="RFC2183">Content-Disposition header field </xref> that
would be signaled by the actual file transfer. Note that the
'size' selector merely includes the file size, and does not
include any potential overhead added by a wrapper, such as
<xref target="RFC3862">message/cpim </xref>.
</t>
<t>
The 'type' selector in the 'file-selector' attribute contains
the MIME media and submedia types of the content. In general,
anything that can be expressed in a Content-Type header field
(see <xref target="RFC2045">RFC 2045 </xref>) can also be
expressed with the 'type' selectors. Possible MIME Media Type
values are the ones listed in the IANA registry for <eref
target="http://www.iana.org/assignments/media-types/">MIME Media
Types </eref>. Zero or more parameters can follow. The syntax of
'parameter' is specified in <xref target="RFC2045">RFC 2045
</xref> .
</t>
<t>
The 'hash' selector in the 'file-selector' attribute provides a
hash computation of the file to be transferred. This is commonly
used by file transfer protocols. For example, <xref
target="I-D.ietf-rmt-flute-revised"> FLUTE </xref> uses hashes
(called message digests) to verify the contents of the
transfer. The purpose of the 'hash' selector is two-fold: On one
side, in pull operations, it allows the file receiver to
identify a remote file by its hash rather than by its file name,
providing that the file receiver has learned the hash of the
remote file by some out-of-band mechanism. On the other side, in
either push or pull operations, it allows the file receiver to
verify the contents of the received file, or even avoid
unnecessary transmission of an existing file.
</t>
<t>
<list style="hanging">
<t>
The address space of the SHA-1 algorithm is big enough to
avoid any collision in hash computations in between two
endpoints. When transferring files, the actual file transfer
protocol should provide reliable transmission of data, so
verifications of received files should always
succeed. However, if endpoints need to protect the integrity
of a file, they should use some other mechanism than the
'hash' selector specified in this memo.
</t>
</list>
</t>
<t>
The 'hash' selector includes the hash algorithm and its
value. Possible hash algorithms are those defined in the IANA
registry of <eref
target="http://www.iana.org/assignments/hash-function-text-names">Hash
Function Textual Names </eref>. Implementations according to
this specification MUST add a <xref target="RFC3174">US
Secure Hash Algorithm 1 (SHA1)</xref> value if the 'hash'
selector is present. If need arises,
extensions can be drafted to support several hashing
algorithms. Therefore, implementations according to this
specification MUST be prepared to receive SDP containing more
than a single 'hash' selector in the 'file-selector' attribute.
</t>
<t>
The value of the 'hash' selector is the byte string resulting of
applying the hash algorithm to the content of the whole file,
even when the file transfer is limited to a number of octets
(i.e., the 'file-range' attribute is indicated).
</t>
<t>
The 'file-transfer-id' attribute provides a unique
identification to the actual file transfer. It is used to
distinguish a new file transfer request from a repetition of the
SDP (or the fraction of the SDP that deals with the file
description). This attribute is described in much greater detail
in <xref target="sec-protocol-file-transfer"/>.
</t>
<t>
The 'file-disposition' attribute provides a suggestion to the other
endpoint about the intended disposition of the file. <xref
target="sec-disposition" /> provides further discussion of the
possible values. The value of this attribute SHOULD be the same
as the disposition type parameter of the <xref
target="RFC2183">Content-Disposition header field </xref> that
would be signaled by the actual file transfer protocol.
</t>
<t>
The 'file-date' attribute indicates the dates at which the file
was created, modified, or last read. This attribute MAY contain
a combination of the 'creation', 'modification', and 'read'
parameters, but MUST NOT contain more than one of each type .
</t>
<t>
The 'creation' parameter indicates the date at which the file
was created. The value MUST be a quoted string which contains a
representation of the creation date of the file in <xref
target="RFC2822"> RFC 2822 </xref> 'date-time' format. Numeric
timezones (+HHMM or -HHMM) MUST be used. The value of this
parameter SHOULD be the same as the 'creation-date' parameter of
the <xref target="RFC2183">Content-Disposition header field
</xref> that would be signaled by the actual file transfer
protocol.
</t>
<t>
The 'modification' parameter indicates the date at which the
file was last modified. The value MUST be a quoted string which
contains a representation of the last modification date to the
file in <xref target="RFC2822"> RFC 2822 </xref> 'date-time'
format. Numeric timezones (+HHMM or -HHMM) MUST be used. The
value of this parameter SHOULD be the same as the
'modification-date' parameter of the <xref
target="RFC2183">Content-Disposition header field </xref> that
would be signaled by the actual file transfer protocol.
</t>
<t>
The 'read' parameter indicates the date at which the file was
last read. The value MUST be a quoted string which contains a
representation of the last date the file was read in <xref
target="RFC2822"> RFC 2822 </xref> 'date-time' format. Numeric
timezones (+HHMM or -HHMM) MUST be used. The value of this
parameter SHOULD be the same as the 'read-date' parameter of the
<xref target="RFC2183">Content-Disposition header field </xref>
that would be signaled by the actual file transfer protocol.
</t>
<t>
The 'file-icon' attribute can be useful with certain file types
such as images. It allows the file sender to include a pointer
to a body that includes a small preview icon representing the
contents of the file to be transferred, which the file receiver
can use to determine whether it wants to receive such file. The
'file-icon' attribute contains a Content-ID URL, which is
specified in <xref target="RFC2392">RFC 2392 </xref>. <xref
target="sec-file-icon" /> contains further considerations about
the 'file-icon' attribute.
</t>
<t>
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 file transfer can be interrupted, resumed, even
perhaps changing one of the endpoints. The 'file-range'
attribute contains the "start offset" and "stop offset" of the
file, separated by a dash "-". The "start offset" value refers
to the position of the file where the file transfer should
start. The first byte of a file is denoted by the ordinal number
"1". The "stop offset" value refers position of the file where
the file transfer should stop. The "stop offset" value MAY
contain a "*" if the total size of the file is not known in
advance. The absence of this attribute indicates a complete
file, i.e., as if the 'file-range' attribute would have been
present with a value "1-*". The 'file-range' attribute must not
be confused with the Byte-Range header in MSRP. The former
indicates the portion of a file that the application would read
and pass onto the MSRP stack for transportation. From the point
of view of MSRP, the portion of the file is viewed as a whole
message. The latter indicates the number of bytes of that
message that are carried in a chunk and the total size of the
message. Therefore, MSRP starts counting the delivered message
at byte number 1, independently of position of that byte in the
file.
</t>
<t>
The following is an example of an SDP body that contains the
extensions defined in this memo:
</t>
<figure anchor="fig-sdp-example" title="Example of SDP describing a
file transfer"><artwork>
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
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-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=file-disposition:attachment
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com
a=file-range:1-32349
</artwork></figure>
<t>
<list style='hanging'>
<t>
NOTE: The 'file-selector' attribute in the above figure is
split in three lines for formatting purposes. Real
implementations will encode it in a single line.
</t>
</list>
</t>
</section>
<section title="File Disposition Types" anchor="sec-disposition">
<t>
The SDP Offer/Answer for file transfer allows the file sender to
indicate a preferred disposition of the file to be transferred
in a new 'file-disposition' attribute. In principle, any value
listed in the IANA registry for <eref
target="http://www.iana.org/assignments/mail-cont-disp">Mail
Content Disposition Values </eref> is acceptable, however, most
of them may not be applicable.
</t>
<t>
There are two content dispositions of interest for file transfer
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 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. 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 takes an action. In any case, the exact
actions are implementation dependent.
</t>
<t>
To indicate that a file should be automatically rendered, this
memo uses the existing 'render' value of the Content Disposition
type in the new 'file-disposition' attribute in SDP. To indicate
that a file should not be automatically rendered, this memo
users the existing 'attachment' value of the Content-Disposition
type in the new 'file-disposition' attribute in SDP. The default
value is 'render', i.e., the absence of a 'file-disposition'
attribute in the SDP has the same semantics as 'render'.
</t>
<t>
<list style="hanging">
<t>
The disposition value 'attachment' is specified in <xref
target="RFC2183">RFC 2183 </xref> with the following
definition:
</t>
<t>
<list style="hanging">
<t>
"Body parts 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."
</t>
</list>
</t>
<t>
In the case of this specification, the 'attachment'
disposition type is used to indicate that the display of the
file should not be automatic, but contingent upon some
further action of the user.
</t>
</list>
</t>
</section>
<section title="Protocol Operation" anchor="sec-protocol">
<t>
This Section discusses how to use the parameters defined in
<xref target="sec-sdp-extensions"/> in the context of an
offer/answer <xref target="RFC3264"/> exchange. Additionally,
this section also discusses the behavior of the endpoints using
MSRP.
</t>
<t>
Usually the file transfer session is initiated when the offerer
sends an SDP offer to the answerer. The answerer either accepts
or rejects the file transfer session and sends an SDP answer to
the offerer.
</t>
<t>
We can differentiate two use cases, depending on whether the
offerer is the file sender or file receiver:
</t>
<t>
<list style="numbers">
<t>
The offerer is the file sender, i.e., the offerer wants to
transmit a file to the answerer. Consequently the answerer
is the file receiver. In this case the SDP offer contains a
'sendonly' attribute, and accordingly the SDP answer
contains a 'recvonly' attribute.
</t>
<t>
The offerer is the file receiver, i.e., the offerer wants to
fetch a file from the answerer. Consequently the answerer is
the file sender. In this case the SDP offer contains a
session or media 'recvonly' attribute, and accordingly the
SDP answer contains a session or media 'sendonly' attribute.
</t>
</list>
</t>
<section title="Offerer's Behavior" anchor="sec-protocol-offerer">
<t>
An offerer that wishes to send or receive one or more files to
or from an answerer MUST build an <xref target="RFC4566">SDP
</xref> description of a session containing one or more "m="
lines, each one describing an MSRP session (and thus, one file
transfer operation), according to the <xref
target="RFC4975">MSRP </xref>
procedures. All the media line attributes specified and
required by <xref
target="RFC4975">MSRP </xref> (e.g.,
"a=path", "a=accept-types", etc.) MUST be included as
well. For each file to be transferred there MUST be a separate
"m=" line.</t>
<section title="The Offerer is a File Sender" anchor="sec-protocol-offerer-sender">
<t>
In a push operation, the file sender creates and SDP offer
describing the file to be sent. The file sender MUST add a
'file-selector' attribute media line containing at least
one of the 'type', 'size', 'hash' selectors in indicating
the type, size, or hash of the file, respectively. The
file sender MUST add a 'file-transfer-id' attribute
containing a new randomly chosen identifier value, which
does not clash with other previously used values in the
same attribute. 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.
</t>
<t>
<list style="hanging">
<t>
Not all the selectors in the 'file-selector' attribute
might be known when the file sender creates the SDP
offer, for example, because the host is still
processing the file.
</t>
</list>
</t>
<t>
<list style="hanging">
<t>
The 'hash' selector in the 'file-selector' attribute
contains valuable information to the file receiver to
identify whether the file is already available and
need not be transmitted.
</t>
</list>
</t>
<t>
The file sender MAY also add a 'name' selector in the
'file-selector' attribute, and a 'file-icon',
'file-disposition', and 'file-date' attributes further
describing the file to be transferred. The 'file-disposition'
attribute provides a presentation suggestion, (for
example: the file sender would like the file receiver to
render the file or not). The three date attributes provide
the answerer with an indication of the age of the
file. The file sender MAY also add a 'file-range'
attribute indicating the start and stop offsets of the file.
</t>
<t>
When the file sender receives the SDP answer, if the port
number of the answer for a file request is non-zero, the
file sender starts the transfer of the file according to
the negotiated parameters in SDP.
</t>
</section>
<section title="The Offerer is a File Receiver" anchor="sec-protocol-offerer-receiver">
<t>
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-selector' attribute and SHOULD add,
at least, one of the selector defined for that attribute
(i.e., 'name', 'type', 'size', or 'hash'). In many
cases, if the hash of the file is known, that is enough to
identify the file, therefore, the offerer can include only
a 'hash' selector. However, 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 fetched. The
file receiver MUST also add a 'file-transfer-id' attribute
with a newly created random value (new within the current
session). The file receiver MAY also add a 'file-range'
attribute indicating the start and stop offsets of the
file. There is no need to for the file receiver 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 file receiver MUST
create an SDP offer that contains a session or media
'recvonly' attribute.
</t>
<t>
When the file receiver receives the SDP answer, if the
port number of the answer for a file request is non-zero,
then the file receiver 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 its
reception and check it against the hash received in the
answer. In case the computed hash does not match the one
contained in the SDP answer, the file receiver SHOULD
consider that the file transfer failed and SHOULD inform
the user.
</t>
</section>
<section title="SDP Offer for Several Files" anchor="sec-protocol-offerer-several">
<t>
An offerer that wishes to send or receive more than one
file 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=" lines to zero, as per
regular <xref target="RFC4566">SDP </xref>
procedures. Each file has its own file transfer
identifier, which uniquely identifies each file transfer.
</t>
<t>
Using an "m=" line per file implies that different files
are transferred using different MSRP sessions. However,
all those MSRP sessions can be set up to run over a single
TCP connection, as described in Section 8.1 of <xref
target="RFC4975">RFC 4975 </xref>. The same TCP connection
can also be re-used for sequential file transfers.
</t>
</section>
</section>
<section title="Answerer's Behavior" anchor="sec-protocol-answerer">
<t>
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 zero, as per regular <xref
target="RFC4566">SDP </xref> procedures. The rejected answer
MUST contained a 'file-selector' and 'file-transfer-id'
attributes whose values mirror the corresponding values
of the SDP offer.
</t>
<t>
If the answerer decides to accept the file, it proceeds as
per regular <xref
target="RFC4975">MSRP </xref> and
<xref target="RFC4566">SDP </xref> procedures.
</t>
<section title="The Answerer is a File Receiver" anchor="sec-protocol-answerer-receiver">
<t>
In a push operation the SDP answerer is the file
receiver. When the file receiver gets the SDP offer, it
first examines the 'file-transfer-id' attribute. If the
value of the 'file-transfer-id' attribute has been
previously used then the existing session remains without
changes, perhaps the file transfer is still in progress,
or perhaps it has concluded, but there are no change with
respect the current status. The SDP answerer creates a
regular SDP answer and sends it to the offerer.
</t>
<t>
If the SDP offer contains a new 'file-transfer-id'
attribute, then this signals a request for a new file
transfer. The SDP answerer extracts the attributes and
parameters that describe the file and typically requests
permission from the user to accept or reject the reception
of the file. If the file transfer operation is accepted,
the file receiver MUST create an SDP answer according to
the procedures specified in <xref target="RFC3264">RFC
3264</xref>. If the offer contains 'name', 'type', 'size'
selectors in the 'file-selector' attribute, the answerer
MUST copy them into the answer. The file receiver copies
the value of the 'file-transfer-id' attribute to the SDP
answer. Then the file receiver MUST add a session or media
'recvonly' attribute according to the procedures specified
in <xref target="RFC3264">RFC 3264</xref>. The file
receiver MUST NOT include 'file-icon', 'file-disposition',
or 'file-date' attributes in the SDP answer.
</t>
<t>
The file receiver can use the hash to find out if a local
file with the same hash is already available, in which
case, this could imply the reception of a duplicated
file. It is up to the answerer to determine whether the
file transfer is accepted or not in case of a duplicated
file.
</t>
<t>
If the SDP offer contains a 'file-range' attribute and the
file receiver accepts to receive the range of bytes
declared in there, the file receiver MUST include a
'file-range' attribute in the SDP answer with the same
range of values. If the file receiver does not accept the
reception of that range of bytes, it SHOULD reject the
transfer of the file.
</t>
</section>
<section title="The Answerer is a File Sender" anchor="sec-protocol-answerer-sender">
<t>
In a pull operation the answerer is the file sender. In
this case, the file sender MUST first inspect the value of
the 'file-transfer-id' attribute. If the has not been
previously been used throughout the session, then
acceptance of the file MUST provoke the transfer of the
file over the negotiated protocol. However, if the value
has been previously used by another file transfer
operation within the session, then the file sender MUST
NOT alert the user and MUST NOT start a new transfer of
the file. No matter whether an actual file transfer is
initiated or not, the file sender MUST create a proper SDP
answer that contains the 'file-transfer-id' attribute with
the same value received in the SDP offer, and then it MUST
continue processing the SDP answer.
</t>
<t>
The file sender MUST always create an SDP answer according
to the SDP offer/answer procedures specified in <xref
target="RFC3264">RFC 3264 </xref>. The file sender inspects
the file selector of the received SDP offer, which is
encoded in the 'file-selector' media attribute
line. Then the file sender applies the file selector, which implies
selecting those files that match one by one with the
'name', 'type', 'size', and 'hash' selectors of the
'file-selector' attribute line (if they are present). The
file selector identifies zero or more candidate 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 by setting the port number to zero, and then
the file sender SHOULD also reject the SDP as per
procedures in <xref target="RFC3264">RFC 3264 </xref>, if
this is the only stream described in the SDP offer.
</t>
<t>
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 SDP answer that contains a
'sendonly' attribute, according to the procedures
described <xref target="RFC3264">RFC 3264 </xref>. The
file sender SHOULD add a 'hash' selector in the answer
with the locally computed SHA-1 hash over the complete
file. If a hash value computed by the file sender differs
from that specified by the file receiver, the file sender
can either send the file without that hash value or reject
the request by setting the port in the media stream to
zero. The file sender MAY also include a 'type' selector
in the 'file-selector' attribute line of the SDP answer.
The answerer MAY also include a 'file-icon' and
'file-disposition' 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., <xref target="RFC4975">MSRP </xref>) can
accommodate a <xref target="RFC2183">Content-Disposition
header field </xref> with the equivalent parameters.
</t>
<t>
<list style="hanging">
<t>
The whole idea of adding file descriptors to SDP is to
provide a mechanism where a file transfer can be
accepted prior to its start. Adding any SDP attributes
that are otherwise signaled later in the file
transfer protocol would just duplicate the
information, but will not provide any information to
the offerer to accept or reject the file transfer
(note that the offerer is requesting a file).
</t>
</list>
</t>
<t>
Last, if the file selector points to multiple candidate
files, the answerer MAY use some local policy,
e.g. consulting the user, to choose one of them to be
defined in the SDP answer. If that choice cannot be done,
the answerer SHOULD reject the MSRP media stream for file
transfer (by setting the port number to zero).
</t>
<t>
<list style="hanging">
<t>
If the need arises, future specifications can provide
a suitable mechanism that allows to either select
multiple files or, e.g., resolve ambiguities by
returning a list of files that match the file
selector.
</t>
</list>
</t>
<t>
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 MUST include a 'file-range'
attribute in the SDP answer with 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.
</t>
</section>
</section>
<section title="The 'file-transfer-id' attribute" anchor="sec-protocol-file-transfer">
<t>
This specification creates an extension to <xref
target="RFC3264">the SDP Offer/Answer Model </xref>, and
because of that, it is assumed that the existing SDP
behavior is kept intact. The SDP behavior requires, for
example, that SDP is sent again to the remote party in
situations where the media description or perhaps other SDP
parameters have not changed with respect a previous
offer/answer exchange. Let's consider the <xref
target="RFC4028">SIP Session Timer (RFC 4028) </xref>, which
uses re-INVITE requests to refresh sessions. RFC 4028 recommends to
send unmodified SDP in a re-INVITE to refresh the
session. Should this re-INVITE contain SDP describing a file
transfer operation and occur while the file transfer was
still going on, there would be no means to detect 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).
</t>
<t>
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.
</t>
<t>
In other cases, a file transfer was successfully
completed. Then, if an endpoint re-sends the SDP offer with
the media stream for the file transfer, then the other
endpoint wouldn't be able to determine whether a new file
transfer should start or not.
</t>
<t>
To address these scenarios this specification defines the
'file-transfer-id' attribute which contains a unique file
transfer identifier. The file transfer identifier helps both
endpoints to determine whether the SDP offer is requesting a
new file transfer or it is a repetition of the SDP. A new
file transfer is one that, in case of acceptance, will
provoke the actual transfer of a file. This is typically the
case of new offer/answer exchanges, or in cases where an
endpoint wants to abort the existing file transfer and
re-start the file transfer once more. On the other hand, the
repetition of the SDP does not lead to any actual 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 repeated offer/answer exchanges, 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.).
</t>
<t>
Implementations according to this
specification MUST include a 'file-transfer-id' attribute in
SDP offers and answers. The SDP offerer MUST select a file
transfer identifier according to the syntax and add it to
the 'file-transfer-id' attribute. The SDP answerer MUST copy
the value of the 'file-transfer-id' attribute in the SDP
answer.
</t>
<t>
The file transfer identifier MUST be unique within the
current session (never used before in this session), and it
is RECOMMENDED to be unique across different sessions. It is
RECOMMENDED to select a relatively big random identifier
(e.g., 32 characters) to avoid duplications. The SDP
answerer MUST keep track of the proposed file transfer
identifiers in each session and copy the value of the
received file transfer identifier in the SDP answer.
</t>
<t>
If a file transfer is suspended and resumed at a later time,
the resumption is considered a new file transfer (even when
the file to be transferred is the same), therefore, the SDP
offerer MUST choose a new file transfer identifier.
</t>
<t>
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-id' 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-id' attribute can take.
</t>
<t>
As a side effect, the 'file-transfer-id' 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,
except for the value of the 'file-transfer-id' attribute,
which is a new value within the session. 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.
</t>
<t>
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 description that maintains the media description line
corresponding to the file transfer. The SDP offerer MUST
then set the port number to zero and MUST keep the same
value of the 'file-transfer-id' attribute that the initial
file transfer got.
</t>
</section>
<section title="Indicating File Transfer Offer/Answer Capability"
anchor="sec-capability">
<t>
<xref target="RFC3264">The SDP Offer/Answer Model </xref>
provides provisions for indicating a capability to another
endpoint (see Section 9 of <xref target="RFC3264">RFC 3264
</xref>). The mechanism assumes a high-level protocol, such
as <xref target="RFC3261">SIP </xref>, that provides a
capability query (such as a SIP OPTIONS request). <xref
target="RFC3264">RFC 3264 </xref> 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.
</t>
</section>
<section title="Re-usage of Existing m= Lines in SDP" anchor="sdp-reusage">
<t>
<xref target="RFC3264">The SDP Offer/Answer Model </xref>
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 rules of this memo. Therefore, the
procedures defined in <xref target="RFC3264"> RFC 3264
</xref>, in particular those defined in Section 8.3, MUST
apply for 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 a different value of the 'file-transfer-id' attribute.
</t>
<t>
If the file offerer re-sends an SDP offer with a port
different than zero, then the 'file-transfer-id' attribute
determines whether a new 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).
</t>
</section>
<section title="MSRP Usage" anchor="sec-protocol-msrp">
<t>
The file transfer service specified in this document uses
"m=" lines to describe the unidirectional transfer of a
file. Consequently, each MSRP session established following
the procedures in <xref target="sec-protocol-offerer"/> and
<xref target="sec-protocol-answerer"/> is only used to
transfer a single file. So, senders MUST only use the
dedicated MSRP session to send the file described in the SDP
offer or answer. That is, senders MUST NOT send additional
files over the same MSRP session.
</t>
<t>
File transfer may be accomplished using a new multimedia
session established for the purpose. Alternatively a file
transfer may be conducted within an existing multimedia
session, without regard for the media in use within that
session. Of particular note, file transfer may be done
within a multimedia session containing an MSRP session used
for regular instant messaging. If file transfer is
initiated within an existing multimedia session, the SDP
offerer MUST NOT reuse an existing "m=" line that is still
being used by MSRP (either regular MSRP for instant
messaging or an ongoing file transfer). Rather it MUST add
an addtional "m=" line or else reuse an "m=" line that is no
longer being used.
</t>
<t>
Additionally, implementations according to this
specification MUST include a single file in a single MSRP
message. Notice that the MSRP specification defines "MSRP
message" as a complete unit of MIME or text content, which
can be split and delivered in more than one MSRP request;
each of these portions of the complete message is called a
"chunk". So, it is still valid to send a file in several
chunks, but from the MSRP point of view, all the chunks
together form an MSRP message: the CPIM message that wraps
the file. When chunking, notice that MSRP does not require
to wait for a 200-class response for a chunk before sending
the following one. Therefore, it is valid to send pipelined
MSRP SEND requests containing chunks of the same MSRP
message (the file). <xref target="sec-examples-push-file"/>
contains an example of a file transfer using pipelined MSRP
requests.
</t>
<t>
The <xref target="RFC4975">MSRP
specification </xref> 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.
</t>
<t>
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 last byte (i.e., the whole file is
transferred). If a 'file-range' attribute is present in SDP,
the file sender application MUST extract the indicated range
of bytes from the file (start and stop offset bytes). Then
the file sender application MAY wrap those bytes in an
appropriate wrapper. MSRP mandates implementations to
implement the <xref target="RFC3862">message/cpim wrapper
</xref>. Usage of a wrapper is negotiated in the SDP (see
Section 8.6 in <xref target="RFC4975">RFC 4975
</xref>). Last, the file sender application delivers the
content (e.g., the message/cpim body) to MSRP for
transportation. MSRP will consider the delivered content as
a whole message, and will start numbering bytes with the
number 1.
</t>
<t>
Note that the default content disposition of MSRP bodies is
'render'. When MSRP is used to transfer files, the MSRP
Content-Disposition header can also take the value
'attachment' as indicated in <xref target="sec-disposition"/>.
</t>
<t>
Once the file transfer is completed, the file sender SHOULD
close the MSRP session, and MUST behave according to the
<xref target="RFC4975">MSRP </xref>
procedures with respect closing MSRP sessions.
</t>
</section>
<section title="Considerations about the 'file-icon'
attribute" anchor="sec-file-icon">
<t>
This specification allows a file sender to include a small
preview of an image file: an icon. A 'file-icon' attribute
contains a <xref target="RFC2392">CID URL </xref> 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 MUST wrap the SDP body and the
icon bodies in a MIME multipart/related
body. Therefore, implementations according to this
specification MUST implement the <xref
target="RFC2387">multipart/related MIME type </xref>. When
creating a multipart/related MIME wrapper, the SDP body MUST
be the root body, which according to <xref
target="RFC2387">RFC 2387 </xref> is identified as the first
body in the multipart/related MIME wrapper or explicitly
identified by the 'start' parameter. According to <xref
target="RFC2387">RFC 2387 </xref>, the 'type' parameter MUST
be present and point to the root body, i.e., the SDP body.
</t>
<t>
Assume that an endpoint behaving according to this
specification tries to send a file to a remote endpoint that
neither implements this specification nor implements
multipart MIME bodies. The file sender sends an SDP offer
that contains a multipart/related MIME body that includes an
SDP body part and an icon body part. The file receiver, not
supporting multipart MIME types, will reject the SDP offer,
via a higher protocol mechanism (e.g., SIP). 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-sends the SDP offer again. This provides some
backwards compatibility with file receives that do not
implement this specification and increases the chances of
getting the SDP accepted at the file receiver.
</t>
<t>
Since the icon is sent as part of the signaling, it is
recommended to keep icons restricted to the minimum number
of bytes that provide significance.
</t>
</section>
</section>
<section title="Examples" anchor="sec-examples">
<section title="Offerer sends a file to the Answerer" anchor="sec-examples-push-file">
<t>
This section shows an example flow for a file transfer
scenario. The example assumes that <xref
target="RFC3261">SIP </xref> is used to transport the SDP
offer/answer exchange, although the SIP details are briefly
shown in the sake of brevity.
</t>
<t>
Alice, the SDP offerer, wishes to send an image file to Bob
(the answerer). Alice's User Agent Client (UAC) creates a
unidirectional 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 an icon representing
the contents of the file to be transferred. The sequence
flow is shown in <xref target="fig-push-file-flow"/>.
</t>
<figure anchor="fig-push-file-flow" title="Flow diagram of an
offerer sending a
file to an
answerer"
align="center">
<artwork><![CDATA[
Alice's UAC Bob's UAS
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
| |
|(4) (MSRP) SEND (chunk) |
|----------------------->|
|(5) (MSRP) SEND (chunk) |
|----------------------->|
|(6) (MSRP) 200 OK |
|<-----------------------|
|(7) (MSRP) 200 OK |
|<-----------------------|
| |
|(8) (SIP) BYE |
|----------------------->|
|(9) (SIP) 200 OK |
|<-----------------------|
| |
| |
]]>
</artwork></figure>
<t>
F1: Alice constructs an SDP description of the file to be
sent and attaches it to a SIP INVITE request addressed to
Bob.
</t>
<figure anchor="fig-invite-1" title="INVITE request containing an SDP
offer for file
transfer"><artwork><![CDATA[
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
boundary="boundary71"
Content-Length: [length]
--boundary71
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
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-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
a=file-disposition:render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
[...small preview icon of the file...]
--boundary71--
]]>
</artwork></figure>
<t>
<list style='hanging'>
<t>
NOTE: The Content-Type header field and the
'file-selector' attribute in the above figure are split
in several lines for formatting purposes. Real
implementations will encode it in a single line.
</t>
</list>
</t>
<t>
From now on we omit the SIP details for the sake of brevity.
</t>
<t>
F2: Bob receives the INVITE request, inspects the SDP offer and
extracts the icon body, checks the creation date and file size, and
decides to accept the file transfer. So Bob creates the following SDP
answer:
</t>
<figure anchor="fig-sdp-1" title="SDP answer accepting the SDP offer
for file
transfer"><artwork><![CDATA[
v=0
o=bob 2890844656 2890844656 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
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-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
]]>
</artwork></figure>
<t>
<list style='hanging'>
<t>
NOTE: The 'file-selector' attribute in the above figure
is split in three lines for formatting purposes. Real
implementations will encode it in a single line.
</t>
</list>
</t>
<t>
F4: Alice opens a TCP connection to Bob and creates an MSRP SEND
request. This SEND request contains the first chunk of the file.
</t>
<figure anchor="fig-msrp-send-1" title="MSRP SEND request
containing the first
chunk of actual
file"><artwork><![CDATA[
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2048/4385
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool picture.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300";
size=4092
Content-Type: image/jpeg
... first set of bytes of the JPEG image ...
-------d93kswow+
]]>
</artwork></figure>
<t>
F5: Alice sends the second and last chunk. Note that MSRP
allows to send pipelined chunks, so there is no need to wait
for the 200 (OK) response from the previous chunk.
</t>
<figure anchor="fig-msrp-send-2" title="MSRP SEND request
containing the second
chunk of actual
file"><artwork><![CDATA[
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 2049-4385/4385
Content-Type: message/cpim
... second set of bytes of the JPEG image ...
-------op2nc9a$
]]>
</artwork></figure>
<t>
F6: Bob acknowledges the reception of the first chunk.
</t>
<figure anchor="fig-msrp-200-1" title="MSRP 200 OK
response"><artwork><![CDATA[
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4385
-------d93kswow$
]]>
</artwork></figure>
<t>
F7: Bob acknowledges the reception of the second chunk.
</t>
<figure anchor="fig-msrp-200-2" title="MSRP 200 OK
response"><artwork><![CDATA[
MSRP op2nc9a 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 2049-4385/4385
-------op2nc9a$
]]>
</artwork></figure>
<t>
F8: Alice terminates the SIP session by sending a SIP BYE request.
</t>
<t>
F9: Bob acknowledges the reception of the BYE request and sends a 200
(OK) response.
</t>
</section>
<section title="Offerer requests a file from the Answerer and second
file transfer" anchor="sec-examples-fetch-file">
<t>
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 she wants to download. She has
learned the hash of the file by some out-of-band
mechanism. The hash selector is enough to produce a file
selector that points to the specific file. So, Alice creates
an SDP offer that contains the file descriptor. Bob accepts
the 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. Therefore Alice re-uses the existing SDP
media line with different attributes and updates the
description of the new file she wants to send to Bob's User
Agent Server (UAS). In particular, Alice creates a new file
transfer identifier since this is a new file transfer
operation. <xref target="fig-fetch-file-flow" />
shows the sequence flow.
</t>
<figure anchor="fig-fetch-file-flow" title="Flow diagram of an
offerer requesting
a file from the
answerer and then
sending a file to
the answer"
align="center">
<artwork><![CDATA[
Alice's UAC Bob's UAS
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
| |
|(4) (MSRP) SEND (file) |
|<-----------------------|
|(5) (MSRP) 200 OK |
|----------------------->|
| |
|(6) (SIP) INVITE |
|----------------------->|
|(7) (SIP) 200 OK |
|<-----------------------|
|(8) (SIP) ACK |
|----------------------->|
| |
|(9) (MSRP) SEND (file) |
|----------------------->|
|(10) (MSRP) 200 OK |
|<-----------------------|
| |
|(11) (SIP) BYE |
|<-----------------------|
|(12) (SIP) 200 OK |
|----------------------->|
| |
| |
]]>
</artwork></figure>
<t>
F1: Alice constructs an SDP description of the file she
wants to receive and attaches the SDP offer to a SIP INVITE
request addressed to Bob.
</t>
<figure anchor="fig-invite-2" title="INVITE request containing
an SDP offer for file
transfer">
<artwork><![CDATA[
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
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-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
]]></artwork></figure>
<t>
<list style='hanging'>
<t>
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.
</t>
</list>
</t>
<t>
From now on we omit the SIP details for the sake of brevity.
</t>
<t>
F2: Bob receives the INVITE request, inspects the SDP offer,
computes the file descriptor and finds a local file whose
hash equals the one indicated in the SDP. Bob accepts the
file transmission and creates an SDP answer as follows:
</t>
<figure anchor="fig-sdp-2" title="SDP answer accepting the SDP
offer for file
transfer">
<artwork><![CDATA[
v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:type:image/jpeg 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-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
]]></artwork></figure>
<t>
<list style='hanging'>
<t>
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.
</t>
</list>
</t>
<t>
F4: Alice opens a TCP connection to Bob. Bob then creates an
MSRP SEND request that contains the file.
</t>
<figure anchor="fig-msrp-send-3" title="MSRP SEND request
containing the actual
file">
<artwork>
<![CDATA[
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool photo.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300";
modification-date="Mon, 15 May 2006 16:04:53 +0300";
read-date="Mon, 16 May 2006 09:12:27 +0300";
size=1931
Content-Type: image/jpeg
...binary JPEG image...
-------d93kswow$
]]></artwork></figure>
<t>
F5: Alice acknowledges the reception of the SEND request.
</t>
<figure anchor="fig-msrp-200-3" title="MSRP 200 OK
response">
<artwork>
<![CDATA[
MSRP d93kswow 200 OK
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
Byte-Range: 1-2027/2027
-------d93kswow$
]]></artwork></figure>
<t>
F6: Alice re-uses the existing SDP media line inserting the
description of the file to be sent and attaches it to a SIP
re-INVITE request addressed to Bob. Alice reuses the TCP
port number for the MSRP stream, but changes the MSRP
session and the 'file-transfer-id' value according to this
specification.
</t>
<figure anchor="fig-invite-3" title="Reuse of the SDP in a
second file
transfer">
<artwork><![CDATA[
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>;tag=1928323431
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 2 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:33 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
boundary="boundary71"
Content-Length: [length of multipart]
--boundary71
Content-Type: application/sdp
Content-Length: [length of SDP]
v=0
o=alice 2890844526 2890844527 IN IP4 alicepc.example.com
s=
c=IN IP4 alicepc.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/iau39;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
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-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300"
a=file-icon:cid:id3@alicepc.example.com
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id3@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
[..small preview icon...]
--boundary71--
]]>
</artwork></figure>
<t>
<list style='hanging'>
<t>
NOTE: The Content-Type header field and the
'file-selector' attribute in the above figure are split
in several lines for formatting purposes. Real
implementations will encode it in a single line.
</t>
</list>
</t>
<t>
F7: Bob receives the re-INVITE request, inspects the SDP
offer and extracts the icon body, checks the creation date
and file size, and decides to accept the file transfer. So
Bob creates an SDP answer where he reuses the same TCP port
number, but changes his MSRP session, according to the
procedures of this specification.
</t>
<figure anchor="fig-sdp-3" title="SDP answer accepting the SDP
offer for file
transfer">
<artwork><![CDATA[
v=0
o=bob 2890844656 2890855440 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
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-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
]]>
</artwork></figure>
<t>
<list style='hanging'>
<t>
NOTE: The 'file-selector' attribute in the above figure is
split in three lines for formatting purposes. Real
implementations will encode it in a single line.
</t>
</list>
</t>
<t>
F9: If a TCP connection towards Bob is already open, Alice
re-uses that TCP connection to send an MSRP SEND request
that contains the file.
</t>
<figure anchor="fig-msrp-send-4" title="MSRP SEND request
containing the actual
file">
<artwork><![CDATA[
MSRP d95ksxox SEND
To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 13449sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-21T13:02:15-03:00
Content-Disposition: render; filename="Sunset.jpg";
creation-date="Sun, 21 May 2006 13:02:15 -0300";
size=1931
Content-Type: image/jpeg
...binary JPEG image...
-------d95ksxox+
]]></artwork></figure>
<t>
F10: Bob acknowledges the reception of the SEND request.
</t>
<figure anchor="fig-msrp-200-4" title="MSRP 200 OK
response">
<artwork><![CDATA[
MSRP d95ksxox 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
Byte-Range: 1-2027/2027
-------d95ksxox$
]]></artwork></figure>
<t>
F11: Then Bob terminates the SIP session by sending a
SIP BYE request.
</t>
<t>
F12: Alice acknowledges the reception of the BYE request
and sends a 200 (OK) response.
</t>
</section>
<section title="Example of a capability indication">
<t>
Alice sends an OPTIONS request to Bob (this request does
not contain SDP). Bob answers with a 200 (OK) response
that contain the SDP shown in <xref
target="fig-200-ok-options" />. The SDP indicates
support for CPIM messages that can contain other 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/answer mechanism.
</t>
<figure anchor="fig-capability-request" title="Flow diagram of a
capability request"
align="center">
<artwork><![CDATA[
Alice's UAC Bob's UAS
| |
|(1) (SIP) OPTIONS |
|----------------------->|
|(2) (SIP) 200 OK |
| with SDP |
|<-----------------------|
| |
| |
]]></artwork></figure>
<figure anchor="fig-200-ok-options" title="SDP of the 200 (OK)
response to an OPTIONS
request">
<artwork><![CDATA[
v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=-
c=IN IP4 bobpc.example.com
t=0 0
m=message 0 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=max-size:20000
a=file-selector
]]></artwork></figure>
</section>
</section>
<section title="Security Considerations" anchor="sec-security">
<t>
The SDP attributes defined in this specification identify a
file to be transferred between two endpoints. An endpoint can
offer to send the file to the other endpoint or request to
receive the file from the other endpoint. In the former case,
an attacker modifying those SDP attributes could cheat the
receiver making it think that the file to be transferred was a
different one. In the latter case, the attacker could make the
sender send a different file than the one requested by the
receiver. Consequently, it is RECOMMENDED that integrity
protection be applied to the SDP session descriptions carrying
the attributes specified in this specification.
</t>
<t>
The descriptions of the files being transferred between
endpoints may reveal information the endpoints may consider
confidential. Therefore, it is RECOMMENDED that SDP session
descriptions carrying the attributes specified in this
specification be encrypted.
</t>
<t>
TLS and S/MIME are the natural choices to provide offer/answer
exchanges with integrity protection and confidentiality.
</t>
<t>
It is possible that a malicious or misbehaving implementation
tries to exhaust the resources of the remote endpoint, e.g.,
the internal memory or the file system, by sending very large
files. To protect from this attack an SDP answer SHOULD first
verify the identity of the SDP offerer, and perhaps, only
accept file transfers from trusted sources. Mechanisms to
verify the identity of the file sender depend on the high-level
protocol that carries the SDP, for example, <xref
target="RFC3261">SIP </xref> and <xref target="RFC4975">MSRP
</xref>.
</t>
<t>
It is also RECOMMENDED that implementations take measurements
to avoid attacks on resource exhaustion, for example, by
limiting the size of receive files, verifying that there is
enough space in the file system to store the file prior to its
reception, or limiting the number of simultaneous file
transfers.
</t>
<t>
File receivers MUST also sanitize all input, such as the local
file name, prior to making calls to the local file system to
store a file. This is to prevent the existence of meaningful
characters to the local operating system that could damage it.
</t>
<t>
Once a file has been transferred the file receiver must take
care with it. Typically file transfer is a commonly used
mechanism for transmitting computer virus, spyware, and other
types of malware. File recipients should apply all possible
security technologies (e.g., antivirus, antispaware, etc.) to
dismiss the risk of damage at their host.
</t>
</section>
<section title="IANA Considerations" anchor="sec-iana">
<t>
This document instructs IANA to register a number of SDP
attributes according to the following:
</t>
<section title="Registration of new SDP attributes"
anchor="sec-iana-sdp">
<t>
This memo provides instructions to IANA to register a number
of media level only attributes in the <eref
target="http://www.iana.org/assignments/sdp-parameters">Session
Description Protocol Parameters registry </eref>. The
registration data, according to <xref target="RFC4566">RFC
4566</xref> follows.
</t>
<t>
<list style="hanging">
<t>
Note to the RFC Editor: replace "RFC XXXX" with the RFC
number of this specification.
</t>
</list>
</t>
<section title="Registration of the file-selector attribute">
<t>
<list>
<t>Contact: Miguel Garcia <miguel.garcia@nsn.com></t>
<t>Phone: +358 71400 4000</t>
<t>Attribute name: file-selector</t>
<t>Long-form attribute name: File Selector</t>
<t>Type of attribute: media level only </t>
<t>This attribute is subject to the charset attribute</t>
<t>Description: This attribute unambiguously identify a file by
indicating a combination of the 4-tuple composed of the name, size,
type, and hash of the file.</t>
<t>Specification: RFC XXXX</t>
</list>
</t>
</section>
<section title="Registration of the file-transfer-id attribute">
<t>
<list>
<t>Contact: Miguel Garcia <miguel.garcia@nsn.com></t>
<t>Phone: +358 71400 4000</t>
<t>Attribute name: file-transfer-id</t>
<t>Long-form attribute name: File Transfer Identifier</t>
<t>Type of attribute: media level only </t>
<t>This attribute is subject to the charset attribute</t>
<t>Description: This attribute contains a unique
identifier of the file transfer operation within the
session. </t>
<t>Specification: RFC XXXX</t>
</list>
</t>
</section>
<section title="Registration of the file-disposition attribute">
<t>
<list>
<t>Contact: Miguel Garcia <miguel.garcia@nsn.com></t>
<t>Phone: +358 71400 4000</t>
<t>Attribute name: file-disposition</t>
<t>Long-form attribute name: File Disposition</t>
<t>Type of attribute: media level only </t>
<t>This attribute is not subject to the charset attribute</t>
<t>Description: This attribute provides a suggestion to the other
endpoint about the intended disposition of the file</t>
<t>Specification: RFC XXXX</t>
</list>
</t>
</section>
<section title="Registration of the file-date attribute">
<t>
<list>
<t>Contact: Miguel Garcia <miguel.garcia@nsn.com></t>
<t>Phone: +358 71400 4000</t>
<t>Attribute name: file-date</t>
<t>Long-form attribute name: </t>
<t>Type of attribute: media level only </t>
<t>This attribute is not subject to the charset attribute</t>
<t>Description: This attribute indicates the dates at
which the file was created, modified, or last read. </t>
<t>Specification: RFC XXXX</t>
</list>
</t>
</section>
<section title="Registration of the file-icon attribute">
<t>
<list>
<t>Contact: Miguel Garcia <miguel.garcia@nsn.com></t>
<t>Phone: +358 71400 4000</t>
<t>Attribute name: file-icon</t>
<t>Long-form attribute name: File Icon</t>
<t>Type of attribute: media level only </t>
<t>This attribute is not subject to the charset attribute</t>
<t>Description: For image files, this attribute contains a pointer
to a body that includes a small preview icon representing the
contents of the file to be transferred</t>
<t>Specification: RFC XXXX</t>
</list>
</t>
</section>
<section title="Registration of the file-range attribute">
<t>
<list>
<t>Contact: Miguel Garcia <miguel.garcia@nsn.com></t>
<t>Phone: +358 71400 4000</t>
<t>Attribute name: file-range</t>
<t>Long-form attribute name: File Range</t>
<t>Type of attribute: media level only </t>
<t>This attribute is not subject to the charset attribute</t>
<t>Description: it contains the range of transferred
bytes of the file</t>
<t>Specification: RFC XXXX</t>
</list>
</t>
</section>
</section>
</section>
<section title="Acknowledgements" anchor="sec-acks">
<t>
The authors would like to thank Mats Stille, Nancy Greene,
Adamu Haruna, and Arto Leppisaari for discussing initial
concepts described in this memo. Thanks to Pekka Kuure for
reviewing initial versions this document and providing helpful
comments. Joerg Ott, Jiwey Wang, Amitkumar Goel, Sudha Vs, Dan
Wing, Juuso Lehtinen, Remi Denis-Courmont, Colin Perkins,
Sudhakar An, Peter Saint-Andre, Jonathan Rosenberg, and Eric
Rescorla discussed and provided comments and improvements to
this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to
Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott
Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723'
target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486'
target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661'
target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?rfc include="reference.RFC.2045"?>
<?rfc include="reference.RFC.2183"?>
<?rfc include="reference.RFC.2387"?>
<?rfc include="reference.RFC.2392"?>
<?rfc include="reference.RFC.2822"?>
<?rfc include="reference.RFC.3174"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.3629"?>
<?rfc include="reference.RFC.3851"?>
<?rfc include="reference.RFC.3862"?>
<?rfc include="reference.RFC.4234"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.4975"?>
</references>
<references title="Informational References">
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.4028"?>
<?rfc include="reference.RFC.4483"?>
<?rfc include="reference.RFC.4976"?>
<?rfc include="reference.I-D.ietf-rmt-flute-revised"?>
</references>
</back>
</rfc>
<!-- LocalWords: xref CDATA -->
<!-- Changes in version -05
- Typo in Section 10:
s/The SDP attributed/The SDP attributes
-->| PAFTECH AB 2003-2026 | 2026-04-23 11:00:17 |