idnits 2.17.1 draft-ietf-simple-message-sessions-14.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 2626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2616. ** 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 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. -- 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 (February 25, 2006) is 6628 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 2327 ** 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 (-06) exists of draft-ietf-mmusic-comedia-tls-05 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-05 == Outdated reference: A later version (-10) exists of draft-ietf-simple-msrp-relays-07 == Outdated reference: A later version (-03) exists of draft-ietf-sipping-certs-02 -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. '29') (Obsoleted by RFC 6121) Summary: 8 errors (**), 0 flaws (~~), 7 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: August 29, 2006 R. Mahy, Ed. 5 SIP Edge, LLC 6 C. Jennings, Ed. 7 Cisco Systems, Inc. 8 February 25, 2006 10 The Message Session Relay Protocol 11 draft-ietf-simple-message-sessions-14 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 August 29, 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 . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . 20 68 7.1.3. Generating Success Reports . . . . . . . . . . . . . . 21 69 7.1.4. Generating Failure Reports . . . . . . . . . . . . . . 21 70 7.2. Constructing Responses . . . . . . . . . . . . . . . . . 22 71 7.3. Receiving Requests . . . . . . . . . . . . . . . . . . . 23 72 7.3.1. Receiving SEND Requests . . . . . . . . . . . . . . . 23 73 7.3.2. Receiving REPORT Requests . . . . . . . . . . . . . . 25 74 8. Using MSRP with SIP and SDP . . . . . . . . . . . . . . . . . 26 75 8.1. SDP Connection and Media Lines . . . . . . . . . . . . . 27 76 8.2. URL Negotiations . . . . . . . . . . . . . . . . . . . . 27 77 8.3. Path Attributes with Multiple URLs . . . . . . . . . . . 28 78 8.4. Updated SDP Offers . . . . . . . . . . . . . . . . . . . 29 79 8.5. Connection Negotiation . . . . . . . . . . . . . . . . . 30 80 8.6. Content Type Negotiation . . . . . . . . . . . . . . . . 30 81 8.7. Example SDP Exchange . . . . . . . . . . . . . . . . . . 32 82 8.8. MSRP User Experience with SIP . . . . . . . . . . . . . . 32 83 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 33 84 10. Response Code Descriptions . . . . . . . . . . . . . . . . . . 35 85 10.1. 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 86 10.2. 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 87 10.3. 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 88 10.4. 408 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 89 10.5. 413 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 90 10.6. 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 91 10.7. 423 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 92 10.8. 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 93 10.9. 501 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 10.10. 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 95 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 96 11.1. Basic IM Session . . . . . . . . . . . . . . . . . . . . 37 97 11.2. Message with XHTML Content . . . . . . . . . . . . . . . 40 98 11.3. Chunked Message . . . . . . . . . . . . . . . . . . . . . 40 99 11.4. System Message . . . . . . . . . . . . . . . . . . . . . 40 100 11.5. Positive Report . . . . . . . . . . . . . . . . . . . . . 41 101 11.6. Forked IM . . . . . . . . . . . . . . . . . . . . . . . . 41 102 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 45 103 13. CPIM Compatibility . . . . . . . . . . . . . . . . . . . . . . 45 104 14. Security Considerations . . . . . . . . . . . . . . . . . . . 46 105 14.1. Transport Level Protection . . . . . . . . . . . . . . . 46 106 14.2. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . 48 107 14.3. Using TLS in Peer to Peer Mode . . . . . . . . . . . . . 48 108 14.4. Other Security Concerns . . . . . . . . . . . . . . . . . 50 109 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 110 15.1. MSRP Method Names . . . . . . . . . . . . . . . . . . . . 52 111 15.2. MSRP Header Fields . . . . . . . . . . . . . . . . . . . 52 112 15.3. MSRP Status Codes . . . . . . . . . . . . . . . . . . . . 52 113 15.4. MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 53 114 15.5. MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 53 115 15.6. SDP Transport Protocol . . . . . . . . . . . . . . . . . 53 116 15.7. SDP Attribute Names . . . . . . . . . . . . . . . . . . . 53 117 15.7.1. Accept Types . . . . . . . . . . . . . . . . . . . . . 53 118 15.7.2. Wrapped Types . . . . . . . . . . . . . . . . . . . . 54 119 15.7.3. Max Size . . . . . . . . . . . . . . . . . . . . . . . 54 120 15.7.4. Path . . . . . . . . . . . . . . . . . . . . . . . . . 54 121 16. Contributors and Acknowledgments . . . . . . . . . . . . . . . 54 122 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 123 17.1. Normative References . . . . . . . . . . . . . . . . . . 55 124 17.2. Informational References . . . . . . . . . . . . . . . . 56 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 126 Intellectual Property and Copyright Statements . . . . . . . . . . 59 128 1. Introduction 130 A series of related instant messages between two or more parties can 131 be viewed as part of a "message session", that is, a conversational 132 exchange of messages with a definite beginning and end. This is in 133 contrast to individual messages each sent independently. Messaging 134 schemes that track only individual messages can be described as 135 "page-mode" messaging, whereas messaging that is part of a "session" 136 with a definite start and end is called "session-mode" messaging. 138 Page-mode messaging is enabled in SIP via the SIP [4] MESSAGE method 139 [21]. Session-mode messaging has a number of benefits over page-mode 140 messaging, however, such as explicit rendezvous, tighter integration 141 with other media types, direct client-to-client operation, and 142 brokered privacy and security. 144 This document defines a session-oriented instant message transport 145 protocol called the Message Session Relay Protocol (MSRP), whose 146 sessions can be negotiated with an offer or answer [3] using the 147 Session Description Protocol(SDP [2]). The exchange is carried by 148 some signaling protocol, such as the Session Initiation Protocol (SIP 149 [4]). This allows a communication user agent to offer a messaging 150 session as one of the possible media types in a session. For 151 instance, Alice may want to communicate with Bob. Alice doesn't know 152 at the moment whether Bob has his phone or his IM client handy, but 153 she's willing to use either. She sends an invitation to a session to 154 the address of record she has for Bob, sip:bob@example.com. Her 155 invitation offers both voice and an IM session. The SIP services at 156 example.com forward the invitation to Bob at his currently registered 157 clients. Bob accepts the invitation at his IM client and they begin 158 a threaded chat conversation. 160 When a user uses an IM URL, RFC 3861 [31] defines how DNS can be used 161 to map this to a particular protocol to establish the session such as 162 SIP. SIP can use an offer answer model to transport the MSRP URLs 163 for the media in SDP. This document defines how the offer/answer 164 exchange works to establish MSRP connections and how messages are 165 sent across the MSRP protocol, but it does not deal with the issues 166 of mapping an IM URL to a session establishment protocol. 168 This session model allows message sessions to be integrated into 169 advanced communications applications with little to no additional 170 protocol development. For example, during the above chat session, 171 Bob decides Alice really needs to be talking to Carol. Bob can 172 transfer [20] Alice to Carol, introducing them into their own 173 messaging session. Messaging sessions can then be easily integrated 174 into call-center and dispatch environments using third-party call 175 control [19] and conferencing [18] applications. 177 This document specifies MSRP behavior only for peer-to-peer sessions, 178 that is, sessions crossing only a single hop. MSRP relay devices 179 [22] (referred to herein as "relays") are specified in a separate 180 document. 182 2. Conventions 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC-2119 [5]. 188 This document consistently refers to a "message" as a complete unit 189 of MIME or text content. In some cases, a message is split and 190 delivered in more than one MSRP request. Each of these portions of 191 the complete message is called a "chunk". 193 3. Applicability of MSRP 195 MSRP is not designed for use as a standalone protocol. MSRP MUST be 196 used only in the context of a rendezvous mechanism meeting the 197 following requirements: 199 The rendezvous mechanism MUST provide both MSRP URLs associated 200 with an MSRP session to each of the participating endpoints. The 201 rendezvous mechanism MUST implement mechanisms to provide these 202 URLs securely - they MUST NOT be made available to an untrusted 203 third party or be easily discoverable. 205 The rendezvous mechanism MUST provide mechanisms for the 206 negotiation of any supported MSRP extensions that are not 207 backwards compatible. 209 The rendezvous mechanism MUST be able to natively transport im: 210 URIs or automatically translate im: URIs [26] into the addressing 211 identifiers of the rendezvous protocol. 213 To use a rendezvous mechanism with MSRP, an RFC must be prepared 214 describing how it exchanges MSRP URLs and meets these requirements 215 listed here. This document provides such a description for the use 216 of MSRP in the context of SIP and SDP. 218 SIP meets these requirements for a rendezvous mechanism. The MSRP 219 URLs are exchanged using SDP in an offer/answer exchange via SIP. 220 The exchanged SDP can also be used to negotiate MSRP extensions. 221 This SDP can be secured using any of the mechanisms available in SIP, 222 including using the sips mechanism to ensure transport security 223 across intermediaries and S/MIME for end-to-end protection of the SDP 224 entity. SIP can carry arbitrary URIs (including im: URIs) in the 225 Request-URI, and procedures are available to map im: URIs to sip: or 226 sips: URIs. It is expected that initial deployments of MSRP will use 227 SIP as its rendezvous mechanism. 229 4. Protocol Overview 231 MSRP is a text-based, connection-oriented protocol for exchanging 232 arbitrary (binary) MIME[8] content, especially instant messages. 233 This section is a non-normative overview of how MSRP works and how it 234 is used with SIP. 236 MSRP sessions are typically arranged using SIP the same way a session 237 of audio or video media is set up. One SIP user agent (Alice) sends 238 the other (Bob) a SIP invitation containing an offered session- 239 description which includes a session of MSRP. The receiving SIP user 240 agent can accept the invitation and include an answer session- 241 description which acknowledges the choice of media. Alice's session 242 description contains an MSRP URL that describes where she is willing 243 to receive MSRP requests from Bob, and vice-versa. (Note: Some lines 244 in the examples are removed for clarity and brevity.) 245 Alice sends to Bob: 247 INVITE sip:bob@atlanta.example.com SIP/2.0 248 To: 249 From: ;tag=786 250 Call-ID: 3413an89KU 251 Content-Type: application/sdp 253 c=IN IP4 atlanta.example.com 254 m=message 7654 TCP/MSRP * 255 a=accept-types:text/plain 256 a=path:msrp://atlanta.example.com:7654/jshA7we;tcp 258 Bob sends to Alice: 260 SIP/2.0 200 OK 261 To: ;tag=087js 262 From: ;tag=786 263 Call-ID: 3413an89KU 264 Content-Type: application/sdp 266 c=IN IP4 biloxi.example.com 267 m=message 12763 TCP/MSRP * 268 a=accept-types:text/plain 269 a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 271 Alice sends to Bob: 273 ACK sip:bob@atlanta.example.com SIP/2.0 274 To: ;tag=087js 275 From: ;tag=786 276 Call-ID: 3413an89KU 278 MSRP defines two request types, or methods. SEND requests are used 279 to deliver a complete message or a chunk (a portion of a complete 280 message), while REPORT requests report on the status of a previously 281 sent message, or a range of bytes inside a message. When Alice 282 receives Bob's answer, she checks to see if she has an existing 283 connection to Bob. If not, she opens a new connection to Bob using 284 the URL he provided in the SDP. Alice then delivers a SEND request 285 to Bob with her initial message, and Bob replies indicating that 286 Alice's request was received successfully. 288 MSRP a786hjs2 SEND 289 To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 290 From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp 291 Message-ID: 87652 292 Byte-Range: 1-25/25 293 Content-Type: text/plain 295 Hey Bob, are you there? 296 -------a786hjs2$ 298 MSRP a786hjs2 200 OK 299 To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp 300 From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 301 Byte-Range: 1-25/25 302 -------a786hjs2$ 304 Alice's request begins with the MSRP start line, which contains a 305 transaction identifier that is also used for request framing. Next 306 she includes the path of URLs to the destination in the To-Path 307 header field, and her own URL in the From-Path header field. In this 308 typical case there is just one "hop", so there is only one URL in 309 each path header field. She also includes a message ID which she can 310 use to correlate status reports with the original message. Next she 311 puts the actual content. Finally she closes the request with an end- 312 line of seven hyphens, the transaction identifier and a "$" to 313 indicate this request contains the end of a complete message. 315 If Alice wants to deliver a very large message, she can split the 316 message into chunks and deliver each chunk in a separate SEND 317 request. The message ID corresponds to the whole message, so the 318 receiver can also use it to reassemble the message and tell which 319 chunks belong with which message. Chunking is described in more 320 detail in Section 5.1. The Byte-Range header field identifies the 321 portion of the message carried in this chunk and the total size of 322 the message. 324 Alice can also specify what type of reporting she would like in 325 response to her request. If Alice requests positive acknowledgments, 326 Bob sends a REPORT request to Alice confirming the delivery of her 327 complete message. This is especially useful if Alice sent a series 328 of SEND request containing chunks of a single message. More on 329 requesting types of reports and errors is described in Section 5.3. 331 Alice and Bob generally choose their MSRP URLs in such a way that is 332 difficult to guess the exact URL. Alice and Bob can reject requests 333 to URLs they are not expecting to service, and can correlate the 334 specific URL with the probable sender. Alice and Bob can also use 335 TLS [1] to provide channel security over this hop. To receive MSRP 336 requests over a TLS protected connection, Alice or Bob could 337 advertise URLs with the "msrps" scheme instead of "msrp." 339 MSRP is designed with the expectation that MSRP can carry URLs for 340 nodes on the far side of relays. For this reason, a URL with the 341 "msrps" scheme makes no assertion about the security properties of 342 other hops, just the next hop. The user agent knows the URL for each 343 hop, so it can verify that each URL has the desired security 344 properties. 346 MSRP URLs are discussed in more detail in Section 6. 348 An adjacent pair of busy MSRP nodes (for example two relays) can 349 easily have several sessions, and exchange traffic for several 350 simultaneous users. The nodes can use existing connections to carry 351 new traffic with the same destination host, port, transport protocol, 352 and scheme. MSRP nodes can keep track of how many sessions are using 353 a particular connection and close these connections when no sessions 354 have used them for some period of time. Connection management is 355 discussed in more detail in Section 5.4. 357 5. Key Concepts 359 5.1. MSRP Framing and Message Chunking 361 Messages sent using MSRP can be very large and can be delivered in 362 several SEND requests, where each SEND request contains one chunk of 363 the overall message. Long chunks may be interrupted in mid- 364 transmission to ensure fairness across shared transport connections. 365 To support this, MSRP uses a boundary based framing mechanism. The 366 start line of an MSRP request contains a unique identifier that is 367 also used to indicate the end of the request. Included at the end of 368 the end-line, there is a flag that indicates whether this is the last 369 chunk of data for this message or whether the message will be 370 continued in a subsequent chunk. There is also a Byte-Range header 371 field in the request that indicates the overall position of this 372 chunk inside the complete message. 374 For example, the following snippet of two SEND requests demonstrates 375 a message that contains the text "abcdEFGH" being sent as two chunks. 377 MSRP dkei38sd SEND 378 Message-ID: 456 379 Byte-Range: 1-4/8 380 Content-Type: text/plain 382 abcd 383 -------dkei38sd+ 385 MSRP dkei38ia SEND 386 Message-ID: 456 387 Byte-Range: 5-8/8 388 Content-Type: text/plain 390 EFGH 391 -------dkei38ia$ 393 This chunking mechanism allows a sender to interrupt a chunk part of 394 the way through sending it. The ability to interrupt messages allows 395 multiple sessions to share a TCP connection, and for large messages 396 to be sent efficiently while not blocking other messages that share 397 the same connection, or even the same MSRP session. Any chunk that 398 is larger than 2048 octets MUST be interruptible. While MSRP would 399 be simpler to implement if each MSRP session used its own TCP 400 connection, that approach would circumvent the congestion avoidance 401 features of TCP. 403 The chunking mechanism only applies to the SEND method, as it is the 404 only method used to transfer message content. 406 5.2. MSRP Addressing 408 MSRP entities are addressed using URLs. The MSRP URL schemes are 409 defined in Section 6. The syntax of the To-Path and From-Path header 410 fields each allow for a list of URLs. This was done to allow the 411 protocol to work with relays, which are defined in a separate 412 document, to provide a complete path to the end recipient. When two 413 MSRP nodes communicate directly they need only one URL in the To-Path 414 list and one URL in the From-Path list. 416 5.3. MSRP Transaction and Report Model 418 A sender sends MSRP requests to a receiver. The receiver MUST 419 quickly accept or reject the request. If the receiver initially 420 accepted the request, it still may then do things that take 421 significant time to succeed or fail. For example, if the receiver is 422 an MSRP to XMPP [29] gateway, it may forward the message over XMPP. 423 The XMPP side may later indicate that the request did not work. At 424 this point, the MSRP receiver may need to indicate that the request 425 did not succeed. There are two important concepts here: first, the 426 hop by hop delivery of the request may succeed or fail; second, the 427 end result of the request may be successfully processed or not. The 428 first type of status is referred to as "transaction status" and may 429 be returned in response to a request. The second type of status is 430 referred to as "delivery status" and may be returned in a REPORT 431 transaction. 433 The original sender of a request can indicate if they wish to receive 434 reports for requests that fail, and can independently indicate if 435 they wish to receive reports for requests that succeed. A receiver 436 only sends a success REPORT if it knows that the request was 437 successfully delivered, and the sender requested a success report. A 438 receiver only sends a failure REPORT if the request failed to be 439 delivered and the sender requested failure reports. 441 This document describes the behavior of MSRP endpoints. MSRP 442 relays will introduce additional conditions that indicate a 443 failure REPORT should be sent, such as the failure to receive a 444 positive response from the next hop. 446 Two header fields control the sender's desire to receive reports. 447 The header field "Success-Report" can have a value of "yes" or "no" 448 and the "Failure-Report" header field can have a value of "yes", 449 "no", or "partial". 451 The combinations of reporting are needed to meet the various 452 scenarios of currently deployed IM systems. Success-Report might be 453 "no" in many public systems to reduce load but might be "yes" in 454 certain enterprise systems, such as systems used for securities 455 trading. A Failure-Report value of "no" is useful for sending system 456 messages such as "the system is going down in 5 minutes" without 457 causing a response explosion to the sender. A Failure-Report of 458 "yes" is used by many systems that wish to notify the user if the 459 message failed. A Failure-Report of "partial" is a way to report 460 errors other than timeouts. The timeout error reporting requires the 461 sending hop to run a timer and the receiving hop to send an 462 acknowledgment to stop the timer. Some systems don't want the 463 overhead of doing this. "Partial" allows them to choose not to do 464 so, but still allows error responses to be sent in many cases. 466 The "partial" value allows a compromise between no reporting of 467 failures, and reporting all failures. For example, with 468 "partial", an sending device does not have to keep transaction 469 state around waiting for a positive acknowledgment. But it still 470 allows devices to report other types of errors. For example, the 471 receiving device could still report a policy violation such as an 472 unacceptable content-type, or an ICMP error trying to connect to a 473 downstream device. 475 5.4. MSRP Connection Model 477 When an MSRP endpoint wishes to send a request to a peer identified 478 by an MSRP URL, it first needs a transport connection, with the 479 appropriate security properties, to the host specified in the URL. 480 If the sender already has such a connection, that is, one associated 481 with the same host, port, and URL scheme, then it SHOULD reuse that 482 connection. 484 When a new MSRP session is created, the offerer MUST act as the 485 "active" endpoint, meaning that it is responsible for opening the 486 transport connection to the answerer, if a new connection is 487 required. However, this requirement MAY be weakened if standardized 488 mechanisms for negotiating the connection direction become available, 489 and is implemented by both parties to the connection. 491 Likewise, the active endpoint MUST immediately issue a SEND request. 492 This initial SEND request MAY have a body if the sender has content 493 to send, or it MAY have no body at all. 495 The first SEND request serves to bind a connection to an MSRP 496 session from the perspective of the passive endpoint. If the 497 connection is not authenticated with TLS, and the active endpoint 498 did not send an immediate request, the passive endpoint would have 499 no way to determine who had connected, and would not be able to 500 safely send any requests towards the active party until after the 501 active party sends its first request. 503 When an element needs to form a new connection, it looks at the URL 504 to decide on the type of connection (TLS, TCP, etc.) then connects to 505 the host indicated by the URL, following the URL resolution rules in 506 Section 6.2. Connections using the msrps: scheme MUST use TLS. The 507 SubjectAltName in the received certificate MUST match the hostname 508 part of the URL and the certificate MUST be valid, including having a 509 date that is valid and being signed by an acceptable certificate 510 authority. At this point the device that initiated the connection 511 can assume that this connection is with the correct host. 513 If the connection used mutual TLS authentication, and the TLS client 514 presented a valid certificate, then the element accepting the 515 connection can immediately know the identity of the connecting host. 516 When mutual TLS authentication is not used, the listening device MUST 517 wait until it receives a request on the connection, at which time it 518 infers the identity of the connecting device from the associated 519 session description. 521 When the first request arrives, its To-Path header field should 522 contain a URL that the listening element provided in the SDP for a 523 session. The element that accepted the connection looks up the URL 524 in the received request, and determines which session it matches. If 525 a match exists, the node MUST assume that the host that formed the 526 connection is the host to which this URL was given. If no match 527 exists, the node MUST reject the request with a 481 response. The 528 node MUST also check to make sure the session is not already in use 529 on another connection. If the session is already in use, it MUST 530 reject the request with a 506 response. 532 If it were legal to have multiple connections associated with the 533 same session, a security problem would exist. If the initial SEND 534 request is not protected, an eavesdropper might learn the URL, and 535 use it to insert messages into the session via a different 536 connection. 538 If a connection fails for any reason, then an MSRP endpoint MUST 539 consider any sessions associated with the connection as also having 540 failed. When either endpoint notices such a failure, it MAY attempt 541 to re-create any such sessions. If it chooses to do so, it MUST use 542 a new SDP exchange, for example, in a SIP re-INVITE . If a 543 replacement session is successfully created, endpoints MAY attempt to 544 resend any content for which delivery on the original session could 545 not be confirmed. If it does this, the Message-ID values for the 546 resent messages MUST match those used in the initial attempts. If 547 the receiving endpoint receives more than one message with the same 548 Message-ID, it SHOULD assume that the messages are duplicates. The 549 specific action that an endpoint takes when it receives a duplicate 550 message is a matter of local policy, except that it SHOULD NOT 551 present the duplicate messages to the user without warning of the 552 duplication. Note that acknowledgments as needed based on the 553 Failure-Report and Success-Report settings are still necessary even 554 for requests containing duplicate content. 556 When endpoints create a new session in this fashion, the chunks for a 557 given logical message MAY be split across the sessions. However, 558 endpoints SHOULD NOT split chunks between sessions under non-failure 559 circumstances. 561 If an endpoint attempts to re-create a failed session in this manner, 562 it MUST NOT assume that the MSRP URLs in the SDP will be the same as 563 the old ones. 565 A connection SHOULD NOT be closed while there are sessions associated 566 with it. 568 6. MSRP URLs 570 URLs using the MSRP and MSRPS schema are used to identify a session 571 of instant messages at a particular MSRP device. MSRP URLs are 572 ephemeral; an MSRP device will generally use a different MSRP URL for 573 each distinct session. An MSRP URL generally has no meaning outside 574 of the associated session. 576 An MSRP URL follows a subset of the URL syntax in Appendix A of 577 RFC3986 [10], with a scheme of "msrp" or "msrps". The syntax is 578 described in Section 9. 580 The constructions for "userinfo", and "unreserved" are detailed in 581 RFC3986 [10]. In order to allow IPV6 addressing, the construction 582 for hostport is that used for SIP in RFC3261. URLs designating MSRP 583 over TCP MUST include the "tcp" transport parameter. 585 Since this document only specifies MSRP over TCP, all MSRP URLs 586 herein use the "tcp" transport parameter. Documents that provide 587 bindings on other transports should define respective parameters 588 for those transports. 590 An MSRP URL hostport field identifies a participant in a particular 591 MSRP session. If the hostport contains a numeric IP address, it MUST 592 also contain a port. The session-id part identifies a particular 593 session of the participant. The absence of the session-id part 594 indicates a reference to an MSRP host device, but does not 595 specifically refer to a particular session. 597 A scheme of "msrps" indicates the underlying connection MUST be 598 protected with TLS. 600 MSRP has an IANA registered recommended port defined in Section 15.4. 601 This value is not a default, as the URL negotiation process described 602 herein will always include explicit port numbers. However, the URLs 603 SHOULD be configured so that the recommended port is used whenever 604 appropriate. This makes life easier for network administrators who 605 need to manage firewall policy for MSRP. 607 The hostport will typically not contain a userinfo component, but MAY 608 do so to indicate a user account for which the session is valid. 609 Note that this is not the same thing as identifying the session 610 itself. If a userinfo component exists, it MUST be constructed only 611 from "unreserved" characters, to avoid a need for escape processing. 612 Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo 613 part MUST NOT contain password information. 615 The limitation of userinfo to unreserved characters is an 616 additional restriction to the userinfo definition in RFC3986. 617 That version allows reserved characters. The additional 618 restriction is to avoid the need for escaping. 620 The following is an example of a typical MSRP URL: 622 msrp://host.example.com:8493/asfd34;tcp 624 6.1. MSRP URL Comparison 626 MSRP URL comparisons MUST be performed according to the following 627 rules: 629 1. The scheme must match. Scheme comparison is case insensitive. 631 2. If the hostpart contains an explicit IP address, and/or port, 632 these are compared for address and port equivalence. Otherwise, 633 hostpart is compared as a case insensitive character string. 635 3. If the port exists explicitly in either URL, then it must match 636 exactly. A URL with an explicit port is never equivalent to 637 another with no port specified. 639 4. The session-id part is compared as case sensitive. A URL without 640 a session-id part is never equivalent to one that includes one. 642 5. URLs with different "transport" parameters never match. Two URLs 643 that are identical except for transport are not equivalent. The 644 transport parameter is case-insensitive. 646 6. Userinfo parts are not considered for URL comparison. 648 Path normalization is not relevant for MSRP URLs. Escape 649 normalization is not required due to character restrictions in the 650 formal syntax. 652 6.2. Resolving MSRP Host Device 654 An MSRP host device is identified by the hostport of an MSRP URL. 656 If the hostport contains a numeric IP address and port, they MUST be 657 used as listed. 659 If the hostport contains a host name and a port, the connecting 660 device MUST determine a host address by doing an A or AAAA DNS query, 661 and use the port as listed. 663 If a connection attempt fails, the device SHOULD attempt to connect 664 to the addresses returned in any additional A or AAAA records, in the 665 order the records were presented. 667 This process assumes that the connection port is always known 668 prior to resolution. This is always true for the MSRP URL uses 669 described in this document, that is, URLs exchanged in the SDP 670 offer and answer. The introduction of relays may create 671 situations where this is not the case. For example, the MSRP URL 672 that a user enters into a client to configure it to use a relay 673 may be intended to be easily remembered and communicated by 674 humans, and therefore is likely to omit the port. Therefore, the 675 relay specification [22] may describe additional steps to resolve 676 the port number. 678 MSRP devices MAY use other methods for discovering other such 679 devices, when appropriate. For example, MSRP endpoints may use other 680 mechanisms to discover relays, which are beyond the scope of this 681 document. 683 7. Method-Specific Behavior 685 7.1. Constructing Requests 687 To form a new request, the sender creates a unique transaction 688 identifier and uses this and the method name to create an MSRP 689 request start line. Next, the sender places the target URL in a To- 690 Path header field, and the sender's URL in a From-Path header field. 691 If multiple URLs are present in the To-Path, the leftmost is the 692 first URL visited; the rightmost URL is the last URL visited. The 693 processing then becomes method specific. Additional method-specific 694 header fields are added as described in the following sections. 696 After any method-specific header fields are added, processing 697 continues to handle a body, if present. If the request has a body, 698 it must contain a Content-Type header field. It may contain other 699 MIME-specific header fields. The Content-Type header field MUST be 700 the last field in the message header section. The body MUST be 701 separated from the header fields with an extra CRLF. 703 Non-SEND requests are not intended to carry message content, and are 704 therefore not interruptible. Non-SEND request bodies MUST NOT be 705 larger than 10240 octets. 707 Although this document does not discuss any particular usage of 708 bodies in non-SEND requests, they may be useful in the future for 709 carrying security or identity information, information about a 710 message in progress, etc. The 10K size limit was chosen to be 711 large enough for most of such applications, but small enough to 712 avoid the fairness issues caused by sending arbitrarily large 713 content in non-interruptible method bodies. 715 A request with no body MUST NOT include a Content-Type header field. 716 Note that, if no body is present, no extra CRLF will be present 717 between the header section and the end-line. 719 Requests with no bodies are useful when a client wishes to send 720 "traffic", but does not wish to send content to be rendered to the 721 peer user. For example, the offerer must send a SEND request 722 immediately upon establishing a connection. If it has nothing to 723 say at the moment, it can send a request with no body. Bodiless 724 requests may also be used in certain applications to keep NAT 725 bindings alive, etc. 726 Bodiless requests are distinct from requests with empty bodies. A 727 request with an empty body will have a Content-Type header field 728 value, and will generally be rendered to the recipient according 729 to the rules for that type. 731 The end-line that terminates the request MUST be composed of seven 732 "-" (minus sign) characters, the transaction ID as used in the start 733 line, and a flag character. If a body is present, the end-line must 734 be preceded by a CRLF that is not part of the body. If the chunk 735 represents the data that forms the end of the complete message, the 736 flag value MUST be a "$". If sender is aborting an incomplete 737 message, and intends to send no further chunks in that message, it 738 MUST be a "#". Otherwise it MUST be a "+". 740 If the request contains a body, the sender MUST ensure that the end- 741 line (seven hyphens, the transaction identifier, and a continuation 742 flag) is not present in the body. If the end-line is present in the 743 body, the sender MUST choose a new transaction identifier that is not 744 present in the body, and add a CRLF if needed, and the end-line, 745 including the "$", "#", or "+" character. 747 Some implementations may choose to scan for the closing sequence as 748 they send the body, and if it is encountered, simply interrupt the 749 chunk at that point and start a new transaction with a different 750 transaction identifier to carry the rest of the body. Other 751 implementation may choose to scan the data an ensure that the body 752 does not contain the transaction identifier before they start sending 753 the transaction. 755 Finally, requests which have no body MUST NOT contain a Content-Type 756 header field or any other MIME specific header field. Requests 757 without bodies MUST contain a end-line after the final header field. 759 Once a request is ready for delivery, the sender follows the 760 connection management (Section 5.4) rules to forward the request over 761 an existing open connection or create a new connection. 763 7.1.1. Sending SEND Requests 765 When an endpoint has a message to deliver, it first generates a new 766 Message-ID. This ID MUST be globally unique. If necessary, it 767 breaks the message into chunks. It then generates a SEND request for 768 each chunk, following the procedures for constructing requests 769 (Section 7.1). 771 The Message-ID header field provides a globally unique message 772 identifier that refers to a particular version of a particular 773 message. The term "Message" in this context refers to a unit of 774 content that the sender wishes to convey to the recipient. While 775 such a message may be broken into chunks, the Message-ID refers to 776 the entire message, not a chunk of the message. 777 The uniqueness of the message identifier is guaranteed by the host 778 that generates it. This message identifier is intended to be 779 machine readable and not necessarily meaningful to humans. A 780 message identifier pertains to exactly one version of a particular 781 message; subsequent revisions to the message each receive new 782 message identifiers. 784 Each chunk of a message MUST contain a Message-ID header field 785 containing the Message-ID. If the sender wishes non-default status 786 reporting, it MUST insert a Failure-Report and/or Success-Report 787 header field with an appropriate value. All chunks of the same 788 message MUST use the same Failure-Report and Success-Report values in 789 their SEND requests. 791 If success reports are requested, i.e. the value of the Success- 792 Report header field is "yes", the sending device MAY wish to run a 793 timer of some value that makes sense for its application and take 794 action if a success Report is not received in this time. There is no 795 universal value for this timer. For many IM applications, it may be 796 2 minutes while for some trading systems it may be under a second. 797 Regardless of whether such a timer is used, if the success report has 798 not been received by the time the session is ended, the device SHOULD 799 inform the user. 801 If the value of "Failure-Report" is set to "yes", then the sender of 802 the request runs a timer. If a 200 response to the transaction is 803 not received within 30 seconds from the time the last byte of the 804 transaction is sent, or submitted to the operating system for 805 sending, the element MUST inform the user that the request probably 806 failed. If the value is set to "partial", then the element sending 807 the transaction does not have to run a timer, but MUST inform the 808 user if it receives a non-recoverable error response to the 809 transaction. 811 If no Success-Report header field is present in a SEND request, it 812 MUST be treated the same as a Success-Report header field with value 813 of "no". If no Failure-Report header field is present, it MUST be 814 treated the same as a Failure-Report header field with value of 815 "yes". If an MSRP endpoint receives a REPORT for a Message-ID it 816 does not recognize, it SHOULD silently ignore the REPORT. 818 Success-Report and Failure-Report header fields MUST NOT be present 819 in REPORT requests. MSRP nodes MUST NOT send REPORT requests in 820 response to REPORT requests. MSRP Nodes MUST NOT send MSRP responses 821 to REPORT requests. 823 The Byte-Range header field value contains a starting value (range- 824 start) followed by a "-", an ending value (range-end) followed by a 825 "/", and finally the total length. The first octet in the message 826 has a position of one, rather than a zero. 828 The first chunk of the message SHOULD, and all subsequent chunks MUST 829 include a Byte-Range header field. The range-start field MUST 830 indicate the position of the first byte in the body in the overall 831 message (for the first chunk this field will have a value of one). 832 The range-end field SHOULD indicate the position of the last byte in 833 the body, if known. It MUST take the value of "*" if the position is 834 unknown, or if the request needs to be interruptible. The total 835 field SHOULD contain the total size of the message, if known. The 836 total field MAY contain a "*" if the total size of the message is not 837 known in advance. The sender MUST send all chunks in Byte-Range 838 order. (However, the receiver cannot assume the requests will be 839 delivered in order, as intervening relays may have changed the 840 order.) 842 To ensure fairness over a connection, senders MUST NOT send chunks 843 with a body larger than 2048 octets unless they are prepared to 844 interrupt them (meaning that any chunk with a body of greater than 845 2048 octets will have a "*" character in the range-end field). A 846 sender can use one of the following two strategies to satisfy this 847 requirement. The sender is STRONGLY RECOMMENDED to send messages 848 larger than 2048 octets using as few chunks as possible, interrupting 849 chunks (at least 2048 octets long) only when other traffic is waiting 850 to use the same connection. Alternatively, the sender MAY simply 851 send chunks in 2048 octet increments until the final chunk. Note 852 that the former strategy results in markedly more efficient use of 853 the connection. All MSRP nodes MUST be able to receive chunks of any 854 size from zero octets to the maximum number of octets they can 855 receive for a complete message. Senders SHOULD NOT break messages 856 into chunks smaller than 2048 octets, except for the final chunk of a 857 complete message. 859 A SEND request is interrupted while a body is in the process of being 860 written to the connection by simply noting how much of the message 861 has already been written to the connection, then writing out the end- 862 line to end the chunk. It can then be resumed in a another chunk 863 with the same Message-ID and a Byte-Range header field range start 864 field containing the position of the first byte after the 865 interruption occurred. 867 SEND requests larger than 2048 octets MUST be interrupted if the 868 sender needs to send pending responses or REPORT requests. If 869 multiple SEND requests from different sessions are concurrently being 870 sent over the same connection, the device SHOULD implement some 871 scheme to alternate between them such that each concurrent request 872 gets a chance to send some fair portion of data at regular intervals 873 suitable to the application. 875 The sender MUST NOT assume that a message is received by the peer 876 with the same chunk allocation with which it was sent. An 877 intervening relay could possibly break SEND requests into smaller 878 chunks, or aggregate multiple chunks into larger ones. 880 The default disposition of bodies is "render". If the sender wants 881 different disposition, it MAY insert a Content-Disposition[9] header 882 field. Since MSRP can carry unencoded binary payloads, transfer 883 encoding is always "binary", and transfer-encoding parameters MUST 884 NOT be present. 886 7.1.2. Sending REPORT Requests 888 REPORT requests are similar to SEND requests, except that report 889 requests MUST NOT include Success-Report or Failure-Report header 890 fields, and MUST contain a Status header field. REPORT requests MUST 891 contain the Message-ID header field from the original SEND request. 893 If an MSRP element receives a REPORT for a Message-ID it does not 894 recognize, it SHOULD silently ignore the REPORT. 896 An MSRP endpoint MUST be able to generate success REPORT requests. 898 REPORT requests will normally not include a body, as the REPORT 899 request header fields can carry sufficient information in most cases. 900 However, REPORT requests MAY include a body containing additional 901 information about the status of the associated SEND request. Such a 902 body is informational only, and the sender of the REPORT request 903 SHOULD NOT assume that the recipient pays any attention to the body. 904 REPORT requests are not interruptible. 906 7.1.3. Generating Success Reports 908 An endpoint MUST send a success report if it successfully receives a 909 SEND request which contained a Success-Report value of "yes" and 910 either contains a complete message, or contains the last chunk needed 911 to complete the message. This request is sent following the normal 912 procedures (Section 7.1), with a few additional requirements. 914 The endpoint inserts a To-Path header field containing the From-Path 915 value from the original request, and a From-Path header field 916 containing the URL identifying itself in the session. The endpoint 917 then inserts a Status header field with a namespace of "000", a 918 short-status of "200" and an implementation defined comment phrase. 919 It also inserts a Message-ID header field containing the value from 920 the original request. 922 The namespace field denotes the context of the short-status field. 923 The namespace value of "000" means the short-status should be 924 interpreted in the same way as the matching MSRP transaction 925 response code. If a future specification uses the short-status 926 field for some other purpose, it MUST define a new namespace field 927 value. 929 The endpoint MUST NOT send a success report for a SEND request that 930 either contained no Success-Report header field, or contained such a 931 field with a value of "no". That is, if no Success-Report header 932 field is present, it is treated identically to one with a value of 933 "no." 935 7.1.4. Generating Failure Reports 937 If an MSRP endpoint receives a SEND request that it cannot process 938 for some reason, and the Failure-Report header field either was not 939 present in the original request, or had a value of "yes", it SHOULD 940 simply include the appropriate error code in the transaction 941 response. However, there may be situations where the error cannot be 942 determined quickly, such as when the endpoint is a gateway that must 943 wait for a downstream network to indicate an error. In this 944 situation, it MAY send a 200 OK response to the request, and then 945 send a failure REPORT request when the error is detected. 947 If the endpoint receives a SEND request with a Failure-Report header 948 field value of "no", then it MUST NOT send a failure REPORT request, 949 and MUST NOT send a transaction response. If the value is "partial", 950 it MUST NOT send a 200 transaction response to the request, but 951 SHOULD send an appropriate non-200 class response if a failure 952 occurs. 954 As stated above, if no Failure-Report header field is present, it 955 MUST be treated the same as a Failure-Report header field with value 956 of "yes". 958 Construction of failure REPORT requests is identical to that for 959 success REPORT requests, except the Status header field code and 960 reason fields MUST contain appropriate error codes. Any error 961 response code defined in this specification MAY also be used in 962 failure reports. 964 If a failure REPORT request is sent in response to a SEND request 965 that contained a chunk, it MUST include a Byte-Range header field 966 indicating the actual range being reported on. It can take the 967 range-start and total values from the original SEND request, but MUST 968 calculate the range-end field from the actual body data. 970 Endpoints SHOULD NOT send REPORT requests if they have reason to 971 believe the request will not be delivered. For example, they SHOULD 972 NOT send a REPORT request on a session that is no longer valid. 974 This section only describes failure report generation behavior for 975 MSRP endpoints. Relay behavior is beyond the scope of this 976 document, and will be considered in a separate document [22]. We 977 expect failure reports to be more commonly generated by relays 978 than by endpoints. 980 7.2. Constructing Responses 982 If an MSRP endpoint receives a request that either contains a 983 Failure-Report header field value of "yes", or does not contain a 984 Failure-Report header field at all, it MUST immediately generate a 985 response. Likewise, if an MSRP endpoint receives a request that 986 contains a Failure-Report header field value of "partial", and the 987 receiver is unable to process the request, it SHOULD immediately 988 generate a response. 990 To construct the response, the endpoint first creates the response 991 start-line, inserting appropriate response code and reason fields. 992 The transaction identifier in the response start line MUST match the 993 transaction identifier from the original request. 995 The endpoint then inserts an appropriate To-Path header field. If 996 the request triggering the response was a SEND request, the To-Path 997 header field is formed by copying the last (right-most) URL in the 998 From-Path header field of the request. (Responses to SEND requests 999 are returned only to the previous hop.) For responses to all other 1000 request methods, the To-Path header field contains the full path back 1001 to the original sender. This full path is generated by taking the 1002 list of URLs from the From-Path of the original request, reversing 1003 the list, and writing the reversed list into the To-Path of the 1004 response. (Legal REPORT requests do not request responses, so this 1005 specification doesn't exercise the behavior described above, however 1006 we expect that extensions for gateways and relays will need such 1007 behavior.) 1009 Finally, the endpoint inserts a From-Path header field containing the 1010 URL that identifies it in the context of the session, followed by the 1011 end-line after the last header field. The response MUST be 1012 transmitted back on the same connection on which the original request 1013 arrived. 1015 7.3. Receiving Requests 1017 The receiving endpoint must first check the URL in the To-Path to 1018 make sure the request belongs to an existing session. When the 1019 request is received, the To-Path will have exactly one URL, which 1020 MUST map to an existing session that is associated with the 1021 connection on which the request arrived. If this is not true, then 1022 the receiver MUST generate a 481 error and ignore the request. Note 1023 that if the Failure-Report header field had a value of "no", then no 1024 error report would be sent. 1026 Further request processing by the receiver is method specific. 1028 7.3.1. Receiving SEND Requests 1030 When the receiving endpoint receives a SEND request, it first 1031 determines if it contains a complete message, or a chunk from a 1032 larger message. If the request contains no Byte-Range header field, 1033 or contains one with a range-start value of "1", and the closing line 1034 continuation flag has a value of "$", then the request contained the 1035 entire message. Otherwise, the receiver looks at the Message-ID 1036 value to associate chunks together into the original message. It 1037 forms a virtual buffer to receive the message, keeping track of which 1038 bytes have been received and which are missing. The receiver takes 1039 the data from the request and places it in the appropriate place in 1040 the buffer. The receiver SHOULD determine the actual length of each 1041 chunk by inspecting the payload itself; it is possible the body is 1042 shorter than the range-end field indicates. This can occur if the 1043 sender interrupted a SEND request unexpectedly. It is worth noting 1044 that the chunk that has a termination character of "$" defines the 1045 total length of the message. 1047 It is technically illegal for the sender to prematurely interrupt 1048 a request that had anything other than "*" in the last-byte 1049 position of the Byte-Range header field. But having the receiver 1050 calculate a chunk length based on actual content adds resilience 1051 in the face of sender errors. Since this should never happen with 1052 compliant senders, this only has a SHOULD strength. 1054 Receivers MUST not assume the chunks will be delivered in order or 1055 that they will receive all the chunks with "+" flags before they 1056 receive the chunk with the "$" flag. In certain cases of connection 1057 failure, it is possible for information to be duplicated. If chunk 1058 data is received that overlaps already received data for the same 1059 message, the last chunk received SHOULD take precedence (even though 1060 this may not have been the last chunk transmitted). For example, if 1061 bytes 1 to 100 were received and a chunk arrives that contains bytes 1062 50 to 150, this second chunk will overwrite bytes 50 to 100 of the 1063 data that had already been received. Although other schemes work, 1064 this is the easiest for the receiver and results in consistent 1065 behavior between clients. 1067 There are situations in which the receiver may not be able to give 1068 precedence to the last chunk received when chunks overlap. For 1069 example, the recipient might incrementally render chunks as they 1070 arrive. If a new chunk arrives that overlaps with a previously 1071 rendered chunk, it would be too late to "take back" any 1072 conflicting data from the first chunk. Therefore, the requirement 1073 to give precedence to the most recent chunk is specified at a 1074 "SHOULD" strength. This requirement is not intended to disallow 1075 applications where this behavior does not make sense. 1077 The seven "-" in the end-line are used so that the receiver can 1078 search for the value "----", 32 bits at a time to find the probable 1079 location of the end-line. This allows most processors to locate the 1080 boundaries and copy the memory at the same rate that a normal memory 1081 copy could be done. This approach results in a system that is as 1082 fast as framing based on specifying the body length in the header 1083 fields of the request, but also allows for the interruption of 1084 messages. 1086 What is done with the body is outside the scope of MSRP and largely 1087 determined by the MIME Content-Type and Content-Disposition. The 1088 body MAY be rendered after the whole message is received or partially 1089 rendered as it is being received. 1091 If the SEND request contained a Content-Type header field indicating 1092 an unsupported MIME type, and the Failure-Report value is not "no", 1093 the receiver MUST generate a response with a status code of 415. All 1094 MSRP endpoints MUST be able to receive the multipart/mixed [15] and 1095 multipart/alternative [15] MIME types. 1097 If the Success-Report header field was set to "yes", then when a 1098 complete message has been received, the receiver MUST send a success 1099 REPORT with a byte range covering the whole message. If the Success- 1100 Report header field is set to "yes", then the receiver MAY generate 1101 incremental success REPORTs as the chunks are received. These can be 1102 sent periodically and cover all the bytes that have been received so 1103 far, or they can be sent after a chunk arrives and cover just the 1104 part from that chunk. 1106 It is helpful to think of a success REPORT as reporting on a 1107 particular range of bytes, rather than on a particular chunk sent 1108 by a client. The sending client cannot depend on the Byte-Range 1109 header field in a given success report matching that of a 1110 particular SEND request. For example, an intervening MSRP relay 1111 may break chunks into smaller chunks, or aggregate multiple chunks 1112 into larger ones. 1113 A side effect of this is, even if no relay is used, the receiving 1114 client may report on byte ranges that do not exactly match those 1115 in the original chunks sent by the sender. It can wait until all 1116 bytes in a message are received and report on the whole, it can 1117 report as it receives each chunk, or it can report on any other 1118 received range. 1119 Reporting on ranges smaller than the entire message contents 1120 allows certain improved user experiences for the sender. For 1121 example, a sending client could display incremental status 1122 information showing which ranges of bytes have been acknowledged 1123 by the receiver. 1124 However, the choice on whether to report incrementally is entirely 1125 up to the receiving client. There is no mechanism for the sender 1126 to assert its desire to receive incremental reports or not. Since 1127 the presence of a relay can cause the receiver to see a very 1128 different chunk allocation than the sender, such a mechanism would 1129 be of questionable value. 1131 7.3.2. Receiving REPORT Requests 1133 When an endpoint receives a REPORT request, it correlates it to the 1134 original SEND request using the Message-ID and the Byte-Range, if 1135 present. If it requested success reports, then it SHOULD keep enough 1136 state about each outstanding sent message so that it can correlate 1137 REPORT requests to the original messages. 1139 An endpoint that receives a REPORT request containing a Status header 1140 field with a namespace field of "000" MUST interpret the report in 1141 exactly the same way it would interpret an MSRP transaction response 1142 with a response code matching the short-code field. 1144 It is possible to receive a failure report or a failure transaction 1145 response for a chunk that is currently being delivered. In this 1146 case, the entire message corresponding to that chunk SHOULD be 1147 aborted, by including the "#" character in the continuation field of 1148 the end-line. 1150 It is possible that an endpoint will receive a REPORT request on a 1151 session that is no longer valid. The endpoint's behavior if this 1152 happens is a matter of local policy. The endpoint is not required to 1153 take any steps to facilitate such late delivery, i.e. it is not 1154 expected to keep a connection active in case late REPORTs might 1155 arrive. 1157 When an endpoint that sent a SEND request receives a failure REPORT 1158 indicating that a particular byte range was not received, it MUST 1159 treat the session as failed. If it wishes to recover, it MUST first 1160 re-negotiate the URLs at the signaling level then resend that range 1161 of bytes of the message on the resulting new session. 1163 MSRP nodes MUST NOT send MSRP REPORT requests in responses to other 1164 REPORT requests. 1166 8. Using MSRP with SIP and SDP 1168 MSRP sessions will typically be initiated using the Session 1169 Description Protocol (SDP) [2] via the SIP offer/answer mechanism 1170 [3]. 1172 This document defines a handful of new SDP parameters to set up MSRP 1173 sessions. These are detailed below and in the IANA Considerations 1174 section. 1176 An MSRP media-line (that is, a media-line proposing MSRP) in the 1177 session description is accompanied by a mandatory "path" attribute. 1178 This attribute contains a space-separated list of URLs that must be 1179 visited to contact the user agent advertising this session- 1180 description. If more than one URL is present, the leftmost URL is 1181 the first URL that must be visited to reach the target resource. 1182 (The path list can contain multiple URLs to allow for the deployment 1183 of gateways or relays in the future.) MSRP implementations that can 1184 accept incoming connections without the need for relays will 1185 typically only provide a single URL here. 1187 An MSRP media line is also accompanied by an "accept-types" 1188 attribute, and optionally an "accept-wrapped-types" attribute. These 1189 attributes are used to specify the MIME types that are acceptable to 1190 the endpoint. 1192 8.1. SDP Connection and Media Lines 1194 The format of an SDP connection-line takes the following format: 1196 c=
1198 The network type and address type fields are used as normal for SDP. 1199 The connection address field MUST be set to the IP address or fully 1200 qualified domain name from the MSRP URL identifying the endpoint in 1201 its path attribute. 1203 The general format of an SDP media-line is: 1205 m= 1207 An offered or accepted media-line for MSRP over TCP MUST include a 1208 protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The 1209 media field value MUST be "message". The format list field MUST be 1210 set to "*". 1212 The port field value MUST match the port value used in the endpoint's 1213 MSRP URL in the path attribute, except that, as described in [3], a 1214 user agent that wishes to accept an offer, but not a specific media- 1215 line MUST, set the port number of that media-line to zero (0) in the 1216 response. Since MSRP allows multiple sessions to share the same TCP 1217 connection, multiple m-lines in a single SDP document may share the 1218 same port field value; MSRP devices MUST NOT assume any particular 1219 relationship between m-lines on the sole basis that they have 1220 matching port field values. 1222 MSRP devices do not use the c-line address field, or the m-line 1223 port and format list fields to determine where to connect. 1224 Rather, they use the attributes defined in this specification. 1225 The connection information is copied to the c-line and m-line for 1226 purposes of backwards compatibility with conventional SDP usages. 1227 While MSRP could theoretically carry any media type, "message" is 1228 appropriate. 1230 8.2. URL Negotiations 1232 Each endpoint in an MSRP session is identified by a URL. These URLs 1233 are negotiated in the SDP exchange. Each SDP offer or answer that 1234 proposes MSRP MUST contain a path attribute containing one or more 1235 MSRP URLs. The path attribute is used in an SDP a-line, and has the 1236 following syntax: 1238 path = path-label ":" path-list 1239 path-label = "path" 1240 path-list= MSRP-URL *(SP MSRP-URL) 1242 where MSRP-URL is an msrp: or msrps: URL as defined in Section 6. 1243 MSRP URLs included in an SDP offer or answer MUST include explicit 1244 port numbers. 1246 An MSRP device uses the URL to determine a host address, port, 1247 transport, and protection level when connecting, and to identify the 1248 target when sending requests and responses. 1250 The offerer and answerer each selects a URL to represent itself and 1251 sends it to the peer device in the SDP document. Each device stores 1252 the path value received from the peer and uses that value as the 1253 target for requests inside the resulting session. If the path 1254 attribute received from the peer contains more than one URL, then the 1255 target URL is the rightmost, while the leftmost entry represents the 1256 adjacent hop. If only one entry is present, then it is both the peer 1257 and adjacent hop URL. The target path is the entire path attribute 1258 value received from the peer. 1260 The following example shows an SDP offer with a session URL of 1261 "msrp://alice.example.com:7394/2s93i;tcp" 1263 v=0 1264 o=alice 2890844526 2890844527 IN IP4 alice.example.com 1265 s= - 1266 c=IN IP4 alice.example.com 1267 t=0 0 1268 m=message 7394 TCP/MSRP * 1269 a=accept-types:text/plain 1270 a=path:msrp://alice.example.com:7394/2s93i;tcp 1272 The rightmost URL in the path attribute MUST identify the endpoint 1273 that generated the SDP document, or some other location where that 1274 endpoint wishes to receive requests associated with the session. It 1275 MUST be assigned for this particular session, and MUST NOT duplicate 1276 any URL in use for any other session in which the endpoint is 1277 currently participating. It SHOULD be hard to guess, and protected 1278 from eavesdroppers. This is discussed in more detail in Section 14. 1280 8.3. Path Attributes with Multiple URLs 1282 As mentioned previously, this document describes MSRP for peer-to- 1283 peer scenarios, that is, when no relays are used. The use of relays 1284 are described in a separate document [22]. In order to allow an MSRP 1285 device that only implements the core specification to interoperate 1286 with devices that use relays, this document must include a few 1287 assumptions about how relays work. 1289 An endpoint that uses one or more relays will indicate that by 1290 putting a URL for each device in the relay chain into the SDP path 1291 attribute. The final entry will point to the endpoint itself. The 1292 other entries will indicate each proposed relay, in order. The first 1293 entry will point to the first relay in the chain from the perspective 1294 of the peer; that is, the relay to which the peer device, or a relay 1295 operating on its behalf, should connect. 1297 Endpoints that do not wish to insert a relay, including those that do 1298 not support relays at all, will put exactly one URL into the path 1299 attribute. This URL represents both the endpoint for the session, 1300 and the connection point. 1302 Even though endpoints that implement only this specification will 1303 never introduce a relay, they need to be able to interoperate with 1304 other endpoints that do use relays. Therefore, they MUST be prepared 1305 to receive more than one URL in the SDP path attribute. When an 1306 endpoint receives more than one URL in a path attribute, only the 1307 first entry is relevant for purposes of resolving the address and 1308 port, and establishing the network connection, as it describes the 1309 first adjacent hop. 1311 If an endpoint puts more than one URL in a path attribute, the final 1312 URL in the path attribute (the peer URL) identifies the session, and 1313 must not duplicate the URL of any other session in which the endpoint 1314 is currently participating. Uniqueness requirements for other 1315 entries in the path attribute are out of scope for this document. 1317 8.4. Updated SDP Offers 1319 MSRP endpoints may sometimes need to send additional SDP exchanges 1320 for an existing session. They may need to send periodic exchanges 1321 with no change to refresh state in the network, for example, SIP 1322 session timers or the SIP UPDATE[23] request. They may need to 1323 change some other stream in a session without affecting the MSRP 1324 stream, or they may need to change an MSRP stream without affecting 1325 some other stream. 1327 Either peer may initiate an updated exchange at any time. The 1328 endpoint that sends the new offer assumes the role of offerer for all 1329 purposes. The answerer MUST respond with a path attribute that 1330 represents a valid path to itself at the time of the updated 1331 exchange. This new path may be the same as its previous path, but 1332 may be different. The new offerer MUST NOT assume that the peer will 1333 answer with the same path it used previously. 1335 If either party wishes to send an SDP document that changes nothing 1336 at all, then it MUST have the same o-line as in the previous 1337 exchange. 1339 8.5. Connection Negotiation 1341 Previous versions of this document included a mechanism to negotiate 1342 the direction for any required TCP connection. The mechanism was 1343 loosely based on the COMEDIA [25] work being done in the MMUSIC 1344 working group. The primary motivation was to allow MSRP sessions to 1345 succeed in situations where the offerer could not accept connections 1346 but the answerer could. For example, the offerer might be behind a 1347 NAT, while the answerer might have a globally routable address. 1349 The SIMPLE working group chose to remove that mechanism from MSRP, as 1350 it added a great deal of complexity to connection management. 1351 Instead, MSRP now specifies a default connection direction. The 1352 party that sent the original offer is responsible for connecting to 1353 its peer. 1355 8.6. Content Type Negotiation 1357 An SDP media-line proposing MSRP MUST be accompanied by an accept- 1358 types attribute. 1360 An entry of "*" in the accept-types attribute indicates that the 1361 sender may attempt to send content with media types that have not 1362 been explicitly listed. Likewise, an entry with an explicit type and 1363 a "*" character as the subtype indicates that the sender may attempt 1364 to send content with any subtype of that type. If the receiver 1365 receives an MSRP request and is able to process the media type, it 1366 does so. If not, it will respond with a 415 response. Note that all 1367 explicit entries SHOULD be considered preferred over any non-listed 1368 types. This feature is needed as, otherwise, the list of formats for 1369 rich IM devices may be prohibitively large. 1371 The accept-types attribute may include container types, that is, MIME 1372 formats that contain other types internally. If compound types are 1373 used, the types listed in the accept-types attribute may be used both 1374 as the root payload, or may be wrapped in a listed container type. 1375 Any container types MUST also be listed in the accept-types 1376 attribute. 1378 Occasionally an endpoint will need to specify a MIME body type that 1379 can only be used if wrapped inside a listed container type. 1381 Endpoints MAY specify MIME types that are only allowed when wrapped 1382 inside compound types using the "accept-wrapped-types" attribute in 1383 an SDP a-line. 1385 The semantics for accept-wrapped-types are identical to those of the 1386 accept-types attribute, with the exception that the specified types 1387 may only be used when wrapped inside container types listed in 1388 accept-types attribute. Only types listed in the accept-types 1389 attribute may be used as the "root" type for the entire body. Since 1390 any type listed in accept-types may be used both as a root body, and 1391 wrapped in other bodies, format entries from accept-types SHOULD NOT 1392 be repeated in this attribute. 1394 This approach does not allow for specifying distinct lists of 1395 acceptable wrapped types for different types of containers. If an 1396 endpoint understands a MIME type in the context of one wrapper, it is 1397 assumed to understand it in the context of any other acceptable 1398 wrappers, subject to any constraints defined by the wrapper types 1399 themselves. 1401 The approach of specifying types that are only allowed inside of 1402 containers separately from the primary payload types allows an 1403 endpoint to force the use of certain wrappers. For example, a 1404 CPIM [12] gateway device may require all messages to be wrapped 1405 inside message/cpim bodies, but may allow several content types 1406 inside the wrapper. If the gateway were to specify the wrapped 1407 types in the accept-types attribute, its peer might attempt to use 1408 those types without the wrapper. 1410 If the recipient of an offer does not understand any of the payload 1411 types indicated in the offered SDP, it SHOULD indicate that using the 1412 appropriate mechanism of the rendezvous protocol. For example, in 1413 SIP, it SHOULD return a SIP 488 response. 1415 An endpoint MAY indicate the maximum size message they wish to 1416 receive using the max-size a-line attribute. Max-size refers to the 1417 complete message in octets, not the size of any one chunk. Senders 1418 SHOULD NOT exceed the max-size limit for any message sent in the 1419 resulting session. However, the receiver should consider max-size 1420 value as a hint. 1422 The formal syntax for these attributes are as follows: 1424 accept-types = accept-types-label ":" format-list 1425 accept-types-label = "accept-types" 1426 accept-wrapped-types = wrapped-types-label ":" format-list 1427 wrapped-types-label = "accept-wrapped-types" 1428 format-list = format-entry *( SP format-entry) 1429 format-entry = (type "/" subtype) / (type "/" "*") / ("*") 1430 type = token 1431 subtype = token 1433 max-size = max-size-label ":" max-size-value 1434 max-size-label = "max-size" 1435 max-size-value = 1*(DIGIT) ;max size in octets 1437 8.7. Example SDP Exchange 1439 Endpoint A wishes to invite Endpoint B to an MSRP session. A offers 1440 the following session description: 1442 v=0 1443 o=usera 2890844526 2890844527 IN IP4 alice.example.com 1444 s= - 1445 c=IN IP4 alice.example.com 1446 t=0 0 1447 m=message 7394 TCP/MSRP * 1448 a=accept-types: message/cpim text/plain text/html 1449 a=path:msrp://alice.example.com:7394/2s93i9;tcp 1451 B responds with its own URL: 1453 v=0 1454 o=userb 2890844530 2890844532 IN IP4 bob.example.com 1455 s= - 1456 c=IN IP4 bob.example.com 1457 t=0 0 1458 m=message 8493 TCP/MSRP * 1459 a=accept-types:message/cpim text/plain 1460 a=path:msrp://bob.example.com:8493/si438ds;tcp 1462 8.8. MSRP User Experience with SIP 1464 In typical SIP applications, when an endpoint receives an INVITE 1465 request, it alerts the user, and waits for user input before 1466 responding. This is analogous to the typical telephone user 1467 experience, where the callee "answers" the call. 1469 In contrast, the typical user experience for instant messaging 1470 applications is that the initial received message is immediately 1471 displayed to the user, without waiting for the user to "join" the 1472 conversation. Therefore, the principle of least surprise would 1473 suggest that MSRP endpoints using SIP signaling SHOULD allow a mode 1474 where the endpoint quietly accepts the session, and begins displaying 1475 messages. 1477 This guideline may not make sense for all situations, such as for 1478 mixed media applications, where both MSRP and audio sessions are 1479 offered in the same INVITE. In general, good application design 1480 should take precedence. 1482 SIP INVITE requests may be forked by a SIP proxy, resulting in more 1483 than one endpoint receiving the same INVITE. SIP early media [28] 1484 techniques can be used to establish a preliminary session with each 1485 endpoint so the initial message(s) are displayed on each endpoint, 1486 and canceling the INVITE transaction for any endpoints that do not 1487 send MSRP traffic after some period of time, so that they cease 1488 receiving MSRP traffic from the inviter. 1490 9. Formal Syntax 1492 MSRP is a text protocol that uses the UTF-8 [14] transformation 1493 format. 1495 The following syntax specification uses the augmented Backus-Naur 1496 Form (BNF) as described in RFC-2234 [6]. 1498 msrp-req-or-resp = msrp-request / msrp-response 1499 msrp-request = req-start headers [content-stuff] end-line 1500 msrp-response = resp-start headers end-line 1502 req-start = pMSRP SP transact-id SP method CRLF 1503 resp-start = pMSRP SP transact-id SP status-code [SP comment] CRLF 1504 comment = utf8text 1506 pMSRP = %x4D.53.52.50 ; MSRP in caps 1507 transact-id = ident 1508 method = mSEND / mREPORT / other-method 1509 mSEND = %x53.45.4e.44 ; SEND in caps 1510 mREPORT = %x52.45.50.4f.52.54; REPORT in caps 1512 other-method = 1*UPALPHA 1513 status-code = 3DIGIT ; any code defined in this document 1514 ; or an extension document 1516 MSRP-URL = msrp-scheme "://" [userinfo "@"] hostport 1517 ["/" session-id] ";" transport *( ";" url-parameter) 1518 ; userinfo as defined in RFC3986, except 1519 ; limited to unreserved. 1520 ; hostport as defined in RFC3261 1522 msrp-scheme = "msrp" / "msrps" 1523 session-id = 1*( unreserved / "+" / "=" / "/" ) 1524 ; unreserved as defined in RFC3986 1525 transport = "tcp" / ALPHANUM 1526 url-parameter = token ["=" token] 1528 headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) 1530 header = Message-ID 1531 / Success-Report 1532 / Failure-Report 1533 / Byte-Range 1534 / Status 1535 / ext-header 1537 To-Path = "To-Path:" SP MSRP-URL *( SP MSRP-URL ) 1538 From-Path = "From-Path:" SP MSRP-URL *( SP MSRP-URL ) 1539 Message-ID = "Message-ID:" SP ident 1540 Success-Report = "Success-Report:" SP ("yes" / "no" ) 1541 Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" ) 1542 Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total 1543 range-start = 1*DIGIT 1544 range-end = 1*DIGIT / "*" 1545 total = 1*DIGIT / "*" 1547 Status = "Status:" SP namespace SP status-code [SP text-reason] 1548 namespace = 3(DIGIT); "000" for all codes defined in this document. 1549 text-reason = utf8text 1551 ident = alphanum 3*31ident-char 1552 ident-char = alphanum / "." / "-" / "+" / "%" / "=" 1554 content-stuff = *(Other-Mime-header CRLF) 1555 Content-Type 2CRLF data CRLF 1557 Content-Type = "Content-Type:" SP media-type 1558 media-type = type "/" subtype *( ";" gen-param ) 1559 type = token 1560 subtype = token 1562 gen-param = pname [ "=" pval ] 1563 pname = token 1564 pval = token / quoted-string 1566 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E 1567 / %x30-39 / %x41-5A / %x5E-7E) 1568 ; token is compared case-insensitive 1570 quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE 1571 qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E 1572 / UTF8-NONASCII 1573 qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) 1574 BACKSLASH = "\" 1575 UPALPHA = %x41-5A 1576 ALPHANUM = ALPHA / DIGIT 1578 Other-Mime-header = (Content-ID 1579 / Content-Description 1580 / Content-Disposition 1581 / mime-extension-field); 1583 ; Content-ID, and Content-Description are defined in RFC2045. 1584 ; Content-Disposition is defined in RFC2183 1585 ; MIME-extension-field indicates additional MIME extension 1586 ; header fields as described in RFC2045 1588 data = *OCTET 1589 end-line = "-------" transact-id continuation-flag CRLF 1590 continuation-flag = "+" / "$" / "#" 1592 ext-header = hname ":" SP hval CRLF 1593 hname = ALPHA *token 1594 hval = utf8text 1596 utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) 1598 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 1599 / %xE0-EF 2UTF8-CONT 1600 / %xF0-F7 3UTF8-CONT 1601 / %xF8-Fb 4UTF8-CONT 1602 / %xFC-FD 5UTF8-CONT 1603 UTF8-CONT = %x80-BF 1605 10. Response Code Descriptions 1607 This section summarizes the semantics of various response codes that 1608 may be used in MSRP transaction responses. These codes may also be 1609 used in the Status header field in REPORT requests. 1611 10.1. 200 1613 The 200 response code indicates a successful transaction. 1615 10.2. 400 1617 A 400 response indicates a request was unintelligible. The sender 1618 may retry the request after correcting the error. 1620 10.3. 403 1622 A 403 response indicates the attempted action is not allowed. The 1623 sender should not try the request again. 1625 10.4. 408 1627 A 408 response indicates that a downstream transaction did not 1628 complete in the alloted time. It is never sent by any elements 1629 described in this specification. However, 408 is used in the MSRP 1630 Relay extension; therefore MSRP endpoints may receive it. An 1631 endpoint MUST treat a 408 response in the same manner as it would 1632 treat a local timeout. 1634 10.5. 413 1636 A 413 response indicates that the receiver wishes the sender to stop 1637 sending the particular message. Typically, a 413 is sent in response 1638 to a chunk of an undesired message. 1640 If a message sender receives a 413 in a response, or in a REPORT 1641 request, it MUST NOT send any further chunks in the message, that is, 1642 any further chunks with the same Message-ID value. If the sender 1643 receives the 413 while in the process of sending a chunk, and the 1644 chunk is interruptible, the sender MUST interrupt it. 1646 10.6. 415 1648 A 415 response indicates the SEND request contained a MIME content- 1649 type that is not understood by the receiver. The sender should not 1650 send any further messages with the same content-type for the duration 1651 of the session. 1653 10.7. 423 1655 A 423 response indicates that one of the requested parameters is out 1656 of bounds. It is used by the relay extensions to this document. 1658 10.8. 481 1660 A 481 response indicates that the indicated session does not exist. 1661 The sender should terminate the session. 1663 10.9. 501 1665 A 501 response indicates that the recipient does not understand the 1666 request method. 1668 The 501 response code exists to allow some degree of method 1669 extensibility. It is not intended as a license to ignore methods 1670 defined in this document; rather it is a mechanism to report lack 1671 of support of extension methods. 1673 10.10. 506 1675 A 506 response indicates that a request arrived on a session which is 1676 already bound to another network connection. The sender should cease 1677 sending messages for that session on this connection. 1679 11. Examples 1681 11.1. Basic IM Session 1683 This section shows an example flow for the most common scenario. The 1684 example assumes SIP is used to transport the SDP exchange. Details 1685 of the SIP messages and SIP proxy infrastructure are omitted for the 1686 sake of brevity. In the example, assume the offerer is 1687 sip:alice@example.com and the answerer is sip:bob@example.com. 1689 Alice Bob 1690 | | 1691 | | 1692 |(1) (SIP) INVITE | 1693 |----------------------->| 1694 |(2) (SIP) 200 OK | 1695 |<-----------------------| 1696 |(3) (SIP) ACK | 1697 |----------------------->| 1698 |(4) (MSRP) SEND | 1699 |----------------------->| 1700 |(5) (MSRP) 200 OK | 1701 |<-----------------------| 1702 |(6) (MSRP) SEND | 1703 |<-----------------------| 1704 |(7) (MSRP) 200 OK | 1705 |----------------------->| 1706 |(8) (SIP) BYE | 1707 |----------------------->| 1708 |(9) (SIP) 200 OK | 1709 |<-----------------------| 1710 | | 1711 | | 1713 1. Alice constructs a local URL of 1714 msrp://alicepc.example.com:7777/iau39;tcp . 1716 Alice->Bob (SIP): INVITE sip:bob@example.com 1718 v=0 1719 o=alice 2890844557 2890844559 IN IP4 alicepc.example.com 1720 s= - 1721 c=IN IP4 alicepc.example.com 1722 t=0 0 1723 m=message 7777 TCP/MSRP * 1724 a=accept-types:text/plain 1725 a=path:msrp://alicepc.example.com:7777/iau39;tcp 1727 2. Bob listens on port 8888, and sends the following response: 1729 Bob->Alice (SIP): 200 OK 1731 v=0 1732 o=bob 2890844612 2890844616 IN IP4 bob.example.com 1733 s= - 1734 c=IN IP4 bob.example.com 1735 t=0 0 1736 m=message 8888 TCP/MSRP * 1737 a=accept-types:text/plain 1738 a=path:msrp://bob.example.com:8888/9di4ea;tcp 1740 3. Alice->Bob (SIP): ACK sip:bob@example.com 1742 4. (Alice opens connection to Bob.) Alice->Bob (MSRP): 1744 MSRP d93kswow SEND 1745 To-Path: msrp://bob.example.com:8888/9di4ea;tcp 1746 From-Path: msrp://alicepc.example.com:7777/iau39;tcp 1747 Message-ID: 12339sdqwer 1748 Content-Type: text/plain 1750 Hi, I'm Alice! 1751 -------d93kswow$ 1753 5. Bob->Alice (MSRP): 1755 MSRP d93kswow 200 OK 1756 To-Path: msrp://alicepc.example.com:7777/iau39;tcp 1757 From-Path: msrp://bob.example.com:8888/9di4ea;tcp 1758 -------d93kswow$ 1760 6. Bob->Alice (MSRP): 1762 MSRP dkei38sd SEND 1763 To-Path: msrp://alicepc.example.com:7777/iau39;tcp 1764 From-Path: msrp://bob.example.com:8888/9di4ea;tcp 1765 Message-ID: 456 1766 Content-Type: text/plain 1768 Hi, Alice! I'm Bob! 1769 -------dkei38sd$ 1771 7. Alice->Bob (MSRP): 1773 MSRP dkei38sd 200 OK 1774 To-Path: msrp://alicepc.example.com:7777/iau39;tcp 1775 From-Path: msrp://bob.example.com:8888/9di4ea;tcp 1776 -------dkei38sd$ 1778 8. Alice->Bob (SIP): BYE sip:bob@example.com 1780 Alice invalidates local session state. 1782 9. Bob invalidates local state for the session. 1784 Bob->Alice (SIP): 200 OK 1786 11.2. Message with XHTML Content 1788 MSRP dsdfoe38sd SEND 1789 To-Path: msrp://alice.atlanta.com:7777/iau39;tcp 1790 From-Path: msrp://bob.atlanta.com:8888/9di4ea;tcp 1791 Message-ID: 456 1792 Content-Type: application/xhtml+xml 1794 1795 1798 1799 1800 FY2005 Results 1801 1802 1803

See the results at example.org.

1805 1806 1807 -------dsdfoe38sd$ 1809 11.3. Chunked Message 1811 For an example of a chunked message, see the example in Section 5.1. 1813 11.4. System Message 1815 Sysadmin->Alice (MSRP): 1817 MSRP d93kswow SEND 1818 To-Path: msrp://alicepc.example.com:8888/9di4ea;tcp 1819 From-Path: msrp://example.com:7777/iau39;tcp 1820 Message-ID: 12339sdqwer 1821 Failure-Report: no 1822 Success-Report: no 1823 Content-Type: text/plain 1825 This conference will end in 5 minutes 1826 -------d93kswow$ 1828 11.5. Positive Report 1830 Alice->Bob (MSRP): 1832 MSRP d93kswow SEND 1833 To-Path: msrp://bob.example.com:8888/9di4ea;tcp 1834 From-Path: msrp://alicepc.example.com:7777/iau39;tcp 1835 Message-ID: 12339sdqwer 1836 Success-Report: yes 1837 Failure-Report: no 1838 Content-Type: text/html 1840 1841

Here is that important link... 1842 foobar 1843

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