mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
initial version
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@283 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
0ca76963bd
commit
36d043ec3f
137
xep-0201.xml
Normal file
137
xep-0201.xml
Normal file
@ -0,0 +1,137 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Best Practices for Message Threads</title>
|
||||
<abstract>This specification defines recommended handling of XMPP message threads.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0201</number>
|
||||
<status>Experimental</status>
|
||||
<type>Informational</type>
|
||||
<jig>Standards JIG</jig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>N/A</shortname>
|
||||
&stpeter;
|
||||
&ianpaterson;
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2006-12-20</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.2</version>
|
||||
<date>2006-12-14</date>
|
||||
<initials>psa</initials>
|
||||
<remark>Corrected SHIM example; added XMPP Registrar considerations.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2006-12-13</date>
|
||||
<initials>psa/ip</initials>
|
||||
<remark>First draft.</remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
&RFC3921BISNOTE;
|
||||
<p>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 <cite>RFC 3921</cite>). 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 <cite>RFC 3921</cite>.</p>
|
||||
</section1>
|
||||
<section1 topic='Motivation' anchor='motivation'>
|
||||
<p>Threads matter because they enable XMPP clients to:</p>
|
||||
<ul>
|
||||
<li>Track conversation topics within the context of a one-to-one chat session or a &xep0045; room.</li>
|
||||
<li>Restart a chat or groupchat conversation from message history.</li>
|
||||
<li>Separate logical sessions from physical interface objects such as windows.</li>
|
||||
<li>Route XMPP stanzas internally (e.g., dispatching different content types to different windows), thus facilitating the creation of more robust plugin architectures.</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Semantics' anchor='semantics'>
|
||||
<p>Section 2.1.2.3 of <cite>RFC 3920</cite> currently 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.</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 proposal 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'.</p>
|
||||
</section1>
|
||||
<section1 topic='Uniqueness' anchor='unique'>
|
||||
<p>Section 2.1.2.3 of <cite>RFC 3920</cite> currently 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'>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.</p>
|
||||
</section1>
|
||||
<section1 topic='Handling' anchor='handling'>
|
||||
<p>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 <cite>XEP-0155</cite> with no parameters specified). An entity SHOULD destroy the thread when it sends or receives a <cite>XEP-0155</cite> "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.</p>
|
||||
<p>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.</p>
|
||||
<p>There are no special handling requirements related to threads in the context of <message/> stanzas of type 'headline' or 'normal'.</p>
|
||||
</section1>
|
||||
<section1 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>
|
||||
<table caption='When to Include Threads'>
|
||||
<tr>
|
||||
<th>Message Type</th>
|
||||
<th>Inclusion</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>chat</td>
|
||||
<td>RECOMMENDED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>groupchat</td>
|
||||
<td>OPTIONAL</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>headline</td>
|
||||
<td>OPTIONAL</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>normal</td>
|
||||
<td>OPTIONAL</td>
|
||||
</tr>
|
||||
</table>
|
||||
</section1>
|
||||
<section1 topic='SHIM Header' anchor='shim'>
|
||||
<p>In some contexts it may be desirable to enforce thread-like semantics when exchanging XMPP <iq/> stanzas. Because <cite>RFC 3920</cite> 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:</p>
|
||||
<example caption='ThreadID header'><![CDATA[
|
||||
<iq from='romeo@montague.net/home'
|
||||
to='joogle@botster.shakespeare.lit'
|
||||
type='get'
|
||||
id='create1'>
|
||||
<command xmlns='http://jabber.org/protocol/commands'
|
||||
node='create'
|
||||
action='execute'>
|
||||
<headers xmlns='http://jabber.org/protocol/shim'>
|
||||
<header name='ThreadID'>e0ffe42b28561960c6b12b944a092794b9683a38</header>
|
||||
</headers>
|
||||
</command>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>This document introduces no new security concerns or considerations above and beyond those specified in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='SHIM Headers Registry' anchor='registrar-shim'>
|
||||
<p>The XMPP Registrar shall add "ThreadID" to its registry of SHIM headers. The submission is as follows:</p>
|
||||
<code><![CDATA[
|
||||
<header>
|
||||
<name>ThreadID</name>
|
||||
<desc>
|
||||
This header has the same semantics as the thread child element
|
||||
of the XMPP message stanza but is for use in IQ stanzas.
|
||||
</desc>
|
||||
<doc>XEP-0201</doc>
|
||||
</header>
|
||||
]]></code>
|
||||
</section2>
|
||||
</section1>
|
||||
</xep>
|
||||
141
xep-0202.xml
Normal file
141
xep-0202.xml
Normal file
@ -0,0 +1,141 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Entity Time</title>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating the local time of an entity.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0202</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<jig>Standards JIG</jig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0082</spec>
|
||||
</dependencies>
|
||||
<supersedes>
|
||||
<spec>XEP-0090</spec>
|
||||
</supersedes>
|
||||
<supersededby/>
|
||||
<shortname>Not yet assigned</shortname>
|
||||
&stpeter;
|
||||
<author>
|
||||
<firstname>Maciej</firstname>
|
||||
<surname>Niedzielski</surname>
|
||||
<email>machekku@uaznia.net</email>
|
||||
<jid>machekku@uaznia.net</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2006-12-20</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial version; further specified security considerations; per Council feedback, removed tz and display elements.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.2</version>
|
||||
<date>2006-12-19</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Clarified text; adjusted protocol definition; corrected schema.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2006-12-05</date>
|
||||
<initials>mn</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>Although the XMPP protocol extension defined in &xep0090; provides a way to discover the time at another entity, it has several limitations:</p>
|
||||
<ul>
|
||||
<li><p>The 'jabber:iq:time' namespace specified in <cite>XEP-0090</cite> 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.</p></li>
|
||||
<li><p>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 <note>A list of English-language time zone names and abbreviations is located at <<link url='http://www.timeanddate.com/library/abbreviations/timezones/'>http://www.timeanddate.com/library/abbreviations/timezones/</link>>, but it is not a canonical list and there are no such localized lists for all languages.</note> and in practice the XML character data of the <tx/> element is effectively useless.</p></li>
|
||||
<li><p>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.</p></li>
|
||||
<li><p>The 'jabber:iq:time' namespace specified in <cite>XEP-0090</cite> (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).</p></li>
|
||||
</ul>
|
||||
<p>To overcome these limitations, this document defines a replacement for <cite>XEP-0090</cite> which enables communication of an entity's UTC time and numeric time zone offset while adhering to <cite>XEP-0082</cite>.</p>
|
||||
</section1>
|
||||
<section1 topic='Protocol Definition' anchor='protocol'>
|
||||
<p>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 <link url='#ns'>Protocol Namespace</link>). The following children of the <time/> element are defined for use in IQ stanzas of type 'result':</p>
|
||||
<table caption='Child Elements'>
|
||||
<tr>
|
||||
<th>Element</th>
|
||||
<th>Definition</th>
|
||||
<th>Inclusion</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><tzo/></td>
|
||||
<td>The entity's numeric time zone offset from UTC. The format MUST conform to Time Zone Definition (TZD) in <cite>XEP-0082</cite>.</td>
|
||||
<td>REQUIRED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><utc/></td>
|
||||
<td>The UTC time according to the responding entity. The format MUST conform to the dateTime profile specified in <cite>XEP-0082</cite> and MUST be expressed in UTC.</td>
|
||||
<td>REQUIRED</td>
|
||||
</tr>
|
||||
</table>
|
||||
</section1>
|
||||
<section1 topic='Examples' anchor='examples'>
|
||||
<example caption='Querying Another Entity for the Local Time'><![CDATA[
|
||||
<iq type='get'
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com/balcony'
|
||||
id='time_1'>
|
||||
<time xmlns='http://www.xmpp.org/extensions/xep-0202.html#ns'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='A Response to the Query'><![CDATA[
|
||||
<iq type='result'
|
||||
from='juliet@capulet.com/balcony'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='time_1'>
|
||||
<time xmlns='http://www.xmpp.org/extensions/xep-0202.html#ns'>
|
||||
<tzo>-06:00</tzo>
|
||||
<utc>2006-12-19T17:58:35Z</utc>
|
||||
</time>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The standard error conditions described in &xep0086; apply (e.g., &unavailable; if the entity does not support the namespace).</p>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<p>This protocol was designed in a way that makes migration from <cite>XEP-0090</cite> straightforward. This document specifies a different format for the XML character data of the <utc> element (compliant with <cite>XEP-0082</cite>) and specifies a new <tzo> element for the numeric offset from UTC, while removing the formerly optional and effectively useless <display/> and <tz/> elements.</p>
|
||||
<p>Implementations that support <cite>XEP-0090</cite> should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in <cite>XEP-0090</cite> for backwards compatibility until the status of that specification is changed to Obsolete.</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='registrar'>
|
||||
<p>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.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Protocol Namespace' anchor='ns'>
|
||||
<p>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;.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace='http://www.xmpp.org/extensions/xep-0202.html#ns'
|
||||
xmlns='http://www.xmpp.org/extensions/xep-0202.html#ns'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:element name='time'>
|
||||
<xs:complexType>
|
||||
<xs:sequence minOccurs='0'>
|
||||
<xs:element name='tzo' type='xs:string' maxOccurs='1'/>
|
||||
<xs:element name='utc' type='xs:string' maxOccurs='1'/>
|
||||
</xs:sequence>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</section1>
|
||||
</xep>
|
||||
154
xep-0203.xml
Normal file
154
xep-0203.xml
Normal file
@ -0,0 +1,154 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Delayed Delivery</title>
|
||||
<abstract>This document defines an XMPP protocol extension for communicating the fact that an XML stanza has been delivered with a delay.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0203</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<jig>Standards JIG</jig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0082</spec>
|
||||
</dependencies>
|
||||
<supersedes>
|
||||
<spec>XEP-0091</spec>
|
||||
</supersedes>
|
||||
<supersededby/>
|
||||
<shortname>Not yet assigned</shortname>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2006-12-20</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2006-12-19</date>
|
||||
<initials>psa</initials>
|
||||
<remark>First draft.</remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>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 <cite>XEP-0091</cite> which enables communication of delayed delivery information while adhering to <cite>XEP-0082</cite>.</p>
|
||||
</section1>
|
||||
<section1 topic='Protocol Definition' anchor='protocol'>
|
||||
<p>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:</p>
|
||||
<ul>
|
||||
<li>A message that is sent to an offline entity and stored for later delivery (see &xep0160;).</li>
|
||||
<li>The last available presence stanza sent by a connected client to a server.</li>
|
||||
<li>Messages cached by a &xep0045; room for delivery to new participants when they join the room.</li>
|
||||
</ul>
|
||||
<p>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:</p>
|
||||
<table caption='Defined Attributes'>
|
||||
<tr>
|
||||
<th>Element</th>
|
||||
<th>Definition</th>
|
||||
<th>Inclusion</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><from/></td>
|
||||
<td>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).</td>
|
||||
<td>RECOMMENDED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><stamp/></td>
|
||||
<td>The time when the XML stanza was originally sent. The format MUST adhere to the dateTime format specified in <cite>XEP-0082</cite> and MUST be expressed in UTC.</td>
|
||||
<td>REQUIRED</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>In addition, the <delay/> element MAY contain XML character data that provides a natural-language description of the reason for the delay.</p>
|
||||
</section1>
|
||||
<section1 topic='Examples' anchor='examples'>
|
||||
<example caption='Receiving a Message Sent While Offline'><![CDATA[
|
||||
<message
|
||||
from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com'
|
||||
type='chat'>
|
||||
<body>
|
||||
O blessed, blessed night! I am afeard.
|
||||
Being in night, all this is but a dream,
|
||||
Too flattering-sweet to be substantial.
|
||||
</body>
|
||||
<delay xmlns='http://www.xmpp.org/extensions/xep-0203.html#ns'
|
||||
from='capulet.com'
|
||||
stamp='2002-09-10T23:08:25Z'>
|
||||
Offline Storage
|
||||
</delay>
|
||||
</message>
|
||||
]]></example>
|
||||
<example caption='Receiving the Last Presence Update of Another Entity'><![CDATA[
|
||||
<presence from='juliet@capulet.com/balcony' to='romeo@montague.net'>
|
||||
<status>anon!</status>
|
||||
<show>xa</show>
|
||||
<priority>1</priority>
|
||||
<delay xmlns='http://www.xmpp.org/extensions/xep-0203.html#ns'
|
||||
from='juliet@capulet.com/balcony'
|
||||
stamp='20020910T23:41:07'/>
|
||||
</presence>
|
||||
]]></example>
|
||||
<example caption='Receiving Cached Messages from a Conference Room'><![CDATA[
|
||||
<message
|
||||
from='coven@macbeth.shakespeare.lit/secondwitch'
|
||||
to='macbeth@shakespeare.lit/laptop'
|
||||
type='groupchat'>
|
||||
<body>
|
||||
By the pricking of my thumbs,
|
||||
Something wicked this way comes.
|
||||
Open, locks,
|
||||
Whoever knocks!
|
||||
</body>
|
||||
<delay xmlns='http://www.xmpp.org/extensions/xep-0203.html#ns'
|
||||
from='coven@macbeth.shakespeare.lit'
|
||||
stamp='20020910T23:05:37'/>
|
||||
</message>
|
||||
]]></example>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<p>This protocol was designed in a way that makes migration from <cite>XEP-0091</cite> 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 <cite>XEP-0082</cite>).</p>
|
||||
<p>Implementations that support <cite>XEP-0091</cite> should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in <cite>XEP-0091</cite> for backwards compatibility until the status of that specification is changed to Obsolete.</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>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.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Protocol Namespace' anchor='ns'>
|
||||
<p>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;.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace='http://www.xmpp.org/extensions/xep-0203.html#ns'
|
||||
xmlns='http://www.xmpp.org/extensions/xep-0203.html#ns'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:element name='delay'>
|
||||
<xs:complexType>
|
||||
<xs:simpleContent>
|
||||
<xs:extension base='xs:string'>
|
||||
<xs:attribute name='from' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='stamp' type='xs:string' use='required'/>
|
||||
</xs:extension>
|
||||
</xs:simpleContent>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</section1>
|
||||
</xep>
|
||||
Loading…
Reference in New Issue
Block a user