WDIFF

draft-ietf-mmusic-file-transfer-mech-06.txt --> draft-ietf-mmusic-file-transfer-mech-07.txt

MMUSIC Working Group M. Garcia-Martin
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track M. Isomaki
Expires: June 23, September 28, 2008 Nokia
G. Camarillo
S. Loreto
Ericsson
P. Kyzivat
Cisco Systems
December 21, 2007
March 27, 2008

A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable
File Transfer
draft-ietf-mmusic-file-transfer-mech-06.txt
draft-ietf-mmusic-file-transfer-mech-07.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 23, September 28, 2008.

Abstract

This document provides a mechanism to negotiate the transfer of one

Garcia-Martin, et al. Expires June 23, 2008 [Page 1]

Internet-Draft SDP offer/answer for file transfer December 2007
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

Garcia-Martin, et al. Expires September 28, 2008 [Page 1]

Internet-Draft SDP offer/answer for file transfer March 2008

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.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 2]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Alternatives Considered . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 5
5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 8 7
6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9 8
7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 15 13
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15 14
8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 16 14
8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 16 15
8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 17 15
8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 18 16
8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 18 16
8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 18 17
8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 19 18
8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 21 19
8.4. Aborting an ongoing file transfer operation . . . . . . . 21
8.5. Indicating File Transfer Offer/Answer Capability . . . . . 23
8.5. 22
8.6. Re-usage of Existing m= "m=" Lines in SDP . . . . . . . . . . . 23
8.6. 22
8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23
8.7.
8.8. Considerations about the 'file-icon' attribute . . . . . . 25 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
file transfer . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Example of a capability indication . . . . . . . . . . . . 37
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. Registration of new SDP attributes . . . . . . . . . . . . 39
11.1.1. Registration of the file-selector attribute . . . . . 39
11.1.2. Registration of the file-transfer-id attribute . . . . 40
11.1.3. Registration of the file-disposition attribute . . . . 40
11.1.4. Registration of the file-date attribute . . . . . . . 40
11.1.5. Registration of the file-icon attribute . . . . . . . 41
11.1.6. Registration of the file-range attribute . . . . . . . 41
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
13.2. Informational References . . . . . . . . . . . . . . . . . 42
Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 45
Intellectual Property and Copyright Statements . . . . . . . . . . 45 46

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 3]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

1. Introduction

The Session Description Protocol (SDP) Offer/Answer [RFC3264]
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.

The Message Session Relay Protocol (MSRP) [RFC4975] 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) 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
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. MSRP
relays [RFC4976] provide a mechanism for Network Address Translator
(NAT) traversal. Finally, Secure MIME (S/MIME) [RFC3851] can be used
for ensuring the integrity and confidentiality of the transferred
content.

However, the baseline MSRP does not readily meet all the requirements
for file transfer services within multimedia sessions. There are
four main missing features:

o The recipient must be able to distinguish "file transfer" from
"file attached to IM", allowing the recipient to treat the cases
differently.
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
decline it, using the meta information in the request. The actual
transfer must take place only after acceptance by the recipient.
o It must be possible for the sender to pass some meta information
on the file before the actual transfer. This must be able to
include at least content type, size, hash and name of the file, as
well as a short (human readable) description.
o 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.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 4]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

The rest of this document is organized as follows. Section 3 defines
a few terms used in this document. Section 4 provides the overview
of operation. Section 5 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
Section 6. Section 7 discusses the file disposition types.
Section 8 describes the protocol operation involving SDP and MSRP.
Finally, some examples are given in Section 9.

1.1. Alternatives Considered

2. Terminology

The requirements key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are related to be interpreted as described in BCP 14, RFC 2119
[RFC2119].

3. Definitions

For the description and negotiation purpose of this document, the session, not following definitions specified
in RFC 3264 [RFC3264] apply:

o Answer
o Answerer
o Offer
o Offerer

Additionally, we define the following terms:

File sender: The endpoint that is willing to send a file to the actual
file transfer mechanism. Thus, it is
natural receiver.
File receiver: The endpoint that in order to meet them it is enough to define attribute
extensions and usage conventions willing to SDP, while MSRP itself needs no
extensions and can be used as it is. This is effectively receive a file from
the
approach taken file sender.
File selector: A tuple of file attributes that the SDP offerer
includes in this specification. Another goal has been to
specify the SDP extensions in such a way that order to select a regular MSRP endpoint
which does not support them could still file at the SDP answerer.
This is described in some cases act as an
endpoint more detail in a Section 5.
Push operation: A file transfer session, albeit with a somewhat reduced
functionality.

In some ways operation where the aim SDP offerer
takes the role of this specification is similar to the aim file sender and the SDP answerer takes role
of
content indirection mechanism in the Session Initiation Protocol
(SIP) [RFC4483]. Both mechanisms allow a user agent to decide
whether or not to download a file based on information about receiver.
Pull operation: A file transfer operation where the
file. However, there are some differences. With content
indirection, it is not possible SDP offerer
takes the role of the file receiver and the SDP answerer takes the
role of the file sender.

4. Overview of Operation

An SDP offerer creates an SDP body that contains the description of

Garcia-Martin, et al. Expires September 28, 2008 [Page 5]

Internet-Draft SDP offer/answer for file transfer March 2008

one or more files that the other endpoint offerer wants to explicitly 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.

The actual file transfer. Also, it transfer is not possible for carried out using the Message Session
Relay Protocol (MSRP) [RFC4975]. Each SDP "m=" line describes an
endpoint
MSRP media stream used to request transfer a single file from another endpoint. Furthermore,
content indirection is not tied to at a time. That is,
the context transfer of a multiple simultaneous files requires multiple "m="
lines and corresponding MSRP media session,
which is sometimes streams. It should be noted that
multiple MSRP media streams can share a desirable property. Finally, content
indirection typically requires some server infrastructure, which may single transport layer
connection, so this mechanism will not always be available. It is possible lead to excessive 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
transport resources.

Each "m=" line for an MSRP media stream is accompanied with a few
attributes describing the
requirements.

Based on file to be transferred. If the argumentation above, this document defines file sender
generates the SDP
attribute extensions offer, the attributes describe a local file to be
sent (push), and usage conventions needed for meeting the
requirements on file transfer services with receiver can use this information to either
accept or reject the transfer. However, if the SDP offer/answer
model, using MSRP as offer is
generated by the transfer protocol within file receiver, the session.

Garcia-Martin, et al. Expires June 23, 2008 [Page 5]

Internet-Draft SDP offer/answer for attributes are intended to
characterize a particular file transfer December 2007

In principle it that the file receiver is possible willing to use
get (pull) from the SDP extensions defined here
and replace MSRP with any other similar protocol file sender. It is possible 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 file sender
does not have a matching file or does not want to be negotiated on an send the file, in
which case the offer is rejected.

The attributes describing each file are provided in SDP offer/answer exchange
(RFC 3264 [RFC3264]), be able to carry MIME objects between two
endpoints, and use a reliable transport protocol (e.g., TCP).

This specification defines by a set of
new SDP attributes that describe a
file to be transferred between two endpoints. The information needed attributes, most of which have been directly borrowed from
MIME. This way, user agents can decide whether or not to describe accept a
given file could be potentially encoded in a few different
ways. The MMUSIC working group considered a few alternative
approaches before deciding to use the encoding described in
Section 6. In particular, the working group looked at transfer based on the MIME
'external-body' type and file's name, size, description,
hash, icon (e.g., if the use of file is a single picture), etc.

SDP attribute or
parameter.

A MIME 'external-body' could potentially be direction attributes (e.g., 'sendonly', 'recvonly') are used to describe
indicate the file
to be transferred. In fact, many direction of the transfer, i.e., whether the SDP parameters this
specification defines are also supported by 'external-body' body
parts. The MMUSIC working group decided not offerer
is willing to use 'external-body'
body parts because a number send of existing offer/answer implementations
do not support multipart bodies.

The information carried in receive the SDP attributes defined in Section 6
could potentially be encoded in a single SDP attribute. The MMUSIC
working group decided not to follow this approach because it is
expected file. Assuming that implementations support only a subset the answerer
accepts the file transfer, the actual transfer of the parameters
defined in Section 6. Those implementations will be able files takes
place with ordinary MSRP. Note that the 'sendonly' and 'recvonly'
attributes refer to use the direction of MSRP SEND requests and do not
preclude other protocol elements (such as 200 responses, REPORT
requests, etc.).

In principle the file transfer can work even with an endpoint
supporting only regular SDP rules in order to ignore non-supported SDP parameters.
If all MSRP without understanding the information was encoded extensions
defined herein, in a single particular case where that endpoint is both
the SDP attribute, those
rules, which relate to backwards compatibility, answerer and the file receiver. The regular MSRP endpoint
answers the offer as it would need answer any ordinary MSRP offer
without paying attention to the extension attributes. In such a
scenario the user experience would, however, be
redefined specifically reduced, since the
recipient would not know (by any protocol means) the reason for that parameter.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
the session and "OPTIONAL" in this
document are to would not be interpreted as described in BCP 14, RFC 2119
[RFC2119].

3. Definitions

For the purpose of this document, able to accept/reject it based on the following definitions specified
in RFC 3264 [RFC3264] apply:

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 6]

Internet-Draft SDP offer/answer for file transfer December 2007

o Answer
o Answerer
o Offer
o Offerer

Additionally, we define the following terms: March 2008

file attributes.

5. File sender: The endpoint that selector

When the SDP offerer is willing to send a the file the offer needs to unambiguously
identify the requested file. For this purpose we introduce the
notion of a file receiver.
File receiver: The endpoint that selector, which is willing to receive a file from tuple composed of one or more
of the following individual selectors: the name, size, type, and hash
of the file. The file sender.
File selector: A tuple selector can include any number of selectors,
so all four of them do not always need to be present.

The purpose of the file attributes selector is to provide enough information
about the file to the remote entity, so that both the SDP offerer
includes in local and the SDP in order
remote entity can refer to select a the same file. The file at selector is
encoded in a 'file-selector' media attribute in SDP. The formal
syntax of the SDP answerer.
This 'file-selector' media attribute is described in more detail in Section 5.
Push operation: A
Figure 1.

The file transfer operation where the SDP offerer
takes selection process is applied to all the role of available files at
the host. The process selects those file sender and the SDP answerer takes role that match each of the file receiver.
Pull operation: A file transfer operation where
selectors present in the SDP offerer
takes 'file-selector' attribute. The result can
be zero, one, or more files, depending on the role presence of the file receiver and
mentioned selectors in the SDP answerer takes the
role of and depending on the available files
in a host. The file sender.

4. Overview of Operation

An SDP offerer creates an SDP body transfer mechanism specified in this document
requires that contains a file selector eventually results at most in a single
file to be chosen. Typically, if the description of
one or more files hash selector is known, it is
enough to produce a file selector that the offerer wants points to send exactly zero or receive. The
offerer sends one
file. However, a file selector that selects a unique file is not
always known by the SDP offer to offerer. Sometimes only the remote endpoint. The SDP answerer
can accept name, size or reject the transfer of each type
of those files.

The actual file transfer is carried out using are known, so the Message Session
Relay Protocol (MSRP) [RFC4975]. Each SDP "m=" line describes file selector may result in selecting more
than one file, which is an
MSRP media stream used to transfer a single undesired case. The opposite is also
true: if the file at selector contains a time. That is,
the transfer of multiple simultaneous files requires multiple "m="
lines hash selector 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.

Each "m=" line for an MSRP media stream name
selector, there is accompanied with a few
attributes describing risk that the file to be transferred. If remote host has renamed the file,
in which case, although a file sender
generates whose computed hash equals the SDP offer, hash
selector exists, the attributes describe a local file to be
sent (push), and name does not match that of the name
selector, thus, the file receiver can use selection process will result in the
selection of zero files.

This specification uses the Secure Hash Algorithm 1, SHA-1 [RFC3174].
If future needs require adding support for different hashing
algorithms, they will be specified as extensions to this information document.

Implementations according to either
accept or reject this specification MUST implement the transfer. However, if
'file-selector' attribute and MAY implement any of the other
attributes specified in this specification. SDP offer is
generated by the offers and answers
for file receiver, the attributes are intended to
characterize transfer MUST contain a particular file that the file receiver is willing to
get (pull) from the file sender. It is possible 'file-selector' media attribute that
selects the file sender
does not have a matching file or does not want to send the file, in
which case be transferred and MAY contain any of the offer is rejected. other

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 7]

Internet-Draft SDP offer/answer for file transfer December 2007

The March 2008

attributes describing each specified in this specification.

The 'file-selector' media attribute is also useful when learning the
support of the file are provided transfer offer/answer capability that this
document specifies. This is further explained in Section 8.5.

6. Extensions to SDP by

We define a set number of new SDP attributes, most of which have been directly borrowed from
MIME. This way, user agents can decide whether or not [RFC4566] attributes that provide the
required information to accept describe the transfer of a
given file transfer based on the file's name, size, description,
hash, icon (e.g., if with MSRP.
These are all media level only attributes in SDP. The following is
the file formal ABNF syntax [RFC5234] of these new attributes. It is a picture), etc.

SDP direction attributes (e.g., 'sendonly', 'recvonly') are used to
indicate the direction of the transfer, i.e., whether
built above 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 [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183
[RFC2183], RFC 2392 [RFC2392], and do not
preclude other protocol elements (such as 200 responses, REPORT
requests, etc.).

In principle the file transfer can work even with an endpoint
supporting only regular MSRP without understanding the extensions RFC 2822 [RFC2822].

attribute = file-selector-attr / file-disp-attr /
file-tr-id-attr / file-date-attr /
file-icon-attr / file-range-attr
;attribute is 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.

5. File RFC 4566

file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector

Specially = filename-selector / filesize-selector /
filetype-selector / hash-selector

filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE defined 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 RFC 5234
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 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.

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 RFC 5234

filesize-selector = "size:" filesize-value
filesize-value = integer ;integer defined in SDP. The
formal syntax of the 'file-selector' media attribute is described RFC 4566

filetype-selector = "type:" type "/" subtype *(";"parameter)
; parameter defined in
Figure 1.

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 RFC 2045
type = token ; token defined in the 'file-selector' attribute. Thus, a 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

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 8]

Internet-Draft SDP offer/answer for file transfer December 2007

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 March 2008

; by colons.
; HEXDIG defined in
this document requires that a file selector eventually results at
most RFC 5234

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 a single file to RFC 2822
; numeric timezones (+HHMM or -HHMM)
; must be chosen. Typically, if used
; DQUOTE defined in RFC 5234 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 / "*"

Figure 1: Syntax of the hash selector
is known, it is enough to produce a file selector that points SDP extension

When used for capability query (see Section 8.5), the 'file-selector'
attribute MUST NOT contain any selector, because its presence merely
indicates compliance to
exactly zero this specification.

When used in an SDP offer or answer, the 'file-selector' attribute
MUST contain at least one file. However, a selector. Selectors characterize the file
to be transferred. There are four selectors in this attribute:
'name', 'size', 'type', and 'hash'.

The 'name' selector that selects a
unique file is not always known by in the offerer. Sometimes only 'file-selector' attribute contains the
name, size or type
filename of file are known, so the file selector may result content enclosed in selecting more than one file, which is an undesired case. double quotes. The
opposite is also true: if the file selector contains a hash selector
and a name selector, there filename is a risk that
encoded in UTF-8 [RFC3629]. Its value SHOULD be the remote host has renamed same as the file, in which case, although a file whose computed hash equals
'filename' parameter of the hash selector exists, Content-Disposition header field
[RFC2183] that would be signaled by the actual file transfer. If a
file name does not match contains double quotes or any other character that of the
name selector, thus, the file selection process will result
syntax does not allow in the
selection of zero files.

This specification uses the Secure Hash Algorithm 1, SHA-1 [RFC3174].
If future needs require adding support for different hashing
algorithms, 'name' selector, they will MUST be specified as extensions to this document.

Implementations according to this specification percent-
encoded. The 'name' selector MUST implement the
'file-selector' attribute and MAY implement any of NOT contain characters that can be
interpreted as directory structure by the other
attributes specified local operating system. If
such characters are present in this specification. the file name, they MUST be percent-

Garcia-Martin, et al. Expires September 28, 2008 [Page 9]

Internet-Draft SDP offers and answers offer/answer for file transfer MUST contain a 'file-selector' media attribute March 2008

encoded.

Note that
selects the file to be transferred and MAY 'name' selector might still contain any of the other
attributes specified in this specification.

The 'file-selector' media attribute is also useful when learning characters that,
although not meaningful for the
support of local operating system, might
still be meaningful to the file transfer offer/answer capability that this
document specifies. This is further explained remote operating system (e.g., '\',
'/', ':'). Therefore, implementations are responsible for
sanitizing the input received from the remote endpoint before
doing a local operation in Section 8.4.

6. Extensions to SDP

We define the local file system, such as the
creation of a number local file. Among other things, implementations can
percent-encode characters that are meaningful to the local
operating system before doing file system local calls.

The 'size' selector in the 'file-selector' attribute indicates the
size of new SDP [RFC4566] attributes the file in octets. The value of this attribute SHOULD be
the same as the 'size' parameter of the Content-Disposition header
field [RFC2183] that provide would be signaled by the
required information to describe actual file transfer.
Note that the transfer 'size' selector merely includes the file size, and does
not include any potential overhead added by a wrapper, such as
message/cpim [RFC3862].

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 file Content-Type header field (see RFC 2045
[RFC2045]) can also be expressed with MSRP.
These the 'type' selectors. Possible
MIME Media Type values are all media level only attributes the ones listed in SDP. The following is the formal ABNF IANA registry for
MIME Media Types [1]. Zero or more parameters can follow. The
syntax [RFC4234] of these new attributes. It 'parameter' is
built above the SDP [RFC4566] grammar, specified in RFC 2045 [RFC2045], RFC 2183
[RFC2183], RFC 2392 [RFC2392], and RFC 2822 [RFC2822]. [RFC2045] .

The 'hash' selector in the 'file-selector' attribute = file-selector-attr / file-disp-attr /
file-tr-id-attr / file-date-attr /
file-icon-attr / file-range-attr
;attribute provides a hash
computation of the file to be transferred. This is defined commonly used by
file transfer protocols. For example, FLUTE
[I-D.ietf-rmt-flute-revised] 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 RFC 4566

file-selector-attr = "file-selector" [":" 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.

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 *(SP selector)] specified in this memo.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 9] 10]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

The 'hash' selector = filename-selector / filesize-selector /
filetype-selector / hash-selector

filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE includes the hash algorithm and its value.
Possible hash algorithms are those 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 the IANA registry of
Hash Function
;Textual 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 [2]. Implementations according to this
specification MUST add a US Secure Hash Algorithm 1 (SHA1) [RFC3174]
value if the 'hash' selector is defined in RFC 2822
; numeric timezones (+HHMM or -HHMM)
; must present. If need arises, extensions
can 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

Garcia-Martin, et al. Expires June 23, 2008 [Page 10]

Internet-Draft drafted to support several hashing algorithms. Therefore,
implementations according to this specification MUST be prepared to
receive SDP offer/answer for file transfer December 2007

file-range-attr = "file-range:" start-offset "-" stop-offset
start-offset = integer ;integer defined containing more than a single 'hash' selector in RFC 4566
stop-offset = integer / "*"

Figure 1: Syntax the
'file-selector' attribute.

The value of the SDP extension

When used for capability query (see Section 8.4), 'hash' selector is the 'file-selector' 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 MUST NOT contain any selector, because its presence merely
indicates compliance is indicated).

The 'file-transfer-id' attribute provides a randomly chosen globally
unique identification to this specification.

When the actual file transfer. It is used in an to
distinguish a new file transfer request from a repetition of the SDP offer or answer,
(or the 'file-selector' attribute
MUST contain at least one selector. Selectors characterize fraction of the SDP that deals with the file
to be transferred. There are four selectors description).
This attribute is described in this attribute:
'name', 'size', 'type', and 'hash'.

The 'name' selector much greater detail in the 'file-selector' Section 8.3.

The 'file-disposition' attribute contains provides a suggestion to the
filename other
endpoint about the intended disposition of the content enclosed in double quotes. file. Section 7
provides further discussion of the possible values. The filename is
encoded in UTF-8 [RFC3629]. Its value of
this attribute SHOULD be the same as the
'filename' disposition type parameter
of the Content-Disposition header field [RFC2183] that would be
signaled by the actual file transfer. If a transfer protocol.

The 'file-date' attribute indicates the dates at which the file name contains double quotes was
created, modified, or any other character that the
syntax does not allow in last read. This attribute MAY contain a
combination of the 'name' selector, they MUST be percent-
encoded. The 'name' selector 'creation', 'modification', and 'read' parameters,
but MUST NOT contain characters that can be
interpreted as directory structure by more than one of each type .

The 'creation' parameter indicates the local operating system. If
such characters are present in date at which the file name, they was
created. The value MUST be percent-
encoded.

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 quoted string which contains 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.

The 'size' selector in the 'file-selector' attribute indicates
representation of the
size creation date of the file in octets. RFC 2822 [RFC2822]
'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used.
The value of this attribute parameter SHOULD be the same as the 'size' 'creation-date'
parameter of the Content-Disposition header field [RFC2183] that
would be signaled by the actual file transfer.
Note that transfer protocol.

The 'modification' parameter indicates the 'size' selector merely includes date at which the file size, and does
not include any potential overhead added by a wrapper, such as
message/cpim [RFC3862]. was
last modified. The 'type' selector value MUST be a quoted string which contains a
representation of the last modification date to the file in RFC 2822
[RFC2822] 'date-time' format. Numeric timezones (+HHMM or -HHMM)
MUST be used. The value of this parameter SHOULD be the 'file-selector' attribute contains same as the
MIME media and submedia types
'modification-date' parameter of the content. In general, anything
that can be expressed in a Content-Type Content-Disposition header field (see RFC 2045
[RFC2183] that would be signaled by the actual file transfer

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 11]

Internet-Draft SDP offer/answer for file transfer December 2007

[RFC2045]) can also be expressed with the 'type' selectors. Possible
MIME Media Type values are March 2008

protocol.

The 'read' parameter indicates the ones listed in date at which the IANA registry for
MIME Media Types [1]. Zero or more parameters can follow. file was last
read. The
syntax value MUST be a quoted string which contains a
representation of 'parameter' is specified the last date the file was read in RFC 2045 [RFC2045] . 2822
[RFC2822] 'date-time' format. Numeric timezones (+HHMM or -HHMM)
MUST be used. The 'hash' selector in value of this parameter SHOULD be the 'file-selector' attribute provides a hash
computation same as the
'read-date' parameter of the file to Content-Disposition header field
[RFC2183] that would be transferred. This is commonly used signaled by the actual file transfer protocols. For example, FLUTE
[I-D.ietf-rmt-flute-revised] uses hashes (called message digests) to
verify the contents of the transfer.
protocol.

The purpose of the 'hash'
selector is two-fold: On one side, in pull operations, it 'file-icon' attribute can be useful with certain file types such
as images. It allows the file receiver sender to identify include a remote file by its hash rather than by
its file name, providing pointer to a body
that includes a small preview icon representing the file receiver has learned the hash contents of the remote
file by some out-of-band mechanism. On the other side,
in either push or pull operations, it allows to be transferred, which the file receiver can use to
verify the contents of the received file, or even avoid unnecessary
transmission of an existing determine
whether it wants to receive such file. The address space of the SHA-1 algorithm 'file-icon' attribute
contains a Content-ID URL, which is big enough to avoid
any collision in hash computations specified in between two endpoints. When
transferring files, RFC 2392 [RFC2392].
Section 8.8 contains further considerations about the actual file transfer protocol should
provide reliable transmission of data, so verifications of
received files should always succeed. However, if endpoints need 'file-icon'
attribute.

The 'file-range' attribute provides a mechanism to protect the integrity signal a chunk of
a file, they should use some other
mechanism file rather than the 'hash' selector specified in this memo. complete file. This enable use cases where a
file transfer can be interrupted, resumed, even perhaps changing one
of the endpoints. The 'hash' selector includes 'file-range' attribute contains the hash algorithm "start
offset" and its value.
Possible hash algorithms are those defined in the IANA registry "stop offset" of
Hash Function Textual Names [2]. Implementations according to this
specification MUST add a US Secure Hash Algorithm 1 (SHA1) [RFC3174]
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 file, separated by a single 'hash' selector in the
'file-selector' attribute. dash "-". The
"start offset" value refers to the position of the 'hash' selector is file where the
file transfer should start. The first byte string resulting of
applying the hash algorithm to a file is denoted by
the content ordinal number "1". The "stop offset" value refers position of
the whole file, even
when file where the file transfer is limited to should stop. The "stop offset"
value MAY contain a number "*" if the total size of octets (i.e., the
'file-range' attribute file is indicated). not known in
advance. The 'file-transfer-id' absence of this attribute provides indicates a unique identification to
the actual file transfer. It is used to distinguish a new file
transfer request from complete file,
i.e., as if the 'file-range' attribute would have been present with a repetition
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 SDP (or application would read and pass onto the fraction MSRP stack for
transportation. From the point of view of MSRP, the
SDP that deals with portion of the
file description). This attribute is
described viewed as a whole message. The latter indicates the number
of bytes of that message that are carried in much greater detail 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 Section 8.3.
the file.

The 'file-disposition' attribute provides a suggestion to following is an example of an SDP body that contains the other
extensions defined in this memo:

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 12]

Internet-Draft SDP offer/answer for file transfer December 2007

endpoint about the intended disposition of the file. Section 7
provides further discussion of the possible values. The value of
this attribute SHOULD be the same as the disposition type parameter March 2008

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

Figure 2: Example of the Content-Disposition header field [RFC2183] that would be
signaled by the actual SDP describing a file transfer protocol.

NOTE: The 'file-date' 'file-selector' attribute indicates the dates at which in the file was
created, modified, or last read. This attribute MAY contain above figure is split
in three lines for formatting purposes. Real implementations will
encode it in a
combination of the 'creation', 'modification', and 'read' parameters,
but MUST NOT contain more than one of each type . single line.

7. File Disposition Types

The 'creation' parameter indicates the date at which SDP Offer/Answer for file transfer allows the file was
created. The value MUST be a quoted string which contains sender to
indicate a
representation of the creation date preferred disposition of the file in RFC 2822 [RFC2822]
'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST to be used.
The transferred in a
new 'file-disposition' attribute. In principle, any value of this parameter SHOULD be the same as listed in
the 'creation-date'
parameter IANA registry for Mail Content Disposition Values [3] is
acceptable, however, most of the Content-Disposition header field [RFC2183] that
would them may not be signaled by the actual applicable.

There are two content dispositions of interest for file transfer protocol.

The 'modification' parameter indicates
operations. On one hand, the date at which file sender may just want the file was
last modified. The value MUST to
be a quoted string which contains a
representation of rendered immediately in the last modification date file receiver's device. On the other
hand, the file sender may just want to indicate the file in RFC 2822
[RFC2822] 'date-time' format. Numeric timezones (+HHMM or -HHMM)
MUST recipient
that the file should not be used. The value rendered at the reception of this parameter SHOULD be the same as file.
The recipient's user agent may want to interact with the
'modification-date' parameter of the Content-Disposition header field
[RFC2183] that would be signaled by the actual file transfer
protocol.

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 user
regarding the file was read in RFC 2822
[RFC2822] 'date-time' format. Numeric timezones (+HHMM disposition or -HHMM)
MUST be used. The value of this parameter SHOULD be it may save the same as file until the
'read-date' parameter of user
takes an action. In any case, the Content-Disposition header field
[RFC2183] exact actions are implementation
dependent.

To indicate that would be signaled by the actual a file transfer
protocol.

The 'file-icon' attribute can should 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 automatically rendered, this memo
uses the contents existing 'render' value 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 Content Disposition type in RFC 2392 [RFC2392].
Section 8.7 contains further considerations about
the 'file-icon'
attribute.

The 'file-range' new 'file-disposition' attribute provides a mechanism to signal a chunk of in SDP. To indicate that a file rather than the complete file. This enable use cases where a

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 13]

Internet-Draft SDP offer/answer for file transfer December 2007

file transfer can March 2008

should not be interrupted, resumed, even perhaps changing one automatically rendered, this memo users the existing
'attachment' value of the endpoints. The 'file-range' Content-Disposition type in the new 'file-
disposition' attribute contains in SDP. The default value is 'render', i.e.,
the "start
offset" and "stop offset" absence of the file, separated by a dash "-". 'file-disposition' attribute in the SDP has the same
semantics as 'render'.

The
"start offset" disposition value refers 'attachment' is specified in RFC 2183
[RFC2183] with the following definition:

"Body parts can be designated 'attachment' to indicate that
they are separate from the position main body of the file where the
file transfer mail message, and
that their display should start. The first byte of a file is denoted by
the ordinal number "1". The "stop offset" value refers position not be automatic, but contingent upon
some further action of the file where the file transfer should stop. The "stop offset"
value MAY contain a "*" if user."
In the total size case of this specification, the file 'attachment' disposition
type is not known in
advance. The absence used to indicate that the display 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 file should not
be confused with
the Byte-Range header in MSRP. The former indicates the portion automatic, but contingent upon some further action of a
file that the application would read and pass onto user.

8. Protocol Operation

This section discusses how to use the MSRP stack for
transportation. From parameters defined in Section 6
in the point of view context of MSRP, an offer/answer [RFC3264] exchange. Additionally,
this section also discusses the portion behavior of the endpoints using MSRP.

A file transfer session is viewed as a whole message. initiated by the offerer sending an SDP
offer to the answerer. The latter indicates answerer either accepts or rejects the number
of bytes of that message that are carried in a chunk
file transfer session and sends an SDP answer to the total
size of the message. Therefore, MSRP starts counting offerer.

We can differentiate two use cases, depending on whether the delivered
message at byte number 1, independently of position of that byte in offerer
is the file. file sender or file receiver:

1. The following offerer is an example of an 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 body that offer contains a
'sendonly' attribute, and accordingly the
extensions defined in this memo:

Figure 2: Example of SDP describing answer contains a
'recvonly' attribute.
2. 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.

8.1. Offerer's Behavior

An offerer who wishes to send or receive one or more files to or from
an answerer MUST build an SDP [RFC4566] description of a session
containing one "m=" line per file. When MSRP is used as the transfer
mechanism, each "m=" line also describes a single MSRP session,

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 14]

Internet-Draft SDP offer/answer for file transfer December 2007

NOTE: The 'file-selector' attribute in March 2008

according to the above figure is split
in three MSRP [RFC4975] procedures. Any "m=" lines for formatting purposes. Real implementations will
encode it that may
have already been present in a single line.

7. File Disposition Types

The previous SDP Offer/Answer for file transfer allows exchange are normally
kept unmodified; the file sender to
indicate a preferred disposition of new "m=" lines are added afterwards (Section 8.6
describes cases when "m=" lines are re-used). All the file to media line
attributes specified and required by MSRP [RFC4975] (e.g., "a=path",
"a=accept-types", etc.) MUST be transferred in included as well.

8.1.1. The Offerer is a
new 'file-disposition' attribute. File Sender

In principle, any value listed in
the IANA registry for Mail Content Disposition Values [3] is
acceptable, however, most of them may not be applicable.

There are two content dispositions of interest for file transfer
operations. On one hand, a push operation, the file sender may just want creates and SDP offer describing
the file to be rendered immediately 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 file receiver's device. On type, size, or hash of the other
hand, file,
respectively. If the file sender may just want wishes to indicate the start a new file recipient
that
transfer, the file should not be rendered at the reception of sender MUST add a 'file-transfer-id' attribute
containing a new globally unique random identifier value.
Additionally, the file.
The recipient's user agent may want file sender MUST add a session or media 'sendonly'
attribute to interact with the user
regarding SDP offer. Then the file disposition or it may save sender sends the SDP offer
to the file until receiver.

Not all the user
takes an action. In any case, selectors in the exact actions are implementation
dependent.

To indicate that a file should 'file-selector' attribute might be automatically rendered, this memo
uses
known when the existing 'render' value of file sender creates the Content Disposition type SDP offer, for example,
because the host is still processing the file.

The 'hash' selector in the new 'file-disposition' 'file-selector' attribute in SDP. To indicate that a contains
valuable information to the file
should receiver to identify whether the
file is already available and need not be automatically rendered, this memo users the existing
'attachment' value of the Content-Disposition type transmitted.

The file sender MAY also add a 'name' selector in the new 'file-selector'
attribute, and a 'file-icon', 'file-disposition', and 'file-date'
attributes further describing the file to be transferred. The 'file-
disposition' attribute in SDP. The default value is 'render', i.e.,
the absence of provides a 'file-disposition' attribute in presentation suggestion, (for
example: the SDP has file sender would like the same
semantics as 'render'. file receiver to render the
file or not). The disposition value 'attachment' is specified in RFC 2183
[RFC2183] with three date attributes provide the following definition:

"Body parts can be designated 'attachment' to indicate that
they are separate from answerer with an
indication of the main body age of the mail message, file. The file sender MAY also add a
'file-range' attribute indicating the start and
that their display should not be automatic, but contingent upon
some further action stop offsets of the user."
In
file.

When the case of this specification, file sender receives the 'attachment' disposition
type is used to indicate that SDP answer, if the display port number of
the answer for a file should not
be automatic, but contingent upon some further action request is non-zero, the file sender starts the
transfer of the user.

8. Protocol Operation

This Section discusses how file according to use the negotiated parameters defined in Section 6 in SDP.

8.1.2. The Offerer is a File Receiver

In a pull operation, the context 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 an offer/answer [RFC3264] exchange. Additionally, the selector
defined for that attribute (i.e., 'name', 'type', 'size', or 'hash').

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 15]

Internet-Draft SDP offer/answer for file transfer December 2007

this section also discusses March 2008

In many cases, if the behavior hash of the endpoints using MSRP.

Usually the file transfer session is initiated when the offerer sends
an SDP offer known, that is enough to
identify the answerer. The answerer either accepts or rejects
the file transfer session and sends an SDP answer to file, therefore, the offerer.

We offerer can differentiate two use cases, depending on whether include only a 'hash'
selector. However, specially in cases where the offerer
is hash of the file sender or file receiver:

1. The offerer is
unknown, the file sender, i.e., the offerer wants to
transmit name, size, and type can provide a description of
the file to the answerer. Consequently the answerer is be fetched. If the file receiver. In this case the SDP offer contains receiver wishes to start a
'sendonly' attribute, and accordingly the SDP answer contains new
file transfer it MUST add a
'recvonly' attribute.
2. 'file-transfer-id' attribute containing a
new globally unique random value. The offerer is the file receiver, i.e., the offerer wants to
fetch receiver MAY also add a file from
'file-range' attribute indicating the answerer. Consequently start and stop offsets of the answerer
file. There is no need to for the file sender. In 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 case
specification (other than the mandatory ones). Additionally, the
file receiver MUST create an SDP offer that contains a session or
media 'recvonly' attribute, and accordingly the SDP answer
contains a session or media 'sendonly' attribute.

8.1. Offerer's Behavior

An offerer that wishes to send or receive one or more files to or
from an answerer MUST build an

When the file receiver receives the SDP [RFC4566] description answer, if the port number of
the answer for a session
containing one or more "m=" lines, each one describing an MSRP
session (and thus, one file transfer operation), according to request is non-zero, then the
MSRP [RFC4975] procedures. All file receiver
should receive the media line attributes specified
and required by MSRP [RFC4975] (e.g., "a=path", "a=accept-types",
etc.) MUST be included as well. For each file to be transferred
there MUST be a separate using the protocol indicated in the "m="
line.

8.1.1. The Offerer is a File Sender

In a push operation, If the file sender creates and SDP offer describing
the file to be sent. The file sender MUST add answer contains a 'file-selector'
attribute media line containing at least one of supported hashing algorithm in
the 'type', 'size', 'hash' selectors in indicating of the 'file-selector' attribute, then the file
receiver SHOULD compute 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, 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 sender MUST add a session or media
'sendonly' attribute to receiver SHOULD consider that the file transfer failed and
SHOULD inform the user.

8.1.3. SDP offer. Then Offer for Several Files

An offerer that wishes to send or receive more than one file
generates an "m=" line per file along with the file sender sends 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 SDP offer [RFC4566] procedures. Each file
has its own file transfer identifier, which uniquely identifies each
file transfer.

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 RFC 4975 [RFC4975]. The same TCP
connection can also be re-used for sequential file transfers.

8.2. Answerer's Behavior

If the answerer wishes to reject a file receiver. offered by the offerer, it
sets the port number of the "m=" line associated with the file to
zero, as per regular SDP [RFC4566] procedures. The rejected answer
MUST contained a 'file-selector' and 'file-transfer-id' attributes

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 16]

Internet-Draft SDP offer/answer for file transfer December 2007

Not all the selectors in the 'file-selector' attribute might be
known when March 2008

whose values mirror the file sender creates corresponding values of the SDP offer, for example,
because offer.

If the host is still processing the file.

The 'hash' selector in the 'file-selector' attribute contains
valuable information to the file receiver answerer decides to identify whether accept the
file is already available file, it proceeds as per
regular MSRP [RFC4975] and need not be transmitted. SDP [RFC4566] procedures.

8.2.1. The file sender MAY also add Answerer is a 'name' selector in the 'file-selector'
attribute, and File Receiver

In a 'file-icon', 'file-disposition', and 'file-date'
attributes further describing push operation the file to be transferred. The 'file-
disposition' attribute provides a presentation suggestion, (for
example: SDP answerer is the file sender would like receiver. When the
file receiver to render gets the
file or not). The three date attributes provide SDP offer, it first examines the answerer with an
indication of port number.
If the age of port number is set to zero, the file. The file sender MAY also add a
'file-range' attribute indicating the start transfer operation is
closed, and stop offsets of the
file.

When the file sender receives no more data is expected over the SDP answer, media stream. Then, if
the port number of
the answer for a file request is non-zero, different than zero, the file sender starts receiver inspects
the
transfer 'file-transfer-id' attribute. If the value of the file according to 'file-
transfer-id' attribute has been previously used then the negotiated parameters in SDP.

8.1.2. The Offerer existing
session remains without changes, perhaps the file transfer is a File Receiver still
in progress, or perhaps it has concluded, but there are no change
with respect the current status. In a pull operation, any case, independently of the file receiver creates
port number, the SDP offer answerer creates a regular SDP answer and sends
it to the file sender. The file receiver MUST include a 'file-
selector' attribute and SHOULD add, at least, one of offerer.

If the selector
defined port number is different than zero and 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 attribute (i.e., 'name', 'type', 'size', describe the file and typically requests permission
from the user to accept or 'hash').
In many cases, if reject the hash reception of the file. If the
file transfer operation is known, that is enough accepted, the file receiver MUST create an
SDP answer according to
identify the file, therefore, procedures specified in RFC 3264
[RFC3264]. If the offerer can include only a 'hash'
selector. However, specially offer contains 'name', 'type', 'size' selectors in cases where
the hash of 'file-selector' attribute, the file is
unknown, answerer MUST copy them into the
answer. The file name, size, and type can provide a description receiver copies the value of the file 'file-transfer-id'
attribute to be fetched. The the SDP answer. Then the file receiver MUST also add a 'file-
transfer-id'
session or media 'recvonly' attribute with a newly created random value (new within according to the current session). procedures
specified in RFC 3264 [RFC3264]. The file receiver MAY also add MUST NOT include
'file-icon', 'file-disposition', or 'file-date' attributes in the SDP
answer.

The file receiver can use the hash to find out if a 'file-range'
attribute indicating local file with
the start and stop offsets of same hash is already available, in which case, this could imply
the reception of a duplicated file. There It is no need up to for the file receiver answerer to include further
determine whether the file
attributes transfer is accepted or not in case of a
duplicated file.

If 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.

When 'file-range' attribute and the file
receiver receives the SDP answer, if accepts to receive the port number range of
the answer for a file request is non-zero, then bytes declared in there, the
file receiver
should receive the file using the protocol indicated MUST include a 'file-range' attribute in the m= line.
If the SDP answer contains a supported hashing algorithm in
with the
'hash' selectors same range of the 'file-selector' attribute, then values. If the file receiver does not accept
the reception of that range of bytes, it SHOULD reject the transfer
of the file.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 17]

Internet-Draft SDP offer/answer for file transfer December 2007

receiver SHOULD compute March 2008

8.2.2. The Answerer is a File Sender

In a pull operation the hash of answerer is the file after its reception and
check it against sender. In this case,
the hash received in file sender MUST first inspect the answer. In case value of the
computed hash does not match
'file-transfer-id' attribute. If the one contained in has not been previously been
used throughout the SDP answer, session, then acceptance of the file receiver SHOULD consider that MUST provoke
the file transfer failed and
SHOULD inform of the user.

8.1.3. SDP Offer for Several Files

An offerer that wishes to send or receive more than one file
generates an "m=" line per file along with over the file attributes
described in this specification. This way, negotiated protocol. However, if
the answerer can reject
individual files value has been previously used by setting another file transfer operation
within the port number of their associated "m="
lines to zero, as per regular SDP [RFC4566] procedures. Each file
has its own file transfer identifier, which uniquely identifies each
file transfer.

8.2. Answerer's Behavior

If session, then the answerer wishes to reject a file offered by the offerer, it
sets sender MUST NOT alert the port number user and
MUST NOT start a new transfer of the "m=" line associated with file. No matter whether an
actual file transfer is initiated or not, the file to
zero, as per regular SDP [RFC4566] procedures. The rejected answer sender MUST contained create
a 'file-selector' and proper SDP answer that contains the 'file-transfer-id' attributes
whose values mirror attribute
with the corresponding values of same value received in the SDP offer.

If the answerer decides to accept the file, it proceeds as per
regular MSRP [RFC4975] offer, and then it MUST
continue processing the SDP [RFC4566] procedures.

8.2.1. answer.

The Answerer is a File Receiver

In a push operation the file sender MUST always create an SDP answerer is answer according to the SDP
offer/answer procedures specified in RFC 3264 [RFC3264]. The file receiver. When
sender inspects the file receiver gets selector of the received SDP offer, it first examines the 'file-
transfer-id' attribute. If the value of which is
encoded in the 'file-transfer-id' 'file-selector' media attribute has been previously used then line. Then the existing session remains
without changes, perhaps file
sender applies the file transfer is still in progress, or
perhaps it has concluded, but there are no change selector, which implies selecting those files
that match one by one with respect the
current status. The SDP answerer creates a regular SDP answer 'name', 'type', 'size', and
sends it to the offerer.

If 'hash'
selectors of the SDP offer contains a new 'file-transfer-id' attribute, then
this signals a request for a new file transfer. 'file-selector' attribute line (if they are
present). The SDP answerer
extracts the attributes and parameters that describe the file and
typically requests permission from selector identifies zero or more candidate files
to be sent. If the user file selector is unable to accept or identify any file,
then the answerer MUST reject the

Garcia-Martin, et al. Expires June 23, 2008 [Page 18]

Internet-Draft SDP offer/answer MSRP stream for file transfer December 2007

reception of by
setting the file. If port number to zero, and then the file transfer operation is accepted, sender SHOULD also
reject the file receiver MUST create an SDP answer according to the as per procedures specified in RFC 3264 [RFC3264]. If [RFC3264], if this is
the offer contains
'name', 'type', 'size' selectors only stream described in the 'file-selector' attribute,
the answerer MUST copy them into SDP offer.

If the answer. The file receiver
copies the value of selector points to a single file and the 'file-transfer-id' attribute file sender
decides to accept the SDP
answer. Then file transfer, the file receiver sender MUST add create an
SDP answer that contains a session or media
'recvonly' attribute 'sendonly' attribute, according to the
procedures specified in described RFC 3264 [RFC3264]. The file receiver MUST NOT include 'file-icon',
'file-disposition', or 'file-date' attributes sender SHOULD add
a 'hash' selector in the SDP answer.

The file receiver can use answer with the locally computed SHA-1 hash to find out if
over the complete file. If a local hash value computed by the file with sender
differs from that specified by the same file receiver, the file sender can
either send the file without that hash is already available, in which case, this could imply value or reject the reception of a duplicated file. It is up to request by
setting the answerer to
determine whether port in the media stream to zero. The file transfer is accepted or not sender MAY
also include a 'type' selector in case the 'file-selector' attribute line
of a
duplicated file.

If the SDP offer contains answer. The answerer MAY also include a 'file-range' attribute 'file-icon' and the file
receiver accepts
'file-disposition' attributes to receive further describe the range of bytes declared in there, file. Although
the
file receiver MUST answerer MAY also include a 'file-range' attribute '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 [RFC4975]) can accommodate a Content-
Disposition header field [RFC2183] with the same range equivalent parameters.

Garcia-Martin, et al. Expires September 28, 2008 [Page 18]

Internet-Draft SDP offer/answer for file transfer March 2008

The whole idea of values. If 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 receiver does transfer protocol would just duplicate the
information, but will not accept provide any information to the reception of that range of bytes, it SHOULD offerer
to accept or reject the file transfer
of (note that the file.

8.2.2. The Answerer offerer is
requesting a File Sender

In a pull operation the answerer is file).

Last, if the file sender. In this case, selector points to multiple candidate files, the file sender MUST first inspect
answerer MAY use some local policy, e.g. consulting the value user, to
choose one of them to be defined in the
'file-transfer-id' attribute. SDP answer. If that choice
cannot be done, the has not been previously been
used throughout the session, then acceptance of answerer SHOULD reject the MSRP media stream for
file MUST provoke
the transfer of the file over (by setting the negotiated protocol. However, if port number to zero).

If the value has been previously used need arises, future specifications can provide a suitable
mechanism that allows to either select multiple files or, e.g.,
resolve ambiguities by another returning a list of files that match the
file transfer operation
within selector.

If the session, then SDP offer contains a 'file-range' attribute and the file
sender MUST NOT alert accepts to send the user and
MUST NOT start a new transfer range of the file. No matter whether an
actual file transfer is initiated or not, bytes declared in there, the file
sender MUST create include a proper 'file-range' attribute in the SDP answer that contains the 'file-transfer-id' attribute with
the same value received in range of values. If the SDP offer, and then file sender does not accept sending
that range of bytes, it MUST
continue processing SHOULD reject the SDP answer. transfer of the file.

8.3. The file sender MUST always create 'file-transfer-id' attribute

This specification creates an SDP answer according extension to the SDP
offer/answer procedures specified in RFC 3264 [RFC3264]. The file
sender inspects the file selector Offer/Answer Model
[RFC3264], and because of that, it is assumed that the received existing SDP offer, which
behavior is
encoded kept intact. The SDP behavior requires, for example,
that SDP is sent again to the remote party in situations where the 'file-selector'
media attribute line. Then description or perhaps other SDP parameters have not changed
with respect a previous offer/answer exchange. Let's consider the
SIP Session Timer (RFC 4028) [RFC4028], 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
sender applies transfer operation and occur while the file selector, which implies selecting those files
that match one by one with
transfer was still going on, there would be no means to detect
whether the 'name', 'type', 'size', and 'hash'
selectors of SDP creator wanted to abort the 'file-selector' attribute line (if they are
present). The current file selector identifies zero transfer
operation and initiate a new one or more candidate files
to be sent. If the SDP file selector description was
included in the SDP due to other reasons (e.g., session timer
refresh).

A similar scenario occurs when two endpoints have successfully agreed
on a file transfer, which is unable currently taking place when one of the
endpoints wants to identify any file, 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

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 19]

Internet-Draft SDP offer/answer for file transfer December 2007

then the answerer MUST reject March 2008

the MSRP stream for current ongoing file transfer by
setting the port number to zero, and then add the file sender SHOULD also
reject new media descriptions.
The problem is that, the SDP as per procedures in RFC 3264 [RFC3264], if this other endpoint is
the only stream described in the SDP offer.

If the file selector points not able to determine if a single
new file and the transfer is requested or not.

In other cases, a file sender
decides to accept 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 sender MUST create an
SDP answer that transfer should start or not.

To address these scenarios this specification defines the 'file-
transfer-id' attribute which contains a 'sendonly' attribute, according globally unique random
identifier allocated to the
procedures described RFC 3264 [RFC3264]. file transfer operation. The file sender SHOULD add
a 'hash' selector in the answer with the locally computed SHA-1 hash
over
transfer identifier helps both endpoints to determine whether the complete file. If SDP
offer is requesting a hash value computed by the new file sender
differs from that specified by transfer or it is a repetition of the
SDP. A new file receiver, transfer is one that, in case of acceptance, will
provoke the file sender can
either send actual transfer of a file. This is typically the file without that hash value case of
new offer/answer exchanges, or reject the request by
setting the port in the media stream cases where an endpoint wants to zero. The
abort the existing file sender MAY
also include a 'type' selector in transfer and re-start the 'file-selector' attribute line file transfer once
more. On the other hand, the repetition of the SDP answer. The answerer MAY also include a 'file-icon' and
'file-disposition' attributes does not lead to further describe
any actual file to be transferred, potentially because the file. Although file
transfer is still going on or because it has already finished. This
is the answerer MAY also include case of a 'name' and 'size' selectors repeated offer/answer exchanges, which can be due to
a number of reasons (session timer, addition/removal of other media
types in the
'file-selector' attribute, and a 'file-date' attribute, it is
RECOMMENDED not SDP, update in SDP due to changes in other session
parameters, etc.).

Implementations according to this specification MUST include them a 'file-
transfer-id' attribute in the SDP answer if the actual offers and answers. The SDP offerer
MUST select a file transfer protocol (e.g., MSRP [RFC4975]) can accommodate a Content-
Disposition header field [RFC2183] with identifier according to the equivalent parameters. syntax and
add it to the 'file-transfer-id' attribute. The whole idea SDP answerer MUST
copy the value of adding the 'file-transfer-id' attribute in the SDP answer.

The file descriptors transfer identifier MUST be unique within the current
session (never used before in this session), and it is RECOMMENDED to SDP
be unique across different sessions. It is RECOMMENDED to provide a
mechanism where select a file transfer can be accepted prior
relatively big random identifier (e.g., 32 characters) to its
start. Adding any avoid
duplications. The SDP attributes that are otherwise signaled
later in answerer MUST keep track of the proposed file
transfer protocol would just duplicate the
information, but will not provide any information to identifiers in each session and copy the offerer
to accept or reject value of the
received file transfer (note that identifier in the offerer is
requesting SDP answer.

If a file).

Last, if the file selector points to multiple candidate files, transfer is suspended and resumed at a later time, the
answerer MAY use some local policy, e.g. consulting
resumption is considered a new file transfer (even when the user, to
choose one of them file to
be defined in the SDP answer. If that choice
cannot be done, transferred is the answerer SHOULD reject same), therefore, the MSRP media stream for SDP offerer MUST choose a
new file transfer (by setting identifier.

If an endpoint sets the port number to zero).

If zero in 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 media description
of files that match the
file selector.

If the SDP offer contains a 'file-range' attribute and the file
sender accepts transfer, for example because it wants to send the range of bytes declared in there, reject the file
sender MUST include a 'file-range' attribute in
transfer operation, then the SDP answer with
the same range of values. If the file sender does not accept sending
that range of bytes, it SHOULD reject MUST mirror the transfer value of the file.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 20]

Internet-Draft SDP offer/answer for file transfer December 2007

8.3. The March 2008

'file-transfer-id' attribute

This specification creates an extension to the SDP Offer/Answer Model
[RFC3264], and because of that, it is assumed that included in the existing SDP
behavior is kept intact. The SDP behavior requires, for example, offer. This
effectively means that SDP is sent again setting a media stream to zero has higher
precedence than any value that the remote party in situations where the
media description or perhaps other SDP parameters have not changed
with respect 'file-transfer-id' attribute can
take.

As a previous offer/answer exchange. Let's consider side effect, the
SIP Session Timer (RFC 4028) [RFC4028], 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 '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 operation and occur while the file actual transfer was still going on, there would be no means to detect
whether of the SDP creator wanted to abort
file is taking place. At some point in time in the middle of the current
file transfer
operation and initiate transfer, one endpoint sends a new SDP offer, equal to the
initial one or except for the SDP file description was
included in value of the SDP due to other reasons (e.g., session timer
refresh).

A similar scenario occurs when two endpoints have successfully agreed
on a file transfer, 'file-transfer-id' attribute,
which is currently taking place when one of a new globally unique random value. This indicates that the
endpoints
offerer wants to add additional media streams to abort the existing
session. In this case, the endpoint sends transfer and start a re-INVITE request that
contains SDP. new one,
according to the SDP parameters. The SDP needs answerer SHOULD abort the
ongoing file transfer, according to maintain the media descriptions for procedures of the current ongoing file
transfer protocol (e.g., MSRP), and add the new media descriptions.
The problem is that, start sending file once more from
the other endpoint is not able to determine if a
new initial requested octet. Section 8.4 further discusses file
transfer is requested or not. abortion.

In other cases, another scenario, an endpoint that has successfully transferred a
file transfer was successfully completed. Then, if wants to send an endpoint re-sends SDP due to other reasons than the transfer of a
file. The SDP offer with offerer creates an SDP file description that maintains
the media stream for description line corresponding to the file
transfer, transfer. The
SDP offerer MUST then set the other endpoint wouldn't be able port number to determine
whether a new file transfer should start or not.

To address these scenarios this specification defines zero and MUST keep the 'file-
transfer-id'
same value of the 'file-transfer-id' attribute which contains a unique that the initial file
transfer
identifier. The got.

8.4. Aborting an ongoing file transfer identifier helps both endpoints operation

A file sender that wishes to
determine whether the SDP offer is requesting a new abort an ongoing file transfer or
it is a repetition of the SDP. A new operation
without initiating an alternative file transfer transfer, if an ongoing MSRP
SEND request is one that, being transmitted, aborts the MSRP message by
including the '#' character in
case of acceptance, will provoke the actual transfer continuation field of a file. This
is typically the case end-line
of new offer/answer exchanges, or in cases
where an endpoint wants a SEND request, according to abort the existing MSRP procedures (see Section 7.1
of RFC 4975 [RFC4975]). Since a file transfer and re-
start is transmitted as one MSRP
message, aborting the file transfer once more. On MSRP message effectively aborts the other hand, file
transfer. Then the repetition
of file sender SHOULD close the MSRP session. This
is done by sending a new SDP does not lead to any actual file offer that sets the port number to be transferred,
potentially because zero
in the related "m=" line that describes the file transfer is still going on or because it
has already finished. This is the case (see
Section 8.2 of a repeated offer/answer
exchanges, which can RFC 3264 [RFC3264]). This SDP offer MUST conform with
the requirements of Section 8.1.1. The 'file-transfer-id' attribute
MUST be due the same that identifies the ongoing transfer. Then the file
sender sends the SDP offer to a number the file recipient.

A file receiver that receives the above SDP offer creates an SDP
answer according to the procedures of reasons (session timer,
addition/removal the SDP offer/answer (RFC 3264
[RFC3264]). This SDP answer MUST conform with the requirements of other media types in
Section 8.2.1. Then the SDP, update in file recipient sends this SDP due answer to changes in other session parameters, etc.). the

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 21]

Internet-Draft SDP offer/answer for file transfer December 2007

Implementations according to this specification MUST include a 'file-
transfer-id' attribute in SDP offers and answers. The SDP offerer
MUST select a March 2008

file transfer identifier according sender.

A file receiver that wishes to abort an ongoing transfer first must
determine if the syntax and
add it MSRP sender wishes to receive failure reports. If
the 'file-transfer-id' attribute. The SDP answerer MUST
copy current MSRP SEND request sets the Failure-Report header to a
value different than "no", then the file receiver generates an MSRP
413 response to the current MSRP SEND request (see Section 10.5 of
RFC 4975 [RFC4975]). Then the 'file-transfer-id' attribute in file receiver SHOULD close the MSRP
session. This is done by sending a new SDP answer.

The offer that sets the port
number to zero in the related "m=" line that describes the file
transfer identifier (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer
MUST be unique within conform with the current
session (never used before requirements expressed 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. Section 8.1.2. The SDP answerer
'file-transfer-id' attribute MUST keep track of be the proposed file
transfer identifiers in each session and copy same that identifies the value of
ongoing transfer. Then the
received file transfer identifier in sender sends the SDP answer.

If a file transfer is suspended and resumed at a later time, the
resumption is considered a new file transfer (even when the file offer to
be transferred is the same), therefore, the SDP offerer MUST choose a
new
file transfer identifier.

If receiver.

A file sender that receives an endpoint sets SDP offer setting the port number to
zero in the media description
of a related "m=" line for file transfer, for example because first, if an ongoing
MSRP SEND request is being transmitted, it wants to reject aborts the file
transfer operation, then MSRP message by
including the SDP answer should mirror '#' character in the value continuation field of the 'file-transfer-id' attribute included in the SDP offer. This
effectively means that setting end-line
of a media stream SEND request, according to zero has higher
precedence than any value that the 'file-transfer-id' attribute can
take.

As MSRP procedures (see Section 7.1
of RFC 4975 [RFC4975]). Since a side effect, the 'file-transfer-id' attribute can be used for file is transmitted as one MSRP
message, aborting and restarting again an ongoing the MSRP message effectively aborts the file
transfer. Assume that
two endpoints agree on a Then the file transfer and sender creates an SDP answer according to
the actual transfer procedures of the
file is taking place. At some point in time in SDP offer/answer (RFC 3264 [RFC3264]). This
SDP answer MUST conform with the middle requirements of Section 8.2.2. Then
the file transfer, one endpoint sender 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.

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 this SDP offerer MUST then set the port number answer to zero and MUST keep the
same value of the 'file-transfer-id' attribute that the initial file
transfer got.

Garcia-Martin, et al. Expires June 23, 2008 [Page 22]

Internet-Draft SDP offer/answer for file transfer December 2007

8.4. receiver.

8.5. 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.

8.6. Re-usage of Existing m= "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

Garcia-Martin, et al. Expires September 28, 2008 [Page 22]

Internet-Draft SDP offer/answer for file transfer March 2008

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 RFC 3264
[RFC3264], in particular those defined in Section 8.3, MUST apply for
file transfer operations. An endpoint that wants to re-use an
existing m= "m=" line to start the file transfer of another file creates
a different 'file-selector' attribute and selects a different new globally
unique random value of the 'file-transfer-id' attribute.

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).

8.6.

8.7. MSRP Usage

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 Section 8.1
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
in the SDP offer or answer. That is, senders MUST NOT send
additional files over the same MSRP session.

File transfer may be accomplished using a new multimedia session
established for the purpose. Alternatively a file transfer may be

Garcia-Martin, et al. Expires June 23, 2008 [Page 23]

Internet-Draft SDP offer/answer for file transfer December 2007
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.

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

Garcia-Martin, et al. Expires September 28, 2008 [Page 23]

Internet-Draft SDP offer/answer for file transfer March 2008

send pipelined MSRP SEND requests containing chunks of the same MSRP
message (the file). Section 9.1 contains an example of a file
transfer using pipelined MSRP requests.

The MSRP specification [RFC4975] 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= "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
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
message/cpim wrapper [RFC3862]. Usage of a wrapper is negotiated in
the SDP (see Section 8.6 in RFC 4975 [RFC4975]). 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.

Note that the default content disposition of MSRP bodies is 'render'.
When MSRP is used to transfer files, the MSRP Content-Disposition

Garcia-Martin, et al. Expires June 23, 2008 [Page 24]

Internet-Draft SDP offer/answer for file transfer December 2007
header can also take the value 'attachment' as indicated in
Section 7.

Once the file transfer is completed, the file sender SHOULD close the
MSRP session, session and MUST behave according to the MSRP [RFC4975]
procedures with respect closing MSRP sessions.

8.7. Considerations about the 'file-icon' attribute

This specification allows a file sender Note that MSRP
session management is not related to TCP connection management. As a
matter of fact, MSRP allows multiple MSRP sessions to share the same
TCP connection.

8.8. 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 MUST wrap the SDP body and the icon bodies in a MIME
multipart/related body. Therefore, implementations according to this
specification MUST implement the multipart/related MIME type
[RFC2387]. When creating a multipart/related MIME wrapper, the SDP

Garcia-Martin, et al. Expires September 28, 2008 [Page 24]

Internet-Draft SDP offer/answer for file transfer March 2008

body MUST be the root body, which according to RFC 2387 [RFC2387] is
identified as the first body in the multipart/related MIME wrapper or
explicitly identified by the 'start' parameter. According to RFC
2387 [RFC2387], the 'type' parameter MUST be present and point to the
root body, i.e., the SDP body.

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.

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.

9. Examples

9.1. Offerer sends a file to the Answerer

This section shows an example flow for a file transfer scenario. The
example assumes that SIP [RFC3261] is used to transport the SDP
offer/answer exchange, although the SIP details are briefly shown in

Garcia-Martin, et al. Expires June 23, 2008 [Page 25]

Internet-Draft SDP offer/answer for file transfer December 2007
the sake of brevity.

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 Figure 3.

Garcia-Martin, et al. Expires September 28, 2008 [Page 25]

Internet-Draft SDP offer/answer for file transfer March 2008

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 |
|<-----------------------|
| |
| |

Figure 3: Flow diagram of an offerer sending a file to an answerer

F1: Alice constructs an SDP description of the file to be sent and
attaches it to a SIP INVITE request addressed to Bob.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 26]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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--

Figure 4: INVITE request containing an SDP offer for file transfer

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 27]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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.

From now on we omit the SIP details for the sake of brevity.

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:

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

Figure 5: SDP answer accepting the SDP offer for file transfer

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.

F4: Alice opens a TCP connection to Bob and creates an MSRP SEND
request. This SEND request contains the first chunk of the file.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 28]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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+

Figure 6: MSRP SEND request containing the first chunk of actual file

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.

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$

Figure 7: MSRP SEND request containing the second chunk of actual
file

F6: Bob acknowledges the reception of the first chunk.

MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4385
-------d93kswow$

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 29]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

Figure 8: MSRP 200 OK response

F7: Bob acknowledges the reception of the second chunk.

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$

Figure 9: MSRP 200 OK response

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
(OK) response.

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
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. Figure 10 shows the sequence flow.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 30]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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 |
|----------------------->|
| |
| |

Figure 10: Flow diagram of an offerer requesting a file from the
answerer and then sending a file to the answer

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.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 31]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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

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.

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:

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 32]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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

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
SEND request that contains the file.

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$

Figure 13: MSRP SEND request containing the actual file

F5: Alice acknowledges the reception of the SEND request.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 33]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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$

Figure 14: MSRP 200 OK response

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.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 34]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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--

Figure 15: Reuse of the SDP in a second file transfer

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 35]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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.

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.

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

Figure 16: SDP answer accepting the SDP offer for file transfer

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.

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.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 36]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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+

Figure 17: MSRP SEND request containing the actual file

F10: Bob acknowledges the reception of the SEND request.

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$

Figure 18: MSRP 200 OK response

F11: Then Bob terminates the SIP session by sending a SIP BYE
request.

F12: Alice acknowledges the reception of the BYE request and sends a
200 (OK) response.

9.3. Example of a capability indication

Alice sends an OPTIONS request to Bob (this request does not contain
SDP). Bob answers with a 200 (OK) response that contain the SDP
shown in Figure 20. 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.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 37]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

Alice's UAC Bob's UAS
| |
|(1) (SIP) OPTIONS |
|----------------------->|
|(2) (SIP) 200 OK |
| with SDP |
|<-----------------------|
| |
| |

Figure 19: Flow diagram of a capability request

v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=-
c=IN IP4 bobpc.example.com
t=0 0
m=message 0 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=max-size:20000
a=file-selector

Figure 20: SDP of the 200 (OK) response to an OPTIONS request

10. Security Considerations

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.

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.

TLS and S/MIME are the natural choices to provide offer/answer
exchanges with integrity protection and confidentiality.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 38]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

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, SIP
[RFC3261] and MSRP [RFC4975].

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.

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.

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 receivers should apply all possible security technologies (e.g.,
antivirus, antispaware, etc.) to dismiss the risk of damage at their
host.

11. IANA Considerations

This document instructs IANA to register a number of SDP attributes
according to the following:

11.1. Registration of new SDP attributes

This memo provides instructions to IANA to register a number of media
level only attributes in the Session Description Protocol Parameters
registry [4]. The registration data, according to RFC 4566 [RFC4566]
follows.

Note to the RFC Editor: replace "RFC XXXX" with the RFC number of
this specification.

11.1.1. Registration of the file-selector attribute

Contact: Miguel Garcia <miguel.garcia@nsn.com>

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 39]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

Phone: +358 71400 4000
Attribute name: file-selector
Long-form attribute name: File Selector
Type of attribute: media level only
This attribute is subject to the charset attribute
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.
Specification: RFC XXXX

11.1.2. Registration of the file-transfer-id attribute

Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71400 4000
Attribute name: file-transfer-id
Long-form attribute name: File Transfer Identifier
Type of attribute: media level only
This attribute is subject to the charset attribute
Description: This attribute contains a unique identifier of the
file transfer operation within the session.
Specification: RFC XXXX

11.1.3. Registration of the file-disposition attribute

Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71400 4000
Attribute name: file-disposition
Long-form attribute name: File Disposition
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: This attribute provides a suggestion to the other
endpoint about the intended disposition of the file
Specification: RFC XXXX

11.1.4. Registration of the file-date attribute

Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71400 4000
Attribute name: file-date
Long-form attribute name:
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: This attribute indicates the dates at which the file
was created, modified, or last read.
Specification: RFC XXXX

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 40]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

11.1.5. Registration of the file-icon attribute

Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71400 4000
Attribute name: file-icon
Long-form attribute name: File Icon
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: For image files, this attribute contains a pointer to
a body that includes a small preview icon representing the
contents of the file to be transferred
Specification: RFC XXXX

11.1.6. Registration of the file-range attribute

Contact: Miguel Garcia <miguel.garcia@nsn.com>
Phone: +358 71400 4000
Attribute name: file-range
Long-form attribute name: File Range
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: it contains the range of transferred bytes of the
file
Specification: RFC XXXX

12. Acknowledgements

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 Rescorla, and Vikram Chhibber discussed and provided
comments and improvements to this document.

13. References

13.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 41]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.

[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2387, August 1998.

[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.

[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.

[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.

[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August 2004.

[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.

[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.

13.2. Informational References

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.

[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Session Initiation Protocol (SIP)", RFC 4028, April 2005.
Session Initiation Protocol (SIP)", RFC 4028, April 2005.

Garcia-Martin, et al. Expires September 28, 2008 [Page 42]

Internet-Draft SDP offer/answer for file transfer March 2008

[RFC4483] Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483,
May 2006.

[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007.

[I-D.ietf-rmt-flute-revised]
Paila, T., "FLUTE - File Delivery over Unidirectional
Transport", draft-ietf-rmt-flute-revised-05 (work in
progress), October 2007.

URIs

[1] <http://www.iana.org/assignments/media-types/>

[2] <http://www.iana.org/assignments/hash-function-text-names>

[3] <http://www.iana.org/assignments/mail-cont-disp>

[4] <http://www.iana.org/assignments/sdp-parameters>

Appendix A. Alternatives Considered

The requirements are related to the description and negotiation of
the session, not to the actual file transfer mechanism. Thus, it is
natural that in order to meet them it is enough to define attribute
extensions and usage conventions to SDP, while MSRP itself needs no
extensions and can be used as it is. This is effectively the
approach taken in this specification. Another goal has been to
specify the SDP extensions in such a way that a regular MSRP endpoint
which does not support them could still in some cases act as an
endpoint in a file transfer session, albeit with a somewhat reduced
functionality.

In some ways the aim of this specification is similar to the aim of
content indirection mechanism in the Session Initiation Protocol
(SIP) [RFC4483]. Both mechanisms allow a user agent to decide
whether or not to download a file based on information about the
file. However, there are some differences. With content
indirection, it is not possible for the other endpoint to explicitly
accept or reject the file transfer. Also, it is not possible for an
endpoint to request a file from another endpoint. Furthermore,
content indirection is not tied to the context of a media session,
which is sometimes a desirable property. Finally, content
indirection typically requires some server infrastructure, which may

Garcia-Martin, et al. Expires September 28, 2008 [Page 43]

Internet-Draft SDP offer/answer for file transfer March 2008

not always be available. It is possible to use content indirection
directly between the endpoints too, but in that case there is no
definition for how it works for endpoints behind NATs. The level of
requirements in implementations decides which solution meets the
requirements.

Based on the argumentation above, this document defines the SDP
attribute extensions and usage conventions needed for meeting the
requirements on file transfer services with the SDP offer/answer
model, using MSRP as the transfer protocol within the session.

In principle it is possible to use the SDP extensions defined here
and replace MSRP with any other similar protocol that can carry
MIME objects. This kind of specification can be written as a
separate document if the need arises. Essentially, such protocol
should be able to be negotiated on an SDP offer/answer exchange
(RFC 3264 [RFC3264]), be able to describe the file to be
transferred in SDP offer/answer exchange, be able to carry MIME
objects between two endpoints, and use a reliable transport
protocol (e.g., TCP).

This specification defines a set of SDP attributes that describe a
file to be transferred between two endpoints. The information needed
to describe a file could be potentially encoded in a few different
ways. The MMUSIC working group considered a few alternative
approaches before deciding to use the encoding described in
Section 6. In particular, the working group looked at the MIME
'external-body' type and the use of a single SDP attribute or
parameter.

A MIME 'external-body' could potentially be used to describe the file
to be transferred. In fact, many of the SDP parameters this
specification defines are also supported by 'external-body' body
parts. The MMUSIC working group decided not to use 'external-body'
body parts because a number of existing offer/answer implementations
do not support multipart bodies.

The information carried in the SDP attributes defined in Section 6
could potentially be encoded in a single SDP attribute. The MMUSIC
working group decided not to follow this approach because it is
expected that implementations support only a subset of the parameters
defined in Section 6. Those implementations will be able to use
regular SDP rules in order to ignore non-supported SDP parameters.
If all the information was encoded in a single SDP attribute, those
rules, which relate to backwards compatibility, would need to be
redefined specifically for that parameter.

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 42] 44]

Internet-Draft SDP offer/answer for file transfer December 2007

[RFC4483] Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483,
May 2006.

[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007.

[I-D.ietf-rmt-flute-revised]
Paila, T., "FLUTE - File Delivery over Unidirectional
Transport", draft-ietf-rmt-flute-revised-05 (work in
progress), October 2007.

URIs

[1] <http://www.iana.org/assignments/media-types/>

[2] <http://www.iana.org/assignments/hash-function-text-names>

[3] <http://www.iana.org/assignments/mail-cont-disp>

[4] <http://www.iana.org/assignments/sdp-parameters> March 2008

Authors' Addresses

Miguel A. Garcia-Martin
Nokia Siemens Networks
P.O.Box 6
Nokia Siemens Networks, FIN 02022
Finland

Phone: +358-71400-4000
Email: miguel.garcia@nsn.com

Markus Isomaki
Nokia
Keilalahdentie 2-4
Espoo 02150
Finland

Email: markus.isomaki@nokia.com

Garcia-Martin, et al. Expires June 23, 2008 [Page 43]

Internet-Draft SDP offer/answer for file transfer December 2007

Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland

Email: Gonzalo.Camarillo@ericsson.com

Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland

Email: Salvatore.Loreto@ericsson.com

Paul H. Kyzivat
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
USA

Email: pkyzivat@cisco.com

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 44] 45]

Internet-Draft SDP offer/answer for file transfer December 2007 March 2008

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Garcia-Martin, et al. Expires June 23, September 28, 2008 [Page 45] 46]

----