Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6120

Extensible Messaging and Presence Protocol (XMPP): Core

Pages: 211
Proposed Standard
Errata
Obsoletes:  3920
Updated by:  75908553
Part 3 of 9 – Pages 43 to 69
First   Prev   Next

Top   ToC   RFC6120 - Page 43   prevText

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).
Top   ToC   RFC6120 - Page 44
   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
Top   ToC   RFC6120 - Page 45
   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
Top   ToC   RFC6120 - Page 46
      (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:
Top   ToC   RFC6120 - Page 47
     <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'>
Top   ToC   RFC6120 - Page 48
     <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.
Top   ToC   RFC6120 - Page 49
   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>
Top   ToC   RFC6120 - Page 50
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.
Top   ToC   RFC6120 - Page 51

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
Top   ToC   RFC6120 - Page 52
   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'>
Top   ToC   RFC6120 - Page 53
   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>
Top   ToC   RFC6120 - Page 54
   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'>
Top   ToC   RFC6120 - Page 55
   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>
Top   ToC   RFC6120 - Page 56
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>
Top   ToC   RFC6120 - Page 57
   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.)
Top   ToC   RFC6120 - Page 58
   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>
Top   ToC   RFC6120 - Page 59
   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>
Top   ToC   RFC6120 - Page 60
   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
Top   ToC   RFC6120 - Page 61
   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.)
Top   ToC   RFC6120 - Page 62
   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'>
Top   ToC   RFC6120 - Page 63
   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).
Top   ToC   RFC6120 - Page 64
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'>
Top   ToC   RFC6120 - Page 65
   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).
Top   ToC   RFC6120 - Page 66
   (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'>
Top   ToC   RFC6120 - Page 67
   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>
Top   ToC   RFC6120 - Page 68

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>
Top   ToC   RFC6120 - Page 69
   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)

Next Section