9.  Detailed Examples

   The detailed examples in this section further illustrate the
   protocols defined in this specification.

9.1.  Client-to-Server Examples

   The following examples show the XMPP data flow for a client
   negotiating an XML stream with a server, exchanging XML stanzas, and
   closing the negotiated stream.  The server is "im.example.com", the
   server requires use of TLS, the client authenticates via the SASL
   SCRAM-SHA-1 mechanism as <juliet@im.example.com> with a password of
   "r0m30myr0m30", and the client binds a client-submitted resource to
   the stream.  It is assumed that before sending the initial stream
   header, the client has already resolved an SRV record of
   _xmpp-client._tcp.im.example.com and has opened a TCP connection to
   the advertised port at the resolved IP address.

9.1.1.  TLS

   Step 1: Client initiates stream to server:

   C: <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'>

   Step 2: Server responds by sending a response stream header to
   client:

   S: <stream:stream
        from='im.example.com'
        id='t7AMCin9zjMNwQKDnplntZPIDEI='
        to='juliet@im.example.com'
        version='1.0'
        xml:lang='en'
        xmlns='jabber:client'
        xmlns:stream='http://etherx.jabber.org/streams'>

   Step 3: Server sends stream features to client (only the STARTTLS
   extension at this point, which is mandatory-to-negotiate):

   S: <stream:features>
        <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
          <required/>
        </starttls>
      </stream:features>

   Step 4: Client sends STARTTLS command to server:

   C: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

   Step 5: Server informs client that it is allowed to proceed:

   S: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

   Step 5 (alt): Server informs client that STARTTLS negotiation has
   failed, closes the XML stream, and terminates the TCP connection
   (thus, the stream negotiation process ends unsuccessfully and the
   parties do not move on to the next step):

   S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
      </stream:stream>

   Step 6: Client and server attempt to complete TLS negotiation over
   the existing TCP connection (see [TLS] for details).

   Step 7: If TLS negotiation is successful, client initiates a new
   stream to server over the TLS-protected TCP connection:

   C: <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'>

   Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP
   connection (thus, the stream negotiation process ends unsuccessfully
   and the parties do not move on to the next step):

9.1.2.  SASL

   Step 8: Server responds by sending a stream header to client along
   with any available stream features:

   S: <stream:stream
        from='im.example.com'
        id='vgKi/bkYME8OAj4rlXMkpucAqe4='
        to='juliet@im.example.com'
        version='1.0'
        xml:lang='en'
        xmlns='jabber:client'
        xmlns:stream='http://etherx.jabber.org/streams'>

   S: <stream:features>
        <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
          <mechanism>SCRAM-SHA-1-PLUS</mechanism>
          <mechanism>SCRAM-SHA-1</mechanism>
          <mechanism>PLAIN</mechanism>
        </mechanisms>
      </stream:features>

   Step 9: Client selects an authentication mechanism (in this case,
   SCRAM-SHA-1), including initial response data:

   C: <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"
            mechanism="SCRAM-SHA-1">
        biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ==
      </auth>

   The decoded base 64 data is
   "n,,n=juliet,r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AA".

   Step 10: Server sends a challenge:

   S: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
        cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y
        TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT
        AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY=
      </challenge>

   The decoded base 64 data is "r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AAe12469
   5b-69a9-4de6-9c30-
   b51b3808c59e,s=NjhkYTM0MDgtNGY0Zi00NjdmLTkxMmUtNDlmNTNmNDNkMDMz,i=409
   6" (line breaks not included in actual data).

   Step 11: Client sends a response:

   C: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
        Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N
        jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV
        RCa0gyRlhzMFdEWHZKWXc9
      </response>

   The decoded base 64 data is "c=biws,r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0
   AAe124695b-69a9-4de6-9c30-b51b3808c59e,p=UA57tM/
   SvpATBkH2FXs0WDXvJYw=" (line breaks not included in actual data).

   Step 12: Server informs client of success, including additional data
   with success:

   S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
        dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
      </success>

   The decoded base 64 data is "v=pNNDFVEQxuXxCoSEiW8GEZ+1RSo=".

   Step 12 (alt): Server returns a SASL error to client (thus, the
   stream negotiation process ends unsuccessfully and the parties do not
   move on to the next step):

   S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
        <not-authorized/>
      </failure>
      </stream>

   Step 13: Client initiates a new stream to server:

   C: <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'>

9.1.3.  Resource Binding

   Step 14: Server responds by sending a stream header to client along
   with supported features (in this case, resource binding):

   S: <stream:stream
        from='im.example.com'
        id='gPybzaOzBmaADgxKXu9UClbprp0='
        to='juliet@im.example.com'
        version='1.0'
        xml:lang='en'
        xmlns='jabber:client'
        xmlns:stream='http://etherx.jabber.org/streams'>

   S: <stream:features>
        <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
      </stream:features>

   Upon being informed that resource binding is mandatory-to-negotiate,
   the client needs to bind a resource to the stream; here we assume
   that the client submits a human-readable text string.

   Step 15: Client binds a resource:

   C: <iq id='yhc13a95' type='set'>
        <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
          <resource>balcony</resource>
        </bind>
      </iq>

   Step 16: Server accepts submitted resourcepart and informs client of
   successful resource binding:

   S: <iq id='yhc13a95' type='result'>
        <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
          <jid>
            juliet@im.example.com/balcony
          </jid>
        </bind>
      </iq>

   Step 16 (alt): Server returns error to client (thus, the stream
   negotiation process ends unsuccessfully and the parties do not move
   on to the next step):

   S: <iq id='yhc13a95' type='error'>
        <error type='cancel'>
          <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
        </error>
      </iq>

9.1.4.  Stanza Exchange

   Now the client is allowed to send XML stanzas over the negotiated
   stream.

   C: <message from='juliet@im.example.com/balcony'
               id='ju2ba41c'
               to='romeo@example.net'
               type='chat'
               xml:lang='en'>
        <body>Art thou not Romeo, and a Montague?</body>
      </message>

   If necessary, sender's server negotiates XML streams with intended
   recipient's server (see Section 9.2).

   The intended recipient replies, and the message is delivered to the
   client.

   E: <message from='romeo@example.net/orchard'
               id='ju2ba41c'
               to='juliet@im.example.com/balcony'
               type='chat'
               xml:lang='en'>
        <body>Neither, fair saint, if either thee dislike.</body>
      </message>

   The client can subsequently send and receive an unbounded number of
   subsequent XML stanzas over the stream.

9.1.5.  Close

   Desiring to send no further messages, the client closes its stream to
   the server but waits for incoming data from the server.

   C: </stream:stream>

   Consistent with Section 4.4, the server might send additional data to
   the client and then closes its stream to the client.

   S: </stream:stream>

   The client now sends a TLS close_notify alert, receives a responding
   close_notify alert from the server, and then terminates the
   underlying TCP connection.

9.2.  Server-to-Server Examples

   The following examples show the data flow for a server negotiating an
   XML stream with a peer server, exchanging XML stanzas, and closing
   the negotiated stream.  The initiating server ("Server1") is
   im.example.com; the receiving server ("Server2") is example.net and
   it requires use of TLS; im.example.com presents a certificate and
   authenticates via the SASL EXTERNAL mechanism.  It is assumed that
   before sending the initial stream header, Server1 has already
   resolved an SRV record of _xmpp-server._tcp.example.net and has
   opened a TCP connection to the advertised port at the resolved IP
   address.  Note how Server1 declares the content namespace "jabber:
   server" as the default namespace and uses prefixes for stream-related
   elements, whereas Server2 uses prefix-free canonicalization.

9.2.1.  TLS

   Step 1: Server1 initiates stream to Server2:

   S1: <stream:stream
         from='im.example.com'
         to='example.net'
         version='1.0'
         xmlns='jabber:server'
         xmlns:stream='http://etherx.jabber.org/streams'>

   Step 2: Server2 responds by sending a response stream header to
   Server1:

   S2: <stream
         from='example.net'
         id='hTiXkW+ih9k2SqdGkk/AZi0OJ/Q='
         to='im.example.com'
         version='1.0'
         xmlns='http://etherx.jabber.org/streams'>

   Step 3: Server2 sends stream features to Server1 (only the STARTTLS
   extension at this point, which is mandatory-to-negotiate):

   S2: <features xmlns='http://etherx.jabber.org/streams'>
         <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
           <required/>
         </starttls>
       </features>

   Step 4: Server1 sends the STARTTLS command to Server2:

   S1: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

   Step 5: Server2 informs Server1 that it is allowed to proceed:

   S2: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

   Step 5 (alt): Server2 informs Server1 that STARTTLS negotiation has
   failed, closes the stream, and terminates the TCP connection (thus,
   the stream negotiation process ends unsuccessfully and the parties do
   not move on to the next step):

   S2: <failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
       </stream>

   Step 6: Server1 and Server2 attempt to complete TLS negotiation via
   TCP (see [TLS] for details).

   Step 7: If TLS negotiation is successful, Server1 initiates a new
   stream to Server2 over the TLS-protected TCP connection:

   S1: <stream:stream
         from='im.example.com'
         to='example.net'
         version='1.0'
         xmlns='jabber:server'
         xmlns:stream='http://etherx.jabber.org/streams'>

   Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes the
   TCP connection (thus, the stream negotiation process ends
   unsuccessfully and the parties do not move on to the next step).

9.2.2.  SASL

   Step 8: Server2 sends a response stream header to Server1 along with
   available stream features (including a preference for the SASL
   EXTERNAL mechanism):

   S2: <stream
         from='example.net'
         id='RChdjlgj/TIBcbT9Keu31zDihH4='
         to='im.example.com'
         version='1.0'
         xmlns='http://etherx.jabber.org/streams'>

   S2: <features xmlns='http://etherx.jabber.org/streams'>
         <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
           <mechanism>EXTERNAL</mechanism>
         </mechanisms>
       </features>

   Step 9: Server1 selects the EXTERNAL mechanism (including an empty
   response of "="):

   S1: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
             mechanism='EXTERNAL'>=</auth>

   Step 10: Server2 returns success:

   S2: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

   Step 10 (alt): Server2 informs Server1 of failed authentication
   (thus, the stream negotiation process ends unsuccessfully and the
   parties do not move on to the next step):

   S2: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
         <not-authorized/>
       </failure>
       </stream>

   Step 11: Server1 initiates a new stream to Server2:

   S1: <stream:stream
         from='im.example.com'
         to='example.net'
         version='1.0'
         xmlns='jabber:server'
         xmlns:stream='http://etherx.jabber.org/streams'>

   Step 12: Server2 responds by sending a stream header to Server1 along
   with any additional features (or, in this case, an empty features
   element):

   S2: <stream
         from='example.net'
         id='MbbV2FeojySpUIP6J91qaa+TWHM='
         to='im.example.com'
         version='1.0'
         xmlns='http://etherx.jabber.org/streams'>

   S2: <features xmlns='http://etherx.jabber.org/streams'/>

9.2.3.  Stanza Exchange

   Now Server1 is allowed to send XML stanzas to Server2 over the
   negotiated stream from im.example.com to example.net; here we assume
   that the transferred stanzas are those shown earlier for client-to-
   server communication, albeit over a server-to-server stream qualified
   by the 'jabber:server' namespace.

   Server1 sends XML stanza to Server2:

   S1: <message from='juliet@im.example.com/balcony'
                id='ju2ba41c'
                to='romeo@example.net'
                type='chat'
                xml:lang='en'>
       <body>Art thou not Romeo, and a Montague?</body>
      </message>

9.2.4.  Close

   Desiring to send no further messages, Server1 closes its stream to
   Server2 but waits for incoming data from Server2.  (In practice, the
   stream would most likely remain open for some time, since Server1 and
   Server2 do not immediately know if the stream will be needed for
   further communication.)

   S1: </stream:stream>

   Consistent with the recommended stream closing handshake, Server2
   closes the stream as well:

   S2: </stream>

   Server1 now sends a TLS close_notify alert, receives a responding
   close_notify alert from Server2, and then terminates the underlying
   TCP connection.

10.  Server Rules for Processing XML Stanzas

   Each server implementation will contain its own logic for processing
   stanzas it receives.  Such logic determines whether the server needs
   to route a given stanza to another domain, deliver it to a local
   entity (typically a connected client associated with a local
   account), or handle it directly within the server itself.  This
   section provides general rules for processing XML stanzas.  However,
   particular XMPP applications MAY specify delivery rules that modify
   or supplement the following rules (e.g., a set of delivery rules for
   instant messaging and presence applications is defined in [XMPP-IM]).

10.1.  In-Order Processing

   An XMPP server MUST ensure in-order processing of the stanzas and
   other XML elements it receives over a given input stream from a
   connected client or remote server.

   In-order processing applies (a) to any XML elements used to negotiate
   and manage XML streams, and (b) to all uses of XML stanzas, including
   but not limited to the following:

   1.  Stanzas sent by a client to its server or to its own bare JID for
       direct processing by the server (e.g., in-order processing of a
       roster get and initial presence as described in [XMPP-IM]).

   2.  Stanzas sent by a connected client and intended for delivery to
       another entity associated with the server (e.g., stanzas
       addressed from <juliet@im.example.com> to
       <nurse@im.example.com>).  The server MUST ensure that it delivers
       stanzas addressed to the intended recipient in the order it
       receives them over the input stream from the sending client,
       treating stanzas addressed to the bare JID and the full JID of
       the intended recipient as equivalent for delivery purposes.

   3.  Stanzas sent by a connected client and intended for delivery to
       an entity located at a remote domain (e.g., stanzas addressed
       from <juliet@im.example.com> to <romeo@example.net>).  The
       routing server MUST ensure that it routes stanzas addressed to
       the intended recipient in the order it receives them over the
       input stream from the sending client, treating stanzas addressed
       to the bare JID and the full JID of the intended recipient as
       equivalent for routing purposes.  To help ensure in-order
       processing, the routing server MUST route such stanzas over a
       single output stream to the remote domain, rather than sending
       some stanzas over one server-to-server stream and other stanzas
       over another server-to-server stream.

   4.  Stanzas routed from one server to another server for delivery to
       an entity associated with the remote domain (e.g., stanzas
       addressed from <juliet@im.example.com> to <romeo@example.net> and
       routed by <im.example.com> over a server-to-server stream to
       <example.net>).  The delivering server MUST ensure that it
       delivers stanzas to the intended recipient in the order it
       receives them over the input stream from the routing server,
       treating stanzas addressed to the bare JID and the full JID of
       the intended recipient as equivalent for delivery purposes.

   5.  Stanzas sent by one server to another server for direct
       processing by the server that is hosting the remote domain (e.g.,
       stanzas addressed from <im.example.com> to <example.net>).

   If the server's processing of a particular request could have an
   effect on its processing of subsequent data it might receive over
   that input stream (e.g., enforcement of communication policies), it
   MUST suspend processing of subsequent data until it has processed the
   request.

   In-order processing applies only to a single input stream.
   Therefore, a server is not responsible for ensuring the coherence of
   data it receives across multiple input streams associated with the
   same local account (e.g., stanzas received over two different input
   streams from <juliet@im.example.com/balcony> and
   <juliet@im.example.com/chamber>) or the same remote domain (e.g., two
   different input streams negotiated by a remote domain; however, a
   server MAY close the stream with a <conflict/> stream error
   (Section 4.9.3.3) if a remote server attempts to negotiate more than
   one stream, as described under Section 4.9.3.3).

10.2.  General Considerations

   At high level, there are three primary considerations at play in
   server processing of XML stanzas, which sometimes are at odds but
   need to be managed in a consistent way:

   1.  It is good to deliver a stanza to the intended recipient if
       possible.

   2.  If a stanza cannot be delivered, it is helpful to inform the
       sender.

   3.  It is bad to facilitate directory harvesting attacks
       (Section 13.11) and presence leaks (Section 13.10.2).

   With regard to possible delivery-related attacks, the following
   points need to be kept in mind:

   1.  From the perspective of an attacker, there is little if any
       effective difference between the server's (i) delivering the
       stanza or storing it offline for later delivery (see [XMPP-IM])
       and (ii) silently ignoring it (because an error is not returned
       immediately in any of those cases); therefore, in scenarios where
       a server delivers a stanza or places the stanza into offline
       storage for later delivery, it needs to silently ignore the
       stanza if that account does not exist.

   2.  How a server processes stanzas sent to the bare JID
       <localpart@domainpart> has implications for directory harvesting,
       because an attacker could determine whether an account exists if
       the server responds differently depending on whether there is an
       account for a given bare JID.

   3.  How a server processes stanzas sent to a full JID has
       implications for presence leaks, because an attacker could send
       requests to multiple full JIDs and receive different replies
       depending on whether the user has a device currently online at
       that full JID.  The use of randomized resourceparts (whether
       generated by the client or the server as described under
       Section 7) significantly helps to mitigate this attack, so it is
       of somewhat lesser concern than the directory harvesting attack.

   Naturally, presence is not leaked if the entity to which a user's
   server returns an error already knows the user's presence or is
   authorized to do so (e.g., by means of a presence subscription or
   directed presence), and a server does not enable a directory

   harvesting attack if it returns an error to an entity that already
   knows if a user exists (e.g., because the entity is in the user's
   contact list); these matters are discussed more fully in [XMPP-IM].

10.3.  No 'to' Address

   If the stanza possesses no 'to' attribute, the server MUST handle it
   directly on behalf of the entity that sent it, where the meaning of
   "handle it directly" depends on whether the stanza is message,
   presence, or IQ.  Because all stanzas received from other servers
   MUST possess a 'to' attribute, this rule applies only to stanzas
   received from a local entity (typically a client) that is connected
   to the server.

10.3.1.  Message

   If the server receives a message stanza with no 'to' attribute, it
   MUST treat the message as if the 'to' address were the bare JID
   <localpart@domainpart> of the sending entity.

10.3.2.  Presence

   If the server receives a presence stanza with no 'to' attribute, it
   MUST broadcast it to the entities that are subscribed to the sending
   entity's presence, if applicable ([XMPP-IM] defines the semantics of
   such broadcasting for presence applications).

10.3.3.  IQ

   If the server receives an IQ stanza with no 'to' attribute, it MUST
   process the stanza on behalf of the account from which received the
   stanza, as follows:

   1.  If the IQ stanza is of type "get" or "set" and the server
       understands the namespace that qualifies the payload, the server
       MUST handle the stanza on behalf of the sending entity or return
       an appropriate error to the sending entity.  Although the meaning
       of "handle" is determined by the semantics of the qualifying
       namespace, in general the server will respond to the IQ stanza of
       type "get" or "set" by returning an appropriate IQ stanza of type
       "result" or "error", responding as if the server were the bare
       JID of the sending entity.  As an example, if the sending entity
       sends an IQ stanza of type "get" where the payload is qualified
       by the 'jabber:iq:roster' namespace (as described in [XMPP-IM]),
       then the server will return the roster associated with the
       sending entity's bare JID to the particular resource of the
       sending entity that requested the roster.

   2.  If the IQ stanza is of type "get" or "set" and the server does
       not understand the namespace that qualifies the payload, the
       server MUST return an error to the sending entity, which MUST be
       <service-unavailable/>.

   3.  If the IQ stanza is of type "error" or "result", the server MUST
       handle the error or result in accordance with the payload of the
       associated IQ stanza or type "get" or "set" (if there is no such
       associated stanza, the server MUST ignore the error or result
       stanza).

10.4.  Remote Domain

   If the domainpart of the JID contained in the 'to' attribute does not
   match one of the configured FQDNs of the server, the server SHOULD
   attempt to route the stanza to the remote domain (subject to local
   service provisioning and security policies regarding inter-domain
   communication, since such communication is OPTIONAL for any given
   deployment).  As described in the following sections, there are two
   possible cases.

      Security Warning: These rules apply only client-to-server streams.
      As described under Section 8.1.1.2, a server MUST NOT accept a
      stanza over a server-to-server stream if the domainpart of the JID
      in the 'to' attribute does not match an FQDN serviced by the
      receiving server.

10.4.1.  Existing Stream

   If a server-to-server stream already exists between the two domains,
   the sender's server SHOULD attempt to route the stanza to the
   authoritative server for the remote domain over the existing stream.

10.4.2.  No Existing Stream

   If there exists no server-to-server stream between the two domains,
   the sender's server will proceed as follows:

   1.  Resolve the FQDN of the remote domain (as described under
       Section 13.9.2).

   2.  Negotiate a server-to-server stream between the two domains (as
       defined under Section 5 and Section 6).

   3.  Route the stanza to the authoritative server for the remote
       domain over the newly established stream.

10.4.3.  Error Handling

   If routing of a stanza to the intended recipient's server is
   unsuccessful, the sender's server MUST return an error to the sender.
   If resolution of the remote domain is unsuccessful, the stanza error
   MUST be <remote-server-not-found/> (Section 8.3.3.16).  If resolution
   succeeds but streams cannot be negotiated, the stanza error MUST be
   <remote-server-timeout/> (Section 8.3.3.17).

   If stream negotiation with the intended recipient's server is
   successful but the remote server cannot deliver the stanza to the
   recipient, the remote server MUST return an appropriate error to the
   sender by way of the sender's server.

10.5.  Local Domain

   If the domainpart of the JID contained in the 'to' attribute matches
   one of the configured FQDNs of the server, the server MUST first
   determine if the FQDN is serviced by the server itself or by a
   specialized local service.  If the latter, the server MUST route the
   stanza to that service.  If the former, the server MUST proceed as
   follows.  However, the server MUST NOT route or "forward" the stanza
   to another domain, because it is the server's responsibility to
   process all stanzas for which the domainpart of the 'to' address
   matches one of the configured FQDNs of the server (among other
   things, this helps to prevent looping).

10.5.1.  domainpart

   If the JID contained in the 'to' attribute is of the form
   <domainpart>, then the server MUST either (a) handle the stanza as
   appropriate for the stanza kind or (b) return an error stanza to the
   sender.

10.5.2.  domainpart/resourcepart

   If the JID contained in the 'to' attribute is of the form
   <domainpart/resourcepart>, then the server MUST either (a) handle the
   stanza as appropriate for the stanza kind or (b) return an error
   stanza to the sender.

10.5.3.  localpart@domainpart

   An address of this type is normally associated with an account on the
   server.  The following rules provide some general guidelines; more
   detailed rules in the context of instant messaging and presence
   applications are provided in [XMPP-IM].

10.5.3.1.  No Such User

   If there is no local account associated with the
   <localpart@domainpart>, how the stanza is processed depends on the
   stanza type.

   o  For a message stanza, the server MUST either (a) silently ignore
      the stanza or (b) return a <service-unavailable/> stanza error
      (Section 8.3.3.19) to the sender.

   o  For a presence stanza, the server SHOULD ignore the stanza (or
      behave as described in [XMPP-IM]).

   o  For an IQ stanza, the server MUST return a <service-unavailable/>
      stanza error (Section 8.3.3.19) to the sender.

10.5.3.2.  User Exists

   If the JID contained in the 'to' attribute is of the form
   <localpart@domainpart>, how the stanza is processed depends on the
   stanza type.

   o  For a message stanza, if there exists at least one connected
      resource for the account then the server SHOULD deliver it to at
      least one of the connected resources.  If there exists no
      connected resource then the server MUST either (a) store the
      message offline for delivery when the account next has a connected
      resource or (b) return a <service-unavailable/> stanza error
      (Section 8.3.3.19).

   o  For a presence stanza, if there exists at least one connected
      resource that has sent initial presence (i.e., has a "presence
      session" as defined in [XMPP-IM]) then the server SHOULD deliver
      it to such resources.  If there exists no connected resource then
      the server SHOULD ignore the stanza (or behave as described in
      [XMPP-IM]).

   o  For an IQ stanza, the server MUST handle it directly on behalf of
      the intended recipient.

10.5.4.  localpart@domainpart/resourcepart

   If the JID contained in the 'to' attribute is of the form
   <localpart@domainpart/resourcepart> and the user exists but there is
   no connected resource that exactly matches the full JID, the stanza
   SHOULD be processed as if the JID were of the form
   <localpart@domainpart> as described under Section 10.5.3.2.

   If the JID contained in the 'to' attribute is of the form
   <localpart@domainpart/resourcepart>, the user exists, and there is a
   connected resource that exactly matches the full JID, the server MUST
   deliver the stanza to that connected resource.

11.  XML Usage

11.1.  XML Restrictions

   XMPP defines a class of data objects called XML streams as well as
   the behavior of computer programs that process XML streams.  XMPP is
   an application profile or restricted form of the Extensible Markup
   Language [XML], and a complete XML stream (including start and end
   stream tags) is a conforming XML document.

   However, XMPP does not deal with XML documents but with XML streams.
   Because XMPP does not require the parsing of arbitrary and complete
   XML documents, there is no requirement that XMPP needs to support the
   full feature set of [XML].  Furthermore, XMPP uses XML to define
   protocol data structures and extensions for the purpose of structured
   interactions between network entities and therefore adheres to the
   recommendations provided in [XML-GUIDE] regarding restrictions on the
   use of XML in IETF protocols.  As a result, the following features of
   XML are prohibited in XMPP:

   o  comments (as defined in Section 2.5 of [XML])

   o  processing instructions (Section 2.6 therein)

   o  internal or external DTD subsets (Section 2.8 therein)

   o  internal or external entity references (Section 4.2 therein) with
      the exception of the predefined entities (Section 4.6 therein)

   An XMPP implementation MUST behave as follows with regard to these
   features:

   1.  An XMPP implementation MUST NOT inject characters matching such
       features into an XML stream.

   2.  If an XMPP implementation receives characters matching such
       features over an XML stream, it MUST close the stream with a
       stream error, which SHOULD be <restricted-xml/>
       (Section 4.9.3.18), although some existing implementations send
       <bad-format/> (Section 4.9.3.1) instead.

11.2.  XML Namespace Names and Prefixes

   XML namespaces (see [XML-NAMES]) are used within XMPP streams to
   create strict boundaries of data ownership.  The basic function of
   namespaces is to separate different vocabularies of XML elements that
   are structurally mixed together.  Ensuring that XMPP streams are
   namespace-aware enables any allowable XML to be structurally mixed
   with any data element within XMPP.  XMPP-specific rules for XML
   namespace names and prefixes are defined under Section 4.8 for XML
   streams and Section 8.4 for XML stanzas.

11.3.  Well-Formedness

   In XML, there are two varieties of well-formedness:

   o  "XML-well-formedness" in accordance with the definition of "well-
      formed" from Section 2.1 of [XML].

   o  "Namespace-well-formedness" in accordance with the definition of
      "namespace-well-formed" from Section 7 of [XML-NAMES].

   The following rules apply:

   1.  An XMPP entity MUST NOT generate data that is not XML-well-
       formed.

   2.  An XMPP entity MUST NOT accept data that is not XML-well-formed;
       instead it MUST close the stream over which the data was received
       with a <not-well-formed/> stream error (Section 4.9.3.13).

   3.  An XMPP entity MUST NOT generate data that is not namespace-well-
       formed.

   4.  An XMPP entity MUST NOT accept data that is not namespace-well-
       formed (in particular, an XMPP server MUST NOT route or deliver
       data that is not namespace-well-formed); instead it MUST return
       either a <not-acceptable/> stanza error (Section 8.3.3.9) or
       close the stream with a <not-well-formed/> stream error
       (Section 4.9.3.13), where it is preferable to close the stream
       with a stream error because accepting such data can open an
       entity to certain denial-of-service attacks.

      Interoperability Note: Because these restrictions were
      underspecified in [RFC3920], it is possible that implementations
      based on that specification will send data that does not comply
      with these restrictions.

11.4.  Validation

   A server is not responsible for ensuring that XML data delivered to a
   connected client or routed to a peer server is valid, in accordance
   with the definition of "valid" provided in Section 2.8 of [XML].  An
   implementation MAY choose to accept or send only data that has been
   explicitly validated against the schemas provided in this document,
   but such behavior is OPTIONAL.  Clients are advised not to rely on
   the ability to send data that does not conform to the schemas, and
   SHOULD ignore any non-conformant elements or attributes on the
   incoming XML stream.

      Informational Note: The terms "valid" and "well-formed" are
      distinct in XML.

11.5.  Inclusion of XML Declaration

   Before sending a stream header, an implementation SHOULD send an XML
   declaration (matching the "XMLDecl" production from [XML]).
   Applications MUST follow the rules provided in [XML] regarding the
   format of the XML declaration and the circumstances under which the
   XML declaration is included.

   Because external markup declarations are prohibited in XMPP (as
   described under Section 11.1), the standalone document declaration
   (matching the "SDDecl" production from [XML]) would have no meaning
   and therefore MUST NOT be included in an XML declaration sent over an
   XML stream.  If an XMPP entity receives an XML declaration containing
   a standalone document declaration set to a value of "no", the entity
   MUST either ignore the standalone document declaration or close the
   stream with a stream error, which SHOULD be <restricted-xml/>
   (Section 4.9.3.18).

11.6.  Character Encoding

   Implementations MUST support the UTF-8 transformation of Universal
   Character Set [UCS2] characters, as needed for conformance with
   [CHARSETS] and as defined in [UTF-8].  Implementations MUST NOT
   attempt to use any other encoding.  If one party to an XML stream
   detects that the other party has attempted to send XML data with an
   encoding other than UTF-8, it MUST close the stream with a stream
   error, which SHOULD be <unsupported-encoding/> (Section 4.9.3.22),
   although some existing implementations send <bad-format/>
   (Section 4.9.3.1) instead.

   Because it is mandatory for an XMPP implementation to support all and
   only the UTF-8 encoding and because UTF-8 always has the same byte
   order, an implementation MUST NOT send a byte order mark ("BOM") at

   the beginning of the data stream.  If an entity receives the
   [UNICODE] character U+FEFF anywhere in an XML stream (including as
   the first character of the stream), it MUST interpret that character
   as a zero width no-break space, not as a byte order mark.

11.7.  Whitespace

   Except where explicitly disallowed (e.g., during TLS negotiation
   (Section 5) and SASL negotiation (Section 6)), either entity MAY send
   whitespace as separators between XML stanzas or between any other
   first-level elements sent over the stream.  One common use for
   sending such whitespace is explained under Section 4.4.

11.8.  XML Versions

   XMPP is an application profile of XML 1.0.  A future version of XMPP
   might be defined in terms of higher versions of XML, but this
   specification defines XMPP only in terms of XML 1.0.

12.  Internationalization Considerations

   As specified under Section 11.6, XML streams MUST be encoded in
   UTF-8.

   As specified under Section 4.7, an XML stream SHOULD include an 'xml:
   lang' attribute specifying the default language for any XML character
   data that is intended to be presented to a human user.  As specified
   under Section 8.1.5, an XML stanza SHOULD include an 'xml:lang'
   attribute if the stanza contains XML character data that is intended
   to be presented to a human user.  A server SHOULD apply the default
   'xml:lang' attribute to stanzas it routes or delivers on behalf of
   connected entities, and MUST NOT modify or delete 'xml:lang'
   attributes on stanzas it receives from other entities.

   Internationalization of XMPP addresses is specified in [XMPP-ADDR].