RFC 5547
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer 🎀
okay bestie, this is RFC 5547 💖, a Standards Track doc from the Network Working Group, published in May 2009 🌸. The authors are M. Garcia-Martin (Ericsson), M. Isomaki (Nokia), G. Camarillo (Ericsson), S. Loreto (Ericsson), and P. Kyzivat (Cisco Systems) ✨. The title block doesn't list anything it obsoletes or updates, so this one is a fresh start 🦋.
Status of This Memo 📋
this doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🫶. for the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. distribution of this memo is unlimited 🌈.
Copyright Notice ©️
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 💅
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as in effect on the date of publication (http://trustee.ietf.org/license-info). please read these carefully, because they spell out your rights and restrictions for this document 🙈.
Abstract 🦋
this doc gives you a way to negotiate the transfer of one or more files between two endpoints, using the Session Description Protocol (SDP) offer/answer model from RFC 3264 💌. SDP gets extended so it can describe the attributes of the files being transferred. the offerer can describe either the files it wants to send or the files it would like to receive. the answerer can accept or reject the offer separately for each individual file ✅. the transfer of one or more files kicks off after a successful negotiation 🔥. the Message Session Relay Protocol (MSRP) is the default mechanism for actually carrying the files between the endpoints, and this doc also explains how to use MSRP for file transfer 🧚.
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Definitions .....................................................4
4. Overview of Operation ...........................................5
5. File Selector ...................................................6
6. Extensions to SDP ...............................................7
7. File Disposition Types .........................................13
8. Protocol Operation .............................................13
8.1. The 'file-transfer-id' Attribute ..........................14
8.2. Offerer's Behavior ........................................17
8.2.1. The Offerer Is a File Sender .......................17
8.2.2. The Offerer Is a File Receiver .....................18
8.2.3. SDP Offer for Several Files ........................18
8.3. Answerer's Behavior .......................................19
8.3.1. The Answerer Is a File Receiver ....................19
8.3.2. The Answerer Is a File Sender ......................20
8.4. Aborting an Ongoing File Transfer Operation ...............22
8.5. Indicating File Transfer Offer/Answer Capability ..........25
8.6. Reusage of Existing "m=" Lines in SDP .....................26
8.7. MSRP Usage ................................................26
8.8. Considerations about the 'file-icon' Attribute ............28
9. Examples .......................................................28
9.1. Offerer Sends a File to the Answerer ......................28
9.2. Offerer Requests a File from the Answerer and
Second File Transfer ......................................33
9.3. Example of a Capability Indication ........................40
10. Security Considerations .......................................41
11. IANA Considerations ...........................................42
11.1. Registration of New SDP Attributes .......................42
11.1.1. Registration of the file-selector Attribute .......43
11.1.2. Registration of the file-transfer-id Attribute ....43
11.1.3. Registration of the file-disposition Attribute ....43
11.1.4. Registration of the file-date Attribute ...........44
11.1.5. Registration of the file-icon Attribute ...........44
11.1.6. Registration of the file-range Attribute ..........45
12. Acknowledgments ...............................................45
13. References ....................................................45
13.1. Normative References .....................................45
13.2. Informative References ...................................46
Appendix A. Alternatives Considered ..............................481. Introduction ✨
okay so the Session Description Protocol (SDP) offer/answer [RFC3264] is how two endpoints agree on a shared picture of a multimedia session between them 🎬. these sessions often carry real-time media like voice and video, but they're not limited to that. honestly, any media component type can be supported, as long as someone has written down how to negotiate it inside the SDP offer/answer exchange 💜.
the Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for sending instant messages (IMs) within a session 💬. its spec explains how to use SDP to set up an MSRP session. on top of plain text, MSRP can carry arbitrary (binary) Multipurpose Internet Mail Extensions (MIME) [RFC2045] compliant content, like images or video clips 📸.
there are lots of times when the endpoints in a multimedia session want to swap files inside that session 📁. with MSRP, you can embed files as MIME objects right in the stream of instant messages. MSRP has other features that are useful for file transfer too 🌟. message chunking lets a big file share the same transport connection with IM chatter without blocking the IMs 🙌. MSRP relays [RFC4976] give you a mechanism for Network Address Translator (NAT) traversal 🧭. and Secure MIME (S/MIME) [RFC3851] can be used for ensuring the integrity and confidentiality of the transferred content 🔐.
but the baseline MSRP doesn't quite cover everything file transfer needs inside multimedia sessions 😭. there are four main missing features:
- The recipient must be able to distinguish "file transfer" from "file attached to IM", allowing the recipient to treat the cases differently. 👀
- 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. 🙋♀️
- 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. 📝
- It must be possible for the recipient to request a file from the sender, providing meta information about the file. The sender must be able to decide whether to send a file matching the request. 🎯
the rest of this document is organized like this. Section 3 defines a few terms used in the doc 📖. Section 4 gives the overview of operation 🗺️. Section 5 introduces the concept of the file selector 🎯. the detailed syntax and semantics of the new SDP attributes, plus conventions for how the existing ones are used, live in Section 6 🧩. Section 7 talks about file disposition types 🗃️. Section 8 describes the protocol operation involving SDP and MSRP ⚙️. and finally, Section 9 has some examples 🍓.
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 from RFC 3264 [RFC3264] apply:
- Answer 💌
- Answerer 🙋
- Offer 📨
- Offerer 📤
we also define the following terms, so everyone's on the same page 🫶:
- 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 to select a file at the SDP answerer. Section 5 goes into more detail on this 🎀.
- Push operation: a file transfer operation where the SDP offerer takes the role of the file sender and the SDP answerer takes the 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 ✨
okay so here's the big picture 🧚 An SDP offerer makes an SDP body that describes one or more files they want to send or receive. They send that offer to the remote endpoint, and the SDP answerer can accept or reject each file separately. so cute, right? 🎀
The actual transfer happens over the Message Session Relay Protocol (MSRP) [RFC4975]. Each SDP "m=" line describes one MSRP media stream that moves a single file at a time. So if you want to send several files at once, you need several "m=" lines and matching MSRP media streams 📂 It should be noted that multiple MSRP media streams can share a single transport layer connection, so this won't lead to excessive use of transport resources. no overload, bestie 💅
Each "m=" line for an MSRP media stream comes with a few attributes that describe the file. If the file sender writes the SDP offer, the attributes describe a local file that gets sent (push), and the file receiver uses that info to accept or reject. But if the file receiver writes the offer, the attributes characterize a specific file the receiver is hoping to get (pull) from the file sender. It's possible the file sender doesn't have a matching file or doesn't want to send it, and then the offer gets rejected 🥲
All those per-file attributes live in SDP as a set of new SDP attributes, and most of them are borrowed straight from MIME 🍓 That's the magic, because user agents can decide whether to accept a transfer based on the file's name, size, description, hash, icon (for example, if it's a picture), and so on 📸
SDP direction attributes (like 'sendonly' and 'recvonly') show which way the transfer goes, meaning whether the SDP offerer wants to send or receive the file. If the answerer accepts, the files move using ordinary MSRP. Also, the 'sendonly' and 'recvonly' attributes refer to the direction of MSRP SEND requests. They do not block other protocol elements, like 200 responses, REPORT requests, and so on 🦋
In principle the file transfer can work even with an endpoint that only supports regular MSRP and doesn't understand the extensions defined here. That only happens when that endpoint is both the SDP answerer and the file receiver. The regular MSRP endpoint answers the offer like it would answer any ordinary MSRP offer and ignores the extension attributes. In that case the user experience is weaker, though, because the recipient wouldn't know (by any protocol means) why the session exists, and couldn't accept or reject it based on the file attributes 🙈
5. File Selector
When the file receiver writes the SDP offer, the offer has to unambiguously identify the requested file at the file sender 🎯 So we introduce the file selector, which is a tuple made of one or more of these individual selectors: the name, size, type, and hash of the file. The file selector can include any number of selectors, so all four don't always have to show up 💖
The whole point of the file selector is to give the remote entity enough info about the file so that both sides can refer to the same file 🫶 The file selector is encoded in a 'file-selector' media attribute in SDP. The formal syntax of that attribute is in Figure 1.
The file selection process runs against every available file on the host. It picks the files that match each selector present in the 'file-selector' attribute. The result can be zero, one, or many files, depending on which selectors are in the SDP and which files the host has 📁 The file transfer mechanism in this document needs a file selector to end up with at most one file chosen. Usually, if the hash selector is known, it's enough to make a file selector that points to exactly zero or one file. The catch is that the offerer doesn't always know a selector that picks out one unique file. Sometimes only the name, size, or type is known, so the selector might match more than one file, and that's the undesired case 😬 The opposite can happen too: if the file selector has a hash selector and a name selector, the remote host may have renamed the file. Then a file whose computed hash equals the hash selector might exist, but its name won't match the name selector. So in that case, the selection process ends up picking zero files 💀
This specification uses the Secure Hash Algorithm 1, SHA-1 [RFC3174]. If future needs call for different hashing algorithms, they'll be specified as extensions to this document 🌈
Implementations that follow this specification MUST implement the 'file-selector' attribute and MAY implement any of the other attributes 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 in this specification 👑
The 'file-selector' media attribute is also useful for learning whether the other side supports the file transfer offer/answer capability this document specifies. That's explained more in Section 8.5 ✨
6. Extensions to SDP
We define a bunch of new SDP [RFC4566] attributes that carry the info needed to describe transferring a file with MSRP 🦋 All of them are media-level-only attributes in SDP. The formal ABNF syntax [RFC5234] for these new attributes is below. It's built on top of the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183 [RFC2183], RFC 2392 [RFC2392], and RFC 5322 [RFC5322] 🧠
attribute =/ file-selector-attr / file-disp-attr /
file-tr-id-attr / file-date-attr /
file-icon-attr / file-range-attr
; attribute is defined in RFC 4566
file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector = filename-selector / filesize-selector /
filetype-selector / hash-selector
filename-selector = "name:" DQUOTE filename-string DQUOTE
; DQUOTE defined in RFC 5234
filename-string = 1*(filename-char/percent-encoded)
filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF
; any byte except NUL, CR, LF,
; double quotes, or percent
percent-encoded = "%" HEXDIG HEXDIG
; HEXDIG defined in RFC 5234
filesize-selector = "size:" filesize-value
filesize-value = integer ;integer defined in RFC 4566
filetype-selector = "type:" type "/" subtype *(";" ft-parameter)
ft-parameter = attribute "=" DQUOTE value-string DQUOTE
; attribute is defined in RFC 2045
; free insertion of linear-white-space is not
; permitted in this context.
; note: value-string has to be re-encoded
; when translating between this and a
; Content-Type header.
value-string = filename-string
hash-selector = "hash:" hash-algorithm ":" hash-value
hash-algorithm = token ; see IANA Hash Function
; Textual Names registry
; only "sha-1" currently supported
hash-value = 2HEXDIG *(":" 2HEXDIG)
; Each byte in upper-case hex, separated
; by colons.
; HEXDIG defined in RFC 5234
file-tr-id-attr = "file-transfer-id:" file-tr-id-value
file-tr-id-value = token
file-disp-attr = "file-disposition:" file-disp-value
file-disp-value = token
file-date-attr = "file-date:" date-param *(SP date-param)
date-param = c-date-param / m-date-param / r-date-param
c-date-param = "creation:" DQUOTE date-time DQUOTE
m-date-param = "modification:" DQUOTE date-time DQUOTE
r-date-param = "read:" DQUOTE date-time DQUOTE
; date-time is defined in RFC 5322
; numeric timezones (+HHMM or -HHMM)
; must be used
; DQUOTE defined in RFC 5234 files.
file-icon-attr = "file-icon:" file-icon-value
file-icon-value = cid-url ; cid-url defined in RFC 2392
file-range-attr = "file-range:" start-offset "-" stop-offset
start-offset = integer ; integer defined in RFC 4566
stop-offset = integer / "*"
Figure 1: Syntax of the SDP extensionWhen the 'file-selector' attribute is used for a capability query (see Section 8.5), it MUST NOT contain any selector, because its presence alone shows that the endpoint complies with this specification 🙌
When the 'file-selector' attribute shows up in an SDP offer or answer, it MUST contain at least one selector. Selectors describe the file to be transferred, and there are four of them in this attribute: 'name', 'size', 'type', and 'hash' 🍰
The 'name' selector in the 'file-selector' attribute holds the filename of the content, wrapped 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 the actual file transfer would signal. If a file name has double quotes or any other character the syntax doesn't allow in the 'name' selector, those characters MUST be percent-encoded. The 'name' selector MUST NOT contain characters that the local operating system could read as directory structure. If characters like that show up in the file name, they MUST be percent-encoded 🗂️
Note that the 'name' selector might still contain characters that, although not meaningful to 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 in the local file system, such as creating a local file. Among other things, implementations can percent-encode characters that are meaningful to the local operating system before making local file system calls 🛡️
The 'size' selector in the 'file-selector' attribute gives 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 the actual file transfer would signal. Note that the 'size' selector only includes the file size, and does not include any potential overhead added by a wrapper, such as message/cpim [RFC3862] 📏💅
The 'type' selector in the 'file-selector' attribute is where you put the MIME media and submedia types of the content, bestie 🎀 Basically, anything you can say in a Content-Type header field (see RFC 2045 [RFC2045]) can also go in a 'type' selector. ✨ Valid MIME Media Type values are the ones in the IANA registry for MIME Media Types [IANA], and zero or more parameters can follow. 💅 When you translate parameters from a Content-Type header into a 'type' selector, you have to re-encode each parameter before it gets tucked into the selector (see the ABNF syntax of 'ft-parameter'). Re-encoding is the whole glow-up 💖
The 'hash' selector in the 'file-selector' attribute gives you a hash computation of the file being transferred 🔐 File transfer protocols use this a lot. For example, FLUTE [FLUTE-REV] uses hashes (called message digests) to verify the contents of the transfer. 🧚 The 'hash' selector has two jobs. First, in pull operations, the file receiver can identify a remote file by its hash instead of its file name, as long as the file receiver has learned that hash through some out-of-band mechanism. Second, in either push or pull operations, the file receiver can verify the contents of the received file, or even skip transmitting a file it already has. Smart, right? 🦋
🙈 The address space of the SHA-1 algorithm is big enough to avoid any collision in hash computations in between two endpoints. When transferring files, the actual file transfer protocol should provide reliable transmission of data, so verifications of received files should always succeed. However, if endpoints need to protect the integrity of a file, they should use some other mechanism than the 'hash' selector specified in this memo.
The 'hash' selector includes the hash algorithm and its value. The possible hash algorithms are the ones defined in the IANA registry of Hash Function Textual Names [IANA]. 🌸 Implementations of this spec MUST add a 160-bit string from the computation of US Secure Hash Algorithm 1 (SHA1) [RFC3174] whenever the 'hash' selector is present. If the need arises, extensions can be drafted to support several hashing algorithms. So implementations according to this specification MUST be prepared to receive SDP containing more than a single 'hash' selector in the 'file-selector' attribute. Be ready for anything, bestie 👑
The value of the 'hash' selector is the byte string you get by applying the hash algorithm to the content of the whole file, even when the transfer is limited to a range of octets (i.e., the 'file-range' attribute is indicated). 💜
The 'file-transfer-id' attribute gives the actual file transfer a randomly chosen, globally unique identification ✨ It's how you tell a brand-new file transfer request apart from a repeat of the SDP (or the part of the SDP that describes the file). This attribute gets much deeper coverage in Section 8.1.
The 'file-disposition' attribute is a suggestion to the other endpoint about the intended disposition of the file 🎀 Section 7 has more on the possible values. The value of this attribute SHOULD be the same as the disposition type parameter of the Content-Disposition header field [RFC2183] that the actual file transfer protocol would signal.
The 'file-date' attribute tells you the dates on which the file was created, modified, or last read 📅 It MAY contain a combination of the 'creation', 'modification', and 'read' parameters, but it MUST NOT contain more than one of each type .
The 'creation' parameter is the date the file was created 🌈 Its value MUST be a quoted string holding a representation of the creation date in RFC 5322 [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. The value of this parameter SHOULD be the same as the 'creation-date' parameter of the Content-Disposition header field [RFC2183] that the actual file transfer protocol would signal.
The 'modification' parameter is the date the file was last modified ✏️ Its value MUST be a quoted string holding a representation of the last modification date in RFC 5322 [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. The value of this parameter SHOULD be the same as the 'modification-date' parameter of the Content-Disposition header field [RFC2183] that the actual file transfer protocol would signal.
The 'read' parameter is the date the file was last read 👀 Its value MUST be a quoted string holding a representation of the last date the file was read in RFC 5322 [RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used. The value of this parameter SHOULD be the same as the 'read-date' parameter of the Content-Disposition header field [RFC2183] that the actual file transfer protocol would signal.
The 'file-icon' attribute is super useful with certain file types, like images 🖼️ It lets the file sender include a pointer to a body containing a small preview icon that represents the file's contents. The file receiver can look at that icon to decide whether it wants to receive the file at all. The 'file-icon' attribute contains a Content-ID URL, specified in RFC 2392 [RFC2392]. Section 8.8 has more considerations about the 'file-icon' attribute.
The 'file-range' attribute lets you signal a chunk of a file instead of the whole thing 🧩 This makes it possible to interrupt a file transfer and resume it later, maybe even with one of the endpoints swapped out. The 'file-range' attribute holds the "start offset" and "stop offset" of the file, separated by a dash "-". The "start offset" is the octet position in the file where the transfer should start. The first octet of a file is numbered "1". The "stop offset" is the octet position where the transfer should stop, and that octet is included. The "stop offset" value MAY contain a "" if the total size of the file isn't known in advance. If this attribute is absent, you're getting the complete file, as if 'file-range' had been present with a value of "1-". 💫
Don't mix up the 'file-range' attribute with the Byte-Range header in MSRP 🙅♀️ The 'file-range' attribute is the portion of a file that the application reads and passes to the MSRP stack for transport. From MSRP's point of view, that portion is treated as one whole message. The Byte-Range header, on the other hand, tells you how many bytes of that message are in a given chunk and the total size of the message. So MSRP starts counting the delivered message at octet number 1, no matter where that octet sits in the file. Two different counting systems, bestie, keep them separate 💅
Here's an example of an SDP body that uses 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-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
a=file-disposition:attachment
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
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 lets the file sender indicate a preferred disposition of the file in a new 'file-disposition' attribute 🎀 In principle, any value in the IANA registry for Mail Content Disposition Values [IANA] is acceptable, but honestly, most of them won't be applicable.
There are two content dispositions that really matter for file transfer operations 👀 On one hand, the file sender may just want the file rendered right away on the file receiver's device. On the other hand, the file sender may just want to tell the file receiver that the file should not be rendered when it arrives. The recipient's user agent may want to check with the user about the file disposition, or it may save the file until the user takes an action. Either way, 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 uses the existing 'attachment' value of the Content-Disposition type in the new 'file-disposition' attribute in SDP 📎 The default value is 'render', which means that 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 this definition 📖
"Body parts 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."
For this specification, the 'attachment' disposition type is used to say that the display of the file should not be automatic, but depends on some further action from the user 🫶
8. Protocol Operation 🦋
This section talks about how to use the parameters defined in Section 6 during an offer/answer [RFC3264] exchange 💌 It also covers how the endpoints behave when they're using MSRP.
A file transfer session starts when the offerer sends an SDP offer to the answerer 🚀 The answerer either accepts or rejects the file transfer session, and then sends an SDP answer back to the offerer.
There are two use cases, depending on whether the offerer is the file sender or the file receiver 👯♀️
- The offerer is the file sender, meaning the offerer wants to transmit a file to the answerer. So the answerer is the file receiver. In this case, the SDP offer contains a 'sendonly' attribute, and the SDP answer accordingly contains a 'recvonly' attribute. 📤
- The offerer is the file receiver, meaning the offerer wants to fetch a file from the answerer. So the answerer is the file sender. In this case, the SDP offer contains a session or media 'recvonly' attribute, and the SDP answer accordingly contains a session or media 'sendonly' attribute. 📥
8.1. The 'file-transfer-id' Attribute ✨
Okay bestie, so this spec is an extension to the SDP offer/answer model [RFC3264], which means the existing SDP behavior has to stay totally intact 💅 That includes the part where SDP gets sent again to the other party even when the media description (or other SDP parameters) hasn't changed since the last offer/answer exchange. Think about the SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITE requests to refresh sessions. RFC 4028 recommends sending unmodified SDP in a re-INVITE to refresh the session 🌸 Now imagine that re-INVITE has SDP describing a file transfer and shows up while the transfer is still going. There would be no way to tell if the SDP creator wanted to abort the current transfer and start a new one, or if the file description was just tagging along for some other reason (e.g., session timer refresh). Not ideal 🙈
A similar situation happens when two endpoints have agreed on a file transfer, and it's already happening, and then one of them wants to add more media streams to the session. The endpoint sends a re-INVITE request with the SDP. That SDP needs to keep the media descriptions for the ongoing file transfer and add the new ones. The problem is the other endpoint can't tell whether a brand new file transfer is being requested 😭
And then there's the case where a file transfer already finished. If an endpoint resends the SDP offer with the media stream for that file transfer, the other endpoint wouldn't be able to figure out whether a new file transfer should start 💀
So to fix all this, this specification defines the 'file-transfer-id' attribute, which holds a globally unique random identifier allocated to the file transfer operation 🦋 The file transfer identifier helps both endpoints figure out whether an SDP offer is requesting a new file transfer or is just a repeat of the SDP. A new file transfer is one that, if accepted, will actually cause a file to be transferred. That's typically what happens in new offer/answer exchanges, or when an endpoint wants to abort the existing file transfer and restart it once more. A repeated SDP, on the other hand, doesn't lead to any actual file being transferred, maybe because the transfer is still going on or because it already finished. This is what happens with repeated offer/answer exchanges, which can happen for a bunch of reasons (session timer, addition/removal of other media types in the SDP, an update in SDP due to changes in other session parameters, etc.) 🌈
Here's the big rule: implementations following 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 gets suspended and resumed later, the resumption counts as a new file transfer (even when the file being transferred is the same), so 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. Basically, setting a media stream to zero has higher precedence than any value the 'file-transfer-id' attribute can take 💅
As a side effect, the 'file-transfer-id' attribute can be used to abort and then restart an ongoing file transfer. Say two endpoints agree on a file transfer and it's actually happening. Partway through, one endpoint sends a new SDP offer that's identical to the initial one except the 'file-transfer-id' value, which is a new globally unique random value. That tells the answerer 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, following the procedures of the file transfer protocol (e.g., MSRP), and start sending the file again from the initially requested octet. Section 8.4 goes into more detail about aborting a file transfer 🦋
If an endpoint creates an SDP offer where the 'file-transfer-id' attribute value hasn't changed since a previously sent one, but the file selector changes so a new file gets selected, that's considered an error. 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 doesn't 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 they're requesting the same file described in a previous SDP offer/answer exchange 🫶
Figure 3 sums up how the 'file-transfer-id' attribute relates to the file selector across 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 exchangeIn another scenario, an endpoint that has successfully transferred a file wants to send an SDP for some reason other than transferring a file. The SDP offerer creates an SDP file description that keeps the media description line for 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 wants 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 get 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, indicating the type, size, or hash of the file, respectively. If the file sender wants to start a new file transfer, the file sender MUST add a 'file-transfer-id' attribute containing a new globally unique random identifier value. On top of that, 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, plus 'file-icon', 'file-disposition', and 'file-date' attributes that describe the file being transferred in more detail. The 'file-disposition' attribute gives a presentation suggestion (for example, whether the file sender would like the file receiver to render the file or not). The three date attributes tell the answerer how old the file is. The file sender MAY also add a 'file-range' attribute indicating the start and stop offsets of the file 🌈
When the file sender gets the SDP answer, if the port number of the answer for a file request is non-zero, the file sender starts transferring the file according to the parameters negotiated in SDP ⭐
8.2.2. The Offerer Is a File Receiver ✨
Okay so in a pull operation, the file receiver is the one who makes the SDP offer and sends it to the file sender 💌. The file receiver MUST include a file-selector attribute, and it MUST include at least one of the selectors defined for that attribute (aka name, type, size, or hash) 🎀. If the hash is already known, that alone can identify the file, so the offerer can include only a hash selector 🔍. But when the hash is unknown, the file name, size, and type can describe the file to be fetched 🧚. If the file receiver wants to start a brand new file transfer, it MUST add a file-transfer-id attribute containing a new globally unique random value 🦋. It MAY also add a file-range attribute to say where the start and stop offsets are 🌸. There's no need to include any other file attributes in the offer (beyond the mandatory ones), so it is RECOMMENDED that SDP offerers skip any other file attribute defined by this specification 💅. Also, the file receiver MUST add a session or media recvonly attribute to the SDP offer. Then it sends the offer to the file sender 🚀.
When the file receiver gets the SDP answer, if the port number for a file request is non-zero, the file receiver should receive the file using the protocol indicated in the m= line 📨. If the answer contains a supported hashing algorithm in the hash selectors of the file-selector attribute, the file receiver SHOULD compute the hash of the file after receiving it, then check it against the hash from the answer 🧮. If the computed hash doesn't match, the file receiver SHOULD consider 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. If they don't, the file receiver SHOULD consider the file transfer failed and SHOULD inform the user 💀.
8.2.3. SDP Offer for Several Files 🗂️
An offerer that wants 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, per regular SDP [RFC4566] procedures. Likewise, the answerer can accept each file separately by setting its associated m= port to a non-zero value. Each file has its own file transfer identifier, which uniquely identifies each file transfer 🎀.
Using an m= line per file means 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 wants to reject a file offered by the offerer, it sets the port number of the m= line associated with that file to zero, 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 checks the port number first. If the port number is set to zero, the file transfer operation is closed, and no more data is expected over the media stream 🚫. If the port number is non-zero, the file receiver inspects the file-transfer-id attribute. If that value has been used before, the existing session stays as it is. Maybe the file transfer is still in progress, or maybe it has wrapped up, but either way nothing has changed since the current status 🌙. No matter what the port number is, the SDP answerer creates a regular SDP answer and sends it back to the offerer ✨.
If the port number is non-zero and the SDP offer contains a new file-transfer-id attribute, that's a request for a new file transfer 🆕. The SDP answerer pulls out the attributes and parameters that describe the file and usually asks the user for permission to accept or reject the file 🙏. If the file transfer is accepted, the file receiver MUST create an SDP answer according to the procedures 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 into the SDP answer 🎟️. Then the file receiver MUST add a session or media recvonly attribute according to the procedures 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 whether a local file with the same hash is already available. If it is, that could mean receiving a duplicated file 👯. It's up to the answerer to decide whether the file transfer is accepted in the case of a duplicated file 🤷♀️.
If the SDP offer contains a file-range attribute and the file receiver accepts receiving the range of octets declared there, the file receiver MUST include a file-range attribute in the SDP answer with the same range of values 📏. If the file receiver doesn't accept 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 don't match, the file receiver SHOULD consider 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. If they don't, the file receiver SHOULD consider 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 hasn't been used before throughout the session, then accepting the file MUST provoke the transfer of the file over the negotiated protocol 🚚. However, if the value was already used by another file transfer operation within the session, the file sender MUST NOT alert the user and MUST NOT start a new transfer of the file 🙈. Whether or not an actual file transfer is started, 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 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 it applies the file selector, which means selecting the files that match, one by one, the name, type, size, and hash selectors of the file-selector attribute line (if they're present) 🔍. The file selector identifies zero or more candidate files to be sent. If the file selector can't identify any file, the answerer MUST reject the MSRP stream for file transfer by setting the port number to zero. Then the answerer SHOULD also reject the SDP as per the 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 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 the hash computed by the file sender differs from the one 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 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 can't be made, 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 sending the range of octets declared there, the file sender MUST include a file-range attribute in the SDP answer with the same range of values 📦. If the file sender doesn't accept sending that range of octets, it SHOULD reject the transfer of the file 🚫.
8.4. Aborting an Ongoing File Transfer Operation ✨
Okay so either the file sender OR the file receiver can bail on an ongoing file transfer at any time 💅. Unless otherwise noted, whoever aborts MUST follow the procedures at the media level (e.g., MSRP) and at the signaling level (SDP offer/answer), as described below.
Picture the scenario in Figure 4, where the file sender wants to abort without starting some other transfer 🦋. Say an MSRP SEND request is being transmitted. The sender aborts the MSRP message by putting the # character in the continuation field of the end-line of the SEND request, following the MSRP rules (see Section 7.1 of RFC 4975 [RFC4975]). A file goes over as one MSRP message, so aborting that message basically aborts the whole file transfer 😭. The file receiver replies to the SEND request with a 200 response. Then the file sender SHOULD close the MSRP session by making a new SDP offer that sets the port number to zero in the related m= line for the file transfer (see Section 8.2 of RFC 3264 [RFC3264]). That SDP offer MUST conform with the requirements of Section 8.2.1. The 'file-transfer-id' attribute MUST be the same one that identifies the ongoing transfer. Then the sender ships this SDP offer off 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 gets 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 back 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 transferWhen the file receiver wants to abort, there are two possible scenarios, depending on the value of the Failure-Report header in the ongoing MSRP SEND request 🤔. Now check out Figure 5, where the MSRP SEND request includes a Failure-Report header set to a value different than "no". When the file receiver wants to abort, it 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 for 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 one 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 MSRPIn another scenario, shown in Figure 6, an ongoing file transfer is happening, and 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 for 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 one 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 MSRPWhen a file sender gets an SDP offer that sets the port number to zero in the related m= line for the file transfer, it first aborts any ongoing MSRP SEND request that's being transmitted 🛑. It does this by putting the # character in the continuation field of the end-line of the SEND request, following 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] has 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] explains how to build the SDP that goes in the response to that capability query. So RFC 3264 says an endpoint builds an SDP body that includes an m= line with the media type (message, for MSRP) ✨. An endpoint that implements the procedures 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] has rules that let SDP offerers and answerers modify an existing media line, i.e., reuse a media line with different attributes. You can do the same when SDP signals a file transfer under this memo's rules 🧚. So the procedures defined in RFC 3264 [RFC3264], in particular those in Section 8.3, MUST apply for file transfer operations. An endpoint that wants to reuse an existing m= line to start the transfer of another file creates a different 'file-selector' attribute and picks a new globally unique random value for 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 decides whether a new file transfer starts or whether the file transfer doesn't need to start. If the SDP answerer accepts the SDP, the file transfer starts from the indicated octet (if a 'file-range' attribute is present) 👑.
8.7. MSRP Usage 💌
Okay bestie, let's talk MSRP 🦋. The file transfer service in this doc uses "m=" lines in SDP to describe a one-way transfer of a file, so every MSRP session set up through Section 8.2 and Section 8.3 is only ever carrying ONE file 💅. That means senders MUST only use that dedicated MSRP session to send the file described in the SDP offer or answer. Senders MUST NOT send additional files over the same MSRP session. One session, one file, no sharing 🙅♀️. It's giving single-purpose energy.
File transfer can happen in a brand new multimedia session made just for it, or inside an existing multimedia session no matter what media is already going on in there 🌸. Of particular note, it can happen inside a session that already has an MSRP session for regular instant messaging 💬. If file transfer starts inside an existing session, the SDP offerer MUST NOT reuse an existing "m=" line that is still being used by MSRP (whether that's regular instant messaging or an ongoing file transfer) 🚫. Instead, it MUST add an additional "m=" line, or else reuse an "m=" line that is no longer being used ✨.
Also, implementations following this spec MUST include a single file in a single MSRP message 📦. Quick reminder: MSRP defines an "MSRP message" as a complete unit of MIME or text content, which can get split up and delivered across more than one MSRP request. Each of those pieces is called a "chunk" 🧩. So yes, it's still totally valid to send a file in several chunks, but from MSRP's point of view, all the chunks together form ONE MSRP message: the Common Presence and Instant Messaging (CPIM) message that wraps the file 🎀. When chunking, it's worth noticing that MSRP does not require waiting for a 200-class response for a chunk before sending the next one. So it's valid to send pipelined MSRP SEND requests containing chunks of the same MSRP message (the file). Section 9.1 has an example of a file transfer using pipelined MSRP requests 🍓.
The MSRP specification [RFC4975] defines a 'max-size' SDP attribute 📏. It specifies the maximum number of octets of an MSRP message that the creator of the SDP is willing to receive (remember that 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 🛑.
If there's no '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 (aka the whole file gets sent) 🌈. If a 'file-range' attribute IS present, 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 hands the content (e.g., the message/cpim body) over to MSRP for transportation. MSRP will treat the delivered content as a whole message, and will start numbering bytes with the number 1 🔢.
Heads up: 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 for closing MSRP sessions 👋. Also, MSRP session management is not related to TCP connection management, fr 🤯. As a matter of fact, MSRP lets multiple MSRP sessions share the same TCP connection 🧦.
8.8. Considerations about the 'file-icon' Attribute 🖼️
This spec lets a file sender include a tiny preview of an image file: an icon 🌷. A 'file-icon' attribute contains a Content-ID (CID) URL [RFC2392] pointing to an additional body that holds the actual icon. Since the icon is sent as a separate body alongside the SDP body, the file sender MUST wrap the SDP body and the icon bodies in a MIME multipart/related body 🎁. So implementations following this spec 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 🧠.
Picture this: an endpoint following this spec tries to send a file to a remote endpoint that neither implements this spec NOR implements multipart MIME bodies 😬. The file sender sends an SDP offer containing a multipart/related MIME body with 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 gives some backwards compatibility with file receivers that don't implement this spec, and boosts the chances of the SDP getting 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 still provide significance 🤏.
9. Examples ✨
9.1. Offerer Sends a File to the Answerer ✨
okay so this example walks through a whole file transfer from start to finish 🎀 It assumes SIP [RFC3261] is carrying the SDP offer/answer exchange, but we only briefly peek at the SIP parts so it doesn't get too long 💅
Alice is the SDP offerer, and she wants to send a picture to Bob (the answerer) 🦋 Alice's User Agent Client (UAC) makes a unidirectional SDP offer that describes the file she's sending to Bob's User Agent Server (UAS). The description also includes an icon that represents what's inside the file. Here's the whole flow 👑
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 7: Flow diagram of an offerer sending a file to an answerer
F1: Alice builds an SDP description of the file she wants to send and attaches it to a SIP INVITE request addressed to Bob 📎
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
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-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
a=file-disposition:render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.example.com
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
[...small preview icon of the file...]
--boundary71--Figure 8: INVITE request containing an SDP offer for file transfer
NOTE: The Content-Type header field and the 'file-selector' attribute in the above figure are split in several lines for formatting purposes. Real implementations will encode it in a single line.
From here on we're skipping the SIP details to keep things moving 🙈
F2: Bob gets the INVITE, checks out the SDP offer, pulls out the icon body, double-checks the creation date and file size, and decides yes, he wants it 😭 So Bob sends back this 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-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvEFigure 9: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split in three lines for formatting purposes. Real implementations will encode it in a single line.
F4: Alice opens a TCP connection to Bob and creates an MSRP SEND request 🚀 This SEND request carries the first chunk of the file.
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2048/4385
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool picture.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300";
size=4092
Content-Type: image/jpeg
... first set of bytes of the JPEG image ...
-------d93kswow+Figure 10: MSRP SEND request containing the first chunk of actual file
F5: Alice sends the second and last chunk 🫶 Quick tea: MSRP lets you send pipelined chunks, so there's no need to wait for the 200 (OK) response to the previous chunk. Efficient and iconic 🔥
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 11: MSRP SEND request containing the second chunk of actual file
F6: Bob confirms he got the first chunk ✅
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4385
-------d93kswow$Figure 12: MSRP 200 OK response
F7: Bob confirms he got the second chunk too 🎉
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 13: MSRP 200 OK response
F8: Alice ends the SIP session by sending a SIP BYE request 👋
F9: Bob acknowledges the BYE request and sends back a 200 (OK) response. And that's a whole file delivered, bestie 💜
9.2. Offerer Requests a File from the Answerer and Second File Transfer ✨
okay so in this example, Alice (the SDP offerer) wants to fetch a file from Bob (the SDP answerer) 📁 Alice knows Bob has the exact file she's after, and she learned its hash through some out-of-band mechanism 🔍 The hash selector is enough to produce a file selector that points right at that file, so Alice creates an SDP offer that contains the file descriptor 💖 Bob accepts and sends the file over 🎀 Once Alice has fully received Bob's file, she wants to send Bob a new image file 📸 So she reuses the existing SDP media line with different attributes and updates the description for the new file, sent to Bob's User Agent Server (UAS) 💅 She also creates a new file transfer identifier, since this is a brand new file transfer operation 🦋 Figure 14 shows the sequence flow.
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 14: Flow diagram of an offerer requesting a file from the answerer and then sending a file to the answer
F1: Alice builds an SDP description of the file she wants to receive and attaches the SDP offer to a SIP INVITE request addressed to Bob 💌
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
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:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2Figure 15: INVITE request containing an SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split in two lines for formatting purposes. Real implementations will encode it in a single line.
From now on we skip the SIP details to keep things brief ✂️
F2: Bob gets the INVITE request, checks out the SDP offer, works out the file descriptor, and finds a local file whose hash matches the one in the SDP 🕵️♀️ He accepts the file transfer and creates an SDP answer like this:
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-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2Figure 16: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split in two lines for formatting purposes. Real implementations will encode it in a single line.
F4: Alice opens a TCP connection to Bob 🔌 Then Bob builds an MSRP SEND request that carries the file 🎁
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
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 +0300";
modification-date="Mon, 15 May 2006 16:04:53 +0300";
read-date="Mon, 16 May 2006 09:12:27 +0300";
size=1931
Content-Type: image/jpeg
...binary JPEG image...
-------d93kswow$Figure 17: MSRP SEND request containing the actual file
F5: Alice confirms she got the SEND request 🥰
MSRP d93kswow 200 OK
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
Byte-Range: 1-2027/2027
-------d93kswow$Figure 18: MSRP 200 OK response
F6: Alice reuses the existing SDP media line, drops in the description of the file she's sending, and attaches it to a SIP re-INVITE request addressed to Bob 🔁 She keeps the TCP port number for the MSRP stream, but changes the MSRP session and the 'file-transfer-id' value to follow this specification ✨
INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>;tag=1928323431
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 2 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:33 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/related; type="application/sdp";
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 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/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-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300"
a=file-icon:cid:id3@alicepc.example.com
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id3@alicepc.example.com>
Content-Length: [length of image]
Content-Disposition: icon
[..small preview icon...]
--boundary71--Figure 19: Reuse of the SDP in a second file transfer
NOTE: The Content-Type header field and the 'file-selector' attribute in the above figure are split in several lines for formatting purposes. Real implementations will encode it in a single line.
F7: Bob gets the re-INVITE request, checks the SDP offer, pulls out the icon body, checks the creation date and file size, and decides to accept the transfer 🙌 So he builds an SDP answer where he keeps the same TCP port number but changes his MSRP session, following the procedures of this specification 🌸
v=0
o=bob 2890844656 2890855440 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/eh10dsk;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:renderFigure 20: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split in three lines for formatting purposes. Real implementations will encode it in a single line.
F9: If a TCP connection towards Bob is already open, Alice reuses that connection to send an MSRP SEND request carrying the file 🚀
MSRP d95ksxox SEND
To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 13449sdqwer
Byte-Range: 1-2027/2027
Content-Type: message/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-21T13:02:15-03:00
Content-Disposition: render; filename="Sunset.jpg";
creation-date="Sun, 21 May 2006 13:02:15 -0300";
size=1931
Content-Type: image/jpeg
...binary JPEG image...
-------d95ksxox+Figure 21: MSRP SEND request containing the actual file
F10: Bob confirms he got the SEND request 💜
MSRP d95ksxox 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
Byte-Range: 1-2027/2027
-------d95ksxox$Figure 22: MSRP 200 OK response
F11: Then Bob wraps up the SIP session by sending a SIP BYE request 👋
F12: Alice acknowledges the BYE request and sends back a 200 (OK) response 🎀
9.3. Example of a Capability Indication 🧚
okay so Alice sends an OPTIONS request to Bob (no SDP in this one) 📨 Bob answers with a 200 (OK) response that contains the SDP shown in Figure 24 🙌 That SDP says Bob supports CPIM messages that can carry other MIME types 💌 The biggest MSRP message the endpoint can receive is 20000 octets 📏 And the presence of the 'file-selector' attribute tells Alice that Bob supports the file transfer offer/answer mechanism 💖
Alice's UAC Bob's UAS
| |
|(1) (SIP) OPTIONS |
|----------------------->|
|(2) (SIP) 200 OK |
| with SDP |
|<-----------------------|
| |
| |Figure 23: Flow diagram of a capability request
v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=-
c=IN IP4 bobpc.example.com
t=0 0
m=message 0 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=max-size:20000
a=file-selectorFigure 24: SDP of the 200 (OK) response to an OPTIONS request
10. Security Considerations 🔒✨
Okay bestie, security time, and it's serious but also kind of iconic 💅. The SDP attributes in this spec identify a file that two endpoints are about to swap. An endpoint can offer to send the file to the other side, or request to receive one from them. If it's the offer-to-send case, an attacker who messes with those attributes could trick the receiver into thinking the file is a totally different one 💀. In the request-to-receive case, the attacker could make the sender ship a different file than the one the receiver actually asked for. So it is RECOMMENDED that integrity protection be applied to the SDP session descriptions carrying the attributes in this spec 🛡️. It is also RECOMMENDED that senders verify the properties of the file against the selectors that describe it 🎀.
The descriptions of the files being moved around can reveal info the endpoints might consider confidential 👀. So it is RECOMMENDED that SDP session descriptions carrying the attributes in this spec are encrypted 🔐.
TLS and S/MIME are the natural choices for offer/answer exchanges that need both integrity protection and confidentiality 🫶.
When an SDP offer contains the description of a file to be sent or received, the SDP answerer MUST first authenticate the SDP offerer, and then it MUST authorize the file transfer operation, typically according to a local policy 🚦. Usually these functions are built into the high-level protocol that carries SDP (like SIP), and into the file transfer protocol (like MSRP) 🧚. If SIP [RFC3261] and MSRP [RFC4975] are used, the standard mechanisms for user authentication and authorization are sufficient ✨.
Heads up: a malicious or misbehaving implementation can try to exhaust the resources of the remote endpoint, like its internal memory or file system, by sending very large files 😭. To protect from this, an SDP answer SHOULD first verify the identity of the SDP offerer, and perhaps only accept file transfers from trusted sources 🙈. How you verify the identity of the file sender depends on the high-level protocol carrying the SDP, for example SIP [RFC3261] and MSRP [RFC4975].
It is also RECOMMENDED that implementations take measures to avoid resource exhaustion attacks 🌸. For example, they can limit the size of received files, verify that there is enough space in the file system to store the file before it's received, or limit the number of simultaneous file transfers 🍓.
File receivers MUST also sanitize all input, such as the local file name, before making calls to the local file system to store a file 🧼. This is to stop meaningful characters to the local operating system from showing up and damaging it 💥.
Once a file has been transferred, the file receiver must take care of it 🫧. File transfer is a super common way to spread computer viruses, spyware, and other kinds of malware, so file receivers should apply all possible security technologies (e.g., anti-virus, anti-spyware) to reduce the risk of damage to their host 🦋.
11. IANA Considerations 📋
IANA has registered a number of SDP attributes according to the following 🌈.
11.1. Registration of New SDP Attributes
IANA has registered a number of media-level-only attributes in the Session Description Protocol Parameters registry [IANA]. The registration data, according to RFC 4566 [RFC4566], follows 💜.
11.1.1. Registration of the file-selector Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: file-selector
Long-form attribute name: File Selector
Type of attribute: media level only
This attribute is subject to the charset attribute
Description: This attribute unambiguously identifies a file by
indicating a combination of the 4-tuple composed of the name,
size, type, and hash of the file.
Specification: RFC 554711.1.2. Registration of the file-transfer-id Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: file-transfer-id
Long-form attribute name: File Transfer Identifier
Type of attribute: media level only
This attribute is subject to the charset attribute
Description: This attribute contains a unique identifier of the file
transfer operation within the session.
Specification: RFC 554711.1.3. Registration of the file-disposition Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: file-disposition
Long-form attribute name: File Disposition
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: This attribute provides a suggestion to the other
endpoint about the intended disposition of the file.
Specification: RFC 554711.1.4. Registration of the file-date Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: file-date
Long-form attribute name:
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: This attribute indicates the dates on which the file
was created, modified, or last read.
Specification: RFC 554711.1.5. Registration of the file-icon Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: file-icon
Long-form attribute name: File Icon
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: For image files, this attribute contains a pointer to a
body that includes a small preview icon representing the contents
of the file to be transferred.
Specification: RFC 554711.1.6. Registration of the file-range Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: file-range
Long-form attribute name: File Range
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: This attribute contains the range of transferred octets
of the file.
Specification: RFC 554712. Acknowledgments 🙌
The authors would like to thank Mats Stille, Nancy Greene, Adamu Haruna, and Arto Leppisaari for discussing the initial concepts described in this memo 💖. Thanks to Pekka Kuure for reviewing initial versions of this document and giving helpful comments ✨. Joerg Ott, Jiwey Wang, Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis-Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, Richard Barnes, and Chris Newman discussed the document and gave comments and improvements 👑.
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.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183,
August 1997.
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2387, August 1998.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform
Resource Locators", RFC 2392, August 1998.
[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.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862,
August 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975,
September 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.13.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Session Initiation Protocol (SIP)", RFC 4028,
April 2005.
[RFC4483] Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483,
May 2006.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)",
RFC 4976, September 2007.
[IANA] IANA, "Internet Assigned Numbers Authority",
<http://www.iana.org>.
[FLUTE-REV] Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE -
File Delivery over Unidirectional Transport", Work
in Progress, September 2008.Appendix A. Alternatives Considered 🦋
Okay so the requirements are all about describing and negotiating the session, not the actual file transfer mechanism 💅 So it's enough to define attribute extensions and usage conventions for SDP, and MSRP itself needs no extensions and can be used as it is. That's basically the approach this spec takes ✨ Another goal was making the SDP extensions work so a regular MSRP endpoint that doesn't support them could still act as an endpoint in a file transfer session in some cases, just with a somewhat reduced vibe 🥺
Lowkey, this spec is similar to the goal of content indirection in the Session Initiation Protocol (SIP) [RFC4483] 🎀 Both let a user agent decide whether to download a file based on info about the file. But there are some differences, bestie:
- With content indirection, the other endpoint can't explicitly accept or reject the file transfer 🙈
- It's also not possible for an endpoint to request a file from another endpoint 💀
- Content indirection isn't tied to the context of a media session, which is sometimes a desirable property 🌸
- Content indirection typically needs some server infrastructure, which may not always be available 😭
It's possible to use content indirection directly between the endpoints too, but then there's no definition for how it works for endpoints behind NATs 🧚 And honestly, the level of requirements in implementations is what decides which solution meets the requirements 👑
So based on all that, this document defines the SDP attribute extensions and usage conventions needed to meet the requirements on file transfer services with the SDP offer/answer model, using MSRP as the transfer protocol within the session. Slay 💖
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. Essentially, such a protocol should be able to be negotiated on an SDP offer/answer exchange (RFC 3264 [RFC3264]), be able to describe the file to be transferred in SDP offer/answer exchange, be able to carry MIME objects between two endpoints, and use a reliable transport protocol (e.g., TCP). 🌈
This specification defines a set of SDP attributes that describe a file to be transferred between two endpoints 🍓 The info needed to describe a file could be encoded in a few different ways, so the MMUSIC working group looked at some alternatives before deciding to use the encoding described in Section 6 🫶 In particular, they checked out the MIME 'external-body' type and the idea of using a single SDP attribute or parameter.
A MIME 'external-body' could potentially be used to describe the file to be transferred. Honestly, a lot of the SDP parameters this spec defines are also supported by 'external-body' body parts ✨ But MMUSIC decided not to use 'external-body' body parts because a number of existing offer/answer implementations don't support multipart bodies 😭
The info carried in the SDP attributes defined in Section 6 could potentially be encoded in a single SDP attribute. The MMUSIC working group decided against that because implementations are expected to support only a subset of the parameters defined in Section 6 💅 Those implementations can use regular SDP rules to ignore non-supported SDP parameters. If everything was crammed into a single SDP attribute, those rules, which relate to backwards compatibility, would need to be redefined specifically for that parameter 🙃 Not it 💀
Authors' Addresses 💜
Miguel A. Garcia-Martin
Ericsson
Calle Via de los Poblados 13
Madrid, ES 28033
Spain
EMail: miguel.a.garcia@ericsson.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
Paul H. Kyzivat
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: pkyzivat@cisco.comThat's the whole squad, bestie 🎀🌈 Thank you for reading all eleven parts with me, you're literally the best 🫶✨
📦 where this page comes from
- ietf: rfc5547 2009-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms