idnits 2.17.1 draft-ietf-simple-message-sessions-08.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2212. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 497 has weird spacing: '... herein use t...' == Line 612 has weird spacing: '...that is a "$"...' == Line 886 has weird spacing: '...ins one with ...' == Line 1081 has weird spacing: '...include expli...' == Line 1112 has weird spacing: '...ssigned for t...' == 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 'SHOULD not' in this paragraph: If a connection fails, the sender SHOULD attempt to re-setup the URL path using a new offer, for example, in a SIP re-invite or update [12]. It MUST not assume that the new URLs in the SDP will be the same as the old ones. A connection SHOULD not be closed while there are sessions that are using this connection. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Receivers MUST not assume the chunks will be delivered in order or that they will receive all the chunks with "+" flags before they receive the chunk with the "$" flag. In certain cases of connection failure, it is possible for information to be duplicated. If chunks data is received that overlaps already received data for the same message, the last chunk received takes precedence (even though this may not have been the last chunk transmitted). For example, if bytes 1 to 100 was received and a chunk arrives that contains bytes 50 to 150, this second chunk will overwrite bytes 50 to 100 of the data that had already been received. Although other schemes work, this is the easiest for the receiver and results in consistent behavior between clients. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 25, 2004) is 7184 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '8' is defined on line 2075, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2079, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 2144, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '1') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (ref. '10') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3546 (ref. '11') (Obsoleted by RFC 4366) -- Duplicate reference: draft-ietf-impp-cpim-msgfmt, mentioned in '13', was also mentioned in '7'. ** Obsolete normative reference: RFC 3268 (ref. '14') (Obsoleted by RFC 5246) ** Downref: Normative reference to an Informational RFC: RFC 3269 (ref. '15') == Outdated reference: A later version (-07) exists of draft-ietf-sipping-cc-conferencing-03 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-02 == Outdated reference: A later version (-02) exists of draft-mahy-simple-why-session-mode-00 == Outdated reference: A later version (-10) exists of draft-ietf-simple-msrp-relays-01 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-02 == Outdated reference: A later version (-04) exists of draft-jennings-sipping-certs-03 == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-05 -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '27') (Obsoleted by RFC 3851) Summary: 12 errors (**), 0 flaws (~~), 20 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE WG B. Campbell, Ed. 2 Internet-Draft Estacado Systems 3 Expires: February 23, 2005 R. Mahy, Ed. 4 C. Jennings, Ed. 5 Cisco Systems, Inc. 6 August 25, 2004 8 The Message Session Relay Protocol 9 draft-ietf-simple-message-sessions-08.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 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 23 Internet-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 February 23, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document describes the Message Session Relay Protocol (MSRP), 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 setup via a rendezvous or session setup protocol 48 such as the Session Initiation Protocol (SIP). 50 Table of Contents 52 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Introduction and Background . . . . . . . . . . . . . . . . 4 54 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5 55 4. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 8 56 4.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8 57 4.2 MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 9 58 4.3 MSRP Transaction and Report Model . . . . . . . . . . . . 9 59 4.4 MSRP Connection Model . . . . . . . . . . . . . . . . . . 10 60 5. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 5.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 13 62 5.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 14 63 6. Method-Specific Behavior . . . . . . . . . . . . . . . . . . 14 64 6.1 Constructing Requests . . . . . . . . . . . . . . . . . . 14 65 6.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 15 66 6.1.2 Sending REPORT requests . . . . . . . . . . . . . . . 18 67 6.1.3 Failure REPORT Generation . . . . . . . . . . . . . . 18 68 6.2 Constructing Responses . . . . . . . . . . . . . . . . . . 19 69 6.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 20 70 6.3.1 Receiving SEND requests . . . . . . . . . . . . . . . 20 71 6.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 21 72 7. Using MSRP with SIP . . . . . . . . . . . . . . . . . . . . 22 73 7.1 SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 22 74 7.1.1 URL Negotiations . . . . . . . . . . . . . . . . . . . 24 75 7.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 25 76 7.1.3 Updated SDP Offers . . . . . . . . . . . . . . . . . . 26 77 7.1.4 Example SDP Exchange . . . . . . . . . . . . . . . . . 26 78 7.1.5 Connection Negotiation . . . . . . . . . . . . . . . . 27 79 7.2 MSRP User Experience with SIP . . . . . . . . . . . . . . 27 80 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 28 81 9. Response Code Descriptions . . . . . . . . . . . . . . . . . 30 82 9.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 83 9.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 84 9.3 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 85 9.4 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 86 9.5 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 87 9.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 9.7 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 10.1 Basic IM session . . . . . . . . . . . . . . . . . . . . 31 91 10.2 Chunked Message . . . . . . . . . . . . . . . . . . . . 33 92 10.3 System Message . . . . . . . . . . . . . . . . . . . . . 33 93 10.4 Positive Report . . . . . . . . . . . . . . . . . . . . 34 94 10.5 Forked IM . . . . . . . . . . . . . . . . . . . . . . . 34 95 11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 37 96 12. CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 37 97 13. Security Considerations . . . . . . . . . . . . . . . . . . 38 98 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 99 14.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . 40 100 14.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 40 101 14.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . 40 102 14.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . 40 103 14.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 40 104 14.3.3 Max Size . . . . . . . . . . . . . . . . . . . . . . 41 105 14.3.4 Path . . . . . . . . . . . . . . . . . . . . . . . . 41 106 15. Change History . . . . . . . . . . . . . . . . . . . . . . . 41 107 15.1 draft-ietf-simple-message-sessions-08 . . . . . . . . . 41 108 15.2 draft-ietf-simple-message-sessions-07 . . . . . . . . . 41 109 15.3 draft-ietf-simple-message-sessions-06 . . . . . . . . . 42 110 15.4 draft-ietf-simple-message-sessions-05 . . . . . . . . . 42 111 15.5 draft-ietf-simple-message-sessions-04 . . . . . . . . . 43 112 15.6 draft-ietf-simple-message-sessions-03 . . . . . . . . . 43 113 15.7 draft-ietf-simple-message-sessions-02 . . . . . . . . . 43 114 15.8 draft-ietf-simple-message-sessions-01 . . . . . . . . . 44 115 15.9 draft-ietf-simple-message-sessions-00 . . . . . . . . . 44 116 15.10 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 45 117 16. Contributors and Acknowledgments . . . . . . . . . . . . . . 45 118 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 119 17.1 Normative References . . . . . . . . . . . . . . . . . . . 45 120 17.2 Informational References . . . . . . . . . . . . . . . . . 46 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48 122 Intellectual Property and Copyright Statements . . . . . . . 49 124 1. Conventions 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC-2119 [5]. 130 This document consistently refers to a "message" as a complete unit 131 of MIME or text content. In some cases a message is split and 132 delivered in more than one MSRP request. Each of these portions of 133 the complete message is called a "chunk". 135 2. Introduction and Background 137 A series of related textual messages between two or more parties can 138 be viewed as part of a session with a definite start and end. This 139 is in contrast to individual messages each sent completely 140 independently. The SIMPLE Working Group describes messaging schemes 141 that only track individual messages as "page-mode" messages, whereas 142 messaging that is part of a "session" with a definite start and end 143 is called session-mode messaging. 145 Page-mode messaging is enabled in SIMPLE via the SIP [4]MESSAGE 146 method [19]. Session-mode messaging has a number of benefits [20] 147 over page-mode messaging however, such as explicit rendezvous, 148 tighter integration with other media types, direct client-to-client 149 operation, and brokered privacy and security. 151 This document defines a session-oriented instant message transport 152 protocol called the Message Session Relay Protocol (MSRP), whose 153 sessions can be included in an offer or answer [3] using the Session 154 Description Protocol(SDP [2]). The exchange is carried by some 155 signaling protocol, such as SIP [4]. This allows a communication 156 user agent to offer a messaging session as one of the possible media 157 types in a session. For instance, Alice may want to communicate with 158 Bob. Alice doesn't know at the moment whether Bob has his phone or 159 his IM client handy, but she's willing to use either. She sends an 160 invitation to a session to the address of record she has for Bob, 161 sip:bob@example.com. Her invitation offers both voice and an IM 162 session. The SIP services at example.com forward the invitation to 163 Bob at his currently registered clients. Bob accepts the invitation 164 at his IM client and they begin a threaded chat conversation. 166 This session model allows message sessions to be integrated into 167 advanced communications applications with little to no additional 168 protocol development. For example, during the above chat session, 169 Bob decides Alice really needs to be talking to Carol. Bob can 170 transfer [18] Alice to Carol, introducing them into their own 171 messaging session. Messaging sessions can then be easily integrated 172 into call-center and dispatch environments utilizing third-party call 173 control [17] and conferencing [16] applications. 175 3. Protocol Overview 177 MSRP is a text-based, connection-oriented protocol for exchanging 178 arbitrary (binary) MIME content, especially instant messages. This 179 section is a non-normative overview of how MSRP works and how it is 180 used with SIP. 182 MSRP sessions are typically arranged using SIP the same way a session 183 of audio or video media is setup. One SIP user agent (Alice) sends 184 the other (Bob) a SIP invitation containing an offer 185 session-description which includes a session of MSRP. The receiving 186 SIP user agent can accept the invitation and include an answer 187 session-description which acknowledges the choice of media. Alice's 188 session description contains an MSRP URL that describes where she is 189 willing to receive MSRP requests from Bob, and vice-versa. (Note: 190 Some lines in the examples are removed for clarity and brevity.) 191 Alice sends to Bob: 193 INVITE sip:alice@atlanta.example.com SIP/2.0 194 To: 195 From: ;tag=786 196 Call-ID: 3413an89KU 197 Content-Type: application/sdp 199 c=IN IP4 10.1.1.1 200 m=message 9 msrp * 201 a=accept-types:text/plain 202 a=path:msrp://atlanta.example.com:7654/jshA7we;tcp 204 Bob sends to Alice: 206 SIP/2.0 200 OK 207 To: ;tag=087js 208 From: ;tag=786 209 Call-ID: 3413an89KU 210 Content-Type: application/sdp 212 c=IN IP4 10.2.2.2 213 m=message 9 msrp * 214 a=accept-types:text/plain 215 a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 217 Alice sends to Bob: 219 ACK sip:alice@atlanta.example.com SIP/2.0 220 To: ;tag=087js 221 From: ;tag=786 222 Call-ID: 3413an89KU 224 MSRP defines two request types, or methods. SEND requests are used 225 to deliver a complete message or a chunk (a portion of a complete 226 message), while REPORT requests report on the status of an earlier 227 SEND request. When Alice receives Bob's answer, she checks to see if 228 she has an existing connection to Bob. If not, she opens a new 229 connection to Bob using the URL he provided in the SDP. Alice then 230 delivers a SEND request to Bob with her initial message, and Bob 231 replies indicating that Alice's request was received successfully. 233 MSRP a786hjs2 SEND 234 To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 235 From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp 236 Message-ID: 87652 237 Content-Type: text/plain 239 Hey Bob, are you there? 240 -------a786hjs2$ 242 MSRP a786hjs2 200 OK 243 To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp 244 From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 245 Message-ID: 87652 246 -------a786hjs2$ 248 Alice's request begins with the MSRP start line, which contains a 249 transaction identifier that is also used as a final boundary marker. 250 Next she includes the path of URLs to the destination in the To-Path 251 header, and her own URL in the From-Path header. In this typical 252 case there is just one "hop", so there is only one URL in each path 253 header field. She also includes a message ID which she can use to 254 correlate responses and status reports with the original message. 255 Next she puts the actual content. Finally she closes the request 256 with an end line: seven hyphens, the transaction identifier / 257 boundary marker and a "$" to indicate this request contains the end 258 of a complete message. 260 If Alice wants to deliver a very large message, she can split the 261 message into chunks and deliver each chunk in a separate SEND 262 request. The message ID corresponds to the whole message, so the 263 receiver can also use it to reassemble the message and tell which 264 chunks belong with which message. Chunking is described in more 265 detail in Section 4.1. 267 Alice can also specify what type of reporting she would like in 268 response to her request. If Alice requests positive 269 acknowledgements, Bob sends a REPORT request to Alice confirming the 270 delivery of her complete message. This is especially useful if Alice 271 sent a series of SEND request containing chunks of a single message. 272 More on requesting types of reports and errors is described in 273 Section 4.3. 275 Alice and Bob generally choose their MSRP URLs in such a way that is 276 difficult to guess the exact URL. Alice and Bob can reject requests 277 to URLs they are not expecting to service, and can correlate the 278 specific URL with the probable sender. Alice and Bob can also use 279 TLS [1] to provide channel security over this hop. To receive MSRP 280 requests over a TLS protected connection, Alice or Bob could 281 advertise URLs with the "msrps" scheme instead of "msrp." 283 This document specifies MSRP behavior only peer-to-peer session, that 284 is, for a single hop. But is designed with the expectation that MSRP 285 can carry URLs for nodes on the far side of gateways or relays. For 286 this reason, a URL with the "msrps" scheme makes no assertion about 287 the security properties of other hops, just the next hop. 289 MSRP URLs are discussed in more detail in Section 5. 291 An adjacent pair of busy MSRP nodes (for example two gateways) can 292 easily have several sessions, and exchange traffic for several 293 simultaneous users. The nodes can use existing connections to carry 294 new traffic with the same destination host, port, transport protocol, 295 and scheme. MSRP nodes can keep track of how many sessions are using 296 a particular connection and close these connections when no sessions 297 have used them for some period of time. Connection management is 298 discussed in more detail in Section 4.4. 300 4. Key Concepts 302 4.1 MSRP Framing and Message Chunking 304 Messages sent using MSRP can be very large and can be delivered in 305 several SEND requests, where each SEND request contains one chunk of 306 the overall message. To support this, MSRP uses a boundary based 307 framing mechanism. The header of an MSRP request contains a unique 308 boundary string that is used to indicate the end of the request. 309 Following the boundary string at the end of the body data, there is a 310 flag that indicates whether this is the last chunk of data for this 311 message or whether the message will be continued in a subsequent 312 chunk. There is also a Byte-Range header in the request that 313 indicates the overall position of this chunk inside the complete 314 message. 316 For example, the following snippet of two SEND requests demonstrates 317 a message that contains the text "abcdEFGH" being sent as two chunks. 319 MSRP dkei38sd SEND 320 Message-ID: 456 321 Byte-Range: 1-4/8 322 Content-Type: text/plain 324 abcd 325 -------dkei38sd+ 327 MSRP dkei38ia SEND 328 Message-ID: 456 329 Byte-Range: 5-8/8 330 Content-Type: text/plain 332 EFGH 333 -------dkei38ia$ 335 This chunking mechanism allows a sender to interrupt a chunk part way 336 through sending it. The ability to interrupt messages allows 337 multiple sessions to share a TCP connection, and for large messages 338 to be sent efficiently while not blocking other messages that share 339 the same connection. 341 The ability to interrupt messages is needed so that TCP connections 342 can be shared. Connection sharing is necessary for "fair" allocation 343 of bandwidth in congestion situations and for allowing MSRP network 344 elements that have a very large number of concurrent connections to 345 different users. 347 4.2 MSRP Addressing 349 MSRP entities are addressed using URLs. The MSRP URL schemes are 350 defined in Section 5. The syntax of the To-Path and From-Path 351 headers allow for a list of URLs. This was done to allow the 352 protocol to work with gateways or relays defined in the future, to 353 provide a complete path to the end recipient. When two MSRP nodes 354 communicate directly they need only one URL in the To-Path list and 355 one URL in the From-Path list. 357 4.3 MSRP Transaction and Report Model 359 A sender sends MSRP requests to a receiver. The receiver MUST 360 quickly accept or reject the request. If the receiver initially 361 accepted the request, it still may then do things that take 362 significant time to succeed or fail. For example, if the receiver is 363 an MSRP to XMPP [29] gateway, it may forward the message over XMPP. 364 The XMPP side may later indicate that the request did not work. At 365 this point, the MSRP receiver may need to indicate that the request 366 did not succeed. There are two important concepts here: first, the 367 hop by hop delivery of the request may succeed or fail; second, the 368 end result of the request may be successfully processed or not. The 369 first type of status is referred to as "transaction status" and may 370 be returned in response to a request. The second type of status is 371 referred to as "request status" and may be returned in a REPORT 372 transaction. 374 The original sender of a request can indicate if they wish to receive 375 reports for requests that fail, and can independently indicate if 376 they wish to receive reports for requests that succeed. A receiver 377 only sends a success REPORT if it knows that the request succeeded, 378 and the sender requested a success report. A receiver only sends a 379 failure REPORT if the request failed and the sender requested failure 380 reports. 382 This document describes the behavior of MSRP endpoints. MSRP 383 relays or gateways are likely to have additional conditions that 384 indicate a failure REPORT should be sent, such as the failure to 385 receive a positive response from the next hop. 387 Two header fields control the sender's desire to receive reports. 388 The header "Report-Success" can have a value of "yes" or "no" and the 389 "Report-Failure" header can have a value of "yes", "no", or 390 "partial". 392 The combinations of reporting are needed to meet the various 393 scenarios of currently deployed IM systems. Report-Success might be 394 "no" in many public systems to reduce load but is used in some 395 current enterprise systems, such as systems used for securities 396 trading. A Report-Failure value of "no" is useful for sending system 397 messages such as "the system is going down in 5 minutes" without 398 causing a response explosion to the sender. A Report-Failure of 399 "yes" is used by many systems that wish to notify the user if the 400 message failed but some other systems choose to use a value of 401 "partial" to reduce the load on the servers caused by 200 OK 402 responses, but still allow error responses to be sent in many cases. 404 4.4 MSRP Connection Model 406 When MSRP wishes to send a request to a peer identified by an MSRP 407 URL, it first needs a connection, with the appropriate security 408 properties, to the host specified in the URL. If the sender already 409 has such a connection, that is, one associated with the same host, 410 port, and URL scheme, then it SHOULD reuse that connection. 412 When a new MSRP session is created, the convention is that the 413 element that sent the SDP offer MUST immediately issue a SEND request 414 to the answerer. This request MAY have a empty body, or MAY carry 415 content. 417 When a new connection needs to be formed, the element looks at the 418 URL to decide on the type of connection (TLS, TCP, etc.) then 419 connects to the host indicated by the URL, following the URL 420 resolution rules in Section 5.2. For connections using the msrps: 421 scheme, the SubjectAltName in the received certificate MUST match the 422 hostname part of the URL and the certificate MUST be valid, including 423 having a date that is valid and being signed by an acceptable 424 certificate authority. At this point the device that initiated the 425 connection can assume that this connection is with the correct host. 427 If the connection used mutual TLS authentication, and the TLS client 428 presented a valid certificate, then the element accepting the 429 connection can know the identity of the connecting host. When mutual 430 TLS authentication is not used, the listening device MUST wait until 431 it receives a request on the connection to determine the identity of 432 the connecting device. 434 When the first request arrives, its To-Path header field should 435 contain a URL that the listening element handed out in the SDP for a 436 session. The element that accepted the connection looks up the URL 437 in the received request, and determines which session it matches. If 438 a match exists, the node MUST assume that the host that formed the 439 connection is the host that this URL was given to. If no match 440 exists, the node MUST reject the request with a 481 response. The 441 node MUST also check to make sure the session is not already in use 442 on another connection. If so, it MUST reject the request with a 506 443 response. 445 If it were legal to have multiple connections associated with the 446 same session, a security problem would exist. If the initial SEND 447 request is not protected, an eavesdropper might learn the URL, and 448 use it to insert messages into the session via a different 449 connection. 451 If a connection fails for any reason, then an MSRP endpoint MUST 452 consider failed any sessions associated with the connection as well. 453 When an endpoint notices such a failure, it MAY attempt to re-create 454 any such sessions. If it chooses to do so, it MUST use new SDP 455 exchange. If a replacement session is successfully created, 456 endpoints MAY attempt to resend any content for which delivery on the 457 original session could not be confirmed. If it does this, the 458 Message-ID values for the resent messages MUST match those used in 459 the initial attempts. If the receiving endpoint receives more than 460 one message with the same Message-ID. It SHOULD assume that the 461 messages are duplicates. It MAY take any action based on that 462 knowledge, but SHOULD NOT present the duplicate messages to the user 463 without warning of the duplicates. 465 In this situation, the endpoint MUST choose Message-ID values so that 466 they are unique in the context of both the original session and the 467 replacement session. 469 When endpoints create a new session in this fashion, the chunks for a 470 given logical message MAY be split across the sessions. However, 471 endpoints SHOULD NOT split chunks between sessions under normal 472 circumstances. 474 If a connection fails, the sender SHOULD attempt to re-setup the URL 475 path using a new offer, for example, in a SIP re-invite or update 476 [12]. It MUST not assume that the new URLs in the SDP will be the 477 same as the old ones. A connection SHOULD not be closed while there 478 are sessions that are using this connection. 480 5. MSRP URLs 482 An MSRP URL follows a subset of the URL syntax in Appendix A of 483 RFC2396 [10], with a scheme of "msrp" or "msrps": 485 MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" 486 resource] ";" transport 487 msrp-scheme = "msrp" / "msrps" 488 resource = 1*unreserved 489 transport = "tcp" / ALPHANUM 491 The constructions for "userinfo", "hostport", and "unreserved" are 492 detailed in RFC2396 [10]. URLs designating MSRP over TCP MUST 493 include the "tcp" parameter. If some other transport is used, the 494 "tcp" parameter MUST NOT be present. 496 Since this document only specifies MSRP over TCP, all MSRP URLs 497 herein use the "tcp" parameter. Documents that provide bindings 498 on other transports should define respective parameters for those 499 transports. 501 An MSRP URL hostport field identifies a participant in an MSRP 502 session. If the hostport contains a numeric IP address, it MUST also 503 contain a port. The resource part identifies a particular session 504 the participant. The absence of the resource part indicates a 505 reference to an MSRP host device, but does not specifically refer to 506 a particular session resource. 508 A scheme of "msrps" indicates the underlying connection MUST be 509 protected with TLS. 511 MSRP has an IANA registered recommended port defined in Section 14.1. 512 This value is not a default, as the URL negotiation process described 513 herein will always include explicit port numbers. However, the URLs 514 SHOULD be configured so that the recommended port is used whenever 515 appropriate. This makes life easier for network administrators who 516 need to manage firewall policy for MSRP. 518 The server part will typically not contain a userinfo component, but 519 MAY do so to indicate a user account for which the session is valid. 520 Note that this is not the same thing as identifying the session 521 itself. If a userinfo component exists, it MUST be constructed only 522 from "unreserved" characters, to avoid a need for escape processing. 523 Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo 524 part MUST NOT contain password information. 526 The following is an example of a typical MSRP URL: 528 msrp://host.example.com:8493/asfd34;tcp 530 5.1 MSRP URL Comparison 532 MSRP URL comparisons MUST be performed according to the following 533 rules: 535 1. The scheme must match exactly. 537 2. If the hostpart contains an eplicit IP address, and/or port, 538 these are compared numerically. Otherwise, hostpart is compared 539 as a case insensitive character string. 541 3. If the port exists explicitly in either URL, then it must match 542 exactly. An URL with an explicit port is never equivalent to 543 another with no port specified. 545 4. The resource part is compared as case sensitive. A URL without a 546 resource part is never equivalent to one that includes a resource 547 part. 549 5. URLs with different "transport" parameters never match. Two URLs 550 that are identical except for transport are not equivalent. 552 6. Userinfo parts are not considered for URL comparison. 554 Path normalization is not relevant for MSRP URLs. Escape 555 normalization is not required, since the relevant parts are limited 556 to unreserved characters. 558 5.2 Resolving MSRP Host Device 560 An MSRP host device is identified by the server part of an MSRP URL. 562 If the server part contains a numeric IP address and port, they MUST 563 be used as listed. 565 If the server part contains a host name and a port, the connecting 566 device MUST determine a host address by doing an A or AAAA DNS query, 567 and use the port as listed. 569 If a connection attempt fails, the device SHOULD attempt to connect 570 to the addresses returned in any additional A or AAAA records, in the 571 order the records were presented. 573 This process assumes that the connection port is always known 574 prior to resolution. This is always true for the MSRP URL uses 575 described in this document, that is, URLs always created and 576 consumed by automata, rather than by humans. The introduction of 577 relays may create situations where this is not the case. For 578 example, the MSRP URL that a user enters into a client to 579 configure it to use a relay may be intended to be easily 580 remembered and communicated by humans, and therefore is likely to 581 omit the port. Therefore, the relay specification [21] may 582 describe additional steps to resolve the port number. 584 MSRP devices MAY use other methods for discovering other such 585 devices, when appropriate. For example, MSRP endpoints may use other 586 mechanisms to discover relays, which are beyond the scope of this 587 document. 589 6. Method-Specific Behavior 591 6.1 Constructing Requests 593 To form a new request, the sender creates a unique transaction 594 identifier and uses this and the method name to create an MSRP 595 request start line. Next, the sender places the target path in a 596 To-Path header, and the sender's URL in a From-Path header. If 597 multiple URLs are present in the To-Path, the leftmost is the first 598 URL visited; the rightmost URL is the last URL visited. The 599 processing then becomes method specific. Additional method-specific 600 headers are added as described in the following sections. 602 After any method-specific headers are added, processing continues to 603 handle a body, if present. A body in a Non-SEND request MUST NOT be 604 longer than 2048 octets. If the request has a body, it must contain 605 a Content-Type header field. It may contain other MIME specific 606 headers. The Content-Type header MUST be the last header line. The 607 body MUST be separated from the headers with an extra CRLF. 609 The boundary marker that terminates the body MUST be preceded by a 610 CRLF that is not part of the body and then seven "-" (minus sign) 611 characters. After the boundary marker, there MUST be a flag 612 character that is a "$" (for the last chunk of the complete 613 message), "#" (for the last chunk of an aborted message), or "+" (for 614 chunks other than the last). If the chunk represents the data that 615 forms the end of the complete message, the flag value MUST be a "$". 616 If sender is abandoning an incomplete message, and intends to send no 617 further chunks in that message, it MUST be a "#". Otherwise it MUST 618 be a "+". 620 If the request contains a body, the sender MUST check the body to 621 insure that the closing sequence (a CRLF, seven hyphens, and the 622 transaction identifier) is not present in the body. If the closing 623 sequence is present in the body, the sender MUST choose a new 624 transaction identifier that is not present in the body, and add the 625 closing sequence, including the "$", "#", or "+" character, and a 626 final CRLF. 628 Finally, requests which have no body MUST NOT contain a Content-Type 629 header or any other MIME specific header. Bodiless requests MUST 630 contain a closing sequence after the final header. 632 Once a request is ready for delivery, the sender follows the 633 connection management (Section 4.4) rules to forward the request over 634 an existing open connection or create a new connection. 636 6.1.1 Delivering SEND requests 638 When an endpoint has a message to deliver, it first generates a new 639 unique Message-ID. This ID MUST be unique within the scope of the 640 session. If the message is larger than 2048 octets in length, it 641 either generates an interruptible chunk (which is RECOMMENDED), or it 642 MAY break the complete message into chunks of 2048 octets. It then 643 generates a SEND request for each chunk, following the procedures 644 for constructing requests (Section 6.1). 646 Each chunk MUST contain a Message-ID header field containing the 647 Message-ID. If the sender wishes non-default status reporting, it 648 MUST insert a Report-Failure and/or Report-Success header field with 649 an appropriate value. All chunks of the same message MUST use the 650 same Report-Failure and Report-Success values in their SEND requests. 652 If success reports are requested, i.e. the value of the 653 Report-Success header is "yes", the sending device MAY wish to run a 654 timer of some value that makes sense for its application and take 655 action if a success Report is not received in this time. There is no 656 universal value for this timer. For many IM applications, it may be 657 2 minutes while for some trading systems it may be under a second. 658 Regardless of whether such a timer is used, if the success report has 659 not been received by the time the session is ended, the device SHOULD 660 inform the user. 662 If the value of "Report-Failure" is set to "yes", then the sender of 663 the request runs a timer. If a 200 response to the transaction is 664 not received within 30 seconds from the time the last byte of the 665 transaction is sent, the element MUST inform the user that the 666 request probably failed. If the value is set to "partial", then the 667 element sending the transaction does not have to run a timer, but 668 MUST inform the user if receives a non-recoverable error response to 669 the transaction. 671 If no Report-Success header is present in a SEND request, it MUST be 672 treated the same as a Report-Success header with value of "no". If 673 no Report-Failure header is present, it MUST be treated the same as a 674 Report-Failure header with value of "yes". REPORT requests MUST have 675 the same Message-ID header value as the request they are reporting 676 on. They MAY also have the Byte-Range of the chunk they are 677 reporting on. If an MSRP element receives a REPORT for a Message-ID 678 it does not recognize, it SHOULD silently ignore the REPORT. 680 Report-Success and Report-Failure MUST NOT be present for any method 681 other than SEND. MSRP nodes MUST NOT send REPORT requests in 682 response to report requests. MSRP Nodes MUST NOT send MSRP responses 683 to REPORT requests. 685 The Byte-Range header value contains a starting value (range-start) 686 followed by a "-", an ending value (range-end) followed by a "/", and 687 finally the total length. The first byte in the message is indicated 688 by a one, rather than a zero. 690 The first chunk of the message SHOULD, and all subsequent chunks MUST 691 include a Byte-Range header field. The range-start field MUST 692 indicate the position of the first byte in the body in the overall 693 message (that is, a value of one). The range-end field SHOULD 694 indicate the position of the last byte in the body, if known. It 695 MUST take the value of "*" if the position is unknown, or if the 696 request needs to be interruptible. The total field SHOULD contain 697 the total size of the message, if known. The total field MAY contain 698 a "*" if the total size of the message is not known in advance. All 699 chunks other than the last MUST include a "+" character in the 700 continuation field of the closing line. The final chunk MUST use a 701 "$" character if it completes the message, or a "#" if the sender is 702 aborting the message. The sender MUST send all chunks in Byte-Range 703 order. (However, the receiver cannot assume the requests will be 704 delivered in order, as an intervening relay may have changed the 705 order.) 707 To insure fairness over a connection, senders MUST NOT send chunks 708 with a body larger than 2048 octets unless they are prepared to 709 interrupt them. A sender can use one of the following two strategies 710 to satisfy this requirement. The sender is STRONGLY RECOMMENDED to 711 send messages larger than 2048 octets using as few chunks as 712 possible, interrupting chunks (at least 2048 octets long) when other 713 traffic is waiting to use the same connection. Alternatively, the 714 sender MAY simply send chunks in 2048 octet increments until the 715 final chunk. Note that the former strategy results in markedly more 716 efficient use of the connection. All MSRP nodes MUST be able to 717 receive chunks of any size from 0 octets to the maximum number of 718 octets they can receive for a complete message. Senders SHOULD NOT 719 break messages into chunks smaller than 2048 octets, except for the 720 final chunk of a complete message. 722 A SEND request is interruptible if it either has no Byte-Range header 723 field, or has such a field with a "*" in the last-byte sub-field. 725 A SEND request is interrupted while a body is in the process of being 726 written to the connection by simply noting how much of the message 727 has already been written to the connection, then writing out the 728 boundary string to end the chunk. It can then be resumed in a 729 another chunk with the same Message-ID and a Byte-Range header range 730 start field containing the position of the first byte after the 731 interruption occurred. 733 SEND requests larger than 2k MUST be interrupted to send pending 734 response or REPORT requests. If multiple SEND requests from 735 different sessions are concurrently being sent over the same 736 connection, the device SHOULD implement some scheme to alternate 737 between them such that each concurrent request gets a chance to send 738 some fair portion of data at regular intervals suitable to the 739 application. 741 The sender MUST NOT assume that a message is received by the peer 742 with the same chunk allocation it was sent with. An intervening 743 relay could possibly break SEND requests into smaller chunks, or 744 aggregate multiple chunks into larger ones. 746 The default disposition of body is "render". If the sender wants 747 different disposition, it MAY insert a Content-Disposition header. 748 Since MSRP is a binary protocol, transfer encoding MUST be "binary". 750 6.1.2 Sending REPORT requests 752 REPORT requests are similar to SEND requests, except that report 753 requests MUST NOT include Report-Success or Report-Failure header 754 fields, and MUST contain a Status header field. REPORT requests MUST 755 contain the Message-ID header from the original SEND request. 757 If an MSRP element receives a REPORT for a Message-ID it does not 758 recognize, it SHOULD silently ignore the REPORT. 760 An MSRP endpoint MUST be able to generate success REPORT requests. 762 REPORT requests will normally not include a body, as the REPORT 763 request header fields can carry sufficient information in most cases. 764 However, REPORT requests MAY include a body containing additional 765 information about the status of the assocated SEND request. Such a 766 body is informational only, and the sender of the REPORT request 767 SHOULD NOT assume that the recipient pays any attention to the body. 768 Since REPORT requests are not interruptible, the size of such a body 769 MUST NOT exceed 2 kilobytes. 771 An endpoint MUST send a success report if it successfully receives a 772 SEND request which contained a Report-Success value of "yes" and 773 either contains a complete message, or contains the last chunk needed 774 to complete the message. This request is sent following the normal 775 procedures (Section 6.1), with a few additional requirements. 777 The endpoint inserts a To-Path header field containing the From-Path 778 value from the original request, and a From-Path header containing 779 the URL identifying itself in the session. The endpoint then inserts 780 a Status header field with a namespace of "000", a short-status of 781 "200" and a relevant Reason phrase, and a Message-ID header field 782 containing the value from the original request. 784 The endpoint MUST NOT send a success report for a SEND request that 785 either contained no Report-Success header field, or contained such a 786 field with a value of "no". That is, if no Report-Success header 787 field is present, it is treated identically to one with a value of 788 "no." 790 6.1.3 Failure REPORT Generation 792 If an MSRP endpoint receives a SEND request that it cannot process 793 for some reason, and the Report-Failure header either was not present 794 in the original request, or had a value of "yes", it SHOULD simply 795 include the appopriate error code in the transaction respons. 796 However, there may be situations where the error cannot be determined 797 quickly, such as when the endpoint is a gateway that must wait for a 798 downstream network to indicate an error. In this situation, it MAY 799 send a 200 OK response to the request, and then send a failure REPORT 800 request when the error is detected. 802 If the endpoint receives a SEND request with a Report-Failure header 803 field value of "no", then it MUST NOT send a failure REPORT request, 804 and SHOULD NOT send an MSRP response. If the value is "partial", it 805 SHOULD NOT send a 200 response to the request, but SHOULD send a 806 non-200 class response if appropriate. 808 As stated above, if no Report-Failure header is present, it MUST be 809 treated the same as a Report-Failure header with value of "yes". 811 Construction of failure REPORT requests is identical to that for 812 success reports, except the Status header code and reason fields MUST 813 contain appropriate error codes. Any error response code defined in 814 this specification MAY also be used in failure reports. 816 If a failure report is sent in response to a SEND request that 817 contained a chunk, it MUST include a Byte-Range header indicating the 818 actual range being reported on. It can take the range-start and 819 total values from the original SEND request, but MUST calculate the 820 range-end field from the actual body data. 822 Endpoints SHOULD NOT send REPORT requests if they have reason to 823 believe the request will not be delivered. For example, they SHOULD 824 NOT send a REPORT request on a session that is no longer valid. 826 This section only describes failure report generation behavior for 827 MSRP endpoints. Relay behavior is beyond the scope of this 828 document, and will be considered in a separate document. We 829 expect failure reports to be more commonly generated by relays 830 than by endpoints. 832 6.2 Constructing Responses 834 If an MSRP endpoint receives a request that either contains a 835 Report-Failure header value of "yes", or does not contain a 836 Report-Failure header field at all, it MUST immediately generate a 837 response. Likewise, if an MSRP endpoint receives a request that 838 contains a Report-Failure header value of "partial", and the receiver 839 is unable to process the request, it SHOULD immediately generate a 840 response. 842 To construct the response, the endpoint first creates the response 843 start-line, inserting appropriate response code and reason fields. 844 The transaction identifier in the response start line MUST match the 845 transaction identifier from the original request. 847 The endpoint then inserts an appropriate To-Path header field. If 848 the request triggering the response was a SEND request, the To-Path 849 header field is formed by copying the last (right-most) URI in the 850 From-Path header field of the request. (Unlike other methods, 851 responses to SEND requests are returned only to the previous hop.) 852 For responses to all other requests, the To-Path header field 853 contains the full path back to the original sender. This full path 854 is generated by taking the list of URLs from the From-Path of the 855 original request, reversing the list, and writing the reversed list 856 into the To-Path of the response. (Legal REPORT requests do not 857 request responses, so this specification doesn't exercise the 858 behavior described above, however we expect that extensions for 859 gateways and relays will need such behavior.) 861 Finally, the endpoint inserts a From-Path header field containing the 862 URL that identifies it in the context of the session, followed by the 863 closing sequence after the last header field. The response MUST be 864 transmitted back on the same connection on which the original request 865 arrived. 867 6.3 Receiving Requests 869 The receiving endpoint must first check the URL in the To-Path to 870 make sure the request belongs to an existing session. When the 871 request is received, the To-Path will have exactly one URL, which 872 MUST map to an existing session that is associated with the 873 connection on which the request arrived. If this is not true, and 874 the request contained a Report-Failure header value of "no", then the 875 receiver SHOULD quietly ignore the request. If the Report-Failure 876 header is not present, or had any other value, then the receiver MUST 877 return a 481 response. 879 Further request processing by the receiver is method specific. 881 6.3.1 Receiving SEND requests 883 When the receiving endpoint receives a SEND request, it first 884 determines if it contains a complete message, or a chunk from a 885 larger message. If the request contains no Byte-Range header, or 886 contains one with a range-start value of "1", and the closing line 887 continuation flag has a value of "$", then the request contained the 888 entire message. Otherwise, the receiver looks at the Message-ID 889 value to associate chunks together into the original message. It 890 forms a virtual buffer to receive the message, keeping track of which 891 bytes have been received and which are missing. The receiver takes 892 the data from the request and places it in the appropriate place in 893 the buffer. The receiver MUST determine the actual length of each 894 chunk by inspecting the payload itself; it is possible the body is 895 shorter than the range-end field indicates. This can occur if the 896 sender interrupted a SEND request unexpectedly. It is worth nothing 897 that the chunk that has a termination character of "$" defines the 898 total length of the message. 900 Receivers MUST not assume the chunks will be delivered in order or 901 that they will receive all the chunks with "+" flags before they 902 receive the chunk with the "$" flag. In certain cases of connection 903 failure, it is possible for information to be duplicated. If chunks 904 data is received that overlaps already received data for the same 905 message, the last chunk received takes precedence (even though this 906 may not have been the last chunk transmitted). For example, if bytes 907 1 to 100 was received and a chunk arrives that contains bytes 50 to 908 150, this second chunk will overwrite bytes 50 to 100 of the data 909 that had already been received. Although other schemes work, this is 910 the easiest for the receiver and results in consistent behavior 911 between clients. 913 The seven "-" before the boundary are used so that the receiver can 914 search for the value "----", 32 bits at a time to find the probable 915 location of the boundary. This allows most processors to locate the 916 boundaries and copy the memory at the same rate that a normal memory 917 copy could be done. This approach results in a system that is as 918 fast as framing based on specifying the body length in the headers of 919 the request, but also allows for the interruption of messages. 921 What is done with the body is outside the scope of MSRP and largely 922 determined by the MIME Content-Type and Content-Disposition. The 923 body MAY be rendered after the whole message is received or partially 924 rendered as it is being received. 926 If the SEND request contained a Content-Type header field indicating 927 an unsupported MIME type, the receiver SHOULD send a 415 response, if 928 allowed by the Report-Failure header field. All MSRP endpoints MUST 929 be able to receive the multipart/mixed and multipart/alternative MIME 930 types. 932 6.3.2 Receiving REPORT requests 934 When an endpoint receives a REPORT request, it may correlate it to 935 the original SEND request using the Message-ID and the Byte-Range, if 936 present. If it requested success reports, then it SHOULD keep enough 937 state about each outstanding sent message so that it can correlate 938 REPORT requests to the original messages. 940 An endpoint that receives a REPORT request containing a Status header 941 with a namespace field of "000", it SHOULD interpret the report in 942 exactly the same way it would interpret an MSRP transaction response 943 with a response code matching the short-code field. 945 It is possible to receive a failure report or a failure transaction 946 response for a chunk that is currently being delivered. In this case 947 the entire message corresponding to that chunk should be aborted. 949 It is possible that an endpoint will receive a REPORT request on a 950 session that is no longer valid. The endpoint's behavior if this 951 happens is a matter of local policy. The endpoint is not required to 952 take any steps to facilitate such late delivery, i.e. it is not 953 expected to keep a connection active in case late REPORTs might 954 arrive. 956 MSRP Modes MUST NOT send MSRP responses to REPORT requests. 958 7. Using MSRP with SIP 960 7.1 SDP Offer-Answer Exchanges for MSRP Sessions 962 MSRP sessions will typically be initiated using the Session 963 Description Protocol (SDP) [2] via the SIP offer-answer mechanism 964 [3]. 966 This document defines a handful of new SDP parameters to setup MSRP 967 sessions. These are detailed below and in the IANA Considerations 968 section. 970 The general format of an SDP media-line is: 972 m= 974 An offered or accepted MSRP media-line MUST have the following value 975 exactly, with the exception that the port field MAY be set to zero. 976 (According to [3], a user agent that wishes to accept an offer, but 977 not a specific media-line MUST set the port number of that media-line 978 to zero (0).) 980 m=message 9 msrp * 982 While MSRP could theoretically carry any media type, "message" is 983 appropriate. For MSRP, the port number is always ignored--the 984 actual port number is provided in an MSRP URL. Instead a dummy 985 value is used, which is always ignored if non-zero. The protocol 986 is always "msrp", and the value of the format list is always a 987 single asterisk character ("*"). 989 An MSRP media-line is always accompanied by a mandatory "path" 990 attribute. This attribute contains a space separated list of URLs 991 that must be visited to contact the user agent advertising this 992 session-description. If more than one URL is present, the leftmost 993 URL is the first URL that must be visited to reach the target 994 resource. (The path list can contain multiple URLs to allow for the 995 deployment of gateways or relays in the future.) MSRP 996 implementations which can accept incoming connections will typically 997 only provide a single URL here. 999 MSRP media lines MUST also be accompanied by an "accept-types" 1000 attribute. This attribute contains a list of MIME types which are 1001 acceptable to the endpoint. 1003 A "*" entry in the accept-types attribute indicates that the sender 1004 may attempt to send content with media types that have not been 1005 explicitly listed. Likewise, an entry with an explicit type and a 1006 "*" character as the subtype indicates that the sender may attempt to 1007 send content with any subtype of that type. If the receiver receives 1008 an MSRP request and is able to process the media type, it does so. 1009 If not, it will respond with a 415 response. Note that all explicit 1010 entries SHOULD be considered preferred over any non-listed types. 1011 This feature is needed as, otherwise, the list of formats for rich IM 1012 devices may be prohibitively large. 1014 The accept-types attribute may include container types, that is, MIME 1015 formats that contain other types internally. If compound types are 1016 used, the types listed in the accept-types attribute may be used both 1017 as the root payload, or may be wrapped in a listed container type. 1018 Any container types MUST also be listed in the accept-types 1019 attribute. 1021 Occasionally an endpoint will need to specify a MIME body type that 1022 can only be used if wrapped inside a listed container type. 1024 Endpoints MAY specify MIME types that are only allowed when wrapped 1025 inside compound types using the "accept-wrapped-types" attribute in 1026 an SDP a-line. 1028 The semantics for accept-wrapped-types are identical to those of the 1029 accept-types attribute, with the exception that the specified types 1030 may only be used when wrapped inside containers. Only types listed 1031 in the accept-types attribute may be used as the "root" type for the 1032 entire body. Since any type listed in accept-types may be used both 1033 as a root body, and wrapped in other bodies, format entries from 1034 accept-types SHOULD NOT be repeated in this attribute. 1036 This approach does not allow for specifying distinct lists of 1037 acceptable wrapped types for different types of containers. If an 1038 endpoint understands a MIME type in the context of one wrapper, it is 1039 assumed to understand it in the context of any other acceptable 1040 wrappers, subject to any constraints defined by the wrapper types 1041 themselves. 1043 The approach of specifying types that are only allowed inside of 1044 containers separately from the primary payload types allows an 1045 endpoint to force the use of certain wrappers. For example, a 1046 CPIM [13] gateway device may require all messages to be wrapped 1047 inside message/cpim bodies, but may allow several content types 1048 inside the wrapper. If the gateway were to specify the wrapped 1049 types in the accept-types attribute, its peer might attempt to use 1050 those types without the wrapper. 1051 An endpoint MAY indicate the maximim size message they wish to 1052 receive using the max-size a-line attribute Max-size refers to the 1053 complete message, not the size of any one chunk. Senders SHOULD 1054 NOT exceed the max-size limit for any message sent in the 1055 resulting session. However, the receiver should consider max-size 1056 value as a hint. 1058 accept-types = accept-types-label ":" format-list 1059 accept-types-label = "accept-types" 1060 accept-wrapped-types = wrapped-types-label ":" format-list 1061 wrapped-types-label = "accept-wrapped-types" 1062 format-list = format-entry *( SP format-entry) 1063 format-entry = (type "/" subtype) / (type "/" "*") / ("*") 1064 type = token 1065 subtype = token 1067 max-size = max-size-label ":" max-size-value 1068 max-size-label = "max-size" 1069 max-size-value = 1*(DIGIT) 1071 7.1.1 URL Negotiations 1073 Each endpoint in an MSRP session is identified by a URL. These URLs 1074 are negotiated in the SDP exchange. Each SDP offer or answer MUST 1075 contain one or more MSRP URL in a path attribute. This attribute has 1076 the following syntax: 1078 "a=path:" MSRP_URL *(SP MSRP_URL) 1080 where MSRP_URL is an msrp: or msrps: URL as defined in Section 5. 1081 MSRP URLs included in an SDP offer or answer MUST include explicit 1082 port numbers. 1084 An MSRP device uses the URL to determine a host address, port, 1085 transport, and protection level when connecting, and to identify the 1086 target when sending requests and responses. 1088 The offerer and answerer each selects a URL to represent itself, and 1089 send it to the peer device in the SDP document. Each device stores 1090 the path value received from the peer, and uses that value as the 1091 target for requests inside the resulting session. If the path 1092 attribute received from the peer contains more than one URL, then the 1093 target URL is the rightmost, while the leftmost entry represents the 1094 adjacent hop. If only one entry is present, then it is both the peer 1095 and adjacent hop URL. The target path is the entire path attribute 1096 value received from the peer. 1098 The following example shows an SDP offer with a session URL of 1099 "msrp://a.example.com:7394/2s93i;tcp" 1101 v=0 1102 o=alice 2890844526 2890844527 IN IP4 alice.example.com 1103 s= 1104 c=IN IP4 alice.example.com 1105 m=message 9 msrp * 1106 a=accept-types:text/plain 1107 a=path:msrp://a.example.com:7394/2s93i;tcp 1109 The rightmost URI in the path attribute MUST identify the endpoint 1110 that generated the SDP document, or some other location where that 1111 endpoint wishes to receive requests associated with the session. It 1112 MUST be assigned for this particular session, and MUST NOT duplicate 1113 any URI in use for any other session in which the endpoint is 1114 currently participating. It SHOULD be hard to guess, and protected 1115 from eavesdroppers. This is discussed in more detail in Section 13. 1117 7.1.2 Path Attributes with Multiple URLs 1119 As mentioned previously, this document describes MSRP for 1120 peer-to-peer scenarios, that is, when no relays are used. However, 1121 we expect a separate document to describe the use of relays. In 1122 order to allow an MSRP device that only implements the core 1123 specification to interoperate with devices that use relays, this 1124 document must include a few assumptions about how relays work. 1126 An endpoint that uses one or more relays will indicate that by 1127 putting a URL for each device in the relay chain into the SDP path 1128 attribute. The final entry would point to the endpoint itself. The 1129 other entries would indicate each proposed relay, in order. The 1130 first entry would point to the first relay in the chain; that is, the 1131 relay to which the peer device, or a relay operation on its behalf, 1132 should connect. 1134 Endpoints that do not wish to insert a relay, including those that do 1135 not support relays at all, will put exactly one URL into the path 1136 attribute. This URL represents both the endpoint for the session, 1137 and the connection point. 1139 While endpoints that implement only this specification will never 1140 introduce a relay, they will need to be able to interoperate with 1141 other endpoints that do use relays. Therefore, they MUST be prepared 1142 to receive more than one URL in the SDP path attribute. When an 1143 endpoint receives more than one URL in a path header, only the first 1144 entry is relevant for purposes of resolving the address and port, and 1145 establishing the network connection, as it describes the first 1146 adjacent hop. 1148 If an endpoint puts more than one URL in a path attribute, the final 1149 URL in the path (the peer URL) attribute MUST exhibit the uniqueness 1150 properties described above. Uniqueness requirements for other 1151 entries in the attribute are out of scope for this document. 1153 7.1.3 Updated SDP Offers 1155 MSRP endpoints may sometimes need to send additional SDP exchanges 1156 for an existing session. They may need to send periodic exchanges 1157 with no change to refresh state in the network, for example, SIP 1158 Session Timers. They may need to change some other stream in a 1159 session without affecting the MSRP stream, or they may need to change 1160 an MSRP stream without affecting some other stream. 1162 Either peer may initiate an updated exchange at any time. The 1163 endpoint that sends the new offer assumes the role of offerer for all 1164 purposes. The answerer MUST respond with a path attribute that 1165 represents a valid path to itself at the time of the updated 1166 exchange. This new path may be the same as its previous path, but 1167 may be different. The new offerer MUST NOT assume that the peer will 1168 answer with the same path it used previously. 1170 If either party wishes to send an SDP document that changes nothing 1171 at all, then it MUST have the same o-line as in the previous 1172 exchange. 1174 7.1.4 Example SDP Exchange 1176 Endpoint A wishes to invite Endpoint B to a MSRP session. A offers 1177 the following session description: 1179 v=0 1180 o=usera 2890844526 2890844527 IN IP4 alice.example.com 1181 s= 1182 c=IN IP4 alice.example.com 1183 t=0 0 1184 m=message 9 msrp * 1185 a=accept-types: message/cpim text/plain text/html 1186 a=path:msrp://alice.example.com:7394/2s93i9;tcp 1188 B responds with its own URL: 1190 v=0 1191 o=userb 2890844530 2890844532 IN IP4 bob.example.com 1192 s= 1193 c=IN IP4 bob.example.com 1194 t=0 0 1195 m=message 9 msrp * 1196 a=accept-types:message/cpim text/plain 1197 a=path:msrp://bob.example.com:8493/si438ds;tcp 1199 7.1.5 Connection Negotiation 1201 Previous versions of this document included a mechanism to negotiate 1202 the direction for any required TCP connection. The mechanism was 1203 loosely based on the COMEDIA [24] work being done in the MMUSIC 1204 working group. The primary motivation was to allow MSRP sessions to 1205 succeed in situations where the offerer could not accept connections 1206 but the answerer could. For example, the offerer might be behind a 1207 NAT, while the answerer might have a globally routable address. 1209 The SIMPLE working group chose to remove that mechanism from MSRP, as 1210 it added a great deal of complexity to connection management. 1211 Instead, MSRP now specifies a default connection direction. 1213 7.2 MSRP User Experience with SIP 1215 In typical SIP applications, when an endpoint receives an INVITE 1216 request, it alerts the user, and waits for user input before 1217 responding. This is analogous to the typical telephone user 1218 experience, where the callee "answers" the call. 1220 In contrast, the typical user experience for instant messaging 1221 applications is that the initial received message is immediately 1222 displayed to the user, without waiting for the user to "join" the 1223 conversation. Therefore, the principle of least surprise would 1224 suggest that MSRP endpoints using SIP signaling SHOULD allow a mode 1225 where the endpoint quietly accepts the session, and begins displaying 1226 messages. 1228 SIP INVITE requests may be forked by a SIP proxy, resulting in more 1229 than one endpoint receiving the same INVITE. SIP early media [28] 1230 techniques can be used to establish a preliminary session with each 1231 endpoint, and canceling the INVITE transaction for any endpoints that 1232 do not send MSRP traffic after some period of time. 1234 8. Formal Syntax 1236 MSRP is a text protocol that uses the UTF-8 [15] transformation 1237 format. 1239 The following syntax specification uses the augmented Backus-Naur 1240 Form (BNF) as described in RFC-2234 [6]. 1242 msrp-req-or-resp = msrp-request / msrp-response 1243 msrp-request = req-start headers [content-stuff] end-line 1244 msrp-response = resp-start headers end-line 1246 req-start = pMSRP SP transact-id SP method CRLF 1247 resp-start = pMSRP SP transact-id SP status-code [SP phrase] CRLF 1248 phrase = utf8text 1250 pMSRP = %x4D.53.52.50 ; MSRP in caps 1251 transact-id = ident 1252 method = mSEND / mREPORT / other-method 1253 mSEND = %53.45.4e.44 ; SEND in caps 1254 mREPORT = %52.45.50.4f.52.54; REPORT in caps 1256 other-method = 1*UPALPHA 1257 status-code = 3DIGIT 1259 headers = 1*( header CRLF ) 1261 header = ( To-Path 1262 / From-Path 1263 / Message-ID 1264 / Report-Success 1265 / Report-Failure 1266 / Byte-Range 1267 / Status 1268 / ext-header ) 1270 To-Path = "To-Path:" SP URL *( SP URL ) 1271 From-Path = "From-Path:" SP URL *( SP URL ) 1272 Message-ID = "Message-ID:" SP ident 1273 Report-Success = "Report-Success:" SP ("yes" / "no" ) 1274 Report-Failure = "Report-Failure:" SP ("yes" / "no" / "partial" ) 1275 Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total 1276 range-start = 1*DIGIT 1277 range-end = 1*DIGIT / "*" 1278 total = 1*DIGIT / "*" 1279 dUmMy= "Status:" SP namespace SP short-status [SP text-reason] 1281 ident = alphanum 3*31ident-char 1282 ident-char = alphanum / "." / "-" / "+" / "%" / "=" 1284 content-stuff = *(Other-Mime-Header CRLF) 1285 Content-Type 2CRLF data CRLF 1287 Content-Type = "Content-Type:" SP media-type 1288 media-type = type "/" subtype *( ";" gen-param ) 1289 type = token 1290 subtype = token 1292 gen-param = pname [ "=" pval ] 1293 pname = token 1294 pval = token / quoted-string 1296 token = 1*(%x21 / %xx23-27 / %x2A-2B / %x2D-2E 1297 / %x30-39 / %x41-5A / %x5E-7E) 1299 quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE 1300 qdtext = SP / HT / %x21 / %x23-5B / %x5D-7E 1301 / UTF8-NONASCII 1302 qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) 1303 BACKSLASH = "\" 1304 DQUOTE = %x22 1305 CRLF = %x0D.0A 1306 HT = %x09 1307 SP = %x20 1308 UPALPHA = %x41-5A 1309 LOWALPHA = %x61-7A 1310 DIGIT = %x30-39 1311 ALPHANUM = LOWALPHA / UPALPHA / DIGIT 1313 Other-Mime-Header = (Content-ID 1314 / Content-Description 1315 / Content-Disposition 1316 / mime-extension-field); 1317 ; Content-ID, and Content-Description are defined in RFC2045. 1318 ; Content-Disposition is defined in RFC2183 1319 ; MIME-extension-field indicates additional MIME extension 1320 ; headers as described in RFC2045 1322 data = *OCTET 1323 end-line = "-------" transact-id continuation-flag CRLF 1324 continuation-flag = "+" / "$" / "#" 1326 ext-header = hname ":" SP hval CRLF 1327 hname = alpha *token 1328 hval = utf8text 1330 utf8text = *(HT / %x20-7E / UTF8-NONASCII) 1332 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 1333 / %xE0-EF 2UTF8-CONT 1334 / %xF0-F7 3UTF8-CONT 1335 / %xF8-Fb 4UTF8-CONT 1336 / %xFC-FD 5UTF8-CONT 1337 UTF8-CONT = %x80-BF 1339 9. Response Code Descriptions 1341 This section summarizes the semantics of various response codes that 1342 may be used in MSRP transaction responses. These codes may also be 1343 used in the Status header in REPORT requests. 1345 9.1 200 1347 The 200 response code indicates a successful transaction. 1349 9.2 400 1351 A 400 response indicates a request was unintelligible. 1353 9.3 403 1355 The action is not allowed 1357 9.4 415 1359 A 415 response indicates the SEND request contained a MIME 1360 content-type that is not understood by the receiver. 1362 9.5 426 1364 A 426 response indicates that the request is only allowed over TLS 1365 protected connections. 1367 9.6 481 1369 A 481 response indicates that no session exists for the connection. 1371 9.7 506 1373 A 506 response indicates that a request arrived on a session which is 1374 already bound to another network connection. 1376 10. Examples 1378 10.1 Basic IM session 1380 This section shows an example flow for the most common scenario. The 1381 example assumes SIP is used to transport the SDP exchange. Details 1382 of the SIP messages and SIP proxy infrastructure are omitted for the 1383 sake of brevity. In the example, assume the offerer is 1384 sip:alice@example.com and the answerer is sip:bob@example.com. 1386 Alice Bob 1387 | | 1388 | | 1389 |(1) (SIP) INVITE | 1390 |----------------------->| 1391 |(2) (SIP) 200 OK | 1392 |<-----------------------| 1393 |(3) (SIP) ACK | 1394 |----------------------->| 1395 |(4) (MSRP) SEND | 1396 |----------------------->| 1397 |(5) (MSRP) 200 OK | 1398 |<-----------------------| 1399 |(6) (MSRP) SEND | 1400 |<-----------------------| 1401 |(7) (MSRP) 200 OK | 1402 |----------------------->| 1403 |(8) (SIP) BYE | 1404 |----------------------->| 1405 |(9) (SIP) 200 OK | 1406 |<-----------------------| 1407 | | 1408 | | 1410 1. Alice constructs a local URL of 1411 msrp://alicepc.example.com:7777/iau39;tcp . 1413 Alice->Bob (SIP): INVITE sip:bob@example.com 1415 v=0 1416 o=alice 2890844557 2890844559 IN IP4 alicepc.example.com 1417 s= 1418 c=IN IP4 alicepc.example.com 1419 t=0 0 1420 m=message 9 msrp * 1421 a=accept-types:text/plain 1422 a=path:msrp://alicepc.example.com:7777/iau39;tcp 1424 2. Bob listens on port 8888, and sends the following response: 1426 Bob->Alice (SIP): 200 OK 1428 v=0 1429 o=bob 2890844612 2890844616 IN IP4 bob.example.com 1430 s= 1431 c=IN IP4 bob.example.com 1432 t=0 0 1433 m=message 9 msrp * 1434 a=accept-types:text/plain 1435 a=path:msrp://bob.example.com:8888/9di4ea;tcp 1437 3. Alice->Bob (SIP): ACK 1439 4. (Alice opens connection to Bob.) Alice->Bob (MSRP): 1441 MSRP d93kswow SEND 1442 To-Path:msrp://bob.example.com:8888/9di4ea;tcp 1443 From-Path:msrp://alicepc.example.com:7777/iau39;tcp 1444 Message-ID: 12339sdqwer 1445 Content-Type:text/plain 1446 Hi, I'm Alice! 1447 -------d93kswow$ 1449 5. Bob->Alice (MSRP): 1451 MSRP d93kswow 200 OK 1452 To-Path:msrp://bob.example.com:8888/9di4ea;tcp 1453 From-Path:msrp://alicepc.example.com:7777/iau39;tcp 1454 -------d93kswow$ 1456 6. Bob->Alice (MSRP): 1458 MSRP dkei38sd SEND 1459 To-Path:msrp://alice.example.com:7777/iau39;tcp 1460 From-Path:msrp://bob.example.com:8888/9di4ea;tcp 1461 Message-ID: 456 1462 Content-Type:text/plain 1463 Hi, Alice! I'm Bob! 1464 -------dkei38sd$ 1466 7. Alice->Bob (MSRP): 1468 MSRP dkei38sd 200 OK 1469 To-Path:msrp://alice.example.com:7777/iau39;tcp 1470 From-Path:msrp://bob.example.com:8888/9di4ea;tcp 1471 -------dkei38sd$ 1473 8. Alice->Bob (SIP): BYE 1475 Alice invalidates local session state. 1477 9. Bob invalidates local state for the session. 1479 Bob->Alice (SIP): 200 OK 1481 10.2 Chunked Message 1483 For an example of a chunked message, see the example in Section 4.1. 1485 10.3 System Message 1487 Sysadmin->Alice (MSRP): 1489 MSRP d93kswow SEND 1490 To-Path:msrp://alicepc.example.com:8888/9di4ea;tcp 1491 From-Path:msrp://example.com:7777/iau39;tcp 1492 Message-ID: 12339sdqwer 1493 Report-Failure: no 1494 Report-Success: no 1495 Content-Type:text/plain 1496 This conference will end in 5 minutes 1497 -------d93kswow$ 1499 10.4 Positive Report 1501 Alice->Bob (MSRP): 1503 MSRP d93kswow SEND 1504 To-Path:msrp://bob.example.com:8888/9di4ea;tcp 1505 From-Path:msrp://alicepc.example.com:7777/iau39;tcp 1506 Message-ID: 12339sdqwer 1507 Report-Success: yes 1508 Content-Type:text/html 1510 1511

Here is that important link... 1512 foobar 1513

1514 1515 -------d93kswow$ 1517 Bob->Alice (MSRP): 1519 MSRP d93kswow 200 OK 1520 To-Path:msrp://alicepc.example.com:7777/iau39;tcp 1521 From-Path:msrp://bob.example.com:8888/9di4ea;tcp 1522 -------d93kswow$ 1524 Bob->Alice (MSRP): 1526 MSRP dkei38sd REPORT 1527 To-Path:msrp://alicepc.example.com:7777/iau39;tcp 1528 From-Path:msrp://bob.example.com:8888/9di4ea;tcp 1529 Message-ID: 12339sdqwer 1530 Status: 000 200 OK 1531 -------dkei38sd$ 1533 10.5 Forked IM 1535 Traditional IM systems generally do a poor job of handling multiple 1536 simultaneous IM clients online for the same person. While some do a 1537 better job than many existing systems, handling of multiple clients 1538 is fairly crude. This becomes a much more significant issue when 1539 always-on mobile devices are available, but when it is desirable to 1540 use them only if another IM client is not available. 1542 Using SIP makes rendezvous decisions explicit, deterministic, and 1543 very flexible; instead "pager-mode" IM systems use implicit 1544 implementation-specific decisions which IM clients cannot influence. 1546 With SIP session mode messaging rendezvous decisions can be under 1547 control of the client in a predictable, interoperable way for any 1548 host that implements callee capabilities [30]. As a result, 1549 rendezvous policy is managed consistently for each address of record. 1551 The following example shows Juliet with several IM clients where she 1552 can be reached. Each of these has a unique SIP Contact and MSRP 1553 session. The example takes advantage of SIP's capability to "fork" 1554 an invitation to several Contacts in parallel, in sequence, or in 1555 combination. Juliet has registered from her chamber, the balcony, 1556 her PDA, and as a last resort, you can leave a message with her 1557 Nurse. Juliet's contacts are listed below. The q-values express 1558 relative preference (q=1.0 is the highest preference). 1560 We query for a list of Juliet's contacts by sending a REGISTER: 1562 REGISTER sip:thecapulets.example.com SIP/2.0 1563 To: Juliet 1564 From: Juliet ;tag=12345 1565 Call-ID: 09887877 1566 CSeq: 772 REGISTER 1568 The Response contains her Contacts: 1570 SIP/2.0 200 OK 1571 To: Juliet 1572 From: Juliet ;tag=12345 1573 Call-ID: 09887877 1574 CSeq: 772 REGISTER 1575 Contact: 1576 ;q=0.9;expires=3600 1577 Contact: 1578 ;q=1.0;expires=3600 1579 Contact: ;q=0.4;expires=3600 1580 Contact: ;q=0.1;expires=3600 1582 When Romeo opens his IM program, he selects Juliet and types the 1583 message "art thou hither?" (instead of "you there?"). His client 1584 sends a SIP invitation to sip:juliet@thecapulets.example.com. The 1585 Proxy there tries first the balcony and the chamber simultaneously. 1586 A client is running on both those systems, both of which setup early 1587 sessions of MSRP with Romeo's client. The client automatically sends 1588 the message over the MSRPS to the two MSRP URIs involved. After a 1589 delay of a several seconds with no reply or activity from Juliet, the 1590 proxy cancels the invitation at her first two contacts, and forwards 1591 the invitation on to Juliet's PDA. Since her father is talking to 1592 her about her wedding, she selects "Do Not Disturb" on her PDA, which 1593 sends a "Busy Here" response. The proxy then tries the Nurse, who 1594 answers and tells Romeo what is going on. 1596 Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse 1597 Proxy balcony chamber PDA 1599 | | | | | | 1600 |--INVITE--->| | | | | 1601 | |--INVITE--->| | | | 1602 | |<----180----| | | | 1603 |<----180----| | | | | 1604 |---PRACK---------------->| | | | 1605 |<----200-----------------| | | | 1606 |<===Early MSRP Session==>| art thou hither? | | 1607 | | | | | | 1608 | |--INVITE---------------->| | | 1609 | |<----180-----------------| | | 1610 |<----180----| | | | | 1611 |---PRACK----------------------------->| | | 1612 |<----200------------------------------| | | 1613 |<========Early MSRP Session==========>| art thou hither? | 1614 | | | | | | 1615 | | | | | | 1616 | | .... Time Passes .... | | | 1617 | | | | | | 1618 | | | | | | 1619 | |--CANCEL--->| | | | 1620 | |<---200-----| | | | 1621 | |<---487-----| | | | 1622 | |----ACK---->| | | | 1623 | |--CANCEL---------------->| | | 1624 | |<---200------------------| | | 1625 | |<---487------------------| | | 1626 | |----ACK----------------->| | | 1627 | |--INVITE---------------------------->| romeo wants 1628 | | | | | to IM w/ you 1629 | |<---486 Busy Here--------------------| | 1630 | |----ACK----------------------------->| | 1631 | | | | | | 1632 | |--INVITE---------------------------------------->| 1633 | |<---200 OK---------------------------------------| 1634 |<--200 OK---| | | | | 1635 |---ACK------------------------------------------------------->| 1636 |<================MSRP Session================================>| 1637 | | | | | | 1638 | Hi Romeo, Juliet is | 1639 | with her father now | 1640 | can i take a message?| 1641 | | 1642 | Tell her to go to confession tommorrow.... | 1644 11. Extensibility 1646 MSRP was designed to be only minimally extensible. New MSRP Methods, 1647 Headers, and status codes can be defined in standards track RFCs. 1648 There is no registry of headers, methods, or status codes, since the 1649 number of new elements and total extensions is expected to be very 1650 small. MSRP does not contain a version number or any negotiation 1651 mechanism to require or discover new features. If a 1652 non-interoperable update or extension occurs in the future, it will 1653 be treated as a new protocol, and must describe how its use will be 1654 signaled. 1656 In order to allow extension header fields without breaking 1657 interoperablility, if an MSRP device receives a request or response 1658 containing a header field that it does not understand, it MUST ignore 1659 the header field and process the request or response as if the header 1660 field was not present. 1662 MSRP was designed to use lists of URLs instead of a single URL in the 1663 To-Path and From-Path headers in anticipation of relay or gateway 1664 functionality being added. In addition, msrp: and msrps: URLs can 1665 contain parameters which are extensible. 1667 12. CPIM compatibility 1669 MSRP sessions may be gatewayed to other CPIM [25]compatible 1670 protocols. If this occurs, the gateway MUST maintain session state, 1671 and MUST translate between the MSRP session semantics and CPIM 1672 semantics that do not include a concept of sessions. Furthermore, 1673 when one endpoint of the session is a CPIM gateway, instant messages 1674 SHOULD be wrapped in "message/cpim" [7] bodies. Such a gateway MUST 1675 include "message/cpim" as the first entry in its SDP accept-types 1676 attribute. MSRP endpoints sending instant messages to a peer that 1677 has included 'message/cpim" as the first entry in the accept-types 1678 attribute SHOULD encapsulate all instant message bodies in "message/ 1679 cpim" wrappers. All MSRP endpoints MUST support the message/cpim 1680 type, and SHOULD support the S/MIME features of that format. 1682 If a message is to be wrapped in a message/cpim envelope, the 1683 wrapping MUST be done prior to breaking the message into chuncks, if 1684 needed. 1686 13. Security Considerations 1688 Instant Messaging systems are used to exchange a variety of sensitive 1689 information ranging from personal conversations, to corporate 1690 confidential information, to account numbers and other financial 1691 trading information. IM is used by individuals, corporations, and 1692 governments for communicating important information. Like many 1693 communications systems, the properties of Integrity and 1694 Confidentiality of the exchanged information, along with the 1695 possibility of Anonymous communications, and knowing you are 1696 communicating with the correct other party are required. MSRP pushes 1697 many of the hard problems to SIP when SIP sets up the session, but 1698 some of the problems remain. Spam and DoS attacks are also very 1699 relevant to IM systems. 1701 MSRP needs to provide confidentiality and integrity for the messages 1702 it transfers. It also needs to provide assurances the connected host 1703 is the host that it meant to connect to and that the connection has 1704 not been hijacked. 1706 When using only TCP connections, MSRP security is fairly weak. If 1707 host A is contacting B, B passes its hostname and a secret to A using 1708 SIP. If the SIP offer or answer is not TLS or S/MIME [27] protected, 1709 anyone can see this secret. A then connects to the provided host 1710 name and passes the secret in the clear across the connection to B. 1711 A assumes that it is talking to B based on where it sent the SYN 1712 packet and then delivers the secret in plain text across the 1713 connections. B assumes it is talking to A because the host on the 1714 other end of the connection delivered the secret. An attacker that 1715 could ACK the SYN packet could insert itself as a man in the middle 1716 in the connection. 1718 When using TLS connections, the security is significantly improved. 1719 We assume that the host accepting the connection has a certificate 1720 from a well know certificate authority. Furthermore, we assume that 1721 the SIP signaling to set up the session is protected with TLS (using 1722 sips). In this case, when host A contacts host B, the secret is 1723 passed through a SIP confidential channel to A. A connects with TLS 1724 to B. B presents a valid certificate, so A knows it really is 1725 connected to B. A then delivers the secret provided by B, so that B 1726 can verify it is connected to A. In this case, a rogue SIP Proxy can 1727 see the secret in the SIP signaling traffic and could potentially 1728 insert itself as a man-in-the-middle. 1730 Realistically, using TLS is only feasible when connecting to gateways 1731 or relays , as the types of hosts that end clients use for sending 1732 instant messages are unlikely to have a long term stable IP address 1733 or a stable DNS name that a certificate can bind to. In addition, 1734 the cost of server certificates from well known certificate 1735 authorities is currently too high for the vast majority of end users 1736 to even consider getting one for each client. 1738 The only real security for connections without relays is achieved 1739 using S/MIME. This does not require the actual endpoint to have 1740 certificates from a well known certificate authority. The Identity 1741 [22] and Certificates [23] mechanism with SIP provides S/MIME based 1742 delivery of a secret between A and B. No SIP intermediary except the 1743 explicitly trusted authentication service (one per user) can see the 1744 secret. The S/MIME encryption of the SDP can also be used by SIP to 1745 exchange keying material that can be used in MRSP. The MSRP session 1746 can then use S/MIME with this keying material to encrypt and sign 1747 messages sent over MSRP. The connection can still be hijacked since 1748 the secret is sent in clear text to the other end of the TCP 1749 connection, but this risk is mitigated if all the MSRP content is 1750 encrypted and signed with S/MIME. 1752 MSRP can not be used as an amplifier for DoS attacks, but it can be 1753 used to form a distributed attack to consume TCP connection resource 1754 on servers. The attacker, Eve, sends an SIP INVITE with no offer to 1755 Alice. Alice returns a 200 with an offer and Eve returns an answer 1756 with the SDP that indicates that her MSRP address is the address of 1757 Tom. Since Alice sent the offer, Alice will initiate a connection to 1758 Tom using up resources on Tom's server. Given the huge number of IM 1759 clients, and the relatively few TCP connections that most servers 1760 support, this is a fairly straightforward attack. 1762 SIP is attempting to address issues in dealing with spam. The spam 1763 issue is probably best dealt with at the SIP level when an MSRP 1764 session is initiated and not at the MSRP level. 1766 TLS is used to authenticate devices and to provide integrity and 1767 confidentiality for the headers being transported. MSRP elements 1768 MUST implement TLS and MUST also implement the TLS 1769 ClientExtendedHello extended hello information for server name 1770 indication as described in [11]. A TLS cipher-suite of 1771 TLS_RSA_WITH_AES_128_CBC_SHA [14] MUST be supported (other 1772 cipher-suites MAY also be supported). 1774 Since MSRP carries arbitrary MIME content, it can trivially carry S/ 1775 MIME protected messages as well. All MSRP implementations MUST 1776 support the multipart/signed MIME type even if they do not support S/ 1777 MIME. Since SIP can carry a session key, S/MIME messages in the 1778 context of a session could also be protected using a key-wrapped 1779 shared secret [26] provided in the session setup. 1781 If a sender chooses to employ S/MIME to protect a message, all S/MIME 1782 operations MUST occur prior to breaking the message into chunks, if 1783 needed. 1785 14. IANA Considerations 1787 14.1 MSRP Port 1789 MSRP uses TCP port XYX, to be determined by IANA after this document 1790 is approved for publication. Usage of this value is described in 1791 Section 5 1793 14.2 MSRP URL Schemes 1795 This document defines the URL schemes of "msrp" and "msrps". 1797 Syntax See Section 5. 1798 Character Encoding See Section 5. 1799 Intended Usage See Section 5. 1800 Protocols The Message Session Relay Protocol (MSRP). 1801 Security Considerations See Section 13. 1802 Relevant Publications RFCXXXX 1803 [Note to RFC Editor: Please replace RFCXXXX in the above 1804 paragraph with the actual number assigned to this document. 1806 14.3 SDP Parameters 1808 This document registers the following SDP parameters in the 1809 sdp-parameters registry: 1811 14.3.1 Accept Types 1813 Attribute-name: accept-types 1814 Long-form Attribute Name Acceptable MIME Types 1815 Type: Media level 1816 Subject to Charset Attribute No 1817 Purpose and Appropriate Values See Section 7.1. 1819 14.3.2 Wrapped Types 1821 Attribute-name: accept-wrapped-types 1822 Long-form Attribute Name Acceptable MIME Types Inside Wrappers 1823 Type: Media level 1824 Subject to Charset Attribute No 1825 Purpose and Appropriate Values See Section 7.1. 1827 14.3.3 Max Size 1829 Attribute-name: max-size 1830 Long-form Attribute Name Maximum message size. 1831 Type: Media level 1832 Subject to Charset Attribute No 1833 Purpose and Appropriate Values See Section 7.1. 1835 14.3.4 Path 1837 Attribute-name: path 1838 Long-form Attribute Name MSRP URL Path 1839 Type: Media level 1840 Subject to Charset Attribute No 1841 Purpose and Appropriate Values See Section 7.1.1. 1843 15. Change History 1845 15.1 draft-ietf-simple-message-sessions-08 1847 Removed DSN section. Removed statements that an error report 1848 SHOULD contain a body. REPORT requests may now contain 1849 informational bodies no larger than 2K, but the recipient is free 1850 to ignore them. 1851 Added the "#" value for the continuation-flag to indicate the last 1852 chunk of an abandoned message. 1853 Added direction that s/mime and cpim envelops must be applied 1854 before chunking. 1855 Added direction to set the last-byte field in byte-range to "*" if 1856 there is any chance of interrupting a SEND request. 1857 Changed max-size to refer to entire message, instead of a 1858 particular MIME content-type 1859 Added requirent for the use of UTF-8, and reference to RFC3629 1860 Added requrement to ignore unknown headers. 1861 Several ABNF fixes 1862 Removed redundant material between normative sections. 1863 Numerous editorial fixes. 1865 15.2 draft-ietf-simple-message-sessions-07 1867 Significant re-write to attempt to improve readability. 1868 Added maximum size parameter in accept-types 1869 Changed the Boundary field to be part of the start-line rather 1870 than a header field. 1871 Removed the TR-IDheader, and changed request-response matching to 1872 be based on the Boundary field value. Responses still contain the 1873 TR-ID header, which must match the Boundary from the request. 1875 Removed transport selection from URL scheme and added the "tcp" 1876 parameter. 1877 Added description of the "simple" mode with no transaction 1878 responses, and made mode selection dependent on the reporting 1879 level requested for a give message. 1880 Changed the DSN section to reflect separate request of success and 1881 failure reports. Enhanced REPORT method to be useful even without 1882 a payload. 1883 removed SRV usage for URL resolution. This is only used for relay 1884 discovery, and therefore should be moved to the relay draft. 1885 Added discussion about late REPORT handling. Asserted that REPORT 1886 requests are always sent in simple mode. 1887 Removed the dependency on multipart/byteranges for fragmentation. 1888 Incorporated the Byte-Range header into the base MSRP header set. 1889 Removed the VISIT method. Change to use SEND to serve the purpose 1890 formerly reserved to VISIT. 1892 15.3 draft-ietf-simple-message-sessions-06 1894 Changed To and From header names to To-Path and From-Path. Added 1895 more clarification to path handling, and commentary on how it 1896 enables relay usage. 1897 Changed mechanism for signaling transport and TLS protection into 1898 the MSRP URL, rather than the SDP M-Line. 1899 Removed length field from start line and added Boundary header 1900 field and Closing field. 1901 Added recommendation to fragment any content over 2k. 1902 Added Rohan's proposal to make offerer connect to answerer. (With 1903 open issue for more discussion.) 1904 Changed To-Path and From-Path usage in responses to indicate the 1905 destination and source of the response, rather than merely copy 1906 from the associated request. 1907 Updated DSN section. Added text on field usage. 1908 Fixed change TR-ID header from version 05 were erroneously 1909 attributed to 04. 1911 15.4 draft-ietf-simple-message-sessions-05 1913 Changed the use of session URLs. Instead of a single session URL, 1914 each endpoint is identified by a distinct URL. MSRP requests will 1915 put the destination URL in a To header, and the sender URL in a 1916 From header. 1917 Changed the SDP exchange of MSRP URLs to handle the URL for each 1918 endpoint. Further, changed the SDP attribute to support a list of 1919 URLs in each direction. This may be used with relays to exchange 1920 paths, rather than single URLs. MSRP endpoints must be able to 1921 intelligently process such a list if received. This document does 1922 not, however, describe how to generate such a list. 1924 Added section for Delivery Status Notification handling, and added 1925 associated entries into the syntax definition. 1926 Added content fragmentation section. 1927 Removed recommendation to start separate session for large 1928 transfers. 1929 Corrected some mistakes in the syntax definitions. 1930 Added Chris Boulton as a co-author for his contribution of the DSN 1931 text. 1933 15.5 draft-ietf-simple-message-sessions-04 1935 Removed the direction attribute. Rather than using a comedia 1936 styled direction negotiation, we just state that the answerer 1937 opens any needed connection. 1939 15.6 draft-ietf-simple-message-sessions-03 1941 Removed all specification of relays, and all features specific to 1942 the use of relays. The working group has chosen to move relay 1943 work into a separate effort, in order to advance the base 1944 specification. (The MSRP acronym is unchanged for the sake of 1945 convenience.) This included removal of the BIND method, all 1946 response codes specific to BIND, Digest Authentication, and the 1947 inactivity timeout. 1948 Removed text indicating that an endpoint could retry failed 1949 requests on the same connection. Rather, the endpoint should 1950 consider the connection dead, and either signal a reconnection or 1951 end the session. 1952 Added text describing subsequent SDP exchanges. Added mandatory 1953 "count" parameter to the direction attribute to allow explicit 1954 signaling of the need to reconnect. 1955 Added text to describe the use of send and receive only indicators 1956 in SDP for one-way transfer of large content. 1957 Added text requiring unique port field values if multiple M-line's 1958 exist. 1959 Corrected a number of editorial mistakes. 1961 15.7 draft-ietf-simple-message-sessions-02 1963 Moved all content type negotiation from the "m"-line format list 1964 into "a"-line attributes. Added the accept-types attribute. This 1965 is due to the fact that the sdp format-list syntax is not 1966 conducive to encoding MIME content types values. 1967 Added "other-method" construction to the message syntax to allow 1968 for extensible methods. 1969 Consolidated all syntax definitions into the same section. 1970 Cleaned up ABNF for digest challenge and response syntax. 1972 Changed the session inactivity timeout to 12 minutes. 1973 Required support for the SHA1 algorithm. 1974 Required support for the message/cpim format. 1975 Fixed lots of editorial issues. 1976 Documented a number of open issues from recent list discussions. 1978 15.8 draft-ietf-simple-message-sessions-01 1980 Abstract rewritten. 1981 Added architectural considerations section. 1982 The m-line format list now only describes the root body part for a 1983 request. Contained body part types may be described in the 1984 "accept-wrapped-types" a-line attribute. 1985 Added a standard dummy value for the m-line port field. Clarified 1986 that a zero in this field has normal SDP meaning. 1987 Clarified that an endpoint is globally configured as to whether or 1988 not to use a relay. There is no relay discovery mechanism 1989 intrinsic to MSRP. 1990 Changed digest algorithm to SHA1. Added TR-ID and S-URI to the 1991 hash for digest authentication. 1992 CMS usage replaced with S/MIME. 1993 TLS and msrps: usage clarified. 1994 Session state timeout is now based on SEND activity, rather than 1995 BIND and VISIT refreshes. 1996 Default port added. 1997 Added sequence diagrams to the example message flows. 1998 Added discussion of self-signed certificates in the security 1999 considerations section. 2001 15.9 draft-ietf-simple-message-sessions-00 2003 Name changed to reflect status as a work group item. 2004 This version no longer supports the use of multiple sessions 2005 across a single TCP session. This has several related changes: 2006 There is now a single session URI, rather than a separate one for 2007 each endpoint. The session URI is not required to be in requests 2008 other than BIND and VISIT, as the session can be determined based 2009 on the connection on which it arrives. 2010 BIND and VISIT now create soft state, eliminating the need for the 2011 RELEASE and LEAVE methods. 2012 The MSRP URL format was changed to better reflect generic URL 2013 standards. URL comparison and resolution rules were added. SRV 2014 usage added. 2015 Determination of host and visitor roles now uses a direction 2016 attribute much like the one used in COMEDIA. 2017 Format list negotiation expanded to allow a "prefer these formats 2018 but try anything" semantic 2019 Clarified handling of direction notification failures. 2020 Clarified signaling associated with session failure due to dropped 2021 connections. 2022 Clarified security related motivations for MSRP. 2023 Removed MIKEY dependency for session key exchange. Simple usage 2024 of k-lines in SDP, where the SDP exchange is protected end-to-end 2025 seems sufficient. 2027 15.10 draft-campbell-simple-im-sessions-01 2029 Version 01 is a significant re-write. References to COMEDIA were 2030 removed, as it was determined that COMEDIA would not allow 2031 connections to be used bidirectional in the presence of NATs. 2032 Significantly more discussion of a concrete mechanism has been added 2033 to make up for no longer using COMEDIA. Additionally, this draft and 2034 draft-campbell-cpimmsg-sessions (which would have also changed 2035 drastically) have now been combined into this single draft. 2037 16. Contributors and Acknowledgments 2039 In addition to the editors, The following people contributed 2040 extensive work to this document: Chris Boulton, Paul Kyzivat, Orit 2041 Levin, Adam Roach, Jonathan Rosenberg, and Robert Sparks. 2043 The following people contributed substantial discussion and feedback 2044 to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson, 2045 Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, 2046 and Orit Levin. 2048 17. References 2050 17.1 Normative References 2052 [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2053 2246, January 1999. 2055 [2] Handley, M. and V. Jacobson, "SDP: Session Description 2056 Protocol", RFC 2327, April 1998. 2058 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2059 Session Description Protocol (SDP)", RFC 3264, June 2002. 2061 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2062 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2063 Session Initiation Protocol", RFC 3261, June 2002. 2065 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2066 Levels", BCP 14, RFC 2119, March 1997. 2068 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2069 Specifications: ABNF", RFC 2234, November 1997. 2071 [7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging 2072 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in 2073 progress), January 2003. 2075 [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2076 Extensions (MIME) Part One: Format of Internet Message Bodies", 2077 RFC 2045, November 1996. 2079 [9] Troost, R., Dorner, S. and K. Moore, "Communicating 2080 Presentation Information in Internet Messages: The 2081 Content-Disposition Header Field", RFC 2183, August 1997. 2083 [10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2084 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2085 1998. 2087 [11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and 2088 T. Wright, "Transport Layer Security (TLS) Extensions", RFC 2089 3546, June 2003. 2091 [12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 2092 Method", RFC 3311, October 2002. 2094 [13] Atkins, D. and G. Klyne, "Common Presence and Instant 2095 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 2096 (work in progress), January 2003. 2098 [14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 2099 Transport Layer Secur ity (TLS)", RFC 3268, June 2002. 2101 [15] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2102 3269, November 2003. 2104 17.2 Informational References 2106 [16] Johnston, A. and O. Levin, "Session Initiation Protocol Call 2107 Control - Conferencing for User Agents", 2108 draft-ietf-sipping-cc-conferencing-03 (work in progress), 2109 February 2004. 2111 [17] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 2112 "Best Current Practices for Third Party Call Control in the 2113 Session Initiation Protocol", draft-ietf-sipping-3pcc-06 (work 2114 in progress), January 2004. 2116 [18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 2117 Control - Transfer", draft-ietf-sipping-cc-transfer-02 (work in 2118 progress), February 2004. 2120 [19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 2121 D. Gurle, "Session Initiation Protocol (SIP) Extension for 2122 Instant Messaging", RFC 3428, December 2002. 2124 [20] Mahy, R., "Benefits and Motivation for Session Mode Instant 2125 Messaging", draft-mahy-simple-why-session-mode-00 (work in 2126 progress), February 2004. 2128 [21] Mahy, R. and C. Jennings, "Relays for the Message Session Relay 2129 Protocol (MSRP)", draft-ietf-simple-msrp-relays-01.txt (work in 2130 progress), July 2004. 2132 [22] Peterson, J. and C. Jennings, "Enhancements for Authenticated 2133 Identity Management in the Session Initiation Protocol (SIP)", 2134 draft-ietf-sip-identity-02 (work in progress), May 2004. 2136 [23] Jennings, C. and J. Peterson, "Certificate Management Service 2137 for SIP", draft-jennings-sipping-certs-03 (work in progress), 2138 May 2004. 2140 [24] Yon, D., "Connection-Oriented Media Transport in SDP", 2141 draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 2142 2003. 2144 [25] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", 2145 draft-ietf-impp-im-04 (work in progress), August 2003. 2147 [26] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, 2148 December 2001. 2150 [27] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2151 2633, June 1999. 2153 [28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone 2154 Generation in the Session Initiation Protocol (SIP)", 2155 draft-ietf-sipping-early-media-02 (work in progress), June 2156 2004. 2158 [29] Saint-Andre, P., "Extensible Messaging and Presence Protocol 2159 (XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22 2160 (work in progress), April 2004. 2162 [30] Rosenberg, J., "Indicating User Agent Capabilities in the 2163 Session Initiation Protocol (SIP)", 2164 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 2166 Authors' Addresses 2168 Ben Campbell (editor) 2169 Estacado Systems 2171 EMail: ben@nostrum.com 2173 Rohan Mahy (editor) 2174 Cisco Systems, Inc. 2175 5617 Scotts Valley Drive, Suite 200 2176 Scotts Valley, CA 95066 2177 USA 2179 EMail: rohan@cisco.com 2181 Cullen Jennings (editor) 2182 Cisco Systems, Inc. 2183 170 West Tasman Dr. 2184 MS: SJC-21/2 2185 San Jose, CA 95134 2186 USA 2188 EMail: fluffy@cisco.com 2190 Intellectual Property Statement 2192 The IETF takes no position regarding the validity or scope of any 2193 Intellectual Property Rights or other rights that might be claimed to 2194 pertain to the implementation or use of the technology described in 2195 this document or the extent to which any license under such rights 2196 might or might not be available; nor does it represent that it has 2197 made any independent effort to identify any such rights. Information 2198 on the procedures with respect to rights in RFC documents can be 2199 found in BCP 78 and BCP 79. 2201 Copies of IPR disclosures made to the IETF Secretariat and any 2202 assurances of licenses to be made available, or the result of an 2203 attempt made to obtain a general license or permission for the use of 2204 such proprietary rights by implementers or users of this 2205 specification can be obtained from the IETF on-line IPR repository at 2206 http://www.ietf.org/ipr. 2208 The IETF invites any interested party to bring to its attention any 2209 copyrights, patents or patent applications, or other proprietary 2210 rights that may cover technology that may be required to implement 2211 this standard. Please address the information to the IETF at 2212 ietf-ipr@ietf.org. 2214 Disclaimer of Validity 2216 This document and the information contained herein are provided on an 2217 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2218 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2219 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2220 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2221 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2222 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2224 Copyright Statement 2226 Copyright (C) The Internet Society (2004). This document is subject 2227 to the rights, licenses and restrictions contained in BCP 78, and 2228 except as set forth therein, the authors retain all their rights. 2230 Acknowledgment 2232 Funding for the RFC Editor function is currently provided by the 2233 Internet Society.