From 5fa0cfc3427319566f04cddc35fcba941c8b13e3 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 31 Mar 2010 04:06:42 +0000 Subject: [PATCH] 1.13rc14 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@4114 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0060.xml | 43 ++++++++++--------------------------------- 1 file changed, 10 insertions(+), 33 deletions(-) diff --git a/xep-0060.xml b/xep-0060.xml index 7919e8ef..b2dd233d 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -51,8 +51,8 @@ &ralphm; - 1.13rc13 - in progress, 2009-12-07 + 1.13rc14 + in progress, 2010-03-30 psa
    @@ -65,6 +65,7 @@
  • Defined "room" value for itemreply config option.
  • Added optional 'publisher' attribute to <item/> element.
  • Added optional <redirect/> child to <delete/> element.
  • +
  • Based redirects on URIs for consistency with rfc3920bis gone and redirect errors.
  • Clarified meaning of filtered notifications (they are based on NodeIDs, not payload namespaces).
  • Added pubsub-on-a-jid service discovery feature for explicit discovery that an IM and presence account also functions as a virtual pubsub service.
  • Added purge_offline node configuration option for purging the node when the relevant publisher goes offline, for use in certain extended presence applications.
  • @@ -74,7 +75,6 @@
  • Clarified suggested rules for payload definitions.
  • 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.
  • Added error handling for too-many-subscriptions to help prevent a certain denial of service attack.
  • 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).
  • @@ -3810,7 +3810,7 @@ And by opposing end them? id='delete1'> - + @@ -3827,13 +3827,17 @@ And by opposing end them? - + + + - + + + ]]> @@ -5233,30 +5237,6 @@ And by opposing end them?

    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 SHOULD NOT send an event notification at all (just as it would not for presence-based delivery via &MESSAGE; stanzas). The IQ stanza containing an event 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.

    - - - - - [ ... ENTRY ... ] - - - - - ]]> - - ]]> -
    -

    Sending events to users of existing Jabber servers may force event notifications to be routed to offline storage for later delivery (as described in &xep0160;). This may not always be desirable. The possible ways of preventing this behavior include:

      @@ -6257,9 +6237,6 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae -