moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

1.13rc8

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3647 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-11-18 23:25:13 +00:00
parent de7b438bff
commit 133df48a70
1 changed files with 45 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
xep-0060.xml
View File

@ -51,8 +51,8 @@
&ralphm;
<revision>
<version>1.13rc7</version>
<date>in progress, 2009-11-17</date>
<version>1.13rc8</version>
<date>in progress, 2009-11-18</date>
<initials>psa</initials>
<remark>
<ul>
@ -63,7 +63,7 @@
<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 &lt;item/&gt; element.</li>
<li>Added optional 'timestamp' attribute to &lt;item/&gt; element.</li>
<li>Added optional 'ver' attribute to &lt;item/&gt; and &lt;items/&gt; elements, along with associated pubsub#versioning configuration field.</li>
<li>Added optional &lt;redirect/&gt; child to &lt;delete/&gt; 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>
@ -2312,6 +2312,21 @@ 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>
@ -2709,25 +2724,25 @@ 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 Timestamp' anchor='publisher-publish-success-timestamp'>
<p>If configured to do so, the service can include the timestamp of the item when it generates notifications.</p>
<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'>
<items node='princely_musings'
ver='some-version-string'>
<item id='ae890ac52d0df67ed7cfdf51b644e901'
publisher='hamlet@denmark.lit'
timestamp='2003-12-13T18:30:09Z'>
publisher='hamlet@denmark.lit'>
[ ... ENTRY ... ]
</item>
</items>
</event>
</message>
]]></example>
<p>The value of the 'timestamp' attribute MUST conform to the dateTime format specified in XEP-0082, in UTC.</p>
<p>The value of the 'timestamp' attribute MUST be generated by the service, not accepted by the service in the published item.</p>
<p>The combination of the ItemID and item timestamp MUST be unique, such that a subsequent publish with the same ItemID MUST have a different (later) value of the 'timestamp' attribute than the earlier published item, even at the expense of literal accuracy (thus it is similar to the <cite>modtime</cite> attribute in ACAP &rfc2244;).</p>
<p>However, the 'timestamp' attribute does not provide accurate tracking of the exact chronology of the items published at a node, and a recipient cannot rely on this attribute for versioning, synchronization, or other similar purposes.</p>
<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>
@ -3276,6 +3291,7 @@ And by opposing end them?
<field var='pubsub#access_model'><value>open</value></field>
<field var='pubsub#publish_model'><value>publishers</value></field>
<field var='pubsub#purge_offline'><value>0</value></field>
<field var='pubsub#versioning'><value>0</value></field>
<field var='pubsub#send_last_published_item'><value>never</value></field>
<field var='pubsub#presence_based_delivery'><value>false</value></field>
<field var='pubsub#notification_type'><value>headline</value></field>
@ -3399,6 +3415,10 @@ And by opposing end them?
label='Purge all items when the relevant publisher goes offline?'>
<value>0</value>
</field>
<field var='pubsub#versioning' type='boolean'
label='Provide versioning information about published items'>
<value>0</value>
</field>
<field var='pubsub#max_payload_size' type='text-single'
label='Max Payload size in bytes'>
<value>1028</value>
@ -3540,6 +3560,7 @@ And by opposing end them?
</field>
<field var='pubsub#publish_model'><value>publishers</value></field>
<field var='pubsub#purge_offline'><value>0</value></field>
<field var='pubsub#versioning'><value>0</value></field>
<field var='pubsub#send_last_published_item'><value>never</value></field>
<field var='pubsub#presence_based_delivery'><value>false</value></field>
<field var='pubsub#notification_type'><value>headline</value></field>
@ -3626,6 +3647,7 @@ And by opposing end them?
<field var='pubsub#access_model'><value>open</value></field>
<field var='pubsub#publish_model'><value>publishers</value></field>
<field var='pubsub#purge_offline'><value>0</value></field>
<field var='pubsub#versioning'><value>0</value></field>
<field var='pubsub#max_payload_size'><value>9216</value></field>
<field var='pubsub#send_last_published_item'><value>never</value></field>
<field var='pubsub#presence_based_delivery'><value>0</value></field>
@ -3741,6 +3763,10 @@ And by opposing end them?
label='Purge all items when the relevant publisher goes offline?'>
<value>0</value>
</field>
<field var='pubsub#versioning' type='boolean'
label='Provide versioning information about published items'>
<value>0</value>
</field>
<field var='pubsub#max_payload_size' type='text-single'
label='Max payload size in bytes'>
<value>9216</value>
@ -6214,6 +6240,11 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<field var='pubsub#purge_offline'
type='boolean'
label='Whether to purge all items when the relevant publisher goes offline'/>
<field var='pubsub#versioning'
type='boolean'
label='Provide versioning information about published items'>
<value>0</value>
</field>
<field var='pubsub#roster_groups_allowed'
type='list-multi'
label='The roster group(s) allowed to subscribe and retrieve items'/>
@ -6795,6 +6826,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
<xs:element ref='retract' minOccurs='0' maxOccurs='unbounded'/>
</xs:choice>
<xs:attribute name='node' type='xs:string' use='required'/>
<xs:attribute name='ver' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
@ -6806,6 +6838,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
<xs:attribute name='id' type='xs:string' use='optional'/>
<xs:attribute name='node' type='xs:string' use='optional'/>
<xs:attribute name='publisher' type='xs:string' use='optional'/>
<xs:attribute name='ver' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>