idnits 2.17.1 draft-pd-msrp-websocket-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 387 has weird spacing: '...otocols a.exa...' (Using the creation date from RFC4975, updated by this document, for RFC5378 checks: 2003-05-23) -- 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 (November 23, 2012) is 4144 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-sipcore-sip-websocket-06 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Dunkley 3 Internet-Draft G. Llewellyn 4 Updates: 4975, 4976 (if approved) Crocodile RCS Ltd 5 Intended status: Standards Track November 23, 2012 6 Expires: May 27, 2013 8 The WebSocket Protocol as a Transport for the Message Session Relay 9 Protocol (MSRP) 10 draft-pd-msrp-websocket-02 12 Abstract 14 The WebSocket protocol enables two-way real-time communication 15 between clients and servers. This document specifies a new WebSocket 16 sub-protocol as a reliable transport mechanism between MSRP (Message 17 Session Relay Protocol) clients and relays to enable usage of MSRP in 18 new scenarios. This document normatively updates RFC 4975 and RFC 19 4976. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 27, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 4 59 4. The WebSocket MSRP Sub-Protocol . . . . . . . . . . . . . . . 4 60 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. MSRP encoding . . . . . . . . . . . . . . . . . . . . . . 5 62 5. MSRP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Updates to RFC 4975 . . . . . . . . . . . . . . . . . . . 6 65 5.2.1. MSRP URI Transport Parameter . . . . . . . . . . . . . 6 66 5.2.2. SDP Transport Protocol . . . . . . . . . . . . . . . . 6 67 5.3. Updates to RFC 4976 . . . . . . . . . . . . . . . . . . . 7 68 5.3.1. AUTH Request Authentication . . . . . . . . . . . . . 7 69 5.3.2. Use of TLS . . . . . . . . . . . . . . . . . . . . . . 7 70 6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 7 71 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. AUTH . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.2. SEND (MSRP WebSocket Client to MSRP Client) . . . . . . . 10 75 8.3. SEND (MSRP Client to MSRP WebSocket Client) . . . . . . . 13 76 8.4. SEND (MSRP WebSocket Client to MSRP WebSocket Client) . . 15 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 17 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 10.1. Registration of the WebSocket MSRP Sub-Protocol . . . . . 17 81 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 84 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 85 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 18 86 A.1. MSRP WebSocket Client Considerations . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 The WebSocket [RFC6455] protocol enables message exchange between 92 clients and servers on top of a persistent TCP connection (optionally 93 secured with TLS [RFC5246]). The initial protocol handshake makes 94 use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to 95 reuse existing HTTP infrastructure. 97 Modern web browsers include a WebSocket client stack complying with 98 the WebSocket API [WS-API] as specified by the W3C. It is expected 99 that other client applications (those running in personal computers 100 and devices such as smart-phones) will also make a WebSocket client 101 stack available. The specification in this document enables usage of 102 MSRP in these scenarios. 104 This specification defines a new WebSocket sub-protocol (as defined 105 in section 1.9 in [RFC6455]) for transporting MSRP messages between a 106 WebSocket client and MSRP relay [RFC4976] containing a WebSocket 107 server, a new transport for MSRP, and procedures for MSRP clients and 108 relays implementing the WebSocket transport. 110 2. Terminology 112 All diagrams, examples, and notes in this specification are non- 113 normative, as are all sections explicitly marked non-normative. 114 Everything else in this specification is normative. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2.1. Definitions 122 MSRP WebSocket Client: An MSRP entity capable of opening outbound 123 connections to MSRP relays which are WebSocket servers and 124 communicating using the WebSocket MSRP sub-protocol as defined 125 by this document. 127 MSRP WebSocket Server: An MSRP entity (specifically an MSRP relay 128 [RFC4976]) capable of listening for inbound connections from 129 WebSocket clients and communicating using the WebSocket MSRP 130 sub-protocol as defined by this document. 132 3. The WebSocket Protocol 134 _This section is non-normative._ 136 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 137 (optionally secured with TLS [RFC5246]) in which both client and 138 server exchange message units in both directions. The protocol 139 defines a connection handshake, WebSocket sub-protocol and extensions 140 negotiation, a frame format for sending application and control data, 141 a masking mechanism, and status codes for indicating disconnection 142 causes. 144 The WebSocket connection handshake is based on HTTP [RFC2616] and 145 utilizes the HTTP GET method with an "Upgrade" request. This is sent 146 by the client and then answered by the server (if the negotiation 147 succeeded) with an HTTP 101 status code. Once the handshake is 148 completed the connection upgrades from HTTP to the WebSocket 149 protocol. This handshake procedure is designed to reuse the existing 150 HTTP infrastructure. During the connection handshake, client and 151 server agree on the application protocol to use on top of the 152 WebSocket transport. Such application protocol (also known as a 153 "WebSocket sub-protocol") defines the format and semantics of the 154 messages exchanged by the endpoints. This could be a custom protocol 155 or a standardized one (such as the WebSocket MSRP sub-protocol 156 defined in this document). Once the HTTP 101 response is processed 157 both client and server reuse the underlying TCP connection for 158 sending WebSocket messages and control frames to each other. Unlike 159 plain HTTP, this connection is persistent and can be used for 160 multiple message exchanges. 162 WebSocket defines message units to be used by applications for the 163 exchange of data, so it provides a message boundary-preserving 164 transport layer. These message units can contain either UTF-8 text 165 or binary data, and can be split into multiple WebSocket text/binary 166 transport frames as needed by the WebSocket stack. 168 The WebSocket API [WS-API] for web browsers only defines callbacks 169 to be invoked upon receipt of an entire message unit, regardless 170 of whether it was received in a single WebSocket frame or split 171 across multiple frames. 173 4. The WebSocket MSRP Sub-Protocol 175 The term WebSocket sub-protocol refers to an application-level 176 protocol layered on top of a WebSocket connection. This document 177 specifies the WebSocket MSRP sub-protocol for carrying MSRP requests 178 and responses through a WebSocket connection. 180 4.1. Handshake 182 The MSRP WebSocket Client and MSRP WebSocket Server negotiate usage 183 of the WebSocket MSRP sub-protocol during the WebSocket handshake 184 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 185 include the value "msrp" in the Sec-WebSocket-Protocol header in its 186 handshake request. The 101 reply from the Server MUST contain "msrp" 187 in its corresponding Sec-WebSocket-Protocol header. 189 Below is an example of a WebSocket handshake in which the Client 190 requests the WebSocket MSRP sub-protocol support from the Server: 192 GET / HTTP/1.1 193 Host: a.example.com 194 Upgrade: websocket 195 Connection: Upgrade 196 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 197 Origin: http://www.example.com 198 Sec-WebSocket-Protocol: msrp 199 Sec-WebSocket-Version: 13 201 The handshake response from the Server accepting the WebSocket MSRP 202 sub-protocol would look as follows: 204 HTTP/1.1 101 Switching Protocols 205 Upgrade: websocket 206 Connection: Upgrade 207 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 208 Sec-WebSocket-Protocol: msrp 210 Once the negotiation has been completed, the WebSocket connection is 211 established and can be used for the transport of MSRP requests and 212 responses. The WebSocket messages transmitted over this connection 213 MUST conform to the negotiated WebSocket sub-protocol. 215 4.2. MSRP encoding 217 WebSocket messages can be transported in either UTF-8 text frames or 218 binary frames. MSRP [RFC4975] allows both text and binary bodies in 219 MSRP requests. Therefore MSRP WebSocket Clients and Servers MUST 220 accept both text and binary frames. 222 5. MSRP WebSocket Transport 223 5.1. General 225 WebSocket clients cannot receive WebSocket connections initiated by 226 other WebSocket clients or WebSocket servers. This means that it is 227 impossible for an MSRP client to communicate directly with other MSRP 228 clients. Therefore, all MSRP over WebSocket messages MUST be routed 229 via an MSRP WebSocket Server. 231 MSRP WebSocket Servers can be used to route MSRP messages between 232 MSRP WebSocket Clients, and between MSRP WebSocket Clients and 233 "normal" MSRP clients and relays. 235 Each MSRP message MUST be carried within a single WebSocket message, 236 and a WebSocket message MUST NOT contain more than one MSRP message. 238 This simplifies parsing of MSRP messages for both clients and 239 servers. When large messages are sent MSRP chunking (as defined 240 in section 5.1 of [RFC4975]) MUST be used to split the message 241 into several smaller MSRP messages. 243 5.2. Updates to RFC 4975 245 5.2.1. MSRP URI Transport Parameter 247 This document defines the value "ws" as the transport parameter value 248 for an MSRP URI [RFC3986] to be contacted using the MSRP WebSocket 249 sub-protocol as transport. 251 The updated augmented BNF (Backus-Naur Form) [RFC5234] for this 252 parameter is the following (the original BNF for this parameter can 253 be found in [RFC4975]): 255 transport = "tcp" / "ws" / 1*ALPHANUM 257 5.2.2. SDP Transport Protocol 259 This document does not define a new SDP transport protocol for MSRP 260 over WebSockets. Adding a new SDP transport protocol may cause 261 problems with parsers in existing, non-WebSocket, MSRP clients. 262 Further, as all MSRP over WebSocket messages MUST be routed via an 263 MSRP WebSocket Server it is acceptable for an MSRP WebSocket Client 264 to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in SDP - that 265 being the protocol used by non-WebSocket clients and between MSRP 266 relays. 268 5.3. Updates to RFC 4976 270 5.3.1. AUTH Request Authentication 272 The MSRP relay specification [RFC4976] states that AUTH requests MUST 273 be authenticated. This document modifies this requirement to state 274 that all connections between MSRP clients and relays MUST be 275 authenticated. In the case of the MSRP WebSocket Clients there are 276 two possible authentication mechanisms: 278 1. HTTP Digest authentication in AUTH (as per [RFC4976]). 280 2. Cookie-based or HTTP Digest authentication in the WebSocket 281 Handshake (see Section 7). 283 5.3.2. Use of TLS 285 The MSRP relay specification [RFC4976] mandates the use of TLS 286 between MSRP clients and MSRP relays, and specifies the mechanisms 287 that must be used for TLS authentication. This document downgrades 288 the MUSTs with respect to TLS to SHOULDs when using the MSRP 289 WebSocket sub-protocol as transport. Connections between MSRP 290 WebSocket Clients and Servers SHOULD use secure WebSocket 291 connections, but MAY use insecure WebSocket connections. As the 292 secure WebSocket connections are negotiated between the client's 293 WebSocket stack and the WebSocket server, an MSRP WebSocket Client 294 may have no knowledge of, or control over, the mechanisms used for 295 TLS authentication. 297 6. Connection Keep Alive 299 _This section is non-normative._ 301 It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their 302 WebSocket connections open by sending periodic WebSocket "Ping" 303 frames as described in [RFC6455] section 5.5.2. 305 The WebSocket API [WS-API] does not provide a mechanism for 306 applications running in a web browser to control whether or not 307 periodic WebSocket "Ping" frames are sent to the server. The 308 implementation of such a keep alive feature is the decision of 309 each web browser manufacturer and may also depend on the 310 configuration of the web browser. 312 A future WebSocket protocol extension providing a similar keep alive 313 mechanism could also be used. 315 7. Authentication 317 _This section is non-normative._ 319 Prior to sending MSRP requests, an MSRP WebSocket Client connects to 320 an MSRP WebSocket Server and performs the connection handshake. As 321 described in Section 3 the handshake procedure involves a HTTP GET 322 method request from the Client and a response from the Server 323 including an HTTP 101 status code. 325 In order to authorize the WebSocket connection, the MSRP WebSocket 326 Server MAY inspect any Cookie [RFC6265] headers present in the HTTP 327 GET request. For many web applications the value of such a Cookie is 328 provided by the web server once the user has authenticated themselves 329 to the web server, which could be done by many existing mechanisms. 330 As an alternative method, the MSRP WebSocket Server could request 331 HTTP authentication by replying to the Client's GET method request 332 with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers 333 this usage in section 4.1: 335 If the status code received from the server is not 101, the 336 WebSocket client stack handles the response per HTTP [RFC2616] 337 procedures, in particular the client might perform authentication 338 if it receives 401 status code. 340 Regardless of whether the MSRP WebSocket Server requires 341 authentication during the WebSocket handshake, authentication MAY be 342 requested at MSRP protocol level. Therefore it is RECOMMENDED that 343 an MSRP WebSocket Client implements HTTP Digest [RFC2617] 344 authentication as stated in [RFC4976]. 346 8. Examples 348 8.1. AUTH 350 Alice (MSRP WSS) a.example.com 351 | | 352 |HTTP GET (WS handshake) F1 | 353 |---------------------------->| 354 |101 Switching Protocols F2 | 355 |<----------------------------| 356 | | 357 |AUTH F3 | 358 |---------------------------->| 359 |200 OK F4 | 360 |<----------------------------| 361 | | 363 Alice loads a web page using her web browser and retrieves JavaScript 364 code implementing the WebSocket MSRP sub-protocol defined in this 365 document. The JavaScript code (an MSRP WebSocket Client) establishes 366 a secure WebSocket connection with an MSRP relay (an MSRP WebSocket 367 Server) at a.example.com. Upon WebSocket connection, Alice 368 constructs and sends an MSRP AUTH request. Since the JavaScript 369 stack in a browser has no way to determine the local address from 370 which the WebSocket connection was made, this implementation uses a 371 random ".invalid" domain name for the hostpart of the From-Path URI 372 (see Appendix A.1). 374 Message details (authentication is omitted for simplicity): 376 F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS) 378 GET / HTTP/1.1 379 Host: a.example.com 380 Upgrade: websocket 381 Connection: Upgrade 382 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 383 Origin: https://www.example.com 384 Sec-WebSocket-Protocol: msrp 385 Sec-WebSocket-Version: 13 387 F2 101 Switching Protocols a.example.com -> Alice (TLS) 389 HTTP/1.1 101 Switching Protocols 390 Upgrade: websocket 391 Connection: Upgrade 392 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 393 Sec-WebSocket-Protocol: msrp 395 F3 AUTH Alice -> a.example.com (transport WSS) 397 MSRP 49fi AUTH 398 To-Path: msrps://alice@a.example.com:443;ws 399 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 400 -------49fi$ 402 F4 200 OK a.example.com -> Alice (transport WSS) 404 MSRP 49fi 200 OK 405 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 406 From-Path: msrps://alice@a.example.com:443;ws 407 Use-Path: msrps://a.example.com:2855/jui787s2f;tcp 408 Expires: 900 409 -------49fi$ 411 8.2. SEND (MSRP WebSocket Client to MSRP Client) 412 Alice (MSRP WSS) a.example.com (MSRP TLS) Bob 413 | | | 414 |SEND F1 | | 415 |---------------------------->| | 416 |200 OK F2 | | 417 |<----------------------------| | 418 | |SEND F3 | 419 | |---------------------------->| 420 | |200 OK F4 | 421 | |<----------------------------| 423 In the same scenario Alice sends an instant message to Bob (session 424 details having been previously negotiated by some other mechanism - 425 such as SDP [RFC4976]). The MSRP WebSocket Server at a.example.com 426 acts as an MSRP relay, routing the message to Bob over TLS. 428 In this example Bob himself does not require an MSRP relay and has 429 not authenticated with a.example.com but Alice does and has. 431 Message details (note that MSRP does not permit line folding. A "\" 432 in the examples shows a line continuation due to limitations in line 433 length of this document. Neither the backslash nor the extra CRLF is 434 included in the actual request or response): 436 F1 SEND Alice -> a.example.com (transport WSS) 438 MSRP 6aef SEND 439 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 440 msrps://bob.example.com:8145/foo;tcp 441 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 442 Success-Report: no 443 Byte-Range: 1-*/* 444 Message-ID: 87652 445 Content-Type: text/plain 447 Hi Bob, I'm about to send you file.mpeg 448 -------6aef$ 450 F2 200 OK a.example.com -> Alice (transport WSS) 452 MSRP 6aef 200 OK 453 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 454 From-Path: msrps://a.example.com:2855/jui787s2f;tcp 455 -------6aef$ 457 F3 SEND a.example.com -> Bob (transport TLS) 459 MSRP juh76 SEND 460 To-Path: msrps://bob.example.com:8145/foo;tcp 461 From-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 462 msrps://df7jal23ls0d.invalid:2855/98cjs;ws 463 Success-Report: no 464 Byte-Range: 1-*/* 465 Message-ID: 87652 466 Content-Type: text/plain 468 Hi Bob, I'm about to send you file.mpeg 469 -------juh76$ 471 F4 200 OK Bob -> a.example.com (transport TLS) 473 MSRP juh76 200 OK 474 To-Path: msrps://a.example.com:2855/jui787s2f;tcp 475 From-Path: msrps://bob.example.com:8145/foo;tcp 476 -------juh76$ 478 8.3. SEND (MSRP Client to MSRP WebSocket Client) 480 Bob (MSRP TLS) a.example.com (MSRP WSS) Alice 481 | | | 482 |SEND F1 | | 483 |---------------------------->| | 484 |200 OK F2 | | 485 |<----------------------------| | 486 | |SEND F3 | 487 | |---------------------------->| 488 | |200 OK F4 | 489 | |<----------------------------| 491 In the same scenario Bob sends an instant message to Alice (session 492 details having been previously negotiated by some other mechanism - 493 such as SDP [RFC4976]). The MSRP WebSocket Server at a.example.com 494 acts as an MSRP relay, routing the message to Alice over secure 495 WebSocket. 497 In this example Bob himself does not require an MSRP relay and has 498 not authenticated with a.example.com but Alice does and has. 500 Message details (note that MSRP does not permit line folding. A "\" 501 in the examples shows a line continuation due to limitations in line 502 length of this document. Neither the backslash nor the extra CRLF is 503 included in the actual request or response): 505 F1 SEND Bob -> a.example.com (transport TLS) 507 MSRP xght6 SEND 508 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 509 msrps://df7jal23ls0d.invalid:2855/98cjs;ws 510 From-Path: msrps://bob.example.com:8145/foo;tcp 511 Success-Report: no 512 Byte-Range: 1-*/* 513 Message-ID: 87652 514 Content-Type: text/plain 516 Thanks for the file. 517 -------xght6$ 519 F2 200 OK a.example.com -> Bob (transport TLS) 521 MSRP xght6 200 OK 522 To-Path: msrps://bob.example.com:8145/foo;tcp 523 From-Path: msrps://a.example.com:2855/jui787s2f;tcp 524 -------xght6$ 526 F3 SEND a.example.com -> Alice (transport WSS) 528 MSRP yh67 SEND 529 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 530 From-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 531 msrps://bob.example.com:8145/foo;tcp 532 Success-Report: no 533 Byte-Range: 1-*/* 534 Message-ID: 87652 535 Content-Type: text/plain 537 Hi Bob, I'm about to send you file.mpeg 538 -------yh67$ 540 F4 200 OK Bob -> a.example.com (transport TLS) 542 MSRP yh67 200 OK 543 To-Path: msrps://a.example.com:2855/jui787s2f;tcp 544 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 545 -------yh67$ 547 8.4. SEND (MSRP WebSocket Client to MSRP WebSocket Client) 549 Alice (MSRP WSS) a.example.com (MSRP WSS) Carol 550 | | | 551 |SEND F1 | | 552 |---------------------------->| | 553 |200 OK F2 | | 554 |<----------------------------| | 555 | |SEND F3 | 556 | |---------------------------->| 557 | |200 OK F4 | 558 | |<----------------------------| 560 In the same scenario Alice sends an instant message to Carol (session 561 details having been previously negotiated by some other mechanism - 562 such as SDP [RFC4976]). The MSRP WebSocket Server at a.example.com 563 acts as an MSRP relay, routing the message to Carol over secure 564 WebSocket. 566 In this example both Alice and Carol are using MSRP WebSocket Clients 567 and an MSRP WebSocket Server. This means that a.example.com will 568 appear twice in the To-Path in F1. a.example.com can either handle 569 this internally or loop the MSRP SEND request back to itself as if it 570 were two, separate, MSRP relays. 572 Message details (note that MSRP does not permit line folding. A "\" 573 in the examples shows a line continuation due to limitations in line 574 length of this document. Neither the backslash nor the extra CRLF is 575 included in the actual request or response): 577 F1 SEND Alice -> a.example.com (transport WSS) 579 MSRP kjh6 SEND 580 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 581 msrps://a.example.com:2855/iwnslt;tcp \ 582 msrps://jk9awp14vj8x.invalid:2855/76qwe;ws 583 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 584 Success-Report: no 585 Byte-Range: 1-*/* 586 Message-ID: 87652 587 Content-Type: text/plain 589 Carol, here is the file Bob sent me. 590 -------kjh6$ 592 F2 200 OK a.example.com -> Alice (transport WSS) 594 MSRP kjh6 200 OK 595 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 596 From-Path: msrps://a.example.com:2855/jui787s2f;tcp 597 -------kjh6$ 599 F3 SEND a.example.com -> Carol (transport WSS) 601 MSRP re58 SEND 602 To-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws 603 From-Path: msrps://a.example.com:2855/iwnslt;tcp \ 604 msrps://a.example.com:2855/jui787s2f;tcp \ 605 msrps://df7jal23ls0d.invalid/98cjs;ws 606 Success-Report: no 607 Byte-Range: 1-*/* 608 Content-Type: text/plain 610 Carol, here is the file Bob sent me. 611 -------re58$ 613 F4 200 OK Carol -> a.example.com (transport WSS) 615 MSRP re58 200 OK 616 To-Path: msrps://a.example.com:2855/iwnslt;tcp 617 From-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws 618 -------re58$ 620 9. Security Considerations 622 9.1. Secure WebSocket Connection 624 It is RECOMMENDED that the MSRP traffic transported over a WebSocket 625 communication be protected by using a secure WebSocket connection 626 (using TLS [RFC5246] over TCP). 628 10. IANA Considerations 630 10.1. Registration of the WebSocket MSRP Sub-Protocol 632 This specification requests IANA to register the WebSocket MSRP sub- 633 protocol in the registry of WebSocket sub-protocols with the 634 following data: 636 Subprotocol Identifier: msrp 638 Subprotocol Common Name: WebSocket Transport for MSRP (Message 639 Session Relay Protocol) 641 Subprotocol Definition: TBD, it should point to this document 643 11. Acknowledgements 645 Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and 646 Victor Pascual, the authors of [I-D.ietf-sipcore-sip-websocket] which 647 has inspired this draft. 649 Additional thanks to Inaki Baz Castillo who pointed out that "web- 650 browser" shouldn't be used all the time as this specification should 651 be valid for smartphones and apps other than browsers. 653 Special thanks to James Wyatt from Crocodile RCS Ltd for helping with 654 the JavaScript MSRP over WebSockets prototyping. 656 12. References 658 12.1. Normative References 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 664 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 666 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 667 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 668 September 2007. 670 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 671 Specifications: ABNF", STD 68, RFC 5234, January 2008. 673 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 674 RFC 6455, December 2011. 676 12.2. Informative References 678 [I-D.ietf-sipcore-sip-websocket] 679 Castillo, I., Millan, J., and V. Pascual, "The WebSocket 680 Protocol as a Transport for the Session Initiation 681 Protocol (SIP)", draft-ietf-sipcore-sip-websocket-06 (work 682 in progress), November 2012. 684 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 685 Names", BCP 32, RFC 2606, June 1999. 687 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 688 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 689 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 691 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 692 Leach, P., Luotonen, A., and L. Stewart, "HTTP 693 Authentication: Basic and Digest Access Authentication", 694 RFC 2617, June 1999. 696 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 697 Resource Identifier (URI): Generic Syntax", STD 66, 698 RFC 3986, January 2005. 700 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 701 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 703 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 704 April 2011. 706 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 708 Appendix A. Implementation Guidelines 710 _This section is non-normative._ 712 A.1. MSRP WebSocket Client Considerations 714 The JavaScript stack in web browsers does not have the ability to 715 discover the local transport address used for originating WebSocket 716 connections. Therefore the MSRP WebSocket Client constructs a domain 717 name consisting of a random token followed by the ".invalid" top- 718 level domain name, as stated in [RFC2606], and uses it within its 719 From-Path headers. 721 The From-Path URI provided by MSRP clients which use an MSRP relay 722 is not used for routing MSRP messages, thus it is safe to set a 723 random domain in the hostpart of the From-Path URI. 725 Authors' Addresses 727 Peter Dunkley 728 Crocodile RCS Ltd 729 Forum 3, Parkway 730 Solent Business Park, Whiteley 731 Fareham PO15 7FH 732 United Kingdom 734 Email: peter.dunkley@crocodile-rcs.com 736 Gavin Llewellyn 737 Crocodile RCS Ltd 738 Forum 3, Parkway 739 Solent Business Park, Whiteley 740 Fareham PO15 7FH 741 United Kingdom 743 Email: gavin.llewellyn@crocodile-rcs.com