--- 1/draft-ietf-mmusic-file-transfer-mech-00.txt 2007-04-27 22:12:07.000000000 +0200 +++ 2/draft-ietf-mmusic-file-transfer-mech-01.txt 2007-04-27 22:12:07.000000000 +0200 @@ -1,22 +1,23 @@ MMUSIC Working Group M. Garcia-Martin -Internet-Draft M. Isomaki -Intended status: Standards Track Nokia -Expires: June 21, 2007 G. Camarillo +Internet-Draft Nokia Siemens Networks +Intended status: Standards Track M. Isomaki +Expires: October 29, 2007 Nokia + G. Camarillo S. Loreto Ericsson - December 18, 2006 + April 27, 2007 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer - draft-ietf-mmusic-file-transfer-mech-00.txt + draft-ietf-mmusic-file-transfer-mech-01.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 @@ -27,33 +28,32 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 21, 2007. + This Internet-Draft will expire on October 29, 2007. Copyright Notice - Copyright (C) The IETF Trust (2006). + Copyright (C) The IETF Trust (2007). Abstract This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. - The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file . The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. Table of Contents @@ -58,62 +58,64 @@ 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 . . . . . . . . . . . . . . . . . . . . 13 - 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14 + 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 . . . . . . . . . . . . 15 - 8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 16 - 8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 16 - 8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 16 - 8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 17 - 8.3. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 18 - 8.4. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 19 + 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 . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 20 9.2. Offerer requests a file from the Answerer and second - file transfer . . . . . . . . . . . . . . . . . . . . . . 23 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 11.1. Registration of new SDP attributes . . . . . . . . . . . . 29 - 11.1.1. Registration of the file-selector attribute . . . . . 30 - 11.1.2. Registration of the disposition attribute . . . . . . 30 - 11.1.3. Registration of the file-date attribute . . . . . . . 30 - 11.1.4. Registration of the icon attribute . . . . . . . . . . 30 - 11.1.5. Registration of the file-range attribute . . . . . . . 31 - 11.2. Registration of new Content Disposition value . . . . . . 31 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 - 13.2. Informational References . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 - Intellectual Property and Copyright Statements . . . . . . . . . . 35 + 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 disposition attribute . . . . . . 33 + 11.1.3. Registration of the file-date attribute . . . . . . . 33 + 11.1.4. Registration of the 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 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) [12] is a protocol for + 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 @@ -139,42 +141,45 @@ on the file before the actual transfer. This MUST be able to include at least content type, size, hash and name of the file, as well as a short (human readable) description. o It MUST be possible for the recipient to request a file from the sender, providing meta information about the file. The sender MUST be able to decide whether to send a file matching the request. The rest of this document is organized as follows. Section 3 defines a few terms used in this document. Section 4 provides the overview - of operation. 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 8 describes the protocol operation - involving SDP and MSRP. Finally, some examples are given in - Section 9. + 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) [14]. Both mechanisms allow a user agent to decide whether or + (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 @@ -210,39 +215,38 @@ 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 - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "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. + 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 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 @@ -243,21 +247,21 @@ 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) [12]. Each SDP "m=" line describes an MSRP + 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 @@ -320,50 +324,54 @@ 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 of zero files. Since there are several hashing algorithms, such as SHA-1 [6], SHA- - 256, SHA-384, SHA-512 [11], etc., a file selector MAY contain several + 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]. attribute = file-selector-attr / disposition-attr / file-date-attr / icon-attr / file-range-attr ;attribute is defined in RFC 4566 - file-selector-attr = "file-selector:" (selector) *(SP selector) + 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 @@ -391,29 +399,47 @@ ; must be used ; DQUOTE defined in RFC 4234 icon-attr = "icon:" icon-value 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 - The 'file-selector' attribute is composed of one or more selectors - which parametrize the file to be transferred. There are four - selectors in this attribute: 'name', 'size', 'type', and 'hash'. + 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. + 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 @@ -516,21 +542,22 @@ 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=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=disposition:not-render a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00" a=icon:cid:id2@alicepc.example.com a=file-range:1-32349 Figure 2: Example of SDP describing a file transfer @@ -587,22 +614,22 @@ 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 [12] procedures. All the media line attributes specified and - required by MSRP [12] (e.g., "a=path", "a=accept-types", etc.) MUST + 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, @@ -657,28 +684,28 @@ 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 [12]. + 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 [12] and SDP [10] + 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 @@ -734,21 +761,21 @@ 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 an 'icon' and '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 [12]) can accommodate a + 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). @@ -762,65 +789,94 @@ 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. Re-usage of Existing m= Lines in SDP +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. -8.4. MSRP Usage +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 [12] procedures + MSRP session, and MUST behave according to the MSRP [11] procedures with respect closing MSRP sessions. 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 [13] is used to transport the SDP offer/ + 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. @@ -828,24 +884,24 @@ | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | | |(4) (MSRP) SEND (chunk) | |----------------------->| - |(5) (MSRP) 200 OK | - |<-----------------------| - |(6) (MSRP) SEND (chunk) | + |(5) (MSRP) SEND (chunk) | |----------------------->| + |(6) (MSRP) 200 OK | + |<-----------------------| |(7) (MSRP) 200 OK | |<-----------------------| | | |(8) (SIP) BYE | |----------------------->| |(9) (SIP) 200 OK | |<-----------------------| | | | | @@ -870,21 +926,22 @@ 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=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=disposition:render a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00" a=icon:cid:id2@alicepc.example.com --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary @@ -909,21 +966,22 @@ 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=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. @@ -942,45 +1000,47 @@ 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: 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 7: MSRP 200 OK response - - F6: Alice sends the second and last chunk. + 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 8: MSRP SEND request containing the second chunk of actual + 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$ + 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 @@ -1055,41 +1115,43 @@ 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=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:* + 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 SEND request that contains the file. MSRP d93kswow SEND @@ -1144,21 +1206,22 @@ 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=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=disposition:render a=file-date:creation:"Sun, 21 May 2006 13:02:15 +03:00" a=icon:cid:id3@alicepc.example.com --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary @@ -1181,21 +1244,22 @@ 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=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=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. @@ -1232,20 +1296,48 @@ -------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 . + + 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=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 @@ -1270,86 +1362,86 @@ 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 + Contact: Miguel Garcia Phone: +358 71800 8000 Attribute name: file-sector 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 disposition attribute - Contact: Miguel Garcia + Contact: Miguel Garcia Phone: +358 71800 8000 Attribute name: 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 + Contact: Miguel Garcia Phone: +358 71800 8000 Attribute name: file-date Long-form attribute name: + Type of attribute: media level only This attribute is not subject to the charset attribute Description: This attribute indicates the dates at which the file was created, modified, or last read. Specification: RFC XXXX 11.1.4. Registration of the icon attribute - Contact: Miguel Garcia + Contact: Miguel Garcia Phone: +358 71800 8000 Attribute name: 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 + Contact: Miguel Garcia 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 - IANA acts on Mail Content Disposition Values and Parameters - registry [19] and registers a new Mail Content Disposition Value - according to the following data: + 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. 12. Acknowledgements @@ -1390,71 +1482,71 @@ [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] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and - HMAC-SHA)", RFC 4634, August 2006. - - [12] Campbell, B., "The Message Session Relay Protocol", - draft-ietf-simple-message-sessions-18 (work in progress), - December 2006. + [11] Campbell, B., "The Message Session Relay Protocol", + draft-ietf-simple-message-sessions-19 (work in progress), + February 2007. 13.2. Informational References - [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + [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. - [14] Burger, E., "A Mechanism for Content Indirection in Session + [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-08 (work in - progress), July 2006. + 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-02 (work in progress), - August 2006. + Transport", draft-ietf-rmt-flute-revised-03 (work in progress), + January 2007. URIs [17] [18] [19] [20] Authors' Addresses Miguel A. Garcia-Martin - Nokia - P.O.Box 407 - NOKIA GROUP, FIN 00045 + Nokia Siemens Networks + P.O.Box 6 + Nokia Siemens Networks, FIN 02022 Finland - Email: miguel.an.garcia@nokia.com - + Email: miguel.garcia@nsn.com Markus Isomaki Nokia Keilalahdentie 2-4 Espoo 02150 Finland Email: markus.isomaki@nokia.com + Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Salvatore Loreto Ericsson @@ -1459,21 +1551,21 @@ Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Salvatore.Loreto@ericsson.com Full Copyright Statement - Copyright (C) The IETF Trust (2006). + 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