idnits 2.17.1 draft-ietf-simple-message-sessions-01.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 3 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. == There are 5 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 362: '...Therefore relays SHOULD NOT be used in...' RFC 2119 keyword, line 363: '..., MSRP endpoints SHOULD be configured ...' RFC 2119 keyword, line 374: '... SHOULD NOT be used....' RFC 2119 keyword, line 382: '... the provider SHOULD provide its end...' RFC 2119 keyword, line 414: '...y large content, it SHOULD establish a...' (193 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 190 has weird spacing: '...nt over relia...' == Line 744 has weird spacing: '...] query strin...' == Line 945 has weird spacing: '...line is copie...' == Line 1386 has weird spacing: '...will be commo...' == Line 1420 has weird spacing: '...ined by perfo...' == 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: 1. Construct a session MSRP URL . This URL MUST be resolvable to the offerer. The URL SHOULD be temporary, SHOULD be hard to guess, and MUST not duplicate the URL of any other session currently hosted by the offerer. == 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: 1. Construct a new session URL . This MUST be a MSRP or MSRPS URL, MUST resolve to the answerer, and MUST not be the same as the session URL in the offer. The URL SHOULD be temporary, SHOULD be hard to guess, and MUST not duplicate URLs currently identifying any active sessions hosted by the answerer. == 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: 2. If the client is authorized, construct a session MSRP URL. The URL MUST resolve to the relay. It SHOULD be temporary, and hard to guess. It MUST not duplicate URL used in any active sessions hosted by the relay. If the relay wishes the visiting endpoint to connect over a point other than the MSRP relay well-know port, it MUST explicitly add the port number to visitor URL. -- 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 (June 30, 2003) is 7599 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: '11' is defined on line 2420, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 2445, 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 informational reference (is this intentional?): RFC 1889 (ref. '11') (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-03 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-01 == Outdated reference: A later version (-04) exists of draft-ietf-impp-im-03 == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-05 -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. '19') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 10 errors (**), 0 flaws (~~), 18 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group B. Campbell 3 Internet-Draft J. Rosenberg 4 Expires: December 29, 2003 R. Sparks 5 dynamicsoft 6 P. Kyzivat 7 Cisco Systems 8 June 30, 2003 10 Instant Message Sessions in SIMPLE 11 draft-ietf-simple-message-sessions-01 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 29, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document describes the Message Session Relay Protocol (MSRP), a 42 mechanism for transmitting a series of Instant Messages within a 43 session. MSRP sessions are managed using the SDP offer/answer model 44 carried by a signaling protocol such as SIP. 46 MSRP supports end-to-end Instant Message Sessions, as well as 47 sessions traversing one or two relays. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Motivation for Session-mode Messaging . . . . . . . . . . . 4 53 3. Scope of this Document . . . . . . . . . . . . . . . . . . . 5 54 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5 55 5. Architectural Considerations . . . . . . . . . . . . . . . . 8 56 5.1 Use of Relays . . . . . . . . . . . . . . . . . . . . . . . 8 57 5.2 Transferring Large Content . . . . . . . . . . . . . . . . . 9 58 5.3 Connection Sharing . . . . . . . . . . . . . . . . . . . . . 9 59 6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 10 60 6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . . 10 61 6.2 The Direction Attribute . . . . . . . . . . . . . . . . . . 11 62 6.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . . 13 63 6.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . . 13 64 6.5 Example SDP Exchange . . . . . . . . . . . . . . . . . . . . 14 65 7. The Message Session Relay Protocol . . . . . . . . . . . . . 15 66 7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . . 16 68 7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . . 16 69 7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . . 17 70 7.2 MSRP messages . . . . . . . . . . . . . . . . . . . . . . . 17 71 7.3 MSRP Transactions . . . . . . . . . . . . . . . . . . . . . 18 72 7.4 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . . 19 73 7.4.1 Initiating an MSRP session . . . . . . . . . . . . . . . . . 19 74 7.4.2 Handling VISIT requests . . . . . . . . . . . . . . . . . . 23 75 7.4.3 Sending Instant Messages on a Session . . . . . . . . . . . 23 76 7.4.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . . 24 77 7.4.5 Session Inactivity Timer . . . . . . . . . . . . . . . . . . 24 78 7.4.6 Managing Session State and Connections . . . . . . . . . . . 25 79 7.5 MSRP Relays . . . . . . . . . . . . . . . . . . . . . . . . 26 80 7.5.1 Establishing Session State at a Relay . . . . . . . . . . . 26 81 7.5.2 Removing Session State from a relay . . . . . . . . . . . . 28 82 7.5.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . . 28 83 7.5.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . . 28 84 7.6 Digest Authentication . . . . . . . . . . . . . . . . . . . 30 85 7.6.1 The SHA1 Algorithm . . . . . . . . . . . . . . . . . . . . . 31 86 7.7 Method Descriptions . . . . . . . . . . . . . . . . . . . . 31 87 7.7.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 7.7.2 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 7.7.3 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 90 7.8 Response Code Descriptions . . . . . . . . . . . . . . . . . 32 91 7.8.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 92 7.8.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 93 7.8.3 401 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 94 7.8.4 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 95 7.8.5 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 96 7.8.6 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 7.8.7 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 98 7.8.8 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 99 7.8.9 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 100 7.9 Header Field Descriptions . . . . . . . . . . . . . . . . . 33 101 7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 102 7.9.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 103 7.9.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 104 7.9.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 7.9.5 Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 36 106 7.9.6 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 107 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 108 8.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 36 109 8.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . . 39 110 8.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . . 42 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46 112 9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . . 46 113 9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . . 46 114 9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 115 9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . . 46 116 9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . . 47 117 9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 47 118 9.2.5 Security Considerations . . . . . . . . . . . . . . . . . . 47 119 9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . . 47 120 9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 47 121 9.3.1 Direction . . . . . . . . . . . . . . . . . . . . . . . . . 47 122 9.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . . 47 123 10. Security Considerations . . . . . . . . . . . . . . . . . . 48 124 10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . . 48 125 10.2 Sensitivity of the Session URL . . . . . . . . . . . . . . . 49 126 10.3 End to End Protection of IMs . . . . . . . . . . . . . . . . 49 127 10.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 50 128 10.5 PKI Considerations . . . . . . . . . . . . . . . . . . . . . 50 129 11. Changes from Previous Draft Versions . . . . . . . . . . . . 50 130 11.1 draft-ietf-simple-message-sessions-01 . . . . . . . . . . . 51 131 11.2 draft-ietf-simple-message-sessions-00 . . . . . . . . . . . 51 132 11.3 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . . 52 133 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 134 Normative References . . . . . . . . . . . . . . . . . . . . 53 135 Informational References . . . . . . . . . . . . . . . . . . 53 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54 137 Intellectual Property and Copyright Statements . . . . . . . 56 139 1. Introduction 141 The MESSAGE [10] extension to SIP [2] allows SIP to be used to 142 transmit instant messages. Instant messages sent using the MESSAGE 143 method are normally independent of each other. This approach is often 144 called page-mode messaging, since it follows a model similar to that 145 used by many two-way pager devices. page-mode messaging makes sense 146 for instant message exchanges where a small number of messages occur. 148 There are also applications in which it is useful for instant 149 messages to be associated together in some way. For example, a user 150 may wish to join a text conference, participate in the conference for 151 some period of time, then leave the conference. This usage is 152 analogous to regular media sessions that are typically initiated, 153 managed, and terminated using SIP. We commonly refer to this model as 154 session-mode messaging. 156 One of the primary purposes of SIP and SDP (Section 6) is the 157 management of media sessions. Session-mode messaging can be thought 158 of as a media session like any other. This document describes the 159 motivations for session-mode messaging, the Message Session Relay 160 Protocol, and the use of the SDP offer/answer mechanism for managing 161 MSRP session. 163 2. Motivation for Session-mode Messaging 165 Message sessions offer several advantages over page-mode messages. 166 For message exchanges that include more than a small number of 167 message transactions, message sessions offer a way to remove 168 messaging load from intervening SIP proxies. For example, a minimal 169 session setup and tear-down requires one INVITE/ACK transaction, and 170 one BYE transaction, for a total of 5 SIP messages. Normal SIP 171 request routing allows for all but the initial INVITE transaction to 172 bypass any intervening proxies that do not specifically request to be 173 in the path for future requests. Session-mode messages never cross 174 the SIP proxies themselves, unless proxies also act as message 175 relays. 177 Each page-mode message involves a complete SIP transaction, that is, 178 a request and a response. Any page-mode message exchange that 179 involves more than 2 MESSAGE requests will generate more SIP requests 180 than a minimal session initiation sequence. Since MESSAGE is normally 181 used outside of a SIP dialog, these requests will typically traverse 182 the entire proxy network between the endpoints. 184 Due to network congestion concerns, the MESSAGE method has 185 significant limitations in message size, a prohibition against 186 overlapping requests, etc. Much of this has been required because of 187 perceived limitations in the congestion-avoidance features of SIP 188 itself. Work is in progress to mitigate these concerns. 190 However, session-mode messages are always sent over reliable, 191 congestion-safe transports. Therefore, there are no restrictions on 192 message sizes. There is no requirement to wait for acknowledgement, 193 so that message transactions can be overlapped. 195 Message sessions allow greater efficiency for secure message 196 exchanges. The SIP MESSAGE request inherits the S/MIME features of 197 SIP, allowing a message to be signed and/or encrypted. However, this 198 approach requires public key operations for each message. With 199 session-mode messaging, a session key can be established at the time 200 of session initiation. This key can be used to protect each message 201 that is part of the session. This requires only symmetric key 202 operations for each subsequent IM, and no additional certificate 203 exchanges are required after the initial exchange. The establishment 204 of the session key can be done using standard techniques that apply 205 to voice and video, in addition to instant messaging. 207 Finally, SIP devices can treat message sessions like any other media 208 sessions. Any SIP feature that can be applied to other sorts of media 209 sessions can equally apply to message sessions. For example, 210 conferencing [12], third party call control [13], call transfer [14], 211 QoS integration [15], and privacy [16] can all be applied to message 212 sessions. 214 Messaging sessions can also reduce the overhead in each individual 215 message. In page-mode, each message needs to include all of the SIP 216 headers that are mandated by RFC 3261 [2]. However, many of these 217 headers are not needed once a context is established for exchanging 218 messages. As a result, messaging session mechanisms can be designed 219 with significantly less overhead. 221 3. Scope of this Document 223 This document describes the use of MSRP between endpoints, or via one 224 or two relays, where endpoints have advance knowledge of the relays. 225 It does not provide a mechanism for endpoints to determine whether a 226 relay is needed, or for endpoints to discover the presence of relays. 228 This document describes the use of MSRP over TCP. MSRP may be used 229 over other congestion-controlled protocols such as SCTP. However, the 230 specific bindings for other such protocols are outside the scope of 231 this document. 233 4. Protocol Overview 234 The Message Session Relay Protocol (MSRP) provides a mechanism for 235 transporting session-mode messages between endpoints. MSRP also 236 contains primitives to allow the use of one or two relay devices. 237 MSRP uses connection oriented, reliable network transport protocols 238 only. It is intrinsically NAT and firewall friendly, as it allows 239 participants to positively associate message sessions with specific 240 connections, and does not depend upon connection source address, 241 which may be obscured by NATs. 243 MSRP uses the following primitives: 245 SEND: Used to send message content from one endpoint to another. 247 VISIT: Used by an endpoint to establish a session association to the 248 opposite endpoint, or to a relay that was selected by the opposite 249 endpoint. 251 BIND: Used by an endpoint to establish a session at a relay, and 252 allow the opposite endpoint to visit that relay. 254 The simplest use case for MSRP is a session that goes directly 255 between endpoints, with no intermediaries involved. Assume A is an 256 endpoint that wishes to establish a message session, and B is the 257 endpoint invited by A. A invites B to participate in a message 258 session by sending a URL that represents the session. This URL is 259 temporary, and must not duplicate the URL used for any other active 260 sessions. 262 B "visits" A by connecting to A and sending a VISIT request 263 containing the URL that A provided. This associates the connection 264 from B with the session. B then responds to the invitation, informing 265 A that B has accepted the session. A and B may now exchange messages 266 using SEND requests on the connection. 268 When either party wishes to end the session, it informs the peer 269 party with a SIP BYE request. A terminates the session by 270 invalidating associated state, and dropping the connection. 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) 278 B->A (MSRP): VISIT (msrp://A/123) 279 A->B (MSRP): 200 OK 281 B->A (SDP): answer(msrp://A/123) 283 A->B (MSRP): SEND 285 B->A (MSRP): 200 OK 287 B->A (MSRP): SEND 289 A->B (MSRP): 200 OK 291 The session state has an associated inactivity timer. This timer is 292 initialized when a successful VISIT request occurs, and is reset each 293 time either endpoint sends a SEND request. If this timer expires 294 without being reset, the hosting device invalidates the session state 295 and terminates all associated connections. Endpoints that are 296 otherwise idle may keep a session active by periodically sending SEND 297 requests with no content. 299 A slightly more complicated case involves a single relay, known about 300 in advance by one of the parties. The endpoint that has the 301 preexisting relationship with the relay uses the BIND method to 302 establish session state in the relay. The relay returns a temporary 303 URL, that identifies the session. For endpoints A and B, and relay R, 304 the flow would look like the following: 306 A->R: MSRP: BIND(msrp://r) 308 R->A: MSRP: 200 OK (msrp://r/4uye) 310 A->B (SDP): offer (msrp://r/4uye) 312 B->R (MSRP): VISIT (msrp://r/4uye) 314 R->B (MSRP): 200 OK 316 B->A (SDP): answer(msrp://r/4uye) 318 A->R (MSRP): SEND 320 R->B (MSRP): SEND 322 B->R (MSRP): 200 OK 324 R->A (MSRP): 200 OK 325 B->R (MSRP): SEND 327 R->A (MSRP): SEND 329 A->R (MSRP): 200 OK 331 R->B (MSRP): 200 OK 333 The BIND request contains an expiration time. If a successful VISIT 334 request does not occur prior to the expiration, the relay will 335 destroy the session. Additionally, when tearing down a session, the 336 host endpoint invalidates the session state by issuing a BIND request 337 with an expiration value of zero. 339 5. Architectural Considerations 341 There are a number of considerations that, if handled in a reasonable 342 fashion, will allow more effective use of the protocols described in 343 this document. 345 5.1 Use of Relays 347 The primary motivation for relay support in MSRP is to deal with 348 situations where, due to issues of network topologies, neither 349 endpoint is able to receive an inbound TCP connection from the other. 350 For example, both endpoints may be behind separate firewalls that 351 only allow outbound connections. Relays may also be needed for policy 352 enforcement. For example, parts of the financial industry require the 353 logging of all communication. 355 However, the use of such relays has a significant impact on the 356 scalability of MSRP. Each relay will require two TCP connections for 357 each session in use, as well as memory for local session state 358 storage. Most general purpose platforms on which one might implement 359 MSRP relays will have relatively low limits on the number of 360 simultaneous TCP connections they can handle. 362 Therefore relays SHOULD NOT be used indescrimantly. In the absence of 363 strong reasons to use relays, MSRP endpoints SHOULD be configured to 364 set up point-to-point sessions. 366 MSRP supports the use of two relays, where each endpoint has a relay 367 acting on its behalf. However, most of the network topology issues 368 mentioned above can work with a single relay, if that relay is 369 reachable by both endpoints. Dual relays are only needed for cases of 370 very strict firewall policy, such as when only specific hosts are 371 allowed to connect to the outside world; or situations requiring 372 strict policy enforcement at both endpoint domains. If a given usage 373 scenario can be solved with a single relay, then a second relay 374 SHOULD NOT be used. 376 In spite of these recommendations, relays serve a real purpose in 377 that the increase the likelihood of two arbitrary endpoints being 378 able to talk to one another. Therefore if a provider deploys MSRP 379 endpoints in a network configuration that prevents them from 380 receiving TCP connections from arbitrary peers, and does not wish to 381 explicitly prevent MSRP communication with the outside world, then 382 the provider SHOULD provide its endpoints with the use of an MSRP 383 relay that is reachable from arbitrary peers. 385 5.2 Transferring Large Content 387 MSRP endpoints may attempt to send very long messages on a session. 388 For example, most commercial instant messaging systems have a file 389 transfer feature. Since MSRP does not impose message size limits, 390 there is nothing to prevent endpoints from transferring files over 391 it. 393 An analysis of whether it makes sense to do this, rather than sending 394 such content over FTP, HTTP, or some other such protocol, is beyond 395 the scope of this document. However, implementers should be aware of 396 the impact of sending very large messages over MSRP. The primary 397 impact is, since MSRP is sent over TCP, is that any additional 398 messages that the sender wishes to send will be blocked until the 399 large transfer is complete. This includes responses to messages sent 400 by the peer. Therefore, any SEND transactions initiated by the peer 401 are likely to time out, even though they are received without 402 problems. 404 Further, there is no way to abort the sending of a very large message 405 before it is complete. For the sake of efficiency, the framing 406 mechanism in MSRP is very simple. There is no clean way to recover 407 framing if the complete message is not sent. 409 These issues can be mitigated greatly if the endpoint simply 410 establishes a separate session for the transfer. This allows the 411 transfer to be sent without interfering with any instant messages 412 being sent on other sessions. Further, the endpoint can abort the 413 transfer by simply tearing down the transfer session. Therefore, if a 414 peer wishes to send very large content, it SHOULD establish a 415 dedicated session for that purpose. 417 5.3 Connection Sharing 419 The SIMPLE working group spent quite a bit of effort in the 420 consideration of shared TCP connections. Connection sharing would 421 offer value whenever a large number of message sessions cross the 422 same two adjacent devices. This situation is likely to occur in the 423 two relay model. It may also occur in the point-to-point model if the 424 endpoints are multiuser devices, as is likely with web-hosted 425 messaging services. 427 Unfortunately, such connection sharing in TCP created significant 428 problems. The biggest problem is it introduced a head-of-line 429 blocking problem that spanned sessions. For example, if two different 430 pairs of users had sessions that crossed the same shared connection, 431 a large message sent on one session would block transfer of messages 432 on the other session. The working group considered this an 433 unacceptable property of shared connections. One possible solution 434 was to put limits on message size, and possibly add mechanisms to 435 allow breaking messages into many chunks. However, these solutions 436 promised to add a great deal of complexity to the protocol, so the 437 work group chose not to go that route. 439 It may be possible to relax this requirement using other transport 440 protocols, such as SCTP. The lack of connection sharing in this 441 document should not be construed to prohibit shared connections on 442 other such protocols. However, such specification is beyond the scope 443 of this document. 445 6. SDP Offer-Answer Exchanges for MSRP Sessions 447 MSRP sessions will typically be initiated using the Session 448 Description Protocol (SDP) [1] offer-answer mechanism, carried in SIP 449 [2] or any other protocol supporting it. MSRP borrows the idea of the 450 direction attributes from COMEDIA [18], but does not depend on that 451 specification. 453 6.1 Use of the SDP M-line 455 The SDP m-line takes the following form: 457 m= 459 For non-RTP media sessions, The media field specifies the top level 460 MIME media type for the session. For MSRP sessions, the media field 461 MUST have the value of "message". The port field is normally not 462 used, and SHOULD be set to 9999. An exception is when the port field 463 value is set to zero, according to normal SDP usage. 465 The proto field MUST designate the message session mechanism and 466 transport protocol, separated by a "/" character. For MSRP, left part 467 of this value MUST be "msrp". For MSRP over TCP, the right part of 468 this field MUST take the value "tcp". For MSRP over other transport 469 protocols, the field value MUST be defined by the specification for 470 that protocol binding. 472 The format list MUST indicate the MIME content-types that the 473 endpoint is willing to accept in the payload of SEND requests. If the 474 final entry in the format list is a "*", this indicates that the 475 endpoint is may be willing to receive other types as well, but the 476 types listed explicitly are preferred. The format list in the SDP 477 answer MUST be the same as, or a subset of, the list provided in the 478 offer. 480 A "*" in the format list indicates that the sender may attempt to 481 send messages with other media types that have not been explicitly 482 listed. If the receiver is able to process the media type, it does 483 so. If not, it will respond with a 415. Note that all explicit 484 entries in the format list should be considered preferred over any 485 non-listed types. This feature is needed as, otherwise, the format 486 list for IM devices may be prohibitively large. 488 The m-line format list may include MIME wrapper types, that is, 489 mime formats that contain other types internally. The types listed 490 in the format field can be used both as the root payload, or may 491 be contained in container types. (Note that the container type 492 must also be listed in the format list.) A list of types that are 493 only allowed when wrapped in containers can be communicated in the 494 accept-wrapped-types (Section 6.3) attribute. 496 The port field in the M-line is not normally used to determine the 497 port to which to connect. Rather, the actual port is determined by 498 the contents of the session URL (Section 7.1). However, a port value 499 of zero has the normal SDP meaning. 501 The following example illustrates an m-line for a message session, 502 where the endpoint is willing to accept root payloads of message/ 503 cpim, plain text or HTML. The second two types could either be 504 presented as the root body, or could be contained within message/cpim 505 bodies. 507 m=message 9999 msrp/tcp message/cpim text/plain text/html 509 6.2 The Direction Attribute 511 Since MSRP uses connection oriented transport protocols, one goal of 512 the SDP negotiation is to determine which participant initiates the 513 transport connection. The direction attribute advertises whether the 514 offerer or answerer wishes to initiate the connection, wishes the 515 peer endpoint to initiate the connection, or doesn't care. 517 The endpoint that accepts the connection, or has a relay accept the 518 connection on its behalf, is said to "host" the session, and is known 519 as the hosting endpoint. The endpoint that initiates the connection 520 is said to "visit" the session, and is known as the visiting 521 endpoint. 523 The direction attribute is included in an SDP a-line, with a value 524 taking the following syntax: 526 direction = direction-label ":" role 527 direction-label = "direction" 528 role = active / passive / both 529 active = "active" 530 passive = "passive" [sp timeout] 531 both = "both" 532 timeout = 1*DIGIT ; timeout value in seconds 534 The values for the role field are as follows: 536 passive The endpoint wishes to host the session 538 active The endpoint wishes the peer to host the session. 540 both The endpoint is willing to act as either host or visitor. If 541 "both" is selected, it may contain an optional timeout value. This 542 timeout specifies how much time the answerer should wait before 543 giving up on a connection and attempting to take over as host 544 device. If the timeout value is not specified, it defaults to 30 545 seconds. 547 The SDP offer for an MSRP session MUST contain a direction attribute, 548 which MAY take any of the defined values. If the offerer is capable 549 of hosting the session, or can arrange for a relay to host the 550 session on its behalf, then it SHOULD select "both". The endpoint 551 SHOULD NOT select "active" unless it cannot host the session under 552 any circumstances. The endpoint SHOULD NOT select "passive" unless it 553 has no option but to host the session. 555 The SDP answer also MUST contain a direction attribute, but its value 556 choices are limited based on the value in the offer. If the offer 557 contained "active", then the answerer MUST either select "passive" or 558 reject the offer. Likewise, if the offer contained "passive", then 559 the answerer MUST select"active" or reject the offer. If the offer 560 contained "both", the answerer SHOULD select "active", but MAY select 561 "passive" if it is unable to reach the host device, or if local 562 policy requires it to act as host. 564 6.3 MIME Wrappers 566 The MIME content-types in the M-line format list will often include 567 compound types; that is, types that contain other types. For example, 568 "message/cpim" or "multipart/mixed." Occasionally and endpoint will 569 need to specify a MIME body type that can only be used if wrapped 570 inside a listed container type. 572 Endpoints MAY specify MIME types that are only allowed to be wrapped 573 inside compound types using the "accept-wrapped-types" attribute in 574 an SDP a-line. This attribute has the following syntax: 576 accept-wrapped-types = wrapped-types-label ":" format-list 577 wrapped-types-label = "accept-wrapped-types" 579 The format-list element has the identical syntax as the format list 580 in the m-line. The semantics for this attribute are identical to 581 those of the m-line format list, with the exception that the 582 specified types may only be used when wrapped inside containers. The 583 container types would be specified on the m-line normally. Since any 584 type listed on the m-line may be used both as a root body, or wrapped 585 in other bodies, format entries from the m-line SHOULD NOT be 586 repeated in this attribute. 588 This approach does not allow for specifying distinct lists of 589 acceptable wrapped types for different types of containers. If an 590 endpoint understands a MIME type in the context of one wrapper, it is 591 assumed to understand it in the context of any other acceptable 592 wrappers, subject to any constraints defined by the wrapper types 593 themselves. 595 The approach of specifying types that are only allowed inside of 596 containers separately from the primary payload types allows an 597 endpoint to force the use of certain wrappers. For example, a CPIM 598 gateway device may require all messages to be wrapped inside 599 message/cpim bodies, but may allow several content types inside 600 the wrapper. If the gateway were to specify the wrapped types in 601 the m-line format list, its peer could choose to use those types 602 without the wrapper. 604 6.4 URL Negotiations 606 An MSRP session is identified by an MSRP URL, which is determined by 607 the hosting endpoint, and negotiated in the SDP exchange. Any SDP 608 offer or answer that creates a possibility that the sender will host 609 the session, that is, contains a direction value of "passive" or 610 "both", MUST contain an MSRP URL in a session attribute. This 611 attribute has the following syntax: 613 a=session: 615 where is an MSRP or MSRPS URL as defined in Section 7.1. 617 The visitor will use the session URL established by the host both to 618 resolve the host address and port, and to identify the session when 619 connecting. For MSRP sessions, the address field in the C-line is not 620 relevant, and MUST be ignored. The port field in the M-line MUST be 621 ignored if non-zero. Zero values have the normal meeting for SDP. 623 The following example shows an SDP offer with a session URL of 624 "msrp://example.com:7394/2s93i" 626 c=IN IP4 useless.host.name 627 m=message 9999 msrp/tcp text/plain 628 a=direction:both 629 a=session:msrp://example.com:7394/2s93i 631 The session URL MUST be a temporary URL assigned just for this 632 particular session. It MUST NOT duplicate any URL in use for any 633 other session hosted by the endpoint or relay. Further, since the 634 peer endpoint will use the session URL to identify itself when 635 connecting, it SHOULD be hard to guess, and protected from 636 eavesdroppers. This will be discussed in more detail in Section 10. 638 6.5 Example SDP Exchange 640 Endpoint A wishes to invite Endpoint B to a MSRP session. A offers 641 the following session description containing the following lines: 643 c=IN IP4 alice.example.com 644 m=message 9999 msrp/tcp message/cpim text/plain text/html 645 a=direction:both 646 a=session:msrp://alice.example.com:7394/2s93i9 648 Endpoint B chooses to participate in the role of visitor, opens a TCP 649 connection to alice.example.com:7394, and successfully performs a 650 VISIT transaction passing the URL of msrp://alice.example.com:7394/ 651 2s93i9;. B indicates that it has accomplished this by answering with: 653 c=IN IP4 dontlookhere 654 m=message 9999 msrp/tcp message/cpim text/plain 655 a=direction:active 657 A may now send IMs to B by executing SEND transactions on the same 658 connection on which B sent the VISIT request. 660 7. The Message Session Relay Protocol 662 The Message Session Relay Protocol (MSRP) is a text based, message 663 oriented protocol for the transfer of instant messages in the context 664 of a session. MSRP uses the UTF8 character set. 666 MSRP messages MUST be sent over reliable, congestion-controlled, 667 connection-oriented transport protocols, such as TCP. 669 7.1 MSRP URLs 671 MSRP sessions are identified by MSRP URLs. An MSRP URL follows a 672 subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme 673 of "msrp": 675 msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource] 677 resource = 1*unreserved 679 The constructions for "userinfo", "hostport", and "unreserved" are 680 detailed in RFC2396 [4]. 682 An MSRP URL server part identifies the hosting device of an MSRP 683 session. If the server part contains a numeric IP address, it MUST 684 also contain a port. The resource part identifies a particular 685 session at that host device. The absence of the resource part 686 indicates a reference to an MSRP host device, but does not 687 specifically refer to a particular session resource. 689 MSRP has an IANA registered recommended port defined in Section 9.1. 690 However, this value should not be considered a default, as the URL 691 process described herein will always explicitly resolve a port 692 number. However, the URLs SHOULD be configured so that the 693 recommended port is used whenever appropriate. This makes life easier 694 for network administrators who need to manage firewall policy for 695 MSRP. 697 The server part will typically not contain a userinfo component, but 698 MAY do so to indicate a user account for which the session is valid. 699 Note that this is not the same thing as identifying the session 700 itself. If a userinfo component exists, MUST be constructed only from 701 "unreserved" characters, to avoid a need for escape processing. 702 Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo 703 part MUST NOT contain password information. 705 The following is an example of a typical MSRP URL: 707 msrp://host.example.com:8493/asfd34 709 7.1.1 MSRP URL Comparison 711 MSRP URL comparisons MUST be performed according to the following 712 rules: 714 The host part is compared as case insensitive. 716 If the port exists explicitly in either URL, then it must match 717 exactly. An URL with an explicit port is never equivalent to 718 another with no port specified. 720 The resource part is compared as case insensitive. A URL without a 721 resource part is never equivalent to one that includes a resource 722 part. 724 Userinfo parts are not considered for URL comparison. 726 Path normalization is not relevant for MSRP URLs. Escape 727 normalization is not required, since the relevant parts are limited 728 to unreserved characters. 730 7.1.2 Resolving MSRP Host Device 732 An MSRP host device is identified by the server part of an MSRP URL. 734 If the server part contains a numeric IP address and port, they MUST 735 be used as listed.. 737 If the server part contains a host name and a port, the connecting 738 device MUST determine a host address by doing an A or AAAA DNS query, 739 and use the port as listed. 741 If the server part contains a host name but no port, the connecting 742 device MUST perform the following steps: 744 1. Construct an SRV [6] query string by prefixing the host name 745 with the service field "_msrp" and the protocol field ("_tcp" for 746 TCP). For example, "_msrp._tcp.host.example.com". 748 2. Perform a DNS SRV query using this query string. 750 3. Select a resulting record according to the rules in RFC2782 [6]. 751 Determine the port from the chosen record. 753 4. If necessary, determine a host device address by performing an A 754 or AAAA query on the host name field in the selected SRV result 755 record. If multiple A or AAAA records are returned, the first 756 entry SHOULD be chosen for the initial connection attempt. This 757 allows any ordering created in the DNS to be preserved. 759 5. If the connection attempt fails, the device SHOULD attempt to 760 connect to the addresses returned in any additional A or AAAA 761 records, in the order the records were presented. If all of these 762 fail, the device SHOULD attempt to use any additional SRV records 763 that may have been returned, following the normal rules for SRV 764 record selection. 766 Note that in most cases, the transport protocol will be determined 767 separately from the resolution process. For example, if the MSRP URL 768 was communicated in an SDP offer or answer, the SDP M-line will 769 contain the transport protocol. When an MSRP URL is communicated 770 outside of SDP, the protocol SHOULD also be communicated. For 771 example, a client may be configured to use a particular relay that is 772 referenced with an MSRP URL. The client MUST also be told what 773 protocol to use. If a device needs to resolve an MSRP URL and does 774 not know the protocol, it SHOULD assume TCP. 776 7.1.3 The msrps URL Scheme 778 The "msrps" URL Scheme indicates that each hop MUST be secured with 779 TLS. Otherwise, it is used identically as an MSRP URL, except that a 780 MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS 781 scheme is further discussed in Section 10. 783 7.2 MSRP messages 785 MSRP messages are either requests or responses. Requests and 786 responses are distinguished from one another by the first line. The 787 first line of a Request takes the form of the request-start entry 788 below. Likewise, the first line of a response takes the form of 789 response-start. The syntax for an MSRP message is as follows: 791 msrp-message = request-start/response-start *(header CRLF) 792 [CRLF body] 793 request-start = "MSRP" SP length SP Method CRLF 794 response-start= "MSRP" SP length SP Status-Code SP 795 Reason CRLF 796 length = 1*DIGIT ; the length of the message, exclusive of the start line. 797 Method = SEND / BIND / VISIT 798 header = Client-Authenticate / Server-Challenge / 799 Transaction-ID / Session-URL/ Content-Type / Expires 800 Status-Code = 200 ;Success 801 / 400 ;Bad Request 802 / 401 ;Authentication Required 803 / 403 ;Forbidden 804 / 415 ;Unsupported Content Type 805 / 426 ;Upgrade Required 806 / 481 ;No session 807 / 500 ;Cannot Deliver 808 / 506 ;duplicate session 809 Reason = token ; Human readable text describing status 810 Client-Authenticate = "CAuth" credentials 811 Server-Challenge = "SChal" ":" challenge 812 Transaction-ID = "Tr-ID" ":" token 813 Content-Type = "Content-Type" ":" quoted-string 814 Session-URL = "S-URL" ":" msrp_url 815 Expires = "Exp"":" delta-seconds 816 delta-seconds= 1*DIGIT ; Integer number of seconds 818 All requests and responses MUST contain at least a TR-ID header 819 field. Messages MAY contain other fields, depending on the method or 820 response code. 822 7.3 MSRP Transactions 824 An MSRP transaction consists of exactly one request and one response. 825 A response matches a transaction if it share the same TR-ID value, 826 and arrives on the same connection on which the transaction was sent. 828 BIND is always hop by hop. VISIT transactions are usually hop-by-hop, 829 but may be relayed in situations where the visiting endpoint uses a 830 relay. However, SEND transactions are end-to-end, meaning that under 831 normal circumstances the response is sent by the peer endpoint, even 832 if there are intervening relays. 834 Endpoints MUST select TR-ID header field values in requests so that 835 they are not repeated by the same endpoint in scope of the given 836 session. TR-ID values SHOULD be globally unique. The TR-ID space of 837 each endpoint is independent of that of its peer. Endpoints MUST NOT 838 infer any semantics from the TR-ID header field beyond what is stated 839 above. In particular, TR-ID values are not required to follow any 840 sequence. 842 MSRP Transactions complete when a response is received, or after a 843 timeout interval expires with no response. Endpoints MUST treat such 844 timeouts in exactly the same way they would treat a 500 response. The 845 size of the timeout interval is a matter of local policy, with a 846 default of 30 seconds after a request has been completely sent. 848 7.4 MSRP Sessions 850 AN MSRP session is a context in which a series of instant messages 851 are exchanged, using SEND requests. A session has two endpoints (a 852 host and a visitor) and may have one or two relays. A session is 853 identified by an MSRP URL. 855 7.4.1 Initiating an MSRP session 857 When an endpoint wishes to engage a peer endpoint in a message 858 session, it invites the peer to communicate using an SDP offer, 859 carried over SIP or some other protocol supporting the SDP offer/ 860 answer model. For the purpose of this document, we will refer to the 861 endpoint choosing to initiate communication as the offerer, and the 862 peer being invited as the answerer. 864 The offerer SHOULD volunteer to act as the hosting endpoint if 865 allowed by policy and network topology. An endpoint is said to host a 866 session if one of two conditions are true. The host either directly 867 listens for a connection from the peer endpoint, and maintains 868 session state itself, or it uses a BIND request to initialize session 869 state at a relay that will listen for a connection from the peer. The 870 peer that is not the host is designated as the visitor. The offerer 871 MAY request the answerer to act as host if it is prevented from 872 accepting connections by network topology or policy, and is not able 873 to bind to a relay to act on its behalf. 875 If the offerer wishes to host the session directly, that is without 876 using a relay, it MUST perform the following steps: 878 1. Construct a session MSRP URL . This URL MUST be resolvable to the 879 offerer. The URL SHOULD be temporary, SHOULD be hard to guess, 880 and MUST not duplicate the URL of any other session currently 881 hosted by the offerer. 883 2. Listen for a connection from the peer. 885 3. Construct an SDP offer as described in Section 6, including the 886 list of allowed IM payload formats in the format list. The 887 offerer maps the session URL to the session attribute, as 888 described in Section 6.4. 890 4. Insert a direction attribute. This value SHOULD be "both", 891 indicating that the offerer will allow the answerer to override 892 the offerer's decision to host. If "both" is selected, the 893 offerer SHOULD leave the timeout at the default value (by leaving 894 out the value entirely." However, the offerer MAY select a 895 different timeout if circumstances warrant it. The direction 896 value MAY be "passive" if the offerer is prevented from allowing 897 the answerer override this choice. 899 5. Send the SDP offer using the normal processing for the signaling 900 protocol. 902 If the offerer chooses to force the answerer to host the session, it 903 MUST perform the following steps instead: 905 1. Construct an SDP offer as described above, but with no session 906 attribute. 908 2. Insert a direction attribute with a value of "active". 910 3. Send the offer using normal processing for the signaling 911 protocol. 913 When the answerer receives the SDP offer and chooses to participate 914 in the session, it must choose whether of act as the host or the 915 visitor. A direction attribute value of "both" in the offer indicates 916 that the offerer wishes to host, but will allow the answerer to host, 917 in which case the answerer SHOULD act as the visitor, but MAY choose 918 to host. A value of "passive" means the offerer insists upon hosting, 919 in which case the answerer MUST act as visitor or decline the offer. 921 If the answerer chooses to participate as a visitor, it MUST perform 922 the following steps: 924 1. Determine the host address and port from the session URL, 925 following the procedures in section Section 7.1 927 2. Connect to the host address and port, using the transport 928 protocol from the M-line. 930 3. Construct a VISIT request, which MUST contain the following 931 information: 933 1. An S-URL header field containing the session URL. 935 2. A TR-ID header field containing a unique transaction ID. 937 3. A size field containing size of the message subsequent to the 938 start-line. 940 4. Send the request and wait for a response 942 5. If the transaction succeeds, send a SDP answer via the signaling 943 protocol, according to the following rules: 945 1. The C-line is copied unmodified from the offer. 947 2. The M-Line contains a dummy port value, the protocol field 948 from the original offer, and a format list describing the 949 SEND payload media types that the answerer is willing to 950 accept. The format list in the answer MUST be either the same 951 as the format list in the offer, or a subset. 953 3. A direction attribute containing the value "active". 955 6. If the transaction fails, the answerer MAY choose to act as host, 956 if allowed by the direction attribute of the answer. If the 957 answerer is unable or unwilling to host, then it should return an 958 error response as appropriate for the signaling protocol. 960 Some TCP connection failure conditions may ordinarily take some time 961 to notice. For example, if the offerer is unable to open a TCP 962 connection to the host device, this connection attempt may take a 963 fairly large number of seconds to timeout. This length of time will 964 not be acceptable for many call flow scenarios. Therefore, the 965 devices SHOULD limit the time they wait for the TCP connection to a 966 shorter timeout value, which will default to 30 seconds. However, the 967 offerer MAY supply a different time in the timeout parameter of the 968 "both" direction value. If the offerer supplies a value, the answerer 969 SHOULD use that value for the TCP connection timeout, interpreted as 970 an integer number of seconds. 972 If the answerer chooses to host the session, it MUST perform the 973 following steps: 975 1. Construct a new session URL . This MUST be a MSRP or MSRPS URL, 976 MUST resolve to the answerer, and MUST not be the same as the 977 session URL in the offer. The URL SHOULD be temporary, SHOULD be 978 hard to guess, and MUST not duplicate URLs currently identifying 979 any active sessions hosted by the answerer. 981 2. Listen for a connection from the peer. 983 3. Construct an SDP answer as described in Section 6, mapping the 984 new session URL to the session attribute, and inserting a 985 direction attribute with the value of "passive". 987 4. Send the SDP offer using the normal processing for the signaling 988 protocol. 990 When the offerer receives the SDP answer, it must determine who will 991 continue to host the session. If the answer contained a direction 992 attribute value of "active", the offerer MUST continue as host. If 993 the offer contained "active" or "both" and the answer contains 994 "passive", then the offerer MUST allow the answerer to host the 995 session. 997 If the offerer chooses not to continue as host, it MUST perform the 998 following steps: 1000 1. Release resources it acquired in expectation of hosting the 1001 session, if any. 1003 2. Determine the host address and port from the session URL of the 1004 answer, following the procedures in section Section 7.1 1006 3. Connect to the host address and port, using the transport 1007 protocol from the M-line. 1009 4. Construct a VISIT request, which MUST contain the following 1010 information: 1012 1. A S-URL header field containing the session URL. 1014 2. A TR-ID header field containing a unique transaction ID. 1016 3. A size field containing size of the message subsequent to the 1017 start-line. 1019 5. Send the request and wait for a response 1021 6. If the transaction succeeds, set the actual expiration time to 1022 the value in the Exp header field in the response, and 1023 acknowledge the answer via the signaling protocol. If either the 1024 connection attempt or the VISIT transaction fail, acknowledge the 1025 answer, then initiate the tear-down of the session using the 1026 signaling protocol. 1028 7.4.2 Handling VISIT requests 1030 An MSRP endpoint that is hosting a session will receive a VISIT 1031 request from the visiting endpoint. When an endpoint receives a VISIT 1032 request, it MUST perform the following procedures: 1034 1. Check if state exists for a session with a URL that matches the 1035 S-URL of the VISIT request. If so, and if no visitor connection 1036 has been associated with the session, then return a 200 response, 1037 and save state designating the connection on which the request 1038 was received as the visitor leg of the session. 1040 2. If the session exists, and the visitor connection has already 1041 been established, return a 506 response and do not change session 1042 state in any way. 1044 3. If no matching session exists, return a 481 request, and do not 1045 change session state in any way. 1047 7.4.3 Sending Instant Messages on a Session 1049 Once a MSRP session has been established, either endpoint may send 1050 instant messages to its peer using the SEND method. When an endpoint 1051 wishes to do so, it MUST construct a SEND request according to the 1052 following process: 1054 1. Insert the message payload in the body, and the media type in the 1055 Content-Type header field. The media type MUST match one of the 1056 types in the format list negotiated in the SDP exchange. If a "*" 1057 is present in the format list, then the media type SHOULD match 1058 one of the explicitly listed entries, but MAY be any other 1059 arbitrary value. 1061 2. Set the TR-ID header field to a unique value. 1063 3. Send the request on the connection associated with the session. 1065 4. If a 2xx response code is received, the transaction was 1066 successful. 1068 5. If a 5xx response code is received, the transaction failed, but 1069 may possibly be successful if retried. The endpoint MAY retry the 1070 request as a new transaction, that is, with a new TR-ID value. If 1071 the endpoint receives 5xx responses more than some threshold 1072 number of times in a row, it SHOULD assume the session has 1073 failed, and initiate tear-down via the signaling protocol. The 1074 threshold value is a matter of local policy. 1076 6. If a 415 response is received, this indicates the recipient is 1077 unable or unwilling to process the media type. The sender SHOULD 1078 NOT attempt to send that particular media type again in the 1079 context of this session. 1081 7. If any other response code is received, the endpoint SHOULD 1082 assume the session has failed, and initiate tear-down. 1084 When an endpoint receives a SEND request, it MUST perform the 1085 following steps. 1087 1. Determine that it understands the media type in the body, if any 1088 exists. 1090 2. If it does, return a 200 response and render the message to the 1091 user. The method of rendering is a matter of local policy. 1093 3. If it does not understand the media type, return a 415 response. 1095 7.4.4 Ending a Session 1097 When either endpoint in an MSRP session wishes to end the session, it 1098 first signals its intent using the normal processing for the 1099 signaling protocol. For example, in SIP, it would send a BYE request 1100 to the peer. After agreeing to end the session, the host endpoint 1101 MUST release any resources acquired as part of the session. The 1102 process for this differs depending on whether the session is hosted 1103 directly by the host, or an a relay. 1105 The host MUST destroy local state for the session. This involves 1106 completely removing the state entry for this session and invalidating 1107 session URL. If the host is using an MSRP relay, it MUST send a BIND 1108 containing an expires value of zero. This request MUST be sent host 1109 connection established by the original BIND request. This BIND 1110 request MUST include the session URL in the S-URL header field. 1112 Since these host actions completely destroy the session state at 1113 the hosting device, the visitor is not required to take further 1114 action beyond cleaning up any local state. If for some reason the 1115 host fails to destroy session state, the state will be invalidated 1116 anyway when the inactivity timer expires. 1118 7.4.5 Session Inactivity Timer 1120 State associated with MSRP sessions, either at the host endpoint, or 1121 a hosting or visiting relay, is soft-state; that is, it expires over 1122 time if no message activity occurs. Each such device maintains a pair 1123 of inactivity timer, each with an initial value of 1 minute. One of 1124 these timers is assigned for each endpoint. 1126 All devices use the same, predetermined timer expiration value. 1127 While there might be some utility in negotiating this timer on a 1128 per device basis, such negotiation would add a great deal of 1129 complexity to MSRP. 1131 When a hosting device or visiting relay returns a successful response 1132 to a VISIT request, it MUST initialize both timers. The device MUST 1133 reset a timer anytime the associated endpoint sends a SEND request. 1134 If either timer expires without being reset, the device MUST 1135 invalidate the session, using normal procedures depending on the 1136 device's role in the session. 1138 Each endpoint MUST keep a similar timer, which it initializes when 1139 the session is created from its perspective. For the host endpoint, 1140 this is when it receives a successful response to a BIND request. For 1141 a visiting endpoint, this is when it sees a successful response to a 1142 VISIT request. Each endpoint resets its timer whenever it sends a 1143 SEND request. If an endpoint inactivity timer approaches expiration, 1144 and the endpoint wishes to continue participating in the session, it 1145 MUST send a SEND request. This request MAY be sent without a body if 1146 there is no user data to send. Endpoints MUST select the timer value 1147 so that there is sufficient time for the SEND request to traverse to 1148 the opposite endpoint. If the endpoint waits to the last moment, 1149 there is a danger that it will not be received by all relevant 1150 devices in time to prevent session destruction. 1152 7.4.6 Managing Session State and Connections 1154 A MSRP session is represented by state at the host device. As mention 1155 previously, session state is identified by an MSRP URL. An active 1156 session also has two associated network connections. The connection 1157 hosting device and the host endpoint is known as the host connection. 1158 The connection with the visiting endpoint is the visiting connection. 1159 Note that when the session state is hosted directly by an endpoint, 1160 the host connection may not involve a physical network connection; 1161 rather it is a logical connection the device maintains with itself. 1163 When session state is destroyed for any reason, the hosting device 1164 SHOULD drop the connection(s). 1166 If a connection fails for any reason, the session hosting device MUST 1167 invalidate the session state. This is true regardless of whether the 1168 dropped connection is the host or visiting connection. Once a 1169 connection is dropped, the associated session state MUST NOT be 1170 reused. If the endpoints wish to continue to communicate after a 1171 connection failure, they must initiate a new session. An endpoint 1172 detecting a connection failure SHOULD attempt to tear down the 1173 session using the rules of the signaling protocol. 1175 It would be nice to allow sessions to be recovered after a 1176 connection failure, perhaps by allowing the opposite endpoint to 1177 reconnect, and send a new VISIT or BIND request. However, this 1178 approach creates a race condition between the time that the 1179 hosting device notices the failed connection, and the time that 1180 the endpoint tries to recover the session. If the endpoint 1181 attempts to reconnect prior to the hosting device noticing the 1182 failure, the hosting device will interpret the recovery attempt as 1183 a conflict. The only way around this would be to force the hosting 1184 device to do a liveness check on the original connection, which 1185 would create a lot of complexity and overhead that do not seem to 1186 be worth the trouble. 1188 7.5 MSRP Relays 1190 7.5.1 Establishing Session State at a Relay 1192 An endpoint that wishes to host a MSRP session MAY do so by 1193 initiating session state at a MSRP relay, rather than hosting 1194 directly. An endpoint may wish to do this because network topology or 1195 local policy prevents a peer from connecting directly to the 1196 endpoint. The use of a relay should not be the default case, that is, 1197 a hosting endpoint that is not prevented from doing so by topology or 1198 policy SHOULD host the session directly. In order to use a relay, an 1199 MSRP endpoint MUST have knowledge of that relay's existence and 1200 location.. 1202 We previously mentioned how an endpoint wishing to host a MSRP 1203 session constructs session URL. When using a relay, the endpoint 1204 delegates that responsibility to the relay. 1206 To establish session state at a relay, the endpoint MUST perform the 1207 following steps: 1209 1. Open a network connection to the relay at the relays address and 1210 port. Normally, this information will be resolved from an MSRP 1211 URL representing the relay, although the relay MAY be configured 1212 with an explicit address and port, rather than a URL. 1214 2. Construct a BIND request with a S-URL that refers to the relay. 1216 3. Set the Expire header field to a desired value. 1218 4. Send the BIND request on the connection. 1220 5. Respond to any authentication request from the relay. 1222 6. If the response has a 2xx status code, use the URL in the S-URL 1223 header field as the session URL. The endpoint uses this URL in 1224 exactly the same manner as it had constructed it itself. 1225 Additionally, accept the expires value in the response as 1226 pre-visit expiration time. 1228 A MSRP relay listens for connections at all times. When it receives a 1229 BIND request, it SHOULD authenticate the request, either using 1230 digest-authentication, TLS authentication, or some other 1231 authentication mechanism. If authentication succeeds, the relay 1232 performs the following steps: 1234 1. Verify the client is authorized to BIND to this relay. If not, 1235 return a 403 response and make no state change. 1237 2. If the client is authorized, construct a session MSRP URL. The 1238 URL MUST resolve to the relay. It SHOULD be temporary, and hard 1239 to guess. It MUST not duplicate URL used in any active sessions 1240 hosted by the relay. If the relay wishes the visiting endpoint to 1241 connect over a point other than the MSRP relay well-know port, it 1242 MUST explicitly add the port number to visitor URL. 1244 3. Establish the pre-visit expiration time for the session according 1245 to section Section 7.4.5. 1247 4. Create state for the session. The relay MUST associate the 1248 connection on which the BIND request arrived as the host 1249 connection for the session. 1251 5. Return a 200 response, with the session URL in the S-URL header 1252 field, and the pre-visit session expiration time in the Exp 1253 header field. 1255 When an MSRP relay receives a VISIT request, it MUST perform the 1256 following steps: 1258 1. Check the S-URL header field value to see it matches the URL for 1259 an existing session state entry. 1261 2. If not, return a 481 response and make no state changes 1263 3. If it matches, but another connection has already been associated 1264 with the session URL, return a 506 response and make no state 1265 changes. If the session has been previously associated with this 1266 connection, treat the request as a refresh. 1268 4. If it matches, and no visiting connection has been previously 1269 associated with the session, then the VISIT succeeds. The relay 1270 assigns the connection on which it received the VISIT request as 1271 the visiting connection for the session, and returns a 200 1272 response. 1274 7.5.2 Removing Session State from a relay 1276 An MSRP relay SHOULD remove state for a session when any of the 1277 following conditions occur: 1279 o The session inactivity timer expires. 1281 o The pre-visit timer expires before a VISIT request has occurred. 1283 o The host sends a BIND refresh request matching with an expiration 1284 value of zero. 1286 o Either the host or visitor network connection fails for any 1287 reason. 1289 7.5.3 Sending IMs across an MSRP relay 1291 Once a session is established at a relay, the host and visitor may 1292 exchange IMs by sending SEND requests. Under normal circumstances, 1293 the relay does not respond to SEND requests in any way. Rather, the 1294 relay MUST forward the request to the peer connection unchanged. 1295 Likewise, if the relay receives a response it MUST forward the 1296 request unchanged on the peer connection. 1298 If a SEND request arrives on a connection that is not associated with 1299 a session, the relay MUST return a 481 response. 1301 7.5.4 Relay Pairs 1303 In rare circumstances, two relays may be required in a session. For 1304 example, two endpoints may exist in separate administrative domains, 1305 where each domain's policy insist that all sessions must cross that 1306 domain's relay. A relay operating on behalf of the visiting endpoint 1307 is known as a visiting relay. An MSRP relay MAY be capable of acting 1308 as a visiting relay. 1310 This document does not describe a mechanism for an endpoint to 1311 discover that it needs to use a visiting relay. We assume that an 1312 endpoint is globally configured to use or not use such a relay, 1313 and does not make this decision on a session-by-session basis. 1314 This, of course, does not preclude using some other mechanism to 1315 make such a decision. 1317 In a two relay scenario, the visitor connects to a relay operating on 1318 its behalf, rather than connecting directly to the hosting device. 1319 The visitor sends a VISIT request as it would if it had connected 1320 directly to the hosting device. The visiting relay then connects to 1321 the hosting device and performs a VISIT request on behalf of the 1322 visitor. 1324 When a relay that is capable of acting as a visiting relay receives a 1325 VISIT request, it MUST check to see if the S-URL of the request 1326 matches a domain that the relay hosts. If the URL matches, then the 1327 visitor is not requesting the relay act as a visiting relay, and it 1328 SHOULD operate normally. If the URL does not match, then the relay 1329 SHOULD perform the following steps: 1331 1. The relay SHOULD authenticate the VISIT request, using digest 1332 authentication or some other mechanism. 1334 2. Determine that the visiting endpoint is authorized to use this 1335 device as a visiting relay. If not, return a 403 response and 1336 drop the connection. 1338 3. Attempt to open a connection to the hosting device, determining 1339 the address and port from the S-URL exactly as if it were a 1340 visiting endpoint connecting directly. If this connection is 1341 successful, continue with the remaining steps. Otherwise, return 1342 a 500 response. 1344 4. Create local state to associate the connection to the host device 1345 with the connection to the visiting device. 1347 5. Relay the VISIT request unchanged to the hosting device. 1349 6. Relay the response to the VISIT request unchanged to the visiting 1350 endpoint. 1352 7. Relay all subsequent arriving on one of the associated 1353 connections to the peer connection. 1355 If either associated connection fails for any reason, the visiting 1356 relay MUST invalidate the session state, and MUST drop the peer 1357 connection. 1359 7.6 Digest Authentication 1361 MSRP relays may use the digest authentication scheme to authenticate 1362 users. MSRP digest authentication is a simplified version of HTTP 1363 digest authentication [19], but this specification does not 1364 normatively depend on that document. MSRP digest authentication does 1365 not support the concept of a protection domain, nor does it support 1366 integrity protection. Since a user of a relay is expected to have 1367 credentials for that particular relay, it does not support the realm 1368 concept. Finally, since digest authentication is only expected for 1369 the initial BIND or VISIT request, MSRP does not support HTTP digest 1370 optimizations such as MD5-sess and preemptive credential loading by 1371 the client. 1373 Typically, a hosting user that uses a relay will have a preexisting 1374 relationship with that relay. This relationship SHOULD include 1375 authentication credentials. An MSRP relay SHOULD authenticate initial 1376 BIND requests. 1378 It is less likely that the visiting user will have an account at the 1379 hosting relay, so in most cases the authentication of VISIT requests 1380 is not useful. However a relay MAY authenticate initial VISIT 1381 requests. A visiting relay SHOULD authenticate initial VISIT 1382 requests, as it is much more likely to share credentials with the 1383 visiting user. 1385 There has been some discussion that a hosting relay SHOULD also 1386 authenticate VISIT requests. However, it will be common for 1387 visiting users to have no preexisting relationship with the host 1388 relay. Using authentication here would require the host endpoint 1389 to send temporary credentials in the SDP exchange, perhaps as part 1390 of the session URL. However, these temporary credentials would 1391 necessarily be transferred via the same channels as the session 1392 URL itself. If the credentials are sufficiently protected in 1393 transfer, then so is the session URL. Further, since the session 1394 URL is intended for a one time use, and is expected to be hard to 1395 guess, that URL itself should be sufficient for this purpose. Any 1396 situation where this is not adequate can be covered by the use of 1397 the MSRPS scheme. 1399 MSRP relays MUST NOT request authentication for any method other than 1400 BIND and VISIT. 1402 If a relay wishes to authenticate a request using digest 1403 authentication, it MAY challenge the request by responding with a 1404 401 response, which MUST include a SChal header field. 1406 If an endpoint wishes to respond to a digest authentication challenge 1407 received in a 401 response, it MAY do so by sending a new VISIT or 1408 BIND request, identical to the previous request, but with a CAuth 1409 header field containing the response to the challenge. 1411 7.6.1 The SHA1 Algorithm 1413 The only digest authentication algorithm defined in this 1414 specification is SHA1. [9] Other algorithms can be added as 1415 extensions. SHA1 is the default algorithm if no algorithm directive 1416 is present in the challenge. 1418 The SHA1 digest is defined as follows: 1420 Let KD(secret, data) denote the string obtained by performing the 1421 digest algorithm to the data "data" with the secret "secret". Let 1422 H(data) denote the string obtained by performing the checksum 1423 algorithm on the data "data". 1425 For the "SHA1" algorithm, H(data) = SHA1(data), and KD(secret,data) = 1426 H(concat(secret, ":", data) 1428 The request-digest value in a CAuth header field takes the following 1429 format. Note that unq(quoted-string) denotes the value of the string 1430 with the quotes removed. 1432 request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> 1433 A1 = unq(username-value) ":" shared-secret 1434 A2 = concat(Method,TR-ID,S-URI) 1436 When the relay receives a CAuth header, it SHOULD check its validity 1437 by looking up the shared secret, or H(A1), performing the same digest 1438 operation as performed by the client, and comparing the results to 1439 the request-digest value. 1441 7.7 Method Descriptions 1443 This section summarizes the purpose of each MSRP method. All MSRP 1444 messages MUST contain the TR-ID header fields. All messages MUST 1445 contain a length field in the start line that indicates the overall 1446 length of the request, including any body, but not including the 1447 start line itself. Additional requirements exist depending on the 1448 individual method. Except where otherwise noted, all requests are hop 1449 by hop. 1451 7.7.1 BIND 1453 The BIND method is used by a host endpoint to establish or refresh 1454 session state at a hosting relay. BIND requests SHOULD be 1455 authenticated. BIND requests MUST contain the S-URL and Exp header 1456 fields and MAY contain the CAuth header fields. 1458 A successful response to a BIND request MUST contain the S-URL and 1459 Exp header fields. 1461 7.7.2 SEND 1463 The SEND method is used by both the host and visitor endpoints to 1464 send instant messages to its peer endpoint. SEND requests SHOULD 1465 contain a MIME body part. The body MUST be of a media type included 1466 in the format list negotiated in the SDP exchange. If a body is 1467 present, the request MUST contain a Content-Type header field 1468 identifying the media type of the body. 1470 Unlike other methods, SEND requests are end to end in nature. This 1471 means the request is consumed only by the opposite endpoint. Under 1472 normal conditions, any intervening relays merely forward the request 1473 on towards the peer endpoint. 1475 7.7.3 VISIT 1477 The visiting endpoint uses the VISIT method to associate a network 1478 connection with the session state at the hosting device, which could 1479 be either the host endpoint or a relay operating on behalf of the 1480 host endpoint. The request MUST contain a S-URL header matching the 1481 session URL. 1483 There is normally no authentication operation for the VISIT 1484 request. This is because the session URL acts as a shared secret 1485 between host and the visitor. This puts certain requirements on 1486 the handling of the session URLs that are discussed in Section 10. 1487 However, if a visiting relay is used, it SHOULD authenticate VISIT 1488 requests. 1490 7.8 Response Code Descriptions 1492 This section summarizes the various response codes. Except where 1493 noted, all responses MUST contain a TR-ID header field matching the 1494 TR-ID header field of the associated request. Responses are never 1495 consumed by relays. 1497 7.8.1 200 1499 The 200 response code indicates a successful transaction. 1501 7.8.2 400 1503 A 400 response indicates a request was unintelligible. 1505 7.8.3 401 1507 A 401 response indicates authentication is required. 401 responses 1508 MUST NOT be used in response to any method other than BIND and VISIT. 1509 A 401 response MUST contain a SChal header field. 1511 7.8.4 403 1513 A 403 response indicates the user is not authorized to perform the 1514 action. 1516 7.8.5 415 1518 A 415 response indicates the SEND request contained a MIME 1519 content-type that is not understood by the receiver. 1521 7.8.6 426 1523 A 426 response indicates that the request is only allowed over TLS 1524 protected connections. 1526 Open Issue: Do we need to make 426 extensible to support other 1527 types of protection? 1529 7.8.7 481 1531 A 481 response indicates that no session exists for the connection. 1533 7.8.8 500 1535 A 500 response indicates that a relay was unable to deliver a SEND 1536 request to the target. 1538 7.8.9 506 1540 A 506 response indicates that a VISIT request occurred in which the 1541 S-URL indicates a session that is already associated with another 1542 connection. A 506 response MUST NOT be returned in response to any 1543 method other than VISIT. 1545 7.9 Header Field Descriptions 1547 This section summarizes the various header fields. MSRP header fields 1548 are single valued; that is, they MUST NOT occur more than once in a 1549 particular request or response. 1551 7.9.1 TR-ID 1553 The TR-ID header field contains a transaction identifier used to map 1554 a response to the corresponding request. A TR-ID value MUST be unique 1555 among all values used by a given endpoint inside a given session. 1556 MSRP elements MUST NOT assume any additional semantics for TR-ID. 1558 7.9.2 Exp 1560 The Exp header field specifies when the state associated with a BIND 1561 request will expire, if no successful VISIT request has been 1562 received.. The value is specified as an integer number of seconds 1563 from the time the request is received. BIND requests MUST contain 1564 this header field. Furthermore, successful responses to BIND requests 1565 MUST also contain the Exp header. 1567 The maximum value for the Exp header field is (2**32)-1 seconds. 1569 Exp has no meaning if it occurs in MSRP messages other than BIND 1570 requests, and responses to those requests. MSRP compliant devices 1571 SHOULD NOT use Exp in other requests or responses, unless that usage 1572 is defined in an extension to this specification. 1574 7.9.3 CAuth 1576 The CAuth header field is used by a host endpoint to respond to offer 1577 digest authentication credentials to a relay, usually in response to 1578 a digest authentication challenge. CAuth SHOULD NOT be present in a 1579 request of any method other than BIND and VISIT. 1581 The CAuth credentials adhere to the following syntax: 1583 credentials = "Digest" digest-response 1584 digest-response = 1#( username | nonce | 1585 response | [ algorithm ] | 1586 [auth-param] ) 1588 username = "username" "=" username-value 1589 username-value = quoted-string 1590 response = "response" "=" request-digest 1591 request-digest = <"> 32LHEX <"> 1592 LHEX = "0" | "1" | "2" | "3" | 1593 "4" | "5" | "6" | "7" | 1594 "8" | "9" | "a" | "b" | 1595 "c" | "d" | "e" | "f" 1597 The meaning of each value is as follows: 1599 username: The user's account name. 1601 nonce: The nonce value copied from the challenge. 1603 response: A 32 hex digit string that proves user knowledge of the 1604 shared secret. 1606 algorithm: The algorithm value copied from the challenge. 1608 auth-param: Additional parameters for the sake of extensibility. 1610 7.9.4 SChal 1612 The SChal header field is used by a relay to carry the challenge in a 1613 digest authentication attempt. Exactly one SChal header field MUST 1614 exist in a 401 response. The SChal header MUST NOT be used in any 1615 message except for a 401 response. The SChal header field value is 1616 made up of a challenge according to the following syntax: 1618 challenge= digest-scheme SP digest-challenge 1620 digest-scheme = "Digest" 1621 digest-challenge = 1#( nonce | [ algorithm ] | 1622 [auth-param] ) 1623 nonce = "nonce" "=" nonce-value 1624 nonce-value = quoted-string 1625 algorithm = "algorithm" "=" ( "SHA1" | token ) 1627 The meaning of each value is as follows: 1629 digest scheme: A token to identify the particular authentication 1630 scheme. For digest, the value MUST be "Digest." This token is 1631 present for the sake of extensibility. 1633 nonce: A server-specified string, which the relay SHOULD uniquely 1634 generate each time it sends a 401 response. This string SHOULD 1635 take the form of base64 or hexadecimal data, to avoid the presence 1636 of a double-quote character, which is not allowed. 1638 algorithm: A token indicating the algorithms to be used to generate 1639 the digest and checksum. This directive exists for the sake of 1640 extensibility; the only value defined by this document is "SHA1". 1641 Absence of this directive indicates a value of "SHA1". 1643 7.9.5 Content-Type 1645 The Content-Type header field is used to indicate the MIME media type 1646 of the body. Content-Type MUST be present if a body is present. 1648 7.9.6 S-URL 1650 The S-URL header field is used to identify the session. The S-URI 1651 header field MUST be present in a BIND request, a successful response 1652 to a BIND request, or a VISIT request. 1654 8. Examples 1656 This section shows some example message flows for various common 1657 scenarios. The examples assume SIP is used to transport the SDP 1658 exchange. Details of the SIP messages and SIP proxy infrastructure 1659 are omitted for the sake of brevity. In the examples, assume the 1660 offerer is sip:alice@atlanta.com and the answerer is 1661 sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length 1662 field indicates the actual length of the rest of the message. 1664 8.1 No Relay 1666 In this scenario, the session goes directly between endpoints with no 1667 MSRP relays involved. 1669 Alice Bob 1670 | | 1671 | | 1672 |(1) (SIP) INVITE | 1673 |----------------------->| 1674 |(2) (MSRP) VISIT | 1675 |<-----------------------| 1676 |(3) (MSRP) 200 OK | 1677 |----------------------->| 1678 |(4) (SIP) 200 OK | 1679 |<-----------------------| 1680 |(5) (SIP) ACK | 1681 |----------------------->| 1682 |(6) (MSRP) SEND | 1683 |----------------------->| 1684 |(7) (MSRP) 200 OK | 1685 |<-----------------------| 1686 |(8) (MSRP) SEND | 1687 |<-----------------------| 1688 |(9) (MSRP) 200 OK | 1689 |----------------------->| 1690 |(10) (SIP) BYE | 1691 |----------------------->| 1692 |(11) (SIP) 200 OK | 1693 |<-----------------------| 1694 | | 1695 | | 1697 1. Alice constructs a session URL of msrp://alicepc.atlanta.com/ 1698 iau39 and listens for a connection on TCP port 7777. 1700 Alice->Bob (SIP): INVITE sip:bob@biloxi.com 1702 c=IN IP4 fillername 1703 m=message 9999 msrp/tcp text/plain 1704 a=direction:both 1705 a=session:msrp://alicepc.atlanta.com/iau39:7777 1707 2. Bob opens a TCP connection to alicepc.atlanta.com:7777: 1709 Bob->Alice (MSRP): 1711 MSRP xx VISIT 1712 S-URL:msrp://alicepc.atlanta.com/iau39:7777 1713 Tr-ID: sie09s 1715 3. Alice->Bob (MSRP): 1717 MSRP xx 200 OK 1718 Tr-ID: sie09s 1719 Exp:300 1721 4. Bob->Alice (SIP): 200 OK 1723 c=IN IP4 ignorefield 1724 m=message 9999 msrp/tcp text/plain 1725 a=direction:active 1727 5. Alice->Bob (SIP): ACK 1729 6. Alice->Bob (MSRP): 1731 MSRP xx SEND 1732 TR-ID: 123 1733 Content-Type: "text/plain" 1734 Hi, I'm Alice! 1736 7. Bob->Alice (MSRP): 1738 MSRP xx 200 OK 1739 TR-ID: 123 1741 8. Bob->Alice (MSRP): 1743 MSRP xx SEND 1744 TR-ID: 456 1745 Content-Type: "text/plain" 1747 Hi, Alice! I'm Bob! 1749 9. Alice->Bob (MSRP): 1751 MSRP xx 200 OK 1752 TR-ID: 456 1754 10. Alice->Bob (SIP): BYE 1756 Alice invalidates session and drops connection. 1758 11. Bob invalidates local state for the session. 1760 Bob->Alice (SIP): 200 OK 1762 8.2 Single Relay 1764 This scenario introduces an MSRP relay at relay.atlanta.com. 1766 Alice Relay Bob 1767 | | | 1768 | | | 1769 |(1) (MSRP) BIND | | 1770 |----------------------->| | 1771 |(2) (MSRP) 200 OK | | 1772 |<-----------------------| | 1773 |(3) (SIP) INVITE | | 1774 |------------------------------------------------>| 1775 | |(4) (MSRP) VISIT | 1776 | |<-----------------------| 1777 | |(5) (MSRP) 200 OK | 1778 | |----------------------->| 1779 |(6) (SIP) 200 OK | | 1780 |<------------------------------------------------| 1781 |(7) (SIP) ACK | | 1782 |------------------------------------------------>| 1783 |(8) (MSRP) SEND | | 1784 |----------------------->| | 1785 | |(9) (MSRP) SEND | 1786 | |----------------------->| 1787 | |(10) (MSRP) 200 OK | 1788 | |<-----------------------| 1789 |(11) (MSRP) 200 OK | | 1790 |<-----------------------| | 1791 | |(12) (MSRP) SEND | 1792 | |<-----------------------| 1793 |(13) (MSRP) SEND | | 1794 |<-----------------------| | 1795 |(14) (MSRP) 200 OK | | 1796 |----------------------->| | 1797 | |(15) (MSRP) 200 OK | 1798 | |----------------------->| 1799 |(16) (SIP) BYE | | 1800 |------------------------------------------------>| 1801 |(17) (MSRP) BIND | | 1802 |----------------------->| | 1803 |(18) (MSRP) 200 OK | | 1804 |<-----------------------| | 1805 |(19) (SIP) 200 OK | | 1806 |<------------------------------------------------| 1807 | | | 1808 | | | 1810 1. Alice->Relay (MSRP): Alice opens a connection to the relay, and 1811 sends the following: 1813 MSRP xx BIND 1814 S-URL:msrp://relay.atlanta.com 1815 TR-ID: 321 1816 Exp:600 1818 2. Relay->Alice (MSRP): 1820 MSRP xx 200 OK 1821 TR-ID: 321 1822 S-URL: msrp://relay.atlanta.com:7777/iau39 1823 Exp:300 1825 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 1827 c=IN IP4 dummyvalue 1828 m=message 9999 msrp/tcp text/plain 1829 a=direction:passive 1830 a=session:msrp://relay.atlanta.com:7777/iau39 1832 4. Bob->Alice: Open connection to relay.atlanta.com:7777. 1834 Bob->Relay (MSRP): 1836 MSRP xx VISIT 1837 S-URL:msrp://relay.atlanta.com:7777/iau39 1838 TR-ID: msrp:sie09s 1840 5. Relay->Bob (MSRP): 1842 MSRP xx 200 OK 1843 TR-ID: sie09s 1844 Exp:300 1846 6. Bob->Alice (SIP): 200 OK 1847 c=IN IP4 nobodybutuschickens 1848 m=message 9999 msrp/tcp text/plain 1849 a=direction:active 1851 7. Alice->Bob (SIP): ACK 1853 8. Alice->Relay (MSRP): 1855 MSRP xx SEND 1856 TR-ID: 123 1857 Content-Type: "text/plain" 1858 Hi, I'm Alice! 1860 9. Relay->Bob (MSRP): 1862 MSRP xx SEND 1863 TR-ID: 123 1864 Content-Type: "text/plain" 1865 Hi, I'm Alice! 1867 10. Bob->Relay (MSRP): 1869 MSRP xx 200 OK 1870 TR-ID: 123 1872 11. Relay->Alice (MSRP): 1874 MSRP xx 200 OK 1875 TR-ID: 123 1877 12. Bob->Relay (MSRP): 1879 MSRP xx SEND 1880 TR-ID: 456 1881 Content-Type:"text/plain" 1883 Hi, Alice! I'm Bob! 1885 13. Relay->Alice (MSRP): 1887 MSRP xx SEND 1888 TR-ID: 456 1889 Content-Type: "text/plain" 1891 Hi, Alice! I'm Bob! 1893 14. Alice->relay (MSRP): 1895 MSRP xx 200 OK 1896 TR-ID: 456 1898 15. Relay->Bob (MSRP): 1900 MSRP xx 200 OK 1901 TR-ID: 456 1903 16. Alice->Bob (SIP): BYE 1905 17. Alice->Relay (MSRP): 1907 MSRP xx BIND 1908 S-URL: msrp://relay.atlanta.com:7777/iau39 1909 TR-ID: 42 1910 Exp:0 1912 18. Relay->Alice (MSRP): Relay invalidates session state. 1914 MSRP xx 200 OK 1915 TR-ID: 42 1916 Exp:0 1918 19. Bob invalidates local state for the session. 1920 Bob->Alice (SIP): 200 OK 1922 8.3 Two Relays 1924 In this scenario, both Alice and Bob are each required by local 1925 policy to route all sessions through a different local relay. 1927 Alice AtlantaRelay BiloxiRelay Bob 1928 | | | | 1929 | | | | 1930 |(1) (MSRP) BIND | | 1931 |------------->| | | 1932 |(2) (MSRP) 200 OK | | 1933 |<-------------| | | 1934 |(3) (SIP) INVITE | | 1935 |------------------------------------------->| 1936 | | |(4) (MSRP) VISIT 1937 | | |<-------------| 1938 | |(5) (MSRP) VISIT | 1939 | |<-------------| | 1940 | |(6) (MSRP) 200 OK | 1941 | |------------->| | 1942 | | |(7) (MSRP) 200 OK 1943 | | |------------->| 1944 |(8) (SIP) 200 OK | | 1945 |<-------------------------------------------| 1946 |(9) (SIP) ACK | | | 1947 |------------------------------------------->| 1948 |(10) (MSRP) SEND | | 1949 |------------->| | | 1950 | |(11) (MSRP) SEND | 1951 | |------------->| | 1952 | | |(12) (MSRP) SEND 1953 | | |------------->| 1954 | | |(13) (MSRP) 200 OK 1955 | | |<-------------| 1956 | |(14) (MSRP) 200 OK | 1957 | |<-------------| | 1958 |(15) (MSRP) SEND | | 1959 |<-------------| | | 1960 |(16) (SIP) BYE| | | 1961 |------------------------------------------->| 1962 |(17) (MSRP) BIND | | 1963 |------------->| | | 1964 |(18) (MSRP) 200 OK | | 1965 |<-------------| | | 1966 |(19) (SIP) 200 OK | | 1967 |<-------------------------------------------| 1968 | | | | 1969 | | | | 1971 1. Alice->AtlantaRelay (MSRP): Alice opens a connection to her 1972 relay, and sends the following: 1974 MSRP xx BIND 1975 S-URL: msrp://relay.atlanta.com 1976 TR-ID: 321 1977 Exp:600 1979 2. AtlantaRelay->Alice (MSRP): 1981 MSRP xx 200 OK 1982 TR-ID: 321 1983 S-URL: msrp://relay.atlanta.com:7777/iau39 1984 Exp:600 1986 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 1988 c=IN IP4 blahblahblah 1989 m=message 9999 msrp/tcp text/plain 1990 a=session:msrp://relay.atlanta.com:7777/iau39 1991 a=direction:passive 1993 4. Bob determines that, due to local policy, he must connect 1994 through his own relay. 1996 Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay, 1997 and sends the following: 1999 MSRP xx VISIT 2000 S-URL: msrp://relay.atlanta.com:7777/iau39 2001 TR-ID: 934 2003 5. BiloxiRelay->AtlantaRelay (MSRP): BiloxiRelay resolves the URL, 2004 opens a connection to relay.atlanta.com:7777, and sends the 2005 following: 2007 MSRP xx VISIT 2008 S-URL: msrp://relay.atlanta.com:7777/iau39 2009 TR-ID: 934 2011 6. AtlantaRelay->BiloxiRelay(MSRP): 2013 MSRP xx 200 OK 2014 TR-ID: 934 2016 7. BiloxiRelay->Bob(MSRP): 2018 MSRP xx 200 OK 2019 TR-ID: 934 2021 8. Bob->Alice (SIP): 200 OK 2023 c=IN IP4 stuff 2024 m=message 9999 msrp/tcp text/plain 2025 a=direction: active 2027 9. Alice->Bob (SIP): ACK 2029 10. Alice->AtlantaRelay (MSRP): 2031 MSRP xx SEND 2032 TR-ID: 123 2033 Content-Type: "text/plain" 2034 Hi, I'm Alice! 2036 11. AtlantaRelay ->BiloxiRelay (MSRP): 2038 MSRP xx SEND 2039 TR-ID: 123 2040 Content-Type: "text/plain" 2041 Hi, I'm Alice! 2043 12. BiloxiRelay->Bob (MSRP): 2045 MSRP xx SEND 2046 TR-ID: 123 2047 Content-Type: "text/plain" 2048 Hi, I'm Alice! 2050 13. Bob->BiloxiRelay (MSRP): 2052 MSRP xx 200 OK 2053 TR-ID: 123 2055 14. BiloxiRelay->AtlantaRelay (MSRP): 2057 MSRP xx 200 OK 2058 TR-ID: 123 2060 15. AtlantaRelay->Alice (MSRP): 2062 MSRP xx 200 OK 2063 TR-ID: 123 2065 16. Alice->Bob (SIP): BYE 2067 17. Alice->AtlantaRelay (MSRP): 2069 MSRP xx BIND 2070 S-URL: msrp://relay.atlanta.com:7777/iau39 2071 TR-ID: 42 2072 Exp:0 2074 18. Relay->Alice (MSRP): Relay invalidates session state. 2076 MSRP xx 200 OK 2077 TR-ID: 42 2078 Exp:0 2080 19. Bob->Alice (SIP): 200 OK 2082 9. IANA Considerations 2084 9.1 MSRP Port 2086 MSRP uses TCP port XYX, to be determined by IANA after this document 2087 is approved for publication. Usage of this value is described in 2088 Section 7.1 2090 9.2 MSRP URL Schemes 2092 This document defines the URL schemes of "msrp" and "msrps". 2094 9.2.1 Syntax 2096 See Section 7.1. 2098 9.2.2 Character Encoding 2100 See Section 7.1. 2102 9.2.3 Intended Usage 2104 See Section 7.1. 2106 9.2.4 Protocols 2108 The Message Session Relay Protocol (MSRP). 2110 9.2.5 Security Considerations 2112 See Section 10. 2114 9.2.6 Relevant Publications 2116 RFCXXXX 2118 [Note to RFC Editor: Please replace RFCXXXX in the above paragraph 2119 with the actual number assigned to this document. 2121 9.3 SDP Parameters 2123 This document registers the following SDP parameters in the 2124 sdp-parameters registry: 2126 9.3.1 Direction 2128 Attribute-name: direction 2130 Long-form Attribute Name Direction 2132 Type: Media level 2134 Subject to Charset Attribute No 2136 Purpose and Appropriate Values See Section 6.2. 2138 9.3.2 Wrapped Types 2140 Attribute-name: accept-wrapped-types 2142 Long-form Attribute Name Acceptable MIME Types Inside Wrappers 2144 Type: Media level 2146 Subject to Charset Attribute No 2147 Purpose and Appropriate Values See Section 6.3. 2149 10. Security Considerations 2151 There are a number of security considerations for MSRP, some of which 2152 are mentioned elsewhere in this document. This section discusses 2153 those further, and introduces some new ones. 2155 10.1 TLS and the MSRPS Scheme 2157 All MSRP devices must support TLS, with at least the 2158 TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites 2159 MAY be supported. 2161 MSRP does not define a separate TCP port for TLS connections. This 2162 means that all MSRP server devices, that is, all devices that listen 2163 for TCP connections, MUST be prepared to handle both TLS and plain 2164 text connections on the same port. When a device accepts a TCP 2165 connection, it MUST watch for the TLS handshake messages to determine 2166 if a particular connection uses TLS. If the first data received is 2167 not part of a TLS handshake request, the device ceases to watch for 2168 the TLS handshake and begins normal MSRP processing. 2170 An MSRP device MAY refuse to accept a given request over a non-TLS 2171 connection by returning a 426 response, after which it MUST either 2172 immediately close the connection, or begin watching for a TLS 2173 handshake request as it would if it had just accepted a connection. 2175 MSRP devices acting in the role of TCP client MAY perform a TLS 2176 handshake either immediately upon connection, or immediately after 2177 receiving a 426 response. They MUST NOT attempt to upgrade to TLS at 2178 any other time. 2180 Allowing clients to upgrade at any time would require the server 2181 device to check every single request to determine if it is an MSRP 2182 request or a TLS handshake request. The specified approach only 2183 requires this check on the initial data received on a connection, 2184 or on data received immediately after a 426 response. In both 2185 cases, the receiver will have to peek ahead in the received data 2186 stream to look for the TLS, then read again from the start once 2187 the presence or absence of TLS has been determined. 2189 The MSRPS URI scheme indicates that all hops in an MSRP session MUST 2190 be protected with TLS. Ensuring this implies some additional rules. A 2191 relay MUST return an MSRPS URL to a BIND request if the request 2192 arrived over TLS and included a MSRPS URI in the S-URI header field. 2193 The relay MAY return an MSRPS URI to any BIND request that arrives 2194 over TLS, but MUST NOT return an MSRP URI to a BIND request that does 2195 not arrive over TLS. If a relay receives a BIND request with an MSRPS 2196 S-URI, over a non-TLS connection, it MUST reject the request with a 2197 426 response. A relay may insist on always using MSRPS by returning a 2198 426 to any bind received over an unprotected connection, and always 2199 returning MSRPS URLs to BIND requests over protected connections. 2201 A VISIT request for an MSRPS URL MUST be sent over a TLS protected 2202 connection. If a visiting relay receives a VISIT request for an MSRPS 2203 URL over an unprotected connection, it MUST reject the request with a 2204 426 response. 2206 10.2 Sensitivity of the Session URL 2208 The URL of a MSRP session is used by the visiting endpoint to 2209 identify itself to the hosting device, regardless of whether the 2210 session is directly hosted by the host endpoint, or is hosted by a 2211 relay. If an attacker were able to acquire session URL, either by 2212 guessing it or by eavesdropping, there is a window of opportunity in 2213 which the attacker could hijack the session by sending a VISIT 2214 request to the host device before the true visiting endpoint. Because 2215 of this sensitivity, the session URL SHOULD be constructed in a way 2216 to make it difficult to guess, and should be sufficiently random so 2217 that it is unlikely to be reused. All mechanisms used to transport 2218 the session URL to the visitor and back to the host SHOULD be 2219 protected from eavesdroppers and man-in-the-middle attacks. 2221 Therefore an MSRP device MUST support the use of TLS for at least the 2222 VISIT request, which by extension indicates the endpoint MUST support 2223 the use of TLS for all MSRP messages. Further, MSRP connections 2224 SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST 2225 be capable of using the security features of the signaling protocol 2226 in order to protect the SDP exchange and SHOULD actually use them on 2227 all such exchanges. End-to-end protection schemes SHOULD be preferred 2228 over hop-by-hop schemes for protection of the SDP exchange. 2230 10.3 End to End Protection of IMs 2232 Instant messages can contain very sensitive information. As a result, 2233 as specified in RFC 2779 [3], instant messaging protocols need to 2234 provide for encryption, integrity and authentication of instant 2235 messages. Therefore MSRP endpoints MUST support the end-to-end 2236 encryption and integrity of bodies sent via SEND requests using 2237 Secure MIME (S/MIME) [7]. 2239 Note that while each protected body could use separate keying 2240 material, this is inefficient in that it requires an independent 2241 public key operation for each message. Endpoints wishing to invoke 2242 end-to-end protection of message sessions SHOULD exchange symmetric 2243 keys in SDP k-lines, and use secret key encryption on for each MSRP 2244 message. When symmetric keys are present in the SDP, the offer-answer 2245 exchange MUST be protected from eavesdropping and tampering using the 2246 appropriate facilities of the signaling protocol. For example, if the 2247 signaling protocol is SIP, the SDP exchange MUST be protected using 2248 S/MIME. 2250 10.4 CPIM compatibility 2252 MSRP sessions may be gatewayed to other CPIM [17]compatible 2253 protocols. If this occurs, the gateway MUST maintain session state, 2254 and MUST translate between the MSRP session semantics and CPIM 2255 semantics that do not include a concept of sessions. Furthermore, 2256 when one endpoint of the session is a CPIM gateway, instant messages 2257 SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST 2258 include "message/cpim" as the first entry in its SDP format list. 2259 MSRP endpoints sending instant messages to a peer that has included 2260 'message/cpim" as the first entry in the format list SHOULD 2261 encapsulate all instant message bodies in "message/cpim" wrappers. 2262 All MSRP endpoints SHOULD support the S/MIME features of that format. 2264 10.5 PKI Considerations 2266 Several aspects of MSRP will benefit from being used in the context 2267 of a public key infrastructure. For example, the MSRPS scheme allows, 2268 and even encourages, TLS connections between endpoint devices. And 2269 while MSRP allows for a symmetric session key to protect all messages 2270 in a session, it is most likely that session key itself would be 2271 exchanged in a signaling protocol such as SIP. Since that key is 2272 extremely sensitive, its exchange would also need to be protected. In 2273 SIP, the preferred mechanism for this would be S/MIME, which would 2274 also benefit from a PKI. 2276 However, all of these features may be used without PKI. Each endpoint 2277 could instead use self signed certificates. This will, of course, be 2278 less convenient than with a PKI, in that there would be no 2279 certificate authority to act as a trusted introducer. Peers would be 2280 required to exchange certificates prior to securely communicating. 2282 Since, at least for the immediate future, any given MSRP 2283 implementation is likely to communicate with at least some peers that 2284 do not have a PKI available, MSRP implementations SHOULD support the 2285 use of self-signed certificates, and SHOULD support the ability to 2286 configure lists of trusted certificates. 2288 11. Changes from Previous Draft Versions 2289 This section to be deleted prior to publication as an RFC 2291 11.1 draft-ietf-simple-message-sessions-01 2293 Abstract rewritten. 2295 Added architectural considerations section. 2297 The m-line format list now only describes the root body part for a 2298 request. Contained body part types may be described in the 2299 "accept-wrapped-types" a-line attribute. 2301 Added a standard dummy value for the m-line port field. Clarified 2302 that a zero in this field has normal SDP meaning. 2304 Clarified that an endpoint is globally configured as to whether or 2305 not to use a relay. There is no relay discovery mechanism 2306 intrinsic to MSRP. 2308 Changed digest algorithm to SHA1. Added TR-ID and S-URI to the 2309 hash for digest authentication. 2311 CMS usage replaced with S/MIME. 2313 TLS and MSRPS usage clarified. 2315 Session state timeout is now based on SEND activity, rather than 2316 BIND and VISIT refreshes. 2318 Default port added. 2320 Added sequence diagrams to the example message flows. 2322 Added discussion of self-signed certificates in the security 2323 considerations section. 2325 11.2 draft-ietf-simple-message-sessions-00 2327 Name changed to reflect status as a work group item. 2329 This version no longer supports the use of multiple sessions 2330 across a single TCP session. This has several related changes: 2331 There is now a single session URI, rather than a separate one for 2332 each endpoint. The session URI is not required to be in requests 2333 other than BIND and VISIT, as the session can be determined based 2334 on the connection on which it arrives. 2336 BIND and VISIT now create soft state, eliminating the need for the 2337 RELEASE and LEAVE methods. 2339 The MSRP URL format was changed to better reflect generic URL 2340 standards. URL comparison and resolution rules were added. SRV 2341 usage added. 2343 Determination of host and visitor roles now uses a direction 2344 attribute much like the one used in COMEDIA. 2346 Format list negotiation expanded to allow a "prefer these formats 2347 but try anything" semantic 2349 Clarified handling of direction notification failures. 2351 Clarified signaling associated with session failure due to dropped 2352 connections. 2354 Clarified security related motivations for MSRP. 2356 Removed MIKEY dependency for session key exchange. Simple usage of 2357 k-lines in SDP, where the SDP exchange is protected end-to-end 2358 seems sufficient. 2360 11.3 draft-campbell-simple-im-sessions-01 2362 Version 01 is a significant re-write. References to COMEDIA were 2363 removed, as it was determined that COMEDIA would not allow 2364 connections to be used bidirectionally in the presence of NATs. 2365 Significantly more discussion of a concrete mechanism has been added 2366 to make up for no longer using COMEDIA. Additionally, this draft and 2367 draft-campbell-cpimmsg-sessions (which would have also changed 2368 drastically) have now been combined into this single draft. 2370 12. Contributors 2372 The following people contributed substantially to this ongoing 2373 effort: 2375 Rohan Mahy 2376 Allison Mankin 2377 Jon Peterson 2378 Brian Rosen 2379 Dean Willis 2380 Adam Roach 2381 Cullen Jennings 2383 Normative References 2385 [1] Handley, M. and V. Jacobson, "SDP: Session Description 2386 Protocol", RFC 2327, April 1998. 2388 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2389 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2390 Session Initiation Protocol", RFC 3261, June 2002. 2392 [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 2393 Presence Protocol Requirements", RFC 2779, February 2000. 2395 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 2396 Identifiers (URL): Generic Syntax", RFC 2396, August 1998. 2398 [5] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging 2399 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in 2400 progress), January 2003. 2402 [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 2403 specifying the location of services (DNS SRV)", RFC 2782, 2404 February 2000. 2406 [7] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2407 2633, June 1999. 2409 [8] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites for 2410 Transport Layer Security (TLS)", RFC 3268, June 2002. 2412 [9] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 2413 (SHA1)", RFC 3174, September 2001. 2415 Informational References 2417 [10] Campbell, B. and J. Rosenberg, "Session Initiation Protocol 2418 Extension for Instant Messaging", RFC 3428, September 2002. 2420 [11] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 2421 "RTP: A Transport Protocol for Real-Time Applications", RFC 2422 1889, January 1996. 2424 [12] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. 2425 and A. Johnston, "A Multi-party Application Framework for SIP", 2426 draft-ietf-sipping-cc-framework-02 (work in progress), May 2427 2003. 2429 [13] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 2430 "Best Current Practices for Third Party Call Control in the 2431 Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work 2432 in progress), March 2003. 2434 [14] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 2435 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 2436 progress), February 2003. 2438 [15] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of 2439 Resource Management and Session Initiation Protocol (SIP)", RFC 2440 3312, October 2002. 2442 [16] Peterson, J., "A Privacy Mechanism for the Session Initiation 2443 Protocol (SIP)", RFC 3323 , November 2002. 2445 [17] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", 2446 draft-ietf-impp-im-03 (work in progress), May 2003. 2448 [18] Yon, D., "Connection-Oriented Media Transport in SDP", 2449 draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 2450 2003. 2452 [19] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2453 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 2454 Basic and Digest Access Authentication", RFC 2617, June 1999. 2456 Authors' Addresses 2458 Ben Campbell 2459 dynamicsoft 2460 5100 Tennyson Parkway 2461 Suite 1200 2462 Plano, TX 75024 2464 EMail: bcampbell@dynamicsoft.com 2466 Jonathan Rosenberg 2467 dynamicsoft 2468 600 Lanidex Plaza 2469 Parsippany, NJ 07054 2471 EMail: jdrosen@dynamicsoft.com 2472 Robert Sparks 2473 dynamicsoft 2474 5100 Tennyson Parkway 2475 Suite 1200 2476 Plano, TX 75024 2478 EMail: rsparks@dynamicsoft.com 2480 Paul Kyzivat 2481 Cisco Systems 2482 Mail Stop LWL3/12/2 2483 900 Chelmsford St. 2484 Lowell, MA 01851 2486 EMail: pkyzivat@cisco.com 2488 Intellectual Property Statement 2490 The IETF takes no position regarding the validity or scope of any 2491 intellectual property or other rights that might be claimed to 2492 pertain to the implementation or use of the technology described in 2493 this document or the extent to which any license under such rights 2494 might or might not be available; neither does it represent that it 2495 has made any effort to identify any such rights. Information on the 2496 IETF's procedures with respect to rights in standards-track and 2497 standards-related documentation can be found in BCP-11. Copies of 2498 claims of rights made available for publication and any assurances of 2499 licenses to be made available, or the result of an attempt made to 2500 obtain a general license or permission for the use of such 2501 proprietary rights by implementors or users of this specification can 2502 be obtained from the IETF Secretariat. 2504 The IETF invites any interested party to bring to its attention any 2505 copyrights, patents or patent applications, or other proprietary 2506 rights which may cover technology that may be required to practice 2507 this standard. Please address the information to the IETF Executive 2508 Director. 2510 Full Copyright Statement 2512 Copyright (C) The Internet Society (2003). All Rights Reserved. 2514 This document and translations of it may be copied and furnished to 2515 others, and derivative works that comment on or otherwise explain it 2516 or assist in its implementation may be prepared, copied, published 2517 and distributed, in whole or in part, without restriction of any 2518 kind, provided that the above copyright notice and this paragraph are 2519 included on all such copies and derivative works. However, this 2520 document itself may not be modified in any way, such as by removing 2521 the copyright notice or references to the Internet Society or other 2522 Internet organizations, except as needed for the purpose of 2523 developing Internet standards in which case the procedures for 2524 copyrights defined in the Internet Standards process must be 2525 followed, or as required to translate it into languages other than 2526 English. 2528 The limited permissions granted above are perpetual and will not be 2529 revoked by the Internet Society or its successors or assignees. 2531 This document and the information contained herein is provided on an 2532 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2533 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2534 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2535 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2536 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2538 Acknowledgement 2540 Funding for the RFC Editor function is currently provided by the 2541 Internet Society.