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

      <required/>

    </starttls>

  </stream:features>

A element MAY contain more than one mandatory-to-

negotiate feature. This means that the initiating entity can choose

among the mandatory-to-negotiate features at this stage of the stream

negotiation process. As an example, perhaps a future technology will

perform roughly the same function as TLS, so the receiving entity

might advertise support for both TLS and the future technology at the

same stage of the stream negotiation process. However, this applies

only at a given stage of the stream negotiation process and does not

apply to features that are mandatory-to-negotiate at different stages

(e.g., the receiving entity would not advertise both STARTTLS and

SASL as mandatory-to-negotiate, or both SASL and resource binding as

mandatory-to-negotiate, because TLS would need to be negotiated

before SASL and because SASL would need to be negotiated before

resource binding).

A element that contains both mandatory-to-negotiate and

voluntary-to-negotiate features indicates that the negotiation is not

complete but that the initiating entity MAY complete the voluntary-

to-negotiate feature(s) before it attempts to negotiate the

mandatory-to-negotiate feature(s).

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

    <compression xmlns='http://jabber.org/features/compress'>

      <method>zlib</method>

      <method>lzw</method>

    </compression>

  </stream:features>

A element that contains only voluntary-to-negotiate

features indicates that the stream negotiation is complete and that

the initiating entity is cleared to send XML stanzas, but that the

initiating entity MAY negotiate further features if desired.

Saint-Andre Standards Track [Page 26]

RFC 6120 XMPP Core March 2011

    <compression xmlns='http://jabber.org/features/compress'>

      <method>zlib</method>

      <method>lzw</method>

    </compression>

  </stream:features>

An empty element indicates that the stream negotiation is

complete and that the initiating entity is cleared to send XML

stanzas.

R: stream:features/

4.3.3. Restarts

On successful negotiation of a feature that necessitates a stream

restart, both parties MUST consider the previous stream to be

replaced but MUST NOT send a closing tag and MUST NOT

terminate the underlying TCP connection; instead, the parties MUST

reuse the existing connection, which might be in a new state (e.g.,

encrypted as a result of TLS negotiation). The initiating entity

then MUST send a new initial stream header, which SHOULD be preceded

by an XML declaration as described under Section 11.5. When the

receiving entity receives the new initial stream header, it MUST

generate a new stream ID (instead of reusing the old stream ID)

before sending a new response stream header (which SHOULD be preceded

by an XML declaration as described under Section 11.5).

4.3.4. Resending Features

The receiving entity MUST send an updated list of stream features to

the initiating entity after a stream restart. The list of updated

features MAY be empty if there are no further features to be

advertised or MAY include any combination of features.

4.3.5. Completion of Stream Negotiation

The receiving entity indicates completion of the stream negotiation

process by sending to the initiating entity either an empty

element or a element that contains only

voluntary-to-negotiate features. After doing so, the receiving

entity MAY send an empty element (e.g., after negotiation

of such voluntary-to-negotiate features) but MUST NOT send additional

stream features to the initiating entity (if the receiving entity has

new features to offer, preferably limited to mandatory-to-negotiate

or security-critical features, it can simply close the stream with a

stream error (Section 4.9.3.16) and then advertise the new

features when the initiating entity reconnects, preferably closing

Saint-Andre Standards Track [Page 27]

RFC 6120 XMPP Core March 2011

existing streams in a staggered way so that not all of the initiating

entities reconnect at once). Once stream negotiation is complete,

the initiating entity is cleared to send XML stanzas over the stream

for as long as the stream is maintained by both parties.

  Informational Note: Resource binding as specified under Section 7

  is an historical exception to the foregoing rule, since it is

  mandatory-to-negotiate for clients but uses XML stanzas for

  negotiation purposes.

The initiating entity MUST NOT attempt to send XML stanzas

(Section 8) to entities other than itself (i.e., the client's

connected resource or any other authenticated resource of the

client's account) or the server to which it is connected until stream

negotiation has been completed. Even if the initiating entity does

attempt to do so, the receiving entity MUST NOT accept such stanzas

and MUST close the stream with a stream error

(Section 4.9.3.12). This rule applies to XML stanzas only (i.e.,

, , and elements qualified by the content

namespace) and not to XML elements used for stream negotiation (e.g.,

elements used to complete TLS negotiation (Section 5) or SASL

negotiation (Section 6)).

4.3.6. Determination of Addresses

After the parties to an XML stream have completed the appropriate

aspects of stream negotiation, the receiving entity for a stream MUST

determine the initiating entity's JID.

For client-to-server communication, both SASL negotiation (Section 6)

and resource binding (Section 7) MUST be completed before the server

can determine the client's address. The client's bare JID

(localpart@domainpart) MUST be the authorization identity (as

defined by [SASL]), either (1) as directly communicated by the client

during SASL negotiation (Section 6) or (2) as derived by the server

from the authentication identity if no authorization identity was

specified during SASL negotiation. The resourcepart of the full JID

(<localpart@domainpart/resourcepart>) MUST be the resource negotiated

by the client and server during resource binding (Section 7). A

client MUST NOT attempt to guess at its JID but instead MUST consider

its JID to be whatever the server returns to it during resource

binding. The server MUST ensure that the resulting JID (including

localpart, domainpart, resourcepart, and separator characters)

conforms to the canonical format for XMPP addresses defined in

[XMPP-ADDR]; to meet this restriction, the server MAY replace the JID

sent by the client with the canonicalized JID as determined by the

server and communicate that JID to the client during resource

binding.

Saint-Andre Standards Track [Page 28]

RFC 6120 XMPP Core March 2011

For server-to-server communication, the initiating server's bare JID

() MUST be the authorization identity (as defined by

[SASL]), either (1) as directly communicated by the initiating server

during SASL negotiation (Section 6) or (2) as derived by the

receiving server from the authentication identity if no authorization

identity was specified during SASL negotiation. In the absence of

SASL negotiation, the receiving server MAY consider the authorization

identity to be an identity negotiated within the relevant

verification protocol (e.g., the 'from' attribute of the

element in Server Dialback [XEP-0220]).

  Security Warning: Because it is possible for a third party to

  tamper with information that is sent over the stream before a

  security layer such as TLS is successfully negotiated, it is

  advisable for the receiving server to treat any such unprotected

  information with caution; this applies especially to the 'from'

  and 'to' addresses on the first initial stream header sent by the

  initiating entity.

4.3.7. Flow Chart

We summarize the foregoing rules in the following non-normative flow

chart for the stream negotiation process, presented from the

perspective of the initiating entity.

Saint-Andre Standards Track [Page 29]

RFC 6120 XMPP Core March 2011

               +---------------------+

               | open TCP connection |

               +---------------------+

                   +---------------+

                   | send initial  |<-------------------------+

                   | stream header |                          ^

                   +---------------+                          |

                          |                                   |

                          v                                   |

                  +------------------+                        |

                  | receive response |                        |

                  | stream header    |                        |

                  +------------------+                        |

                          |                                   |

                          v                                   |

                   +----------------+                         |

                   | receive stream |                         |

+------------------>| features | |

^ {OPTIONAL} +----------------+ |

| | |

| v |

| +<-----------------+ |

| | |

| {empty?} ----> {all voluntary?} ----> {some mandatory?} |

| | no | no | |

| | yes | yes | yes |

| | v v |

| | +---------------+ +----------------+ |

| | +---------------+ +----------------+ |

| v | | |

| +---------+ v | |

| | DONE |<----- {negotiate?} | |

| +---------+ no | | |

| yes | | |

| v v |

| +--------->+<---------+ |

| | |

| v |

+<-------------------------- {restart mandatory?} ------------>+

              no                                     yes

              Figure 3: Stream Negotiation Flow Chart

Saint-Andre Standards Track [Page 30]

RFC 6120 XMPP Core March 2011

4.4. Closing a Stream

An XML stream from one entity to another can be closed at any time,

either because a specific stream error (Section 4.9) has occurred or

in the absence of an error (e.g., when a client simply ends its

session).

A stream is closed by sending a closing tag.

E: </stream:stream>

If the parties are using either two streams over a single TCP

connection or two streams over two TCP connections, the entity that

sends the closing stream tag MUST behave as follows:

Wait for the other party to also close its outbound stream before

   terminating the underlying TCP connection(s); this gives the

   other party an opportunity to finish transmitting any outbound

   data to the closing entity before the termination of the TCP

   connection(s).

Refrain from sending any further data over its outbound stream to

   the other entity, but continue to process data received from the

   other entity (and, if necessary, process such data).

Consider both streams to be void if the other party does not send

   its closing stream tag within a reasonable amount of time (where

   the definition of "reasonable" is a matter of implementation or

   deployment).

After receiving a reciprocal closing stream tag from the other

   party or waiting a reasonable amount of time with no response,

   terminate the underlying TCP connection(s).

  Security Warning: In accordance with Section 7.2.1 of [TLS], to

  help prevent a truncation attack the party that is closing the

  stream MUST send a TLS close_notify alert and MUST receive a

  responding close_notify alert from the other party before

  terminating the underlying TCP connection(s).

If the parties are using multiple streams over multiple TCP

connections, there is no defined pairing of streams and therefore the

behavior is a matter for implementation.

Saint-Andre Standards Track [Page 31]

RFC 6120 XMPP Core March 2011

4.5. Directionality

An XML stream is always unidirectional, by which is meant that XML

stanzas can be sent in only one direction over the stream (either

from the initiating entity to the receiving entity or from the

receiving entity to the initiating entity).

Depending on the type of session that has been negotiated and the

nature of the entities involved, the entities might use:

o Two streams over a single TCP connection, where the security

  context negotiated for the first stream is applied to the second

  stream.  This is typical for client-to-server sessions, and a

  server MUST allow a client to use the same TCP connection for both

  streams.

o Two streams over two TCP connections, where each stream is

  separately secured.  In this approach, one TCP connection is used

  for the stream in which stanzas are sent from the initiating

  entity to the receiving entity, and the other TCP connection is

  used for the stream in which stanzas are sent from the receiving

  entity to the initiating entity.  This is typical for server-to-

  server sessions.

o Multiple streams over two or more TCP connections, where each

  stream is separately secured.  This approach is sometimes used for

  server-to-server communication between two large XMPP service

  providers; however, this can make it difficult to maintain

  coherence of data received over multiple streams in situations

  described under Section 10.1, which is why 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).

This concept of directionality applies only to stanzas and explicitly

does not apply to first-level children of the stream root that are

used to bootstrap or manage the stream (e.g., first-level elements

used for TLS negotiation, SASL negotiation, Server Dialback

[XEP-0220], and Stream Management [XEP-0198]).

The foregoing considerations imply that while completing STARTTLS

negotiation (Section 5) and SASL negotiation (Section 6) two servers

would use one TCP connection, but after the stream negotiation

process is done that original TCP connection would be used only for

the initiating server to send XML stanzas to the receiving server.

In order for the receiving server to send XML stanzas to the

initiating server, the receiving server would need to reverse the

roles and negotiate an XML stream from the receiving server to the

Saint-Andre Standards Track [Page 32]

RFC 6120 XMPP Core March 2011

initiating server over a separate TCP connection. This separate TCP

connection is then secured using a new round of TLS and/or SASL

negotiation.

  Implementation Note: For historical reasons, a server-to-server

  session always uses two TCP connections.  While that approach

  remains the standard behavior described in this document,

  extensions such as [XEP-0288] enable servers to negotiate the use

  of a single TCP connection for bidirectional stanza exchange.

  Informational Note: Although XMPP developers sometimes apply the

  terms "unidirectional" and "bidirectional" to the underlying TCP

  connection (e.g., calling the TCP connection for a client-to-

  server session "bidirectional" and the TCP connection for a

  server-to-server session "unidirectional"), strictly speaking a

  stream is always unidirectional (because the initiating entity and

  receiving entity always have a minimum of two streams, one in each

  direction) and a TCP connection is always bidirectional (because

  TCP traffic can be sent in both directions).  Directionality

  applies to the application-layer traffic sent over the TCP

  connection, not to the transport-layer traffic sent over the TCP

  connection itself.

4.6. Handling of Silent Peers

When an entity that is a party to a stream has not received any XMPP

traffic from its stream peer for some period of time, the peer might

appear to be silent. There are several reasons why this might

happen:

The underlying TCP connection is dead.

The XML stream is broken despite the fact that the underlying TCP

   connection is alive.

The peer is idle and simply has not sent any XMPP traffic over

   its XML stream to the entity.

These three conditions are best handled separately, as described in

the following sections.

  Implementation Note: For the purpose of handling silent peers, we

  treat a two unidirectional TCP connections as conceptually

  equivalent to a single bidirectional TCP connection (see

  Section 4.5); however, implementers need to be aware that, in the

  case of two unidirectional TCP connections, responses to traffic

  at the XMPP application layer will come back from the peer on the

  second TCP connection.  In addition, the use of multiple streams

Saint-Andre Standards Track [Page 33]

RFC 6120 XMPP Core March 2011

  in each direction (which is a somewhat frequent deployment choice

  for server-to-server connectivity among large XMPP service

  providers) further complicates application-level checking of XMPP

  streams and their underlying TCP connections, because there is no

  necessary correlation between any given initial stream and any

  given response stream.

4.6.1. Dead Connection

If the underlying TCP connection is dead, stream-level checks (e.g.,

[XEP-0199] and [XEP-0198]) are ineffective. Therefore, it is

unnecessary to close the stream with or without an error, and it is

appropriate instead to simply terminate the TCP connection.

One common method for checking the TCP connection is to send a space

character (U+0020) between XML stanzas, which is allowed for XML

streams as described under Section 11.7; the sending of such a space

character is properly called a "whitespace keepalive" (the term

"whitespace ping" is often used, despite the fact that it is not a

ping since no "pong" is possible). However, this is not allowed

during TLS negotiation or SASL negotiation, as described under

Section 5.3.3 and Section 6.3.5.

4.6.2. Broken Stream

Even if the underlying TCP connection is alive, the peer might never

respond to XMPP traffic that the entity sends, whether normal stanzas

or specialized stream-checking traffic such as the application-level

pings defined in [XEP-0199] or the more comprehensive Stream

Management protocol defined in [XEP-0198]. In this case, it is

appropriate for the entity to close a broken stream with a

stream error (Section 4.9.3.4).

4.6.3. Idle Peer

Even if the underlying TCP connection is alive and the stream is not

broken, the peer might have sent no stanzas for a certain period of

time. In this case, the peer itself MAY close the stream (as

described under Section 4.4) rather than leaving an unused stream

open. If the idle peer does not close the stream, the other party

MAY either close the stream using the handshake described under

Section 4.4 or close the stream with a stream error (e.g., <resource-

constraint/> (Section 4.9.3.17) if the entity has reached a limit on

the number of open TCP connections or

(Section 4.9.3.14) if the connection has exceeded a local timeout

policy). However, consistent with the order of layers (specified

under Section 13.3), the other party is advised to verify that the

underlying TCP connection is alive and the stream is unbroken (as

Saint-Andre Standards Track [Page 34]

RFC 6120 XMPP Core March 2011

described above) before concluding that the peer is idle.

Furthermore, it is preferable to be liberal in accepting idle peers,

since experience has shown that doing so improves the reliability of

communication over XMPP networks and that it is typically more

efficient to maintain a stream between two servers than to

aggressively time out such a stream.

4.6.4. Use of Checking Methods

Implementers are advised to support whichever stream-checking and

connection-checking methods they deem appropriate, but to carefully

weigh the network impact of such methods against the benefits of

discovering broken streams and dead TCP connections in a timely

manner. The length of time between the use of any particular check

is very much a matter of local service policy and depends strongly on

the network environment and usage scenarios of a given deployment and

connection type. At the time of writing, it is RECOMMENDED that any

such check be performed not more than once every 5 minutes and that,

ideally, such checks will be initiated by clients rather than

servers. Those who implement XMPP software and deploy XMPP services

are encouraged to seek additional advice regarding appropriate timing

of stream-checking and connection-checking methods, particularly when

power-constrained devices are being used (e.g., in mobile

environments).

4.7. Stream Attributes

The attributes of the root element are defined in the

following sections.

  Security Warning: Until and unless the confidentiality and

  integrity of the stream are protected via TLS as described under

  Section 5 or an equivalent security layer (such as the SASL GSSAPI

  mechanism), the attributes provided in a stream header could be

  tampered with by an attacker.

  Implementation Note: The attributes of the root <stream/> element

  are not prepended by a namespace prefix because, as explained in

  [XML-NAMES], "[d]efault namespace declarations do not apply

  directly to attribute names; the interpretation of unprefixed

  attributes is determined by the element on which they appear."

4.7.1. from

The 'from' attribute specifies an XMPP identity of the entity sending

the stream element.

Saint-Andre Standards Track [Page 35]

RFC 6120 XMPP Core March 2011

For initial stream headers in client-to-server communication, the

'from' attribute is the XMPP identity of the principal controlling

the client, i.e., a JID of the form localpart@domainpart. The

client might not know the XMPP identity, e.g., because the XMPP

identity is assigned at a level other than the XMPP application layer

(as in the Generic Security Service Application Program Interface

[GSS-API]) or is derived by the server from information provided by

the client (as in some deployments of end-user certificates with the

SASL EXTERNAL mechanism). Furthermore, if the client considers the

XMPP identity to be private information then it is advised not to

include a 'from' attribute before the confidentiality and integrity

of the stream are protected via TLS or an equivalent security layer.

However, if the client knows the XMPP identity then it SHOULD include

the 'from' attribute after the confidentiality and integrity of the

stream are protected via TLS or an equivalent security layer.

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

For initial stream headers in server-to-server communication, the

'from' attribute is one of the configured FQDNs of the server, i.e.,

a JID of the form . The initiating server might have

more than one XMPP identity, e.g., in the case of a server that

provides virtual hosting, so it will need to choose an identity that

is associated with this output stream (e.g., based on the 'to'

attribute of the stanza that triggered the stream negotiation

attempt). Because a server is a "public entity" on the XMPP network,

it MUST include the 'from' attribute after the confidentiality and

integrity of the stream are protected via TLS or an equivalent

security layer.

  <stream:stream

      from='example.net'

      to='im.example.com'

      version='1.0'

      xml:lang='en'

      xmlns='jabber:server'

      xmlns:stream='http://etherx.jabber.org/streams'>

Saint-Andre Standards Track [Page 36]

RFC 6120 XMPP Core March 2011

For response stream headers in both client-to-server and server-to-

server communication, the receiving entity MUST include the 'from'

attribute and MUST set its value to one of the receiving entity's

FQDNs (which MAY be an FQDN other than that specified in the 'to'

attribute of the initial stream header, as described under

Section 4.9.1.3 and Section 4.9.3.6).

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

Whether or not the 'from' attribute is included, each entity MUST

verify the identity of the other entity before exchanging XML stanzas

with it, as described under Section 13.5.

  Interoperability Note: It is possible that implementations based

  on [RFC3920] will not include the 'from' address on any stream

  headers (even ones whose confidentiality and integrity are

  protected); an entity SHOULD be liberal in accepting such stream

  headers.

4.7.2. to

For initial stream headers in both client-to-server and server-to-

server communication, the initiating entity MUST include the 'to'

attribute and MUST set its value to a domainpart that the initiating

entity knows or expects the receiving entity to service. (The same

information can be provided in other ways, such as a Server Name

Indication during TLS negotiation as described in [TLS-EXT].)

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

For response stream headers in client-to-server communication, if the

client included a 'from' attribute in the initial stream header then

the server MUST include a 'to' attribute in the response stream

Saint-Andre Standards Track [Page 37]

RFC 6120 XMPP Core March 2011

header and MUST set its value to the bare JID specified in the 'from'

attribute of the initial stream header. If the client did not

include a 'from' attribute in the initial stream header then the

server MUST NOT include a 'to' attribute in the response stream

header.

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

For response stream headers in server-to-server communication, the

receiving entity MUST include a 'to' attribute in the response stream

header and MUST set its value to the domainpart specified in the

'from' attribute of the initial stream header.

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

Whether or not the 'to' attribute is included, each entity MUST

verify the identity of the other entity before exchanging XML stanzas

with it, as described under Section 13.5.

  Interoperability Note: It is possible that implementations based

  on [RFC3920] will not include the 'to' address on stream headers;

  an entity SHOULD be liberal in accepting such stream headers.

4.7.3. id

The 'id' attribute specifies a unique identifier for the stream,

called a "stream ID". The stream ID MUST be generated by the

receiving entity when it sends a response stream header and MUST BE

unique within the receiving application (normally a server).

Saint-Andre Standards Track [Page 38]

RFC 6120 XMPP Core March 2011

  Security Warning: The stream ID MUST be both unpredictable and

  non-repeating because it can be security-critical when reused by

  an authentication mechanisms, as is the case for Server Dialback

  [XEP-0220] and the "XMPP 0.9" authentication mechanism used before

  RFC 3920 defined the use of SASL in XMPP; for recommendations

  regarding randomness for security purposes, see [RANDOM].

For initial stream headers, the initiating entity MUST NOT include

the 'id' attribute; however, if the 'id' attribute is included, the

receiving entity MUST ignore it.

For response stream headers, the receiving entity MUST include the

'id' attribute.

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

  Interoperability Note: In RFC 3920, the text regarding inclusion

  of the 'id' attribute was ambiguous, leading some implementations

  to leave the attribute off the response stream header.

4.7.4. xml:lang

The 'xml:lang' attribute specifies an entity's preferred or default

language for any human-readable XML character data to be sent over

the stream (an XML stanza can also possess an 'xml:lang' attribute,

as discussed under Section 8.1.5). The syntax of this attribute is

defined in Section 2.12 of [XML]; in particular, the value of the

'xml:lang' attribute MUST conform to the NMTOKEN datatype (as defined

in Section 2.3 of [XML]) and MUST conform to the language identifier

format defined in [LANGTAGS].

For initial stream headers, the initiating entity SHOULD include the

'xml:lang' attribute.

Saint-Andre Standards Track [Page 39]

RFC 6120 XMPP Core March 2011

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

For response stream headers, the receiving entity MUST include the

'xml:lang' attribute. The following rules apply:

o If the initiating entity included an 'xml:lang' attribute in its

  initial stream header and the receiving entity supports that

  language in the human-readable XML character data that it

  generates and sends to the initiating entity (e.g., in the <text/>

  element for stream and stanza errors), the value of the 'xml:lang'

  attribute MUST be the identifier for the initiating entity's

  preferred language (e.g., "de-CH").

o If the receiving entity supports a language that matches the

  initiating entity's preferred language according to the "lookup

  scheme" specified in Section 3.4 of [LANGMATCH] (e.g., "de"

  instead of "de-CH"), then the value of the 'xml:lang' attribute

  SHOULD be the identifier for the matching language.

o If the receiving entity does not support the initiating entity's

  preferred language or a matching language according to the lookup

  scheme (or if the initiating entity did not include the 'xml:lang'

  attribute in its initial stream header), then the value of the

  'xml:lang' attribute MUST be the identifier for the default

  language of the receiving entity (e.g., "en").

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

If the initiating entity included the 'xml:lang' attribute in its

initial stream header, the receiving entity SHOULD remember that

value as the default xml:lang for all stanzas sent by the initiating

entity over the current stream. As described under Section 8.1.5,

Saint-Andre Standards Track [Page 40]

RFC 6120 XMPP Core March 2011

the initiating entity MAY include the 'xml:lang' attribute in any XML

stanzas it sends over the stream. If the initiating entity does not

include the 'xml:lang' attribute in any such stanza, the receiving

entity SHOULD add the 'xml:lang' attribute to the stanza when routing

it to a remote server or delivering it to a connected client, where

the value of the attribute MUST be the identifier for the language

preferred by the initiating entity (even if the receiving entity does

not support that language for human-readable XML character data it

generates and sends to the initiating entity, such as in stream or

stanza errors). If the initiating entity includes the 'xml:lang'

attribute in any such stanza, the receiving entity MUST NOT modify or

delete it when routing it to a remote server or delivering it to a

connected client.

4.7.5. version

The inclusion of the version attribute set to a value of at least

"1.0" signals support for the stream-related protocols defined in

this specification, including TLS negotiation (Section 5), SASL

negotiation (Section 6), stream features (Section 4.3.2), and stream

errors (Section 4.9).

The version of XMPP specified in this specification is "1.0"; in

particular, XMPP 1.0 encapsulates the stream-related protocols as

well as the basic semantics of the three defined XML stanza types

(, , and as described under Sections

8.2.1, 8.2.2, and 8.2.3, respectively).

The numbering scheme for XMPP versions is ".". The

major and minor numbers MUST be treated as separate integers and each

number MAY be incremented higher than a single digit. Thus, "XMPP

2.4" would be a lower version than "XMPP 2.13", which in turn would

be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be

ignored by recipients and MUST NOT be sent.

The major version number will be incremented only if the stream and

stanza formats or obligatory actions have changed so dramatically

that an older version entity would not be able to interoperate with a

newer version entity if it simply ignored the elements and attributes

it did not understand and took the actions defined in the older

specification.

The minor version number will be incremented only if significant new

capabilities have been added to the core protocol (e.g., a newly

defined value of the 'type' attribute for message, presence, or IQ

stanzas). The minor version number MUST be ignored by an entity with

a smaller minor version number, but MAY be used for informational

purposes by the entity with the larger minor version number (e.g.,

Saint-Andre Standards Track [Page 41]

RFC 6120 XMPP Core March 2011

the entity with the larger minor version number would simply note

that its correspondent would not be able to understand that value of

the 'type' attribute and therefore would not send it).

The following rules apply to the generation and handling of the

'version' attribute within stream headers:

The initiating entity MUST set the value of the 'version'

   attribute in the initial stream header to the highest version

   number it supports (e.g., if the highest version number it

   supports is that defined in this specification, it MUST set the

   value to "1.0").

The receiving entity MUST set the value of the 'version'

   attribute in the response stream header to either the value

   supplied by the initiating entity or the highest version number

   supported by the receiving entity, whichever is lower.  The

   receiving entity MUST perform a numeric comparison on the major

   and minor version numbers, not a string match on

   "<major>.<minor>".

If the version number included in the response stream header is

   at least one major version lower than the version number included

   in the initial stream header and newer version entities cannot

   interoperate with older version entities as described, the

   initiating entity SHOULD close the stream with an <unsupported-

   version/> stream error (Section 4.9.3.25).

If either entity receives a stream header with no 'version'

   attribute, the entity MUST consider the version supported by the

   other entity to be "0.9" and SHOULD NOT include a 'version'

   attribute in the response stream header.

Saint-Andre Standards Track [Page 42]

RFC 6120 XMPP Core March 2011

4.7.6. Summary of Stream Attributes

The following table summarizes the attributes of the root

element.

+----------+--------------------------+-------------------------+

| | initiating to receiving | receiving to initiating |

+----------+--------------------------+-------------------------+

| to | JID of receiver | JID of initiator |

| from | JID of initiator | JID of receiver |

| id | ignored | stream identifier |

| xml:lang | default language | default language |

| version | XMPP 1.0+ supported | XMPP 1.0+ supported |

+----------+--------------------------+-------------------------+

                    Figure 4: Stream Attributes

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 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 (Section 4.9.3.10), although

some existing implementations send (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).

Saint-Andre Standards Track [Page 43]

RFC 6120 XMPP Core March 2011

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>

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

Saint-Andre Standards Track [Page 44]

RFC 6120 XMPP Core March 2011

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 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

Saint-Andre Standards Track [Page 45]

RFC 6120 XMPP Core March 2011

  (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:

Saint-Andre Standards Track [Page 46]

RFC 6120 XMPP Core March 2011

 <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

(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:

The stream header needs to contain a namespace declaration for

   both the content namespace and the stream namespace.

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

Saint-Andre Standards Track [Page 47]

RFC 6120 XMPP Core March 2011

 <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 (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

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 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 element with an appropriate child element specifying

the error condition and then immediately close the stream as

described under Section 4.4.

Saint-Andre Standards Track [Page 48]

RFC 6120 XMPP Core March 2011

C: No closing tag!

    <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 tag, include the

element as a child of the stream element, and send the closing

tag (preferably in the same TCP packet).

  <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/'>

  <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>

Saint-Andre Standards Track [Page 49]

RFC 6120 XMPP Core March 2011

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.

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

  <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.

Saint-Andre Standards Track [Page 50]

RFC 6120 XMPP Core March 2011

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 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 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 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

Saint-Andre Standards Track [Page 51]

RFC 6120 XMPP Core March 2011

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).)

    <body>No closing tag!

  </message>

    <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 , , <not-well-

formed/>, , and . 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.)

  <foobar:stream

      from='juliet@im.example.com'

      to='im.example.com'

      version='1.0'

      xmlns='jabber:client'

      xmlns:foobar='http://etherx.jabber.org/streams'>

Saint-Andre Standards Track [Page 52]

RFC 6120 XMPP Core March 2011

  <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).

  <stream:stream

      from='juliet@im.example.com'

      to='im.example.com'

      version='1.0'

      xmlns='jabber:client'

      xmlns:stream='http://etherx.jabber.org/streams'>

  <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>

Saint-Andre Standards Track [Page 53]

RFC 6120 XMPP Core March 2011

If a client receives a 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.)

  <stream:stream

      from='example.net'

      to='foo.im.example.com'

      version='1.0'

      xmlns='jabber:server'

      xmlns:stream='http://etherx.jabber.org/streams'>

Saint-Andre Standards Track [Page 54]

RFC 6120 XMPP Core March 2011

  <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.)

  <stream:stream

      from='example.net'

      to='example.org'

      version='1.0'

      xmlns='jabber:server'

      xmlns:stream='http://etherx.jabber.org/streams'>

  <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>

Saint-Andre Standards Track [Page 55]

RFC 6120 XMPP Core March 2011

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.)

    <body>Wherefore art thou?</body>

  </message>

    <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.

    <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".)

    <body>Neither, fair saint, if either thee dislike.</body>

  </message>

Saint-Andre Standards Track [Page 56]

RFC 6120 XMPP Core March 2011

    <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.)

  <stream:stream

      from='juliet@im.example.com'

      to='im.example.com'

      version='1.0'

      xmlns='jabber:client'

      xmlns:stream='http://wrong.namespace.example.org/'>

  <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.)

Saint-Andre Standards Track [Page 57]

RFC 6120 XMPP Core March 2011

P: <iq from='example.net'

      id='l3b1vs75'

      to='im.example.com'

      type='subscribe'>

    <ping xmlns='urn:xmpp:ping'/>

  </iq>

    <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.)

  <stream:stream

      from='juliet@im.example.com'

      to='im.example.com'

      version='1.0'

      xmlns='jabber:client'

      xmlns:stream='http://etherx.jabber.org/streams'>

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

    <body>Wherefore art thou?</body>

  </message>

Saint-Andre Standards Track [Page 58]

RFC 6120 XMPP Core March 2011

    <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.)

    <foo:body>What is this foo?</foo:body>

  </message>

    <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 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.)

    <body>[ ... the-emacs-manual ... ]</body>

  </message>

Saint-Andre Standards Track [Page 59]

RFC 6120 XMPP Core March 2011

    <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

condition is more appropriate.

  <stream:stream

      from='juliet@im.example.com'

      to='im.example.com'

      version='1.0'

      xmlns='jabber:client'

      xmlns:stream='http://etherx.jabber.org/streams'>

  <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

Saint-Andre Standards Track [Page 60]

RFC 6120 XMPP Core March 2011

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).

    <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.

  <stream:stream

      from='juliet@im.example.com'

      to='im.example.com'

      version='1.0'

      xmlns='jabber:client'

      xmlns:stream='http://etherx.jabber.org/streams'>

  <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.)

Saint-Andre Standards Track [Page 61]

RFC 6120 XMPP Core March 2011

    <!--<subject/>-->

    <body>This message has no subject.</body>

  </message>

    <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 element as described under

Section 3.2.

  <stream:stream

      from='juliet@im.example.com'

      to='im.example.com'

      version='1.0'

      xmlns='jabber:client'

      xmlns:stream='http://etherx.jabber.org/streams'>

Saint-Andre Standards Track [Page 62]

RFC 6120 XMPP Core March 2011

  <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 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 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).

Saint-Andre Standards Track [Page 63]

RFC 6120 XMPP Core March 2011

4.9.3.20. system-shutdown

The server is being shut down and all active streams are being

closed.

    <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.

    <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.)

  <stream:stream

      from='juliet@im.example.com'

      to='im.example.com'

      version='1.0'

      xmlns='jabber:client'

      xmlns:stream='http://etherx.jabber.org/streams'>

Saint-Andre Standards Track [Page 64]

RFC 6120 XMPP Core March 2011

  <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.)

    <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).

Saint-Andre Standards Track [Page 65]

RFC 6120 XMPP Core March 2011

(In the following example, the client attempts to send a first-level

child element of qualified by the 'jabber:client'

namespace, but the schema for that namespace defines no such

element.)

    <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>

    <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.

  <stream:stream

      from='juliet@im.example.com'

      to='im.example.com'

      version='11.0'

      xmlns='jabber:client'

      xmlns:stream='http://etherx.jabber.org/streams'>

Saint-Andre Standards Track [Page 66]

RFC 6120 XMPP Core March 2011

  <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 element will

contain two or three child elements.

    <body>

      My keyboard layout is:

      QWERTYUIOP{}|

      ASDFGHJKL:"

      ZXCVBNM<>?

    </body>

  </message>

    <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>

Saint-Andre Standards Track [Page 67]

RFC 6120 XMPP Core March 2011

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:

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

  <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>

Saint-Andre Standards Track [Page 68]

RFC 6120 XMPP Core March 2011

A connection gone bad:

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

  <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>

   <not-well-formed

       xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>

  </stream:error>

  </stream:stream>

More detailed examples are provided under Section 9.

STARTTLS Negotiation

5.1. Fundamentals

XMPP includes a method for securing the stream from tampering and

eavesdropping. This channel encryption method makes use of the

Transport Layer Security [TLS] protocol, specifically a "STARTTLS"

extension that is modeled after similar extensions for the [IMAP],

Saint-Andre Standards Track [Page 69]

RFC 6120 XMPP Core March 2011

[POP3], and [ACAP] protocols as described in [USINGTLS]. The XML

namespace name for the STARTTLS extension is

'urn:ietf:params:xml:ns:xmpp-tls'.

5.2. Support

Support for STARTTLS is REQUIRED in XMPP client and server

implementations. An administrator of a given deployment MAY specify

that TLS is mandatory-to-negotiate for client-to-server

communication, server-to-server communication, or both. An

initiating entity SHOULD use TLS to secure its stream with the

receiving entity before proceeding with SASL authentication.

5.3. Stream Negotiation Rules

5.3.1. Mandatory-to-Negotiate

If the receiving entity advertises only the STARTTLS feature or if

the receiving entity includes the child element as

explained under Section 5.4.1, the parties MUST consider TLS as

mandatory-to-negotiate. If TLS is mandatory-to-negotiate, the

receiving entity SHOULD NOT advertise support for any stream feature

except STARTTLS during the initial stage of the stream negotiation

process, because further stream features might depend on prior

negotiation of TLS given the order of layers in XMPP (e.g., the

particular SASL mechanisms offered by the receiving entity will

likely depend on whether TLS has been negotiated).

5.3.2. Restart

After TLS negotiation, the parties MUST restart the stream.

5.3.3. Data Formatting

During STARTTLS negotiation, the entities MUST NOT send any

whitespace as separators between XML elements (i.e., from the last

character of the first-level element qualified by the

'urn:ietf:params:xml:ns:xmpp-tls' namespace as sent by the initiating

entity, until the last character of the first-level

element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace

as sent by the receiving entity). This prohibition helps to ensure

proper security layer byte precision. Any such whitespace shown in

the STARTTLS examples provided in this document is included only for

the sake of readability.

Saint-Andre Standards Track [Page 70]

RFC 6120 XMPP Core March 2011

5.3.4. Order of TLS and SASL Negotiations

If the initiating entity chooses to use TLS, STARTTLS negotiation

MUST be completed before proceeding to SASL negotiation (Section 6);

this order of negotiation is necessary to help safeguard

authentication information sent during SASL negotiation, as well as

to make it possible to base the use of the SASL EXTERNAL mechanism on

a certificate (or other credentials) provided during prior TLS

negotiation.

5.3.5. TLS Renegotiation

The TLS protocol allows either party in a TLS-protected channel to

initiate a new handshake that establishes new cryptographic

parameters (see [TLS-NEG]). The cases most commonly mentioned are:

Refreshing encryption keys.

Wrapping the TLS sequence number as explained in Section 6.1 of

   [TLS].

Protecting client credentials by completing server authentication

   first and then completing client authentication over the

   protected channel.

Because it is relatively inexpensive to establish streams in XMPP,

for the first two cases it is preferable to use an XMPP stream reset

(as described under Section 4.9.3.16) instead of performing TLS

renegotiation.

The third case has improved security characteristics when the TLS

client (which might be an XMPP server) presents credentials to the

TLS server. If communicating such credentials to an unauthenticated

TLS server might leak private information, it can be appropriate to

complete TLS negotiation for the purpose of authenticating the TLS

server to the TLS client and then attempt TLS renegotiation for the

purpose of authenticating the TLS client to the TLS server. However,

this case is extremely rare because the credentials presented by an

XMPP server or XMPP client acting as a TLS client are almost always

public (i.e., a PKIX certificate), and therefore providing those

credentials before authenticating the XMPP server acting as a TLS

server would not in general leak private information.

As a result, implementers are encouraged to carefully weigh the costs

and benefits of TLS renegotiation before supporting it in their

software, and XMPP entities that act as TLS clients are discouraged

Saint-Andre Standards Track [Page 71]

RFC 6120 XMPP Core March 2011

from attempting TLS renegotiation unless the certificate (or other

credential information) sent during TLS negotiation is known to be

private.

Support for TLS renegotiation is strictly OPTIONAL. However,

implementations that support TLS renegotiation MUST implement and use

the TLS Renegotiation Extension [TLS-NEG].

If an entity that does not support TLS renegotiation detects a

renegotiation attempt, then it MUST immediately close the underlying

TCP connection without returning a stream error (since the violation

has occurred at the TLS layer, not the XMPP layer, as described under

Section 13.3).

If an entity that supports TLS renegotiation detects a TLS

renegotiation attempt that does not use the TLS Renegotiation

Extension [TLS-NEG], then it MUST immediately close the underlying

TCP connection without returning a stream error (since the violation

has occurred at the TLS layer, not the XMPP layer as described under

Section 13.3).

5.3.6. TLS Extensions

Either party to a stream MAY include any TLS extension during the TLS

negotiation itself. This is a matter for the TLS layer, not the XMPP

layer.

5.4. Process

5.4.1. Exchange of Stream Headers and Stream Features

The initiating entity resolves the FQDN of the receiving entity as

specified under Section 3, opens a TCP connection to the advertised

port at the resolved IP address, and sends an initial stream header

to the receiving entity.

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

The receiving entity MUST send a response stream header to the

initiating entity over the TCP connection opened by the initiating

entity.

Saint-Andre Standards Track [Page 72]

RFC 6120 XMPP Core March 2011

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

The receiving entity then MUST send stream features to the initiating

entity. If the receiving entity supports TLS, the stream features

MUST include an advertisement for support of STARTTLS negotiation,

i.e., a element qualified by the

'urn:ietf:params:xml:ns:xmpp-tls' namespace.

If the receiving entity considers STARTTLS negotiation to be

mandatory-to-negotiate, the element MUST contain an empty

child element.

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

      <required/>

    </starttls>

  </stream:features>

5.4.2. Initiation of STARTTLS Negotiation

5.4.2.1. STARTTLS Command

In order to begin the STARTTLS negotiation, the initiating entity

issues the STARTTLS command (i.e., a element qualified by

the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the

receiving entity that it wishes to begin a STARTTLS negotiation to

secure the stream.

The receiving entity MUST reply with either a element

(proceed case) or a element (failure case) qualified by

the 'urn:ietf:params:xml:ns:xmpp-tls' namespace.

5.4.2.2. Failure Case

If the failure case occurs, the receiving entity MUST return a

element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls'

namespace, close the XML stream, and terminate the underlying TCP

connection.

Saint-Andre Standards Track [Page 73]

RFC 6120 XMPP Core March 2011

R: </stream:stream>

Causes for the failure case include but are not limited to:

The initiating entity has sent a malformed STARTTLS command.

The receiving entity did not offer the STARTTLS feature in its

   stream features.

The receiving entity cannot complete STARTTLS negotiation because

   of an internal error.

  Informational Note: STARTTLS failure is not triggered by TLS

  errors such as bad_certificate or handshake_failure, which are

  generated and handled during the TLS negotiation itself as

  described in [TLS].

If the failure case occurs, the initiating entity MAY attempt to

reconnect as explained under Section 3.3.

5.4.2.3. Proceed Case

If the proceed case occurs, the receiving entity MUST return a

element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls'

namespace.

The receiving entity MUST consider the TLS negotiation to have begun

immediately after sending the closing '>' character of the

element to the initiating entity. The initiating entity MUST

consider the TLS negotiation to have begun immediately after

receiving the closing '>' character of the element from

the receiving entity.

The entities now proceed to TLS negotiation as explained in the next

section.

5.4.3. TLS Negotiation

5.4.3.1. Rules

In order to complete TLS negotiation over the TCP connection, the

entities MUST follow the process defined in [TLS].

Saint-Andre Standards Track [Page 74]

RFC 6120 XMPP Core March 2011

The following rules apply:

The entities MUST NOT send any further XML data until the TLS

   negotiation is complete.

When using any of the mandatory-to-implement (MTI) ciphersuites

   specified under Section 13.8, the receiving entity MUST present a

   certificate.

So that mutual certificate authentication will be possible, the

   receiving entity SHOULD send a certificate request to the

   initiating entity, and the initiating entity SHOULD send a

   certificate to the receiving entity (but for privacy reasons

   might opt not to send a certificate until after the receiving

   entity has authenticated to the initiating entity).

The receiving entity SHOULD choose which certificate to present

   based on the domainpart contained in the 'to' attribute of the

   initial stream header (in essence, this domainpart is

   functionally equivalent to the Server Name Indication defined for

   TLS in [TLS-EXT]).

To determine if the TLS negotiation will succeed, the initiating

   entity MUST attempt to validate the receiving entity's

   certificate in accordance with the certificate validation

   procedures specified under Section 13.7.2.

If the initiating entity presents a certificate, the receiving

   entity too MUST attempt to validate the initiating entity's

   certificate in accordance with the certificate validation

   procedures specified under Section 13.7.2.

Following successful TLS negotiation, all further data

   transmitted by either party MUST be protected with the negotiated

   algorithms, keys, and secrets (i.e., encrypted, integrity-

   protected, or both depending on the ciphersuite used).

  Security Warning: See Section 13.8 regarding ciphersuites that

  MUST be supported for TLS; naturally, other ciphersuites MAY be

  supported as well.

5.4.3.2. TLS Failure

If the TLS negotiation results in failure, the receiving entity MUST

terminate the TCP connection.

Saint-Andre Standards Track [Page 75]

RFC 6120 XMPP Core March 2011

The receiving entity MUST NOT send a closing tag before

terminating the TCP connection (since the failure has occurred at the

TLS layer, not the XMPP layer as described under Section 13.3).

The initiating entity MAY attempt to reconnect as explained under

Section 3.3, with or without attempting TLS negotiation (in

accordance with local service policy, user-configured preferences,

etc.).

5.4.3.3. TLS Success

If the TLS negotiation is successful, then the entities MUST proceed

as follows.

The initiating entity MUST discard any information transmitted in

   layers above TCP that it obtained from the receiving entity in an

   insecure manner before TLS took effect (e.g., the receiving

   entity's 'from' address or the stream ID and stream features

   received from the receiving entity).

The receiving entity MUST discard any information transmitted in

   layers above TCP that it obtained from the initiating entity in

   an insecure manner before TLS took effect (e.g., the initiating

   entity's 'from' address).

The initiating entity MUST send a new initial stream header to

   the receiving entity over the encrypted connection (as specified

   under Section 4.3.3, the initiating entity MUST NOT send a

   closing </stream> tag before sending the new initial stream

   header, since the receiving entity and initiating entity MUST

   consider the original stream to be replaced upon success of the

   TLS negotiation).

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

The receiving entity MUST respond with a new response stream

   header over the encrypted connection (for which it MUST generate

   a new stream ID instead of reusing the old stream ID).

Saint-Andre Standards Track [Page 76]

RFC 6120 XMPP Core March 2011

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

The receiving entity also MUST send stream features to the

   initiating entity, which MUST NOT include the STARTTLS feature

   but which SHOULD include the SASL stream feature as described

   under Section 6 (see especially Section 6.4.1 regarding the few

   reasons why the SASL stream feature would not be offered here).

    <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

      <mechanism>EXTERNAL</mechanism>

      <mechanism>SCRAM-SHA-1-PLUS</mechanism>

      <mechanism>SCRAM-SHA-1</mechanism>

      <mechanism>PLAIN</mechanism>

    </mechanisms>

  </stream:features>

SASL Negotiation

6.1. Fundamentals

XMPP includes a method for authenticating a stream by means of an

XMPP-specific profile of the Simple Authentication and Security Layer

protocol (see [SASL]). SASL provides a generalized method for adding

authentication support to connection-based protocols, and XMPP uses

an XML namespace profile of SASL that conforms to the profiling

requirements of [SASL]. The XML namespace name for the SASL

extension is 'urn:ietf:params:xml:ns:xmpp-sasl'.

6.2. Support

Support for SASL negotiation is REQUIRED in XMPP client and server

implementations.

6.3. Stream Negotiation Rules

6.3.1. Mandatory-to-Negotiate

The parties to a stream MUST consider SASL as mandatory-to-negotiate.

Saint-Andre Standards Track [Page 77]

RFC 6120 XMPP Core March 2011

6.3.2. Restart

After SASL negotiation, the parties MUST restart the stream.

6.3.3. Mechanism Preferences

Any entity that will act as a SASL client or a SASL server MUST

maintain an ordered list of its preferred SASL mechanisms according

to the client or server, where the list is ordered according to local

policy or user configuration (which SHOULD be in order of perceived

strength to enable the strongest authentication possible). The

initiating entity MUST maintain its own preference order independent

of the preference order of the receiving entity. A client MUST try

SASL mechanisms in its preference order. For example, if the server

offers the ordered list "PLAIN SCRAM-SHA-1 GSSAPI" or "SCRAM-SHA-1

GSSAPI PLAIN" but the client's ordered list is "GSSAPI SCRAM-SHA-1",

the client MUST try GSSAPI first and then SCRAM-SHA-1 but MUST NOT

try PLAIN (since PLAIN is not on its list).

6.3.4. Mechanism Offers

If the receiving entity considers TLS negotiation (Section 5) to be

mandatory-to-negotiate before it will accept authentication with a

particular SASL mechanism, it MUST NOT advertise that mechanism in

its list of available SASL mechanisms before TLS negotiation has been

completed.

The receiving entity SHOULD offer the SASL EXTERNAL mechanism if both

of the following conditions hold:

During TLS negotiation the initiating entity presented a

   certificate that is acceptable to the receiving entity for

   purposes of strong identity verification in accordance with local

   service policies (e.g., because said certificate is unexpired, is

   unrevoked, and is anchored to a root trusted by the receiving

   entity).

The receiving entity expects that the initiating entity will be

   able to authenticate and authorize as the identity provided in

   the certificate; in the case of a server-to-server stream, the

   receiving entity might have such an expectation because a DNS

   domain name presented in the initiating entity's certificate

   matches the domain referenced in the 'from' attribute of the

   initial stream header, where the matching rules of [TLS-CERTS]

   apply; in the case of a client-to-server stream, the receiving

   entity might have such an expectation because the bare JID

   presented in the initiating entity's certificate matches a user

   account that is registered with the server or because other

Saint-Andre Standards Track [Page 78]

RFC 6120 XMPP Core March 2011

   information contained in the initiating entity's certificate

   matches that of an entity that has permission to use the server

   for access to an XMPP network.

However, the receiving entity MAY offer the SASL EXTERNAL mechanism

under other circumstances, as well.

When the receiving entity offers the SASL EXTERNAL mechanism, the

receiving entity SHOULD list the EXTERNAL mechanism first among its

offered SASL mechanisms and the initiating entity SHOULD attempt SASL

negotiation using the EXTERNAL mechanism first (this preference will

tend to increase the likelihood that the parties can negotiate mutual

certificate authentication).

Section 13.8 specifies SASL mechanisms that MUST be supported;

naturally, other SASL mechanisms MAY be supported as well.

  Informational Note: Best practices for the use of SASL in the

  context of XMPP are described in [XEP-0175] for the ANONYMOUS

  mechanism and in [XEP-0178] for the EXTERNAL mechanism.

6.3.5. Data Formatting

The following data formatting rules apply to the SASL negotiation:

During SASL negotiation, the entities MUST NOT send any

   whitespace as separators between XML elements (i.e., from the

   last character of the first-level <auth/> element qualified by

   the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the

   initiating entity, until the last character of the first-level

   <success/> element qualified by the

   'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the

   receiving entity).  This prohibition helps to ensure proper

   security layer byte precision.  Any such whitespace shown in the

   SASL examples provided in this document is included only for the

   sake of readability.

Any XML character data contained within the XML elements MUST be

   encoded using base 64, where the encoding adheres to the

   definition in Section 4 of [BASE64] and where the padding bits

   are set to zero.

As formally specified in the XML schema for the

   'urn:ietf:params:xml:ns:xmpp-sasl' namespace under Appendix A.4,

   the receiving entity MAY include one or more application-specific

   child elements inside the <mechanisms/> element to provide

   information that might be needed by the initiating entity in

   order to complete successful SASL negotiation using one or more

Saint-Andre Standards Track [Page 79]

RFC 6120 XMPP Core March 2011

   of the offered mechanisms; however, the syntax and semantics of

   all such elements are out of scope for this specification (see

   [XEP-0233] for one example).

6.3.6. Security Layers

Upon successful SASL negotiation that involves negotiation of a

security layer, both the initiating entity and the receiving entity

MUST discard any application-layer state (i.e, state from the XMPP

layer, excluding state from the TLS negotiation or SASL negotiation).

6.3.7. Simple User Name

Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify

that the authentication identity used in the context of such

mechanisms is a "simple user name" (see Section 2 of [SASL] as well

as [SASLPREP]). The exact form of the simple user name in any

particular mechanism or deployment thereof is a local matter, and a

simple user name does not necessarily map to an application

identifier such as a JID or JID component (e.g., a localpart).

However, in the absence of local information provided by the server,

an XMPP client SHOULD assume that the authentication identity for

such a SASL mechanism is a simple user name equal to the localpart of

the user's JID.

6.3.8. Authorization Identity

An authorization identity is an OPTIONAL identity included by the

initiating entity to specify an identity to act as (see Section 2 of

[SASL]). In client-to-server streams, it would most likely be used

by an administrator to perform some management task on behalf of

another user, whereas in server-to-server streams it would most

likely be used to specify a particular add-on service at an XMPP

service (e.g., a multi-user chat server at conference.example.com

that is hosted by the example.com XMPP service). If the initiating

entity wishes to act on behalf of another entity and the selected

SASL mechanism supports transmission of an authorization identity,

the initiating entity MUST provide an authorization identity during

SASL negotiation. If the initiating entity does not wish to act on

behalf of another entity, it MUST NOT provide an authorization

identity.

In the case of client-to-server communication, the value of an

authorization identity MUST be a bare JID (localpart@domainpart)

rather than a full JID (<localpart@domainpart/resourcepart>).

In the case of server-to-server communication, the value of an

authorization identity MUST be a domainpart only ().

Saint-Andre Standards Track [Page 80]

RFC 6120 XMPP Core March 2011

If the initiating entity provides an authorization identity during

SASL negotiation, the receiving entity is responsible for verifying

that the initiating entity is in fact allowed to assume the specified

authorization identity; if not, the receiving entity MUST return an

SASL error as described under Section 6.5.6.

6.3.9. Realms

The receiving entity MAY include a realm when negotiating certain

SASL mechanisms (e.g., both the GSSAPI and DIGEST-MD5 mechanisms

allow the authentication exchange to include a realm, though in

different ways, whereas the EXTERNAL, SCRAM, and PLAIN mechanisms do

not). If the receiving entity does not communicate a realm, the

initiating entity MUST NOT assume that any realm exists. The realm

MUST be used only for the purpose of authentication; in particular,

an initiating entity MUST NOT attempt to derive an XMPP domainpart

from the realm information provided by the receiving entity.

6.3.10. Round Trips

[SASL] specifies that a using protocol such as XMPP can define two

methods by which the protocol can save round trips where allowed for

the SASL mechanism:

When the SASL client (the XMPP "initiating entity") requests an

   authentication exchange, it can include "initial response" data

   with its request if appropriate for the SASL mechanism in use.

   In XMPP, this is done by including the initial response as the

   XML character data of the <auth/> element.

At the end of the authentication exchange, the SASL server (the

   XMPP "receiving entity") can include "additional data with

   success" if appropriate for the SASL mechanism in use.  In XMPP,

   this is done by including the additional data as the XML

   character data of the <success/> element.

For the sake of protocol efficiency, it is REQUIRED for clients and

servers to support these methods and RECOMMENDED to use them;

however, clients and servers MUST support the less efficient modes as

well.

Saint-Andre Standards Track [Page 81]

RFC 6120 XMPP Core March 2011

6.4. Process

The process for SASL negotiation is as follows.

6.4.1. Exchange of Stream Headers and Stream Features

If SASL negotiation follows successful STARTTLS negotiation

(Section 5), then the SASL negotiation occurs over the protected

stream that has already been negotiated. If not, the initiating

entity resolves the FQDN of the receiving entity as specified under

Section 3, opens a TCP connection to the advertised port at the

resolved IP address, and sends an initial stream header to the

receiving entity. In either case, the receiving entity will receive

an initial stream from the initiating entity.

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

When the receiving entity processes an initial stream header from the

initiating entity, it MUST send a response stream header to the

initiating entity (for which it MUST generate a unique stream ID. If

TLS negotiation has already succeeded, then this stream ID MUST be

different from the stream ID sent before TLS negotiation succeeded).

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

The receiving entity also MUST send stream features to the initiating

entity. The stream features SHOULD include an advertisement for

support of SASL negotiation, i.e., a element qualified

by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. Typically there

are only three cases in which support for SASL negotiation would not

be advertised here:

Saint-Andre Standards Track [Page 82]

RFC 6120 XMPP Core March 2011

o TLS negotiation needs to happen before SASL can be offered (i.e.,

  TLS is required and the receiving entity is responding to the very

  first initial stream header it has received for this connection

  attempt).

o SASL negotiation is impossible for a server-to-server connection

  (i.e., the initiating server has not provided a certificate that

  would enable strong authentication and therefore the receiving

  server is falling back to weak identity verification using the

  Server Dialback protocol [XEP-0220]).

o SASL has already been negotiated (i.e., the receiving entity is

  responding to an initial stream header sent as a stream restart

  after successful SASL negotiation).

The element MUST contain one child element

for each authentication mechanism the receiving entity offers to the

initiating entity. As noted, the order of elements in

the XML indicates the preference order of the SASL mechanisms

according to the receiving entity (which is not necessarily the

preference order according to the initiating entity).

    <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

      <mechanism>EXTERNAL</mechanism>

      <mechanism>SCRAM-SHA-1-PLUS</mechanism>

      <mechanism>SCRAM-SHA-1</mechanism>

      <mechanism>PLAIN</mechanism>

    </mechanisms>

  </stream:features>

6.4.2. Initiation

In order to begin the SASL negotiation, the initiating entity sends

an element qualified by the

'urn:ietf:params:xml:ns:xmpp-sasl' namespace and includes an

appropriate value for the 'mechanism' attribute, thus starting the

handshake for that particular authentication mechanism. This element

MAY contain XML character data (in SASL terminology, the "initial

response") if the mechanism supports or requires it. If the

initiating entity needs to send a zero-length initial response, it

MUST transmit the response as a single equals sign character ("="),

which indicates that the response is present but contains no data.

I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

        mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>

Saint-Andre Standards Track [Page 83]

RFC 6120 XMPP Core March 2011

If the initiating entity subsequently sends another element

and the ongoing authentication handshake has not yet completed, the

receiving entity MUST discard the ongoing handshake and MUST process

a new handshake for the subsequently requested SASL mechanism.

6.4.3. Challenge-Response Sequence

If necessary, the receiving entity challenges the initiating entity

by sending a element qualified by the

'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY

contain XML character data (which MUST be generated in accordance

with the definition of the SASL mechanism chosen by the initiating

entity).

The initiating entity responds to the challenge by sending a

element qualified by the

'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY

contain XML character data (which MUST be generated in accordance

with the definition of the SASL mechanism chosen by the initiating

entity).

If necessary, the receiving entity sends more challenges and the

initiating entity sends more responses.

This series of challenge/response pairs continues until one of three

things happens:

o The initiating entity aborts the handshake for this authentication

  mechanism.

o The receiving entity reports failure of the handshake.

o The receiving entity reports success of the handshake.

These scenarios are described in the following sections.

6.4.4. Abort

The initiating entity aborts the handshake for this authentication

mechanism by sending an element qualified by the

'urn:ietf:params:xml:ns:xmpp-sasl' namespace.

Upon receiving an element, the receiving entity MUST return

a element qualified by the

'urn:ietf:params:xml:ns:xmpp-sasl' namespace and containing an

child element.

Saint-Andre Standards Track [Page 84]

RFC 6120 XMPP Core March 2011

    <aborted/>

  </failure>

6.4.5. SASL Failure

The receiving entity reports failure of the handshake for this

authentication mechanism by sending a element qualified by

the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace (the particular

cause of failure MUST be communicated in an appropriate child element

of the element as defined under Section 6.5).

    <not-authorized/>

  </failure>

Where appropriate for the chosen SASL mechanism, the receiving entity

SHOULD allow a configurable but reasonable number of retries (at

least 2 and no more than 5); this enables the initiating entity

(e.g., an end-user client) to tolerate incorrectly provided

credentials (e.g., a mistyped password) without being forced to

reconnect (which it would if the receiving entity immediately

returned a SASL failure and closed the stream).

If the initiating entity attempts a reasonable number of retries with

the same SASL mechanism and all attempts fail, it MAY fall back to

the next mechanism in its ordered list by sending a new

request to the receiving entity, thus starting a new handshake for

that authentication mechanism. If all handshakes fail and there are

no remaining mechanisms in the initiating entity's list of supported

and acceptable mechanisms, the initiating entity SHOULD simply close

the stream as described under Section 4.4 (instead of waiting for the

stream to time out).

If the initiating entity exceeds the number of retries, the receiving

entity MUST close the stream with a stream error, which SHOULD be

(Section 4.9.3.14), although some existing

implementations send (Section 4.9.3.12) instead.

  Implementation Note: For server-to-server streams, if the

  receiving entity cannot offer the SASL EXTERNAL mechanism or any

  other SASL mechanism based on the security context established

  during TLS negotiation, the receiving entity MAY attempt to

  complete weak identity verification using the Server Dialback

  protocol [XEP-0220]; however, if according to local service

  policies weak identity verification is insufficient then the

Saint-Andre Standards Track [Page 85]

RFC 6120 XMPP Core March 2011

  receiving entity SHOULD instead close the stream with a <policy-

  violation/> stream error (Section 4.9.3.14) instead of waiting for

  the stream to time out.

6.4.6. SASL Success

Before considering the SASL handshake to be a success, if the

initiating entity provided a 'from' attribute on an initial stream

header whose confidentiality and integrity were protected via TLS or

an equivalent security layer (such as the SASL GSSAPI mechanism) then

the receiving entity SHOULD correlate the authentication identity

resulting from the SASL negotiation with that 'from' address; if the

two identities do not match then the receiving entity SHOULD

terminate the connection attempt (however, the receiving entity might

have legitimate reasons not to terminate the connection attempt, for

example, because it has overridden a connecting client's address to

correct the JID format or assign a JID based on information presented

in an end-user certificate).

The receiving entity reports success of the handshake by sending a

element qualified by the

'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY

contain XML character data (in SASL terminology, "additional data

with success") if the chosen SASL mechanism supports or requires it.

If the receiving entity needs to send additional data of zero length,

it MUST transmit the data as a single equals sign character ("=").

  Informational Note: For client-to-server streams, the

  authorization identity communicated during SASL negotiation is

  used to determine the canonical address for the initiating client

  according to the receiving server, as described under

  Section 4.3.6.

Upon receiving the element, the initiating entity MUST

initiate a new stream over the existing TCP connection by sending a

new initial stream header to the receiving entity (as specified under

Section 4.3.3, the initiating entity MUST NOT send a closing

tag before sending the new initial stream header, since the

receiving entity and initiating entity MUST consider the original

stream to be replaced upon success of the SASL negotiation).

Saint-Andre Standards Track [Page 86]

RFC 6120 XMPP Core March 2011

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

Upon receiving the new initial stream header from the initiating

entity, the receiving entity MUST respond by sending a new response

stream header to the initiating entity (for which it MUST generate a

new stream ID instead of reusing the old stream ID).

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

The receiving entity MUST also send stream features, containing any

further available features or containing no features (via an empty

element).

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

  </stream:features>

6.5. SASL Errors

The syntax of SASL errors is as follows, where the XML data shown

within the square brackets '[' and ']' is OPTIONAL.

 <defined-condition/>

 [<text xml:lang='langcode'>

     OPTIONAL descriptive text

 </text>]

The "defined-condition" MUST be one of the SASL-related error

conditions defined in the following sections. However, because

additional error conditions might be defined in the future, if an

entity receives a SASL error condition that it does not understand

then it MUST treat the unknown condition as a generic authentication

failure, i.e., as equivalent to (Section 6.5.10).

Saint-Andre Standards Track [Page 87]

RFC 6120 XMPP Core March 2011

Inclusion of the element is OPTIONAL, and can be used to

provide application-specific information about the error condition,

which information MAY be displayed to a human but only as a

supplement to the defined condition.

Because XMPP itself defines an application profile of SASL and there

is no expectation that more specialized XMPP applications will be

built on top of SASL, the SASL error format does not provide

extensibility for application-specific error conditions as is done

for XML streams (Section 4.9.4) and XML stanzas (Section 8.3.4).

6.5.1. aborted

The receiving entity acknowledges that the authentication handshake

has been aborted by the initiating entity; sent in reply to the

element.

    <aborted/>

  </failure>

6.5.2. account-disabled

The account of the initiating entity has been temporarily disabled;

sent in reply to an element (with or without initial response

data) or a element.

I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

        mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>

    <account-disabled/>

    <text xml:lang='en'>Call 212-555-1212 for assistance.</text>

  </failure>

6.5.3. credentials-expired

The authentication failed because the initiating entity provided

credentials that have expired; sent in reply to a element

or an element with initial response data.

    [ ... ]

  </response>

Saint-Andre Standards Track [Page 88]

RFC 6120 XMPP Core March 2011

    <credentials-expired/>

  </failure>

6.5.4. encryption-required

The mechanism requested by the initiating entity cannot be used

unless the confidentiality and integrity of the underlying stream are

protected (typically via TLS); sent in reply to an element

(with or without initial response data).

I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

        mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>

    <encryption-required/>

  </failure>

6.5.5. incorrect-encoding

The data provided by the initiating entity could not be processed

because the base 64 encoding is incorrect (e.g., because the encoding

does not adhere to the definition in Section 4 of [BASE64]); sent in

reply to a element or an element with initial

response data.

I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

        mechanism='DIGEST-MD5'>[ ... ]</auth>

    <incorrect-encoding/>

  </failure>

6.5.6. invalid-authzid

The authzid provided by the initiating entity is invalid, either

because it is incorrectly formatted or because the initiating entity

does not have permissions to authorize that ID; sent in reply to a

element or an element with initial response data.

    [ ... ]

  </response>

    <invalid-authzid/>

  </failure>

Saint-Andre Standards Track [Page 89]

RFC 6120 XMPP Core March 2011

6.5.7. invalid-mechanism

The initiating entity did not specify a mechanism, or requested a

mechanism that is not supported by the receiving entity; sent in

reply to an element.

I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

        mechanism='CRAM-MD5'/>

    <invalid-mechanism/>

  </failure>

6.5.8. malformed-request

The request is malformed (e.g., the element includes initial

response data but the mechanism does not allow that, or the data sent

violates the syntax for the specified SASL mechanism); sent in reply

to an , , , or element.

(In the following example, the XML character data of the

element contains more than 255 UTF-8-encoded Unicode characters and

therefore violates the "token" production for the SASL ANONYMOUS

mechanism as specified in [ANONYMOUS].)

I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

        mechanism='ANONYMOUS'>[ ... some-long-token ... ]</auth>

    <malformed-request/>

  </failure>

6.5.9. mechanism-too-weak

The mechanism requested by the initiating entity is weaker than

server policy permits for that initiating entity; sent in reply to an

element (with or without initial response data).

I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

        mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>

    <mechanism-too-weak/>

  </failure>

Saint-Andre Standards Track [Page 90]

RFC 6120 XMPP Core March 2011

6.5.10. not-authorized

The authentication failed because the initiating entity did not

provide proper credentials, or because some generic authentication

failure has occurred but the receiving entity does not wish to

disclose specific information about the cause of the failure; sent in

reply to a element or an element with initial

response data.

    [ ... ]

  </response>

    <not-authorized/>

  </failure>

  Security Warning: This error condition includes but is not limited

  to the case of incorrect credentials or a nonexistent username.

  In order to discourage directory harvest attacks, no

  differentiation is made between incorrect credentials and a

  nonexistent username.

6.5.11. temporary-auth-failure

The authentication failed because of a temporary error condition

within the receiving entity, and it is advisable for the initiating

entity to try again later; sent in reply to an element or a

element.

    [ ... ]

  </response>

    <temporary-auth-failure/>

  </failure>

6.6. SASL Definition

The profiling requirements of [SASL] require that the following

information be supplied by the definition of a using protocol.

service name: "xmpp"

initiation sequence: After the initiating entity provides an opening

  XML stream header and the receiving entity replies in kind, the

  receiving entity provides a list of acceptable authentication

Saint-Andre Standards Track [Page 91]

RFC 6120 XMPP Core March 2011

  methods.  The initiating entity chooses one method from the list

  and sends it to the receiving entity as the value of the

  'mechanism' attribute possessed by an <auth/> element, optionally

  including an initial response to avoid a round trip.

exchange sequence: Challenges and responses are carried through the

  exchange of <challenge/> elements from receiving entity to

  initiating entity and <response/> elements from initiating entity

  to receiving entity.  The receiving entity reports failure by

  sending a <failure/> element and success by sending a <success/>

  element; the initiating entity aborts the exchange by sending an

  <abort/> element.  Upon successful negotiation, both sides

  consider the original XML stream to be closed and new stream

  headers are sent by both entities.

security layer negotiation: The security layer takes effect

  immediately after sending the closing '>' character of the

  <success/> element for the receiving entity, and immediately after

  receiving the closing '>' character of the <success/> element for

  the initiating entity.  The order of layers is first [TCP], then

  [TLS], then [SASL], then XMPP.

use of the authorization identity: The authorization identity can be

  used in XMPP to denote the non-default <localpart@domainpart> of a

  client; an empty string is equivalent to an absent authorization

  identity.

Resource Binding

7.1. Fundamentals

After a client authenticates with a server, it MUST bind a specific

resource to the stream so that the server can properly address the

client. That is, there MUST be an XMPP resource associated with the

bare JID (localpart@domainpart) of the client, so that the address

for use over that stream is a full JID of the form

<localpart@domainpart/resource> (including the resourcepart). This

ensures that the server can deliver XML stanzas to and receive XML

stanzas from the client in relation to entities other than the server

itself or the client's account, as explained under Section 10.

  Informational Note: The client could exchange stanzas with the

  server itself or the client's account before binding a resource

  since the full JID is needed only for addressing outside the

  context of the stream negotiated between the client and the

  server, but this is not commonly done.

Saint-Andre Standards Track [Page 92]

RFC 6120 XMPP Core March 2011

After a client has bound a resource to the stream, it is referred to

as a "connected resource". A server SHOULD allow an entity to

maintain multiple connected resources simultaneously, where each

connected resource is associated with a distinct XML stream and is

differentiated from the other connected resources by a distinct

resourcepart.

  Security Warning: A server SHOULD enable the administrator of an

  XMPP service to limit the number of connected resources in order

  to prevent certain denial-of-service attacks as described under

  Section 13.12.

If, before completing the resource binding step, the client attempts

to send an XML stanza to an entity other than the server itself or

the client's account, the server MUST NOT process the stanza and MUST

close the stream with a stream error

(Section 4.9.3.12).

The XML namespace name for the resource binding extension is

'urn:ietf:params:xml:ns:xmpp-bind'.

7.2. Support

Support for resource binding is REQUIRED in XMPP client and server

implementations.

7.3. Stream Negotiation Rules

7.3.1. Mandatory-to-Negotiate

The parties to a stream MUST consider resource binding as mandatory-

to-negotiate.

7.3.2. Restart

After resource binding, the parties MUST NOT restart the stream.

7.4. Advertising Support

Upon sending a new response stream header to the client after

successful SASL negotiation, the server MUST include a

element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace

in the stream features it presents to the client.

The server MUST NOT include the resource binding stream feature until

after the client has authenticated, typically by means of successful

SASL negotiation.

Saint-Andre Standards Track [Page 93]

RFC 6120 XMPP Core March 2011

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

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

  </stream:features>

Upon being informed that resource binding is mandatory-to-negotiate,

the client MUST bind a resource to the stream as described in the

following sections.

7.5. Generation of Resource Identifiers

A resourcepart MUST at a minimum be unique among the connected

resources for that localpart@domainpart. Enforcement of this

policy is the responsibility of the server.

  Security Warning: A resourcepart can be security-critical.  For

  example, if a malicious entity can guess a client's resourcepart

  then it might be able to determine if the client (and therefore

  the controlling principal) is online or offline, thus resulting in

  a presence leak as described under Section 13.10.2.  To prevent

  that possibility, a client can either (1) generate a random

  resourcepart on its own or (2) ask the server to generate a

  resourcepart on its behalf.  One method for ensuring that the

  resourcepart is random is to generate a Universally Unique

  Identifier (UUID) as specified in [UUID].

7.6. Server-Generated Resource Identifier

A server MUST be able to generate an XMPP resourcepart on behalf of a

client. The resourcepart generated by the server MUST be random (see

[RANDOM]).

7.6.1. Success Case

A client requests a server-generated resourcepart by sending an IQ

stanza of type "set" (see Section 8.2.3) containing an empty

element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind'

namespace.

Saint-Andre Standards Track [Page 94]

RFC 6120 XMPP Core March 2011

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

  </iq>

Once the server has generated an XMPP resourcepart for the client, it

MUST return an IQ stanza of type "result" to the client, which MUST

include a child element that specifies the full JID for the

connected resource as determined by the server.

   <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

     <jid>

       juliet@im.example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb

     </jid>

   </bind>

  </iq>

7.6.2. Error Cases

When a client asks the server to generate a resourcepart during

resource binding, the following stanza error conditions are defined:

o The account has reached a limit on the number of simultaneous

  connected resources allowed.

o The client is otherwise not allowed to bind a resource to the

  stream.

Naturally, it is possible that error conditions not specified here

might occur, as described under Section 8.3.

7.6.2.1. Resource Constraint

If the account has reached a limit on the number of simultaneous

connected resources allowed, the server MUST return a <resource-

constraint/> stanza error (Section 8.3.3.18).

    <error type='wait'>

      <resource-constraint

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </iq>

Saint-Andre Standards Track [Page 95]

RFC 6120 XMPP Core March 2011

7.6.2.2. Not Allowed

If the client is otherwise not allowed to bind a resource to the

stream, the server MUST return a stanza error

(Section 8.3.3.10).

    <error type='cancel'>

      <not-allowed

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </iq>

7.7. Client-Submitted Resource Identifier

Instead of asking the server to generate a resourcepart on its

behalf, a client MAY attempt to submit a resourcepart that it has

generated or that the controlling user has provided.

7.7.1. Success Case

A client asks its server to accept a client-submitted resourcepart by

sending an IQ stanza of type "set" containing a element with

a child element containing non-zero-length XML character

data.

    <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

      <resource>balcony</resource>

    </bind>

  </iq>

The server SHOULD accept the client-submitted resourcepart. It does

so by returning an IQ stanza of type "result" to the client,

including a child element that specifies the full JID for the

connected resource and contains without modification the client-

submitted text.

   <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

     <jid>juliet@im.example.com/balcony</jid>

   </bind>

  </iq>

Alternatively, in accordance with local service policies the server

MAY refuse the client-submitted resourcepart and override it with a

resourcepart that the server generates.

Saint-Andre Standards Track [Page 96]

RFC 6120 XMPP Core March 2011

   <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

     <jid>

  juliet@im.example.com/balcony 4db06f06-1ea4-11dc-aca3-000bcd821bfb

     </jid>

   </bind>

  </iq>

7.7.2. Error Cases

When a client attempts to submit its own XMPP resourcepart during

resource binding, the following stanza error conditions are defined

in addition to those described under Section 7.6.2:

o The provided resourcepart cannot be processed by the server.

o The provided resourcepart is already in use.

Naturally, it is possible that error conditions not specified here

might occur, as described under Section 8.3.

7.7.2.1. Bad Request

If the provided resourcepart cannot be processed by the server (e.g.,

because it is of zero length or because it otherwise violates the

rules for resourceparts specified in [XMPP-ADDR]), the server can

return a stanza error (Section 8.3.3.1) but SHOULD

instead process the resourcepart so that it is in conformance.

    <error type='modify'>

      <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </iq>

7.7.2.2. Conflict

If there is a currently connected client whose session has the

resourcepart being requested by the newly connecting client, the

server MUST do one of the following (which of these the server does

is a matter for implementation or local service policy, although

suggestions are provided below).

Override the resourcepart provided by the newly connecting client

   with a server-generated resourcepart.  This behavior is

   encouraged, because it simplifies the resource binding process

   for client implementations.

Saint-Andre Standards Track [Page 97]

RFC 6120 XMPP Core March 2011

Disallow the resource binding attempt of the newly connecting

   client and maintain the session of the currently connected

   client.  This behavior is neither encouraged nor discouraged,

   despite the fact that it was implicitly encouraged in RFC 3920;

   however, note that handling of the <conflict/> error is unevenly

   supported among existing client implementations, which often

   treat it as an authentication error and have been observed to

   discard cached credentials when receiving it.

Terminate the session of the currently connected client and allow

   the resource binding attempt of the newly connecting client.

   Although this was the traditional behavior of early XMPP server

   implementations, it is now discouraged because it can lead to a

   never-ending cycle of two clients effectively disconnecting each

   other; however, note that this behavior can be appropriate in

   some deployment scenarios or if the server knows that the

   currently connected client has a dead connection or broken stream

   as described under Section 4.6.

If the server follows behavior #1, it returns an stanza of type

"result" to the newly connecting client, where the child of

the element contains XML character data that indicates the

full JID of the client, including the resourcepart that was generated

by the server.

   <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

     <jid>

  juliet@im.example.com/balcony 4db06f06-1ea4-11dc-aca3-000bcd821bfb

     </jid>

   </bind>

  </iq>

If the server follows behavior #2, it sends a stanza

error (Section 8.3.3.2) in response to the resource binding attempt

of the newly connecting client but maintains the XML stream so that

the newly connecting client has an opportunity to negotiate a non-

conflicting resourcepart (i.e., the newly connecting client needs to

choose a different resourcepart before making another attempt to bind

a resource).

    <error type='modify'>

      <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </iq>

Saint-Andre Standards Track [Page 98]

RFC 6120 XMPP Core March 2011

If the server follows behavior #3, it returns a stream

error (Section 4.9.3.3) to the currently connected client (as

described under Section 4.9.3.3) and returns an IQ stanza of type

"result" (indicating success) in response to the resource binding

attempt of the newly connecting client.

    <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

      <jid>

        juliet@im.example.com/balcony

      </jid>

    </bind>

  </iq>

7.7.3. Retries

If an error occurs when a client submits a resourcepart, the server

SHOULD allow a configurable but reasonable number of retries (at

least 5 and no more than 10); this enables the client to tolerate

incorrectly provided resourceparts (e.g., bad data formats or

duplicate text strings) without being forced to reconnect.

After the client has reached the retry limit, the server MUST close

the stream with a stream error

(Section 4.9.3.14).

XML Stanzas

After a client and a server (or two servers) have completed stream

negotiation, either party can send XML stanzas. Three kinds of XML

stanza are defined for the 'jabber:client' and 'jabber:server'

namespaces: , , and . In addition, there

are five common attributes for these stanza types. These common

attributes, as well as the basic semantics of the three stanza types,

are defined in this specification; more detailed information

regarding the syntax of XML stanzas for instant messaging and

presence applications is provided in [XMPP-IM], and for other

applications in the relevant XMPP extension specifications.

Support for the XML stanza syntax and semantics defined in this

specification is REQUIRED in XMPP client and server implementations.

  Security Warning: A server MUST NOT process a partial stanza and

  MUST NOT attach meaning to the transmission timing of any part of

  a stanza (before receipt of the closing tag).

Saint-Andre Standards Track [Page 99]

RFC 6120 XMPP Core March 2011

8.1. Common Attributes

The following five attributes are common to message, presence, and IQ

stanzas.

8.1.1. to

The 'to' attribute specifies the JID of the intended recipient for

the stanza.

 <body>Art thou not Romeo, and a Montague?</body>

For information about server processing of inbound and outbound XML

stanzas based on the 'to' address, refer to Section 10.

8.1.1.1. Client-to-Server Streams

The following rules apply to inclusion of the 'to' attribute in

stanzas sent from a connected client to its server over an XML stream

qualified by the 'jabber:client' namespace.

A stanza with a specific intended recipient (e.g., a conversation

   partner, a remote service, the server itself, even another

   resource associated with the user's bare JID) MUST possess a 'to'

   attribute whose value is an XMPP address.

A stanza sent from a client to a server for direct processing by

   the server (e.g., roster processing as described in [XMPP-IM] or

   presence sent to the server for broadcasting to other entities)

   MUST NOT possess a 'to' attribute.

The following rules apply to inclusion of the 'to' attribute in

stanzas sent from a server to a connected client over an XML stream

qualified by the 'jabber:client' namespace.

If the server has received the stanza from another connected

   client or from a peer server, the server MUST NOT modify the 'to'

   address before delivering the stanza to the client.

If the server has itself generated the stanza (e.g., a response

   to an IQ stanza of type "get" or "set", even if the stanza did

   not include a 'to' address), the stanza MAY include a 'to'

   address, which MUST be the full JID of the client; however, if

   the stanza does not include a 'to' address then the client MUST

   treat it as if the 'to' address were included with a value of the

   client's full JID.

Saint-Andre Standards Track [Page 100]

RFC 6120 XMPP Core March 2011

  Implementation Note: It is the server's responsibility to deliver

  only stanzas that are addressed to the client's full JID or the

  user's bare JID; thus, there is no need for the client to check

  the 'to' address of incoming stanzas.  However, if the client does

  check the 'to' address then it is suggested to check at most the

  bare JID portion (not the full JID), since the 'to' address might

  be the user's bare JID, the client's current full JID, or even a

  full JID with a different resourcepart (e.g., in the case of so-

  called "offline messages" as described in [XEP-0160]).

8.1.1.2. Server-to-Server Streams

The following rules apply to inclusion of the 'to' attribute in the

context of XML streams qualified by the 'jabber:server' namespace

(i.e., server-to-server streams).

A stanza MUST possess a 'to' attribute whose value is an XMPP

   address; if a server receives a stanza that does not meet this

   restriction, it MUST close the stream with an <improper-

   addressing/> stream error (Section 4.9.3.7).

The domainpart of the JID contained in the stanza's 'to'

   attribute MUST match the FQDN of the receiving server (or any

   validated domain thereof) as communicated via SASL negotiation

   (see Section 6), Server Dialback (see [XEP-0220]), or similar

   means; if a server receives a stanza that does not meet this

   restriction, it MUST close the stream with a <host-unknown/>

   stream error (Section 4.9.3.6) or a <host-gone/> stream error

   (Section 4.9.3.5).

8.1.2. from

The 'from' attribute specifies the JID of the sender.

<message from='juliet@im.example.com/balcony'

        to='romeo@example.net'>

 <body>Art thou not Romeo, and a Montague?</body>

8.1.2.1. Client-to-Server Streams

The following rules apply to the 'from' attribute in the context of

XML streams qualified by the 'jabber:client' namespace (i.e., client-

to-server streams).

When a server receives an XML stanza from a connected client, the

   server MUST add a 'from' attribute to the stanza or override the

   'from' attribute specified by the client, where the value of the

Saint-Andre Standards Track [Page 101]

RFC 6120 XMPP Core March 2011

   'from' attribute MUST be the full JID

   (<localpart@domainpart/resource>) determined by the server for

   the connected resource that generated the stanza (see

   Section 4.3.6), or the bare JID (<localpart@domainpart>) in the

   case of subscription-related presence stanzas (see [XMPP-IM]).

When the server generates a stanza on its own behalf for delivery

   to the client from the server itself, the stanza MUST include a

   'from' attribute whose value is the bare JID (i.e., <domainpart>)

   of the server as agreed upon during stream negotiation (e.g.,

   based on the 'to' attribute of the initial stream header).

When the server generates a stanza from the server for delivery

   to the client on behalf of the account of the connected client

   (e.g., in the context of data storage services provided by the

   server on behalf of the client), the stanza MUST either (a) not

   include a 'from' attribute or (b) include a 'from' attribute

   whose value is the account's bare JID (<localpart@domainpart>).

A server MUST NOT send to the client a stanza without a 'from'

   attribute if the stanza was not generated by the server on its

   own behalf (e.g., if it was generated by another client or a peer

   server and the server is merely delivering it to the client on

   behalf of some other entity); therefore, when a client receives a

   stanza that does not include a 'from' attribute, it MUST assume

   that the stanza is from the user's account on the server.

8.1.2.2. Server-to-Server Streams

The following rules apply to the 'from' attribute in the context of

XML streams qualified by the 'jabber:server' namespace (i.e., server-

to-server streams).

A stanza MUST possess a 'from' attribute whose value is an XMPP

   address; if a server receives a stanza that does not meet this

   restriction, it MUST close the stream with an <improper-

   addressing/> stream error (Section 4.9.3.7).

The domainpart of the JID contained in the stanza's 'from'

   attribute MUST match the FQDN of the sending server (or any

   validated domain thereof) as communicated via SASL negotiation

   (see Section 6), Server Dialback (see [XEP-0220]), or similar

   means; if a server receives a stanza that does not meet this

   restriction, it MUST close the stream with an <invalid-from/>

   stream error (Section 4.9.3.9).

Enforcement of these rules helps to prevent certain denial-of-service

attacks as described under Section 13.12.

Saint-Andre Standards Track [Page 102]

RFC 6120 XMPP Core March 2011

8.1.3. id

The 'id' attribute is used by the originating entity to track any

response or error stanza that it might receive in relation to the

generated stanza from another entity (such as an intermediate server

or the intended recipient).

It is up to the originating entity whether the value of the 'id'

attribute is unique only within its current stream or unique

globally.

For and stanzas, it is RECOMMENDED for the

originating entity to include an 'id' attribute; for stanzas,

it is REQUIRED.

If the generated stanza includes an 'id' attribute then it is

REQUIRED for the response or error stanza to also include an 'id'

attribute, where the value of the 'id' attribute MUST match that of

the generated stanza.

The semantics of IQ stanzas impose additional restrictions as

described under Section 8.2.3.

8.1.4. type

The 'type' attribute specifies the purpose or context of the message,

presence, or IQ stanza. The particular allowable values for the

'type' attribute vary depending on whether the stanza is a message,

presence, or IQ stanza. The defined values for message and presence

stanzas are specific to instant messaging and presence applications

and therefore are defined in [XMPP-IM], whereas the values for IQ

stanzas specify the part of the semantics for all structured request-

response exchanges (no matter what the payload) and therefore are

specified under Section 8.2.3. The only 'type' value common to all

three kinds of stanzas is "error" as described under Section 8.3.

8.1.5. xml:lang

A stanza SHOULD possess an 'xml:lang' attribute (as defined in

Section 2.12 of [XML]) if the stanza contains XML character data that

is intended to be presented to a human user (as explained in

[CHARSETS], "internationalization is for humans"). The value of the

'xml:lang' attribute specifies the default language of any such

human-readable XML character data.

Saint-Andre Standards Track [Page 103]

RFC 6120 XMPP Core March 2011

 <show>dnd</show>

 <status>Wooing Juliet</status>

The value of the 'xml:lang' attribute MAY be overridden by the 'xml:

lang' attribute of a specific child element.

 <show>dnd</show>

 <status>Wooing Juliet</status>

 <status xml:lang='cs'>Dvo&#x0159;&#x00ED;m se Julii</status>

If an outbound stanza generated by a client does not possess an 'xml:

lang' attribute, the client's server SHOULD add an 'xml:lang'

attribute whose value is that specified for the client's output

stream as defined under Section 4.7.4.

    <show>dnd</show>

    <status>Wooing Juliet</status>

  </presence>

S: <presence from='romeo@example.net/orchard'

            to='juliet@im.example.com'

            xml:lang='en'>

    <show>dnd</show>

    <status>Wooing Juliet</status>

  </presence>

If an inbound stanza received by a client or server does not possess

an 'xml:lang' attribute, an implementation MUST assume that the

default language is that specified for the entity's input stream as

defined under Section 4.7.4.

The value of the 'xml:lang' attribute MUST conform to the NMTOKEN

datatype (as defined in Section 2.3 of [XML]) and MUST conform to the

format defined in [LANGTAGS].

A server MUST NOT modify or delete 'xml:lang' attributes on stanzas

it receives from other entities.

Saint-Andre Standards Track [Page 104]

RFC 6120 XMPP Core March 2011

8.2. Basic Semantics

8.2.1. Message Semantics

The stanza is a "push" mechanism whereby one entity pushes

information to another entity, similar to the communications that

occur in a system such as email. All message stanzas will possess a

'to' attribute that specifies the intended recipient of the message

(see Section 8.1.1 and Section 10.3), unless the message is being

sent to the bare JID of a connected client's account. Upon receiving

a message stanza with a 'to' address, a server SHOULD attempt to

route or deliver it to the intended recipient (see Section 10 for

general routing and delivery rules related to XML stanzas).

8.2.2. Presence Semantics

The stanza is a specialized "broadcast" or "publish-

subscribe" mechanism, whereby multiple entities receive information

(in this case, network availability information) about an entity to

which they have subscribed. In general, a publishing client SHOULD

send a presence stanza with no 'to' attribute, in which case the

server to which the client is connected will broadcast that stanza to

all subscribed entities. However, a publishing client MAY also send

a presence stanza with a 'to' attribute, in which case the server

will route or deliver that stanza to the intended recipient.

Although the stanza is most often used by XMPP clients,

it can also be used by servers, add-on services, and any other kind

of XMPP entity. See Section 10 for general routing and delivery

rules related to XML stanzas, and [XMPP-IM] for rules specific to

presence applications.

8.2.3. IQ Semantics

Info/Query, or IQ, is a "request-response" mechanism, similar in some

ways to the Hypertext Transfer Protocol [HTTP]. The semantics of IQ

enable an entity to make a request of, and receive a response from,

another entity. The data content of the request and response is

defined by the schema or other structural definition associated with

the XML namespace that qualifies the direct child element of the IQ

element (see Section 8.4), and the interaction is tracked by the

requesting entity through use of the 'id' attribute. Thus, IQ

interactions follow a common pattern of structured data exchange such

as get/result or set/result (although an error can be returned in

reply to a request if appropriate):

Saint-Andre Standards Track [Page 105]

RFC 6120 XMPP Core March 2011

Requesting Responding

 Entity                      Entity

   |                            |

   | <iq id='1' type='get'>     |

   |   [ ... payload ... ]      |

   | </iq>                      |

   | -------------------------> |

   |                            |

   | <iq id='1' type='result'>  |

   |   [ ... payload ... ]      |

   | </iq>                      |

   | <------------------------- |

   |                            |

   | <iq id='2' type='set'>     |

   |   [ ... payload ... ]      |

   | </iq>                      |

   | -------------------------> |

   |                            |

   | <iq id='2' type='error'>   |

   |   [ ... condition ... ]    |

   | </iq>                      |

   | <------------------------- |

   |                            |

                 Figure 5: Semantics of IQ Stanzas

To enforce these semantics, the following rules apply:

The 'id' attribute is REQUIRED for IQ stanzas.

The 'type' attribute is REQUIRED for IQ stanzas. The value MUST

   be one of the following; if not, the recipient or an intermediate

   router MUST return a <bad-request/> stanza error

   (Section 8.3.3.1).

   *  get -- The stanza requests information, inquires about what

      data is needed in order to complete further operations, etc.

   *  set -- The stanza provides data that is needed for an

      operation to be completed, sets new values, replaces existing

      values, etc.

   *  result -- The stanza is a response to a successful get or set

      request.

Saint-Andre Standards Track [Page 106]

RFC 6120 XMPP Core March 2011

   *  error -- The stanza reports an error that has occurred

      regarding processing or delivery of a get or set request (see

      Section 8.3).

An entity that receives an IQ request of type "get" or "set" MUST

   reply with an IQ response of type "result" or "error".  The

   response MUST preserve the 'id' attribute of the request (or be

   empty if the generated stanza did not include an 'id' attribute).

An entity that receives a stanza of type "result" or "error" MUST

   NOT respond to the stanza by sending a further IQ response of

   type "result" or "error"; however, the requesting entity MAY send

   another request (e.g., an IQ of type "set" to provide obligatory

   information discovered through a get/result pair).

An IQ stanza of type "get" or "set" MUST contain exactly one

   child element, which specifies the semantics of the particular

   request.

An IQ stanza of type "result" MUST include zero or one child

   elements.

An IQ stanza of type "error" MAY include the child element

   contained in the associated "get" or "set" and MUST include an

   <error/> child; for details, see Section 8.3.

8.3. Stanza Errors

Stanza-related errors are handled in a manner similar to stream

errors (Section 4.9). Unlike stream errors, stanza errors are

recoverable; therefore, they do not result in termination of the XML

stream and underlying TCP connection. Instead, the entity that

discovers the error condition returns an error stanza, which is a

stanza that:

o is of the same kind (message, presence, or IQ) as the generated

  stanza that triggered the error

o has a 'type' attribute set to a value of "error"

o typically swaps the 'from' and 'to' addresses of the generated

  stanza

o mirrors the 'id' attribute (if any) of the generated stanza that

  triggered the error

Saint-Andre Standards Track [Page 107]

RFC 6120 XMPP Core March 2011

o contains an child element that specifies the error

  condition and therefore provides a hint regarding actions that the

  sender might be able to take in an effort to remedy the error

  (however, it is not always possible to remedy the error)

8.3.1. Rules

The following rules apply to stanza errors:

The receiving or processing entity that detects an error

   condition in relation to a stanza SHOULD return an error stanza

   (and MUST do so for IQ stanzas).

The error stanza SHOULD simply swap the 'from' and 'to' addresses

   from the generated stanza, unless doing so would (1) result in an

   information leak (see under Section 13.10) or other breach of

   security, or (2) force the sender of the error stanza to include

   a malformed JID in the 'from' or 'to' address of the error

   stanza.

If the generated stanza was or and

   included an 'id' attribute then it is REQUIRED for the error

   stanza to also include an 'id' attribute.  If the generated

   stanza was <iq/> then the error stanza MUST include an 'id'

   attribute.  In all cases, the value of the 'id' attribute MUST

   match that of the generated stanza (or be empty if the generated

   stanza did not include an 'id' attribute).

An error stanza MUST contain an child element.

The entity that returns an error stanza MAY pass along its JID to

   the sender of the generated stanza (e.g., for diagnostic or

   tracking purposes) through the addition of a 'by' attribute to

   the <error/> child element.

The entity that returns an error stanza MAY include the original

   XML sent so that the sender can inspect and, if necessary,

   correct the XML before attempting to resend (however, this is a

   courtesy only and the originating entity MUST NOT depend on

   receiving the original payload).  Naturally, the entity MUST NOT

   include the original data if it not well-formed XML, violates the

   XML restrictions of XMPP (see under Section 11.1), or is

   otherwise harmful (e.g., exceeds a size limit).

An child MUST NOT be included if the 'type' attribute

   has a value other than "error" (or if there is no 'type'

   attribute).

Saint-Andre Standards Track [Page 108]

RFC 6120 XMPP Core March 2011

An entity that receives an error stanza MUST NOT respond to the

   stanza with a further error stanza; this helps to prevent

   looping.

8.3.2. Syntax

The syntax for stanza-related errors is as follows, where XML data

shown within the square brackets '[' and ']' is OPTIONAL, 'intended-

recipient' is the JID of the entity to which the original stanza was

addressed, 'sender' is the JID of the originating entity, and 'error-

generator' is the entity that detects the fact that an error has

occurred and thus returns an error stanza.

 [OPTIONAL to include sender XML here]

 <error [by='error-generator']

        type='error-type'>

   <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

   [<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'

          xml:lang='langcode'>

     OPTIONAL descriptive text

   </text>]

   [OPTIONAL application-specific condition element]

 </error>

The "stanza-kind" MUST be one of message, presence, or iq.

The "error-type" MUST be one of the following:

o auth -- retry after providing credentials

o cancel -- do not retry (the error cannot be remedied)

o continue -- proceed (the condition was only a warning)

o modify -- retry after changing the data sent

o wait -- retry after waiting (the error is temporary)

The "defined-condition" MUST correspond to one of the stanza error

conditions defined under Section 8.3.3. However, because additional

error conditions might be defined in the future, if an entity

receives a stanza error condition that it does not understand then it

MUST treat the unknown condition as equivalent to <undefined-

condition/> (Section 8.3.3.21). If the designers of an XMPP protocol

extension or the developers of an XMPP implementation need to

communicate a stanza error condition that is not defined in this

Saint-Andre Standards Track [Page 109]

RFC 6120 XMPP Core March 2011

specification, they can do so by defining an application-specific

error condition element qualified by an application-specific

namespace.

The element:

o MUST contain a defined condition element.

o MAY contain a 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-stanzas' 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-

  specific namespace that defines the syntax and semantics of the

  element.

The element is OPTIONAL. If included, it is to 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

SHOULD NOT be used as the error message presented to a human user,

but MAY be shown in addition to the error message associated with the

defined condition element (and, optionally, the application-specific

condition element).

  Interoperability Note: The syntax defined in [RFC3920] included a

  legacy 'code' attribute, whose semantics have been replaced by the

  defined condition elements; information about mapping defined

  condition elements to values of the legacy 'code' attribute can be

  found in [XEP-0086].

8.3.3. Defined Conditions

The following conditions are defined for use in stanza errors.

The error-type value that is RECOMMENDED for each defined condition

is the usual expected type; however, in some circumstances a

different type might be more appropriate.

8.3.3.1. bad-request

The sender has sent a stanza containing XML that does not conform to

the appropriate schema or that cannot be processed (e.g., an IQ

stanza that includes an unrecognized value of the 'type' attribute,

Saint-Andre Standards Track [Page 110]

RFC 6120 XMPP Core March 2011

or an element that is qualified by a recognized namespace but that

violates the defined syntax for the element); the associated error

type SHOULD be "modify".

C: <iq from='juliet@im.example.com/balcony'

      id='zj3v142b'

      to='im.example.com'

      type='subscribe'>

    <ping xmlns='urn:xmpp:ping'/>

  </iq>

S: <iq from='im.example.com'

      id='zj3v142b'

      to='juliet@im.example.com/balcony'

      type='error'>

    <error type='modify'>

      <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </iq>

8.3.3.2. conflict

Access cannot be granted because an existing resource exists with the

same name or address; the associated error type SHOULD be "cancel".

    <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

      <resource>balcony</resource>

    </bind>

  </iq>

    <error type='cancel'>

      <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </iq>

8.3.3.3. feature-not-implemented

The feature represented in the XML stanza is not implemented by the

intended recipient or an intermediate server and therefore the stanza

cannot be processed (e.g., the entity understands the namespace but

does not recognize the element name); the associated error type

SHOULD be "cancel" or "modify".

Saint-Andre Standards Track [Page 111]

RFC 6120 XMPP Core March 2011

C: <iq from='juliet@im.example.com/balcony'

      id='9u2bax16'

      to='pubsub.example.com'

      type='get'>

    <pubsub xmlns='http://jabber.org/protocol/pubsub'>

      <subscriptions/>

    </pubsub>

  </iq>

E: <iq from='pubsub.example.com'

      id='9u2bax16'

      to='juliet@im.example.com/balcony'

      type='error'>

    <error type='cancel'>

      <feature-not-implemented

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

      <unsupported

          xmlns='http://jabber.org/protocol/pubsub#errors'

          feature='retrieve-subscriptions'/>

    </error>

  </iq>

8.3.3.4. forbidden

The requesting entity does not possess the necessary permissions to

perform an action that only certain authorized roles or individuals

are allowed to complete (i.e., it typically relates to authorization

rather than authentication); the associated error type SHOULD be

"auth".

C: <presence

      from='juliet@im.example.com/balcony'

      id='y2bs71v4'

      to='characters@muc.example.com/JulieC'>

    <x xmlns='http://jabber.org/protocol/muc'/>

  </presence>

E: <presence

      from='characters@muc.example.com/JulieC'

      id='y2bs71v4'

      to='juliet@im.example.com/balcony'

      type='error'>

    <error type='auth'>

      <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </presence>

Saint-Andre Standards Track [Page 112]

RFC 6120 XMPP Core March 2011

8.3.3.5. gone

The recipient or server can no longer be contacted at this address,

typically on a permanent basis (as opposed to the error

condition, which is used for temporary addressing failures); the

associated error type SHOULD be "cancel" and the error stanza SHOULD

include a new address (if available) as the XML character data of the

element (which MUST be a Uniform Resource Identifier [URI] or

Internationalized Resource Identifier [IRI] at which the entity can

be contacted, typically an XMPP IRI as specified in [XMPP-URI]).

C: <message

      from='juliet@im.example.com/churchyard'

      id='sj2b371v'

      to='romeo@example.net'

      type='chat'>

    <body>Thy lips are warm.</body>

  </message>

S: <message

      from='romeo@example.net'

      id='sj2b371v'

      to='juliet@im.example.com/churchyard'

      type='error'>

    <error by='example.net'

           type='cancel'>

      <gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>

        xmpp:romeo@afterlife.example.net

      </gone>

    </error>

  </message>

8.3.3.6. internal-server-error

The server has experienced a misconfiguration or other internal error

that prevents it from processing the stanza; the associated error

type SHOULD be "cancel".

C: <presence

      from='juliet@im.example.com/balcony'

      id='y2bs71v4'

      to='characters@muc.example.com/JulieC'>

    <x xmlns='http://jabber.org/protocol/muc'/>

  </presence>

Saint-Andre Standards Track [Page 113]

RFC 6120 XMPP Core March 2011

E: <presence

      from='characters@muc.example.com/JulieC'

      id='y2bs71v4'

      to='juliet@im.example.com/balcony'

      type='error'>

    <error type='cancel'>

      <internal-server-error

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </presence>

8.3.3.7. item-not-found

The addressed JID or item requested cannot be found; the associated

error type SHOULD be "cancel".

C: <presence from='userfoo@example.com/bar'

            id='pwb2n78i'

            to='nosuchroom@conference.example.org/foo'/>

S: <presence from='nosuchroom@conference.example.org/foo'

            id='pwb2n78i'

            to='userfoo@example.com/bar'

            type='error'>

    <error type='cancel'>

      <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </presence>

  Security Warning: An application MUST NOT return this error if

  doing so would provide information about the intended recipient's

  network availability to an entity that is not authorized to know

  such information (for a more detailed discussion of presence

  authorization, refer to the discussion of presence subscriptions

  in [XMPP-IM]); instead it MUST return a <service-unavailable/>

  stanza error (Section 8.3.3.19).

8.3.3.8. jid-malformed

The sending entity has provided (e.g., during resource binding) or

communicated (e.g., in the 'to' address of a stanza) an XMPP address

or aspect thereof that violates the rules defined in [XMPP-ADDR]; the

associated error type SHOULD be "modify".

Saint-Andre Standards Track [Page 114]

RFC 6120 XMPP Core March 2011

C: <presence

      from='juliet@im.example.com/balcony'

      id='y2bs71v4'

      to='ch@r@cters@muc.example.com/JulieC'>

    <x xmlns='http://jabber.org/protocol/muc'/>

  </presence>

E: <presence

      from='ch@r@cters@muc.example.com/JulieC'

      id='y2bs71v4'

      to='juliet@im.example.com/balcony'

      type='error'>

    <error by='muc.example.com'

           type='modify'>

      <jid-malformed

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </presence>

  Implementation Note: Enforcement of the format for XMPP localparts

  is primarily the responsibility of the service at which the

  associated account or entity is located (e.g., the example.com

  service is responsible for returning <jid-malformed/> errors

  related to all JIDs of the form <localpart@example.com>), whereas

  enforcement of the format for XMPP domainparts is primarily the

  responsibility of the service that seeks to route a stanza to the

  service identified by that domainpart (e.g., the example.org

  service is responsible for returning <jid-malformed/> errors

  related to stanzas that users of that service have to tried send

  to JIDs of the form <localpart@example.com>).  However, any entity

  that detects a malformed JID MAY return this error.

8.3.3.9. not-acceptable

The recipient or server understands the request but cannot process it

because the request does not meet criteria defined by the recipient

or server (e.g., a request to subscribe to information that does not

simultaneously include configuration parameters needed by the

recipient); the associated error type SHOULD be "modify".

    <body>[ ... the-emacs-manual ... ]</body>

  </message>

Saint-Andre Standards Track [Page 115]

RFC 6120 XMPP Core March 2011

    <error type='modify'>

      <not-acceptable

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </message>

8.3.3.10. not-allowed

The recipient or server does not allow any entity to perform the

action (e.g., sending to entities at a blacklisted domain); the

associated error type SHOULD be "cancel".

C: <presence

      from='juliet@im.example.com/balcony'

      id='y2bs71v4'

      to='characters@muc.example.com/JulieC'>

    <x xmlns='http://jabber.org/protocol/muc'/>

  </presence>

E: <presence

      from='characters@muc.example.com/JulieC'

      id='y2bs71v4'

      to='juliet@im.example.com/balcony'

      type='error'>

    <error type='cancel'>

      <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </presence>

8.3.3.11. not-authorized

The sender needs to provide credentials before being allowed to

perform the action, or has provided improper credentials (the name

"not-authorized", which was borrowed from the "401 Unauthorized"

error of [HTTP], might lead the reader to think that this condition

relates to authorization, but instead it is typically used in

relation to authentication); the associated error type SHOULD be

"auth".

C: <presence

      from='juliet@im.example.com/balcony'

      id='y2bs71v4'

      to='characters@muc.example.com/JulieC'>

    <x xmlns='http://jabber.org/protocol/muc'/>

  </presence>

Saint-Andre Standards Track [Page 116]

RFC 6120 XMPP Core March 2011

E: <presence

      from='characters@muc.example.com/JulieC'

      id='y2bs71v4'

      to='juliet@im.example.com/balcony'>

    <error type='auth'>

      <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </presence>

8.3.3.12. policy-violation

The entity has violated some local service policy (e.g., a message

contains words that are prohibited by the service) and the server MAY

choose to specify the policy in the element or in an

application-specific condition element; the associated error type

SHOULD be "modify" or "wait" depending on the policy being violated.

(In the following example, the client sends an XMPP message

containing words that are forbidden according to the server's local

service policy.)

C: <message from='romeo@example.net/foo'

           to='bill@im.example.com'

           id='vq71f4nb'>

    <body>%#&@^!!!</body>

  </message>

S: <message from='bill@im.example.com'

           id='vq71f4nb'

           to='romeo@example.net/foo'>

    <error by='example.net' type='modify'>

      <policy-violation

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </message>

8.3.3.13. recipient-unavailable

The intended recipient is temporarily unavailable, undergoing

maintenance, etc.; the associated error type SHOULD be "wait".

C: <presence

      from='juliet@im.example.com/balcony'

      id='y2bs71v4'

      to='characters@muc.example.com/JulieC'>

    <x xmlns='http://jabber.org/protocol/muc'/>

  </presence>

Saint-Andre Standards Track [Page 117]

RFC 6120 XMPP Core March 2011

E: <presence

      from='characters@muc.example.com/JulieC'

      id='y2bs71v4'

      to='juliet@im.example.com/balcony'>

    <error type='wait'>

      <recipient-unavailable

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </presence>

  Security Warning: An application MUST NOT return this error if

  doing so would provide information about the intended recipient's

  network availability to an entity that is not authorized to know

  such information (for a more detailed discussion of presence

  authorization, refer to the discussion of presence subscriptions

  in [XMPP-IM]); instead it MUST return a <service-unavailable/>

  stanza error (Section 8.3.3.19).

8.3.3.14. redirect

The recipient or server is redirecting requests for this information

to another entity, typically in a temporary fashion (as opposed to

the error condition, which is used for permanent addressing

failures); the associated error type SHOULD be "modify" and the error

stanza SHOULD contain the alternate address in the XML character data

of the element (which MUST be a URI or IRI with which the

sender can communicate, typically an XMPP IRI as specified in

[XMPP-URI]).

C: <presence

      from='juliet@im.example.com/balcony'

      id='y2bs71v4'

      to='characters@muc.example.com/JulieC'>

    <x xmlns='http://jabber.org/protocol/muc'/>

  </presence>

E: <presence

      from='characters@muc.example.com/JulieC'

      id='y2bs71v4'

      to='juliet@im.example.com/balcony'

      type='error'>

    <error type='modify'>

      <redirect xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>

        xmpp:characters@conference.example.org

      </redirect>

    </error>

  </presence>

Saint-Andre Standards Track [Page 118]

RFC 6120 XMPP Core March 2011

  Security Warning: An application receiving a stanza-level redirect

  SHOULD warn a human user of the redirection attempt and request

  approval before proceeding to communicate with the entity whose

  address is contained in the XML character data of the <redirect/>

  element, because that entity might have a different identity or

  might enforce different security policies.  The end-to-end

  authentication or signing of XMPP stanzas could help to mitigate

  this risk, since it would enable the sender to determine if the

  entity to which it has been redirected has the same identity as

  the entity it originally attempted to contact.  An application MAY

  have a policy of following redirects only if it has authenticated

  the receiving entity.  In addition, an application SHOULD abort

  the communication attempt after a certain number of successive

  redirects (e.g., at least 2 but no more than 5).

8.3.3.15. registration-required

The requesting entity is not authorized to access the requested

service because prior registration is necessary (examples of prior

registration include members-only rooms in XMPP multi-user chat

[XEP-0045] and gateways to non-XMPP instant messaging services, which

traditionally required registration in order to use the gateway

[XEP-0100]); the associated error type SHOULD be "auth".

C: <presence

      from='juliet@im.example.com/balcony'

      id='y2bs71v4'

      to='characters@muc.example.com/JulieC'>

    <x xmlns='http://jabber.org/protocol/muc'/>

  </presence>

E: <presence

      from='characters@muc.example.com/JulieC'

      id='y2bs71v4'

      to='juliet@im.example.com/balcony'>

    <error type='auth'>

      <registration-required

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </presence>

8.3.3.16. remote-server-not-found

A remote server or service specified as part or all of the JID of the

intended recipient does not exist or cannot be resolved (e.g., there

is no _xmpp-server._tcp DNS SRV record, the A or AAAA fallback

Saint-Andre Standards Track [Page 119]

RFC 6120 XMPP Core March 2011

resolution fails, or A/AAAA lookups succeed but there is no response

on the IANA-registered port 5269); the associated error type SHOULD

be "cancel".

C: <message

      from='romeo@example.net/home'

      id='ud7n1f4h'

      to='bar@example.org'

      type='chat'>

   <body>yt?</body>

  </message>

E: <message

      from='bar@example.org'

      id='ud7n1f4h'

      to='romeo@example.net/home'

      type='error'>

    <error type='cancel'>

      <remote-server-not-found

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </message>

8.3.3.17. remote-server-timeout

A remote server or service specified as part or all of the JID of the

intended recipient (or needed to fulfill a request) was resolved but

communications could not be established within a reasonable amount of

time (e.g., an XML stream cannot be established at the resolved IP

address and port, or an XML stream can be established but stream

negotiation fails because of problems with TLS, SASL, Server

Dialback, etc.); the associated error type SHOULD be "wait" (unless

the error is of a more permanent nature, e.g., the remote server is

found but it cannot be authenticated or it violates security

policies).

C: <message

      from='romeo@example.net/home'

      id='ud7n1f4h'

      to='bar@example.org'

      type='chat'>

   <body>yt?</body>

  </message>

Saint-Andre Standards Track [Page 120]

RFC 6120 XMPP Core March 2011

E: <message

      from='bar@example.org'

      id='ud7n1f4h'

      to='romeo@example.net/home'

      type='error'>

    <error type='wait'>

      <remote-server-timeout

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </message>

8.3.3.18. resource-constraint

The server or recipient is busy or lacks the system resources

necessary to service the request; the associated error type SHOULD be

"wait".

C: <iq from='romeo@example.net/foo'

      id='kj4vz31m'

      to='pubsub.example.com'

      type='get'>

    <pubsub xmlns='http://jabber.org/protocol/pubsub'>

      <items node='my_musings'/>

    </pubsub>

  </iq>

E: <iq from='pubsub.example.com'

      id='kj4vz31m'

      to='romeo@example.net/foo'

      type='error'>

    <error type='wait'>

      <resource-constraint

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </iq>

8.3.3.19. service-unavailable

The server or recipient does not currently provide the requested

service; the associated error type SHOULD be "cancel".

C: <message from='romeo@example.net/foo'

           to='juliet@im.example.com'>

    <body>Hello?</body>

  </message>

Saint-Andre Standards Track [Page 121]

RFC 6120 XMPP Core March 2011

S: <message from='juliet@im.example.com/foo'

           to='romeo@example.net'>

    <error type='cancel'>

      <service-unavailable

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </message>

  Security Warning: An application MUST return a <service-

  unavailable/> stanza error (Section 8.3.3.19) instead of <item-

  not-found/> (Section 8.3.3.7) or <recipient-unavailable/>

  (Section 8.3.3.13) if sending one of the latter errors would

  provide information about the intended recipient's network

  availability to an entity that is not authorized to know such

  information (for a more detailed discussion of presence

  authorization, refer to [XMPP-IM]).

8.3.3.20. subscription-required

The requesting entity is not authorized to access the requested

service because a prior subscription is necessary (examples of prior

subscription include authorization to receive presence information as

defined in [XMPP-IM] and opt-in data feeds for XMPP publish-subscribe

as defined in [XEP-0060]); the associated error type SHOULD be

"auth".

C: <message

      from='romeo@example.net/orchard'

      id='pa73b4n7'

      to='playwright@shakespeare.example.com'

      type='chat'>

    <subject>ACT II, SCENE II</subject>

    <body>help, I forgot my lines!</body>

  </message>

E: <message

      from='playwright@shakespeare.example.com'

      id='pa73b4n7'

      to='romeo@example.net/orchard'

      type='error'>

    <error type='auth'>

      <subscription-required

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

    </error>

  </message>

Saint-Andre Standards Track [Page 122]

RFC 6120 XMPP Core March 2011

8.3.3.21. undefined-condition

The error condition is not one of those defined by the other

conditions in this list; any error type can be associated with this

condition, and it SHOULD NOT be used except in conjunction with an

application-specific condition.

C: <message

      from='northumberland@shakespeare.example'

      id='richard2-4.1.247'

      to='kingrichard@royalty.england.example'>

    <body>My lord, dispatch; read o'er these articles.</body>

    <amp xmlns='http://jabber.org/protocol/amp'>

      <rule action='notify'

            condition='deliver'

            value='stored'/>

    </amp>

  </message>

S: <message from='example.org'

           id='amp1'

           to='northumberland@example.net/field'

           type='error'>

    <amp xmlns='http://jabber.org/protocol/amp'

         from='kingrichard@example.org'

         status='error'

         to='northumberland@example.net/field'>

      <rule action='error'

            condition='deliver'

            value='stored'/>

    </amp>

    <error type='modify'>

      <undefined-condition

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

      <failed-rules xmlns='http://jabber.org/protocol/amp#errors'>

        <rule action='error'

              condition='deliver'

              value='stored'/>

      </failed-rules>

    </error>

  </message>

8.3.3.22. unexpected-request

The recipient or server understood the request but was not expecting

it at this time (e.g., the request was out of order); the associated

error type SHOULD be "wait" or "modify".

Saint-Andre Standards Track [Page 123]

RFC 6120 XMPP Core March 2011

C: <iq from='romeo@example.net/foo'

      id='o6hsv25z'

      to='pubsub.example.com'

      type='set'>

    <pubsub xmlns='http://jabber.org/protocol/pubsub'>

       <unsubscribe

           node='my_musings'

           jid='romeo@example.net'/>

    </pubsub>

  </iq>

E: <iq from='pubsub.example.com'

      id='o6hsv25z'

      to='romeo@example.net/foo'

      type='error'>

    <error type='modify'>

      <unexpected-request

          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

      <not-subscribed

          xmlns='http://jabber.org/protocol/pubsub#errors'/>

    </error>

  </iq>

8.3.4. Application-Specific Conditions

As noted, an application MAY provide application-specific stanza

error information by including a properly namespaced child within the

error element. Typically, the application-specific element

supplements or further qualifies a defined element. Thus, the

element will contain two or three child elements.

 <error type='modify'>

   <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

   <too-many-parameters xmlns='http://example.org/ns'/>

 </error>

Saint-Andre Standards Track [Page 124]

RFC 6120 XMPP Core March 2011

 <error type='modify'>

   <undefined-condition

         xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

   <text xml:lang='en'

         xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>

     [ ... application-specific information ... ]

   </text>

   <too-many-parameters xmlns='http://example.org/ns'/>

 </error>

An entity that receives an application-specific error condition it

does not understand MUST ignore that condition but appropriately

process the rest of the error stanza.

8.4. Extended Content

Although the message, presence, and IQ stanzas provide basic

semantics for messaging, availability, and request-response

interactions, XMPP uses XML namespaces (see [XML-NAMES]) to extend

the basic stanza syntax for the purpose of providing additional

functionality.

A message or presence stanza MAY contain one or more optional child

elements specifying content that extends the meaning of the message

(e.g., an XHTML-formatted version of the message body as described in

[XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one

such child element. Such a child element MAY have any name and MUST

possess a namespace declaration (other than "jabber:client", "jabber:

server", or "http://etherx.jabber.org/streams") that defines the data

contained within the child element. Such a child element is called

an "extension element". An extension element can be included either

at the direct child level of the stanza or in any mix of levels.

Similarly, "extension attributes" are allowed. That is: a stanza

itself (i.e., an , , or element qualified

by the "jabber:client" or "jabber:server" content namespace) or any

child element of such a stanza (whether an extension element or a

child element qualified by the content namespace) MAY also include

one or more attributes qualified by XML namespaces other than the

content namespace or the reserved

"http://www.w3.org/XML/1998/namespace" namespace (including the so-

called "empty namespace" if the attribute is not prefixed as

described under [XML-NAMES]).

Saint-Andre Standards Track [Page 125]

RFC 6120 XMPP Core March 2011

  Interoperability Note: For the sake of backward compatibility and

  maximum interoperability, an entity that generates a stanza SHOULD

  NOT include such attributes in the stanza itself or in child

  elements of the stanza that are qualified by the content

  namespaces "jabber:client" or "jabber:server" (e.g., the <body/>

  child of the <message/> stanza).

An extension element or extension attribute is said to be "extended

content" and the qualifying namespace for such an element or

attribute is said to be an "extended namespace".

  Informational Note: Although extended namespaces for XMPP are

  commonly defined by the XMPP Standards Foundation (XSF) and by the

  IETF, no specification or IETF standards action is necessary to

  define extended namespaces, and any individual or organization is

  free to define XMPP extensions.

To illustrate these concepts, several examples follow.

The following stanza contains one direct child element whose extended

namespace is 'jabber:iq:roster':

<iq from='juliet@capulet.com/balcony'

   id='h83vxa4c'

   type='get'>

<query xmlns='jabber:iq:roster'/>

The following stanza contains two direct child elements with two

different extended namespaces.

 <c xmlns='http://jabber.org/protocol/caps'

    hash='sha-1'

    node='http://code.google.com/p/exodus'

    ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>

 <x xmlns='vcard-temp:x:update'>

   <photo>sha1-hash-of-image</photo>

 </x>

The following stanza contains two child elements, one of which is

qualified by the "jabber:client" or "jabber:server" content namespace

and one of which is qualified by an extended namespace; the extension

element in turn contains a child element that is qualified by a

different extended namespace.

Saint-Andre Standards Track [Page 126]

RFC 6120 XMPP Core March 2011

 <body>Hello?</body>

 <html xmlns='http://jabber.org/protocol/xhtml-im'>

   <body xmlns='http://www.w3.org/1999/xhtml'>

     <p style='font-weight:bold'>Hello?</p>

   </body>

 </html>

It is conventional in the XMPP community for implementations to not

generate namespace prefixes for elements that are qualified by

extended namespaces (in the XML community, this convention is

sometimes called "prefix-free canonicalization"). However, if an

implementation generates such namespace prefixes then it MUST include

the namespace declaration in the stanza itself or a child element of

the stanza, not in the stream header (see Section 4.8.4).

Routing entities (typically servers) SHOULD try to maintain prefixes

when serializing XML stanzas for processing, but receiving entities

MUST NOT depend on the prefix strings to have any particular value

(the allowance for the 'stream' prefix, described under

Section 4.8.5, is an exception to this rule, albeit for streams

rather than stanzas).

Support for any given extended namespace is OPTIONAL on the part of

any implementation. If an entity does not understand such a

namespace, the entity's expected behavior depends on whether the

entity is (1) the recipient or (2) a server that is routing or

delivering the stanza to the recipient.

If a recipient receives a stanza that contains an element or

attribute it does not understand, it MUST NOT attempt to process that

XML data and instead MUST proceed as follows.

o If an intended recipient receives a message stanza whose only

  child element is qualified by a namespace it does not understand,

  then depending on the XMPP application it MUST either ignore the

  entire stanza or return a stanza error, which SHOULD be <service-

  unavailable/> (Section 8.3.3.19).

o If an intended recipient receives a presence stanza whose only

  child element is qualified by a namespace it does not understand,

  then it MUST ignore the child element by treating the presence

  stanza as if it contained no child element.

Saint-Andre Standards Track [Page 127]

RFC 6120 XMPP Core March 2011

o If an intended recipient receives a message or presence stanza

  that contains XML data qualified by a namespace it does not

  understand, then it MUST ignore the portion of the stanza

  qualified by the unknown namespace.

o If an intended recipient receives an IQ stanza of type "get" or

  "set" containing a child element qualified by a namespace it does

  not understand, then the entity MUST return an IQ stanza of type

  "error" with an error condition of <service-unavailable/>.

If a server handles a stanza that is intended for delivery to another

entity and that contains a child element it does not understand, it

MUST route the stanza unmodified to a remote server or deliver the

stanza unmodified to a connected client associated with a local

account.

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

Saint-Andre Standards Track [Page 128]

RFC 6120 XMPP Core March 2011

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):

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

      <required/>

    </starttls>

  </stream:features>

Step 4: Client sends STARTTLS command to server:

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

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):

  </stream:stream>

Step 6: Client and server attempt to complete TLS negotiation over

the existing TCP connection (see [TLS] for details).

Saint-Andre Standards Track [Page 129]

RFC 6120 XMPP Core March 2011

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

    <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".

Saint-Andre Standards Track [Page 130]

RFC 6120 XMPP Core March 2011

Step 10: Server sends a challenge:

    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:

    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:

    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):

    <not-authorized/>

  </failure>

  </stream>

Saint-Andre Standards Track [Page 131]

RFC 6120 XMPP Core March 2011

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