<title>Best Practices for Use of SASL ANONYMOUS</title>
<abstract>This document specifies best practices for use of the SASL ANONYMOUS mechanism in the context of client authentication with an XMPP server.</abstract>
&LEGALNOTICE;
<number>0175</number>
<status>Active</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.0</version>
<date>2006-09-20</date>
<initials>psa</initials>
<remark><p>Per a vote of the Jabber Council, advanced status to Active.</p></remark>
<p><cite>RFC 3920</cite> allows the use of any SASL mechanism (see &rfc4422;) in XMPP authentication, including the SASL ANONYMOUS mechanism (see &rfc4505;). This document specifies a recommended protocol flow for such use.</p>
<p>Note: This document is provided for discussion purposes in order to clarify the usage of SASL ANONYMOUS in XMPP systems. It is not meant to supersede the text in <cite>RFC 3920</cite>, <cite>RFC 4422</cite>, or <cite>RFC 4505</cite>. However, the recommendations in this document may be folded into <cite>rfc3920bis</cite> when that document is written.</p>
</section1>
<section1topic='Recommendation'anchor='rec'>
<p><cite>RFC 3920</cite> specifies that after an XMPP client authenticates with an XMPP server, it must bind a resource to the XML stream so that XML stanzas can be routed to the client. In essence there are three resource binding scenarios:</p>
<ol>
<li>The client specifies a desired resource identifier and the server accepts it.</li>
<li>The client specifies a desired resource identifier but the server does not accept it, instead overruling the client and assigning a resource identifier.</li>
<li>The client asks the server to assign a resource identifier and the server does so.</li>
</ol>
<p>No matter which scenario is enacted, at the end of the process the server informs the client of its full JID (&FULLJID;). In particular, it might be helpful for an XMPP server to assign a full JID to the client (i.e., not just the resource identifier) if it authenticates with SASL ANONYMOUS, and to ensure that the "bare JID" portion (&BAREJID;) is unique in the context of the domain served by the server.</p>
<p>The RECOMMENDED protocol flow following TLS negotiation (refer to <cite>RFC 3920</cite>) is as follows:</p>
<ol>
<li>
<p>Client initiates stream to server.</p>
<examplecaption="Stream initiation"><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client'
to='example.com'
version='1.0'>
]]></example>
</li>
<li>
<p>Server replies with stream header.</p>
<examplecaption="Stream header reply"><![CDATA[
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client'
id='c2s_234'
from='example.com'
version='1.0'>
]]></example>
</li>
<li>
<p>Server advertises stream features.</p>
<examplecaption="Stream features advertisement"><![CDATA[