idnits 2.17.1 draft-pd-msrp-websocket-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4975, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4976, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 385 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 (October 11, 2012) is 4208 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: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5234' is defined on line 657, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-sipcore-sip-websocket-04 -- 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 (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Dunkley 3 Internet-Draft Crocodile RCS Ltd 4 Updates: 4975, 4976 (if approved) October 11, 2012 5 Intended status: Informational 6 Expires: April 14, 2013 8 The WebSocket Protocol as a Transport for the Message Session Relay 9 Protocol (MSRP) 10 draft-pd-msrp-websocket-00 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. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 14, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 4 58 4. The WebSocket MSRP Sub-Protocol . . . . . . . . . . . . . . . 4 59 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. MSRP encoding . . . . . . . . . . . . . . . . . . . . . . 5 61 5. MSRP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 62 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Updates to RFC 4975 . . . . . . . . . . . . . . . . . . . 6 64 5.2.1. MSRP URI Transport Parameter . . . . . . . . . . . . . 6 65 5.2.2. SDP Transport Protocol . . . . . . . . . . . . . . . . 6 66 5.3. Updates to RFC 4976 . . . . . . . . . . . . . . . . . . . 7 67 5.3.1. AUTH Request Authentication . . . . . . . . . . . . . 7 68 5.3.2. Use of TLS . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 7 70 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. AUTH . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.2. SEND (MSRP WebSocket Client to MSRP Client) . . . . . . . 10 74 8.3. SEND (MSRP Client to MSRP WebSocket Client) . . . . . . . 13 75 8.4. SEND (MSRP WebSocket Client to MSRP WebSocket Client) . . 15 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 17 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 10.1. Registration of the WebSocket MSRP Sub-Protocol . . . . . 17 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 84 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 18 85 A.1. MSRP WebSocket Client Considerations . . . . . . . . . . . 18 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Introduction 90 The WebSocket [RFC6455] protocol enables message exchange between 91 clients and servers on top of a persistent TCP connection (optionally 92 secured with TLS [RFC5246]). The initial protocol handshake makes 93 use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to 94 reuse existing HTTP infrastructure. 96 Modern web browsers include a WebSocket client stack complying with 97 the WebSocket API [WS-API] as specified by the W3C. It is expected 98 that other client applications (those running in personal computers 99 and devices such as smart-phones) will also make a WebSocket client 100 stack available. The specification in this document enables usage of 101 MSRP in these scenarios. 103 This specification defines a new WebSocket sub-protocol (as defined 104 in section 1.9 in [RFC6455]) for transporting MSRP messages between a 105 WebSocket client and MSRP relay [RFC4976] containing a WebSocket 106 server, a new transport for MSRP, and procedures for MSRP clients and 107 relays implementing the WebSocket transport. 109 2. Terminology 111 All diagrams, examples, and notes in this specification are non- 112 normative, as are all sections explicitly marked non-normative. 113 Everything else in this specification is normative. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2.1. Definitions 121 MSRP WebSocket Client: An MSRP entity capable of opening outbound 122 connections to MSRP relays which are WebSocket servers and 123 communicating using the WebSocket MSRP sub-protocol as defined 124 by this document. 126 MSRP WebSocket Server: An MSRP entity (specifically an MSRP relay) 127 capable of listening for inbound connections from WebSocket 128 clients and communicating using the WebSocket MSRP sub-protocol 129 as defined by this document. 131 3. The WebSocket Protocol 133 _This section is non-normative._ 135 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 136 (optionally secured with TLS [RFC5246]) in which both client and 137 server exchange message units in both directions. The protocol 138 defines a connection handshake, WebSocket sub-protocol and extensions 139 negotiation, a frame format for sending application and control data, 140 a masking mechanism, and status codes for indicating disconnection 141 causes. 143 The WebSocket connection handshake is based on HTTP [RFC2616] and 144 utilizes the HTTP GET method with an "Upgrade" request. This is sent 145 by the client and then answered by the server (if the negotiation 146 succeeded) with an HTTP 101 status code. Once the handshake is 147 completed the connection upgrades from HTTP to the WebSocket 148 protocol. This handshake procedure is designed to reuse the existing 149 HTTP infrastructure. During the connection handshake, client and 150 server agree on the application protocol to use on top of the 151 WebSocket transport. Such application protocol (also known as a 152 "WebSocket sub-protocol") defines the format and semantics of the 153 messages exchanged by the endpoints. This could be a custom protocol 154 or a standardized one (such as the WebSocket MSRP sub-protocol 155 defined in this document). Once the HTTP 101 response is processed 156 both client and server reuse the underlying TCP connection for 157 sending WebSocket messages and control frames to each other. Unlike 158 plain HTTP, this connection is persistent and can be used for 159 multiple message exchanges. 161 WebSocket defines message units to be used by applications for the 162 exchange of data, so it provides a message boundary-preserving 163 transport layer. These message units can contain either UTF-8 text 164 or binary data, and can be split into multiple WebSocket text/binary 165 transport frames as needed by the WebSocket stack. 167 The WebSocket API [WS-API] for web browsers only defines callbacks 168 to be invoked upon receipt of an entire message unit, regardless 169 of whether it was received in a single WebSocket frame or split 170 across multiple frames. 172 4. The WebSocket MSRP Sub-Protocol 174 The term WebSocket sub-protocol refers to an application-level 175 protocol layered on top of a WebSocket connection. This document 176 specifies the WebSocket MSRP sub-protocol for carrying MSRP requests 177 and responses through a WebSocket connection. 179 4.1. Handshake 181 The MSRP WebSocket Client and MSRP WebSocket Server negotiate usage 182 of the WebSocket MSRP sub-protocol during the WebSocket handshake 183 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 184 include the value "msrp" in the Sec-WebSocket-Protocol header in its 185 handshake request. The 101 reply from the Server MUST contain "msrp" 186 in its corresponding Sec-WebSocket-Protocol header. 188 Below is an example of a WebSocket handshake in which the Client 189 requests the WebSocket MSRP sub-protocol support from the Server: 191 GET / HTTP/1.1 192 Host: a.example.com 193 Upgrade: websocket 194 Connection: Upgrade 195 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 196 Origin: http://www.example.com 197 Sec-WebSocket-Protocol: msrp 198 Sec-WebSocket-Version: 13 200 The handshake response from the Server accepting the WebSocket MSRP 201 sub-protocol would look as follows: 203 HTTP/1.1 101 Switching Protocols 204 Upgrade: websocket 205 Connection: Upgrade 206 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 207 Sec-WebSocket-Protocol: msrp 209 Once the negotiation has been completed, the WebSocket connection is 210 established and can be used for the transport of MSRP requests and 211 responses. The WebSocket messages transmitted over this connection 212 MUST conform to the negotiated WebSocket sub-protocol. 214 4.2. MSRP encoding 216 WebSocket messages can be transported in either UTF-8 text frames or 217 binary frames. MSRP [RFC4975] allows both text and binary bodies in 218 MSRP requests. Therefore MSRP WebSocket Clients and Servers MUST 219 accept both text and binary frames. 221 5. MSRP WebSocket Transport 222 5.1. General 224 Web-browsers are WebSocket clients and cannot receive WebSocket 225 connections initiated by other clients. This means that it is 226 impossible for a JavaScript MSRP client to communicate directly with 227 other MSRP clients. Therefore, all MSRP over WebSocket messages MUST 228 be routed via an MSRP relay [RFC4976]. 230 MSRP WebSocket Servers can be used to route MSRP messages between 231 MSRP WebSocket Clients, and between MSRP WebSocket Clients and 232 "normal" MSRP clients and relays. 234 Each MSRP message MUST be carried within a single WebSocket message, 235 and a WebSocket message MUST NOT contain more than one MSRP message. 237 This simplifies parsing of MSRP messages for both clients and 238 servers. When large messages are sent MSRP chunking (as defined 239 in section 5.1 of [RFC4975]) MUST be used to split the message 240 into several smaller MSRP messages. 242 5.2. Updates to RFC 4975 244 5.2.1. MSRP URI Transport Parameter 246 This document defines the value "ws" as the transport parameter value 247 for an MSRP URI [RFC3986] to be contacted using the MSRP WebSocket 248 sub-protocol as transport. 250 The updated augmented BNF (Backus-Naur Form) [RFC5234]for this 251 parameter is the following (the original BNF for this parameter can 252 be found in [RFC4975]): 254 transport = "tcp" / "ws" / 1*ALPHANUM 256 5.2.2. SDP Transport Protocol 258 This document does not define a new SDP transport protocol for MSRP 259 over WebSockets. Adding a new SDP transport protocol may cause 260 problems with parsers in existing, non-WebSocket, MSRP clients. 261 Further, as all MSRP over WebSocket messages MUST be routed via an 262 MSRP WebSocket Server it is acceptable for an MSRP WebSocket Client 263 to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in SDP - that 264 being the protocol used by non-WebSocket clients and between MSRP 265 relays. 267 5.3. Updates to RFC 4976 269 5.3.1. AUTH Request Authentication 271 The MSRP relay specification [RFC4976] states that AUTH requests MUST 272 be authenticated. This document modifies this requirement to state 273 that all connections between MSRP clients and relays MUST be 274 authenticated. In the case of the MSRP WebSocket Clients there are 275 two possible authentication mechanisms: 277 1. HTTP Digest authentication in AUTH (as per [RFC4976]). 279 2. Cookie-based or HTTP Digest authentication in the WebSocket 280 Handshake (see Section 7). 282 5.3.2. Use of TLS 284 The MSRP relay specification [RFC4976] mandates the use of TLS 285 between MSRP clients and MSRP relays, and specifies the mechanisms 286 that must be used for TLS authentication. This document downgrades 287 the MUSTs with respect to TLS to SHOULDs when using the MSRP 288 WebSocket sub-protocol as transport. Connections between MSRP 289 WebSocket Clients and Servers SHOULD use secure WebSocket 290 connections, but MAY use insecure WebSocket connections. As the 291 secure WebSocket connections are negotiated between the web-browser 292 and the WebSocket server an MSRP WebSocket Client has no knowledge 293 of, or control over, the mechanisms used for TLS authentication. 295 6. Connection Keep Alive 297 _This section is non-normative._ 299 It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their 300 WebSocket connections open by sending periodic WebSocket "Ping" 301 frames as described in [RFC6455] section 5.5.2. 303 The WebSocket API [WS-API] does not provide a mechanism for 304 applications running in a web browser to control whether or not 305 periodic WebSocket "Ping" frames are sent to the server. The 306 implementation of such a keep alive feature is the decision of 307 each web browser manufacturer and may also depend on the 308 configuration of the web browser. 310 A future WebSocket protocol extension providing a similar keep alive 311 mechanism could also be used. 313 7. Authentication 315 _This section is non-normative._ 317 Prior to sending MSRP requests, an MSRP WebSocket Client connects to 318 an MSRP WebSocket Server and performs the connection handshake. As 319 described in Section 3 the handshake procedure involves a HTTP GET 320 method request from the Client and a response from the Server 321 including an HTTP 101 status code. 323 In order to authorize the WebSocket connection, the MSRP WebSocket 324 Server MAY inspect any Cookie [RFC6265] headers present in the HTTP 325 GET request. For many web applications the value of such a Cookie is 326 provided by the web server once the user has authenticated themselves 327 to the web server, which could be done by many existing mechanisms. 328 As an alternative method, the MSRP WebSocket Server could request 329 HTTP authentication by replying to the Client's GET method request 330 with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers 331 this usage in section 4.1: 333 If the status code received from the server is not 101, the 334 WebSocket client stack handles the response per HTTP [RFC2616] 335 procedures, in particular the client might perform authentication 336 if it receives 401 status code. 338 Regardless of whether the MSRP WebSocket Server requires 339 authentication during the WebSocket handshake, authentication MAY be 340 requested at MSRP protocol level. Therefore it is RECOMMENDED that 341 an MSRP WebSocket Client implements HTTP Digest [RFC2617] 342 authentication as stated in [RFC4976]. 344 8. Examples 346 8.1. AUTH 348 Alice (MSRP WSS) a.example.com 349 | | 350 |HTTP GET (WS handshake) F1 | 351 |---------------------------->| 352 |101 Switching Protocols F2 | 353 |<----------------------------| 354 | | 355 |AUTH F3 | 356 |---------------------------->| 357 |200 OK F4 | 358 |<----------------------------| 359 | | 361 Alice loads a web page using her web browser and retrieves JavaScript 362 code implementing the WebSocket MSRP sub-protocol defined in this 363 document. The JavaScript code (an MSRP WebSocket Client) establishes 364 a secure WebSocket connection with an MSRP relay (a MSRP WebSocket 365 Server) at a.example.com. Upon WebSocket connection, Alice 366 constructs and sends an MSRP AUTH request. Since the JavaScript 367 stack in a browser has no way to determine the local address from 368 which the WebSocket connection was made, this implementation uses a 369 random ".invalid" domain name for the hostpart of the From-Path URI 370 (see Appendix A.1). 372 Message details (authentication is omitted for simplicity): 374 F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS) 376 GET / HTTP/1.1 377 Host: a.example.com 378 Upgrade: websocket 379 Connection: Upgrade 380 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 381 Origin: https://www.example.com 382 Sec-WebSocket-Protocol: msrp 383 Sec-WebSocket-Version: 13 385 F2 101 Switching Protocols a.example.com -> Alice (TLS) 387 HTTP/1.1 101 Switching Protocols 388 Upgrade: websocket 389 Connection: Upgrade 390 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 391 Sec-WebSocket-Protocol: msrp 393 F3 AUTH Alice -> a.example.com (transport WSS) 395 MSRP 49fi AUTH 396 To-Path: msrps://alice@a.example.com;tcp 397 From-Path: msrps://df7jal23ls0d.invalid/98cjs;ws 398 -------49fi$ 400 F4 200 OK a.example.com -> Alice (transport WSS) 402 MSRP 49fi 200 OK 403 To-Path: msrps://df7jal23ls0d.invalid/98cjs;ws 404 From-Path: msrps://alice@a.example.com;tcp 405 Use-Path: msrps://a.example.com:9000/jui787s2f;tcp 406 Expires: 900 407 -------49fi$ 409 8.2. SEND (MSRP WebSocket Client to MSRP Client) 410 Alice (MSRP WSS) a.example.com (MSRP TLS) Bob 411 | | | 412 |SEND F1 | | 413 |---------------------------->| | 414 |200 OK F2 | | 415 |<----------------------------| | 416 | |SEND F3 | 417 | |---------------------------->| 418 | |200 OK F4 | 419 | |<----------------------------| 421 In the same scenario Alice sends an instant message to Bob (session 422 details having been previously negotiated by some other mechanism - 423 such as SDP [RFC4976]). The MSRP WebSocket Server at a.example.com 424 acts as an MSRP relay, routing the message to Bob over TLS. 426 Message details (note that MSRP does not permit line folding. A "\" 427 in the examples shows a line continuation due to limitations in line 428 length of this document. Neither the backslash nor the extra CRLF is 429 included in the actual request or response): 431 F1 SEND Alice -> a.example.com (transport WSS) 433 MSRP 6aef SEND 434 To-Path: msrps://a.example.com:9000/kjfjan;tcp \ 435 msrps://bob.example.com:8145/foo;tcp 436 From-Path: msrps://df7jal23ls0d.invalid/98cjs;ws 437 Success-Report: no 438 Byte-Range: 1-*/* 439 Message-ID: 87652 440 Content-Type: text/plain 442 Hi Bob, I'm about to send you file.mpeg 443 -------6aef$ 445 F2 200 OK a.example.com -> Alice (transport WSS) 447 MSRP 6aef 200 OK 448 To-Path: msrps://df7jal23ls0d.invalid/98cjs;ws 449 From-Path: msrps://a.example.com:9000/kjfjan;tcp 450 Message-ID: 87652 451 -------6aef$ 453 F3 SEND a.example.com -> Bob (transport TLS) 455 MSRP juh76 SEND 456 To-Path: msrps://bob.example.com:8145/foo;tcp 457 From-Path: msrps://a.example.com:9000/kjfjan;tcp \ 458 msrps://df7jal23ls0d.invalid/98cjs;ws 459 Success-Report: no 460 Byte-Range: 1-*/* 461 Message-ID: 87652 462 Content-Type: text/plain 464 Hi Bob, I'm about to send you file.mpeg 465 -------juh76$ 467 F4 200 OK Bob -> a.example.com (transport TLS) 469 MSRP juh76 200 OK 470 To-Path: msrps://a.example.com:9000/kjfjan;tcp 471 From-Path: msrps://bob.example.com:8145/foo;tcp 472 Message-ID: 87652 473 -------juh76$ 475 8.3. SEND (MSRP Client to MSRP WebSocket Client) 477 Bob (MSRP TLS) a.example.com (MSRP WSS) Alice 478 | | | 479 |SEND F1 | | 480 |---------------------------->| | 481 |200 OK F2 | | 482 |<----------------------------| | 483 | |SEND F3 | 484 | |---------------------------->| 485 | |200 OK F4 | 486 | |<----------------------------| 488 In the same scenario Bob sends an instant message to Alice (session 489 details having been previously negotiated by some other mechanism - 490 such as SDP [RFC4976]). The MSRP WebSocket Server at a.example.com 491 acts as an MSRP relay, routing the message to Alice over secure 492 WebSocket. 494 Message details (note that MSRP does not permit line folding. A "\" 495 in the examples shows a line continuation due to limitations in line 496 length of this document. Neither the backslash nor the extra CRLF is 497 included in the actual request or response): 499 F1 SEND Bob -> a.example.com (transport TLS) 501 MSRP xght6 SEND 502 To-Path: msrps://a.example.com:9000/jui787s2f;tcp \ 503 msrps://df7jal23ls0d.invalid/98cjs;ws 504 From-Path: msrps://bob.example.com:8145/foo;tcp 505 Success-Report: no 506 Byte-Range: 1-*/* 507 Message-ID: 87652 508 Content-Type: text/plain 510 Thanks for the file. 511 -------xght6$ 513 F2 200 OK a.example.com -> Bob (transport TLS) 515 MSRP xght6 200 OK 516 To-Path: msrps://bob.example.com:8145/foo;tcp 517 From-Path: msrps://a.example.com:9000/jui787s2f;tcp 518 Message-ID: 87652 519 -------6aef$ 521 F3 SEND a.example.com -> Alice (transport WSS) 523 MSRP yh67 SEND 524 To-Path: msrps://df7jal23ls0d.invalid/98cjs;ws 525 From-Path: msrps://a.example.com:9000/jui787s2f;tcp \ 526 msrps://bob.example.com:8145/foo;tcp 527 Success-Report: no 528 Byte-Range: 1-*/* 529 Message-ID: 87652 530 Content-Type: text/plain 532 Hi Bob, I'm about to send you file.mpeg 533 -------yh67$ 535 F4 200 OK Bob -> a.example.com (transport TLS) 537 MSRP yh67 200 OK 538 To-Path: msrps://a.example.com:9000/jui787s2f;tcp 539 From-Path: msrps://df7jal23ls0d.invalid/98cjs;ws 540 Message-ID: 87652 541 -------yh67$ 543 8.4. SEND (MSRP WebSocket Client to MSRP WebSocket Client) 545 Alice (MSRP WSS) a.example.com (MSRP WSS) Carol 546 | | | 547 |SEND F1 | | 548 |---------------------------->| | 549 |200 OK F2 | | 550 |<----------------------------| | 551 | |SEND F3 | 552 | |---------------------------->| 553 | |200 OK F4 | 554 | |<----------------------------| 556 In the same scenario Alice sends an instant message to Carol (session 557 details having been previously negotiated by some other mechanism - 558 such as SDP [RFC4976]). The MSRP WebSocket Server at a.example.com 559 acts as an MSRP relay, routing the message to Carol over secure 560 WebSocket. 562 Message details (note that MSRP does not permit line folding. A "\" 563 in the examples shows a line continuation due to limitations in line 564 length of this document. Neither the backslash nor the extra CRLF is 565 included in the actual request or response): 567 F1 SEND Alice -> a.example.com (transport WSS) 569 MSRP kjh6 SEND 570 To-Path: msrps://a.example.com:9000/iwnslt;tcp \ 571 msrps://jk9awp14vj8x.invalid/76qwe;ws 572 From-Path: msrps://df7jal23ls0d.invalid/98cjs;ws 573 Success-Report: no 574 Byte-Range: 1-*/* 575 Message-ID: 87652 576 Content-Type: text/plain 578 Carol, here is the file Bob sent me. 579 -------kjh6$ 581 F2 200 OK a.example.com -> Alice (transport WSS) 583 MSRP kjh6 200 OK 584 To-Path: msrps://df7jal23ls0d.invalid/98cjs;ws 585 From-Path: msrps://a.example.com:9000/iwnslt;tcp 586 Message-ID: 87652 587 -------kjh$ 589 F3 SEND a.example.com -> Carol (transport WSS) 591 MSRP re58 SEND 592 To-Path: msrps://jk9awp14vj8x.invalid/76qwe;ws 593 From-Path: msrps://a.example.com:9000/iwnslt;tcp \ 594 msrps://df7jal23ls0d.invalid/98cjs;ws 595 Success-Report: no 596 Byte-Range: 1-*/* 597 Message-ID: 87652 598 Content-Type: text/plain 600 Carol, here is the file Bob sent me. 601 -------re58$ 603 F4 200 OK Carol -> a.example.com (transport WSS) 605 MSRP re58 200 OK 606 To-Path: msrps://a.example.com:9000/iwnslt;tcp 607 From-Path: msrps://jk9awp14vj8x.invalid/76qwe;ws 608 Message-ID: 87652 609 -------re58$ 611 9. Security Considerations 613 9.1. Secure WebSocket Connection 615 It is recommended that the MSRP traffic transported over a WebSocket 616 communication be protected by using a secure WebSocket connection 617 (using TLS [RFC5246] over TCP). 619 10. IANA Considerations 621 10.1. Registration of the WebSocket MSRP Sub-Protocol 623 This specification requests IANA to register the WebSocket MSRP sub- 624 protocol in the registry of WebSocket sub-protocols with the 625 following data: 627 Subprotocol Identifier: msrp 629 Subprotocol Common Name: WebSocket Transport for MSRP (Message 630 Session Relay Protocol) 632 Subprotocol Definition: TBD, it should point to this document 634 11. Acknowledgements 636 Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and 637 Victor Pascual, the authors of [I-D.ietf-sipcore-sip-websocket] which 638 has inspired this draft. 640 Special thanks to James Wyatt from Crocodile RCS Ltd for helping with 641 the JavaScript MSRP over WebSockets prototyping. 643 12. References 645 12.1. Normative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, March 1997. 650 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 651 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 653 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 654 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 655 September 2007. 657 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 658 Specifications: ABNF", STD 68, RFC 5234, January 2008. 660 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 661 RFC 6455, December 2011. 663 12.2. Informative References 665 [I-D.ietf-sipcore-sip-websocket] 666 Castillo, I., Millan, J., and V. Pascual, "The WebSocket 667 Protocol as a Transport for the Session Initiation 668 Protocol (SIP)", draft-ietf-sipcore-sip-websocket-04 (work 669 in progress), October 2012. 671 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 672 Names", BCP 32, RFC 2606, June 1999. 674 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 675 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 676 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 678 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 679 Leach, P., Luotonen, A., and L. Stewart, "HTTP 680 Authentication: Basic and Digest Access Authentication", 681 RFC 2617, June 1999. 683 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 684 Resource Identifier (URI): Generic Syntax", STD 66, 685 RFC 3986, January 2005. 687 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 688 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 690 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 691 April 2011. 693 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 695 Appendix A. Implementation Guidelines 697 _This section is non-normative._ 699 A.1. MSRP WebSocket Client Considerations 701 The JavaScript stack in web browsers does not have the ability to 702 discover the local transport address used for originating WebSocket 703 connections. Therefore the MSRP WebSocket Client constructs a domain 704 name consisting of a random token followed by the ".invalid" top- 705 level domain name, as stated in [RFC2606], and uses it within its 706 From-Path headers. 708 The From-Path URI provided by MSRP clients which use an MSRP relay 709 is not used for routing MSRP messages, thus it is safe to set a 710 random domain in the hostpart of the From-Path URI. 712 Author's Address 714 Peter Dunkley 715 Crocodile RCS Ltd 716 Forum 3, Parkway 717 Solent Business Park, Whiteley 718 Fareham PO15 7FH 719 United Kingdom 721 Email: peter.dunkley@crocodile-rcs.com