moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

1.1pre1 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1297 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-10-18 18:04:38 +00:00
parent 3a984255c8
commit 4909741db7
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
xep-0175.xml
View File

@ -21,6 +21,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.1pre1</version>
<date>in progress, last updated 2007-10-18</date>
<initials>psa</initials>
<remark><p>Recommended that node identifier be a UUID; recommended that trace data not be included.</p></remark>
</revision>
<revision>
<version>1.0</version>
<date>2006-09-20</date>
@ -53,6 +59,10 @@
<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 method for ensuring the uniqueness of the node identifier is a matter of implementation. It is RECOMMENDED for the node identifier to be a UUID as specified in &rfc4122;.</p>
<p>Although <cite>RFC 4505</cite> allows the initiating entity (client) to provide so-called "trace data" when authenticating via SASL ANONYMOUS, no standardized usage of trace data is defined for the XMPP profile, and it is NOT RECOMMENDED to include trace data as the XML character data of the &lt;auth/&gt; element (instead, the &lt;auth/&gt; element SHOULD be empty).</p>
</section1>
<section1 topic='Protocol Flow' anchor='flow'>
<p>The RECOMMENDED protocol flow following TLS negotiation (refer to <cite>RFC 3920</cite>) is as follows:</p>
<ol>
<li>