From d87fe915aa72530440215e563a97bca885bf98d5 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 21 Apr 2009 21:56:55 +0000 Subject: [PATCH] 1.2rc2 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3071 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0163.xml | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/xep-0163.xml b/xep-0163.xml index 9bf9dc18..9eaab322 100644 --- a/xep-0163.xml +++ b/xep-0163.xml @@ -26,6 +26,12 @@ pep &stpeter; &ksmith; + + 1.2rc2 + in progress, last updated 2009-04-17 + psa +

Removed the one-node-per-namespace rule (community consensus that it is overly restrictive); clarified the meaning of auto-subscribe.

 + 1.1 2007-09-26 @@ -300,7 +306,6 @@
  1. Every account a pubsub service.
  2. One publisher per node.
    3. -
  3. One node per namespace.
  4. Use presence.
  5. Filter notifications based on expressed interest.
  6. Smart defaults.
    7. @@ -312,9 +317,6 @@

    There is no need for multiple publishers to a PEP service, since by definition the service generates information associated with only one entity. The owner-publisher for every node is the bare JID of the account owner.

     - -

    There is only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there is one pubsub node for geolocation events, one node for tune events, and one node for mood events). This simplifies node creation, discovery, publishing, and subscribing.

    -

    Although generic publish-subscribe services do not necessarily have access to presence information about subscribers, PEP services are integrated with presence in the following ways:

      @@ -366,7 +368,7 @@
    • The entity is the account owner itself, in which case the PEP service shall send notifications to all of the account owner's available resources (subject to notification filtering).
-

A PEP service MUST support the "auto-subscribe" feature defined in Section 9.1 of XEP-0060. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has a pubsub subscription account owner's root collection node (i.e., bare JID), with a subscription_type of "items" and a subscription_depth of "all".

+

A PEP service MUST support the "auto-subscribe" feature defined in Section 9.1 of XEP-0060. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has the right to subscribe to any of the account owner's PEP nodes (if the access model is the default of "presence") and to retrieve items from such PEP nodes.

A PEP service MUST support the "filtered-notifications" feature defined in Section 9.2 of XEP-0060. This implies that when an automatic subscriber can specify which event payloads it wants to receive by including appropriate feature bundles in the XEP-0115 information it broadcasts.

@@ -396,6 +398,7 @@

As mentioned, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber, including the account owner itself. (That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in XMPP IM.)

+

Note: The "on_sub_and_presence" setting relates to the subscriber's presence, not the publisher's presence.

If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of XEP-0060).

 + +

An earlier version of this document specified that there there could be only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there could be only one pubsub node for geolocation events, one node for tune events, and one node for mood events, etc.). However, this rule is now considered overly restrictive because some data formats can be used to encapsulate many different kinds of information; the canonical example is Atom as defined in &rfc4287;, for which many extensions exist.

+

A specification that defines a given payload format for use in PEP MUST specify whether there shall be only one node per namespace, or whether multiple NodeIDs for the same namespace are allowable.

+