From 8930133cb12cef58730b70ca2abac6523b19b6a7 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Fri, 9 Dec 2016 13:34:55 -0600 Subject: [PATCH] XEP-0366: Fix whitespace and DTD issues --- xep-0366.xml | 111 +++++++++++++++++++++++++-------------------------- 1 file changed, 55 insertions(+), 56 deletions(-) diff --git a/xep-0366.xml b/xep-0366.xml index c6e81dfd..91f1f1cf 100644 --- a/xep-0366.xml +++ b/xep-0366.xml @@ -98,18 +98,24 @@
-
Aggregate Token
-
- A hash which represents the state of a list of entities, and changes if - any of the entities change. -
-
Versioned Entity
-
Any object which may be versioned (eg. rooms, users).
-
Version Token
-
- A short, case sensitive string which represents an entity and changes if - that entity changes. -
+ +
Aggregate Token
+
+ A hash which represents the state of a list of entities, and changes if + any of the entities change. +
+ + +
Versioned Entity
+
Any object which may be versioned (eg. rooms, users).
+ + +
Version Token
+
+ A short, case sensitive string which represents an entity and changes if + that entity changes. +
+
@@ -196,7 +202,7 @@ - ]]> +]]>

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: - + - - ]]> -

+]]> @@ -251,7 +256,8 @@

For example, a versioned roster request might look like this: - + @@ -271,16 +277,15 @@ 9ZFZXVP9 - - ]]> -

+]]>

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: - + @@ -288,8 +293,7 @@ - ]]> -

+]]>

@@ -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: +

@@ -307,9 +312,7 @@ - - ]]> -

+]]>

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: - + 9ZFZXVP9 - - ]]> -

+]]>

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: - + 4YAZ7Y38 - - ]]> -

+]]>

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 @@

+]]>

Which results in the aggregate token:

+]]>

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 - ]]> +]]>

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: -

    -
  • - 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. -
    • -
  • Users whom the requester has contacted recently or frequently.
    • -
  • Users that should always be returned as part of server policy.
    • -

+
    +
  • + 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. +
    • +
  • Users whom the requester has contacted recently or frequently.
    • +
  • Users that should always be returned as part of server policy.
    • +
@@ -537,7 +538,7 @@ anne@shakespeare.lit:VIZSVF0D,bill@shakespeare.lit:25P2A7H8 -

This document requires no interaction with &IANA;.

+

This document requires no interaction with &IANA;.

 @@ -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 ). - - ]]> +]]>

This specification defines the following entity versioning profile:

@@ -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: - + Roster entity versioning Allows versioning of entities in an XMPP roster. RFC 6121 TODO: Insert this document once it is assigned a number - - ]]> -

+]]> -TODO +

TODO