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.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document provides a mechanism to negotiate the transfer of one
   or more files between two endpoints by using the Session Description
   Protocol (SDP) offer/answer model specified in RFC 3264.  SDP is
   extended to describe the attributes of the files to be transferred.
   The offerer can either describe the files it wants to send, or the
   files it would like to receive.  The answerer can either accept or
   reject the offer separately for each individual file.  The transfer
   of one or more files is initiated after a successful negotiation.
   The Message Session Relay Protocol (MSRP) is defined as the default
   mechanism to actually carry the files between the endpoints.  The
   conventions on how to use MSRP for file transfer are also provided in
   this document.

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

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.

   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 receiver.
   File receiver:   The endpoint that is
   natural willing to receive a file from
      the file sender.
   File selector:   A tuple of file attributes that the SDP offerer
      includes in the SDP 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. select a file at the SDP answerer.
      This is effectively the
   approach taken described in this specification.  Another goal has been to
   specify more detail in Section 5.
   Push operation:   A file transfer operation where 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 offerer
      takes the role of the file sender and the SDP answerer takes role
      of the file receiver.
   Pull 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 receiver and the SDP answerer takes the
      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 sender.

4.  Overview of Operation

   An SDP offerer creates an SDP body that contains the
   file.  However, there are some differences.  With content
   indirection, it is not possible for description of
   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 the
   requirements.

   Based on the argumentation above, this document defines the SDP
   attribute extensions and usage conventions needed
   transport resources.

   Each "m=" line for meeting the
   requirements on file transfer services with the SDP offer/answer
   model, using an MSRP as the transfer protocol within the session.

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

   This specification defines a set of transferred.  If the file sender
   generates the SDP offer, the attributes that describe a local file to be transferred between two endpoints.  The
   sent (push), and the file receiver can use this information needed to describe a either
   accept or reject the transfer.  However, if the SDP offer is
   generated by the file could be potentially encoded in receiver, the attributes are intended to
   characterize 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 particular file that the use of a single SDP attribute or
   parameter.

   A MIME 'external-body' could potentially be used file receiver is willing to describe
   get (pull) from the file
   to be transferred.  In fact, many of sender.  It is possible that the SDP parameters this
   specification defines are also supported by 'external-body' body
   parts.  The MMUSIC working group decided file sender
   does not to use 'external-body'
   body parts because have a number of existing offer/answer implementations
   do matching file or does not support multipart bodies.

   The information carried want to send the file, in
   which case the SDP offer is rejected.

   The attributes defined in Section 6
   could potentially be encoded describing each file are provided in SDP by a single set of
   new SDP attribute.  The MMUSIC
   working group decided attributes, most of which have been directly borrowed from
   MIME.  This way, user agents can decide whether or not to follow this approach because it is
   expected that implementations support only accept a subset of
   given file transfer based on 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 file's name, size, description,
   hash, icon (e.g., if the information was encoded in file is a single picture), etc.

   SDP attribute, those
   rules, which relate direction attributes (e.g., 'sendonly', 'recvonly') are used to backwards compatibility, would need
   indicate the direction of the transfer, i.e., whether the SDP offerer
   is willing to be
   redefined specifically for send of receive the file.  Assuming that parameter.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", the answerer
   accepts the file transfer, the actual transfer of the files takes
   place with ordinary MSRP.  Note that the 'sendonly' and "OPTIONAL" in this
   document are 'recvonly'
   attributes refer to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

3.  Definitions

   For the purpose direction of this document, the following definitions specified
   in RFC 3264 [RFC3264] apply:

   o  Answer
   o  Answerer
   o  Offer
   o  Offerer

   Additionally, we define MSRP SEND requests and do not
   preclude other protocol elements (such as 200 responses, REPORT
   requests, etc.).

      In principle the following terms:

   File sender:   The file transfer can work even with an endpoint
      supporting only regular MSRP without understanding the extensions
      defined herein, in a particular case where that endpoint is willing to send a file to both
      the SDP answerer and the file receiver.
   File receiver:  The regular MSRP endpoint that is willing
      answers the offer as it would answer any ordinary MSRP offer
      without paying attention to receive the extension attributes.  In such a file from
      scenario the user experience would, however, be reduced, since 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 sender. attributes.

5.  File selector:   A tuple of file attributes that selector

   When the SDP offerer
      includes in is the SDP in order file the offer needs to select unambiguously
   identify the requested file.  For this purpose we introduce the
   notion of a file at the SDP answerer.
      This selector, which is described in a tuple composed of one or more detail in Section 5.
   Push operation:   A file transfer operation where
   of the SDP offerer
      takes following individual selectors: the role name, size, type, and hash
   of the file.  The file sender and the SDP answerer takes role selector can include any number of selectors,
   so all four of them do not always need to be present.

   The purpose of the file receiver.
   Pull operation:   A file transfer operation where selector is to provide enough information
   about the SDP offerer
      takes file to the role of remote entity, so that both the file receiver local and the SDP answerer takes
   remote entity can refer to the
      role same file.  The file selector is
   encoded in a 'file-selector' media attribute in SDP.  The formal
   syntax of the 'file-selector' media attribute is described in
   Figure 1.

   The file sender.

4.  Overview of Operation

   An SDP offerer creates an SDP body that contains selection process is applied to all the description of
   one or more available files that at
   the offerer wants to send or receive. host.  The
   offerer sends process selects those file that match each of the SDP offer to
   selectors present in the remote endpoint. 'file-selector' attribute.  The SDP answerer result can accept
   be zero, one, or reject more files, depending on the transfer of each presence of those files.

   The actual file transfer is carried out using the Message Session
   Relay Protocol (MSRP) [RFC4975].  Each
   mentioned selectors in the SDP "m=" line describes an
   MSRP media stream used to and depending on the available files
   in a host.  The file transfer mechanism specified in this document
   requires that a single file selector eventually results at a time.  That is,
   the transfer of multiple simultaneous files requires multiple "m="
   lines and corresponding MSRP media streams.  It should be noted that
   multiple MSRP media streams can share most in 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 is accompanied with a few
   attributes describing the
   file to be transferred.  If the file sender
   generates the SDP offer, chosen.  Typically, if the attributes describe a local file hash selector is known, it is
   enough to be
   sent (push), and the produce a file receiver can use this information selector that points to either
   accept exactly zero or reject the transfer. one
   file.  However, if the SDP offer a file selector that selects a unique file is
   generated not
   always known by the file receiver, offerer.  Sometimes only the attributes are intended to
   characterize a particular name, size or type
   of file that are known, so the file receiver selector may result in selecting more
   than one file, which is willing to
   get (pull) from an undesired case.  The opposite is also
   true: if the file sender.  It selector contains a hash selector and a name
   selector, there is possible a risk that the file sender
   does not have remote host has renamed the file,
   in which case, although a matching file or whose computed hash equals the hash
   selector exists, the file name does not want to send match that of the file, in
   which case name
   selector, thus, the offer is rejected.

   The attributes describing each file are provided selection process will result in SDP by a set of
   new SDP attributes, most the
   selection of which have been directly borrowed from
   MIME. zero files.

   This way, user agents can decide whether or not to accept a
   given file transfer based on the file's name, size, description,
   hash, icon (e.g., if specification uses the file is a picture), etc.

   SDP direction attributes (e.g., 'sendonly', 'recvonly') are used Secure Hash Algorithm 1, SHA-1 [RFC3174].
   If future needs require adding support for different hashing
   algorithms, they will be specified as extensions to
   indicate this document.

   Implementations according to this specification MUST implement the direction
   'file-selector' attribute and MAY implement any of the transfer, i.e., whether the other
   attributes specified in this specification.  SDP offerer
   is willing offers and answers
   for file transfer MUST contain a 'file-selector' media attribute that
   selects the file to send be transferred and MAY contain any of receive the file.  Assuming that other
   attributes specified in this specification.

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

6.  Extensions to SDP

   We define a number of the files takes
   place with ordinary MSRP.  Note new SDP [RFC4566] attributes that provide the 'sendonly' and 'recvonly'
   attributes refer
   required information to describe the direction transfer of MSRP SEND requests and do not
   preclude other protocol elements (such as 200 responses, REPORT
   requests, etc.).

      In principle the a file transfer can work even with an endpoint
      supporting MSRP.
   These are all media level only regular MSRP without understanding the extensions
      defined herein, attributes in a special case where that endpoint SDP.  The following is
   the
      recipient formal ABNF syntax [RFC5234] 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 selector

   Specially in case these new attributes.  It is
   built above 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 [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183
   [RFC2183], RFC 2392 [RFC2392], and 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 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 in RFC 4566

   file-selector-attr   = "file-selector" [":" 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 *(SP selector)]
   selector is encoded in a 'file-selector' media attribute in SDP.  The
   formal syntax of the 'file-selector' media attribute is described             = filename-selector / filesize-selector /
                          filetype-selector / hash-selector

   filename-selector    = "name:"  DQUOTE filename-string DQUOTE
                                       ; DQUOTE 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 in the 'file-selector' attribute.  Thus, a
   file selector can point to zero, one, 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 more files, depending on the
   presence of the mentioned selectors in the SDP and depending on the
   available files percent
   percent-encoded      = "%" HEXDIG HEXDIG
                                ; HEXDIG defined in a host.  The file transfer mechanism specified RFC 5234

   filesize-selector    = "size:" filesize-value
   filesize-value       = integer        ;integer defined in
   this document requires that a file selector eventually results at
   most RFC 4566

   filetype-selector    = "type:" type "/" subtype *(";"parameter)
                                      ; parameter defined in a single file to be chosen.  Typically, if the hash selector
   is known, it is enough to produce a file selector that points to
   exactly zero or one file.  However, a file selector that selects a
   unique file is not always known by the offerer.  Sometimes only the
   name, size or RFC 2045
   type of file are known, so the file selector may result                 = token       ; token defined in selecting more than one file, which is an undesired case.  The
   opposite is also true: if the file selector contains a hash selector
   and a name selector, there is a risk that the remote host has renamed
   the file, 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 which case, although a file whose computed hash equals
   the hash selector exists, the file name does not match that of the
   name selector, thus, the file selection process will result upper-case hex, separated
                                ; by colons.
                                ; HEXDIG defined in the
   selection of zero 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 RFC 2822
                             ; numeric timezones (+HHMM or -HHMM)
                             ; must be used
                             ; DQUOTE defined in RFC 5234 files.

   This specification uses

   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 Secure Hash Algorithm 1, SHA-1 [RFC3174].
   If future needs require adding support SDP extension

   When used for different hashing
   algorithms, they will be specified as extensions to this document.

   Implementations according to this specification MUST implement capability query (see Section 8.5), the 'file-selector'
   attribute and MAY implement MUST NOT contain any of the other
   attributes specified in selector, because its presence merely
   indicates compliance to this specification.

   When used in an SDP offers and answers
   for file transfer MUST contain a offer or answer, the 'file-selector' media attribute that
   selects
   MUST contain at least one selector.  Selectors characterize the file
   to be transferred and MAY contain any of the other
   attributes specified transferred.  There are four selectors in this specification.

   The 'file-selector' media attribute is also useful when learning attribute:
   'name', 'size', 'type', and 'hash'.

   The 'name' selector in the
   support 'file-selector' attribute contains the
   filename of the file transfer offer/answer capability that this
   document specifies.  This content enclosed in double quotes.  The filename is further explained
   encoded in Section 8.4.

6.  Extensions to SDP

   We define a number UTF-8 [RFC3629].  Its value SHOULD be the same as the
   'filename' parameter of new SDP [RFC4566] attributes the Content-Disposition header field
   [RFC2183] that provide would be signaled by the
   required information actual file transfer.  If a
   file name contains double quotes or any other character that the
   syntax does not allow in the 'name' selector, they MUST be percent-
   encoded.  The 'name' selector MUST NOT contain characters that can be
   interpreted as directory structure by the local operating system.  If
   such characters are present in the file name, they MUST be percent-
   encoded.

      Note that the 'name' selector might still contain characters that,
      although not meaningful for the local operating system, might
      still be meaningful to describe the transfer of 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 with MSRP.
   These system, such as the
      creation of a local file.  Among other things, implementations can
      percent-encode characters that are all media level only attributes in SDP. meaningful to the local
      operating system before doing file system local calls.

   The following is 'size' selector in the formal ABNF syntax [RFC4234] 'file-selector' attribute indicates the
   size of these new attributes.  It is
   built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183
   [RFC2183], RFC 2392 [RFC2392], and 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 file in RFC 4566

   file-selector-attr   = "file-selector" [":" octets.  The value of this attribute SHOULD be
   the same as the 'size' parameter of the Content-Disposition header
   field [RFC2183] that would be signaled by the actual file transfer.
   Note that the 'size' selector *(SP 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             = filename-selector / filesize-selector /
                          filetype-selector / hash-selector

   filename-selector    = "name:"  DQUOTE filename-string DQUOTE
                                       ; DQUOTE defined in RFC 4234
   filename-string      = 1*(filename-char/percent-encoded)
   filename-char        = %x01-09/%x0B-0C/%x0E-21/%x23-24/%26-FF)
                                 ;any byte except NUL, CR, LF,
                                 ;double quotes, or percent
   percent-encoded      = "%" HEXDIG HEXDIG
                                ; HEXDIG defined in RFC 4234

   filesize-selector    = "size:" filesize-value
   filesize-value       = integer        ;integer defined in RFC 4566

   filetype-selector    = "type:" type "/" subtype *(";"parameter)
                                      ; parameter defined the 'file-selector' attribute contains the
   MIME media and submedia types of the content.  In general, anything
   that can be expressed in a Content-Type header field (see RFC 2045
   type                 = token       ; token defined
   [RFC2045]) can also be expressed with the 'type' selectors.  Possible
   MIME Media Type values are the ones listed in RFC 4566
   subtype              = token

   hash-selector        = "hash:" hash-algorithm ":" hash-value
   hash-algorithm       = token     ;see the IANA Hash Function
                                    ;Textual Names registry
                                    ;only "sha-1" currently supported
   hash-value           = 2HEXDIG *(":" 2HEXDIG)
                                ; Each byte in upper-case hex, separated
                                ; by colons.
                                ; HEXDIG defined in RFC 4234

   file-tr-id-attr      = "file-transfer-id:" file-tr-id-value
   file-tr-id-value     = token

   file-disp-attr       = "file-disposition:" file-disp-value
   file-disp-value      = token

   file-date-attr       = "file-date:"  date-param *(SP date-param)

   date-param           = c-date-param / m-date-param / r-date-param
   c-date-param         = "creation:" DQUOTE date-time DQUOTE
   m-date-param         = "modification:" DQUOTE date-time DQUOTE
   r-date-param         = "read:" DQUOTE date-time DQUOTE
                             ; date-time is defined in RFC 2822
                             ; numeric timezones (+HHMM or -HHMM)
                             ; must be used
                             ; DQUOTE defined in RFC 4234  files.

   file-icon-attr       = "file-icon:" file-icon-value
   file-icon-value      = cid-url        ;cid-url defined in RFC 2392
   file-range-attr      = "file-range:" start-offset "-" stop-offset
   start-offset         = integer        ;integer defined for
   MIME Media Types [1].  Zero or more parameters can follow.  The
   syntax of 'parameter' is specified in RFC 4566
   stop-offset          = integer / "*"

                   Figure 1: Syntax of the SDP extension

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

   When used 2045 [RFC2045] .

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

   The 'name' selector in the 'file-selector' attribute contains  This is commonly used by
   file transfer protocols.  For example, FLUTE
   [I-D.ietf-rmt-flute-revised] uses hashes (called message digests) to
   verify the
   filename contents of the content enclosed in double quotes. transfer.  The filename is
   encoded in UTF-8 [RFC3629].  Its value SHOULD be the same as the
   'filename' parameter purpose of the Content-Disposition header field
   [RFC2183] that would be signaled by 'hash'
   selector is two-fold: On one side, in pull operations, it allows the actual
   file transfer.  If receiver to identify a remote file name contains double quotes or any other character by its hash rather than by
   its file name, providing that the
   syntax does not allow in file receiver has learned the 'name' selector, they MUST be percent-
   encoded.  The 'name' selector MUST NOT contain characters that can be
   interpreted as directory structure hash
   of the remote file by some out-of-band mechanism.  On the local operating system.  If
   such characters are present other side,
   in either push or pull operations, it allows the file name, they 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 receiver to
   verify the remote operating system (e.g., '\',
      '/', ':').  Therefore, implementations are responsible for
      sanitizing contents of the input received from file, or even avoid unnecessary
   transmission of an existing file.

      The address space of the remote endpoint before
      doing a local operation SHA-1 algorithm is big enough to avoid
      any collision in hash computations in between two endpoints.  When
      transferring files, the local actual file system, such as transfer protocol should
      provide reliable transmission of data, so verifications of
      received files should always succeed.  However, if endpoints need
      to protect the
      creation integrity of a local file.  Among file, they should use some other things, implementations can
      percent-encode characters that are meaningful to
      mechanism than the local
      operating system before doing file system local calls.

   The 'size' 'hash' selector specified in this memo.

   The 'hash' selector includes the 'file-selector' attribute indicates the
   size of the file hash algorithm and its value.
   Possible hash algorithms are those defined in octets.  The value of this attribute SHOULD be the same as the 'size' parameter IANA registry of
   Hash Function Textual Names [2].  Implementations according to this
   specification MUST add a US Secure Hash Algorithm 1 (SHA1) [RFC3174]
   value if the Content-Disposition header
   field [RFC2183] that would be signaled by the actual file transfer.
   Note that the 'size' 'hash' selector merely includes the file size, and does
   not include any potential overhead added by is present.  If need arises, extensions
   can be drafted to support several hashing algorithms.  Therefore,
   implementations according to this specification MUST be prepared to
   receive SDP containing more than a wrapper, such as
   message/cpim [RFC3862].

   The 'type' single 'hash' selector in the
   'file-selector' attribute contains attribute.

   The value of the
   MIME media and submedia types 'hash' selector is the byte string resulting of
   applying the content.  In general, anything
   that can be expressed in a Content-Type header field (see RFC 2045
   [RFC2045]) can also be expressed with hash algorithm to the 'type' selectors.  Possible
   MIME Media Type values are content of the ones listed in whole file, even
   when the IANA registry for
   MIME Media Types [1].  Zero or more parameters can follow.  The
   syntax file transfer is limited to a number of 'parameter' octets (i.e., the
   'file-range' attribute is specified in RFC 2045 [RFC2045] . indicated).

   The 'hash' selector in the 'file-selector' 'file-transfer-id' attribute provides a hash
   computation of randomly chosen globally
   unique identification to the actual file to be transferred.  This transfer.  It is commonly used by to
   distinguish a new file transfer protocols.  For example, FLUTE
   [I-D.ietf-rmt-flute-revised] uses hashes (called message digests) to
   verify the contents request from a repetition of the transfer.  The purpose SDP
   (or the fraction of the 'hash'
   selector SDP that deals with the file description).
   This attribute is two-fold: On one side, described in pull operations, it allows the
   file receiver to identify much greater detail in Section 8.3.

   The 'file-disposition' attribute provides a remote file by its hash rather than by
   its file name, providing that suggestion to the file receiver has learned other
   endpoint about the hash intended disposition of the remote file by some out-of-band mechanism.  On file.  Section 7
   provides further discussion of the other side,
   in either push or pull operations, it allows possible values.  The value of
   this attribute SHOULD be the file receiver to
   verify same as the contents disposition type parameter
   of the received file, Content-Disposition header field [RFC2183] that would be
   signaled by the actual file transfer protocol.

   The 'file-date' attribute indicates the dates at which the file was
   created, modified, or even avoid unnecessary
   transmission last read.  This attribute MAY contain a
   combination of an existing file.

      The address space the 'creation', 'modification', and 'read' parameters,
   but MUST NOT contain more than one of each type .

   The 'creation' parameter indicates the SHA-1 algorithm is big enough to avoid
      any collision in hash computations in between two endpoints.  When
      transferring files, date at which the actual file transfer protocol should
      provide reliable transmission of data, so verifications was
   created.  The value MUST be a quoted string which contains a
   representation of
      received files should always succeed.  However, if endpoints need
      to protect the integrity creation date of a file, they should use some other
      mechanism than the 'hash' selector specified file in this memo. RFC 2822 [RFC2822]
   'date-time' format.  Numeric timezones (+HHMM or -HHMM) MUST be used.
   The 'hash' selector includes value of this parameter SHOULD be the hash algorithm and its value.
   Possible hash algorithms are those defined in same as the IANA registry 'creation-date'
   parameter 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 Content-Disposition header field [RFC2183] that
   would be prepared to
   receive SDP containing more than a single 'hash' selector in the
   'file-selector' attribute.

   The value of the 'hash' selector is the byte string resulting of
   applying the hash algorithm to the content of the whole file, even
   when signaled by the actual file transfer is limited to a number of octets (i.e., the
   'file-range' attribute is indicated). protocol.

   The 'file-transfer-id' attribute provides a unique identification to 'modification' parameter indicates the date at which the actual file transfer.  It is used to distinguish was
   last modified.  The value MUST be a new file
   transfer request from quoted string which contains a repetition of the SDP (or the fraction
   representation of the
   SDP that deals with last modification date to the file description).  This attribute is
   described in much greater detail in Section 8.3.

   The 'file-disposition' attribute provides a suggestion to the other
   endpoint about the intended disposition of the file.  Section 7
   provides further discussion of the possible values. 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 disposition type
   'modification-date' parameter of the Content-Disposition header field
   [RFC2183] that would be signaled by the actual file transfer
   protocol.

   The 'file-date' attribute 'read' parameter indicates the dates date at which the file was
   created, modified, or last
   read.  This attribute MAY contain a
   combination of the 'creation', 'modification', and 'read' parameters,
   but MUST NOT contain more than one of each type .

   The 'creation' parameter indicates the date at which the file was
   created.  The value MUST be a quoted string which contains a
   representation of the creation date of the file in RFC 2822 [RFC2822]
   'date-time' format.  Numeric timezones (+HHMM or -HHMM) MUST be used.
   The value of this parameter SHOULD be the same as the 'creation-date'
   parameter of the Content-Disposition header field [RFC2183] that
   would be signaled by the actual file transfer protocol.

   The 'modification' parameter indicates the date at which the file was
   last modified.  The value MUST be a quoted string which contains a
   representation of the last modification date to the file in RFC 2822
   [RFC2822] 'date-time' format.  Numeric timezones (+HHMM or -HHMM)
   MUST be used.  The value of this parameter SHOULD be the same as the
   'modification-date' parameter of the 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  The value MUST be a quoted string which contains a
   representation of the last date the file was read in RFC 2822
   [RFC2822] 'date-time' format.  Numeric timezones (+HHMM or -HHMM)
   MUST be used.  The value of this parameter SHOULD be the same as the
   'read-date' parameter of the Content-Disposition header field
   [RFC2183] that would be signaled by the actual file transfer
   protocol.

   The 'file-icon' attribute can be useful with certain file types such
   as images.  It allows the file sender to include a pointer to a body
   that includes a small preview icon representing the contents of the
   file to be transferred, which the file receiver can use to determine
   whether it wants to receive such file.  The 'file-icon' attribute
   contains a Content-ID URL, which is specified in RFC 2392 [RFC2392].
   Section 8.7 8.8 contains further considerations about the 'file-icon'
   attribute.

   The 'file-range' attribute provides a mechanism to signal a chunk of
   a file rather than the complete file.  This enable use cases where a
   file transfer can be interrupted, resumed, even perhaps changing one
   of the endpoints.  The 'file-range' attribute contains the "start
   offset" and "stop offset" of the file, separated by a dash "-".  The
   "start offset" value refers to the position of the file where the
   file transfer should start.  The first byte of a file is denoted by
   the ordinal number "1".  The "stop offset" value refers position of
   the file where the file transfer should stop.  The "stop offset"
   value MAY contain a "*" if the total size of the file is not known in
   advance.  The absence of this attribute indicates a complete file,
   i.e., as if the 'file-range' attribute would have been present with a
   value "1-*".  The 'file-range' attribute must not be confused with
   the Byte-Range header in MSRP.  The former indicates the portion of a
   file that the application would read and pass onto the MSRP stack for
   transportation.  From the point of view of MSRP, the portion of the
   file is viewed as a whole message.  The latter indicates the number
   of bytes of that message that are carried in a chunk and the total
   size of the message.  Therefore, MSRP starts counting the delivered
   message at byte number 1, independently of position of that byte in
   the file.

   The following is an example of an SDP body that contains the
   extensions defined in this memo:

   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 SDP describing a 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.

7.  File Disposition Types

   The SDP Offer/Answer for file transfer allows the file sender to
   indicate a preferred disposition of the file to be transferred in a
   new 'file-disposition' attribute.  In principle, any value listed in
   the IANA registry for 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, the file sender may just want the file to
   be rendered immediately in the file receiver's device.  On the other
   hand, the file sender may just want to indicate the file recipient
   that the file should not be rendered at the reception of the file.
   The recipient's user agent may want to interact with the user
   regarding the file disposition or it may save the file until the user
   takes an action.  In any case, the exact actions are implementation
   dependent.

   To indicate that a file should be automatically rendered, this memo
   uses the existing 'render' value of the Content Disposition type in
   the new 'file-disposition' attribute in SDP.  To indicate that a file
   should not be automatically rendered, this memo users the existing
   'attachment' value of the Content-Disposition type in the new 'file-
   disposition' attribute in SDP.  The default value is 'render', i.e.,
   the absence of a 'file-disposition' attribute in the SDP has the same
   semantics as 'render'.

      The disposition value '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 main body of the mail message, and
         that their display should not be automatic, but contingent upon
         some further action of the user."
      In the case of this specification, the 'attachment' disposition
      type is used to indicate that the display of the file should not
      be automatic, but contingent upon some further action of the user.

8.  Protocol Operation

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

   Usually the

   A file transfer session is initiated when by the offerer sends sending an SDP
   offer to the answerer.  The answerer either accepts or rejects the
   file transfer session and sends an SDP answer to the offerer.

   We can differentiate two use cases, depending on whether the offerer
   is the file sender or file receiver:

   1.  The offerer is the file sender, i.e., the offerer wants to
       transmit a file to the answerer.  Consequently the answerer is
       the file receiver.  In this case the SDP offer contains a
       'sendonly' attribute, and accordingly the SDP answer contains a
       'recvonly' attribute.
   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 that 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 or more "m=" lines, each one describing an line per file.  When MSRP
   session (and thus, one file is used as the transfer operation),
   mechanism, each "m=" line also describes a single MSRP session,
   according to the MSRP [RFC4975] procedures.  Any "m=" lines that may
   have already been present in a previous SDP exchange are normally
   kept unmodified; the new "m=" lines are added afterwards (Section 8.6
   describes cases when "m=" lines are re-used).  All the media line
   attributes specified and required by MSRP [RFC4975] (e.g., "a=path",
   "a=accept-types", etc.)  MUST be included as well.  For each file to be transferred
   there MUST be a separate "m=" line.

8.1.1.  The Offerer is a File Sender

   In a push operation, the file sender creates and SDP offer describing
   the file to be sent.  The file sender MUST add a 'file-selector'
   attribute media line containing at least one of the 'type', 'size',
   'hash' selectors in indicating the type, size, or hash of the file,
   respectively.  The  If the file sender wishes to start a new file
   transfer, the file sender MUST add a 'file-transfer-id' attribute
   containing a new randomly chosen globally unique random identifier value, which
   does not clash with other previously used values in the same
   attribute. value.
   Additionally, the file sender MUST add a session or media 'sendonly'
   attribute to the SDP offer.  Then the file sender sends the SDP offer
   to the file receiver.

      Not all the selectors in the 'file-selector' attribute might be
      known when the file sender creates the SDP offer, for example,
      because the host is still processing the file.

      The 'hash' selector in the 'file-selector' attribute contains
      valuable information to the file receiver to identify whether the
      file is already available and need not be transmitted.

   The file sender MAY also add a 'name' selector in the 'file-selector'
   attribute, and a 'file-icon', 'file-disposition', and 'file-date'
   attributes further describing the file to be transferred.  The 'file-
   disposition' attribute provides a presentation suggestion, (for
   example: the file sender would like the file receiver to render the
   file or not).  The three date attributes provide the answerer with an
   indication of the age of the file.  The file sender MAY also add a
   'file-range' attribute indicating the start and stop offsets of the
   file.

   When the file sender receives the SDP answer, if the port number of
   the answer for a file request is non-zero, the file sender starts the
   transfer of the file according to the negotiated parameters in SDP.

8.1.2.  The Offerer is a File Receiver

   In a pull operation, the file receiver creates the SDP offer and
   sends it to the file sender.  The file receiver MUST include a 'file-
   selector' attribute and SHOULD add, at least, one of the selector
   defined for that attribute (i.e., 'name', 'type', 'size', or 'hash').

   In many cases, if the hash of the file is known, that is enough to
   identify the file, therefore, the offerer can include only a 'hash'
   selector.  However, specially in cases where the hash of the file is
   unknown, the file name, size, and type can provide a description of
   the file to be fetched.  The  If the file receiver wishes to start a new
   file transfer it MUST also add a 'file-
   transfer-id' 'file-transfer-id' attribute with containing a newly created
   new globally unique random value (new within
   the current session). value.  The file receiver MAY also add a
   'file-range' attribute indicating the start and stop offsets of the
   file.  There is no need to for the file receiver to include further
   file attributes in the SDP offer, thus it is RECOMMENDED that SDP
   offerers do not include any other file attribute defined by this
   specification (other than the mandatory ones).  Additionally, the
   file receiver MUST create an SDP offer that contains a session or
   media 'recvonly' attribute.

   When the file receiver receives the SDP answer, if the port number of
   the answer for a file request is non-zero, then the file receiver
   should receive the file using the protocol indicated in the m= "m="
   line.  If the SDP answer contains a supported hashing algorithm in
   the 'hash' selectors of the 'file-selector' attribute, then the file
   receiver SHOULD compute the hash of the file after its reception and
   check it against the hash received in the answer.  In case the
   computed hash does not match the one contained in the SDP answer, the
   file receiver SHOULD consider that the file transfer failed and
   SHOULD inform the user.

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 the file attributes
   described in this specification.  This way, the answerer can reject
   individual files by setting the port number of their associated "m="
   lines to zero, as per regular SDP [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 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
   whose values mirror the corresponding values of the SDP offer.

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

8.2.1.  The Answerer is a File Receiver

   In a push operation the SDP answerer is the file receiver.  When the
   file receiver gets the SDP offer, it first examines the 'file-
   transfer-id' port number.
   If the port number is set to zero, the file transfer operation is
   closed, and no more data is expected over the media stream.  Then, if
   the port number is different than zero, the file receiver inspects
   the 'file-transfer-id' attribute.  If the value of the 'file-transfer-id' 'file-
   transfer-id' attribute has been previously used then the existing
   session remains without changes, perhaps the file transfer is still
   in progress, or perhaps it has concluded, but there are no change
   with respect the current status.  The  In any case, independently of the
   port number, the SDP answerer creates a regular SDP answer and sends
   it to the offerer.

   If the 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 describe the file and typically requests permission
   from the user to accept or reject the reception of the file.  If the
   file transfer operation is accepted, the file receiver MUST create an
   SDP answer according to the procedures specified in RFC 3264
   [RFC3264].  If the offer contains 'name', 'type', 'size' selectors in
   the 'file-selector' attribute, the answerer MUST copy them into the
   answer.  The file receiver copies the value of the 'file-transfer-id'
   attribute to the SDP answer.  Then the file receiver MUST add a
   session or media 'recvonly' attribute according to the procedures
   specified in RFC 3264 [RFC3264].  The file receiver 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 local file with
   the same hash is already available, in which case, this could imply
   the reception of a duplicated file.  It is up to the answerer to
   determine whether the file transfer is accepted or not in case of a
   duplicated file.

   If the SDP offer contains a 'file-range' attribute and the file
   receiver accepts to receive the range of bytes declared in there, the
   file receiver MUST include a 'file-range' attribute in the SDP answer
   with the same range of values.  If the file receiver does not accept
   the reception of that range of bytes, it SHOULD reject the transfer
   of the file.

8.2.2.  The Answerer is a File Sender

   In a pull operation the answerer is the file sender.  In this case,
   the file sender MUST first inspect the value of the
   'file-transfer-id' attribute.  If the has not been previously been
   used throughout the session, then acceptance of the file MUST provoke
   the transfer of the file over the negotiated protocol.  However, if
   the value has been previously used by another file transfer operation
   within the session, then the file sender MUST NOT alert the user and
   MUST NOT start a new transfer of the file.  No matter whether an
   actual file transfer is initiated or not, the file sender MUST create
   a proper SDP answer that contains the 'file-transfer-id' attribute
   with the same value received in the SDP offer, and then it MUST
   continue processing the SDP answer.

   The file sender MUST always create an SDP answer according to the SDP
   offer/answer procedures specified in RFC 3264 [RFC3264].  The file
   sender inspects the file selector of the received SDP offer, which is
   encoded in the 'file-selector' media attribute line.  Then the file
   sender applies the file selector, which implies selecting those files
   that match one by one with the 'name', 'type', 'size', and 'hash'
   selectors of the 'file-selector' attribute line (if they are
   present).  The file selector identifies zero or more candidate files
   to be sent.  If the file selector is unable to identify any file,
   then the answerer MUST reject the MSRP stream for file transfer by
   setting the port number to zero, and then the file sender SHOULD also
   reject the SDP as per procedures in RFC 3264 [RFC3264], if this is
   the only stream described in the SDP offer.

   If the file selector points to a single file and the file sender
   decides to accept the file transfer, the file sender MUST create an
   SDP answer that contains a 'sendonly' attribute, according to the
   procedures described RFC 3264 [RFC3264].  The file sender SHOULD add
   a 'hash' selector in the answer with the locally computed SHA-1 hash
   over the complete file.  If a hash value computed by the file sender
   differs from that specified by the file receiver, the file sender can
   either send the file without that hash value or reject the request by
   setting the port in the media stream to zero.  The file sender MAY
   also include a 'type' selector in the 'file-selector' attribute line
   of the SDP answer.  The answerer MAY also include a 'file-icon' and
   'file-disposition' attributes to further describe the file.  Although
   the answerer MAY also include a 'name' and 'size' selectors in the
   'file-selector' attribute, and a 'file-date' attribute, it is
   RECOMMENDED not to include them in the SDP answer if the actual file
   transfer protocol (e.g., MSRP [RFC4975]) can accommodate a Content-
   Disposition header field [RFC2183] with the equivalent parameters.

      The whole idea of adding file descriptors to SDP is to provide a
      mechanism where a file transfer can be accepted prior to its
      start.  Adding any SDP attributes that are otherwise signaled
      later in the file transfer protocol would just duplicate the
      information, but will not provide any information to the offerer
      to accept or reject the file transfer (note that the offerer is
      requesting a file).

   Last, if the file selector points to multiple candidate files, the
   answerer MAY use some local policy, e.g. consulting the user, to
   choose one of them to be defined in the SDP answer.  If that choice
   cannot be done, the answerer SHOULD reject the MSRP media stream for
   file transfer (by setting the port number to zero).

      If the need arises, future specifications can provide a suitable
      mechanism that allows to either select multiple files or, e.g.,
      resolve ambiguities by returning a list of files that match the
      file selector.

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

8.3.  The 'file-transfer-id' attribute

   This specification creates an extension to the SDP Offer/Answer Model
   [RFC3264], and because of that, it is assumed that the existing SDP
   behavior is kept intact.  The SDP behavior requires, for example,
   that SDP is sent again to the remote party in situations where the
   media description or perhaps other SDP parameters have not changed
   with respect a previous offer/answer exchange.  Let's consider the
   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 transfer operation and occur while the file
   transfer was still going on, there would be no means to detect
   whether the SDP creator wanted to abort the current file transfer
   operation and initiate a new one or the SDP file description was
   included in the SDP due to other reasons (e.g., session timer
   refresh).

   A similar scenario occurs when two endpoints have successfully agreed
   on a file transfer, which is currently taking place when one of the
   endpoints wants to add additional media streams to the existing
   session.  In this case, the endpoint sends a re-INVITE request that
   contains SDP.  The SDP needs to maintain the media descriptions for
   the current ongoing file transfer and add the new media descriptions.
   The problem is that, the other endpoint is not able to determine if a
   new file transfer is requested or not.

   In other cases, a file transfer was successfully completed.  Then, if
   an endpoint re-sends the SDP offer with the media stream for the file
   transfer, then the other endpoint wouldn't be able to determine
   whether a new file transfer should start or not.

   To address these scenarios this specification defines the 'file-
   transfer-id' attribute which contains a globally unique random
   identifier allocated to the file transfer
   identifier. operation.  The file
   transfer identifier helps both endpoints to determine whether the SDP
   offer is requesting a new file transfer or it is a repetition of the
   SDP.  A new file transfer is one that, in case of acceptance, will
   provoke the actual transfer of a file.  This is typically the case of
   new offer/answer exchanges, or in cases where an endpoint wants to
   abort the existing file transfer and re-
   start re-start the file transfer once
   more.  On the other hand, the repetition of the SDP does not lead to
   any actual file to be transferred, potentially because the file
   transfer is still going on or because it has already finished.  This
   is the case of a repeated offer/answer exchanges, which can be due to
   a number of reasons (session timer, addition/removal of other media
   types in the SDP, update in SDP due to changes in other session
   parameters, etc.).

   Implementations according to this specification MUST include a 'file-
   transfer-id' attribute in SDP offers and answers.  The SDP offerer
   MUST select a file transfer identifier according to the syntax and
   add it to the 'file-transfer-id' attribute.  The SDP answerer MUST
   copy the value of the 'file-transfer-id' attribute in the SDP answer.

   The file transfer identifier MUST be unique within the current
   session (never used before in this session), and it is RECOMMENDED to
   be unique across different sessions.  It is RECOMMENDED to select a
   relatively big random identifier (e.g., 32 characters) to avoid
   duplications.  The SDP answerer MUST keep track of the proposed file
   transfer identifiers in each session and copy the value of the
   received file transfer identifier in the SDP answer.

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

   If an endpoint sets the port number to zero in the media description
   of a file transfer, for example because it wants to reject the file
   transfer operation, then the SDP answer should MUST mirror the value of the
   'file-transfer-id' attribute included in the SDP offer.  This
   effectively means that setting a media stream to zero has higher
   precedence than any value that the 'file-transfer-id' attribute can
   take.

   As a side effect, the 'file-transfer-id' attribute can be used for
   aborting and restarting again an ongoing file transfer.  Assume that
   two endpoints agree on a file transfer and the actual transfer of the
   file is taking place.  At some point in time in the middle of the
   file transfer, one endpoint sends a new SDP offer, equal to the
   initial one, one except for the value of the 'file-transfer-id' attribute,
   which is a new value within the session. globally unique random value.  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.  Section 8.4 further discusses file
   transfer abortion.

   In another scenario, an endpoint that has successfully transferred a
   file wants to send an SDP due to other reasons than the transfer of a
   file.  The SDP offerer creates an SDP file description that maintains
   the media description line corresponding to the file transfer.  The
   SDP offerer MUST then set the port number to zero and MUST keep the
   same value of the 'file-transfer-id' attribute that the initial file
   transfer got.

8.4.  Indicating File Transfer Offer/Answer Capability

   The SDP Offer/Answer Model [RFC3264] provides provisions for
   indicating  Aborting an ongoing file transfer operation

   A file sender that wishes to abort an ongoing file transfer operation
   without initiating an alternative file transfer, if an ongoing MSRP
   SEND request is being transmitted, aborts the MSRP message by
   including the '#' character in the continuation field of the end-line
   of a capability SEND request, according to another endpoint the MSRP procedures (see Section 9 7.1
   of RFC
   3264 [RFC3264]).  The mechanism assumes a high-level protocol, such
   as SIP [RFC3261], that provides 4975 [RFC4975]).  Since a capability query (such file is transmitted as a SIP
   OPTIONS request).  RFC 3264 [RFC3264] indicates how to build one MSRP
   message, aborting the SDP
   that is included in MSRP message effectively aborts the response to such request.  As such, RFC 3264
   indicates that and endpoint builds an file
   transfer.  Then the file sender SHOULD close the MSRP session.  This
   is done by sending a new SDP body offer that contains an sets the port number to zero
   in the related "m=" line that contains the media type (message, for MSRP).  An endpoint
   that implements describes the procedures specified in this document SHOULD also
   add a 'file-selector' media attribute for file transfer (see
   Section 8.2 of RFC 3264 [RFC3264]).  This SDP offer MUST conform with
   the "m=message" line. requirements of Section 8.1.1.  The
   'file-selector' media 'file-transfer-id' attribute
   MUST be empty, i.e., it MUST NOT
   contain any selector.  The endpoint MUST NOT add any of the other same that identifies the ongoing transfer.  Then the file attributes defined in this specification.

8.5.  Re-usage of Existing m= Lines in SDP

   The
   sender sends the SDP Offer/Answer Model [RFC3264] provides rules offer to the file recipient.

   A file receiver that allow receives the above SDP
   offerers and answerers to modify an existing media line, i.e., re-use offer creates an existing media line with different attributes.  The same is also
   possible when SDP signals a file transfer operation
   answer according to the
   rules procedures of this memo.  Therefore, the procedures defined in RFC SDP offer/answer (RFC 3264
   [RFC3264], in particular those defined in Section 8.3,
   [RFC3264]).  This SDP answer MUST apply for
   file transfer operations.  An endpoint that wants to re-use an
   existing m= line to start conform with the file transfer of another file creates a
   different 'file-selector' attribute and a different value requirements of the
   'file-transfer-id' attribute.

   If
   Section 8.2.1.  Then the file offerer re-sends an recipient sends this SDP offer with a port different than
   zero, then answer to the 'file-transfer-id' attribute determines whether a new
   file transfer will start or whether the sender.

   A file receiver that wishes to abort an ongoing transfer does not need first must
   determine if the MSRP sender wishes to start. receive failure reports.  If
   the SDP answerer accepts current MSRP SEND request sets the SDP, Failure-Report header to a
   value different than "no", then the file transfer
   starts from receiver generates an MSRP
   413 response to the indicated byte (if a 'file-range' attribute is
   present).

8.6. current MSRP Usage

   The SEND request (see Section 10.5 of
   RFC 4975 [RFC4975]).  Then the file transfer service specified receiver SHOULD close the MSRP
   session.  This is done by sending a new SDP offer that sets the port
   number to zero in this document uses the related "m=" lines
   to describe line that describes the unidirectional file
   transfer (see Section 8.2 of a file.  Consequently,
   each MSRP session established following RFC 3264 [RFC3264]).  This SDP offer
   MUST conform with the procedures requirements expressed in Section 8.1
   and Section 8.2 is only used to transfer a single file.  So, senders 8.1.2.  The
   'file-transfer-id' attribute MUST only use be the dedicated MSRP session to send same that identifies the
   ongoing transfer.  Then the file described
   in sender sends 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 to the purpose.  Alternatively a
   file transfer may be
   conducted within receiver.

   A file sender that receives an existing multimedia session, without regard for SDP offer setting the media port number to
   zero in use within that session.  Of particular note, the related "m=" line for file
   transfer may be done within a multimedia session containing transfer, first, if an ongoing
   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 SEND request is still being used by MSRP
   (either regular MSRP for instant messaging or an ongoing file
   transfer).  Rather transmitted, 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 aborts 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 by
   including the '#' character in several chunks, but
   from the MSRP point continuation field 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 end-line
   of a
   chunk before sending the following one.  Therefore, it is valid to
   send pipelined MSRP SEND requests containing chunks of request, according to the same MSRP
   message (the file). procedures (see Section 9.1 contains an example 7.1
   of RFC 4975 [RFC4975]).  Since a file
   transfer using pipelined MSRP requests.

   The is transmitted as one MSRP specification [RFC4975] defines a 'max-size' SDP attribute.
   This attribute specifies
   message, aborting the maximum number of octets of an MSRP message that effectively aborts the creator of file
   transfer.  Then the file sender creates an SDP is willing answer according to receive (notice
   once more
   the definition procedures of "MSRP message").  File receivers MAY add
   a 'max-size' attribute to the MSRP m= line that specifies the file,
   indicating the maximum number of octets of an MSRP message.  File
   senders MUST NOT exceed the 'max-size' limit for any message sent in
   the resulting session.

   In the absence of a 'file-range' attribute in the SDP, the MSRP file
   transfer SDP offer/answer (RFC 3264 [RFC3264]).  This
   SDP answer MUST start with the first byte of the file and end conform 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 requirements of bytes from the file (start and stop offset
   bytes). Section 8.2.2.  Then
   the file sender application MAY wrap those bytes in an
   appropriate wrapper.  MSRP mandates implementations sends this SDP answer to implement the
   message/cpim wrapper [RFC3862].  Usage of a wrapper is negotiated in the file 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 8.6 in 9 of 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
   3264 [RFC3264]).  The mechanism assumes a high-level protocol, such
   as SIP [RFC3261], that provides a capability query (such as a whole message, and will start numbering bytes with SIP
   OPTIONS request).  RFC 3264 [RFC3264] indicates how to build the number 1.

   Note SDP
   that the default content disposition of MSRP bodies is 'render'.
   When MSRP is used to transfer files, the MSRP Content-Disposition
   header can also take the value 'attachment' as indicated included in
   Section 7.

   Once the file transfer is completed, the file sender SHOULD close the
   MSRP 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 response to include a small preview of
   an image file: an icon.  A 'file-icon' attribute contains a CID URL
   [RFC2392] such request.  As such, RFC 3264
   indicates that points to and endpoint builds an additional SDP body that contains an "m="
   line that contains the actual
   icon.  Since media type (message, for MSRP).  An endpoint
   that implements the icon is sent as procedures specified in this document SHOULD also
   add a separate body along the SDP body, 'file-selector' media attribute for the file sender "m=message" line.  The
   'file-selector' media attribute MUST wrap 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.6.  Re-usage of Existing "m=" Lines in SDP body

   The SDP Offer/Answer Model [RFC3264] provides rules that allow SDP
   offerers and the icon bodies in answerers to modify an existing media line, i.e., re-use
   an existing media line with different attributes.  The same is also
   possible when SDP signals a MIME
   multipart/related body.  Therefore, implementations file transfer operation according to this
   specification MUST implement the multipart/related MIME type
   [RFC2387].  When creating a multipart/related MIME wrapper,
   rules of this memo.  Therefore, the SDP
   body procedures defined in RFC 3264
   [RFC3264], in particular those defined in Section 8.3, MUST be the root body, which according apply for
   file transfer operations.  An endpoint that wants to RFC 2387 [RFC2387] is
   identified as re-use an
   existing "m=" line to start 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 file transfer of another file creates
   a different 'file-selector' attribute and point to selects a new globally
   unique random value of the
   root body, i.e., 'file-transfer-id' attribute.

   If 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 offerer re-sends an SDP offer that contains with 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 port different than
   zero, then the SDP
   offer, via 'file-transfer-id' attribute determines whether a higher protocol mechanism (e.g., SIP).  In this case, it
   is RECOMMENDED that the new
   file sender removes the icon body part,
   creates a single SDP body (i.e., without multipart MIME) and re-sends transfer will start or whether the SDP offer again.  This provides some backwards compatibility with file receives that do transfer does not implement this specification and increases
   the chances of getting need
   to start.  If the SDP accepted at answerer accepts the SDP, then file receiver.

   Since the icon is sent as part of transfer
   starts from the signaling, it indicated byte (if a 'file-range' attribute is recommended to
   keep icons restricted
   present).

8.7.  MSRP Usage

   The file transfer service specified in this document uses "m=" lines
   to describe the minimum number unidirectional transfer of bytes that provide
   significance.

9.  Examples

9.1.  Offerer sends a file to file.  Consequently,
   each MSRP session established following the Answerer

   This section shows an example flow for a file transfer scenario.  The
   example assumes that SIP [RFC3261] procedures in Section 8.1
   and Section 8.2 is only used to transport transfer a single file.  So, senders
   MUST only use the SDP
   offer/answer exchange, although dedicated MSRP session to send the SIP details are briefly shown file described
   in the sake of brevity.

   Alice, the SDP offerer, wishes to 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
   conducted within an image existing multimedia session, without regard for
   the media in use within that session.  Of particular note, file to Bob (the
   answerer).  Alice's User Agent Client (UAC) creates
   transfer may be done within a unidirectional multimedia session containing an MSRP
   session used for regular instant messaging.  If file transfer is
   initiated within an existing multimedia session, the SDP offer offerer MUST
   NOT reuse an existing "m=" line that contains the description of the 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 she wants to
   send is no longer being used.

   Additionally, implementations according to Bob's User Agent Server (UAS).  The description also includes
   an icon representing this specification MUST
   include a single file in a single MSRP message.  Notice that the contents MSRP
   specification defines "MSRP message" as a complete unit of the file to MIME or
   text content, which can be transferred.  The
   sequence flow split and delivered in more than one MSRP
   request; each of these portions of the complete message is shown called a
   "chunk".  So, it is still valid to send a file in Figure 3.

                   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 several chunks, but
   from the MSRP point of view, all the chunks together form an offerer sending MSRP
   message: the CPIM message that wraps the file.  When chunking, notice
   that MSRP does not require to wait for a file 200-class response for a
   chunk before sending the following one.  Therefore, it is valid to
   send pipelined MSRP SEND requests containing chunks of the same MSRP
   message (the file).  Section 9.1 contains an answerer

   F1: Alice constructs an example of a file
   transfer using pipelined MSRP requests.

   The MSRP specification [RFC4975] defines a 'max-size' SDP description attribute.
   This attribute specifies the maximum number of octets of an MSRP
   message that the file to be sent and
   attaches it creator of the SDP is willing to receive (notice
   once more the definition of "MSRP message").  File receivers MAY add
   a SIP INVITE request addressed 'max-size' attribute to Bob.

   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 the MSRP "m=" line that specifies the file,
   indicating the maximum number of image]
   Content-Disposition: icon

   [...small preview icon octets of the file...]

   --boundary71--

    Figure 4: INVITE request containing an SDP offer for file transfer
      NOTE: The Content-Type header field and the 'file-selector'
      attribute in MSRP message.  File
   senders MUST NOT exceed the above figure are split in several lines 'max-size' limit for
      formatting purposes.  Real implementations will encode it any message sent in a
      single line.

   From now on we omit
   the SIP details for resulting session.

   In the sake absence of brevity.

   F2: Bob receives a 'file-range' attribute in the INVITE request, inspects SDP, the SDP offer and
   extracts MSRP file
   transfer MUST start with the icon body, checks first byte of the creation date and file size, and
   decides to accept the file transfer.  So Bob creates end with 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
   last byte (i.e., the SDP offer for whole file transfer

      NOTE: The 'file-selector' is transferred).  If a 'file-range'
   attribute in the above figure is split present 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 SDP, the first chunk of file sender application MUST extract
   the file.

   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 indicated range of bytes of the JPEG image ...
   -------d93kswow+

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

   F5: Alice sends the second (start and last chunk.  Note that stop offset
   bytes).  Then the file sender application MAY wrap those bytes in an
   appropriate wrapper.  MSRP allows to
   send pipelined chunks, so there is no need mandates implementations to wait for the 200 (OK)
   response from implement 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 wrapper [RFC3862].  Usage of a wrapper is negotiated in
   the JPEG image ...
   -------op2nc9a$

     Figure 7: MSRP SEND request containing SDP (see Section 8.6 in RFC 4975 [RFC4975]).  Last, the second chunk of actual file

   F6: Bob acknowledges
   sender application delivers the reception of content (e.g., the first chunk. message/cpim body)
   to 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$
                      Figure 8: for transportation.  MSRP 200 OK response

   F7: Bob acknowledges will consider the reception of delivered content
   as a whole message, and will start numbering bytes with 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: number 1.

   Note that the default content disposition of MSRP 200 OK response

   F8: Alice terminates bodies is 'render'.
   When MSRP is used to transfer files, the SIP session by sending a SIP BYE request.

   F9: Bob acknowledges MSRP Content-Disposition
   header can also take the reception of value 'attachment' as indicated in
   Section 7.

   Once the BYE request and sends a 200
   (OK) response.

9.2.  Offerer requests a file from transfer is completed, the Answerer and second file transfer

   In this example Alice, sender SHOULD close the SDP offerer, first wishes
   MSRP session and MUST behave according to fetch a file
   from Bob, the SDP answerer.  Alice knows MSRP [RFC4975]
   procedures with respect closing MSRP sessions.  Note that Bob has MSRP
   session management is not related to TCP connection management.  As a specific file
   she wants
   matter of fact, MSRP allows multiple MSRP sessions to download.  She has learned share the hash of same
   TCP connection.

8.8.  Considerations about the 'file-icon' attribute

   This specification allows a file by some
   out-of-band mechanism.  The hash selector is enough sender to produce include a file
   selector small preview of
   an image file: an icon.  A 'file-icon' attribute contains a CID URL
   [RFC2392] that points to the specific file.  So, Alice creates an SDP
   offer additional body that contains the file descriptor.  Bob accepts the
   transmission and sends actual
   icon.  Since the file to Alice.  When Alice has completely
   received Bob's file, she intends to send icon is sent as a new image separate body along the SDP body,
   the file to Bob.
   Therefore Alice re-uses sender MUST wrap the existing SDP media line with different
   attributes body and updates the description of the new file she wants to
   send to Bob's User Agent Server (UAS).  In particular, Alice creates icon bodies in a new file transfer identifier since MIME
   multipart/related body.  Therefore, implementations according to this is a new file transfer
   operation.  Figure 10 shows
   specification MUST implement the sequence flow.

                   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 multipart/related MIME type
   [RFC2387].  When creating a file from multipart/related MIME wrapper, the
              answerer and then sending a file SDP
   body MUST be the root body, which according to RFC 2387 [RFC2387] is
   identified as the answer

   F1: Alice constructs an SDP description of first body in the file she wants multipart/related MIME wrapper or
   explicitly identified by the 'start' parameter.  According to
   receive RFC
   2387 [RFC2387], the 'type' parameter MUST be present and attaches point to the
   root body, i.e., the SDP offer body.

   Assume that an endpoint behaving according to this specification
   tries to send a SIP INVITE request addressed file to Bob.

   INVITE sip:bob@example.com SIP/2.0
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 1 INVITE
   Max-Forwards: 70
   Date: Sun, 21 May 2006 13:02:03 GMT
   Contact: <sip:alice@alicepc.example.com>
   Content-Type: application/sdp
   Content-Length: [length of SDP]

   v=0
   o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
   s=
   c=IN IP4 alicepc.example.com
   t=0 0
   m=message 7654 TCP/MSRP *
   a=recvonly
   a=accept-types:message/cpim
   a=accept-wrapped-types:*
   a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
   a=file-selector:hash:sha-1:
     72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
   a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2

    Figure 11: INVITE request containing a remote endpoint that neither implements
   this specification nor implements multipart MIME bodies.  The file
   sender sends an SDP offer for file transfer

      NOTE: that contains a multipart/related MIME body
   that includes an SDP body part and an icon body part.  The 'file-selector' attribute in the above figure is split
      in two lines for formatting purposes.  Real implementations file
   receiver, not supporting multipart MIME types, will
      encode reject the SDP
   offer, via a higher protocol mechanism (e.g., SIP).  In this case, it in
   is RECOMMENDED that the file sender removes the icon body part,
   creates a single line.

   From now on we omit the SIP details for SDP body (i.e., without multipart MIME) and re-sends
   the sake of brevity.

   F2: Bob SDP offer again.  This provides some backwards compatibility with
   file receives that do not implement this specification and increases
   the INVITE request, inspects chances of getting the SDP offer, computes accepted at the file descriptor and finds 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 local file whose hash equals to the one
   indicated 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
   the SDP.  Bob accepts sake of brevity.

   Alice, the file transmission and creates
   an SDP answer as follows:

   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 offerer, wishes to send an image 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 (the
   answerer).  Alice's User Agent Client (UAC) creates an MSRP
   SEND request a unidirectional
   SDP offer 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 description of the actual file

   F5: Alice acknowledges that she wants to
   send to Bob's User Agent Server (UAS).  The description also includes
   an icon representing the reception contents of the file to be transferred.  The
   sequence flow is shown in Figure 3.

                   Alice's UAC                 Bob's UAS
                         |                        |
                         |(1) (SIP) INVITE        |
                         |----------------------->|
                         |(2) (SIP) 200 OK        |
                         |<-----------------------|
                         |(3) (SIP) ACK           |
                         |----------------------->|
                         |                        |
                         |(4) (MSRP) SEND request.

   MSRP d93kswow (chunk) |
                         |----------------------->|
                         |(5) (MSRP) SEND (chunk) |
                         |----------------------->|
                         |(6) (MSRP) 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       |
                         |<-----------------------|
                         |(7) (MSRP) 200 OK response

   F6: Alice re-uses the existing SDP media line inserting the
   description of the file       |
                         |<-----------------------|
                         |                        |
                         |(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 re-INVITE 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.

   INVITE sip:bob@example.com SIP/2.0
   To: Bob <sip:bob@example.com>;tag=1928323431 <sip:bob@example.com>
   From: Alice <sip:alice@example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 2 1 INVITE
   Max-Forwards: 70
   Date: Sun, 21 May 2006 13:02:33 13:02:03 GMT
   Contact: <sip:alice@alicepc.example.com>
   Content-Type: multipart/related; type="application/sdp";
                 boundary="boundary71"
   Content-Length: [length of multipart] [length]

   --boundary71
   Content-Type: application/sdp
   Content-Length: [length of SDP]

   v=0
   o=alice 2890844526 2890844527 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/iau39;tcp
   a=file-selector:name:"sunset.jpg"
   a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
   a=file-selector:name:"My cool picture.jpg" type:image/jpeg
     size:4096
     size:4092 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
     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:"Sun, 21
   a=file-date:creation:"Mon, 15 May 2006 13:02:15 15:01:31 +0300"
   a=file-icon:cid:id3@alicepc.example.com
   a=file-icon:cid:id2@alicepc.example.com

   --boundary71
   Content-Type: image/jpeg
   Content-Transfer-Encoding: binary
   Content-ID: <id3@alicepc.example.com> <id2@alicepc.example.com>
   Content-Length: [length of image]
   Content-Disposition: icon

   [..small

   [...small preview icon...]

   --boundary71--

           Figure 15: Reuse icon of the file...]

   --boundary71--

    Figure 4: INVITE request containing an SDP in a second offer for file transfer
      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:

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

   F2: Bob receives the re-INVITE 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. following
   SDP answer:

   v=0
   o=bob 2890844656 2890855440 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/eh10dsk;tcp
   a=file-selector:name:"sunset.jpg"
   a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
   a=file-selector:name:"My cool picture.jpg" type:image/jpeg
     size:4096
     size:4092 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
     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 16: 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.

   F9: If a TCP connection towards Bob is already open,

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

   MSRP d95ksxox d93kswow SEND
   To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp msrp://bobpc.example.com:8888/9di4ea;tcp
   From-Path: msrp://alicepc.example.com:7654/iau39;tcp
   Message-ID: 13449sdqwer 12339sdqwer
   Byte-Range: 1-2027/2027 1-2048/4385
   Content-Type: message/cpim

   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.com>
   DateTime: 2006-05-21T13:02:15-03:00 2006-05-15T15:02:31-03:00
   Content-Disposition: render; filename="Sunset.jpg";
                      creation-date="Sun, 21 filename="My cool picture.jpg";
                      creation-date="Mon, 15 May 2006 13:02:15 -0300";
                      size=1931 15:01:31 +0300";
                      size=4092
   Content-Type: image/jpeg

   ...binary

   ... first set of bytes of the JPEG image...
   -------d95ksxox+ image ...
   -------d93kswow+

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

   F10: Bob acknowledges

   F5: Alice sends the reception 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. request containing the second chunk of actual
                                   file

   F6: Bob acknowledges the reception of the first chunk.

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

   F11: Then

   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.

   F12: Alice

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

9.3.  Example of

9.2.  Offerer requests a capability indication

   Alice sends an OPTIONS request file from the Answerer and second file transfer

   In this example Alice, the SDP offerer, first wishes to Bob (this request does not contain
   SDP).  Bob answers with fetch a 200 (OK) response that contain file
   from Bob, the SDP
   shown in Figure 20.  The SDP indicates support for CPIM messages answerer.  Alice knows that
   can contain other MIME types. Bob has a specific file
   she wants to download.  She has learned the hash of the file by some
   out-of-band mechanism.  The maximum MSRP message size hash selector is enough to produce a file
   selector that points to the
   endpoint can receive is 20000 octets.  The presence of specific file.  So, Alice creates an SDP
   offer that contains the 'file-
   selector' attribute indicates support for file descriptor.  Bob accepts the
   transmission and sends the file transfer offer/
   answer mechanism.

                   Alice's 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.

                   Alice's UAC                 Bob's UAS
                         |                        |
                         |(1) (SIP) OPTIONS 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      |
                         |<-----------------------|
                         |          with SDP                        |
                         |(11) (SIP) BYE          |
                         |<-----------------------|
                         |(12) (SIP) 200 OK       |
                         |----------------------->|
                         |                        |
                         |                        |

     Figure 19: 10: Flow diagram of an offerer requesting a capability 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.

   INVITE sip:bob@example.com SIP/2.0
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 1 INVITE
   Max-Forwards: 70
   Date: Sun, 21 May 2006 13:02:03 GMT
   Contact: <sip:alice@alicepc.example.com>
   Content-Type: application/sdp
   Content-Length: [length of SDP]

   v=0
   o=bob 2890844656 2890855439
   o=alice 2890844526 2890844526 IN IP4 bobpc.example.com
   s=- alicepc.example.com
   s=
   c=IN IP4 bobpc.example.com alicepc.example.com
   t=0 0
   m=message 0 7654 TCP/MSRP *
   a=recvonly
   a=accept-types:message/cpim
   a=accept-wrapped-types:*
   a=max-size:20000
   a=file-selector
   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 20: SDP of the 200 (OK) response to an OPTIONS 11: INVITE request

10.  Security Considerations

   The containing an SDP attributes defined in this specification identify a file to
   be transferred between two endpoints.  An endpoint can offer to send
   the for file to transfer

      NOTE: The 'file-selector' attribute in the other endpoint or request to receive 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 file from SIP details for the other endpoint.  In sake of brevity.

   F2: Bob receives the former case, an attacker modifying those
   SDP attributes could cheat INVITE request, inspects the receiver making it think that SDP offer, computes
   the file
   to be transferred was a different one.  In the latter case, the
   attacker could make the sender send descriptor and finds a different local file than whose hash equals the one
   requested by the receiver.  Consequently, it is RECOMMENDED that
   integrity protection be applied to the SDP session descriptions
   carrying the attributes specified
   indicated in this specification.

   The descriptions of the files being transferred between endpoints may
   reveal information SDP.  Bob accepts the endpoints may consider confidential.
   Therefore, it is RECOMMENDED that file transmission and creates
   an SDP session descriptions carrying answer as follows:

   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 attributes specified SDP offer for file transfer

      NOTE: The 'file-selector' attribute in this specification be encrypted.

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

   It above figure is possible that split
      in two lines for formatting purposes.  Real implementations will
      encode it in a malicious or misbehaving implementation tries single line.

   F4: Alice opens a TCP connection 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 Bob. Bob then creates an SDP answer SHOULD first verify MSRP
   SEND request that contains the identity of 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 SDP offerer, and perhaps, only accept actual file transfers from trusted
   sources.  Mechanisms to verify

   F5: Alice acknowledges the identity reception of the file sender depend
   on the high-level protocol that carries the SDP, for example, SIP
   [RFC3261] and SEND request.

   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 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 file prior to its reception, or limiting existing SDP media line inserting the
   number
   description 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 be sent and attaches it to store a file.
   This is SIP re-INVITE
   request addressed to prevent Bob. Alice reuses the existence of meaningful characters to TCP port number for the
   local operating system that could damage it.

   Once a file has been transferred
   MSRP stream, but changes the file receiver must take care
   with it.  Typically file transfer is a commonly used mechanism for
   transmitting computer virus, spyware, MSRP session and other types of malware.
   File recipients should apply all possible security technologies
   (e.g., antivirus, antispaware, etc.) to dismiss the risk of damage at
   their host.

11.  IANA Considerations

   This document instructs IANA to register a number of SDP attributes 'file-transfer-id'
   value according to the following:

11.1.  Registration this specification.

   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 new SDP attributes

   This memo provides instructions to IANA to register a number multipart]

   --boundary71
   Content-Type: application/sdp
   Content-Length: [length 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 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
      this specification.

11.1.1.  Registration image]
   Content-Disposition: icon

   [..small preview icon...]

   --boundary71--

           Figure 15: Reuse of the file-selector SDP in a second file transfer
      NOTE: The Content-Type header field and the 'file-selector'
      attribute

      Contact: Miguel Garcia <miguel.garcia@nsn.com>
      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 in the charset attribute
      Description: This attribute unambiguously identify a file by
      indicating above figure are split in several lines for
      formatting purposes.  Real implementations will encode it in a combination of
      single line.

   F7: Bob receives the 4-tuple composed of re-INVITE request, inspects the name, SDP offer and
   extracts the icon body, checks the creation date and file size, type, and hash of
   decides to accept the file.
      Specification: RFC XXXX

11.1.2.  Registration of file transfer.  So Bob creates an SDP answer
   where he reuses 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 same TCP port number, but changes his MSRP
   session, according to the charset attribute
      Description: This attribute contains a unique identifier 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 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

      NOTE: The 'file-selector' attribute is not subject to in the charset attribute
      Description: This attribute provides above figure is split
      in three lines for formatting purposes.  Real implementations will
      encode it in a suggestion 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 other
      endpoint about the intended disposition of
   file.

   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
      Specification: RFC XXXX

11.1.4.  Registration of

   F10: Bob acknowledges the file-date attribute

      Contact: Miguel Garcia <miguel.garcia@nsn.com>
      Phone: +358 71400 4000
      Attribute name: file-date
      Long-form attribute name:
      Type reception of attribute: media level only
      This attribute is not subject to the charset attribute
      Description: This attribute indicates 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 dates at which SIP session by sending a SIP BYE
   request.

   F12: Alice acknowledges the file
      was created, modified, or last read.
      Specification: RFC XXXX

11.1.5.  Registration reception 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 BYE request and sends a
   200 (OK) response.

9.3.  Example of attribute: media level only
      This attribute is not subject to the charset attribute
      Description: For image files, this attribute contains a pointer capability indication

   Alice sends an OPTIONS request to Bob (this request does not contain
   SDP).  Bob answers with a body 200 (OK) response that includes a small preview icon representing the
      contents of contain the file to be transferred
      Specification: RFC XXXX

11.1.6.  Registration of 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 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
   endpoint can receive is not subject to 20000 octets.  The presence of the charset 'file-
   selector' attribute
      Description: it contains indicates support for the range file transfer offer/
   answer mechanism.

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

              Figure 19: Flow diagram of transferred bytes 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
      file
      Specification: RFC XXXX

12.  Acknowledgements

   The authors would like 200 (OK) response to thank Mats Stille, Nancy Greene, Adamu
   Haruna, and Arto Leppisaari for discussing initial concepts described an OPTIONS request

10.  Security Considerations

   The SDP attributes defined in this memo.  Thanks specification identify a file to Pekka Kuure for reviewing initial versions
   this document and providing helpful comments.  Joerg Ott, Jiwey Wang,
   Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis-
   Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan
   Rosenberg, and Eric Rescorla discussed and provided comments and
   improvements
   be transferred between two endpoints.  An endpoint can offer to this document.

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs send
   the file 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.

   [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
              Presentation Information 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 Internet Messages: this specification.

   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. 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 H. Schulzrinne, "An Offer/Answer Model S/MIME are the natural choices to provide offer/answer
   exchanges with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3629]  Yergeau, F., "UTF-8, integrity protection and confidentiality.

   It is possible that a transformation format of ISO
              10646", STD 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 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>
      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

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, Eric 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.

   [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 D. Atkins, "Common Presence and Instant
              Messaging (CPIM): Message Format", RFC 3862, August 2004.

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

   [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 Instant
              Messaging (CPIM): Message Format", RFC 3862, August 2004.

   [RFC4234]  Crocker, D., Ed. usage conventions to SDP, while MSRP itself needs no
   extensions and P. Overell, "Augmented BNF can be used as it is.  This is effectively the
   approach taken in this specification.  Another goal has been to
   specify the SDP extensions in such a way that a regular MSRP endpoint
   which does not support them could still in some cases act as an
   endpoint in a file transfer session, albeit with a somewhat reduced
   functionality.

   In some ways the aim of this specification is similar to the aim of
   content indirection mechanism in the Session Initiation Protocol
   (SIP) [RFC4483].  Both mechanisms allow a user agent to decide
   whether or not to download a file based on information about the
   file.  However, there are some differences.  With content
   indirection, it is not possible for the other endpoint to explicitly
   accept or reject the file transfer.  Also, it is not possible for an
   endpoint to request a file from another endpoint.  Furthermore,
   content indirection is not tied to the context of a media session,
   which is sometimes a desirable property.  Finally, content
   indirection typically requires some server infrastructure, which may
   not always be available.  It is possible to use content indirection
   directly between the endpoints too, but in that case there is no
   definition for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC4566]  Handley, M., Jacobson, V., 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 C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4975]  Campbell, B., Mahy, R., 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 C. Jennings, "The Message
              Session Relay Protocol (MSRP)", RFC 4975, September 2007.

13.2.  Informational References

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., 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 E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC4028]  Donovan, S. 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 J. Rosenberg, "Session Timers 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
              Session Initiation Protocol (SIP)", RFC 4028, April 2005.

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

   [RFC4976]  Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
              for 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 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 parameters
   defined 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> Section 6.  Those implementations will be able to use
   regular SDP rules in order to ignore non-supported SDP parameters.
   If all the information was encoded in a single SDP attribute, those
   rules, which relate to backwards compatibility, would need to be
   redefined specifically for that parameter.

Authors' Addresses

   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

   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

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

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