[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-garcia-mmusic-file-transfer-mech) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5547

MMUSIC Working Group                                    M. Garcia-Martin
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                              M. Isomaki
Expires: November 19, 2007                                         Nokia
                                                            G. Camarillo
                                                               S. Loreto
                                                                Ericsson
                                                            May 18, 2007


 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable
                             File Transfer
              draft-ietf-mmusic-file-transfer-mech-02.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 November 19, 2007.

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



Garcia-Martin, et al.   Expires November 19, 2007               [Page 1]


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


   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.










































Garcia-Martin, et al.   Expires November 19, 2007               [Page 2]


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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Alternatives Considered  . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  7
   5.  File selector  . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Extensions to SDP  . . . . . . . . . . . . . . . . . . . . . .  9
   7.  File Disposition Types . . . . . . . . . . . . . . . . . . . . 14
   8.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 15
       8.1.1.  The Offerer is a File Sender . . . . . . . . . . . . . 15
       8.1.2.  The Offerer is a File Receiver . . . . . . . . . . . . 16
       8.1.3.  SDP Offer for Several Files  . . . . . . . . . . . . . 17
     8.2.  Answerer's Behavior  . . . . . . . . . . . . . . . . . . . 17
       8.2.1.  The Answerer is a File Receiver  . . . . . . . . . . . 17
       8.2.2.  The Answerer is a File Sender  . . . . . . . . . . . . 18
     8.3.  Indicating File Transfer Offer/Answer Capability . . . . . 19
     8.4.  Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 19
     8.5.  MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  Offerer sends a file to the Answerer . . . . . . . . . . . 21
     9.2.  Offerer requests a file from the Answerer and second
           file transfer  . . . . . . . . . . . . . . . . . . . . . . 25
     9.3.  Example of a capability indication . . . . . . . . . . . . 31
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 32
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
     11.1. Registration of new SDP attributes . . . . . . . . . . . . 33
       11.1.1. Registration of the file-selector attribute  . . . . . 33
       11.1.2. Registration of the file-disposition attribute . . . . 33
       11.1.3. Registration of the file-date attribute  . . . . . . . 33
       11.1.4. Registration of the file-icon attribute  . . . . . . . 34
       11.1.5. Registration of the file-range attribute . . . . . . . 34
     11.2. Registration of new Content Disposition value  . . . . . . 34
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 35
     13.2. Informational References . . . . . . . . . . . . . . . . . 36
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 38










Garcia-Martin, et al.   Expires November 19, 2007               [Page 3]


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


1.  Introduction

   The Session Description Protocol (SDP) Offer/Answer [7] 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) [11] is a protocol for
   transmitting instant messages (IM) in the context of a session.  The
   protocol specification includes a description how to use it with SDP.
   In addition to plain text messages, MSRP is able to carry arbitrary
   (binary) Multipurpose Internet Mail Extensions (MIME) [2] 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 [15] provide a mechanism for Network Address Translator (NAT)
   traversal.  Finally, Secure MIME (S/MIME) [8] can be used for
   ensuring the integrity and confidentiality of the transfered content.

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

   o  The recipient MUST be able to distinguish "file transfer" from
      "file attached to IM", allowing the recipient to treat the cases
      differently.
   o  It MUST be possible for the sender to send the request for a file
      transfer.  It MUST be possible for the recipient to accept or
      decline it, using the meta information in the request.  The actual
      transfer MUST take place only after acceptance by the recipient.
   o  It MUST be possible for the sender to pass some meta information
      on the file before the actual transfer.  This MUST be able to
      include at least content type, size, hash and name of the file, as
      well as a short (human readable) description.
   o  It MUST be possible for the recipient to request a file from the
      sender, providing meta information about the file.  The sender
      MUST be able to decide whether to send a file matching the
      request.




Garcia-Martin, et al.   Expires November 19, 2007               [Page 4]


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


   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.
   Section 8.3 describes the mechanism whereby a user can learn the
   support for the functionality described in this specification at a
   remote endpoint.  Finally, some examples are given in Section 9.

1.1.  Alternatives Considered

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

   In some ways the aim of this specification is similar to the aim of
   content indirection mechanism in the Session Initiation Protocol
   (SIP) [13].  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 accpet or reject the
   file transfer.  Also, it is not possible for an endpoint to request a
   file from another endpoint.  Furthermore, content indirection is not
   tied to the context of a media session, which is sometimes a
   desirable property.  Finally, content indirection typically requires
   some server infrastructure, which may not always be available.  (It
   is possible to use content indirection directly between the endpoints
   too, but in that case there is no definition for how it works for
   endpoints behind NATs.)

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








Garcia-Martin, et al.   Expires November 19, 2007               [Page 5]


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


      In principle it is possible to use the SDP extensions defined here
      and replace MSRP with any other similar protocol that can carry
      MIME objects.  This kind of specification can be written as a
      separate document if the need arises.

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

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

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


2.  Terminology

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


3.  Definitions

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

   o  Answer
   o  Answerer
   o  Offer





Garcia-Martin, et al.   Expires November 19, 2007               [Page 6]


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


   o  Offerer

   Additionally, we define the following terms:

   File sender:   The endpoint that is willing to send a file to the
      file receiver.
   File receiver:   The endpoint that is 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 select a file at the SDP answerer.
      This is described in more detail in Section 5.


4.  Overview of Operation

   An SDP offerer creates an SDP body that contains the description of
   one or more files that the offerer wants to send or receive.  The
   offerer sends the SDP offer to the remote endpoint.  The SDP answerer
   can accept or reject the transfer of each of those files.

   The actual file transfer is carried out using the Message Session
   Relay Protocol (MSRP) [11].  Each SDP "m=" line describes an MSRP
   media stream used to transfer a single file.  That is, the transfer
   of multiple simultaneous files requires multiple "m=" lines and
   corresponding MSRP media streams.  It should be noted that multiple
   MSRP media streams can share a single transport layer connection, so
   this mechanism will not lead to excessive use of transport resources.

   Each "m=" line for an MSRP media stream is accompanied with a few
   attributes describing the file to be transferred.  If the file sender
   generates the SDP offer, the attributes describe a local file to be
   sent (push), and the file receiver can use this information to either
   accept or reject the transfer.  However, if the SDP offer is
   generated by the file receiver, the attributes are intended to
   characterize a particular file that the file receiver is willing to
   get (pull) from the file sender.  It is possible that the file sender
   does not have a matching file or does not want to send the file, in
   which case the offer is rejected.

   The attributes describing each file are provided in SDP by a set of
   new SDP attributes, most of which have been directly borrowed from
   MIME.  This way, user agents can decide whether or not to accept a
   given file transfer based on the file's name, size, description,
   hash, icon (e.g., if the file is a picture), etc.

   SDP direction attributes (e.g., 'sendonly', 'recvonly') are used to
   indicate the direction of the transfer, i.e., whether the SDP offerer
   is willing to send of receive the file.  Assuming that the answerer



Garcia-Martin, et al.   Expires November 19, 2007               [Page 7]


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


   accepts the file transfer, the actual transfer of the files takes
   place with ordinary MSRP.

      In principle the file transfer can work even with an endpoint
      supporting only regular MSRP without understanding the extensions
      defined herein, in a special case where that endpoint is the
      recipient of the file.  The regular MSRP endpoint answers the
      offer as it would answer any ordinary MSRP offer without paying
      attention to the extension attributes.  In such a scenario the
      user experience would however be reduced, as the recipient would
      not know (by any protocol means) the reason for the session and
      would not be able to accept/reject it based on the file
      attributes.


5.  File selector

   Specially in case the SDP offer is generated by the file receiver,
   the offer needs a mechanism to unambiguously identify the requested
   file.  For this purpose, the file transfer mechanism introduces the
   concept of a file selector, which is defined as the combination of
   the 4-tuple composed of the name, size, type, and hash of the file.
   We call each of these individual items a selector.

   The purpose of the file selector is to provide enough information
   that characterizes a file to the remote entity, so that both the
   local and the remote entity can refer to the same file.  The file
   selector is encoded in a 'file-selector' media attribute in SDP.  The
   formal syntax of the 'file-selector' media attribute is described in
   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, or more files, depending on the
   presence of the mentioned selectors in the SDP and depending on the
   available files in a host.  The file transfer mechanism specified in
   this document requires that a file selector eventually results at
   most in a single file to be chosen.  Typically, if the hash selector
   is known, it is enough to produce a file selector that points to
   exactly zero or one file.  However, a file selector that selects a
   unique file is not always known by the offerer.  Sometimes only the
   name, size or type of file are known, so the file selector may result
   in selecting more than one file, which is an undesired case.  The
   opposite is also true: if the file selector contains a hash and a
   name selectors, there is a risk that the remote host has renamed the
   file, although there is a file with the indicated hash, the file name
   does not match, thus, the file selector will result in the selection



Garcia-Martin, et al.   Expires November 19, 2007               [Page 8]


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


   of zero files.

   Since there are several hashing algorithms, such as SHA-1 [6], SHA-
   256, SHA-384, SHA-512 [14], etc., a file selector MAY contain several
   hashes, each one describing the hash of the file with a different
   hashing algorithm.  Implementations that make use of the hash SHOULD
   select one among the supported ones before selecting a file.  So,
   when several hashes are present in the SDP, the file selector
   consists of the union of the name, size, type, and any of the
   supported hash algorithms.

   Implementations according to this specification MUST implement the
   'file-selector' attribute and MAY implement any of the other
   attributes specified in this specification.  SDP offers and answers
   for file transfer MUST contain a 'file-selector' media attribute that
   selects the file to be transferred and MAY contain any of the other
   attributes specified in this specification.

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


6.  Extensions to SDP

   We define a number of new SDP [10] attributes that provide the
   required information to describe the transfer of a file with MSRP.
   These are all media level only attributes in SDP.  The following is
   the formal ABNF syntax [9] of these new attributes.  It is built
   above the SDP [10] grammar, RFC 2045 [2], RFC 2183 [3], and RFC 2392
   [4].




















Garcia-Martin, et al.   Expires November 19, 2007               [Page 9]


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


    attribute            = file-selector-attr / file-disp-attr /
                           file-date-attr / file-icon-attr /
                           file-range-attr
                           ;attribute is defined in RFC 4566

    file-selector-attr   = "file-selector" [":" selector *(SP selector)]
    selector             = filename-selector / filesize-selector /
                           filetype-selector / hash-selector

    filename-selector    = "name:"  DQUOTE filename-string DQUOTE
                                        ; DQUOTE defined in RFC 4234
    filename-string      = byte-string ;byte-string defined in RFC 4566

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

    filetype-selector    = "type:" type "/" subtype *(";"parameter)
                                       ; parameter defined in RFC 2045
    type                 = token
    subtype              = token

    hash-selector        = "hash:" hash-algorithm ":" hash-value
    hash-algorithm       = token     ;see IANA Hash Function
                                     ;Textual Names registry
    hash-value           = hex-val   ;hex-val defined in RFC 4234

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

    file-date            = "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

    file-icon-attr       = "file-icon:" file-icon-value
    file-icon-value      = cid-url        ;cid-url defined in RFC 2392

    file-range-attr      = "file-range:" integer "-" integer
                                        ;integer defined in RFC 4566

                   Figure 1: Syntax of the SDP extension




Garcia-Martin, et al.   Expires November 19, 2007              [Page 10]


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


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

   When used in an SDP offer or answer, the 'file-selector' attribute
   MUST contain at least one selector.  Selectors parametrize 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 the
   filename of the content enclosed in double quotes.  The filename is
   encoded in UTF-8.  Its value SHOULD be the same as the 'filename'
   parameter of Content-Disposition header field [3] that could be
   signalled by the actual file transfer.  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 escaped.

      Note that the 'name' selector might still contain characters that,
      although not meaningful for the local operating system, might
      still be meaningful to the remote operating system (e.g., '\',
      '/', ':').  Therefore, implementations are responsible for
      sanitizing the input received from the remote endpoint before
      doing a local operation, such as the creation of a local file.
      Among other things, implementations can escape characters that are
      meaningful to the local operating system before doing file system
      local calls.

   The 'size' selector in the 'file-selector' attribute indicates the
   size of the file in octets.  The value of this attribute SHOULD be
   the same of the 'size' parameter of Content-Disposition header field
   [3] that could be signalled by the actual file transfer.  Note that
   the 'size' selector merely includes the file size, and does not
   include any potential overhead added by a wrapper, such as message/
   cpim.

   The 'type' selector in the 'file-selector' attribute contains the
   MIME media type of the content.  In general, anything that can be
   expressed in a Content-Type header field (see RFC 2045 [2]) can also
   be expressed with the 'type' selectors.  Possible MIME Media Type
   values are the ones listed in the IANA registry for MIME Media
   Types [17].  Zero or more parameters can follow.  The syntax of
   'parameter' is specified in RFC 2045 [2] .

   The 'hash' selector in the 'file-selector' attribute provides a hash
   of the file to be transferred.  This is commonly used by file
   transfer protocols.  For example, FLUTE [16] uses hashes (called
   message digests) to verify the contents of the transfer.  The purpose



Garcia-Martin, et al.   Expires November 19, 2007              [Page 11]


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


   of the 'hash' selector is two-fold: On one side, it allows the file
   receiver to identify a file by its hash rather than by its file name,
   providing that the file receiver has learned the hash of the file by
   some out-of-band mechanism.  On the other side, it allows the file
   sender to provide the hash of the file to be transmitted, which can
   be used by the file receiver for verification of its contents or to
   avoid the unnecessary transmission of a file that already exists.
   The 'hash' selector includes the hash algorithm and its value.  In
   fact, since there are several hashing algorithms, the SDP MAY contain
   several 'hash' selectors with different algorithms.  Possible hash
   algorithms are those defined in the IANA registry of Hash Function
   Textual Names [18].  Implementations according to this specification
   MUST support the US Secure Hash Algorithm 1 (SHA1) [6] and MAY
   support other hashing algorithms.  The value is the byte string
   resulting of applying the hash algorithm to the content of the whole
   file.

   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.  The value of
   this attribute SHOULD be the same of the disposition type parameter
   of the Content-Disposition header field [3] that could be signalled
   by the actual file transfer protocol.

   The 'file-date' attribute indicates the dates at which the file was
   created, modified, or last read.  This attribute MAY contain a
   combination of the 'creation', 'modification', and 'read' parameters.
   Only one parameter of each type (creation, modification, or read)
   MUST be present in a 'file-date' attribute.

   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 [5]
   'date-time' format.  Numeric timezones (+HHMM or -HHMM) MUST be used.
   The value of this parameter SHOULD be the same of the 'creation-date'
   parameter of Content-Disposition header field [3] that could be
   signalled 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
   [5] 'date-time' format.  Numeric timezones (+HHMM or -HHMM) MUST be
   used.  The value of this parameter SHOULD be the same of the
   'modification-date' parameter of Content-Disposition header field [3]
   that could be signalled by the actual file transfer protocol.

   The 'read' parameter indicates the date at which the file was last
   read.  The value MUST be a quoted string which contains a



Garcia-Martin, et al.   Expires November 19, 2007              [Page 12]


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


   representation of the last date the file was read in RFC 2822 [5]
   'date-time' format.  Numeric timezones (+HHMM or -HHMM) MUST be used.
   The value of this parameter SHOULD be the same of the 'read-date'
   parameter of Content-Disposition header field [3] that could be
   signalled by the actual file transfer protocol.

   The 'file-icon' attribute can be useful with certain file types such
   as images.  It allows the sender to include a pointer to a body that
   includes a small preview icon representing the contents of the file
   to be transferred.  This allows the sender to include the icon as
   another body accompanying the SDP, and to the recipient to get the
   icon of the file to be transferred.  It is recommended to keep icons
   restricted to the minimum number of bytes that provide significance.
   The 'file-icon' attribute contains a Content-ID URL, which is
   specified in RFC 2392 [4].

   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 is composed to two
   integer values separated by a dash "-".  The first integer value
   refers to the first byte of the file to be transferred.  The second
   integer value refers to the last byte of the file to be transferred.
   The first byte of a file is indicated with "1".  The absence of this
   attribute indicates a complete file, i.e., like if the 'file-range'
   attribute would have been present with values 1-<size_of_file>.  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:













Garcia-Martin, et al.   Expires November 19, 2007              [Page 13]


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


    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:72245FE8653DDAF371362F86D471913EE4A2CE2E
    a=file-disposition:not-render
    a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00"
    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
   two 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 [19] 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 defines a new value
   'not-render' of the Content Disposition type.  The default value is



Garcia-Martin, et al.   Expires November 19, 2007              [Page 14]


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


   'render', i.e., the absence of a 'file-disposition' attribute in the
   SDP has the same semantics as 'render'.


8.  Protocol Operation

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

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

   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 'recvonly'
       attribute, and accordingly the SDP answer contains a 'sendonly'
       attribute.

8.1.  Offerer's Behavior

   An offerer that wishes to send or receive one or more files to or
   from an answerer MUST build an SDP [10] description of a session
   containing one or more "m=" lines, each one describing an MSRP
   session (and thus, one file transfer operation), according to the
   MSRP [11] procedures.  All the media line attributes specified and
   required by MSRP [11] (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.  Then it sends the SDP offer to the file
   receiver.  The file sender MUST add a 'file-selector' attribute media
   line containing at least one of the 'type', 'size', 'hash',
   parameters in indicating the type, size, or hash of the file,
   respectively.  If the file sender is able to compute the hash of the
   file with different hashing algorithms, it MAY add several 'hash'



Garcia-Martin, et al.   Expires November 19, 2007              [Page 15]


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


   parameters, each one referring to a different hashing algorithm.
   Additionally, the file sender MUST add a session or media 'sendonly'
   attribute to the SDP offer.

      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' parameter 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.  If the
      sender supports several hashing algorithms, then several 'hash'
      parameters can be included.

   The file sender MAY also add a 'name' parameter 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 offset of
   the file transfer.

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 parameters
   defined for such attribute (i.e., 'name', 'type', 'size', or 'hash').
   Several 'hash' parameters MAY be included if each 'hash' parameter is
   computed with a different hashing algorithm.  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' attribute.  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.  There is no need to for the file offerer to include further
   file attributes in the SDP offer, thus it is RECOMMENDED that SDP
   offerers do not include any other file attribute defined by this
   specification (other than the mandatory ones).  Additionally, the
   file receiver MUST create an SDP offer that contains a session or
   media 'recvonly' attribute.

   The file receiver MAY also add a 'file-range' attribute indicating
   the start and stop offset of the file transfer.






Garcia-Martin, et al.   Expires November 19, 2007              [Page 16]


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


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.  This way, the answerer can reject
   individual files by setting the port number of their associated "m="
   lines to zero, as per regular SDP [10] procedures.

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

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 [10] procedures.  If the answerer decides to
   accept the file, it proceeds as per regular MSRP [11] and SDP [10]
   procedures.

8.2.1.  The Answerer is a File Receiver

   In a push operation the answerer is the file receiver.  When the file
   receiver gets the SDP answer, it extracts the attributes and
   parameters that describe the file and typically requests permission
   to the user to accept or reject the reception of the file.  If the
   file transfer operation is accepted, the file receiver MUST create an
   SDP answer according to the procedures specified in RFC 3264 [7].  If
   the offer contains 'name', 'type', 'size', parameters in the 'file-
   selector' attribute, the answerer MUST copy them into the answer.  If
   the offer contains one ore more 'hash' parameters in the 'file-
   selector' attribute, the answerer discards those with non-supported
   hashing algorithms and MUST copy the remaining (if any) to the 'file-
   selector' attribute of the answer.  This informs the offerer that the
   answerer supports this specification.  Then the file receiver MUST
   add a 'recvonly' attribute according to the procedures specified in
   RFC 3264 [7].  The file receiver MUST NOT include 'file-icon', 'file-
   disposition', or 'file-date' attributes in the SDP answer.

   If the SDP offer contains one or more 'hash' parameters in the 'file-
   selector' attribute, the answerer discards those with unsupported
   hashing algorithms.  The file receiver can use the remaining hashes
   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



Garcia-Martin, et al.   Expires November 19, 2007              [Page 17]


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


   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 a file sender.  In this case, the
   file sender MUST first inspect the received SDP offer and apply the
   file selector.  The file selector is encoded in the 'file-selector'
   media attribute line in SDP.  First, if the file selector contains
   several hashes, the file sender MUST select one of them which
   contains a supported hashing algorithm and discard the rest.  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' parameters 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 [7], 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 [7].  If the SDP offer included several
   'hash' parameters, the file sender SHOULD include at least one in the
   SDP answer, selected among those present in the offer and, at the
   same time, supported by the file sender.  If the SDP offer did not
   include a 'hash' parameter, the file sender SHOULD add one or more
   'hash' parameters, according to the supported hashing algorithms.
   The file sender MAY also include a 'type' parameter 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' parameters 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 [11]) can
   accommodate a Content-Disposition header field [3] 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 signalled
      later in the file transfer protocol would just duplicate the
      information, but will not provide any information to the offerer



Garcia-Martin, et al.   Expires November 19, 2007              [Page 18]


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


      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 choise
   cannot be done, the answere 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.  Indicating File Transfer Offer/Answer Capability

   The SDP Offer/Answer Model [7] provides provisions for indicating a
   capability to another endpoint (see Section 9 of RFC 3264 [7]).  The
   mechanism assumes a high-level protocol, such as SIP [12], that
   provides a capability query (such as a SIP OPTIONS request).  RFC
   3264 [7] indicates how to build the SDP that is included in the
   response to such request.  As such, RFC 3264 indicates that and
   endpoint builds an SDP body that contains an "m=" line that contains
   the media type (message, for MSRP).  An endpoint that implements the
   procedures specified in this document SHOULD also add a 'file-
   selector' media attribute for the "m=message" line.  The 'file-
   selector' media attribute MUST be empty, i.e., it MUST NOT contain
   any selector.

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

   The SDP Offer/Answer Model [7] provides rules that allow SDP offerers
   and answerers to modify an existing media line, i.e., re-use an
   existing media line with different attributes.  The same is also
   possible when SDP signals a file transfer operation according to the
   rules of this memo.  Therefore, the procedures defined in RFC 3264
   [7], in particular those defined in Section 8.3, MUST apply for file
   transfer operations.







Garcia-Martin, et al.   Expires November 19, 2007              [Page 19]


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


8.5.  MSRP Usage

   The file transfer service specified in this document uses "m=" lines
   to describe the unidirectional transfer of a file.  Consequently,
   each MSRP session established following the procedures in Section 8.1
   and Section 8.2 is only used to transfer a single file.  So, senders
   MUST only use the dedicated MSRP session to send the file described
   in the SDP offer or answer.  That is, senders MUST NOT send
   additional files over the same MSRP session.

   Additionally, implementations according to this specification MUST
   include a single file in a single MSRP message.  Notice that the MSRP
   specification defines "MSRP message" as a complete unit of MIME or
   text content, which can be split and delivered in more than one MSRP
   request; each of these portions of the complete message is called a
   "chunk".  So, it is still valid to send a file in several chunks, but
   from the MSRP point of view, all the chunks together form an MSRP
   message: the file.  When chunking, notice that MSRP does not require
   to wait for a 200-class response for a chunk before sending the
   following one.  Therefore, it is valid to send pipelined MSRP SEND
   requests containing chunks of the same MSRP message (the file).
   Section 9.1 contains an example of a file transfer using pipelined
   MSRP requests.

   In the absence of a 'file-range' attribute in the SDP, the MSRP file
   transfer MUST start with the first byte of the file and end with the
   last byte (i.e., the whole file is transferred).  If a 'file-range'
   attribute is present in SDP, the file sender application MUST extract
   the indicated range of bytes from the file (start and stop bytes).
   Then the file sender application SHOULD wrap those bytes in an
   appropriate wrapper, such as message/cpim.  Last, the file sender
   application delivers the message/cpim to MSRP for transportation.
   MSRP will consider the message/cpim as a whole message, and will
   start numbering bytes at number 1.

   Note that the default content disposition of MSRP bodies is 'render'.
   When MSRP is used to transfer files, the MSRP Content-Disposition
   header can also take the value 'not-render' defined by this memo.

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


9.  Examples






Garcia-Martin, et al.   Expires November 19, 2007              [Page 20]


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


9.1.  Offerer sends a file to the Answerer

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

   Alice, the SDP offerer, wishes to send an image file to Bob (the
   answerer).  Alice's User Agent Client (UAC) creates a unidirectional
   SDP offer that contains the description of the file that she wants to
   send to Bob's User Agent Server (UAS).  The description also includes
   an icon representing the contents of the file to be transferred.  The
   sequence flow is shown in Figure 3.

         Alice's UAC                 Bob's UAS
               |                        |
               |(1) (SIP) INVITE        |
               |----------------------->|
               |(2) (SIP) 200 OK        |
               |<-----------------------|
               |(3) (SIP) ACK           |
               |----------------------->|
               |                        |
               |(4) (MSRP) SEND (chunk) |
               |----------------------->|
               |(5) (MSRP) SEND (chunk) |
               |----------------------->|
               |(6) (MSRP) 200 OK       |
               |<-----------------------|
               |(7) (MSRP) 200 OK       |
               |<-----------------------|
               |                        |
               |(8) (SIP) BYE           |
               |----------------------->|
               |(9) (SIP) 200 OK        |
               |<-----------------------|
               |                        |
               |                        |


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

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







Garcia-Martin, et al.   Expires November 19, 2007              [Page 21]


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


     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/mixed; 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:72245FE8653DDAF371362F86D471913EE4A2CE2E
     a=file-disposition:render
     a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00"
     a=file-icon:cid:id2@alicepc.example.com

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

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

     --boundary71--


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

   NOTE: The 'file-selector' attribute in the above figure is split in
   two lines for formatting purposes.  Real implementations will encode



Garcia-Martin, et al.   Expires November 19, 2007              [Page 22]


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


   it in a single line.

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

   F2: Bob receives the INVITE request, inspects the SDP offer and
   extracts the icon body, checks the creation date and file size, and
   decides to accept the file transfer.  So Bob creates the following
   SDP answer:

     v=0
     o=bob 2890844656 2890844656 IN IP4 bobpc.example.com
     s=
     c=IN IP4 bobpc.example.com
     t=0 0
     m=message 8888 TCP/MSRP *
     a=recvonly
     a=accept-types:message/cpim
     a=accept-wrapped-types:*
     a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
     a=file-selector:name:"My cool picture.jpg" type:image/jpeg
           size:4092 hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E


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

   NOTE: The 'file-selector' attribute in the above figure is split in
   two lines for formatting purposes.  Real implementations will encode
   it in a single line.

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




















Garcia-Martin, et al.   Expires November 19, 2007              [Page 23]


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


    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 +03:00";
                       size=4092
    Content-Type: image/jpeg

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


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

   F5: Alice sends the second and last chunk.  Note that MSRP allows to
   send pipelined chunks, so there is no need to wait for the 200 (OK)
   response from the previous chunk.

      MSRP op2nc9a SEND
      To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
      From-Path: msrp://alicepc.example.com:7654/iau39;tcp
      Message-ID: 12339sdqwer
      Byte-Range: 2049-4385/4385
      Content-Type: message/cpim

      ... second set of bytes of the JPEG image ...
      -------op2nc9a$


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

   F6: Bob acknowledges the reception of the first chunk.

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





Garcia-Martin, et al.   Expires November 19, 2007              [Page 24]


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


                      Figure 8: MSRP 200 OK response

   F7: Bob acknowledges the reception of the second chunk.

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


                      Figure 9: MSRP 200 OK response

   F8: Alice terminates the SIP session by sending a SIP BYE request.

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

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

   In this example Alice, the SDP offerer, first wishes to fetch a file
   from Bob, the SDP answerer.  Alice knows that Bob has a specific file
   she wants to download.  She has learned the hash of the file by some
   out-of-band mechanism.  The hash attribute is enough to produce a
   file selector that points to the specific file.  So, Alice creates an
   SDP offer that contains the file descriptor.  Bob accepts the
   transmission and sends the file to Alice.  When Alice has completely
   received Bob's file, she intends to send a new image file to Bob.
   Therefore Alice re-uses the existing SDP media line with different
   attributes and updates the description of the new file she wants to
   send to Bob's User Agent Server (UAS).  Figure 10 shows the sequence
   flow.



















Garcia-Martin, et al.   Expires November 19, 2007              [Page 25]


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


          Alice's UAC                 Bob's UAS
                |                        |
                |(1) (SIP) INVITE        |
                |----------------------->|
                |(2) (SIP) 200 OK        |
                |<-----------------------|
                |(3) (SIP) ACK           |
                |----------------------->|
                |                        |
                |(4) (MSRP) SEND (file)  |
                |<-----------------------|
                |(5) (MSRP) 200 OK       |
                |----------------------->|
                |                        |
                |(6) (SIP) INVITE        |
                |----------------------->|
                |(7) (SIP) 200 OK        |
                |<-----------------------|
                |(8) (SIP) ACK           |
                |----------------------->|
                |                        |
                |(9) (MSRP) SEND (file)  |
                |----------------------->|
                |(10) (MSRP) 200 OK      |
                |<-----------------------|
                |                        |
                |(11) (SIP) BYE          |
                |<-----------------------|
                |(12) (SIP) 200 OK       |
                |----------------------->|
                |                        |
                |                        |


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

   F1: Alice constructs an SDP description of the file she wants to
   receive and attaches the SDP offer to a SIP INVITE request addressed
   to Bob.











Garcia-Martin, et al.   Expires November 19, 2007              [Page 26]


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


     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:image/jpeg
     a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
     a=file-selector:hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E

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

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

   F2: Bob receives the INVITE request, inspects the SDP offer, computes
   the file descriptor and finds a local file whose hash equals the one
   indicated in the SDP.  Bob accepts the file transmission and creates
   an SDP answer as follows:

     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:hash:sha-1:72245FE8653DDAF371362F86D471913EE4A2CE2E
                     type:image/jpeg

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

   F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP



Garcia-Martin, et al.   Expires November 19, 2007              [Page 27]


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


   SEND request that contains the file.


    MSRP d93kswow SEND
    To-Path: msrp://alicepc.example.com:7654/iau39;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 +03:00";
                   modification-date="Mon, 15 May 2006 16:04:53 +03:00";
                   read-date="Mon, 16 May 2006 09:12:27 +03:00";
                   size=1931
    Content-Type: image/jpeg

    ...binary JPEG image...
    -------d93kswow$

          Figure 13: MSRP SEND request containing the actual file

   F5: Alice acknowledges the reception of the SEND request.


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

                      Figure 14: MSRP 200 OK response

   F6: Alice re-uses the existing SDP media line inserting the
   description of the file to be sent and attaches it to a SIP re-INVITE
   request addressed to Bob.












Garcia-Martin, et al.   Expires November 19, 2007              [Page 28]


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


      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/mixed; boundary="boundary71"
      Content-Length: [length of multipart]

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

      v=0
      o=alice 2890844526 2890844527 IN IP4 alicepc.example.com
      s=
      c=IN IP4 alicepc.example.com
      t=0 0
      m=message 5670 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:5670/iau39;tcp
      a=file-selector:name:"sunset.jpg" type:image/jpeg
        size:4096 hash:sha-1:58231FE8653BBCF371362F86D471913EE4B1DF2F
      a=file-disposition:render
      a=file-date:creation:"Sun, 21 May 2006 13:02:15 +03:00"
      a=file-icon:cid:id3@alicepc.example.com

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

      [..small preview icon...]

      --boundary71--


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

   NOTE: The 'file-selector' attribute in the above figure is split in
   two lines for formatting purposes.  Real implementations will encode



Garcia-Martin, et al.   Expires November 19, 2007              [Page 29]


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


   it in a single line.

   F7: Bob receives the re-INVITE request, inspects the SDP offer and
   extracts the icon body, checks the creation date and file size, and
   decides to accept the file transfer.  So Bob creates the following
   SDP answer:

      v=0
      o=bob 2890844656 2890855440 IN IP4 bobpc.example.com
      s=
      c=IN IP4 bobpc.example.com
      t=0 0
      m=message 9999 TCP/MSRP *
      a=recvonly
      a=accept-types:message/cpim
      a=accept-wrapped-types:*
      a=path:msrp://bobpc.example.com:9999/9an4ea;tcp
      a=file-selector:name:"sunset.jpg" type:image/jpeg
        size:4096 hash:sha-1:58231FE8653BBCF371362F86D471913EE4B1DF2F
      a=file-disposition:render


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

   NOTE: The 'file-selector' attribute in the above figure is split in
   two lines for formatting purposes.  Real implementations will encode
   it in a single line.

   F9: Alice opens a new TCP connection to Bob and creates an MSRP SEND
   request that contains the file.





















Garcia-Martin, et al.   Expires November 19, 2007              [Page 30]


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


      MSRP d95ksxox SEND
      To-Path: msrp://bobpc.example.com:9999/9an4ea;tcp
      From-Path: msrp://alicepc.example.com:5670/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";
                         size=1931
      Content-Type: image/jpeg

      ...binary JPEG image...
      -------d95ksxox+

          Figure 17: MSRP SEND request containing the actual file

   F10: Bob acknowledges the reception of the SEND request.

      MSRP d95ksxox 200 OK
      To-Path: msrp://alicepc.example.com:5670/iau39;tcp
      From-Path: msrp://bobpc.example.com:9999/9an4ea;tcp
      Byte-Range: 1-2027/2027
      -------d95ksxox$

                      Figure 18: MSRP 200 OK response

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

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

9.3.  Example of a capability indication

   Alice sends an OPTIONS request to Bob (this request does not contain
   SDP).  Bob answers with a 200 (OK) response that contain the SDP
   shown in Figure 20.  The SDP indicates support for CPIM messages that
   can contain other few MIME types.  The presence of the 'file-
   selector' attribute indicates support for the file transfer offer/
   answer mechanism.







Garcia-Martin, et al.   Expires November 19, 2007              [Page 31]


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


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

              Figure 19: Flow diagram of a capability request


      v=0
      o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
      s=-
      c=IN IP4 bobpc.example.com
      t=0 0
      m=message 0 TCP/MSRP *
      a=accept-types:message/cpim
      a=accept-wrapped-types:text/plain text/html image/jpeg image/gif
      a=file-selector

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


10.  Security Considerations

   The SDP attributed defined in this specification identify a file to
   be transfered between two endpoints.  An endpoint can offer to send
   the file to the other endpoint or request to receive the file from
   the other endpoint.  In the former case, an attacker modifying those
   SDP attributes could cheat the receiver making it think that the file
   to be transfered was a different one.  In the latter case, the
   attacker could make the sender send a different file than the one
   requested by the receiver.  Consequently, it is RECOMMENDED that
   integrity protection be applied to the SDP session descriptions
   carrying the attributes specified in this specification.

   The descriptions of the files being transfered between endpoints may
   reveal information the endpoints may consider confidential.
   Therefore, it is RECOMMENDED that SDP session descriptions carrying
   the attributes specified in this specification be encrypted.

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





Garcia-Martin, et al.   Expires November 19, 2007              [Page 32]


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


11.  IANA Considerations

   This document instructs IANA to register a number of SDP attributes
   an a new Content Disposition value, 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 [20].  The registration data, according to RFC 4566 [10]
   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 71800 8000
      Attribute name: file-selector
      Long-form attribute name:
      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-disposition attribute

      Contact: Miguel Garcia <miguel.garcia@nsn.com>
      Phone: +358 71800 8000
      Attribute name: file-disposition
      Long-form attribute name:
      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.3.  Registration of the file-date attribute

      Contact: Miguel Garcia <miguel.garcia@nsn.com>
      Phone: +358 71800 8000
      Attribute name: file-date
      Long-form attribute name:





Garcia-Martin, et al.   Expires November 19, 2007              [Page 33]


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


      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.4.  Registration of the file-icon attribute

      Contact: Miguel Garcia <miguel.garcia@nsn.com>
      Phone: +358 71800 8000
      Attribute name: file-icon
      Long-form attribute name:
      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.5.  Registration of the file-range attribute

      Contact: Miguel Garcia <miguel.garcia@nsn.com>
      Phone: +358 71800 8000
      Attribute name: file-range
      Long-form attribute name:
      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

11.2.  Registration of new Content Disposition value

   This document requests IANA to act on Mail Content Disposition Values
   and Parameters registry [19] and register a new Mail Content
   Disposition Value according to the following data:

   Name           Description                                  Reference
   -----          ------------                                 ---------
   not-render     the body should not be rendered to the user  [RFCXXXX]


   Note to the RFC Editor: Please replace RFCXXXX with the RFC number of
   this specification.







Garcia-Martin, et al.   Expires November 19, 2007              [Page 34]


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


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, and Colin Perkins discussed and provided comments and
   improvements to this document.


13.  References

13.1.  Normative References

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

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

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

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

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

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

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

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

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

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

   [11]  Campbell, B., "The Message Session Relay Protocol",



Garcia-Martin, et al.   Expires November 19, 2007              [Page 35]


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


         draft-ietf-simple-message-sessions-19 (work in progress),
         February 2007.

13.2.  Informational References

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

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

   [14]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and
         HMAC-SHA)", RFC 4634, August 2006.

   [15]  Jennings, C., "Relay Extensions for the Message Sessions Relay
         Protocol (MSRP)", draft-ietf-simple-msrp-relays-10 (work in
         progress), December 2006.

   [16]  Paila, T., "FLUTE - File Delivery over Unidirectional
         Transport", draft-ietf-rmt-flute-revised-03 (work in progress),
         January 2007.

URIs

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

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

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

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


Authors' Addresses

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

   Email: miguel.garcia@nsn.com








Garcia-Martin, et al.   Expires November 19, 2007              [Page 36]


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


   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


























Garcia-Martin, et al.   Expires November 19, 2007              [Page 37]


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


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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

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


Intellectual Property

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

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

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


Acknowledgment

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





Garcia-Martin, et al.   Expires November 19, 2007              [Page 38]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/