idnits 2.17.1 draft-ietf-simple-message-sessions-19.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, updated by RFC 4748 on line 2809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2833. 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 IETF Trust 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 (February 23, 2007) is 6271 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 2492 ** 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 (-15) exists of draft-ietf-sip-certs-02 -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. '30') (Obsoleted by RFC 6121) Summary: 10 errors (**), 0 flaws (~~), 5 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: August 27, 2007 Plantronics 6 C. Jennings, Ed. 7 Cisco Systems, Inc. 8 February 23, 2007 10 The Message Session Relay Protocol 11 draft-ietf-simple-message-sessions-19 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 27, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . 37 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 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" schemes are used to identify a 604 session of instant messages at a particular MSRP device, as well as 605 to identify an MSRP Relay in general. This document describes the 606 former usage; The latter usage is described in the MSRP Relay 607 specification [23]. MSRP URIs that identify sessions are ephemeral; 608 an MSRP device will use a different MSRP URI for each distinct 609 session. An MSRP URI that identifies a session has no meaning 610 outside the scope of that session. 612 An MSRP URI follows a subset of the URI syntax in Appendix A of 613 RFC3986 [10], with a scheme of "msrp" or "msrps". The syntax is 614 described in Section 9. 616 MSRP URIs are primarily expected to be generated and exchanged 617 between systems, and are not intended for "human consumption". 618 Therefore, they are encoded entirely in US-ASCII. 620 The constructions for "authority", "userinfo", and "unreserved" are 621 detailed in RFC3986 [10]. URIs designating MSRP over TCP MUST 622 include the "tcp" transport parameter. 624 Since this document only specifies MSRP over TCP, all MSRP URIs 625 herein use the "tcp" transport parameter. Documents that provide 626 bindings on other transports should define respective parameters 627 for those transports. 629 The MSRP URI authority field identifies a participant in a particular 630 MSRP session. If the authority field contains a numeric IP address, 631 it MUST also contain a port. The session-id part identifies a 632 particular session of the participant. The absence of the session-id 633 part indicates a reference to an MSRP host device, but does not refer 634 to a particular session at that device. A particular value of 635 session-id is only meaningful in the context of the associated 636 authority; thus the authority component can be thought of as a 637 identifying the "authority" governing a name space for the 638 session-id. 640 A scheme of "msrps" indicates that the underlying connection MUST be 641 protected with TLS. 643 MSRP has an IANA-registered recommended port defined in Section 15.4. 644 This value is not a default, as the URI negotiation process described 645 herein will always include explicit port numbers. However, the URIs 646 SHOULD be configured so that the recommended port is used whenever 647 appropriate. This makes life easier for network administrators who 648 need to manage firewall policy for MSRP. 650 The authority component will typically not contain a userinfo 651 component, but MAY do so to indicate a user account for which the 652 session is valid. Note that this is not the same thing as 653 identifying the session itself. A userinfo part MUST NOT contain 654 password information. 656 The following is an example of a typical MSRP URI: 658 msrp://host.example.com:8493/asfd34;tcp 660 6.1. MSRP URI Comparison 662 In the context of the MSRP protocol, MSRP URI comparisons MUST be 663 performed according to the following rules: 665 1. The scheme MUST match. Scheme comparison is case insensitive. 667 2. If the authority component contains an explicit IP address, 668 and/or port, these are compared for address and port equivalence. 669 Percent-encoding normalization [10] applies; that is, any 670 percent-encoded nonreserved characters exist in the authority 671 component, they must be decoded prior to comparison. Userinfo 672 parts are not considered for URI comparison. Otherwise, the 673 authority component is compared as a case-insensitive character 674 string. 676 3. If the port exists explicitly in either URI, then it MUST match 677 exactly. A URI with an explicit port is never equivalent to 678 another with no port specified. 680 4. The session-id part is compared as case sensitive. A URI without 681 a session-id part is never equivalent to one that includes one. 683 5. URIs with different "transport" parameters never match. Two URIs 684 that are identical except for transport are not equivalent. The 685 transport parameter is case-insensitive. 687 Path normalization [10] is not relevant for MSRP URIs. 689 6.2. Resolving MSRP Host Device 691 An MSRP host device is identified by the authority component of an 692 MSRP URI. 694 If the authority component contains a numeric IP address and port, 695 they MUST be used as listed. 697 If the authority component contains a host name and a port, the 698 connecting device MUST determine a host address by doing an A or AAAA 699 DNS query, 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 creates situations 709 where this is not the case. For example, the MSRP URI that a user 710 enters into a client to configure it to use a relay may be 711 intended to be easily remembered and communicated by humans, and 712 therefore is likely to omit the port. Therefore, the relay 713 specification [23] describes additional steps to resolve the port 714 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 "://" authority 1628 ["/" session-id] ";" transport *( ";" URI-parameter) 1629 ; authority as defined in RFC3986 1631 msrp-scheme = "msrp" / "msrps" 1632 session-id = 1*( unreserved / "+" / "=" / ) 1633 ; unreserved as defined in RFC3986 1634 transport = "tcp" / 1*ALPHANUM 1635 URI-parameter = token ["=" token] 1637 headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) 1639 header = Message-ID 1640 / Success-Report 1641 / Failure-Report 1642 / Byte-Range 1643 / Status 1644 / ext-header 1646 To-Path = "To-Path:" SP MSRP-URI *( SP MSRP-URI ) 1647 From-Path = "From-Path:" SP MSRP-URI *( SP MSRP-URI ) 1648 Message-ID = "Message-ID:" SP ident 1649 Success-Report = "Success-Report:" SP ("yes" / "no" ) 1650 Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" ) 1651 Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total 1652 range-start = 1*DIGIT 1653 range-end = 1*DIGIT / "*" 1654 total = 1*DIGIT / "*" 1656 Status = "Status:" SP namespace SP status-code [SP text-reason] 1657 namespace = 3(DIGIT); "000" for all codes defined in this document. 1658 text-reason = utf8text 1660 ident = ALPHANUM 3*31ident-char 1661 ident-char = ALPHANUM / "." / "-" / "+" / "%" / "=" 1663 content-stuff = *(Other-Mime-header CRLF) 1664 Content-Type 2CRLF data CRLF 1666 Content-Type = "Content-Type:" SP media-type 1667 media-type = type "/" subtype *( ";" gen-param ) 1668 type = token 1669 subtype = token 1671 gen-param = pname [ "=" pval ] 1672 pname = token 1673 pval = token / quoted-string 1675 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E 1676 / %x30-39 / %x41-5A / %x5E-7E) 1677 ; token is compared case-insensitive 1679 quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE 1680 qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E 1681 / UTF8-NONASCII 1682 qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) 1683 BACKSLASH = "\" 1684 UPALPHA = %x41-5A 1685 ALPHANUM = ALPHA / DIGIT 1687 Other-Mime-header = (Content-ID 1688 / Content-Description 1689 / Content-Disposition 1690 / mime-extension-field); 1692 ; Content-ID, and Content-Description are defined in RFC2045. 1693 ; Content-Disposition is defined in RFC2183 1694 ; MIME-extension-field indicates additional MIME extension 1695 ; header fields as described in RFC2045 1697 data = *OCTET 1698 end-line = "-------" transact-id continuation-flag CRLF 1699 continuation-flag = "+" / "$" / "#" 1701 ext-header = hname ":" SP hval CRLF 1702 hname = ALPHA *token 1703 hval = utf8text 1705 utf8text = *(HTAB / %x20-7E / UTF8-NONASCII) 1707 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 1708 / %xE0-EF 2UTF8-CONT 1709 / %xF0-F7 3UTF8-CONT 1710 / %xF8-Fb 4UTF8-CONT 1711 / %xFC-FD 5UTF8-CONT 1712 UTF8-CONT = %x80-BF 1714 Figure 11: MSRP ABNF 1716 10. Response Code Descriptions 1718 This section summarizes the semantics of various response codes that 1719 may be used in MSRP transaction responses. These codes may also be 1720 used in the Status header field in REPORT requests. 1722 10.1. 200 1724 The 200 response code indicates a successful transaction. 1726 10.2. 400 1728 A 400 response indicates a request was unintelligible. The sender 1729 may retry the request after correcting the error. 1731 10.3. 403 1733 A 403 response indicates the attempted action is not allowed. The 1734 sender should not try the request again. 1736 10.4. 408 1738 A 408 response indicates that a downstream transaction did not 1739 complete in the alloted time. It is never sent by any elements 1740 described in this specification. However, 408 is used in the MSRP 1741 Relay extension; therefore MSRP endpoints may receive it. An 1742 endpoint MUST treat a 408 response in the same manner as it would 1743 treat a local timeout. 1745 10.5. 413 1747 A 413 response indicates that the receiver wishes the sender to stop 1748 sending the particular message. Typically, a 413 is sent in response 1749 to a chunk of an undesired message. 1751 If a message sender receives a 413 in a response, or in a REPORT 1752 request, it MUST NOT send any further chunks in the message, that is, 1753 any further chunks with the same Message-ID value. If the sender 1754 receives the 413 while in the process of sending a chunk, and the 1755 chunk is interruptible, the sender MUST interrupt it. 1757 10.6. 415 1759 A 415 response indicates the SEND request contained a media type that 1760 is not understood by the receiver. The sender should not send any 1761 further messages with the same content-type for the duration of the 1762 session. 1764 10.7. 423 1766 A 423 response indicates that one of the requested parameters is out 1767 of bounds. It is used by the relay extensions to this document. 1769 10.8. 481 1771 A 481 response indicates that the indicated session does not exist. 1772 The sender should terminate the session. 1774 10.9. 501 1776 A 501 response indicates that the recipient does not understand the 1777 request method. 1779 The 501 response code exists to allow some degree of method 1780 extensibility. It is not intended as a license to ignore methods 1781 defined in this document; rather it is a mechanism to report lack 1782 of support of extension methods. 1784 10.10. 506 1786 A 506 response indicates that a request arrived on a session which is 1787 already bound to another network connection. The sender should cease 1788 sending messages for that session on this connection. 1790 11. Examples 1792 11.1. Basic IM Session 1794 This section shows an example flow for the most common scenario. The 1795 example assumes SIP is used to transport the SDP exchange. Details 1796 of the SIP messages and SIP proxy infrastructure are omitted for the 1797 sake of brevity. In the example, assume that the offerer is 1798 sip:alice@example.com and the answerer is sip:bob@example.com. 1800 Alice Bob 1801 | | 1802 | | 1803 |(1) (SIP) INVITE | 1804 |----------------------->| 1805 |(2) (SIP) 200 OK | 1806 |<-----------------------| 1807 |(3) (SIP) ACK | 1808 |----------------------->| 1809 |(4) (MSRP) SEND | 1810 |----------------------->| 1811 |(5) (MSRP) 200 OK | 1812 |<-----------------------| 1813 |(6) (MSRP) SEND | 1814 |<-----------------------| 1815 |(7) (MSRP) 200 OK | 1816 |----------------------->| 1817 |(8) (SIP) BYE | 1818 |----------------------->| 1819 |(9) (SIP) 200 OK | 1820 |<-----------------------| 1821 | | 1822 | | 1824 Figure 12: Basic IM Session Example 1826 1. Alice constructs a local URI of 1827 msrp://alicepc.example.com:7777/iau39soe2843z;tcp . 1829 Alice->Bob (SIP): INVITE sip:bob@example.com 1831 v=0 1832 o=alice 2890844557 2890844559 IN IP4 alicepc.example.com 1833 s= - 1834 c=IN IP4 alicepc.example.com 1835 t=0 0 1836 m=message 7777 TCP/MSRP * 1837 a=accept-types:text/plain 1838 a=path:msrp://alicepc.example.com:7777/iau39soe2843z;tcp 1840 2. Bob listens on port 8888, and sends the following response: 1842 Bob->Alice (SIP): 200 OK 1844 v=0 1845 o=bob 2890844612 2890844616 IN IP4 bob.example.com 1846 s= - 1847 c=IN IP4 bob.example.com 1848 t=0 0 1849 m=message 8888 TCP/MSRP * 1850 a=accept-types:text/plain 1851 a=path:msrp://bob.example.com:8888/9di4eae923wzd;tcp 1853 3. Alice->Bob (SIP): ACK sip:bob@example.com 1855 4. (Alice opens connection to Bob.) Alice->Bob (MSRP): 1857 MSRP d93kswow SEND 1858 To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp 1859 From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 1860 Message-ID: 12339sdqwer 1861 Byte-Range: 1-16/16 1862 Content-Type: text/plain 1864 Hi, I'm Alice! 1865 -------d93kswow$ 1867 5. Bob->Alice (MSRP): 1869 MSRP d93kswow 200 OK 1870 To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 1871 From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp 1872 -------d93kswow$ 1874 6. Bob->Alice (MSRP): 1876 MSRP dkei38sd SEND 1877 To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 1878 From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp 1879 Message-ID: 456s9wlk3 1880 Byte-Range: 1-21/21 1881 Content-Type: text/plain 1883 Hi, Alice! I'm Bob! 1884 -------dkei38sd$ 1886 7. Alice->Bob (MSRP): 1888 MSRP dkei38sd 200 OK 1889 To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp 1890 From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp 1891 -------dkei38sd$ 1893 8. Alice->Bob (SIP): BYE sip:bob@example.com 1895 Alice invalidates local session state. 1897 9. Bob invalidates local state for the session. 1899 Bob->Alice (SIP): 200 OK 1901 11.2. Message with XHTML Content 1903 MSRP dsdfoe38sd SEND 1904 To-Path: msrp://alice.example.com:7777/iau39soe2843z;tcp 1905 From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp 1906 Message-ID: 456so39s 1907 Byte-Range: 1-374/374 1908 Content-Type: application/xhtml+xml 1910 1911 1914 1915 1916 FY2005 Results 1917 1918 1919

See the results at example.org.

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

Here is that important link... 2002 foobar 2003

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