One document matched: draft-ietf-xmpp-websocket-02.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-02"
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/>
<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. The WebSocket protocol is a bidirectional
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 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", "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: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
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>
</section>
<section title="XMPP Stream Setup" anchor="setup">
<t>
The first message sent after the handshake is complete MUST
be an <open/> element qualified by the "urn:ietf:params:xml:ns:xmpp-framing"
namespace. The 'from', 'id', 'to', and 'version' attributes of this element mirror those of the XMPP
opening stream tag as defined for the 'http://etherx.jabber.org/streams' namespace in XMPP <xref
target="RFC6120"/>. The '<' character of the open tag
MUST be the first character of the text payload.
</t>
<t>
The server MUST respond with an <open /> element, or
a <close /> element (see <xref target="see-other-uri"/>).
</t>
<t>
Clients MUST NOT attempt to multiplex XMPP streams for multiple
JIDs 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>
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 <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.
</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>
<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 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"/>. If the client has not negotiated the
use of <xref target="XEP-0198"/>, there is no distinction between
a stream that was closed as described above and a simple disconnection;
the stream is then considered implicitly closed and the XMPP session
ended.
</t>
<section title="see-other-uri" anchor="see-other-uri">
<t>
If the server (or a connection mananger intermediary) wishes 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 WebSocket endpoint.
</t>
<t>
Clients MUST NOT accept suggested endpoints with a lower security context (e.g. moving
from a "wss://" endpoint to a "ws://" 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="Stanzas">
<t>
Every XMPP stanza or other XML element sent directly over
the XMPP stream (e.g. <features xmlns="http://etherx.jabber.org/streams"/>)
MUST be sent in its own message. As such, every WebSocket text
message that is received MUST be a complete
and parsable XML fragment, with all relevant xmlns and xml:lang
declarations specified.
</t>
<t>
As it is already mandated that the content of each message is
UTF-8 encoded, XML text declarations SHOULD NOT be included
in messages.
</t>
<figure>
<preamble>
Examples of WebSocket messages that contain independently
parsable XML fragments (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 namespace MUST be declared):
</preamble>
<artwork><![CDATA[
<features xmlns="http://etherx.jabber.org/streams">
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
</features>
<error xmlns="http://etherx.jabber.org/streams">
<host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</error>
<message xmlns="jabber:client" xml:lang="en">
<body>Every WebSocket message is parsable by itself.</body>
</message>
]]></artwork>
</figure>
</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 <close/> element.
</t>
<figure>
<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>
XMPP servers often send "whitespace keepalives" (see Section 4.6.1
of <xref target='RFC6120'/>) between stanzas to maintain an XML
stream, 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 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>
</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:39:40 |