1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00

XEP-0366: Fix whitespace and DTD issues

This commit is contained in:
Sam Whited 2016-12-09 13:34:55 -06:00
parent ec594b803a
commit 8930133cb1

View File

@ -98,18 +98,24 @@
<section1 topic='Glossary' anchor='glossary'> <section1 topic='Glossary' anchor='glossary'>
<dl> <dl>
<di>
<dt>Aggregate Token</dt> <dt>Aggregate Token</dt>
<dd> <dd>
A hash which represents the state of a list of entities, and changes if A hash which represents the state of a list of entities, and changes if
any of the entities change. any of the entities change.
</dd> </dd>
</di>
<di>
<dt>Versioned Entity</dt> <dt>Versioned Entity</dt>
<dd>Any object which may be versioned (eg. rooms, users).</dd> <dd>Any object which may be versioned (eg. rooms, users).</dd>
</di>
<di>
<dt>Version Token</dt> <dt>Version Token</dt>
<dd> <dd>
A short, case sensitive string which represents an entity and changes if A short, case sensitive string which represents an entity and changes if
that entity changes. that entity changes.
</dd> </dd>
</di>
</dl> </dl>
</section1> </section1>
@ -208,6 +214,7 @@
the responding entity as described in the relavant specifications. Eg. a the responding entity as described in the relavant specifications. Eg. a
response from a server that supports roster versioning for the requesting response from a server that supports roster versioning for the requesting
entity might look like the following: entity might look like the following:
</p>
<example caption="Service discovery information response"><![CDATA[ <example caption="Service discovery information response"><![CDATA[
<iq from='shakespeare.lit' <iq from='shakespeare.lit'
id='ku6e51v3' id='ku6e51v3'
@ -217,9 +224,7 @@
<feature var='urn:xmpp:entityver:0'/> <feature var='urn:xmpp:entityver:0'/>
<feature var='urn:xmpp:entityver:profile:roster:0'/> <feature var='urn:xmpp:entityver:profile:roster:0'/>
</query> </query>
</iq> </iq>]]></example>
]]></example>
</p>
</section1> </section1>
<section1 topic='Entity Sync' anchor='entity_sync'> <section1 topic='Entity Sync' anchor='entity_sync'>
@ -251,6 +256,7 @@
</p> </p>
<p> <p>
For example, a versioned roster request might look like this: For example, a versioned roster request might look like this:
</p>
<example caption="Roster Request"><![CDATA[ <example caption="Roster Request"><![CDATA[
<!-- Client --> <!-- Client -->
<iq from='romeo@montague.lit/home' id='56' to='romeo@montague.lit' type='get'> <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> <version xmlns='urn:xmpp:entityver:0'>9ZFZXVP9</version>
</item> </item>
</query> </query>
</iq> </iq>]]></example>
]]></example>
</p>
<p> <p>
Note that in this case there may be three roster items total (and the 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 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 items and the server is informing the client about a change to
"bill@shakespeare.lit". Version tokens MUST also be present in roster "bill@shakespeare.lit". Version tokens MUST also be present in roster
pushes: pushes:
</p>
<example caption="Roster Push"><![CDATA[ <example caption="Roster Push"><![CDATA[
<iq from='romeo@montague.lit' id='ah382g678jka7' to='romeo@montague.lit/home' type='set'> <iq from='romeo@montague.lit' id='ah382g678jka7' to='romeo@montague.lit/home' type='set'>
<query xmlns='jabber:iq:roster' ver='ver34'> <query xmlns='jabber:iq:roster' ver='ver34'>
@ -289,7 +294,6 @@
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</p>
</section2> </section2>
<section2 topic='Cache Invalidation' anchor='deletes'> <section2 topic='Cache Invalidation' anchor='deletes'>
<p> <p>
@ -300,6 +304,7 @@
the client receives such an empty version node it SHOULD purge the entity 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 from its cache. For example, the following would remove the roster item
'bill@shakespeare.lit' from the cache: 'bill@shakespeare.lit' from the cache:
</p>
<example caption="Cache invalidation"><![CDATA[ <example caption="Cache invalidation"><![CDATA[
<iq from='romeo@montague.lit' id='56' to='romeo@montague.lit/home' type='result> <iq from='romeo@montague.lit' id='56' to='romeo@montague.lit/home' type='result>
<query xmlns='jabber:iq:roster'> <query xmlns='jabber:iq:roster'>
@ -307,9 +312,7 @@
<version xmlns='urn:xmpp:entityver:0'/> <version xmlns='urn:xmpp:entityver:0'/>
</item> </item>
</query> </query>
</iq> </iq>]]></example>
]]></example>
</p>
<p> <p>
Roster pushes that indicate a deleted item MUST also remove the version 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). 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" 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 attribute to the request, eg. a roster request for a partial list looks
like: like:
</p>
<example caption="Roster Request"><![CDATA[ <example caption="Roster Request"><![CDATA[
<!-- Client --> <!-- Client -->
<iq from='romeo@montague.lit/home' <iq from='romeo@montague.lit/home'
@ -361,9 +365,7 @@
<version xmlns='urn:xmpp:entityver:0'>9ZFZXVP9</version> <version xmlns='urn:xmpp:entityver:0'>9ZFZXVP9</version>
</item> </item>
</query> </query>
</iq> </iq>]]></example>
]]></example>
</p>
<p> <p>
When making a request for a partial list, clients do not need to send up 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 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 namespace and MUST have a 'profile' attribute set to the namespace for
which the search is being performed. For instance, searching the roster which the search is being performed. For instance, searching the roster
looks like the following: looks like the following:
</p>
<example caption="Roster search"><![CDATA[ <example caption="Roster search"><![CDATA[
<!-- Client --> <!-- Client -->
<iq from='romeo@montague.lit/home' <iq from='romeo@montague.lit/home'
@ -407,9 +410,7 @@
<version xmlns='urn:xmpp:entityver:0'>4YAZ7Y38</version> <version xmlns='urn:xmpp:entityver:0'>4YAZ7Y38</version>
</item> </item>
</query> </query>
</iq> </iq>]]></example>
]]></example>
</p>
<p> <p>
Search results SHOULD be added to the given list's cache. In this way, Search results SHOULD be added to the given list's cache. In this way,
the full list does not need to be known. the full list does not need to be known.
@ -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 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 following may be returned to the requesting entity during the initial
roster sync: roster sync:
</p>
<ul> <ul>
<li> <li>
Users that are grouped with the requester in some way. Eg. for a Users that are grouped with the requester in some way.
company with a large shared roster which places the requesting client Eg. for a company with a large shared roster which places the requesting
in the "Marketing Department" group, the server may wish to return client in the "Marketing Department" group, the server may wish to return
roster items that also share that group. roster items that also share that group.
</li> </li>
<li>Users whom the requester has contacted recently or frequently.</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> <li>Users that should always be returned as part of server policy.</li>
</ul> </ul>
</p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <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 The document in which the EV profile for the list is specified (may be the
same as <listdev/>). same as <listdev/>).
</doc> </doc>
</profile> </profile>]]></code>
]]></code>
</section2> </section2>
<section2 topic='Entity Versioning Profiles' anchor='registrar-evprofile'> <section2 topic='Entity Versioning Profiles' anchor='registrar-evprofile'>
<p>This specification defines the following entity versioning profile:</p> <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 Upon advancement of this specification from a status of Experimental to a
status of Draft, the &REGISTRAR; shall add the following definition to status of Draft, the &REGISTRAR; shall add the following definition to
the entity versioning profiles registry, as described in this document: the entity versioning profiles registry, as described in this document:
</p>
<code><![CDATA[ <code><![CDATA[
<profile> <profile>
<name>Roster entity versioning</name> <name>Roster entity versioning</name>
<desc>Allows versioning of entities in an XMPP roster.</desc> <desc>Allows versioning of entities in an XMPP roster.</desc>
<listdef>RFC 6121</listdef> <listdef>RFC 6121</listdef>
<doc>TODO: Insert this document once it is assigned a number</doc> <doc>TODO: Insert this document once it is assigned a number</doc>
</profile> </profile>]]></code>
]]></code>
</p>
</section2> </section2>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
TODO <p>TODO</p>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>