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 6 of 9 – Pages 128 to 148
First   Prev   Next

Top   ToC   RFC6120 - Page 128   prevText

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'>
Top   ToC   RFC6120 - Page 129
   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).
Top   ToC   RFC6120 - Page 130
   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".
Top   ToC   RFC6120 - Page 131
   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>
Top   ToC   RFC6120 - Page 132
   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>
Top   ToC   RFC6120 - Page 133
   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>
Top   ToC   RFC6120 - Page 134
   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'>
Top   ToC   RFC6120 - Page 135
   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'>
Top   ToC   RFC6120 - Page 136
   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>
Top   ToC   RFC6120 - Page 137
   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.)
Top   ToC   RFC6120 - Page 138
   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.
Top   ToC   RFC6120 - Page 139
   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).
Top   ToC   RFC6120 - Page 140

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
Top   ToC   RFC6120 - Page 141
   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.
Top   ToC   RFC6120 - Page 142
   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.
Top   ToC   RFC6120 - Page 143

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].
Top   ToC   RFC6120 - Page 144
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.
Top   ToC   RFC6120 - Page 145
   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.
Top   ToC   RFC6120 - Page 146

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.
Top   ToC   RFC6120 - Page 147

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
Top   ToC   RFC6120 - Page 148
   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].


(page 148 continued on part 7)

Next Section