tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6120

 
 
 

Extensible Messaging and Presence Protocol (XMPP): Core

Part 3 of 9, p. 43 to 69
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 43 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part