The service would then return that specific item, if available.
-The subscriber can request all items published since a particular version of the published data by specifying the Node ID and 'ver' attribute (about which see Item Versioning).
-The service would then return all the items published since that version of the data published at the node.
-There are several reasons why the items retrieval request might fail:
The value of the 'publisher' attribute MUST be generated by the service, not accepted by the service in the published item, since allowing the publisher to assert its JID would open the possibility of spoofing.
The JID stamped by the service can be either (1) the full JID &LOCALFULL; of the publisher as taken the 'from' attribute of the IQ-set used to publish the item or (2) the bare JID &LOCALBARE; of the publisher as derived from a formal affiliation in the explicit list of whitelisted publishers.
-If configured to do so (via the "pubsub#versioning" configuration field), the service can include the "version" of the published data when it generates notifications.
-Definition: The 'ver' attribute is a string that identifies a particular version of the data published at a node. The value MUST be generated only by the server and MUST be treated by the client as opaque. The server can use any appropriate method for generating the version ID, such as a hash of the published data (e.g., of all the current items cached at the node) or a strictly-increasing sequence number.
-Note: The value of the 'ver' attribute is conceptually equivalent to the 'ver' attribute from &xep0237;.
-The value of the 'ver' attribute MUST be generated by the service, not accepted by the service in the published item.
-The combination of the ItemID and 'ver' MUST be unique, such that a subsequent publish with the same ItemID MUST have a different value of the 'ver' attribute than the earlier published item.
-If a single entity is subscribed to a node multiple times, the service SHOULD notate the event notification so that the entity can determine which subscription identifier(s) generated this event. If these notations are included, they MUST use the &xep0131; format and SHOULD be included after the event notification information (i.e., as the last child of the &MESSAGE; stanza).
A service MAY track the "version" of data published at a node, in the form of the version across all published items, the version of each particular item, or both. The version is tracked using the 'ver' attribute, which can be included on the <items/> element or the <item/> element.
+Definition: The 'ver' attribute is a string that identifies a particular version of the items published at a node or of a particular item. The value MUST be generated only by the server, MUST NOT be accepted by the service from the publisher, and MUST be treated by the client as opaque. The server can use any appropriate method for generating the version ID, such as a hash of the published data or a strictly-increasing sequence number.
+Note: The value of the 'ver' attribute is conceptually equivalent to the 'ver' attribute from &xep0237;.
+If a service supports data versioning, it MUST advertise a feature of "http://jabber.org/protocol/pubsub#versioning".
+The service can include the version of the collective items when it generates notifications.
+If any items are subsequently published to or deleted from the node (thus overwriting the old version), the service would change the version.
+The service can include the version of a particular item when it generates notifications.
+If an item with the same ItemID is subsequently published to the node (thus overwriting the old version), the service would change the version.
+If the service supports data versioning, it MUST inform the publisher of the latest version when returning an IQ-result after a publishing request or item deletion is processed.
+If the service supports data versioning, the subscriber can request all items published since a particular version of the published data by specifying both the Node ID and 'ver' attribute on the <items/> element.
+The service would then return all the items published since that version of the data published at the node, as well as notice of any item deletions (if configured to send notifications on delete). If no items have been published or deleted, the service would return an empty IQ-result.
+This section summarizes the features described herein, specifies the appropriate requirements level for each feature (REQUIRED, RECOMMENDED, or OPTIONAL), and provides cross-references to the section of this document in which each feature is described.
Note: The feature names are all of the form "http://jabber.org/protocol/pubsub#name", where "name" is the text specified in the first column below.
@@ -5059,6 +5123,12 @@ And by opposing end them?Thanks to Blaine Cook, Brian Cully, Dave Cridland, Gaston Dombiak, Seth Fitzsimmons, Anastasia Gornostaeva, Joe Hildebrand, Dirk Meyer, Tory Patnoe, Christophe Romain, Kevin Smith, Chris Teegarden, Matt Tucker, Bob Wyman, and Brett Zamir for their feedback.
+Thanks to Kirk Bateman, Robin Collier, Blaine Cook, Ovidiu Craciun, Brian Cully, Dave Cridland, Guillaume Desmottes, Gaston Dombiak, William Edney, Seth Fitzsimmons, Fabio Forno, Nathan Fritz, Julien Genestoux, Anastasia Gornostaeva, Joe Hildebrand, Curtis King, Tuomas Koski, Petri Liimatta, Tobias Markmann, Pedro Melo, Dirk Meyer, Tory Patnoe, Peter Petrov, Christophe Romain, Pavel Šimerda, Andy Skelton, Kevin Smith, Chris Teegarden, Simon Tennant, Matt Tucker, Matthew Wild, Bob Wyman, Matus Zamborsky, and Brett Zamir for their feedback.