idnits 2.17.00 (12 Aug 2021) /tmp/idnits17672/draft-pd-dispatch-msrp-websocket-15.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 444 has weird spacing: '...otocols a.exa...' == Line 505 has weird spacing: '...otocols a.exa...' == Line 519 has weird spacing: '...horized a.exa...' (Using the creation date from RFC4975, updated by this document, for RFC5378 checks: 2003-05-23) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 15, 2016) is 2098 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) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dispatch Working Group P. Dunkley 3 Internet-Draft G. Llewellyn 4 Updates: 4975, 4976 (if approved) Xura 5 Intended status: Standards Track V. Pascual 6 Expires: February 16, 2017 Oracle 7 G. Salgueiro 8 Ram. Ravindranath 9 Cisco 10 August 15, 2016 12 The WebSocket Protocol as a Transport for the Message Session Relay 13 Protocol (MSRP) 14 draft-pd-dispatch-msrp-websocket-15 16 Abstract 18 The WebSocket protocol enables two-way real-time communication 19 between clients and servers in situations where direct access to TCP 20 and UDP are not available (for example, from within Javascript in a 21 web browser). This document specifies a new WebSocket sub-protocol 22 as a reliable transport mechanism between MSRP (Message Session Relay 23 Protocol) clients and relays to enable usage of MSRP in new 24 scenarios. This document normatively updates RFC 4975 and RFC 4976. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 16, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. WebSocket Protocol Overview . . . . . . . . . . . . . . . . . 4 76 4. The WebSocket MSRP Sub-Protocol . . . . . . . . . . . . . . . 5 77 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4.2. MSRP Encoding . . . . . . . . . . . . . . . . . . . . . . 6 79 5. MSRP WebSocket Transport . . . . . . . . . . . . . . . . . . 6 80 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 5.2. Updates to RFC 4975 . . . . . . . . . . . . . . . . . . . 7 82 5.2.1. MSRP URI Transport Parameter . . . . . . . . . . . . 7 83 5.2.2. SDP Transport Protocol . . . . . . . . . . . . . . . 7 84 5.3. Updates to RFC 4976 . . . . . . . . . . . . . . . . . . . 7 85 5.3.1. AUTH Request Authentication . . . . . . . . . . . . . 7 86 6. Connection Keep-alive . . . . . . . . . . . . . . . . . . . . 8 87 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8 88 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 9 90 8.1.1. WebSocket Authentication . . . . . . . . . . . . . . 9 91 8.1.2. MSRP Authentication . . . . . . . . . . . . . . . . . 10 92 8.2. Example Session: MSRP WebSocket Client to MSRP Client . . 12 93 8.2.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 13 94 8.2.2. SEND (MSRP WebSocket Client to MSRP Client) . . . . . 13 95 8.2.3. SEND (MSRP Client to MSRP WebSocket Client) . . . . . 16 97 8.3. Example Session: Two MSRP WebSocket Clients . . . . . . . 18 98 8.3.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 18 99 8.3.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . 18 100 8.4. Example Session: MSRP WebSocket Client to MSRP Client 101 Using a Relay . . . . . . . . . . . . . . . . . . . . . . 21 102 8.4.1. SDP Exchange . . . . . . . . . . . . . . . . . . . . 21 103 8.4.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . 21 104 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 105 9.1. Kamailio SIP Server . . . . . . . . . . . . . . . . . . . 24 106 9.2. Crocodile MSRP . . . . . . . . . . . . . . . . . . . . . 25 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 109 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 110 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 111 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 112 13.2. Informative References . . . . . . . . . . . . . . . . . 27 113 Appendix A. Implementation Guidelines: MSRP WebSocket Client 114 Considerations . . . . . . . . . . . . . . . . . . . 29 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 117 1. Introduction 119 The WebSocket [RFC6455] protocol enables message exchange between 120 clients and servers on top of a persistent TCP connection (optionally 121 secured with TLS [RFC5246]). The initial protocol handshake makes 122 use of HTTP [RFC7230] semantics, allowing the WebSocket protocol to 123 reuse existing HTTP infrastructure. 125 Modern web browsers include a WebSocket client stack complying with 126 the WebSocket API [WS-API] as specified by the W3C. It is expected 127 that other client applications (those running in personal computers 128 and devices such as smart-phones) will also make a WebSocket client 129 stack available. The specification in this document enables usage of 130 Message Session Relay Protocol [RFC4975] in these scenarios. 132 This specification defines a new WebSocket sub-protocol (as defined 133 in section 1.9 in [RFC6455]) for transporting MSRP messages between a 134 WebSocket client and MSRP relay [RFC4976] containing a WebSocket 135 server, a new transport for MSRP, and procedures for MSRP clients and 136 relays implementing the WebSocket transport. 138 MSRP over WebSocket is well suited for MSRP interactions between 139 clients and servers. Common use cases for MSRP over WebSocket 140 include: 142 o Human-to-machine messaging 143 o Client-to-server data exchange (for example, application control 144 signalling) 146 o Human-to-human messaging where local policy requires 147 authentication and/or logging 149 MSRP-CEMA [RFC6714] is outside of the scope of this document as this 150 document is intended to describe connecting to a WebSocket server 151 that is an MSRP relay. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 2.1. Definitions 161 MSRP WebSocket Client: An MSRP entity capable of opening outbound 162 connections to MSRP relays which are WebSocket servers and 163 communicating using the WebSocket MSRP sub-protocol as defined 164 by this document. 166 MSRP WebSocket Server: An MSRP entity (specifically an MSRP relay 167 [RFC4976]) capable of listening for inbound connections from 168 WebSocket clients and communicating using the WebSocket MSRP 169 sub-protocol as defined by this document. 171 3. WebSocket Protocol Overview 173 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 174 (optionally secured with TLS [RFC5246]) in which both client and 175 server exchange message units in both directions. The protocol 176 defines a connection handshake, WebSocket sub-protocol and extensions 177 negotiation, a frame format for sending application and control data, 178 a masking mechanism, and status codes for indicating disconnection 179 causes. 181 The WebSocket connection handshake is based on HTTP [RFC7230] and 182 utilizes the HTTP GET method with an "Upgrade" request. This is sent 183 by the client and then answered by the server (if the negotiation 184 succeeded) with an HTTP 101 status code. Once the handshake is 185 completed the connection upgrades from HTTP to the WebSocket 186 protocol. This handshake procedure is designed to reuse the existing 187 HTTP infrastructure. During the connection handshake, client and 188 server agree on the application protocol to use on top of the 189 WebSocket transport. Such application protocol (also known as a 190 "WebSocket sub-protocol") defines the format and semantics of the 191 messages exchanged by the endpoints. This could be a custom protocol 192 or a standardized one (such as the WebSocket MSRP sub-protocol 193 defined in this document). Once the HTTP 101 response is processed 194 both client and server reuse the underlying TCP connection for 195 sending WebSocket messages and control frames to each other. Unlike 196 plain HTTP, this connection is persistent and can be used for 197 multiple message exchanges. 199 WebSocket defines message units to be used by applications for the 200 exchange of data, so it provides a message boundary-preserving 201 transport layer. These message units can contain either UTF-8 text 202 or binary data, and can be split into multiple WebSocket text/binary 203 transport frames as needed by the WebSocket stack. 205 The WebSocket API [WS-API] for web browsers only defines callbacks 206 to be invoked upon receipt of an entire message unit, regardless 207 of whether it was received in a single WebSocket frame or split 208 across multiple frames. 210 4. The WebSocket MSRP Sub-Protocol 212 The term WebSocket sub-protocol refers to an application-level 213 protocol layered on top of a WebSocket connection. This document 214 specifies the WebSocket MSRP sub-protocol for carrying MSRP requests 215 and responses through a WebSocket connection. 217 4.1. Handshake 219 The MSRP WebSocket Client and MSRP WebSocket Server negotiate usage 220 of the WebSocket MSRP sub-protocol during the WebSocket handshake 221 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 222 include the value "msrp" in the Sec-WebSocket-Protocol header in its 223 handshake request. The 101 reply from the Server MUST contain "msrp" 224 in its corresponding Sec-WebSocket-Protocol header. 226 Below is an example of a WebSocket handshake in which the Client 227 requests the WebSocket MSRP sub-protocol support from the Server: 229 GET / HTTP/1.1 230 Host: a.example.com 231 Upgrade: websocket 232 Connection: Upgrade 233 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 234 Origin: http://www.example.com 235 Sec-WebSocket-Protocol: msrp 236 Sec-WebSocket-Version: 13 238 The handshake response from the Server accepting the WebSocket MSRP 239 sub-protocol would look as follows: 241 HTTP/1.1 101 Switching Protocols 242 Upgrade: websocket 243 Connection: Upgrade 244 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 245 Sec-WebSocket-Protocol: msrp 247 Once the negotiation has been completed, the WebSocket connection is 248 established and can be used for the transport of MSRP requests and 249 responses. The WebSocket messages transmitted over this connection 250 MUST conform to the negotiated WebSocket sub-protocol. 252 4.2. MSRP Encoding 254 WebSocket messages can be transported in either UTF-8 text frames or 255 binary frames. MSRP [RFC4975] allows both text and binary bodies in 256 MSRP requests. Therefore MSRP WebSocket Clients and Servers MUST 257 accept both text and binary frames. 259 The WebSocket API [WS-API] does not allow developers to choose 260 whether to send UTF-8 text or binary frames, but will not send 261 non-UTF-8 characters in a text frame. The content of text frames 262 MUST be interpreted as binary by WebSocket Clients and Servers. 264 5. MSRP WebSocket Transport 266 5.1. General 268 WebSocket clients cannot receive WebSocket connections initiated by 269 other WebSocket clients or WebSocket servers. This means that it is 270 challenging for an MSRP client to communicate directly with other 271 MSRP clients. Therefore, all MSRP over WebSocket messages MUST be 272 routed via an MSRP WebSocket Server. MSRP traffic transported over 273 WebSockets MUST be protected by using a secure WebSocket connection 274 (using TLS [RFC5246] over TCP). 276 MSRP WebSocket Servers can be used to route MSRP messages between 277 MSRP WebSocket Clients, and between MSRP WebSocket Clients and 278 "normal" MSRP clients and relays. 280 Each MSRP chunk MUST be carried within a single WebSocket message, 281 and a WebSocket message MUST NOT contain more than one MSRP chunk. 283 This simplifies parsing of MSRP messages for both clients and 284 servers. When large messages are sent by non-WebSocket peer, MSRP 285 chunking (as defined in section 5.1 of [RFC4975]) MUST be used by 286 the WebSocket MSRP Servers to split the message into several 287 smaller MSRP chunks. 289 5.2. Updates to RFC 4975 291 5.2.1. MSRP URI Transport Parameter 293 This document defines the value "ws" as the transport parameter value 294 for an MSRP URI [RFC3986] to be contacted using the MSRP WebSocket 295 sub-protocol as transport. 297 The updated augmented BNF (Backus-Naur Form) [RFC5234] for this 298 parameter is the following (the original BNF for this parameter can 299 be found in [RFC4975]): 301 transport = "tcp" / "ws" / 1*ALPHANUM 303 5.2.2. SDP Transport Protocol 305 This document does not define a new SDP transport protocol for MSRP 306 over WebSockets. As all MSRP over WebSocket messages MUST be routed 307 via an MSRP WebSocket Server, MSRP WebSocket Client MUST specify 308 "TCP/TLS/MSRP" protocols in the SDP m-line - that being the protocol 309 used by non-WebSocket clients and between MSRP relays ([RFC4975] 310 section 8.1). 312 The "ws" transport parameter will appear in the endpoint URI in the 313 SDP "path" attribute ([RFC4975] Section 8.2). MSRP was designed with 314 the possibility of new transport bindings in mind ([RFC4975] 315 Section 6) so MSRP implementations are expected to allow unrecognised 316 transports, provided that they do not have to establish a direct 317 connection to the resource described by the URI. 319 5.3. Updates to RFC 4976 321 5.3.1. AUTH Request Authentication 323 The MSRP relay specification [RFC4976] states that AUTH requests MUST 324 be authenticated. This document modifies this requirement to state 325 that all connections between MSRP clients and relays MUST be 326 authenticated. In the case of the MSRP WebSocket Clients there are 327 two possible authentication mechanisms: 329 1. HTTP Digest authentication in AUTH (as per [RFC4976]). 331 2. Cookie-based or HTTP Digest authentication in the WebSocket 332 Handshake (see Section 7). 334 3. Mutual TLS between the WebSocket based MSRP client and the 335 WebSocket server. 337 The AUTH request is a required event when authentication occurs at 338 the WebSocket connection level, since the Use-Path: header required 339 to create the SDP offer is included in the 200 OK response to the 340 AUTH request. 342 6. Connection Keep-alive 344 It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their 345 WebSocket connections open by sending periodic WebSocket "Ping" 346 frames as described in [RFC6455] section 5.5.2. 348 The WebSocket API [WS-API] does not provide a mechanism for 349 applications running in a web browser to control whether or not 350 periodic WebSocket "Ping" frames are sent to the server. The 351 implementation of such a keep alive feature is the decision of 352 each web browser manufacturer and may also depend on the 353 configuration of the web browser. 355 A future WebSocket protocol extension providing a similar keep alive 356 mechanism could also be used. 358 When MSRP WebSocket Clients or Servers cannot use WebSocket "Ping" 359 frames to keep connections open an MSRP implementation MAY use 360 bodiless SEND requests as described in [RFC4975] section 7.1. MSRP 361 WebSocket Clients or Servers MUST be prepared to receive bodiless 362 SEND requests. 364 7. Authentication 366 Prior to sending MSRP requests, an MSRP WebSocket Client connects to 367 an MSRP WebSocket Server and performs the connection handshake. As 368 described in Section 3 the handshake procedure involves a HTTP GET 369 method request from the Client and a response from the Server 370 including an HTTP 101 status code. 372 In order to authorize the WebSocket connection, the MSRP WebSocket 373 Server MAY inspect any HTTP headers present (for example, Cookie 374 [RFC6265], Host [RFC7230], or Origin [RFC6454]) in the HTTP GET 375 request. For many web applications the value of such a Cookie is 376 provided by the web server once the user has authenticated themselves 377 to the web server, which could be done by many existing mechanisms. 378 As an alternative method, the MSRP WebSocket Server could request 379 HTTP authentication by replying to the Client's GET method request 380 with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers 381 this usage in section 4.1: 383 If the status code received from the server is not 101, the 384 WebSocket client stack handles the response per HTTP [RFC7230] 385 procedures, in particular the client might perform authentication 386 if it receives 401 status code. 388 If the HTTP GET request contains an Origin header the MSRP WebSocket 389 Server SHOULD indicate Cross-Origin Resource Sharing [CORS] by adding 390 an Access-Control-Allow-Origin header to the 101 response. 392 Regardless of whether the MSRP WebSocket Server requires 393 authentication during the WebSocket handshake, authentication MAY be 394 requested at the MSRP protocol level by an MSRP Server challenging 395 AUTH requests using a 401 response. Therefore, an MSRP WebSocket 396 Client SHOULD support HTTP Digest [RFC7235] authentication as stated 397 in [RFC4976]. 399 8. Examples 401 8.1. Authentication 403 8.1.1. WebSocket Authentication 405 Alice (MSRP WSS) a.example.com 406 | | 407 |HTTP GET (WS handshake) F1 | 408 |---------------------------->| 409 |101 Switching Protocols F2 | 410 |<----------------------------| 411 | | 412 |AUTH F3 | 413 |---------------------------->| 414 |200 OK F4 | 415 |<----------------------------| 416 | | 418 Alice loads a web page using her web browser and retrieves JavaScript 419 code implementing the WebSocket MSRP sub-protocol defined in this 420 document. The JavaScript code (an MSRP WebSocket Client) establishes 421 a secure WebSocket connection with an MSRP relay (an MSRP WebSocket 422 Server) at a.example.com. Upon WebSocket connection, Alice 423 constructs and sends an MSRP AUTH request. Since the JavaScript 424 stack in a browser has no way to determine the local address from 425 which the WebSocket connection was made, this implementation uses a 426 random ".invalid" domain name for the hostpart of the From-Path URI 427 (see Appendix A). 429 In this example, it is assumed that authentication is performed at 430 the WebSocket layer (not shown), so no challenge is issued for the 431 MSRP AUTH message: 433 F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS) 435 GET / HTTP/1.1 436 Host: a.example.com 437 Upgrade: websocket 438 Connection: Upgrade 439 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 440 Origin: https://www.example.com 441 Sec-WebSocket-Protocol: msrp 442 Sec-WebSocket-Version: 13 444 F2 101 Switching Protocols a.example.com -> Alice (TLS) 446 HTTP/1.1 101 Switching Protocols 447 Upgrade: websocket 448 Connection: Upgrade 449 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 450 Sec-WebSocket-Protocol: msrp 452 F3 AUTH Alice -> a.example.com (transport WSS) 454 MSRP 49fi AUTH 455 To-Path: msrps://alice@a.example.com:443;ws 456 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 457 -------49fi$ 459 F4 200 OK a.example.com -> Alice (transport WSS) 461 MSRP 49fi 200 OK 462 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 463 From-Path: msrps://alice@a.example.com:443;ws 464 Use-Path: msrps://a.example.com:2855/jui787s2f;tcp 465 Expires: 900 466 -------49fi$ 468 8.1.2. MSRP Authentication 469 Alice (MSRP WSS) a.example.com 470 | | 471 |HTTP GET (WS handshake) F1 | 472 |---------------------------->| 473 |101 Switching Protocols F2 | 474 |<----------------------------| 475 | | 476 |AUTH F3 | 477 |---------------------------->| 478 |401 Unauthorized F4 | 479 |<----------------------------| 480 |AUTH F5 | 481 |---------------------------->| 482 |200 OK F6 | 483 |<----------------------------| 484 | | 486 This example uses the same scenario as Section 8.1.1, but with 487 authentication performed at the MSRP layer. 489 Note that MSRP does not permit line folding. A "\" in the examples 490 shows a line continuation due to limitations in line length of this 491 document. Neither the backslash nor the extra CRLF is included in 492 the actual MSRP message. 494 F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS) 496 GET / HTTP/1.1 497 Host: a.example.com 498 Upgrade: websocket 499 Connection: Upgrade 500 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 501 Origin: https://www.example.com 502 Sec-WebSocket-Protocol: msrp 503 Sec-WebSocket-Version: 13 505 F2 101 Switching Protocols a.example.com -> Alice (TLS) 507 HTTP/1.1 101 Switching Protocols 508 Upgrade: websocket 509 Connection: Upgrade 510 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 511 Sec-WebSocket-Protocol: msrp 513 F3 AUTH Alice -> a.example.com (transport WSS) 514 MSRP 4rsxt9nz AUTH 515 To-Path: msrps://alice@a.example.com:443;ws 516 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 517 -------4rsxt9nz$ 519 F4 401 Unauthorized a.example.com -> Alice (transport WSS) 521 MSRP 4rsxt9nz 401 Unauthorized 522 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 523 From-Path: msrps://alice@a.example.com:443;ws 524 WWW-Authenticate: Digest realm="example.com", \ 525 nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", qop="auth" 526 -------4rsxt9nz$ 528 F5 AUTH Alice -> a.example.com (transport WSS) 530 MSRP qy1hsow5 AUTH 531 To-Path: msrps://alice@a.example.com:443;ws 532 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 533 Authorization: Digest username="alice", realm="example.com", \ 534 nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", \ 535 uri="msrps://alice@a.example.com:443;ws", \ 536 response="5011d0d58fe975e0d0cdc007ae26f4b7", \ 537 qop=auth, cnonce="zic5ml401prb", nc=00000001 538 -------qy1hsow5$ 540 F6 200 OK a.example.com -> Alice (transport WSS) 542 MSRP qy1hsow5 200 OK 543 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 544 From-Path: msrps://alice@a.example.com:443;ws 545 Use-Path: msrps://a.example.com:2855/jui787s2f;tcp 546 Expires: 900 547 -------qy1hsow5$ 549 8.2. Example Session: MSRP WebSocket Client to MSRP Client 551 The following sub-sections show various message exchanges occuring 552 during the course of an MSRP session between a WebSocket client and a 553 non-WebSocket client. 555 8.2.1. SDP Exchange 557 The following example shows SDP that could be included in a SIP 558 message to set up an MSRP session between Alice and Bob where Alice 559 uses a WebSocket MSRP relay, and Bob uses a traditional MSRP client 560 without a relay. 562 A "\" in the examples shows a line continuation due to limitations in 563 line length of this document. Neither the backslash nor the extra 564 CRLF is included in the actual SDP. 566 Alice makes an offer with a path including the relay (having already 567 successfully authenticated with the relay): 569 c=IN IP4 a.example.com 570 m=message 1234 TCP/TLS/MSRP * 571 a=accept-types:message/cpim text/plain text/html 572 a=path:msrps://a.example.com:2855/jui787s2f;tcp \ 573 msrps://df7jal23ls0d.invalid:2855/98cjs;ws 575 In this offer, Alice wishes to receive MSRP messages via the relay at 576 a.example.com. She wants to use TLS as the transport for the MSRP 577 session (beyond the relay). She can accept message/cpim, text/plain, 578 and text/html message bodies in SEND requests. 580 Bob's answer to this offer could look like: 582 c=IN IP4 bob.example.com 583 m=message 1234 TCP/TLS/MSRP * 584 a=accept-types:message/cpim text/plain 585 a=path:msrps://bob.example.com:49154/foo;tcp 587 Here Bob wishes to receive the MSRP messages at bob.example.com. He 588 can accept only message/cpim and text/plain message bodies in SEND 589 requests and has rejected the text/html content offered by Alice. He 590 does not need a relay to set up the MSRP session. 592 8.2.2. SEND (MSRP WebSocket Client to MSRP Client) 593 Alice (MSRP WSS) a.example.com (MSRP TLS) Bob 594 | | | 595 |SEND F1 | | 596 |---------------------------->| | 597 |200 OK F2 | | 598 |<----------------------------| | 599 | |SEND F3 | 600 | |---------------------------->| 601 | |200 OK F4 | 602 | |<----------------------------| 604 Later in the session, Alice sends an instant message to Bob. The 605 MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing 606 the message to Bob over TLS. 608 Message details (A "\" in the examples shows a line continuation due 609 to limitations in line length of this document. Neither the 610 backslash nor the extra CRLF is included in the actual request or 611 response): 613 F1 SEND Alice -> a.example.com (transport WSS) 615 MSRP 6aef SEND 616 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 617 msrps://bob.example.com:49154/foo;tcp 618 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 619 Success-Report: no 620 Byte-Range: 1-*/* 621 Message-ID: 87652 622 Content-Type: text/plain 624 Hi Bob, I'm about to send you file.mpeg 625 -------6aef$ 627 F2 200 OK a.example.com -> Alice (transport WSS) 629 MSRP 6aef 200 OK 630 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 631 From-Path: msrps://a.example.com:2855/jui787s2f;tcp 632 -------6aef$ 634 F3 SEND a.example.com -> Bob (transport TLS) 636 MSRP juh76 SEND 637 To-Path: msrps://bob.example.com:49154/foo;tcp 638 From-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 639 msrps://df7jal23ls0d.invalid:2855/98cjs;ws 640 Success-Report: no 641 Byte-Range: 1-*/* 642 Message-ID: 87652 643 Content-Type: text/plain 645 Hi Bob, I'm about to send you file.mpeg 646 -------juh76$ 648 F4 200 OK Bob -> a.example.com (transport TLS) 650 MSRP juh76 200 OK 651 To-Path: msrps://a.example.com:2855/jui787s2f;tcp 652 From-Path: msrps://bob.example.com:49154/foo;tcp 653 -------juh76$ 655 8.2.3. SEND (MSRP Client to MSRP WebSocket Client) 657 Bob (MSRP TLS) a.example.com (MSRP WSS) Alice 658 | | | 659 |SEND F1 | | 660 |---------------------------->| | 661 |200 OK F2 | | 662 |<----------------------------| | 663 | |SEND F3 | 664 | |---------------------------->| 665 | |200 OK F4 | 666 | |<----------------------------| 668 Later in the session, Bob sends an instant message to Alice. The 669 MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing 670 the message to Alice over secure WebSocket. 672 Message details (A "\" in the examples shows a line continuation due 673 to limitations in line length of this document. Neither the 674 backslash nor the extra CRLF is included in the actual request or 675 response): 677 F1 SEND Bob -> a.example.com (transport TLS) 679 MSRP xght6 SEND 680 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 681 msrps://df7jal23ls0d.invalid:2855/98cjs;ws 682 From-Path: msrps://bob.example.com:49154/foo;tcp 683 Success-Report: no 684 Byte-Range: 1-*/* 685 Message-ID: 87652 686 Content-Type: text/plain 688 Thanks for the file. 689 -------xght6$ 691 F2 200 OK a.example.com -> Bob (transport TLS) 693 MSRP xght6 200 OK 694 To-Path: msrps://bob.example.com:49154/foo;tcp 695 From-Path: msrps://a.example.com:2855/jui787s2f;tcp 696 -------xght6$ 698 F3 SEND a.example.com -> Alice (transport WSS) 700 MSRP yh67 SEND 701 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 702 From-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 703 msrps://bob.example.com:49154/foo;tcp 704 Success-Report: no 705 Byte-Range: 1-*/* 706 Message-ID: 87652 707 Content-Type: text/plain 709 Thanks for the file. 710 -------yh67$ 712 F4 200 OK Alice -> a.example.com (transport WSS) 714 MSRP yh67 200 OK 715 To-Path: msrps://a.example.com:2855/jui787s2f;tcp 716 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 717 -------yh67$ 719 8.3. Example Session: Two MSRP WebSocket Clients 721 The following sub-sections show various message exchanges occuring 722 during the course of an MSRP session between two WebSocket clients. 724 8.3.1. SDP Exchange 726 The following example shows SDP that could be included in a SIP 727 message to set up an MSRP session between Alice and Carol where both 728 of them are using the same WebSocket MSRP relay. 730 Alice makes an offer with a path including the relay (having already 731 successfully authenticated with the relay): 733 c=IN IP4 a.example.com 734 m=message 1234 TCP/TLS/MSRP * 735 a=accept-types:message/cpim text/plain text/html 736 a=path:msrps://a.example.com:2855/jui787s2f;tcp \ 737 msrps://df7jal23ls0d.invalid:2855/98cjs;ws 739 In this offer, Alice wishes to receive MSRP messages via the relay at 740 a.example.com. She wants to use TLS as the transport for the MSRP 741 session (beyond the relay). She can accept message/cpim, text/plain, 742 and text/html message bodies in SEND requests. 744 Carol's answer to this offer could look like: 746 c=IN IP4 a.example.com 747 m=message 1234 TCP/TLS/MSRP * 748 a=accept-types:message/cpim text/plain 749 a=path:msrps://a.example.com:2855/iwnslt;tcp \ 750 msrps://jk9awp14vj8x.invalid:2855/76qwe;ws 752 Here Carol also wishes to receive the MSRP messages via 753 a.example.com. She can accept only message/cpim and text/plain 754 message bodies in SEND requests and has rejected the text/html 755 content offered by Alice. 757 8.3.2. SEND 758 Alice (MSRP WSS) a.example.com (MSRP WSS) Carol 759 | | | 760 |SEND F1 | | 761 |---------------------------->| | 762 |200 OK F2 | | 763 |<----------------------------| | 764 | |SEND F3 | 765 | |---------------------------->| 766 | |200 OK F4 | 767 | |<----------------------------| 769 Later in the session Alice sends an instant message to Carol. The 770 MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing 771 the message to Carol over secure WebSocket. 773 In this example both Alice and Carol are using MSRP WebSocket 774 Clients, and the same MSRP WebSocket Server. This means that 775 a.example.com will appear twice in the To-Path in F1. a.example.com 776 can either handle this internally or loop the MSRP SEND request back 777 to itself as if it were two, separate, MSRP relays. 779 Message details (A "\" in the examples shows a line continuation due 780 to limitations in line length of this document. Neither the 781 backslash nor the extra CRLF is included in the actual request or 782 response): 784 F1 SEND Alice -> a.example.com (transport WSS) 786 MSRP kjh6 SEND 787 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 788 msrps://a.example.com:2855/iwnslt;tcp \ 789 msrps://jk9awp14vj8x.invalid:2855/76qwe;ws 790 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 791 Success-Report: no 792 Byte-Range: 1-*/* 793 Message-ID: 87652 794 Content-Type: text/plain 796 Carol, I sent that file to Bob. 797 -------kjh6$ 799 F2 200 OK a.example.com -> Alice (transport WSS) 801 MSRP kjh6 200 OK 802 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 803 From-Path: msrps://a.example.com:2855/jui787s2f;tcp 804 -------kjh6$ 806 F3 SEND a.example.com -> Carol (transport WSS) 808 MSRP re58 SEND 809 To-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws 810 From-Path: msrps://a.example.com:2855/iwnslt;tcp \ 811 msrps://a.example.com:2855/jui787s2f;tcp \ 812 msrps://df7jal23ls0d.invalid/98cjs;ws 813 Success-Report: no 814 Byte-Range: 1-*/* 815 Message-ID: 87652 816 Content-Type: text/plain 818 Carol, I sent that file to Bob. 819 -------re58$ 821 F4 200 OK Carol -> a.example.com (transport WSS) 823 MSRP re58 200 OK 824 To-Path: msrps://a.example.com:2855/iwnslt;tcp 825 From-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws 826 -------re58$ 828 8.4. Example Session: MSRP WebSocket Client to MSRP Client Using a 829 Relay 831 The following sub-sections show various message exchanges occuring 832 during the course of an MSRP session between a WebSocket client and a 833 non-WebSocket client, where the latter is also using an MSRP relay. 835 8.4.1. SDP Exchange 837 The following example shows SDP that could be included in a SIP 838 message to set up an MSRP session between Alice and Bob where Alice 839 uses a WebSocket MSRP relay, and Bob uses a traditional MSRP client 840 with a separate relay. 842 Alice makes an offer with a path including the relay (having already 843 successfully authenticated with the relay): 845 c=IN IP4 a.example.com 846 m=message 1234 TCP/TLS/MSRP * 847 a=accept-types:message/cpim text/plain text/html 848 a=path:msrps://a.example.com:2855/jui787s2f;tcp \ 849 msrps://df7jal23ls0d.invalid:2855/98cjs;ws 851 In this offer, Alice wishes to receive MSRP messages via the relay at 852 a.example.com. She wants to use TLS as the transport for the MSRP 853 session (beyond the relay). She can accept message/cpim, text/plain, 854 and text/html message bodies in SEND requests. 856 Bob's answer to this offer could look like: 858 c=IN IP4 bob.example.com 859 m=message 1234 TCP/TLS/MSRP * 860 a=accept-types:message/cpim text/plain 861 a=path:msrps://relay.example.net:2855/kwvin5f;tcp \ 862 msrps://bob.example.com:49154/foo;tcp 864 Here Bob wishes to receive the MSRP messages via the relay at 865 relay.example.net. He can accept only message/cpim and text/plain 866 message bodies in SEND requests and has rejected the text/html 867 content offered by Alice. 869 8.4.2. SEND 870 Alice (MSRP WSS) a.example.com (MSRP) relay.example.net (MSRP) Bob 871 | | | | 872 |SEND F1 | | | 873 |--------------------->| | | 874 |200 OK F2 | | | 875 |<---------------------| | | 876 | |SEND F3 | | 877 | |---------------------->| | 878 | |200 OK F4 | | 879 | |<----------------------| | 880 | | |SEND F5 | 881 | | |------------------->| 882 | | |200 OK F6 | 883 | | |<-------------------| 885 Later in the session Alice sends an instant message to Bob. The MSRP 886 WebSocket Server at a.example.com acts as an MSRP relay, routing the 887 message to Bob via his relay, relay.example.net. 889 Message details (A "\" in the examples shows a line continuation due 890 to limitations in line length of this document. Neither the 891 backslash nor the extra CRLF is included in the actual request or 892 response): 894 F1 SEND Alice -> a.example.com (transport WSS) 896 MSRP Ycwt SEND 897 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 898 msrps://relay.example.net:2855/kwvin5f;tcp \ 899 msrps://bob.example.com:49154/foo;tcp 900 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 901 Success-Report: no 902 Byte-Range: 1-*/* 903 Message-ID: 87652 904 Content-Type: text/plain 906 Bob, that was the wrong file - don't watch it! 907 -------Ycwt$ 909 F2 200 OK a.example.com -> Alice (transport WSS) 911 MSRP Ycwt 200 OK 912 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws 913 From-Path: msrps://a.example.com:2855/jui787s2f;tcp 914 -------Ycwt$ 915 F3 SEND a.example.com -> relay.example.net (transport TLS) 917 MSRP 13GA SEND 918 To-Path: msrps://relay.example.net:2855/kwvin5f;tcp \ 919 msrps://bob.example.com:49154/foo;tcp 920 From-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 921 msrps://df7jal23ls0d.invalid/98cjs;ws 922 Success-Report: no 923 Byte-Range: 1-*/* 924 Message-ID: 87652 925 Content-Type: text/plain 927 Bob, that was the wrong file - don't watch it! 928 -------13GA$ 930 F4 200 OK relay.example.net -> a.example.com (transport TLS) 932 MSRP 13GA 200 OK 933 To-Path: msrps://a.example.com:2855/iwnslt;tcp 934 From-Path: msrps://relay.example.net:2855/kwvin5f;tcp 935 -------13GA$ 937 F5 SEND relay.example.net -> bob.example.com (transport TLS) 939 MSRP kXeg SEND 940 To-Path: msrps://bob.example.com:49154/foo;tcp 941 From-Path: msrps://relay.example.net:2855/kwvin5f;tcp \ 942 msrps://a.example.com:2855/jui787s2f;tcp \ 943 msrps://df7jal23ls0d.invalid/98cjs;ws 944 Success-Report: no 945 Byte-Range: 1-*/* 946 Message-ID: 87652 947 Content-Type: text/plain 949 Bob, that was the wrong file - don't watch it! 950 -------kXeg$ 952 F6 200 OK bob.example.com -> relay.example.net (transport TLS) 954 MSRP kXeg 200 OK 955 To-Path: msrps://relay.example.net:2855/kwvin5f;tcp 956 From-Path: msrps://bob.example.com:49154/foo;tcp 957 -------kXeg$ 959 9. Implementation Status 961 Note to RFC Editor: Please remove this section and the reference to 962 [RFC6982] before publication. 964 This section records the status of known implementations of the 965 protocol defined by this specification at the time of posting of this 966 Internet-Draft, and is based on a proposal described in [RFC6982]. 967 The description of implementations in this section is intended to 968 assist the IETF in its decision processes in progressing drafts to 969 RFCs. Please note that the listing of any individual implementation 970 here does not imply endorsement by the IETF. Furthermore, no effort 971 has been spent to verify the information presented here that was 972 supplied by IETF contributors. This is not intended as, and must not 973 be construed to be, a catalog of available implementations or their 974 features. Readers are advised to note that other implementations may 975 exist. 977 According to [RFC6982], "this will allow reviewers and working groups 978 to assign due consideration to documents that have the benefit of 979 running code, which may serve as evidence of valuable experimentation 980 and feedback that have made the implemented protocols more mature. 981 It is up to the individual working groups to use this information as 982 they see fit". 984 9.1. Kamailio SIP Server 986 Organization: Kamailio 988 Name: Kamailio v4.0.0 (4.0.0 http://www.kamailio.org/w/kamailio- 989 v4-0-0-release-notes/) 991 Description: Kamailio (former OpenSER) is an Open Source SIP 992 Server, able to handle thousands of call setups per second. 993 (http://www.kamailio.org) 995 Level of maturity: Beta 997 Coverage: This module implements a WebSocket (RFC 6455) server and 998 provides connection establishment (handshaking), management 999 (including connection keep-alive), and framing for the SIP and 1000 MSRP WebSocket sub-protocols (draft-ietf-sipcore-sip-websocket and 1001 draft-pd-dispatch-msrp-websocket). The module supports WebSockets 1002 (ws) and secure WebSockets (wss). 1004 Licensing: Open Source GPLv2 1006 Contact: http://www.kamailio.org/w/contact-us/ 1007 URL: http://git.sip-router.org/cgi- 1008 bin/gitweb.cgi?p=kamailio;a=tree;f=modules/ 1009 websocket;h=e75c6cd28493f812a955eeff9e64905aee01bcbf;hb=HEAD 1011 http://git.sip-router.org/cgi- 1012 bin/gitweb.cgi?p=kamailio;a=tree;f=modules/ 1013 msrp;h=0ffaeb57fb43a4d429680209262ad847f7ce6074;hb=HEAD 1015 9.2. Crocodile MSRP 1017 Organization: Crocodile RCS Ltd. 1019 Name: Crocodile MSRP (https://github.com/crocodilertc/crocodile- 1020 msrp) 1022 Description: Crocodile MSRP is a Javascript MSRP over WebSocket 1023 stack. 1025 Level of maturity: Beta 1027 Coverage: Open source client implementation of draft-pd-dispatch- 1028 msrp-websocket. 1030 Licensing: Released under the MIT license 1031 (http://www.opensource.org/licenses/mit-license.php). 1033 Contact: Gavin Llewellyn (gavin.llewellyn@crocodilertc.net) 1035 URL: https://github.com/crocodilertc/crocodile-msrp 1037 10. Security Considerations 1039 MSRP traffic transported over WebSockets MUST be protected by using a 1040 secure WebSocket connection (using TLS [RFC5246] over TCP). 1042 When establishing a connection using MSRP over secure WebSockets, the 1043 client MUST authenticate the server using the server's certificate 1044 according to the WebSocket validation procedure in [RFC6455]. 1046 Any security considerations specific to the WebSocket protocol is 1047 detailed in the relevant specification([RFC6455] and is considered 1048 outside the scope of this document. The certificate name matching, 1049 described by [RFC6455], and cryptosuite selection will be handled by 1050 the browser, and the browser's procedures will supersede those 1051 specified in [RFC4975]. 1053 Since the TLS session is always terminated at the MSRP WebSocket 1054 server and the WebSocket server can see the plain text, the MSRP 1055 client (browser) SHOULD NOT indicate end-to-end security to user. 1057 TLS, as used in this document, should follow the best current 1058 practices defined in [RFC7525]. 1060 11. IANA Considerations 1062 This specification requests IANA to register the WebSocket MSRP sub- 1063 protocol in the "WebSocket Subprotocol Name Registry" with the 1064 following data: 1066 Subprotocol Identifier: msrp 1068 Subprotocol Common Name: WebSocket Transport for MSRP (Message 1069 Session Relay Protocol) 1071 Subprotocol Definition: TBD, it should point to this document 1073 Reference: TBD, it should point to this document 1075 12. Acknowledgements 1077 Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and 1078 Victor Pascual, the authors of [RFC7118] which has inspired this 1079 draft. 1081 Additional thanks to Inaki Baz Castillo who pointed out that "web- 1082 browser" shouldn't be used all the time as this specification should 1083 be valid for smartphones and apps other than browsers and suggested 1084 clarifications to the SDP handling for MSRP over WebSocket. 1086 Special thanks to James Wyatt from Crocodile RCS Ltd for helping with 1087 the JavaScript MSRP over WebSockets prototyping. 1089 Special thanks to Anton Roman who has contributed to this draft. 1091 Thanks to Saul Ibarra Corretge for suggesting that the existing MSRP 1092 keep alive mechanism may be used when WebSocket pings are not 1093 available. 1095 Thanks to Ben Cambell, Inaki Baz Castillo, Keith Drage, Olle 1096 Johansson, Christer Holmberg for their thoughtful discussion comments 1097 and review feedback that led to the improvement of this document. 1098 Special thanks to Mary Barnes for both her technical review and for 1099 offering to act as document shepherd. Thanks also to Stephen 1100 Farrell, Alissa Cooper, Mirja Kuehlewind, Allison Mankin, Alexey 1101 Melnikov and Kathleen Moriarty for their review comments. 1103 13. References 1105 13.1. Normative References 1107 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1108 Requirement Levels", BCP 14, RFC 2119, 1109 DOI 10.17487/RFC2119, March 1997, 1110 . 1112 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., 1113 "The Message Session Relay Protocol (MSRP)", RFC 4975, 1114 DOI 10.17487/RFC4975, September 2007, 1115 . 1117 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 1118 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 1119 DOI 10.17487/RFC4976, September 2007, 1120 . 1122 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1123 Specifications: ABNF", STD 68, RFC 5234, 1124 DOI 10.17487/RFC5234, January 2008, 1125 . 1127 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1128 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1129 . 1131 13.2. Informative References 1133 [CORS] W3C and A. van Kesteren, Ed., "Cross-Origin Resource 1134 Sharing", January 2013. 1136 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 1137 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 1138 . 1140 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1141 Resource Identifier (URI): Generic Syntax", STD 66, 1142 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1143 . 1145 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1146 (TLS) Protocol Version 1.2", RFC 5246, 1147 DOI 10.17487/RFC5246, August 2008, 1148 . 1150 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1151 DOI 10.17487/RFC6265, April 2011, 1152 . 1154 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1155 DOI 10.17487/RFC6454, December 2011, 1156 . 1158 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 1159 Establishment for Media Anchoring (CEMA) for the Message 1160 Session Relay Protocol (MSRP)", RFC 6714, 1161 DOI 10.17487/RFC6714, August 2012, 1162 . 1164 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1165 Code: The Implementation Status Section", RFC 6982, 1166 DOI 10.17487/RFC6982, July 2013, 1167 . 1169 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 1170 "The WebSocket Protocol as a Transport for the Session 1171 Initiation Protocol (SIP)", RFC 7118, 1172 DOI 10.17487/RFC7118, January 2014, 1173 . 1175 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1176 Protocol (HTTP/1.1): Message Syntax and Routing", 1177 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1178 . 1180 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1181 Protocol (HTTP/1.1): Authentication", RFC 7235, 1182 DOI 10.17487/RFC7235, June 2014, 1183 . 1185 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1186 "Recommendations for Secure Use of Transport Layer 1187 Security (TLS) and Datagram Transport Layer Security 1188 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1189 2015, . 1191 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", September 1192 2012. 1194 Appendix A. Implementation Guidelines: MSRP WebSocket Client 1195 Considerations 1197 The JavaScript stack in web browsers does not have the ability to 1198 discover the local transport address used for originating WebSocket 1199 connections. Therefore the MSRP WebSocket Client constructs a domain 1200 name consisting of a random token followed by the ".invalid" top- 1201 level domain name, as stated in [RFC2606], and uses it within its 1202 From-Path headers. 1204 The From-Path URI provided by MSRP clients which use an MSRP relay 1205 is not used for routing MSRP messages, thus it is safe to set a 1206 random domain in the hostpart of the From-Path URI. 1208 Authors' Addresses 1210 Peter Dunkley 1211 Xura 1212 Lancaster Court 1213 8 Barnes Wallis Road 1214 Fareham PO15 5TU 1215 United Kingdom 1217 Email: peter.dunkley@xura.com 1219 Gavin Llewellyn 1220 Xura 1221 Lancaster Court 1222 8 Barnes Wallis Road 1223 Fareham PO15 5TU 1224 United Kingdom 1226 Email: gavin.llewellyn@xura.com 1228 Victor Pascual 1229 Oracle 1231 Email: victor.pascual.avila@oracle.com 1232 Gonzalo Salgueiro 1233 Cisco Systems, Inc. 1234 7200-12 Kit Creek Road 1235 Research Triangle Park, NC 27709 1236 US 1238 Email: gsalguei@cisco.com 1240 Ram Mohan Ravindranath 1241 Cisco Systems, Inc. 1243 Email: rmohanr@cisco.com