RFC 5547
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
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.
A file transfer session is initiated by the offerer sending an SDP
offer to the answerer. The answerer either accepts or rejects the
file transfer session and sends an SDP answer to the offerer.
We can differentiate two use cases, depending on whether the offerer
is the file sender or file receiver:
1. The offerer is the file sender, i.e., the offerer wants to
transmit a file to the answerer. Consequently, the answerer is
the file receiver. In this case, the SDP offer contains a
'sendonly' attribute, and accordingly the SDP answer contains a
'recvonly' attribute.
2. The offerer is the file receiver, i.e., the offerer wants to
fetch a file from the answerer. Consequently, the answerer is
the file sender. In this case, the SDP offer contains a session
or media 'recvonly' attribute, and accordingly the SDP answer
contains a session or media 'sendonly' attribute.
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 to 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 the 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 whether or not a new file transfer is requested.
In other cases, a file transfer was successfully completed. Then, if an endpoint resends the SDP offer with the media stream for the file transfer, then the other endpoint wouldn't be able to determine whether or not a new file transfer should start. 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 restart 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 aborting a file transfer. If an endpoint creates an SDP offer where the 'file-transfer-id' attribute value does not change with respect to a previously sent one, but the file selector changes so that a new file is selected, then this is considered an 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 reused). 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.2.1. The Offerer Is a File Sender
In a push operation, the file sender creates an 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', or '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 for the file receiver to identify whether the file is already available and need not be transmitted. The file sender MAY also add a 'name' selector in the 'file-selector' attribute, and '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 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.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 MUST include, at least, one of the selectors defined for such 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, particularly 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 for the file receiver 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 add a session or media 'recvonly' attribute in the SDP offer. Then, the file receiver sends the SDP offer to the file sender. When the file receiver receives the SDP answer, if the port number of 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. Similarly, the file receiver SHOULD also verify that the other selectors declared in the SDP match the file properties, otherwise, the file receiver SHOULD consider that the file transfer failed and SHOULD inform the user.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 reused for sequential file transfers.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.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 changes with respect to the current status. In any case, independently of the port number, the SDP answerer creates a regular SDP answer and sends it to the offerer. If the port number is different than zero and the SDP offer contains a new 'file-transfer-id' attribute, then it is signaling a request for a new file transfer. The SDP answerer extracts the attributes and parameters that describe the file and typically requests permission from 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', or 'size' selectors in the 'file-selector' attribute, the answerer MUST copy them into the answer. The file receiver copies the value of the 'file-transfer-id' attribute to the SDP answer. 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-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 or not the file transfer is accepted 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 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. When the file transfer operation is complete, the file receiver computes the hash of the file and SHOULD verify that it matches the hash declared in the SDP. If they do not match, the file receiver SHOULD consider that the file transfer failed and SHOULD inform the user. Similarly, the file receiver SHOULD also verify that the other selectors declared in the SDP match the file properties; otherwise, the file receiver SHOULD consider that the file transfer failed and SHOULD inform the user.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 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 or not an actual file transfer is initiated, the file sender MUST create a proper SDP answer that contains the 'file-transfer-id' attribute with the same value received in the SDP offer, and then it MUST continue processing the SDP answer. The file sender MUST always create an SDP answer according to the SDP offer/answer procedures specified in RFC 3264 [RFC3264]. The file sender inspects the file selector of the received SDP offer, which is encoded in the 'file-selector' media attribute line. 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 answerer 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 in RFC 3264 [RFC3264]. The file sender SHOULD add a 'hash' selector in the answer with the locally computed SHA-1 hash over the complete file. 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 to zero. The file sender MAY also include a 'type' selector in the 'file-selector' attribute line of the SDP answer. The answerer MAY also include '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 [RFC4975]) 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 signaled 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 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 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 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.2.1. The 'file-transfer-id' attribute MUST be the same attribute 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 the 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.3.1. Then the file receiver sends this SDP answer to the file sender.
File sender File receiver | | |\ | | \ | | \ | | \ | | \ | | \ | abort->| \ MSRP SEND (#) | | +--------------->| | MSRP 200 | |<-----------------------| | re-INVITE (SDP offer) | |----------------------->| | SIP 200 OK (SDP answer)| |<-----------------------| | SIP ACK | |----------------------->| | | 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 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.2.2. The 'file-transfer-id' attribute MUST be the same attribute 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 | | \ | | \ | | \ | | \ | | \ | | \ | | MSRP 413 |<-abort |<-----------------------| | \ (#) | | +----------->| | re-INVITE (SDP offer) | |<-----------------------| | SIP 200 OK (SDP answer)| |----------------------->| | SIP ACK | |<-----------------------| | | 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 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 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.2.2. The 'file-transfer-id' attribute MUST be the same attribute 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 | | \ | | \ | | \ | | \ | | \ | | \ | | re-INVITE (SDP offer) |<-abort |<-----------------------| | \ (#) | | +----------->| | MSRP 200 | |<-----------------------| | SIP 200 OK (SDP answer)| |----------------------->| | SIP ACK | |<-----------------------| | | 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, 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.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, RFC 3264 indicates that an endpoint builds an SDP body that contains
an "m=" line containing 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.6. Reusage 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., reuse 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 reuse 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 resends 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 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.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 initiated within an existing multimedia session, the SDP offerer MUST NOT reuse an existing "m=" line that is still being used by MSRP (either regular MSRP for instant messaging or an ongoing file transfer). Rather, it MUST add an additional "m=" line or else reuse an "m=" line that is no longer being used.
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 Common Presence and Instant Messaging (CPIM) message that wraps the file. When chunking is used, it should be noticed 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 [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 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 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 matter of fact, MSRP allows multiple MSRP sessions to share the same TCP connection.8.8. 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 Content-ID (CID) URL [RFC2392] pointing 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 MUST wrap the SDP body and the icon bodies in a MIME multipart/related body. Therefore, implementations according to this specification MUST implement the multipart/related MIME type [RFC2387]. When creating a multipart/ related MIME wrapper, the SDP body MUST be the root body, which according to RFC 2387 [RFC2387] is identified as the first body in the multipart/related MIME wrapper or explicitly identified by the 'start' parameter. According to RFC 2387 [RFC2387], the 'type' parameter MUST be present and point to the root body, i.e., the SDP body. Assume that an endpoint behaving according to this specification tries to send a file to a remote endpoint that neither implements this specification nor implements multipart MIME bodies. The file sender sends an SDP offer that contains a multipart/related MIME body 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 resends the SDP offer. 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 octets that provide significance.
(page 28 continued on part 3)
