idnits 2.17.1 draft-ietf-simple-message-sessions-07.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2309. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2325), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 49 longer pages, the longest (page 29) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 52 pages 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 343 has weird spacing: '...hich of multi...' == Line 605 has weird spacing: '... herein use t...' == Line 938 has weird spacing: '...ins one with ...' == Line 1115 has weird spacing: '...include expli...' == Line 1146 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 '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. == 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 [13]. 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. -- 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 (July 18, 2004) is 7222 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 2177, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2181, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 2239, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 2243, 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 1894 (ref. '8') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 2396 (ref. '11') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3546 (ref. '12') (Obsoleted by RFC 4366) -- Duplicate reference: draft-ietf-impp-cpim-msgfmt, mentioned in '14', was also mentioned in '7'. ** Obsolete normative reference: RFC 3268 (ref. '15') (Obsoleted by RFC 5246) == 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: 13 errors (**), 0 flaws (~~), 23 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE WG B. Campbell, Ed. 2 Internet-Draft 3 Expires: January 16, 2005 R. Mahy 4 C. Jennings 5 Cisco Systems, Inc. 6 July 18, 2004 8 The Message Session Relay Protocol 9 draft-ietf-simple-message-sessions-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 16, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes the Message Session Relay Protocol (MSRP), a 43 protocol for transmitting a series of related instant messages in the 44 context of a session. Message sessions are treated like any other 45 media stream when setup via a rendezvous or session setup protocol 46 such as the Session Initiation Protocol (SIP). 48 Table of Contents 50 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Introduction and Background . . . . . . . . . . . . . . . . 4 52 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5 53 4. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 8 54 4.1 MSRP Framing and Message Chunking . . . . . . . . . . . . 8 55 4.2 MSRP Addressing . . . . . . . . . . . . . . . . . . . . . 11 56 4.3 MSRP Transaction and Report Model . . . . . . . . . . . . 11 57 4.4 MSRP Connection Model . . . . . . . . . . . . . . . . . . 12 58 5. MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 14 59 5.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 15 60 5.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 16 61 6. Method-Specific Behavior . . . . . . . . . . . . . . . . . . 16 62 6.1 Constructing Requests . . . . . . . . . . . . . . . . . . 16 63 6.1.1 Delivering SEND requests . . . . . . . . . . . . . . . 17 64 6.1.2 Sending REPORT requests . . . . . . . . . . . . . . . 19 65 6.1.3 Failure REPORT Generation . . . . . . . . . . . . . . 19 66 6.2 Constructing Responses . . . . . . . . . . . . . . . . . . 20 67 6.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 21 68 6.3.1 Receiving SEND requests . . . . . . . . . . . . . . . 21 69 6.3.2 Receiving REPORT requests . . . . . . . . . . . . . . 22 70 7. Using MSRP with SIP . . . . . . . . . . . . . . . . . . . . 22 71 7.1 SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 22 72 7.1.1 URL Negotiations . . . . . . . . . . . . . . . . . . . 25 73 7.1.2 Path Attributes with Multiple URLs . . . . . . . . . . 26 74 7.1.3 Updated SDP Offers . . . . . . . . . . . . . . . . . . 27 75 7.1.4 Example SDP Exchange . . . . . . . . . . . . . . . . . 27 76 7.1.5 Connection Negotiation . . . . . . . . . . . . . . . . 28 77 7.2 MSRP User Experience with SIP . . . . . . . . . . . . . . 28 78 8. DSN payloads in MSRP REPORT Requests . . . . . . . . . . . . 28 79 8.1 Per-Message DSN header usage . . . . . . . . . . . . . . . 28 80 8.2 Per-Recipient DSN header usage . . . . . . . . . . . . . . 29 81 8.3 original-envelope-id usage . . . . . . . . . . . . . . . . 29 82 8.4 reporting-mta . . . . . . . . . . . . . . . . . . . . . . 29 83 8.5 final-recipient . . . . . . . . . . . . . . . . . . . . . 29 84 8.6 action . . . . . . . . . . . . . . . . . . . . . . . . . . 30 85 8.7 status . . . . . . . . . . . . . . . . . . . . . . . . . . 30 86 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 30 87 10. Response Code Descriptions . . . . . . . . . . . . . . . . . 32 88 10.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 89 10.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 90 10.3 403 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 10.4 415 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 92 10.5 426 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 93 10.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 94 10.7 506 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 95 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 96 11.1 Basic IM session . . . . . . . . . . . . . . . . . . . . 33 97 11.2 Chunked Message . . . . . . . . . . . . . . . . . . . . 36 98 11.3 System Message . . . . . . . . . . . . . . . . . . . . . 36 99 11.4 Positive Report . . . . . . . . . . . . . . . . . . . . 37 100 11.5 Forked IM . . . . . . . . . . . . . . . . . . . . . . . 37 101 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 40 102 13. CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 40 103 14. Security Considerations . . . . . . . . . . . . . . . . . . 40 104 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 105 15.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . 42 106 15.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . 42 107 15.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . 43 108 15.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . 43 109 15.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . 43 110 15.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . 43 111 15.4 IANA registration forms for DSN types . . . . . . . . . 43 112 15.4.1 IANA registration form for address-type . . . . . . 43 113 15.4.2 IANA registration form for MTA-name-type . . . . . . 44 114 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 44 115 16.1 draft-ietf-simple-message-sessions-07 . . . . . . . . . 44 116 16.2 draft-ietf-simple-message-sessions-06 . . . . . . . . . 44 117 16.3 draft-ietf-simple-message-sessions-05 . . . . . . . . . 45 118 16.4 draft-ietf-simple-message-sessions-04 . . . . . . . . . 45 119 16.5 draft-ietf-simple-message-sessions-03 . . . . . . . . . 45 120 16.6 draft-ietf-simple-message-sessions-02 . . . . . . . . . 46 121 16.7 draft-ietf-simple-message-sessions-01 . . . . . . . . . 46 122 16.8 draft-ietf-simple-message-sessions-00 . . . . . . . . . 47 123 16.9 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 47 124 17. Contributors and Acknowledgments . . . . . . . . . . . . . . 47 125 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 126 18.1 Normative References . . . . . . . . . . . . . . . . . . . 48 127 18.2 Informational References . . . . . . . . . . . . . . . . . 49 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 50 129 Intellectual Property and Copyright Statements . . . . . . . 52 131 1. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC-2119 [5]. 137 This document consistently refers to a "message" as a complete unit 138 of MIME or text content. In some cases a message is split and 139 delivered in more than one MSRP request. Each of these portions of 140 the complete message is called a "chunk". 142 2. Introduction and Background 144 A series of related textual messages between two or more parties can 145 be viewed as part of a session with a definite start and end. This 146 is in contrast to individual messages each sent completely 147 independently. The SIMPLE Working Group describes messaging schemes 148 that only track individual messages as "page-mode" messages, whereas 149 messaging that is part of a "session" with a definite start and end 150 is called session-mode messaging. 152 Page-mode messaging is enabled in SIMPLE via the SIP [4]MESSAGE 153 method [19]. Session-mode messaging has a number of benefits [20] 154 over page-mode messaging however, such as explicit rendezvous, 155 tighter integration with other media types, direct client-to-client 156 operation, and brokered privacy and security. 158 This document defines a session-oriented instant message transport 159 protocol (MSRP), whose sessions can be included in an offer or answer 160 [3] of a session description (for example, SDP [2]). The exchange is 161 carried by some signaling protocol, such as SIP [4]. This allows a 162 communication user agent to offer a messaging session as one of the 163 possible media types in a session. For instance, Alice may want to 164 communicate with Bob. Alice doesn't know at the moment whether Bob 165 has his phone or his IM client handy, but she's willing to use 166 either. She sends an invitation to a session to the address of 167 record she has for Bob, sip:bob@example.com. Her invitation offers 168 both voice and an IM session. The SIP services at example.com 169 forward the invitation to Bob at his currently registered clients. 170 Bob accepts the invitation at his IM client and they begin a threaded 171 chat conversation. 173 This session model allows message sessions to be integrated into 174 advanced communications applications with little to no additional 175 protocol development. For example, during the above chat session, 176 Bob decides Alice really needs to be talking to Carol. Bob can 177 transfer [18] Alice to Carol, introducing them into their own 178 messaging session. Messaging sessions can then be easily integrated 179 into call-center and dispatch environments utilizing third-party call 180 control [17] and conferencing [16] applications. 182 3. Protocol Overview 184 MSRP is a text-based, connection-oriented protocol for exchanging 185 arbitrary (binary) MIME content, especially instant messages. This 186 section is a non-normative overview of how MSRP works and how it is 187 used with SIP. 189 MSRP sessions are typically arranged using SIP the same way a session 190 of audio or video media is setup. One SIP user agent (Alice) sends 191 the other (Bob) a SIP invitation containing an offer 192 session-description which includes a session of MSRP. The receiving 193 SIP user agent can accept the invitation and include an answer 194 session-description which acknowledges the choice of media. Alice's 195 session description contains an MSRP URL that describes where she is 196 willing to receive MSRP requests from Bob, and vice-versa. (Note: 197 Some lines in the examples are removed for clarity and brevity.) 198 Alice sends to Bob: 200 INVITE sip:alice@atlanta.example.com SIP/2.0 201 To: 202 From: ;tag=786 203 Call-ID: 3413an89KU 204 Content-Type: application/sdp 206 c=IN IP4 10.1.1.1 207 m=message 9 msrp * 208 a=accept-types:text/plain 209 a=path:msrp://atlanta.example.com:7654/jshA7we;tcp 211 Bob sends to Alice: 213 SIP/2.0 200 OK 214 To: ;tag=087js 215 From: ;tag=786 216 Call-ID: 3413an89KU 217 Content-Type: application/sdp 219 c=IN IP4 10.2.2.2 220 m=message 9 msrp * 221 a=accept-types:text/plain 222 a=path:msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 224 Alice sends to Bob: 226 ACK sip:alice@atlanta.example.com SIP/2.0 227 To: ;tag=087js 228 From: ;tag=786 229 Call-ID: 3413an89KU 231 MSRP defines two request types, or methods. SEND requests are used 232 to deliver a complete message or a chunk (a portion of a complete 233 message), while REPORT requests report on the status of an earlier 234 SEND request. When Alice receives Bob's answer, she checks to see if 235 she has an existing connection to Bob. If not, she opens a new 236 connection to Bob using the URL he provided in the SDP. Alice then 237 delivers a SEND request to Bob with her initial message, and Bob 238 replies indicating that Alice's request was received successfully. 240 MSRP a786hjs2 SEND 241 To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 242 From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp 243 Message-ID: 87652 244 Content-Type: text/plain 246 Hey Bob, are you there? 247 -------a786hjs2$ 249 MSRP a786hjs2 200 OK 250 To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp 251 From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 252 Message-ID: 87652 253 -------a786hjs2$ 255 Alice's request begins with the MSRP start line, which contains a 256 transaction identifier that is also used as a final boundary marker. 257 Next she includes the path of URLs to the destination in the To-Path 258 header, and her own URL in the From-Path header. In this typical 259 case there is just one "hop", so there is only one URL in each path 260 header field. She also includes a message ID which she can use to 261 correlate responses and status reports with the original message. 262 Next she puts the actual content. Finally she closes the request 263 with an end line: seven hyphens, the transaction identifier / 264 boundary marker and a "$" to indicate this request contains the end 265 of a complete message. 267 If Alice wants to deliver a very large message, she can split the 268 message into chunks and deliver each chunk in a separate SEND 269 request. The message ID corresponds to the whole message, so the 270 receiver can also use it to reassemble the message and tell which 271 chunks belong with which message. Chunking is described in more 272 detail in Section 4.1. 274 Alice can also specify what type of reporting she would like in 275 response to her request. If Alice requests positive 276 acknowledgements, Bob sends a REPORT request to Alice confirming the 277 delivery of her complete message. This is especially useful if Alice 278 sent a series of SEND request containing chunks of a single message. 279 More on requesting types of reports and errors is described in 280 Section 4.3. 282 Alice and Bob generally choose their MSRP URLs in such a way that is 283 difficult to guess the exact URL. Alice and Bob can reject requests 284 to URLs they are not expecting to service, and can correlate the 285 specific URL with the probable sender. Alice and Bob can also use 286 TLS [1] to provide channel security over this hop. To receive MSRP 287 requests over a TLS protected connection, Alice or Bob could 288 advertise URLs with the "msrps" scheme instead of "msrp." 290 This document specifies MSRP behavior only peer-to-peer session, that 291 is, for a single hop. But is designed with the expectation that MSRP 292 can carry URLs for nodes on the far side of gateways or relays. For 293 this reason, a URL with the "msrps" scheme makes no assertion about 294 the security properties of other hops, just the next hop. 296 MSRP URLs are discussed in more detail in Section 5. 298 An adjacent pair of busy MSRP nodes (for example two gateways) can 299 easily have several sessions, and exchange traffic for several 300 simultaneous users. The nodes can use existing connections to carry 301 new traffic with the same destination host, port, transport protocol, 302 and scheme. MSRP nodes can keep track of how many sessions are using 303 a particular connection and close these connections when no sessions 304 have used them for some period of time. Connection management is 305 discussed in more detail in Section 4.4. 307 4. Key Concepts 309 4.1 MSRP Framing and Message Chunking 311 Messages sent using MSRP can be very large and can be delivered in 312 several SEND requests, where each SEND request contains one chunk of 313 the overall message. To support this, MSRP uses a boundary based 314 framing mechanism. The header of an MSRP request contains a unique 315 boundary string that is used to indicate the end of the request. 316 Following the boundary string at the end of the body data, there is a 317 flag that indicates whether this is the last chunk of data for this 318 message or whether the message will be continued in a subsequent 319 chunk. There is also a Byte-Range header in the request that 320 indicates the overall position of this chunk inside the complete 321 message. 323 For example, the following snippet of two SEND requests demonstrates 324 a message that contains the text "abcdEFGH" being sent as two chunks. 326 MSRP dkei38sd SEND 327 Message-ID: 456 328 Byte-Range: 1-4/8 329 Content-Type: "text/plain" 331 abcd 332 -------dkei38sd+ 334 MSRP dkei38ia SEND 335 Message-ID: 456 336 Byte-Range: 5-8/8 337 Content-Type: "text/plain" 339 EFGH 340 -------dkei38ia$ 342 The receiver uses the value of the Message-ID header to determine 343 which of multiple chunks belong to the same message. The Message-ID 344 header MUST have the same value for each chunk in the same message, 345 and a sender MUST ensure that the message ID is unique for each of 346 the messages it sends within a particular session. 348 The boundary marker that terminates the body MUST be preceded by a 349 CRLF that is not part of the body and then seven "-" (minus sign) 350 characters. After the boundary marker, there MUST be a flag 351 character that is either a "$" (for the last chunk of the message) or 352 "+" (for chunks other than the last). If the chunk represents the 353 data that forms the end of the message, the flag MUST be a "$", 354 otherwise the flag MUST be a "+". 356 The Byte-Range header value contains a starting value followed by a 357 "-", an ending value followed by a "/", and finally the total length. 358 The starting value indicates the index into the message where the 359 first byte in the current chunk belongs. The index of the first 360 octet in the complete message is ONE, not zero. The ending value 361 indicates the location where the last octet belongs. The body MAY 362 contain less data than is indicated by the end but it MUST NOT 363 contain more octets than indicated. The length indicates the number 364 of octets in the complete message. Both the ending value and length 365 MAY have the value of "*" in some or all of the chunks, to indicate 366 that they are not specified. If no Byte-Range header is present, the 367 SEND request MUST be treated as if there was a Byte-Range header 368 present with a value of "1-*/*". 370 This chunking mechanism allows a sender to interrupt a chunk part way 371 through sending it by writing out the boundary termination and the 372 "+" flag to indicate that the end of this chunk is not the end of the 373 complete message. The ability to interrupt messages allows multiple 374 sessions to share a TCP connection, and for large messages to be sent 375 efficiently while not blocking other messages that share the same 376 connection. 378 To insure fairness over a connection, senders MUST NOT send chunks 379 with a body larger than 2048 octets unless they are prepared to 380 interrupt them. A sender can use one of the following two strategies 381 to satisfy this requirement. The sender is STRONGLY RECOMMENDED to 382 send messages larger than 2048 octets using as few chunks as 383 possible, interrupting chunks (at least 2048 octets long) when other 384 traffic is waiting to use the same connection. Alternatively, the 385 sender MAY simply send chunks in 2048 octet increments until the 386 final chunk. Note that the former strategy results in markedly more 387 efficient use of the connection. All MSRP nodes MUST be able to 388 receive chunks of any size from 0 octets to the maximum number of 389 octets they can receive for a complete message. Senders SHOULD NOT 390 break messages into chunks smaller than 2048 octets, except for the 391 final chunk of a complete message. 393 Receivers MUST not assume the chunks will be delivered in order or 394 that they will receive all the chunks with "+" flags before they 395 receive the chunk with the "$" flag. In certain cases of connection 396 failure, it is possible for information to be duplicated. If chunks 397 data is received that overlaps already received data for the same 398 message, the last chunk received takes precedence (even though this 399 may not have been the last chunk transmitted). For example, if bytes 400 1 to 100 was received and a chunk arrives that contains bytes 50 to 401 150, this second chunk will overwrite bytes 50 to 100 of the data 402 that had already been received. Although other schemes work, this is 403 the easiest for the receiver and results in consistent behavior 404 between clients. 406 The seven "-" before the boundary are used so that the receiver can 407 search for the value "----", 32 bits at a time to find the probable 408 location of the boundary. This allows most processors to locate the 409 boundaries and copy the memory at the same rate that a normal memory 410 copy could be done. This approach results in a system that is as 411 fast as framing based on specifying the body length in the headers of 412 the request, but also allows for the interruption of messages. 414 The ability to interrupt messages is needed so that TCP connections 415 can be shared. Connection sharing is necessary for "fair" allocation 416 of bandwidth in congestion situations and for allowing MSRP network 417 elements that have a very large number of concurrent connections to 418 different users. 420 4.2 MSRP Addressing 422 MSRP entities are addressed using URLs. The MSRP URL schemes are 423 defined in Section 5. The syntax of the To-Path and From-Path 424 headers allow for a list of URLs. This was done to allow the 425 protocol to work with gateways or relays defined in the future, to 426 provide a complete path to the end recipient. When two MSRP nodes 427 communicate directly they need only one URL in the To-Path list and 428 one URL in the From-Path list. 430 4.3 MSRP Transaction and Report Model 432 A sender sends MSRP requests to a receiver. The receiver MUST 433 quickly accept or reject the request. If the receiver initially 434 accepted the request, it still may then do things that take 435 significant time to succeed or fail. For example, if the receiver is 436 an MSRP to XMPP [29] gateway, it may forward the message over XMPP. 437 The XMPP side may later indicate that the request did not work. At 438 this point, the MSRP receiver may need to indicate that the request 439 did not succeed. There are two important concepts here: first, the 440 hop by hop delivery of the request may succeed or fail; second, the 441 end result of the request may be successfully processed or not. The 442 first type of status is referred to as "transaction status" and may 443 be returned in response to a request. The second type of status is 444 referred to as "request status" and may be returned in a REPORT 445 transaction. 447 The original sender of a request can indicate if they wish to receive 448 reports for requests that fail, and can independently indicate if 449 they wish to receive reports for requests that succeed. A receiver 450 only sends a success REPORT if it knows that the request succeeded, 451 and the sender requested a success report. A receiver only sends a 452 failure REPORT if the request failed and the sender requested failure 453 reports. 455 This document describes the behavior of MSRP endpoints. MSRP 456 relays or gateways are likely to have additional conditions that 457 indicate a failure REPORT should be sent, such as the failure to 458 receive a positive response from the next hop. 460 Two header fields control the sender's desire to receive reports. 461 The header "Report-Success" can have a value of "yes" or "no" and the 462 "Report-Failure" header can have a value of "yes", "no", or 463 "partial". 465 If the value of "Report-Failure" is set to "yes", then the sender of 466 the request runs a timer. If a 200 response to the transaction is 467 not received within 30 seconds from the time the last byte of the 468 transaction is sent, the element MUST inform the user that the 469 request probably failed. If the value is set to "partial", then the 470 element sending the transaction does not have to run a timer, but 471 MUST inform the user if receives a non-recoverable error response to 472 the transaction. 474 Similarly if the value of the Report-Success header is "yes", then 475 the receiving node MUST send a "success" REPORT after the request is 476 complete to indicate that the request succeeded. Likewise if the 477 value is "no", it MUST NOT send a success REPORT. 479 A consequence of this is that if an MSRP element receives a request 480 that has the Report-Failure header set to a value of "no", it SHOULD 481 NOT send any responses to this request, because the element sending 482 the request would not do anything with the resulting response. If 483 the value is "partial", it SHOULD NOT send a 200 response to the 484 request, but SHOULD send a non-200 class response if appropriate. 486 If no Report-Success header is present in a SEND request, it MUST be 487 treated the same as a Report-Success header with value of "no". If 488 no Report-Failure header is present, it MUST be treated the same as a 489 Report-Failure header with value of "yes". REPORT requests MUST have 490 the same Message-ID header value as the request they are reporting 491 on. They MAY also have the Byte-Range of the chunk they are 492 reporting on. If an MSRP element receives a REPORT for a Message-ID 493 it does not recognize, it SHOULD silently ignore the REPORT. 495 Report-Success and Report-Failure MUST NOT be present in a REPORT 496 request. MSRP nodes MUST NOT send REPORT requests in response to 497 report requests. MSRP Nodes MUST NOT send MSRP responses to REPORT 498 requests. 500 The combinations of reporting may seem overly complex but they are 501 needed to meet the various scenarios of currently deployed IM 502 systems. Report-Success might be "no" in many public systems to 503 reduce load but is used in some current enterprise systems, such as 504 systems used for securities trading. A Report-Failure value of "no" 505 is useful for sending system messages such as "the system is going 506 down in 5 minutes" without causing a response explosion to the 507 sender. A Report-Failure of "yes" is used by many systems that wish 508 to notify the user if the message failed but some other systems 509 choose to use a value of "partial" to reduce the load on the servers 510 caused by 200 OK responses, but still allow error responses to be 511 sent in many cases. 513 4.4 MSRP Connection Model 515 When MSRP wishes to send a request to a peer identified by an MSRP 516 URL, it first needs a connection, with the appropriate security 517 properties, to the host specified in the URL. If the sender already 518 has such a connection, that is, one associated with the same host, 519 port, and URL scheme, then it SHOULD reuse that connection. 521 When a new MSRP session is created, the convention is that the 522 element that sent the SDP offer MUST immediately issue a SEND request 523 to the answerer. This request MAY have a empty body, or MAY carry 524 content. 526 When a new connection needs to be formed, the element looks at the 527 URL to decide on the type of connection (TLS, TCP, etc.) then 528 connects to the host indicated by the URL, following the URL 529 resolution rules in Section 5.2. For connections using the msrps: 530 scheme, the SubjectAltName in the received certificate MUST match the 531 hostname port of the URL and the certificate MUST be valid, including 532 having a date that is valid and being signed by an acceptable 533 certificate authority. At this point the device that initiated the 534 connection can assume that this connection is with the correct host. 536 If the connection used mutual TLS authentication, and the TLS client 537 presented a valid certificate, then the element accepting the 538 connection can know the identity of the connecting host. When mutual 539 TLS authentication is not used, the listening device MUST wait until 540 it receives a request on the connection to determine the identity of 541 the connecting device. 543 When the first request arrives, it's To-Path header field should 544 contain a URL that the listening element handed out in the SDP for a 545 session. The element that accepted the connection looks up the URL 546 in the received request, and determines which session it matches. If 547 a match exists, the node MUST assume that the host that formed the 548 connection is the host that this URL was given to. If no match 549 exists, the node MUST reject the request with a 481 response. The 550 node MUST also check to make sure the session is not already in use 551 on another connection. If so, it MUST reject the request with a 506 552 response. 554 If it were legal to have multiple connections associated with the 555 same session, a security problem would exist. If the initial SEND 556 request is not protected, an eavesdropper might learn the URL, and 557 use it to insert messages into the session via a different 558 connection. 560 If a connection fails for any reason, then an MSRP endpoint MUST 561 consider failed any sessions associated with the connection as well. 562 When an endpoint notices such a failure, it SHOULD attempt to 563 re-create any such sessions using a new SDP exchange. If a 564 replacement session is successfully created, endpoints MAY attempt to 565 resend any content for which delivery on the original session could 566 not be confirmed. If it does this, the Message-ID values for the 567 resent messages MUST match those used in the initial attempts. If 568 the receiving endpoint receives more than one message with the same 569 Message-ID. It SHOULD assume that the messages are duplicates. It 570 MAY take any action based on that knowledge, but SHOULD NOT present 571 the duplicate messages to the user without warning of the duplicates. 573 In this situation, the endpoint MUST choose Message-ID values so that 574 they are unique in the context of both the original session and the 575 replacement session. 577 When endpoints create a new session in this fashion, the chunks for a 578 given logical message MAY be split across the sessions. However, 579 endpoints SHOULD NOT split chunks between sessions under normal 580 circumstances. 582 If a connection fails, the sender SHOULD attempt to re-setup the URL 583 path using a new offer, for example, in a SIP re-invite or update 584 [13]. It MUST not assume that the new URLs in the SDP will be the 585 same as the old ones. A connection SHOULD not be closed while there 586 are sessions that are using this connection. 588 5. MSRP URLs 590 An MSRP URL follows a subset of the URL syntax in Appendix A of 591 RFC2396 [11], with a scheme of "msrp" or "msrps": 593 MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" 594 resource] ";" transport 595 msrp-scheme = "msrp" / "msrps" 596 resource = 1*unreserved 597 transport = "tcp" / token 599 The constructions for "userinfo", "hostport", and "unreserved" are 600 detailed in RFC2396 [11]. URLs designating MSRP over TCP MUST 601 include the "tcp" parameter. If some other transport is used, the 602 "tcp" parameter MUST NOT be present. 604 Since this document only specifies MSRP over TCP, all MSRP URLs 605 herein use the "tcp" parameter. Documents that provide bindings 606 on other transports should define respective parameters for those 607 transports. A MSRP URL with multiple, contradictory transports is 608 invalid, unless some other document specifies meaning for the 609 particular combination of transport parameters. 611 An MSRP URL server part identifies a participant in an MSRP session. 613 If the server part contains a numeric IP address, it MUST also 614 contain a port. The resource part identifies a particular session 615 the participant. The absence of the resource part indicates a 616 reference to an MSRP host device, but does not specifically refer to 617 a particular session resource. 619 A scheme of "msrps" indicates the underlying connection MUST be 620 protected with TLS. 622 MSRP has an IANA registered recommended port defined in Section 15.1. 623 This value is not a default, as the URL negotiation process described 624 herein will always include explicit port numbers. However, the URLs 625 SHOULD be configured so that the recommended port is used whenever 626 appropriate. This makes life easier for network administrators who 627 need to manage firewall policy for MSRP. 629 The server part will typically not contain a userinfo component, but 630 MAY do so to indicate a user account for which the session is valid. 631 Note that this is not the same thing as identifying the session 632 itself. If a userinfo component exists, it MUST be constructed only 633 from "unreserved" characters, to avoid a need for escape processing. 634 Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo 635 part MUST NOT contain password information. 637 The following is an example of a typical MSRP URL: 639 msrp://host.example.com:8493/asfd34;tcp 641 5.1 MSRP URL Comparison 643 MSRP URL comparisons MUST be performed according to the following 644 rules: 646 1. The scheme must match exactly. 648 2. The host part is compared as case insensitive. 650 3. If the port exists explicitly in either URL, then it must match 651 exactly. An URL with an explicit port is never equivalent to 652 another with no port specified. 654 4. The resource part is compared as case sensitive. A URL without a 655 resource part is never equivalent to one that includes a resource 656 part. 658 5. URLs with different "transport" parameters never match. Two URLs 659 that are identical except for transport are not equivalent. 661 6. Userinfo parts are not considered for URL comparison. 663 Path normalization is not relevant for MSRP URLs. Escape 664 normalization is not required, since the relevant parts are limited 665 to unreserved characters. 667 5.2 Resolving MSRP Host Device 669 An MSRP host device is identified by the server part of an MSRP URL. 671 If the server part contains a numeric IP address and port, they MUST 672 be used as listed. 674 If the server part contains a host name and a port, the connecting 675 device MUST determine a host address by doing an A or AAAA DNS query, 676 and use the port as listed. 678 If a connection attempt fails, the device SHOULD attempt to connect 679 to the addresses returned in any additional A or AAAA records, in the 680 order the records were presented. 682 This process assumes that the connection port is always known 683 prior to resolution. This is always true for the MSRP URL uses 684 described in this document, that is, URLs always created and 685 consumed by automata, rather than by humans. The introduction of 686 relays may create situations where this is not the case. For 687 example, the MSRP URL that a user enters into a client to 688 configure it to use a relay may be intended to be easily 689 remembered and communicated by humans, and therefore is likely to 690 omit the port. Therefore, the relay specification [21] may 691 describe additional steps to resolve the port number. 693 MSRP devices MAY use other methods for discovering other such 694 devices, when appropriate. For example, MSRP endpoints may use other 695 mechanisms to discover relays, which are beyond the scope of this 696 document. 698 6. Method-Specific Behavior 700 6.1 Constructing Requests 702 To form a new request, the sender creates a unique transaction 703 identifier and uses this and the method name to create an MSRP 704 request start line. Next, the sender places the target path in a 705 To-Path header, and the sender's URL in a From-Path header. If 706 multiple URLs are present in the To-Path, the leftmost is the first 707 URL visited; the rightmost URL is the last URL visited. The 708 processing then becomes method specific. Additional method-specific 709 headers are added as described in the following sections. 711 After any method-specific headers are added, processing continues to 712 handle a body, if present. A body in a Non-SEND request MUST NOT be 713 longer than 2048 octets. If the request has a body, it must contain 714 a Content-Type header field. It may contain other MIME specific 715 headers. The Content-Type header MUST be the last header line. The 716 body MUST be separated from the headers with an extra CRLF. 718 If the request contains a body, the sender MUST check the body to 719 insure that the closing sequence (a CRLF, seven hyphens, and the 720 transaction identifier) is not present in the body. If the closing 721 sequence is present in the body, the sender MUST choose a new 722 transaction identifier that is not present in the body, and add the 723 closing sequence, including the "$" or "+" character, and a final 724 CRLF. 726 Finally, requests which have no body MUST NOT contain a Content-Type 727 header or any other MIME specific header. Bodiless requests MUST 728 contain a closing sequence after the final header. 730 Once a request is ready for delivery, the sender follows the 731 connection management (Section 4.4) rules to forward the request over 732 an existing open connection or create a new connection. 734 6.1.1 Delivering SEND requests 736 When an endpoint has a message to deliver, it first generates a new 737 unique Message-ID. This ID MUST be unique within the scope of the 738 session. If the message is larger than 2048 octets in length, it 739 either generates an interruptible chunk (which is RECOMMENDED), or it 740 MAY break the complete message into chunks of 2048 octets. It then 741 generates a SEND request for each chunk, following the procedures 742 for constructing requests (Section 6.1). 744 Each chunk MUST contain a Message-ID header field containing the 745 Message-ID. If the sender wishes non-default status reporting, it 746 MUST insert a Report-Failure and/or Report-Success header field with 747 an appropriate value. All chunks of the same message MUST use the 748 same Report-Failure and Report-Success values in their SEND requests. 750 If success reports are requested, the sending device MAY wish to run 751 a timer of some value that makes sense for it's application and take 752 action if a success Report is not received in this time. There is no 753 universal value for this timer. For many IM applications, it may be 754 2 minutes while for some trading systems it may be under a second. 755 Regardless of whether such a timer is used, if the success report has 756 not been received by the time the session is ended, the device SHOULD 757 inform the user. 759 The first chunk of the message SHOULD, and all subsequent chunks MUST 760 include a Byte-Range header field. The range-start field MUST 761 indicate the position of the first byte in the body in the overall 762 message. The range-end field SHOULD indicate the position of the 763 last byte in the body, if known. It MUST take the value of "*" if 764 the position is unknown, or if the request needs to be interruptible. 765 The total field SHOULD contain the total size of the message, if 766 known. The total filed MAY contain a "*" if the total size of the 767 message is not known in advance. All chunks other than the last MUST 768 include a "+" character in the continuation field of the closing 769 line. The final chunk MUST use a "$" character. The sender MUST 770 send all chunks in Byte-Range order. (However,the receiver cannot 771 assume the requests will be delivered in order, as an intervening 772 relay may have changed the order.) 774 If the sender chooses to send a body larger than 2048 octets in a 775 single chunk, the request MUST be constructed so that it can be 776 interrupted. A SEND request is interruptible if it either has no 777 Byte-Range header field, or has such a field with a "*" in the 778 last-byte sub-field. 780 A SEND request is interrupted while a body is in the process of being 781 written to the connection by simply noting how much of the message 782 has already been written to the connection, then writing out the 783 boundary string to end the chunk. It can then be resumed in a 784 another chunk with the same Message-ID and a Byte-Range header range 785 start field containing the position of the first byte after the 786 interruption occurred. 788 SEND requests larger than 2k MUST be interrupted to send pending 789 response or REPORT requests. If multiple SEND requests from 790 different sessions are concurrently being sent over the same 791 connections, the device SHOULD implement some scheme to alternate 792 between them such that each concurrent request gets a chance to send 793 some fair portion of data at regular intervals suitable to the 794 application. 796 The sender MUST NOT assume that a message is received by the peer 797 with the same chunk allocation it was sent with. An intervening 798 relay could possibly break SEND requests into smaller chunks, or 799 aggregate multiple chunks into larger ones. 801 The default disposition of body is "render". If the sender wants 802 different disposition, it MAY insert a Content-Disposition header. 803 Since MSRP is a binary protocol, transfer encoding MUST be "binary". 805 6.1.2 Sending REPORT requests 807 REPORT requests are similar to SEND requests, except that report 808 requests MUST NOT include Report-Success or Report-Failure header 809 fields, and MUST contain a Status header field. REPORT requests MUST 810 contain the Message-ID header from the original SEND request. 812 An MSRP endpoint MUST be able to generate success REPORT requests. 814 REPORT requests MAY include a body. If a body is included, it SHOULD 815 be of the DSN MIME type detailed in RFC1894 [8], but MAY be of some 816 other type if the sender of the SEND request indicated support in the 817 "receipt-type" parameter of the respective Report-Success or 818 Report-Failure header field. This parameter contains the alternative 819 MIME type that SHOULD be used for this particular report. A client 820 specifying an alternative 'receipt-type' for an MSRP transaction MUST 821 also be capable of receiving the default format specified in this 822 RFC1894. Use of the DSN MIME format in MSRP is described in Section 823 8 825 An endpoint MUST send a success report if it successfully receives a 826 SEND request which contained a Report-Success value of "yes", and 827 either contains a complete message, or contains the last chunk needed 828 to complete the message. This request is sent following the normal 829 procedures (Section 6.1), with a few additional requirements. 831 The endpoint inserts a To-Path header field containing the From-Path 832 value from the original request, and a From-Path header containing 833 the URL identifying itself in the session. The endpoint then inserts 834 a Status header field with a namespace of "000", a short-status of 835 "200" and a relevant Reason phrase, and a Message-ID header field 836 containing the value from the original request. 838 Positive status reports SHOULD NOT include a payload. 840 The endpoint MUST NOT send a success report for a SEND request that 841 either contained no Report-Success header field, or contained such a 842 field with a value of "no". 844 6.1.3 Failure REPORT Generation 846 If an MSRP endpoint receives a SEND request that it cannot process 847 for some reason, and the Report-Failure header either was not present 848 in the original request, or had a value of "yes", it SHOULD simply 849 send a transaction response with an appropriate error response code. 850 However, there may be situations where the error cannot be determined 851 quickly, such as when the endpoint is a gateway that must wait for a 852 downstream network to indicate an error. In this situation, it MAY 853 send a 200 OK response to the request, and then send a failure REPORT 854 request when the error is detected. 856 If the endpoint receives a SEND request with a Report-Failure header 857 field value of "none", then it MUST NOT send a failure REPORT 858 request, and SHOULD NOT send an MSRP response. 860 Construction of failure REPORT requests is identical to that for 861 success reports, except the Status header code and reason fields 862 SHOULD contain appropriate error codes. Any error response code 863 defined in this specification MAY also be used in failure reports. 864 Failure REPORT requests MAY contain a payload, using the DSN MIME 865 type. They MAY contain some other type if allowed by a receipt-type 866 in the Report-Failure header field. 868 If a failure report is sent in response to a SEND request that 869 contained a chunk, it MUST include a Byte-Range header indicating the 870 actual range being reported on. It can take the range-start and 871 total values from the original SEND request, but MUST calculate the 872 range-end field from the actual body data. 874 Endpoints SHOULD NOT send REPORT requests if they have reason to 875 believe the request will not be delivered. For example, they SHOULD 876 NOT send a REPORT request on a session that is no longer valid. 878 This section only describes failure report generation behavior for 879 MSRP endpoints. Relay behavior is beyond the scope of this 880 document, and will be considered in a separate document. We 881 expect failure reports to be more commonly generated by relays 882 than by endpoints. 884 6.2 Constructing Responses 886 If an MSRP endpoint receives a request that either contains a 887 Report-Failure header value of "yes", or does not contain a 888 Report-Failure header field at all, it MUST immediately generate a 889 response. Likewise, if an MSRP endpoint receives a request that 890 contains a Report-Failure header value of "partial", and the receiver 891 is unable to process the request, it SHOULD immediately generate a 892 response. 894 To construct the response, the endpoint first creates the response 895 start-line, inserting appropriate response code and reason fields. 896 The transaction identifier in the response start line MUST match the 897 transaction identifier from the original request. 899 The endpoint then inserts an appropriate To-Path header field. If 900 the request triggering the response was a SEND request, the To-Path 901 header field is formed by copying the last (right-most) URI in the 902 From-Path header field of the request. (Unlike other methods, 903 responses to SEND requests are returned only to the previous hop.) 904 For responses to all other requests, the To-Path header field 905 contains the full path back to the original sender. This full path 906 is generated by taking the list of URLs from the From-Path of the 907 original request, reversing the list, and writing the reversed list 908 into the To-Path of the response. (Legal REPORT requests do not 909 request responses, so this specification doesn't exercise the 910 behavior described above, however we expect that extensions for 911 gateways and relays will need such behavior.) 913 Finally, the endpoint inserts a From-Path header field containing the 914 URL that identifies it in the context of the session, followed by the 915 closing sequence after the last header field. The response MUST be 916 transmitted back on the same connection on which the original request 917 arrived. 919 6.3 Receiving Requests 921 The receiving endpoint must first check the URL in the To-Path to 922 make sure the request belongs to an existing session. When the 923 request is received, the To-Path will have exactly one URL, which 924 MUST map to an existing session that is associated with the 925 connection on which the request arrived. If this is not true, and 926 the request contained a Report-Failure header value of "no", then the 927 receiver SHOULD quietly ignore the request. If the Report-Failure 928 header is not present, or had any other value, then the receiver MUST 929 return a 481 response. 931 Further request processing by the receiver is method specific. 933 6.3.1 Receiving SEND requests 935 When the receiving endpoint receives a SEND request, it first 936 determines if it contains a complete message, or a chunk from a 937 larger message. If the request contains no Byte-Range header, or 938 contains one with a range-start value of "1", and the closing line 939 continuation flag has a value of "$", then the request contained the 940 entire message. Otherwise, the receiver looks at the Message-ID 941 value to associate chunks together into the original message. It 942 forms a virtual buffer to receive the message, keeping track of which 943 bytes have been received and which are missing. The receiver takes 944 the data from the request and places it in the appropriate place in 945 the buffer. The receiver MUST determine the actual length of each 946 chunk by inspecting the payload itself; it is possible the body is 947 shorter than the range-end field indicates. This can occur if the 948 sender interrupted a SEND request unexpectedly. It is worth nothing 949 that the chunk that has a termination character of "$" defines the 950 total length of the message. 952 What is done with the body is outside the scope of MSRP and largely 953 determined by the MIME type. The body MAY be rendered after the 954 whole message is received or partially rendered as it is being 955 received. 957 If the SEND request contained a Content-Type header field indicating 958 an unsupported MIME type, the receiver SHOULD send a 415 response, if 959 allowed by the Report-Failure header field. All MSRP endpoints MUST 960 be able to receive the multipart/mixed and multipart/alternative MIME 961 types. 963 If the SEND request contained a Report-Success header field with a 964 value of "yes", and the request is either contains the entire message 965 or the last chunk needed to complete a message, the receiver MUST 966 send a success REPORT request back to the sender. 968 6.3.2 Receiving REPORT requests 970 When an endpoint receives a REPORT request, it may correlate it to 971 the original SEND request using the Message-ID and the Byte-Range, if 972 present. If it requested success reports, then it SHOULD keep enough 973 state about each outstanding sent message so that it can correlate 974 REPORT requests to the original messages. 976 An endpoint that receives a REPORT request containing a Status header 977 with a namespace field of "000", it SHOULD interpret the report in 978 exactly the same way it would interpret an MSRP transaction response 979 with a response code matching the short-code field. 981 It is possible to receive a failure report or a failure transaction 982 response for a chunk that is currently being delivered. In this case 983 the entire message corresponding to that chunk should be aborted. 985 It is possible that an endpoint will receive a REPORT request on a 986 session that is no longer valid. The endpoint's behavior if this 987 happens is a matter of local policy. The endpoint is not required to 988 take any steps to facilitate such late delivery, i.e. it is not 989 expected to keep a connection active in case late REPORTs might 990 arrive. 992 7. Using MSRP with SIP 994 7.1 SDP Offer-Answer Exchanges for MSRP Sessions 996 MSRP sessions will typically be initiated using the Session 997 Description Protocol (SDP) [2] via the SIP offer-answer mechanism 998 [3]. 1000 This document defines a handful of new SDP parameters to setup MSRP 1001 sessions. These are detailed below and in the IANA Considerations 1002 section. 1004 The general format of an SDP media-line is: 1006 m= 1008 An offered or accepted MSRP media-line MUST have the following value 1009 exactly, with the exception that the port field MAY be set to zero. 1010 (According to [3], a user agent that wishes to accept an offer, but 1011 not a specific media-line MUST set the port number of that media-line 1012 to zero (0).) 1014 m=message 9 msrp * 1016 While MSRP could theoretically carry any media type, "message" is 1017 appropriate. For MSRP, the port number is always ignored--the 1018 actual port number is provided in an MSRP URL. Instead "9" is 1019 used, which is an innocuous value which is assigned to the discard 1020 port. The protocol is always "msrp", and the value of the format 1021 list is always a single asterisk character ("*"). 1023 An MSRP media-line is always accompanied by a mandatory "path" 1024 attribute. This attribute contains a space separated list of URLs 1025 that must be visited to contact the user agent advertising this 1026 session-description. If more than one URL is present, the leftmost 1027 URL is the first URL that must be visited to reach the target 1028 resource. (The path list can contain multiple URLs to allow for the 1029 deployment of gateways or relays in the future.) MSRP 1030 implementations which can accept incoming connections will typically 1031 only provide a single URL here. 1033 MSRP media lines MUST also be accompanied by an "accept-types" 1034 attribute. This attribute contains a list of MIME types which are 1035 acceptable to the endpoint. 1037 A "*" entry in the accept-types attribute indicates that the sender 1038 may attempt to send content with media types that have not been 1039 explicitly listed. Likewise, an entry with an explicit type and a 1040 "*" character as the subtype indicates that the sender may attempt to 1041 send content with any subtype of that type. If the receiver receives 1042 an MSRP request and is able to process the media type, it does so. 1043 If not, it will respond with a 415 response. Note that all explicit 1044 entries SHOULD be considered preferred over any non-listed types. 1046 This feature is needed as, otherwise, the list of formats for rich IM 1047 devices may be prohibitively large. 1049 The accept-types attribute may include container types, that is, MIME 1050 formats that contain other types internally. If compound types are 1051 used, the types listed in the accept-types attribute may be used both 1052 as the root payload, or may be wrapped in a listed container type. 1053 Any container types MUST also be listed in the accept-types 1054 attribute. 1056 Occasionally an endpoint will need to specify a MIME body type that 1057 can only be used if wrapped inside a listed container type. 1059 Endpoints MAY specify MIME types that are only allowed when wrapped 1060 inside compound types using the "accept-wrapped-types" attribute in 1061 an SDP a-line. 1063 The semantics for accept-wrapped-types are identical to those of the 1064 accept-types attribute, with the exception that the specified types 1065 may only be used when wrapped inside containers. Only types listed 1066 in the accept-types attribute may be used as the "root" type for the 1067 entire body. Since any type listed in accept-types may be used both 1068 as a root body, and wrapped in other bodies, format entries from 1069 accept-types SHOULD NOT be repeated in this attribute. 1071 This approach does not allow for specifying distinct lists of 1072 acceptable wrapped types for different types of containers. If an 1073 endpoint understands a MIME type in the context of one wrapper, it is 1074 assumed to understand it in the context of any other acceptable 1075 wrappers, subject to any constraints defined by the wrapper types 1076 themselves. 1078 The approach of specifying types that are only allowed inside of 1079 containers separately from the primary payload types allows an 1080 endpoint to force the use of certain wrappers. For example, a 1081 CPIM [14] gateway device may require all messages to be wrapped 1082 inside message/cpim bodies, but may allow several content types 1083 inside the wrapper. If the gateway were to specify the wrapped 1084 types in the accept-types attribute, its peer might attempt to use 1085 those types without the wrapper. 1086 All types listed in either the accept-types or 1087 accept-wrapped-types attributes MAY include a max-size parameter, 1088 indicating the largest message it is willing to accept of that 1089 type. Max-size refers to the complete message, not the size of 1090 any one chunk. Senders MUST NOT exceed the max-size limit, if 1091 any, when sending messages of any listed type. If a type is 1092 listed without the parameter, then no preset size limit exists. 1094 accept-types = accept-types-label ":" format-list 1095 accept-types-label = "accept-types" 1096 accept-wrapped-types = wrapped-types-label ":" format-list 1097 wrapped-types-label = "accept-wrapped-types" 1098 format-list = format-entry *( SP format-entry) 1099 format-entry = ctype [SEMI max-size] 1100 ctype = (type "/" subtype) / (type "/" "*") / ("*") 1101 type = token 1102 subtype = token 1103 max-size = "max" "=" 1*(DIGIT) 1105 7.1.1 URL Negotiations 1107 Each endpoint in an MSRP session is identified by a URL. These URLs 1108 are negotiated in the SDP exchange. Each SDP offer or answer MUST 1109 contain one or more MSRP URL in a path attribute. This attribute has 1110 the following syntax: 1112 "a=path:" MSRP_URL *(SP MSRP_URL) 1114 where MSRP_URL is an msrp: or msrps: URL as defined in Section 5. 1115 MSRP URLs included in an SDP offer or answer MUST include explicit 1116 port numbers. 1118 An MSRP device uses the URL to determine a host address, port, 1119 transport, and protection level when connecting, and to identify the 1120 target when sending requests and responses. 1122 The offerer and answerer each selects a URL to represent itself, and 1123 send it to the peer device in the SDP document. Each device stores 1124 the path value received from the peer, and uses that value as the 1125 target for requests inside the resulting session. If the path 1126 attribute received from the peer contains more than one URL, then the 1127 target URL is the rightmost, while the leftmost entry represents the 1128 adjacent hop. If only one entry is present, then it is both the peer 1129 and adjacent hop URL. The target path is the entire path attribute 1130 value received from the peer. 1132 The following example shows an SDP offer with a session URL of 1133 "msrp://a.example.com:7394/2s93i;tcp" 1135 v=0 1136 o=alice 2890844526 2890844527 IN IP4 alice.example.com 1137 s= 1138 c=IN IP4 alice.example.com 1139 m=message 9 msrp * 1140 a=accept-types:text/plain 1141 a=path:msrp://a.example.com:7394/2s93i;tcp 1143 The rightmost URI in the path attribute MUST identify the endpoint 1144 that generated the SDP document, or some other location where that 1145 endpoint wishes to receive requests associated with the session. It 1146 MUST be assigned for this particular session, and MUST NOT duplicate 1147 any URI in use for any other session in which the endpoint is 1148 currently participating. It SHOULD be hard to guess, and protected 1149 from eavesdroppers. This is discussed in more detail in Section 14. 1151 7.1.2 Path Attributes with Multiple URLs 1153 As mentioned previously, this document describes MSRP for 1154 peer-to-peer scenarios, that is, when no relays are used. However, 1155 we expect a separate document to describe the use of relays. In 1156 order to allow an MSRP device that only implements the core 1157 specification to interoperate with devices that use relays, this 1158 document must include a few assumptions about how relays work. 1160 An endpoint that uses one or more relays will indicate that by 1161 putting a URL for each device in the relay chain into the SDP path 1162 attribute. The final entry would point to the endpoint itself. The 1163 other entries would indicate each proposed relay, in order. The 1164 first entry would point to the first relay in the chain; that is, the 1165 relay to which the peer device, or a relay operation on its behalf, 1166 should connect. 1168 Endpoints that do not wish to insert a relay, including those that do 1169 not support relays at all, will put exactly one URL into the path 1170 attribute. This URL represents both the endpoint for the session, 1171 and the connection point. 1173 While endpoints that implement only this specification will never 1174 introduce a relay, they will need to be able to interoperate with 1175 other endpoints that do use relays. Therefore, they MUST be prepared 1176 to receive more than one URL in the SDP path attribute. When an 1177 endpoint receives more than one URL in a path header, only the first 1178 entry is relevant for purposes of resolving the address and port, and 1179 establishing the network connection, as it describes the first 1180 adjacent hop. 1182 If an endpoint puts more than one URL in a path attribute, the final 1183 URL in the path (the peer URL) attribute MUST exhibit the uniqueness 1184 properties described above. Uniqueness requirements for other 1185 entries in the attribute are out of scope for this document. 1187 7.1.3 Updated SDP Offers 1189 MSRP endpoints may sometimes need to send additional SDP exchanges 1190 for an existing session. They may need to send periodic exchanges 1191 with no change to refresh state in the network, for example, SIP 1192 Session Timers. They may need to change some other stream in a 1193 session without affecting the MSRP stream, or they may need to change 1194 an MSRP stream without affecting some other stream. 1196 Either peer may initiate an updated exchange at any time. The 1197 endpoint that sends the new offer assumes the role of offerer for all 1198 purposes. The answerer MUST respond with a path attribute that 1199 represents a valid path to itself at the time of the updated 1200 exchange. This new path may be the same as its previous path, but 1201 may be different. The new offerer MUST NOT assume that the peer will 1202 answer with the same path it used previously. 1204 If either party wishes to send an SDP document that changes nothing 1205 at all, then it MUST have the same o-line as in the previous 1206 exchange. 1208 7.1.4 Example SDP Exchange 1210 Endpoint A wishes to invite Endpoint B to a MSRP session. A offers 1211 the following session description: 1213 v=0 1214 o=usera 2890844526 2890844527 IN IP4 alice.example.com 1215 s= 1216 c=IN IP4 alice.example.com 1217 t=0 0 1218 m=message 9 msrp * 1219 a=accept-types: message/cpim text/plain text/html 1220 a=path:msrp://alice.example.com:7394/2s93i9;tcp 1222 B responds with its own URL: 1224 v=0 1225 o=userb 2890844530 2890844532 IN IP4 bob.example.com 1226 s= 1227 c=IN IP4 bob.example.com 1228 t=0 0 1229 m=message 9 msrp * 1230 a=accept-types:message/cpim text/plain 1231 a=path:msrp://bob.example.com:8493/si438ds;tcp 1233 7.1.5 Connection Negotiation 1235 Previous versions of this document included a mechanism to negotiate 1236 the direction for any required TCP connection. The mechanism was 1237 loosely based on the COMEDIA [24]work being done in the MMUSIC 1238 working group. The primary motivation was to allow MSRP sessions to 1239 succeed in situations where the offerer could not accept connections 1240 but the answerer could. For example, the offerer might be behind a 1241 NAT, while the answerer might have a globally routable address. 1243 The SIMPLE working group chose to remove that mechanism from MSRP, as 1244 it added a great deal of complexity to connection management. 1245 Instead, MSRP now specifies a default connection direction. 1247 7.2 MSRP User Experience with SIP 1249 In typical SIP applications, when an endpoint receives an INVITE 1250 request, it alerts the user, and waits for user input before 1251 responding. This is analogous to the typical telephone user 1252 experience, where the callee "answers" the call. 1254 In contrast, the typical user experience for instant messaging 1255 applications is that the initial received message is immediately 1256 displayed to the user, without waiting for the user to "join" the 1257 conversation. Therefore, the principle of least surprise would 1258 suggest that MSRP endpoints using SIP signaling SHOULD allow a mode 1259 where the endpoint quietly accepts the session, and begins displaying 1260 messages. 1262 SIP INVITE requests may be forked by a SIP proxy, resulting in more 1263 than one endpoint receiving the same INVITE. SIP early media [28] 1264 techniques can be used to establish a preliminary session with each 1265 endpoint, and canceling the INVITE transaction for any endpoints that 1266 do not send MSRP traffic after some period of time. 1268 8. DSN payloads in MSRP REPORT Requests 1270 The format of a default REPORT request payload format the DSN taken 1271 from RFC1894 [8]. Only a minimal subset of fields are relevant for 1272 MSRP, as detailed in the remainder of this section. 1274 8.1 Per-Message DSN header usage 1276 original-envelope-id: See Section 8.3 1278 reporting-mta: See Section 8.4 1280 dsn-gateway: Not Used 1281 received-from-mta: Not Used 1283 arrival-date: Not Used 1285 8.2 Per-Recipient DSN header usage 1287 original-recipient Not Used 1289 final-recipient: See Section 8.5 1291 action: See Section 8.6 1293 status: See Section 8.7 1295 remote-mta: Not Used 1297 diagnostic-code: Not Used 1299 last-attempt-date: Not Used 1301 will-retry-until:Not Used 1303 8.3 original-envelope-id usage 1305 The 'original-envelope-id' field contains a unique identifier which 1306 is used to correlate a DSN report with the originating MSRP 1307 transaction. The entity generating the DSN report MUST insert the 1308 Message-ID value that appeared in the original MSRP request into the 1309 'original-envelope-id' field. This allows a requesting client to 1310 explicitly correlate a REPORT request with the original request. 1311 This correlation is implementation specific and makes no requirements 1312 on clients to hold state for transactions ID's. Information 1313 regarding the original request can be obtained from the DSN MIME type 1314 outlined in [8]. 1316 8.4 reporting-mta 1318 The 'reporting-mta-field' MUST follow the guidelines set out in RFC 1319 1894[8]. The 'mta-name-type' from RFC1894[8] MUST use the value of 1320 'msrp-name-type', as defined in Section 15.4 of this specification. 1321 The 'mta-name' value for this field as specified in RFC1894 [8] MUST 1322 equal the MSRP URL representing itself in the context of the session. 1324 8.5 final-recipient 1326 The 'final-recipient-field' MUST follow the guidelines set out in RFC 1327 1894[8]. The 'address-type' from RFC1894 [8] MUST use the value of 1328 'msrp-address-type', as defined in Section 15.4 of this 1329 specification. The 'address-type' value for this field as specified 1330 in RFC1894 [8] MUST equal the final value contained in the MSRP 1331 'To-Path' header from the original request. 1333 8.6 action 1335 The 'action' field MUST follow the guidelines set out in RFC 1894[8]. 1336 An MSRP entity constructing a DSN report MUST use the 'delivered' 1337 value for a successful delivery and MUST use the 'failed' value for 1338 an unsuccessful delivery. The other values specified for the 1339 'action' field in RFC 1894[8] MAY be used. 1341 8.7 status 1343 The 'status' field MUST follow the guidelines set out in RFC 1894[8]. 1344 An MSRP entity constructing a DSN report MUST represent the MSRP 1345 status code in the correct format detailed in RFC 1894[8] for the 1346 'status' field of a DSN report. An MSRP status code consists of a 1347 three digit number while a DSN status is three digits separated by 1348 '.'. An example would be: 1350 Status: 5.0.0 (unknown permanent failure) 1352 When generating this field the first digit of the MSRP status code 1353 (working from left to right) MUST be placed in the first part of the 1354 'status' DSN field. The second digit MUST be placed in the second 1355 part of the 'status' DSN field. The third digit MUST be placed in 1356 the third part of the 'status' DSN field. An example of a DSN 1357 'status' field value would be: 1359 An MSRP '200' success response would be mapped to: 1361 Status: 2.0.0 (OK) 1363 The MSRP reason phrase mapped to a DSN 'status' field MAY be enclosed 1364 in parentheses if required. 1366 9. Formal Syntax 1368 The following syntax specification uses the augmented Backus-Naur 1369 Form (BNF) as described in RFC-2234 [6]. 1371 msrp-req-or-resp = msrp-request / msrp-response 1372 msrp-request = req-start headers [content-stuff] end-line 1373 msrp-response = resp-start headers end-line 1375 req-start = pMSRP SP transact-id SP method CRLF 1376 resp-start = pMSRP SP transact-id SP status-code [SP phrase] CRLF 1377 phrase = utf8text 1379 pMSRP = %4d.53.52.50 ; MSRP in caps 1380 transact-id = ident 1381 method = mSEND / mREPORT / other-method 1382 mSEND = %53.45.4e.44 ; SEND in caps 1383 mREPORT = %52.45.50.4f.52.54; REPORT in caps 1385 other-method = 1*UPALPHA 1386 status-code = 3DIGIT 1388 headers = 1*( header CRLF ) 1390 header = ( To-Path 1391 / From-Path 1392 / Message-ID 1393 / Report-Success 1394 / Report-Failure 1395 / Byte-Range 1396 / Status 1397 / Mime-Header 1398 / ext-header ) 1400 To-Path = "To-Path:" SP URL *( SP URL ) 1401 From-Path = "From-Path:" SP URL *( SP URL ) 1402 Message-ID = "Message-ID:" SP ident 1403 Report-Success = "Report-Success:" SP ("yes" / "no" ) 1404 Report-Failure = "Report-Failure:" SP ("yes" / "no" / "partial" ) 1405 Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total 1406 range-start = 1*DIGIT 1407 range-end = 1*DIGIT / "*" 1408 total = 1*DIGIT / "*" 1409 Status = "Status:" SP namespace SP short-status [SP text-reason] 1411 ident = alphanum 3*31ident-char 1412 ident-char = alphanum / "." / "-" / "+" / "%" / "=" 1414 content-stuff = *(Other-Mime-Header CRLF) 1415 Content-Type 2CRLF data CRLF 1417 Content-Type = "Content-Type:" SP media-type 1418 media-type = type "/" subtype *( ";" gen-param ) 1419 type = token 1420 subtype = token 1422 gen-param = pname [ "=" pval ] 1423 pname = token 1424 pval = token / quoted-string 1426 token = 1*(alphanum / "-" / "." / "!" / "%" 1427 / "*" / "_" / "+" 1429 quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE 1430 qdtext = SP / HT / %x21 / %x23-5B / %x5D-7E 1431 / UTF8-NONASCII 1432 qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) 1433 BACKSLASH = "\" 1434 DQUOTE = %x22 1436 Other-Mime-Header = (Content-ID 1437 / Content-Description 1438 / Content-Disposition 1439 / mime-extension-field); 1441 ; Content-ID, and Content-Description are defined in RFC2045. 1442 ; Content-Disposition is defined in RFC2183 1443 ; MIME-extension-field indicates additional MIME extension 1444 ; headers as described in RFC2045 1446 data = *OCTET 1447 end-line = "-------" transact-id continuation-flag CRLF 1448 continuation-flag = "+" / "$" 1450 ext-header = hname ":" SP hval CRLF 1451 hname = alpha *token 1452 hval = utf8text 1454 utf8text = *(HT / %x20-7E / UTF8-NONASCII) 1456 UTF8-NONASCII = %xC0-DF 1UTF8-CONT 1457 / %xE0-EF 2UTF8-CONT 1458 / %xF0-F7 3UTF8-CONT 1459 / %xF8-Fb 4UTF8-CONT 1460 / %xFC-FD 5UTF8-CONT 1461 UTF8-CONT = %x80-BF 1463 10. Response Code Descriptions 1465 This section summarizes the semantics of various response codes that 1466 may be used in MSRP transaction responses. These codes may also be 1467 used in the Status header in REPORT requests. 1469 10.1 200 1471 The 200 response code indicates a successful transaction. 1473 10.2 400 1475 A 400 response indicates a request was unintelligible. 1477 10.3 403 1479 The action is not allowed 1481 10.4 415 1483 A 415 response indicates the SEND request contained a MIME 1484 content-type that is not understood by the receiver. 1486 10.5 426 1488 A 426 response indicates that the request is only allowed over TLS 1489 protected connections. 1491 10.6 481 1493 A 481 response indicates that no session exists for the connection. 1495 10.7 506 1497 A 506 response indicates that a request arrived on a session which is 1498 already bound to another network connection. 1500 11. Examples 1502 11.1 Basic IM session 1504 This section shows an example flow for the most common scenario. The 1505 example assumes SIP is used to transport the SDP exchange. Details 1506 of the SIP messages and SIP proxy infrastructure are omitted for the 1507 sake of brevity. In the example, assume the offerer is 1508 sip:alice@example.com and the answerer is sip:bob@example.com. 1510 Alice Bob 1511 | | 1512 | | 1513 |(1) (SIP) INVITE | 1514 |----------------------->| 1515 |(4) (SIP) 200 OK | 1516 |<-----------------------| 1517 |(5) (SIP) ACK | 1518 |----------------------->| 1519 |(6) (MSRP) SEND | 1520 |----------------------->| 1521 |(7) (MSRP) 200 OK | 1522 |<-----------------------| 1523 |(8) (MSRP) SEND | 1524 |<-----------------------| 1525 |(9) (MSRP) 200 OK | 1526 |----------------------->| 1527 |(10) (SIP) BYE | 1528 |----------------------->| 1529 |(11) (SIP) 200 OK | 1530 |<-----------------------| 1531 | | 1532 | | 1534 1. Alice constructs a local URL of 1535 msrp://alicepc.example.com:7777/iau39;tcp . 1537 Alice->Bob (SIP): INVITE sip:bob@example.com 1539 v=0 1540 o=alice 2890844557 2890844559 IN IP4 alicepc.example.com 1541 s= 1542 c=IN IP4 alicepc.example.com 1543 t=0 0 1544 m=message 9 msrp * 1545 a=accept-types:text/plain 1546 a=path:msrp://alicepc.example.com:7777/iau39;tcp 1548 2. Bob listens on port 8888, and sends the following response: 1549 3. Bob->Alice (SIP): 200 OK 1551 v=0 1552 o=bob 2890844612 2890844616 IN IP4 bob.example.com 1553 s= 1554 c=IN IP4 bob.example.com 1555 t=0 0 1556 m=message 9 msrp * 1557 a=accept-types:text/plain 1558 a=path:msrp://bob.example.com:8888/9di4ea;tcp 1560 4. Alice->Bob (SIP): ACK 1562 5. (Alice opens connection to Bob.) Alice->Bob (MSRP): 1564 MSRP d93kswow SEND 1565 To-Path:msrp://bob.example.com:8888/9di4ea;tcp 1566 From-Path:msrp://alicepc.example.com:7777/iau39;tcp 1567 Message-ID: 12339sdqwer 1568 Content-Type:text/plain 1569 Hi, I'm Alice! 1570 -------d93kswow$ 1572 6. Bob->Alice (MSRP): 1574 MSRP d93kswow 200 OK 1575 To-Path:msrp://bob.example.com:8888/9di4ea;tcp 1576 From-Path:msrp://alicepc.example.com:7777/iau39;tcp 1577 -------d93kswow$ 1579 7. Bob->Alice (MSRP): 1581 MSRP dkei38sd SEND 1582 To-Path:msrp://alice.example.com:7777/iau39;tcp 1583 From-Path:msrp://bob.example.com:8888/9di4ea;tcp 1584 Message-ID: 456 1585 Content-Type:text/plain 1587 Hi, Alice! I'm Bob! 1588 -------dkei38sd$ 1590 8. Alice->Bob (MSRP): 1592 MSRP dkei38sd 200 OK 1593 To-Path:msrp://alice.example.com:7777/iau39;tcp 1594 From-Path:msrp://bob.example.com:8888/9di4ea;tcp 1595 -------dkei38sd$ 1597 9. Alice->Bob (SIP): BYE 1599 Alice invalidates local session state. 1601 10. Bob invalidates local state for the session. 1603 Bob->Alice (SIP): 200 OK 1605 11.2 Chunked Message 1607 For an example of a chunked message, see the example in Section 4.1. 1609 11.3 System Message 1611 Sysadmin->Alice (MSRP): 1613 MSRP d93kswow SEND 1614 To-Path:msrp://alicepc.example.com:8888/9di4ea;tcp 1615 From-Path:msrp://example.com:7777/iau39;tcp 1616 Message-ID: 12339sdqwer 1617 Report-Failure: no 1618 Report-Success: no 1619 Content-Type:text/plain 1620 The system is going down in 5 minutes 1621 -------d93kswow$ 1623 11.4 Positive Report 1625 Alice->Bob (MSRP): 1627 MSRP d93kswow SEND 1628 To-Path:msrp://bob.example.com:8888/9di4ea;tcp 1629 From-Path:msrp://alicepc.example.com:7777/iau39;tcp 1630 Message-ID: 12339sdqwer 1631 Report-Success: yes 1632 Content-Type:text/html 1634 1635

Here is that important link... 1636 foobar 1637

1638 1639 -------d93kswow$ 1641 Bob->Alice (MSRP): 1643 MSRP d93kswow 200 OK 1644 To-Path:msrp://alicepc.example.com:7777/iau39;tcp 1645 From-Path:msrp://bob.example.com:8888/9di4ea;tcp 1646 -------d93kswow$ 1648 Bob->Alice (MSRP): 1650 MSRP dkei38sd SEND 1651 To-Path:msrp://alicepc.example.com:7777/iau39;tcp 1652 From-Path:msrp://bob.example.com:8888/9di4ea;tcp 1653 Message-ID: 12339sdqwer 1654 Status: 000 200 OK 1655 -------dkei38sd$ 1657 11.5 Forked IM 1659 Traditional IM systems generally do a poor job of handling multiple 1660 simultaneous IM clients online for the same person. While some do a 1661 better job than many existing systems, handling of multiple clients 1662 is fairly crude. This becomes a much more significant issue when 1663 always-on mobile devices are available, but when it is desirable to 1664 use them only if another IM client is not available. 1666 Using SIP makes rendezvous decisions explicit, deterministic, and 1667 very flexible; instead "pager-mode" IM systems use implicit 1668 implementation-specific decisions which IM clients cannot influence. 1670 With SIP session mode messaging rendezvous decisions can be under 1671 control of the client in a predictable, interoperable way for any 1672 host that implements callee capabilities [30]. As a result, 1673 rendezvous policy is managed consistently for each address of record. 1675 The following example shows Juliet with several IM clients where she 1676 can be reached. Each of these has a unique SIP Contact and MSRP 1677 session. The example takes advantage of SIP's capability to "fork" 1678 an invitation to several Contacts in parallel, in sequence, or in 1679 combination. Juliet has registered from her chamber, the balcony, 1680 her PDA, and as a last resort, you can leave a message with her 1681 Nurse. Juliet's contacts are listed below. The q-values express 1682 relative preference (q=1.0 is the highest preference). 1684 We query for a list of Juliet's contacts by sending a REGISTER: 1686 REGISTER sip:thecapulets.example.com SIP/2.0 1687 To: Juliet 1688 From: Juliet ;tag=12345 1689 Call-ID: 09887877 1690 CSeq: 772 REGISTER 1692 The Response contains her Contacts: 1694 SIP/2.0 200 OK 1695 To: Juliet 1696 From: Juliet ;tag=12345 1697 Call-ID: 09887877 1698 CSeq: 771 REGISTER 1699 Contact: 1700 ;q=0.9;expires=3600 1701 Contact: 1702 ;q=1.0;expires=3600 1703 Contact: ;q=0.4;expires=3600 1704 Contact: ;q=0.1;expires=3600 1706 When Romeo opens his IM program, he selects Juliet and types the 1707 message "art thou hither?" (instead of "you there?"). His client 1708 sends a SIP invitation to sip:juliet@thecapulets.example.com. The 1709 Proxy there tries first the balcony and the chamber simultaneously. 1710 A client is running on both those systems, both of which setup early 1711 sessions of MSRP with Romeo's client. The client automatically sends 1712 the message over the MSRPS to the two MSPR URIs involved. After a 1713 delay of a several seconds with no reply or activity from Juliet, the 1714 proxy cancels the invitation at her first two contacts, and forwards 1715 the invitation on to Juliet's PDA. Since her father is talking to 1716 her about her wedding, she selects "Do Not Disturb" on her PDA, which 1717 sends a "Busy Here" response. The proxy then tries the Nurse, who 1718 answers and tells Romeo what is going on. 1720 Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse 1721 Proxy balcony chamber PDA 1723 | | | | | | 1724 |--INVITE--->| | | | | 1725 | |--INVITE--->| | | | 1726 | |<----180----| | | | 1727 |<----180----| | | | | 1728 |---PRACK---------------->| | | | 1729 |<----200-----------------| | | | 1730 |<===Early MSRP Session==>| art thou hither? | | 1731 | | | | | | 1732 | |--INVITE---------------->| | | 1733 | |<----180-----------------| | | 1734 |<----180----| | | | | 1735 |---PRACK----------------------------->| | | 1736 |<----200------------------------------| | | 1737 |<========Early MSRP Session==========>| art thou hither? | 1738 | | | | | | 1739 | | | | | | 1740 | | .... Time Passes .... | | | 1741 | | | | | | 1742 | | | | | | 1743 | |--CANCEL--->| | | | 1744 | |<---200-----| | | | 1745 | |<---487-----| | | | 1746 | |----ACK---->| | | | 1747 | |--CANCEL---------------->| | | 1748 | |<---200------------------| | | 1749 | |<---487------------------| | | 1750 | |----ACK----------------->| | | 1751 | |--INVITE---------------------------->| romeo wants 1752 | | | | | to IM w/ you 1753 | |<---486 Busy Here--------------------| | 1754 | |----ACK----------------------------->| | 1755 | | | | | | 1756 | |--INVITE---------------------------------------->| 1757 | |<---200 OK---------------------------------------| 1758 |<--200 OK---| | | | | 1759 |---ACK------------------------------------------------------->| 1760 |<================MSRP Session================================>| 1761 | | | | | | 1762 | Hi Romeo, Juliet is | 1763 | with her father now | 1764 | can i take a message?| 1765 | | 1766 | Tell her to go to confession tommorrow.... | 1768 12. Extensibility 1770 MSRP was designed to be only minimally extensible. New MSRP Methods, 1771 Headers, and status codes can be defined in standards track RFCs. 1772 There is no registry of headers, methods, or status codes, since the 1773 number of new elements and total extensions is expected to be very 1774 small. MSRP does not contain a version number or any negotiation 1775 mechanism to require or discover new features. 1777 MSRP was designed to use lists of URLs instead of a single URL in the 1778 To-Path and From-Path headers in anticipation of relay or gateway 1779 functionality being added. In addition, msrp: and msrps: URLs can 1780 contain parameters which are extensible. 1782 13. CPIM compatibility 1784 MSRP sessions may be gatewayed to other CPIM [25]compatible 1785 protocols. If this occurs, the gateway MUST maintain session state, 1786 and MUST translate between the MSRP session semantics and CPIM 1787 semantics that do not include a concept of sessions. Furthermore, 1788 when one endpoint of the session is a CPIM gateway, instant messages 1789 SHOULD be wrapped in "message/cpim" [7] bodies. Such a gateway MUST 1790 include "message/cpim" as the first entry in its SDP accept-types 1791 attribute. MSRP endpoints sending instant messages to a peer that 1792 has included 'message/cpim" as the first entry in the accept-types 1793 attribute SHOULD encapsulate all instant message bodies in "message/ 1794 cpim" wrappers. All MSRP endpoints MUST support the message/cpim 1795 type, and SHOULD support the S/MIME features of that format. 1797 14. Security Considerations 1799 Instant Messaging systems are used to exchange a variety of sensitive 1800 information ranging from personal conversations, to corporate 1801 confidential information, to account numbers and other financial 1802 trading information. IM is used by individuals, corporations, and 1803 governments for communicating important information. Like many 1804 communications systems, the properties of Integrity and 1805 Confidentiality of the exchanged information, along with the 1806 possibility of Anonymous communications, and knowing you are 1807 communicating with the correct other party are required. MSRP pushes 1808 many of the hard problems to SIP when SIP sets up the session, but 1809 some of the problems remain. Spam and DoS attacks are also very 1810 relevant to IM systems. 1812 MSRP needs to provide confidentiality and integrity for the messages 1813 it transfers. It also needs to provide assurances the connected host 1814 is the host that it meant to connect to and that the connection has 1815 not been hijacked. 1817 When using only TCP connections, MSRP security is fairly weak. If 1818 host A is contacting B, B passes its hostname and a secret to A using 1819 SIP. If the SIP offer or answer is not TLS or S/MIME [27] protected, 1820 anyone can see this secret. A then connects to the provided host 1821 name and passes the secret in the clear across the connection to B. 1822 A assumes that it is talking to B based on where it sent the SYN 1823 packet and then delivers the secret in plain text across the 1824 connections. B assumes it is talking to A because the host on the 1825 other end of the connection delivered the secret. An attacker that 1826 could ACK the SYN packet could insert itself as a man in the middle 1827 in the connection. 1829 When using TLS connections, the security is significantly improved. 1830 We assume that the host accepting the connection has a certificate 1831 from a well know certificate authority. Furthermore, we assume that 1832 the SIP signaling to set up the session is protected with TLS (using 1833 sips). In this case, when host A contacts host B, the secret is 1834 passed through a SIP confidential channel to A. A connects with TLS 1835 to B. B presents a valid certificate, so A knows it really is 1836 connected to B. A then delivers the secret provided by B, so that B 1837 can verify it is connected to A. In this case, a rogue SIP Proxy can 1838 see the secret in the SIP signaling traffic and could potentially 1839 insert itself as a man-in-the-middle. 1841 Realistically, using TLS is only feasible when connecting to gateways 1842 or relays , as the types of hosts that end clients use for sending 1843 instant messages are unlikely to have a long term stable IP address 1844 or a stable DNS name that a certificate can bind to. In addition, 1845 the cost of server certificates from well known certificate 1846 authorities is currently too high for the vast majority of end users 1847 to even consider getting one for each client. 1849 The only real security for connections without relays is achieved 1850 using S/MIME. This does not require the actual endpoint to have 1851 certificates from a well known certificate authority. The Identity 1852 [22] and Certificates [23] mechanism with SIP provides S/MIME based 1853 delivery of a secret between A and B. No SIP intermediary except the 1854 explicitly trusted authentication service (one per user) can see the 1855 secret. The S/MIME encryption of the SDP can also be used by SIP to 1856 exchange keying material that can be used in MRSP. The MSRP session 1857 can then use S/MIME with this keying material to encrypt and sign 1858 messages sent over MSRP. The connection can still be hijacked since 1859 the secret is sent in clear text to the other end of the TCP 1860 connection, but this risk is mitigated if all the MSRP content is 1861 encrypted and signed with S/MIME. 1863 MSRP can not be used as an amplifier for DoS attacks, but it can be 1864 used to form a distributed attack to consume TCP connection resource 1865 on servers. The attacker, Eve, sends an SIP INVITE with no offer to 1866 Alice. Alice returns a 200 with an offer and Eve returns an answer 1867 with the SDP that indicates that her MSRP address is the address of 1868 Tom. Since Alice sent the offer, Alice will initiate a connection to 1869 Tom using up resources on Tom's server. Given the huge number of IM 1870 clients, and the relatively few TCP connections that most servers 1871 support, this is a fairly straightforward attack. 1873 SIP is attempting to address issues in dealing with spam. The spam 1874 issue is probably best dealt with at the SIP level when an MSRP 1875 session is initiated and not at the MSRP level. 1877 TLS is used to authenticate devices and to provide integrity and 1878 confidentiality for the headers being transported. MSRP elements 1879 MUST implement TLS and MUST also implement the TLS 1880 ClientExtendedHello extended hello information for server name 1881 indication as described in [12]. A TLS cipher-suite of 1882 TLS_RSA_WITH_AES_128_CBC_SHA [15] MUST be supported (other 1883 cipher-suites MAY also be supported). 1885 Since MSRP carries arbitrary MIME content, it can trivially carry S/ 1886 MIME protected messages as well. All MSRP implementations MUST 1887 support the multipart/signed MIME type even if they do not support S/ 1888 MIME. Since SIP can carry a session key, S/MIME messages in the 1889 context of a session could also be protected using a key-wrapped 1890 shared secret [26] provided in the session setup. 1892 15. IANA Considerations 1894 15.1 MSRP Port 1896 MSRP uses TCP port XYX, to be determined by IANA after this document 1897 is approved for publication. Usage of this value is described in 1898 Section 5 1900 15.2 MSRP URL Schemes 1902 This document defines the URL schemes of "msrp" and "msrps". 1904 Syntax See Section 5. 1905 Character Encoding See Section 5. 1906 Intended Usage See Section 5. 1907 Protocols The Message Session Relay Protocol (MSRP). 1908 Security Considerations See Section 14. 1909 Relevant Publications RFCXXXX 1910 [Note to RFC Editor: Please replace RFCXXXX in the above 1911 paragraph with the actual number assigned to this document. 1913 15.3 SDP Parameters 1915 This document registers the following SDP parameters in the 1916 sdp-parameters registry: 1918 15.3.1 Accept Types 1920 Attribute-name: accept-types 1921 Long-form Attribute Name Acceptable MIME Types 1922 Type: Media level 1923 Subject to Charset Attribute No 1924 Purpose and Appropriate Values See Section 7.1. 1926 15.3.2 Wrapped Types 1928 Attribute-name: accept-wrapped-types 1929 Long-form Attribute Name Acceptable MIME Types Inside Wrappers 1930 Type: Media level 1931 Subject to Charset Attribute No 1932 Purpose and Appropriate Values See Section 7.1. 1934 15.3.3 Path 1936 Attribute-name: path 1937 Long-form Attribute Name MSRP URL Path 1938 Type: Media level 1939 Subject to Charset Attribute No 1940 Purpose and Appropriate Values See Section 7.1.1. 1942 15.4 IANA registration forms for DSN types 1944 15.4.1 IANA registration form for address-type 1946 This document registers a new 'address-type' for use in conjunction 1947 with RFC1894[8]. The authors request that these values be recorded 1948 in the IANA registry for DSN 'address-type'. 1950 Proposed Address name: msrp-address-type 1951 Syntax: See Section 5 1953 15.4.2 IANA registration form for MTA-name-type 1955 This document registers a new 'MTA-name-type' for use in conjunction 1956 with RFC1894[8]. The authors request that these values be recorded 1957 in the IANA registry for DSN 'MTA-name-type'. 1959 Proposed Address name: msrp-name-type 1961 Syntax: See Section 5 1963 16. Change History 1965 16.1 draft-ietf-simple-message-sessions-07 1967 Significant re-write to attempt to improve readability. 1968 Added maximum size parameter in accept-types 1969 Changed the Boundary field to be part of the start-line rather 1970 than a header field. 1971 Removed the TR-IDheader, and changed request-response matching to 1972 be based on the Boundary field value. Responses still contain the 1973 TR-ID header, which must match the Boundary from the request. 1974 Removed transport selection from URL scheme and added the "tcp" 1975 parameter. 1976 Added description of the "simple" mode with no transaction 1977 responses, and made mode selection dependent on the reporting 1978 level requested for a give message. 1979 Changed the DSN section to reflect separate request of success and 1980 failure reports. Enhanced REPORT method to be useful even without 1981 a payload. 1982 removed SRV usage for URL resolution. This is only used for relay 1983 discovery, and therefore should be moved to the relay draft. 1984 Added discussion about late REPORT handling. Asserted that REPORT 1985 requests are always sent in simple mode. 1986 Removed the dependency on multipart/byteranges for fragmentation. 1987 Incorporated the Byte-Range header into the base MSRP header set. 1988 Removed the VISIT method. Change to use SEND to serve the purpose 1989 formerly reserved to VISIT. 1991 16.2 draft-ietf-simple-message-sessions-06 1993 Changed To and From header names to To-Path and From-Path. Added 1994 more clarification to path handling, and commentary on how it 1995 enables relay usage. 1996 Changed mechanism for signaling transport and TLS protection into 1997 the MSRP URL, rather than the SDP M-Line. 1999 Removed length field from start line and added Boundary header 2000 field and Closing field. 2001 Added recommendation to fragment any content over 2k. 2002 Added Rohan's proposal to make offerer connect to answerer. (With 2003 open issue for more discussion.) 2004 Changed To-Path and From-Path usage in responses to indicate the 2005 destination and source of the response, rather than merely copy 2006 from the associated request. 2007 Updated DSN section. Added text on field usage. 2008 Fixed change TR-ID header from version 05 were erroneously 2009 attributed to 04. 2011 16.3 draft-ietf-simple-message-sessions-05 2013 Changed the use of session URLs. Instead of a single session URL, 2014 each endpoint is identified by a distinct URL. MSRP requests will 2015 put the destination URL in a To header, and the sender URL in a 2016 From header. 2017 Changed the SDP exchange of MSRP URLs to handle the URL for each 2018 endpoint. Further, changed the SDP attribute to support a list of 2019 URLs in each direction. This may be used with relays to exchange 2020 paths, rather than single URLs. MSRP endpoints must be able to 2021 intelligently process such a list if received. This document does 2022 not, however, describe how to generate such a list. 2023 Added section for Delivery Status Notification handling, and added 2024 associated entries into the syntax definition. 2025 Added content fragmentation section. 2026 Removed recommendation to start separate session for large 2027 transfers. 2028 Corrected some mistakes in the syntax definitions. 2029 Added Chris Boulton as a co-author for his contribution of the DSN 2030 text. 2032 16.4 draft-ietf-simple-message-sessions-04 2034 Removed the direction attribute. Rather than using a comedia 2035 styled direction negotiation, we just state that the answerer 2036 opens any needed connection. 2038 16.5 draft-ietf-simple-message-sessions-03 2040 Removed all specification of relays, and all features specific to 2041 the use of relays. The working group has chosen to move relay 2042 work into a separate effort, in order to advance the base 2043 specification. (The MSRP acronym is unchanged for the sake of 2044 convenience.) This included removal of the BIND method, all 2045 response codes specific to BIND, Digest Authentication, and the 2046 inactivity timeout. 2048 Removed text indicating that an endpoint could retry failed 2049 requests on the same connection. Rather, the endpoint should 2050 consider the connection dead, and either signal a reconnection or 2051 end the session. 2052 Added text describing subsequent SDP exchanges. Added mandatory 2053 "count" parameter to the direction attribute to allow explicit 2054 signaling of the need to reconnect. 2055 Added text to describe the use of send and receive only indicators 2056 in SDP for one-way transfer of large content. 2057 Added text requiring unique port field values if multiple M-line's 2058 exist. 2059 Corrected a number of editorial mistakes. 2061 16.6 draft-ietf-simple-message-sessions-02 2063 Moved all content type negotiation from the "m"-line format list 2064 into "a"-line attributes. Added the accept-types attribute. This 2065 is due to the fact that the sdp format-list syntax is not 2066 conducive to encoding MIME content types values. 2067 Added "other-method" construction to the message syntax to allow 2068 for extensible methods. 2069 Consolidated all syntax definitions into the same section. 2070 Cleaned up ABNF for digest challenge and response syntax. 2071 Changed the session inactivity timeout to 12 minutes. 2072 Required support for the SHA1 algorithm. 2073 Required support for the message/cpim format. 2074 Fixed lots of editorial issues. 2075 Documented a number of open issues from recent list discussions. 2077 16.7 draft-ietf-simple-message-sessions-01 2079 Abstract rewritten. 2080 Added architectural considerations section. 2081 The m-line format list now only describes the root body part for a 2082 request. Contained body part types may be described in the 2083 "accept-wrapped-types" a-line attribute. 2084 Added a standard dummy value for the m-line port field. Clarified 2085 that a zero in this field has normal SDP meaning. 2086 Clarified that an endpoint is globally configured as to whether or 2087 not to use a relay. There is no relay discovery mechanism 2088 intrinsic to MSRP. 2089 Changed digest algorithm to SHA1. Added TR-ID and S-URI to the 2090 hash for digest authentication. 2091 CMS usage replaced with S/MIME. 2092 TLS and msrps: usage clarified. 2093 Session state timeout is now based on SEND activity, rather than 2094 BIND and VISIT refreshes. 2096 Default port added. 2097 Added sequence diagrams to the example message flows. 2098 Added discussion of self-signed certificates in the security 2099 considerations section. 2101 16.8 draft-ietf-simple-message-sessions-00 2103 Name changed to reflect status as a work group item. 2104 This version no longer supports the use of multiple sessions 2105 across a single TCP session. This has several related changes: 2106 There is now a single session URI, rather than a separate one for 2107 each endpoint. The session URI is not required to be in requests 2108 other than BIND and VISIT, as the session can be determined based 2109 on the connection on which it arrives. 2110 BIND and VISIT now create soft state, eliminating the need for the 2111 RELEASE and LEAVE methods. 2112 The MSRP URL format was changed to better reflect generic URL 2113 standards. URL comparison and resolution rules were added. SRV 2114 usage added. 2115 Determination of host and visitor roles now uses a direction 2116 attribute much like the one used in COMEDIA. 2117 Format list negotiation expanded to allow a "prefer these formats 2118 but try anything" semantic 2119 Clarified handling of direction notification failures. 2120 Clarified signaling associated with session failure due to dropped 2121 connections. 2122 Clarified security related motivations for MSRP. 2123 Removed MIKEY dependency for session key exchange. Simple usage 2124 of k-lines in SDP, where the SDP exchange is protected end-to-end 2125 seems sufficient. 2127 16.9 draft-campbell-simple-im-sessions-01 2129 Version 01 is a significant re-write. References to COMEDIA were 2130 removed, as it was determined that COMEDIA would not allow 2131 connections to be used bidirectional in the presence of NATs. 2132 Significantly more discussion of a concrete mechanism has been added 2133 to make up for no longer using COMEDIA. Additionally, this draft and 2134 draft-campbell-cpimmsg-sessions (which would have also changed 2135 drastically) have now been combined into this single draft. 2137 17. Contributors and Acknowledgments 2139 In addition to the editor, The following people contributed extensive 2140 work to this document: Chris Boulton, Cullen Jennings, Paul Kyzivat, 2141 Rohan Mahy, Adam Roach, Jonathan Rosenberg, Robert Sparks. 2143 The following people contributed substantial discussion and feedback 2144 to this ongoing effort: Allison Mankin, Jon Peterson, Brian Rosen, 2145 Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, Orit Levin. 2147 18. References 2149 18.1 Normative References 2151 [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2152 2246, January 1999. 2154 [2] Handley, M. and V. Jacobson, "SDP: Session Description 2155 Protocol", RFC 2327, April 1998. 2157 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2158 Session Description Protocol (SDP)", RFC 3264, June 2002. 2160 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2161 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2162 Session Initiation Protocol", RFC 3261, June 2002. 2164 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2165 Levels", BCP 14, RFC 2119, March 1997. 2167 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2168 Specifications: ABNF", RFC 2234, November 1997. 2170 [7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging 2171 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in 2172 progress), January 2003. 2174 [8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for 2175 Delivery Status Notifications", RFC 1894, January 1996. 2177 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2178 Extensions (MIME) Part One: Format of Internet Message Bodies", 2179 RFC 2045, November 1996. 2181 [10] Troost, R., Dorner, S. and K. Moore, "Communicating 2182 Presentation Information in Internet Messages: The 2183 Content-Disposition Header Field", RFC 2183, August 1997. 2185 [11] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2186 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2187 1998. 2189 [12] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and 2190 T. Wright, "Transport Layer Security (TLS) Extensions", RFC 2191 3546, June 2003. 2193 [13] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 2194 Method", RFC 3311, October 2002. 2196 [14] Atkins, D. and G. Klyne, "Common Presence and Instant 2197 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 2198 (work in progress), January 2003. 2200 [15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 2201 Transport Layer Secur ity (TLS)", RFC 3268, June 2002. 2203 18.2 Informational References 2205 [16] Johnston, A. and O. Levin, "Session Initiation Protocol Call 2206 Control - Conferencing for User Agents", 2207 draft-ietf-sipping-cc-conferencing-03 (work in progress), 2208 February 2004. 2210 [17] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 2211 "Best Current Practices for Third Party Call Control in the 2212 Session Initiation Protocol", draft-ietf-sipping-3pcc-06 (work 2213 in progress), January 2004. 2215 [18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 2216 Control - Transfer", draft-ietf-sipping-cc-transfer-02 (work in 2217 progress), February 2004. 2219 [19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 2220 D. Gurle, "Session Initiation Protocol (SIP) Extension for 2221 Instant Messaging", RFC 3428, December 2002. 2223 [20] Mahy, R., "Benefits and Motivation for Session Mode Instant 2224 Messaging", draft-mahy-simple-why-session-mode-00 (work in 2225 progress), February 2004. 2227 [21] Mahy, R. and C. Jennings, "Relays for the Message Session Relay 2228 Protocol (MSRP)", draft-ietf-simple-msrp-relays-01.txt (work in 2229 progress), July 2004. 2231 [22] Peterson, J. and C. Jennings, "Enhancements for Authenticated 2232 Identity Management in the Session Initiation Protocol (SIP)", 2233 draft-ietf-sip-identity-02 (work in progress), May 2004. 2235 [23] Jennings, C. and J. Peterson, "Certificate Management Service 2236 for SIP", draft-jennings-sipping-certs-03 (work in progress), 2237 May 2004. 2239 [24] Yon, D., "Connection-Oriented Media Transport in SDP", 2240 draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 2241 2003. 2243 [25] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", 2244 draft-ietf-impp-im-04 (work in progress), August 2003. 2246 [26] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, 2247 December 2001. 2249 [27] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2250 2633, June 1999. 2252 [28] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone 2253 Generation in the Session Initiation Protocol (SIP)", 2254 draft-ietf-sipping-early-media-02 (work in progress), June 2255 2004. 2257 [29] Saint-Andre, P., "Extensible Messaging and Presence Protocol 2258 (XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22 2259 (work in progress), April 2004. 2261 [30] Rosenberg, J., "Indicating User Agent Capabilities in the 2262 Session Initiation Protocol (SIP)", 2263 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 2265 Authors' Addresses 2267 Ben Campbell (editor) 2269 EMail: ben@nostrum.com 2271 Rohan Mahy 2272 Cisco Systems, Inc. 2273 5617 Scotts Valley Drive, Suite 200 2274 Scotts Valley, CA 95066 2275 USA 2277 EMail: rohan@cisco.com 2278 Cullen Jennings 2279 Cisco Systems, Inc. 2280 170 West Tasman Dr. 2281 MS: SJC-21/2 2282 San Jose, CA 95134 2283 USA 2285 EMail: fluffy@cisco.com 2287 Intellectual Property Statement 2289 The IETF takes no position regarding the validity or scope of any 2290 Intellectual Property Rights or other rights that might be claimed to 2291 pertain to the implementation or use of the technology described in 2292 this document or the extent to which any license under such rights 2293 might or might not be available; nor does it represent that it has 2294 made any independent effort to identify any such rights. Information 2295 on the procedures with respect to rights in RFC documents can be 2296 found in BCP 78 and BCP 79. 2298 Copies of IPR disclosures made to the IETF Secretariat and any 2299 assurances of licenses to be made available, or the result of an 2300 attempt made to obtain a general license or permission for the use of 2301 such proprietary rights by implementers or users of this 2302 specification can be obtained from the IETF on-line IPR repository at 2303 http://www.ietf.org/ipr. 2305 The IETF invites any interested party to bring to its attention any 2306 copyrights, patents or patent applications, or other proprietary 2307 rights that may cover technology that may be required to implement 2308 this standard. Please address the information to the IETF at 2309 ietf-ipr@ietf.org. 2311 Disclaimer of Validity 2313 This document and the information contained herein are provided on an 2314 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2315 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2316 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2317 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2318 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2319 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2321 Copyright Statement 2323 Copyright (C) The Internet Society (2004). This document is subject 2324 to the rights, licenses and restrictions contained in BCP 78, and 2325 except as set forth therein, the authors retain all their rights. 2327 Acknowledgment 2329 Funding for the RFC Editor function is currently provided by the 2330 Internet Society.