idnits 2.17.1 draft-ietf-simple-message-sessions-05.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 8 instances of too long lines in the document, the longest one being 19 characters in excess of 72. ** There are 20 instances of lines with control characters in the document. == There are 3 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 300: '... MUST have the value of "message". T...' RFC 2119 keyword, line 301: '... used, and MAY be set to any value c...' RFC 2119 keyword, line 303: '... MUST not be repeated in other MSRP ...' RFC 2119 keyword, line 305: '... The proto field MUST designate the me...' RFC 2119 keyword, line 307: '... of this value MUST be "msrp". For M...' (147 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1136 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 (April 12, 2004) is 7316 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 1749, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1764, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1789, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1792, 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 (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE Working Group B. Campbell 2 Internet-Draft J. Rosenberg 3 Expires: October 11, 2004 R. Sparks 4 dynamicsoft 5 P. Kyzivat 6 Cisco Systems 7 C. Boulton 8 Ubiquity Software Corporation 9 April 12, 2004 11 The Message Session Relay Protocol 12 draft-ietf-simple-message-sessions-05 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 11, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes the Message Session Relay Protocol (MSRP), a 43 mechanism for transmitting a series of Instant Messages within a 44 session. MSRP sessions are managed using the Session Description 45 Protocol (SDP) offer/answer model carried by a signaling protocol 46 such as the Session Initiation Protocol (SIP). 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Motivation for Session-mode Messaging . . . . . . . . . . 4 52 3. Scope of this Document . . . . . . . . . . . . . . . . . . 5 53 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 54 5. Architectural Considerations . . . . . . . . . . . . . . . 7 55 6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . 7 56 6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 7 57 6.2 The Accept Types Attribute . . . . . . . . . . . . . . . . 8 58 6.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . 8 59 6.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 9 60 6.5 Path Attributes with Multiple URLs . . . . . . . . . . . . 10 61 6.6 Updated SDP Offers . . . . . . . . . . . . . . . . . . . . 11 62 6.7 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 11 63 6.8 Connection Negotiation . . . . . . . . . . . . . . . . . . 12 64 7. The Message Session Relay Protocol . . . . . . . . . . . . 12 65 7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 12 66 7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 13 67 7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 13 68 7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 14 69 7.2 Connection Managment . . . . . . . . . . . . . . . . . . . 14 70 7.3 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 15 71 7.4 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 16 72 7.5 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 17 73 7.5.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 17 74 7.5.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 19 75 7.5.3 Sending Instant Messages on a Session . . . . . . . . . . 19 76 7.5.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . 20 77 7.5.5 Managing Session State and Connections . . . . . . . . . . 21 78 7.6 Delivery Status Notification . . . . . . . . . . . . . . . 22 79 7.6.1 Endpoint DSN Request . . . . . . . . . . . . . . . . . . . 22 80 7.6.2 DSN generation . . . . . . . . . . . . . . . . . . . . . . 23 81 7.6.3 Receiving positive DSN . . . . . . . . . . . . . . . . . . 24 82 7.6.4 Receiving negative DSN . . . . . . . . . . . . . . . . . . 24 83 7.6.5 DSN headers in MSRP . . . . . . . . . . . . . . . . . . . 24 84 7.7 Message Fragmentation . . . . . . . . . . . . . . . . . . 24 85 7.7.1 MSRP Usage of message/byteranges . . . . . . . . . . . . . 24 86 7.8 Method Descriptions . . . . . . . . . . . . . . . . . . . 25 87 7.8.1 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 7.8.2 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 7.8.3 REPORT . . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 7.9 Response Code Descriptions . . . . . . . . . . . . . . . . 26 91 7.9.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 7.9.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 7.9.3 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 7.9.4 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 7.9.5 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 7.9.6 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 7.10 Header Field Descriptions . . . . . . . . . . . . . . . . 26 98 7.10.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 7.10.2 To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 7.10.3 From . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 7.10.4 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 27 102 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 27 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 30 104 9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . 30 105 9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . 30 106 9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 30 107 9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . 30 108 9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . 30 109 9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 30 110 9.2.5 Security Considerations . . . . . . . . . . . . . . . . . 30 111 9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . 30 112 9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 31 113 9.3.1 Accept Types . . . . . . . . . . . . . . . . . . . . . . . 31 114 9.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . 31 115 9.3.3 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 10. Security Considerations . . . . . . . . . . . . . . . . . 31 117 10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . 31 118 10.1.1 Sensitivity of the Session URL . . . . . . . . . . . . . . 32 119 10.1.2 End to End Protection of IMs . . . . . . . . . . . . . . . 33 120 10.1.3 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 33 121 10.1.4 PKI Considerations . . . . . . . . . . . . . . . . . . . . 34 122 11. Changes from Previous Draft Versions . . . . . . . . . . . 34 123 11.1 draft-ietf-simple-message-sessions-04 . . . . . . . . . . 34 124 11.2 draft-ietf-simple-message-sessions-03 . . . . . . . . . . 35 125 11.3 draft-ietf-simple-message-sessions-02 . . . . . . . . . . 35 126 11.4 draft-ietf-simple-message-sessions-01 . . . . . . . . . . 35 127 11.5 draft-ietf-simple-message-sessions-00 . . . . . . . . . . 36 128 11.6 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 37 129 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 37 130 Normative References . . . . . . . . . . . . . . . . . . . 37 131 Informational References . . . . . . . . . . . . . . . . . 38 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39 133 Intellectual Property and Copyright Statements . . . . . . 40 135 1. Introduction 137 The MESSAGE [12] extension to SIP [2] allows SIP to be used to 138 transmit instant messages. Instant messages sent using the MESSAGE 139 method are normally independent of each other. This approach is often 140 called page-mode messaging, since it follows a model similar to that 141 used by many two-way pager devices. Page-mode messaging makes sense 142 for instant message exchanges where a small number of messages occur. 143 Endpoints may treat page-mode messages as if they took place in an 144 imaginative session, but there is no formal relationship between one 145 message and another. 147 There are also applications in which it is useful for instant 148 messages to be formally associated in a session. For example, a user 149 may wish to join a text conference, participate in the conference for 150 some period of time, then leave the conference. This usage is 151 analogous to regular media sessions that are typically initiated, 152 managed, and terminated using SIP. We commonly refer to this model as 153 session-mode messaging. 155 One of the primary purposes of SIP and SDP (Section 6) is the 156 management of media sessions. Session-mode messaging can be thought 157 of as a media session like any other. This document describes the 158 motivations for session-mode messaging, the Message Session Relay 159 Protocol, and the use of the SDP offer/answer mechanism for managing 160 MSRP session. 162 2. Motivation for Session-mode Messaging 164 Message sessions offer several advantages over page-mode messages. 165 For message exchanges that include more than a small number of 166 message transactions, message sessions offer a way to remove 167 messaging load from intervening SIP proxies. For example, a minimal 168 session setup and tear-down requires one INVITE/ACK transaction, and 169 one BYE transaction, for a total of 5 SIP messages. Normal SIP 170 request routing allows for all but the initial INVITE transaction to 171 bypass any intervening proxies that do not specifically request to be 172 in the path for future requests. Session-mode messages never cross 173 the SIP proxies themselves. 175 Each page-mode message involves a complete SIP transaction, that is, 176 a request and a response. Any page-mode message exchange that 177 involves more than 2 MESSAGE requests will generate more SIP requests 178 than a minimal session initiation sequence. Since MESSAGE is normally 179 used outside of a SIP dialog, these requests will typically traverse 180 the entire proxy network between the endpoints. 182 Due to network congestion concerns, the MESSAGE method has 183 significant limitations in message size, a prohibition against 184 overlapping requests, etc. Much of this has been required because of 185 perceived limitations in the congestion-avoidance features of SIP 186 itself. Work is in progress to mitigate these concerns. 188 However, session-mode messages are always sent over reliable, 189 congestion-safe transports. Therefore, there are no restrictions on 190 message sizes. There is no requirement to wait for acknowledgement 191 before sending another message, so that message transactions can be 192 overlapped. 194 Message sessions allow greater efficiency for secure message 195 exchanges. The SIP MESSAGE request inherits the S/MIME features of 196 SIP, allowing a message to be signed and/or encrypted. However, this 197 approach requires public key operations for each message. With 198 session-mode messaging, a session key can be established at the time 199 of session initiation. This key can be used to protect each message 200 that is part of the session. This requires only symmetric key 201 operations for each subsequent IM, and no additional certificate 202 exchanges are required after the initial exchange. The establishment 203 of the session key can be done using standard techniques that apply 204 to voice and video, in addition to instant messaging. 206 Finally, SIP devices can treat message sessions like any other media 207 sessions. Any SIP feature that can be applied to other sorts of media 208 sessions can equally apply to message sessions. For example, 209 conferencing [14], third party call control [15], call transfer [16], 210 QoS integration [17], and privacy [18] can all be applied to message 211 sessions. 213 Messaging sessions can also reduce the overhead in each individual 214 message. In page-mode, each message needs to include all of the SIP 215 headers that are mandated by RFC 3261 [2]. However, many of these 216 headers are not needed once a context is established for exchanging 217 messages. As a result, messaging session mechanisms can be designed 218 with significantly less overhead. 220 3. Scope of this Document 222 This document describes the use of MSRP between endpoints. It does 223 not specify the use of intermediaries, nor does it prohibit such use. 224 We expect an extension to this specification to define MSRP 225 intermediaries and their use. 227 This document describes the use of MSRP over TCP. MSRP may be used 228 over other congestion-controlled protocols such as SCTP. However, the 229 specific bindings for other such protocols are outside the scope of 230 this document. 232 4. Protocol Overview 234 The Message Session Relay Protocol (MSRP) provides a mechanism for 235 transporting session-mode messages between endpoints. MSRP uses 236 connection oriented, reliable network transport protocols only. It 237 can operate in the presence of many NAT and firewall environments, as 238 it allows participants to positively associate message sessions with 239 specific connections, and does not depend upon connection source 240 address, which may be obscured by NATs. 242 MSRP uses the following primitives: 244 SEND: Used to send message content from one endpoint to another. 246 VISIT: Used by an endpoint to establish a session association to the 247 host endpoint. 249 Assume A is an endpoint that wishes to establish a message session, 250 and B is the endpoint invited by A. A invites B to participate in a 251 message session by sending a URL. This URL is temporary, and must not 252 duplicate any URL that A has offered for other active sessions. 254 B "visits" A by connecting to A and sending a VISIT request 255 containing the URL that A provided. This associates the connection 256 from B with the session. B then responds to the invitation with a URL 257 of its own. This informs A that B has accepted the session, and will 258 accept messages at that URL. A and B may now exchange messages using 259 SEND requests on the connection. Each party targets such requests to 260 the peer's URL. 262 When either party wishes to end the session, it informs its peer 263 using the appropriate mechanism of the chosen signaling protocol, 264 such as a SIP BYE request. 266 The end to end case looks something like the following. (Note that 267 the example shows a logical flow only; syntax will come later in this 268 document.) 270 A->B (SDP): offer (msrp://A/123) 271 B->A (MSRP): VISIT (msrp://A/123, msrp://B/456) 272 A->B (MSRP): 200 OK 273 B->A (SDP): answer(msrp://B/456) 274 A->B (MSRP): SEND (msrp://B/456) 275 B->A (MSRP): 200 OK 276 B->A (MSRP): SEND (msrp://A/123) 277 A->B (MSRP): 200 OK 279 5. Architectural Considerations 281 There are a number of considerations that, if handled in a reasonable 282 fashion, will allow more effective use of the protocols described in 283 this document. 285 6. SDP Offer-Answer Exchanges for MSRP Sessions 287 MSRP sessions will typically be initiated using the Session 288 Description Protocol (SDP) [1] offer-answer mechanism, carried in the 289 Session Initiation Protocol (SIP) [2] or any other protocol 290 supporting it. 292 6.1 Use of the SDP M-line 294 The SDP "m"-line takes the following form: 296 m= 298 For non-RTP media sessions, The media field specifies the top level 299 MIME media type for the session. For MSRP sessions, the media field 300 MUST have the value of "message". The port field is normally not 301 used, and MAY be set to any value chosen by the endpoint. A port 302 field value of zero has the standard SDP meaning. Non-zero values 303 MUST not be repeated in other MSRP m-lines in the same SDP document. 305 The proto field MUST designate the message session mechanism and 306 transport protocol, separated by a "/" character. For MSRP, left part 307 of this value MUST be "msrp". For MSRP over TCP, the right part of 308 this field MUST take the value "tcp". For MSRP over other transport 309 protocols, the field value MUST be defined by the specification for 310 that protocol binding. 312 The format list list is ignored for MSRP. This is because MSRP 313 formats are specified as MIME content types, which are not convenient 314 to encode in the SDP format list syntax. Instead, the allowed formats 315 are negotiated using "a"-line attributes. For MSRP sessions, the 316 format list SHOULD contain a "*" character, and nothing else. 318 The port field in the M-line is not used to determine the port to 319 which to connect. Rather, the actual port is determined by the the 320 MSRP URL (Section 7.1) in the path attribute. However, a port value 321 of zero has the normal SDP meaning. 323 The following example illustrates an m-line for a message session, 324 where the endpoint is willing to accept root payloads of message/ 325 cpim, plain text or HTML. The second two types could either be 326 presented as the root body, or could be contained within message/cpim 327 bodies. 329 m=message 9999 msrp/tcp * 331 6.2 The Accept Types Attribute 333 MSRP can carry any MIME encoded payload. Endpoints specify MIME 334 content types that they are willing to receive in the accept types 335 "a"-line attribute. This attribute has the following syntax: 337 accept-types = accept-types-label ":" format-list 338 accept-types-label = "accept-types" 339 format-list = format-entry *( SP 340 format-entry) format-entry = (type "/" subtype) / ("*") 341 type = token 342 subtype = token 344 SDP offers for MSRP sessions MUST include an accept-types attribute. 345 SDP answers MUST also include the attribute, which MUST contain 346 either the same list as in the offer or a subset of that list. 348 A "*" entry in the accept-types attribute indicates that the sender 349 may attempt to send messages with media types that have not been 350 explicitly listed. If the receiver is able to process the media type, 351 it does so. If not, it will respond with a 415. Note that all 352 explicit entries SHOULD be considered preferred over any non-listed 353 types. This feature is needed as, otherwise, the list of formats for 354 rich IM devices may be prohibitively large. 356 The accept-types attribute may include container types, that is, mime 357 formats that contain other types internally. If compound types are 358 used, the types listed in the accept-types attribute may be used both 359 as the root payload, or may be wrapped in a listed container type. 360 (Note that the container type MUST also be listed in the accept-types 361 attribute.) 363 6.3 MIME Wrappers 365 The MIME content-types in the accept-types attribute will often 366 include container types; that is, types that contain other types. For 367 example, "message/cpim" or "multipart/mixed." Occasionally an 368 endpoint will need to specify a MIME body type that can only be used 369 if wrapped inside a listed container type. 371 Endpoints MAY specify MIME types that are only allowed to be wrapped 372 inside compound types using the "accept-wrapped-types" attribute in 373 an SDP a-line. This attribute has the following syntax: 375 accept-wrapped-types = wrapped-types-label ":" format-list 376 wrapped-types-label = "accept-wrapped-types" ` 378 The format-list element has the identical syntax as defined for the 379 accept-types attribute. The semantics for this attribute are 380 identical to those of the accept-types attribute, with the exception 381 that the specified types may only be used when wrapped inside 382 containers. Only types listed in accept-types may be used as the 383 "root" type for the entire body. Since any type listed in 384 accept-types may be used both as a root body, and wrapped in other 385 bodies, format entries from the m-line SHOULD NOT be repeated in this 386 attribute. 388 This approach does not allow for specifying distinct lists of 389 acceptable wrapped types for different types of containers. If an 390 endpoint understands a MIME type in the context of one wrapper, it is 391 assumed to understand it in the context of any other acceptable 392 wrappers, subject to any constraints defined by the wrapper types 393 themselves. 395 The approach of specifying types that are only allowed inside of 396 containers separately from the primary payload types allows an 397 endpoint to force the use of certain wrappers. For example, a CPIM 398 gateway device may require all messages to be wrapped inside 399 message/cpim bodies, but may allow several content types inside 400 the wrapper. If the gateway were to specify the wrapped types in 401 the accept-types attribute, its peer could choose to use those 402 types without the wrapper. 404 6.4 URL Negotiations 406 Each endpoint in an MSRP session is identified by a URL. These URLs 407 are negotiated in the SDP exchange. Each SDP offer or answer MUST 408 contain one or more MSRP URL in a path attribute. This attribute has 409 the following syntax: 411 a=path ":" MSRP_URL *(SP MSRP_URL) 413 where MSRP_URL is an MSRP or MSRPS URL as defined in Section 7.1. 415 The answerer will use the offered URL(s) to resolve the host address 416 and port when connecting, and to identify the target when sending 417 messages. For MSRP sessions, the address field in the C-line is not 418 relevant, and MUST be ignored. The port field in the M-line MUST be 419 ignored if non-zero. Zero values have the usual meaning for SDP. 421 Both offerer and answerer store the path values received from the 422 peer. For a given endpoint, the local URL is the URL that the 423 endpoint put into a path attribute value to send to its peer. The 424 peer URL is the URL received from the peer. If the path attribute 425 received from the peer contains more than one URL, then the peer URL 426 is the last entry, while the first entry is the connection URL. If 427 only one entry is present, then it is both the peer and connection 428 URL. The remote path is the entire path attribute value received from 429 the peer. 431 The following example shows an SDP offer with a session URL of 432 "msrp://a.example.com:7394/2s93i" 434 v=0 435 o=someuser 2890844526 2890844527 IN IP4 alice.example.com 436 s= 437 c=IN IP4 alice.example.com m=message 9999 msrp/tcp * 438 a=accept-types:text/plain 439 a=path:msrp://a.example.com:7394/2s93i 441 The first URI in the path attribute MUST identify the endpoint that 442 generated the SDP document, or some other location where that 443 endpoint wishes to receive messages associated with the session. If 444 the URL identifies the endpoint, it MUST MUST be a temporary URL 445 assigned just for this particular session, and MUST NOT duplicate any 446 URL in use for any other session in which the endpoint is currently 447 participating. Further, it SHOULD be hard to guess, and protected 448 from eavesdroppers. This will be discussed in more detail in Section 449 10. 451 6.5 Path Attributes with Multiple URLs 453 As mentioned previously, this document describes MSRP for 454 peer-to-peer scenarios, that is, when no relays are used. However, we 455 expect a separate document to describe the use of relays in the near 456 future. The path attribute supports lists of URLs in order to 457 facilitate that work. For peer-to-peer session, a path attribute will 458 contain exactly one URL, describing an endpoint. This means that 459 endpoints that only implement this specification will never send more 460 than one URL in a path attribute, but MUST be prepared to receive 461 more than one. When an endpoint receives more than one URL in a path 462 header, only the first entry is relevant for purposes of resolving 463 the address and port, and establishing the network connection, thus 464 the term connection URL. 466 If an endpoint puts more than one URL in a path attribute, final URL 467 in the path (the peer URL) attribute MUST exhibit the uniqueness 468 properties described above. Uniqueness requirements for other entries 469 in the attribute are out of scope for this document. 471 6.6 Updated SDP Offers 473 To do: Revisit this section based on new connection management rules 475 MSRP endpoints may sometimes need to send additional SDP exchanges 476 for an existing session. They may need to send periodic exchanges 477 with no change to refresh state in the network, for example, SIP 478 timers. They may need to change some other stream in a session 479 without affecting the MSRP stream, or they may need to change an MSRP 480 stream without affecting some other stream. 482 If either party wish to send an SDP document that changes nothing at 483 all, then it MUST have the same o-line version as in the previous 484 exchange. 486 6.7 Example SDP Exchange 488 Endpoint A wishes to invite Endpoint B to a MSRP session. A offers 489 the following session description: 491 v=0 492 o=usera 2890844526 2890844527 IN IP4 alice.example.com 493 s= 494 c=IN IP4 alice.example.com t=0 0 495 m=message 9999 msrp/tcp * 496 a=accept-types: message/cpim text/plain text/html 497 a=path:msrp://alice.example.com:7394/2s93i9 499 Endpoint B performs a VISIT transaction passing the URL of msrp:// 500 alice.example.com:7394/2s93i9. B indicates that it has accomplished 501 this by answering with: 503 v=0 504 o=userb 2890844530 2890844532 IN IP4 bob.example.com 505 s= 506 c=IN IP4 dontlookhere 507 t=0 0 508 m=message 9999 msrp/tcp * 509 a=accept-types:message/cpim text/plain 510 a=path:msrp://bob.example.com:8493/si438ds 512 A may now send IMs to B by executing SEND transactions. 514 6.8 Connection Negotiation 516 Previous versions of this document included a mechanism to negotiate 517 the direction for any required TCP connection. The mechanism was 518 loosely based on COMEDIA [20]work being done in the MMUSIC working 519 group. The primary motivation was to allow MSRP sessions to succeed 520 in situations where the offerer could not accpet connections but the 521 answerer could. For example, the offerer might be behind a NAT, while 522 the answerer might have a globally routable address. 524 The SIMPLE working group chose to remove that mechanism from MSRP for 525 a number of reasons: 527 It added a great deal of complexity to session creation. 528 The work in MSRP had begun to diverge from the work in MMUSIC. 529 There was a lack of successful implementation experience of the 530 COMEDIA work. 532 7. The Message Session Relay Protocol 534 The Message Session Relay Protocol (MSRP) is a text based, message 535 oriented protocol for the transfer of instant messages in the context 536 of a session. MSRP uses the UTF8 character set. 538 MSRP messages MUST be sent over a reliable, congestion-controlled, 539 connection-oriented transport protocol. This document specifies the 540 use of MSRP over TCP. Other documents may specify bindings for other 541 such protocols. 543 7.1 MSRP URLs 545 An MSRP URL follows a subset of the URL syntax in Appendix A of 546 RFC2396 [4], with a scheme of "msrp": 548 msrp_url = "msrp://" [userinfo "@"] hostport ["/" resource] 549 resource = 1*unreserved 551 The constructions for "userinfo", "hostport", and "unreserved" are 552 detailed in RFC2396 [4]. 554 An MSRP URL server part identifies a participant in an MSRP session. 555 If the server part contains a numeric IP address, it MUST also 556 contain a port. The resource part identifies a particular session the 557 participant. The absence of the resource part indicates a reference 558 to an MSRP host device, but does not specifically refer to a 559 particular session resource. 561 MSRP has an IANA registered recommended port defined in Section 9.1. 563 This value is not a default, as the URL process described herein will 564 always explicitly resolve a port number. However, the URLs SHOULD be 565 configured so that the recommended port is used whenever appropriate. 566 This makes life easier for network administrators who need to manage 567 firewall policy for MSRP. 569 The server part will typically not contain a userinfo component, but 570 MAY do so to indicate a user account for which the session is valid. 571 Note that this is not the same thing as identifying the session 572 itself. If a userinfo component exists, MUST be constructed only from 573 "unreserved" characters, to avoid a need for escape processing. 574 Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo 575 part MUST NOT contain password information. 577 The following is an example of a typical MSRP URL: 579 msrp://host.example.com:8493/asfd34 581 7.1.1 MSRP URL Comparison 583 MSRP URL comparisons MUST be performed according to the following 584 rules: 586 1. The host part is compared as case insensitive. 588 2. If the port exists explicitly in either URL, then it must match 589 exactly. An URL with an explicit port is never equivalent to 590 another with no port specified. 592 3. The resource part is compared as case insensitive. A URL without 593 a resource part is never equivalent to one that includes a 594 resource part. 596 4. Userinfo parts are not considered for URL comparison. 598 Path normalization is not relevant for MSRP URLs. Escape 599 normalization is not required, since the relevant parts are limited 600 to unreserved characters. 602 7.1.2 Resolving MSRP Host Device 604 An MSRP host device is identified by the server part of an MSRP URL. 606 If the server part contains a numeric IP address and port, they MUST 607 be used as listed. 609 If the server part contains a host name and a port, the connecting 610 device MUST determine a host address by doing an A or AAAA DNS query, 611 and use the port as listed. 613 If the server part contains a host name but no port, the connecting 614 device MUST perform the following steps: 616 1. Construct an SRV [6] query string by prefixing the host name with 617 the service field "_msrp" and the protocol field ("_tcp" for 618 TCP). For example, "_msrp._tcp.host.example.com". 620 2. Perform a DNS SRV query using this query string. 622 3. Select a resulting record according to the rules in RFC2782 [6]. 623 Determine the port from the chosen record. 625 4. If necessary, determine a host device address by performing an A 626 or AAAA query on the host name field in the selected SRV result 627 record. If multiple A or AAAA records are returned, the first 628 entry SHOULD be chosen for the initial connection attempt. This 629 allows any ordering created in the DNS to be preserved. 631 5. If the connection attempt fails, the device SHOULD attempt to 632 connect to the addresses returned in any additional A or AAAA 633 records, in the order the records were presented. If all of these 634 fail, the device SHOULD attempt to use any additional SRV records 635 that may have been returned, following the normal rules for SRV 636 record selection. 638 In most cases, the transport protocol will be determined separately 639 from the resolution process. For example, if the MSRP URL was 640 communicated in an SDP offer or answer, the SDP M-line will contain 641 the transport protocol. When an MSRP URL is communicated outside of 642 SDP, the protocol SHOULD also be communicated. If a device needs to 643 resolve an MSRP URL and does not know the protocol, it SHOULD assume 644 TCP. 646 7.1.3 The msrps URL Scheme 648 The "msrps" URL Scheme indicates that each hop MUST be secured with 649 TLS. Otherwise, it is used identically as an MSRP URL, except that a 650 MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS 651 scheme is further discussed in Section 10. 653 7.2 Connection Managment 655 When an MSRP endpoint receives an SDP offer, and intends to accept 656 it, it MUST establish a connection device described by the connection 657 URL, if a connection does not already exist. If it already has a 658 connection associated with another session for which the connection 659 URL host part matches the host part of the connection URL for this 660 session, it SHOULD use the that connection, instead. Once connected, 661 the answerer MUST send a VISIT request to associate the new session 662 with the connection, prior to sending the SDP answer. 664 Either endpoint MAY tear down a connection when it no longer has any 665 active or proposed sessions associated with the connection. 667 7.3 MSRP messages 669 MSRP messages are either requests or responses. Requests and 670 responses are distinguished from one another by the first line. The 671 first line of a Request takes the form of the request-start entry 672 below. Likewise, the first line of a response takes the form of 673 response-start. The syntax for an MSRP message is as follows: 675 msrp-message = request-start/response-start *(header CRLF) 676 [CRLF body] 677 request-start = "MSRP" SP length SP Method CRLF 678 response-start = "MSRP" SP length SP Status-Code SP 679 Reason CRLF 681 length = 1*DIGIT ; the length of the message, 682 ; exclusive of the start line. 683 Method = SEND / VISIT / other-method 684 other-method = token 685 header = Tran-ID / Session-URL / Content-Types / 686 From / To / Message-Receipt / Receipt-ID / 687 Byte-Range 689 Status-Code = 200 ;Success 690 / 400 ;Bad Request 691 / 403 ;Forbidden 692 / 415 ;Unsupported Content Type 693 / 426 ;Upgrade Required 694 / 481 ;No session 695 / 506 ;duplicate session 697 Reason = token ; Human readable text describing status 698 Tran-ID = "Tr-ID" ":" token 700 Content-Type = "Content-Type" ":" media-type 701 media-type = type "/" subtype *( ";" parameter ) 702 type = token 703 subtype = token 704 parameter = attribute "=" value 705 attribute = token 706 value = token | quoted-string 708 To = "To" ":" msrp_url *(SP msrp_url) 709 From = "From" ":" msrp_url 711 Message-Receipt = "Message-Receipt" ":" message-receipt-spec 712 ( SEMI receipt-type ) 713 message-receipt-spec = "negative" / "none" / "all" 714 receipt-type = "receipt-type" "=" alt-receipt-type 715 alt-receipt-type = r-type SLASH r-subtype *(SEMI r-parameter) 716 r-type = discrete-type / composite-type 717 discrete-type = "text" / "image" / "audio" / "video" 718 / "application" / extension-token 719 composite-type = "message" / "multipart" / extension-token 720 extension-token = ietf-token / x-token 721 ietf-token = token 722 x-token = "x-" token 723 r-subtype = extension-token / iana-token 724 iana-token = token 725 r-parameter = r-attribute "=" r-value 726 r-attribute = token 727 r-value = token / quoted-string 729 Receipt-ID = "Receipt-ID" ":" token 731 Byte-Range = "Byte-Range" ":" byte-range-spec 732 byte-range-spec = first-byte "-" last-byte 733 first-byte = 1*DIGIT 734 last-byte = 1*DIGIT 736 All requests and responses MUST contain at least a TR-ID header 737 field. All requests must also contain the To and From header fields. 738 Messages MAY contain other fields, depending on the method or 739 response code. 741 7.4 MSRP Transactions 743 An MSRP transaction consists of exactly one request and one response. 744 A response matches a transaction if it share the same TR-ID value, 745 and arrives on the same connection on which the transaction was sent. 747 Endpoints MUST select TR-ID header field values in requests so that 748 they are not repeated by the same endpoint in scope of the given 749 session. TR-ID values SHOULD be globally unique. The TR-ID space of 750 each endpoint is independent of that of its peer. Endpoints MUST NOT 751 infer any semantics from the TR-ID header field beyond what is stated 752 above. In particular, TR-ID values are not required to follow any 753 sequence. 755 MSRP Transactions complete when a response is received, or after a 756 timeout interval expires with no response. Endpoints MUST treat such 757 timeouts in exactly the same way they would treat a 500 response. The 758 timeout interval SHOULD be 30 seconds, but other values may be 759 established as a matter of local policy. 761 7.5 MSRP Sessions 763 AN MSRP session is a context in which a series of instant messages 764 are exchanged, using SEND requests. A session has two endpoints, 765 identified by MSRP URLs. 767 7.5.1 Initiating an MSRP session 769 When an endpoint wishes to engage a peer in a message session, it 770 invites the peer to communicate using an SDP offer, carried over SIP 771 or some other protocol supporting the SDP offer/answer model. For the 772 purpose of this document, we will refer to the endpoint choosing to 773 initiate communication as the offerer, and the peer being invited as 774 the answerer. 776 The offerer MUST be prepared to accept a connection from the 777 answerer. 779 The offerer MUST perform the following steps: 781 1. Construct a MSRP URL to serve as the local URL. This URL MUST 782 resolve to the location that the offerer wishes to host the 783 connection. 785 2. Listen for a connection from the peer. 787 3. Construct an SDP offer as described in Section 6, including the 788 list of allowed IM payload formats in the accept-types attribute. 789 The offerer puts its local URL into the path attribute, as 790 described in Section 6.4. This URL becomes the offerer's local 791 path. 793 4. Send the SDP offer using the normal processing for the signaling 794 protocol. 796 If the answerer chooses to participate, it MUST perform the following 797 steps: 799 1. Parse the first URL from the offered path attribute, to be the 800 connection URL. The full path attribute value will be the 801 answerer's remote path. If the path only contained a single URL 802 entry, then the connection URL and the remote path are identical. 804 2. Determine if it has any existing connection that is associated 805 with a connection URL host part that matches that of the 806 connection URL for this session, and with a transport protocol 807 matching that from the M-line. If one exists, the answerer SHOULD 808 use it for the new session rather than establishing a new 809 connection. 811 [Open Issue: Should we discuss situations when an endpoint may 812 want to intentially not share a connection?] 814 3. If no appropriate connection already exists, determine the host 815 address and port from the peer URL, following the procedures in 816 section Section 7.1, and connect using the transport protocol 817 from the M-line. 819 4. Construct a MSRP URL . This URL MUST resolve to the the answerer. 820 This URL becomes the answerer's local URL. 822 5. Construct a VISIT request, which MUST contain the following 823 information: 825 1. An To header field containing the remote URL. 827 2. A From containing the answerer's local URL. 829 3. A TR-ID header field containing a unique transaction ID. 831 4. A size field containing size of the message subsequent to the 832 start-line. 834 6. Send the request and wait for a response 836 7. If the VISIT transaction succeeds, send a SDP answer via the 837 signaling protocol, according to the following rules: 839 1. The C-line is copied unmodified from the offer. 841 2. The M-Line contains a dummy port value, the protocol field 842 from the original offer. 844 3. The accept-types attribute contains the SEND payload media 845 types that the answerer is willing to accept. The 846 accept-types attribute in the answer MUST be either the same 847 as that of the offer, or it MUST be a subset. 849 4. The path attribute contains the answerer's local URL. 850 8. If the VISIT transaction fails, the answerer MUST reject the 851 offer. 853 7.5.2 Handling VISIT requests 855 An MSRP endpoint that is hosting a session will receive a VISIT 856 request from the visiting endpoint. When an endpoint receives a VISIT 857 request, it MUST perform the following procedures: 859 1. Check if state exists for a session with a local URL that matches 860 the To header field value of the VISIT request. If so, and if no 861 previous VISIT request has been received for that URL, then 862 return a 200 response, and save state associating the URL in the 863 From header field with the connection on which the request was 864 received . 866 2. If the state exists, and a matching VISIT transaction has already 867 occured, return a 506 response and do not change session state in 868 any way. 870 3. If no matching state exists, return a 481 response, and do not 871 change session state in any way. 873 7.5.3 Sending Instant Messages on a Session 875 Once a MSRP session has been established, either endpoint may send 876 instant messages to its peer using the SEND method. When an endpoint 877 wishes to do so, it MUST construct a SEND request according to the 878 following process: 880 1. Insert a To header field containing the remote path. Note that 881 this is the full remote path, not just the connection or peer 882 URL. 884 2. Insert a From header field containing the local URL. 886 3. Insert the message payload in the body, and the media type in the 887 Content-Type header field. The media type MUST match one of the 888 types in the format list negotiated in the SDP exchange. If a "*" 889 was present in the accept-types attribute, then the media type 890 SHOULD match one of the explicitly listed entries, but MAY be any 891 other arbitrary value. 893 4. Set the TR-ID header field to a unique value. 895 5. Send the request on the connection associated with the session. 897 6. If a 2xx response code is received, the transaction was 898 successful. 900 7. If a 415 response is received, this indicates the recipient is 901 unable or unwilling to process the media type. The sender SHOULD 902 NOT attempt to send that particular media type again in the 903 context of this session. 905 8. If any other response code is received, or if the transaction 906 times out, the endpoint SHOULD assume the session has failed, 907 either tear down the session, or attempt to re-establish the 908 session by sending an updated SDP offer proposing a new 909 connection. If a new connection is established, the endpoint MAY 910 choose to resend the content on the new connection. 912 Open Issue: Do we need to create a duplicate mechanism to suppress 913 duplicate messages when a new connection is established in this 914 fashion? mechanism? List consensus seems to indicate we do. We may 915 need to specify that the tr-id space spans a sequence of 916 connections if they are associated with same stream, and of 917 course, specify what it means for a stream to span connections. 919 When an endpoint receives a SEND request, it MUST perform the 920 following steps. 922 1. Check that it has state for a session with a local URL matching 923 the To value. If no matching session exists, return a 481 924 response. 925 2. Determine that it understands the media type in the body, if any 926 exists. 928 3. If it does, return a 200 response and render the message to the 929 user. The method of rendering is a matter of local policy. If the 930 message contained no body at all, the endpoint should quietly 931 ingore it. 933 4. If it does not understand the media type, return a 415 response. 934 The endpoint MUST NOT return a 415 response for any media type 935 for which it indicated support in the SDP exchange. 937 7.5.4 Ending a Session 939 When either endpoint in an MSRP session wishes to end the session, it 940 first signals its intent using the normal processing for the 941 signaling protocol. For example, in SIP, it would send a BYE request 942 to the peer. After agreeing to end the session, the host endpoint 943 MUST release any resources acquired as part of the session. 945 Each peer MUST destroy all local state for the session. This involves 946 completely removing the state entry for the session and invalidating 947 the session URL. 949 If no other sessions are using the connection, the endpoint that 950 opened it SHOULD tear it down. However, the passive party MAY tear 951 down an unused connection after a locally configured timeout period. 953 When an endpoint chooses to close a session, it may have SEND 954 transactions outstanding. For example, it may have send SEND requests 955 to which it has not yet received a response, or it may have received 956 SEND requests that to which it has not responded. Once an endpoint 957 has decided to close the connection, it SHOULD wait for such 958 outstanding transactions to complete. It SHOULD NOT generate any new 959 SEND transactions, and it MAY choose not to respond to any new SEND 960 requests that are received after it decides to close the session. It 961 SHOULD not respond to any new messages that arrive after it signals 962 its intent to close the session. 964 When an endpoint is signaled of its peer's intent to close a session, 965 it SHOULD NOT initiate any more SEND requests. It SHOULD wait for any 966 outstanding transactions that it initiated to complete, and it SHOULD 967 attempt respond to any open SEND transactions received prior to being 968 signaled. 970 It is not possible to completely eliminate the chance of a session 971 terminating with incomplete SEND transactions. When this occurs, the 972 endpoint SHOULD clearly inform the user that the messages may not 973 have been delivered. 975 7.5.5 Managing Session State and Connections 977 A MSRP session is represented by state at each endpoint, identified 978 by the local URL and remote path. An active session also has an 979 associated network connection. 981 If the connection fails for any reason, the session hosting device 982 MUST invalidate the session state for all sessions using the 983 connection. Once a connection is dropped, any associated session 984 state MUST NOT be reused. If an endpoint wishes to continue to 985 communicate after detecting a connection failure, it MAY initiate a 986 new SDP exchange to negotiate a new session URL. Otherwise, it SHOULD 987 attempt to tear down the session using the rules of the signaling 988 protocol. 990 It would be nice to allow sessions to be recovered after a 991 connection failure, perhaps by allowing the active endpoint to 992 reconnect, and send a new VISIT request. However, this approach 993 creates a race condition between the time that the hosting device 994 notices the failed connection, and the time that the endpoint 995 tries to recover the session. If the endpoint attempts to 996 reconnect prior to the hosting device noticing the failure, the 997 hosting device will interpret the recovery attempt as a conflict. 998 The only way around this would be to force the hosting device to 999 do a liveness check on the original connection, which would create 1000 a lot of complexity and overhead that do not seem to be worth the 1001 trouble. 1003 Open Issue: Is this still an issue with shared connections? 1005 7.6 Delivery Status Notification 1007 Delivery Status Notification (DSN)[10] provides an extensible MIME 1008 content-type that is used to convey both positive and negative status 1009 of messages in the network. This functionality is extremely useful 1010 for MSRP sessions that traverse a relay device. Relay support is 1011 considered out of scope for this specification and will be included 1012 in a separate specification. This section will only cover 1013 functionality required by non-relay aware endpoints for basic MSRP 1014 operation. An MSRP endpoint MUST be capable of performing the DSN 1015 operations described in this specification and SHOULD support the DSN 1016 MIME type outlined. An MSRP endpoint MAY use an alternative payload 1017 for reporting message status using the procedures outlined in this 1018 specification which MUST be negotiated during the SDP offer/answer 1019 exchange. 1021 7.6.1 Endpoint DSN Request 1023 An endpoint that wishes to be informed of message delivery/failure 1024 needs to request such information. This is achieved by including an 1025 MSRP Receipt-Request header in the request. The header can equal one 1026 of three values: 1028 negative: Indicates the client only requires failure delivery report. 1030 none: Indicates the client requires no delivery reports. 1032 all: Indicates the client requires both positive and negative 1033 delivery reports. 1035 Within the scope of this specification the Receipt-Request header is 1036 only used in MSRP SEND requests. Future extensions to this 1037 specification MAY use the mechanism described in this document for 1038 delivery/failure status notification of other MSRP requests. 1040 The default value for this header if not present in a request is 1041 'negative'. An example of this header would be: 1043 Message-Receipt: negative 1045 The default DSN MIME type is detailed in RFC 1894[10]. It is 1046 possible for MSRP endpoints to use a different format if required. 1047 This can be achieved by including a 'receipt-type' parameter in the 1048 Message-Receipt header. This parameter contains the alternative MIME 1049 type that SHOULD be used for this particular receipt transaction. 1050 The value included in this header MUST equal a value negotiated 1051 during the SDP offer/answer exchange. 1053 Open Issue: If we negotiate this in the SDP, that also means the 1054 format would be legal for normal messages. Is this okay? Also, I 1055 assume that if we negotiated "*" in the sdp, then any format would be 1056 legal? Do we even need this to be extensible? 1058 Open Issue: Is the RFC1894 the right thing to use? Do we need to add 1059 further verbiage on the format beyond the reference to the RFC? 1061 7.6.2 DSN generation 1063 An MSRP endpoint implementing this specification SHOULD be able to 1064 generate positive delivery status of MSRP requests. On receiving an 1065 MSRP request containing a Message-Receipt header with a value of 1066 TRUE, the endpoint will carry out normal MSRP response generation and 1067 MUST generate an MSRP REPORT request using the following procedures: 1069 1. Insert a To header containing the From value from the original 1070 request. 1071 2. Insert a From header containing the To value from the original 1072 request. 1073 3. Insert the message status payload in the body of the request. If 1074 the default DSN MIME type from DSN[10] is used then the MSRP 1075 Content-Type header MUST use the value multipart/report. The 1076 relevance of DSN headers in MSRP can be found in section 7.6.5. 1077 An alternative MIME type MAY be used but MUST be specified in the 1078 Content-Type header. Negative DSN generation is considered out 1079 of the scope of this document and will be covered in a separate 1080 MSRP relay document. 1081 4. Insert a new transaction ID (TR-ID). 1082 5. Insert the TR-ID value that appeared in the original MSRP request 1083 into the Receipt-ID header. This allows a requesting client to 1084 explicitly correlate a REPORT request with the original request. 1085 This correlation is implementation specific and makes no 1086 requirements on clients to hold state for transactions ID's. 1087 Information regarding the original request can be obtained from 1088 the DSN MIME type outlined in [10]. 1090 6. If the associated SEND request contained a chunk, that is, used 1091 the "message/byteranges" fromat, insert an MSRP Byte-Range header 1092 containing the value from the Content-range header field. It is 1093 possible that an intermediary device may have broken the MSRP 1094 SEND request into chunks without the knowledge of the sending 1095 client. 1097 7.6.3 Receiving positive DSN 1099 An MSRP endpoint implementing this specification MUST be able to 1100 receive positive delivery status of MSRP requests. 1102 7.6.4 Receiving negative DSN 1104 An MSRP endpoint implementing this specification MUST be able to 1105 receive negative delivery status of MSRP requests. 1107 7.6.5 DSN headers in MSRP 1109 To Do - Define meaning + relevance of DSN headers. 1111 7.7 Message Fragmentation 1113 MSRP devices MAY break large content into fragments, and send each 1114 fragment in a separate SEND request. Each fragment is encapsulated 1115 using the "message/byteranges" MIME type, defined in RFC2616 [11], to 1116 correlate parts of the message. The definition of large is 1117 determined by local policy. MSRP endpoints MUST be capable of 1118 receiving and processing fragmented messages. 1120 Open Issue: Do we want to negotiate the use of message/byterange like 1121 any other MIME type? I assume no, as we want to allow relays to 1122 fragment messages, and relays are not privy to the content-types 1123 negotiated for a session. 1125 Although relays are not in scope for this document, we expect that 1126 relays will be able to introduce fragmentation, as well as change the 1127 fragmentation of previously fragemented messages. Therefore, all MSRP 1128 endpoints MUST be able to receive fragmented messages. 1130 7.7.1 MSRP Usage of message/byteranges 1132 The "message/byteranges" type allows multiple ranges in a single 1133 document. However, MSRP devices MUST NOT include more than one byte 1134 range in a single request. Although the HTTP usage for a document 1135 containing a single byte range indicates putting the "Content-Range" 1136 header in a header field, rather than in the body itself, 1137 "Content-Range" MUST NOT appear as an MSRP header field. 1139 [Open Issue: How much of the message/byteranges specification should 1140 we explain or copy forward? Copying too much obscures the fact that 1141 rfc2616 is the normative definition, but it may be helpful to have 1142 more context here.] 1144 If the MSRP device has a priori knowledge of the overall content 1145 length, it SHOULD put that length into instance-length. The device 1146 MAY place a "*" in instance-length if it does not have such 1147 knowledge. 1149 Similarly, if the device has a priori knowledge of the number of 1150 bytes in a byte range, it SHOULD place the last bype position in 1151 last-byte-pos. Otherwise, it MAY use a "*". If "*" is present, the 1152 recipient MUST determine the last-byte-position through normal 1153 request framing and body processing. An MSRP device MUST put the 1154 initial byte position in first-byte-pos. 1156 7.8 Method Descriptions 1158 This section summarizes the purpose of each MSRP method. All MSRP 1159 messages MUST contain the TR-ID, From, and To header fields. All 1160 messages MUST contain a length field in the start line that indicates 1161 the overall length of the request, including any body, but not 1162 including the start line itself. Additional requirements exist 1163 depending on the individual method. 1165 7.8.1 SEND 1167 The SEND method is used by both the host and visitor endpoints to 1168 send instant messages to its peer endpoint. A SEND request MUST 1169 contain a To header field containing the sender's remote path, and a 1170 From header field containing the sender's local URL. SEND requests 1171 SHOULD contain a MIME body part. The body MUST be of a media type 1172 included in the format list negotiated in the SDP exchange. If a body 1173 is present, the request MUST contain a Content-Type header field 1174 identifying the media type of the body. 1176 To Do: We plan to expand the use of MIME headers to allow any 1177 standard MIME header in a SEND request. This is not included in 1178 this version for the sake of getting the draft out as soon as 1179 possible, but will follow soon. 1181 7.8.2 VISIT 1183 The visiting endpoint uses the VISIT method to associate a network 1184 connection with the session state at the hosting device. A VISIT 1185 request MUST include a To header including the sender's connection 1186 URL, and a From header field containing the sender's local URL. 1188 7.8.3 REPORT 1190 Report is used by an endpoint/relay to convey message delivery status 1192 7.9 Response Code Descriptions 1194 This section summarizes the various response codes. Except where 1195 noted, all responses MUST contain a TR-ID header field matching the 1196 TR-ID header field of the original request, and To and From headers 1197 matching those of the original request. 1199 7.9.1 200 1201 The 200 response code indicates a successful transaction. 1203 7.9.2 400 1205 A 400 response indicates a request was unintelligible. 1207 7.9.3 415 1209 A 415 response indicates the SEND request contained a MIME 1210 content-type that is not understood by the receiver. 1212 7.9.4 426 1214 A 426 response indicates that the request is only allowed over TLS 1215 protected connections. 1217 7.9.5 481 1219 A 481 response indicates that no session exists for the connection. 1221 7.9.6 506 1223 A 506 response indicates that a VISIT request occurred in which the 1224 To header indicates a local path that is already associated with 1225 another connection. A 506 response MUST NOT be returned in response 1226 to any method other than VISIT. 1228 7.10 Header Field Descriptions 1230 This section summarizes the various header fields. MSRP header fields 1231 are single valued; that is, they MUST NOT occur more than once in a 1232 particular request or response. 1234 7.10.1 TR-ID 1236 The TR-ID header field contains a transaction identifier used to map 1237 a response to the corresponding request. A TR-ID value MUST be unique 1238 among all values used by a given endpoint inside a given session. 1239 MSRP elements MUST NOT assume any additional semantics for TR-ID. 1241 7.10.2 To 1243 The To header field is used to indicate the sender's remote path. All 1244 MSRP requests MUST contain a To header field. 1246 7.10.3 From 1248 The From header field is used to indicate the sender's local URL. All 1249 MSRP requests MUST contain a From header field. 1251 7.10.4 Content-Type 1253 The Content-Type header field is used to indicate the MIME media type 1254 of the body. Content-Type MUST be present if a body is present. 1256 To Do: The work group has agreed to allow the use of any standard 1257 MIME header. This is not reflected in this version, but will be in 1258 a shortly forthcoming one. 1260 8. Example 1262 This section shows an example message flow for the most common 1263 scenario. The example assumes SIP is used to transport the SDP 1264 exchange. Details of the SIP messages and SIP proxy infrastructure 1265 are omitted for the sake of brevity. In the example, assume the 1266 offerer is sip:alice@atlanta.com and the answerer is 1267 sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length 1268 field indicates the actual length of the rest of the message. 1270 Alice Bob 1271 | | 1272 | | 1273 |(1) (SIP) INVITE | 1274 |----------------------->| 1275 |(2) (MSRP) VISIT | 1276 |<-----------------------| 1277 |(3) (MSRP) 200 OK | 1278 |----------------------->| 1279 |(4) (SIP) 200 OK | 1280 |<-----------------------| 1281 |(5) (SIP) ACK | 1282 |----------------------->| 1283 |(6) (MSRP) SEND | 1284 |----------------------->| 1285 |(7) (MSRP) 200 OK | 1286 |<-----------------------| 1287 |(8) (MSRP) SEND | 1288 |<-----------------------| 1289 |(9) (MSRP) 200 OK | 1290 |----------------------->| 1291 |(10) (SIP) BYE | 1292 |----------------------->| 1293 |(11) (SIP) 200 OK | 1294 |<-----------------------| 1295 | | 1296 | | 1298 1. Alice constructs a local URL of msrp://alicepc.atlanta.com:7777/ 1299 iau39 and listens for a connection on TCP port 7777. 1301 Alice->Bob (SIP): INVITE sip:bob@biloxi.com 1303 v=0 1304 o=alice 2890844557 2890844559 IN IP4 host.anywhere.com 1305 s= 1306 c=IN IP4 fillername 1307 t=0 0 1308 m=message 9999 msrp/tcp * 1309 a=accept-types:text/plain 1310 a=path:msrp://alicepc.atlanta.com:7777/iau39 1312 2. Bob opens a TCP connection to alicepc.atlanta.com:7777: 1314 Bob->Alice (MSRP): 1316 MSRP xx VISIT 1317 To:msrp://alicepc.atlanta.com:7777/iau39 1318 From:msrp://bob.atlanta.com:8888/9di4ea 1319 Tr-ID:sie09s 1321 3. Alice->Bob (MSRP): 1323 MSRP xx 200 OK 1324 To:msrp://alicepc.atlanta.com:7777/iau39 1325 From:msrp://bob.atlanta.com:8888/9di4ea 1326 Tr-ID:sie09s 1328 4. Bob->Alice (SIP): 200 OK 1330 v=0 1331 o=bob 2890844612 2890844616 IN IP4 host.anywhere.com 1332 s= 1333 c=IN IP4 ignorefield 1334 t=0 0 1335 m=message 9999 msrp/tcp * 1336 a=accept-types:text/plain 1337 a=path:msrp://bob.atlanta.com:8888/9di4ea 1339 5. Alice->Bob (SIP): ACK 1341 6. Alice->Bob (MSRP): 1343 MSRP xx SEND 1344 To:msrp://bob.atlanta.com:8888/9di4ea 1345 From:msrp://alicepc.atlanta.com:7777/iau39 1346 TR-ID: 123 1347 Content-Type: "text/plain" 1348 Hi, I'm Alice! 1350 7. Bob->Alice (MSRP): 1352 MSRP xx 200 OK 1353 To:msrp://bob.atlanta.com:8888/9di4ea 1354 From:msrp://alicepc.atlanta.com:7777/iau39 1355 TR-ID: 123 1357 8. Bob->Alice (MSRP): 1359 MSRP xx SEND 1360 To:msrp://alice.atlanta.com:7777/iau39 1361 From:msrp://bob.atlanta.com:8888/9di4ea 1362 TR-ID: 456 1363 Content-Type: "text/plain" 1365 Hi, Alice! I'm Bob! 1367 9. Alice->Bob (MSRP): 1369 MSRP xx 200 OK 1370 To:msrp://alice.atlanta.com:7777/iau39 1371 From:msrp://bob.atlanta.com:8888/9di4ea 1372 TR-ID: 456 1374 10. Alice->Bob (SIP): BYE 1376 Alice invalidates local session state. 1378 11. Bob invalidates local state for the session. 1380 Bob->Alice (SIP): 200 OK 1382 9. IANA Considerations 1384 9.1 MSRP Port 1386 MSRP uses TCP port XYX, to be determined by IANA after this document 1387 is approved for publication. Usage of this value is described in 1388 Section 7.1 1390 9.2 MSRP URL Schemes 1392 This document defines the URL schemes of "msrp" and "msrps". 1394 9.2.1 Syntax 1396 See Section 7.1. 1398 9.2.2 Character Encoding 1400 See Section 7.1. 1402 9.2.3 Intended Usage 1404 See Section 7.1. 1406 9.2.4 Protocols 1408 The Message Session Relay Protocol (MSRP). 1410 9.2.5 Security Considerations 1412 See Section 10. 1414 9.2.6 Relevant Publications 1416 RFCXXXX 1418 [Note to RFC Editor: Please replace RFCXXXX in the above paragraph 1419 with the actual number assigned to this document. 1421 9.3 SDP Parameters 1423 This document registers the following SDP parameters in the 1424 sdp-parameters registry: 1426 9.3.1 Accept Types 1428 Attribute-name: accept-types 1429 Long-form Attribute Name Acceptable MIME Types 1430 Type: Media level 1431 Subject to Charset Attribute No 1432 Purpose and Appropriate Values See Section 6.2. 1434 9.3.2 Wrapped Types 1436 Attribute-name: accept-wrapped-types 1437 Long-form Attribute Name Acceptable MIME Types Inside Wrappers 1438 Type: Media level 1439 Subject to Charset Attribute No 1440 Purpose and Appropriate Values See Section 6.3. 1442 9.3.3 Path 1444 Attribute-name: path 1445 Long-form Attribute Name MSRP URL Path 1446 Type: Media level 1447 Subject to Charset Attribute No 1448 Purpose and Appropriate Values See Section 6.4. 1450 10. Security Considerations 1452 There are a number of security considerations for MSRP, some of which 1453 are mentioned elsewhere in this document. This section discusses 1454 those further, and introduces some new ones. 1456 10.1 TLS and the MSRPS Scheme 1458 All MSRP devices must support TLS, with at least the 1459 TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites 1460 MAY be supported. 1462 MSRP does not define a separate TCP port for TLS connections. This 1463 means that all MSRP server devices, that is, all devices that listen 1464 for TCP connections, MUST be prepared to handle both TLS and plain 1465 text connections on the same port. When a device accepts a TCP 1466 connection, it MUST watch for the TLS handshake messages to determine 1467 if a particular connection uses TLS. If the first data received is 1468 not part of a start TLS request, the device ceases to watch for the 1469 TLS handshake until it reads the entire message. Once the message has 1470 been completely received, the device resumes watching for the start 1471 TLS message. 1473 Any MSRP device MAY refuse to accept a given request over a non-TLS 1474 connection by returning a 426 response. 1476 MSRP devices acting in the role of TCP client MAY perform a TLS 1477 handshake at any time, as long as the request occurs between MSRP 1478 messages. The endpoint MUST NOT send a start TLS request in the 1479 middle of an MSRP message. 1481 The working group considered only requiring the endpoint to watch 1482 for a TLS handshake at the beginning of the session. However, the 1483 endpoint should be able to determine if a new message is a start 1484 TLS request or an MSRP request by only reading ahead three bytes. 1485 Therefore, the working group chose to allow a session to switch to 1486 TLS in mid-stream, as long as the switch occurs between MRSP 1487 messages. 1489 The MSRPS URI scheme indicates that all hops in an MSRP session MUST 1490 be protected with TLS. Since this document does not specify the use 1491 of intermidiary devices, then MSRPS support is trivially equivilant 1492 to TLS support. However, if intermediaries do exist, either as 1493 described in an MSRP extension document, or as some sort of 1494 proprietary devices, they MUST ensure protection at all hops for an 1495 MSRPS URL. 1497 A VISIT request for an MSRPS URL MUST be sent over a TLS protected 1498 connection. If a hosting device receives a VISIT request for an MSRPS 1499 URL over an unprotected connection, it MUST reject the request with a 1500 426 response. 1502 10.1.1 Sensitivity of the Session URL 1504 The URL sent in the SDP offer for a MSRP session is used by the 1505 answerer to identify itself to the hosting device. If an attacker 1506 were able to acquire the session URL, either by guessing it or by 1507 eavesdropping, there is a window of opportunity in which the attacker 1508 could hijack the session by sending a VISIT request to the host 1509 device before the true visiting endpoint. Because of this 1510 sensitivity, the session URL SHOULD be constructed in a way to make 1511 it difficult to guess, and should be sufficiently random so that it 1512 is unlikely to be reused. All mechanisms used to transport this URL 1513 to the answerer SHOULD be protected from eavesdroppers and 1514 man-in-the-middle attacks. 1516 Therefore a MSRP device MUST support the use of TLS for at least the 1517 VISIT request, which by extension indicates the endpoint MUST support 1518 the use of TLS for all MSRP messages. Further, MSRP connections 1519 SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST 1520 be capable of using the security features of the signaling protocol 1521 in order to protect the SDP exchange and SHOULD actually use them on 1522 all such exchanges. End-to-end protection schemes SHOULD be preferred 1523 over hop-by-hop schemes for protection of the SDP exchange. 1525 10.1.2 End to End Protection of IMs 1527 Instant messages can contain very sensitive information. As a result, 1528 as specified in RFC 2779 [3], instant messaging protocols need to 1529 provide for encryption, integrity and authentication of instant 1530 messages. Therefore MSRP endpoints MUST support the end-to-end 1531 encryption and integrity of bodies sent via SEND requests using 1532 Secure MIME (S/MIME) [7]. 1534 Note that while each protected body could use separate keying 1535 material, this is inefficient in that it requires an independent 1536 public key operation for each message. Endpoints wishing to invoke 1537 end-to-end protection of message sessions SHOULD exchange symmetric 1538 keys in SDP k-lines, and use secret key encryption on for each MSRP 1539 message. When symmetric keys are present in the SDP, the offer-answer 1540 exchange MUST be protected from eavesdropping and tampering using the 1541 appropriate facilities of the signaling protocol. For example, if the 1542 signaling protocol is SIP, the SDP exchange MUST be protected using 1543 S/MIME. 1545 10.1.3 CPIM compatibility 1547 MSRP sessions may be gatewayed to other CPIM [19]compatible 1548 protocols. If this occurs, the gateway MUST maintain session state, 1549 and MUST translate between the MSRP session semantics and CPIM 1550 semantics that do not include a concept of sessions. Furthermore, 1551 when one endpoint of the session is a CPIM gateway, instant messages 1552 SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST 1553 include "message/cpim" as the first entry in its SDP accept-types 1554 attribute. MSRP endpoints sending instant messages to a peer that has 1555 included 'message/cpim" as the first entry in the accept-types 1556 attribute SHOULD encapsulate all instant message bodies in "message/ 1557 cpim" wrappers. All MSRP endpoints MUST support the message/cpim 1558 type, and SHOULD support the S/MIME features of that format. 1560 10.1.4 PKI Considerations 1562 Several aspects of MSRP will benefit from being used in the context 1563 of a public key infrastructure. For example, the MSRPS scheme allows, 1564 and even encourages, TLS connections between endpoint devices. And 1565 while MSRP allows for a symmetric session key to protect all messages 1566 in a session, it is most likely that session key itself would be 1567 exchanged in a signaling protocol such as SIP. Since that key is 1568 extremely sensitive, its exchange would also need to be protected. In 1569 SIP, the preferred mechanism for this would be S/MIME, which would 1570 also benefit from a PKI. 1572 However, all of these features may be used without PKI. Each endpoint 1573 could instead use self signed certificates. This will, of course, be 1574 less convenient than with a PKI, in that there would be no 1575 certificate authority to act as a trusted introducer. Peers would be 1576 required to exchange certificates prior to securely communicating. 1578 Since, at least for the immediate future, any given MSRP 1579 implementation is likely to communicate with at least some peers that 1580 do not have a PKI available, MSRP implementations SHOULD support the 1581 use of self-signed certificates, and SHOULD support the ability to 1582 configure lists of trusted certificates. 1584 To Do: Add text discussion the use of TLS certificates in more 1585 detail. 1587 11. Changes from Previous Draft Versions 1589 This section to be deleted prior to publication as an RFC 1591 11.1 draft-ietf-simple-message-sessions-04 1593 Removed the direction attribute. Rather than using a comedia 1594 styled direction negotiation, we just state that the answerer 1595 opens any needed connection. 1596 Changed the use of session URLs. Instead of a single session URL, 1597 each endpoint is identified by a distinct URL. MSRP requests will 1598 put the destination URL in a To header, and the sender URL in a 1599 From header. 1600 Changed the SDP exchange of MSRP URLs to handle the URL for each 1601 endpoint. Further, changed the SDP attribute to support a list of 1602 URLs in each direction. This may be used with relays to exchange 1603 paths, rather than single URLs. MSRP endpoints must be able to 1604 intelligently process such a list if received. This document does 1605 not, however, describe how to generate such a list. 1606 Added section for Delivery Status Notification handling, and added 1607 associated entries into the syntax definition. 1609 Added content fragmentation section. 1610 Removed recommendation to start separate session for large 1611 transfers. 1612 Corrected some mistakes in the syntax definitions. 1613 Added Chris Boulton as a co-author for his contribution of the DSN 1614 text. 1616 11.2 draft-ietf-simple-message-sessions-03 1618 Removed all specification of relays, and all features specific to 1619 the use of relays. The working group has chosen to move relay work 1620 into a separate effort, in order to advance the base 1621 specification. (The MSRP acronym is unchanged for the sake of 1622 convenience.) This included removal of the BIND method, all 1623 response codes specific to BIND, Digest Authentication, and the 1624 inactivity timeout. 1625 Removed text indicating that an endpoint could retry failed 1626 requests on the same connection. Rather, the endpoint should 1627 consider the connection dead, and either signal a reconnection or 1628 end the session. 1629 Added text describing subsequent SDP exchanges. Added mandatory 1630 "count" parameter to the direction attribute to allow explicit 1631 signaling of the need to reconnect. 1632 Added text to describe the use of send and receive only indicators 1633 in SDP for one-way transfer of large content. 1634 Added text requiring unique port field values if multiple M-line's 1635 exist. 1636 Corrected a number of editorial mistakes. 1638 11.3 draft-ietf-simple-message-sessions-02 1640 Moved all content type negotiation from the "m"-line format list 1641 into "a"-line attributes. Added the accept-types attribute. This 1642 is due to the fact that the sdp format-list syntax is not 1643 conducive to encoding MIME content types values. 1644 Added "other-method" construction to the message syntax to allow 1645 for extensible methods. 1646 Consolidated all syntax definitions into the same section. Cleaned 1647 up ABNF for digest challenge and response syntax. 1648 Changed the session inactivity timeout to 12 minutes. 1649 Required support for the SHA1 alogorithm. 1650 Required support for the message/cpim format. 1651 Fixed lots of editorial issues. 1652 Documented a number of open issues from recent list discussions. 1654 11.4 draft-ietf-simple-message-sessions-01 1655 Abstract rewritten. 1656 Added architectural considerations section. 1657 The m-line format list now only describes the root body part for a 1658 request. Contained body part types may be described in the 1659 "accept-wrapped-types" a-line attribute. 1660 Added a standard dummy value for the m-line port field. Clarified 1661 that a zero in this field has normal SDP meaning. 1662 Clarified that an endpoint is globally configured as to whether or 1663 not to use a relay. There is no relay discovery mechanism 1664 intrinsic to MSRP. 1665 Changed digest algorithm to SHA1. Added TR-ID and S-URI to the 1666 hash for digest authentication. 1667 CMS usage replaced with S/MIME. 1668 TLS and MSRPS usage clarified. 1669 Session state timeout is now based on SEND activity, rather than 1670 BIND and VISIT refreshes. 1671 Default port added. 1672 Added sequence diagrams to the example message flows. 1673 Added discussion of self-signed certificates in the security 1674 considerations section. 1676 11.5 draft-ietf-simple-message-sessions-00 1678 Name changed to reflect status as a work group item. 1679 This version no longer supports the use of multiple sessions 1680 across a single TCP session. This has several related changes: 1681 There is now a single session URI, rather than a separate one for 1682 each endpoint. The session URI is not required to be in requests 1683 other than BIND and VISIT, as the session can be determined based 1684 on the connection on which it arrives. 1685 BIND and VISIT now create soft state, eliminating the need for the 1686 RELEASE and LEAVE methods. 1687 The MSRP URL format was changed to better reflect generic URL 1688 standards. URL comparison and resolution rules were added. SRV 1689 usage added. 1690 Determination of host and visitor roles now uses a direction 1691 attribute much like the one used in COMEDIA. 1692 Format list negotiation expanded to allow a "prefer these formats 1693 but try anything" semantic 1694 Clarified handling of direction notification failures. 1695 Clarified signaling associated with session failure due to dropped 1696 connections. 1697 Clarified security related motivations for MSRP. 1698 Removed MIKEY dependency for session key exchange. Simple usage of 1699 k-lines in SDP, where the SDP exchange is protected end-to-end 1700 seems sufficient. 1702 11.6 draft-campbell-simple-im-sessions-01 1704 Version 01 is a significant re-write. References to COMEDIA were 1705 removed, as it was determined that COMEDIA would not allow 1706 connections to be used bidirectional in the presence of NATs. 1707 Significantly more discussion of a concrete mechanism has been added 1708 to make up for no longer using COMEDIA. Additionally, this draft and 1709 draft-campbell-cpimmsg-sessions (which would have also changed 1710 drastically) have now been combined into this single draft. 1712 12. Contributors 1714 The following people contributed substantially to this ongoing 1715 effort: 1716 Rohan Mahy Allison Mankin Jon Peterson Brian Rosen Dean Willis Adam Roach 1717 Cullen Jennings Aki Niemi Hisham Khartabil Pekka Pessi Chris Boulton 1719 Normative References 1721 [1] Handley, M. and V. Jacobson, "SDP: Session Description 1722 Protocol", RFC 2327, April 1998. 1724 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1725 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1726 Session Initiation Protocol", RFC 3261, June 2002. 1728 [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 1729 Presence Protocol Requirements", RFC 2779, February 2000. 1731 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1732 Resource Identifiers (URL): Generic Syntax", RFC 2396, August 1733 1998. 1735 [5] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging 1736 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in 1737 progress), January 2003. 1739 [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1740 specifying the location of services (DNS SRV)", RFC 2782, 1741 February 2000. 1743 [7] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 1744 2633, June 1999. 1746 [8] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites 1747 for Transport Layer Security (TLS)", RFC 3268, June 2002. 1749 [9] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 1750 (SHA1)", RFC 3174, September 2001. 1752 [10] Moore, K. and G. Vaudreuil, "An Extensible Message Format for 1753 Delivery Status Notifications", RFC 1894, January 1996. 1755 [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1756 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 1757 HTTP/1.1", RFC 2616, June 1999. 1759 Informational References 1761 [12] Campbell, B. and J. Rosenberg, "Session Initiation Protocol 1762 Extension for Instant Messaging", RFC 3428, September 2002. 1764 [13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1765 "RTP: A Transport Protocol for Real-Time Applications", RFC 1766 1889, January 1996. 1768 [14] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. 1769 and A. Johnston, "A Multi-party Application Framework for SIP", 1770 draft-ietf-sipping-cc-framework-02 (work in progress), May 1771 2003. 1773 [15] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 1774 "Best Current Practices for Third Party Call Control in the 1775 Session Initiation Protocol", draft-ietf-sipping-3pcc-04 (work 1776 in progress), June 2003. 1778 [16] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1779 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 1780 progress), February 2003. 1782 [17] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of 1783 Resource Management and Session Initiation Protocol (SIP)", RFC 1784 3312, October 2002. 1786 [18] Peterson, J., "A Privacy Mechanism for the Session Initiation 1787 Protocol (SIP)", RFC 3323 , November 2002. 1789 [19] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", 1790 draft-ietf-impp-im-04 (work in progress), August 2003. 1792 [20] Yon, D., "Connection-Oriented Media Transport in SDP", 1793 draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 1794 2003. 1796 Authors' Addresses 1798 Ben Campbell 1799 dynamicsoft 1800 5100 Tennyson Parkway 1801 Suite 1200 1802 Plano, TX 75024 1804 EMail: bcampbell@dynamicsoft.com 1806 Jonathan Rosenberg 1807 dynamicsoft 1808 600 Lanidex Plaza 1809 Parsippany, NJ 07054 1811 EMail: jdrosen@dynamicsoft.com 1813 Robert Sparks 1814 dynamicsoft 1815 5100 Tennyson Parkway 1816 Suite 1200 1817 Plano, TX 75024 1819 EMail: rsparks@dynamicsoft.com 1821 Paul Kyzivat 1822 Cisco Systems 1823 Mail Stop LWL3/12/2 1824 900 Chelmsford St. 1825 Lowell, MA 01851 1827 EMail: pkyzivat@cisco.com 1829 Chris Boulton 1830 Ubiquity Software Corporation 1831 Langstone Park 1832 Newport, South Wales NP18 2LH 1834 EMail: cboulton@ubiquity.net 1836 Intellectual Property Statement 1838 The IETF takes no position regarding the validity or scope of any 1839 intellectual property or other rights that might be claimed to 1840 pertain to the implementation or use of the technology described in 1841 this document or the extent to which any license under such rights 1842 might or might not be available; neither does it represent that it 1843 has made any effort to identify any such rights. Information on the 1844 IETF's procedures with respect to rights in standards-track and 1845 standards-related documentation can be found in BCP-11. Copies of 1846 claims of rights made available for publication and any assurances of 1847 licenses to be made available, or the result of an attempt made to 1848 obtain a general license or permission for the use of such 1849 proprietary rights by implementors or users of this specification can 1850 be obtained from the IETF Secretariat. 1852 The IETF invites any interested party to bring to its attention any 1853 copyrights, patents or patent applications, or other proprietary 1854 rights which may cover technology that may be required to practice 1855 this standard. Please address the information to the IETF Executive 1856 Director. 1858 Full Copyright Statement 1860 Copyright (C) The Internet Society (2004). All Rights Reserved. 1862 This document and translations of it may be copied and furnished to 1863 others, and derivative works that comment on or otherwise explain it 1864 or assist in its implementation may be prepared, copied, published 1865 and distributed, in whole or in part, without restriction of any 1866 kind, provided that the above copyright notice and this paragraph are 1867 included on all such copies and derivative works. However, this 1868 document itself may not be modified in any way, such as by removing 1869 the copyright notice or references to the Internet Society or other 1870 Internet organizations, except as needed for the purpose of 1871 developing Internet standards in which case the procedures for 1872 copyrights defined in the Internet Standards process must be 1873 followed, or as required to translate it into languages other than 1874 English. 1876 The limited permissions granted above are perpetual and will not be 1877 revoked by the Internet Society or its successors or assignees. 1879 This document and the information contained herein is provided on an 1880 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1881 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1882 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1883 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1884 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1886 Acknowledgment 1888 Funding for the RFC Editor function is currently provided by the 1889 Internet Society.