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

See the results at example.org.

1923 1924 1925 -------dsdfoe38sd$ 1927 Figure 13: Example Message with XHTML 1929 11.3. Chunked Message 1931 For an example of a chunked message, see the example in Section 5.1. 1933 11.4. Chunked Message with message/cpim payload 1935 This example shows a chunked message containing a CPIM message that 1936 wraps a text/plain payload. It is worth noting that MSRP considers 1937 the complete CPIM message before chunking the message, thus, the CPIM 1938 headers are included in only the first chunk. The MSRP Content-Type 1939 and Byte-Range headers, present in both chunks, refer to the whole 1940 CPIM message. 1942 MSRP d93kswow SEND 1943 To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp 1944 From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp 1945 Message-ID: 12339sdqwer 1946 Byte-Range: 1-137/148 1947 Content-Type: message/cpim 1949 To: Bob 1950 From: Alice 1951 DateTime: 2006-05-15T15:02:31-03:00 1952 Content-Type: text/plain 1954 ABCD 1955 -------d93kswow+ 1957 Figure 14: First Chunk 1959 Alice sends the second and last chunk. 1961 MSRP op2nc9a SEND 1962 To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp 1963 From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp 1964 Message-ID: 12339sdqwer 1965 Byte-Range: 138-148/148 1966 Content-Type: message/cpim 1968 1234567890 1969 -------op2nc9a$ 1971 Figure 15: Second Chunk 1973 11.5. System Message 1975 Sysadmin->Alice (MSRP): 1977 MSRP d93kswow SEND 1978 To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp 1979 From-Path: msrp://example.com:7777/iau39soe2843z;tcp 1980 Message-ID: 12339sdqwer 1981 Byte-Range: 1-38/38 1982 Failure-Report: no 1983 Success-Report: no 1984 Content-Type: text/plain 1986 This conference will end in 5 minutes 1987 -------d93kswow$ 1989 11.6. Positive Report 1991 Alice->Bob (MSRP): 1993 MSRP d93kswow SEND 1994 To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp 1995 From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 1996 Message-ID: 12339sdqwer 1997 Byte-Range: 1-106/106 1998 Success-Report: yes 1999 Failure-Report: no 2000 Content-Type: text/html 2002 2003

Here is that important link... 2004 foobar 2005

2006 2007 -------d93kswow$ 2009 Figure 16: Initial SEND Request 2011 Bob->Alice (MSRP): 2013 MSRP dkei38sd REPORT 2014 To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 2015 From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp 2016 Message-ID: 12339sdqwer 2017 Byte-Range: 1-106/106 2018 Status: 000 200 OK 2019 -------dkei38sd$ 2021 Figure 17: Success Report 2023 11.7. Forked IM 2025 Traditional IM systems generally do a poor job of handling multiple 2026 simultaneous IM clients online for the same person. While some do a 2027 better job than many existing systems, handling of multiple clients 2028 is fairly crude. This becomes a much more significant issue when 2029 always-on mobile devices are available, but it is desirable to use 2030 them only if another IM client is not available. 2032 Using SIP makes rendezvous decisions explicit, deterministic, and 2033 very flexible. In contrast, "page-mode" IM systems use implicit 2034 implementation-specific decisions which IM clients cannot influence. 2035 With SIP session-mode messaging, rendezvous decisions can be under 2036 control of the client in a predictable, interoperable way for any 2037 host that implements callee capabilities [31]. As a result, 2038 rendezvous policy is managed consistently for each address of record. 2040 The following example shows Juliet with several IM clients where she 2041 can be reached. Each of these has a unique SIP Contact and MSRP 2042 session. The example takes advantage of SIP's capability to "fork" 2043 an invitation to several Contacts in parallel, in sequence, or in 2044 combination. Juliet has registered from her chamber, the balcony, 2045 her PDA, and as a last resort, you can leave a message with her 2046 Nurse. Juliet's contacts are listed below. The q-values express 2047 relative preference (q=1.0 is the highest preference). 2049 When Romeo opens his IM program, he selects Juliet and types the 2050 message "art thou hither?" (instead of "you there?"). His client 2051 sends a SIP invitation to sip:juliet@thecapulets.example.com. The 2052 proxy there tries first the balcony and the chamber simultaneously. 2053 A client is running on each of those systems, both of which set up 2054 early sessions of MSRP with Romeo's client. The client automatically 2055 sends the message over MSRP to the two MSRP URIs involved. After a 2056 delay of a several seconds with no reply or activity from Juliet, the 2057 proxy cancels the invitation at her first two contacts, and forwards 2058 the invitation on to Juliet's PDA. Since her father is talking to 2059 her about her wedding, she selects "Do Not Disturb" on her PDA, which 2060 sends a "Busy Here" response. The proxy then tries the Nurse, who 2061 answers and tells Romeo what is going on. 2063 Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse 2064 Proxy balcony chamber PDA 2066 | | | | | | 2067 |--INVITE--->| | | | | 2068 | |--INVITE--->| | | | 2069 | |<----180----| | | | 2070 |<----180----| | | | | 2071 |---PRACK---------------->| | | | 2072 |<----200-----------------| | | | 2073 |<===Early MSRP Session==>| art thou hither? | | 2074 | | | | | | 2075 | |--INVITE---------------->| | | 2076 | |<----180-----------------| | | 2077 |<----180----| | | | | 2078 |---PRACK----------------------------->| | | 2079 |<----200------------------------------| | | 2080 |<========Early MSRP Session==========>| art thou hither? | 2081 | | | | | | 2082 | | | | | | 2083 | | .... Time Passes .... | | | 2084 | | | | | | 2085 | | | | | | 2086 | |--CANCEL--->| | | | 2087 | |<---200-----| | | | 2088 | |<---487-----| | | | 2089 | |----ACK---->| | | | 2090 | |--CANCEL---------------->| | | 2091 | |<---200------------------| | | 2092 | |<---487------------------| | | 2093 | |----ACK----------------->| | | 2094 | |--INVITE---------------------------->| romeo wants 2095 | | | | | to IM w/ you 2096 | |<---486 Busy Here--------------------| | 2097 | |----ACK----------------------------->| | 2098 | | | | | | 2099 | |--INVITE---------------------------------------->| 2100 | |<---200 OK---------------------------------------| 2101 |<--200 OK---| | | | | 2102 |---ACK------------------------------------------------------->| 2103 |<================MSRP Session================================>| 2104 | | | | | | 2105 | Hi Romeo, Juliet is | 2106 | with her father now | 2107 | can I take a message?| 2108 | | 2109 | Tell her to go to confession tomorrow.... | 2110 Figure 18: Forking Example 2112 12. Extensibility 2114 MSRP was designed to be only minimally extensible. New MSRP Methods, 2115 header fields, and status codes can be defined in standards track 2116 RFCs. MSRP does not contain a version number or any negotiation 2117 mechanism to require or discover new features. If an extension is 2118 specified in the future that requires negotiation, the specification 2119 will need to describe how the extension is to be negotiated in the 2120 encapsulating signaling protocol. If a non-interoperable update or 2121 extension occurs in the future, it will be treated as a new protocol, 2122 and MUST describe how its use will be signaled. 2124 In order to allow extension header fields without breaking 2125 interoperability, if an MSRP device receives a request or response 2126 containing a header field that it does not understand, it MUST ignore 2127 the header field and process the request or response as if the header 2128 field was not present. If an MSRP device receives a request with an 2129 unknown method, it MUST return a 501 response. 2131 MSRP was designed to use lists of URIs instead of a single URI in the 2132 To-Path and From-Path header fields in anticipation of relay or 2133 gateway functionality being added. In addition, "msrp" and "msrps" 2134 URIs can contain parameters that are extensible. 2136 13. CPIM Compatibility 2138 MSRP sessions may go to a gateway to other CPIM [27] compatible 2139 protocols. If this occurs, the gateway MUST maintain session state, 2140 and MUST translate between the MSRP session semantics and CPIM 2141 semantics, which do not include a concept of sessions. Furthermore, 2142 when one endpoint of the session is a CPIM gateway, instant messages 2143 SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST 2144 include "message/cpim" as the first entry in its SDP accept-types 2145 attribute. MSRP endpoints sending instant messages to a peer that 2146 has included "message/cpim" as the first entry in the accept-types 2147 attribute SHOULD encapsulate all instant message bodies in "message/ 2148 cpim" wrappers. All MSRP endpoints MUST support the message/cpim 2149 type, and SHOULD support the S/MIME[7] features of that format. 2151 If a message is to be wrapped in a message/cpim envelope, the 2152 wrapping MUST be done prior to breaking the message into chunks, if 2153 needed. 2155 All MSRP endpoints MUST recognize the From, To, DateTime, and Require 2156 header fields as defined in RFC3862. Such applications SHOULD 2157 recognize the CC header field, and MAY recognize the Subject header 2158 field. Any MSRP application that recognizes any message/cpim header 2159 field MUST understand the NS (name space) header field. 2161 All message/cpim body parts sent by an MSRP endpoint MUST include the 2162 From and To header fields. If the message/cpim body part is 2163 protected using S/MIME, then it MUST also include the DateTime header 2164 field. 2166 The NS, To, and CC header fields may occur multiple times. Other 2167 header fields defined in RFC3862 MUST NOT occur more than once in a 2168 given message/cpim body part in an MSRP message. The Require header 2169 field MAY include multiple values. The NS header field MAY occur 2170 zero or more times, depending on how many name spaces are being 2171 referenced. 2173 Extension header fields MAY occur more than once, depending on the 2174 definition of such header fields. 2176 Using message/cpim envelopes is also useful if an MSRP device 2177 wishes to send a message on behalf of some other identity. The 2178 device may add a message/cpim envelope with the appropriate From 2179 header field value. 2181 14. Security Considerations 2183 Instant Messaging systems are used to exchange a variety of sensitive 2184 information ranging from personal conversations, to corporate 2185 confidential information, to account numbers and other financial 2186 trading information. IM is used by individuals, corporations, and 2187 governments for communicating important information. IM systems need 2188 to provide the properties of integrity and confidentiality for the 2189 exchanged information, the knowledge that you are communicating with 2190 the correct party, and allow the possibility of anonymous 2191 communication. MSRP pushes many of the hard problems to SIP when SIP 2192 sets up the session, but some of the problems remain. Spam and DoS 2193 attacks are also very relevant to IM systems. 2195 MSRP needs to provide confidentiality and integrity for the messages 2196 it transfers. It also needs to provide assurances that the connected 2197 host is the host that it meant to connect to and that the connection 2198 has not been hijacked. 2200 14.1. Secrecy of the MSRP URI 2202 When an endpoint sends an MSRP URI to its peer in a rendez-vous 2203 protocol, that URI is effectively a secret shared between the peers. 2204 If an attacker learns or guesses the URI prior to the completion of 2205 session setup, it may be able to impersonate one of the peers. 2207 Assuming the URI exchange in the rendez-vous protocol is sufficiently 2208 protected, it is critical that the URI remain difficult to "guess" 2209 via brute force methods. Most components of the URI, such as the 2210 scheme and the hostport components, are common knowledge. The 2211 secrecy is entirely provided by the session-id component. 2213 Therefore, when an MSRP device generates an MSRP URI to be used in 2214 the initiation of an MSRP session, the session-id component MUST 2215 contain at least 80 bits of randomness. 2217 14.2. Transport Level Protection 2219 When using only TCP connections, MSRP security is fairly weak. If 2220 host A is contacting host B, B passes its hostname and a secret to A 2221 using a rendezvous protocol. Although MSRP requires the use of a 2222 rendezvous protocol with the ability to protect this exchange, there 2223 is no guarantee that the protection will be used all the time. If 2224 such protection is not used, anyone can see this secret. Host A then 2225 connects to the provided host name and passes the secret in the clear 2226 across the connection to B. Host A assumes that it is talking to B 2227 based on where it sent the SYN packet and then delivers the secret in 2228 plain text across the connections. Host B assumes it is talking to A 2229 because the host on the other end of the connection delivered the 2230 secret. An attacker that could ACK the SYN packet could insert 2231 itself as a man in the middle in the connection. 2233 When using TLS connections, the security is significantly improved. 2234 We assume that the host accepting the connection has a certificate 2235 from a well-known certification authority. Furthermore, we assume 2236 that the signaling to set up the session is protected by the 2237 rendezvous protocol. In this case, when host A contacts host B, the 2238 secret is passed through a confidential channel to A. A connects with 2239 TLS to B. B presents a valid certificate, so A knows it really is 2240 connected to B. A then delivers the secret provided by B, so that B 2241 can verify it is connected to A. In this case, a rogue SIP Proxy can 2242 see the secret in the SIP signaling traffic and could potentially 2243 insert itself as a man-in-the-middle. 2245 Realistically, using TLS with certificates from well known 2246 certification authorities is difficult for peer-to-peer connections, 2247 as the types of hosts that end clients use for sending instant 2248 messages are unlikely to have long-term stable IP addresses or DNS 2249 names that certificates can bind to. In addition, the cost of server 2250 certificates from well-known certification authorities is currently 2251 expensive enough to discourage their use for each client. Using TLS 2252 in a peer-to-peer mode without well known certificate is discussed in 2253 Section 14.4. 2255 TLS becomes much more practical when some form of relay is 2256 introduced. Clients can then form TLS connections to relays, which 2257 are much more likely to have TLS certificates. While this 2258 specification does not address such relays, they are described by a 2259 companion document [23]. That document makes extensive use of TLS to 2260 protect traffic between clients and relays, and between one relay and 2261 another. 2263 TLS is used to authenticate devices and to provide integrity and 2264 confidentiality for the header fields being transported. MSRP 2265 elements MUST implement TLS and MUST also implement the TLS 2266 ClientExtendedHello extended hello information for server name 2267 indication as described in [11]. A TLS cipher-suite of 2268 TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher- 2269 suites MAY also be supported). 2271 14.3. S/MIME 2273 The only strong security for non-TLS connections is achieved using 2274 S/MIME. 2276 Since MSRP carries arbitrary MIME content, it can trivially carry 2277 S/MIME protected messages as well. All MSRP implementations MUST 2278 support the multipart/signed media-type even if they do not support 2279 S/MIME. Since SIP can carry a session key, S/MIME messages in the 2280 context of a session could also be protected using a key-wrapped 2281 shared secret [28] provided in the session setup. MSRP can carry 2282 unencoded binary payloads. Therefore MIME bodies MUST be transferred 2283 with a transfer encoding of binary. If a message is both signed and 2284 encrypted, it SHOULD be signed first, then encrypted. If S/MIME is 2285 supported, SHA-1, SHA-256, RSA, and AES-128 MUST be supported. For 2286 RSA, implementations MUST support key sizes of at least 1024 bits and 2287 SHOULD support key sizes of 2048 bits or more. 2289 This does not actually require the endpoint to have certificates from 2290 a well-known certification authority. When MSRP is used with SIP, 2291 the Identity [17] and Certificates [25] mechanisms provide S/MIME 2292 based delivery of a secret between A and B. No SIP intermediary 2293 except the explicitly trusted authentication service (one per user) 2294 can see the secret. The S/MIME encryption of the SDP can also be 2295 used by SIP to exchange keying material that can be used in MSRP. 2297 The MSRP session can then use S/MIME with this keying material to 2298 sign and encrypt messages sent over MSRP. The connection can still 2299 be hijacked since the secret is sent in clear text to the other end 2300 of the TCP connection, but the consequences are mitigated if all the 2301 MSRP content is signed and encrypted with S/MIME. Although out of 2302 scope for this document, the SIP negotiation of MSRP session can 2303 negotiate symmetric keying material to be used with S/MIME for 2304 integrity and privacy. 2306 14.4. Using TLS in Peer-to-Peer Mode 2308 TLS can be used with a self-signed certificate as long as there is a 2309 mechanism for both sides to ascertain that the other side used the 2310 correct certificate. When used with SDP and SIP, the correct 2311 certificate can be verified by passing a fingerprint of the 2312 certificate in the SDP and ensuring that the SDP has suitable 2313 integrity protection. When SIP is used to transport the SDP, the 2314 integrity can be provided by the SIP Identity mechanism[17]. The 2315 rest of this section describes the details of this approach. 2317 If self-signed certificates are used, the content of the 2318 subjectAltName attribute inside the certificate MAY use the uniform 2319 resource identifier (URI) of the user. In SIP, this URI of the user 2320 is the User's Address of Record (AOR). This is useful for debugging 2321 purposes only and is not required to bind the certificate to one of 2322 the communication endpoints. Unlike normal TLS operations in this 2323 protocol, when doing peer-to-peer TLS, the subjectAltName is not an 2324 important component of the certificate verification. If the endpoint 2325 is also able to make anonymous sessions, a distinct, unique 2326 certificate MUST be used for this purpose. For a client that works 2327 with multiple users, each user SHOULD have its own certificate. 2328 Because the generation of public/private key pairs is relatively 2329 expensive, endpoints are not required to generate certificates for 2330 each session. 2332 A certificate fingerprint is the output of a one-way hash function 2333 computed over the distinguished encoding rules (DER) form of the 2334 certificate. The endpoint MUST use the certificate fingerprint 2335 attribute as specified in [18] and MUST include this in the SDP. The 2336 certificate presented during the TLS handshake needs to match the 2337 fingerprint exchanged via the SDP and if the fingerprint does not 2338 match the hashed certificate then the endpoint MUST tear down the 2339 media session immediately. 2341 When using SIP, the integrity of the fingerprint can be ensured 2342 through the SIP Identity mechanism [17]. When a client wishes to use 2343 SIP to set up a secure MSRP session with another endpoint it sends an 2344 SDP offer in a SIP message to the other endpoint. This offer 2345 includes, as part of the SDP payload, the fingerprint of the 2346 certificate that the endpoint wants to use. The SIP message 2347 containing the offer is sent to the offerer's SIP proxy which will 2348 add an Identity header according to the procedures outlined in [17]. 2349 When the far endpoint receives the SIP message it can verify the 2350 identity of the sender using the Identity header. Since the Identity 2351 header is a digital signature across several SIP headers, in addition 2352 to the body or bodies of the SIP message, the receiver can also be 2353 certain that the message has not been tampered with after the digital 2354 signature was added to the SIP message. 2356 An example of SDP with a fingerprint attribute is shown in the 2357 following figure. Note the fingerprint is shown spread over two 2358 lines due to formatting consideration but should all be on one line. 2360 c=IN IP4 atlanta.example.com 2361 m=message 7654 TCP/TLS/MSRP * 2362 a=accept-types:text/plain 2363 a=path:msrps://atlanta.example.com:7654/jshA7weso3ks;tcp 2364 a=fingerprint:SHA-1 \ 2365 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 2367 Figure 19: SDP with Fingerprint Attribute 2369 14.5. Other Security Concerns 2371 MSRP cannot be used as an amplifier for DoS attacks, but it can be 2372 used to form a distributed attack to consume TCP connection resources 2373 on servers. The attacker, Mallory, sends a SIP INVITE with no offer 2374 to Alice. Alice returns a 200 with an offer and Mallory returns an 2375 answer with SDP indicating that his MSRP address is the address of 2376 Tom. Since Alice sent the offer, Alice will initiate a connection to 2377 Tom using up resources on Tom's server. Given the huge number of IM 2378 clients, and the relatively few TCP connections that most servers 2379 support, this is a fairly straightforward attack. 2381 SIP is attempting to address issues in dealing with spam. The spam 2382 issue is probably best dealt with at the SIP level when an MSRP 2383 session is initiated and not at the MSRP level. 2385 If a sender chooses to employ S/MIME to protect a message, all S/MIME 2386 operations apply to the complete message, prior to any breaking of 2387 the message into chunks. 2389 The signaling will have set up the session to or from some specific 2390 URIs that will often have "im:" or "sip:" URI schemes. When the 2391 signaling has been set up to a specific end user, and S/MIME is 2392 implemented, then the client needs to verify that the name in the 2393 SubjectAltName of the certificate contains an entry that matches the 2394 URI that was used for the other end in the signaling. There are some 2395 cases, such as IM conferencing, where the S/MIME certificate name and 2396 the signaled identity will not match. In these cases, the client 2397 should ensure that the user is informed that the message came from 2398 the user identified in the certificate and does not assume that the 2399 message came from the party they signaled. 2401 In some cases, a sending device may need to attribute a message to 2402 some other identity, and may use different identities for different 2403 messages in the same session. For example, a conference server may 2404 send messages on behalf of multiple users on the same session. 2405 Rather than add additional header fields to MSRP for this purpose, 2406 MSRP relies on the message/cpim format for this purpose. The sender 2407 may envelop such a message in a message/cpim body, and place the 2408 actual sender identity in the From field. The trustworthiness of 2409 such an attribution is affected by the security properties of the 2410 session in the same way that the trustworthiness of the identity of 2411 the actual peer is affected, with the additional issue of determining 2412 whether the recipient trusts the sender to assert the identity. 2414 This approach can result in nesting of message/cpim envelopes. For 2415 example, a message originates from a CPIM gateway, and is then 2416 forwarded by a conference server onto a new session. Both the 2417 gateway and the conference server introduce envelopes. In this case, 2418 the recipient client SHOULD indicate the chain of identity assertions 2419 to the user, rather than allow the user to assume that either the 2420 gateway or the conference server originated the message. 2422 It is possible that a recipient might receive messages that are 2423 attributed to the same sender via different MSRP sessions. For 2424 example, Alice might be in a conversation with Bob via an MSRP 2425 session over a TLS protected channel. Alice might then receive a 2426 different message from Bob over a different session, perhaps with a 2427 conference server that asserts Bob's identity in a message/cpim 2428 envelope signed by the server. 2430 MSRP does not prohibit multiple simultaneous sessions between the 2431 same pair of identities. Nor does it prohibit an endpoint sending a 2432 message on behalf of another identity, such as may be the case for a 2433 conference server. The recipient's endpoint should determine its 2434 level of trust of the authenticity of the sender independently for 2435 each session. The fact that an endpoint trusts the authenticity of 2436 the sender on any given session should not affect the level of trust 2437 it assigns for apparently the same sender on a different session. 2439 When MSRP clients form or acquire a certificate, they SHOULD ensure 2440 that the subjectAltName has a GeneralName entry of type 2441 uniformResourceIdentifier for each URI corresponding to this client 2442 and should always include an "im:" URI. It is fine if the 2443 certificate contains other URIs such as "sip:" or "xmpp:" URIs. 2445 MSRP implementors should be aware of a potential attack on MSRP 2446 devices that involves placing very large values in the byte-range 2447 header field, potentially causing the device to allocate very large 2448 memory buffers to hold the message. Implementations SHOULD apply 2449 some degree of sanity checking on byte-range values before allocating 2450 such buffers. 2452 15. IANA Considerations 2454 This specification instructs IANA to create a new registry for MSRP 2455 parameters. The MSRP Parameter registry is a container for sub- 2456 registries. This section further introduces sub-registries for MSRP 2457 method names, status codes, and header field names. 2459 Additionally, Section 15.4 through Section 15.7 register new 2460 parameters in existing IANA registries. 2462 [NOTE TO IANA/RFC Editor: Please replace all occurrences of RFCXXXX 2463 in this section with the actual number assigned to this document.] 2465 15.1. MSRP Method Names 2467 This specification establishes the Method sub-registry under MSRP 2468 Parameters and initiates its population as follows. New parameters 2469 in this sub-registry must be published in an RFC (either as an IETF 2470 submission or RFC Editor submission). 2472 SEND - [RFCXXXX] 2473 REPORT - [RFCXXXX] 2475 The following information MUST be provided in an RFC publication in 2476 order to register a new MSRP Method: 2478 o The method name. 2479 o The RFC number in which the method is registered. 2481 15.2. MSRP Header Fields 2483 This specification establishes the header field-Field sub-registry 2484 under MSRP Parameters. New parameters in this sub-registry must be 2485 published in an RFC (either as an IETF submission or RFC Editor 2486 submission). Its initial population is defined as follows: 2488 To-Path - [RFCXXXX] 2489 From-Path - [RFCXXXX] 2490 Message-ID - [RFCXXXX] 2491 Success-Report - [RFCXXXX] 2492 Failure-Report - [RFCXXXX] 2493 Byte-Range - [RFCXXXX] 2494 Status - [RFCXXXX] 2496 The following information MUST be provided in an RFC publication in 2497 order to register a new MSRP header field: 2499 o The header field name. 2500 o The RFC number in which the method is registered. 2502 15.3. MSRP Status Codes 2504 This specification establishes the Status-Code sub-registry under 2505 MSRP Parameters. New parameters in this sub-registry must be 2506 published in an RFC (either as an IETF submission or RFC Editor 2507 submission). Its initial population is defined in Section 10. It 2508 takes the following format: 2510 Code [RFC Number] 2512 The following information MUST be provided in an RFC publication in 2513 order to register a new MSRP status code: 2515 o The status code number. 2516 o The RFC number in which the method is registered. 2518 15.4. MSRP Port 2520 MSRP uses TCP port XYZ, from the "registered" port range. Usage of 2521 this value is described in Section 6. 2523 [NOTE TO IANA/RFC Editor: Please replace XYZ in this section with the 2524 assigned port number.] 2526 15.5. URI Schema 2528 This document requests permanent registration the URI schemes of 2529 "msrp" and "msrps". 2531 15.5.1. MSRP Scheme 2532 URI Scheme Name "msrp" 2533 URI Scheme Syntax See the ABNF construction for "MSRP-URI" in 2534 Section 9 of RFCXXXX. 2535 URI Scheme Semantics See Section 6 of RFCXXXX. 2536 Encoding Considerations See Section 6 of RFCXXXX. 2537 Applications/Protocols that use this URI Scheme The Message Session 2538 Relay Protocol (MSRP). 2539 Interoperability Considerations MSRP URIs are expected to be used 2540 only by implemetations of MSRP. No additional interoperability 2541 issues are expected. 2542 Security Considerations See Section 14.1 of RFCXXXX for specific 2543 security considerations for MSRP URIs, and Section 14 of RFCXXXX 2544 for security considerations for MSRP in general. 2545 Contact Ben Campbell (ben@estacado.net). 2546 Author/Change Controller This is a permanent registration request. 2547 Change control does not apply. 2549 15.5.2. MSRPS Scheme 2551 URI Scheme Name "msrps" 2552 URI Scheme Syntax See the ABNF construction for "MSRP-URI" in 2553 Section 9 of RFCXXXX. 2554 URI Scheme Semantics See Section 6 of RFCXXXX. 2555 Encoding Considerations See Section 6 of RFCXXXX. 2556 Applications/Protocols that use this URI Scheme The Message Session 2557 Relay Protocol (MSRP). 2558 Interoperability Considerations MSRP URIs are expected to be used 2559 only by implementations of MSRP. No additional interoperability 2560 issues are expected. 2561 Security Considerations See Section 14.1 of RFCXXXX for specific 2562 security considerations for MSRP URIs, and Section 14 of RFCXXXX 2563 for security considerations for MSRP in general. 2564 Contact Ben Campbell (ben@estacado.net). 2565 Author/Change Controller This is a permanent registration request. 2566 Change control does not apply. 2568 15.6. SDP Transport Protocol 2570 MSRP defines the a new SDP protocol field values "TCP/MSRP" and "TCP/ 2571 TLS/MSRP", which should be registered in the sdp-parameters registry 2572 under "proto". This first value indicates the MSRP protocol when TCP 2573 is used as an underlying transport. The second indicates that TLS is 2574 used. 2576 Specifications defining new protocol values must define the rules for 2577 the associated media format namespace. The "TCP/MSRP" and "TCP/TLS/ 2578 MSRP" protocol values allow only one value in the format field (fmt), 2579 which is a single occurrence of "*". Actual format determination is 2580 made using the "accept-types" and "accept-wrapped-types" attributes. 2582 15.7. SDP Attribute Names 2584 This document registers the following SDP attribute parameter names 2585 in the sdp-parameters registry. These names are to be used in the 2586 SDP att-name field. 2588 15.7.1. Accept Types 2590 Contact Information: Ben Campbell (ben@estacado.net) 2591 Attribute-name: accept-types 2592 Long-form Attribute Name: Acceptable Media Types 2593 Type: Media level 2594 Subject to Charset Attribute: No 2595 Purpose and Appropriate Values: The "accept-types" attribute 2596 contains a list of media-types that the endpoint is willing to 2597 receive. It may contain zero or more registered media-types, or 2598 "*" in a space delimited string. 2600 15.7.2. Wrapped Types 2602 Contact Information: Ben Campbell (ben@estacado.net) 2603 Attribute-name: accept-wrapped-types 2604 Long-form Attribute Name: Acceptable media-types Inside Wrappers 2605 Type: Media level 2606 Subject to Charset Attribute: No 2607 Purpose and Appropriate Values: The "accept-wrapped-types" attribute 2608 contains a list of media types that the endpoint is willing to 2609 receive in an MSRP message with multipart content, but may not be 2610 used as the outermost type of the message. It may contain zero or 2611 more registered media-types, or "*" in a space delimited string. 2613 15.7.3. Max Size 2615 Contact Information: Ben Campbell (ben@estacado.net) 2616 Attribute-name: max-size 2617 Long-form Attribute Name: Maximum message size. 2618 Type: Media level 2619 Subject to Charset Attribute: No 2620 Purpose and Appropriate Values: The "max-size" attribute indicates 2621 the largest message an endpoint wishes to accept. It may take any 2622 numeric value, specified in octets. 2624 15.7.4. Path 2625 Contact Information: Ben Campbell (ben@estacado.net) 2626 Attribute-name: path 2627 Long-form Attribute Name: MSRP URI Path 2628 Type: Media level 2629 Subject to Charset Attribute: No 2630 Purpose and Appropriate Values: The "path" attribute indicates a 2631 series of MSRP devices that must be visited by messages sent in 2632 the session, including the final endpoint. The attribute contains 2633 one or more MSRP URIs, delimited by the space character. 2635 16. Contributors and Acknowledgments 2637 In addition to the editors, the following people contributed 2638 extensive work to this document: Chris Boulton, Paul Kyzivat, Orit 2639 Levin, Hans Persson, Adam Roach, Jonathan Rosenberg, and Robert 2640 Sparks. 2642 The following people contributed substantial discussion and feedback 2643 to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson, 2644 Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, 2645 Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney. 2647 17. References 2649 17.1. Normative References 2651 [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2652 RFC 2246, January 1999. 2654 [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2655 Description Protocol", RFC 4566, July 2006. 2657 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2658 Session Description Protocol (SDP)", RFC 3264, June 2002. 2660 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2661 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2662 Session Initiation Protocol", RFC 3261, June 2002. 2664 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2665 Levels", BCP 14, RFC 2119, March 1997. 2667 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2668 Specifications: ABNF", RFC 4234, October 2005. 2670 [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 2671 (S/MIME) Version 3.1 Message Specification", RFC 3851, 2672 July 2004. 2674 [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2675 Extensions (MIME) Part One: Format of Internet Message Bodies", 2676 RFC 2045, November 1996. 2678 [9] Troost, R., Dorner, S., and K. Moore, "Communicating 2679 Presentation Information in Internet Messages: The Content- 2680 Disposition header field", RFC 2183, August 1997. 2682 [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2683 Resource Identifiers (URI): Generic Syntax", RFC 3986, 2684 January 2005. 2686 [11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 2687 T. Wright, "Transport Layer Security (TLS) Extensions", 2688 RFC 3546, June 2003. 2690 [12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging 2691 (CPIM): Message Format", RFC 3862, August 2004. 2693 [13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 2694 Transport Layer Security (TLS)", RFC 3268, June 2002. 2696 [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2697 RFC 3629, November 2003. 2699 [15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2700 Extensions (MIME) Part Two: Media Types", RFC 2046, 2701 November 1996. 2703 [16] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 2704 Public Key Infrastructure: Certificate and Certificate 2705 Revocation List (CRL) Profile", RFC 3280, April 2002. 2707 [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated 2708 Identity Management in the Session Initiation Protocol (SIP)", 2709 RFC 4474, August 2006. 2711 [18] Lennox, J., "Connection-Oriented Media Transport over the 2712 Transport Layer Security (TLS) Protocol in the Session 2713 Description Protocol (SDP)", RFC 4572, July 2006. 2715 17.2. Informational References 2717 [19] Johnston, A. and O. Levin, "Session Initiation Protocol Call 2718 Control - Conferencing for User Agents", RFC 4579, August 2006. 2720 [20] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 2721 "Best Current Practices for Third Party Call Control in the 2722 Session Initiation Protocol", RFC 3725, April 2004. 2724 [21] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation 2725 Protocol Call Control - Transfer", 2726 draft-ietf-sipping-cc-transfer-07 (work in progress), 2727 October 2006. 2729 [22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 2730 D. Gurle, "Session Initiation Protocol (SIP) Extension for 2731 Instant Messaging", RFC 3428, December 2002. 2733 [23] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for 2734 Message Sessions Relay Protocol (MSRP)", 2735 draft-ietf-simple-msrp-relays-08 (work in progress), July 2006. 2737 [24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 2738 Method", RFC 3311, October 2002. 2740 [25] Jennings, C., Peterson, J., and J. Fischl, "Certificate 2741 Management Service for SIP", draft-ietf-sip-certs-01 (work in 2742 progress), June 2006. 2744 [26] Yon, D. and G. Camarillo, "Connection-Oriented Media Transport 2745 in SDP", RFC 4145, September 2005. 2747 [27] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", 2748 RFC 3860, August 2004. 2750 [28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, 2751 December 2001. 2753 [29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone 2754 Generation in the Session Initiation Protocol (SIP)", RFC 3960, 2755 December 2004. 2757 [30] Saint-Andre, P., "Extensible Messaging and Presence Protocol 2758 (XMPP): Instant Messaging and Presence", RFC 3921, 2759 October 2004. 2761 [31] Rosenberg, J., "Indicating User Agent Capabilities in the 2762 Session Initiation Protocol (SIP)", RFC 3840, August 2004. 2764 [32] Peterson, J., "Address Resolution for Instant Messaging and 2765 Presence", RFC 3861, August 2004. 2767 Authors' Addresses 2769 Ben Campbell (editor) 2770 Estacado Systems 2771 17210 Campbell Road 2772 Suite 250 2773 Dallas, TX 75252 2774 USA 2776 Email: ben@estacado.net 2778 Rohan Mahy (editor) 2779 Plantronics 2780 345 Encincal Street 2781 Santa Cruz, CA 2782 USA 2784 Email: rohan@ekabal.com 2786 Cullen Jennings (editor) 2787 Cisco Systems, Inc. 2788 170 West Tasman Dr. 2789 MS: SJC-21/2 2790 San Jose, CA 95134 2791 USA 2793 Phone: +1 408 421-9990 2794 Email: fluffy@cisco.com 2796 Full Copyright Statement 2798 Copyright (C) The Internet Society (2006). 2800 This document is subject to the rights, licenses and restrictions 2801 contained in BCP 78, and except as set forth therein, the authors 2802 retain all their rights. 2804 This document and the information contained herein are provided on an 2805 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2806 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2807 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2808 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2809 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2810 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2812 Intellectual Property 2814 The IETF takes no position regarding the validity or scope of any 2815 Intellectual Property Rights or other rights that might be claimed to 2816 pertain to the implementation or use of the technology described in 2817 this document or the extent to which any license under such rights 2818 might or might not be available; nor does it represent that it has 2819 made any independent effort to identify any such rights. Information 2820 on the procedures with respect to rights in RFC documents can be 2821 found in BCP 78 and BCP 79. 2823 Copies of IPR disclosures made to the IETF Secretariat and any 2824 assurances of licenses to be made available, or the result of an 2825 attempt made to obtain a general license or permission for the use of 2826 such proprietary rights by implementers or users of this 2827 specification can be obtained from the IETF on-line IPR repository at 2828 http://www.ietf.org/ipr. 2830 The IETF invites any interested party to bring to its attention any 2831 copyrights, patents or patent applications, or other proprietary 2832 rights that may cover technology that may be required to implement 2833 this standard. Please address the information to the IETF at 2834 ietf-ipr@ietf.org. 2836 Acknowledgment 2838 Funding for the RFC Editor function is provided by the IETF 2839 Administrative Support Activity (IASA).