tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5547

 
 
 

A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer

Part 3 of 3, p. 28 to 50
Prev RFC Part

 


prevText      Top      Up      ToC       Page 28 
9.  Examples

9.1.  Offerer Sends a File to the Answerer

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

Top      Up      ToC       Page 29 
   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 7.

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

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

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

   v=0
   o=alice 2890844526 2890844526 IN IP4 alicepc.example.com
   s=
   c=IN IP4 alicepc.example.com
   t=0 0
   m=message 7654 TCP/MSRP *
   i=This is my latest picture
   a=sendonly
   a=accept-types:message/cpim
   a=accept-wrapped-types:*
   a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
   a=file-selector:name:"My cool picture.jpg" type:image/jpeg
     size:4092 hash:sha-1:
     72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
   a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
   a=file-disposition:render
   a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
   a=file-icon:cid:id2@alicepc.example.com

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

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

   --boundary71--

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

Top      Up      ToC       Page 31 
      NOTE: The Content-Type header field and the 'file-selector'
      attribute in the above figure are split in several lines for
      formatting purposes.  Real implementations will encode it in a
      single line.

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

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

   v=0
   o=bob 2890844656 2890844656 IN IP4 bobpc.example.com
   s=
   c=IN IP4 bobpc.example.com
   t=0 0
   m=message 8888 TCP/MSRP *
   a=recvonly
   a=accept-types:message/cpim
   a=accept-wrapped-types:*
   a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
   a=file-selector:name:"My cool picture.jpg" type:image/jpeg
     size:4092 hash:sha-1:
     72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
   a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE

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

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

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

Top      Up      ToC       Page 32 
   MSRP d93kswow SEND
   To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
   From-Path: msrp://alicepc.example.com:7654/iau39;tcp
   Message-ID: 12339sdqwer
   Byte-Range: 1-2048/4385
   Content-Type: message/cpim

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

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

   Figure 10: 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 11: 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$

                      Figure 12: MSRP 200 OK response

Top      Up      ToC       Page 33 
   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 13: MSRP 200 OK response

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

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

9.2.  Offerer Requests a File from the Answerer and Second File Transfer

   In this example, Alice, the SDP offerer, first wishes to fetch a file
   from Bob, the SDP answerer.  Alice knows that Bob has a specific file
   she wants to download.  She has learned the hash of the file by some
   out-of-band mechanism.  The hash selector is enough to produce a file
   selector that points to the specific file.  So, Alice creates an SDP
   offer that contains the file descriptor.  Bob accepts the file
   transfer 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 reuses 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 14 shows the sequence flow.

Top      Up      ToC       Page 34 
                   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 14: 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.

Top      Up      ToC       Page 35 
   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 15: INVITE request containing an SDP offer for file transfer

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

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

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

Top      Up      ToC       Page 36 
   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 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.

   F4: Alice opens a TCP connection to Bob.  Bob then creates an MSRP
   SEND request that contains the file.


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

   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.com>
   DateTime: 2006-05-15T15:02:31-03:00
   Content-Disposition: render; filename="My cool photo.jpg";
                  creation-date="Mon, 15 May 2006 15:01:31 +0300";
                  modification-date="Mon, 15 May 2006 16:04:53 +0300";
                  read-date="Mon, 16 May 2006 09:12:27 +0300";
                  size=1931
   Content-Type: image/jpeg

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

          Figure 17: MSRP SEND request containing the actual file

   F5: Alice acknowledges the reception of the SEND request.

Top      Up      ToC       Page 37 
   MSRP d93kswow 200 OK
   To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
   From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
   Byte-Range: 1-2027/2027
   -------d93kswow$

                      Figure 18: MSRP 200 OK response

   F6: Alice reuses the existing SDP media line inserting the
   description of the file to be sent and attaches it to a SIP re-INVITE
   request addressed to Bob.  Alice reuses the TCP port number for the
   MSRP stream, but changes the MSRP session and the 'file-transfer-id'
   value according to this specification.

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

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

   v=0
   o=alice 2890844526 2890844527 IN IP4 alicepc.example.com
   s=
   c=IN IP4 alicepc.example.com
   t=0 0
   m=message 7654 TCP/MSRP *
   i=This is my latest picture
   a=sendonly
   a=accept-types:message/cpim
   a=accept-wrapped-types:*
   a=path:msrp://alicepc.example.com:7654/iau39;tcp
   a=file-selector:name:"sunset.jpg" type:image/jpeg
     size:4096 hash:sha-1:
     58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
   a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
   a=file-disposition:render
   a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300"
   a=file-icon:cid:id3@alicepc.example.com

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

   [..small preview icon...]

   --boundary71--

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

Top      Up      ToC       Page 39 
      NOTE: The Content-Type header field and the 'file-selector'
      attribute in the above figure are split in several lines for
      formatting purposes.  Real implementations will encode it in a
      single line.

   F7: Bob receives the re-INVITE request, inspects the SDP offer and
   extracts the icon body, checks the creation date and the file size,
   and decides to accept the file transfer.  So Bob creates an SDP
   answer where he reuses the same TCP port number, but changes his MSRP
   session, according to the procedures of this specification.

   v=0
   o=bob 2890844656 2890855440 IN IP4 bobpc.example.com
   s=
   c=IN IP4 bobpc.example.com
   t=0 0
   m=message 8888 TCP/MSRP *
   a=recvonly
   a=accept-types:message/cpim
   a=accept-wrapped-types:*
   a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp
   a=file-selector:name:"sunset.jpg" type:image/jpeg
     size:4096 hash:sha-1:
     58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
   a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
   a=file-disposition:render

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

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

   F9: If a TCP connection towards Bob is already open, Alice reuses
   that TCP connection to send an MSRP SEND request that contains the
   file.

Top      Up      ToC       Page 40 
   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 21: MSRP SEND request containing the actual file

   F10: Bob acknowledges the reception of the SEND request.

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

                      Figure 22: 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 24.  The SDP indicates support for CPIM messages that
   can contain other MIME types.  The maximum MSRP message size that the
   endpoint can receive is 20000 octets.  The presence of the 'file-
   selector' attribute indicates support for the file transfer offer/
   answer mechanism.

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

              Figure 23: Flow diagram of a capability request

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

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

10.  Security Considerations

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

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

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

Top      Up      ToC       Page 42 
   When an SDP offer contains the description of a file to be sent or
   received, the SDP answerer MUST first authenticate the SDP offerer
   and then it MUST authorize the file transfer operation, typically
   according to a local policy.  Typically, these functions are
   integrated in the high-level protocol that carries SDP (e.g., SIP),
   and in the file transfer protocol (e.g., MSRP).  If SIP [RFC3261] and
   MSRP [RFC4975] are used, the standard mechanisms for user
   authentication and authorization are sufficient.

   It is possible that a malicious or misbehaving implementation tries
   to exhaust the resources of the remote endpoint, e.g., the internal
   memory or the file system, by sending very large files.  To protect
   from this attack, an SDP answer SHOULD first verify the identity of
   the SDP offerer, and perhaps only accept file transfers from trusted
   sources.  Mechanisms to verify the identity of the file sender depend
   on the high-level protocol that carries the SDP, for example, SIP
   [RFC3261] and MSRP [RFC4975].

   It is also RECOMMENDED that implementations take measures to avoid
   attacks on resource exhaustion, for example, by limiting the size of
   received 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 of
   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.,
   anti-virus, anti-spyware) to mitigate the risk of damage at their
   host.

11.  IANA Considerations

   IANA has registered a number of SDP attributes according to the
   following.

11.1.  Registration of New SDP Attributes

   IANA has registered a number of media-level-only attributes in the
   Session Description Protocol Parameters registry [IANA].  The
   registration data, according to RFC 4566 [RFC4566], follows.

Top      Up      ToC       Page 43 
11.1.1.  Registration of the file-selector Attribute

   Contact:  Miguel Garcia <miguel.a.garcia@ericsson.com>

   Phone:  +34 91 339 1000

   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 identifies a file by
      indicating a combination of the 4-tuple composed of the name,
      size, type, and hash of the file.

   Specification:  RFC 5547

11.1.2.  Registration of the file-transfer-id Attribute

   Contact:  Miguel Garcia <miguel.a.garcia@ericsson.com>

   Phone:  +34 91 339 1000

   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 5547

11.1.3.  Registration of the file-disposition Attribute

   Contact:  Miguel Garcia <miguel.a.garcia@ericsson.com>

   Phone:  +34 91 339 1000

   Attribute name:  file-disposition

   Long-form attribute name:  File Disposition

   Type of attribute:  media level only

Top      Up      ToC       Page 44 
      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 5547

11.1.4.  Registration of the file-date Attribute

   Contact:  Miguel Garcia <miguel.a.garcia@ericsson.com>

   Phone:  +34 91 339 1000

   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 on which the file
      was created, modified, or last read.

   Specification:  RFC 5547

11.1.5.  Registration of the file-icon Attribute

   Contact:  Miguel Garcia <miguel.a.garcia@ericsson.com>

   Phone:  +34 91 339 1000

   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 5547

Top      Up      ToC       Page 45 
11.1.6.  Registration of the file-range Attribute

   Contact:  Miguel Garcia <miguel.a.garcia@ericsson.com>

   Phone:  +34 91 339 1000

   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:  This attribute contains the range of transferred octets
      of the file.

   Specification:  RFC 5547

12.  Acknowledgments

   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
   of 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, Vikram Chhibber, Ben Campbell, Richard
   Barnes, and Chris Newman 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.

Top      Up      ToC       Page 46 
   [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.

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

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

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

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

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

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

   [RFC5322]    Resnick, P., Ed., "Internet Message Format", RFC 5322,
                October 2008.

13.2.  Informative 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.

Top      Up      ToC       Page 47 
   [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.

   [IANA]       IANA, "Internet Assigned Numbers Authority",
                <http://www.iana.org>.

   [FLUTE-REV]  Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE -
                File Delivery over Unidirectional Transport", Work
                in Progress, September 2008.

Top      Up      ToC       Page 48 
Appendix A.  Alternatives Considered

   The requirements are related to the description and negotiation of
   the session, not to the actual file transfer mechanism.  Thus, it is
   natural that in order to meet them it is enough to define attribute
   extensions and usage conventions to SDP, while MSRP itself needs no
   extensions and can be used as it is.  This is effectively the
   approach taken in this specification.  Another goal has been to
   specify the SDP extensions in such a way that a regular MSRP endpoint
   that 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 how it works for endpoints behind NATs.  The level of
   requirements in implementations decides which solution meets the
   requirements.

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

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

   This specification defines a set of SDP attributes that describe a
   file to be transferred between two endpoints.  The information needed
   to describe a file could be potentially encoded in a few different

Top      Up      ToC       Page 49 
   ways.  The MMUSIC working group considered a few alternative
   approaches before deciding to use the encoding described in
   Section 6.  In particular, the working group looked at the MIME
   'external-body' type and the use of a single SDP attribute or
   parameter.

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

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

Top      Up      ToC       Page 50 
Authors' Addresses

   Miguel A. Garcia-Martin
   Ericsson
   Calle Via de los Poblados 13
   Madrid, ES  28033
   Spain

   EMail: miguel.a.garcia@ericsson.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