1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00

clarified trace data restrictions

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1310 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-10-24 19:00:24 +00:00
parent 2625db2295
commit 549c8f97a5

View File

@ -22,8 +22,8 @@
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.1pre1</version>
<date>in progress, last updated 2007-10-18</date>
<version>1.1pre2</version>
<date>in progress, last updated 2007-10-24</date>
<initials>psa</initials>
<remark><p>Recommended that node identifier be a UUID; recommended that trace data not be included.</p></remark>
</revision>
@ -60,7 +60,7 @@
</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>
<p>Although <cite>RFC 4505</cite> allows the initiating entity (client) to provide so-called "trace data" when authenticating via SASL ANONYMOUS, 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). However, if trace data is included, the server MUST NOT use it for any purpose other than tracing (e.g., in server logs).</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>