mirror of https://github.com/moparisthebest/xeps
XEP-0366: Fix whitespace and DTD issues
This commit is contained in:
Sam Whited
parent
ec594b803a
commit
8930133cb1
111
xep-0366.xml
111
xep-0366.xml
|
|
@ -98,18 +98,24 @@
|
|||
|
||||
<section1 topic='Glossary' anchor='glossary'>
|
||||
<dl>
|
||||
<dt>Aggregate Token</dt>
|
||||
<dd>
|
||||
A hash which represents the state of a list of entities, and changes if
|
||||
any of the entities change.
|
||||
</dd>
|
||||
<dt>Versioned Entity</dt>
|
||||
<dd>Any object which may be versioned (eg. rooms, users).</dd>
|
||||
<dt>Version Token</dt>
|
||||
<dd>
|
||||
A short, case sensitive string which represents an entity and changes if
|
||||
that entity changes.
|
||||
</dd>
|
||||
<di>
|
||||
<dt>Aggregate Token</dt>
|
||||
<dd>
|
||||
A hash which represents the state of a list of entities, and changes if
|
||||
any of the entities change.
|
||||
</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Versioned Entity</dt>
|
||||
<dd>Any object which may be versioned (eg. rooms, users).</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Version Token</dt>
|
||||
<dd>
|
||||
A short, case sensitive string which represents an entity and changes if
|
||||
that entity changes.
|
||||
</dd>
|
||||
</di>
|
||||
</dl>
|
||||
</section1>
|
||||
|
||||
|
|
@ -196,7 +202,7 @@
|
|||
<profile xmlns='urn:xmpp:entityver:profile:roster:0'/>
|
||||
</ver>
|
||||
</stream:features>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>
|
||||
The entity versioning stream feature is merely informative and therefore
|
||||
is never mandatory-to-negotiate.
|
||||
|
|
@ -208,7 +214,8 @@
|
|||
the responding entity as described in the relavant specifications. Eg. a
|
||||
response from a server that supports roster versioning for the requesting
|
||||
entity might look like the following:
|
||||
<example caption="Service discovery information response"><![CDATA[
|
||||
</p>
|
||||
<example caption="Service discovery information response"><![CDATA[
|
||||
<iq from='shakespeare.lit'
|
||||
id='ku6e51v3'
|
||||
to='kingclaudius@shakespeare.lit/castle'
|
||||
|
|
@ -217,9 +224,7 @@
|
|||
<feature var='urn:xmpp:entityver:0'/>
|
||||
<feature var='urn:xmpp:entityver:profile:roster:0'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</p>
|
||||
</iq>]]></example>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Entity Sync' anchor='entity_sync'>
|
||||
|
|
@ -251,7 +256,8 @@
|
|||
</p>
|
||||
<p>
|
||||
For example, a versioned roster request might look like this:
|
||||
<example caption="Roster Request"><![CDATA[
|
||||
</p>
|
||||
<example caption="Roster Request"><![CDATA[
|
||||
<!-- Client -->
|
||||
<iq from='romeo@montague.lit/home' id='56' to='romeo@montague.lit' type='get'>
|
||||
<query xmlns='jabber:iq:roster'>
|
||||
|
|
@ -271,16 +277,15 @@
|
|||
<version xmlns='urn:xmpp:entityver:0'>9ZFZXVP9</version>
|
||||
</item>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</p>
|
||||
</iq>]]></example>
|
||||
<p>
|
||||
Note that in this case there may be three roster items total (and the
|
||||
client only knows about two of them), or there may be two total roster
|
||||
items and the server is informing the client about a change to
|
||||
"bill@shakespeare.lit". Version tokens MUST also be present in roster
|
||||
pushes:
|
||||
<example caption="Roster Push"><![CDATA[
|
||||
</p>
|
||||
<example caption="Roster Push"><![CDATA[
|
||||
<iq from='romeo@montague.lit' id='ah382g678jka7' to='romeo@montague.lit/home' type='set'>
|
||||
<query xmlns='jabber:iq:roster' ver='ver34'>
|
||||
<item jid='tybalt@shakespeare.lit' subscription='remove'>
|
||||
|
|
@ -288,8 +293,7 @@
|
|||
</item>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</p>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Cache Invalidation' anchor='deletes'>
|
||||
<p>
|
||||
|
|
@ -300,6 +304,7 @@
|
|||
the client receives such an empty version node it SHOULD purge the entity
|
||||
from its cache. For example, the following would remove the roster item
|
||||
'bill@shakespeare.lit' from the cache:
|
||||
</p>
|
||||
<example caption="Cache invalidation"><![CDATA[
|
||||
<iq from='romeo@montague.lit' id='56' to='romeo@montague.lit/home' type='result>
|
||||
<query xmlns='jabber:iq:roster'>
|
||||
|
|
@ -307,9 +312,7 @@
|
|||
<version xmlns='urn:xmpp:entityver:0'/>
|
||||
</item>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</p>
|
||||
</iq>]]></example>
|
||||
<p>
|
||||
Roster pushes that indicate a deleted item MUST also remove the version
|
||||
from the cache (and need not contain an empty <version/> element).
|
||||
|
|
@ -338,7 +341,8 @@
|
|||
no mechanism is specified, this is done by adding a boolean "full_list"
|
||||
attribute to the request, eg. a roster request for a partial list looks
|
||||
like:
|
||||
<example caption="Roster Request"><![CDATA[
|
||||
</p>
|
||||
<example caption="Roster Request"><![CDATA[
|
||||
<!-- Client -->
|
||||
<iq from='romeo@montague.lit/home'
|
||||
id='56'
|
||||
|
|
@ -361,9 +365,7 @@
|
|||
<version xmlns='urn:xmpp:entityver:0'>9ZFZXVP9</version>
|
||||
</item>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</p>
|
||||
</iq>]]></example>
|
||||
<p>
|
||||
When making a request for a partial list, clients do not need to send up
|
||||
every entity in their cache. Instead they MAY send up just those entities
|
||||
|
|
@ -389,7 +391,8 @@
|
|||
namespace and MUST have a 'profile' attribute set to the namespace for
|
||||
which the search is being performed. For instance, searching the roster
|
||||
looks like the following:
|
||||
<example caption="Roster search"><![CDATA[
|
||||
</p>
|
||||
<example caption="Roster search"><![CDATA[
|
||||
<!-- Client -->
|
||||
<iq from='romeo@montague.lit/home'
|
||||
id='564'
|
||||
|
|
@ -407,9 +410,7 @@
|
|||
<version xmlns='urn:xmpp:entityver:0'>4YAZ7Y38</version>
|
||||
</item>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</p>
|
||||
</iq>]]></example>
|
||||
<p>
|
||||
Search results SHOULD be added to the given list's cache. In this way,
|
||||
the full list does not need to be known.
|
||||
|
|
@ -436,13 +437,13 @@
|
|||
</p>
|
||||
<example caption="Aggregate token list"><![CDATA[
|
||||
anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>
|
||||
Which results in the aggregate token:
|
||||
</p>
|
||||
<example caption="Aggregate token"><![CDATA[
|
||||
0514fc90e6c7981b06bbb2173bb8ef03
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>
|
||||
The actual request is an IQ sent to the server, or entity handling the
|
||||
versioned list which contains a query that specifies the namespace of the
|
||||
|
|
@ -462,7 +463,7 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
|
|||
0514fc90e6c7981b06bbb2173bb8ef03
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
]]></example>
|
||||
<p>
|
||||
Because aggregate tokens are OPTIONAL to implement, clients MUST fall
|
||||
back to making a normal list request if any error is returned in response
|
||||
|
|
@ -514,17 +515,17 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
|
|||
lists in response to queries. For the case of rosters one or more of the
|
||||
following may be returned to the requesting entity during the initial
|
||||
roster sync:
|
||||
<ul>
|
||||
<li>
|
||||
Users that are grouped with the requester in some way. Eg. for a
|
||||
company with a large shared roster which places the requesting client
|
||||
in the "Marketing Department" group, the server may wish to return
|
||||
roster items that also share that group.
|
||||
</li>
|
||||
<li>Users whom the requester has contacted recently or frequently.</li>
|
||||
<li>Users that should always be returned as part of server policy.</li>
|
||||
</ul>
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
Users that are grouped with the requester in some way.
|
||||
Eg. for a company with a large shared roster which places the requesting
|
||||
client in the "Marketing Department" group, the server may wish to return
|
||||
roster items that also share that group.
|
||||
</li>
|
||||
<li>Users whom the requester has contacted recently or frequently.</li>
|
||||
<li>Users that should always be returned as part of server policy.</li>
|
||||
</ul>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
|
|
@ -537,7 +538,7 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
|
|||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
|
|
@ -579,8 +580,7 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
|
|||
The document in which the EV profile for the list is specified (may be the
|
||||
same as <listdev/>).
|
||||
</doc>
|
||||
</profile>
|
||||
]]></code>
|
||||
</profile>]]></code>
|
||||
</section2>
|
||||
<section2 topic='Entity Versioning Profiles' anchor='registrar-evprofile'>
|
||||
<p>This specification defines the following entity versioning profile:</p>
|
||||
|
|
@ -591,20 +591,19 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8
|
|||
Upon advancement of this specification from a status of Experimental to a
|
||||
status of Draft, the ®ISTRAR; shall add the following definition to
|
||||
the entity versioning profiles registry, as described in this document:
|
||||
<code><![CDATA[
|
||||
</p>
|
||||
<code><![CDATA[
|
||||
<profile>
|
||||
<name>Roster entity versioning</name>
|
||||
<desc>Allows versioning of entities in an XMPP roster.</desc>
|
||||
<listdef>RFC 6121</listdef>
|
||||
<doc>TODO: Insert this document once it is assigned a number</doc>
|
||||
</profile>
|
||||
]]></code>
|
||||
</p>
|
||||
</profile>]]></code>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
TODO
|
||||
<p>TODO</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
|
|
|
|||
Loading…
Reference in New Issue