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

See the results at example.org.

1788 1789 1790 -------dsdfoe38sd$ 1792 11.3. Chunked Message 1794 For an example of a chunked message, see the example in Section 5.1. 1796 11.4. System Message 1798 Sysadmin->Alice (MSRP): 1800 MSRP d93kswow SEND 1801 To-Path: msrp://alicepc.example.com:8888/9di4ea;tcp 1802 From-Path: msrp://example.com:7777/iau39;tcp 1803 Message-ID: 12339sdqwer 1804 Failure-Report: no 1805 Success-Report: no 1806 Content-Type: text/plain 1808 This conference will end in 5 minutes 1809 -------d93kswow$ 1811 11.5. Positive Report 1813 Alice->Bob (MSRP): 1815 MSRP d93kswow SEND 1816 To-Path: msrp://bob.example.com:8888/9di4ea;tcp 1817 From-Path: msrp://alicepc.example.com:7777/iau39;tcp 1818 Message-ID: 12339sdqwer 1819 Success-Report: yes 1820 Failure-Report: no 1821 Content-Type: text/html 1823 1824

Here is that important link... 1825 foobar 1826

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