draft-ietf-xmpp-websocket-05.txt   draft-ietf-xmpp-websocket-06.txt 
XMPP Working Group L. Stout, Ed. XMPP Working Group L. Stout, Ed.
Internet-Draft &yet Internet-Draft &yet
Intended status: Standards Track J. Moffitt Intended status: Standards Track J. Moffitt
Expires: October 22, 2014 Mozilla Expires: October 24, 2014 Mozilla
E. Cestari E. Cestari
cstar industries cstar industries
April 20, 2014 April 22, 2014
An XMPP Sub-protocol for WebSocket An XMPP Sub-protocol for WebSocket
draft-ietf-xmpp-websocket-05 draft-ietf-xmpp-websocket-06
Abstract Abstract
This document defines a binding for the XMPP protocol over a This document defines a binding for the XMPP protocol over a
WebSocket transport layer. A WebSocket binding for XMPP provides WebSocket transport layer. A WebSocket binding for XMPP provides
higher performance than the current HTTP binding for XMPP. higher performance than the current HTTP binding for XMPP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 22, 2014. This Internet-Draft will expire on October 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 36 skipping to change at page 3, line 36
[RFC2119]. [RFC2119].
3. XMPP Sub-Protocol 3. XMPP Sub-Protocol
3.1. Handshake 3.1. Handshake
The XMPP sub-protocol is used to transport XMPP over a WebSocket The XMPP sub-protocol is used to transport XMPP over a WebSocket
connection. The client and server agree to this protocol during the connection. The client and server agree to this protocol during the
WebSocket handshake (see Section 1.3 of [RFC6455]). WebSocket handshake (see Section 1.3 of [RFC6455]).
During the WebSocket handshake, the client MUST include the |Sec- During the WebSocket handshake, the client MUST include the
WebSocket-Protocol| header in its handshake, and the value |xmpp| value |xmpp| in the list of protocols for the |Sec-WebSocket-
MUST be included in the list of protocols. The reply from the server Protocol| header. The reply from the server MUST also contain |xmpp|
MUST also contain |xmpp| in its own |Sec-WebSocket-Protocol| header in its own |Sec-WebSocket-Protocol| header in order for an XMPP sub-
in order for an XMPP sub-protocol connection to be established. protocol connection to be established.
Once the handshake is complete, WebSocket messages sent or received Once the handshake is complete, WebSocket messages sent or received
will conform to the protocol defined in the rest of this document. will conform to the protocol defined in the rest of this document.
C: GET /xmpp-websocket HTTP/1.1 C: GET /xmpp-websocket HTTP/1.1
Host: example.com Host: example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com Origin: http://example.com
skipping to change at page 5, line 25 skipping to change at page 5, line 25
consequence, note that a framed XML stream does not provided a consequence, note that a framed XML stream does not provided a
wrapping <stream:stream/> element encompassing the entirety of the wrapping <stream:stream/> element encompassing the entirety of the
XML stream, as in [RFC6120]. XML stream, as in [RFC6120].
3.3.2. Framed Stream Namespace 3.3.2. Framed Stream Namespace
The XML stream "headers" (the <open/> and <close/> elements) MUST be The XML stream "headers" (the <open/> and <close/> elements) MUST be
qualified by the namespace 'urn:ietf:params:xml:ns:xmpp-framing' (the qualified by the namespace 'urn:ietf:params:xml:ns:xmpp-framing' (the
"framed stream namespace"). If this rule is violated, the entity "framed stream namespace"). If this rule is violated, the entity
that receives the offending stream header MUST close the stream with that receives the offending stream header MUST close the stream with
an error, which SHOULD be <invalid-namespace> (see Section 4.9.3.10 an error, which MUST be <invalid-namespace> (see Section 4.9.3.10 of
of [RFC6120]). [RFC6120]).
3.3.3. Stream Frames 3.3.3. Stream Frames
The individual frames of a framed XML stream have a one-to-one The individual frames of a framed XML stream have a one-to-one
correspondence with WebSocket messages, and MUST be parsable as correspondence with WebSocket messages, and MUST be parsable as
standalone XML documents, complete with all relevant namespace and standalone XML documents, complete with all relevant namespace and
language declarations. The inclusion of XML declarations, however, language declarations. The inclusion of XML declarations, however,
is NOT RECOMMENDED as WebSocket messages are already mandated to be is NOT RECOMMENDED as WebSocket messages are already mandated to be
UTF-8 encoded and therefore would only add a constant size overhead UTF-8 encoded and therefore would only add a constant size overhead
to each message. to each message.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
occur, the server MUST send the stream error as a complete element in occur, the server MUST send the stream error as a complete element in
a message to the client. a message to the client.
If the error occurs during the opening of a stream, the server MUST If the error occurs during the opening of a stream, the server MUST
send the initial open element response, followed by the stream level send the initial open element response, followed by the stream level
error in a second WebSocket message frame. The server MUST then error in a second WebSocket message frame. The server MUST then
close the connection as specified in Section 3.6. close the connection as specified in Section 3.6.
3.6. Closing the Connection 3.6. Closing the Connection
The closing process for the XMPP sub-protocol mirrors that of the
XMPP TCP binding as defined in Section 4.4 of [RFC6120], except that
a <close/> element is used instead of the ending </stream:stream>
tag.
Either the server or the client may close the connection at any time. Either the server or the client may close the connection at any time.
Before closing the connection, the closing party SHOULD close the Before closing the connection, the closing party is expected to first
XMPP stream, if it has been established, by sending a message with close the XMPP stream (if one has been opened) by sending a message
the <close/> element, qualified by the "urn:ietf:params:xml:ns:xmpp- with the <close/> element, qualified by the "urn:ietf:params:xml:ns
framing" namespace. The stream is considered closed when a :xmpp-framing" namespace. The stream is considered closed when a
corresponding <close/> element is received from the other party. corresponding <close/> element is received from the other party, and
the XMPP session is ended.
To close the WebSocket connection, the closing party MUST initiate To then close the WebSocket connection, the closing party MUST
the WebSocket closing handshake (see Section 7.1.2 of [RFC6455]). initiate the WebSocket closing handshake (see Section 7.1.2 of
[RFC6455]).
An example of ending an XMPP over WebSocket session by first closing An example of ending an XMPP over WebSocket session by first closing
the XMPP stream layer and then the WebSocket connection layer: the XMPP stream layer and then the WebSocket connection layer:
Client (XMPP WSS) Server Client (XMPP WSS) Server
| | | | | | | |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing /> | | | | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing /> | |
| |------------------------------------------------------------>| | | |------------------------------------------------------------>| |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | | | | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
| |<------------------------------------------------------------| | | |<------------------------------------------------------------| |
skipping to change at page 7, line 40 skipping to change at page 7, line 47
| +-------------------------------------------------------------+ | | +-------------------------------------------------------------+ |
| | | |
| WS CLOSE FRAME | | WS CLOSE FRAME |
|------------------------------------------------------------------>| |------------------------------------------------------------------>|
| WS CLOSE FRAME | | WS CLOSE FRAME |
|<------------------------------------------------------------------| |<------------------------------------------------------------------|
| | | |
| (Connection Closed) | | (Connection Closed) |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
If a client closes the WebSocket connection without closing the XMPP If the WebSocket connection is closed or broken without the XMPP
stream after having enabled stream management (see Section 3.10), the stream having been closed first, then the XMPP stream is considered
server SHOULD keep the XMPP session alive for a period of time based implicitly closed and the XMPP session ended; however, if the use of
on server policy, as specified in [XEP-0198]. If the client has not stream management resumption was negotiated (see [XEP-0198]), the
negotiated the use of [XEP-0198], there is no distinction between a server SHOULD consider the XMPP session still alive for a period of
stream that was closed as described above and a simple disconnection; time based on server policy as specified in [XEP-0198].
the stream is then considered implicitly closed and the XMPP session
ended.
3.6.1. see-other-uri 3.6.1. see-other-uri
If the server (or a connection manager intermediary) wishes to If the server (or a connection manager intermediary) wishes at any
instruct the client to move to a different WebSocket endpoint (e.g. point to instruct the client to move to a different WebSocket
for load balancing purposes), the server MAY send a <close/> element endpoint (e.g. for load balancing purposes), the server MAY send a
and set the "see-other-uri" attribute to the URI of the new <close/> element and set the "see-other-uri" attribute to the URI of
connection endpoint (which MAY be for a different transport method, the new connection endpoint (which MAY be for a different transport
such as BOSH (see [XEP-0124] and [XEP-0206]). method, such as BOSH (see [XEP-0124] and [XEP-0206]).
Clients MUST NOT accept suggested endpoints with a lower security Clients MUST NOT accept suggested endpoints with a lower security
context (e.g. moving from a "wss://" endpoint to a "ws://" or "http:/ context (e.g. moving from a "wss://" endpoint to a "ws://" or "http:/
/" endpoint). /" endpoint).
An example of the server closing a stream and instructing the client An example of the server closing a stream and instructing the client
to connect at a different WebSocket endpoint: to connect at a different WebSocket endpoint:
S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing"
see-other-uri="wss://otherendpoint.example/xmpp-bind" /> see-other-uri="wss://otherendpoint.example/xmpp-bind" />
skipping to change at page 8, line 44 skipping to change at page 8, line 46
S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" /> S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />
[Streams implicitly closed] [Streams implicitly closed]
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing" C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com" to="example.com"
version="1.0" /> version="1.0" />
3.8. Pings and Keepalives 3.8. Pings and Keepalives
XMPP servers often send "whitespace keepalives" (see Section 4.6.1 of Traditionally, XMPP servers and clients often send "whitespace
[RFC6120]) between stanzas to maintain an XML stream, and XMPP keepalives" (see Section 4.6.1 of [RFC6120]) between stanzas to
clients can do the same as these extra whitespace characters are not maintain an XML stream. However, for the XMPP sub-protocol, each
significant in the protocol. Servers and clients SHOULD use message is required to start with a '<' character, and as such
WebSocket ping control frames instead for this purpose. whitespace keepalives MUST NOT be used.
In some cases, the WebSocket connection might be served by an As alternatives, the XMPP Ping extension [XEP-0199] and the XMPP
intermediary connection manager and not the XMPP server. In these Stream Management extension [XEP-0198] provide pinging mechanisms.
situations, the use of WebSocket ping messages are insufficient to The use of either of these extensions (or both) MAY be used to
test that the XMPP stream is still alive. Both the XMPP Ping determine the state of the connection.
extension [XEP-0199] and the XMPP Stream Management extension
[XEP-0198] provide mechanisms to ping the XMPP server, and either Clients and servers MAY also use WebSocket ping control frames for
extension (or both) MAY be used to determine the state of the this purpose, but note that some environments, such as browsers, do
connection. not provide access for generating or monitoring ping control frames.
3.9. Use of TLS 3.9. Use of TLS
TLS cannot be used at the XMPP sub-protocol layer because the sub- TLS cannot be used at the XMPP sub-protocol layer because the sub-
protocol does not allow for raw binary data to be sent. Instead, protocol does not allow for raw binary data to be sent. Instead,
enabling TLS SHOULD be done at the WebSocket layer using secure when TLS is used, it MUST be enabled the WebSocket layer using secure
WebSocket connections via the |wss| URI scheme. (See Section 10.6 of WebSocket connections via the |wss| URI scheme. (See Section 10.6 of
[RFC6455].) [RFC6455].)
Because TLS is to be provided outside of the XMPP sub-protocol layer, Because TLS is to be provided outside of the XMPP sub-protocol layer,
a server MUST NOT advertise TLS as a stream feature (see Section 4.6 a server MUST NOT advertise TLS as a stream feature (see Section 4.6
of [RFC6120]), and a client MUST ignore any advertised TLS stream of [RFC6120]), and a client MUST ignore any advertised TLS stream
feature, when using the XMPP sub-protocol. feature, when using the XMPP sub-protocol.
3.10. Stream Management 3.10. Stream Management
 End of changes. 14 change blocks. 
46 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/