RFC 6120
Extensible Messaging and Presence Protocol (XMPP): Core
Pages: 211
Proposed Standard
→ Errata
Obsoletes: 3920
Updated by: 7590 8553
Proposed Standard
→ Errata
Obsoletes: 3920
Updated by: 7590 8553
Part 3 of 9 – Pages 43 to 69
4.8. XML Namespaces
Readers are referred to the specification of XML namespaces [XML-NAMES] for a full understanding of the concepts used in this section, especially the concept of a "default namespace" as provided in Section 3 and Section 6.2 of that specification.4.8.1. Stream Namespace
The root <stream/> element ("stream header") MUST be qualified by the namespace 'http://etherx.jabber.org/streams' (the "stream namespace"). If this rule is violated, the entity that receives the offending stream header MUST close the stream with a stream error, which SHOULD be <invalid-namespace/> (Section 4.9.3.10), although some existing implementations send <bad-format/> (Section 4.9.3.1) instead.4.8.2. Content Namespace
An entity MAY declare a "content namespace" as the default namespace for data sent over the stream (i.e., data other than elements qualified by the stream namespace). If so, (1) the content namespace MUST be other than the stream namespace, and (2) the content namespace MUST be the same for the initial stream and the response stream so that both streams are qualified consistently. The content namespace applies to all first-level child elements sent over the stream unless explicitly qualified by another namespace (i.e., the content namespace is the default namespace).
Alternatively (i.e., instead of declaring the content namespace as
the default namespace), an entity MAY explicitly qualify the
namespace for each first-level child element of the stream, using so-
called "prefix-free canonicalization". These two styles are shown in
the following examples.
When a content namespace is declared as the default namespace, in
rough outline a stream will look something like the following.
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<message>
<body>foo</body>
</message>
</stream:stream>
When a content namespace is not declared as the default namespace and
so-called "prefix-free canonicalization" is used instead, in rough
outline a stream will look something like the following.
<stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='http://etherx.jabber.org/streams'>
<message xmlns='jabber:client'>
<body>foo</body>
</message>
</stream>
Traditionally, most XMPP implementations have used the content-
namespace-as-default-namespace style rather than the prefix-free
canonicalization style for stream headers; however, both styles are
acceptable since they are semantically equivalent.
4.8.3. XMPP Content Namespaces
XMPP as defined in this specification uses two content namespaces:
'jabber:client' and 'jabber:server'. These namespaces are nearly
identical but are used in different contexts (client-to-server
communication for 'jabber:client' and server-to-server communication
for 'jabber:server'). The only difference between the two is that
the 'to' and 'from' attributes are OPTIONAL on stanzas sent over XML streams qualified by the 'jabber:client' namespace, whereas they are REQUIRED on stanzas sent over XML streams qualified by the 'jabber: server' namespace. Support for these content namespaces implies support for the common attributes (Section 8.1) and basic semantics (Section 8.2) of all three core stanza types (message, presence, and IQ). An implementation MAY support content namespaces other than 'jabber: client' or 'jabber:server'. However, because such namespaces would define applications other than XMPP, they are to be defined in separate specifications. An implementation MAY refuse to support any other content namespaces as default namespaces. If an entity receives a first-level child element qualified by a content namespace it does not support, it MUST close the stream with an <invalid-namespace/> stream error (Section 4.9.3.10). Client implementations MUST support the 'jabber:client' content namespace as a default namespace. The 'jabber:server' content namespace is out of scope for an XMPP client, and a client MUST NOT send stanzas qualified by the 'jabber:server' namespace. Server implementations MUST support as default content namespaces both the 'jabber:client' namespace (when the stream is used for communication between a client and a server) and the 'jabber:server' namespace (when the stream is used for communication between two servers). When communicating with a connected client, a server MUST NOT send stanzas qualified by the 'jabber:server' namespace; when communicating with a peer server, a server MUST NOT send stanzas qualified by the 'jabber:client' namespace. Implementation Note: Because a client sends stanzas over a stream whose content namespace is 'jabber:client', if a server routes to a peer server a stanza it has received from a connected client then it needs to "re-scope" the stanza so that its content namespace is 'jabber:server'. Similarly, if a server delivers to a connected client a stanza it has received from a peer server then it needs to "re-scope" the stanza so that its content namespace is 'jabber:client'. This rule applies to XML stanzas as defined under Section 4.1 (i.e., a first-level <message/>, <presence/>, or <iq/> element qualified by the 'jabber:client' or 'jabber:server' namespace), and by namespace inheritance to all child elements of a stanza. However, the rule does not apply to elements qualified by namespaces other than 'jabber:client' and 'jabber:server' nor to any children of such elements (e.g., a <message/> element contained within an extension element
(Section 8.4) for reporting purposes). Although it is not
forbidden for an entity to generate stanzas in which an extension
element contains a child element qualified by the 'jabber:client'
or 'jabber:server' namespace, existing implementations handle such
stanzas inconsistently; therefore, implementers are advised to
weigh the likely lack of interoperability against the possible
utility of such stanzas. Finally, servers are advised to apply
stanza re-scoping to other stream connection methods and
alternative XMPP connection methods, such as those specified in
[XEP-0124], [XEP-0206], [XEP-0114], and [XEP-0225].
4.8.4. Other Namespaces
Either party to a stream MAY send data qualified by namespaces other
than the content namespace and the stream namespace. For example,
this is how data related to TLS negotiation and SASL negotiation are
exchanged, as well as XMPP extensions such as Stream Management
[XEP-0198] and Server Dialback [XEP-0220].
Interoperability Note: For historical reasons, some server
implementations expect a declaration of the 'jabber:server:
dialback' namespace on server-to-server streams, as explained in
[XEP-0220].
However, an XMPP server MUST NOT route or deliver data received over
an input stream if that data is (a) qualified by another namespace
and (b) addressed to an entity other than the server, unless the
other party to the output stream over which the server would send the
data has explicitly negotiated or advertised support for receiving
arbitrary data from the server. This rule is included because XMPP
is designed for the exchange of XML stanzas (not arbitrary XML data),
and because allowing an entity to send arbitrary data to other
entities could significantly increase the potential for exchanging
malicious information. As an example of this rule, the server
hosting the example.net domain would not route the following first-
level XML element from <romeo@example.net> to <juliet@example.com>:
<ns1:foo xmlns:ns1='http://example.org/ns1'
from='romeo@example.net/resource1'
to='juliet@example.com'>
<ns1:bar/>
</ns1:foo>
This rule also applies to first-level elements that look like stanzas
but that are improperly namespaced and therefore really are not
stanzas at all (see also Section 4.8.5), for example:
<ns2:message xmlns:ns2='http://example.org/ns2'
from='romeo@example.net/resource1'
to='juliet@example.com'>
<body>hi</body>
</ns2:message>
Upon receiving arbitrary first-level XML elements over an input
stream, a server MUST either ignore the data or close the stream with
a stream error, which SHOULD be <unsupported-stanza-type/>
(Section 4.9.3.24).
4.8.5. Namespace Declarations and Prefixes
Because the content namespace is other than the stream namespace, if
a content namespace is declared as the default namespace then the
following statements are true:
1. The stream header needs to contain a namespace declaration for
both the content namespace and the stream namespace.
2. The stream namespace declaration needs to include a namespace
prefix for the stream namespace.
Interoperability Note: For historical reasons, an implementation
MAY accept only the prefix 'stream' for the stream namespace
(resulting in prefixed names such as <stream:stream> and <stream:
features>); this specification retains that allowance from
[RFC3920] for the purpose of backward compatibility.
Implementations are advised that using a prefix other than
'stream' for the stream namespace might result in interoperability
problems. If an entity receives a stream header with a stream
namespace prefix it does not accept, it MUST close the stream with
a stream error, which SHOULD be <bad-namespace-prefix/>
(Section 4.9.3.2), although some existing implementations send
<bad-format/> (Section 4.9.3.1) instead.
An implementation MUST NOT generate namespace prefixes for elements
qualified by the content namespace (i.e., the default namespace for
data sent over the stream) if the content namespace is 'jabber:
client' or 'jabber:server'. For example, the following is illegal:
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<foo:message xmlns:foo='jabber:client'>
<foo:body>foo</foo:body>
</foo:message>
An XMPP entity SHOULD NOT accept data that violates this rule (in
particular, an XMPP server MUST NOT route or deliver such data to
another entity without first correcting the error); instead it SHOULD
either ignore the data or close the stream with a stream error, which
SHOULD be <bad-namespace-prefix/> (Section 4.9.3.2).
Namespaces declared in a stream header MUST apply only to that stream
(e.g., the 'jabber:server:dialback' namespace used in Server Dialback
[XEP-0220]). In particular, because XML stanzas intended for routing
or delivery over streams with other entities will lose the namespace
context declared in the header of the stream in which those stanzas
originated, namespaces for extended content within such stanzas MUST
NOT be declared in that stream header (see also Section 8.4). If
either party to a stream declares such namespaces, the other party to
the stream SHOULD close the stream with an <invalid-namespace/>
stream error (Section 4.9.3.10). In any case, an entity MUST ensure
that such namespaces are properly declared (according to this
section) when routing or delivering stanzas from an input stream to
an output stream.
4.9. Stream Errors
The root stream element MAY contain an <error/> child element that is
qualified by the stream namespace. The error child SHALL be sent by
a compliant entity if it perceives that a stream-level error has
occurred.
4.9.1. Rules
The following rules apply to stream-level errors.
4.9.1.1. Stream Errors Are Unrecoverable
Stream-level errors are unrecoverable. Therefore, if an error occurs
at the level of the stream, the entity that detects the error MUST
send an <error/> element with an appropriate child element specifying
the error condition and then immediately close the stream as
described under Section 4.4.
C: <message><body>No closing tag!</message>
S: <stream:error>
<not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
The entity that receives the stream error then SHALL close the stream
as explained under Section 4.4.
C: </stream:stream>
4.9.1.2. Stream Errors Can Occur During Setup
If the error is triggered by the initial stream header, the receiving
entity MUST still send the opening <stream> tag, include the <error/>
element as a child of the stream element, and send the closing
</stream> tag (preferably in the same TCP packet).
C: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://wrong.namespace.example.org/'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<invalid-namespace
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.1.3. Stream Errors When the Host Is Unspecified or Unknown
If the initiating entity provides no 'to' attribute or provides an unknown host in the 'to' attribute and the error occurs during stream setup, the value of the 'from' attribute returned by the receiving entity in the stream header sent before closing the stream MUST be either an authoritative FQDN for the receiving entity or the empty string. C: <?xml version='1.0'?> <stream:stream from='juliet@im.example.com' to='unknown.host.example.com' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'> S: <?xml version='1.0'?> <stream:stream from='im.example.com' id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' to='juliet@im.example.com' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'> <stream:error> <host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> </stream:stream>4.9.1.4. Where Stream Errors Are Sent
When two TCP connections are used between the initiating entity and the receiving entity (one in each direction) rather than using a single bidirectional connection, the following rules apply: o Stream-level errors related to the initial stream are returned by the receiving entity on the response stream via the same TCP connection. o Stanza errors triggered by outbound stanzas sent from the initiating entity over the initial stream via the same TCP connection are returned by the receiving entity on the response stream via the other ("return") TCP connection, since they are inbound stanzas from the perspective of the initiating entity.
4.9.2. Syntax
The syntax for stream errors is as follows, where XML data shown within the square brackets '[' and ']' is OPTIONAL. <stream:error> <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> [<text xmlns='urn:ietf:params:xml:ns:xmpp-streams' xml:lang='langcode'> OPTIONAL descriptive text </text>] [OPTIONAL application-specific condition element] </stream:error> The "defined-condition" MUST correspond to one of the stream error conditions defined under Section 4.9.3. However, because additional error conditions might be defined in the future, if an entity receives a stream error condition that it does not understand then it MUST treat the unknown condition as equivalent to <undefined- condition/> (Section 4.9.3.21). If the designers of an XMPP protocol extension or the developers of an XMPP implementation need to communicate a stream error condition that is not defined in this specification, they can do so by defining an application-specific error condition element qualified by an application-specific namespace. The <error/> element: o MUST contain a child element corresponding to one of the defined stream error conditions (Section 4.9.3); this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace. o MAY contain a <text/> child element containing XML character data that describes the error in more detail; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess an 'xml:lang' attribute specifying the natural language of the XML character data. o MAY contain a child element for an application-specific error condition; this element MUST be qualified by an application- defined namespace, and its structure is defined by that namespace (see Section 4.9.4). The <text/> element is OPTIONAL. If included, it MUST be used only to provide descriptive or diagnostic information that supplements the meaning of a defined condition or application-specific condition. It MUST NOT be interpreted programmatically by an application. It MUST NOT be used as the error message presented to a human user, but MAY
be shown in addition to the error message associated with the defined condition element (and, optionally, the application-specific condition element).4.9.3. Defined Stream Error Conditions
The following stream-level error conditions are defined.4.9.3.1. bad-format
The entity has sent XML that cannot be processed. (In the following example, the client sends an XMPP message that is not well-formed XML, which alternatively might trigger a <not-well- formed/> stream error (Section 4.9.3.13).) C: <message> <body>No closing tag! </message> S: <stream:error> <bad-format xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> </stream:stream> This error can be used instead of the more specific XML-related errors, such as <bad-namespace-prefix/>, <invalid-xml/>, <not-well- formed/>, <restricted-xml/>, and <unsupported-encoding/>. However, the more specific errors are RECOMMENDED.4.9.3.2. bad-namespace-prefix
The entity has sent a namespace prefix that is unsupported, or has sent no namespace prefix on an element that needs such a prefix (see Section 11.2). (In the following example, the client specifies a namespace prefix of "foobar" for the XML stream namespace.) C: <?xml version='1.0'?> <foobar:stream from='juliet@im.example.com' to='im.example.com' version='1.0' xmlns='jabber:client' xmlns:foobar='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<bad-namespace-prefix
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.3. conflict
The server either (1) is closing the existing stream for this entity
because a new stream has been initiated that conflicts with the
existing stream, or (2) is refusing a new stream for this entity
because allowing the new stream would conflict with an existing
stream (e.g., because the server allows only a certain number of
connections from the same IP address or allows only one server-to-
server stream for a given domain pair as a way of helping to ensure
in-order processing as described under Section 10.1).
C: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<conflict
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
If a client receives a <conflict/> stream error (Section 4.9.3.3), during the resource binding aspect of its reconnection attempt it MUST NOT blindly request the resourcepart it used during the former session but instead MUST choose a different resourcepart; details are provided under Section 7.4.9.3.4. connection-timeout
One party is closing the stream because it has reason to believe that the other party has permanently lost the ability to communicate over the stream. The lack of ability to communicate can be discovered using various methods, such as whitespace keepalives as specified under Section 4.4, XMPP-level pings as defined in [XEP-0199], and XMPP Stream Management as defined in [XEP-0198]. P: <stream:error> <connection-timeout xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> </stream:stream> Interoperability Note: RFC 3920 specified that the <connection- timeout/> stream error (Section 4.9.3.4) is to be used if the peer has not generated any traffic over the stream for some period of time. That behavior is no longer recommended; instead, the error SHOULD be used only if the connected client or peer server has not responded to data sent over the stream.4.9.3.5. host-gone
The value of the 'to' attribute provided in the initial stream header corresponds to an FQDN that is no longer serviced by the receiving entity. (In the following example, the peer specifies a 'to' address of "foo.im.example.com" when connecting to the "im.example.com" server, but the server no longer hosts a service at that address.) P: <?xml version='1.0'?> <stream:stream from='example.net' to='foo.im.example.com' version='1.0' xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='g4qSvGvBxJ+xeAd7QKezOQJFFlw='
to='example.net'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<host-gone
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.6. host-unknown
The value of the 'to' attribute provided in the initial stream header
does not correspond to an FQDN that is serviced by the receiving
entity.
(In the following example, the peer specifies a 'to' address of
"example.org" when connecting to the "im.example.com" server, but the
server knows nothing of that address.)
P: <?xml version='1.0'?>
<stream:stream
from='example.net'
to='example.org'
version='1.0'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='g4qSvGvBxJ+xeAd7QKezOQJFFlw='
to='example.net'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<host-unknown
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.7. improper-addressing
A stanza sent between two servers lacks a 'to' or 'from' attribute, the 'from' or 'to' attribute has no value, or the value violates the rules for XMPP addresses [XMPP-ADDR]. (In the following example, the peer sends a stanza without a 'to' address over a server-to-server stream.) P: <message from='juliet@im.example.com'> <body>Wherefore art thou?</body> </message> S: <stream:error> <improper-addressing xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> </stream:stream>4.9.3.8. internal-server-error
The server has experienced a misconfiguration or other internal error that prevents it from servicing the stream. S: <stream:error> <internal-server-error xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> </stream:stream>4.9.3.9. invalid-from
The data provided in a 'from' attribute does not match an authorized JID or validated domain as negotiated (1) between two servers using SASL or Server Dialback, or (2) between a client and a server via SASL authentication and resource binding. (In the following example, a peer that has authenticated only as "example.net" attempts to send a stanza from an address at "example.org".) P: <message from='romeo@example.org' to='juliet@im.example.com'> <body>Neither, fair saint, if either thee dislike.</body> </message>
S: <stream:error>
<invalid-from
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.10. invalid-namespace
The stream namespace name is something other than
"http://etherx.jabber.org/streams" (see Section 11.2) or the content
namespace declared as the default namespace is not supported (e.g.,
something other than "jabber:client" or "jabber:server").
(In the following example, the client specifies a namespace of
'http://wrong.namespace.example.org/' for the stream.)
C: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://wrong.namespace.example.org/'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<invalid-namespace
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.11. invalid-xml
The entity has sent invalid XML over the stream to a server that
performs validation (see Section 11.4).
(In the following example, the peer attempts to send an IQ stanza of
type "subscribe", but the XML schema defines no such value for the
'type' attribute.)
P: <iq from='example.net'
id='l3b1vs75'
to='im.example.com'
type='subscribe'>
<ping xmlns='urn:xmpp:ping'/>
</iq>
S: <stream:error>
<invalid-xml
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.12. not-authorized
The entity has attempted to send XML stanzas or other outbound data
before the stream has been authenticated, or otherwise is not
authorized to perform an action related to stream negotiation; the
receiving entity MUST NOT process the offending data before sending
the stream error.
(In the following example, the client attempts to send XML stanzas
before authenticating with the server.)
C: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
C: <message to='romeo@example.net'>
<body>Wherefore art thou?</body>
</message>
S: <stream:error>
<not-authorized
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.13. not-well-formed
The initiating entity has sent XML that violates the well-formedness
rules of [XML] or [XML-NAMES].
(In the following example, the client sends an XMPP message that is
not namespace-well-formed.)
C: <message>
<foo:body>What is this foo?</foo:body>
</message>
S: <stream:error>
<not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
Interoperability Note: In RFC 3920, the name of this error
condition was "xml-not-well-formed" instead of "not-well-formed".
The name was changed because the element name <xml-not-well-
formed/> violates the constraint from Section 3 of [XML] that
"names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are
reserved for standardization in this or future versions of this
specification".
4.9.3.14. policy-violation
The entity has violated some local service policy (e.g., a stanza
exceeds a configured size limit); the server MAY choose to specify
the policy in the <text/> element or in an application-specific
condition element.
(In the following example, the client sends an XMPP message that is
too large according to the server's local service policy.)
C: <message to='juliet@im.example.com' id='foo'>
<body>[ ... the-emacs-manual ... ]</body>
</message>
S: <stream:error>
<policy-violation
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<stanza-too-big xmlns='urn:xmpp:errors'/>
</stream:error>
S: </stream:stream>
4.9.3.15. remote-connection-failed
The server is unable to properly connect to a remote entity that is
needed for authentication or authorization (e.g., in certain
scenarios related to Server Dialback [XEP-0220]); this condition is
not to be used when the cause of the error is within the
administrative domain of the XMPP service provider, in which case the
<internal-server-error/> condition is more appropriate.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<remote-connection-failed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.16. reset
The server is closing the stream because it has new (typically
security-critical) features to offer, because the keys or
certificates used to establish a secure context for the stream have
expired or have been revoked during the life of the stream
(Section 13.7.2.3), because the TLS sequence number has wrapped
(Section 5.3.5), etc. The reset applies to the stream and to any
security context established for that stream (e.g., via TLS and
SASL), which means that encryption and authentication need to be
negotiated again for the new stream (e.g., TLS session resumption
cannot be used).
S: <stream:error>
<reset
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.17. resource-constraint
The server lacks the system resources necessary to service the
stream.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<resource-constraint
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.18. restricted-xml
The entity has attempted to send restricted XML features such as a
comment, processing instruction, DTD subset, or XML entity reference
(see Section 11.1).
(In the following example, the client sends an XMPP message
containing an XML comment.)
C: <message to='juliet@im.example.com'>
<!--<subject/>-->
<body>This message has no subject.</body>
</message>
S: <stream:error>
<restricted-xml
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.19. see-other-host
The server will not provide service to the initiating entity but is
redirecting traffic to another host under the administrative control
of the same service provider. The XML character data of the <see-
other-host/> element returned by the server MUST specify the
alternate FQDN or IP address at which to connect, which MUST be a
valid domainpart or a domainpart plus port number (separated by the
':' character in the form "domainpart:port"). If the domainpart is
the same as the source domain, derived domain, or resolved IPv4 or
IPv6 address to which the initiating entity originally connected
(differing only by the port number), then the initiating entity
SHOULD simply attempt to reconnect at that address. (The format of
an IPv6 address MUST follow [IPv6-ADDR], which includes the enclosing
the IPv6 address in square brackets '[' and ']' as originally defined
by [URI].) Otherwise, the initiating entity MUST resolve the FQDN
specified in the <see-other-host/> element as described under
Section 3.2.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<see-other-host
xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
[2001:41D0:1:A49b::1]:9222
</see-other-host>
</stream:error>
</stream:stream>
When negotiating a stream with the host to which it has been
redirected, the initiating entity MUST apply the same policies it
would have applied to the original connection attempt (e.g., a policy
requiring TLS), MUST specify the same 'to' address on the initial
stream header, and MUST verify the identity of the new host using the
same reference identifier(s) it would have used for the original
connection attempt (in accordance with [TLS-CERTS]). Even if the
receiving entity returns a <see-other-host/> error before the
confidentiality and integrity of the stream have been established
(thus introducing the possibility of a denial-of-service attack), the
fact that the initiating entity needs to verify the identity of the
XMPP service based on the same reference identifiers implies that the
initiating entity will not connect to a malicious entity. To reduce
the possibility of a denial-of-service attack, (a) the receiving
entity SHOULD NOT close the stream with a <see-other-host/> stream
error until after the confidentiality and integrity of the stream
have been protected via TLS or an equivalent security layer (such as
the SASL GSSAPI mechanism), and (b) the receiving entity MAY have a
policy of following redirects only if it has authenticated the
receiving entity. In addition, the initiating entity SHOULD abort
the connection attempt after a certain number of successive redirects
(e.g., at least 2 but no more than 5).
4.9.3.20. system-shutdown
The server is being shut down and all active streams are being closed. S: <stream:error> <system-shutdown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> </stream:stream>4.9.3.21. undefined-condition
The error condition is not one of those defined by the other conditions in this list; this error condition SHOULD NOT be used except in conjunction with an application-specific condition. S: <stream:error> <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <app-error xmlns='http://example.org/ns'/> </stream:error> </stream:stream>4.9.3.22. unsupported-encoding
The initiating entity has encoded the stream in an encoding that is not supported by the server (see Section 11.6) or has otherwise improperly encoded the stream (e.g., by violating the rules of the [UTF-8] encoding). (In the following example, the client attempts to encode data using UTF-16 instead of UTF-8.) C: <?xml version='1.0' encoding='UTF-16'?> <stream:stream from='juliet@im.example.com' to='im.example.com' version='1.0' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<unsupported-encoding
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.23. unsupported-feature
The receiving entity has advertised a mandatory-to-negotiate stream
feature that the initiating entity does not support, and has offered
no other mandatory-to-negotiate feature alongside the unsupported
feature.
(In the following example, the receiving entity requires negotiation
of an example feature, but the initiating entity does not support the
feature.)
R: <stream:features>
<example xmlns='urn:xmpp:example'>
<required/>
</example>
</stream:features>
I: <stream:error>
<unsupported-feature
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.24. unsupported-stanza-type
The initiating entity has sent a first-level child of the stream that
is not supported by the server, either because the receiving entity
does not understand the namespace or because the receiving entity
does not understand the element name for the applicable namespace
(which might be the content namespace declared as the default
namespace).
(In the following example, the client attempts to send a first-level
child element of <pubsub/> qualified by the 'jabber:client'
namespace, but the schema for that namespace defines no such
element.)
C: <pubsub xmlns='jabber:client'>
<publish node='princely_musings'>
<item id='ae890ac52d0df67ed7cfdf51b644e901'>
<entry xmlns='http://www.w3.org/2005/Atom'>
<title>Soliloquy</title>
<summary>
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
</summary>
<link rel='alternate' type='text/html'
href='http://denmark.example/2003/12/13/atom03'/>
<id>tag:denmark.example,2003:entry-32397</id>
<published>2003-12-13T18:30:02Z</published>
<updated>2003-12-13T18:30:02Z</updated>
</entry>
</item>
</publish>
</pubsub>
S: <stream:error>
<unsupported-stanza-type
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.3.25. unsupported-version
The 'version' attribute provided by the initiating entity in the
stream header specifies a version of XMPP that is not supported by
the server.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='11.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<unsupported-version
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
4.9.4. Application-Specific Conditions
As noted, an application MAY provide application-specific stream
error information by including a properly namespaced child in the
error element. The application-specific element SHOULD supplement or
further qualify a defined element. Thus, the <error/> element will
contain two or three child elements.
C: <message>
<body>
My keyboard layout is:
QWERTYUIOP{}|
ASDFGHJKL:"
ZXCVBNM<>?
</body>
</message>
S: <stream:error>
<not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Some special application diagnostic information!
</text>
<escape-your-data xmlns='http://example.org/ns'/>
</stream:error>
</stream:stream>
4.10. Simplified Stream Examples
This section contains two highly simplified examples of a stream- based connection between a client and a server; these examples are included for the purpose of illustrating the concepts introduced thus far, but the reader needs to be aware that these examples elide many details (see Section 9 for more complete examples). A basic connection: C: <?xml version='1.0'?> <stream:stream from='juliet@im.example.com' to='im.example.com' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'> S: <?xml version='1.0'?> <stream:stream from='im.example.com' id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' to='juliet@im.example.com' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'> [ ... stream negotiation ... ] C: <message from='juliet@im.example.com/balcony' to='romeo@example.net' xml:lang='en'> <body>Art thou not Romeo, and a Montague?</body> </message> S: <message from='romeo@example.net/orchard' to='juliet@im.example.com/balcony' xml:lang='en'> <body>Neither, fair saint, if either thee dislike.</body> </message> C: </stream:stream> S: </stream:stream>
A connection gone bad:
C: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
[ ... stream negotiation ... ]
C: <message from='juliet@im.example.com/balcony'
to='romeo@example.net'
xml:lang='en'>
<body>No closing tag!
</message>
S: <stream:error>
<not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
More detailed examples are provided under Section 9.
(page 69 continued on part 4)