--- 1/draft-ietf-mmusic-file-transfer-mech-08.txt 2008-11-03 11:12:08.000000000 +0100 +++ 2/draft-ietf-mmusic-file-transfer-mech-09.txt 2008-11-03 11:12:08.000000000 +0100 @@ -1,25 +1,25 @@ MMUSIC Working Group M. Garcia-Martin -Internet-Draft Nokia Siemens Networks +Internet-Draft Ericsson Intended status: Standards Track M. Isomaki -Expires: November 21, 2008 Nokia +Expires: May 7, 2009 Nokia G. Camarillo S. Loreto Ericsson P. Kyzivat Cisco Systems - May 20, 2008 + November 3, 2008 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer - draft-ietf-mmusic-file-transfer-mech-08.txt + draft-ietf-mmusic-file-transfer-mech-09.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 @@ -30,21 +30,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 21, 2008. + This Internet-Draft will expire on May 7, 2009. 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 @@ -57,54 +57,54 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14 - 8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 14 - 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 . . . . . . . . . . . . . . . . . . . 17 - 8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 17 - 8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 18 - 8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 19 - 8.4. Aborting an ongoing file transfer operation . . . . . . . 21 - 8.5. Indicating File Transfer Offer/Answer Capability . . . . . 24 - 8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 25 - 8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 25 - 8.8. Considerations about the 'file-icon' attribute . . . . . . 27 - 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 27 + 8.1. The 'file-transfer-id' attribute . . . . . . . . . . . . . 14 + 8.2. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 17 + 8.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 17 + 8.2.2. The Offerer is a File Receiver . . . . . . . . . . . . 18 + 8.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 19 + 8.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 19 + 8.3.1. The Answerer is a File Receiver . . . . . . . . . . . 19 + 8.3.2. The Answerer is a File Sender . . . . . . . . . . . . 20 + 8.4. Aborting an ongoing file transfer operation . . . . . . . 22 + 8.5. Indicating File Transfer Offer/Answer Capability . . . . . 25 + 8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 26 + 8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 26 + 8.8. Considerations about the 'file-icon' attribute . . . . . . 28 + 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 28 9.2. Offerer requests a file from the Answerer and second - file transfer . . . . . . . . . . . . . . . . . . . . . . 32 - 9.3. Example of a capability indication . . . . . . . . . . . . 39 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 - 11.1. Registration of new SDP attributes . . . . . . . . . . . . 41 - 11.1.1. Registration of the file-selector attribute . . . . . 41 - 11.1.2. Registration of the file-transfer-id attribute . . . . 42 - 11.1.3. Registration of the file-disposition attribute . . . . 42 - 11.1.4. Registration of the file-date attribute . . . . . . . 42 - 11.1.5. Registration of the file-icon attribute . . . . . . . 43 - 11.1.6. Registration of the file-range attribute . . . . . . . 43 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43 - 13.2. Informational References . . . . . . . . . . . . . . . . . 44 - Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 45 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 - Intellectual Property and Copyright Statements . . . . . . . . . . 48 + file transfer . . . . . . . . . . . . . . . . . . . . . . 33 + 9.3. Example of a capability indication . . . . . . . . . . . . 40 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 + 11.1. Registration of new SDP attributes . . . . . . . . . . . . 42 + 11.1.1. Registration of the file-selector attribute . . . . . 42 + 11.1.2. Registration of the file-transfer-id attribute . . . . 43 + 11.1.3. Registration of the file-disposition attribute . . . . 43 + 11.1.4. Registration of the file-date attribute . . . . . . . 43 + 11.1.5. Registration of the file-icon attribute . . . . . . . 44 + 11.1.6. Registration of the file-range attribute . . . . . . . 44 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 + 13.2. Informational References . . . . . . . . . . . . . . . . . 45 + Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 46 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 + Intellectual Property and Copyright Statements . . . . . . . . . . 49 1. Introduction The Session Description Protocol (SDP) Offer/Answer [RFC3264] provides a mechanism for two endpoints to arrive at a common view of a multimedia session between them. These sessions often contain real-time media streams such as voice and video, but are not limited to that. Basically, any media component type can be supported, as long as there is a specification how to negotiate it within the SDP offer/answer exchange. @@ -295,35 +295,35 @@ support of the file transfer offer/answer capability that this document specifies. This is further explained in Section 8.5. 6. Extensions to SDP We define a number of new SDP [RFC4566] 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 [RFC5234] of these new attributes. It is built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183 - [RFC2183], RFC 2392 [RFC2392], and RFC 2822 [RFC2822]. + [RFC2183], RFC 2392 [RFC2392], and RFC 5322 [RFC5322]. attribute = file-selector-attr / file-disp-attr / file-tr-id-attr / file-date-attr / file-icon-attr / file-range-attr ;attribute is defined in RFC 4566 file-selector-attr = "file-selector" [":" selector *(SP selector)] selector = filename-selector / filesize-selector / filetype-selector / hash-selector filename-selector = "name:" DQUOTE filename-string DQUOTE ; DQUOTE defined in RFC 5234 filename-string = 1*(filename-char/percent-encoded) - filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%26-FF) + filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF ;any byte except NUL, CR, LF, ;double quotes, or percent percent-encoded = "%" HEXDIG HEXDIG ; HEXDIG defined in RFC 5234 filesize-selector = "size:" filesize-value filesize-value = integer ;integer defined in RFC 4566 filetype-selector = "type:" type "/" subtype *(";"parameter) ; parameter defined in RFC 2045 @@ -344,21 +344,21 @@ file-disp-attr = "file-disposition:" file-disp-value file-disp-value = token file-date-attr = "file-date:" date-param *(SP date-param) date-param = c-date-param / m-date-param / r-date-param c-date-param = "creation:" DQUOTE date-time DQUOTE m-date-param = "modification:" DQUOTE date-time DQUOTE r-date-param = "read:" DQUOTE date-time DQUOTE - ; date-time is defined in RFC 2822 + ; date-time is defined in RFC 5322 ; numeric timezones (+HHMM or -HHMM) ; must be used ; DQUOTE defined in RFC 5234 files. file-icon-attr = "file-icon:" file-icon-value file-icon-value = cid-url ;cid-url defined in RFC 2392 file-range-attr = "file-range:" start-offset "-" stop-offset start-offset = integer ;integer defined in RFC 4566 stop-offset = integer / "*" @@ -445,89 +445,90 @@ The value of the 'hash' selector is the byte string resulting of applying the hash algorithm to the content of the whole file, even when the file transfer is limited to a number of octets (i.e., the 'file-range' attribute is indicated). The 'file-transfer-id' attribute provides a randomly chosen globally unique identification to the actual file transfer. It is used to distinguish a new file transfer request from a repetition of the SDP (or the fraction of the SDP that deals with the file description). - This attribute is described in much greater detail in Section 8.3. + This attribute is described in much greater detail in Section 8.1. The 'file-disposition' attribute provides a suggestion to the other endpoint about the intended disposition of the file. Section 7 provides further discussion of the possible values. The value of this attribute SHOULD be the same as the disposition type parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer protocol. The 'file-date' attribute indicates the dates at which the file was created, modified, or last read. This attribute MAY contain a combination of the 'creation', 'modification', and 'read' parameters, but MUST NOT contain more than one of each type . The 'creation' parameter indicates the date at which the file was created. The value MUST be a quoted string which contains a - representation of the creation date of the file in RFC 2822 [RFC2822] + representation of the creation date of the file in RFC 5322 [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. The value of this parameter SHOULD be the same as the 'creation-date' parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer protocol. The 'modification' parameter indicates the date at which the file was last modified. The value MUST be a quoted string which contains a - representation of the last modification date to the file in RFC 2822 - [RFC2822] 'date-time' format. Numeric timezones (+HHMM or -HHMM) + representation of the last modification date to the file in RFC 5322 + [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. The value of this parameter SHOULD be the same as the 'modification-date' parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer protocol. The 'read' parameter indicates the date at which the file was last read. The value MUST be a quoted string which contains a - representation of the last date the file was read in RFC 2822 - [RFC2822] 'date-time' format. Numeric timezones (+HHMM or -HHMM) + representation of the last date the file was read in RFC 5322 + [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. The value of this parameter SHOULD be the same as the 'read-date' parameter of the Content-Disposition header field [RFC2183] that would be signaled by the actual file transfer protocol. The 'file-icon' attribute can be useful with certain file types such as images. It allows the file sender to include a pointer to a body that includes a small preview icon representing the contents of the file to be transferred, which the file receiver can use to determine whether it wants to receive such file. The 'file-icon' attribute contains a Content-ID URL, which is specified in RFC 2392 [RFC2392]. Section 8.8 contains further considerations about the 'file-icon' attribute. The 'file-range' attribute provides a mechanism to signal a chunk of a file rather than the complete file. This enable use cases where a file transfer can be interrupted, resumed, even perhaps changing one of the endpoints. The 'file-range' attribute contains the "start offset" and "stop offset" of the file, separated by a dash "-". The - "start offset" value refers to the position of the file where the - file transfer should start. The first byte of a file is denoted by - the ordinal number "1". The "stop offset" value refers position of - the file where the file transfer should stop. The "stop offset" - value MAY contain a "*" if the total size of the file is not known in - advance. The absence of this attribute indicates a complete file, - i.e., as if the 'file-range' attribute would have been present with a - value "1-*". The 'file-range' attribute must not be confused with - the Byte-Range header in MSRP. The former indicates the portion of a - file that the application would read and pass onto the MSRP stack for + "start offset" value refers to the octet position of the file where + the file transfer should start. The first octet of a file is denoted + by the ordinal number "1". The "stop offset" value refers to the + octet position of the file where the file transfer should stop, + inclusive of this octet. The "stop offset" value MAY contain a "*" + if the total size of the file is not known in advance. The absence + of this attribute indicates a complete file, i.e., as if the 'file- + range' attribute would have been present with a value "1-*". The + 'file-range' attribute must not be confused with the Byte-Range + header in MSRP. The former indicates the portion of a file that the + application would read and pass onto the MSRP stack for transportation. From the point of view of MSRP, the portion of the file is viewed as a whole message. The latter indicates the number of bytes of that message that are carried in a chunk and the total size of the message. Therefore, MSRP starts counting the delivered - message at byte number 1, independently of position of that byte in + message at octet number 1, independently of position of that octet in the file. The following is an example of an SDP body that contains the extensions defined in this memo: v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 @@ -607,42 +608,172 @@ transmit a file to the answerer. Consequently the answerer is the file receiver. In this case the SDP offer contains a 'sendonly' attribute, and accordingly the SDP answer contains a 'recvonly' attribute. 2. The offerer is the file receiver, i.e., the offerer wants to fetch a file from the answerer. Consequently the answerer is the file sender. In this case the SDP offer contains a session or media 'recvonly' attribute, and accordingly the SDP answer contains a session or media 'sendonly' attribute. -8.1. Offerer's Behavior +8.1. The 'file-transfer-id' attribute + + This specification creates an extension to the SDP Offer/Answer Model + [RFC3264], and because of that, it is assumed that the existing SDP + behavior is kept intact. The SDP behavior requires, for example, + that SDP is sent again to the remote party in situations where the + media description or perhaps other SDP parameters have not changed + with respect a previous offer/answer exchange. Let's consider the + SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITE requests + to refresh sessions. RFC 4028 recommends to send unmodified SDP in a + re-INVITE to refresh the session. Should this re-INVITE contain SDP + describing a file transfer operation and occur while the file + transfer was still going on, there would be no means to detect + whether the SDP creator wanted to abort the current file transfer + operation and initiate a new one or the SDP file description was + included in the SDP due to other reasons (e.g., session timer + refresh). + + A similar scenario occurs when two endpoints have successfully agreed + on a file transfer, which is currently taking place when one of the + endpoints wants to add additional media streams to the existing + session. In this case, the endpoint sends a re-INVITE request that + contains SDP. The SDP needs to maintain the media descriptions for + the current ongoing file transfer and add the new media descriptions. + The problem is that, the other endpoint is not able to determine if a + new file transfer is requested or not. + + In other cases, a file transfer was successfully completed. Then, if + an endpoint re-sends the SDP offer with the media stream for the file + transfer, then the other endpoint wouldn't be able to determine + whether a new file transfer should start or not. + + To address these scenarios this specification defines the 'file- + transfer-id' attribute which contains a globally unique random + identifier allocated to the file transfer operation. The file + transfer identifier helps both endpoints to determine whether the SDP + offer is requesting a new file transfer or it is a repetition of the + SDP. A new file transfer is one that, in case of acceptance, will + provoke the actual transfer of a file. This is typically the case of + new offer/answer exchanges, or in cases where an endpoint wants to + abort the existing file transfer and re-start the file transfer once + more. On the other hand, the repetition of the SDP does not lead to + any actual file to be transferred, potentially because the file + transfer is still going on or because it has already finished. This + is the case of repeated offer/answer exchanges, which can be due to a + number of reasons (session timer, addition/removal of other media + types in the SDP, update in SDP due to changes in other session + parameters, etc.). + + Implementations according to this specification MUST include a 'file- + transfer-id' attribute in SDP offers and answers. The SDP offerer + MUST select a file transfer identifier according to the syntax and + add it to the 'file-transfer-id' attribute. The SDP answerer MUST + copy the value of the 'file-transfer-id' attribute in the SDP answer. + + The file transfer identifier MUST be unique within the current + session (never used before in this session), and it is RECOMMENDED to + be unique across different sessions. It is RECOMMENDED to select a + relatively big random identifier (e.g., 32 characters) to avoid + duplications. The SDP answerer MUST keep track of the proposed file + transfer identifiers in each session and copy the value of the + received file transfer identifier in the SDP answer. + + If a file transfer is suspended and resumed at a later time, the + resumption is considered a new file transfer (even when the file to + be transferred is the same), therefore, the SDP offerer MUST choose a + new file transfer identifier. + + If an endpoint sets the port number to zero in the media description + of a file transfer, for example because it wants to reject the file + transfer operation, then the SDP answer MUST mirror the value of the + 'file-transfer-id' attribute included in the SDP offer. This + effectively means that setting a media stream to zero has higher + precedence than any value that the 'file-transfer-id' attribute can + take. + + As a side effect, the 'file-transfer-id' attribute can be used for + aborting and restarting again an ongoing file transfer. Assume that + two endpoints agree on a file transfer and the actual transfer of the + file is taking place. At some point in time in the middle of the + file transfer, one endpoint sends a new SDP offer, equal to the + initial one except for the value of the 'file-transfer-id' attribute, + which is a new globally unique random value. This indicates that the + offerer wants to abort the existing transfer and start a new one, + according to the SDP parameters. The SDP answerer SHOULD abort the + ongoing file transfer, according to the procedures of the file + transfer protocol (e.g., MSRP), and start sending file once more from + the initial requested octet. Section 8.4 further discusses file + transfer abortion. + + If an endpoint creates an SDP offer where the 'file-transfer-id' + attribute value does not change with respect a previously sent one, + but the file selector changes so that a new file is selected, then + this is considered and error, and the SDP answerer MUST abort the + file transfer operation (e.g., by setting the port number to zero in + the SDP answer). Note that endpoints MAY change the 'file-selector' + attribute as long as the selected file does not change (e.g., by + adding a hash selector), however it is RECOMMENDED that endpoints do + not change the value of the 'file-selector' attribute if it is + requested to transfer the same file described in a previous SDP + offer/answer exchange. + + Figure 3 summarizes the relation of the 'file-transfer-id' attribute + with the file selector in subsequent SDP exchanges. + + \ | | | + \ file selector | different | same | + 'file-transfer-id' \ | file | file | + ==================================+=============+===============+ + | new file | new file | + changed | transfer | transfer | + | operation | operation | + ----------------------------------+-------------+---------------+ + | | existing file | + unchanged | error | transfer | + | | operation | + ----------------------------------+-------------+---------------+ + + Figure 3: Relation of the 'file-transfer-id' attribute with the + selector of the file in a subsequent SDP exchange + + In another scenario, an endpoint that has successfully transferred a + file wants to send an SDP due to other reasons than the transfer of a + file. The SDP offerer creates an SDP file description that maintains + the media description line corresponding to the file transfer. The + SDP offerer MUST then set the port number to zero and MUST keep the + same value of the 'file-transfer-id' attribute that the initial file + transfer got. + +8.2. Offerer's Behavior An offerer who wishes to send or receive one or more files to or from an answerer MUST build an SDP [RFC4566] description of a session containing one "m=" line per file. When MSRP is used as the transfer mechanism, each "m=" line also describes a single MSRP session, according to the MSRP [RFC4975] procedures. Any "m=" lines that may have already been present in a previous SDP exchange are normally kept unmodified; the new "m=" lines are added afterwards (Section 8.6 describes cases when "m=" lines are re-used). All the media line attributes specified and required by MSRP [RFC4975] (e.g., "a=path", "a=accept-types", etc.) MUST be included as well. -8.1.1. The Offerer is a File Sender +8.2.1. The Offerer is a File Sender In a push operation, the file sender creates and SDP offer describing the file to be sent. The file sender MUST add a 'file-selector' attribute media line containing at least one of the 'type', 'size', 'hash' selectors in indicating the type, size, or hash of the file, respectively. If the file sender wishes to start a new file transfer, the file sender MUST add a 'file-transfer-id' attribute containing a new globally unique random identifier value. + Additionally, the file sender MUST add a session or media 'sendonly' attribute to the SDP offer. Then the file sender sends the SDP offer to the file receiver. Not all the selectors in the 'file-selector' attribute might be known when the file sender creates the SDP offer, for example, because the host is still processing the file. The 'hash' selector in the 'file-selector' attribute contains valuable information to the file receiver to identify whether the @@ -655,27 +786,26 @@ example: the file sender would like the file receiver to render the file or not). The three date attributes provide the answerer with an indication of the age of the file. The file sender MAY also add a 'file-range' attribute indicating the start and stop offsets of the file. When the file sender receives the SDP answer, if the port number of the answer for a file request is non-zero, the file sender starts the transfer of the file according to the negotiated parameters in SDP. -8.1.2. The Offerer is a File Receiver +8.2.2. The Offerer is a File Receiver In a pull operation, the file receiver creates the SDP offer and sends it to the file sender. The file receiver MUST include a 'file- selector' attribute and SHOULD add, at least, one of the selector defined for that attribute (i.e., 'name', 'type', 'size', or 'hash'). - In many cases, if the hash of the file is known, that is enough to identify the file, therefore, the offerer can include only a 'hash' selector. However, specially in cases where the hash of the file is unknown, the file name, size, and type can provide a description of the file to be fetched. If the file receiver wishes to start a new file transfer it MUST add a 'file-transfer-id' attribute containing a new globally unique random value. The file receiver MAY also add a 'file-range' attribute indicating the start and stop offsets of the file. There is no need to for the file receiver to include further file attributes in the SDP offer, thus it is RECOMMENDED that SDP @@ -689,50 +819,50 @@ the answer for a file request is non-zero, then the file receiver should receive the file using the protocol indicated in the "m=" line. If the SDP answer contains a supported hashing algorithm in the 'hash' selectors of the 'file-selector' attribute, then the file receiver SHOULD compute the hash of the file after its reception and check it against the hash received in the answer. In case the computed hash does not match the one contained in the SDP answer, the file receiver SHOULD consider that the file transfer failed and SHOULD inform the user. -8.1.3. SDP Offer for Several Files +8.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 along with the file attributes described in this specification. This way, the answerer can reject individual files by setting the port number of their associated "m=" lines to zero, as per regular SDP [RFC4566] procedures. Similarly, the answerer can accept each individual file separately by setting the port number of their associated "m=" lines to non-zero value. Each file has its own file transfer identifier, which uniquely identifies each file transfer. Using an "m=" line per file implies that different files are transferred using different MSRP sessions. However, all those MSRP sessions can be set up to run over a single TCP connection, as described in Section 8.1 of RFC 4975 [RFC4975]. The same TCP connection can also be re-used for sequential file transfers. -8.2. Answerer's Behavior +8.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 [RFC4566] procedures. The rejected answer MUST contained a 'file-selector' and 'file-transfer-id' attributes whose values mirror the corresponding values of the SDP offer. If the answerer decides to accept the file, it proceeds as per regular MSRP [RFC4975] and SDP [RFC4566] procedures. -8.2.1. The Answerer is a File Receiver +8.3.1. The Answerer is a File Receiver In a push operation the SDP answerer is the file receiver. When the file receiver gets the SDP offer, it first examines the port number. If the port number is set to zero, the file transfer operation is closed, and no more data is expected over the media stream. Then, if the port number is different than zero, the file receiver inspects the 'file-transfer-id' attribute. If the value of the 'file- transfer-id' attribute has been previously used then the existing session remains without changes, perhaps the file transfer is still in progress, or perhaps it has concluded, but there are no change @@ -756,27 +886,27 @@ 'file-icon', 'file-disposition', or 'file-date' attributes in the SDP answer. The file receiver can use the hash to find out if a local file with the same hash is already available, in which case, this could imply the reception of a duplicated file. It is up to the answerer to determine whether the file transfer is accepted or not in case of a duplicated file. If the SDP offer contains a 'file-range' attribute and the file - receiver accepts to receive the range of bytes declared in there, the - file receiver MUST include a 'file-range' attribute in the SDP answer - with the same range of values. If the file receiver does not accept - the reception of that range of bytes, it SHOULD reject the transfer - of the file. + receiver accepts to receive the range of octets declared in there, + the file receiver MUST include a 'file-range' attribute in the SDP + answer with the same range of values. If the file receiver does not + accept the reception of that range of octets, it SHOULD reject the + transfer of the file. -8.2.2. The Answerer is a File Sender +8.3.2. The Answerer is a File Sender In a pull operation the answerer is the file sender. In this case, the SDP answerer MUST first inspect the value of the 'file-transfer-id' attribute. If it has not been previously been used throughout the session, then acceptance of the file MUST provoke the transfer of the file over the negotiated protocol. However, if the value has been previously used by another file transfer operation within the session, then the file sender MUST NOT alert the user and MUST NOT start a new transfer of the file. No matter whether an actual file transfer is initiated or not, the file sender MUST create @@ -829,152 +959,65 @@ choose one of them to be defined in the SDP answer. If that choice cannot be done, the answerer SHOULD reject the MSRP media stream for file transfer (by setting the port number to zero). If the need arises, future specifications can provide a suitable mechanism that allows to either select multiple files or, e.g., resolve ambiguities by returning a list of files that match the file selector. If the SDP offer contains a 'file-range' attribute and the file - sender accepts to send the range of bytes declared in there, the file - sender MUST include a 'file-range' attribute in the SDP answer with - the same range of values. If the file sender does not accept sending - that range of bytes, it SHOULD reject the transfer of the file. - -8.3. The 'file-transfer-id' attribute - - This specification creates an extension to the SDP Offer/Answer Model - [RFC3264], and because of that, it is assumed that the existing SDP - behavior is kept intact. The SDP behavior requires, for example, - that SDP is sent again to the remote party in situations where the - media description or perhaps other SDP parameters have not changed - with respect a previous offer/answer exchange. Let's consider the - SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITE requests - to refresh sessions. RFC 4028 recommends to send unmodified SDP in a - re-INVITE to refresh the session. Should this re-INVITE contain SDP - describing a file transfer operation and occur while the file - transfer was still going on, there would be no means to detect - whether the SDP creator wanted to abort the current file transfer - operation and initiate a new one or the SDP file description was - included in the SDP due to other reasons (e.g., session timer - refresh). - - A similar scenario occurs when two endpoints have successfully agreed - on a file transfer, which is currently taking place when one of the - endpoints wants to add additional media streams to the existing - session. In this case, the endpoint sends a re-INVITE request that - contains SDP. The SDP needs to maintain the media descriptions for - the current ongoing file transfer and add the new media descriptions. - The problem is that, the other endpoint is not able to determine if a - new file transfer is requested or not. - - In other cases, a file transfer was successfully completed. Then, if - an endpoint re-sends the SDP offer with the media stream for the file - transfer, then the other endpoint wouldn't be able to determine - whether a new file transfer should start or not. - - To address these scenarios this specification defines the 'file- - transfer-id' attribute which contains a globally unique random - identifier allocated to the file transfer operation. The file - transfer identifier helps both endpoints to determine whether the SDP - offer is requesting a new file transfer or it is a repetition of the - SDP. A new file transfer is one that, in case of acceptance, will - provoke the actual transfer of a file. This is typically the case of - new offer/answer exchanges, or in cases where an endpoint wants to - abort the existing file transfer and re-start the file transfer once - more. On the other hand, the repetition of the SDP does not lead to - any actual file to be transferred, potentially because the file - transfer is still going on or because it has already finished. This - is the case of repeated offer/answer exchanges, which can be due to a - number of reasons (session timer, addition/removal of other media - types in the SDP, update in SDP due to changes in other session - parameters, etc.). - - Implementations according to this specification MUST include a 'file- - transfer-id' attribute in SDP offers and answers. The SDP offerer - MUST select a file transfer identifier according to the syntax and - add it to the 'file-transfer-id' attribute. The SDP answerer MUST - copy the value of the 'file-transfer-id' attribute in the SDP answer. - - The file transfer identifier MUST be unique within the current - session (never used before in this session), and it is RECOMMENDED to - be unique across different sessions. It is RECOMMENDED to select a - relatively big random identifier (e.g., 32 characters) to avoid - duplications. The SDP answerer MUST keep track of the proposed file - transfer identifiers in each session and copy the value of the - received file transfer identifier in the SDP answer. - - If a file transfer is suspended and resumed at a later time, the - resumption is considered a new file transfer (even when the file to - be transferred is the same), therefore, the SDP offerer MUST choose a - new file transfer identifier. - - If an endpoint sets the port number to zero in the media description - of a file transfer, for example because it wants to reject the file - transfer operation, then the SDP answer MUST mirror the value of the - 'file-transfer-id' attribute included in the SDP offer. This - effectively means that setting a media stream to zero has higher - precedence than any value that the 'file-transfer-id' attribute can - take. - - As a side effect, the 'file-transfer-id' attribute can be used for - aborting and restarting again an ongoing file transfer. Assume that - two endpoints agree on a file transfer and the actual transfer of the - file is taking place. At some point in time in the middle of the - file transfer, one endpoint sends a new SDP offer, equal to the - initial one except for the value of the 'file-transfer-id' attribute, - which is a new globally unique random value. This indicates that the - offerer wants to abort the existing transfer and start a new one, - according to the SDP parameters. The SDP answerer SHOULD abort the - ongoing file transfer, according to the procedures of the file - transfer protocol (e.g., MSRP), and start sending file once more from - the initial requested octet. Section 8.4 further discusses file - transfer abortion. - - In another scenario, an endpoint that has successfully transferred a - file wants to send an SDP due to other reasons than the transfer of a - file. The SDP offerer creates an SDP file description that maintains - the media description line corresponding to the file transfer. The - SDP offerer MUST then set the port number to zero and MUST keep the - same value of the 'file-transfer-id' attribute that the initial file - transfer got. + sender accepts to send the range of octets 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 octets, it SHOULD reject the transfer of the + file. 8.4. Aborting an ongoing file transfer operation Either the file sender or the file receiver can abort an ongoing file transfer at any time. Unless otherwise noted, the entity that aborts an ongoing file transfer operation MUST follow the procedures at the media level (e.g., MSRP) and at the signaling level (SDP Offer/ answer), as described below. - Assume the scenario depicted in Figure 3 where a file sender wishes + Assume the scenario depicted in Figure 4 where a file sender wishes to abort an ongoing file transfer without initiating an alternative file transfer. Assume that an ongoing MSRP SEND request is being transmitted. The file sender aborts the MSRP message by including the '#' character in the continuation field of the end-line of a SEND request, according to the MSRP procedures (see Section 7.1 of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP message, aborting the MSRP message effectively aborts the file transfer. The file receiver acknowledges the MSRP SEND request with a 200 response. Then the file sender SHOULD close the MSRP session by creating a new SDP offer that sets the port number to zero in the related "m=" line that describes the file transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer MUST conform with the requirements of - Section 8.1.1. The 'file-transfer-id' attribute MUST be the same + Section 8.2.1. The 'file-transfer-id' attribute MUST be the same that identifies the ongoing transfer. Then the file sender sends this SDP offer to the file receiver. + Rather than close the MSRP session by setting the port number to + zero in the related "m=" line, the file sender could also tear + down the whole session, e.g., by sending a SIP BYE request. + + Note that it is responsibility of the file sender to tear down the + MSRP session. Implementations should be prepared for misbehaviors + and implement measures to avoid hang states. For example, upon + expiration of a timer the file receiver can close the aborted MSRP + session by using regular MSRP procedures. + A file receiver that receives the above SDP offer creates an SDP answer according to the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This SDP answer MUST conform with the requirements of - Section 8.2.1. Then the file receiver sends this SDP answer to the + Section 8.3.1. Then the file receiver sends this SDP answer to the file sender. File sender File receiver | | |\ | | \ | | \ | | \ | | \ | | \ | @@ -983,34 +1026,34 @@ | MSRP 200 | |<-----------------------| | re-INVITE (SDP offer) | |----------------------->| | SIP 200 OK (SDP answer)| |<-----------------------| | SIP ACK | |----------------------->| | | - Figure 3: File sender aborts an ongoing file transfer + Figure 4: File sender aborts an ongoing file transfer When the file receiver wants to abort the file transfer, there are two possible scenarios, depending on the value of the Failure-Report header in the ongoing MSRP SEND request. Assume now the scenario - depicted in Figure 4 where the MSRP SEND request includes a Failure- + depicted in Figure 5 where the MSRP SEND request includes a Failure- Report header set to a value different than "no". When the file receiver wishes to abort the ongoing file transfer, the file receiver generates an MSRP 413 response to the current MSRP SEND request (see Section 10.5 of RFC 4975 [RFC4975]). Then the file receiver MUST close the MSRP session by generating a new SDP offer that sets the port number to zero in the related "m=" line that describes the file transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer - MUST conform with the requirements expressed in Section 8.1.2. The + MUST conform with the requirements expressed in Section 8.2.2. The 'file-transfer-id' attribute MUST be the same that identifies the ongoing transfer. Then the file receiver sends this SDP offer to the file sender. File sender File receiver | | |\ | | \ MSRP SEND | | \ Failure-Report: yes | | \ | @@ -1024,31 +1067,31 @@ | \ (#) | | +----------->| | re-INVITE (SDP offer) | |<-----------------------| | SIP 200 OK (SDP answer)| |----------------------->| | SIP ACK | |<-----------------------| | | - Figure 4: File receiver aborts an ongoing file transfer. Failure- + Figure 5: File receiver aborts an ongoing file transfer. Failure- Report set to a value different than "no" in MSRP - In another scenario, depicted in Figure 5, an ongoing file transfer + In another scenario, depicted in Figure 6, an ongoing file transfer is taking place, where the MSRP SEND request contains a Failure- Report header set to the value "no". When the file receiver wants to abort the ongoing transfer, it MUST close MSRP session by generating a new SDP offer that sets the port number to zero in the related "m=" line that describes the file transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer MUST conform with the requirements - expressed in Section 8.1.2. The 'file-transfer-id' attribute MUST be + expressed in Section 8.2.2. The 'file-transfer-id' attribute MUST be the same that identifies the ongoing transfer. Then the file receiver sends this SDP offer to the file sender. File sender File receiver | | |\ | | \ MSRP SEND | | \ Failure-Report: no | | \ | | \ | @@ -1061,33 +1104,33 @@ | \ (#) | | +----------->| | MSRP 200 | |<-----------------------| | SIP 200 OK (SDP answer)| |----------------------->| | SIP ACK | |<-----------------------| | | - Figure 5: File receiver aborts an ongoing file transfer. Failure- + Figure 6: File receiver aborts an ongoing file transfer. Failure- Report set to "no" in MSRP A file sender that receives an SDP offer setting the port number to zero in the related "m=" line for file transfer, first, if an ongoing MSRP SEND request is being transmitted, it aborts the MSRP message by including the '#' character in the continuation field of the end-line of a SEND request, according to the MSRP procedures (see Section 7.1 of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP message, aborting the MSRP message effectively aborts the file transfer. Then the file sender creates an SDP answer according to the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This - SDP answer MUST conform with the requirements of Section 8.2.2. Then + SDP answer MUST conform with the requirements of Section 8.3.2. Then the file sender sends this SDP answer to the file receiver. 8.5. Indicating File Transfer Offer/Answer Capability The SDP Offer/Answer Model [RFC3264] provides provisions for indicating a capability to another endpoint (see Section 9 of RFC 3264 [RFC3264]). The mechanism assumes a high-level protocol, such as SIP [RFC3261], that provides a capability query (such as a SIP OPTIONS request). RFC 3264 [RFC3264] indicates how to build the SDP that is included in the response to such capability query. As such, @@ -1109,29 +1152,29 @@ [RFC3264], in particular those defined in Section 8.3, MUST apply for file transfer operations. An endpoint that wants to re-use an existing "m=" line to start the file transfer of another file creates a different 'file-selector' attribute and selects a new globally unique random value of the 'file-transfer-id' attribute. If the file offerer re-sends an SDP offer with a port different than zero, then the 'file-transfer-id' attribute determines whether a new file transfer will start or whether the file transfer does not need to start. If the SDP answerer accepts the SDP, then file transfer - starts from the indicated byte (if a 'file-range' attribute is + starts from the indicated octet (if a 'file-range' attribute is present). 8.7. MSRP Usage The file transfer service specified in this document uses "m=" lines in SDP 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 + in Section 8.2 and Section 8.3 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. File transfer may be accomplished using a new multimedia session established for the purpose. Alternatively a file transfer may be conducted within an existing multimedia session, without regard for the media in use within that session. Of particular note, file transfer may be done within a multimedia session containing an MSRP session used for regular instant messaging. If file transfer is @@ -1158,31 +1201,32 @@ The MSRP specification [RFC4975] defines a 'max-size' SDP attribute. This attribute specifies the maximum number of octets of an MSRP message that the creator of the SDP is willing to receive (notice once more the definition of "MSRP message"). File receivers MAY add a 'max-size' attribute to the MSRP "m=" line that specifies the file, indicating the maximum number of octets of an MSRP message. File senders MUST NOT exceed the 'max-size' limit for any message sent in the resulting session. In the absence of a 'file-range' attribute in the SDP, the MSRP file - transfer 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' + transfer MUST start with the first octet of the file and end with the + last octet (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 offset - bytes). Then the file sender application MAY wrap those bytes in an - appropriate wrapper. MSRP mandates implementations to implement the - message/cpim wrapper [RFC3862]. Usage of a wrapper is negotiated in - the SDP (see Section 8.6 in RFC 4975 [RFC4975]). Last, the file - sender application delivers the content (e.g., the message/cpim body) - to MSRP for transportation. MSRP will consider the delivered content - as a whole message, and will start numbering bytes with the number 1. + the indicated range of octets from the file (start and stop offset + octets, both inclusive). Then the file sender application MAY wrap + those octets in an appropriate wrapper. MSRP mandates + implementations to implement the message/cpim wrapper [RFC3862]. + Usage of a wrapper is negotiated in the SDP (see Section 8.6 in RFC + 4975 [RFC4975]). Last, the file sender application delivers the + content (e.g., the message/cpim body) to MSRP for transportation. + MSRP will consider the delivered content as a whole message, and will + start numbering bytes with the 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 'attachment' as indicated in Section 7. Once the file transfer is completed, the file sender SHOULD close the MSRP session and MUST behave according to the MSRP [RFC4975] procedures with respect to closing MSRP sessions. Note that MSRP session management is not related to TCP connection management. As a @@ -1212,38 +1256,38 @@ that includes an SDP body part and an icon body part. The file receiver, not supporting multipart MIME types, will reject the SDP offer via a higher protocol mechanism (e.g., SIP). In this case, it is RECOMMENDED that the file sender removes the icon body part, creates a single SDP body (i.e., without multipart MIME) and re-sends the SDP offer again. This provides some backwards compatibility with file receives that do not implement this specification and increases the chances of getting the SDP accepted at the file receiver. Since the icon is sent as part of the signaling, it is RECOMMENDED to - keep the size of icons restricted to the minimum number of bytes that - provide significance. + keep the size of icons restricted to the minimum number of octets + that provide significance. 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. 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 6. + sequence flow is shown in Figure 7. Alice's UAC Bob's UAS | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | | @@ -1256,21 +1300,21 @@ |(7) (MSRP) 200 OK | |<-----------------------| | | |(8) (SIP) BYE | |----------------------->| |(9) (SIP) 200 OK | |<-----------------------| | | | | - Figure 6: Flow diagram of an offerer sending a file to an answerer + 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. INVITE sip:bob@example.com SIP/2.0 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 1 INVITE Max-Forwards: 70 @@ -1307,21 +1351,21 @@ Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Length: [length of image] Content-Disposition: icon [...small preview icon of the file...] --boundary71-- - Figure 7: INVITE request containing an SDP offer for file transfer + Figure 8: INVITE request containing an SDP offer for file transfer NOTE: The Content-Type header field and the 'file-selector' attribute in the above figure are split in several lines for formatting purposes. Real implementations will encode it in a single line. 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 @@ -1335,21 +1379,21 @@ 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 8: SDP answer accepting the SDP offer for file transfer + 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. MSRP d93kswow SEND To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp @@ -1362,78 +1406,79 @@ From: Alice 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 9: MSRP SEND request containing the first chunk of actual file + 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 10: MSRP SEND request containing the second chunk of actual + 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 11: MSRP 200 OK response + Figure 12: 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 12: MSRP 200 OK response + 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 re-uses the existing SDP media line with different attributes and updates the description of the new file she wants to send to Bob's User Agent Server (UAS). In particular, Alice creates a new file transfer identifier since this is a new file transfer - operation. Figure 13 shows the sequence flow. + operation. Figure 14 shows the sequence flow. Alice's UAC Bob's UAS | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | | @@ -1454,21 +1499,21 @@ |(10) (MSRP) 200 OK | |<-----------------------| | | |(11) (SIP) BYE | |<-----------------------| |(12) (SIP) 200 OK | |----------------------->| | | | | - Figure 13: Flow diagram of an offerer requesting a file from the + 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. INVITE sip:bob@example.com SIP/2.0 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 @@ -1486,21 +1531,21 @@ 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 14: INVITE request containing an SDP offer for file transfer + 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 @@ -1513,21 +1558,21 @@ 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 15: SDP answer accepting the SDP offer for file transfer + 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 @@ -1542,31 +1587,31 @@ 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 16: MSRP SEND request containing the actual file + Figure 17: MSRP SEND request containing the actual file F5: Alice acknowledges the reception of the SEND request. MSRP d93kswow 200 OK To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp Byte-Range: 1-2027/2027 -------d93kswow$ - Figure 17: MSRP 200 OK response + Figure 18: MSRP 200 OK response F6: Alice re-uses the existing SDP media line inserting the description of the file to be sent and attaches it to a SIP re-INVITE request addressed to Bob. Alice reuses the TCP port number for the MSRP stream, but changes the MSRP session and the 'file-transfer-id' value according to this specification. INVITE sip:bob@example.com SIP/2.0 To: Bob ;tag=1928323431 From: Alice ;tag=1928301774 @@ -1606,21 +1651,21 @@ Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Length: [length of image] Content-Disposition: icon [..small preview icon...] --boundary71-- - Figure 18: Reuse of the SDP in a second file transfer + Figure 19: Reuse of the SDP in a second file transfer NOTE: The Content-Type header field and the 'file-selector' attribute in the above figure are split in several lines for formatting purposes. Real implementations will encode it in a single line. F7: 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. @@ -1634,21 +1679,21 @@ 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 19: SDP answer accepting the SDP offer for file transfer + 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 re-uses that TCP connection to send an MSRP SEND request that contains the file. MSRP d95ksxox SEND @@ -1662,72 +1707,72 @@ From: Alice 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 20: MSRP SEND request containing the actual file + 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 21: MSRP 200 OK response + 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 23. The SDP indicates support for CPIM messages that + 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. Alice's UAC Bob's UAS | | |(1) (SIP) OPTIONS | |----------------------->| |(2) (SIP) 200 OK | | with SDP | |<-----------------------| | | | | - Figure 22: Flow diagram of a capability request + 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 23: SDP of the 200 (OK) response to an OPTIONS request + 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 @@ -1745,24 +1790,24 @@ 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 measurements 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 + 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. @@ -1780,89 +1825,89 @@ This memo provides instructions to IANA to register a number of media level only attributes in the Session Description Protocol Parameters registry [4]. The registration data, according to RFC 4566 [RFC4566] follows. Note to the RFC Editor: replace "RFC XXXX" with the RFC number of this specification. 11.1.1. Registration of the file-selector attribute - Contact: Miguel Garcia - Phone: +358 71400 4000 + Contact: Miguel Garcia + 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 identify a file by indicating a combination of the 4-tuple composed of the name, size, type, and hash of the file. Specification: RFC XXXX 11.1.2. Registration of the file-transfer-id attribute - Contact: Miguel Garcia - Phone: +358 71400 4000 + Contact: Miguel Garcia + 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 XXXX 11.1.3. Registration of the file-disposition attribute - Contact: Miguel Garcia - Phone: +358 71400 4000 + Contact: Miguel Garcia + Phone: +34 91 339 1000 Attribute name: file-disposition Long-form attribute name: File Disposition Type of attribute: media level only This attribute is not subject to the charset attribute Description: This attribute provides a suggestion to the other endpoint about the intended disposition of the file Specification: RFC XXXX 11.1.4. Registration of the file-date attribute - Contact: Miguel Garcia - Phone: +358 71400 4000 + Contact: Miguel Garcia + 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 at which the file was created, modified, or last read. Specification: RFC XXXX 11.1.5. Registration of the file-icon attribute - Contact: Miguel Garcia - Phone: +358 71400 4000 + Contact: Miguel Garcia + 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 XXXX 11.1.6. Registration of the file-range attribute - Contact: Miguel Garcia - Phone: +358 71400 4000 + Contact: Miguel Garcia + 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: it contains the range of transferred bytes of the + Description: it contains the range of transferred octets of the file Specification: RFC XXXX 12. Acknowledgements The authors would like to thank Mats Stille, Nancy Greene, Adamu Haruna, and Arto Leppisaari for discussing initial concepts described in this memo. Thanks to Pekka Kuure for reviewing initial versions this document and providing helpful comments. Joerg Ott, Jiwey Wang, Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- @@ -1884,23 +1929,20 @@ [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. - [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, - April 2001. - [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. @@ -1913,42 +1955,46 @@ [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. Informational References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007. [I-D.ietf-rmt-flute-revised] - Paila, T., "FLUTE - File Delivery over Unidirectional - Transport", draft-ietf-rmt-flute-revised-05 (work in - progress), October 2007. + Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE - + File Delivery over Unidirectional Transport", + draft-ietf-rmt-flute-revised-06 (work in progress), + September 2008. URIs [1] [2] [3] [4] @@ -2020,27 +2066,26 @@ 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. Authors' Addresses Miguel A. Garcia-Martin - Nokia Siemens Networks - P.O.Box 6 - Nokia Siemens Networks, FIN 02022 - Finland + Ericsson + Calle Via de los Poblados 13 + Madrid, ES 28033 + Spain - Phone: +358-71400-4000 - Email: miguel.garcia@nsn.com + Email: miguel.a.garcia@ericsson.com Markus Isomaki Nokia Keilalahdentie 2-4 Espoo 02150 Finland Email: markus.isomaki@nokia.com Gonzalo Camarillo