idnits 2.17.1 draft-ietf-simple-message-sessions-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2647. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Receivers MUST not assume that the chunks will be delivered in order or that they will receive all the chunks with "+" flags before they receive the chunk with the "$" flag. In certain cases of connection failure, it is possible for information to be duplicated. If chunk data is received that overlaps already received data for the same message, the last chunk received SHOULD take precedence (even though this may not have been the last chunk transmitted). For example, if bytes 1 to 100 were received and a chunk arrives that contains bytes 50 to 150, this second chunk will overwrite bytes 50 to 100 of the data that had already been received. Although other schemes work, this is the easiest for the receiver and results in consistent behavior between clients. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an endpoint puts more than one URL in a path attribute, the final URL in the path attribute (the peer URL) identifies the session, and MUST not duplicate the URL of any other session in which the endpoint is currently participating. Uniqueness requirements for other entries in the path attribute are out of scope for this document. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2006) is 6508 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 2353 ** Obsolete normative reference: RFC 2246 (ref. '1') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3851 (ref. '7') (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 3546 (ref. '11') (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 3268 (ref. '13') (Obsoleted by RFC 5246) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-06 == Outdated reference: A later version (-10) exists of draft-ietf-simple-msrp-relays-07 -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. '29') (Obsoleted by RFC 6121) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Campbell, Ed. 3 Internet-Draft Estacado Systems 4 Expires: December 26, 2006 R. Mahy, Ed. 5 Plantronics 6 C. Jennings, Ed. 7 Cisco Systems, Inc. 8 June 24, 2006 10 The Message Session Relay Protocol 11 draft-ietf-simple-message-sessions-15 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 26, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document describes the Message Session Relay Protocol, a 45 protocol for transmitting a series of related instant messages in the 46 context of a session. Message sessions are treated like any other 47 media stream when set up via a rendezvous or session creation 48 protocol such as the Session Initiation Protocol. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Applicability of MSRP . . . . . . . . . . . . . . . . . . . . 5 55 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 5.1. MSRP Framing and Message Chunking . . . . . . . . . . . . 9 58 5.2. MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 10 59 5.3. MSRP Transaction and Report Model . . . . . . . . . . . . 10 60 5.4. MSRP Connection Model . . . . . . . . . . . . . . . . . . 12 61 6. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 6.1. MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15 63 6.2. Resolving MSRP Host Device . . . . . . . . . . . . . . . 16 64 7. Method-Specific Behavior . . . . . . . . . . . . . . . . . . . 16 65 7.1. Constructing Requests . . . . . . . . . . . . . . . . . . 16 66 7.1.1. Sending SEND Requests . . . . . . . . . . . . . . . . 18 67 7.1.2. Sending REPORT Requests . . . . . . . . . . . . . . . 21 68 7.1.3. Generating Success Reports . . . . . . . . . . . . . . 21 69 7.1.4. Generating Failure Reports . . . . . . . . . . . . . . 22 70 7.2. Constructing Responses . . . . . . . . . . . . . . . . . 23 71 7.3. Receiving Requests . . . . . . . . . . . . . . . . . . . 24 72 7.3.1. Receiving SEND Requests . . . . . . . . . . . . . . . 24 73 7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 26 74 8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 27 75 8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 27 76 8.2. URL Negotiations . . . . . . . . . . . . . . . . . . . . 28 77 8.3. Path Attributes with Multiple URLs . . . . . . . . . . . 29 78 8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 30 79 8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 30 80 8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 31 81 8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 32 82 8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 33 83 8.9. SDP direction attribute and MSRP . . . . . . . . . . . . 34 84 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 34 85 10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 36 86 10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 87 10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 88 10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 89 10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 90 10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 91 10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 93 10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 95 10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 96 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 97 11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 38 98 11.2. Message with XHTML Content . . . . . . . . . . . . . . . 41 99 11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 41 100 11.4. System Message . . . . . . . . . . . . . . . . . . . . . 41 101 11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 42 102 11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 42 103 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 45 104 13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 45 105 14. Security Considerations . . . . . . . . . . . . . . . . . . . 46 106 14.1. Transport Level Protection . . . . . . . . . . . . . . . 46 107 14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 48 108 14.3. Using TLS in Peer to Peer Mode . . . . . . . . . . . . . 48 109 14.4. Other Security Concerns . . . . . . . . . . . . . . . . . 50 110 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 111 15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 52 112 15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 52 113 15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 52 114 15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 53 115 15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 53 116 15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 53 117 15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 53 118 15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 53 119 15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 54 120 15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 54 121 15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 54 122 16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 55 123 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 124 17.1. Normative References . . . . . . . . . . . . . . . . . . 55 125 17.2. Informational References . . . . . . . . . . . . . . . . 56 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 127 Intellectual Property and Copyright Statements . . . . . . . . . . 59 129 1. Introduction 131 A series of related instant messages between two or more parties can 132 be viewed as part of a "message session", that is, a conversational 133 exchange of messages with a definite beginning and end. This is in 134 contrast to individual messages each sent independently. Messaging 135 schemes that track only individual messages can be described as 136 "page-mode" messaging, whereas messaging that is part of a "session" 137 with a definite start and end is called "session-mode" messaging. 139 Page-mode messaging is enabled in SIP via the SIP [4] MESSAGE method 140 [21]. Session-mode messaging has a number of benefits over page-mode 141 messaging, however, such as explicit rendezvous, tighter integration 142 with other media types, direct client-to-client operation, and 143 brokered privacy and security. 145 This document defines a session-oriented instant message transport 146 protocol called the Message Session Relay Protocol (MSRP), whose 147 sessions can be negotiated with an offer or answer [3] using the 148 Session Description Protocol(SDP [2]). The exchange is carried by 149 some signaling protocol, such as the Session Initiation Protocol (SIP 150 [4]). This allows a communication user agent to offer a messaging 151 session as one of the possible media types in a session. For 152 instance, Alice may want to communicate with Bob. Alice doesn't know 153 at the moment whether Bob has his phone or his IM client handy, but 154 she's willing to use either. She sends an invitation to a session to 155 the address of record she has for Bob, sip:bob@example.com. Her 156 invitation offers both voice and an IM session. The SIP services at 157 example.com forward the invitation to Bob at his currently registered 158 clients. Bob accepts the invitation at his IM client and they begin 159 a threaded chat conversation. 161 When a user uses an IM URL, RFC 3861 [31] defines how DNS can be used 162 to map this to a particular protocol to establish the session such as 163 SIP. SIP can use an offer answer model to transport the MSRP URLs 164 for the media in SDP. This document defines how the offer/answer 165 exchange works to establish MSRP connections and how messages are 166 sent across the MSRP protocol, but it does not deal with the issues 167 of mapping an IM URL to a session establishment protocol. 169 This session model allows message sessions to be integrated into 170 advanced communications applications with little to no additional 171 protocol development. For example, during the above chat session, 172 Bob decides Alice really needs to be talking to Carol. Bob can 173 transfer [20] Alice to Carol, introducing them into their own 174 messaging session. Messaging sessions can then be easily integrated 175 into call-center and dispatch environments using third-party call 176 control [19] and conferencing [18] applications. 178 This document specifies MSRP behavior only for peer-to-peer sessions, 179 that is, sessions crossing only a single hop. MSRP relay devices 180 [22] (referred to herein as "relays") are specified in a separate 181 document. 183 2. Conventions 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC-2119 [5]. 189 This document consistently refers to a "message" as a complete unit 190 of MIME or text content. In some cases, a message is split and 191 delivered in more than one MSRP request. Each of these portions of 192 the complete message is called a "chunk". 194 3. Applicability of MSRP 196 MSRP is not designed for use as a standalone protocol. MSRP MUST be 197 used only in the context of a rendezvous mechanism meeting the 198 following requirements: 200 The rendezvous mechanism MUST provide both MSRP URLs associated 201 with an MSRP session to each of the participating endpoints. The 202 rendezvous mechanism MUST implement mechanisms to protect the 203 confidentiality of these URLs - they MUST NOT be made available to 204 an untrusted third party or be easily discoverable. 206 The rendezvous mechanism MUST provide mechanisms for the 207 negotiation of any supported MSRP extensions that are not 208 backwards compatible. 210 The rendezvous mechanism MUST be able to natively transport im: 211 URIs or automatically translate im: URIs [26] into the addressing 212 identifiers of the rendezvous protocol. 214 To use a rendezvous mechanism with MSRP, an RFC MUST be prepared 215 describing how it exchanges MSRP URLs and meets these requirements 216 listed here. This document provides such a description for the use 217 of MSRP in the context of SIP and SDP. 219 SIP meets these requirements for a rendezvous mechanism. The MSRP 220 URLs are exchanged using SDP in an offer/answer exchange via SIP. 221 The exchanged SDP can also be used to negotiate MSRP extensions. 222 This SDP can be secured using any of the mechanisms available in SIP, 223 including using the sips mechanism to ensure transport security 224 across intermediaries and S/MIME for end-to-end protection of the SDP 225 body. SIP can carry arbitrary URIs (including im: URIs) in the 226 Request-URI, and procedures are available to map im: URIs to sip: or 227 sips: URIs. It is expected that initial deployments of MSRP will use 228 SIP as its rendezvous mechanism. 230 4. Protocol Overview 232 MSRP is a text-based, connection-oriented protocol for exchanging 233 arbitrary (binary) MIME[8] content, especially instant messages. 234 This section is a non-normative overview of how MSRP works and how it 235 is used with SIP. 237 MSRP sessions are typically arranged using SIP the same way a session 238 of audio or video media is set up. One SIP user agent (Alice) sends 239 the other (Bob) a SIP invitation containing an offered session- 240 description which includes a session of MSRP. The receiving SIP user 241 agent can accept the invitation and include an answer session- 242 description which acknowledges the choice of media. Alice's session 243 description contains an MSRP URL that describes where she is willing 244 to receive MSRP requests from Bob, and vice-versa. (Note: Some lines 245 in the examples are removed for clarity and brevity.) 246 Alice sends to Bob: 248 INVITE sip:bob@biloxi.example.com SIP/2.0 249 To: 250 From: ;tag=786 251 Call-ID: 3413an89KU 252 Content-Type: application/sdp 254 c=IN IP4 atlanta.example.com 255 m=message 7654 TCP/MSRP * 256 a=accept-types:text/plain 257 a=path:msrp://atlanta.example.com:7654/jshA7we;tcp 259 Bob sends to Alice: 261 SIP/2.0 200 OK 262 To: ;tag=087js 263 From: ;tag=786 264 Call-ID: 3413an89KU 265 Content-Type: application/sdp 267 c=IN IP4 biloxi.example.com 268 m=message 12763 TCP/MSRP * 269 a=accept-types:text/plain 270 a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 272 Alice sends to Bob: 274 ACK sip:bob@biloxi SIP/2.0 275 To: ;tag=087js 276 From: ;tag=786 277 Call-ID: 3413an89KU 279 MSRP defines two request types, or methods. SEND requests are used 280 to deliver a complete message or a chunk (a portion of a complete 281 message), while REPORT requests report on the status of a previously 282 sent message, or a range of bytes inside a message. When Alice 283 receives Bob's answer, she checks to see if she has an existing 284 connection to Bob. If not, she opens a new connection to Bob using 285 the URL he provided in the SDP. Alice then delivers a SEND request 286 to Bob with her initial message, and Bob replies indicating that 287 Alice's request was received successfully. 289 MSRP a786hjs2 SEND 290 To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 291 From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp 292 Message-ID: 87652 293 Byte-Range: 1-25/25 294 Content-Type: text/plain 296 Hey Bob, are you there? 297 -------a786hjs2$ 299 MSRP a786hjs2 200 OK 300 To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp 301 From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 302 Byte-Range: 1-25/25 303 -------a786hjs2$ 305 Alice's request begins with the MSRP start line, which contains a 306 transaction identifier that is also used for request framing. Next 307 she includes the path of URLs to the destination in the To-Path 308 header field, and her own URL in the From-Path header field. In this 309 typical case there is just one "hop", so there is only one URL in 310 each path header field. She also includes a message ID which she can 311 use to correlate status reports with the original message. Next she 312 puts the actual content. Finally she closes the request with an end- 313 line of seven hyphens, the transaction identifier and a "$" to 314 indicate this request contains the end of a complete message. 316 If Alice wants to deliver a very large message, she can split the 317 message into chunks and deliver each chunk in a separate SEND 318 request. The message ID corresponds to the whole message, so the 319 receiver can also use it to reassemble the message and tell which 320 chunks belong with which message. Chunking is described in more 321 detail in Section 5.1. The Byte-Range header field identifies the 322 portion of the message carried in this chunk and the total size of 323 the message. 325 Alice can also specify what type of reporting she would like in 326 response to her request. If Alice requests positive acknowledgments, 327 Bob sends a REPORT request to Alice confirming the delivery of her 328 complete message. This is especially useful if Alice sent a series 329 of SEND request containing chunks of a single message. More on 330 requesting types of reports and errors is described in Section 5.3. 332 Alice and Bob generally choose their MSRP URLs in such a way that is 333 difficult to guess the exact URL. Alice and Bob can reject requests 334 to URLs they are not expecting to service, and can correlate the 335 specific URL with the probable sender. Alice and Bob can also use 336 TLS [1] to provide channel security over this hop. To receive MSRP 337 requests over a TLS protected connection, Alice or Bob could 338 advertise URLs with the "msrps" scheme instead of "msrp." 340 MSRP is designed with the expectation that MSRP can carry URLs for 341 nodes on the far side of relays. For this reason, a URL with the 342 "msrps" scheme makes no assertion about the security properties of 343 other hops, just the next hop. The user agent knows the URL for each 344 hop, so it can verify that each URL has the desired security 345 properties. 347 MSRP URLs are discussed in more detail in Section 6. 349 An adjacent pair of busy MSRP nodes (for example two relays) can 350 easily have several sessions, and exchange traffic for several 351 simultaneous users. The nodes can use existing connections to carry 352 new traffic with the same destination host, port, transport protocol, 353 and scheme. MSRP nodes can keep track of how many sessions are using 354 a particular connection and close these connections when no sessions 355 have used them for some period of time. Connection management is 356 discussed in more detail in Section 5.4. 358 5. Key Concepts 360 5.1. MSRP Framing and Message Chunking 362 Messages sent using MSRP can be very large and can be delivered in 363 several SEND requests, where each SEND request contains one chunk of 364 the overall message. Long chunks may be interrupted in mid- 365 transmission to ensure fairness across shared transport connections. 366 To support this, MSRP uses a boundary-based framing mechanism. The 367 start line of an MSRP request contains a unique identifier that is 368 also used to indicate the end of the request. Included at the end of 369 the end-line, there is a flag that indicates whether this is the last 370 chunk of data for this message or whether the message will be 371 continued in a subsequent chunk. There is also a Byte-Range header 372 field in the request that indicates that the overall position of this 373 chunk inside the complete message. 375 For example, the following snippet of two SEND requests demonstrates 376 a message that contains the text "abcdEFGH" being sent as two chunks. 378 MSRP dkei38sd SEND 379 Message-ID: 456 380 Byte-Range: 1-4/8 381 Content-Type: text/plain 383 abcd 384 -------dkei38sd+ 386 MSRP dkei38ia SEND 387 Message-ID: 456 388 Byte-Range: 5-8/8 389 Content-Type: text/plain 391 EFGH 392 -------dkei38ia$ 394 This chunking mechanism allows a sender to interrupt a chunk part of 395 the way through sending it. The ability to interrupt messages allows 396 multiple sessions to share a TCP connection, and for large messages 397 to be sent efficiently while not blocking other messages that share 398 the same connection, or even the same MSRP session. Any chunk that 399 is larger than 2048 octets MUST be interruptible. While MSRP would 400 be simpler to implement if each MSRP session used its own TCP 401 connection, there are compelling reasons to conserve connection. For 402 example, the TCP peer may be a relay device that connects to many 403 other peers. Such a device will scale better if each peer does not 404 create a large number of connections. 406 The chunking mechanism only applies to the SEND method, as it is the 407 only method used to transfer message content. 409 5.2. MSRP Addressing 411 MSRP entities are addressed using URLs. The MSRP URL schemes are 412 defined in Section 6. The syntax of the To-Path and From-Path header 413 fields each allow for a list of URLs. This was done to allow the 414 protocol to work with relays, which are defined in a separate 415 document, to provide a complete path to the end recipient. When two 416 MSRP nodes communicate directly they need only one URL in the To-Path 417 list and one URL in the From-Path list. 419 5.3. MSRP Transaction and Report Model 421 A sender sends MSRP requests to a receiver. The receiver MUST 422 quickly accept or reject the request. If the receiver initially 423 accepted the request, it still may then do things that take 424 significant time to succeed or fail. For example, if the receiver is 425 an MSRP to XMPP [29] gateway, it may forward the message over XMPP. 427 The XMPP side may later indicate that the request did not work. At 428 this point, the MSRP receiver may need to indicate that the request 429 did not succeed. There are two important concepts here: first, the 430 hop by hop delivery of the request may succeed or fail; second, the 431 end result of the request may be successfully processed or not. The 432 first type of status is referred to as "transaction status" and may 433 be returned in response to a request. The second type of status is 434 referred to as "delivery status" and may be returned in a REPORT 435 transaction. 437 The original sender of a request can indicate if they wish to receive 438 reports for requests that fail, and can independently indicate if 439 they wish to receive reports for requests that succeed. A receiver 440 only sends a success REPORT if it knows that the request was 441 successfully delivered, and the sender requested a success report. A 442 receiver only sends a failure REPORT if the request failed to be 443 delivered and the sender requested failure reports. 445 This document describes the behavior of MSRP endpoints. MSRP 446 relays will introduce additional conditions that indicate a 447 failure REPORT should be sent, such as the failure to receive a 448 positive response from the next hop. 450 Two header fields control the sender's desire to receive reports. 451 The header field "Success-Report" can have a value of "yes" or "no" 452 and the "Failure-Report" header field can have a value of "yes", 453 "no", or "partial". 455 The combinations of reporting are needed to meet the various 456 scenarios of currently deployed IM systems. Success-Report might be 457 "no" in many public systems to reduce load but might be "yes" in 458 certain enterprise systems, such as systems used for securities 459 trading. A Failure-Report value of "no" is useful for sending system 460 messages such as "the system is going down in 5 minutes" without 461 causing a response explosion to the sender. A Failure-Report of 462 "yes" is used by many systems that wish to notify the user if the 463 message failed. A Failure-Report of "partial" is a way to report 464 errors other than timeouts. The timeout error reporting requires the 465 sending hop to run a timer and the receiving hop to send an 466 acknowledgment to stop the timer. Some systems don't want the 467 overhead of doing this. "Partial" allows them to choose not to do 468 so, but still allows error responses to be sent in many cases. 470 The term "partial" denotes the fact that the hop-by-hop 471 acknowledgment mechanism that would be required if with a Failure- 472 Report value of "yes" is not invoked. Thus, each device uses only 473 "part" of the set of error detection tools available to them. 474 This allows a compromise between no reporting of failures at all, 475 and reporting every possible failure. For example, with 476 "partial", an sending device does not have to keep transaction 477 state around waiting for a positive acknowledgment. But it still 478 allows devices to report other types of errors. The receiving 479 device could still report a policy violation such as an 480 unacceptable content-type, or an ICMP error trying to connect to a 481 downstream device. 483 5.4. MSRP Connection Model 485 When an MSRP endpoint wishes to send a request to a peer identified 486 by an MSRP URL, it first needs a transport connection, with the 487 appropriate security properties, to the host specified in the URL. 488 If the sender already has such a connection, that is, one associated 489 with the same host, port, and URL scheme, then it SHOULD reuse that 490 connection. 492 When a new MSRP session is created, the initiating endpoint MUST act 493 as the "active" endpoint, meaning that it is responsible for opening 494 the transport connection to the answerer, if a new connection is 495 required. However, this requirement MAY be weakened if standardized 496 mechanisms for negotiating the connection direction become available, 497 and is implemented by both parties to the connection. 499 Likewise, the active endpoint MUST immediately issue a SEND request. 500 This initial SEND request MAY have a body if the sender has content 501 to send, or it MAY have no body at all. 503 The first SEND request serves to bind a connection to an MSRP 504 session from the perspective of the passive endpoint. If the 505 connection is not authenticated with TLS, and the active endpoint 506 did not send an immediate request, the passive endpoint would have 507 no way to determine who had connected, and would not be able to 508 safely send any requests towards the active party until after the 509 active party sends its first request. 511 When an element needs to form a new connection, it looks at the URL 512 to decide on the type of connection (TLS, TCP, etc.) then connects to 513 the host indicated by the URL, following the URL resolution rules in 514 Section 6.2. Connections using the "msrps" scheme MUST use TLS. The 515 SubjectAltName in the received certificate MUST match the hostname 516 part of the URL and the certificate MUST be valid, including having a 517 date that is valid and being signed by an acceptable certificate 518 authority. At this point the device that initiated the connection 519 can assume that this connection is with the correct host. 521 The rules on certificate name matching and CA signing MAY be relaxed 522 when using TLS peer-to-peer. In this case, a mechanism to ensure 523 that the peer used a correct certificate MUST be used. See 524 Section 14.3 for details. 526 If the connection used mutual TLS authentication, and the TLS client 527 presented a valid certificate, then the element accepting the 528 connection can immediately know the identity of the connecting host. 529 When mutual TLS authentication is not used, the listening device MUST 530 wait until it receives a request on the connection, at which time it 531 infers the identity of the connecting device from the associated 532 session description. 534 When the first request arrives, its To-Path header field should 535 contain a URL that the listening element provided in the SDP for a 536 session. The element that accepted the connection looks up the URL 537 in the received request, and determines which session it matches. If 538 a match exists, the node MUST assume that the host that formed the 539 connection is the host to which this URL was given. If no match 540 exists, the node MUST reject the request with a 481 response. The 541 node MUST also check to make sure the session is not already in use 542 on another connection. If the session is already in use, it MUST 543 reject the request with a 506 response. 545 If it were legal to have multiple connections associated with the 546 same session, a security problem would exist. If the initial SEND 547 request is not protected, an eavesdropper might learn the URL, and 548 use it to insert messages into the session via a different 549 connection. 551 If a connection fails for any reason, then an MSRP endpoint MUST 552 consider any sessions associated with the connection as also having 553 failed. When either endpoint notices such a failure, it MAY attempt 554 to re-create any such sessions. If it chooses to do so, it MUST use 555 a new SDP exchange, for example, in a SIP re-INVITE. If a 556 replacement session is successfully created, endpoints MAY attempt to 557 resend any content for which delivery on the original session could 558 not be confirmed. If it does this, the Message-ID values for the 559 resent messages MUST match those used in the initial attempts. If 560 the receiving endpoint receives more than one message with the same 561 Message-ID, it SHOULD assume that the messages are duplicates. The 562 specific action that an endpoint takes when it receives a duplicate 563 message is a matter of local policy, except that it SHOULD NOT 564 present the duplicate messages to the user without warning of the 565 duplication. Note that acknowledgments as needed based on the 566 Failure-Report and Success-Report settings are still necessary even 567 for requests containing duplicate content. 569 When endpoints create a new session in this fashion, the chunks for a 570 given logical message MAY be split across the sessions. However, 571 endpoints SHOULD NOT split chunks between sessions under non-failure 572 circumstances. 574 If an endpoint attempts to re-create a failed session in this manner, 575 it MUST NOT assume that the MSRP URLs in the SDP will be the same as 576 the old ones. 578 A connection SHOULD NOT be closed while there are sessions associated 579 with it. 581 6. MSRP URLs 583 URLs using the "msrp" and "msrps" schema are used to identify a 584 session of instant messages at a particular MSRP device. MSRP URLs 585 are ephemeral; an MSRP device will generally use a different MSRP URL 586 for each distinct session. An MSRP URL generally has no meaning 587 outside of the associated session. 589 An MSRP URL follows a subset of the URL syntax in Appendix A of 590 RFC3986 [10], with a scheme of "msrp" or "msrps". The syntax is 591 described in Section 9. 593 The constructions for "userinfo", and "unreserved" are detailed in 594 RFC3986 [10]. In order to allow IPV6 addressing, the construction 595 for hostport is that used for SIP in RFC3261. URLs designating MSRP 596 over TCP MUST include the "tcp" transport parameter. 598 Since this document only specifies MSRP over TCP, all MSRP URLs 599 herein use the "tcp" transport parameter. Documents that provide 600 bindings on other transports should define respective parameters 601 for those transports. 603 An MSRP URL hostport field identifies a participant in a particular 604 MSRP session. If the hostport contains a numeric IP address, it MUST 605 also contain a port. The session-id part identifies a particular 606 session of the participant. The absence of the session-id part 607 indicates a reference to an MSRP host device, but does not 608 specifically refer to a particular session. 610 A scheme of "msrps" indicates that the underlying connection MUST be 611 protected with TLS. 613 MSRP has an IANA-registered recommended port defined in Section 15.4. 614 This value is not a default, as the URL negotiation process described 615 herein will always include explicit port numbers. However, the URLs 616 SHOULD be configured so that the recommended port is used whenever 617 appropriate. This makes life easier for network administrators who 618 need to manage firewall policy for MSRP. 620 The hostport will typically not contain a userinfo component, but MAY 621 do so to indicate a user account for which the session is valid. 622 Note that this is not the same thing as identifying the session 623 itself. If a userinfo component exists, it MUST be constructed only 624 from "unreserved" characters, to avoid a need for escape processing. 625 Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo 626 part MUST NOT contain password information. 628 The limitation of userinfo to unreserved characters is an 629 additional restriction to the userinfo definition in RFC3986. 630 That version allows reserved characters. The additional 631 restriction is to avoid the need for escaping. 633 The following is an example of a typical MSRP URL: 635 msrp://host.example.com:8493/asfd34;tcp 637 6.1. MSRP URL Comparison 639 MSRP URL comparisons MUST be performed according to the following 640 rules: 642 1. The scheme MUST match. Scheme comparison is case insensitive. 644 2. If the hostpart contains an explicit IP address, and/or port, 645 these are compared for address and port equivalence. Otherwise, 646 hostpart is compared as a case insensitive character string. 648 3. If the port exists explicitly in either URL, then it MUST match 649 exactly. A URL with an explicit port is never equivalent to 650 another with no port specified. 652 4. The session-id part is compared as case sensitive. A URL without 653 a session-id part is never equivalent to one that includes one. 655 5. URLs with different "transport" parameters never match. Two URLs 656 that are identical except for transport are not equivalent. The 657 transport parameter is case-insensitive. 659 6. Userinfo parts are not considered for URL comparison. 661 Path normalization is not relevant for MSRP URLs. Escape 662 normalization is not required due to character restrictions in the 663 formal syntax. 665 6.2. Resolving MSRP Host Device 667 An MSRP host device is identified by the hostport of an MSRP URL. 669 If the hostport contains a numeric IP address and port, they MUST be 670 used as listed. 672 If the hostport contains a host name and a port, the connecting 673 device MUST determine a host address by doing an A or AAAA DNS query, 674 and use the port as listed. 676 If a connection attempt fails, the device SHOULD attempt to connect 677 to the addresses returned in any additional A or AAAA records, in the 678 order the records were presented. 680 This process assumes that the connection port is always known 681 prior to resolution. This is always true for the MSRP URL uses 682 described in this document, that is, URLs exchanged in the SDP 683 offer and answer. The introduction of relays may create 684 situations where this is not the case. For example, the MSRP URL 685 that a user enters into a client to configure it to use a relay 686 may be intended to be easily remembered and communicated by 687 humans, and therefore is likely to omit the port. Therefore, the 688 relay specification [22] may describe additional steps to resolve 689 the port number. 691 MSRP devices MAY use other methods for discovering other such 692 devices, when appropriate. For example, MSRP endpoints may use other 693 mechanisms to discover relays, which are beyond the scope of this 694 document. 696 7. Method-Specific Behavior 698 7.1. Constructing Requests 700 To form a new request, the sender creates a unique transaction 701 identifier and uses this and the method name to create an MSRP 702 request start line. Next, the sender places the target URL in a To- 703 Path header field, and the sender's URL in a From-Path header field. 704 If multiple URLs are present in the To-Path, the leftmost is the 705 first URL visited; the rightmost URL is the last URL visited. The 706 processing then becomes method specific. Additional method-specific 707 header fields are added as described in the following sections. 709 After any method-specific header fields are added, processing 710 continues to handle a body, if present. If the request has a body, 711 it MUST contain a Content-Type header field. It may contain other 712 MIME-specific header fields. The Content-Type header field MUST be 713 the last field in the message header section. The body MUST be 714 separated from the header fields with an extra CRLF. 716 Non-SEND requests are not intended to carry message content, and are 717 therefore not interruptible. Non-SEND request bodies MUST NOT be 718 larger than 10240 octets. 720 Although this document does not discuss any particular usage of 721 bodies in non-SEND requests, they may be useful in the future for 722 carrying security or identity information, information about a 723 message in progress, etc. The 10K size limit was chosen to be 724 large enough for most of such applications, but small enough to 725 avoid the fairness issues caused by sending arbitrarily large 726 content in non-interruptible method bodies. 728 A request with no body MUST NOT include a Content-Type header field. 729 Note that, if no body is present, no extra CRLF will be present 730 between the header section and the end-line. 732 Requests with no bodies are useful when a client wishes to send 733 "traffic", but does not wish to send content to be rendered to the 734 peer user. For example, the active endpoint sends a SEND request 735 immediately upon establishing a connection. If it has nothing to 736 say at the moment, it can send a request with no body. Bodiless 737 requests may also be used in certain applications to keep NAT 738 bindings alive, etc. 739 Bodiless requests are distinct from requests with empty bodies. A 740 request with an empty body will have a Content-Type header field 741 value, and will generally be rendered to the recipient according 742 to the rules for that type. 744 The end-line that terminates the request MUST be composed of seven 745 "-" (minus sign) characters, the transaction ID as used in the start 746 line, and a flag character. If a body is present, the end-line MUST 747 be preceded by a CRLF that is not part of the body. If the chunk 748 represents the data that forms the end of the complete message, the 749 flag value MUST be a "$". If the sender is aborting an incomplete 750 message, and intends to send no further chunks in that message, it 751 MUST be a "#". Otherwise it MUST be a "+". 753 If the request contains a body, the sender MUST ensure that the end- 754 line (seven hyphens, the transaction identifier, and a continuation 755 flag) is not present in the body. If the end-line is present in the 756 body, the sender MUST choose a new transaction identifier that is not 757 present in the body, and add a CRLF if needed, and the end-line, 758 including the "$", "#", or "+" character. 760 Some implementations may choose to scan for the closing sequence as 761 they send the body, and if it is encountered, simply interrupt the 762 chunk at that point and start a new transaction with a different 763 transaction identifier to carry the rest of the body. Other 764 implementation may choose to scan the data an ensure that the body 765 does not contain the transaction identifier before they start sending 766 the transaction. 768 Finally, requests which have no body MUST NOT contain a Content-Type 769 header field or any other MIME-specific header field. Requests 770 without bodies MUST contain a end-line after the final header field. 772 Once a request is ready for delivery, the sender follows the 773 connection management (Section 5.4) rules to forward the request over 774 an existing open connection or create a new connection. 776 7.1.1. Sending SEND Requests 778 When an endpoint has a message to deliver, it first generates a new 779 Message-ID. This ID MUST be globally unique. If necessary, it 780 breaks the message into chunks. It then generates a SEND request for 781 each chunk, following the procedures for constructing requests 782 (Section 7.1). 784 The Message-ID header field provides a globally unique message 785 identifier that refers to a particular version of a particular 786 message. The term "Message" in this context refers to a unit of 787 content that the sender wishes to convey to the recipient. While 788 such a message may be broken into chunks, the Message-ID refers to 789 the entire message, not a chunk of the message. 790 The uniqueness of the message identifier is guaranteed by the host 791 that generates it. This message identifier is intended to be 792 machine readable and not necessarily meaningful to humans. A 793 message identifier pertains to exactly one version of a particular 794 message; subsequent revisions to the message each receive new 795 message identifiers. 797 Each chunk of a message MUST contain a Message-ID header field 798 containing the Message-ID. If the sender wishes non-default status 799 reporting, it MUST insert a Failure-Report and/or Success-Report 800 header field with an appropriate value. All chunks of the same 801 message MUST use the same Failure-Report and Success-Report values in 802 their SEND requests. 804 If success reports are requested, i.e. the value of the Success- 805 Report header field is "yes", the sending device MAY wish to run a 806 timer of some value that makes sense for its application and take 807 action if a success report is not received in this time. There is no 808 universal value for this timer. For many IM applications, it may be 809 2 minutes while for some trading systems it may be under a second. 810 Regardless of whether such a timer is used, if the success report has 811 not been received by the time the session is ended, the device SHOULD 812 inform the user. 814 If the value of "Failure-Report" is set to "yes", then the sender of 815 the request runs a timer. If a 200 response to the transaction is 816 not received within 30 seconds from the time the last byte of the 817 transaction is sent, or submitted to the operating system for 818 sending, the element MUST inform the user that the request probably 819 failed. If the value is set to "partial", then the element sending 820 the transaction does not have to run a timer, but MUST inform the 821 user if it receives a non-recoverable error response to the 822 transaction. 824 The treatment of timers for success reports and failure reports is 825 intentionally inconsistent. An explicit timeout value makes sense 826 for failure reports since such reports will usually refer to a 827 message "chunk" which is acknowledged on a hop-by-hop basis. This 828 is not the case for success reports, which are end-to-end and may 829 refer to the entire message content, which can be arbitrarily 830 large. 832 If no Success-Report header field is present in a SEND request, it 833 MUST be treated the same as a Success-Report header field with value 834 of "no". If no Failure-Report header field is present, it MUST be 835 treated the same as a Failure-Report header field with value of 836 "yes". If an MSRP endpoint receives a REPORT for a Message-ID it 837 does not recognize, it SHOULD silently ignore the REPORT. 839 The Byte-Range header field value contains a starting value (range- 840 start) followed by a "-", an ending value (range-end) followed by a 841 "/", and finally the total length. The first octet in the message 842 has a position of one, rather than a zero. 844 The first chunk of the message SHOULD, and all subsequent chunks MUST 845 include a Byte-Range header field. The range-start field MUST 846 indicate the position of the first byte in the body in the overall 847 message (for the first chunk this field will have a value of one). 848 The range-end field SHOULD indicate the position of the last byte in 849 the body, if known. It MUST take the value of "*" if the position is 850 unknown, or if the request needs to be interruptible. The total 851 field SHOULD contain the total size of the message, if known. The 852 total field MAY contain a "*" if the total size of the message is not 853 known in advance. The sender MUST send all chunks in Byte-Range 854 order. (However, the receiver cannot assume that the requests will 855 be delivered in order, as intervening relays may have changed the 856 order.) 858 There are some circumstances where an endpoint may choose to send an 859 empty SEND request. For the sake of consistency, a Byte-Range header 860 field referring to nonexistent or zero-length content MUST still have 861 a range-start value of 1. For example, "1-0/0" 863 To ensure fairness over a connection, senders MUST NOT send chunks 864 with a body larger than 2048 octets unless they are prepared to 865 interrupt them (meaning that any chunk with a body of greater than 866 2048 octets will have a "*" character in the range-end field). A 867 sender can use one of the following two strategies to satisfy this 868 requirement. The sender is STRONGLY RECOMMENDED to send messages 869 larger than 2048 octets using as few chunks as possible, interrupting 870 chunks (at least 2048 octets long) only when other traffic is waiting 871 to use the same connection. Alternatively, the sender MAY simply 872 send chunks in 2048 octet increments until the final chunk. Note 873 that the former strategy results in markedly more efficient use of 874 the connection. All MSRP nodes MUST be able to receive chunks of any 875 size from zero octets to the maximum number of octets they can 876 receive for a complete message. Senders SHOULD NOT break messages 877 into chunks smaller than 2048 octets, except for the final chunk of a 878 complete message. 880 A SEND request is interrupted while a body is in the process of being 881 written to the connection by simply noting how much of the message 882 has already been written to the connection, then writing out the end- 883 line to end the chunk. It can then be resumed in a another chunk 884 with the same Message-ID and a Byte-Range header field range start 885 field containing the position of the first byte after the 886 interruption occurred. 888 SEND requests larger than 2048 octets MUST be interrupted if the 889 sender needs to send pending responses or REPORT requests. If 890 multiple SEND requests from different sessions are concurrently being 891 sent over the same connection, the device SHOULD implement some 892 scheme to alternate between them such that each concurrent request 893 gets a chance to send some fair portion of data at regular intervals 894 suitable to the application. 896 The sender MUST NOT assume that a message is received by the peer 897 with the same chunk allocation with which it was sent. An 898 intervening relay could possibly break SEND requests into smaller 899 chunks, or aggregate multiple chunks into larger ones. 901 The default disposition of bodies is "render". If the sender wants a 902 different disposition, it MAY insert a Content-Disposition[9] header 903 field. Since MSRP can carry unencoded binary payloads, transfer 904 encoding is always "binary", and transfer-encoding parameters MUST 905 NOT be present. 907 7.1.2. Sending REPORT Requests 909 REPORT requests are similar to SEND requests, except that report 910 requests MUST NOT include Success-Report or Failure-Report header 911 fields, and MUST contain a Status header field. REPORT requests MUST 912 contain the Message-ID header field from the original SEND request. 914 If an MSRP element receives a REPORT for a Message-ID it does not 915 recognize, it SHOULD silently ignore the REPORT. 917 An MSRP endpoint MUST be able to generate success REPORT requests. 919 REPORT requests will normally not include a body, as the REPORT 920 request header fields can carry sufficient information in most cases. 921 However, REPORT requests MAY include a body containing additional 922 information about the status of the associated SEND request. Such a 923 body is informational only, and the sender of the REPORT request 924 SHOULD NOT assume that the recipient pays any attention to the body. 925 REPORT requests are not interruptible. 927 Success-Report and Failure-Report header fields MUST NOT be present 928 in REPORT requests. MSRP nodes MUST NOT send REPORT requests in 929 response to REPORT requests. MSRP Nodes MUST NOT send MSRP responses 930 to REPORT requests. 932 7.1.3. Generating Success Reports 934 When an endpoint receives a message in one or more chunks that 935 contain a Success-Reports value of "true", it MUST send a success 936 report or reports covering all bytes that are received successfully. 937 The success reports are sent in the form of REPORT requests, 938 following the normal procedures (Section 7.1), with a few additional 939 requirements. 941 The receiver MAY wait until it receives the last chunk of a message, 942 and send a success report that covers the complete message. 943 Alternately, it MAY generate incremental success REPORTs as the 944 chunks are received. These can be sent periodically and cover all 945 the bytes that have been received so far, or they can be sent after a 946 chunk arrives and cover just the part from that chunk. 948 It is helpful to think of a success REPORT as reporting on a 949 particular range of bytes, rather than on a particular chunk sent 950 by a client. The sending client cannot depend on the Byte-Range 951 header field in a given success report matching that of a 952 particular SEND request. For example, an intervening MSRP relay 953 may break chunks into smaller chunks, or aggregate multiple chunks 954 into larger ones. 955 A side effect of this is, even if no relay is used, the receiving 956 client may report on byte ranges that do not exactly match those 957 in the original chunks sent by the sender. It can wait until all 958 bytes in a message are received and report on the whole, it can 959 report as it receives each chunk, or it can report on any other 960 received range. 961 Reporting on ranges smaller than the entire message contents 962 allows certain improved user experiences for the sender. For 963 example, a sending client could display incremental status 964 information showing which ranges of bytes have been acknowledged 965 by the receiver. 966 However, the choice on whether to report incrementally is entirely 967 up to the receiving client. There is no mechanism for the sender 968 to assert its desire to receive incremental reports or not. Since 969 the presence of a relay can cause the receiver to see a very 970 different chunk allocation than the sender, such a mechanism would 971 be of questionable value. 973 When generating a REPORT request, the endpoint inserts a To-Path 974 header field containing the From-Path value from the original 975 request, and a From-Path header field containing the URL identifying 976 itself in the session. The endpoint then inserts a Status header 977 field with a namespace of "000", a status-code of "200" and an 978 implementation-defined comment phrase. It also inserts a Message-ID 979 header field containing the value from the original request. 981 The namespace field denotes the context of the status-code field. 982 The namespace value of "000" means the status-code should be 983 interpreted in the same way as the matching MSRP transaction 984 response code. If a future specification uses the status-code 985 field for some other purpose, it MUST define a new namespace field 986 value. 988 The endpoint MUST NOT send a success report for a SEND request that 989 either contained no Success-Report header field, or contained such a 990 field with a value of "no". That is, if no Success-Report header 991 field is present, it is treated identically to one with a value of 992 "no." 994 7.1.4. Generating Failure Reports 996 If an MSRP endpoint receives a SEND request that it cannot process 997 for some reason, and the Failure-Report header field either was not 998 present in the original request, or had a value of "yes", it SHOULD 999 simply include the appropriate error code in the transaction 1000 response. However, there may be situations where the error cannot be 1001 determined quickly, such as when the endpoint is a gateway that waits 1002 for a downstream network to indicate an error. In this situation, it 1003 MAY send a 200 OK response to the request, and then send a failure 1004 REPORT request when the error is detected. 1006 If the endpoint receives a SEND request with a Failure-Report header 1007 field value of "no", then it MUST NOT send a failure REPORT request, 1008 and MUST NOT send a transaction response. If the value is "partial", 1009 it MUST NOT send a 200 transaction response to the request, but 1010 SHOULD send an appropriate non-200 class response if a failure 1011 occurs. 1013 As stated above, if no Failure-Report header field is present, it 1014 MUST be treated the same as a Failure-Report header field with value 1015 of "yes". 1017 Construction of failure REPORT requests is identical to that for 1018 success REPORT requests, except the Status header field code and 1019 reason fields MUST contain appropriate error codes. Any error 1020 response code defined in this specification MAY also be used in 1021 failure reports. 1023 If a failure REPORT request is sent in response to a SEND request 1024 that contained a chunk, it MUST include a Byte-Range header field 1025 indicating the actual range being reported on. It can take the 1026 range-start and total values from the original SEND request, but MUST 1027 calculate the range-end field from the actual body data. 1029 Endpoints SHOULD NOT send REPORT requests if they have reason to 1030 believe the request will not be delivered. For example, they SHOULD 1031 NOT send a REPORT request on a session that is no longer valid. 1033 This section only describes failure report generation behavior for 1034 MSRP endpoints. Relay behavior is beyond the scope of this 1035 document, and will be considered in a separate document [22]. We 1036 expect failure reports to be more commonly generated by relays 1037 than by endpoints. 1039 7.2. Constructing Responses 1041 If an MSRP endpoint receives a request that either contains a 1042 Failure-Report header field value of "yes", or does not contain a 1043 Failure-Report header field at all, it MUST immediately generate a 1044 response. Likewise, if an MSRP endpoint receives a request that 1045 contains a Failure-Report header field value of "partial", and the 1046 receiver is unable to process the request, it SHOULD immediately 1047 generate a response. 1049 To construct the response, the endpoint first creates the response 1050 start-line, inserting appropriate response code and reason fields. 1051 The transaction identifier in the response start line MUST match the 1052 transaction identifier from the original request. 1054 The endpoint then inserts an appropriate To-Path header field. If 1055 the request triggering the response was a SEND request, the To-Path 1056 header field is formed by copying the last (right-most) URL in the 1057 From-Path header field of the request. (Responses to SEND requests 1058 are returned only to the previous hop.) For responses to all other 1059 request methods, the To-Path header field contains the full path back 1060 to the original sender. This full path is generated by taking the 1061 list of URLs from the From-Path of the original request, reversing 1062 the list, and writing the reversed list into the To-Path of the 1063 response. (Legal REPORT requests do not request responses, so this 1064 specification doesn't exercise the behavior described above, however 1065 we expect that extensions for gateways and relays will need such 1066 behavior.) 1068 Finally, the endpoint inserts a From-Path header field containing the 1069 URL that identifies it in the context of the session, followed by the 1070 end-line after the last header field. The response MUST be 1071 transmitted back on the same connection on which the original request 1072 arrived. 1074 7.3. Receiving Requests 1076 The receiving endpoint MUST first check the URL in the To-Path to 1077 make sure the request belongs to an existing session. When the 1078 request is received, the To-Path will have exactly one URL, which 1079 MUST map to an existing session that is associated with the 1080 connection on which the request arrived. If this is not true, then 1081 the receiver MUST generate a 481 error and ignore the request. Note 1082 that if the Failure-Report header field had a value of "no", then no 1083 error report would be sent. 1085 Further request processing by the receiver is method specific. 1087 7.3.1. Receiving SEND Requests 1089 When the receiving endpoint receives a SEND request, it first 1090 determines if it contains a complete message, or a chunk from a 1091 larger message. If the request contains no Byte-Range header field, 1092 or contains one with a range-start value of "1", and the closing line 1093 continuation flag has a value of "$", then the request contained the 1094 entire message. Otherwise, the receiver looks at the Message-ID 1095 value to associate chunks together into the original message. It 1096 forms a virtual buffer to receive the message, keeping track of which 1097 bytes have been received and which are missing. The receiver takes 1098 the data from the request and places it in the appropriate place in 1099 the buffer. The receiver SHOULD determine the actual length of each 1100 chunk by inspecting the payload itself; it is possible the body is 1101 shorter than the range-end field indicates. This can occur if the 1102 sender interrupted a SEND request unexpectedly. It is worth noting 1103 that the chunk that has a termination character of "$" defines the 1104 total length of the message. 1106 It is technically illegal for the sender to prematurely interrupt 1107 a request that had anything other than "*" in the last-byte 1108 position of the Byte-Range header field. But having the receiver 1109 calculate a chunk length based on actual content adds resilience 1110 in the face of sender errors. Since this should never happen with 1111 compliant senders, this only has a SHOULD strength. 1113 Receivers MUST not assume that the chunks will be delivered in order 1114 or that they will receive all the chunks with "+" flags before they 1115 receive the chunk with the "$" flag. In certain cases of connection 1116 failure, it is possible for information to be duplicated. If chunk 1117 data is received that overlaps already received data for the same 1118 message, the last chunk received SHOULD take precedence (even though 1119 this may not have been the last chunk transmitted). For example, if 1120 bytes 1 to 100 were received and a chunk arrives that contains bytes 1121 50 to 150, this second chunk will overwrite bytes 50 to 100 of the 1122 data that had already been received. Although other schemes work, 1123 this is the easiest for the receiver and results in consistent 1124 behavior between clients. 1126 There are situations in which the receiver may not be able to give 1127 precedence to the last chunk received when chunks overlap. For 1128 example, the recipient might incrementally render chunks as they 1129 arrive. If a new chunk arrives that overlaps with a previously 1130 rendered chunk, it would be too late to "take back" any 1131 conflicting data from the first chunk. Therefore, the requirement 1132 to give precedence to the most recent chunk is specified at a 1133 "SHOULD" strength. This requirement is not intended to disallow 1134 applications where this behavior does not make sense. 1136 The seven "-" in the end-line are used so that the receiver can 1137 search for the value "----", 32 bits at a time to find the probable 1138 location of the end-line. This allows most processors to locate the 1139 boundaries and copy the memory at the same rate that a normal memory 1140 copy could be done. This approach results in a system that is as 1141 fast as framing based on specifying the body length in the header 1142 fields of the request, but also allows for the interruption of 1143 messages. 1145 What is done with the body is outside the scope of MSRP and largely 1146 determined by the MIME Content-Type and Content-Disposition. The 1147 body MAY be rendered after the whole message is received or partially 1148 rendered as it is being received. 1150 If the SEND request contained a Content-Type header field indicating 1151 an unsupported MIME type, and the Failure-Report value is not "no", 1152 the receiver MUST generate a response with a status code of 415. All 1153 MSRP endpoints MUST be able to receive the multipart/mixed [15] and 1154 multipart/alternative [15] MIME types. 1156 If the Success-Report header field was set to "yes", the receiver 1157 must construct and send one or more success reports, as described in 1158 Section 7.1.3. 1160 7.3.2. Receiving REPORT Requests 1162 When an endpoint receives a REPORT request, it correlates it to the 1163 original SEND request using the Message-ID and the Byte-Range, if 1164 present. If it requested success reports, then it SHOULD keep enough 1165 state about each outstanding sent message so that it can correlate 1166 REPORT requests to the original messages. 1168 An endpoint that receives a REPORT request containing a Status header 1169 field with a namespace field of "000" MUST interpret the report in 1170 exactly the same way it would interpret an MSRP transaction response 1171 with a response code matching the status-code field. 1173 It is possible to receive a failure report or a failure transaction 1174 response for a chunk that is currently being delivered. In this 1175 case, the entire message corresponding to that chunk SHOULD be 1176 aborted, by including the "#" character in the continuation field of 1177 the end-line. 1179 It is possible that an endpoint will receive a REPORT request on a 1180 session that is no longer valid. The endpoint's behavior if this 1181 happens is a matter of local policy. The endpoint is not required to 1182 take any steps to facilitate such late delivery, i.e. it is not 1183 expected to keep a connection active in case late REPORTs might 1184 arrive. 1186 When an endpoint that sent a SEND request receives a failure REPORT 1187 indicating that a particular byte range was not received, it MUST 1188 treat the session as failed. If it wishes to recover, it MUST first 1189 re-negotiate the URLs at the signaling level then resend that range 1190 of bytes of the message on the resulting new session. 1192 MSRP nodes MUST NOT send MSRP REPORT requests in response to other 1193 REPORT requests. 1195 8. Using MSRP with SIP and SDP 1197 MSRP sessions will typically be initiated using the Session 1198 Description Protocol (SDP) [2] via the SIP offer/answer mechanism 1199 [3]. 1201 This document defines a handful of new SDP parameters to set up MSRP 1202 sessions. These are detailed below and in the IANA Considerations 1203 section. 1205 An MSRP media-line (that is, a media-line proposing MSRP) in the 1206 session description is accompanied by a mandatory "path" attribute. 1207 This attribute contains a space-separated list of URLs to be visited 1208 to contact the user agent advertising this session-description. If 1209 more than one URL is present, the leftmost URL is the first URL to be 1210 visited to reach the target resource. (The path list can contain 1211 multiple URLs to allow for the deployment of gateways or relays in 1212 the future.) MSRP implementations that can accept incoming 1213 connections without the need for relays will typically only provide a 1214 single URL here. 1216 An MSRP media line is also accompanied by an "accept-types" 1217 attribute, and optionally an "accept-wrapped-types" attribute. These 1218 attributes are used to specify the MIME types that are acceptable to 1219 the endpoint. 1221 8.1. SDP Connection and Media Lines 1223 An SDP connection-line takes the following format: 1225 c=
1227 The network type and address type fields are used as normal for SDP. 1228 The connection address field MUST be set to the IP address or fully 1229 qualified domain name from the MSRP URL identifying the endpoint in 1230 its path attribute. 1232 The general format of an SDP media-line is: 1234 m= 1236 An offered or accepted media-line for MSRP over TCP MUST include a 1237 protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The 1238 media field value MUST be "message". The format list field MUST be 1239 set to "*". 1241 The port field value MUST match the port value used in the endpoint's 1242 MSRP URL in the path attribute, except that, as described in [3], a 1243 user agent that wishes to accept an offer, but not a specific media- 1244 line, MUST set the port number of that media-line to zero (0) in the 1245 response. Since MSRP allows multiple sessions to share the same TCP 1246 connection, multiple m-lines in a single SDP document may share the 1247 same port field value; MSRP devices MUST NOT assume any particular 1248 relationship between m-lines on the sole basis that they have 1249 matching port field values. 1251 MSRP devices do not use the c-line address field, or the m-line 1252 port and format list fields to determine where to connect. 1253 Rather, they use the attributes defined in this specification. 1254 The connection information is copied to the c-line and m-line for 1255 purposes of backwards compatibility with conventional SDP usages. 1256 While MSRP could theoretically carry any media type, "message" is 1257 appropriate. 1259 8.2. URL Negotiations 1261 Each endpoint in an MSRP session is identified by a URL. These URLs 1262 are negotiated in the SDP exchange. Each SDP offer or answer that 1263 proposes MSRP MUST contain a path attribute containing one or more 1264 MSRP URLs. The path attribute is used in an SDP a-line, and has the 1265 following syntax: 1267 path = path-label ":" path-list 1268 path-label = "path" 1269 path-list= MSRP-URL *(SP MSRP-URL) 1271 where MSRP-URL is an "msrp" or "msrps" URL as defined in Section 6. 1272 MSRP URLs included in an SDP offer or answer MUST include explicit 1273 port numbers. 1275 An MSRP device uses the URL to determine a host address, port, 1276 transport, and protection level when connecting, and to identify the 1277 target when sending requests and responses. 1279 The offerer and answerer each selects a URL to represent itself and 1280 sends it to the peer device in the SDP document. Each device stores 1281 the path value received from the peer and uses that value as the 1282 target for requests inside the resulting session. If the path 1283 attribute received from the peer contains more than one URL, then the 1284 target URL is the rightmost, while the leftmost entry represents the 1285 adjacent hop. If only one entry is present, then it is both the peer 1286 and adjacent hop URL. The target path is the entire path attribute 1287 value received from the peer. 1289 The following example shows an SDP offer with a session URL of 1290 "msrp://alice.example.com:7394/2s93i;tcp" 1292 v=0 1293 o=alice 2890844526 2890844527 IN IP4 alice.example.com 1294 s= - 1295 c=IN IP4 alice.example.com 1296 t=0 0 1297 m=message 7394 TCP/MSRP * 1298 a=accept-types:text/plain 1299 a=path:msrp://alice.example.com:7394/2s93i;tcp 1301 The rightmost URL in the path attribute MUST identify the endpoint 1302 that generated the SDP document, or some other location where that 1303 endpoint wishes to receive requests associated with the session. It 1304 MUST be assigned for this particular session, and MUST NOT duplicate 1305 any URL in use for any other session in which the endpoint is 1306 currently participating. It SHOULD be hard to guess, and protected 1307 from eavesdroppers. This is discussed in more detail in Section 14. 1309 8.3. Path Attributes with Multiple URLs 1311 As mentioned previously, this document describes MSRP for peer-to- 1312 peer scenarios, that is, when no relays are used. The use of relays 1313 are described in a separate document [22]. In order to allow an MSRP 1314 device that only implements the core specification to interoperate 1315 with devices that use relays, this document must include a few 1316 assumptions about how relays work. 1318 An endpoint that uses one or more relays will indicate that by 1319 putting a URL for each device in the relay chain into the SDP path 1320 attribute. The final entry will point to the endpoint itself. The 1321 other entries will indicate each proposed relay, in order. The first 1322 entry will point to the first relay in the chain from the perspective 1323 of the peer; that is, the relay to which the peer device, or a relay 1324 operating on its behalf, should connect. 1326 Endpoints that do not wish to insert a relay, including those that do 1327 not support relays at all, will put exactly one URL into the path 1328 attribute. This URL represents both the endpoint for the session, 1329 and the connection point. 1331 Even though endpoints that implement only this specification will 1332 never introduce a relay, they need to be able to interoperate with 1333 other endpoints that do use relays. Therefore, they MUST be prepared 1334 to receive more than one URL in the SDP path attribute. When an 1335 endpoint receives more than one URL in a path attribute, only the 1336 first entry is relevant for purposes of resolving the address and 1337 port, and establishing the network connection, as it describes the 1338 first adjacent hop. 1340 If an endpoint puts more than one URL in a path attribute, the final 1341 URL in the path attribute (the peer URL) identifies the session, and 1342 MUST not duplicate the URL of any other session in which the endpoint 1343 is currently participating. Uniqueness requirements for other 1344 entries in the path attribute are out of scope for this document. 1346 8.4. Updated SDP Offers 1348 MSRP endpoints may sometimes need to send additional SDP exchanges 1349 for an existing session. They may need to send periodic exchanges 1350 with no change to refresh state in the network, for example, SIP 1351 session timers or the SIP UPDATE[23] request. They may need to 1352 change some other stream in a session without affecting the MSRP 1353 stream, or they may need to change an MSRP stream without affecting 1354 some other stream. 1356 Either peer may initiate an updated exchange at any time. The 1357 endpoint that sends the new offer assumes the role of offerer for all 1358 purposes. The answerer MUST respond with a path attribute that 1359 represents a valid path to itself at the time of the updated 1360 exchange. This new path may be the same as its previous path, but 1361 may be different. The new offerer MUST NOT assume that the peer will 1362 answer with the same path it used previously. 1364 If either party wishes to send an SDP document that changes nothing 1365 at all, then it MUST have the same o-line as in the previous 1366 exchange. 1368 8.5. Connection Negotiation 1370 Previous versions of this document included a mechanism to negotiate 1371 the direction for any required TCP connection. The mechanism was 1372 loosely based on the COMEDIA [25] work being done in the MMUSIC 1373 working group. The primary motivation was to allow MSRP sessions to 1374 succeed in situations where the offerer could not accept connections 1375 but the answerer could. For example, the offerer might be behind a 1376 NAT, while the answerer might have a globally routable address. 1378 The SIMPLE working group chose to remove that mechanism from MSRP, as 1379 it added a great deal of complexity to connection management. 1380 Instead, MSRP now specifies a default connection direction. The 1381 party that sent the original offer is responsible for connecting to 1382 its peer. 1384 8.6. Content Type Negotiation 1386 An SDP media-line proposing MSRP MUST be accompanied by an accept- 1387 types attribute. 1389 An entry of "*" in the accept-types attribute indicates that the 1390 sender may attempt to send content with media types that have not 1391 been explicitly listed. Likewise, an entry with an explicit type and 1392 a "*" character as the subtype indicates that the sender may attempt 1393 to send content with any subtype of that type. If the receiver 1394 receives an MSRP request and is able to process the media type, it 1395 does so. If not, it will respond with a 415 response. Note that all 1396 explicit entries SHOULD be considered preferred over any non-listed 1397 types. This feature is needed as, otherwise, the list of formats for 1398 rich IM devices may be prohibitively large. 1400 This specification requires the support of certain data formats. 1401 Mandatory formats MUST be signaled like any other, either explicitly 1402 or by the use of a "*". 1404 The accept-types attribute may include container types, that is, MIME 1405 formats that contain other types internally. If compound types are 1406 used, the types listed in the accept-types attribute may be used both 1407 as the root payload, or may be wrapped in a listed container type. 1408 Any container types MUST also be listed in the accept-types 1409 attribute. 1411 Occasionally an endpoint will need to specify a MIME body type that 1412 can only be used if wrapped inside a listed container type. 1414 Endpoints MAY specify MIME types that are only allowed when wrapped 1415 inside compound types using the "accept-wrapped-types" attribute in 1416 an SDP a-line. 1418 The semantics for accept-wrapped-types are identical to those of the 1419 accept-types attribute, with the exception that the specified types 1420 may only be used when wrapped inside container types listed in 1421 accept-types attribute. Only types listed in the accept-types 1422 attribute may be used as the "root" type for the entire body. Since 1423 any type listed in accept-types may be used both as a root body, and 1424 wrapped in other bodies, format entries from accept-types SHOULD NOT 1425 be repeated in this attribute. 1427 This approach does not allow for specifying distinct lists of 1428 acceptable wrapped types for different types of containers. If an 1429 endpoint understands a MIME type in the context of one wrapper, it is 1430 assumed to understand it in the context of any other acceptable 1431 wrappers, subject to any constraints defined by the wrapper types 1432 themselves. 1434 The approach of specifying types that are only allowed inside of 1435 containers separately from the primary payload types allows an 1436 endpoint to force the use of certain wrappers. For example, a 1437 CPIM [12] gateway device may require all messages to be wrapped 1438 inside message/cpim bodies, but may allow several content types 1439 inside the wrapper. If the gateway were to specify the wrapped 1440 types in the accept-types attribute, its peer might attempt to use 1441 those types without the wrapper. 1443 If the recipient of an offer does not understand any of the payload 1444 types indicated in the offered SDP, it SHOULD indicate that using the 1445 appropriate mechanism of the rendezvous protocol. For example, in 1446 SIP, it SHOULD return a SIP 488 response. 1448 An endpoint MAY indicate the maximum size message they wish to 1449 receive using the max-size a-line attribute. Max-size refers to the 1450 complete message in octets, not the size of any one chunk. Senders 1451 SHOULD NOT exceed the max-size limit for any message sent in the 1452 resulting session. However, the receiver should consider max-size 1453 value as a hint. 1455 The formal syntax for these attributes are as follows: 1457 accept-types = accept-types-label ":" format-list 1458 accept-types-label = "accept-types" 1459 accept-wrapped-types = wrapped-types-label ":" format-list 1460 wrapped-types-label = "accept-wrapped-types" 1461 format-list = format-entry *( SP format-entry) 1462 format-entry = (type "/" subtype) / (type "/" "*") / ("*") 1463 type = token 1464 subtype = token 1466 max-size = max-size-label ":" max-size-value 1467 max-size-label = "max-size" 1468 max-size-value = 1*(DIGIT) ;max size in octets 1470 8.7. Example SDP Exchange 1472 Endpoint A wishes to invite Endpoint B to an MSRP session. A offers 1473 the following session description: 1475 v=0 1476 o=usera 2890844526 2890844527 IN IP4 alice.example.com 1477 s= - 1478 c=IN IP4 alice.example.com 1479 t=0 0 1480 m=message 7394 TCP/MSRP * 1481 a=accept-types: message/cpim text/plain text/html 1482 a=path:msrp://alice.example.com:7394/2s93i9;tcp 1484 B responds with its own URL: 1486 v=0 1487 o=userb 2890844530 2890844532 IN IP4 bob.example.com 1488 s= - 1489 c=IN IP4 bob.example.com 1490 t=0 0 1491 m=message 8493 TCP/MSRP * 1492 a=accept-types:message/cpim text/plain 1493 a=path:msrp://bob.example.com:8493/si438ds;tcp 1495 8.8. MSRP User Experience with SIP 1497 In typical SIP applications, when an endpoint receives an INVITE 1498 request, it alerts the user, and waits for user input before 1499 responding. This is analogous to the typical telephone user 1500 experience, where the callee "answers" the call. 1502 In contrast, the typical user experience for instant messaging 1503 applications is that the initial received message is immediately 1504 displayed to the user, without waiting for the user to "join" the 1505 conversation. Therefore, the principle of least surprise would 1506 suggest that MSRP endpoints using SIP signaling SHOULD allow a mode 1507 where the endpoint quietly accepts the session, and begins displaying 1508 messages. 1510 This guideline may not make sense for all situations, such as for 1511 mixed media applications, where both MSRP and audio sessions are 1512 offered in the same INVITE. In general, good application design 1513 should take precedence. 1515 SIP INVITE requests may be forked by a SIP proxy, resulting in more 1516 than one endpoint receiving the same INVITE. SIP early media [28] 1517 techniques can be used to establish a preliminary session with each 1518 endpoint so the initial message(s) are displayed on each endpoint, 1519 and canceling the INVITE transaction for any endpoints that do not 1520 send MSRP traffic after some period of time, so that they cease 1521 receiving MSRP traffic from the inviter. 1523 8.9. SDP direction attribute and MSRP 1525 SDP defines a number of attributes that modify the direction of media 1526 flows. These are the "sendonly", "recvonly", "inactive", and 1527 "sendrecv" attributes. 1529 If a "sendonly" or "recvonly" attribute modifies an MSRP media 1530 description line, the attribute indicates the direction of MSRP SEND 1531 requests that contain regular message payloads. Unless otherwise 1532 specified, these attributes do not affect the direction of other 1533 types of requests, such as REPORT. SEND requests that contain some 1534 kind of control or reporting protocol rather than regular message 1535 payload (e.g., IMDN reports) should be generated according to the 1536 protocol rules as if no direction attribute were present. 1538 9. Formal Syntax 1540 MSRP is a text protocol that uses the UTF-8 [14] transformation 1541 format. 1543 The following syntax specification uses the augmented Backus-Naur 1544 Form (BNF) as described in RFC-2234 [6]. 1546 msrp-req-or-resp = msrp-request / msrp-response 1547 msrp-request = req-start headers [content-stuff] end-line 1548 msrp-response = resp-start headers end-line 1550 req-start = pMSRP SP transact-id SP method CRLF 1551 resp-start = pMSRP SP transact-id SP status-code [SP comment] CRLF 1552 comment = utf8text 1554 pMSRP = %x4D.53.52.50 ; MSRP in caps 1555 transact-id = ident 1556 method = mSEND / mREPORT / other-method 1557 mSEND = %x53.45.4e.44 ; SEND in caps 1558 mREPORT = %x52.45.50.4f.52.54; REPORT in caps 1560 other-method = 1*UPALPHA 1561 status-code = 3DIGIT ; any code defined in this document 1562 ; or an extension document 1564 MSRP-URL = msrp-scheme "://" [userinfo "@"] hostport 1565 ["/" session-id] ";" transport *( ";" url-parameter) 1566 ; userinfo as defined in RFC3986, except 1567 ; limited to unreserved. 1568 ; hostport as defined in RFC3261 1570 msrp-scheme = "msrp" / "msrps" 1571 session-id = 1*( unreserved / "+" / "=" / "/" ) 1572 ; unreserved as defined in RFC3986 1573 transport = "tcp" / ALPHANUM 1574 url-parameter = token ["=" token] 1576 headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) 1578 header = Message-ID 1579 / Success-Report 1580 / Failure-Report 1581 / Byte-Range 1582 / Status 1583 / ext-header 1585 To-Path = "To-Path:" SP MSRP-URL *( SP MSRP-URL ) 1586 From-Path = "From-Path:" SP MSRP-URL *( SP MSRP-URL ) 1587 Message-ID = "Message-ID:" SP ident 1588 Success-Report = "Success-Report:" SP ("yes" / "no" ) 1589 Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" ) 1590 Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total 1591 range-start = 1*DIGIT 1592 range-end = 1*DIGIT / "*" 1593 total = 1*DIGIT / "*" 1595 Status = "Status:" SP namespace SP status-code [SP text-reason] 1596 namespace = 3(DIGIT); "000" for all codes defined in this document. 1597 text-reason = utf8text 1599 ident = alphanum 3*31ident-char 1600 ident-char = alphanum / "." / "-" / "+" / "%" / "=" 1602 content-stuff = *(Other-Mime-header CRLF) 1603 Content-Type 2CRLF data CRLF 1605 Content-Type = "Content-Type:" SP media-type 1606 media-type = type "/" subtype *( ";" gen-param ) 1607 type = token 1608 subtype = token 1610 gen-param = pname [ "=" pval ] 1611 pname = token 1612 pval = token / quoted-string 1614 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E 1615 / %x30-39 / %x41-5A / %x5E-7E) 1616 ; token is compared case-insensitive 1618 quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE 1619 qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E 1620 / UTF8-NONASCII 1621 qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) 1622 BACKSLASH = "\" 1623 UPALPHA = %x41-5A 1624 ALPHANUM = ALPHA / DIGIT 1626 Other-Mime-header = (Content-ID 1627 / Content-Description 1628 / Content-Disposition 1629 / mime-extension-field); 1631 ; Content-ID, and Content-Description are defined in RFC2045. 1632 ; Content-Disposition is defined in RFC2183 1633 ; MIME-extension-field indicates additional MIME extension 1634 ; header fields as described in RFC2045 1636 data = *OCTET 1637 end-line = "-------" transact-id continuation-flag CRLF 1638 continuation-flag = "+" / "$" / "#" 1640 ext-header = hname ":" SP hval CRLF 1641 hname = ALPHA *token 1642 hval = utf8text 1644 utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) 1646 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 1647 / %xE0-EF 2UTF8-CONT 1648 / %xF0-F7 3UTF8-CONT 1649 / %xF8-Fb 4UTF8-CONT 1650 / %xFC-FD 5UTF8-CONT 1651 UTF8-CONT = %x80-BF 1653 10. Response Code Descriptions 1655 This section summarizes the semantics of various response codes that 1656 may be used in MSRP transaction responses. These codes may also be 1657 used in the Status header field in REPORT requests. 1659 10.1. 200 1661 The 200 response code indicates a successful transaction. 1663 10.2. 400 1665 A 400 response indicates a request was unintelligible. The sender 1666 may retry the request after correcting the error. 1668 10.3. 403 1670 A 403 response indicates the attempted action is not allowed. The 1671 sender should not try the request again. 1673 10.4. 408 1675 A 408 response indicates that a downstream transaction did not 1676 complete in the alloted time. It is never sent by any elements 1677 described in this specification. However, 408 is used in the MSRP 1678 Relay extension; therefore MSRP endpoints may receive it. An 1679 endpoint MUST treat a 408 response in the same manner as it would 1680 treat a local timeout. 1682 10.5. 413 1684 A 413 response indicates that the receiver wishes the sender to stop 1685 sending the particular message. Typically, a 413 is sent in response 1686 to a chunk of an undesired message. 1688 If a message sender receives a 413 in a response, or in a REPORT 1689 request, it MUST NOT send any further chunks in the message, that is, 1690 any further chunks with the same Message-ID value. If the sender 1691 receives the 413 while in the process of sending a chunk, and the 1692 chunk is interruptible, the sender MUST interrupt it. 1694 10.6. 415 1696 A 415 response indicates the SEND request contained a MIME content- 1697 type that is not understood by the receiver. The sender should not 1698 send any further messages with the same content-type for the duration 1699 of the session. 1701 10.7. 423 1703 A 423 response indicates that one of the requested parameters is out 1704 of bounds. It is used by the relay extensions to this document. 1706 10.8. 481 1708 A 481 response indicates that the indicated session does not exist. 1709 The sender should terminate the session. 1711 10.9. 501 1713 A 501 response indicates that the recipient does not understand the 1714 request method. 1716 The 501 response code exists to allow some degree of method 1717 extensibility. It is not intended as a license to ignore methods 1718 defined in this document; rather it is a mechanism to report lack 1719 of support of extension methods. 1721 10.10. 506 1723 A 506 response indicates that a request arrived on a session which is 1724 already bound to another network connection. The sender should cease 1725 sending messages for that session on this connection. 1727 11. Examples 1729 11.1. Basic IM Session 1731 This section shows an example flow for the most common scenario. The 1732 example assumes SIP is used to transport the SDP exchange. Details 1733 of the SIP messages and SIP proxy infrastructure are omitted for the 1734 sake of brevity. In the example, assume that the offerer is 1735 sip:alice@example.com and the answerer is sip:bob@example.com. 1737 Alice Bob 1738 | | 1739 | | 1740 |(1) (SIP) INVITE | 1741 |----------------------->| 1742 |(2) (SIP) 200 OK | 1743 |<-----------------------| 1744 |(3) (SIP) ACK | 1745 |----------------------->| 1746 |(4) (MSRP) SEND | 1747 |----------------------->| 1748 |(5) (MSRP) 200 OK | 1749 |<-----------------------| 1750 |(6) (MSRP) SEND | 1751 |<-----------------------| 1752 |(7) (MSRP) 200 OK | 1753 |----------------------->| 1754 |(8) (SIP) BYE | 1755 |----------------------->| 1756 |(9) (SIP) 200 OK | 1757 |<-----------------------| 1758 | | 1759 | | 1761 1. Alice constructs a local URL of 1762 msrp://alicepc.example.com:7777/iau39;tcp . 1764 Alice->Bob (SIP): INVITE sip:bob@example.com 1766 v=0 1767 o=alice 2890844557 2890844559 IN IP4 alicepc.example.com 1768 s= - 1769 c=IN IP4 alicepc.example.com 1770 t=0 0 1771 m=message 7777 TCP/MSRP * 1772 a=accept-types:text/plain 1773 a=path:msrp://alicepc.example.com:7777/iau39;tcp 1775 2. Bob listens on port 8888, and sends the following response: 1777 Bob->Alice (SIP): 200 OK 1779 v=0 1780 o=bob 2890844612 2890844616 IN IP4 bob.example.com 1781 s= - 1782 c=IN IP4 bob.example.com 1783 t=0 0 1784 m=message 8888 TCP/MSRP * 1785 a=accept-types:text/plain 1786 a=path:msrp://bob.example.com:8888/9di4ea;tcp 1788 3. Alice->Bob (SIP): ACK sip:bob@example.com 1790 4. (Alice opens connection to Bob.) Alice->Bob (MSRP): 1792 MSRP d93kswow SEND 1793 To-Path: msrp://bob.example.com:8888/9di4ea;tcp 1794 From-Path: msrp://alicepc.example.com:7777/iau39;tcp 1795 Message-ID: 12339sdqwer 1796 Content-Type: text/plain 1798 Hi, I'm Alice! 1799 -------d93kswow$ 1801 5. Bob->Alice (MSRP): 1803 MSRP d93kswow 200 OK 1804 To-Path: msrp://alicepc.example.com:7777/iau39;tcp 1805 From-Path: msrp://bob.example.com:8888/9di4ea;tcp 1806 -------d93kswow$ 1808 6. Bob->Alice (MSRP): 1810 MSRP dkei38sd SEND 1811 To-Path: msrp://alicepc.example.com:7777/iau39;tcp 1812 From-Path: msrp://bob.example.com:8888/9di4ea;tcp 1813 Message-ID: 456 1814 Content-Type: text/plain 1816 Hi, Alice! I'm Bob! 1817 -------dkei38sd$ 1819 7. Alice->Bob (MSRP): 1821 MSRP dkei38sd 200 OK 1822 To-Path: msrp://alicepc.example.com:7777/iau39;tcp 1823 From-Path: msrp://bob.example.com:8888/9di4ea;tcp 1824 -------dkei38sd$ 1826 8. Alice->Bob (SIP): BYE sip:bob@example.com 1828 Alice invalidates local session state. 1830 9. Bob invalidates local state for the session. 1832 Bob->Alice (SIP): 200 OK 1834 11.2. Message with XHTML Content 1836 MSRP dsdfoe38sd SEND 1837 To-Path: msrp://alice.example.com:7777/iau39;tcp 1838 From-Path: msrp://bob.example.com:8888/9di4ea;tcp 1839 Message-ID: 456 1840 Content-Type: application/xhtml+xml 1842 1843 1846 1847 1848 FY2005 Results 1849 1850 1851

See the results at example.org.

1853 1854 1855 -------dsdfoe38sd$ 1857 11.3. Chunked Message 1859 For an example of a chunked message, see the example in Section 5.1. 1861 11.4. System Message 1863 Sysadmin->Alice (MSRP): 1865 MSRP d93kswow SEND 1866 To-Path: msrp://alicepc.example.com:8888/9di4ea;tcp 1867 From-Path: msrp://example.com:7777/iau39;tcp 1868 Message-ID: 12339sdqwer 1869 Failure-Report: no 1870 Success-Report: no 1871 Content-Type: text/plain 1873 This conference will end in 5 minutes 1874 -------d93kswow$ 1876 11.5. Positive Report 1878 Alice->Bob (MSRP): 1880 MSRP d93kswow SEND 1881 To-Path: msrp://bob.example.com:8888/9di4ea;tcp 1882 From-Path: msrp://alicepc.example.com:7777/iau39;tcp 1883 Message-ID: 12339sdqwer 1884 Byte-Range: 1-106/106 1885 Success-Report: yes 1886 Failure-Report: no 1887 Content-Type: text/html 1889 1890

Here is that important link... 1891 foobar 1892

1893 1894 -------d93kswow$ 1896 Bob->Alice (MSRP): 1898 MSRP dkei38sd REPORT 1899 To-Path: msrp://alicepc.example.com:7777/iau39;tcp 1900 From-Path: msrp://bob.example.com:8888/9di4ea;tcp 1901 Message-ID: 12339sdqwer 1902 Byte-Range: 1-106/106 1903 Status: 000 200 OK 1904 -------dkei38sd$ 1906 11.6. Forked IM 1908 Traditional IM systems generally do a poor job of handling multiple 1909 simultaneous IM clients online for the same person. While some do a 1910 better job than many existing systems, handling of multiple clients 1911 is fairly crude. This becomes a much more significant issue when 1912 always-on mobile devices are available, but it is desirable to use 1913 them only if another IM client is not available. 1915 Using SIP makes rendezvous decisions explicit, deterministic, and 1916 very flexible. In contrast, "page-mode" IM systems use implicit 1917 implementation-specific decisions which IM clients cannot influence. 1918 With SIP session-mode messaging, rendezvous decisions can be under 1919 control of the client in a predictable, interoperable way for any 1920 host that implements callee capabilities [30]. As a result, 1921 rendezvous policy is managed consistently for each address of record. 1923 The following example shows Juliet with several IM clients where she 1924 can be reached. Each of these has a unique SIP Contact and MSRP 1925 session. The example takes advantage of SIP's capability to "fork" 1926 an invitation to several Contacts in parallel, in sequence, or in 1927 combination. Juliet has registered from her chamber, the balcony, 1928 her PDA, and as a last resort, you can leave a message with her 1929 Nurse. Juliet's contacts are listed below. The q-values express 1930 relative preference (q=1.0 is the highest preference). 1932 When Romeo opens his IM program, he selects Juliet and types the 1933 message "art thou hither?" (instead of "you there?"). His client 1934 sends a SIP invitation to sip:juliet@thecapulets.example.com. The 1935 proxy there tries first the balcony and the chamber simultaneously. 1936 A client is running on each of those systems, both of which set up 1937 early sessions of MSRP with Romeo's client. The client automatically 1938 sends the message over MSRP to the two MSRP URIs involved. After a 1939 delay of a several seconds with no reply or activity from Juliet, the 1940 proxy cancels the invitation at her first two contacts, and forwards 1941 the invitation on to Juliet's PDA. Since her father is talking to 1942 her about her wedding, she selects "Do Not Disturb" on her PDA, which 1943 sends a "Busy Here" response. The proxy then tries the Nurse, who 1944 answers and tells Romeo what is going on. 1946 Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse 1947 Proxy balcony chamber PDA 1949 | | | | | | 1950 |--INVITE--->| | | | | 1951 | |--INVITE--->| | | | 1952 | |<----180----| | | | 1953 |<----180----| | | | | 1954 |---PRACK---------------->| | | | 1955 |<----200-----------------| | | | 1956 |<===Early MSRP Session==>| art thou hither? | | 1957 | | | | | | 1958 | |--INVITE---------------->| | | 1959 | |<----180-----------------| | | 1960 |<----180----| | | | | 1961 |---PRACK----------------------------->| | | 1962 |<----200------------------------------| | | 1963 |<========Early MSRP Session==========>| art thou hither? | 1964 | | | | | | 1965 | | | | | | 1966 | | .... Time Passes .... | | | 1967 | | | | | | 1968 | | | | | | 1969 | |--CANCEL--->| | | | 1970 | |<---200-----| | | | 1971 | |<---487-----| | | | 1972 | |----ACK---->| | | | 1973 | |--CANCEL---------------->| | | 1974 | |<---200------------------| | | 1975 | |<---487------------------| | | 1976 | |----ACK----------------->| | | 1977 | |--INVITE---------------------------->| romeo wants 1978 | | | | | to IM w/ you 1979 | |<---486 Busy Here--------------------| | 1980 | |----ACK----------------------------->| | 1981 | | | | | | 1982 | |--INVITE---------------------------------------->| 1983 | |<---200 OK---------------------------------------| 1984 |<--200 OK---| | | | | 1985 |---ACK------------------------------------------------------->| 1986 |<================MSRP Session================================>| 1987 | | | | | | 1988 | Hi Romeo, Juliet is | 1989 | with her father now | 1990 | can I take a message?| 1991 | | 1992 | Tell her to go to confession tomorrow.... | 1994 12. Extensibility 1996 MSRP was designed to be only minimally extensible. New MSRP Methods, 1997 header fields, and status codes can be defined in standards track 1998 RFCs. MSRP does not contain a version number or any negotiation 1999 mechanism to require or discover new features. If an extension is 2000 specified in the future that requires negotiation, the specification 2001 will need to describe how the extension is to be negotiated in the 2002 encapsulating signaling protocol. If a non-interoperable update or 2003 extension occurs in the future, it will be treated as a new protocol, 2004 and MUST describe how its use will be signaled. 2006 In order to allow extension header fields without breaking 2007 interoperability, if an MSRP device receives a request or response 2008 containing a header field that it does not understand, it MUST ignore 2009 the header field and process the request or response as if the header 2010 field was not present. If an MSRP device receives a request with an 2011 unknown method, it MUST return a 501 response. 2013 MSRP was designed to use lists of URLs instead of a single URL in the 2014 To-Path and From-Path header fields in anticipation of relay or 2015 gateway functionality being added. In addition, "msrp" and "msrps" 2016 URLs can contain parameters that are extensible. 2018 13. CPIM Compatibility 2020 MSRP sessions may go to a gateway to other CPIM [26] compatible 2021 protocols. If this occurs, the gateway MUST maintain session state, 2022 and MUST translate between the MSRP session semantics and CPIM 2023 semantics, which do not include a concept of sessions. Furthermore, 2024 when one endpoint of the session is a CPIM gateway, instant messages 2025 SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST 2026 include "message/cpim" as the first entry in its SDP accept-types 2027 attribute. MSRP endpoints sending instant messages to a peer that 2028 has included "message/cpim" as the first entry in the accept-types 2029 attribute SHOULD encapsulate all instant message bodies in "message/ 2030 cpim" wrappers. All MSRP endpoints MUST support the message/cpim 2031 type, and SHOULD support the S/MIME[7] features of that format. 2033 If a message is to be wrapped in a message/cpim envelope, the 2034 wrapping MUST be done prior to breaking the message into chunks, if 2035 needed. 2037 All MSRP endpoints MUST recognize the From, To, DateTime, and Require 2038 header fields as defined in RFC3862. Such applications SHOULD 2039 recognize the CC header field, and MAY recognize the Subject header 2040 field. Any MSRP application that recognizes any message/cpim header 2041 field MUST understand the NS (name space) header field. 2043 All message/cpim body parts sent by an MSRP endpoint MUST include the 2044 From and To header fields. If the message/cpim body part is 2045 protected using S/MIME, then it MUST also include the DateTime header 2046 field. 2048 The NS, To, and CC header fields may occur multiple times. Other 2049 header fields defined in RFC3862 MUST NOT occur more than once in a 2050 given message/cpim body part in an MSRP message. The Require header 2051 field MAY include multiple values. The NS header field MAY occur 2052 zero or more times, depending on how many name spaces are being 2053 referenced. 2055 Extension header fields MAY occur more than once, depending on the 2056 definition of such header fields. 2058 Using message/cpim envelopes is also useful if an MSRP device 2059 wishes to send a message on behalf of some other identity. The 2060 device may add a message/cpim envelope with the appropriate From 2061 header field value. 2063 14. Security Considerations 2065 Instant Messaging systems are used to exchange a variety of sensitive 2066 information ranging from personal conversations, to corporate 2067 confidential information, to account numbers and other financial 2068 trading information. IM is used by individuals, corporations, and 2069 governments for communicating important information. IM systems need 2070 to provide the properties of integrity and confidentiality for the 2071 exchanged information, the knowledge that you are communicating with 2072 the correct party, and allow the possibility of anonymous 2073 communication. MSRP pushes many of the hard problems to SIP when SIP 2074 sets up the session, but some of the problems remain. Spam and DoS 2075 attacks are also very relevant to IM systems. 2077 MSRP needs to provide confidentiality and integrity for the messages 2078 it transfers. It also needs to provide assurances that the connected 2079 host is the host that it meant to connect to and that the connection 2080 has not been hijacked. 2082 14.1. Transport Level Protection 2084 When using only TCP connections, MSRP security is fairly weak. If 2085 host A is contacting host B, B passes its hostname and a secret to A 2086 using a rendezvous protocol. Although MSRP requires the use of a 2087 rendezvous protocol with the ability to protect this exchange, there 2088 is no guarantee that the protection will be used all the time. If 2089 such protection is not used, anyone can see this secret. Host A then 2090 connects to the provided host name and passes the secret in the clear 2091 across the connection to B. Host A assumes that it is talking to B 2092 based on where it sent the SYN packet and then delivers the secret in 2093 plain text across the connections. Host B assumes it is talking to A 2094 because the host on the other end of the connection delivered the 2095 secret. An attacker that could ACK the SYN packet could insert 2096 itself as a man in the middle in the connection. 2098 When using TLS connections, the security is significantly improved. 2099 We assume that the host accepting the connection has a certificate 2100 from a well-known certificate authority. Furthermore, we assume that 2101 the signaling to set up the session is protected by the rendezvous 2102 protocol. In this case, when host A contacts host B, the secret is 2103 passed through a confidential channel to A. A connects with TLS to B. 2104 B presents a valid certificate, so A knows it really is connected to 2105 B. A then delivers the secret provided by B, so that B can verify it 2106 is connected to A. In this case, a rogue SIP Proxy can see the secret 2107 in the SIP signaling traffic and could potentially insert itself as a 2108 man-in-the-middle. 2110 Realistically, using TLS with certificates from well known 2111 certificate authorities is difficult for peer-to-peer connections, as 2112 the types of hosts that end clients use for sending instant messages 2113 are unlikely to have long-term stable IP addresses or DNS names that 2114 certificates can bind to. In addition, the cost of server 2115 certificates from well-known certificate authorities is currently 2116 expensive enough to discourage their use for each client. Using TLS 2117 in a peer-to-peer mode without well known certificate is discussed in 2118 Section 14.3. 2120 TLS becomes much more practical when some form of relay is 2121 introduced. Clients can then form TLS connections to relays, which 2122 are much more likely to have TLS certificates. While this 2123 specification does not address such relays, they are described by a 2124 companion document [22]. That document makes extensive use of TLS to 2125 protect traffic between clients and relays, and between one relay and 2126 another. 2128 TLS is used to authenticate devices and to provide integrity and 2129 confidentiality for the header fields being transported. MSRP 2130 elements MUST implement TLS and MUST also implement the TLS 2131 ClientExtendedHello extended hello information for server name 2132 indication as described in [11]. A TLS cipher-suite of 2133 TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher- 2134 suites MAY also be supported). 2136 14.2. S/MIME 2138 The only strong security for non-TLS connections is achieved using 2139 S/MIME. 2141 Since MSRP carries arbitrary MIME content, it can trivially carry 2142 S/MIME protected messages as well. All MSRP implementations MUST 2143 support the multipart/signed MIME type even if they do not support 2144 S/MIME. Since SIP can carry a session key, S/MIME messages in the 2145 context of a session could also be protected using a key-wrapped 2146 shared secret [27] provided in the session setup. MSRP can carry 2147 unencoded binary payloads. Therefore MIME bodies MUST be transferred 2148 with a transfer encoding of binary. If a message is both signed and 2149 encrypted, it SHOULD be signed first, then encrypted. If S/MIME is 2150 supported, SHA-1, RSA, and AES-128 MUST be supported. 2152 This does not actually require the endpoint to have certificates from 2153 a well-known certificate authority. When MSRP is used with SIP, the 2154 Identity [16] and Certificates [24] mechanisms provide S/MIME based 2155 delivery of a secret between A and B. No SIP intermediary except the 2156 explicitly trusted authentication service (one per user) can see the 2157 secret. The S/MIME encryption of the SDP can also be used by SIP to 2158 exchange keying material that can be used in MSRP. The MSRP session 2159 can then use S/MIME with this keying material to encrypt and sign 2160 messages sent over MSRP. The connection can still be hijacked since 2161 the secret is sent in clear text to the other end of the TCP 2162 connection, but the consequences are mitigated if all the MSRP 2163 content is encrypted and signed with S/MIME. Although out of scope 2164 for this document, the SIP negotiation of MSRP session can negotiate 2165 symmetric keying material to be used with S/MIME for integrity and 2166 privacy. 2168 14.3. Using TLS in Peer to Peer Mode 2170 TLS can be used with a self-signed certificate as long as there is a 2171 mechanism for both sides to ascertain that the other side used the 2172 correct certificate. When used with SDP and SIP, the correct 2173 certificate can be verified by passing a fingerprint of the 2174 certificate in the SDP and ensuring that the SDP has suitable 2175 integrity protection. When SIP is used to transport the SDP, the 2176 integrity can be provided by the SIP Identity mechanism[16]. The 2177 rest of this section describes the details of this approach. 2179 If self-signed certificates are used, the content of the 2180 subjectAltName attribute inside the certificate MAY use the uniform 2181 resource identifier (URI) of the user. In SIP, this URI of the user 2182 is the User's Address of Record (AOR). This is useful for debugging 2183 purposes only and is not required to bind the certificate to one of 2184 the communication endpoints. Unlike normal TLS operations in this 2185 protocol, when doing peer-to-peer TLS, the subjectAltName is not an 2186 important component of the certificate verification. If the endpoint 2187 is also able to make anonymous sessions, a distinct, unique 2188 certificate MUST be used for this purpose. For a client that works 2189 with multiple users, each user SHOULD have its own certificate. 2190 Because the generation of public/private key pairs is relatively 2191 expensive, endpoints are not required to generate certificates for 2192 each session. 2194 A certificate fingerprint is the output of a one-way hash function 2195 computed over the distinguished encoding rules (DER) form of the 2196 certificate. The endpoint MUST use the certificate fingerprint 2197 attribute as specified in [17] and MUST include this in the SDP. The 2198 certificate presented during the TLS handshake needs to match the 2199 fingerprint exchanged via the SDP and if the fingerprint does not 2200 match the hashed certificate then the endpoint MUST tear down the 2201 media session immediately. 2203 When using SIP, the integrity of the fingerprint can be ensured 2204 through the SIP Identity mechanism [16]. When a client wishes to use 2205 SIP to set up a secure MSRP session with another endpoint it sends an 2206 SDP offer in a SIP message to the other endpoint. This offer 2207 includes, as part of the SDP payload, the fingerprint of the 2208 certificate that the endpoint wants to use. The SIP message 2209 containing the offer is sent to the offerer's SIP proxy which will 2210 add an Identity header according to the procedures outlined in [16]. 2211 When the far endpoint receives the SIP message it can verify the 2212 identity of the sender using the Identity header. Since the Identity 2213 header is a digital signature across several SIP headers, in addition 2214 to the body or bodies of the SIP message, the receiver can also be 2215 certain that the message has not been tampered with after the digital 2216 signature was added to the SIP message. 2218 An example of SDP with a fingerprint attribute is shown in the 2219 following figure. Note the fingerprint is shown spread over two 2220 lines due to formatting consideration but should all be on one line. 2222 c=IN IP4 atlanta.example.com 2223 m=message 7654 TCP/TLS/MSRP * 2224 a=accept-types:text/plain 2225 a=path:msrps://atlanta.example.com:7654/jshA7we;tcp 2226 a=fingerprint:SHA-1 \ 2227 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2229 14.4. Other Security Concerns 2231 MSRP cannot be used as an amplifier for DoS attacks, but it can be 2232 used to form a distributed attack to consume TCP connection resources 2233 on servers. The attacker, Mallory, sends a SIP INVITE with no offer 2234 to Alice. Alice returns a 200 with an offer and Mallory returns an 2235 answer with SDP indicating that his MSRP address is the address of 2236 Tom. Since Alice sent the offer, Alice will initiate a connection to 2237 Tom using up resources on Tom's server. Given the huge number of IM 2238 clients, and the relatively few TCP connections that most servers 2239 support, this is a fairly straightforward attack. 2241 SIP is attempting to address issues in dealing with spam. The spam 2242 issue is probably best dealt with at the SIP level when an MSRP 2243 session is initiated and not at the MSRP level. 2245 If a sender chooses to employ S/MIME to protect a message, all S/MIME 2246 operations apply to the complete message, prior to any breaking of 2247 the message into chunks. 2249 The signaling will have set up the session to or from some specific 2250 URLs that will often have "im:" or "sip:" URI schemes. When the 2251 signaling has been set up to a specific end user, and S/MIME is 2252 implemented, then the client needs to verify that the name in the 2253 SubjectAltName of the certificate contains an entry that matches the 2254 URI that was used for the other end in the signaling. There are some 2255 cases, such as IM conferencing, where the S/MIME certificate name and 2256 the signaled identity will not match. In these cases, the client 2257 should ensure that the user is informed that the message came from 2258 the user identified in the certificate and does not assume that the 2259 message came from the party they signaled. 2261 In some cases, a sending device may need to attribute a message to 2262 some other identity, and may use different identities for different 2263 messages in the same session. For example, a conference server may 2264 send messages on behalf of multiple users on the same session. 2265 Rather than add additional header fields to MSRP for this purpose, 2266 MSRP relies on the message/cpim format for this purpose. The sender 2267 may envelop such a message in a message/cpim body, and place the 2268 actual sender identity in the From field. The trustworthiness of 2269 such an attribution is affected by the security properties of the 2270 session in the same way that the trustworthiness of the identity of 2271 the actual peer is affected, with the additional issue of determining 2272 whether the recipient trusts the sender to assert the identity. 2274 This approach can result in nesting of message/cpim envelopes. For 2275 example, a message originates from a CPIM gateway, and is then 2276 forwarded by a conference server onto a new session. Both the 2277 gateway and the conference server introduce envelopes. In this case, 2278 the recipient client SHOULD indicate the chain of identity assertions 2279 to the user, rather than allow the user to assume that either the 2280 gateway or the conference server originated the message. 2282 It is possible that a recipient might receive messages that are 2283 attributed to the same sender via different MSRP sessions. For 2284 example, Alice might be in a conversation with Bob via an MSRP 2285 session over a TLS protected channel. Alice might then receive a 2286 different message from Bob over a different session, perhaps with a 2287 conference server that asserts Bob's identity in a message/cpim 2288 envelope signed by the server. 2290 MSRP does not prohibit multiple simultaneous sessions between the 2291 same pair of identities. Nor does it prohibit an endpoint sending a 2292 message on behalf of another identity, such as may be the case for a 2293 conference server. The recipient's endpoint should determine its 2294 level of trust of the authenticity of the sender independently for 2295 each session. The fact that an endpoint trusts the authenticity of 2296 the sender on any given session should not affect the level of trust 2297 it assigns for apparently the same sender on a different session. 2299 When MSRP clients form or acquire a certificate, they SHOULD ensure 2300 that the subjectAltName has a GeneralName entry of type 2301 uniformResourceIdentifier for each URL corresponding to this client 2302 and should always include an "im:" URI. It is fine if the 2303 certificate contains other URIs such as "sip:" or "xmpp:" URIs. 2305 MSRP implementors should be aware of a potential attack on MSRP 2306 devices that involves placing very large values in the byte-range 2307 header field, potentially causing the device to allocate very large 2308 memory buffers to hold the message. Implementations SHOULD apply 2309 some degree of sanity checking on byte-range values before allocating 2310 such buffers. 2312 15. IANA Considerations 2314 This specification instructs IANA to create a new registry for MSRP 2315 parameters. The MSRP Parameter registry is a container for sub- 2316 registries. This section further introduces sub-registries for MSRP 2317 method names, status codes, and header field names. 2319 Additionally, Section 15.4 through Section 15.7 register new 2320 parameters in existing IANA registries. 2322 [NOTE TO IANA/RFC Editor: Please replace all occurrences of RFCXXXX 2323 in this section with the actual number assigned to this document.] 2325 15.1. MSRP Method Names 2327 This specification establishes the Method sub-registry under MSRP 2328 Parameters and initiates its population as follows. New parameters 2329 in this sub-registry must be published in an RFC (either as an IETF 2330 submission or RFC Editor submission). 2332 SEND - [RFCXXXX] 2333 REPORT - [RFCXXXX] 2335 The following information MUST be provided in an RFC publication in 2336 order to register a new MSRP Method: 2338 The method name. 2339 The RFC number in which the method is registered. 2341 15.2. MSRP Header Fields 2343 This specification establishes the header field-Field sub-registry 2344 under MSRP Parameters. New parameters in this sub-registry must be 2345 published in an RFC (either as an IETF submission or RFC Editor 2346 submission). Its initial population is defined as follows: 2348 To-Path - [RFCXXXX] 2349 From-Path - [RFCXXXX] 2350 Success-Report - [RFCXXXX] 2351 Failure-Report - [RFCXXXX] 2352 Byte-Range - [RFCXXXX] 2353 Status - [RFCXXXX] 2355 The following information MUST be provided in an RFC publication in 2356 order to register a new MSRP header field: 2358 The header field name. 2359 The RFC number in which the method is registered. 2361 15.3. MSRP Status Codes 2363 This specification establishes the Status-Code sub-registry under 2364 MSRP Parameters. New parameters in this sub-registry must be 2365 published in an RFC (either as an IETF submission or RFC Editor 2366 submission). Its initial population is defined in Section 10. It 2367 takes the following format: 2369 Code [RFC Number] 2371 The following information MUST be provided in an RFC publication in 2372 order to register a new MSRP status code: 2374 The status code number. 2375 The RFC number in which the method is registered. 2377 15.4. MSRP Port 2379 MSRP uses TCP port XYZ. Usage of this value is described in 2380 Section 6. 2382 [NOTE TO IANA/RFC Editor: Please replace XYZ in this section with the 2383 assigned port number.] 2385 15.5. MSRP URL Schemes 2387 This document defines the URL schemes of "msrp" and "msrps". 2389 Syntax: See Section 6. 2390 Character Encoding: See Section 6. 2391 Intended Usage: See Section 6. 2392 Protocols: The Message Session Relay Protocol (MSRP). 2393 Security Considerations: See Section 14. 2394 Relevant Publications: RFCXXXX 2396 15.6. SDP Transport Protocol 2398 MSRP defines the a new SDP protocol field values "TCP/MSRP" and "TCP/ 2399 TLS/MSRP", which should be registered in the sdp-parameters registry 2400 under "proto". This first value indicates the MSRP protocol when TCP 2401 is used as an underlying transport. The second indicates that TLS is 2402 used. 2404 Specifications defining new protocol values must define the rules for 2405 the associated media format namespace. The "TCP/MSRP" and "TCP/TLS/ 2406 MSRP" protocol values allow only one value in the format field (fmt), 2407 which is a single occurrence of "*". Actual format determination is 2408 made using the "accept-types" and "accept-wrapped-types" attributes. 2410 15.7. SDP Attribute Names 2412 This document registers the following SDP attribute parameter names 2413 in the sdp-parameters registry. These names are to be used in the 2414 SDP att-name field. 2416 15.7.1. Accept Types 2417 Contact Information: Ben Campbell (ben@estacado.net) 2418 Attribute-name: accept-types 2419 Long-form Attribute Name: Acceptable MIME Types 2420 Type: Media level 2421 Subject to Charset Attribute: No 2422 Purpose and Appropriate Values: The "accept-types" attribute contains 2423 a list of MIME content-types that the endpoint is willing to 2424 receive. It may contain zero or more registered MIME types, or 2425 "*" in a space delimited string. 2427 15.7.2. Wrapped Types 2429 Contact Information: Ben Campbell (ben@estacado.net) 2430 Attribute-name: accept-wrapped-types 2431 Long-form Attribute Name: Acceptable MIME Types Inside Wrappers 2432 Type: Media level 2433 Subject to Charset Attribute: No 2434 Purpose and Appropriate Values: The "accept-wrapped-types" attribute 2435 contains a list of MIME content-types that the endpoint is willing 2436 to receive in an MSRP message with multipart content, but may not 2437 be used as the outermost type of the message. It may contain zero 2438 or more registered MIME types, or "*" in a space delimited string. 2440 15.7.3. Max Size 2442 Contact Information: Ben Campbell (ben@estacado.net) 2443 Attribute-name: max-size 2444 Long-form Attribute Name: Maximum message size. 2445 Type: Media level 2446 Subject to Charset Attribute: No 2447 Purpose and Appropriate Values: The "max-size" attribute indicates 2448 the largest message an endpoint wishes to accept. It may take any 2449 numeric value, specified in octets. 2451 15.7.4. Path 2453 Contact Information: Ben Campbell (ben@estacado.net) 2454 Attribute-name: path 2455 Long-form Attribute Name: MSRP URL Path 2456 Type: Media level 2457 Subject to Charset Attribute: No 2458 Purpose and Appropriate Values: The "path" attribute indicates a 2459 series of MSRP devices that must be visited by messages sent in 2460 the session, including the final endpoint. The attribute contains 2461 one or more MSRP URIs, delimited by the space character. 2463 16. Contributors and Acknowledgments 2465 In addition to the editors, the following people contributed 2466 extensive work to this document: Chris Boulton, Paul Kyzivat, Orit 2467 Levin, Hans Persson, Adam Roach, Jonathan Rosenberg, and Robert 2468 Sparks. 2470 The following people contributed substantial discussion and feedback 2471 to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson, 2472 Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, 2473 Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney. 2475 17. References 2477 17.1. Normative References 2479 [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2480 RFC 2246, January 1999. 2482 [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2483 Description Protocol", draft-ietf-mmusic-sdp-new-26 (work in 2484 progress), July 2006. 2486 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2487 Session Description Protocol (SDP)", RFC 3264, June 2002. 2489 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2490 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2491 Session Initiation Protocol", RFC 3261, June 2002. 2493 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2494 Levels", BCP 14, RFC 2119, March 1997. 2496 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2497 Specifications: ABNF", RFC 2234, November 1997. 2499 [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 2500 (S/MIME) Version 3.1 Message Specification", RFC 3851, 2501 July 2004. 2503 [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2504 Extensions (MIME) Part One: Format of Internet Message Bodies", 2505 RFC 2045, November 1996. 2507 [9] Troost, R., Dorner, S., and K. Moore, "Communicating 2508 Presentation Information in Internet Messages: The Content- 2509 Disposition header field", RFC 2183, August 1997. 2511 [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2512 Resource Identifiers (URI): Generic Syntax", RFC 3986, 2513 January 2005. 2515 [11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 2516 T. Wright, "Transport Layer Security (TLS) Extensions", 2517 RFC 3546, June 2003. 2519 [12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging 2520 (CPIM): Message Format", RFC 3862, August 2004. 2522 [13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 2523 Transport Layer Security (TLS)", RFC 3268, June 2002. 2525 [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2526 RFC 3629, November 2003. 2528 [15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2529 Extensions (MIME) Part Two: Media Types", rfc 2046, 2530 November 1996. 2532 [16] Peterson, J. and C. Jennings, "Enhancements for Authenticated 2533 Identity Management in the Session Initiation Protocol (SIP)", 2534 draft-ietf-sip-identity-06 (work in progress), October 2005. 2536 [17] Lennox, J., "Connection-Oriented Media Transport over the 2537 Transport Layer Security (TLS) Protocol in the Session 2538 Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-06 2539 (work in progress), March 2006. 2541 17.2. Informational References 2543 [18] Johnston, A. and O. Levin, "Session Initiation Protocol Call 2544 Control - Conferencing for User Agents", 2545 draft-ietf-sipping-cc-conferencing-07 (work in progress), 2546 June 2005. 2548 [19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 2549 "Best Current Practices for Third Party Call Control in the 2550 Session Initiation Protocol", RFC 3725, April 2004. 2552 [20] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation 2553 Protocol Call Control - Transfer", 2554 draft-ietf-sipping-cc-transfer-06 (work in progress), 2555 March 2006. 2557 [21] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 2558 D. Gurle, "Session Initiation Protocol (SIP) Extension for 2559 Instant Messaging", RFC 3428, December 2002. 2561 [22] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for 2562 Message Sessions Relay Protocol (MSRP)", 2563 draft-ietf-simple-msrp-relays-07 (work in progress), 2564 February 2006. 2566 [23] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 2567 Method", RFC 3311, October 2002. 2569 [24] Jennings, C. and J. Peterson, "Certificate Management Service 2570 for SIP", draft-ietf-sipping-certs-03 (work in progress), 2571 March 2006. 2573 [25] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport 2574 in SDP", rfc 4145, September 2005. 2576 [26] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", 2577 rfc 3860, August 2004. 2579 [27] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, 2580 December 2001. 2582 [28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone 2583 Generation in the Session Initiation Protocol (SIP)", rfc 3960, 2584 December 2004. 2586 [29] Saint-Andre, P., "Extensible Messaging and Presence Protocol 2587 (XMPP): Instant Messaging and Presence", RFC 3921, 2588 October 2004. 2590 [30] Rosenberg, J., "Indicating User Agent Capabilities in the 2591 Session Initiation Protocol (SIP)", RFC 3840, August 2004. 2593 [31] Peterson, J., "Address Resolution for Instant Messaging and 2594 Presence", rfc 3861, August 2004. 2596 Authors' Addresses 2598 Ben Campbell (editor) 2599 Estacado Systems 2600 17210 Campbell Road 2601 Suite 250 2602 Dallas, TX 75252 2603 USA 2605 Email: ben@estacado.net 2607 Rohan Mahy (editor) 2608 Plantronics 2609 345 Encincal Street 2610 Santa Cruz, CA 2611 USA 2613 Email: rohan@ekabal.com 2615 Cullen Jennings (editor) 2616 Cisco Systems, Inc. 2617 170 West Tasman Dr. 2618 MS: SJC-21/2 2619 San Jose, CA 95134 2620 USA 2622 Phone: +1 408 421-9990 2623 Email: fluffy@cisco.com 2625 Intellectual Property Statement 2627 The IETF takes no position regarding the validity or scope of any 2628 Intellectual Property Rights or other rights that might be claimed to 2629 pertain to the implementation or use of the technology described in 2630 this document or the extent to which any license under such rights 2631 might or might not be available; nor does it represent that it has 2632 made any independent effort to identify any such rights. Information 2633 on the procedures with respect to rights in RFC documents can be 2634 found in BCP 78 and BCP 79. 2636 Copies of IPR disclosures made to the IETF Secretariat and any 2637 assurances of licenses to be made available, or the result of an 2638 attempt made to obtain a general license or permission for the use of 2639 such proprietary rights by implementers or users of this 2640 specification can be obtained from the IETF on-line IPR repository at 2641 http://www.ietf.org/ipr. 2643 The IETF invites any interested party to bring to its attention any 2644 copyrights, patents or patent applications, or other proprietary 2645 rights that may cover technology that may be required to implement 2646 this standard. Please address the information to the IETF at 2647 ietf-ipr@ietf.org. 2649 Disclaimer of Validity 2651 This document and the information contained herein are provided on an 2652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2654 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2655 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2656 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2659 Copyright Statement 2661 Copyright (C) The Internet Society (2006). This document is subject 2662 to the rights, licenses and restrictions contained in BCP 78, and 2663 except as set forth therein, the authors retain all their rights. 2665 Acknowledgment 2667 Funding for the RFC Editor function is currently provided by the 2668 Internet Society.