From 549c8f97a505b0c1ef84878c45a215eec7003fd8 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 24 Oct 2007 19:00:24 +0000 Subject: [PATCH] clarified trace data restrictions git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1310 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0175.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xep-0175.xml b/xep-0175.xml index ce140048..edad187c 100644 --- a/xep-0175.xml +++ b/xep-0175.xml @@ -22,8 +22,8 @@ N/A &stpeter; - 1.1pre1 - in progress, last updated 2007-10-18 + 1.1pre2 + in progress, last updated 2007-10-24 psa

Recommended that node identifier be a UUID; recommended that trace data not be included.

@@ -60,7 +60,7 @@

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.

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

-

Although RFC 4505 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 <auth/> element (instead, the <auth/> element SHOULD be empty).

+

Although RFC 4505 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 <auth/> element (instead, the <auth/> 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).

The RECOMMENDED protocol flow following TLS negotiation (refer to RFC 3920) is as follows: