GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7977

Internet Engineering Task Force (IETF) P. Dunkley Request for Comments: 7977 G. Llewellyn Updates: 4975, 4976 Xura Category: Standards Track V. Pascual ISSN: 2070-1721 Oracle

                                                          G. Salgueiro
                                                       R. Ravindranath
                                                                 Cisco
                                                        September 2016
               The WebSocket Protocol as a Transport
           for the Message Session Relay Protocol (MSRP)

Abstract

 The WebSocket protocol enables two-way real-time communication
 between clients and servers in situations where direct access to TCP
 and UDP is not available (for example, from within JavaScript in a
 web browser).  This document specifies a new WebSocket subprotocol as
 a reliable transport mechanism between Message Session Relay Protocol
 (MSRP) clients and relays to enable usage of MSRP in new scenarios.
 This document normatively updates RFCs 4975 and 4976.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7977.

Dunkley, et al. Standards Track [Page 1] RFC 7977 WebSocket as a Transport for MSRP September 2016

Copyright Notice

 Copyright (c) 2016 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
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Dunkley, et al. Standards Track [Page 2] RFC 7977 WebSocket as a Transport for MSRP September 2016

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
 2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   5
 3.  WebSocket Protocol Overview . . . . . . . . . . . . . . . . .   5
 4.  The WebSocket MSRP Subprotocol  . . . . . . . . . . . . . . .   6
   4.1.  Handshake . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.2.  MSRP Encoding . . . . . . . . . . . . . . . . . . . . . .   7
 5.  MSRP WebSocket Transport  . . . . . . . . . . . . . . . . . .   7
   5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.2.  Updates to RFC 4975 . . . . . . . . . . . . . . . . . . .   7
     5.2.1.  MSRP URI Transport Parameter  . . . . . . . . . . . .   7
     5.2.2.  SDP Transport Protocol  . . . . . . . . . . . . . . .   8
   5.3.  Updates to RFC 4976 . . . . . . . . . . . . . . . . . . .   8
     5.3.1.  AUTH Request Authentication . . . . . . . . . . . . .   8
 6.  Connection Keepalive  . . . . . . . . . . . . . . . . . . . .   9
 7.  Authentication  . . . . . . . . . . . . . . . . . . . . . . .   9
 8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .  10
     8.1.1.  WebSocket Authentication  . . . . . . . . . . . . . .  10
     8.1.2.  MSRP Authentication . . . . . . . . . . . . . . . . .  12
   8.2.  Example Session: MSRP WebSocket Client to MSRP Client . .  14
     8.2.1.  SDP Exchange  . . . . . . . . . . . . . . . . . . . .  14
     8.2.2.  SEND (MSRP WebSocket Client to MSRP Client) . . . . .  15
     8.2.3.  SEND (MSRP Client to MSRP WebSocket Client) . . . . .  16
   8.3.  Example Session: Two MSRP WebSocket Clients . . . . . . .  18
     8.3.1.  SDP Exchange  . . . . . . . . . . . . . . . . . . . .  18
     8.3.2.  SEND  . . . . . . . . . . . . . . . . . . . . . . . .  19
   8.4.  Example Session: MSRP WebSocket Client to MSRP Client
         Using a Relay . . . . . . . . . . . . . . . . . . . . . .  20
     8.4.1.  SDP Exchange  . . . . . . . . . . . . . . . . . . . .  20
     8.4.2.  SEND  . . . . . . . . . . . . . . . . . . . . . . . .  21
 9.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
 11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
   11.1.  Normative References . . . . . . . . . . . . . . . . . .  25
   11.2.  Informative References . . . . . . . . . . . . . . . . .  25
 Appendix A.  Implementation Guidelines: MSRP WebSocket Client
              Considerations . . . . . . . . . . . . . . . . . . .  27
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  27
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

Dunkley, et al. Standards Track [Page 3] RFC 7977 WebSocket as a Transport for MSRP September 2016

1. Introduction

 The WebSocket [RFC6455] protocol enables message exchange between
 clients and servers on top of a persistent TCP connection (optionally
 secured with Transport Layer Security (TLS) [RFC5246]).  The initial
 protocol handshake makes use of HTTP [RFC7230] 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 smartphones) will also make a WebSocket client
 stack available.  The specification in this document enables usage of
 Message Session Relay Protocol [RFC4975] in these scenarios.
 This specification defines a new WebSocket subprotocol (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.
 MSRP over WebSocket is well suited for MSRP interactions between
 clients and servers.  Common use cases for MSRP over WebSocket
 include:
 o  Human-to-machine messaging
 o  Client-to-server data exchange (for example, application control
    signaling)
 o  Human-to-human messaging where local policy requires
    authentication and/or logging
 MSRP Connection Establishment for Media Anchoring (MSRP-CEMA)
 [RFC6714] is outside of the scope of this document, as this document
 is intended to describe connecting to a WebSocket server that is an
 MSRP relay.

2. Terminology

 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].

Dunkley, et al. Standards Track [Page 4] RFC 7977 WebSocket as a Transport for MSRP September 2016

2.1. Definitions

 MSRP WebSocket Client:  An MSRP entity capable of opening outbound
       connections to MSRP relays that are WebSocket servers and
       communicating using the WebSocket MSRP subprotocol as defined
       by this document.
 MSRP WebSocket Server:  An MSRP entity (specifically an MSRP relay
       [RFC4976]) capable of listening for inbound connections from
       WebSocket clients and communicating using the WebSocket MSRP
       subprotocol as defined by this document.

3. WebSocket Protocol Overview

 The WebSocket protocol [RFC6455] is a transport layer on top of TCP
 (optionally secured with TLS [RFC5246]) in which both the client and
 server exchange message units in both directions.  The protocol
 defines a connection handshake, WebSocket subprotocol 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 [RFC7230] 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 subprotocol") 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 subprotocol 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.

Dunkley, et al. Standards Track [Page 5] RFC 7977 WebSocket as a Transport for MSRP September 2016

 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 Subprotocol

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

4.1. Handshake

 The MSRP WebSocket Client and MSRP WebSocket Server negotiate usage
 of the WebSocket MSRP subprotocol 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 subprotocol 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
 subprotocol 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 subprotocol.

Dunkley, et al. Standards Track [Page 6] RFC 7977 WebSocket as a Transport for MSRP September 2016

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.
 The WebSocket API [WS-API] does not allow developers to choose
 whether to send UTF-8 text or binary frames but will not send
 non-UTF-8 characters in a text frame.  The content of text frames
 MUST be interpreted as binary by WebSocket Clients and Servers.

5. MSRP WebSocket Transport

5.1. General

 WebSocket clients cannot receive WebSocket connections initiated by
 other WebSocket clients or WebSocket servers.  This means that it is
 challenging for an MSRP client to communicate directly with other
 MSRP clients.  Therefore, all MSRP-over-WebSocket messages MUST be
 routed via an MSRP WebSocket Server.  MSRP traffic transported over
 WebSockets MUST be protected by using a Secure WebSocket (WSS)
 connection (using TLS [RFC5246] over TCP).
 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 chunk MUST be carried within a single WebSocket message,
 and a WebSocket message MUST NOT contain more than one MSRP chunk.
 This simplifies parsing of MSRP messages for both clients and
 servers.  When large messages are sent by a non-WebSocket peer, MSRP
 chunking (as defined in Section 5.1 of [RFC4975]) MUST be used by the
 WebSocket MSRP Servers to split the message into several smaller MSRP
 chunks.

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
 subprotocol as transport.

Dunkley, et al. Standards Track [Page 7] RFC 7977 WebSocket as a Transport for MSRP September 2016

 The updated ABNF [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 Session Description Protocol
 (SDP) transport protocol for MSRP over WebSockets.  As all MSRP-over-
 WebSocket messages MUST be routed via an MSRP WebSocket Server, the
 MSRP WebSocket Client MUST specify "TCP/TLS/MSRP" protocols in the
 SDP m-line -- that being the protocol used by non-WebSocket clients
 and between MSRP relays (see Section 8.1 of [RFC4975]).
 The "ws" transport parameter will appear in the endpoint URI in the
 SDP "path" attribute (see Section 8.2 of [RFC4975]).  MSRP was
 designed with the possibility of new transport bindings in mind (see
 Section 6 of [RFC4975]), so MSRP implementations are expected to
 allow unrecognized transports, provided that they do not have to
 establish a direct connection to the resource described by the URI.

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
 three 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).
 3.  Mutual TLS between the WebSocket-based MSRP client and the
     WebSocket server.
 The AUTH request is a required event when authentication occurs at
 the WebSocket connection level since the "Use-Path:" header required
 to create the SDP offer is included in the 200 OK response to the
 AUTH request.

Dunkley, et al. Standards Track [Page 8] RFC 7977 WebSocket as a Transport for MSRP September 2016

6. Connection Keepalive

 It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their
 WebSocket connections open by sending periodic WebSocket "Ping"
 frames as described in Section 5.5.2 of [RFC6455].
 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 keepalive 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 keepalive
 mechanism could also be used.
 When MSRP WebSocket Clients or Servers cannot use WebSocket "Ping"
 frames to keep connections open, an MSRP implementation MAY use
 bodiless SEND requests as described in Section 7.1 of [RFC4975].
 MSRP WebSocket Clients or Servers MUST be prepared to receive
 bodiless SEND requests.

7. Authentication

 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 HTTP headers present (for example, Cookie
 [RFC6265], Host [RFC7230], or Origin [RFC6454]) 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 and is paraphrased as follows:
    If the status code received from the server is not 101, the
    WebSocket client stack handles the response per HTTP [RFC7230]
    procedures; in particular, the client might perform authentication
    if it receives a 401 status code.

Dunkley, et al. Standards Track [Page 9] RFC 7977 WebSocket as a Transport for MSRP September 2016

 If the HTTP GET request contains an Origin header, the MSRP WebSocket
 Server SHOULD indicate Cross-Origin Resource Sharing [CORS] by adding
 an Access-Control-Allow-Origin header to the 101 response.
 Regardless of whether the MSRP WebSocket Server requires
 authentication during the WebSocket handshake, authentication MAY be
 requested at the MSRP protocol level by an MSRP Server challenging
 AUTH requests using a 401 response.  Therefore, an MSRP WebSocket
 Client SHOULD support HTTP Digest [RFC7235] authentication as stated
 in [RFC4976].

8. Examples

8.1. Authentication

8.1.1. WebSocket Authentication

 Alice    (MSRP WSS)    a.example.com
 |                             |
 |HTTP GET (WS handshake) F1   |
 |---------------------------->|
 |101 Switching Protocols F2   |
 |<----------------------------|
 |                             |
 |AUTH F3                      |
 |---------------------------->|
 |200 OK F4                    |
 |<----------------------------|
 |                             |
 Alice loads a web page using her web browser and retrieves JavaScript
 code implementing the WebSocket MSRP subprotocol defined in this
 document.  The JavaScript code (an MSRP WebSocket Client) establishes
 a secure WebSocket connection with an MSRP relay (an 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).

Dunkley, et al. Standards Track [Page 10] RFC 7977 WebSocket as a Transport for MSRP September 2016

 In this example, it is assumed that authentication is performed at
 the WebSocket layer (not shown), so no challenge is issued for the
 MSRP AUTH message:
 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:443;ws
 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 -------49fi$
 F4 200 OK  a.example.com -> Alice (transport WSS)
 MSRP 49fi 200 OK
 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 From-Path: msrps://alice@a.example.com:443;ws
 Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
 Expires: 900
 -------49fi$

Dunkley, et al. Standards Track [Page 11] RFC 7977 WebSocket as a Transport for MSRP September 2016

8.1.2. MSRP Authentication

 Alice    (MSRP WSS)     a.example.com
 |                             |
 |HTTP GET (WS handshake) F1   |
 |---------------------------->|
 |101 Switching Protocols F2   |
 |<----------------------------|
 |                             |
 |AUTH F3                      |
 |---------------------------->|
 |401 Unauthorized F4                    |
 |<----------------------------|
 |AUTH F5                      |
 |---------------------------->|
 |200 OK F6                    |
 |<----------------------------|
 |                             |
 This example uses the same scenario as Section 8.1.1 but with
 authentication performed at the MSRP layer.
 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 MSRP message.
 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

Dunkley, et al. Standards Track [Page 12] RFC 7977 WebSocket as a Transport for MSRP September 2016

 F3 AUTH  Alice -> a.example.com (transport WSS)
 MSRP 4rsxt9nz AUTH
 To-Path: msrps://alice@a.example.com:443;ws
 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 -------4rsxt9nz$
 F4 401 Unauthorized  a.example.com -> Alice (transport WSS)
 MSRP 4rsxt9nz 401 Unauthorized
 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 From-Path: msrps://alice@a.example.com:443;ws
 WWW-Authenticate: Digest realm="example.com", \
  nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", qop="auth"
 -------4rsxt9nz$
 F5 AUTH  Alice -> a.example.com (transport WSS)
 MSRP qy1hsow5 AUTH
 To-Path: msrps://alice@a.example.com:443;ws
 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 Authorization: Digest username="alice", realm="example.com", \
  nonce="UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4+dd4A=", \
  uri="msrps://alice@a.example.com:443;ws", \
  response="5011d0d58fe975e0d0cdc007ae26f4b7", \
  qop=auth, cnonce="zic5ml401prb", nc=00000001
 -------qy1hsow5$
 F6 200 OK  a.example.com -> Alice (transport WSS)
 MSRP qy1hsow5 200 OK
 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 From-Path: msrps://alice@a.example.com:443;ws
 Use-Path: msrps://a.example.com:2855/jui787s2f;tcp
 Expires: 900
 -------qy1hsow5$

Dunkley, et al. Standards Track [Page 13] RFC 7977 WebSocket as a Transport for MSRP September 2016

8.2. Example Session: MSRP WebSocket Client to MSRP Client

 The following subsections show various message exchanges occurring
 during the course of an MSRP session between a WebSocket client and a
 non-WebSocket client.

8.2.1. SDP Exchange

 The following example shows SDP that could be included in a SIP
 message to set up an MSRP session between Alice and Bob where Alice
 uses a WebSocket MSRP relay and Bob uses a traditional MSRP client
 without a relay.
 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 SDP.
 Alice makes an offer with a path including the relay (having already
 successfully authenticated with the relay):
 c=IN IP4 a.example.com
 m=message 1234 TCP/TLS/MSRP *
 a=accept-types:message/cpim text/plain text/html
 a=path:msrps://a.example.com:2855/jui787s2f;tcp \
        msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 In this offer, Alice wishes to receive MSRP messages via the relay at
 a.example.com.  She wants to use TLS as the transport for the MSRP
 session (beyond the relay).  She can accept message/cpim, text/plain,
 and text/html message bodies in SEND requests.
 Bob's answer to this offer could look like:
 c=IN IP4 bob.example.com
 m=message 1234 TCP/TLS/MSRP *
 a=accept-types:message/cpim text/plain
 a=path:msrps://bob.example.com:49154/foo;tcp
 Here, Bob wishes to receive the MSRP messages at bob.example.com.  He
 can accept only message/cpim and text/plain message bodies in SEND
 requests and has rejected the text/html content offered by Alice.  He
 does not need a relay to set up the MSRP session.

Dunkley, et al. Standards Track [Page 14] RFC 7977 WebSocket as a Transport for MSRP September 2016

8.2.2. SEND (MSRP WebSocket Client to MSRP Client)

 Alice    (MSRP WSS)     a.example.com      (MSRP TLS)     Bob
 |                             |                             |
 |SEND F1                      |                             |
 |---------------------------->|                             |
 |200 OK F2                    |                             |
 |<----------------------------|                             |
 |                             |SEND F3                      |
 |                             |---------------------------->|
 |                             |200 OK F4                    |
 |                             |<----------------------------|
 Later in the session, Alice sends an instant message to Bob.  The
 MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing
 the message to Bob over TLS.
 Message details (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):
 F1 SEND  Alice -> a.example.com (transport WSS)
 MSRP 6aef SEND
 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
          msrps://bob.example.com:49154/foo;tcp
 From-Path: msrps://df7jal23ls0d.invalid:2855/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:2855/98cjs;ws
 From-Path: msrps://a.example.com:2855/jui787s2f;tcp
 -------6aef$

Dunkley, et al. Standards Track [Page 15] RFC 7977 WebSocket as a Transport for MSRP September 2016

 F3 SEND  a.example.com -> Bob (transport TLS)
 MSRP juh76 SEND
 To-Path: msrps://bob.example.com:49154/foo;tcp
 From-Path:  msrps://a.example.com:2855/jui787s2f;tcp \
             msrps://df7jal23ls0d.invalid:2855/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:2855/jui787s2f;tcp
 From-Path: msrps://bob.example.com:49154/foo;tcp
 -------juh76$

8.2.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                    |
 |                             |<----------------------------|
 Later in the session, Bob sends an instant message to Alice.  The
 MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing
 the message to Alice over secure WebSocket.

Dunkley, et al. Standards Track [Page 16] RFC 7977 WebSocket as a Transport for MSRP September 2016

 Message details (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):
 F1 SEND  Bob -> a.example.com (transport TLS)
 MSRP xght6 SEND
 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
          msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 From-Path: msrps://bob.example.com:49154/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:49154/foo;tcp
 From-Path: msrps://a.example.com:2855/jui787s2f;tcp
 -------xght6$
 F3 SEND  a.example.com -> Alice (transport WSS)
 MSRP yh67 SEND
 To-Path:  msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 From-Path:  msrps://a.example.com:2855/jui787s2f;tcp \
             msrps://bob.example.com:49154/foo;tcp
 Success-Report: no
 Byte-Range: 1-*/*
 Message-ID: 87652
 Content-Type: text/plain
 Thanks for the file.
 -------yh67$

Dunkley, et al. Standards Track [Page 17] RFC 7977 WebSocket as a Transport for MSRP September 2016

 F4 200 OK  Alice -> a.example.com (transport WSS)
 MSRP yh67 200 OK
 To-Path:  msrps://a.example.com:2855/jui787s2f;tcp
 From-Path:  msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 -------yh67$

8.3. Example Session: Two MSRP WebSocket Clients

 The following subsections show various message exchanges occurring
 during the course of an MSRP session between two WebSocket clients.

8.3.1. SDP Exchange

 The following example shows SDP that could be included in a SIP
 message to set up an MSRP session between Alice and Carol where both
 of them are using the same WebSocket MSRP relay.
 Alice makes an offer with a path including the relay (having already
 successfully authenticated with the relay):
 c=IN IP4 a.example.com
 m=message 1234 TCP/TLS/MSRP *
 a=accept-types:message/cpim text/plain text/html
 a=path:msrps://a.example.com:2855/jui787s2f;tcp \
        msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 In this offer, Alice wishes to receive MSRP messages via the relay at
 a.example.com.  She wants to use TLS as the transport for the MSRP
 session (beyond the relay).  She can accept message/cpim, text/plain,
 and text/html message bodies in SEND requests.
 Carol's answer to this offer could look like:
 c=IN IP4 a.example.com
 m=message 1234 TCP/TLS/MSRP *
 a=accept-types:message/cpim text/plain
 a=path:msrps://a.example.com:2855/iwnslt;tcp \
        msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
 Here, Carol also wishes to receive the MSRP messages via
 a.example.com.  She can accept only message/cpim and text/plain
 message bodies in SEND requests and has rejected the text/html
 content offered by Alice.

Dunkley, et al. Standards Track [Page 18] RFC 7977 WebSocket as a Transport for MSRP September 2016

8.3.2. SEND

 Alice    (MSRP WSS)     a.example.com     (MSRP WSS)    Carol
 |                             |                             |
 |SEND F1                      |                             |
 |---------------------------->|                             |
 |200 OK F2                    |                             |
 |<----------------------------|                             |
 |                             |SEND F3                      |
 |                             |---------------------------->|
 |                             |200 OK F4                    |
 |                             |<----------------------------|
 Later in the session, Alice sends an instant message to Carol.  The
 MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing
 the message to Carol over secure WebSocket.
 In this example, both Alice and Carol are using MSRP WebSocket
 Clients and the same MSRP WebSocket Server.  This means that
 a.example.com will appear twice in the To-Path in F1.  a.example.com
 can either handle this internally or loop the MSRP SEND request back
 to itself as if it were two separate MSRP relays.
 Message details (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):
 F1 SEND  Alice -> a.example.com (transport WSS)
 MSRP kjh6 SEND
 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
          msrps://a.example.com:2855/iwnslt;tcp \
          msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 Success-Report: no
 Byte-Range: 1-*/*
 Message-ID: 87652
 Content-Type: text/plain
 Carol, I sent that file to Bob.
 -------kjh6$

Dunkley, et al. Standards Track [Page 19] RFC 7977 WebSocket as a Transport for MSRP September 2016

 F2 200 OK  a.example.com -> Alice (transport WSS)
 MSRP kjh6 200 OK
 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 From-Path: msrps://a.example.com:2855/jui787s2f;tcp
 -------kjh6$
 F3 SEND  a.example.com -> Carol (transport WSS)
 MSRP re58 SEND
 To-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
 From-Path: msrps://a.example.com:2855/iwnslt;tcp \
            msrps://a.example.com:2855/jui787s2f;tcp \
            msrps://df7jal23ls0d.invalid/98cjs;ws
 Success-Report: no
 Byte-Range: 1-*/*
 Message-ID: 87652
 Content-Type: text/plain
 Carol, I sent that file to Bob.
 -------re58$
 F4 200 OK  Carol -> a.example.com (transport WSS)
 MSRP re58 200 OK
 To-Path: msrps://a.example.com:2855/iwnslt;tcp
 From-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
 -------re58$

8.4. Example Session: MSRP WebSocket Client to MSRP Client Using a

    Relay
 The following subsections show various message exchanges occurring
 during the course of an MSRP session between a WebSocket client and a
 non-WebSocket client, where the latter is also using an MSRP relay.

8.4.1. SDP Exchange

 The following example shows SDP that could be included in a SIP
 message to set up an MSRP session between Alice and Bob where Alice
 uses a WebSocket MSRP relay and Bob uses a traditional MSRP client
 with a separate relay.

Dunkley, et al. Standards Track [Page 20] RFC 7977 WebSocket as a Transport for MSRP September 2016

 Alice makes an offer with a path including the relay (having already
 successfully authenticated with the relay):
 c=IN IP4 a.example.com
 m=message 1234 TCP/TLS/MSRP *
 a=accept-types:message/cpim text/plain text/html
 a=path:msrps://a.example.com:2855/jui787s2f;tcp \
        msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 In this offer, Alice wishes to receive MSRP messages via the relay at
 a.example.com.  She wants to use TLS as the transport for the MSRP
 session (beyond the relay).  She can accept message/cpim, text/plain,
 and text/html message bodies in SEND requests.
 Bob's answer to this offer could look like:
 c=IN IP4 bob.example.com
 m=message 1234 TCP/TLS/MSRP *
 a=accept-types:message/cpim text/plain
 a=path:msrps://relay.example.net:2855/kwvin5f;tcp \
        msrps://bob.example.com:49154/foo;tcp
 Here, Bob wishes to receive the MSRP messages via the relay at
 relay.example.net.  He can accept only message/cpim and text/plain
 message bodies in SEND requests and has rejected the text/html
 content offered by Alice.

8.4.2. SEND

 Alice (MSRP WSS) a.example.com (MSRP) relay.example.net  (MSRP)   Bob
 |                      |                       |                    |
 |SEND F1               |                       |                    |
 |--------------------->|                       |                    |
 |200 OK F2             |                       |                    |
 |<---------------------|                       |                    |
 |                      |SEND F3                |                    |
 |                      |---------------------->|                    |
 |                      |200 OK F4              |                    |
 |                      |<----------------------|                    |
 |                      |                       |SEND F5             |
 |                      |                       |------------------->|
 |                      |                       |200 OK F6           |
 |                      |                       |<-------------------|
 Later in the session, Alice sends an instant message to Bob.  The
 MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing
 the message to Bob via his relay, relay.example.net.

Dunkley, et al. Standards Track [Page 21] RFC 7977 WebSocket as a Transport for MSRP September 2016

 Message details (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):
 F1 SEND  Alice -> a.example.com (transport WSS)
 MSRP Ycwt SEND
 To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
          msrps://relay.example.net:2855/kwvin5f;tcp \
          msrps://bob.example.com:49154/foo;tcp
 From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 Success-Report: no
 Byte-Range: 1-*/*
 Message-ID: 87652
 Content-Type: text/plain
 Bob, that was the wrong file - don't watch it!
 -------Ycwt$
 F2 200 OK  a.example.com -> Alice (transport WSS)
 MSRP Ycwt 200 OK
 To-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
 From-Path: msrps://a.example.com:2855/jui787s2f;tcp
 -------Ycwt$
 F3 SEND  a.example.com -> relay.example.net (transport TLS)
 MSRP 13GA SEND
 To-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
          msrps://bob.example.com:49154/foo;tcp
 From-Path: msrps://a.example.com:2855/jui787s2f;tcp \
            msrps://df7jal23ls0d.invalid/98cjs;ws
 Success-Report: no
 Byte-Range: 1-*/*
 Message-ID: 87652
 Content-Type: text/plain
 Bob, that was the wrong file - don't watch it!
 -------13GA$

Dunkley, et al. Standards Track [Page 22] RFC 7977 WebSocket as a Transport for MSRP September 2016

 F4 200 OK  relay.example.net -> a.example.com (transport TLS)
 MSRP 13GA 200 OK
 To-Path: msrps://a.example.com:2855/iwnslt;tcp
 From-Path: msrps://relay.example.net:2855/kwvin5f;tcp
 -------13GA$
 F5 SEND  relay.example.net -> bob.example.com (transport TLS)
 MSRP kXeg SEND
 To-Path: msrps://bob.example.com:49154/foo;tcp
 From-Path: msrps://relay.example.net:2855/kwvin5f;tcp \
            msrps://a.example.com:2855/jui787s2f;tcp \
            msrps://df7jal23ls0d.invalid/98cjs;ws
 Success-Report: no
 Byte-Range: 1-*/*
 Message-ID: 87652
 Content-Type: text/plain
 Bob, that was the wrong file - don't watch it!
 -------kXeg$
 F6 200 OK  bob.example.com -> relay.example.net (transport TLS)
 MSRP kXeg 200 OK
 To-Path: msrps://relay.example.net:2855/kwvin5f;tcp
 From-Path: msrps://bob.example.com:49154/foo;tcp
 -------kXeg$

Dunkley, et al. Standards Track [Page 23] RFC 7977 WebSocket as a Transport for MSRP September 2016

9. Security Considerations

 MSRP traffic transported over WebSockets MUST be protected by using a
 secure WebSocket connection (using TLS [RFC5246] over TCP).
 When establishing a connection using MSRP over secure WebSockets, the
 client MUST authenticate the server using the server's certificate
 according to the WebSocket validation procedure in [RFC6455].
 Any security considerations specific to the WebSocket protocol are
 detailed in the relevant specification [RFC6455] and are considered
 outside the scope of this document.  The certificate name matching
 (described by [RFC6455]) and cryptosuite selection will be handled by
 the browser, and the browser's procedures will supersede those
 specified in [RFC4975].
 Since the TLS session is always terminated at the MSRP WebSocket
 Server and the WebSocket server can see the plain text, the MSRP
 client (browser) SHOULD NOT indicate end-to-end security to user.
 TLS, as used in this document, should follow the best current
 practices defined in [RFC7525].

10. IANA Considerations

 Per this specification, IANA has registered the WebSocket MSRP
 subprotocol in the "WebSocket Subprotocol Name Registry" with the
 following data:
 Subprotocol Identifier:  msrp
 Subprotocol Common Name:  WebSocket Transport for MSRP (Message
    Session Relay Protocol)
 Subprotocol Definition:  RFC 7977
 Reference:  RFC 7977

Dunkley, et al. Standards Track [Page 24] RFC 7977 WebSocket as a Transport for MSRP September 2016

11. References

11.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC4975]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
            "The Message Session Relay Protocol (MSRP)", RFC 4975,
            DOI 10.17487/RFC4975, September 2007,
            <http://www.rfc-editor.org/info/rfc4975>.
 [RFC4976]  Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
            for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
            DOI 10.17487/RFC4976, September 2007,
            <http://www.rfc-editor.org/info/rfc4976>.
 [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", STD 68, RFC 5234,
            DOI 10.17487/RFC5234, January 2008,
            <http://www.rfc-editor.org/info/rfc5234>.
 [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
            RFC 6455, DOI 10.17487/RFC6455, December 2011,
            <http://www.rfc-editor.org/info/rfc6455>.

11.2. Informative References

 [CORS]     van Kesteren, A., Ed., "Cross-Origin Resource Sharing",
            W3C Recommendation, January 2014,
            <http://www.w3.org/TR/2014/REC-cors-20140116/>.
 [RFC2606]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
            Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
            <http://www.rfc-editor.org/info/rfc2606>.
 [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
            Resource Identifier (URI): Generic Syntax", STD 66,
            RFC 3986, DOI 10.17487/RFC3986, January 2005,
            <http://www.rfc-editor.org/info/rfc3986>.
 [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246,
            DOI 10.17487/RFC5246, August 2008,
            <http://www.rfc-editor.org/info/rfc5246>.

Dunkley, et al. Standards Track [Page 25] RFC 7977 WebSocket as a Transport for MSRP September 2016

 [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
            DOI 10.17487/RFC6265, April 2011,
            <http://www.rfc-editor.org/info/rfc6265>.
 [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
            DOI 10.17487/RFC6454, December 2011,
            <http://www.rfc-editor.org/info/rfc6454>.
 [RFC6714]  Holmberg, C., Blau, S., and E. Burger, "Connection
            Establishment for Media Anchoring (CEMA) for the Message
            Session Relay Protocol (MSRP)", RFC 6714,
            DOI 10.17487/RFC6714, August 2012,
            <http://www.rfc-editor.org/info/rfc6714>.
 [RFC7118]  Baz Castillo, I., Millan Villegas, J., and V. Pascual,
            "The WebSocket Protocol as a Transport for the Session
            Initiation Protocol (SIP)", RFC 7118,
            DOI 10.17487/RFC7118, January 2014,
            <http://www.rfc-editor.org/info/rfc7118>.
 [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
            Protocol (HTTP/1.1): Message Syntax and Routing",
            RFC 7230, DOI 10.17487/RFC7230, June 2014,
            <http://www.rfc-editor.org/info/rfc7230>.
 [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
            Protocol (HTTP/1.1): Authentication", RFC 7235,
            DOI 10.17487/RFC7235, June 2014,
            <http://www.rfc-editor.org/info/rfc7235>.
 [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
            "Recommendations for Secure Use of Transport Layer
            Security (TLS) and Datagram Transport Layer Security
            (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
            2015, <http://www.rfc-editor.org/info/rfc7525>.
 [WS-API]   Hickson, I., Ed., "The WebSocket API", W3C Candidate
            Recommendation, September 2012,
            <https://www.w3.org/TR/2012/CR-websockets-20120920/>.

Dunkley, et al. Standards Track [Page 26] RFC 7977 WebSocket as a Transport for MSRP September 2016

Appendix A. Implementation Guidelines: 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 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 that 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.

Acknowledgements

 Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and
 Victor Pascual, the authors of [RFC7118], which has inspired this
 document.
 Additional thanks to Inaki Baz Castillo, who pointed out that "web
 browser" shouldn't be used all the time, as this specification should
 be valid for smartphones and apps other than browsers and suggested
 clarifications to the SDP handling for MSRP over WebSocket.
 Special thanks to James Wyatt from Crocodile RCS Ltd for helping with
 the JavaScript MSRP-over-WebSockets prototyping.
 Special thanks to Anton Roman who has contributed to this document.
 Thanks to Saul Ibarra Corretge for suggesting that the existing MSRP
 keepalive mechanism may be used when WebSocket pings are not
 available.
 Thanks to Ben Campbell, Inaki Baz Castillo, Keith Drage, Olle
 Johansson, and Christer Holmberg for their thoughtful discussion
 comments and review feedback that led to the improvement of this
 document.  Special thanks to Mary Barnes for both her technical
 review and for offering to act as Document Shepherd.  Thanks also to
 Stephen Farrell, Alissa Cooper, Mirja Kuehlewind, Allison Mankin,
 Alexey Melnikov, and Kathleen Moriarty for their review comments.

Dunkley, et al. Standards Track [Page 27] RFC 7977 WebSocket as a Transport for MSRP September 2016

Authors' Addresses

 Peter Dunkley
 Xura
 Lancaster Court
 8 Barnes Wallis Road
 Fareham  PO15 5TU
 United Kingdom
 Email: peter.dunkley@xura.com
 Gavin Llewellyn
 Xura
 Lancaster Court
 8 Barnes Wallis Road
 Fareham  PO15 5TU
 United Kingdom
 Email: gavin.llewellyn@xura.com
 Victor Pascual
 Oracle
 Email: victor.pascual.avila@oracle.com
 Gonzalo Salgueiro
 Cisco Systems, Inc.
 7200-12 Kit Creek Road
 Research Triangle Park, NC  27709
 United States of America
 Email: gsalguei@cisco.com
 Ram Mohan Ravindranath
 Cisco Systems, Inc.
 Email: rmohanr@cisco.com

Dunkley, et al. Standards Track [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7977.txt · Last modified: 2016/09/21 23:12 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki