mirror of https://github.com/moparisthebest/xeps
1.13pre10
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3674 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
2465f60519
commit
befc3e86de
148
xep-0060.xml
148
xep-0060.xml
|
|
@ -51,8 +51,8 @@
|
|||
&ralphm;
|
||||
|
||||
<revision>
|
||||
<version>1.13rc8</version>
|
||||
<date>in progress, 2009-11-18</date>
|
||||
<version>1.13rc10</version>
|
||||
<date>in progress, 2009-12-02</date>
|
||||
<initials>psa</initials>
|
||||
<remark>
|
||||
<ul>
|
||||
|
|
@ -63,7 +63,6 @@
|
|||
<li>Removed multiple node discovery since it depended on the deprecated Service Discovery Publishing feature.</li>
|
||||
<li>Defined "room" value for itemreply config option.</li>
|
||||
<li>Added optional 'publisher' attribute to <item/> element.</li>
|
||||
<li>Added optional 'ver' attribute to <item/> and <items/> elements, along with associated pubsub#versioning configuration field.</li>
|
||||
<li>Added optional <redirect/> child to <delete/> element.</li>
|
||||
<li>Clarified meaning of filtered notifications (they are based on NodeIDs, not payload namespaces).</li>
|
||||
<li>Added pubsub-on-a-jid service discovery feature for explicit discovery that an IM and presence account also functions as a virtual pubsub service.</li>
|
||||
|
|
@ -78,6 +77,7 @@
|
|||
<li>Removed the notion of batch publishing because it makes information coherence and atom handling excessively difficult.</li>
|
||||
<li>Added error handling for too-many-subscriptions to help prevent a certain denial of service attack.</li>
|
||||
<li>Added process for retrieving default subscription configuration options for leaf nodes, by omitting the 'node' attribute on the <default/> element (also added the <default/> element to the schema for the http://jabber.org/protocol/pubsub namespace, since it was missing).</li>
|
||||
<li>Added optional data versioning via the 'ver' attribute on the <item/> and <items/> elements, along with associated pubsub#versioning configuration field.</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
|
|
@ -2312,21 +2312,6 @@ And by opposing end them?
|
|||
]]></example>
|
||||
<p>The service would then return that specific item, if available.</p>
|
||||
</section3>
|
||||
<section3 topic='Requesting All Items Since a Given Version' anchor='subscriber-retrieve-since'>
|
||||
<p>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 <link url='#publisher-publish-success-ver'>Item Versioning</link>).</p>
|
||||
<example caption='Subscriber requests items since a given version'><![CDATA[
|
||||
<iq type='get'
|
||||
from='francisco@denmark.lit/barracks'
|
||||
to='pubsub.shakespeare.lit'
|
||||
id='items3'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='princely_musings'
|
||||
ver='some-version-string'/>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The service would then return all the items published since that version of the data published at the node.</p>
|
||||
</section3>
|
||||
<section3 topic='Error Cases' anchor='subscriber-retrieve-error'>
|
||||
<p>There are several reasons why the items retrieval request might fail:</p>
|
||||
<ol>
|
||||
|
|
@ -2724,26 +2709,6 @@ And by opposing end them?
|
|||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</section4>
|
||||
<section4 topic='Item Versioning' anchor='publisher-publish-success-ver'>
|
||||
<p>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.</p>
|
||||
<example caption='Service Notifies Subscribers'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='princely_musings'
|
||||
ver='some-version-string'>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901'
|
||||
publisher='hamlet@denmark.lit'>
|
||||
[ ... ENTRY ... ]
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
<p class='def'><strong>Definition:</strong> The <strong>'ver' attribute</strong> 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.</p>
|
||||
<p>Note: The value of the 'ver' attribute is conceptually equivalent to the 'ver' attribute from &xep0237;.</p>
|
||||
<p>The value of the 'ver' attribute MUST be generated by the service, not accepted by the service in the published item.</p>
|
||||
<p>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.</p>
|
||||
</section4>
|
||||
<section4 topic='Inclusion of Subscription ID' anchor='publisher-publish-success-subid'>
|
||||
<p>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).</p>
|
||||
<example caption='Subscriber receives notated event notification'><![CDATA[
|
||||
|
|
@ -4791,6 +4756,105 @@ And by opposing end them?
|
|||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Data Versioning' anchor='versioning'>
|
||||
<p>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.</p>
|
||||
<p class='def'><strong>Definition:</strong> The <strong>'ver' attribute</strong> 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.</p>
|
||||
<p>Note: The value of the 'ver' attribute is conceptually equivalent to the 'ver' attribute from &xep0237;.</p>
|
||||
<p>If a service supports data versioning, it MUST advertise a feature of "http://jabber.org/protocol/pubsub#versioning".</p>
|
||||
<section2 topic='Versioning of All Items' anchor='versioning-items'>
|
||||
<p>The service can include the version of the collective items when it generates notifications.</p>
|
||||
<example caption='Notification with Version of All Items'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='princely_musings'
|
||||
ver='v103'>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901'
|
||||
publisher='hamlet@denmark.lit'>
|
||||
[ ... ENTRY ... ]
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>If any items are subsequently published to or deleted from the node (thus overwriting the old version), the service would change the version.</p>
|
||||
<example caption='Subsequent Notification with Item Version'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='bar'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='princely_musings'
|
||||
ver='v110'>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901'
|
||||
publisher='hamlet@denmark.lit'>
|
||||
[ ... ENTRY ... ]
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Versioning of a Particular Item' anchor='versioning-item'>
|
||||
<p>The service can include the version of a particular item when it generates notifications.</p>
|
||||
<example caption='Notification with Item Version'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='princely_musings'>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901'
|
||||
publisher='hamlet@denmark.lit'
|
||||
ver='v50'>
|
||||
[ ... ENTRY ... ]
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>If an item with the same ItemID is subsequently published to the node (thus overwriting the old version), the service would change the version.</p>
|
||||
<example caption='Subsequent Notification with Item Version'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='bar'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='princely_musings'>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901'
|
||||
publisher='hamlet@denmark.lit'
|
||||
ver='v59'>
|
||||
[ ... ENTRY ... ]
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Versioning on Publish or Delete' anchor='versioning-publish'>
|
||||
<p>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.</p>
|
||||
<example caption='Success with version'><![CDATA[
|
||||
<iq type='result'
|
||||
from='pubsub.shakespeare.lit'
|
||||
to='hamlet@denmark.lit/blogbot'
|
||||
id='publish1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='princely_musings'
|
||||
ver='v110'>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901'
|
||||
ver='v59'/>
|
||||
</publish>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Retrieving All Items Since a Given Version' anchor='versioning-retrieve'>
|
||||
<p>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.</p>
|
||||
<example caption='Subscriber Requests Items Since a Given Version'><![CDATA[
|
||||
<iq type='get'
|
||||
from='francisco@denmark.lit/barracks'
|
||||
to='pubsub.shakespeare.lit'
|
||||
id='items3'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='princely_musings'
|
||||
ver='v103'/>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>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.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Feature Summary' anchor='features'>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
|
|
@ -5059,6 +5123,12 @@ And by opposing end them?
|
|||
<td>OPTIONAL</td>
|
||||
<td><link url='#impl-subchange'>Notification of Subscription State Changes</link></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>versioning</td>
|
||||
<td>Data versioning is supported.</td>
|
||||
<td>OPTIONAL</td>
|
||||
<td><link url='#versioning'>Data Versioning</link></td>
|
||||
</tr>
|
||||
</table>
|
||||
</section1>
|
||||
|
||||
|
|
@ -7043,7 +7113,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
|
|||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>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.</p>
|
||||
<p>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.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Author Note' anchor='authornote'>
|
||||
|
|
|
|||
Loading…
Reference in New Issue