MMUSIC Working Group M. Garcia-Martin Internet-Draft M. Isomaki Intended status: Standards Track Nokia Expires: December 15, 2006 G. Camarillo S. Loreto Ericsson June 13, 2006 Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer draft-garcia-mmusic-file-transfer-mech-00.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 December 15, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files. The offerer can Garcia-Martin, et al. Expires December 15, 2006 [Page 1] Internet-Draft File Transfer with SDP offer/answer June 2006 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. The transfer of files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined to as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP are provided in the document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 5. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 10 6.1. File selector . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 11 6.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 11 6.2.2. The Offerer is a File Receiver . . . . . . . . . . . . 11 6.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 12 6.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 12 6.3.1. The Answerer is a File Receiver . . . . . . . . . . . 12 6.3.2. The Answerer is a File Sender . . . . . . . . . . . . 12 6.4. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 13 6.5. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Offerer sends a file to the Answerer . . . . . . . . . . . 14 7.2. Offerer requests a file from the Answerer and second file transfer . . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.2. Informational References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Garcia-Martin, et al. Expires December 15, 2006 [Page 2] Internet-Draft File Transfer with SDP offer/answer June 2006 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, the session described with SDP [10]. 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 expressed in [14] 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 December 15, 2006 [Page 3] Internet-Draft File Transfer with SDP offer/answer June 2006 All these 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. 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. 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. The detailed syntax and semantics of the new SDP attributes and conventions on how the existing ones are used is defined in Section 5. Section 6 describes the protocol operation involving SDP and MSRP. Finally, some examples are given in Section 7. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", Garcia-Martin, et al. Expires December 15, 2006 [Page 4] Internet-Draft File Transfer with SDP offer/answer June 2006 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Definitions For the purpose of this document, the following definitions specified in RFC 3264 [7] apply: o Answerer o Offerer Additionally, we define the following terms: File sender: The endpoint that is willing to transmit a file to the file receiver. File receiver: The endpoint that is willing to receive a file from the file sender. File selector: The tuple composed of file attributes that are used in SDP offer in order to delimit the set of files that matches the offer. This is described in more detail in Section 6.1. 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. File transfer is modelled on top of the Message Session Relay Protocol (MSRP) [11]. Each SDP "m=" line describes an MSRP-based media stream used to transfer a single file. That is, the transfer of multiple files requires multiple "m=" lines. Each "m=" line describing an MSRP media stream for file transfer is complemented with a few attributes describing the file to be transferred. SDP direction attibutes "a=sendonly" or "a=recvonly" are used to indicate the direction of the transfer, i.e. whether the SDP offerer is willing to send of receive the file. Assuming that the answerer accepts the file transfer, the actual transfer of the files takes place with ordinary MSRP. 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, Garcia-Martin, et al. Expires December 15, 2006 [Page 5] Internet-Draft File Transfer with SDP offer/answer June 2006 hash, icon (e.g., if the file is a picture), etc. 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. Extensions to SDP We define a number of attributes for SDP [10] that provide the required information to describe the transfer of a file with MSRP. 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 December 15, 2006 [Page 6] Internet-Draft File Transfer with SDP offer/answer June 2006 attribute = filename-attr / filetype-attr / disposition-attr / filesize-attr / creation-date-attr / modification-date-attr / read-date-attr / icon-attr / hash-attr / ;attribute is defined in sdp-new filename-attr = "filename:" filename-string filename-string = byte-string ;byte-string defined in sdp-new filetype-attr = "filetype:" type "/" subtype *(";"parameter) ; parameter defined in RFC 2045 type = token subtype = token disposition-attr = "disposition:" disposition-value disposition-value = token filesize-attr = "filesize:" filesize-value filesize-value = integer ;integer defined in sdp-new creation-date-attr = "creation-date:" date-time modification-date-attr = "modification-date:" date-time read-date-attr = "read-date:" date-time ; date-time is defined in RFC 2822 ; numeric timezones (+HHMM or -HHMM) ; must be used icon-attr = "icon:" icon-value icon-value = cid-url ;cid-url defined in RFC 2392 hash-attr = "hash:" hash-algorithm WSP hash-value hash-algorithm = token ;see IANA Hash Algorithm ;section in the IPSEC ;registry hash-value = hex-val ;hex-val defined in RFC 4234 Figure 1: Syntax of the SDP extension The 'filename' attribute contains the filename of the content, and its value is a byte string (specified in SDP [10]). The value of this attribute SHOULD be the same of the 'filename' parameter of Content-Disposition header field [3] that could be signalled by the actual file transfer. Garcia-Martin, et al. Expires December 15, 2006 [Page 7] Internet-Draft File Transfer with SDP offer/answer June 2006 The 'filetype' 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 'filetype' attribute. Possible MIME Media Type values are the ones listed in the IANA registry for MIME Media Types. Zero or more parameters can follow. The syntax of 'parameter' is specified in RFC 2045 [2] . The 'disposition' attribute provides a suggestion to the other endpoint about the intended disposition of the file. Possible values are the one listed in the IANA registry for Mail Content Disposition Values, although most likely only the "inline" and "attachment" values are significant for file transfer applications. 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. The 'filesize' 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. The 'creation-date' attribute indicates the date at which the file was created. The value MUST be a 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 attribute SHOULD be the same of the 'creation-date' parameter of Content-Disposition header field [3] that could be signalled by the actual file transfer. The 'modification-date' attribute indicates the date at which the file was last modified. The value MUST be a 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 attribute SHOULD be the same of the 'modification- date' parameter of Content-Disposition header field [3] that could be signalled by the actual file transfer. The 'read-date' attribute indicates the date at which the file was last read. The value MUST be a 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 attribute SHOULD be the same of the 'read-date' parameter of Content-Disposition header field [3] that could be signalled by the actual file transfer. The '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 an icon representing the contents of the file to be Garcia-Martin, et al. Expires December 15, 2006 [Page 8] Internet-Draft File Transfer with SDP offer/answer June 2006 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 that can potentially be transferred. It is recommended to keep icons restricted to the minimum number of bytes that provide significance. The 'icon' attribute contains a Content-ID URL, which is specified in RFC 2392 [4]. The 'hash' 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 of the 'hash' attribute 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' attribute includes the type of hash and its value. Possible types of hash are the ones defined in the Hash Algorithm Section of the IANA registry of the IPSec registry. Implementations according to this specification MUST implement the US Secure Hash Algorithm 1 (SHA1) [6] and MAY implement other hashing algorithms. The creator of the SDP MAY also add more than one 'hash' attribute (presumably with different types of hash) to the same file. The value is the byte string resulting of applying the hash algorithm to the content of the file. The following is an example of an SDP body that contains the extensions defined in this memo: v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=message 7654 TCP/MSRP * i=This is my latest picture a=sendonly a=accept-types:* a=path:msrp://atlanta.example.com:7654/jshA7we;tcp a=filename:My cool picture.jpg a=filetype:image/jpeg a=disposition:inline a=filesize:32349 a=creation-date:Mon, 15 May 2006 15:01:31 +03:00 a=icon:cid:id2@alicepc.example.com a=hash:SHA 72245FE8653DDAF371362F86D471913EE4A2CE2E Garcia-Martin, et al. Expires December 15, 2006 [Page 9] Internet-Draft File Transfer with SDP offer/answer June 2006 Figure 2: Example of SDP describing a file transfer 6. Protocol Operation This Section discusses how to use the parameters defined in Section 5 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. 6.1. File selector The protocol specified in this document requires a mechanism to identify files in a remote entitly. We introduce the concept of a file selector, which is defined as the tuple composed of the 'hash', 'filename', 'filesize', and 'filetype' attributes in SDP. The file selector selects all the files where each of the attributes matches with the attributes present in the selector, i.e. the set of files which is the intersection of the files macthing each of the attributes separately. Thus, a file selector can point to zero, one, or more files, depending on the presence of the mentioned attributes in the SDP and depending on the available files in a host. The file transfer mechanism that we specify in this document requires that a file selector eventually results at most in a single file to be chosen. Typically, if the 'hash' attribute is known, the 'hash' attribute is enough to produce a file selector that points to zero or one file. However, a file selector selecting a unique file is not always known by the offerer. Sometimes only the 'filename', 'filesize', or 'filetype' attributes are known, so the file selector may result in more than one file, an undesired case. The opposite is Garcia-Martin, et al. Expires December 15, 2006 [Page 10] Internet-Draft File Transfer with SDP offer/answer June 2006 also true, if the file selector contains a 'hash' and a 'filename' attributes, but the user at 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 of zero files. 6.2. 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. 6.2.1. The Offerer is a File Sender If the offerer is a file sender, it MUST add a session or media 'sendonly' attribute to the SDP offer. Additionally, the offerer SHOULD also add a 'filetype', 'filesize', and 'hash' attributes indicating the type, size, and hash of the file, respectively. These attributes might not be known when the offerer creates the SDP offer, for example, because the host is still processing the file. The 'hash' attribute contains valuable information to the file receiver to identify whether the file is already available and need not be transmitted. The offerer MAY also add a 'filename', 'icon', 'disposition', 'creation-date', 'modification-date', and 'read-date' attributes further describing the file to be transferred. The 'disposition' attribute provides a presentation suggestion, (for example: the file sender would like the file receiver to render file "inline", or save it as an "attachment"). The three date attributes provide the answerer with an indication of the age of the file. 6.2.2. The Offerer is a File Receiver If the offerer is a file receiver, it MUST create an SDP offer that contains a session or media 'recvonly' attribute. Then the offerer SHOULD add at least one of the attributes that constitute the file selector ('hash', 'filename', 'filesize', or 'filetype'). 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. Garcia-Martin, et al. Expires December 15, 2006 [Page 11] Internet-Draft File Transfer with SDP offer/answer June 2006 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). 6.2.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]. 6.3. 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. 6.3.1. The Answerer is a File Receiver If the answerer is a file receiver and decides to accept the file transfer it MUST create an SDP answer (per RFC 3264 [7]) containing a 'recvonly' attribute. If the offer contains 'filetype', 'filesize', 'filename' or 'hash' attributes, the answerer MUST copy them into the answer. This informs the offerer that the answerer supports this specification. If the answerer is a file receiver, it MUST NOT include 'icon', 'disposition', 'creation-date', 'modification-date', or 'read-date' attributes in the SDP answer. If the received offer contains a 'hash' attribute, the answerer can use it 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. 6.3.2. The Answerer is a File Sender If the answerer is a file sender, it MUST first inspect the received SDP offer and apply the file selector. The file selector is the set Garcia-Martin, et al. Expires December 15, 2006 [Page 12] Internet-Draft File Transfer with SDP offer/answer June 2006 of files that results from the intersection of the files whose attributes individually match with the 'filetype', 'filesize', 'filename', and 'hash' attributes (if they are present) that modify the same "m=" line in the SDP offer (i.e., the four mentioned attributes are located under the same "m=" line in SDP). 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 if it is the only stream in the SDP offer, then if SHOULD reject the SDP as per procedures in RFC 3264 [7]). If the file selector points to a single file and the answerer decides to accept the file transfer, the answerer MUST create an SDP answer (per RFC 3264 [7]) that contains a 'sendonly' attribute. The answerer SHOULD add a 'hash' attribute containing the hash of the file to be sent and MAY include, 'filetype', and 'icon' 'disposition' attributes to further describe the file. Although the answerer MAY also include 'filename' 'disposition', 'creation-date', 'modification-date', 'read-date', and 'filesize' attributes, it is RECOMMENDED not to include them 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 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. 6.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 Garcia-Martin, et al. Expires December 15, 2006 [Page 13] Internet-Draft File Transfer with SDP offer/answer June 2006 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. 6.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 6.2 and Section 6.3 is only used to transfer a single file. So, senders MUST only use a given 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. 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. 7. Examples 7.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. Garcia-Martin, et al. Expires December 15, 2006 [Page 14] Internet-Draft File Transfer with SDP offer/answer June 2006 Alice's UAC Bob's UAS | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | | |(4) (MSRP) SEND (chunk) | |----------------------->| |(5) (MSRP) 200 OK | |<-----------------------| |(6) (MSRP) SEND (chunk) | |----------------------->| |(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 December 15, 2006 [Page 15] Internet-Draft File Transfer with SDP offer/answer June 2006 INVITE sip:bob@example.com SIP/2.0 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 1 INVITE Max-Forwards: 70 Date: Sun, 21 May 2006 13:02:03 GMT Contact: 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:* a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=filename:My cool picture.jpg a=filetype:image/jpeg a=disposition:inline a=filesize:4096 a=creation-date:Mon, 15 May 2006 15:01:31 +03:00 a=icon:cid:id2@alicepc.example.com a=hash:SHA 72245FE8653DDAF371362F86D471913EE4A2CE2E --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Length: [length of image] Content-Disposition: icon ...binary JPEG image... --boundary71-- 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 Garcia-Martin, et al. Expires December 15, 2006 [Page 16] Internet-Draft File Transfer with SDP offer/answer June 2006 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:* a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=filename:My cool picture.jpg a=filetype:image/jpeg a=filesize:4096 a=hash:SHA 72245FE8653DDAF371362F86D471913EE4A2CE2E F4: Alice opens a TCP connection to Bob and creates an MSRP SEND request. This SEND request contains the first chunk of the file. MSRP d93kswow SEND To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp Message-ID: 12339sdqwer Byte-Range: 1-2048/4096 Content-Type: image/jpeg Content-Disposition: inline; filename="My cool picture.jpg"; creation-date="Mon, 15 May 2006 15:01:31 +03:00"; size=4096 ... first chunk of the JPEG image ... -------d93kswow+ F5: 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/4096 -------d93kswow$ F6: Alice sends the second and last chunk. Garcia-Martin, et al. Expires December 15, 2006 [Page 17] Internet-Draft File Transfer with SDP offer/answer June 2006 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-4096/4096 Content-Type: image/jpeg Content-Disposition: inline; filename="My cool picture.jpg"; creation-date="Mon, 15 May 2006 15:01:31 +03:00"; size=4096 ... second (and last) chunk of the JPEG image ... -------op2nc9a$ 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-4096/4096 -------op2nc9a$ 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. 7.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 December 15, 2006 [Page 18] Internet-Draft File Transfer with SDP offer/answer June 2006 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 December 15, 2006 [Page 19] Internet-Draft File Transfer with SDP offer/answer June 2006 INVITE sip:bob@example.com SIP/2.0 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 1 INVITE Max-Forwards: 70 Date: Sun, 21 May 2006 13:02:03 GMT Contact: 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:image/jpeg a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=hash:SHA 72245FE8653DDAF371362F86D471913EE4A2CE2E >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:* a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=filetype:image/jpeg a=hash:SHA 72245FE8653DDAF371362F86D471913EE4A2CE2E F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP SEND request that contains the file. Garcia-Martin, et al. Expires December 15, 2006 [Page 20] Internet-Draft File Transfer with SDP offer/answer June 2006 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: image/jpeg Content-Disposition: inline; 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=2027 ...binary JPEG image... -------d93kswow$ 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$ 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 December 15, 2006 [Page 21] Internet-Draft File Transfer with SDP offer/answer June 2006 INVITE sip:bob@example.com SIP/2.0 To: Bob ;tag=1928323431 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 2 INVITE Max-Forwards: 70 Date: Sun, 21 May 2006 13:02:33 GMT Contact: Content-Type: application/sdp; boundary="boundary71" Content-Length: [length of SDP] --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:* a=path:msrp://alicepc.example.com:5670/iau39;tcp a=filename:Sunset.jpg a=filetype:image/jpeg a=disposition:inline a=filesize:4096 a=creation-date:Sun, 21 May 2006 13:02:15 a=icon:cid:id3@alicepc.example.com a=hash:SHA 58231FE8653BBCF371362F86D471913EE4B1DF2F --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Length: [length of image] Content-Disposition: icon ...binary JPEG image... --boundary71-- F7: Bob receives the re-INVITE request, inspects the SDP offer and Garcia-Martin, et al. Expires December 15, 2006 [Page 22] Internet-Draft File Transfer with SDP offer/answer June 2006 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:* a=path:msrp://bobpc.example.com:9999/9an4ea;tcp a=filename:Sunset.jpg a=filetype:image/jpeg a=disposition:inline a=filesize:4096 a=hash:SHA 58231FE8653BBCF371362F86D471913EE4B1DF2F F9: Alice opens a new TCP connection to Bob and creates an MSRP SEND request that contains the file. 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: image/jpeg Content-Disposition: inline; filename="Sunset.jpg"; creation-date="Sun, 21 May 2006 13:02:15"; size=4096 ... binary JPEG image ... -------d95ksxox+ 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$ 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. Garcia-Martin, et al. Expires December 15, 2006 [Page 23] Internet-Draft File Transfer with SDP offer/answer June 2006 8. Security Considerations TBD 9. IANA Considerations TBD 10. 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, and Sudha Vs discussed and provided comments and improvements to this document. 11. References 11.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, Garcia-Martin, et al. Expires December 15, 2006 [Page 24] Internet-Draft File Transfer with SDP offer/answer June 2006 July 2004. [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [10] Handley, M., "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. [11] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-14 (work in progress), February 2006. 11.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] Isomaki, M., "Requirements and Possible Mechanisms for File Transfer Services Within the Context of SIP Based Communication", draft-isomaki-sipping-file-transfer-01 (work in progress), March 2006. [15] Jennings, C., "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", draft-ietf-simple-msrp-relays-07 (work in progress), February 2006. [16] Paila, T., "FLUTE - File Delivery over Unidirectional Transport", draft-ietf-rmt-flute-revised-01 (work in progress), January 2006. Authors' Addresses Miguel A. Garcia-Martin Nokia P.O.Box 407 NOKIA GROUP, FIN 00045 Finland Email: miguel.an.garcia@nokia.com Garcia-Martin, et al. Expires December 15, 2006 [Page 25] Internet-Draft File Transfer with SDP offer/answer June 2006 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 December 15, 2006 [Page 26] Internet-Draft File Transfer with SDP offer/answer June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 December 15, 2006 [Page 27]