From 8aa0f950db1e8036c8a0c4eab898cc8e0d7121c4 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 29 Sep 2009 23:04:40 +0000 Subject: [PATCH] removed batch publishing and retraction git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3470 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0060.xml | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/xep-0060.xml b/xep-0060.xml index 32dd9b67..3f0ecd87 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -73,6 +73,7 @@
  • Mentioned that singleton pattern can be enforced by setting max_items to 1.
  • Removed subids from subscription approval forms because subscribers can have only one unapproved subscription request per node at a given time.
  • Added optional support for delivery of notifications via XMPP IQ stanzas.
    • +
  • Removed the notion of batch publishing because it makes information coherence and atom handling excessively difficult.
    • @@ -2462,7 +2463,7 @@ And by opposing end them?

    The syntax is as follows:

    An example follows.

    @@ -2848,7 +2849,7 @@ And by opposing end them?

    A publisher might want to delete an item once it has been published to a node that supports persistent items. Support for this feature ("delete-items") is RECOMMENDED.

    -

    To delete an item, the publisher sends a retract request as shown in the following examples. The <retract/> element MUST possess a 'node' attribute, MAY possess a 'notify' attribute, and SHOULD contain one &ITEM; element (but MAY contain more than one &ITEM; element for Batch Processing of item retractions); the &ITEM; element MUST be empty and MUST possess an 'id' attribute.

    +

    To delete an item, the publisher sends a retract request as shown in the following examples. The <retract/> element MUST possess a 'node' attribute, MAY possess a 'notify' attribute, and MUST contain one &ITEM; element; the &ITEM; element MUST be empty and MUST possess an 'id' attribute.

     + +

    Implementations of pubsub MAY enable an entity to subscribe to a node temporarily, i.e., only for as long as the subscriber is online in its current presence session. To subscribe temporarily, the subscriber sets the "pubsub#expire" subscription configuration option to a value of "presence". The service will then automatically cancel the subscription when it receives presence of type "unavailable" from the subscriber.

    +     +

    Implementations of pubsub MAY deliver event notifications only when the subscriber is online. In these cases, the option may be a node configuration option as shown in the examples above. To facilitate this, the pubsub service needs to subscribe to the subscriber's presence and check the subscriber's current presence information before sending any event notifications (as described in RFC 3921). Presence subscriptions MUST be based on the subscribed JID.

    - -

    If the pubsub service supports presence-based delivery and a node is configured to enable such delivery, the service MAY offer a value of "iq" for the "pubsub#notification_type" node configuration option. If this value is chosen, the service shall deliver notifications in XMPP IQ stanzas instead of in XMPP message stanzas. Because IQ stanzas are addressed to full JIDs &LOCALFULL;, if the service does not know the full JID of a given subscriber then it MAY send notifications to the bare JID &LOCALBARE; of the subscriber via the usual message stanza, or MAY not send a notification at all. The IQ stanza containing a notification shall be of type "set", and in accordance with the semantics of the IQ stanza defined in RFC 3920 the recipient MUST return either an IQ stanza of type "result" or an IQ stanza of type "error". An example follows

    - + + +

    If the pubsub service supports presence-based delivery and a node is configured to enable such delivery, the service MAY offer a value of "iq" for the "pubsub#notification_type" node configuration option. If this value is chosen, the service shall deliver notifications in XMPP IQ stanzas instead of in XMPP message stanzas. Because IQ stanzas are addressed to full JIDs &LOCALFULL;, if the service does not know the full JID of a given subscriber then it MAY send notifications to the bare JID &LOCALBARE; of the subscriber via the usual message stanza, or MAY not send a notification at all. The IQ stanza containing a notification shall be of type "set", and in accordance with the semantics of the IQ stanza defined in RFC 3920 the recipient MUST return either an IQ stanza of type "result" or an IQ stanza of type "error". An example follows

    + - ]]> - + - ]]> -     + ]]>     @@ -5069,17 +5075,9 @@ And by opposing end them?

    A service MAY cache the last item published to a node, even if the node is configured for transient publication (i.e., configured to not persist items). The last published item SHOULD be sent to new subscribers upon successful processing of a subscription request or approval by a node owner.

    -

    Note: If a publisher requests Batch Processing of item publications, the concept of "last published item" is undefined; therefore, if information coherence is needed, a publisher SHOULD publish items in separate requests rather than in batch mode.

    Note: Particular profiles of the generic publish-subscribe protocol MAY define more stringent requirements regarding the "cache-last-item" feature.

     - -

    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.

    -

    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.

    -

    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 ¬allowed; error, which SHOULD also include a pubsub-specific error condition of <max-items-exceeded/>.

    -

    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.

    -     -

    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 Notification of Subscription State Changes section of this document.