One document matched: draft-ietf-xmpp-websocket-07.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-07"
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@cstar.io</email>
</address>
</author>
<date/>
<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 the Extensible Messaging and Presence
Protocol (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"/> exists to solve these
kinds of problems and is a bidirectional
protocol that provides a simple message-based framing layer
over raw sockets, allowing 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 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 with a top-level
element of <message/>. In this document, the word "message"
will mean a WebSocket message, not an XMPP message stanza, unless
otherwise noted.
</t>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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 value
|xmpp| in the list of protocols for the |Sec-WebSocket-Protocol|
header. 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: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
from="example.com"
id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
xml:lang="en"
version="1.0" />
]]></artwork>
</figure>
</t>
</section>
<section title="WebSocket Messages" anchor="messages">
<t>
Data frame messages in the XMPP sub-protocol MUST be of the
text type and contain UTF-8 encoded data.
</t>
</section>
<section title="XMPP Framing">
<t>
The WebSocket XMPP sub-protocol deviates from the standard method of
constructing and using XML streams as defined in <xref target="RFC6120"/> by
adopting the message framing provided by WebSocket to delineate the stream
open and close headers, stanzas, and other top-level stream elements.
</t>
<section title="Framed XML Stream">
<t>
The start of a framed XML stream is marked by the use of an opening "stream
header" which is an <open/> element with the appropriate attributes
and namespace declarations (see <xref target="framed-stream-namespace"/>). The
attributes of the <open/> element are the same as those of the <stream/>
element defined defined for the 'http://etherx.jabber.org/streams' namespace
in <xref target="RFC6120"/> and with the same semantics and restrictions.
</t>
<t>
The end of a framed XML stream is denoted by the closing "stream header"
which is a <close/> element with its associated attributes and
namespace declarations (see <xref target="framed-stream-namespace"/>).
</t>
<t>
The introduction of the <open/> and <close/> elements is motivated
by the parsable XML document framing restriction in <xref target="frames"/>.
As a consequence, note that a framed XML stream does not
provided a wrapping <stream:stream/> element encompassing the entirety
of the XML stream, as in <xref target="RFC6120"/>.
</t>
</section>
<section title="Framed Stream Namespace" anchor="framed-stream-namespace">
<t>
The XML stream "headers" (the <open/> and <close/> elements)
MUST be qualified by the namespace 'urn:ietf:params:xml:ns:xmpp-framing'
(the "framed stream namespace"). If this rule is violated, the entity that
receives the offending stream header MUST close the stream with an error,
which MUST be <invalid-namespace> (see Section 4.9.3.10 of
<xref target="RFC6120"/>).
</t>
</section>
<section title="Stream Frames" anchor="frames">
<t>
The individual frames of a framed XML stream have a one-to-one correspondence
with WebSocket messages, and MUST be parsable as standalone XML documents,
complete with all relevant namespace and language declarations. The inclusion
of XML declarations, however, is NOT RECOMMENDED as WebSocket messages are already
mandated to be UTF-8 encoded and therefore would only add a constant size overhead to each
message.
</t>
<t>
The first character of each frame MUST be a '<' character.
</t>
<t>
Every XMPP stanza or other XML element (including the stream open and close headers)
sent directly over the XML stream MUST be sent in its own frame.
</t>
<figure>
<preamble>
Example of a WebSocket message that contains an independently
parsable XML document:
</preamble>
<artwork><![CDATA[
<message xmlns="jabber:client" xml:lang="en">
<body>Every WebSocket message is parsable by itself.</body>
</message>
]]></artwork>
</figure>
<figure>
<preamble>
Note that for stream features and
errors, there is no parent context element providing the
"stream" namespace prefix as in <xref target="RFC6120"/>,
and thus the stream prefix MUST be declared or use
an unprefixed form:
</preamble>
<artwork><![CDATA[
<stream:features xmlns:stream="http://etherx.jabber.org/streams">
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
</stream:features>
-- OR --
<error xmlns="http://etherx.jabber.org/streams">
<host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</error>
]]></artwork>
</figure>
</section>
</section>
<section title="Stream Initiation" anchor="setup">
<t>
The first message sent after the WebSocket opening handshake MUST be from the initiating entity, and
MUST be an <open/> element qualified by the "urn:ietf:params:xml:ns:xmpp-framing"
namespace and with the same attributes mandated for the <stream> opening tag as described
in Section 4.7 of <xref target="RFC6120"/>.
</t>
<t>
The receiving entity MUST respond with either an <open /> element (whose attributes match
those described in Section 4.7 of <xref target="RFC6120"/>) or
a <close /> element (see <xref target="see-other-uri"/>).
</t>
<figure>
<preamble>
An example of a successful stream initiation exchange:
</preamble>
<artwork><![CDATA[
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
from="example.com"
id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
xml:lang="en"
version="1.0" />
]]></artwork>
</figure>
<t>
Clients MUST NOT multiplex XMPP streams over the same WebSocket.
</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
server MUST send the initial open element response, followed by
the stream level error in a second WebSocket message frame. The
server MUST then close the connection as specified in <xref target="closing"/>.
</t>
</section>
<section title="Closing the Connection" anchor="closing">
<t>
The closing process for the XMPP sub-protocol mirrors that of
the XMPP TCP binding as defined in Section 4.4 of <xref target="RFC6120"/>,
except that a <close/> element is used instead of the
ending </stream:stream> tag.
</t>
<t>
Either the server or the client may close the connection at any
time. Before closing the connection, the closing party is expected
to first close the XMPP stream (if one has been opened) by sending a
message with the <close/> element, qualified by
the "urn:ietf:params:xml:ns:xmpp-framing" namespace. The
stream is considered closed when a corresponding <close/>
element is received from the other party, and the XMPP session is ended.
</t>
<t>
To then close the WebSocket connection, the closing
party MUST initiate the WebSocket closing handshake (see Section 7.1.2 of
<xref target="RFC6455"/>).
</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
| | | |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing /> | |
| |------------------------------------------------------------>| |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
| |<------------------------------------------------------------| |
| | | |
| | (XMPP Stream Closed) | |
| +-------------------------------------------------------------+ |
| |
| WS CLOSE FRAME |
|------------------------------------------------------------------>|
| WS CLOSE FRAME |
|<------------------------------------------------------------------|
| |
| (Connection Closed) |
+-------------------------------------------------------------------+
]]></artwork>
</figure>
<t>
If the WebSocket connection is closed or broken without the XMPP stream having
been closed first, then the XMPP stream is considered implicitly closed
and the XMPP session ended; however, if the use of stream management
resumption was negotiated (see <xref target="XEP-0198"/>), the server
SHOULD consider the XMPP session still alive for a period of time based
on server policy as specified in <xref target="XEP-0198"/>.
</t>
<section title="see-other-uri" anchor="see-other-uri">
<t>
If the server wishes at any point to instruct
the client to move to a different WebSocket endpoint (e.g. for load balancing
purposes), the server MAY send a <close/> element and set the
"see-other-uri" attribute to the URI of the new connection endpoint (which MAY be
for a different transport method, such as BOSH (see <xref target="XEP-0124"/> and
<xref target="XEP-0206"/>).
</t>
<t>
Clients MUST NOT accept suggested endpoints with a lower security context (e.g. moving
from a "wss://" endpoint to a "ws://" or "http://" endpoint).
</t>
<figure>
<preamble>
An example of the server closing a stream and instructing the client
to connect at a different WebSocket endpoint:
</preamble>
<artwork><![CDATA[
S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing"
see-other-uri="wss://otherendpoint.example/xmpp-bind" />
]]></artwork>
</figure>
</section>
</section>
<section title="Stream Restarts">
<t>
Whenever a stream restart is mandated, both the server and
client streams are implicitly closed and new streams MUST
be opened, using the same process as in <xref target="setup"/>.
The client MUST send a new stream <open/> element and MUST
NOT send a closing <close/> element.
</t>
<figure>
<preamble>
An example of restarting the stream after successful SASL negotiation:
</preamble>
<artwork><![CDATA[
S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />
[Streams implicitly closed]
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
]]></artwork></figure>
</section>
<section title="Pings and Keepalives">
<t>
Traditionally, XMPP servers and clients often send "whitespace keepalives" (see Section 4.6.1
of <xref target='RFC6120'/>) between stanzas to maintain an XML
stream. However, for the XMPP sub-protocol, each message is required
to start with a '<' character, and as such whitespace keepalives
MUST NOT be used.
</t>
<t>
As alternatives, the XMPP Ping extension <xref target="XEP-0199"/> and the XMPP Stream
Management extension <xref target="XEP-0198"/> provide pinging mechanisms.
The use of either of these extensions (or both) MAY be used to determine the state
of the connection.
</t>
<t>
Clients and servers MAY also use WebSocket ping control frames for this purpose, but
note that some environments, such as browsers, do not provide access for generating
or monitoring ping control frames.
</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, 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 <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 the WebSocket Connection Method">
<t>
Section 3 of <xref target="RFC6120"/> defines a procedure for
connecting to an XMPP server, including ways to discover the
TCP/IP address and port of the server. When using the WebSocket
binding as specified in this document (instead of the
TCP binding as specified in <xref target="RFC6120"/>), a client
needs an alternative way to discover information about the
server's connection methods, since web browsers and other
WebSocket-capable software applications typically cannot obtain
such information from the Domain Name System.
</t>
<t>
The alternative lookup process uses Web Host Metadata
<xref target='RFC6415'/> and Web Linking <xref target='RFC5988'/>,
where the link relation type is "urn:xmpp:alt-connections:websocket"
as described in Discovering Alternate XMPP Connection Methods
<xref target="XEP-0156"/>. An example follows.
</t>
<figure>
<artwork><![CDATA[
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel="urn:xmpp:alt-connections:websocket"
href="wss://webcm.example.net:443/ws" />
</XRD>
]]></artwork>
</figure>
<t>
Servers MAY expose discovery information using host-meta documents,
and clients MAY use such information to determine the WebSocket
endpoint for a server.
</t>
<t>
Use of web-host metadata MAY be used to establish trust between the
XMPP server domain and the WebSocket endpoint, particularly in
multi-tenant situations where the same WebSocket endpoint is
serving multiple XMPP domains.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<section anchor="iana-ws" title="WebSocket Subprotocol Name">
<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:">
this document
</t>
</list>
</t>
</section>
<section anchor="iana-ns" title="URN Sub-Namespace">
<t>A URN sub-namespace for framing of Extensible Messaging and Presence Protocol (XMPP) streams is defined as follows.</t>
<t>
<list style='hanging'>
<t hangText='URI:'>urn:ietf:params:xml:ns:xmpp-framing</t>
<t hangText='Specification:'>this document</t>
<t hangText='Description:'>This is the XML namespace name for framing of Extensible Messaging and Presence Protocol (XMPP) streams as defined by RFC XXXX.</t>
<t hangText='Registrant Contact:'>IESG <iesg@ietf.org></t>
</list>
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
Since application level TLS cannot be used (see <xref
target="tls"/>), applications need to protect the privacy
of XMPP traffic at the WebSocket or other appropriate layer.
</t>
<t>
Browser based applications are not able to inspect
and verify at the application layer the certificate used for the WebSocket connection to ensure
that it corresponds to the domain specified as the "to" address
of the XMPP stream. For hosts whose domain matches the origin for the
WebSocket connection, that check is already performed by the browser.
However, in situations where the domain of the XMPP server
might not match the origin for the WebSocket endpoint (especially multi-tenant
hosting situations), the web host metadata method (see
<xref target='RFC6415'/> and <xref target="XEP-0156"/>) MAY be used to
delegate trust from the XMPP server domain to the WebSocket origin.
</t>
<t>
When presented with a new WebSocket endpoint via the "see-other-uri" attribute
of a <close/> element, clients MUST NOT accept the suggestion if the security
context of the new endpoint is lower than the current one in order to prevent downgrade
attacks from a "wss://" endpoint to "ws://".
</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 anchor="security-intermediary" title="Intermediary Services">
<t>
If the XMPP over WebSocket endpoint is provided as an intermediary service between a backend
XMPP service and the client, then it SHOULD encrypt its connection to the backend XMPP service
using any available and appropriate technologies, such as TLS and StartTLS.
</t>
<t>
If data privacy is desired, a client SHOULD encrypt its messages using an
application specific end-to-end encryption technology, as there is no way for the client
to ensure that the XMPP over WebSocket service is using an encryped connection to the
backend XMPP service. Methods for doing so are beyond the scope of this specification.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative 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.6455.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.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.6415.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0124.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0156.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0198.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0199.xml"?>
<?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0206.xml"?>
<reference anchor='XML-SCHEMA'
target='http://www.w3.org/TR/2004/REC-xmlschema-1-20041028'>
<front>
<title>XML Schema Part 1: Structures Second Edition</title>
<author initials='H.' surname='Thompson' fullname='Henry S. Thompson'>
<organization />
</author>
<author initials='M.' surname='Maloney' fullname='Murray Maloney'>
<organization />
</author>
<author initials='N.' surname='Mendelsohn' fullname='Noah Mendelsohn'>
<organization />
</author>
<author initials='D.' surname='Beech' fullname='David Beech'>
<organization />
</author>
<date month='October' day='28' year='2004' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-xmlschema-1-20041028' />
<format type='HTML' target='http://www.w3.org/TR/2004/REC-xmlschema-1-20041028' />
</reference>
</references>
<section title="XML Schema" anchor="schema">
<t>The following schema formally defines the 'urn:ietf:params:xml:ns:xmpp-framing' namespace used in this document, in conformance with W3C XML Schema <xref target='XML-SCHEMA'/>. Because validation of XML streams and stanzas is optional, this schema is not normative and is provided for descriptive purposes only.</t>
<figure>
<artwork><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-framing'
xmlns='urn:ietf:params:xml:ns:xmpp-framing'
elementFormDefault='unqualified'>
<xs:element name='open'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='from' type='xs:string'
use='optional'/>
<xs:attribute name='id' type='xs:string'
use='optional'/>
<xs:attribute name='to' type='xs:string'
use='optional'/>
<xs:attribute name='version' type='xs:decimal'
use='optional'/>
<xs:attribute ref='xml:lang'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='close'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='from' type='xs:string'
use='optional'/>
<xs:attribute name='id' type='xs:string'
use='optional'/>
<xs:attribute name='see-other-uri' type='xs:anyURI'
use='optional'/>
<xs:attribute name='to' type='xs:string'
use='optional'/>
<xs:attribute name='version' type='xs:decimal'
use='optional'/>
<xs:attribute ref='xml:lang'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:43 |