From 84449eb4de04b1012cda0e874810e91e8bae7cab Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 15 May 2009 04:36:12 +0000 Subject: [PATCH] text and example corrections git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3142 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0237.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0237.xml b/xep-0237.xml index 6f217caf..da582efa 100644 --- a/xep-0237.xml +++ b/xep-0237.xml @@ -211,7 +211,7 @@ S: [ reconnection ] C: - + S: @@ -267,7 +267,7 @@ S: Implementors are advised that a pure timestamp is not suitable for this approach, since under some circumstances system clocks can go backwards (e.g., because of an adjustment based on an update triggered by use of the Network Time Protocol as described in &rfc0958;).

-

There are two primary approaches to server-side generation of the 'ver' attribute: complete roster hashes and strictly increasing sequence numbers. Whether the server will send roster pushes varies depending on the approach taken. For instance, if a series of roster modifications result in a roster item that does not differ from the version cached by the client (e.g., a modification to the item's 'name' attribute and then a modification back to the original value), then a server that implements the "complete roster hashes" approach would consider the item to have been modified for purposes of roster versioning and therefore would push the item to the client in an interim roster push; however, a server that implements the "strictly increasing sequence numbers" approach would send a roster push in this situtation.

+

There are two primary approaches to server-side generation of the 'ver' attribute: complete roster hashes and strictly increasing sequence numbers. Whether the server will send roster pushes varies depending on the approach taken. For instance, if a series of roster modifications result in a roster item that does not differ from the version cached by the client (e.g., a modification to the item's 'name' attribute and then a modification back to the original value), then a server that implements the "complete roster hashes" approach would not consider the item to have been modified for purposes of roster versioning and therefore would not push the item to the client in an interim roster push; however, a server that implements the "strictly increasing sequence numbers" approach would send a roster push in this situtation.

Client implementors are reminded that the value of the 'ver' attribute is entirely opaque, and they should behave identically with each strategy described above by simply conforming to the specification. The only storage requirement for this specification is the last seen 'ver' attribute.