moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

XEP-0366: Fix whitespace and DTD issues

Browse Source
This commit is contained in:
Sam Whited 2016-12-09 13:34:55 -06:00
parent ec594b803a
commit 8930133cb1
1 changed files with 55 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
xep-0366.xml
View File

@ -98,18 +98,24 @@
<section1 topic='Glossary' anchor='glossary'>
<dl>
<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,6 +214,7 @@
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:
</p>
<example caption="Service discovery information response"><![CDATA[
<iq from='shakespeare.lit'
id='ku6e51v3'
@ -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,6 +256,7 @@
</p>
<p>
For example, a versioned roster request might look like this:
</p>
<example caption="Roster Request"><![CDATA[
<!-- Client -->
<iq from='romeo@montague.lit/home' id='56' to='romeo@montague.lit' type='get'>
@ -271,15 +277,14 @@
<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:
</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'>
@ -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 &lt;version/&gt; element).
@ -338,6 +341,7 @@
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:
</p>
<example caption="Roster Request"><![CDATA[
<!-- Client -->
<iq from='romeo@montague.lit/home'
@ -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,6 +391,7 @@
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:
</p>
<example caption="Roster search"><![CDATA[
<!-- Client -->
<iq from='romeo@montague.lit/home'
@ -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:
</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
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>
</section1>
<section1 topic='Security Considerations' anchor='security'>
@ -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 &REGISTRAR; shall add the following definition to
the entity versioning profiles registry, as described in this document:
</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'>