Initial version.
Although message threads are re-used in XMPP extension protocols such as &xep0085; and &xep0155;, the semantics of message threads have never been well specified (e.g., in RFC 3921). This document attempts to clearly specify the meaning and handling of message threads for implementation by XMPP clients and possible incorporation into the successor to RFC 3921.
+Threads matter because they enable XMPP clients to:
+Section 2.1.2.3 of RFC 3920 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'.
+Section 2.1.2.3 of RFC 3920 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:
+For messages of type 'chat', 'headline', or 'normal', the value of the <thread/> element MUST be unique for the combination of the sender's bare JID and recipient's bare JID (i.e., the thread MUST NOT ever be repeated in communications between the sender and recipient). For messages of type 'groupchat', the value of the <thread/> element MUST be unique in the context of the multi-user chat room, as long as the room remains in existence.
+In the context of <message/> stanzas of type 'chat' exchanged between two entities, the value of the <thread/> element shall be considered equivalent to a unique identifier for the chat session or conversation thread. If an entity receives such a message with a new or unknown ThreadID, it SHOULD treat the message as part of a session with unnegotiated parameters (i.e., as equivalent to the first message in a chat session that has been negotiated via XEP-0155 with no parameters specified). An entity SHOULD destroy the thread when it sends or receives a XEP-0155 "terminate" action and MAY destroy the thread when it goes offline, but SHOULD NOT destroy the thread if a human user merely closes a window in a client interface.
+To ensure the uniqueness of ThreadIDs in the context of a multi-user chat room, the multi-use chat service MAY provide a way for room occupants to request a unique ThreadID; definition of such methods is out of scope for this specification.
+There are no special handling requirements related to threads in the context of <message/> stanzas of type 'headline' or 'normal'.
+Depending on the type of the message (i.e., the value of the 'type' attribute), the <thread/> should be included as follows:
+| Message Type | +Inclusion | +
|---|---|
| chat | +RECOMMENDED | +
| groupchat | +OPTIONAL | +
| headline | +OPTIONAL | +
| normal | +OPTIONAL | +
In some contexts it may be desirable to enforce thread-like semantics when exchanging XMPP <iq/> stanzas. Because RFC 3920 disallows more than one direct child element of the <iq/> stanza, it is not possible to include the <thread/> element for tracking purposes. Therefore we define a "ThreadID" &xep0131; header with the same semantics as the <thread/> element, but with the syntax of a SHIM header:
+This document introduces no new security concerns or considerations above and beyond those specified in RFC 3920 and RFC 3921.
+This document requires no interaction with &IANA;.
+The XMPP Registrar shall add "ThreadID" to its registry of SHIM headers. The submission is as follows:
+
+ ThreadID
+
+ This header has the same semantics as the thread child element
+ of the XMPP message stanza but is for use in IQ stanzas.
+
+ XEP-0201
+
+ ]]>
+ Initial version; further specified security considerations; per Council feedback, removed tz and display elements.
Clarified text; adjusted protocol definition; corrected schema.
First draft.
Although the XMPP protocol extension defined in &xep0090; provides a way to discover the time at another entity, it has several limitations:
+The 'jabber:iq:time' namespace specified in XEP-0090 requires communication of time only in UTC. While this is useful for UTC synchronization (e.g., if a client wants to synchronize with its server), it does not enable one entity to know the other entity's offset from UTC.
The timezone may be specified in a natural language (English) name via the <tz/> element, but not in a numeric offest. The name may be not understood by the requesting entity since there is no reliable and canonical list of timezone names
The responding entity may provide a user-friendly datetime format via the <display/> element, but this too is effectively useless since datetime formats vary widely by culture and nation.
The 'jabber:iq:time' namespace specified in XEP-0090 (first developed in 1999 or 2000) is not consistent with the recommended date and time profiles for XMPP protocols defined in &xep0082; (written in 2003).
To overcome these limitations, this document defines a replacement for XEP-0090 which enables communication of an entity's UTC time and numeric time zone offset while adhering to XEP-0082.
+The namespace defined herein provides a standard way for XMPP entities to exchange information about the local time. The information is communicated in a request/response pair using an &IQ; element that contains a <time/> element qualified by an XML namespace to be issued when this specification advances to a status of Draft (see Protocol Namespace). The following children of the <time/> element are defined for use in IQ stanzas of type 'result':
+| Element | +Definition | +Inclusion | +
|---|---|---|
| <tzo/> | +The entity's numeric time zone offset from UTC. The format MUST conform to Time Zone Definition (TZD) in XEP-0082. | +REQUIRED | +
| <utc/> | +The UTC time according to the responding entity. The format MUST conform to the dateTime profile specified in XEP-0082 and MUST be expressed in UTC. | +REQUIRED | +
The standard error conditions described in &xep0086; apply (e.g., &unavailable; if the entity does not support the namespace).
+This protocol was designed in a way that makes migration from XEP-0090 straightforward. This document specifies a different format for the XML character data of the <utc> element (compliant with XEP-0082) and specifies a new <tzo> element for the numeric offset from UTC, while removing the formerly optional and effectively useless <display/> and <tz/> elements.
+Implementations that support XEP-0090 should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0090 for backwards compatibility until the status of that specification is changed to Obsolete.
+Revealing an entity's numeric time zone offset may leak limited information about the entity's current location. If the entity's understanding of UTC is far off from actual UTC, revealing that discrepancy may make it possible for an attacker to send XML stanzas that appear to be in the past or future even though they are not; therefore an entity should use the Network Time Protocol (&rfc0958;) or a similar technology to stay synchronized with actual UTC.
+This document requires no interaction with &IANA;.
+Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0202.html#ns"; upon advancement of this specification, the XMPP Registrar shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+Initial version.
Although the XMPP protocol extension defined in &xep0091; provides a way to communicate that an XML stanza (typically a &MESSAGE; or &PRESENCE; stanza) has been delivered with a delay, the timestamp format defined in that document does not adhere to the recommended date and time profiles for XMPP protocols defined in &xep0082;. Therefore, this document defines a replacement for XEP-0091 which enables communication of delayed delivery information while adhering to XEP-0082.
+The XML namespace defined herein is used to provide timestamp information about data stored for later delivery. The most common uses of this namespace are to stamp:
+Information about the delivery delay is communicated by adding to the <message/> or <presence/> stanza one and only one <delay/> child qualified by a namespace to be issued when this specification advances to a status of Draft. This information is added by the server or component that delivers the stanza. The following attributes are defined for the <delay/> element:
+| Element | +Definition | +Inclusion | +
|---|---|---|
| <from/> | +The Jabber ID of the entity that originally sent the XML stanza or that delayed the delivery of the stanza (e.g., the address of a multi-user chat room). | +RECOMMENDED | +
| <stamp/> | +The time when the XML stanza was originally sent. The format MUST adhere to the dateTime format specified in XEP-0082 and MUST be expressed in UTC. | +REQUIRED | +
In addition, the <delay/> element MAY contain XML character data that provides a natural-language description of the reason for the delay.
+This protocol was designed in a way that makes migration from XEP-0091 straightforward. All attributes present in the 'jabber:x:delay' namespace are present in the namespace defined herein. However, this document specifies a different format for the value of the <stamp> attribute (compliant with XEP-0082).
+Implementations that support XEP-0091 should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0091 for backwards compatibility until the status of that specification is changed to Obsolete.
+Delayed delivery data can expose information about the sender's presence on the network at some time in the past. However, this introduces no new vulnerabilities, since the same information would have been available in real time.
+This document requires no interaction with &IANA;.
+Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0203.html#ns"; upon advancement of this specification, the XMPP Registrar shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+