One document matched: draft-ietf-xmpp-websocket-09.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-09"
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>
To date, applications using the Extensible Messaging and
Presence Protocol (XMPP) (see <xref target="RFC6120"/>
and <xref target="RFC6121"/>) on the Web have made
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,
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>
<t>
The WebSocket binding for XMPP is designed for use by
browser-based applications (e.g., XMPP clients written in
JavaScript). These applications typically are used to
access the same information and communication opportunities
(e.g., the same XMPP "roster" of contacts) as clients that
access connect to an XMPP server over the TCP binding
defined in <xref target='RFC6120'/>. Although the only
essential difference is the underlying transport binding,
relevant implications (e.g., framing methods and discovery
processes) are highlighted in this specification.
</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>
If a client receives a handshake response that does not include
'xmpp' in the 'Sec-WebSocket-Protocol' header, then a XMPP sub-protocol
WebSocket connection was not established and the client MUST
close the WebSocket connection.
</t>
<t>
Once the handshake has successfully completed, WebSocket messages sent or
received MUST conform to the protocol defined in the rest of
this document.
</t>
<t>
<figure>
<preamble>
The following is an example of a WebSocket handshake, followed
by opening an XMPP stream:
</preamble>
<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 framing method for the binding of XMPP to WebSocket differs from the
framing method for the TCP binding as defined in <xref target="RFC6120"/>;
in particular, the WebSocket binding adopts 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. Inclusions of declarations 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 fatal. 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), then a <close/> element is sent with the
'see-other-uri' attribute set 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 (see Section 4.3.3 of
<xref target="RFC6120"/>), both the server and
client streams are implicitly closed and new streams MUST
be opened, using the same process as in <xref target="setup"/>.
</t>
<t>
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.
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 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"/>) when using the XMPP
sub-protocol. Likewise, 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 client MAY use the XMPP Stream Management extension <xref target="XEP-0198"/>
to confirm when stanzas have been received by the server.
</t>
<t>
In particular, the client MAY use session resumption in <xref target="XEP-0198"/>
to recreate the same stream session state after a temporary network
unavailability or after navigating to a new URL in a browser.
</t>
</section>
</section>
<section anchor='discovery' 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 using Domain Name System
service (DNS SRV) records <xref target="RFC2782"/>. 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 DNS.
</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"/>. Conceptually, the host-meta lookup
process used for the WebSocket binding is analogous to the DNS SRV
lookup process used for the TCP binding. The process is as follows.
</t>
<t>
<list style='numbers'>
<t>Send a request over secure HTTP to the path "/.well-known/host-meta" at an HTTP origin <xref target='RFC6454'/> that matches the XMPP service domain (e.g., a URL of "https://im.example.org/.well-known/host-meta" if the XMPP service domain is "im.example.org").</t>
<t>Retrieve a host-meta document specifying a link relation type of "urn:xmpp:alt-connections:websocket", such as:
<figure>
<artwork><![CDATA[
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel="urn:xmpp:alt-connections:websocket"
href="wss://im.example.org:443/ws" />
</XRD>
]]></artwork>
</figure>
</t>
</list>
</t>
<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>
In cases where the XMPP service domain does not match the web
origin of the WebSocket endpoint, the Web-host metadata MAY be
used to establish trust between the XMPP server domain and the
WebSocket endpoint as long as the host-meta request and
response occurred over secure HTTP; this is especially relevant
in multi-tenant situations where the same WebSocket endpoint is
serving multiple XMPP domains (e.g., the XMPP service domains
for both "example.com" and "im.example.org" might be serviced
by the same WebSocket endpoint at "hosting.example.net"). See
<xref target='security'/> for related discussion.
</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. There are two cases:</t>
<t>
<list style='numbers'>
<t>
If the XMPP service domain matches the origin for the WebSocket
connection, the relevant check is already performed by the
browser. For example, the XMPP service domain might be
"foo.example" and the WebSocket endpoint discovered for the
link relation type of "urn:xmpp:alt-connections:websocket" might
be "wss://foo.example/websocket". As long as the certificate
provided over WebSocket or HTTPS is verified according to the
rules defined for secure HTTP <xref target='RFC2818'/>, then
the browser will report the successful establishment of a
secure connection to the application. (However, as noted, the
application is still not able to independently inspect and
verify the certificate, and needs to trust the browser; this
is a limitation of existing browser technologies, and thus
cannot be worked around by WebSocket applications.)
</t>
<t>
In situations where the domain of the XMPP server does not
match the web origin of the WebSocket endpoint (such as
multi-tenant hosting situations, the host-meta process
described under <xref target='discovery'/>) MAY be used to
delegate trust from the XMPP server domain to the WebSocket
origin, as long as the host-meta request and response
occurred over secure HTTP (with appropriate certificate
verification as defined in <xref target='RFC2818'/>).
</t>
</list>
</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.2818.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.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.6415.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.2782.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.6454.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="Acknowledgements" anchor="acknowledgements">
<t>The authors wish to thank the following individuals for their feedback:
Andreas Guth,
Bjoern Hoerhmann,
Dave Cridland,
Florian Zeitz,
Kurt Zeilenga,
Matt Miller,
Matthew Wild,
Paul Aurich,
Sergey Dobrov,
Waqas Hussain.
</t>
<t>Dan Romascanu reviewed the document on behalf of the General Area Review Team.</t>
<t>During IESG review,
Barry Leiba
Benoit Claise,
Dan Romasanu,
Jari Arkko,
Juergen Schoenwaelder,
Spencer Dawkins,
Stephen Farrell,
Ted Lemon,
Kathleen Moriarty,
Pete Resnick
caught several issues that needed to be addressed.</t>
<t>The authors gratefully acknowledge the assistance of Peter Saint-Andre as document
shepherd, Ben Campbell and Joe Hildebrand as the working group chairs, and Richard
Barnes as the sponsoring Area Director.</t>
</section>
<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:43 |