MMUSIC Working Group M. Garcia-Martin Internet-Draft Nokia Siemens Networks Intended status: Standards Track M. Isomaki Expires: December 7, 2007 Nokia G. Camarillo S. Loreto Ericsson June 5, 2007 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer draft-ietf-mmusic-file-transfer-mech-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 7, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is Garcia-Martin, et al. Expires December 7, 2007 [Page 1] Internet-Draft SDP offer/answer for file transfer June 2007 extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. Garcia-Martin, et al. Expires December 7, 2007 [Page 2] Internet-Draft SDP offer/answer for file transfer June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Alternatives Considered . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 14 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 16 8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 16 8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 17 8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 18 8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 18 8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 18 8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 19 8.3. The 'file-transfer' attribute . . . . . . . . . . . . . . 20 8.4. Indicating File Transfer Offer/Answer Capability . . . . . 22 8.5. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 22 8.6. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23 8.7. Considerations about the 'file-icon' attribute . . . . . . 24 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 25 9.2. Offerer requests a file from the Answerer and second file transfer . . . . . . . . . . . . . . . . . . . . . . 29 9.3. Example of a capability indication . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11.1. Registration of new SDP attributes . . . . . . . . . . . . 38 11.1.1. Registration of the file-selector attribute . . . . . 38 11.1.2. Registration of the file-transfer attribute . . . . . 38 11.1.3. Registration of the file-disposition attribute . . . . 38 11.1.4. Registration of the file-date attribute . . . . . . . 39 11.1.5. Registration of the file-icon attribute . . . . . . . 39 11.1.6. Registration of the file-range attribute . . . . . . . 39 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 13.1. Normative References . . . . . . . . . . . . . . . . . . . 40 13.2. Informational References . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 43 Garcia-Martin, et al. Expires December 7, 2007 [Page 3] Internet-Draft SDP offer/answer for file transfer June 2007 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. The Message Session Relay Protocol (MSRP) [I-D.ietf-simple-message-sessions] 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) [RFC2045] compliant content, such as images or video clips. There are many cases where the endpoints involved in a multimedia session would like to exchange files within the context of that session. With MSRP it is possible to embed files as MIME objects inside the stream of instant messages. MSRP also has other features that are useful for file transfer. Message chunking enables the sharing of the same transport connection between the transfer of a large file and interactive IM exchange without blocking the IM. MSRP relays [I-D.ietf-simple-msrp-relays] provide a mechanism for Network Address Translator (NAT) traversal. Finally, Secure MIME (S/MIME) [RFC3851] can be used for ensuring the integrity and confidentiality of the transfered content. However, the baseline MSRP does not readily meet all the requirements for file transfer services within multimedia sessions. There are four main missing features: o The recipient MUST be able to distinguish "file transfer" from "file attached to IM", allowing the recipient to treat the cases differently. o It MUST be possible for the sender to send the request for a file transfer. It MUST be possible for the recipient to accept or decline it, using the meta information in the request. The actual transfer MUST take place only after acceptance by the recipient. o It MUST be possible for the sender to pass some meta information on the file before the actual transfer. This MUST be able to include at least content type, size, hash and name of the file, as well as a short (human readable) description. o It MUST be possible for the recipient to request a file from the sender, providing meta information about the file. The sender MUST be able to decide whether to send a file matching the Garcia-Martin, et al. Expires December 7, 2007 [Page 4] Internet-Draft SDP offer/answer for file transfer June 2007 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. 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.4 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) [RFC4483]. Both mechanisms allow a user agent to decide whether or not to download a file based on information about the file. However, there are some differences. With content indirection, it is not possible for the other endpoint to explicitly accpet or reject the file transfer. Also, it is not possible for an endpoint to request a file from another endpoint. Furthermore, content indirection is not tied to the context of a media session, which is sometimes a desirable property. Finally, content indirection typically requires some server infrastructure, which may not always be available. (It is possible to use content indirection directly between the endpoints too, but in that case there is no definition for how it works for endpoints behind NATs.) Based on the argumentation above, this document defines the SDP attribute extensions and usage conventions needed for meeting the requirements on file transfer services with the SDP offer/answer model, using MSRP as the transfer protocol within the session. Garcia-Martin, et al. Expires December 7, 2007 [Page 5] Internet-Draft SDP offer/answer for file transfer June 2007 In principle it is possible to use the SDP extensions defined here and replace MSRP with any other similar protocol that can carry MIME objects. This kind of specification can be written as a separate document if the need arises. This specification defines a set of SDP attributes that describe a file to be transfered between two endpoits. The information needed to describe a file could be potentially encoded in a few different ways. The MMUSIC working group considered a few alternative approaches before deciding to use the encoding described in Section 6. In particular, the working group looked at the MIME 'external-body' type and the use of a single SDP attribute or parameter. A MIME 'external-body' could potentially be used to describe the file to be transfered. In fact, many of the SDP parameters this specification defines are also supported by 'external-body' body parts. The MMUSIC working group decided not to use 'external-body' body parts because a number of existing offer/answer implementations do not support multipart bodies. The information carried in the SDP attributes defined in Section 6 could potentially be encoded in a single SDP attribute. The MMUSIC working group decided not to follow this approach because it is expected that implementations support only a subset of the parameters defined in Section 6. Those implementations will be able to use regular SDP rules in order to ignore non-supported SDP parameters. If all the information was encoded in a single SDP attribute, those rules, which relate to backwards compatibility, would need to be redefined specifically for that parameter. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Definitions For the purpose of this document, the following definitions specified in RFC 3264 [RFC3264] apply: o Answer Garcia-Martin, et al. Expires December 7, 2007 [Page 6] Internet-Draft SDP offer/answer for file transfer June 2007 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. Push operation: A file transfer operation where the SDP offerer takes the role of the file sender and the SDP answerer takes role of the file receiver. Pull operation: A file transfer operation where the SDP offerer takes the role of the file receiver and the SDP answerer takes the role of the file sender. 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) [I-D.ietf-simple-message-sessions]. Each SDP "m=" line describes an MSRP media stream used to transfer a single file. That is, the transfer of multiple simultaneous files requires multiple "m=" lines and corresponding MSRP media streams. It should be noted that multiple MSRP media streams can share a single transport layer connection, so this mechanism will not lead to excessive use of transport resources. Each "m=" line for an MSRP media stream is accompanied with a few attributes describing the file to be transferred. If the file sender generates the SDP offer, the attributes describe a local file to be sent (push), and the file receiver can use this information to either accept or reject the transfer. However, if the SDP offer is generated by the file receiver, the attributes are intended to characterize a particular file that the file receiver is willing to get (pull) from the file sender. It is possible that the file sender does not have a matching file or does not want to send the file, in which case the offer is rejected. Garcia-Martin, et al. Expires December 7, 2007 [Page 7] Internet-Draft SDP offer/answer for file transfer June 2007 The attributes describing each file are provided in SDP by a set of new SDP attributes, most of which have been directly borrowed from MIME. This way, user agents can decide whether or not to accept a given file transfer based on the file's name, size, description, hash, icon (e.g., if the file is a picture), etc. SDP direction attributes (e.g., 'sendonly', 'recvonly') are used to indicate the direction of the transfer, i.e., whether the SDP offerer is willing to send of receive the file. Assuming that the answerer accepts the file transfer, the actual transfer of the files takes place with ordinary MSRP. In principle the file transfer can work even with an endpoint supporting only regular MSRP without understanding the extensions defined herein, in a special case where that endpoint is the recipient of the file. The regular MSRP endpoint answers the offer as it would answer any ordinary MSRP offer without paying attention to the extension attributes. In such a scenario the user experience would however be reduced, as the recipient would not know (by any protocol means) the reason for the session and would not be able to accept/reject it based on the file attributes. 5. File selector Specially in case the SDP offer is generated by the file receiver, the offer needs a mechanism to unambiguously identify the requested file. For this purpose, the file transfer mechanism introduces the concept of a file selector, which is defined as the combination of the 4-tuple composed of the name, size, type, and hash of the file. We call each of these individual items a selector. The file selector can be composed of any number of selectors, so, it does not require that all four selectors are present at the same time. The purpose of the file selector is to provide enough information that characterizes a file to the remote entity, so that both the local and the remote entity can refer to the same file. The file selector is encoded in a 'file-selector' media attribute in SDP. The formal syntax of the 'file-selector' media attribute is described in Figure 1. The file selection process is applied to all the available files at the host. The process selects those file that match each of the 4-tuple selectors present in the 'file-selector' attribute. Thus, a file selector can point to zero, one, or more files, depending on the presence of the mentioned selectors in the SDP and depending on the available files in a host. The file transfer mechanism specified in Garcia-Martin, et al. Expires December 7, 2007 [Page 8] Internet-Draft SDP offer/answer for file transfer June 2007 this document requires that a file selector eventually results at most in a single file to be chosen. Typically, if the hash selector is known, it is enough to produce a file selector that points to exactly zero or one file. However, a file selector that selects a unique file is not always known by the offerer. Sometimes only the name, size or type of file are known, so the file selector may result in selecting more than one file, which is an undesired case. The opposite is also true: if the file selector contains a hash and a name selectors, there is a risk that the remote host has renamed the file, in which case, although a file whose computed hash equals the hash selector exists, the file name does not match that of the name selector, thus, the file selection process will result in the selection of zero files. Since there are several hashing algorithms, such as SHA-1 [RFC3174], SHA-256, SHA-384, SHA-512 [RFC4634], 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 hashes 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.4. 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 [RFC4234] of these new attributes. It is built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183 [RFC2183], and RFC 2392 [RFC2392]. attribute = file-selector-attr / file-disp-attr / file-date-attr / file-icon-attr / file-range-attr ;attribute is defined in RFC 4566 Garcia-Martin, et al. Expires December 7, 2007 [Page 9] Internet-Draft SDP offer/answer for file transfer June 2007 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 = 1*(%x01-09/%x0B-0C/%x0E-21/%x23-FF) ;any byte except NUL, CR, LF, or double quotes filesize-selector = "size:" filesize-value filesize-value = integer ;integer defined in RFC 4566 filetype-selector = "type:" type "/" subtype *(";"parameter) ; parameter defined in RFC 2045 type = token subtype = token hash-selector = "hash:" hash-algorithm ":" hash-value hash-algorithm = token ;see IANA Hash Function ;Textual Names registry hash-value = 2UHEX *(":" 2UHEX) ; Each byte in upper-case hex, separated ; by colons. file-transfer = "file-transfer:" file-transfer-value file-transfer-value = "new" / "existing" / token file-disp-attr = "file-disposition:" file-disp-value file-disp-value = token file-date = "file-date:" date-param *(SP date-param) date-param = c-date-param / m-date-param / r-date-param c-date-param = "creation:" DQUOTE date-time DQUOTE m-date-param = "modification:" DQUOTE date-time DQUOTE r-date-param = "read:" DQUOTE date-time DQUOTE ; date-time is defined in RFC 2822 ; numeric timezones (+HHMM or -HHMM) ; must be used ; DQUOTE defined in RFC 4234 file-icon-attr = "file-icon:" file-icon-value file-icon-value = cid-url ;cid-url defined in RFC 2392 file-range-attr = "file-range:" integer "-" integer ;integer defined in RFC 4566 Garcia-Martin, et al. Expires December 7, 2007 [Page 10] Internet-Draft SDP offer/answer for file transfer June 2007 Figure 1: Syntax of the SDP extension When used for capability query (see Section 8.4), 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 [RFC3629]. Its value SHOULD be the same as the 'filename' parameter of the Content-Disposition header field [RFC2183] that could be signalled by the actual file transfer. If a file name contains double quotes, they MUST be percent-encoded. 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 percent- encoded. 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 percent-encode 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 as the 'size' parameter of the Content-Disposition header field [RFC2183] that could be signalled by the actual file transfer. Note that the 'size' selector merely includes the file size, and does not include any potential overhead added by a wrapper, such as message/cpim. The 'type' selector in the 'file-selector' attribute contains the MIME media type of the content. In general, anything that can be expressed in a Content-Type header field (see RFC 2045 [RFC2045]) can also be expressed with the 'type' selectors. Possible MIME Media Type values are the ones listed in the IANA registry for MIME Media Types [1]. Zero or more parameters can follow. The syntax of 'parameter' is specified in RFC 2045 [RFC2045] . Garcia-Martin, et al. Expires December 7, 2007 [Page 11] Internet-Draft SDP offer/answer for file transfer June 2007 The 'hash' selector in the 'file-selector' attribute provides a hash computation of the file to be transferred. This is commonly used by file transfer protocols. For example, FLUTE [I-D.ietf-rmt-flute-revised] uses hashes (called message digests) to verify the contents of the transfer. The purpose of the 'hash' selector is two-fold: On one side, in pull operations, it allows the file receiver to identify a remote file by its hash rather than by its file name, providing that the file receiver has learned the hash of the remote file by some out-of-band mechanism. On the other side, in either push or pull operations, it allows the file sender to provide the hash of the file to be transmitted, which can be used by the file receiver for verification of its contents or to avoid the unnecessary transmission of a file that already exists. The 'file-transfer' attribute provides a mechanism for distinguishing new file transfers from existing ones. A new file transfer is one that, in case of acceptance, will provoke the transfer of a file. This is typically the case of new INVITE requests. On the contrary, an existing file transfer is one that is declared in the SDP, but does not lead to any file to be transferred, potentially because the file transfer is still going on or because it has already finished. This is the case of a re-INVITE request, 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' attribute in SDP answers and offers. The 'file- transfer' attribute can take any of two values: "new" or "existing". The "new" value indicates that a file transfer will start once the SDP negotiation is successfully concluded. The "existing" value indicates that the file transfer MUST NOT start at the end of the SDP negotiation. Section 8 and Section 8.3 provide further details. The 'hash' selector includes the hash algorithm and its value. In fact, since there are several hashing algorithms, the 'file-selector' attribute in SDP MAY contain several 'hash' selectors with different algorithms. Possible hash algorithms are those defined in the IANA registry of Hash Function Textual Names [2]. Implementations according to this specification MUST support the US Secure Hash Algorithm 1 (SHA1) [RFC3174] and MAY support other hashing algorithms. The value is the byte string resulting of applying the hash algorithm to the content of the whole file. The 'file-disposition' attribute provides a suggestion to the other endpoint about the intended disposition of the file. Section 7 provides further discussion of the possible values. The value of this attribute SHOULD be the same of the disposition type parameter of the Content-Disposition header field [RFC2183] that could be signalled by the actual file transfer protocol. Garcia-Martin, et al. Expires December 7, 2007 [Page 12] Internet-Draft SDP offer/answer for file transfer June 2007 The 'file-date' attribute indicates the dates at which the file was created, modified, or last read. This attribute MAY contain a combination of the 'creation', 'modification', and 'read' parameters. Only one parameter of each type (creation, modification, or read) MUST be present in a 'file-date' attribute. The 'creation' parameter indicates the date at which the file was created. The value MUST be a quoted string which contains a representation of the creation date of the file in RFC 2822 [RFC2822] '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 could be signalled by the actual file transfer protocol. The 'modification' parameter indicates the date at which the file was last modified. The value MUST be a quoted string which contains a representation of the last modification date to the file in RFC 2822 [RFC2822] '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 could be signalled by the actual file transfer protocol. The 'read' parameter indicates the date at which the file was last read. The value MUST be a quoted string which contains a representation of the last date the file was read in RFC 2822 [RFC2822] '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 could be signalled by the actual file transfer protocol. The 'file-icon' attribute can be useful with certain file types such as images. It allows the sender to include a pointer to a body that includes a small preview icon representing the contents of the file to be transferred. This allows the sender to include the icon as another body accompanying the SDP, and to the recipient to get the icon of the file to be transferred. The 'file-icon' attribute contains a Content-ID URL, which is specified in RFC 2392 [RFC2392]. Section 8.7 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 is composed to two integer values separated by a dash "-". The first integer value refers to the first byte of the file to be transferred. The second Garcia-Martin, et al. Expires December 7, 2007 [Page 13] Internet-Draft SDP offer/answer for file transfer June 2007 integer value refers to the last byte of the file to be transferred. The first byte of a file is indicated with "1". The absence of this attribute indicates a complete file, i.e., like if the 'file-range' attribute would have been present with values 1-. The 'file-range' attribute must not be confused with the Byte-Range header in MSRP. The former indicates the portion of a file that the application would read and pass onto the MSRP stack for transportation. From the point of view of MSRP, the portion of the file is viewed as a whole message. The latter indicates the number of bytes of that message that are carried in a chunk and the total size of the message. Therefore, MSRP starts counting the delivered message at byte number 1, independently of position of that byte in the file. The following is an example of an SDP body that contains the extensions defined in this memo: v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=message 7654 TCP/MSRP * i=This is my latest picture a=sendonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://atlanta.example.com:7654/jshA7we;tcp a=file-selector:name:"My cool picture.jpg" type:image/jpeg size:32349 hash:sha-1: 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E a=file-transfer:new a=file-disposition:not-render a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00" a=file-icon:cid:id2@alicepc.example.com a=file-range:1-32349 Figure 2: Example of SDP describing a file transfer NOTE: The 'file-selector' attribute in the above figure is split in three lines for formatting purposes. Real implementations will encode it in a single line. 7. File Disposition Types The SDP Offer/Answer for file transfer allows the file sender to indicate a preferred disposition of the file to be transferred in a Garcia-Martin, et al. Expires December 7, 2007 [Page 14] Internet-Draft SDP offer/answer for file transfer June 2007 new 'file-disposition' attribute. In principle, any value listed in the IANA registry for Mail Content Disposition Values [3] is acceptable, however, most of them may not be applicable. There are two content dispositions of interest for file transfer operations. On one hand, the file sender may just want the file to be rendered immediately in the file receiver's device. On the other hand, the file sender may just want to indicate the file recipient that the file should not be rendered at the reception of the file. The recipient's user agent may want to interact with the user regarding the file disposition or it may save the file until the user takes an action. In any case, the exact actions are implementation dependent. To indicate that a file should be automatically rendered, this memo uses the existing 'render' value of the Content Disposition type in the new 'file-disposition' attribute in SDP. To indicate that a file should not be automatically rendered, this memo users the existing 'attachment' value of the Content-Disposition type in the new 'file- disposition' attribute in SDP. The default value is 'render', i.e., the absence of a 'file-disposition' attribute in the SDP has the same semantics as 'render'. The disposition value 'attachment' is specified in RFC 2183 [RFC2183] with the following definition: "Bodyparts can be designated 'attachment' to indicate that they are separate from the main body of the mail message, and that their display should not be automatic, but contingent upon some further action of the user." In the case of this specification, the 'attachment' disposition type is used o indicate that the display of the file should not be automatic, but contingent upon some further action of the user. 8. Protocol Operation This Section discusses how to use the parameters defined in Section 6 in the context of an offer/answer [RFC3264] exchange. Additionally, this section also discusses the behavior of the endpoints using MSRP. Usually the file transfer session is initiated when the offerer sends an SDP offer to the answerer. The answerer either accepts or rejects the file transfer session and sends an SDP answer to the offerer. We can differentiate two use cases, depending on whether the offerer is the file sender or file receiver: Garcia-Martin, et al. Expires December 7, 2007 [Page 15] Internet-Draft SDP offer/answer for file transfer June 2007 1. The offerer is the file sender, i.e., the offerer wants to transmit a file to the answerer. Consequently the answerer is the file receiver. In this case the SDP offer contains a 'sendonly' attribute, and accordingly the SDP answer contains a 'recvonly' attribute. 2. The offerer is the file receiver, i.e., the offerer wants to fetch a file from the answerer. Consequently the answerer is the file sender. In this case the SDP offer contains a session or media 'recvonly' attribute, and accordingly the SDP answer contains a session or media '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 [RFC4566] 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 [I-D.ietf-simple-message-sessions] procedures. All the media line attributes specified and required by MSRP [I-D.ietf-simple-message-sessions] (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. 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 is able to compute the hash of the file with different hashing algorithms, it MAY add several 'hash' selectors, each one referring to a different hashing algorithm. The file sender MUST add a 'file-transfer' attribute with a value that indicates whether a new file transfer should start ("new" value), or whether the SDP merely indicates an existing file transfer ("existing" value), in which case a new file transfer should not start. 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. Garcia-Martin, et al. Expires December 7, 2007 [Page 16] Internet-Draft SDP offer/answer for file transfer June 2007 The 'hash' selector in the 'file-selector' attribute contains valuable information to the file receiver to identify whether the file is already available and need not be transmitted. If the sender supports several hashing algorithms, then several 'hash' selector can be included. The file sender MAY also add a 'name' selector in the 'file-selector' attribute, and a 'file-icon', 'file-disposition', and 'file-date' attributes further describing the file to be transferred. The 'file- disposition' attribute provides a presentation suggestion, (for example: the file sender would like the file receiver to render the file or not). The three date attributes provide the answerer with an indication of the age of the file. The file sender MAY also add a 'file-range' attribute indicating the start and stop offset of the file transfer. 8.1.2. The Offerer is a File Receiver In a pull operation, the file receiver creates the SDP offer and sends it to the file sender. The file receiver MUST include a 'file- selector' attribute and SHOULD add, at least, one of the selector defined for that attribute (i.e., 'name', 'type', 'size', or 'hash'). Several 'hash' selectors MAY be included if each 'hash' selector is computed with a different hashing algorithm. In many cases, if the hash of the file is known, that is enough to identify the file, therefore, the offerer can include only a 'hash' 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. The file receiver MUST also add a 'file-transfer' attribute with a value that indicates whether a new file transfer should start ("new" value), or whether the SDP merely indicates an existing file transfer ("existing" value), in which case a new file transfer should not start. There is no need to for the file offerer to include further file attributes in the SDP offer, thus it is RECOMMENDED that SDP offerers do not include any other file attribute defined by this specification (other than the mandatory ones). Additionally, the file receiver MUST create an SDP offer that contains a session or media 'recvonly' attribute. The file receiver MAY also add a 'file-range' attribute indicating the start and stop offset of the file transfer. When the file receiver receives the SDP answer, if the port number of the answer for a file request is non-zero and if the 'file-transfer' attribute is set to "new", 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 Garcia-Martin, et al. Expires December 7, 2007 [Page 17] Internet-Draft SDP offer/answer for file transfer June 2007 hash of the file after receipt and check 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 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. 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 [I-D.ietf-simple-message-sessions]. 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 [RFC4566] procedures and MUST set the 'file- transfer' attribute that mirrors the value received in the SDP offer. If the answerer decides to accept the file, it proceeds as per regular MSRP [I-D.ietf-simple-message-sessions] and SDP [RFC4566] 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 offer, 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 [RFC3264]. If the offer contains 'name', 'type', 'size' selectors in the 'file-selector' attribute, the answerer MUST copy them into the answer. If the offer contains one ore more 'hash' selectors in the 'file-selector' attribute, the answerer discards those with non- supported hashing algorithms and MUST copy the remaining (if any) to the 'file-selector' attribute of the answer. This informs the offerer that the answerer supports this specification. The file receiver then adds a 'file-transfer' attribute with an appropriate value. Then the file receiver MUST add a session or media 'recvonly' attribute according to the procedures specified in RFC 3264 [RFC3264]. The file receiver MUST NOT include 'file-icon', 'file- Garcia-Martin, et al. Expires December 7, 2007 [Page 18] Internet-Draft SDP offer/answer for file transfer June 2007 disposition', or 'file-date' attributes in the SDP answer. If the SDP offer contains one or more 'hash' selectors in the 'file- selector' attribute, the answerer discards those with unsupported hashing algorithms. The file receiver can use the remaining hashes to find out if a local file with the same hash is already available, in which case, this could imply the reception of a duplicated file. It is up to the answerer to determine whether the file transfer is accepted or not in case of a duplicated file. If the SDP offer contains a 'file-range' attribute and the file receiver accepts to receive the range of bytes declared in there, the file receiver MUST include a 'file-range' attribute in the SDP answer with the same range of values. If the file receiver does not accept the reception of that range of bytes, it SHOULD reject the transfer of the file. 8.2.2. The Answerer is a File Sender In a pull operation the answerer is a file sender. In this case, the file sender MUST first inspect the received SDP offer and apply the file selector. The file selector is encoded in the 'file-selector' media attribute line in SDP. First, if the file selector contains several hashes, the file sender MUST select one of them which contains a supported hashing algorithm and discard the rest. Then the file sender applies the file selector, which implies selecting those files that match one by one with the 'name', 'type', 'size', and 'hash' selectors of the 'file-selector' attribute line (if they are present). The file selector identifies zero or more candidate files to be sent. If the file selector is unable to identify any file, then the answerer MUST reject the MSRP stream for file transfer by setting the port number to zero, and then the file sender SHOULD also reject the SDP as per procedures in RFC 3264 [RFC3264], if this is the only stream described in the SDP offer. If the file selector points to a single file and the file sender decides to accept the file transfer, the file sender MUST create an SDP answer that contains a 'sendonly' attribute, according to the procedures described RFC 3264 [RFC3264]. The file sender SHOULD add one or more 'hash' selectors in the answer, with algorithms supported by the file sender and values locally computed by the file sender, and SHOULD include at least one with a hash algorithm selected among those present in the offer. The file sender MUST NOT include a 'hash' selector with an algorithm that was present in the offer and a value that differs from what was in the offer. If a hash value computed by the file sender differs from that specified by the file receiver, the file sender can either send the file without that hash value or reject the request by setting the port in the media stream Garcia-Martin, et al. Expires December 7, 2007 [Page 19] Internet-Draft SDP offer/answer for file transfer June 2007 to zero. The file sender MAY also include a 'type' selector in the 'file-selector' attribute line of the SDP answer. The file sender MUST add a 'file-transfer' attribute with the appropriate value. The answerer MAY also include a 'file-icon' and 'file-disposition' attributes to further describe the file. Although the answerer MAY also include a 'name' and 'size' selectors 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 [I-D.ietf-simple-message-sessions]) can accommodate a Content-Disposition header field [RFC2183] with the equivalent parameters. The whole idea of adding file descriptors to SDP is to provide a mechanism where a file transfer can be accepted prior to its start. Adding any SDP attributes that are otherwise signalled later in the file transfer protocol would just duplicate the information, but will not provide any information to the offerer to accept or reject the file transfer (note that the offerer is requesting a file). Last, if the file selector points to multiple candidate files, the answerer MAY use some local policy, e.g. consulting the user, to choose one of them to be defined in the SDP answer. If that choise cannot be done, the answere SHOULD reject the MSRP media stream for file transfer (by setting the port number to zero). If the need arises, future specifications can provide a suitable mechanism that allows to either select multiple files or, e.g., resolve ambiguities by returning a list of files that match the file selector. 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' attribute This specification creates an extension to the SDP Offer/Answer Model [RFC3264], and because of that, it is assumed that the existing SDP behaviour is kept intact. The SDP behaviour 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-INVITEs to refresh sessions. RFC 4028 recommends to send unmodified SDP in a re-INVITE to refresh the session. Should this re-INVITE contain SDP Garcia-Martin, et al. Expires December 7, 2007 [Page 20] Internet-Draft SDP offer/answer for file transfer June 2007 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' attribute, which can take any of two values: "new" or "existing". A "new" value in the 'file-transfer' attribute indicates that the endpoint wants to create a new file transfer. This is the case of initial offer/answer exchanges, or in cases where an endpoint wants to abort the existing file transfer an re-start the file transfer once more. An "existing" value in the 'file-transfer' attribute indicates that the endpoint is already involved or has concluded the actual file transfer, consequently, a new additional file transfer MUST NOT start. Endpoints MUST include a 'file-transfer' attribute in any SDP offer or answer that defines a file transfer operation, according to this specification. An SDP answer that MUST not downgrade the offered 'file-transfer' value. Table 1 shows the possible combination of 'file-transfer' values in SDP offers and answers both for pull and push file transfer operations. +----------+----------------+ | Offerer | Answerer | +----------+----------------+ | new | new | | existing | new / existing | +----------+----------------+ Table 1: 'file-transfer' attribute values Garcia-Martin, et al. Expires December 7, 2007 [Page 21] Internet-Draft SDP offer/answer for file transfer June 2007 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 should mirror the value of the 'file-transfer' 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' attribute can take. As a side effect, the 'file-transfer' 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, where the 'file-transfer' attribute is set to "new". 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. 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 that maintains the media description line corresponding to the file transfer. The SDP offerer MUST then set the port number to zero and MUST set the 'file- transfer' attribute to "existing" to indicate that the media stream is offered but must not be used. 8.4. 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 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. The endpoint MUST NOT add any of the other file attributes defined in this specification. 8.5. Re-usage of Existing m= Lines in SDP The SDP Offer/Answer Model [RFC3264] provides rules that allow SDP offerers and answerers to modify an existing media line, i.e., re-use Garcia-Martin, et al. Expires December 7, 2007 [Page 22] Internet-Draft SDP offer/answer for file transfer June 2007 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 [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 sends the 'file-transfer' to the value "new". If the file offerer re-sends an SDP offer with a port different than zero, then the 'file-transfer' 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 present). 8.6. 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 CPIM message that wraps 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. The MSRP specification [I-D.ietf-simple-message-sessions] 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. Garcia-Martin, et al. Expires December 7, 2007 [Page 23] Internet-Draft SDP offer/answer for file transfer June 2007 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 '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 [I-D.ietf-simple-message-sessions] procedures with respect closing MSRP sessions. 8.7. Considerations about the 'file-icon' attribute This specification allows a file sender to include a small preview of an image file: an icon. A 'file-icon' attribute contains a CID URL [RFC2392] that points to an additional body that contains the actual icon. Since the icon is sent as a separate body along the SDP body, the file sender has to use a MIME multipart/mixed body that contains an SDP body part and the icon body part. Therefore, implementations according to this specification MUST implement the multipart/mix MIME type [RFC2046]. However, if the file sender sends a request that contains a multipart/mix MIME body that includes an SDP body part and an icon body part, and the file receiver does not support multipart MIME types, then the file receiver will reject, via a higher protocol mechanism (e.g., SIP), the request. 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-tries the request again. This increases the chances of getting the SDP accepted at the file receiver (albeit the file receiver will not implement this specification, which mandates the implementation of multipart MIME bodies). Since the icon is sent as part of the signalling, it is recommended to keep icons restricted to the minimum number of bytes that provide significance. Garcia-Martin, et al. Expires December 7, 2007 [Page 24] Internet-Draft SDP offer/answer for file transfer June 2007 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 in the sake of brevity. Alice, the SDP offerer, wishes to send an image file to Bob (the answerer). Alice's User Agent Client (UAC) creates a unidirectional SDP offer that contains the description of the file that she wants to send to Bob's User Agent Server (UAS). The description also includes an icon representing the contents of the file to be transferred. The sequence flow is shown in Figure 3. Alice's UAC Bob's UAS | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | | |(4) (MSRP) SEND (chunk) | |----------------------->| |(5) (MSRP) SEND (chunk) | |----------------------->| |(6) (MSRP) 200 OK | |<-----------------------| |(7) (MSRP) 200 OK | |<-----------------------| | | |(8) (SIP) BYE | |----------------------->| |(9) (SIP) 200 OK | |<-----------------------| | | | | Figure 3: Flow diagram of an offerer sending a file to an answerer F1: Alice constructs an SDP description of the file to be sent and attaches it to a SIP INVITE request addressed to Bob. Garcia-Martin, et al. Expires December 7, 2007 [Page 25] Internet-Draft SDP offer/answer for file transfer June 2007 INVITE sip:bob@example.com SIP/2.0 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 1 INVITE Max-Forwards: 70 Date: Sun, 21 May 2006 13:02:03 GMT Contact: Content-Type: multipart/mixed; boundary="boundary71" Content-Length: [length] --boundary71 Content-Type: application/sdp Content-Length: [length of SDP] v=0 o=alice 2890844526 2890844526 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 7654 TCP/MSRP * i=This is my latest picture a=sendonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=file-selector:name:"My cool picture.jpg" type:image/jpeg size:4092 hash:sha-1: 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E a=file-transfer:new a=file-disposition:render a=file-date:creation:"Mon, 15 May 2006 15:01:31 +03:00" a=file-icon:cid:id2@alicepc.example.com --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Length: [length of image] Content-Disposition: icon [...small preview icon of the file...] --boundary71-- Figure 4: INVITE request containing an SDP offer for file transfer Garcia-Martin, et al. Expires December 7, 2007 [Page 26] Internet-Draft SDP offer/answer for file transfer June 2007 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. From now on we omit the SIP details for the sake of brevity. F2: Bob receives the INVITE request, inspects the SDP offer and extracts the icon body, checks the creation date and file size, and decides to accept the file transfer. So Bob creates the following SDP answer: v=0 o=bob 2890844656 2890844656 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 8888 TCP/MSRP * a=recvonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=file-selector:name:"My cool picture.jpg" type:image/jpeg size:4092 hash:sha-1: 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E a=file-transfer:new Figure 5: 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. Garcia-Martin, et al. Expires December 7, 2007 [Page 27] Internet-Draft SDP offer/answer for file transfer June 2007 MSRP d93kswow SEND To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp Message-ID: 12339sdqwer Byte-Range: 1-2048/4385 Content-Type: message/cpim To: Bob 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 +03:00"; size=4092 Content-Type: image/jpeg ... first set of bytes of the JPEG image ... -------d93kswow+ Figure 6: MSRP SEND request containing the first chunk of actual file F5: Alice sends the second and last chunk. Note that MSRP allows to send pipelined chunks, so there is no need to wait for the 200 (OK) response from the previous chunk. MSRP op2nc9a SEND To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp Message-ID: 12339sdqwer Byte-Range: 2049-4385/4385 Content-Type: message/cpim ... second set of bytes of the JPEG image ... -------op2nc9a$ Figure 7: MSRP SEND request containing the second chunk of actual file F6: Bob acknowledges the reception of the first chunk. MSRP d93kswow 200 OK To-Path: msrp://alicepc.example.com:7654/iau39;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp Byte-Range: 1-2048/4385 -------d93kswow$ Garcia-Martin, et al. Expires December 7, 2007 [Page 28] Internet-Draft SDP offer/answer for file transfer June 2007 Figure 8: MSRP 200 OK response F7: Bob acknowledges the reception of the second chunk. MSRP op2nc9a 200 OK To-Path: msrp://alicepc.example.com:7654/iau39;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp Byte-Range: 2049-4385/4385 -------op2nc9a$ Figure 9: MSRP 200 OK response F8: Alice terminates the SIP session by sending a SIP BYE request. F9: Bob acknowledges the reception of the BYE request and sends a 200 (OK) response. 9.2. Offerer requests a file from the Answerer and second file transfer In this example Alice, the SDP offerer, first wishes to fetch a file from Bob, the SDP answerer. Alice knows that Bob has a specific file she wants to download. She has learned the hash of the file by some out-of-band mechanism. The hash 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 transmission and sends the file to Alice. When Alice has completely received Bob's file, she intends to send a new image file to Bob. Therefore Alice re-uses the existing SDP media line with different attributes and updates the description of the new file she wants to send to Bob's User Agent Server (UAS). Figure 10 shows the sequence flow. Garcia-Martin, et al. Expires December 7, 2007 [Page 29] Internet-Draft SDP offer/answer for file transfer June 2007 Alice's UAC Bob's UAS | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | | |(4) (MSRP) SEND (file) | |<-----------------------| |(5) (MSRP) 200 OK | |----------------------->| | | |(6) (SIP) INVITE | |----------------------->| |(7) (SIP) 200 OK | |<-----------------------| |(8) (SIP) ACK | |----------------------->| | | |(9) (MSRP) SEND (file) | |----------------------->| |(10) (MSRP) 200 OK | |<-----------------------| | | |(11) (SIP) BYE | |<-----------------------| |(12) (SIP) 200 OK | |----------------------->| | | | | Figure 10: Flow diagram of an offerer requesting a file from the answerer and then sending a file to the answer F1: Alice constructs an SDP description of the file she wants to receive and attaches the SDP offer to a SIP INVITE request addressed to Bob. Garcia-Martin, et al. Expires December 7, 2007 [Page 30] Internet-Draft SDP offer/answer for file transfer June 2007 INVITE sip:bob@example.com SIP/2.0 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 1 INVITE Max-Forwards: 70 Date: Sun, 21 May 2006 13:02:03 GMT Contact: Content-Type: application/sdp Content-Length: [length of SDP] v=0 o=alice 2890844526 2890844526 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 7654 TCP/MSRP * a=recvonly a=accept-types:message/cpim a=accept-wrapped-types:image/jpeg 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:new Figure 11: 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 transmission and creates an SDP answer as follows: Garcia-Martin, et al. Expires December 7, 2007 [Page 31] Internet-Draft SDP offer/answer for file transfer June 2007 v=0 o=bob 2890844656 2890855439 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 8888 TCP/MSRP * a=sendonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=file-selector:type:image/jpeg hash:sha-1: 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E a=file-transfer:new Figure 12: 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/iau39;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp Message-ID: 12339sdqwer Byte-Range: 1-2027/2027 Content-Type: message/cpim To: Bob From: Alice DateTime: 2006-05-15T15:02:31-03:00 Content-Disposition: render; filename="My cool photo.jpg"; creation-date="Mon, 15 May 2006 15:01:31 +03:00"; modification-date="Mon, 15 May 2006 16:04:53 +03:00"; read-date="Mon, 16 May 2006 09:12:27 +03:00"; size=1931 Content-Type: image/jpeg ...binary JPEG image... -------d93kswow$ Figure 13: MSRP SEND request containing the actual file F5: Alice acknowledges the reception of the SEND request. Garcia-Martin, et al. Expires December 7, 2007 [Page 32] Internet-Draft SDP offer/answer for file transfer June 2007 MSRP d93kswow 200 OK To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp Byte-Range: 1-2027/2027 -------d93kswow$ Figure 14: MSRP 200 OK response F6: Alice re-uses the existing SDP media line inserting the description of the file to be sent and attaches it to a SIP re-INVITE request addressed to Bob. Garcia-Martin, et al. Expires December 7, 2007 [Page 33] Internet-Draft SDP offer/answer for file transfer June 2007 INVITE sip:bob@example.com SIP/2.0 To: Bob ;tag=1928323431 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 2 INVITE Max-Forwards: 70 Date: Sun, 21 May 2006 13:02:33 GMT Contact: Content-Type: multipart/mixed; boundary="boundary71" Content-Length: [length of multipart] --boundary71 Content-Type: application/sdp Content-Length: [length of SDP] v=0 o=alice 2890844526 2890844527 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 5670 TCP/MSRP * i=This is my latest picture a=sendonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://alicepc.example.com:5670/iau39;tcp a=file-selector:name:"sunset.jpg" type:image/jpeg size:4096 hash:sha-1: 58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F a=file-transfer:new a=file-disposition:render a=file-date:creation:"Sun, 21 May 2006 13:02:15 +03:00" a=file-icon:cid:id3@alicepc.example.com --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: Content-Length: [length of image] Content-Disposition: icon [..small preview icon...] --boundary71-- Figure 15: Reuse of the SDP in a second file transfer Garcia-Martin, et al. Expires December 7, 2007 [Page 34] Internet-Draft SDP offer/answer for file transfer June 2007 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. F7: Bob receives the re-INVITE request, inspects the SDP offer and extracts the icon body, checks the creation date and file size, and decides to accept the file transfer. So Bob creates the following SDP answer: v=0 o=bob 2890844656 2890855440 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 9999 TCP/MSRP * a=recvonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://bobpc.example.com:9999/9an4ea;tcp a=file-selector:name:"sunset.jpg" type:image/jpeg size:4096 hash:sha-1: 58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F a=file-transfer:new a=file-disposition:render Figure 16: SDP answer accepting the SDP offer for file transfer NOTE: The 'file-selector' attribute in the above figure is split in three lines for formatting purposes. Real implementations will encode it in a single line. F9: Alice opens a new TCP connection to Bob and creates an MSRP SEND request that contains the file. Garcia-Martin, et al. Expires December 7, 2007 [Page 35] Internet-Draft SDP offer/answer for file transfer June 2007 MSRP d95ksxox SEND To-Path: msrp://bobpc.example.com:9999/9an4ea;tcp From-Path: msrp://alicepc.example.com:5670/iau39;tcp Message-ID: 13449sdqwer Byte-Range: 1-2027/2027 Content-Type: message/cpim To: Bob 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"; size=1931 Content-Type: image/jpeg ...binary JPEG image... -------d95ksxox+ Figure 17: MSRP SEND request containing the actual file F10: Bob acknowledges the reception of the SEND request. MSRP d95ksxox 200 OK To-Path: msrp://alicepc.example.com:5670/iau39;tcp From-Path: msrp://bobpc.example.com:9999/9an4ea;tcp Byte-Range: 1-2027/2027 -------d95ksxox$ Figure 18: MSRP 200 OK response F11: Then Bob terminates the SIP session by sending a SIP BYE request. F12: Alice acknowledges the reception of the BYE request and sends a 200 (OK) response. 9.3. Example of a capability indication Alice sends an OPTIONS request to Bob (this request does not contain SDP). Bob answers with a 200 (OK) response that contain the SDP shown in Figure 20. The SDP indicates support for CPIM messages that can contain other few MIME types. The 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. Garcia-Martin, et al. Expires December 7, 2007 [Page 36] Internet-Draft SDP offer/answer for file transfer June 2007 Alice's UAC Bob's UAS | | |(1) (SIP) OPTIONS | |----------------------->| |(2) (SIP) 200 OK | | with SDP | |<-----------------------| | | | | Figure 19: Flow diagram of a capability request v=0 o=bob 2890844656 2890855439 IN IP4 bobpc.example.com s=- c=IN IP4 bobpc.example.com t=0 0 m=message 0 TCP/MSRP * a=accept-types:message/cpim a=accept-wrapped-types:text/plain text/html image/jpeg image/gif a=max-size:20000 a=file-selector Figure 20: SDP of the 200 (OK) response to an OPTIONS request 10. Security Considerations The SDP attributed defined in this specification identify a file to be transfered between two endpoints. An endpoint can offer to send the file to the other endpoint or request to receive the file from the other endpoint. In the former case, an attacker modifying those SDP attributes could cheat the receiver making it think that the file to be transfered was a different one. In the latter case, the attacker could make the sender send a different file than the one requested by the receiver. Consequently, it is RECOMMENDED that integrity protection be applied to the SDP session descriptions carrying the attributes specified in this specification. The descriptions of the files being transfered between endpoints may reveal information the endpoints may consider confidential. Therefore, it is RECOMMENDED that SDP session descriptions carrying the attributes specified in this specification be encrypted. TLS and S/MIME are the natural choices to provide offer/answer exchanges with integrity protection and confidentiality. Garcia-Martin, et al. Expires December 7, 2007 [Page 37] Internet-Draft SDP offer/answer for file transfer June 2007 11. IANA Considerations This document instructs IANA to register a number of SDP attributes according to the following: 11.1. Registration of new SDP attributes This memo provides instructions to IANA to register a number of media level only attributes in the Session Description Protocol Parameters registry [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 71800 8000 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 attribute Contact: Miguel Garcia Phone: +358 71800 8000 Attribute name: file-transfer Long-form attribute name: File Transfer Type of attribute: media level only This attribute is subject to the charset attribute Description: This attribute indicates whether the SDP requests a new file transfer or indicates an existing file transfer. Specification: RFC XXXX 11.1.3. Registration of the file-disposition attribute Contact: Miguel Garcia Phone: +358 71800 8000 Attribute name: file-disposition Long-form attribute name: File Disposition Garcia-Martin, et al. Expires December 7, 2007 [Page 38] Internet-Draft SDP offer/answer for file transfer June 2007 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 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.5. Registration of the file-icon attribute Contact: Miguel Garcia Phone: +358 71800 8000 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 71800 8000 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 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 Garcia-Martin, et al. Expires December 7, 2007 [Page 39] Internet-Draft SDP offer/answer for file transfer June 2007 in this memo. Thanks to Pekka Kuure for reviewing initial versions this document and providing helpful comments. Joerg Ott, Jiwey Wang, Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Courmont, Colin Perkins, Paul Kyzivat, and Sudhakar An discussed and provided comments and improvements to this document. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [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. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. Garcia-Martin, et al. Expires December 7, 2007 [Page 40] Internet-Draft SDP offer/answer for file transfer June 2007 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [I-D.ietf-simple-message-sessions] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-19 (work in progress), February 2007. 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. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, August 2006. [I-D.ietf-simple-msrp-relays] Jennings, C., "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", draft-ietf-simple-msrp-relays-10 (work in progress), December 2006. [I-D.ietf-rmt-flute-revised] Paila, T., "FLUTE - File Delivery over Unidirectional Transport", draft-ietf-rmt-flute-revised-03 (work in progress), January 2007. URIs [1] [2] [3] [4] Garcia-Martin, et al. Expires December 7, 2007 [Page 41] Internet-Draft SDP offer/answer for file transfer June 2007 Authors' Addresses Miguel A. Garcia-Martin Nokia Siemens Networks P.O.Box 6 Nokia Siemens Networks, FIN 02022 Finland 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 Hirsalantie 11 Jorvas 02420 Finland Email: Salvatore.Loreto@ericsson.com Garcia-Martin, et al. Expires December 7, 2007 [Page 42] Internet-Draft SDP offer/answer for file transfer June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Garcia-Martin, et al. Expires December 7, 2007 [Page 43]