Internet DRAFT - draft-pd-msrp-websocket
draft-pd-msrp-websocket
Network Working Group P. Dunkley
Internet-Draft G. Llewellyn
Updates: 4975, 4976 (if approved) Crocodile RCS Ltd
Intended status: Standards Track November 23, 2012
Expires: May 27, 2013
The WebSocket Protocol as a Transport for the Message Session Relay
Protocol (MSRP)
draft-pd-msrp-websocket-02
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. This document normatively updates RFC 4975 and RFC
4976.
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 May 27, 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
Dunkley & Llewellyn Expires May 27, 2013 [Page 1]
Internet-Draft WebSocket as a Transport for MSRP November 2012
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.
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 . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Dunkley & Llewellyn Expires May 27, 2013 [Page 2]
Internet-Draft WebSocket as a Transport for MSRP November 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
[RFC4976]) capable of listening for inbound connections from
WebSocket clients and communicating using the WebSocket MSRP
sub-protocol as defined by this document.
Dunkley & Llewellyn Expires May 27, 2013 [Page 3]
Internet-Draft WebSocket as a Transport for MSRP November 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 & Llewellyn Expires May 27, 2013 [Page 4]
Internet-Draft WebSocket as a Transport for MSRP November 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 & Llewellyn Expires May 27, 2013 [Page 5]
Internet-Draft WebSocket as a Transport for MSRP November 2012
5.1. General
WebSocket clients cannot receive WebSocket connections initiated by
other WebSocket clients or WebSocket servers. This means that it is
impossible 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 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 & Llewellyn Expires May 27, 2013 [Page 6]
Internet-Draft WebSocket as a Transport for MSRP November 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 client's
WebSocket stack and the WebSocket server, an MSRP WebSocket Client
may have 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 & Llewellyn Expires May 27, 2013 [Page 7]
Internet-Draft WebSocket as a Transport for MSRP November 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 & Llewellyn Expires May 27, 2013 [Page 8]
Internet-Draft WebSocket as a Transport for MSRP November 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 (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.1).
Message details (authentication is omitted for simplicity):
Dunkley & Llewellyn Expires May 27, 2013 [Page 9]
Internet-Draft WebSocket as a Transport for MSRP November 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: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$
8.2. SEND (MSRP WebSocket Client to MSRP Client)
Dunkley & Llewellyn Expires May 27, 2013 [Page 10]
Internet-Draft WebSocket as a Transport for MSRP November 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.
In this example Bob himself does not require an MSRP relay and has
not authenticated with a.example.com but Alice does and has.
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 & Llewellyn Expires May 27, 2013 [Page 11]
Internet-Draft WebSocket as a Transport for MSRP November 2012
F1 SEND Alice -> a.example.com (transport WSS)
MSRP 6aef SEND
To-Path: msrps://a.example.com:2855/jui787s2f;tcp \
msrps://bob.example.com:8145/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$
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: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:8145/foo;tcp
-------juh76$
Dunkley & Llewellyn Expires May 27, 2013 [Page 12]
Internet-Draft WebSocket as a Transport for MSRP November 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.
In this example Bob himself does not require an MSRP relay and has
not authenticated with a.example.com but Alice does and has.
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 & Llewellyn Expires May 27, 2013 [Page 13]
Internet-Draft WebSocket as a Transport for MSRP November 2012
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: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: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: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:2855/jui787s2f;tcp
From-Path: msrps://df7jal23ls0d.invalid:2855/98cjs;ws
-------yh67$
Dunkley & Llewellyn Expires May 27, 2013 [Page 14]
Internet-Draft WebSocket as a Transport for MSRP November 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.
In this example both Alice and Carol are using MSRP WebSocket Clients
and an 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 (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 & Llewellyn Expires May 27, 2013 [Page 15]
Internet-Draft WebSocket as a Transport for MSRP November 2012
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, 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: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-*/*
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:2855/iwnslt;tcp
From-Path: msrps://jk9awp14vj8x.invalid:2855/76qwe;ws
-------re58$
Dunkley & Llewellyn Expires May 27, 2013 [Page 16]
Internet-Draft WebSocket as a Transport for MSRP November 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.
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.
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.
Dunkley & Llewellyn Expires May 27, 2013 [Page 17]
Internet-Draft WebSocket as a Transport for MSRP November 2012
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007.
[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-06 (work
in progress), November 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._
Dunkley & Llewellyn Expires May 27, 2013 [Page 18]
Internet-Draft WebSocket as a Transport for MSRP November 2012
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
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.
Authors' Addresses
Peter Dunkley
Crocodile RCS Ltd
Forum 3, Parkway
Solent Business Park, Whiteley
Fareham PO15 7FH
United Kingdom
Email: peter.dunkley@crocodile-rcs.com
Gavin Llewellyn
Crocodile RCS Ltd
Forum 3, Parkway
Solent Business Park, Whiteley
Fareham PO15 7FH
United Kingdom
Email: gavin.llewellyn@crocodile-rcs.com
Dunkley & Llewellyn Expires May 27, 2013 [Page 19]