One document matched: draft-ietf-xmpp-websocket-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcprocack="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc linkmailto="yes"?>
<?rfc strict="yes"?>
<rfc docName="draft-ietf-xmpp-websocket-00"
category="std" ipr="trust200902">
<front>
<title abbrev="XMPP over WebSocket">
An XMPP Sub-protocol for WebSocket
</title>
<author initials="L." surname="Stout" fullname="Lance Stout"
role="editor">
<organization>&yet</organization>
<address>
<email>lance@andyet.net</email>
</address>
</author>
<author initials="J." surname="Moffitt" fullname="Jack Moffitt">
<organization>Mozilla</organization>
<address>
<email>jack@metajack.im</email>
</address>
</author>
<author initials="E." surname="Cestari" fullname="Eric Cestari">
<organization>cstar industries</organization>
<address>
<email>eric@cestari.info</email>
</address>
</author>
<date day="5" month="September" year="2013"/>
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>WebSocket</keyword>
<keyword>XMPP</keyword>
<abstract>
<t>
This document defines a binding for the XMPP protocol over a
WebSocket transport layer. A WebSocket binding for XMPP
provides higher performance than the current HTTP binding for
XMPP.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Applications using XMPP (see <xref target="RFC6120"/>
and <xref target="RFC6121"/>) on the Web currently make
use of BOSH (see <xref target="XEP-0124"/> and
<xref target="XEP-0206"/>), an XMPP binding to HTTP. BOSH is
based on the HTTP long polling technique, and it suffers from
high transport overhead compared to XMPP's native binding
to TCP. In addition, there are a number of other known
issues with long polling <xref target="RFC6202"/>, which have
an impact on BOSH-based systems.
</t>
<t>
It would be much better in most circumstances to avoid
tunneling XMPP over HTTP long polled connections and instead
use the XMPP protocol directly. However, the APIs and sandbox
that browsers have provided do not allow this. The WebSocket
protocol <xref target="RFC6455"/> now exists to solve these
kinds of problems. The WebSocket protocol is a bi-directional
protocol that provides a simple message-based framing layer
over raw sockets and allows for more robust and efficient
communication in web applications.
</t>
<t>
The WebSocket protocol enables two-way communication
between a client and a server, effectively emulating TCP
at the application layer and therefore overcoming many of
the problems with existing long-polling techniques for
bidirectional HTTP. This document defines a WebSocket
sub-protocol for the Extensible Messaging and Presence
Protocol (XMPP).
</t>
</section>
<section title="Terminology">
<t>
The basic unit of framing in the WebSocket protocol is called
a message. In XMPP, the basic unit is the stanza, which is a
subset of the first-level children of each document in an XMPP
stream (see Section 9 of <xref target="RFC6120"/>). XMPP also
has a concept of messages, which are stanzas whose top-level
element name is message. In this document, the word "message"
will mean a WebSocket message, not an XMPP message stanza (see
<xref target="messages"/>).
</t>
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
<section title="XMPP Sub-Protocol">
<section title="Handshake">
<t>
The XMPP sub-protocol is used to transport XMPP over a
WebSocket connection. The client and server agree to this
protocol during the WebSocket handshake (see Section 1.3 of
<xref target="RFC6455"/>).
</t>
<t>
During the WebSocket handshake, the client MUST include the
|Sec-WebSocket-Protocol| header in its handshake, and the
value |xmpp| MUST be included in the list of protocols. The
reply from the server MUST also contain |xmpp| in its own
|Sec-WebSocket-Protocol| header in order for an XMPP
sub-protocol connection to be established.
</t>
<t>
Once the handshake is complete, WebSocket messages sent or
received will conform to the protocol defined in the rest of
this document.
</t>
<t>
<figure>
<artwork><![CDATA[
C: GET /xmpp-websocket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
...
Sec-WebSocket-Protocol: xmpp
Sec-WebSocket-Version: 13
S: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
...
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: xmpp
[WebSocket connection established]
C: <stream:stream xmlns:stream="http://etherx.jabber.org/streams"
xmlns="jabber:client"
to="example.com"
version="1.0">
]]></artwork>
</figure>
</t>
</section>
<section title="Messages" anchor="messages">
<t>
Data frame messages in the XMPP sub-protocol MUST be of the
text type and contain UTF-8 encoded data. The close control
frame's contents are specified in <xref target="closing"/>.
Control frames other than close are not restricted.
</t>
<t>
Unless noted in text, the word "message" will mean a
WebSocket message composed of text data frames.
</t>
</section>
<section title="XMPP Stream Setup" anchor="setup">
<t>
The first message sent after the handshake is complete MUST
be an XMPP opening stream tag as defined in XMPP <xref
target="RFC6120"/> or an XML text declaration (see Section
4.3.1 of <xref target="W3C.REC-xml-20081126"/>) followed by
an XMPP opening stream tag. The stream tag MUST NOT be
closed (i.e. the closing </stream:stream> tag should not
appear in the message) as it is the start of the client's
outgoing XML. The '<' character of the tag or text
declaration MUST be the first character of the text payload.
</t>
<t>
The server MUST respond with a message containing an error
(see <xref target="errors"/>), its own opening stream tag,
or an XML text declaration followed by an opening stream
tag.
</t>
<t>
Except in the case of certain stream errors (see
<xref target="errors"/>), the opening stream tag,
<stream:stream>, MUST appear in a message by itself.
</t>
</section>
<section title="Stream Errors" anchor="errors">
<t>
Stream level errors in XMPP are terminal. Should such an
error occur, the server MUST send the stream error as a
complete element in a message to the client.
</t>
<t>
If the error occurs during the opening of a stream, the
stream error message MUST start with an opening stream tag
(see Section 4.7.1 of <xref target="RFC6120"/>) and end with
a closing stream tag.
</t>
<t>
After the stream error and closing stream tag have been
sent, the server MUST close the connection as in
<xref target="closing"/>.
</t>
</section>
<section title="Closing the Connection" anchor="closing">
<t>
Either the server or the client may close the connection at any
time. Before closing the connection, the closing party SHOULD
close the XMPP stream, if it has been established, by sending a
message with the closing </stream:stream> tag. The XMPP
stream is considered closed when a corresponding </stream:stream>
tag is received from the other party.
</t>
<t>
If a client closes the WebSocket connection without closing the
XMPP stream after having enabled stream management (see
<xref target="sm"/>), the server SHOULD keep the XMPP session alive
for a period of time based on server policy, as specified in
<xref target="XEP-0198"/>.
</t>
<t>
To initiate closing the WebSocket connection, the closing
party MUST send a normal WebSocket close message with
an empty body. The connection is considered closed when a
matching close message is received (see Section 1.4 of
<xref target="RFC6455"/>).
</t>
<t>
Except in the case of certain stream errors (see
<xref target="errors"/>), the closing stream tag,
</stream:stream>, MUST appear in a message by itself.
</t>
<figure>
<preamble>
An example of ending an XMPP over WebSocket session by first
closing the XMPP stream layer and then the WebSocket connection
layer:
</preamble>
<artwork><![CDATA[
Client (XMPP WSS) Server
| | | |
| | </stream:stream> | |
| |------------------------------------>| |
| | </stream:stream> | |
| |<------------------------------------| |
| | | |
| | (XMPP Stream Closed) | |
| +-------------------------------------+ |
| |
| WS CLOSE FRAME |
|------------------------------------------>|
| WS CLOSE FRAME |
|<------------------------------------------|
| |
| (Connection Closed) |
+-------------------------------------------+
]]></artwork>
</figure>
</section>
<section title="Stanzas">
<t>
Each XMPP stanza MUST be sent in its own message. A stanza
MUST NOT be split over multiple messages. All first level
children of the <stream:stream> element MUST be treated
the same as stanzas (e.g. <stream:features> and
<stream:error>).
</t>
</section>
<section title="Stream Restarts">
<t>
After successful SASL authentication, an XMPP stream needs
to be restarted. In these cases, as soon as the message is
sent (or received) containing the success indication, both
the server and client streams are implicitly closed, and
new streams need to be opened. The client MUST open a new
stream as in <xref target="setup"/> and MUST NOT send a
closing stream tag.
</t>
<figure>
<artwork><![CDATA[
S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />
[Streams implicitly closed]
C: <stream:stream xmlns:stream="http://etherx.jabber.org/streams"
xmlns="jabber:client"
to="example.com"
version="1.0">
]]></artwork></figure>
</section>
<section title="Pings and Keepalives">
<t>
XMPP servers send whitespace pings as keepalives between
stanzas, and XMPP clients can do the same as these extra
whitespace characters are not significant in the protocol.
Servers and clients SHOULD use WebSocket ping control
frames instead for this purpose.
</t>
<t>
In some cases, the WebSocket connection might be served by
an intermediary connection manager and not the XMPP server.
In these situations, the use of WebSocket ping messages are
insufficient to test that the XMPP stream is still alive.
Both the XMPP Ping extension <xref target="XEP-0199"/> and
the XMPP Stream Management extension <xref target="XEP-0198"/>
provide mechanisms to ping the XMPP server, and either extension
(or both) MAY be used to determine the state of the connection.
</t>
</section>
<section title="Use of TLS" anchor="tls">
<t>
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, enabling TLS SHOULD be done at the WebSocket layer
using secure WebSocket connections via the |wss| URI scheme.
(See Section 10.6 of <xref target="RFC6455"/>).
</t>
<t>
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 of
<xref target="RFC6120"/>), and a client MUST ignore any
advertised TLS stream feature, when using the XMPP
sub-protocol.
</t>
</section>
<section title="Stream Management" anchor="sm">
<t>
In order to alleviate the problems of temporary disconnections,
the XMPP Stream Management extension <xref target="XEP-0198"/>
MAY be used to confirm when stanzas have been received by the server.
</t>
<t>
In particular, the use of session resumption in
<xref target="XEP-0198"/> MAY be used to allow for recreating
the same stream session state after a temporary network
unavailability or after navigating to a new URL in a browser.
</t>
</section>
</section>
<section title="Discovering Connection Method">
<t>
The XMPP extension Discovering Alternate XMPP Connection Methods
<xref target="XEP-0156"/> provides a mechanism to discover
the additional information needed to connect to an XMPP server
outside of the procedure defined in in Section 3 of
<xref target="RFC6120"/>.
</t>
<t>
For the XMPP over Websocket connection type, the connection
method name "_xmpp-client-websocket" is used to specify a
URI for the server's WebSocket connection endpoint.
</t>
<figure>
<preamble>
An example entry advertising that the URI "wss://example.com/xmpp"
is an XMPP over WebSocket endpoint, using a DNS TXT record
as specified in <xref target="XEP-0156"/>:
</preamble>
<artwork><![CDATA[
_xmppconnect IN TXT "_xmpp-client-websocket=wss://example.com/xmpp"
]]></artwork>
</figure>
<t>
Implementation Note: A server is able to expose both BOSH <xref
target="XEP-0206"/> and WebSocket endpoints over the registered port
5280, using the URI path and connection upgrade headers to determine
which transport to serve.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
Since application level TLS cannot be used (see <xref
target="tls"/>), applications which need to protect the privacy
of the XMPP traffic need to do so at the WebSocket or other
appropriate layer.
</t>
<t>
The Security Considerations for both WebSocket (See Section
10 of <xref target="RFC6455"/> and XMPP (See Section 13 of
<xref target="RFC6120"/>) apply to the WebSocket XMPP
sub-protocol.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This specification requests IANA to register the WebSocket XMPP
sub-protocol under the "WebSocket Subprotocol Name" Registry
with the following data:
<list style="hanging">
<t hangText="Subprotocol Identifier:">
xmpp
</t>
<t hangText="Subprotocol Common Name:">
WebSocket Transport for the Extensible Messaging and
Presence Protocol (XMPP)
</t>
<t hangText="Subprotocol Definition:">
RFC XXXX
</t>
</list>
</t>
<t>
[[NOTE TO RFC EDITOR: Please change XXXX to the number assigned
to this document upon publication.]]
</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6120.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6121.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6202.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-20081126.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0124.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0199.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0156.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0206.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0198.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:52 |