1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@4256 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2010-06-21 20:10:07 +00:00
parent 5c2c15b7cc
commit d47e3746f9

View File

@ -51,11 +51,12 @@
&ralphm;
<revision>
<version>1.13rc17</version>
<date>in progress, last updated 2010-04-13</date>
<version>1.13rc18</version>
<date>in progress, last updated 2010-06-21</date>
<initials>psa</initials>
<remark>
<ul>
<li>Pending further discussion: added but then removed change to allow notifications via IQ stanzas; removed but then retained batch publishing; removed but then retained SubIDs in subscription approvals.</li>
<li>Corrected a large number of reported errata.</li>
<li>Removed delete-any feature.</li>
<li>Added missing delete-items feature.</li>
@ -74,7 +75,6 @@
<li>Added retrieve-default-sub feature for retrieving default subscription configuration from a node (as you can retrieve default node configuration from the service).</li>
<li>Clarified suggested rules for payload definitions.</li>
<li>Mentioned that singleton pattern can be enforced by setting max_items to 1.</li>
<li>Removed subids from subscription approval forms because subscribers can have only one unapproved subscription request per node at a given time.</li>
<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 &lt;default/&gt; element (also added the &lt;default/&gt; element to the schema for the http://jabber.org/protocol/pubsub namespace, since it was missing).</li>
@ -3789,7 +3789,9 @@ And by opposing end them?
to='pubsub.shakespeare.lit'
id='delete1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
<delete node='princely_musings'/>
<delete node='princely_musings>
<redirect uri='xmpp:hamlet@denmark.lit?;node=blog'/>
</delete>
</pubsub>
</iq>
]]></example>
@ -3986,6 +3988,7 @@ And by opposing end them?
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#subscribe_authorization</value>
</field>
<field var='pubsub#subid' type='hidden'><value>123-abc</value></field>
<field var='pubsub#node' type='text-single' label='Node ID'>
<value>princely_musings</value>
</field>
@ -4006,6 +4009,9 @@ And by opposing end them?
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#subscribe_authorization</value>
</field>
<field var='pubsub#subid'>
<value>123-abc</value>
</field>
<field var='pubsub#node'>
<value>princely_musings</value>
</field>
@ -4036,6 +4042,9 @@ And by opposing end them?
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#subscribe_authorization</value>
</field>
<field var='pubsub#subid'>
<value>123-abc</value>
</field>
<field var='pubsub#node'>
<value>princely_musings</value>
</field>
@ -5262,6 +5271,13 @@ And by opposing end them?
<p>Note: Particular profiles of the generic publish-subscribe protocol MAY define more stringent requirements regarding the "cache-last-item" feature.</p>
</section2>
<section2 topic='Batch Processing' anchor='impl-batch'>
<p>A publisher MAY include multiple &ITEM; elements in a publish request and MAY include multiple &ITEM; elements in a retract request. This results in "batch processing" of publications or retractions.</p>
<p>If the service cannot process any one of the items to be published or retracted, the entire batch MUST fail and the service MUST NOT publish or retract any of the items.</p>
<p>If a batch publish contains so many items that publication of all the items would exceed the maximum number of items for the node, the service MUST return a &notallowed; error, which SHOULD also include a pubsub-specific error condition of &lt;max-items-exceeded/&gt;.</p>
<p>Note: Batch publication renders the concept of "last published item" problematic; therefore, if information coherence is needed, a publisher SHOULD publish items in separate requests rather than in batch mode.</p>
</section2>
<section2 topic='Auto-Subscribing Owners and Publishers' anchor='impl-autosubscribe'>
<p>A service MUST allow owners and publishers to subscribe to a node, and to retrieve items from a node even if they are not subscribed. A service MAY auto-subscribe owners and publishers if they are not already subscribed, in which case it SHOULD generate a subscription ID if necessary for the subscription and SHOULD send a notification of successful subscription as described in the <link url='#impl-subchange'>Notification of Subscription State Changes</link> section of this document.</p>
</section2>