idnits 2.17.1 draft-ietf-simple-message-sessions-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 39 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 299: '... MUST have the value of "message". ...' RFC 2119 keyword, line 300: '... used, and MAY be set to any value c...' RFC 2119 keyword, line 302: '... MUST not be repeated in other MSRP ...' RFC 2119 keyword, line 306: '...e protocol field MUST take the value o...' RFC 2119 keyword, line 312: '... the format list SHOULD contain a "*" ...' (166 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 689 has weird spacing: '...nection assoc...' == Line 905 has weird spacing: '...es, the answe...' == Line 1339 has weird spacing: '... rather than ...' == 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: For non-RTP media sessions, The media field specifies the top level MIME media type for the session. For MSRP sessions, the media field MUST have the value of "message". The port field is normally not used, and MAY be set to any value chosen by the endpoint. A port field value of zero has the standard SDP meaning. Non-zero values MUST not be repeated in other MSRP m-lines in the same SDP document. == 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: When an endpoint chooses to close a session, it may have SEND transactions outstanding. For example, it may have send SEND requests to which it has not yet received a response, or it may have received SEND requests that to which it has not responded. Once an endpoint has decided to close the connection, it SHOULD wait for such outstanding transactions to complete. It SHOULD NOT generate any new SEND transactions, and it MAY choose not to respond to any new SEND requests that are received after it decides to close the session. It SHOULD not respond to any new messages that arrive after it signals its intent to close the session. -- 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 (May 17, 2004) is 7282 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC3261' on line 760 == Unused Reference: '6' is defined on line 2032, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2042, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2057, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2082, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 2085, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3') ** Obsolete normative reference: RFC 2396 (ref. '4') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2633 (ref. '7') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 3268 (ref. '8') (Obsoleted by RFC 5246) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '9') ** Obsolete normative reference: RFC 1894 (ref. '10') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 2616 (ref. '11') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '13') (Obsoleted by RFC 3550) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-02 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-3pcc-04 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-01 == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-05 Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group B. Campbell (Ed.) 3 Internet-Draft dynamicsoft 4 Expires: November 15, 2004 May 17, 2004 6 The Message Session Relay Protocol 7 draft-ietf-simple-message-sessions-06 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 15, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document describes the Message Session Relay Protocol (MSRP), a 39 mechanism for transmitting a series of Instant Messages within a 40 session. MSRP sessions are managed using the Session Description 41 Protocol (SDP) offer/answer model carried by a signaling protocol 42 such as the Session Initiation Protocol (SIP). 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2. Motivation for Session-mode Messaging . . . . . . . . . . . 4 48 3. Scope of this Document . . . . . . . . . . . . . . . . . . . 5 49 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 50 5. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 7 51 5.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 7 52 5.2 The Accept Types Attribute . . . . . . . . . . . . . . . . 7 53 5.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 8 54 5.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 9 55 5.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 10 56 5.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 11 57 5.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 11 58 5.8 Connection Negotiation . . . . . . . . . . . . . . . . . . 12 59 6. The Message Session Relay Protocol . . . . . . . . . . . . . 12 60 6.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 12 61 6.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . 13 62 6.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . 14 63 6.2 Connection Direction . . . . . . . . . . . . . . . . . . . 14 64 6.3 MSRP Messages . . . . . . . . . . . . . . . . . . . . . . 15 65 6.3.1 Message Framing . . . . . . . . . . . . . . . . . . . 17 66 6.3.2 Message Examples . . . . . . . . . . . . . . . . . . . 18 67 6.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 19 68 6.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 19 69 6.5.1 Initiating an MSRP session . . . . . . . . . . . . . . 19 70 6.5.2 Handling the initial request . . . . . . . . . . . . . 21 71 6.5.3 Sending Instant Messages on a Session . . . . . . . . 21 72 6.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . 23 73 6.5.5 Managing Session State and Connections . . . . . . . . 23 74 6.6 Delivery Status Notification . . . . . . . . . . . . . . . 24 75 6.6.1 Endpoint DSN Request . . . . . . . . . . . . . . . . . 24 76 6.6.2 DSN generation . . . . . . . . . . . . . . . . . . . . 25 77 6.6.3 Receiving positive DSN . . . . . . . . . . . . . . . . 26 78 6.6.4 Receiving negative DSN . . . . . . . . . . . . . . . . 26 79 6.6.5 DSN headers in MSRP . . . . . . . . . . . . . . . . . 26 80 6.7 Message Fragmentation . . . . . . . . . . . . . . . . . . 28 81 6.7.1 MSRP Usage of message/byteranges . . . . . . . . . . . 28 82 6.8 Method Descriptions . . . . . . . . . . . . . . . . . . . 29 83 6.8.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 6.8.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . 29 85 6.8.3 REPORT . . . . . . . . . . . . . . . . . . . . . . . . 30 86 6.9 Response Code Descriptions . . . . . . . . . . . . . . . . 30 87 6.9.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . 30 88 6.9.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . 30 89 6.9.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . 30 90 6.9.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . 30 91 6.9.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 6.9.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 6.10 Header Field Descriptions . . . . . . . . . . . . . . . 30 94 6.10.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . 31 95 6.10.2 Message-ID . . . . . . . . . . . . . . . . . . . . . 31 96 6.10.3 To-Path . . . . . . . . . . . . . . . . . . . . . . 31 97 6.10.4 From-Path . . . . . . . . . . . . . . . . . . . . . 31 98 6.10.5 Boundary . . . . . . . . . . . . . . . . . . . . . . 31 99 6.10.6 Closing . . . . . . . . . . . . . . . . . . . . . . 31 100 6.10.7 Content-Type . . . . . . . . . . . . . . . . . . . . 32 101 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 32 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 103 8.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 34 104 8.2 MSRP URL Schema . . . . . . . . . . . . . . . . . . . . . 34 105 8.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . 34 106 8.2.2 Character Encoding . . . . . . . . . . . . . . . . . . 34 107 8.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . 35 108 8.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . 35 109 8.2.5 Security Considerations . . . . . . . . . . . . . . . 35 110 8.2.6 Relevant Publications . . . . . . . . . . . . . . . . 35 111 8.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 35 112 8.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . . 35 113 8.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . 35 114 8.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . 35 115 8.4 IANA registration forms for DSN types . . . . . . . . . . 36 116 8.4.1 IANA registration form for address-type . . . . . . . 36 117 8.4.2 IANA registration form for MTA-name-type . . . . . . . 36 118 9. Security Considerations . . . . . . . . . . . . . . . . . . 36 119 9.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 36 120 9.1.1 Sensitivity of Session URLs . . . . . . . . . . . . . 37 121 9.1.2 End to End Protection of IMs . . . . . . . . . . . . . 38 122 9.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . 38 123 9.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . 38 124 10. Changes from Previous Draft Versions . . . . . . . . . . . . 39 125 10.1 draft-ietf-simple-message-sessions-06 . . . . . . . . . 39 126 10.2 draft-ietf-simple-message-sessions-05 . . . . . . . . . 39 127 10.3 draft-ietf-simple-message-sessions-04 . . . . . . . . . 40 128 10.4 draft-ietf-simple-message-sessions-03 . . . . . . . . . 40 129 10.5 draft-ietf-simple-message-sessions-02 . . . . . . . . . 40 130 10.6 draft-ietf-simple-message-sessions-01 . . . . . . . . . 41 131 10.7 draft-ietf-simple-message-sessions-00 . . . . . . . . . 41 132 10.8 draft-campbell-simple-im-sessions-01 . . . . . . . . . . 42 133 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 134 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 135 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 136 13.1 Normative References . . . . . . . . . . . . . . . . . . . 42 137 13.2 Informational References . . . . . . . . . . . . . . . . . 43 138 Author's Address . . . . . . . . . . . . . . . . . . . . . . 44 139 Intellectual Property and Copyright Statements . . . . . . . 45 141 1. Introduction 143 The MESSAGE [12] extension to SIP [2] allows SIP to be used to 144 transmit instant messages. Instant messages sent using the MESSAGE 145 method are normally independent of each other. This approach is 146 often called page-mode messaging, since it follows a model similar to 147 that used by many two-way pager devices. Page-mode messaging makes 148 sense for instant message exchanges where a small number of messages 149 occur. Endpoints may treat page-mode messages as if they took place 150 in an imaginative session, but there is no formal relationship 151 between one message and another. 153 There are also applications in which it is useful for instant 154 messages to be formally associated in a session. For example, a user 155 may wish to join a text conference, participate in the conference for 156 some period of time, then leave the conference. This usage is 157 analogous to regular media sessions that are typically initiated, 158 managed, and terminated using SIP. We commonly refer to this model 159 as session-mode messaging. 161 One of the primary purposes of SIP and SDP (Section 5) is the 162 management of media sessions. Session-mode messaging can be thought 163 of as a media session like any other. This document describes the 164 motivations for session-mode messaging, the Message Session Relay 165 Protocol, and the use of the SDP offer/answer mechanism for managing 166 MSRP session. 168 2. Motivation for Session-mode Messaging 170 Message sessions offer several advantages over page-mode messages. 171 For message exchanges that include more than a small number of 172 message transactions, message sessions offer a way to remove 173 messaging load from intervening SIP proxies. For example, a minimal 174 session setup and tear-down requires one INVITE/ACK transaction, and 175 one BYE transaction, for a total of 5 SIP messages. Normal SIP 176 request routing allows for all but the initial INVITE transaction to 177 bypass any intervening proxies that do not specifically request to be 178 in the path for future requests. Session-mode messages never cross 179 the SIP proxies themselves. 181 Each page-mode message involves a complete SIP transaction, that is, 182 a request and a response. Any page-mode message exchange that 183 involves more than 2 MESSAGE requests will generate more SIP requests 184 than a minimal session initiation sequence. Since MESSAGE is 185 normally used outside of a SIP dialog, these requests will typically 186 traverse the entire proxy network between the endpoints. 188 Due to network congestion concerns, the MESSAGE method has 189 significant limitations in message size, a prohibition against 190 overlapping requests, etc. Much of this has been required because of 191 perceived limitations in the congestion-avoidance features of SIP 192 itself. Work is in progress to mitigate these concerns. 194 However, session-mode messages are always sent over reliable, 195 congestion-safe transports. Therefore, there are no restrictions on 196 message sizes. There is no requirement to wait for acknowledgement 197 before sending another message, so that message transactions can be 198 overlapped. 200 Message sessions allow greater efficiency for secure message 201 exchanges. The SIP MESSAGE request inherits the S/MIME features of 202 SIP, allowing a message to be signed and/or encrypted. However, this 203 approach requires public key operations for each message. With 204 session-mode messaging, a session key can be established at the time 205 of session initiation. This key can be used to protect each message 206 that is part of the session. This requires only symmetric key 207 operations for each subsequent IM, and no additional certificate 208 exchanges are required after the initial exchange. The establishment 209 of the session key can be done using standard techniques that apply 210 to voice and video, in addition to instant messaging. 212 Finally, SIP devices can treat message sessions like any other media 213 sessions. Any SIP feature that can be applied to other sorts of 214 media sessions can equally apply to message sessions. For example, 215 conferencing [14], third party call control [15], call transfer [16], 216 QoS integration [17], and privacy [18] can all be applied to message 217 sessions. 219 Messaging sessions can also reduce the overhead in each individual 220 message. In page-mode, each message needs to include all of the SIP 221 headers that are mandated by RFC 3261 [2]. However, many of these 222 headers are not needed once a context is established for exchanging 223 messages. As a result, messaging session mechanisms can be designed 224 with significantly less overhead. 226 3. Scope of this Document 228 This document describes the use of MSRP between endpoints. It does 229 not specify the use of intermediaries, nor does it prohibit such use. 230 We expect an extension to this specification to define MSRP 231 intermediaries and their use. 233 This document describes the use of MSRP over TCP. MSRP may be used 234 over other congestion-controlled protocols such as SCTP. However, 235 the specific bindings for other such protocols are outside the scope 236 of this document. 238 4. Protocol Overview 240 The Message Session Relay Protocol (MSRP) provides a mechanism for 241 transporting session-mode messages between endpoints. MSRP uses 242 connection oriented, reliable network transport protocols only. It 243 can operate in the presence of many NAT and firewall environments, as 244 it allows participants to positively associate message sessions with 245 specific connections, and does not depend upon connection source 246 address, which may be obscured by NATs. 248 MSRP uses the following primitives: 250 SEND: Used to send message content from one endpoint to another. 252 VISIT: Used by an endpoint to establish a session association to the 253 host endpoint. 255 REPORT Used to carry MSRP message report/receipt information. 257 Assume A is an endpoint that wishes to establish a message session, 258 and B is the endpoint invited by A. A invites B to participate in a 259 message session by sending a URL. This URL is temporary, and must 260 not duplicate any URL that A has offered for other active sessions. 262 B then responds to the invitation with a URL of its own. This 263 informs A that B has accepted the session, and will accept messages 264 at that URL. A connects to B, and sends a request to establish the 265 session. A and B may now exchange messages using SEND requests on 266 the connection. Each party targets such requests to the peer's URL. 268 When either party wishes to end the session, it informs its peer 269 using the appropriate mechanism of the chosen signaling protocol, 270 such as a SIP BYE request. 272 The end to end case looks something like the following. (Note that 273 the example shows a logical flow only; syntax will come later in this 274 document.) 276 A->B (SDP): offer (msrp://A/123) 277 B->A (SDP): answer(msrp://B/456) 278 A->B (TCP) connect 279 A->B (MSRP): SEND (msrp://B/456) 280 B->A (MSRP): 200 OK 281 B->A (MSRP): SEND (msrp://A/123) 282 A->B (MSRP): 200 OK 284 5. SDP Offer-Answer Exchanges for MSRP Sessions 286 MSRP sessions will typically be initiated using the Session 287 Description Protocol (SDP) [1] offer-answer mechanism, carried in the 288 Session Initiation Protocol (SIP) [2] or any other protocol 289 supporting it. 291 5.1 Use of the SDP M-line 293 The SDP "m"-line takes the following form: 295 m= 297 For non-RTP media sessions, The media field specifies the top level 298 MIME media type for the session. For MSRP sessions, the media field 299 MUST have the value of "message". The port field is normally not 300 used, and MAY be set to any value chosen by the endpoint. A port 301 field value of zero has the standard SDP meaning. Non-zero values 302 MUST not be repeated in other MSRP m-lines in the same SDP document. 304 The protocol field is used only to designate MSRP. The underlying 305 transport protocol is determined in the MSRP URL, as described below. 306 Therefore, the protocol field MUST take the value of "msrp". 308 The format list list is ignored for MSRP. This is because MSRP 309 formats are specified as MIME content types, which are not convenient 310 to encode in the SDP format list syntax. Instead, the allowed 311 formats are negotiated using "a"-line attributes. For MSRP sessions, 312 the format list SHOULD contain a "*" character, and nothing else. 314 The port field in the M-line is not used to determine the port to 315 which to connect. Rather, the actual port is determined by the the 316 MSRP URL (Section 6.1) in the path attribute. However, a port value 317 of zero has the normal SDP meaning. 319 The following example illustrates an m-line for a message session, 320 where the endpoint is willing to accept root payloads of message/ 321 cpim, plain text or HTML. The second two types could either be 322 presented as the root body, or could be contained within message/cpim 323 bodies. 325 m=message 9999 msrp * 327 5.2 The Accept Types Attribute 329 MSRP can carry any MIME encoded payload. Endpoints specify MIME 330 content types that they are willing to receive in the accept types 331 "a"-line attribute. This attribute has the following syntax: 333 accept-types = accept-types-label ":" format-list 334 accept-types-label = "accept-types" 335 format-list = format-entry *( SP 336 format-entry) format-entry = (type "/" subtype) / ("*") 337 type = token 338 subtype = token 340 SDP offers for MSRP sessions MUST include an accept-types attribute. 341 SDP answers MUST also include the attribute, which MUST contain 342 either the same list as in the offer or a subset of that list. 344 A "*" entry in the accept-types attribute indicates that the sender 345 may attempt to send messages with media types that have not been 346 explicitly listed. If the receiver is able to process the media 347 type, it does so. If not, it will respond with a 415. Note that all 348 explicit entries SHOULD be considered preferred over any non-listed 349 types. This feature is needed as, otherwise, the list of formats for 350 rich IM devices may be prohibitively large. 352 The accept-types attribute may include container types, that is, mime 353 formats that contain other types internally. If compound types are 354 used, the types listed in the accept-types attribute may be used both 355 as the root payload, or may be wrapped in a listed container type. 356 (Note that the container type MUST also be listed in the accept-types 357 attribute.) 359 5.3 MIME Wrappers 361 The MIME content-types in the accept-types attribute will often 362 include container types; that is, types that contain other types. 363 For example, "message/cpim" or "multipart/mixed." Occasionally an 364 endpoint will need to specify a MIME body type that can only be used 365 if wrapped inside a listed container type. 367 Endpoints MAY specify MIME types that are only allowed to be wrapped 368 inside compound types using the "accept-wrapped-types" attribute in 369 an SDP a-line. This attribute has the following syntax: 371 accept-wrapped-types = wrapped-types-label ":" format-list 372 wrapped-types-label = "accept-wrapped-types" ` 374 The format-list element has the identical syntax as defined for the 375 accept-types attribute. The semantics for this attribute are 376 identical to those of the accept-types attribute, with the exception 377 that the specified types may only be used when wrapped inside 378 containers. Only types listed in accept-types may be used as the 379 "root" type for the entire body. Since any type listed in 380 accept-types may be used both as a root body, and wrapped in other 381 bodies, format entries from the m-line SHOULD NOT be repeated in this 382 attribute. 384 This approach does not allow for specifying distinct lists of 385 acceptable wrapped types for different types of containers. If an 386 endpoint understands a MIME type in the context of one wrapper, it is 387 assumed to understand it in the context of any other acceptable 388 wrappers, subject to any constraints defined by the wrapper types 389 themselves. 391 The approach of specifying types that are only allowed inside of 392 containers separately from the primary payload types allows an 393 endpoint to force the use of certain wrappers. For example, a 394 CPIM gateway device may require all messages to be wrapped inside 395 message/cpim bodies, but may allow several content types inside 396 the wrapper. If the gateway were to specify the wrapped types in 397 the accept-types attribute, its peer could choose to use those 398 types without the wrapper. 400 5.4 URL Negotiations 402 Each endpoint in an MSRP session is identified by a URL. These URLs 403 are negotiated in the SDP exchange. Each SDP offer or answer MUST 404 contain one or more MSRP URL in a path attribute. This attribute has 405 the following syntax: 407 a=path ":" MSRP_URL *(SP MSRP_URL) 409 where MSRP_URL is an MSRP or MSRPS URL as defined in Section 6.1. 410 MSRP URLs included in an SDP offer or answer MUST include an explicit 411 port number. 413 A device uses the URL to determine a host address and port when 414 connecting, and to identify the target when sending messages. For 415 MSRP sessions, the address field in the C-line is not relevant, and 416 MUST be ignored. The port field in the M-line MUST be ignored if 417 non-zero. Zero values have the usual meaning for SDP. 419 A device will further use the URL to determine the transport 420 protocol, and whether to use TLS. This information is encoded in the 421 URL scheme. 423 Both offerer and answerer store the path values received from the 424 peer. For a given endpoint, the local URL is the URL that the 425 endpoint put into a SDP path attribute to represent itself. The peer 426 URL is the URL sent by the peer to represent itself. If the path 427 attribute received from the peer contains more than one URL, then the 428 peer URL is the rightmost, while the leftmost entry represents the 429 adjacent hop. If only one entry is present, then it is both the peer 430 and adjacent URL. The remote path is the entire path attribute value 431 received from the peer. 433 The following example shows an SDP offer with a session URL of 434 "msrp://a.example.com:7394/2s93i" 436 v=0 437 o=someuser 2890844526 2890844527 IN IP4 alice.example.com 438 s= 439 c=IN IP4 alice.example.com m=message 9999 msrp * 440 a=accept-types:text/plain 441 a=path:msrp://a.example.com:7394/2s93i 443 The rightmost URI in the path attribute MUST identify the endpoint 444 that generated the SDP document, or some other location where that 445 endpoint wishes to receive messages associated with the session. It 446 MUST MUST be a temporary URL assigned just for this particular 447 session, and MUST NOT duplicate any URL in use for any other session 448 in which the endpoint is currently participating. Further, it SHOULD 449 be hard to guess, and protected from eavesdroppers. This will be 450 discussed in more detail in Section 9. 452 5.5 Path Attributes with Multiple URLs 454 As mentioned previously, this document describes MSRP for 455 peer-to-peer scenarios, that is, when no relays are used. However, 456 we expect a separate document to describe the use of relays in the 457 near future. In order to allow an MSRP device that only implements 458 the core specification to interoperate with devices that use relays, 459 this document must include a few assumptions about how relays work. 461 An endpoint that uses one or more relays will indicate that by 462 putting a URL for each device in the relay chain into the SDP path 463 attribute. The final entry would point to the endpoint itself. The 464 other entries would indicate each proposed relay, in order. The 465 first entry would point to the first relay in the chain; that is, the 466 relay to which the peer device, or a relay operation on its behalf, 467 should connect. 469 Endpoints that do not wish to insert a relay, including those that do 470 not support relays at all, will put exactly one URL into the path 471 attribute. This URL represents both the endpoint for the session, 472 and the connection point. 474 While endpoints that implement only this specification will never 475 introduce a relay, they will need to be able to interoperate with 476 other endpoints that do use relays. Therefore, they MUST be prepared 477 to receive more than one URL in the SDP path attribute. When an 478 endpoint receives more than one URL in a path header, only the first 479 entry is relevant for purposes of resolving the address and port, and 480 establishing the network connection, as it describes the first 481 adjacent hop. 483 If an endpoint puts more than one URL in a path attribute, the final 484 URL in the path (the peer URL) attribute MUST exhibit the uniqueness 485 properties described above. Uniqueness requirements for other 486 entries in the attribute are out of scope for this document. 488 5.6 Updated SDP Offers 490 To do: Revisit this section based on new connection management rules 492 MSRP endpoints may sometimes need to send additional SDP exchanges 493 for an existing session. They may need to send periodic exchanges 494 with no change to refresh state in the network, for example, SIP 495 timers. They may need to change some other stream in a session 496 without affecting the MSRP stream, or they may need to change an MSRP 497 stream without affecting some other stream. 499 If either party wish to send an SDP document that changes nothing at 500 all, then it MUST have the same o-line version as in the previous 501 exchange. 503 5.7 Example SDP Exchange 505 Endpoint A wishes to invite Endpoint B to a MSRP session. A offers 506 the following session description: 508 v=0 509 o=usera 2890844526 2890844527 IN IP4 alice.example.com 510 s= 511 c=IN IP4 alice.example.com t=0 0 512 m=message 9999 msrp * 513 a=accept-types: message/cpim text/plain text/html 514 a=path:msrp://alice.example.com:7394/2s93i9 516 B responds with its own URL: 518 v=0 519 o=userb 2890844530 2890844532 IN IP4 bob.example.com 520 s= 521 c=IN IP4 dontlookhere 522 t=0 0 523 m=message 9999 msrp * 524 a=accept-types:message/cpim text/plain 525 a=path:msrp://bob.example.com:8493/si438ds 527 A immediately sends some MSRP traffic: Either a VISIT request (if it 528 has no immediate content to send) or a SEND request (if it does have 529 immediate content.) Afterwards, A and B may now exchange IMs by 530 executing SEND transactions. 532 5.8 Connection Negotiation 534 Previous versions of this document included a mechanism to negotiate 535 the direction for any required TCP connection. The mechanism was 536 loosely based on COMEDIA [20]work being done in the MMUSIC working 537 group. The primary motivation was to allow MSRP sessions to succeed 538 in situations where the offerer could not accept connections but the 539 answerer could. For example, the offerer might be behind a NAT, 540 while the answerer might have a globally routable address. 542 The SIMPLE working group chose to remove that mechanism from MSRP, as 543 it added a great deal of complexity to connection management. 544 Instead, MSRP now specifies default connection directions. 546 6. The Message Session Relay Protocol 548 The Message Session Relay Protocol (MSRP) is a text based, message 549 oriented protocol for the transfer of instant messages in the context 550 of a session. MSRP uses the UTF8 character set. 552 MSRP messages MUST be sent over a reliable, congestion-controlled, 553 connection-oriented transport protocol. This document specifies the 554 use of MSRP over TCP. Other documents may specify bindings for other 555 such protocols. 557 6.1 MSRP URLs 559 An MSRP URL follows a subset of the URL syntax in Appendix A of 560 RFC2396 [4], with a scheme of "msrp": 562 msrp_url = msrp-scheme "://" [userinfo "@"] hostport ["/" 563 resource] 564 msrp-scheme = "msrp" / "msrps" / "smsrp" / "smsrps" 565 resource = 1*unreserved 567 The constructions for "userinfo", "hostport", and "unreserved" are 568 detailed in RFC2396 [4]. 570 An MSRP URL server part identifies a participant in an MSRP session. 571 If the server part contains a numeric IP address, it MUST also 572 contain a port. The resource part identifies a particular session 573 the participant. The absence of the resource part indicates a 574 reference to an MSRP host device, but does not specifically refer to 575 a particular session resource. 577 The underlying transport protocol and the protection level (that is, 578 whether TLS is used) is determined by the URL scheme: 580 msrp MSRP over TCP without TLS. 581 msrps MSRP over TCP with TLS. 582 smsrp MSRP over SCTP without TLS. 583 smsrps MSRP over SCTP with TLS. 585 This document only describes the binding for MSRP over TCP. The 586 schema for SCTP are reserved herein, but binding MSRP to SCTP is 587 out of scope for this document. 589 MSRP has an IANA registered recommended port defined in Section 8.1. 590 This value is not a default, as the URL process described herein will 591 always explicitly resolve a port number. However, the URLs SHOULD be 592 configured so that the recommended port is used whenever appropriate. 593 This makes life easier for network administrators who need to manage 594 firewall policy for MSRP. 596 The server part will typically not contain a userinfo component, but 597 MAY do so to indicate a user account for which the session is valid. 598 Note that this is not the same thing as identifying the session 599 itself. If a userinfo component exists, MUST be constructed only 600 from "unreserved" characters, to avoid a need for escape processing. 601 Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo 602 part MUST NOT contain password information. 604 The following is an example of a typical MSRP URL: 606 msrp://host.example.com:8493/asfd34 608 6.1.1 MSRP URL Comparison 610 MSRP URL comparisons MUST be performed according to the following 611 rules: 613 1. The schema must match exactly. 615 2. The host part is compared as case insensitive. 617 3. If the port exists explicitly in either URL, then it must match 618 exactly. An URL with an explicit port is never equivalent to 619 another with no port specified. 621 4. The resource part is compared as case insensitive. A URL without 622 a resource part is never equivalent to one that includes a 623 resource part. 625 5. Userinfo parts are not considered for URL comparison. 627 Path normalization is not relevant for MSRP URLs. Escape 628 normalization is not required, since the relevant parts are limited 629 to unreserved characters. 631 6.1.2 Resolving MSRP Host Device 633 An MSRP host device is identified by the server part of an MSRP URL. 635 If the server part contains a numeric IP address and port, they MUST 636 be used as listed. 638 If the server part contains a host name and a port, the connecting 639 device MUST determine a host address by doing an A or AAAA DNS query, 640 and use the port as listed. 642 If a connection attempt fails, the device SHOULD attempt to connect 643 to the addresses returned in any additional A or AAAA records, in the 644 order the records were presented. 646 This process assumes that the connection port is always known 647 prior to resolution. This is always true for the MSRP URL uses 648 described in this document, that is, URLs always created and 649 consumed by automata, rather than by humans. The introduction of 650 relays may create situations where this is not the case. For 651 example, the MSRP URL that a user enters into a client to 652 configure it to use a relay may be intended to be easily 653 remembered and communicated by humans, and therefore is likely to 654 omit the port. Therefore, the relay specification may describe 655 additional steps to resolve the port number. 657 6.2 Connection Direction 659 When SIP is used as the signaling protocol, the device sending the 660 initial request to communicate is responsible for opening the 661 connection. In most cases, the device sends an offer in an INVITE or 662 UPDATE request, and gets a response in a 2xx or 18x response. In 663 this case, the inviter opens a connection after receiving the 664 response. This can be done in parallel to sending an ACK request. 666 Another, less common scenario is when the inviter sends an INVITE 667 request with no offer, and the invitee sends an offer in the 668 response. In this case, the inviter opens the connection after it 669 receives the offer. It waits for successful connection prior to 670 sending the answer in the SIP ACK request. 672 Open Issue: The delayed offer is not likely to work in SIP, as the 673 invitee is almost certainly to propose RTP rather than MSRP. We 674 either need to do more work to specify how an endpoint that 675 supports both handles a delayed offer, or remove any reference to 676 this. 678 Other signaling protocols may use other approaches. Unless specific 679 behavior is specified for a particular signaling protocol, the 680 offerer is always responsible for opening the connection. 681 Open Issue: Should we put in a hook to allow SDP extensions to be 682 used to determine connection direction? For example, if COMEDIA 683 evolves to a point where it is workable for MSRP, why not allow 684 using it? 686 In all cases, the connecting endpoint connects to the device and port 687 indicated by the connection URL, using the protocol and protection 688 level specified by the URL scheme. If it determines that it already 689 has a connection associated with a URL that has a matching scheme, 690 host part, and port, it SHOULD reuse that connection rather than 691 opening a new one. Once a connection has succeeded, or the decision 692 to reuse a connection has been made, the connecting device MUST 693 immediately send an MSRP request in the context of the new session. 694 This message allows the device accepting the connection to associate 695 the MSRP session with the connection. This MAY be a SEND request, if 696 the device has content to send immediately, or a VISIT request. 698 Open Issue: We are still discussing whether the offerer or the 699 answerer should be responsible for connecting. 701 Either endpoint MAY tear down a connection when it no longer has any 702 active or proposed sessions associated with the connection. 704 6.3 MSRP Messages 706 MSRP messages are either requests or responses. Requests and 707 responses are distinguished from one another by the first line. The 708 first line of a Request takes the form of the request-start entry 709 below. Likewise, the first line of a response takes the form of 710 response-start. The syntax for an MSRP message is as follows: 712 msrp-message = request-start/response-start *(header CRLF) 713 [CRLF body] Closing 714 request-start = "MSRP" SP Method CRLF 715 response-start = "MSRP" SP Status-Code SP 716 Reason CRLF 718 Method = SEND / VISIT / other-method 719 other-method = 1*(ALPHA) 720 header = Tran-ID / Message-ID/ Session-URL / Content-Types / 721 From-Path / To-Path / Message-Receipt / Receipt-ID / 722 Byte-Range / Boundary 724 Status-Code = 200 ;Success 725 / 400 ;Bad Request 726 / 403 ;Forbidden 727 / 415 ;Unsupported Content Type 728 / 426 ;Upgrade Required 729 / 481 ;No session 730 / 506 ;duplicate session 731 / other-status ; extension codes 732 other-status = 3(NUM) 734 Reason = token ; Human readable text describing status 735 Tran-ID = "Tr-ID" ":" token 736 Message-ID = "Message-ID" ":" token 738 Boundary = "Boundary" ":" 0*65(bchars) bcharsnospace 739 bcharsnospace= DIGIT / ALPHA / "'" / "(" / ")" / 740 "+" / "_" / "," / "-" / "." / 741 "/" / ":" / "=" / "?" 742 bchars = bcharsnospace / " " 744 Closing = "-------" Boundary Continue-Flag CRLF ; Boundary must match Boundary header field value 745 Continue-Flag = "+" / "$" 747 Content-Type = "Content-Type" ":" media-type 748 media-type = type "/" subtype *( ";" parameter ) 749 type = token 750 subtype = token 751 parameter = attribute "=" value 752 attribute = token 753 value = token | quoted-string 755 To-Path = "To-Path" ":" msrp_url *(SP msrp_url) 756 From-Path = "From-Path" ":" msrp_url *(SP msrp_url) 758 Message-Receipt = "Message-Receipt" ":" message-receipt-spec ( SEMI receipt-type ) 759 message-receipt-spec = "negative" / "none" / "all" 760 receipt-type = "receipt-type" "=" media-type; is detailed in [RFC3261] 762 Byte-Range = "Byte-Range" ":" byte-range-spec 763 byte-range-spec = first-byte "-" last-byte 764 first-byte = 1*DIGIT 765 last-byte = 1*DIGIT 766 Receipt-ID = "Receipt-ID" ":" token 768 All requests and responses MUST contain at least a TR-ID header 769 field. All requests must also contain the To-Path and From-Path, 770 Message-ID, and Boundary header fields, as well as the Closing field. 771 Messages MAY contain other fields, depending on the method or 772 response code. 774 6.3.1 Message Framing 776 MSRP messages are framed using the Boundary header field value. The 777 Boundary header field contains a boundary string. The Closing field 778 contains the same boundary string with a prefix of "-------" (seven 779 hyphens) and single character suffix representing a continuation 780 flag. 782 The closing field is constructed to allow for simple high speed 783 parsing. The use of seven hyphens forces for of them to be aligned 784 on a 32 bit boundary. A parser can quickly scan for the closing by 785 looking for a 32 bit value equivalent to "----". Once this word is 786 found, the scanner can carefully check and see if this is the 787 boundary it is looking for or just some random data. The boundary 788 string SHOULD have at least 16 bits of randomness in it. For 789 example, a valid boundary would be "Boundary:6ea7" where the 6ea7 was 790 a randomly chosen four digit hexadecimal number. This reduces the 791 chance of the boundary string colliding with content data. 793 The boundary string MUST NOT occur inside the body itself. The 794 sender MUST ensure that a collision does not occur. 796 Since the message fragmentation section (Section 6.7) of this 797 document says that large content should be sent in parcels, it 798 should always be possible to check for boundary collisions prior 799 to sending a parcel. Even in the case of streaming content, where 800 the sender does not have all of the content prior to sending the 801 first message, the chunk size should be small enough so that it is 802 practical to check each chunk for collisions prior to sending. 804 The MSRP boundary strings are distinct and independent from any MIME 805 boundaries that may exist in the message body. For example, if the 806 body is of a multipart type, the MIME headers will include a 807 multipart boundary. This multipart boundary MUST NOT be the same 808 string used in the MSRP Boundary header field. 810 The Closing field contains both the message boundary string and the 811 Continuation-Flag. The Continuation-Flag indicates whether the 812 entire content has been sent or not. Normally, the flag takes the 813 value of "$" (dollar sign) to indicate that all content has been 814 sent, or "+" to indicate that there is additional content that has 815 not yet been sent. 817 The term "content" in this context means a complete logical instant 818 message, from the perspective of the user. The content could be a 819 short text message, a long file transfer, etc. The logical instant 820 message does not necessarily correspond one-to-one with a physical 821 MSRP message. For example, a video message may be one logical 822 instant message from the users' perspective, but it will generally be 823 sent as a series of parcels. Each parcel would be sent as the 824 payload in one physical MSRP SEND request. All the requests except 825 the final one would contain "+" in the continuation-flag to indicate 826 that the content is not complete. The final message would contain 827 "$" to indicate that complete content has been sent. 829 The sender MUST NOT include a completion-flag of "+" if the payload 830 MIME type does not support content fragmentation. 832 6.3.2 Message Examples 834 The following is an example MSRP message sending a text payload: 836 MSRP SEND 837 Boundary: dkei38sd 838 To-Path:msrp://alice.atlanta.com:7777/iau39 839 From-Path:msrp://bob.atlanta.com:8888/9di4ea 840 TR-ID: 456 841 Message-ID: 456 842 Content-Type: "text/plain" 844 Hi, Alice! I'm Bob! 845 -------dkei38sd$ 847 The following is an example of an MSRP message containing a MIME type 848 that uses an internal boundary (not to be confused with the MSRP 849 boundary): 851 MSRP SEND 852 Boundary:a38sdo To-Path:msrp://bob.atlanta.com:8888/9di4ea 853 From-Path:msrp:alice.atlanta.com:7777/iau39 854 TR-ID: 456 855 Message-ID: 456 856 Content-Type: multipart/byteranges;boundary=abcde 858 --abcde 859 Content-Type: image/jpeg 860 Content-range: bytes 0-*/50270 861 [large jpg file] 862 --abcde-- 863 -------a38sdo$ 865 6.4 MSRP Transactions 867 An MSRP transaction consists of exactly one request and one response. 868 A response matches a transaction if the following are true: 870 It shares the same TR-ID value. 871 It is received on the same connection on which the request was 872 sent. 873 The To-Path has a single entry, which matches the response 874 recipient's local URI for the session. 876 Endpoints MUST select TR-ID header field values in requests so that 877 they are not repeated by the same endpoint in scope of the given 878 session. TR-ID values SHOULD be globally unique. The TR-ID space of 879 each endpoint is independent of that of its peer. Endpoints MUST NOT 880 infer any semantics from the TR-ID header field beyond what is stated 881 above. In particular, TR-ID values are not required to follow any 882 sequence. 884 MSRP Transactions complete when a response is received, or after a 885 timeout interval expires with no response. Endpoints MUST treat such 886 timeouts in exactly the same way they would treat a 500 response. 887 The timeout interval SHOULD be 30 seconds, but other values may be 888 established as a matter of local policy. 890 6.5 MSRP Sessions 892 AN MSRP session is a context in which a series of instant messages 893 are exchanged, using SEND requests. A session has two endpoints, 894 identified by MSRP URLs. 896 6.5.1 Initiating an MSRP session 898 When an endpoint wishes to engage a peer in a message session, it 899 invites the peer to communicate using an SDP offer, carried over SIP 900 or some other protocol supporting the SDP offer/answer model. For 901 the purpose of this document, we will refer to the endpoint choosing 902 to initiate communication as the offerer, and the peer being invited 903 as the answerer. 905 Under normal circumstances, the answerer MUST be prepared to accept 906 a connection from the offerer. 908 The offerer MUST perform the following steps: 910 1. Construct a MSRP URL to serve as the local URL. 912 2. Construct an SDP offer as described in Section 5, including the 913 list of allowed IM payload formats in the accept-types attribute. 914 The offerer puts its local URL into the path attribute, as 915 described in Section 5.4. This URL becomes the offerer's local 916 path. 918 3. Send the SDP offer using the normal processing for the signaling 919 protocol. 921 If the answerer chooses to participate, it MUST perform the following 922 steps: 924 1. Store the contents of the offered sdp path attribute as the 925 remote path for he session. 927 2. Construct a MSRP URL that resolves to itself. Save this as the 928 local URL for the session. 930 3. Listen for a connection on the transport, address, and port 931 described by the local URL. 933 4. Send a SDP answer via the signaling protocol, according to the 934 following rules: 936 1. The C-line is copied unmodified from the offer. 938 2. The accept-types attribute contains the SEND payload media 939 types that the answerer is willing to accept. The 940 accept-types attribute in the answer MUST be either the same 941 as that of the offer, or a subset. 943 3. The path attribute contains the answerer's local URL. 945 Again, this document assumes that no relays are introduced. If 946 the answerer were to introduce one or more relay, it would add the 947 appropriate URLs to the path attribute in the SDP answer. It 948 would not need to listen for a connection, as the first relay in 949 its path would have that honor. 951 When the offerer receives the answer, it MUST perform the following 952 steps: 954 1. Save the path attribute contents from the SDP answer as the 955 remote path. 957 2. Designate the first entry in the remote path as the adjacent-hop 958 URL. 960 3. Check to see if a connection already exists that is associated 961 with URL that matches the scheme, host part, and port of the 962 adjacent-hop URL. If such a connection exists, the device SHOULD 963 reuse it, rather than opening a new connection. 965 4. If no matching connection exists, attempt to open a connection to 966 the adjacent hop using the transport, address, port, and 967 protection mode designated by the adjacent-hop URL. 969 5. If the connection succeeds, or if a connection is reused, 970 immediately send a MSRP request to the opposite peer. This 971 SHOULD be a visit request, but MAY be a SEND request if the 972 endpoint has legitimate content to send. 974 6.5.2 Handling the initial request 976 An MSRP device that accepts a network connection will receive an 977 immediate MSRP request from the connecting endpoint. This may be a 978 SEND or VISIT request. When an endpoint receives such a request, it 979 MUST perform the following procedures: 981 1. Check if state exists for a session with a local URL that matches 982 the To-Path header field value of the VISIT request. If so, and 983 if no previous request has been received for that URL on a 984 different connection, then return a 200 response, and save state 985 associating the first URL in the From-Path header field with the 986 connection on which the request was received . 988 2. If the state exists, and a matching request has occurred on a 989 different connection, return a 506 response and do not change 990 session state in any way. 992 3. If no matching state exists, return a 481 response, and do not 993 change session state in any way. 995 6.5.3 Sending Instant Messages on a Session 997 Once a MSRP session has been established, either endpoint may send 998 instant messages to its peer using the SEND method. When an endpoint 999 wishes to do so, it MUST construct a SEND request according to the 1000 following process: 1002 1. Insert a To-Path header field containing the path to the opposite 1003 endpoint, in order from left to right. 1005 2. Insert a From-Path header field containing the local URL. 1007 3. Insert the message payload in the body, and the media type in the 1008 Content-Type header field. The media type MUST match one of the 1009 types in the format list negotiated in the SDP exchange. If a 1010 "*" was present in the accept-types attribute, then the media 1011 type SHOULD match one of the explicitly listed entries, but MAY 1012 be any other arbitrary value. 1014 4. Set the TR-ID and Message-ID header fields to a unique value. 1015 The sender MAY set these fields to the same value. 1017 5. Send the request on the connection associated with the session. 1019 6. If a 2xx response code is received, the transaction was 1020 successful. 1022 7. If a 415 response is received, this indicates the recipient is 1023 unable or unwilling to process the media type. The sender SHOULD 1024 NOT attempt to send that particular media type again in the 1025 context of this session. 1027 8. If any other response code is received, or if the transaction 1028 times out, the endpoint SHOULD assume the session has failed, 1029 either tear down the session, or attempt to re-establish the 1030 session by sending an updated SDP offer proposing a new 1031 connection. If a new connection is established, the endpoint MAY 1032 choose to resend the content on the new connection. 1034 Open Issue: Do we need to create a duplicate mechanism to suppress 1035 duplicate messages when a new connection is established in this 1036 fashion? mechanism? List consensus seems to indicate we do. We 1037 may need to specify that the tr-id space spans a sequence of 1038 connections if they are associated with same stream, and of 1039 course, specify what it means for a stream to span connections. 1041 When an endpoint receives a SEND request, it MUST perform the 1042 following steps. 1044 1. Check that it has state for a session with a local URL matching 1045 the To-Path value. If no matching session exists, return a 481 1046 response. 1048 2. Determine that it understands the media type in the body, if any 1049 exists. 1051 3. If it does, return a 200 response and render the message to the 1052 user. The method of rendering is a matter of local policy. If 1053 the message contained no body at all, the endpoint should quietly 1054 ignore it. 1056 4. If it does not understand the media type, return a 415 response. 1057 The endpoint MUST NOT return a 415 response for any media type 1058 for which it indicated support in the SDP exchange. 1060 6.5.4 Ending a Session 1062 When either endpoint in an MSRP session wishes to end the session, it 1063 first signals its intent using the normal processing for the 1064 signaling protocol. For example, in SIP, it would send a BYE request 1065 to the peer. After agreeing to end the session, the host endpoint 1066 MUST release any resources acquired as part of the session. 1068 Each peer MUST destroy all local state for the session. This 1069 involves completely removing the state entry for the session and 1070 invalidating the session URL. 1072 If no other sessions are using the connection, the endpoint that 1073 opened it SHOULD tear it down. However, the passive party MAY tear 1074 down an unused connection after a locally configured timeout period. 1076 When an endpoint chooses to close a session, it may have SEND 1077 transactions outstanding. For example, it may have send SEND 1078 requests to which it has not yet received a response, or it may have 1079 received SEND requests that to which it has not responded. Once an 1080 endpoint has decided to close the connection, it SHOULD wait for such 1081 outstanding transactions to complete. It SHOULD NOT generate any new 1082 SEND transactions, and it MAY choose not to respond to any new SEND 1083 requests that are received after it decides to close the session. It 1084 SHOULD not respond to any new messages that arrive after it signals 1085 its intent to close the session. 1087 When an endpoint is signaled of its peer's intent to close a session, 1088 it SHOULD NOT initiate any more SEND requests. It SHOULD wait for 1089 any outstanding transactions that it initiated to complete, and it 1090 SHOULD attempt respond to any open SEND transactions received prior 1091 to being signaled. 1093 It is not possible to completely eliminate the chance of a session 1094 terminating with incomplete SEND transactions. When this occurs, the 1095 endpoint SHOULD clearly inform the user that the messages may not 1096 have been delivered. 1098 6.5.5 Managing Session State and Connections 1100 A MSRP session is represented by state at each endpoint, identified 1101 by the local URL and remote path. An active session also has an 1102 associated network connection. 1104 If the connection fails for any reason, the device MUST invalidate 1105 the session state for all sessions using the connection. Once a 1106 connection is dropped, any associated session state MUST NOT be 1107 reused. If an endpoint wishes to continue to communicate after 1108 detecting a connection failure, it MAY initiate a new SDP exchange to 1109 negotiate a new session URL. Otherwise, it SHOULD attempt to tear 1110 down the session using the rules of the signaling protocol. 1112 It would be nice to allow sessions to be recovered after a 1113 connection failure, perhaps by allowing the active endpoint to 1114 reconnect, and send a new VISIT request. However, this approach 1115 creates a race condition between the time that the hosting device 1116 notices the failed connection, and the time that the endpoint 1117 tries to recover the session. If the endpoint attempts to 1118 reconnect prior to the hosting device noticing the failure, the 1119 hosting device will interpret the recovery attempt as a conflict. 1120 The only way around this would be to force the hosting device to 1121 do a liveness check on the original connection, which would create 1122 a lot of complexity and overhead that do not seem to be worth the 1123 trouble. 1125 6.6 Delivery Status Notification 1127 Delivery Status Notification (DSN)[10] provides an extensible MIME 1128 content-type that is used to convey both positive and negative status 1129 of messages in the network. This functionality is extremely useful 1130 for MSRP sessions that traverse a relay device. Relay support is 1131 considered out of scope for this specification and will be included 1132 in a separate specification. This section will only cover 1133 functionality required by non-relay aware endpoints for basic MSRP 1134 operation. An MSRP endpoint MUST be capable of performing the DSN 1135 operations described in this specification and SHOULD support the DSN 1136 MIME type outlined. An MSRP endpoint MAY use an alternative payload 1137 for reporting message status using the procedures outlined in this 1138 specification. 1140 6.6.1 Endpoint DSN Request 1142 An endpoint that wishes to be informed of message delivery/failure 1143 needs to request such information. This is achieved by including an 1144 MSRP Receipt-Request header in the request. The header can equal one 1145 of three values: 1147 negative: Indicates the client only requires failure delivery 1148 report. 1149 none: Indicates the client requires no delivery reports. 1150 all: Indicates the client requires both positive and negative 1151 delivery reports. 1153 Within the scope of this specification the Receipt-Request header is 1154 only used in MSRP SEND requests. Future extensions to this 1155 specification MAY use the mechanism described in this document for 1156 delivery/failure status notification of other MSRP requests. 1158 The default value for this header if not present in a request is 1159 'negative'. An example of this header would be: 1161 Message-Receipt: negative 1163 The default DSN MIME type is detailed in RFC 1894[10]. It is 1164 possible for MSRP endpoints to use a different format if required. 1165 This can be achieved by including a 'receipt-type' parameter in the 1166 Message-Receipt header. This parameter contains the alternative MIME 1167 type that SHOULD be used for this particular receipt transaction. A 1168 client specifying an alternative 'receipt-type' for an MSRP 1169 transaction MUST also be capable of receiving the default format 1170 specified in this document. This allows intermediaries, such as MSRP 1171 relays, to generate failure reports when MSRP transaction failure 1172 occurs. 1174 6.6.2 DSN generation 1176 An MSRP endpoint implementing this specification SHOULD be able to 1177 generate positive delivery status of MSRP requests. On receiving an 1178 MSRP request containing a Message-Receipt header with a value of 1179 'all', the endpoint will carry out normal MSRP response generation 1180 and MUST generate an MSRP REPORT request using the following 1181 procedures: 1183 1. Insert a To header containing the From value from the original 1184 request. 1185 2. Insert a From header containing the To value from the original 1186 request. 1187 3. Insert the message status payload in the body of the request. If 1188 the default DSN MIME type from DSN[10] is used then the MSRP 1189 Content-Type header MUST use the value multipart/report. The 1190 relevance of DSN headers in MSRP can be found in section 7.6.5. 1191 An alternative MIME type MAY be used but MUST be specified in the 1192 Content-Type header. Negative DSN generation is considered out 1193 of the scope of this document and will be covered in a separate 1194 MSRP relay document. 1195 4. Insert a new transaction ID (TR-ID). 1196 5. (Optional) Insert an MSRP Byte-Range header containing the value 1197 from 'multipart/byteranges' MIME header Content-range from the 1198 payload of a chunked message. It is possible that an entity 1199 downstream may decide to break up an MSRP SEND message and send 1200 it in separate chunks. The originating client would be 1201 transparent to this operation but would need to be informed if a 1202 DSN only represents part of the request. 1204 6.6.3 Receiving positive DSN 1206 An MSRP endpoint implementing this specification MUST be able to 1207 receive positive delivery status of MSRP requests. 1209 6.6.4 Receiving negative DSN 1211 An MSRP endpoint implementing this specification MUST be able to 1212 receive negative delivery status of MSRP requests. 1214 6.6.5 DSN headers in MSRP 1216 The format of a default DSN report is taken from RFC 1894[10]. Only 1217 a minimal subset of fields are used, as detailed in the remainder of 1218 this section. 1220 6.6.5.1 Per-Message DSN header usage 1222 original-envelope-id: See Section 6.6.5.3 1224 reporting-mta: See Section 6.6.5.4 1226 dsn-gateway: Not Used 1228 received-from-mta: Not Used 1230 arrival-date: Not Used 1232 6.6.5.2 Per-Recipient DSN header usage 1234 original-recipient Not Used 1236 final-recipient: See Section 6.6.5.5 1238 action: See Section 6.6.5.6 1240 status: See Section 6.6.5.7 1242 remote-mta: Not Used 1244 diagnostic-code: Not Used 1246 last-attempt-date: Not Used 1248 will-retry-until:Not Used 1250 6.6.5.3 original-envelope-id usage 1252 The 'original-envelope-id' field contains a unique identifier which 1253 is used to correlate a DSN report with the originating MSRP 1254 transaction. The entity generating the DSN report MUST insert the 1255 Message-ID value that appeared in the original MSRP request into the 1256 'original-envelope-id' field. This allows a requesting client to 1257 explicitly correlate a REPORT request with the original request. 1258 This correlation is implementation specific and makes no requirements 1259 on clients to hold state for transactions ID's. Information 1260 regarding the original request can be obtained from the DSN MIME type 1261 outlined in [10]. 1263 6.6.5.4 reporting-mta 1265 The 'reporting-mta-field' MUST follow the guidelines set out in RFC 1266 1894[10]. The 'mta-name-type' from RFC1894[10] MUST use the value of 1267 'msrp-name-type', as defined in section 9 of this specification. The 1268 'mta-name' value for this field as specified in RFC1894 [10] MUST 1269 equal an MSRP URL representing itself. 1271 6.6.5.5 final-recipient 1273 The 'final-recipient-field' MUST follow the guidelines set out in RFC 1274 1894[10]. The 'address-type' from RFC1894 [10] MUST use the value of 1275 'msrp-address-type', as defined in section 9 of this specification. 1276 The 'address-type' value for this field as specified in RFC1894 [10] 1277 MUST equal the value contained in the MSRP 'To' header from the 1278 original request being reported on. 1280 6.6.5.6 action 1282 The 'action' field MUST follow the guidelines set out in RFC 1283 1894[10]. An MSRP entity constructing a DSN report MUST use the 1284 'delivered' value for a successful delivery and MUST use the 'failed' 1285 value for an un-successful delivery. The other values specified for 1286 the 'action' field in RFC 1894[10] MAY be used. 1288 6.6.5.7 status 1290 The 'status' field MUST follow the guidelines set out in RFC 1291 1894[10]. An MSRP entity constructing a DSN report MUST represent 1292 the MSRP status code in the correct format detailed in RFC 1894[10] 1293 for the 'status' field of a DSN report. An MSRP status code consists 1294 of a three digit number while a DSN status is three digits separated 1295 by '.'. An example would be: 1297 Status: 5.0.0 (unknown permanent failure) 1298 When generating this field the first digit of the MSRP status code 1299 (working from left to right) MUST be placed in the first part of the 1300 'status' DSN field. The second digit MUST be placed in the second 1301 part of the 'status' DSN field. The third digit MUST be placed in 1302 the third part of the 'status' DSN field. An example of a DSN 1303 'status' field value would be: 1305 An MSRP '200' success response would be mapped to: 1307 Status: 2.0.0 (OK) 1309 The MSRP reason phrase mapped to a DSN 'status' field MAY be enclosed 1310 in parentheses if required. 1312 6.7 Message Fragmentation 1314 MSRP devices SHOULD break large content into fragments, and send each 1315 fragment in a separate SEND request. A message fragment sent in this 1316 way is known as a "parcel". Large content is defined to be anything 1317 larger than 2K bytes. Each parcel is encapsulated using the 1318 "message/byteranges" MIME type, defined in RFC2616 [11], to correlate 1319 parts of the message. The definition of large is determined by local 1320 policy. MSRP endpoints MUST be capable of receiving and processing 1321 fragmented messages. 1323 Open Issue: Do we want to negotiate the use of message/byteranges 1324 like any other MIME type? I assume no, as we want to allow relays 1325 to fragment messages, and relays are not privy to the 1326 content-types negotiated for a session. 1328 Although relays are not in scope for this document, we expect that 1329 relays will be able to introduce fragmentation, as well as change the 1330 fragmentation of previously fragmented messages. Therefore, all MSRP 1331 endpoints MUST be able to receive fragmented messages. 1333 6.7.1 MSRP Usage of message/byteranges 1335 The "message/byteranges" type allows multiple ranges in a single 1336 document. However, MSRP devices MUST NOT include more than one byte 1337 range in a single request. Although the HTTP usage for a document 1338 containing a single byte range indicates putting the "Content-Range" 1339 header in a header field, rather than in the body itself, 1340 "Content-Range" MUST NOT appear as an MSRP header field. 1342 Open Issue: How much of the message/byteranges specification 1343 should we explain or copy forward? Copying too much obscures the 1344 fact that rfc2616 is the normative definition, but it may be 1345 helpful to have more context here. 1347 If the MSRP device has a priori knowledge of the overall content 1348 length, it SHOULD put that length into instance-length. The device 1349 MAY place a "*" in instance-length if it does not have such 1350 knowledge. 1352 Similarly, if the device has a priori knowledge of the number of 1353 bytes in a byte range, it SHOULD place the last byte position in 1354 last-byte-pos. Otherwise, it MAY use a "*". If "*" is present, the 1355 recipient MUST determine the last-byte-position through normal 1356 request framing and body processing. An MSRP device MUST put the 1357 initial byte position in first-byte-pos. 1359 6.8 Method Descriptions 1361 This section summarizes the purpose of each MSRP method. All MSRP 1362 messages MUST contain the TR-ID, From-Path, To-Path, and Boundary 1363 header fields, as well as a Closing field. Additional requirements 1364 exist depending on the individual method. 1366 6.8.1 SEND 1368 The SEND method is used by both the host and visitor endpoints to 1369 send instant messages to its peer endpoint. A SEND request MUST 1370 contain a To-Path header field containing the sender's remote path, a 1371 From-Path header field containing the sender's local URL, and a 1372 Message-ID header field. SEND requests SHOULD contain a MIME body 1373 part. The body MUST be of a media type included in the format list 1374 negotiated in the SDP exchange. If a body is present, the request 1375 MUST contain a Content-Type header field identifying the media type 1376 of the body. 1378 To Do: We plan to expand the use of MIME headers to allow any 1379 standard MIME header in a SEND request. This is not included in 1380 this version for the sake of getting the draft out as soon as 1381 possible, but will follow soon. 1383 6.8.2 VISIT 1385 The visiting endpoint uses the VISIT method to associate a network 1386 connection with the session state at the listening device. A VISIT 1387 request MUST include a To-Path header including the sender's remote 1388 path, and a From-Path header field containing the sender's local URL. 1390 This purpose can also be served by a SEND request, if the sender has 1391 immediate content to send. 1393 Open Issue: There is overlap between SEND and VISIT as currently 1394 defined. We should consider either removing VISIT entirely and 1395 just use an empty SEND request, or we should always require VISIT. 1396 (This would not apply to a endpoint connecting to its own relay.) 1398 6.8.3 REPORT 1400 Report is used by an endpoint or relay to convey message delivery 1401 status 1403 6.9 Response Code Descriptions 1405 This section summarizes the various response codes. Except where 1406 noted, all responses MUST contain a TR-ID header field matching the 1407 TR-ID header field of the original request, and To-Path and From-Path 1408 headers matching those of the original request. 1410 6.9.1 200 1412 The 200 response code indicates a successful transaction. 1414 6.9.2 400 1416 A 400 response indicates a request was unintelligible. 1418 6.9.3 415 1420 A 415 response indicates the SEND request contained a MIME 1421 content-type that is not understood by the receiver. 1423 6.9.4 426 1425 A 426 response indicates that the request is only allowed over TLS 1426 protected connections. 1428 6.9.5 481 1430 A 481 response indicates that no session exists for the connection. 1432 6.9.6 506 1434 A 506 response indicates that a VISIT request occurred in which the 1435 To-Path header indicates a local path that is already associated with 1436 another connection. A 506 response MUST NOT be returned in response 1437 to any method other than VISIT. 1439 6.10 Header Field Descriptions 1441 This section summarizes the various header fields. MSRP header 1442 fields are single valued; that is, they MUST NOT occur more than once 1443 in a particular request or response. 1445 6.10.1 TR-ID 1447 The TR-ID header field contains a transaction identifier used to map 1448 a response to the corresponding request. A TR-ID value MUST be 1449 unique among all values used by a given endpoint inside a given 1450 session. MSRP elements MUST NOT assume any additional semantics for 1451 TR-ID. 1453 6.10.2 Message-ID 1455 The Message-ID header field contains a message identifier used to map 1456 a delivery status notification to the corresponding request. TR-ID 1457 cannot be used for this purpose, as it may change between hops if 1458 relays are involved. A Message-ID value MUST be unique among all 1459 values used by a given endpoint inside a given session. MSRP 1460 elements MUST NOT assume any additional semantics for Message-ID. 1461 The Message-ID value MAY be the same as the original TR-ID value. 1463 6.10.3 To-Path 1465 The To-Path header field is used to indicate the sender's remote 1466 path. All MSRP requests MUST contain a To-Path header field. 1468 6.10.4 From-Path 1470 The From-Path header field is used to indicate the sender's local 1471 URL. All MSRP requests MUST contain a From-Path header field. 1473 6.10.5 Boundary 1475 The Boundary header field contains the boundary string that is used 1476 to terminate the message. This string MUST have at least 16 bits of 1477 randomness. This string MUST NOT be duplicated anywhere else in the 1478 message. The Boundary header field is mandatory for all MSRP 1479 messages, and SHOULD be the first header field in the message. 1481 6.10.6 Closing 1483 The Closing field contains the same boundary string that was 1484 originally listed in the Boundary header field, as well as the 1485 Continuation-Flag field. The Closing field MUST occur at the end of 1486 each MSRP message. If the message content has been sent completely, 1487 the Interrupt-Flag field value MUST be ""$ (dollar sign). If there 1488 is further content to send as part of the "logical" instant message, 1489 this field value MUST be "+". (plus sign.) 1491 6.10.7 Content-Type 1493 The Content-Type header field is used to indicate the MIME media type 1494 of the body. Content-Type MUST be present if a body is present. 1496 To Do: The work group has agreed to allow the use of any standard 1497 MIME header. This is not reflected in this version, but will be 1498 in a shortly forthcoming one. 1500 7. Example 1502 This section shows an example message flow for the most common 1503 scenario. The example assumes SIP is used to transport the SDP 1504 exchange. Details of the SIP messages and SIP proxy infrastructure 1505 are omitted for the sake of brevity. In the example, assume the 1506 offerer is sip:alice@atlanta.com and the answerer is 1507 sip:bob@biloxi.com. 1509 Alice Bob 1510 | | 1511 | | 1512 |(1) (SIP) INVITE | 1513 |----------------------->| 1514 |(4) (SIP) 200 OK | 1515 |<-----------------------| 1516 |(5) (SIP) ACK | 1517 |----------------------->| 1518 |(6) (MSRP) SEND | 1519 |----------------------->| 1520 |(7) (MSRP) 200 OK | 1521 |<-----------------------| 1522 |(8) (MSRP) SEND | 1523 |<-----------------------| 1524 |(9) (MSRP) 200 OK | 1525 |----------------------->| 1526 |(10) (SIP) BYE | 1527 |----------------------->| 1528 |(11) (SIP) 200 OK | 1529 |<-----------------------| 1530 | | 1531 | | 1533 1. Alice constructs a local URL of 1534 msrp://alicepc.atlanta.com:7777/iau39 and listens for a 1535 connection on TCP port 7777. 1537 Alice->Bob (SIP): INVITE sip:bob@biloxi.com 1538 v=0 1539 o=alice 2890844557 2890844559 IN IP4 host.anywhere.com 1540 s= 1541 c=IN IP4 fillername 1542 t=0 0 1543 m=message 9999 msrp * 1544 a=accept-types:text/plain 1545 a=path:msrp://alicepc.atlanta.com:7777/iau39 1547 2. Bob->Alice (SIP): 200 OK 1549 v=0 1550 o=bob 2890844612 2890844616 IN IP4 host.anywhere.com 1551 s= 1552 c=IN IP4 ignorefield 1553 t=0 0 1554 m=message 9999 msrp * 1555 a=accept-types:text/plain 1556 a=path:msrp://bob.atlanta.com:8888/9di4ea 1558 3. Alice->Bob (SIP): ACK 1560 4. (Alice opens connection to Bob. This may occur in parallel with 1561 the previous step.) Alice->Bob (MSRP): 1563 MSRP SEND 1564 Boundary: d93kswow 1565 To-Path:msrp://bob.atlanta.com:8888/9di4ea 1566 From-Path:msrp://alicepc.atlanta.com:7777/iau39 1567 TR-ID: 123 1568 Message-ID: 123 1569 Content-Type: "text/plain" 1570 Hi, I'm Alice! 1571 -------d93kswow$ 1573 5. Bob->Alice (MSRP): 1575 MSRP 200 OK 1576 Boundary: 839s9ed 1577 To-Path:msrp://bob.atlanta.com:8888/9di4ea 1578 From-Path:msrp://alicepc.atlanta.com:7777/iau39 1579 TR-ID: 123 1580 -------839s9ed$ 1582 6. Bob->Alice (MSRP): 1584 MSRP SEND 1585 Boundary: dkei38sd 1586 To-Path:msrp://alice.atlanta.com:7777/iau39 1587 From-Path:msrp://bob.atlanta.com:8888/9di4ea 1588 TR-ID: 456 1589 Message-ID: 456 1590 Content-Type: "text/plain" 1592 Hi, Alice! I'm Bob! 1593 -------dkei38sd$ 1595 7. Alice->Bob (MSRP): 1597 MSRP 200 OK 1598 Boundary: diw3ids 1599 To-Path:msrp://alice.atlanta.com:7777/iau39 1600 From-Path:msrp://bob.atlanta.com:8888/9di4ea 1601 TR-ID: 456 1602 -------diw3ids$ 1604 8. Alice->Bob (SIP): BYE 1606 Alice invalidates local session state. 1608 9. Bob invalidates local state for the session. 1610 Bob->Alice (SIP): 200 OK 1612 8. IANA Considerations 1614 8.1 MSRP Port 1616 MSRP uses TCP port XYX, to be determined by IANA after this document 1617 is approved for publication. Usage of this value is described in 1618 Section 6.1 1620 8.2 MSRP URL Schema 1622 This document defines the URL schema of "msrp" "msrps", "smsrp", and 1623 "smsrps". 1625 8.2.1 Syntax 1627 See Section 6.1. 1629 8.2.2 Character Encoding 1631 See Section 6.1. 1633 8.2.3 Intended Usage 1635 See Section 6.1. 1637 8.2.4 Protocols 1639 The Message Session Relay Protocol (MSRP). 1641 8.2.5 Security Considerations 1643 See Section 9. 1645 8.2.6 Relevant Publications 1647 RFCXXXX 1649 [Note to RFC Editor: Please replace RFCXXXX in the above paragraph 1650 with the actual number assigned to this document. 1652 8.3 SDP Parameters 1654 This document registers the following SDP parameters in the 1655 sdp-parameters registry: 1657 8.3.1 Accept Types 1659 Attribute-name: accept-types 1660 Long-form Attribute Name Acceptable MIME Types 1661 Type: Media level 1662 Subject to Charset Attribute No 1663 Purpose and Appropriate Values See Section 5.2. 1665 8.3.2 Wrapped Types 1667 Attribute-name: accept-wrapped-types 1668 Long-form Attribute Name Acceptable MIME Types Inside Wrappers 1669 Type: Media level 1670 Subject to Charset Attribute No 1671 Purpose and Appropriate Values See Section 5.3. 1673 8.3.3 Path 1675 Attribute-name: path 1676 Long-form Attribute Name MSRP URL Path 1677 Type: Media level 1678 Subject to Charset Attribute No 1679 Purpose and Appropriate Values See Section 5.4. 1681 8.4 IANA registration forms for DSN types 1683 8.4.1 IANA registration form for address-type 1685 This document registers a new 'address-type' for use in conjunction 1686 with RFC1894[10]. The authors request that these values be recorded 1687 in the IANA registry for DSN 'address-type'. 1689 Proposed Address name: msrp-address-type 1691 Syntax: See Section 6.1 1693 8.4.2 IANA registration form for MTA-name-type 1695 This document registers a new 'MTA-name-type' for use in conjunction 1696 with RFC1894[10]. The authors request that these values be recorded 1697 in the IANA registry for DSN 'MTA-name-type'. 1699 Proposed Address name: msrp-name-type 1701 Syntax: See See Section 6.1 1703 9. Security Considerations 1705 There are a number of security considerations for MSRP, some of which 1706 are mentioned elsewhere in this document. This section discusses 1707 those further, and introduces some new ones. 1709 9.1 TLS and the MSRPS Scheme 1711 All MSRP devices must support TLS, with at least the 1712 TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites 1713 MAY be supported. 1715 MSRP does not define a separate TCP port for TLS connections. This 1716 means that all MSRP server devices, that is, all devices that listen 1717 for TCP connections, MUST be prepared to handle both TLS and plain 1718 text connections on the same port. When a device accepts a TCP 1719 connection, it MUST watch for the TLS handshake messages to determine 1720 if a particular connection uses TLS. If the first data received is 1721 not part of a start TLS request, the device ceases to watch for the 1722 TLS handshake until it reads the entire message. Once the message 1723 has been completely received, the device resumes watching for the 1724 start TLS message. 1726 Any MSRP device MAY refuse to accept a given request over a non-TLS 1727 connection by returning a 426 response. 1729 MSRP devices acting in the role of TCP client MAY perform a TLS 1730 handshake at any time, as long as the request occurs between MSRP 1731 messages. The endpoint MUST NOT send a start TLS request in the 1732 middle of an MSRP message. 1734 The working group considered only requiring the endpoint to watch 1735 for a TLS handshake at the beginning of the session. However, the 1736 endpoint should be able to determine if a new message is a start 1737 TLS request or an MSRP request by only reading ahead three bytes. 1738 Therefore, the working group chose to allow a session to switch to 1739 TLS in mid-stream, as long as the switch occurs between MRSP 1740 messages. 1742 There have since been proposals that we only allow start-tls at 1743 connection time. Do we have a consensus here one way or the 1744 other? 1746 The "msrps" and "smsrps" URI schema indicates that the connection 1747 MUST be protected with TLS. 1749 Relay handling of "msrps" and "smsrps" are beyond the scope of 1750 this document. However, any relay specification MUST explicitly 1751 specify this. 1753 MSRP requests for "msrps" URLs MUST be sent over TLS protected 1754 connections. If a device receives a request for a "msrps" or 1755 "smsrps" URL over an unprotected connection, it MUST reject the 1756 request with a 426 response. 1758 9.1.1 Sensitivity of Session URLs 1760 The URLs sent in the SDP offer/answer exchange for a MSRP session are 1761 used by the endpoints to identify each other. If an attacker were 1762 able to acquire the session URL, either by guessing it or by 1763 eavesdropping, there is a window of opportunity in which the attacker 1764 could hijack the session connecting and sending a MSRP request to the 1765 listening device before the legitimate peer. Because of this 1766 sensitivity, these URLs SHOULD be constructed in a way to make them 1767 difficult to guess, and should be sufficiently random so that it is 1768 unlikely to be reused. All mechanisms used to transport these URLs 1769 SHOULD be protected from eavesdroppers and man-in-the-middle attacks. 1771 Therefore a MSRP device MUST support the use of TLS for all MSRP 1772 messages. Further, MSRP connections SHOULD actually be protected 1773 with TLS. Further, an MSRP endpoint MUST be capable of using the 1774 security features of the signaling protocol in order to protect the 1775 SDP exchange and SHOULD actually use them on all such exchanges. 1776 End-to-end protection schemes SHOULD be preferred over hop-by-hop 1777 schemes for protection of the SDP exchange. 1779 9.1.2 End to End Protection of IMs 1781 Instant messages can contain very sensitive information. As a 1782 result, as specified in RFC 2779 [3], instant messaging protocols 1783 need to provide for encryption, integrity and authentication of 1784 instant messages. Therefore MSRP endpoints MUST support the 1785 end-to-end encryption and integrity of bodies sent via SEND requests 1786 using Secure MIME (S/MIME) [7]. 1788 Note that while each protected body could use separate keying 1789 material, this is inefficient in that it requires an independent 1790 public key operation for each message. Endpoints wishing to invoke 1791 end-to-end protection of message sessions SHOULD exchange symmetric 1792 keys in SDP k-lines, and use secret key encryption on for each MSRP 1793 message. When symmetric keys are present in the SDP, the 1794 offer-answer exchange MUST be protected from eavesdropping and 1795 tampering using the appropriate facilities of the signaling protocol. 1796 For example, if the signaling protocol is SIP, the SDP exchange MUST 1797 be protected using S/MIME. 1799 9.1.3 CPIM compatibility 1801 MSRP sessions may be gatewayed to other CPIM [19]compatible 1802 protocols. If this occurs, the gateway MUST maintain session state, 1803 and MUST translate between the MSRP session semantics and CPIM 1804 semantics that do not include a concept of sessions. Furthermore, 1805 when one endpoint of the session is a CPIM gateway, instant messages 1806 SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST 1807 include "message/cpim" as the first entry in its SDP accept-types 1808 attribute. MSRP endpoints sending instant messages to a peer that 1809 has included 'message/cpim" as the first entry in the accept-types 1810 attribute SHOULD encapsulate all instant message bodies in "message/ 1811 cpim" wrappers. All MSRP endpoints MUST support the message/cpim 1812 type, and SHOULD support the S/MIME features of that format. 1814 9.1.4 PKI Considerations 1816 Several aspects of MSRP will benefit from being used in the context 1817 of a public key infrastructure. For example, the MSRPS scheme 1818 allows, and even encourages, TLS connections between endpoint 1819 devices. And while MSRP allows for a symmetric session key to 1820 protect all messages in a session, it is most likely that session key 1821 itself would be exchanged in a signaling protocol such as SIP. Since 1822 that key is extremely sensitive, its exchange would also need to be 1823 protected. In SIP, the preferred mechanism for this would be S/MIME, 1824 which would also benefit from a PKI. 1826 However, all of these features may be used without PKI. Each 1827 endpoint could instead use self signed certificates. This will, of 1828 course, be less convenient than with a PKI, in that there would be no 1829 certificate authority to act as a trusted introducer. Peers would be 1830 required to exchange certificates prior to securely communicating. 1832 Since, at least for the immediate future, any given MSRP 1833 implementation is likely to communicate with at least some peers that 1834 do not have a PKI available, MSRP implementations SHOULD support the 1835 use of self-signed certificates, and SHOULD support the ability to 1836 configure lists of trusted certificates. 1838 To Do: Add text discussion the use of TLS certificates in more 1839 detail. 1841 10. Changes from Previous Draft Versions 1843 This section to be deleted prior to publication as an RFC 1845 10.1 draft-ietf-simple-message-sessions-06 1847 Changed To and From header names to To-Path and From-Path. Added 1848 more clarification to path handling, and commentary on how it 1849 enables relay usage. 1850 Changed mechanism for signaling transport and TLS protection into 1851 the MSRP URL, rather than the SDP M-Line. 1852 Removed length field from start line and added Boundary header 1853 field and Closing field. 1854 Added recommendation to fragment any content over 2k. 1855 Added Rohan's proposal to make offerer connect to answerer. (With 1856 open issue for more discussion.) 1857 Changed To-Path and From-Path usage in responses to indicate the 1858 destination and source of the response, rather than merely copy 1859 from the associated request. 1860 Updated DSN section. Added text on field usage. 1861 Fixed change section--changes from version 05 were erroneously 1862 attributed to 04. 1864 10.2 draft-ietf-simple-message-sessions-05 1866 Changed the use of session URLs. Instead of a single session URL, 1867 each endpoint is identified by a distinct URL. MSRP requests will 1868 put the destination URL in a To header, and the sender URL in a 1869 From header. 1871 Changed the SDP exchange of MSRP URLs to handle the URL for each 1872 endpoint. Further, changed the SDP attribute to support a list of 1873 URLs in each direction. This may be used with relays to exchange 1874 paths, rather than single URLs. MSRP endpoints must be able to 1875 intelligently process such a list if received. This document does 1876 not, however, describe how to generate such a list. 1877 Added section for Delivery Status Notification handling, and added 1878 associated entries into the syntax definition. 1879 Added content fragmentation section. 1880 Removed recommendation to start separate session for large 1881 transfers. 1882 Corrected some mistakes in the syntax definitions. 1883 Added Chris Boulton as a co-author for his contribution of the DSN 1884 text. 1886 10.3 draft-ietf-simple-message-sessions-04 1888 Removed the direction attribute. Rather than using a comedia 1889 styled direction negotiation, we just state that the answerer 1890 opens any needed connection. 1892 10.4 draft-ietf-simple-message-sessions-03 1894 Removed all specification of relays, and all features specific to 1895 the use of relays. The working group has chosen to move relay 1896 work into a separate effort, in order to advance the base 1897 specification. (The MSRP acronym is unchanged for the sake of 1898 convenience.) This included removal of the BIND method, all 1899 response codes specific to BIND, Digest Authentication, and the 1900 inactivity timeout. 1901 Removed text indicating that an endpoint could retry failed 1902 requests on the same connection. Rather, the endpoint should 1903 consider the connection dead, and either signal a reconnection or 1904 end the session. 1905 Added text describing subsequent SDP exchanges. Added mandatory 1906 "count" parameter to the direction attribute to allow explicit 1907 signaling of the need to reconnect. 1908 Added text to describe the use of send and receive only indicators 1909 in SDP for one-way transfer of large content. 1910 Added text requiring unique port field values if multiple M-line's 1911 exist. 1912 Corrected a number of editorial mistakes. 1914 10.5 draft-ietf-simple-message-sessions-02 1916 Moved all content type negotiation from the "m"-line format list 1917 into "a"-line attributes. Added the accept-types attribute. This 1918 is due to the fact that the sdp format-list syntax is not 1919 conducive to encoding MIME content types values. 1920 Added "other-method" construction to the message syntax to allow 1921 for extensible methods. 1922 Consolidated all syntax definitions into the same section. 1923 Cleaned up ABNF for digest challenge and response syntax. 1924 Changed the session inactivity timeout to 12 minutes. 1925 Required support for the SHA1 alogorithm. 1926 Required support for the message/cpim format. 1927 Fixed lots of editorial issues. 1928 Documented a number of open issues from recent list discussions. 1930 10.6 draft-ietf-simple-message-sessions-01 1932 Abstract rewritten. 1933 Added architectural considerations section. 1934 The m-line format list now only describes the root body part for a 1935 request. Contained body part types may be described in the 1936 "accept-wrapped-types" a-line attribute. 1937 Added a standard dummy value for the m-line port field. Clarified 1938 that a zero in this field has normal SDP meaning. 1939 Clarified that an endpoint is globally configured as to whether or 1940 not to use a relay. There is no relay discovery mechanism 1941 intrinsic to MSRP. 1942 Changed digest algorithm to SHA1. Added TR-ID and S-URI to the 1943 hash for digest authentication. 1944 CMS usage replaced with S/MIME. 1945 TLS and MSRPS usage clarified. 1946 Session state timeout is now based on SEND activity, rather than 1947 BIND and VISIT refreshes. 1948 Default port added. 1949 Added sequence diagrams to the example message flows. 1950 Added discussion of self-signed certificates in the security 1951 considerations section. 1953 10.7 draft-ietf-simple-message-sessions-00 1955 Name changed to reflect status as a work group item. 1956 This version no longer supports the use of multiple sessions 1957 across a single TCP session. This has several related changes: 1958 There is now a single session URI, rather than a separate one for 1959 each endpoint. The session URI is not required to be in requests 1960 other than BIND and VISIT, as the session can be determined based 1961 on the connection on which it arrives. 1962 BIND and VISIT now create soft state, eliminating the need for the 1963 RELEASE and LEAVE methods. 1964 The MSRP URL format was changed to better reflect generic URL 1965 standards. URL comparison and resolution rules were added. SRV 1966 usage added. 1968 Determination of host and visitor roles now uses a direction 1969 attribute much like the one used in COMEDIA. 1970 Format list negotiation expanded to allow a "prefer these formats 1971 but try anything" semantic 1972 Clarified handling of direction notification failures. 1973 Clarified signaling associated with session failure due to dropped 1974 connections. 1975 Clarified security related motivations for MSRP. 1976 Removed MIKEY dependency for session key exchange. Simple usage 1977 of k-lines in SDP, where the SDP exchange is protected end-to-end 1978 seems sufficient. 1980 10.8 draft-campbell-simple-im-sessions-01 1982 Version 01 is a significant re-write. References to COMEDIA were 1983 removed, as it was determined that COMEDIA would not allow 1984 connections to be used bidirectional in the presence of NATs. 1985 Significantly more discussion of a concrete mechanism has been added 1986 to make up for no longer using COMEDIA. Additionally, this draft and 1987 draft-campbell-cpimmsg-sessions (which would have also changed 1988 drastically) have now been combined into this single draft. 1990 11. Contributors 1992 In addition to the editor, The following people contributed extensive 1993 work to this document: 1995 Chris Boulton 1996 Cullen Jennings 1997 Paul Kyzivat 1998 Rohan Mahy 1999 Adam Roach 2000 Jonathan Rosenberg 2001 Robert Sparks 2003 12. Acknowledgments 2005 The following people contributed substantial discussion and feedback 2006 to this ongoing effort: 2007 Allison Mankin Jon Peterson Brian Rosen Dean Willis 2008 Aki Niemi Hisham Khartabil Pekka Pessi Orit Levin 2010 13. References 2012 13.1 Normative References 2014 [1] Handley, M. and V. Jacobson, "SDP: Session Description 2015 Protocol", RFC 2327, April 1998. 2017 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2018 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2019 Session Initiation Protocol", RFC 3261, June 2002. 2021 [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 2022 Presence Protocol Requirements", RFC 2779, February 2000. 2024 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2025 Resource Identifiers (URL): Generic Syntax", RFC 2396, August 2026 1998. 2028 [5] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging 2029 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in 2030 progress), January 2003. 2032 [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 2033 specifying the location of services (DNS SRV)", RFC 2782, 2034 February 2000. 2036 [7] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2037 2633, June 1999. 2039 [8] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites 2040 for Transport Layer Security (TLS)", RFC 3268, June 2002. 2042 [9] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 2043 (SHA1)", RFC 3174, September 2001. 2045 [10] Moore, K. and G. Vaudreuil, "An Extensible Message Format for 2046 Delivery Status Notifications", RFC 1894, January 1996. 2048 [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2049 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2050 HTTP/1.1", RFC 2616, June 1999. 2052 13.2 Informational References 2054 [12] Campbell, B. and J. Rosenberg, "Session Initiation Protocol 2055 Extension for Instant Messaging", RFC 3428, September 2002. 2057 [13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 2058 "RTP: A Transport Protocol for Real-Time Applications", RFC 2059 1889, January 1996. 2061 [14] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. 2062 and A. Johnston, "A Multi-party Application Framework for SIP", 2063 draft-ietf-sipping-cc-framework-02 (work in progress), May 2064 2003. 2066 [15] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 2067 "Best Current Practices for Third Party Call Control in the 2068 Session Initiation Protocol", draft-ietf-sipping-3pcc-04 (work 2069 in progress), June 2003. 2071 [16] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 2072 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 2073 progress), February 2003. 2075 [17] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of 2076 Resource Management and Session Initiation Protocol (SIP)", RFC 2077 3312, October 2002. 2079 [18] Peterson, J., "A Privacy Mechanism for the Session Initiation 2080 Protocol (SIP)", RFC 3323 , November 2002. 2082 [19] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", 2083 draft-ietf-impp-im-04 (work in progress), August 2003. 2085 [20] Yon, D., "Connection-Oriented Media Transport in SDP", 2086 draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 2087 2003. 2089 Author's Address 2091 Ben Campbell 2092 dynamicsoft 2093 5100 Tennyson Parkway 2094 Suite 1200 2095 Plano, TX 75024 2097 EMail: bcampbell@dynamicsoft.com 2099 Intellectual Property Statement 2101 The IETF takes no position regarding the validity or scope of any 2102 intellectual property or other rights that might be claimed to 2103 pertain to the implementation or use of the technology described in 2104 this document or the extent to which any license under such rights 2105 might or might not be available; neither does it represent that it 2106 has made any effort to identify any such rights. Information on the 2107 IETF's procedures with respect to rights in standards-track and 2108 standards-related documentation can be found in BCP-11. Copies of 2109 claims of rights made available for publication and any assurances of 2110 licenses to be made available, or the result of an attempt made to 2111 obtain a general license or permission for the use of such 2112 proprietary rights by implementors or users of this specification can 2113 be obtained from the IETF Secretariat. 2115 The IETF invites any interested party to bring to its attention any 2116 copyrights, patents or patent applications, or other proprietary 2117 rights which may cover technology that may be required to practice 2118 this standard. Please address the information to the IETF Executive 2119 Director. 2121 Full Copyright Statement 2123 Copyright (C) The Internet Society (2004). All Rights Reserved. 2125 This document and translations of it may be copied and furnished to 2126 others, and derivative works that comment on or otherwise explain it 2127 or assist in its implementation may be prepared, copied, published 2128 and distributed, in whole or in part, without restriction of any 2129 kind, provided that the above copyright notice and this paragraph are 2130 included on all such copies and derivative works. However, this 2131 document itself may not be modified in any way, such as by removing 2132 the copyright notice or references to the Internet Society or other 2133 Internet organizations, except as needed for the purpose of 2134 developing Internet standards in which case the procedures for 2135 copyrights defined in the Internet Standards process must be 2136 followed, or as required to translate it into languages other than 2137 English. 2139 The limited permissions granted above are perpetual and will not be 2140 revoked by the Internet Society or its successors or assignees. 2142 This document and the information contained herein is provided on an 2143 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2144 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2145 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2146 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2147 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2149 Acknowledgment 2151 Funding for the RFC Editor function is currently provided by the 2152 Internet Society.