mirror of https://github.com/moparisthebest/xeps
0.7
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@4312 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
92c91cd352
commit
4067defc23
32
xep-0201.xml
32
xep-0201.xml
|
|
@ -23,6 +23,12 @@
|
|||
&stpeter;
|
||||
&ianpaterson;
|
||||
&ksmith;
|
||||
<revision>
|
||||
<version>0.7</version>
|
||||
<date>2010-07-12</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Removed definition of ThreadID syntax, semantics, and uniqueness because rfc3921bis covers those topics.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.6</version>
|
||||
<date>2010-05-21</date>
|
||||
|
|
@ -73,7 +79,7 @@
|
|||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>Although message threads are re-used in XMPP extension protocols such as &xep0085;, the semantics of message threads have never been well specified (e.g., in &rfc3921;). This document attempts to clearly specify the meaning and handling of message threads for implementation by XMPP clients and for potential inclusion in &rfc3921bis;.</p>
|
||||
<p>Although message threads are re-used in XMPP extension protocols such as &xep0085;, best practices for generating and handling message threads have never been well specified (e.g., in &rfc3921; or &rfc3921bis;). This document attempts to clearly specify those matters for implementation by XMPP clients.</p>
|
||||
</section1>
|
||||
<section1 topic='Motivation' anchor='motivation'>
|
||||
<p>Threads matter because they enable XMPP clients to:</p>
|
||||
|
|
@ -85,28 +91,6 @@
|
|||
<li>Route XMPP stanzas within a client (e.g., dispatching different content types to different windows), thus facilitating the creation of more robust plugin architectures.</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Definition' anchor='def'>
|
||||
<section2 topic='Semantics' anchor='semantics'>
|
||||
<p>Section 2.1.2.3 of <cite>RFC 3921</cite> states the following regarding the semantics of the ThreadID:</p>
|
||||
<p class='indent'>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 value of the <thread/> element MUST be treated as opaque by entities; no semantic meaning may be derived from it, and only exact comparisons may be made against it.</p>
|
||||
<p>The description in <cite>RFC 3921</cite> 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 propose the following description:</p>
|
||||
<p class='indent'>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 an interaction between plugins. The <thread/> element is not used to identify individual messages, only conversations or messaging sessions.</p>
|
||||
</section2>
|
||||
<section2 topic='Syntax' anchor='syntax'>
|
||||
<p>Section 2.1.2.3 of <cite>RFC 3921</cite> states the following regarding the syntax of the ThreadID:</p>
|
||||
<p class='indent'>A message stanza MUST NOT contain more than one <thread/> element. The <thread/> element MUST NOT possess any attributes.... The <thread/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of XML).</p>
|
||||
<p>For the purpose of improved thread handling, we propose defining a 'parent' attribute that enables an application to identify the current thread as an offshoot or child of a previous thread. Therefore we suggest the following syntax definition:</p>
|
||||
<p class='indent'>The inclusion of the <thread/> element is OPTIONAL. Because the <thread/> element uniquely identifies the particular conversation thread to which a message belongs, a message stanza MUST NOT contain more than one <thread/> element.</p>
|
||||
<p class='indent'>The <thread/> element MAY possess a 'parent' attribute that identifies another thread of which the current thread is an offshoot or child; the value of the 'parent' attribute MUST conform to the syntax of the <thread/> element itself.</p>
|
||||
<p class='indent'>The <thread/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of <xref target="XML"/>).</p>
|
||||
</section2>
|
||||
<section2 topic='Uniqueness' anchor='unique'>
|
||||
<p>Section 2.1.2.3 of <cite>RFC 3921</cite> states the following uniqueness requirement:</p>
|
||||
<p class='indent'>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).</p>
|
||||
<p>The uniqueness requirement in <cite>RFC 3921</cite> 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:</p>
|
||||
<p class='indent'>The value of the <thread/> element is not human-readable and MUST be treated as opaque by entities; no semantic meaning MAY be derived from it, and only exact comparisons may be made against it. The value of the <thread/> element MUST be a universally unique identifier (UUID) as described in &rfc4122;.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Generation' anchor='generation'>
|
||||
<section2 topic='Inclusion' anchor='inclusion'>
|
||||
<p>Depending on the type of the message (i.e., the value of the 'type' attribute), the <thread/> should be included as follows:</p>
|
||||
|
|
@ -175,7 +159,7 @@
|
|||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>An application that generates the UUID used as the ThreadID MUST ensure that the UUID does not reveal identifying information about the entity (e.g., the MAC address of the device on which the XMPP application is running).</p>
|
||||
<p>An application that generates a UUID for use as the ThreadID MUST ensure that the UUID does not reveal identifying information about the entity (e.g., the MAC address of the device on which the XMPP application is running).</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
|
|
|
|||
Loading…
Reference in New Issue