Skip to main content

The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
draft-pd-msrp-websocket-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Peter Dunkley
Last updated 2012-10-11
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-pd-msrp-websocket-00
Network Working Group                                         P. Dunkley
Internet-Draft                                         Crocodile RCS Ltd
Updates: 4975, 4976 (if approved)                       October 11, 2012
Intended status: Informational
Expires: April 14, 2013

  The WebSocket Protocol as a Transport for the Message Session Relay
                            Protocol (MSRP)
                       draft-pd-msrp-websocket-00

Abstract

   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 14, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Dunkley                  Expires April 14, 2013                 [Page 1]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The WebSocket Protocol . . . . . . . . . . . . . . . . . . . .  4
   4.  The WebSocket MSRP Sub-Protocol  . . . . . . . . . . . . . . .  4
     4.1.  Handshake  . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  MSRP encoding  . . . . . . . . . . . . . . . . . . . . . .  5
   5.  MSRP WebSocket Transport . . . . . . . . . . . . . . . . . . .  5
     5.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Updates to RFC 4975  . . . . . . . . . . . . . . . . . . .  6
       5.2.1.  MSRP URI Transport Parameter . . . . . . . . . . . . .  6
       5.2.2.  SDP Transport Protocol . . . . . . . . . . . . . . . .  6
     5.3.  Updates to RFC 4976  . . . . . . . . . . . . . . . . . . .  7
       5.3.1.  AUTH Request Authentication  . . . . . . . . . . . . .  7
       5.3.2.  Use of TLS . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Connection Keep Alive  . . . . . . . . . . . . . . . . . . . .  7
   7.  Authentication . . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  AUTH . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.2.  SEND (MSRP WebSocket Client to MSRP Client)  . . . . . . . 10
     8.3.  SEND (MSRP Client to MSRP WebSocket Client)  . . . . . . . 13
     8.4.  SEND (MSRP WebSocket Client to MSRP WebSocket Client)  . . 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
     9.1.  Secure WebSocket Connection  . . . . . . . . . . . . . . . 17
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Registration of the WebSocket MSRP Sub-Protocol  . . . . . 17
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     12.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Implementation Guidelines . . . . . . . . . . . . . . 18
     A.1.  MSRP WebSocket Client Considerations . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19

Dunkley                  Expires April 14, 2013                 [Page 2]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

1.  Introduction

   The WebSocket [RFC6455] protocol enables message exchange between
   clients and servers on top of a persistent TCP connection (optionally
   secured with TLS [RFC5246]).  The initial protocol handshake makes
   use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to
   reuse existing HTTP infrastructure.

   Modern web browsers include a WebSocket client stack complying with
   the WebSocket API [WS-API] as specified by the W3C. It is expected
   that other client applications (those running in personal computers
   and devices such as smart-phones) will also make a WebSocket client
   stack available.  The specification in this document enables usage of
   MSRP in these scenarios.

   This specification defines a new WebSocket sub-protocol (as defined
   in section 1.9 in [RFC6455]) for transporting MSRP messages between a
   WebSocket client and MSRP relay [RFC4976] containing a WebSocket
   server, a new transport for MSRP, and procedures for MSRP clients and
   relays implementing the WebSocket transport.

2.  Terminology

   All diagrams, examples, and notes in this specification are non-
   normative, as are all sections explicitly marked non-normative.
   Everything else in this specification is normative.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.1.  Definitions

   MSRP WebSocket Client:  An MSRP entity capable of opening outbound
         connections to MSRP relays which are WebSocket servers and
         communicating using the WebSocket MSRP sub-protocol as defined
         by this document.

   MSRP WebSocket Server:  An MSRP entity (specifically an MSRP relay)
         capable of listening for inbound connections from WebSocket
         clients and communicating using the WebSocket MSRP sub-protocol
         as defined by this document.

Dunkley                  Expires April 14, 2013                 [Page 3]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

3.  The WebSocket Protocol

   _This section is non-normative._

   The WebSocket protocol [RFC6455] is a transport layer on top of TCP
   (optionally secured with TLS [RFC5246]) in which both client and
   server exchange message units in both directions.  The protocol
   defines a connection handshake, WebSocket sub-protocol and extensions
   negotiation, a frame format for sending application and control data,
   a masking mechanism, and status codes for indicating disconnection
   causes.

   The WebSocket connection handshake is based on HTTP [RFC2616] and
   utilizes the HTTP GET method with an "Upgrade" request.  This is sent
   by the client and then answered by the server (if the negotiation
   succeeded) with an HTTP 101 status code.  Once the handshake is
   completed the connection upgrades from HTTP to the WebSocket
   protocol.  This handshake procedure is designed to reuse the existing
   HTTP infrastructure.  During the connection handshake, client and
   server agree on the application protocol to use on top of the
   WebSocket transport.  Such application protocol (also known as a
   "WebSocket sub-protocol") defines the format and semantics of the
   messages exchanged by the endpoints.  This could be a custom protocol
   or a standardized one (such as the WebSocket MSRP sub-protocol
   defined in this document).  Once the HTTP 101 response is processed
   both client and server reuse the underlying TCP connection for
   sending WebSocket messages and control frames to each other.  Unlike
   plain HTTP, this connection is persistent and can be used for
   multiple message exchanges.

   WebSocket defines message units to be used by applications for the
   exchange of data, so it provides a message boundary-preserving
   transport layer.  These message units can contain either UTF-8 text
   or binary data, and can be split into multiple WebSocket text/binary
   transport frames as needed by the WebSocket stack.

      The WebSocket API [WS-API] for web browsers only defines callbacks
      to be invoked upon receipt of an entire message unit, regardless
      of whether it was received in a single WebSocket frame or split
      across multiple frames.

4.  The WebSocket MSRP Sub-Protocol

   The term WebSocket sub-protocol refers to an application-level
   protocol layered on top of a WebSocket connection.  This document
   specifies the WebSocket MSRP sub-protocol for carrying MSRP requests
   and responses through a WebSocket connection.

Dunkley                  Expires April 14, 2013                 [Page 4]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

4.1.  Handshake

   The MSRP WebSocket Client and MSRP WebSocket Server negotiate usage
   of the WebSocket MSRP sub-protocol during the WebSocket handshake
   procedure as defined in section 1.3 of [RFC6455].  The Client MUST
   include the value "msrp" in the Sec-WebSocket-Protocol header in its
   handshake request.  The 101 reply from the Server MUST contain "msrp"
   in its corresponding Sec-WebSocket-Protocol header.

   Below is an example of a WebSocket handshake in which the Client
   requests the WebSocket MSRP sub-protocol support from the Server:

     GET / HTTP/1.1
     Host: a.example.com
     Upgrade: websocket
     Connection: Upgrade
     Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
     Origin: http://www.example.com
     Sec-WebSocket-Protocol: msrp
     Sec-WebSocket-Version: 13

   The handshake response from the Server accepting the WebSocket MSRP
   sub-protocol would look as follows:

     HTTP/1.1 101 Switching Protocols
     Upgrade: websocket
     Connection: Upgrade
     Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
     Sec-WebSocket-Protocol: msrp

   Once the negotiation has been completed, the WebSocket connection is
   established and can be used for the transport of MSRP requests and
   responses.  The WebSocket messages transmitted over this connection
   MUST conform to the negotiated WebSocket sub-protocol.

4.2.  MSRP encoding

   WebSocket messages can be transported in either UTF-8 text frames or
   binary frames.  MSRP [RFC4975] allows both text and binary bodies in
   MSRP requests.  Therefore MSRP WebSocket Clients and Servers MUST
   accept both text and binary frames.

5.  MSRP WebSocket Transport

Dunkley                  Expires April 14, 2013                 [Page 5]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

5.1.  General

   Web-browsers are WebSocket clients and cannot receive WebSocket
   connections initiated by other clients.  This means that it is
   impossible for a JavaScript MSRP client to communicate directly with
   other MSRP clients.  Therefore, all MSRP over WebSocket messages MUST
   be routed via an MSRP relay [RFC4976].

   MSRP WebSocket Servers can be used to route MSRP messages between
   MSRP WebSocket Clients, and between MSRP WebSocket Clients and
   "normal" MSRP clients and relays.

   Each MSRP message MUST be carried within a single WebSocket message,
   and a WebSocket message MUST NOT contain more than one MSRP message.

      This simplifies parsing of MSRP messages for both clients and
      servers.  When large messages are sent MSRP chunking (as defined
      in section 5.1 of [RFC4975]) MUST be used to split the message
      into several smaller MSRP messages.

5.2.  Updates to RFC 4975

5.2.1.  MSRP URI Transport Parameter

   This document defines the value "ws" as the transport parameter value
   for an MSRP URI [RFC3986] to be contacted using the MSRP WebSocket
   sub-protocol as transport.

   The updated augmented BNF (Backus-Naur Form) [RFC5234]for this
   parameter is the following (the original BNF for this parameter can
   be found in [RFC4975]):

     transport  =  "tcp" / "ws" / 1*ALPHANUM

5.2.2.  SDP Transport Protocol

   This document does not define a new SDP transport protocol for MSRP
   over WebSockets.  Adding a new SDP transport protocol may cause
   problems with parsers in existing, non-WebSocket, MSRP clients.
   Further, as all MSRP over WebSocket messages MUST be routed via an
   MSRP WebSocket Server it is acceptable for an MSRP WebSocket Client
   to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in SDP - that
   being the protocol used by non-WebSocket clients and between MSRP
   relays.

Dunkley                  Expires April 14, 2013                 [Page 6]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

5.3.  Updates to RFC 4976

5.3.1.  AUTH Request Authentication

   The MSRP relay specification [RFC4976] states that AUTH requests MUST
   be authenticated.  This document modifies this requirement to state
   that all connections between MSRP clients and relays MUST be
   authenticated.  In the case of the MSRP WebSocket Clients there are
   two possible authentication mechanisms:

   1.  HTTP Digest authentication in AUTH (as per [RFC4976]).

   2.  Cookie-based or HTTP Digest authentication in the WebSocket
       Handshake (see Section 7).

5.3.2.  Use of TLS

   The MSRP relay specification [RFC4976] mandates the use of TLS
   between MSRP clients and MSRP relays, and specifies the mechanisms
   that must be used for TLS authentication.  This document downgrades
   the MUSTs with respect to TLS to SHOULDs when using the MSRP
   WebSocket sub-protocol as transport.  Connections between MSRP
   WebSocket Clients and Servers SHOULD use secure WebSocket
   connections, but MAY use insecure WebSocket connections.  As the
   secure WebSocket connections are negotiated between the web-browser
   and the WebSocket server an MSRP WebSocket Client has no knowledge
   of, or control over, the mechanisms used for TLS authentication.

6.  Connection Keep Alive

   _This section is non-normative._

   It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their
   WebSocket connections open by sending periodic WebSocket "Ping"
   frames as described in [RFC6455] section 5.5.2.

      The WebSocket API [WS-API] does not provide a mechanism for
      applications running in a web browser to control whether or not
      periodic WebSocket "Ping" frames are sent to the server.  The
      implementation of such a keep alive feature is the decision of
      each web browser manufacturer and may also depend on the
      configuration of the web browser.

   A future WebSocket protocol extension providing a similar keep alive
   mechanism could also be used.

Dunkley                  Expires April 14, 2013                 [Page 7]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

7.  Authentication

   _This section is non-normative._

   Prior to sending MSRP requests, an MSRP WebSocket Client connects to
   an MSRP WebSocket Server and performs the connection handshake.  As
   described in Section 3 the handshake procedure involves a HTTP GET
   method request from the Client and a response from the Server
   including an HTTP 101 status code.

   In order to authorize the WebSocket connection, the MSRP WebSocket
   Server MAY inspect any Cookie [RFC6265] headers present in the HTTP
   GET request.  For many web applications the value of such a Cookie is
   provided by the web server once the user has authenticated themselves
   to the web server, which could be done by many existing mechanisms.
   As an alternative method, the MSRP WebSocket Server could request
   HTTP authentication by replying to the Client's GET method request
   with a HTTP 401 status code.  The WebSocket protocol [RFC6455] covers
   this usage in section 4.1:

      If the status code received from the server is not 101, the
      WebSocket client stack handles the response per HTTP [RFC2616]
      procedures, in particular the client might perform authentication
      if it receives 401 status code.

   Regardless of whether the MSRP WebSocket Server requires
   authentication during the WebSocket handshake, authentication MAY be
   requested at MSRP protocol level.  Therefore it is RECOMMENDED that
   an MSRP WebSocket Client implements HTTP Digest [RFC2617]
   authentication as stated in [RFC4976].

8.  Examples

8.1.  AUTH

   Alice    (MSRP WSS)     a.example.com
   |                             |
   |HTTP GET (WS handshake) F1   |
   |---------------------------->|
   |101 Switching Protocols F2   |
   |<----------------------------|
   |                             |
   |AUTH F3                      |
   |---------------------------->|
   |200 OK F4                    |
   |<----------------------------|

Dunkley                  Expires April 14, 2013                 [Page 8]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

   |                             |

   Alice loads a web page using her web browser and retrieves JavaScript
   code implementing the WebSocket MSRP sub-protocol defined in this
   document.  The JavaScript code (an MSRP WebSocket Client) establishes
   a secure WebSocket connection with an MSRP relay (a MSRP WebSocket
   Server) at a.example.com.  Upon WebSocket connection, Alice
   constructs and sends an MSRP AUTH request.  Since the JavaScript
   stack in a browser has no way to determine the local address from
   which the WebSocket connection was made, this implementation uses a
   random ".invalid" domain name for the hostpart of the From-Path URI
   (see Appendix A.1).

   Message details (authentication is omitted for simplicity):

Dunkley                  Expires April 14, 2013                 [Page 9]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

   F1 HTTP GET (WS handshake)  Alice -> a.example.com (TLS)

   GET / HTTP/1.1
   Host: a.example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
   Origin: https://www.example.com
   Sec-WebSocket-Protocol: msrp
   Sec-WebSocket-Version: 13

   F2 101 Switching Protocols  a.example.com -> Alice (TLS)

   HTTP/1.1 101 Switching Protocols
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
   Sec-WebSocket-Protocol: msrp

   F3 AUTH  Alice -> a.example.com (transport WSS)

   MSRP 49fi AUTH
   To-Path: msrps://alice@a.example.com;tcp
   From-Path: msrps://df7jal23ls0d.invalid/98cjs;ws
   -------49fi$

   F4 200 OK  a.example.com -> Alice (transport WSS)

   MSRP 49fi 200 OK
   To-Path: msrps://df7jal23ls0d.invalid/98cjs;ws
   From-Path: msrps://alice@a.example.com;tcp
   Use-Path: msrps://a.example.com:9000/jui787s2f;tcp
   Expires: 900
   -------49fi$

8.2.  SEND (MSRP WebSocket Client to MSRP Client)

Dunkley                  Expires April 14, 2013                [Page 10]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

   Alice    (MSRP WSS)     a.example.com      (MSRP TLS)     Bob
   |                             |                             |
   |SEND F1                      |                             |
   |---------------------------->|                             |
   |200 OK F2                    |                             |
   |<----------------------------|                             |
   |                             |SEND F3                      |
   |                             |---------------------------->|
   |                             |200 OK F4                    |
   |                             |<----------------------------|

   In the same scenario Alice sends an instant message to Bob (session
   details having been previously negotiated by some other mechanism -
   such as SDP [RFC4976]).  The MSRP WebSocket Server at a.example.com
   acts as an MSRP relay, routing the message to Bob over TLS.

   Message details (note that MSRP does not permit line folding.  A "\"
   in the examples shows a line continuation due to limitations in line
   length of this document.  Neither the backslash nor the extra CRLF is
   included in the actual request or response):

Dunkley                  Expires April 14, 2013                [Page 11]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

   F1 SEND  Alice -> a.example.com (transport WSS)

   MSRP 6aef SEND
   To-Path: msrps://a.example.com:9000/kjfjan;tcp \
            msrps://bob.example.com:8145/foo;tcp
   From-Path: msrps://df7jal23ls0d.invalid/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Hi Bob, I'm about to send you file.mpeg
   -------6aef$

   F2 200 OK  a.example.com -> Alice (transport WSS)

   MSRP 6aef 200 OK
   To-Path: msrps://df7jal23ls0d.invalid/98cjs;ws
   From-Path: msrps://a.example.com:9000/kjfjan;tcp
   Message-ID: 87652
   -------6aef$

   F3 SEND  a.example.com -> Bob (transport TLS)

   MSRP juh76 SEND
   To-Path: msrps://bob.example.com:8145/foo;tcp
   From-Path:  msrps://a.example.com:9000/kjfjan;tcp \
               msrps://df7jal23ls0d.invalid/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Hi Bob, I'm about to send you file.mpeg
   -------juh76$

   F4 200 OK  Bob -> a.example.com (transport TLS)

   MSRP juh76 200 OK
   To-Path: msrps://a.example.com:9000/kjfjan;tcp
   From-Path: msrps://bob.example.com:8145/foo;tcp
   Message-ID: 87652
   -------juh76$

Dunkley                  Expires April 14, 2013                [Page 12]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

8.3.  SEND (MSRP Client to MSRP WebSocket Client)

   Bob      (MSRP TLS)     a.example.com     (MSRP WSS)    Alice
   |                             |                             |
   |SEND F1                      |                             |
   |---------------------------->|                             |
   |200 OK F2                    |                             |
   |<----------------------------|                             |
   |                             |SEND F3                      |
   |                             |---------------------------->|
   |                             |200 OK F4                    |
   |                             |<----------------------------|

   In the same scenario Bob sends an instant message to Alice (session
   details having been previously negotiated by some other mechanism -
   such as SDP [RFC4976]).  The MSRP WebSocket Server at a.example.com
   acts as an MSRP relay, routing the message to Alice over secure
   WebSocket.

   Message details (note that MSRP does not permit line folding.  A "\"
   in the examples shows a line continuation due to limitations in line
   length of this document.  Neither the backslash nor the extra CRLF is
   included in the actual request or response):

Dunkley                  Expires April 14, 2013                [Page 13]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

   F1 SEND  Bob -> a.example.com (transport TLS)

   MSRP xght6 SEND
   To-Path: msrps://a.example.com:9000/jui787s2f;tcp \
            msrps://df7jal23ls0d.invalid/98cjs;ws
   From-Path: msrps://bob.example.com:8145/foo;tcp
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Thanks for the file.
   -------xght6$

   F2 200 OK  a.example.com -> Bob (transport TLS)

   MSRP xght6 200 OK
   To-Path: msrps://bob.example.com:8145/foo;tcp
   From-Path: msrps://a.example.com:9000/jui787s2f;tcp
   Message-ID: 87652
   -------6aef$

   F3 SEND  a.example.com -> Alice (transport WSS)

   MSRP yh67 SEND
   To-Path:  msrps://df7jal23ls0d.invalid/98cjs;ws
   From-Path:  msrps://a.example.com:9000/jui787s2f;tcp \
               msrps://bob.example.com:8145/foo;tcp
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Hi Bob, I'm about to send you file.mpeg
   -------yh67$

   F4 200 OK  Bob -> a.example.com (transport TLS)

   MSRP yh67 200 OK
   To-Path:  msrps://a.example.com:9000/jui787s2f;tcp
   From-Path:  msrps://df7jal23ls0d.invalid/98cjs;ws
   Message-ID: 87652
   -------yh67$

Dunkley                  Expires April 14, 2013                [Page 14]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

8.4.  SEND (MSRP WebSocket Client to MSRP WebSocket Client)

   Alice    (MSRP WSS)     a.example.com     (MSRP WSS)    Carol
   |                             |                             |
   |SEND F1                      |                             |
   |---------------------------->|                             |
   |200 OK F2                    |                             |
   |<----------------------------|                             |
   |                             |SEND F3                      |
   |                             |---------------------------->|
   |                             |200 OK F4                    |
   |                             |<----------------------------|

   In the same scenario Alice sends an instant message to Carol (session
   details having been previously negotiated by some other mechanism -
   such as SDP [RFC4976]).  The MSRP WebSocket Server at a.example.com
   acts as an MSRP relay, routing the message to Carol over secure
   WebSocket.

   Message details (note that MSRP does not permit line folding.  A "\"
   in the examples shows a line continuation due to limitations in line
   length of this document.  Neither the backslash nor the extra CRLF is
   included in the actual request or response):

Dunkley                  Expires April 14, 2013                [Page 15]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

   F1 SEND  Alice -> a.example.com (transport WSS)

   MSRP kjh6 SEND
   To-Path: msrps://a.example.com:9000/iwnslt;tcp \
            msrps://jk9awp14vj8x.invalid/76qwe;ws
   From-Path: msrps://df7jal23ls0d.invalid/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Carol, here is the file Bob sent me.
   -------kjh6$

   F2 200 OK  a.example.com -> Alice (transport WSS)

   MSRP kjh6 200 OK
   To-Path: msrps://df7jal23ls0d.invalid/98cjs;ws
   From-Path: msrps://a.example.com:9000/iwnslt;tcp
   Message-ID: 87652
   -------kjh$

   F3 SEND  a.example.com -> Carol (transport WSS)

   MSRP re58 SEND
   To-Path: msrps://jk9awp14vj8x.invalid/76qwe;ws
   From-Path: msrps://a.example.com:9000/iwnslt;tcp \
              msrps://df7jal23ls0d.invalid/98cjs;ws
   Success-Report: no
   Byte-Range: 1-*/*
   Message-ID: 87652
   Content-Type: text/plain

   Carol, here is the file Bob sent me.
   -------re58$

   F4 200 OK  Carol -> a.example.com (transport WSS)

   MSRP re58 200 OK
   To-Path: msrps://a.example.com:9000/iwnslt;tcp
   From-Path: msrps://jk9awp14vj8x.invalid/76qwe;ws
   Message-ID: 87652
   -------re58$

Dunkley                  Expires April 14, 2013                [Page 16]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

9.  Security Considerations

9.1.  Secure WebSocket Connection

   It is recommended that the MSRP traffic transported over a WebSocket
   communication be protected by using a secure WebSocket connection
   (using TLS [RFC5246] over TCP).

10.  IANA Considerations

10.1.  Registration of the WebSocket MSRP Sub-Protocol

   This specification requests IANA to register the WebSocket MSRP sub-
   protocol in the registry of WebSocket sub-protocols with the
   following data:

   Subprotocol Identifier:  msrp

   Subprotocol Common Name:  WebSocket Transport for MSRP (Message
      Session Relay Protocol)

   Subprotocol Definition:  TBD, it should point to this document

11.  Acknowledgements

   Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and
   Victor Pascual, the authors of [I-D.ietf-sipcore-sip-websocket] which
   has inspired this draft.

   Special thanks to James Wyatt from Crocodile RCS Ltd for helping with
   the JavaScript MSRP over WebSockets prototyping.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4975]  Campbell, B., Mahy, R., and C. Jennings, "The Message
              Session Relay Protocol (MSRP)", RFC 4975, September 2007.

   [RFC4976]  Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
              for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
              September 2007.

Dunkley                  Expires April 14, 2013                [Page 17]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, December 2011.

12.2.  Informative References

   [I-D.ietf-sipcore-sip-websocket]
              Castillo, I., Millan, J., and V. Pascual, "The WebSocket
              Protocol as a Transport for the Session Initiation
              Protocol (SIP)", draft-ietf-sipcore-sip-websocket-04 (work
              in progress), October 2012.

   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, June 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              April 2011.

   [WS-API]   W3C and I. Hickson, Ed., "The WebSocket API", May 2012.

Appendix A.  Implementation Guidelines

   _This section is non-normative._

A.1.  MSRP WebSocket Client Considerations

   The JavaScript stack in web browsers does not have the ability to
   discover the local transport address used for originating WebSocket
   connections.  Therefore the MSRP WebSocket Client constructs a domain

Dunkley                  Expires April 14, 2013                [Page 18]
Internet-Draft      WebSocket as a Transport for MSRP       October 2012

   name consisting of a random token followed by the ".invalid" top-
   level domain name, as stated in [RFC2606], and uses it within its
   From-Path headers.

      The From-Path URI provided by MSRP clients which use an MSRP relay
      is not used for routing MSRP messages, thus it is safe to set a
      random domain in the hostpart of the From-Path URI.

Author's Address

   Peter Dunkley
   Crocodile RCS Ltd
   Forum 3, Parkway
   Solent Business Park, Whiteley
   Fareham  PO15 7FH
   United Kingdom

   Email: peter.dunkley@crocodile-rcs.com

Dunkley                  Expires April 14, 2013                [Page 19]