From 1a5ae1674bc819011b5ae5def1b53853d53f9715 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 24 Jan 2007 16:19:17 +0000 Subject: [PATCH] typo git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@410 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0201.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0201.xml b/xep-0201.xml index b7b8b245..34ecaae7 100644 --- a/xep-0201.xml +++ b/xep-0201.xml @@ -62,13 +62,13 @@ -

Section 2.1.2.3 of RFC 3920 currently states the following regarding the semantics of the ThreadID:

+

Section 2.1.2.3 of RFC 3921 currently states the following regarding the semantics of the ThreadID:

The <thread/> element contains non-human-readable XML character data specifying an identifier that is used for tracking a conversation thread (sometimes referred to as an "instant messaging session") between two entities.

The description in RFC 3921 is deemed to be too limiting, since it ignores the potential use of the ThreadID when exchanging message stanzas of types other than 'chat'. Therefore we proposal the following description:

The primary use of the XMPP <thread/> element is to uniquely identify a conversation thread or "chat session" between two entities instantiated by <message/> stanzas of type 'chat'. However, the XMPP <thread/> element may also be used to uniquely identify an analogous thread between two entities instantiated by <message/> stanzas of type 'headline' or 'normal', or among multiple entities in the context of a multi-user chat room instantiated by <message/> stanzas of type 'groupchat'. It may also be used for <message/> stanzas not related to a conversation, such as a game session or between plugins.

-

Section 2.1.2.3 of RFC 3920 currently states the following uniqueness requirement:

+

Section 2.1.2.3 of RFC 3921 currently states the following uniqueness requirement:

The value of the <thread/> element ... MUST be unique to that conversation thread within the stream and MUST be consistent throughout that conversation (a client that receives a message from the same full JID but with a different thread ID MUST assume that the message in question exists outside the context of the existing conversation thread).

The uniqueness requirement in RFC 3921 is not deemed strong enough since it is desirable that a ThreadID could be used to (for instance) restart a conversation at a later date. Therefore we propose the following uniqueness requirement:

The value of the <thread/> element MUST be a universally unique identifier (UUID) as described in &rfc4122;.