%ents; ]>
Publish-Subscribe This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can serve as the foundation for a wide variety of applications, including news feeds, content syndication, rich presence, geolocation, workflow systems, network management systems, and any other application that requires event notifications. &LEGALNOTICE; 0060 Draft Standards Track Standards XMPP Core XEP-0004 XEP-0030 XEP-0059 XEP-0068 XEP-0082 XEP-0131 pubsub pubsub http://xmpp.org/schemas/pubsub.xsd pubsub#errors http://xmpp.org/schemas/pubsub-errors.xsd pubsub#event http://xmpp.org/schemas/pubsub-event.xsd pubsub#owner http://xmpp.org/schemas/pubsub-owner.xsd pubsub &pgmillard; &stpeter; &ralphm; 1.15.0 2017-12-12 dg
  • Specify that unregistered publish-options are mapped 1:1 to node configurations
  • Get rid of per-item OVERRIDE
  • Get rid of METADATA publish-options
  • Remove registration for the obsolete pubsub#access_model publish-options
1.14 2017-11-29 jt

Add pubsub#multi-items to features.

1.13.8 2017-10-10 fs (XEP Editor: jwi)

Add missing dependency on XEP-0059.

1.13.7 2017-08-24 egp

Fix examples using invalid XEP-0082 dates.

1.13.6 2017-06-22 dg

Clarify behaviour of publish-options. Fields must be registered

1.13.5 2016-12-21 psa (XEP Editor: ssw)

Add missing options to schema.

1.13.4 2016-12-02 psa

Make Multiple Simultaneous Modifications examples consistent with text.

1.13.3 2016-12-08 ss (XEP Editor: ssw)

Include publisher with any item retrieval.

1.13.2 2016-10-11 ss (XEP Editor: ssw)

Be more consistent with reply.

1.13.1 2016-07-21 ss
  • Fix wording, replace Jabber with XMPP where applicable.
1.13 2010-07-12 psa
  • 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.
  • Corrected a large number of reported errata.
  • Removed delete-any feature.
  • Added missing delete-items feature.
  • Added special value of "presence" for the pubsub#expire option to support temporary subscriptions.
  • Removed replyto and replyroom config options.
  • Removed multiple node discovery since it depended on the deprecated Service Discovery Publishing feature.
  • 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 RFC 6120 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.
  • Added item_expire node configuration option for automatically removing items after a certain number of seconds.
  • Added notification_type node configuration option for defining which value of the <message/> type attribute shall be used for notifications.
  • Added retrieve-default-sub feature for retrieving default subscription configuration from a node (as you can retrieve default node configuration from the service).
  • Clarified suggested rules for payload definitions.
  • Mentioned that singleton pattern can be enforced by setting max_items to 1.
  • 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).
  • Removed informational mapping of node meta-data to Dublin Core.
1.12 2008-09-03 psa
  • Specified that service should return ItemID on successful publish if no ItemID was provided in request.
  • Described the use of Result Set Management to return some but not all published items.
  • Defined pubsub#notify_sub config option so that owners can receive notifications of new subscriptions, unsubscribes, and other subscription changes.
  • Harmonized definition of +notify feature with implementation reality.
  • Moved text about collections to XEP-0248.
1.11 2008-03-05 rm/psa

For collection nodes, changed name of node child element to associate and added disassociate child element to handle disassociation use case; corrected SHIM examples to conform to XEP-0131; modified lease expiry notification for consistency with other subscription-related notifications (i.e., not using SHIM header); renamed SHIM headers to Collection and SubID for consistency with HTTP and Email headers.

1.10 2007-09-26 psa
  • In accordance with XMPP Council consensus, moved the auto-create, auto-subscribe, filtered-notifications, and last-published features from XEP-0163 to this specification
  • Clarified implications of auto-subscribe feature for handling of account owners, stable presence subscribers, and transient presence sharers
  • Updated filtered-notifications text and examples to track changes to XEP-0115
  • Added publish-options functionality
  • Added developer-friendly How It Works section
  • Defined member affiliation to properly implement whitelist feature
  • Split several long sections into smaller sub-sections.
  • Clarified that a pubsub service must generate an ItemID if the publisher does not provide one.
  • Specified recommended ItemID for singleton nodes.
  • Summarized triggers for sending notifications.
1.9 2006-09-13 psa
  • Replaced boolean send_item_subscribe node configuration option with more comprehensive send_last_published_item option per list discussion
  • Added deliver_notifications node configuration option to enable quiet nodes without notifications, if desired enabling pull-model item retrieval only.
  • Modified subscription and affiliation retrieval to return empty element if no results.
1.8 2006-06-27 psa
  • Defined five access models: open, presence, roster, authorize, and whitelist
  • Renamed pubsub#subscription_model feature to pubsub#access_model
  • Separated affiliations retrieval from subscriptions retrieval
  • Removed subscription information from affiliations management
  • Changed <entity/> element to <subscription/> element in response to subscription request
  • Clarified batch processing of item publication and item deletion
  • Added basic example to introduction
  • More fully specified node creation flows
  • More fully specified recommended behavior for caching last published item, including use of jabber:x:delay protocol
  • Specified that semantic meaning of NodeIDs must not be used to encapsulate hierarchy
  • More fully specified error conditions
  • Changed some feature-related conditions to <unsupported/> plus feature attribute
  • Changed some error conditions from <not-authorized/> to <forbidden/>
  • Harmonized error conditions for unsubscribe if entity is not subscribed (unexpected-request rather than not-found)
  • Further defined error conditions related to item publication
  • Specified structure of <affiliations/>, <delete/>, <purge/>, and <subscriptions/> elements qualified by pubsub#owner namespace
  • Changed retrieval of default node configuration options to use <default/> element, not <configure/> element
  • Allowed caching of last published item
  • Added pubsub#deliver subscription option
  • Added meta-data fields for pubsub#owners and pubsub#contact
  • Changed element for retrieval of default node configuration options from <configure/> to <default/> to prevent ambiguity related to configuration of root collection node
  • Specified pubsub#node_type configuration field
  • Specified pubsub#collection SHIM header
  • Specified conformance with Resourceprep for nodes addressable as JIDs
  • Added pubsub#modify-affiliations feature
  • Added pubsub#digest_frequency field to subscribe_options FORM_TYPE
  • Added pubsub#roster_groups_allowed field to node_config FORM_TYPE
  • More clearly specified the requirements level (MUST, SHOULD, MAY) for each service discovery feature
  • Defined pubsub#include_body subscription option and the pubsub#body_xslt node configuration option to transform payload format into an XMPP message body, and clarified rules for inclusion of message bodies
  • Clarified nature of collections and association of a node to a collection
  • Specified that simultaneous subscriptions of type nodes and items are allowed to collection nodes
  • Added examples and further explanation of time-based and content-based subscriptions
  • Added Internationalization Considerations
  • Clarified terminology
  • Corrected and updated the schemas
1.7 2005-03-03 psa/rm
  • Reinstated pubsub#subscribe feature (deleted in error)
  • Added type attribute for the <create/> and <configure/> elements to differentiate between leaf nodes and collection nodes
  • In Section 8.1.7, changed affiliations retrieval support to SHOULD and added pubsub#retrieve-affiliations feature
  • In Section 8.1.10, removed two duplicate examples
  • In Section 8.1.12, clarified relationship between normal disco#info data and node meta-data (which uses a service discovery extension)
  • In Section 8.2.4, specified that node purgation MUST result in one event notification, not a notification per item
  • In Section 8.1.8, further specified handling of SubIDs
  • Clarified nature of the pubsub#type field
  • Mentioned that the forbidden error should be returned in response to certain operations requested by an outcast
  • Corrected datatype of max_items attribute from xs:string to xs:positiveInteger
  • Corrected <requesting-entity-not-subscribed/> error to <not-subscribed/> since the subscribed JID need not be that of the requesting entity
  • Added service discovery features for more optional use cases: retracting items, purging nodes, deleting nodes
  • Updated relevant registries
1.6 2004-07-13 pgm/psa

Added service discovery features for pubsub#meta-data, and pubsub#retrieve-items. Added pubsub#subscription_depth configuration option. Specified pubsub-specific error condition elements qualified by pubsub#errors namespace.

1.5 2004-07-07 pgm/psa

Fixed typos. Added more details to the section on collections. Added paragraph to create node use case to allow the service to change the requested node-id to something which it creates. Added text about bouncing publish requests when the request does not match the event-type for that node. Added disco features for the jabber registrar. Changed affiliation verbiage to allow publishers to remove any item. Tweaked verbiage for create node, eliminated extra example. Fully defined XMPP Registrar submissions. Corrected schemas.

1.4 2004-06-22 pgm

Added subid syntax in a variety of places. Added more information about disco#info and disco#items support. Added more info about subscription options. Added collection information. Added implementation notes about subscription leases, and content-based pubsub services.

1.3 2004-04-25 psa

Editorial review; added one implementation note.

1.2 2004-03-09 psa

Added XMPP error handling.

1.1 2004-01-14 psa

Added XMPP Registrar Considerations subsection for Service Discovery category/type registration.

1.0 2003-10-28 psa

Per a vote of the Jabber Council, advanced status to Draft.

0.16 2003-10-23 pgm

Clarified JID addressing usage for nodes. Added specific MAY requirement for disco usage. Added sentence about implementations verifying that an entity has a subscription before getting the current items.

0.15 2003-10-21 pgm

Fixed invalid XML in examples for subscription deny/allow.

0.14 2003-10-21 pgm

Clarified restrictions on addressing nodes by JID. Added section on Approving and Denying Subscription Requests. Changed get-pending to use Ad-Hoc Commands. Changed semantics when sending in a form type='cancel' for pending subscriptions.

0.13 2003-09-30 pgm

Removed item as a possible child of subscribe and unsubscribe and pubsub in the schemas. Removed retract as a possible child of item in the pubsub#event schema. Added verbiage to requirements for addressing nodes either via JIDs or disco nodes.

0.12 2003-08-13 pgm/psa

Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed <x/> to <event/> for #events namespace; added meta-data about meta-nodes; fully defined XMPP Registrar considerations.

0.11 2003-06-25 pgm

Removed subscription notifications since they have inherent issues. Removed empty implementation note sub-section.

0.10 2003-06-11 pgm

Fixed error example when returning 501 from an items-get request. Added note about receiving subscription requests when an entity is already subscribed. Fixed some entity elements in various subscription examples. Many were missing the node attribute. Added subscription change notification verbiage and example. Added verbiage and example of subscription state notification being sent to the requesting entity. Added disco#items information for getting a list of item identifiers for a single node. Added verbiage for returning the current entity element when a curent subscriber attempts to subscribe again.

0.9 2003-04-30 pgm

Include JID attributes in the entity elements when receiving your affiliations. Changed error code 406 (which was wrong) to 404, which is correct. Changed many 405 errors to 401, and modified the error table to make it more implementable (rules are more concrete). Added subscribe-options element for indicating subscriptions may be configured.

0.8 2003-04-03 pgm

Clarified the affiliations table and the semantics around subscribing and unsubscribing. Added protocol to get all of your affiliations in the service. Added protocol for services informing subscribers that configurable subscription options are available. Added protocol for obtaining existing node configuration settings and for concatenating configuration and node creation requests into a single stanza. Added meta-node implementation notes and specified the interaction with the XMPP Registrar and the meta NodeIDs. Added authorization notes to subscription options.

0.7 2003-02-14 pgm

Clarified requirements around what affiliations must be supported. Moved requirements about specifying entities which can subscribe and publish out of the MUSTs to MAYs. Changed SHOULD to MAY when talking about allowing entities to create nodes. Added ability to send configuration requests in the same stanza as a creation request.

0.6 2003-02-06 pgm

Added more details and an example about publishing without NodeID. Added more implementation notes about NodeIDs and persistent storage.

0.5 2003-01-22 pgm

Fixed header for delete item example. Added examples showing subscribers being notified of deleted items. Added examples for notification of node deletion, and configuration for node deletion. Added Subscriber option semantics and examples. Added examples for 402 and 407 errors on subscribe and create respectively. Added clarification about ItemID handling to impl notes.

0.4 2003-01-21 pgm

Clarified in-band and out-of-band configuration requirement. Added Delete Item privilege for all affiliations to the table. Added Delete item protocol for publishers and owners. Added 401 error case for subscribing to an illegal jid. Changed subscription request form. Added defaults to configuration form, and clarified role of the XMPP Registrar for the features show. Added text explaining the max_items attribute. Changed "last items" to "most recent items". Removed default configuration acceptance -- owners should just cancel. Added the notify_retract configuration option. Clarified error handling for affiliation modifications.

0.3 2003-01-20 pgm

Added subscription attribute for entities. Removed subscriber from the affiliations table. Clarified configuration details. Clarified JabberID usages. Added XMPP Registrar Considerations. Added link to XEP-0068 about the FORM_TYPE element in subscription request notifications. Fixed some typos in examples. Added unsupported configuration namespace to example. Added a default node configuration example.

0.2 2003-01-02 pgm

Added numerous implementation notes; added get-pending action with regard to subscriptions; added error table; changed purge and delete to use IQ type='set'.

0.1 2002-11-19 pgm

Initial version.

The XMPP publish-subscribe extension defined in this document provides a framework for a wide variety of applications, including news feeds, content syndication, extended presence, geolocation, avatar management, shared bookmarks, auction and trading systems, workflow systems, network management systems, NNTP gateways, profile management, and any other application that requires event notifications.

This technology uses the classic "publish-subscribe" or "observer" design pattern: a person or application publishes information, and an event notification (with or without payload) is broadcasted to all authorized subscribers. In general, the relationship between the publisher and subscriber is mediated by a service that receives publication requests, broadcasts event notifications to subscribers, and enables privileged entities to manage lists of people or applications that are authorized to publish or subscribe. The focal point for publication and subscription is a "node" to which publishers send data and from which subscribers receive event notifications. Nodes can also maintain a history of events and provide other services that supplement the pure pubsub model.

This document defines a generic protocol that all pubsub applications can use. Compliant implementations are not required to implement all of the features defined here (see the Feature Summary.) Other specifications may define "subsets" or "profiles" of publish-subscribe for use in specialized contexts, but such profiles are out of scope for this document.

Although this specification is large because it defines many side use cases and possible error flows, the basic idea is simple:

  1. An entity publishes information to a node at a publish-subscribe service.
  2. The pubsub service pushes an event notification to all entities that are authorized to learn about the published information.

Perhaps the most popular application of pubsub-like functionality is content syndication, which has become familiar from the RSS and Atom (&rfc4287;) feeds associated with weblogs, news sites, and other frequently-updated information available on the Internet. Consider the example of a weblog published by <hamlet@denmark.lit>. When Hamlet writes a new weblog entry, his blogging software publishes the entry to a pubsub node hosted at <pubsub.shakespeare.lit>:

Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z ]]>

So that is the "pub" part of pubsub.

Now the pubsub service notifies all the subscribers about the new blog entry:

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

Here is an even simpler example: a transient node that sends only event notifications without a payload:

]]>

Naturally, the entities involved may need to complete other use cases in order to enable full pubsub functionality -- for example, the publisher may need to create the node (see Create a Node) and subscribers may need to sign up for event notifications (see Subscribe to a Node). These use cases are fully described in the remainder of this document. (For information about which features are required and which are recommended or optional, consult the Feature Summary.)

The following terms are used throughout this document to refer to elements, objects, or actions that occur in the context of a pubsub service. (Note: Some of these terms are specified in greater detail within the body of this document.)

Authorize Access Model
A node access model under which an entity can subscribe only through having a subscription request approved by a node owner (subscription requests are accepted but only provisionally) and only subscribers may retrieve items.
Address
(1) A JID as defined in &xmppcore;, or (2) the combination of a JID and a &xep0030; node.
Collection Node
A type of node that contains nodes and/or other collections but no published items. Collections make it possible to represent more sophisticated relationships among nodes. Collection nodes are defined in &xep0248;.
Entity
A JID-addressable XMPP entity (client, service, application, etc.).
Event
A change in the state of a node.
Instant Node
A node whose NodeID is automatically generated by a pubsub service.
Item
An XML fragment which is published to a node, thereby generating an event.
ItemID
A unique identifier for an item in the context of a specific node.
Leaf Node
A type of node that contains published items only. It is NOT a container for other nodes.
Node
A virtual location to which information can be published and from which event notifications and/or payloads can be received (in other pubsub systems, this may be labelled a "topic").
NodeID
The unique identifier for a node within the context of a pubsub service. The NodeID is either supplied by the node creator or generated by the pubsub service (if the node creator requests an Instant Node). The NodeID MAY have semantic meaning (e.g., in some systems or in pubsub profiles such as PEP the NodeID might be an XML namespace for the associated payload), but such meaning is OPTIONAL. If a document defines a given NodeID as unique within the realm of XMPP pubsub systems, it MUST specify the XML namespace of the associated payload.
Notification
A message sent to a subscriber informing them of an event.
Outcast
An entity that is disallowed from subscribing or publishing to a node.
Owner
The manager of a node, of which there may be more than one; often but not necessarily the node creator.
Open Access Model
A node access model under which any entity may subscribe and retrieve items without approval.
Payload
The XML data that is contained within the <item/> element of a publication request or an event notification. A given payload is defined by an XML namespace and associated schema. A document that defines a payload format SHOULD specify whether the payload can be used only for a NodeID whose value is the same as the XML namespace, or whether the payload can be used for any NodeID. Such a document also SHOULD specify whether it is suggested that node at which such payloads are published are best configured as Singleton Nodes.
Personal Eventing
A simplified subset of Publish-Subscribe for use in the context of instant messaging and presence applications, whereby each IM user's JID is a virtual pubsub service; for details, see &xep0163;.
Presence Access Model
A node access model under which any entity that is subscribed to the owner's presence with a subscription of type "from" or "both" (see &rfc3921;) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems.
Publisher
An entity that is allowed to publish items to a node and that is automatically subscribed to the node.
Publish-Only
An entity that is allowed to publish items to a node but that is not allowed to receive notifications. (This affiliation is useful in the context of nodes that do not have an open access model when automated entities need to generate notifications on behalf of the owner.)
Pubsub Service
An XMPP server or component that adheres to the protocol defined herein.
Roster Access Model
A node access model under which any entity that is subscribed to the owner's presence and in the specified roster group(s) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems.
Subscriber
An entity that is subscribed to a node.
Whitelist Access Model
A node access model under which an entity may subscribe and retrieve items only if explicitly allowed to do so by the node owner (subscription requests from unauthorized entities are rejected).

Requirements for a pubsub service can be driven by end-user needs as well as the needs of other components and services which can use the service. First, a pubsub service implemented using XMPP MUST provide the basic features that implement a pure publish-subscribe pattern:

Some of the possible uses of an XMPP-based pubsub service will require other features, but these features are OPTIONAL and therefore not mandatory for compliance with this specification. However, if these features are implemented, they MUST adhere to the protocol described herein in to be compliant. These features include:

To manage permissions, the protocol defined herein uses a hierarchy of affiliations, similiar to those introduced in &xep0045;.

All affiliations MUST be based on a bare JID &BAREJID; instead of a full JID &FULLJID;.

Support for the "owner" and "none" affiliations is REQUIRED. Support for all other affiliations is RECOMMENDED. For each non-required affiliation supported by an implementation, it SHOULD return a service discovery feature of "name-affiliation" where "name" is the name of the affiliation, such as "member", "outcast", or "publisher" (see the Feature Summary). Particular kinds of pubsub services MAY enforce additional requirements (e.g., requiring support for a given non-required affiliation or for all affiliations).

Affiliation Subscribe Retrieve Items Publish Items Delete Single Item Purge Node Configure Node Delete Node
Owner Yes Yes Yes Yes Yes Yes Yes
Publisher Yes Yes Yes Yes * Yes * No No
Publish-Only No No Yes Yes * No * No No
Member Yes Yes No No No No No
None Yes No No No No No No
Outcast No No No No No No No

* Note: A service MAY allow any publisher to delete / purge any item once it has been published to that node instead of allowing only the original publisher to remove it. This behavior is NOT RECOMMENDED for the publish-only affiliation, which SHOULD be allowed to delete only items that the publish-only entity has published.

The ways in which an entity changes its affiliation with a node are well-defined. Typically, action by an owner is required to make an affiliation state transition. Affiliation changes and their triggering actions are specified in the following table.

  Outcast None Member Publisher Owner
Outcast -- Owner removes ban Owner adds entity to member list Owner adds entity to publisher list Owner adds entity to owner list
None Owner bans entity -- Owner adds entity to member list Owner adds entity to publisher list Owner adds entity to owner list
Member Owner bans entity Owner removes entity from member list -- Owner adds entity to publisher list Owner adds entity to owner list
Publisher Owner bans entity Owner removes entity from publisher list n/a -- Owner adds entity to owner list
Owner n/a Owner resigns n/a n/a --

Subscriptions to a node may exist in several states.

Subscription State Description
None The node MUST NOT send event notifications or payloads to the Entity.
Pending An entity has requested to subscribe to a node and the request has not yet been approved by a node owner. The node MUST NOT send event notifications or payloads to the entity while it is in this state.
Unconfigured An entity has subscribed but its subscription options have not yet been configured. The node MAY send event notifications or payloads to the entity while it is in this state. The service MAY timeout unconfigured subscriptions.
Subscribed An entity is subscribed to a node. The node MUST send all event notifications (and, if configured, payloads) to the entity while it is in this state (subject to subscriber configuration and content filtering).

The requirements for the publish-subscribe protocol imply that there are two major dimensions along which we can measure events: persistent vs. transient, and pure event notification vs. inclusion of payload. An implementation SHOULD enable an owner to configure a node along both of these dimensions.

No matter whether a node is configured for persistent or transient events, a service MAY cache the last item published to the node, in which case it SHOULD send that item to subscribers based on configuration of the "send_last_published_item" option (see the Item Caching section of this document); if the service supports the "http://jabber.org/protocol/pubsub#last-published" feature then the value of this option MUST default to "on_sub_and_presence" (though the service SHOULD allow the node owner to override the default).

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

A pubsub service MUST validate publish requests against the configuration of the node along both of these dimensions (see the Publish An Item to a Node section of this document for the relevant error conditions).

The node configuration and desired event type determine whether an item must be provided by the publisher, whether the item includes a payload in the publish request or event notification, and whether an item ID is provided by the publisher or generated by the pubsub service. We can summarize the relevant rules as follows:

 Notification-Only Node *Payload-Included Node *
Persistent Node ** Publish request MUST include an &ITEM; element, which MAY be empty or MAY contain a payload; even if publish request contains a payload, pubsub service MUST NOT include the payload in event notifications; if publish request did not include item ID, pubsub service MUST generate item ID Publish request MUST include an &ITEM; element, which SHOULD contain a payload; if publish request included a payload, event notifications MUST include the payload; if publish request did not include item ID, pubsub service MUST generate item ID
Transient Node ** Publish request MUST NOT include an &ITEM; element; payload is not included in publish request or event notifications, although event notifications MUST include an empty &ITEMS; element; item ID is neither provided in publish request nor generated by pubsub service Publish request MUST include an &ITEM; element, which SHOULD contain a payload; if publish request included a payload, event notifications MUST include the payload; pubsub service MAY generate an item ID

* Note: Whether the node is notification-only or includes payloads is determined by the "pubsub#deliver_payloads" configuration field.

** Note: Whether the node is persistent or transient is determined by the "pubsub#persist_items" configuration field.

There are two types of nodes:

Node Type Description
Leaf A node that contains published items only. It is NOT a container for other nodes. This is the most common node type.
Collection A node that contains nodes and/or other collections but no published items. Collections make it possible to represent more sophisticated relationships among nodes. For details, refer to XEP-0248.

In order to make node creation simpler for clients, we define the following node access models (in order of openness):

Access Model Description
Open Any entity may subscribe to the node (i.e., without the necessity for subscription approval) and any entity may retrieve items from the node (i.e., without being subscribed); this SHOULD be the default access model for generic pubsub services.
Presence Any entity with a subscription of type "from" or "both" may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see RFC 3921).
Roster Any entity in the specified roster group(s) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see RFC 3921).
Authorize The node owner must approve all subscription requests, and only subscribers may retrieve items from the node.
Whitelist An entity may subscribe or retrieve items only if on a whitelist managed by the node owner. The node owner MUST automatically be on the whitelist. In order to add entities to the whitelist, the node owner SHOULD use the protocol specified in the Manage Affiliated Entities section of this document, specifically by setting the affiliation to "member".

A generic publish-subscribe implementation SHOULD support all of the defined access models, although specialized publish-subscribe implementations MAY support only a subset of the access models. Which access models are provided in a particular deployment is a matter of service provisioning (e.g., some restricted deployments may wish to lock down permissions so that only the "authorize" and "whitelist" access models are provided, or even only the "whitelist" access model).

A node creator or owner can override the default access model by specifying an appropriate value for the 'pubsub#access_model' configuration field (see the Create a Node With Default Configuration and Configure a Node sections of this document).

If a pubsub node is addressable, it MUST be addressable either (1) as a JID or (2) as the combination of a JID and a node. These nodes are equivalent to those used in XEP-0030: Service Discovery.

If a pubsub node is addressable as a JID, the NodeID MUST be the resource identifier, and MUST NOT be specified by the "user" portion (node identifier) of the JID (e.g. "domain.tld/NodeID" and "user@domain.tld/NodeID" are allowed; "NodeID@domain.tld" is not allowed This rule does not apply to the root collection node, if any.). JID addressing SHOULD be used when interacting with a pubsub node using a protocol that does not support the node attribute. For example, when a service makes it possible for entities to subscribe to nodes via presence, it would address nodes as JIDs. If a pubsub node is addressable as a JID, the pubsub service MUST ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in RFC 3920.

Consider the following example, in which the pubsub service is located at the hostname pubsub.shakespeare.lit.

... ]]>

Now consider the following example, in which the pubsub service is located at pubsub@shakespeare.lit.

... ]]>

If a pubsub node is addressable as a JID plus node, the NodeID MUST be the value of both the Service Discovery 'node' attribute and the pubsub 'node' attribute; i.e., for discovery purposes, a pubsub node is equivalent to a Service Discovery node. If a pubsub node is addressable as a JID plus node, the pubsub service SHOULD ensure that the NodeID conforms to the Resourceprep profile of Stringprep as described in RFC 3920.

Consider the following example, in which the (virtual) pubsub service is located at hamlet@denmark.lit.

]]>

This section defines the use cases for and protocols to be used by any entity that wishes to interact with a publish-subscribe service, mainly focused on Service Discovery use cases.

A service MUST respond to service discovery information requests qualified by the 'http://jabber.org/protocol/disco#info' namespace. The "disco#info" result returned by a pubsub service MUST indicate the identity of the service and indicate which pubsub features are supported.

]]> ]]>

The possible pubsub features are noted throughout this document and have been registered as described in the XMPP Registrar Considerations section of this document. For information regarding which features are required, recommended, and optional, see the Feature Summary section of this document.

If a service implements a hierarchy of nodes (by means of Collection Nodes), it MUST also enable entities to discover the nodes in that hierarchy by means of the Service Discovery protocol, subject to the recommendations in XEP-0030 regarding large result sets (for which &xep0055; or some other protocol SHOULD be used). The following examples show the use of service discovery in discovering the nodes available at a hierarchical pubsub service.

Note: Node hierarchies and collection nodes are OPTIONAL. For details, refer to the NodeID Semantics and Collection Nodes sections of this document.

In the first example, an entity sends a service discovery items ("disco#items") request to the root node (i.e., the service itself), which is a Collection Node:

]]> ]]>

In the second example, an entity sends a disco#items request to one of the first-level nodes, which is also a collection node:

]]> ]]>

If a node is a leaf node rather than a collection node and items have been published to the node, the service MAY return one &ITEM; element for each published item as described in the Discover Items for a Node section of this document, however such items MUST NOT include a 'node' attribute (since they are published items, not nodes).

A pubsub service MUST allow entities to query individual nodes for the information associated with that node. The Service Discovery protocol MUST be used to discover this information. The "disco#info" result MUST include an identity with a category of "pubsub" and a type of either "leaf" or "collection".

Note: If a node has an identity type of "leaf", then it MUST NOT contain other nodes or collections (only items); if a node has an identity type of "collection", then it MUST NOT contain items (only other nodes or collections).

]]> ]]> ]]> ... ... ]]>

The "disco#info" result MAY include detailed meta-data about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#meta-data" in accordance with &xep0068;. If meta-data is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.

]]> http://jabber.org/protocol/pubsub#meta-data http://www.w3.org/2005/Atom hamlet@denmark.lit 2003-07-29T22:56:10Z Princely Musings (Atom) Updates for Hamlet's Princely Musings weblog. en bard@shakespeare.lit 120 hamlet@denmark.lit hamlet@denmark.lit 1066 ]]>

Note: Node meta-data can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node meta-data SHOULD be provided as fields in the node configuration form.

Note: The pubsub#language field SHOULD be list-single so that the pubsub service can present an appropriate list of languages and language codes.

To discover the published items which exist on the service for a specific node, an entity MAY send a "disco#items" request to the node itself, and the service MAY return each item as a Service Discovery &ITEM; element. The 'name' attribute of each Service Discovery item MUST contain its ItemID and the item MUST NOT possess a 'node' attribute. This ItemID MAY then be used to retrieve the item using the protocol defined in the Retrieve Items from a Node section of this document.

]]>

An entity may want to query the service to retrieve its subscriptions for all nodes at the service. Support for this feature ("retrieve-subscriptions") is RECOMMENDED.

In order to make the request, the requesting entity MUST send an IQ-get whose &PUBSUB; child contains an empty <subscriptions/> element with no attributes.

]]>

If the service returns a list of subscriptions, it MUST return all subscriptions for all JIDs that match the bare JID &BAREJID; portion of the 'from' attribute on the request.

For each subscription, a <subscription/> element is returned specifying the NodeID, the JID that is affiliated (which MAY include a resource, depending on how the entity subscribed), and the current subscription state. If subscription identifiers are supported by the service, the 'subid' attribute MUST be present as well.

]]>

If the requesting entity has no subscriptions, the pubsub service MUST return an empty <subscriptions/> element.

]]>

If the service does not support subscriptions retrieval, the service MUST respond with a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "retrieve-subscriptions".

]]>

An entity MAY also request all of its subscriptions at a specific node (e.g., if it has subscriptions with multiple SubIDs) by including a 'node' attribute on the <subscriptions/> element.

]]>

The service would then return only the entity's subscriptions to that specific node; this acts as a filter on the entity's subscriptions.

]]>

An entity may want to query the service to retrieve its affiliations for all nodes at the service, or query a specific node for its affiliation with that node. Support for this feature ("retrieve-affiliations") is RECOMMENDED.

In order to make the request of the service, the requesting entity includes an empty <affiliations/> element with no attributes.

]]>

If the service returns a list of affiliations, it MUST return all affiliations for all JIDs that match the bare JID &BAREJID; portion of the 'from' attribute on the request.

For each affiliation, an <affiliation/> element is returned containing the NodeID and the affiliation state (owner, publisher, publish-only, member, or outcast).

]]>

If the requesting entity has no affiliations, the pubsub service MUST return an empty <affiliations/> element.

]]>

If the service does not support affiliations retrieval, the service MUST respond with a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "retrieve-affiliations".

]]>

In order to make an affiliations request of a specific node, the requesting entity includes an empty <affiliations/> element with a 'node' attribute.

]]> ]]>

This section defines the use cases for and protocols to be used by potential and actual subscribers. (Note: The Implementation Notes section of this document describes many important factors and business rules which a pubsub service MUST observe. In addition, the examples throughout assume the existence of a separate pubsub component and include any relevant 'from' addresses as stamped by a server or network edge.)

When an XMPP entity wishes to subscribe to a node, it sends a subscription request to the pubsub service. The subscription request is an IQ-set where the <pubsub/> element contains one and only one <subscribe/> element. The <subscribe/> element SHOULD possess a 'node' attribute specifying the node to which the entity wishes to subscribe. The <subscribe/> element MUST also possess a 'jid' attribute specifying the exact XMPP address to be used as the subscribed JID -- often a bare JID &BAREJID; or full JID &FULLJID;.

Here is an example of a subscription request.

]]>

If the subscription request is successfully processed, the server MUST inform the requesting entity that it is now subscribed (which MAY include a service-generated SubID).

]]>

There are several reasons why the subscription request might fail:

  1. The bare JID portions of the JIDs do not match.
  2. The node has an access model of "presence" and the requesting entity is not subscribed to the owner's presence.
  3. The node has an access model of "roster" and the requesting entity is not in one of the authorized roster groups.
  4. The node has an access model of "whitelist" and the requesting entity is not on the whitelist.
  5. The service requires payment for subscriptions to the node.
  6. The requesting entity is anonymous and the service does not allow anonymous entities to subscribe.
  7. The requesting entity has a pending subscription.
  8. The requesting entity is blocked from subscribing (e.g., because having an affiliation of outcast).
  9. The requesting entity has attempted to establish too many subscriptions.
  10. The node does not support subscriptions.
  11. The node has moved.
  12. The node does not exist.

These error cases are described more fully in the following sections.

If the specified JID is a bare JID or full JID, the service MUST at a minimum check the bare JID portion against the bare JID portion of the 'from' attribute on the received IQ request to make sure that the requesting entity has the same identity as the JID which is being requested to be added to the subscriber list.

If the bare JID portions of the JIDs do not match as described above and the requesting entity does not have some kind of admin or proxy privilege as defined by the implementation, the service MUST return a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <invalid-jid/>.

]]>

Note: An implementation MAY enable the service administrator to configure a list of entities that are excluded from this check; those entities may be considered "trusted proxies" that are allowed to subscribe on behalf of other entities. In the same way, implementations MAY enable blacklisting of entities that are not allowed to perform specific operations (such as subscribing or creating nodes).

For nodes with an access model of "presence", if the requesting entity is not subscribed to the owner's presence then the pubsub service MUST respond with a ¬authorized; error, which SHOULD also include a pubsub-specific error condition of <presence-subscription-required/>.

]]>

For nodes with an access model of "roster", if the requesting entity is not in one of the authorized roster groups then the pubsub service MUST respond with a ¬authorized; error, which SHOULD also include a pubsub-specific error condition of <not-in-roster-group/>.

]]>

For nodes with a node access model of "whitelist", if the requesting entity is not on the whitelist then the service MUST return a ¬allowed; error, specifying a pubsub-specific error condition of <closed-node/>.

]]>

Commercial deployments may wish to link subscribers to a database of paying customers. If the subscriber needs to provide payment in order to subscribe to the node (e.g., if the subscriber is not in the customer database or the customer's account is not paid up), the service SHOULD return a &payment; error to the subscriber.

]]>

Some XMPP servers may allow authentication using SASL ANONYMOUS; however, because the resulting entity is unstable (the assigned JID may not be owned by the same principal in a persistent manner), a service MAY prevent anonymous entities from subscribing to nodes and SHOULD use service discovery to determine if an entity has an identity of "account/anonymous". If a requesting entity is anonymous but the service does not allow anonymous entities to subscribe, the service SHOULD return a &forbidden; error to the subscriber.

]]>

If the requesting entity has a pending subscription, the service MUST return a ¬authorized; error to the subscriber, specifying a pubsub-specific error condition of <pending-subscription/>.

]]>

If the requesting entity is blocked from subscribing (e.g., because having an affiliation of outcast), the service MUST return a &forbidden; error to the subscriber.

]]>

If the requesting entity has attempted to establish too many subscriptions (where the definition of "too many" is a matter of local service policy), the service MUST return a &policy; error to the subscriber, specifying a pubsub-specific error condition of <too-many-subscriptions/>.

]]>

The service can match on bare JID or full JID in determining which subscribing entities match for the purpose of determining if an entity has requested too many subscriptions.

If the node does not allow entities to subscribe, the service SHOULD return a &feature; error to the subscriber, specifying a pubsub-specific error condition of <unsupported/> and a feature of "subscribe".

]]>

If the node has, the service SHOULD return a &gone; error (if the node has moved permanently) or a &redirect; error (if the node has moved temporarily).

xmpp:pubsub.shakespeare.lit?;node=some-other-node ]]>

If the node does not exist, the service SHOULD return an ¬found; error to the subscriber.

]]>

For nodes with an access model of "authorize", subscription requests MUST be approved by one of the node owners unless service policy allows entities with affiliations other than "none" to auto-subscribe (e.g., members and publishers might be allowed to auto-subscribe); therefore the pubsub service sends a message to the node owner(s) requesting authorization (see the Manage Subscription Requests section of this document). Because the subscription request may or may not be approved, the service MUST return a pending notification to the subscriber.

]]>

If the entity must configure its subscription options (see the Configure Subscription Options section of this document) before receiving event notifications, the service MUST so inform the entity. It SHOULD do so by returning an IQ-result to the requesting entity with a notation that configuration of subscription options is required.

]]>

Note: The node shall include the <required/> child element only if the subscriber must configure the subscription before receiving any event notifications. A service MAY time out subscription requests if configuration is required and a configuration request is not submitted within a reasonable amount of time (which shall be determined by the service or node configuration).

Alternatively, if the service is unable to create the subscription without simultaneous configuration, the service MAY return a ¬acceptable; error, specifying a pubsub-specific error condition of <configuration-required/>.

http://jabber.org/protocol/pubsub#subscribe_options 1 0 false chat online away ]]>

If the <required/> element is not included and no error is returned, the subscription takes effect immediately and the entity may configure the subscription at any time (the service MAY indicate that subscription options are supported by including an empty <subscribe-options/> element in the IQ-result, as shown in the following example).

]]>

An entity may wish to subscribe using different subscription options, which it can do by subscribing multiple times to the same node. Support for this feature ("multi-subscribe") is OPTIONAL.

If multiple subscriptions for the same JID are allowed, the service MUST use the 'subid' attribute to differentiate between subscriptions for the same entity (therefore the SubID MUST be unique for each node+JID combination and the SubID MUST be present on the entity element any time it is sent to the subscriber). It is NOT RECOMMENDED for clients to generate SubIDs, since collisions might result; therefore a service SHOULD generate the SubID on behalf of the subscriber and MAY overwrite SubIDs if they are provided by subscribers. If the service does not allow multiple subscriptions for the same entity and it receives an additional subscription request, the service MUST return the current subscription state (as if the subscription was just approved).

When the pubsub service generates event notifications, it SHOULD send only one event notification to an entity that has multiple subscriptions, rather than one event notification for each subscription. By "entity" here is meant the JID specified for the subscription, whether bare JID or full JID; however, if the same bare JID has multiple subscriptions but those subscriptions are for different full JIDs (e.g., one subscription for user@domain.tld./foo and another subscription for user@domain.tld/bar), the service MUST treat those as separate JIDs for the purpose of generating event notifications.

When a subscription request is successfully processed, the service MAY send the last published item to the new subscriber. The message containing this item SHOULD be stamped with extended information qualified by the 'urn:xmpp:delay' namespace (see &xep0203;) to indicate it is sent with delayed delivery. (Note that in this example the event notification is sent to the bare JID since that is the subscribed JID.)

Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z ]]>

If the service sends the last published item by default for all nodes (subject to overriding by node configuration), it MUST return a feature of "http://jabber.org/protocol/pubsub#last-published" in its responsess to disco#info requests.

To unsubscribe from a node, the subscriber sends an IQ-set whose &PUBSUB; child contains an <unsubscribe/> element that specifies the node and the subscribed JID.

]]>

If the request can be successfully processed, the service MUST return an IQ result and MAY include a &PUBSUB; child element with the updated <subscription/> element for that node. If subscription identifiers are supported by the service, the 'subid' attribute MUST be present as well.

]]>

There are several reasons why the unsubscribe request might fail:

  1. The requesting entity has multiple subscriptions to the node but does not specify a subscription ID.
  2. The request does not specify an existing subscriber.
  3. The requesting entity does not have sufficient privileges to unsubscribe the specified JID.
  4. The node does not exist.
  5. The request specifies a subscription ID that is not valid or current.

These error cases are described more fully in the following sections.

If the requesting entity has multiple subscriptions to the node but does not specify a subscription ID, the service MUST return a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <subid-required/>.

]]>

If the value of the 'jid' attribute does not specify an existing subscriber, the pubsub service MUST return an error stanza, which SHOULD be &unexpected; and which SHOULD also include a pubsub-specific error condition of <not-subscribed/>.

]]>

If the requesting entity is prohibited from unsubscribing the specified JID, the service MUST return a &forbidden; error. The service MUST validate that the entity making the request is authorized to unsubscribe the entity. If the subscriber's JID is of the form &FULLJID;, a service MUST perform this check by comparing the &BAREJID; part of the two JIDs to ensure that they match. If the bare JID portions of the JIDs do not match and the requesting entity is not authorized to unsubscribe the JID (e.g., because it is not a service-wide admin or authorized proxy), the service MUST return a &forbidden; error.

]]>

If the node does not exist, the pubsub service MUST return an ¬found; error.

]]>

If a subscription identifier is associated with the subscription, the unsubscribe request MUST include an appropriate 'subid' attribute. If the unsubscribe request includes a SubID but SubIDs are not supported for the node (or the subscriber did not subscribe using a SubID in the first place), the service SHOULD ignore the SubID and simply unsubscribe the entity. If the subscriber originally subscribed with a SubID but the unsubscribe request includes a SubID that is not valid or current for the subscriber, the service MUST return a ¬acceptable; error, which SHOULD also include a pubsub-specific error condition of <invalid-subid/>.

]]>

An implementation MAY allow subscribers to configure subscription options. Implementations SHOULD use the Data Forms protocol to accomplish this configuration (however, an out-of-band mechanism such as a web interface could be offered as well).

If a service supports subscription options it MUST advertise that fact in its response to a "disco#info" query by including a feature whose 'var' attribute is "pubsub#subscription-options".

... ... ]]>

A subscriber requests the subscription options by including an <options/> element inside an IQ-get stanza.

]]>

If the request can be successfully processed, the service MUST respond with the options.

http://jabber.org/protocol/pubsub#subscribe_options 1 0 false chat online ]]>

Note: The foregoing example shows some (but by no means all) of the possible configuration options that MAY be provided. If an implementation provides these options using the Data Forms protocol, it MUST use the field variables that are registered with the XMPP Registrar in association with the 'http://jabber.org/protocol/pubsub' namespace (a preliminary representation of those field variables is shown above and in the pubsub#subscribe_options FORM_TYPE section of this document, but MUST NOT be construed as canonical since the XMPP Registrar may standardize additional fields at a later date without changes to this document).

Note: Many of the relevant data form fields are of type "boolean" and MUST be handled accordingly. &BOOLEANNOTE;

There are several reasons why the options request might fail:

  1. The requesting entity does not have sufficient privileges to modify subscription options for the specified JID.
  2. The requesting entity (or specified subscriber) is not subscribed.
  3. The request does not specify both the NodeID and the subscriber's JID.
  4. The request does not specify a subscription ID but one is required.
  5. The request specifies a subscription ID that is not valid or current.
  6. Subscription options are not supported.
  7. The node does not exist.

These error cases are described more fully in the following sections.

When requesting subscription options, the subscriber MUST specify the JID that is subscribed to the node and SHOULD specify a node (if no node is specified, i.e. via node="", the service MUST assume that the requesting entity wishes to request subscription options for its subscription to the root collection node; refer to XEP-0248 for details).

The service MUST validate that the entity making the request is authorized to set the subscription options for the subscribed entity. If the subscriber's JID is of the form &FULLJID;, a service MUST perform this check by comparing the &BAREJID; part of the two JIDs to ensure that they match. If the bare JID portions of the JIDs do not match and the requesting entity is not authorized to modify subscription options for the JID (e.g., because it is not a service-wide admin or authorized proxy), the service MUST return a &forbidden; error.

]]>

If the requesting entity (or specified subscriber, if different) is not subscribed, the service MUST return an &unexpected; error, which SHOULD also include a pubsub-specific error condition of <not-subscribed/>.

]]>

If the subscriber does not specify a subscriber JID, the service MUST return a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <jid-required/>.

]]>

If a subscription identifier is associated with the subscription, the 'subid' attribute MUST be present on the request in order for the service to differentiate subscriptions for the same entity. If the 'subid' is required but not provided, the service MUST return a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <subid-required/>.

]]>

If a subscription identifier is associated with the subscription but the request includes a SubID that is not valid or current for the subscriber, the service MUST return a ¬acceptable; error, which SHOULD also include a pubsub-specific error condition of <invalid-subid/>.

]]>

If the node or service does not support subscription options, the service MUST respond with a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "subscription-options".

]]>

If the node does not exist, the pubsub service MUST return an ¬found; error.

]]>

After receiving the configuration form, the requesting entity SHOULD submit the form in order to update the entity's subscription options for that node.

http://jabber.org/protocol/pubsub#subscribe_options 1 0 false chat online away ]]>

If the service can successfully process the submission, it MUST respond with success.

]]>

If the subscriber attempts to set an invalid group of options, the service MUST respond with a &badrequest; error.

]]>

The other errors already mentioned for getting subscription options also apply to setting subscription options.

As noted, if a service supports subscription options, an entity MAY subscribe and provide the subscription options in the same stanza.

Note: The <options/> element MUST follow the <subscribe/> element and MUST NOT possess a 'node' attribute or 'jid' attribute, since the value of the <subscribe/> element's 'node' attribute specifies the desired NodeID and the value of the <subscribe/> element's 'jid' attribute specifies the subscriber's JID; if any of these rules are violated, the service MUST return a &badrequest; error.

http://jabber.org/protocol/pubsub#subscribe_options 1 0 false chat online away ]]>

When the service informs the client of success, it SHOULD include a data form of type "result" informing the client of the resulting configuration options.

http://jabber.org/protocol/pubsub#subscribe_options 1 0 false chat online away ]]>

An entity might want to request information about the default subscription configuration. Support for this feature is OPTIONAL.

To get the default subscription options for a node, the entity MUST send an empty <default/> element to the node; in response, the node SHOULD return the default subscription options.

]]>

Note: Here the namespace is 'http://jabber.org/protocol/pubsub' (not 'http://jabber.org/protocol/pubsub#owner' as for retrieval of the default node configuration options).

The service itself MAY also have default subscription configuration options. To get the default subscription configuration options all (leaf) nodes at a service, the entity MUST send an empty <default/> element but not specifiy a node; in response, the service SHOULD return the default subscription options.

]]>

The process for retrieving the default subscription configuration options for collection nodes is described in XEP-0248.

If no error occurs, the node MUST return the default subscription configuration options.

http://jabber.org/protocol/pubsub#subscribe_options 1 0 false chat online away ]]>

There are several reasons why the default subscription configuration options request might fail:

  1. The service does not support subscription configuration.
  2. The service does not support retrieval of default subscription configuration.

These error cases are described more fully in the following sections.

If the node does not support subscription configuration, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "subscription-options".

]]>

If the node does not support retrieval of default subscription configuration options, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "retrieve-default-sub".

]]>

Implementations of pubsub that choose to persist items MAY allow entities to request existing items from a node (e.g., an entity may wish to do this after successfully subscribing in order to receive all the items in the publishing history for the node).

The service MUST conform to the node's access model in determining whether to return items to the entity that requests them. Specifically:

  • If the access model is "open", the service SHOULD allow any entity (whether or not it is subscribed) to retrieve items.

  • If the access model is "presence", the service SHOULD allow any entity that is subscribed to the owner's presence to retrieve items.

  • If the access model is "roster", the service SHOULD allow any entity that is subscribed to the owner's presence and contained in the relevant roster group(s) to retrieve items.

  • If the access model is "authorize" or "whitelist", the service MUST allow only subscribed entities to retrieve items.

The only exception foreseen to the SHOULD requirements for the foregoing access models is the enforcement of local privacy and security policies as specified more fully in the Security Considerations section of this document. (In addition, a service MUST always allow the node owner to retrieve items from a node and SHOULD always allow a publisher to do so.)

The subscriber may request all items by specifying only the Node ID without restrictions.

]]>

The service then SHOULD return all available items at the node, although it MAY truncate the result set if a large number of items has been published (see next section) and naturally it cannot return items that have been deleted, expired, etc.

The Uses of This World O, that this too too solid flesh would melt Thaw and resolve itself into a dew! tag:denmark.lit,2003:entry-32396 2003-12-12T17:47:23Z 2003-12-12T17:47:23Z Ghostly Encounters O all you host of heaven! O earth! what else? And shall I couple hell? O, fie! Hold, hold, my heart; And you, my sinews, grow not instant old, But bear me stiffly up. Remember thee! tag:denmark.lit,2003:entry-32396 2003-12-12T23:21:34Z 2003-12-12T23:21:34Z Alone Now I am alone. O, what a rogue and peasant slave am I! tag:denmark.lit,2003:entry-32396 2003-12-13T11:09:53Z 2003-12-13T11:09:53Z Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z ]]>

A node may have a large number of items associated with it, in which case it may be problematic to return all of the items in response to an items request. In this case, the service SHOULD return some of the items and note that the list of items has been truncated by including a &xep0059; notation.

The Uses of This World O, that this too too solid flesh would melt Thaw and resolve itself into a dew! tag:denmark.lit,2003:entry-32396 2003-12-12T17:47:23Z 2003-12-12T17:47:23Z Ghostly Encounters O all you host of heaven! O earth! what else? And shall I couple hell? O, fie! Hold, hold, my heart; And you, my sinews, grow not instant old, But bear me stiffly up. Remember thee! tag:denmark.lit,2003:entry-32396 2003-12-12T23:21:34Z 2003-12-12T23:21:34Z Alone Now I am alone. O, what a rogue and peasant slave am I! tag:denmark.lit,2003:entry-32396 2003-12-13T11:09:53Z 2003-12-13T11:09:53Z 368866411b877c30064a5f62b917cffe 4e30f35051b7b8b42abe083742187228 19 ]]>

Even if the service or node does not support persistent items, it MAY return the last published item.

Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z ]]>

A service MAY return event notifications without payloads (e.g., to conserve bandwidth). If so, the client MAY request a specific item (using the ItemID) in order to retrieve the payload. When an entity requests items by ItemID, implementations MUST allow multiple items to be specified in the request.

]]> The Uses of This World O, that this too too solid flesh would melt Thaw and resolve itself into a dew! tag:denmark.lit,2003:entry-32396 2003-12-12T17:47:23Z 2003-12-12T17:47:23Z Alone Now I am alone. O, what a rogue and peasant slave am I! tag:denmark.lit,2003:entry-32396 2003-12-13T11:09:53Z 2003-12-13T11:09:53Z ]]>

A service MAY allow entities to request the most recent N items by using the 'max_items' attribute. When max_items is used, implementations SHOULD return the N most recent (as opposed to the N oldest) items. (Note: A future version of this specification may recommend the use of XEP-0059 instead of the 'max_items' attribute.)

]]> Alone Now I am alone. O, what a rogue and peasant slave am I! tag:denmark.lit,2003:entry-32396 2003-12-13T11:09:53Z 2003-12-13T11:09:53Z Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z ]]>

The subscriber can request a particular item by specifying the Node ID and the appropriate ItemID.

]]>

The service would then return that specific item, if available.

There are several reasons why the items retrieval request might fail:

  1. The requesting entity has multiple subscriptions to the node but does not specify a subscription ID.
  2. The requesting entity is subscribed but specifies an invalid subscription ID.
  3. The node does not return items to unsubscribed entities and the requesting entity is not subscribed.
  4. The service or node does not support persistent items and does not return the last published item.
  5. The service or node does not support item retrieval.
  6. The node has an access model of "presence" and the requesting entity is not subscribed to the owner's presence.
  7. The node has an access model of "roster" and the requesting entity is not in one of the authorized roster groups.
  8. The node has an access model of "whitelist" and the requesting entity is not on the whitelist.
  9. The service or node requires payment for item retrieval.
  10. The requesting entity is blocked from retrieving items from the node (e.g., because having an affiliation of outcast).
  11. The node does not exist.

These error cases are described more fully in the following sections.

If the requesting entity has multiple subscriptions to the node but does not specify a subscription ID, the service MUST return a &badrequest; error to the subscriber, which SHOULD also include a pubsub-specific error condition of <subid-required/>.

]]>

If the requesting entity is subscribed but specifies an invalid subscription ID, the service MUST return a ¬acceptable; error to the subscriber, which SHOULD also include a pubsub-specific error condition of <invalid-subid/>.

]]>

If the node does not return items to unsubscribed entities and the requesting entity is not subscribed (which includes having a pending subscription), the service MUST return a ¬authorized; error to the subscriber, which SHOULD also include a pubsub-specific error condition of <not-subscribed/>.

]]>

If the service or node does not support persistent items and does not return the last published item, the service MUST return a &feature; error to the subscriber, specifying a pubsub-specific error condition of <unsupported/> and a feature of "persistent-items".

]]>

If the service or node does not support item retrieval (e.g., because the node is a collection node as described in XEP-0248), the service MUST return a &feature; error to the subscriber, specifying a pubsub-specific error condition of <unsupported/> and a feature of "retrieve-items".

]]>

For nodes with an access model of "presence", if the requesting entity is not subscribed to the owner's presence then the pubsub service MUST respond with a ¬authorized; error, which SHOULD also include a pubsub-specific error condition of <presence-subscription-required/>.

]]>

For nodes with an access model of "roster", if the requesting entity is not in one of the authorized roster groups then the pubsub service MUST respond with a ¬authorized; error, which SHOULD also include a pubsub-specific error condition of <not-in-roster-group/>.

]]>

For nodes with a node access model of "whitelist", if the requesting entity is not on the whitelist then the service MUST return a ¬allowed; error, specifying a pubsub-specific error condition of <closed-node/>.

]]>

Commercial deployments may wish to link subscribers to a database of paying customers. If the subscriber needs to provide payment in order to retrieve items from the node (e.g., if the subscriber is not in the customer database or the customer's account is not paid up), the service SHOULD return a &payment; error to the subscriber.

]]>

If the requesting entity is blocked from retrieving items (e.g., because having an affiliation of outcast), the service MUST return a &forbidden; error to the subscriber.

]]>

If the node does not exist, the service SHOULD return an ¬found; error to the subscriber.

]]>

If there are no items at the node or the requested items do not exist, the service SHOULD return an IQ stanza of type "result" with an empty <items/> element.

]]>

Any entity that is allowed to publish items to a node (i.e., a publisher or an owner) may do so at any time by sending an IQ-set to the service containing a pubsub element with a <publish/> child.

The syntax is as follows:

  • The <publish/> element MUST possess a 'node' attribute, specifying the NodeID of the node.
  • Depending on the node configuration, the <publish/> element MAY contain no &ITEM; elements or one &ITEM; element. The inclusion of more than one &ITEM; element is no longer allowed, given the removal of batch publishing from version 1.13 of this specification. It is not necessary for a publication request to include a payload or even an &ITEM; element in order to trigger an event notification. For example, the result of publishing to a transient, notification-only node will be an event notification that does not include even an &ITEM; element. However, for the sake of convenience we refer to the act of publication as "publishing an item" (rather than, say, "triggering an event notification") even though a publication request will not always contain an &ITEM; element.
  • The <item/> element provided by the publisher MAY possess an 'id' attribute, specifying a unique ItemID for the item. If an ItemID is not provided in the publish request, the pubsub service MUST generate one and MUST ensure that it is unique for that node.

An example follows.

Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z ]]>

If the pubsub service can successfully process the request, it MUST inform the publisher of success. If the publish request did not include an ItemID, the IQ-result SHOULD include an empty &ITEM; element that specifies the ItemID of the published item.

]]>

Note: If the publisher previously published an item with the same ItemID, successfully processing the request means that the service MUST overwrite the old item with the new item and then proceed as follows.

The pubsub service MUST then send one event notification to each entity that meets the criteria for receiving an event notification (typically to each approved subscriber, although there are other contexts in which an entity may receive an event notification as summarized under Notification Triggers). Each &MESSAGE; stanza generated by a pubsub service SHOULD possess an 'id' attribute with a unique value so that the service can properly track any notification-related errors that may occur (see the Handling Notification-Related Errors section of this document). Depending on the node configuration, the event notification either will or will not contain the payload, as shown below.

Note: In order to facilitate authorization for item removal as described in the Delete an Item from a Node section of this document, implementations that support persistent items SHOULD store the item (if the node is so configured) and maintain a record of the publisher.

Note: If the service or node is configured so that there is a maximum number of items cached at the node and the maximum is reached when an item is published, the service MUST delete one of the existing items. It is RECOMMENDED for the service to follow the "first in, first out" rule and delete the oldest item. Depending on node configuration, deletion of an existing item MAY result in sending of a delete notification to the subscribers.

If the node is configured to include payloads, the subscribers will receive payloads with the event notifications.

Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z ]]>

If the node is configured to not include payloads, the subscribers will receive event notifications only. (If payloads are not included, subscribers may request the published item via the protocol defined in the Retrieve Items from a Node section of this document.)

]]>

If configured to do so, the service can include the publisher of the item when it generates event notifications.

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

If so, the service MUST also include the publisher with every other form of item retrieval.

[ ... ENTRY ... ] [ ... MORE ITEMS ... ] ]]>

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.

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.

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).

123-abc
004-yyy
]]>

There are several reasons why the publish request might fail:

  1. The requesting entity does not have sufficient privileges to publish.
  2. The node does not support item publication.
  3. The node does not exist.
  4. The payload size exceeds a service-defined limit.
  5. The item contains more than one payload element or the namespace of the root payload element does not match the configured namespace for the node.
  6. The request does not match the node configuration.

These error cases are described more fully in the following sections.

Note: If a publisher publishes an item with an Item ID and the ItemID matches that of an existing item, the pubsub service MUST NOT fail the publication but instead MUST overwrite the existing item and generate a new event notification (i.e., re-publication is equivalent to modification).

If the requesting entity does not have sufficient privileges to publish, the service MUST return a &forbidden; error.

]]>

If the node does not support item publication (e.g., because it is a collection node as described in XEP-0248), the service MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "publish".

]]>

If the requesting entity attempts to publish an item to a node that does not exist and the service does not support the "auto-create" feature (see Automatic Node Creation), the service MUST return an ¬found; error.

]]>

If the payload size exceeds a service-defined limit, the service MUST return a ¬acceptable; error, which SHOULD also include a pubsub-specific error condition of <payload-too-big/>.

]]>

If the &ITEM; element contains more than one payload element or the namespace of the root payload element does not match the configured namespace for the node, the service MUST bounce the request with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <invalid-payload/>.

]]>

If the request does not conform to the configured event type for the node, the service MAY bounce the request with a &badrequest; error, which SHOULD also include a pubsub-specific error condition. The following rules apply:

  • If the event type is persistent (either event notification or payload) and the publisher does not specify an ItemID, the service MUST generate the ItemID and MUST NOT bounce the publication request.
  • If the event type is persistent (either event notification or payload) and the publisher does not include an item, the service MUST bounce the publication request with a &badrequest; error and a pubsub-specific error condition of <item-required/>.
  • If the event type is payload (either persistent or transient) and the publisher does not include a payload, the service SHOULD bounce the publication request with a &badrequest; error and a pubsub-specific error condition of <payload-required/>.
  • If the event type is notification + transient and the publisher provides an item, the service MUST bounce the publication request with a &badrequest; error and a pubsub-specific error condition of <item-forbidden/>.

Examples of these errors are shown below.

]]> ]]> ]]>

A pubsub service MAY automatically create a node when it receives a publish request sent to a node that does not exist (instead of returning an ¬found; error). When doing so, the service SHOULD apply the default node configuration. If a service supports this functionality, it MUST advertise that fact by including a feature of "http://jabber.org/protocol/pubsub#auto-create" in its disco#info responses.

A pubsub service MAY support the ability to specify options along with a publish request (if so, it MUST advertise support for the "http://jabber.org/protocol/pubsub#publish-options" feature). Here is an example:

Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z http://jabber.org/protocol/pubsub#publish-options presence ]]>

The <publish-options/> element MUST contain a data form (see XEP-0004), whose FORM_TYPE MUST be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).

Each form field denotes a precondition to publishing the request. A pub-sub service advertising support for publishing options MUST check each precondition field against the node configuration of the same name, and it MUST reject the publication upon encountering unknown fields.

Preconditions MUST be processed as follows:

  1. If the node exists and the precondition is not met, then the publish MUST fail with a &conflict; error condition and a pubsub-specific condition of <precondition-not-met/>.
  2. If the node exists and the precondition is met, then the publish succeeds.
  3. If the node does not exist and the service supports the "auto-create" feature, then the service shall auto-create the node with default configuration in all respects except those specified in the preconditions, and the publish succeeds.
  4. If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.

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 MUST contain one &ITEM; element; the &ITEM; element MUST be empty and MUST possess an 'id' attribute.

]]>

If no error occurs, the service MUST delete the item.

]]>

If no error occurs and the <retract/> element included a 'notify' attribute with a value of "true" or "1" &BOOLEANNOTE;, then the service MUST delete the item and MUST notify all subscribers as shown below. The syntax is identical to event notifications except that instead of an &ITEM; element, the &ITEMS; element includes a <retract/> element.

]]>

If a single entity is subscribed to the node multiple times, the service SHOULD notate the item deletion so that the entity can determine which subscription identifier(s) generated this event. As above, if these notations are included, they MUST use the Stanza Headers and Internet Metadata (SHIM) protocol and SHOULD be included after the notification data (i.e., as the last child of the &MESSAGE; stanza).

123-abc
004-yyy
]]>

There are several reasons why the item retraction request might fail:

  1. The publisher does not have sufficient privileges to delete the requested item.
  2. The node or item does not exist.
  3. The request does not specify a node.
  4. The request does not include an &ITEM; element or the &ITEM; element does not specify an ItemID.
  5. The node does not support persistent items.
  6. The service does not support the deletion of items.

These error cases are described more fully in the following sections.

If the requesting entity does not have sufficient privileges to delete the item, the service MUST return a &forbidden; error.

]]>

If the node or item does not exist, the service MUST return an ¬found; error.

]]>

If the request does not specify a node, the service MUST return a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <nodeid-required/>.

]]>

If the request does not include an &ITEM; element or the &ITEM; element does not specify an ItemID, the service MUST return a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <item-required/>.

]]>

If the node does not support persistent items (e.g., because it is a collection node or a transient node that does not deliver payloads), the service MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "persistent-items".

]]>

If the service does not support item deletion, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "delete-items".

]]>

An entity may want to create a new node. Support for this feature ("create-nodes") is RECOMMENDED. However, a service MAY disallow creation of nodes based on the identity of the requesting entity, or MAY disallow node creation altogether (e.g., reserving that privilege to a service-wide administrator).

There are two ways to create a node:

  1. Create a node with default configuration for the specified node type.
  2. Create and configure a node simultaneously.
]]>

These methods, along with method-specific error conditions, are explained more fully in the following sections.

In addition to method-specific error conditions, there are several general reasons why the node creation request might fail:

  • The service does not support node creation.
  • Only entities that are registered with the service are allowed to create nodes but the requesting entity is not registered.
  • The requesting entity does not have sufficient privileges to create nodes.
  • The requested NodeID already exists.
  • The request did not include a NodeID and "instant nodes" are not supported.

These general error cases are described more fully below.

If the service does not support node creation, it MUST respond with a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "create-nodes".

]]>

If only entities that are registered with the service may create nodes but the requesting entity has not yet registered, the service MUST respond with a ®istration; error.

]]>

If the requesting entity does not have sufficient privileges to create nodes, the service MUST respond with a &forbidden; error.

]]>

If the requested NodeID already exists, the service MUST respond with a &conflict; error.

]]>

If the node creator does not specify a NodeID but the service does not support instant nodes, the service MUST return a ¬acceptable; error, specifying a pubsub-specific error condition of <nodeid-required/>.

]]>

If the node creator does not specify a NodeID but the service supports instant nodes, the service SHOULD generate a NodeID that is unique within the context of the service on behalf of the node creator.

]]>

If no error occurs, the pubsub service SHOULD create the node, generate a NodeID that is unique within the context of that service, and inform the user of success (including the NodeID in the response).

]]>

Note: When a service successfully creates a node on behalf of the requesting entity, it MUST return an IQ result (in accordance with XMPP Core). If the node creation request did not specify a NodeID and the service supports creation of instant nodes, the service MUST specify the created NodeID in the IQ result. Similarly, if the node creation request specified a NodeID but the service modified the NodeID before creating the node, the service MUST also specify the modified node in the IQ result. In all other cases, the service MAY specify the NodeID in the IQ result but the node creator MUST NOT depend on receiving it from the service (since the node creator can determine which node was created by tracking the 'id' attribute that it specified for the IQ-set).

As explained above, each node type has its own default configuration. By asking the service to create a node with default configuration, the node creator accepts the default configuration. If the service allows node configuration, the owner may reconfigure the node after creating the node (as described in the Configure a Node section of this document). In addition, a service MAY allow entities to determine the default configuration options for a given node type before creating a node (as described in the Request Default Node Configurations section of this document).

In order to create a node with default configuration, the node creator can simply include an empty <create/> child element.

In the following example, the node creator requests a leaf node (the default type) with an open access model (assumed to be the default type for this service).

]]>

Note: The default setting for the 'pubsub#node_type' configuration field is "leaf".

In order to request an access model other than the default for the service, the node creator MUST include a Data Form in the node creation request that specifies a non-default value for the 'pubsub#access_model' field.

http://jabber.org/protocol/pubsub#node_config whitelist ]]>

If the access model is supported and none of the general or method-specific errors has occurred, the service SHOULD create the node and inform the requesting entity of success.

]]>

If service does not support the specified access model, it MUST return a ¬acceptable; error, specifying a pubsub-specific error condition of <unsupported-access-model/>.

]]>

(For error handling if the service does not support the specified node type, refer to XEP-0248.)

If an implementation allows node configuration (see the Configure a Node section of this document), it SHOULD allow node creation requests to contain the desired node configuration in the node creation request.

Note: The <configure/> element MUST follow the <create/> element and MUST NOT possess a 'node' attribute, since the value of the <create/> element's 'node' attribute specifies the desired NodeID; if any of these rules are violated, the service MUST return a &badrequest; error.

http://jabber.org/protocol/pubsub#node_config Princely Musings (Atom) 1 1 1 10 604800 open publishers 0 never false headline 0 0 0 0 1028 http://www.w3.org/2005/Atom http://jabxslt.jabberstudio.org/atom_body.xslt ]]> ]]>

If a service supports this "create-and-configure" feature, it MUST advertise that fact by returning a feature of "http://jabber.org/protocol/pubsub#create-and-configure" in response to service discovery information requests. If the create-and-configure option is not supported but the requesting entity sends such a request anyway, the service SHOULD ignore the configuration part of the request and proceed as if it had not been included.

After creating a new node, the node owner may want to modify the node configuration. Support for this feature is RECOMMENDED.

]]>

If no error occurs, the server MUST return a configuration form to the node owner, which SHOULD contain the current node configuration as the default values.

Note: The following example shows some of the possible configuration options that MAY be provided. If an implementation implements these features using the Data Forms protocol, that implementation MUST use the fields that are registered with the XMPP Registrar in association with the 'http://jabber.org/protocol/pubsub' namespace (a preliminary representation of those field variables is shown below and in the pubsub#node_config FORM_TYPE section of this document, but MUST NOT be construed as canonical, since the XMPP Registrar may standardize additional fields at a later date without changes to this document). An implementation MAY choose to specify different labels, values, and even field types, but MUST conform to the defined variable naming scheme.

http://jabber.org/protocol/pubsub#node_config true true 0 false false 0 1 10 604800 1 open publishers 0 1028 never 0 headline http://www.w3.org/2005/Atom ]]>

There are several reasons why the node configuration request might fail:

  1. The service does not support node configuration.
  2. The requesting entity does not have sufficient privileges to configure the node.
  3. The request did not specify a node.
  4. The node has no configuration options.
  5. The specified node does not exist.

These error cases are described more fully in the following sections.

If the service does not support node configuration, the service MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "config-node".

]]>

If the requesting entity does not have sufficient privileges to configure the node, the service MUST respond with a &forbidden; error.

]]>

If the request did not specify a node, the service SHOULD return a &badrequest; error. It is possible that by not including a NodeID, the requesting entity is asking to configure the root node; however, if the requesting entity is not a service-level admin, it makes sense to return &badrequest; instead of &forbidden;.

]]>

If no configuration options are available (e.g., because node configuration is "locked down"), the service MUST return a ¬allowed; error to the owner.

]]>

If the node does not exist, the service MUST return an ¬found; error.

]]>

After receiving the configuration form, the owner SHOULD submit a completed configuration form.

http://jabber.org/protocol/pubsub#node_config Princely Musings (Atom) 1 1 1 10 604800 roster friends servants courtiers publishers 0 never false headline 0 0 0 0 1028 http://www.w3.org/2005/Atom http://jabxslt.jabberstudio.org/atom_body.xslt ]]>

Alternatively, the owner MAY cancel the configuration process, in which case the existing configuration MUST be applied.

]]>

If the form can be successfully processed, the service MUST return an IQ-result.

]]>

Note: If the node type was changed from leaf to collection and there are items associated with the node, the service MUST purge the node of all items (with or without notifying the subscribers).

If the requested node configuration change cannot be processed (e.g., because the node owner has attempted to change the configuration so that there are no node owners), the service MUST return a ¬acceptable; error to the owner.

]]>

If the "pubsub#notify_config" option is set to true, the service MUST notify subscribers of the configuration change. (A service SHOULD support this option for leaf nodes and MUST support it for collection nodes as described in XEP-0248.) If the node configuration is set to notification-only, the notification MUST consist of an empty <configuration/> element whose 'node' attribute is set to the NodeID of the node; if the node configuration is set to full payloads, the <configuration/> element MUST in addition contain the node configuration as represented via the Data Forms protocol.

]]> http://jabber.org/protocol/pubsub#node_config Princely Musings (Atom) 1 1 0 0 0 0 1 10 604800 1 open publishers 0 9216 never 0 headline http://www.w3.org/2005/Atom http://jabxslt.jabberstudio.org/atom_body.xslt ]]>

An entity may want to request information about the default node configuration, e.g. in order to determine whether to perform create-and-configure as previously described. Support for this feature is OPTIONAL.

To get the node options, the entity MUST send an empty <default/> element to the service with no NodeID; in response, the service SHOULD return the default node options.

]]>

If no error occurs, the service MUST return the default node configuration options.

http://jabber.org/protocol/pubsub#node_config true 1 0 0 0 0 1 10 604800 1 open publishers 0 9216 never 0 headline ]]>

There are several reasons why the default node configuration options request might fail:

  1. The service does not support node configuration.
  2. The service does not support retrieval of default node configuration.

These error cases are described more fully in the following sections.

If the service does not support node configuration, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "config-node".

]]>

If the service does not support retrieval of default node configuration options, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "retrieve-default".

]]>

If a service supports node creation, it MUST support node deletion. If an implementation persists items, it MUST remove all items from persistent storage before the node itself is deleted.

In order to delete a node, a node owner MUST send a node deletion request, consisting of a <delete/> element whose 'node' attribute specifies the NodeID of the node to be deleted.

]]>

The deletion request MAY include the URI of a replacement node to which requests might be redirected. Typically this is an XMPP URI or IRI as described under PubSub URIs, but it can be an HTTP URI or any other scheme.

]]>

Support for redirection is OPTIONAL on the part of pubsub services.

If no error occurs, the service MUST inform the owner of success.

]]>

In addition, the service MUST also send notification of node deletion to all subscribers (which SHOULD include pending and unconfigured subscriptions).

]]>

There are several reasons why the node deletion request might fail:

  1. The requesting entity does not have sufficient privileges to delete the node.
  2. The node is the root collection node, which cannot be deleted (see XEP-0248).
  3. The specified node does not exist.

These error cases are described more fully in the following sections.

If the requesting entity does not have sufficient privileges to delete the node (e.g., is not an owner), the service MUST return a &forbidden; error.

]]>

If the requesting entity attempts to delete a node that does not exist, the service MUST return an ¬found; error.

]]>

If a service persists published items, a node owner may want to purge the node of all published items (thus removing all items from the persistent store, with the exception of the last published item, which MAY be cached). It is OPTIONAL for a service to implement this feature.

In order to purge a node of all items, a node owner sends a node purge request consisting of a <purge/> element whose 'node' attribute specifies the NodeID of the node to be purged.

]]>

If no error occurs, the service MUST purge the node and inform the owner of success.

]]>

If the node or service has been configured to notify subscribers on deletion of items, a purge request MUST NOT result in sending the same notifications as are sent when deleting items (since purging a node with many persisted items could result in a large number of notifications); instead, the node MUST send a single notification to each subscriber, containing an empty <purge/> child element.

]]>

There are several reasons why the node purge request might fail:

  1. The node or service does not support node purging.
  2. The requesting entity does not have sufficient privileges to purge the node.
  3. The node is not configured to persist items.
  4. The specified node does not exist.

These error cases are described more fully in the following sections.

If the node or service does not support node purging, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "purge-nodes".

]]>

If the requesting entity does not have sufficient privileges to purge the node (e.g., because it is not a node owner), the service MUST return a &forbidden; error.

]]>

If the service or node does not persist items (e.g., because the node is a collection node as described in XEP-0248), it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "persistent-items".

]]>

If the node does not exist, the service MUST return an ¬found; error.

]]>

A service MAY send subscription approval requests to the node owner(s) at any time. An approval request consists of a message stanza containing a Data Form scoped by the "http://jabber.org/protocol/pubsub#subscribe_authorization" FORM_TYPE. The form MUST contain a boolean field that has a 'var' attribute of "pubsub#allow", which is the field that designates whether or not to allow the subscription request. The form SHOULD include fields that specify the node identifier and the JID of the pending subscriber. The message MAY include a &BODY; element that contains natural-language text explaining that the message contains a pending subscription form.

PubSub subscriber request To approve this entity's subscription request, click the OK button. To deny the request, click the cancel button. http://jabber.org/protocol/pubsub#subscribe_authorization 123-abc princely_musings horatio@denmark.lit false ]]>

In order to approve the request, the owner shall submit the form and set the "pubsub#allow" field to a value of "1" or "true"; for tracking purposes the message MUST reflect the 'id' attribute originally provided.

http://jabber.org/protocol/pubsub#subscribe_authorization 123-abc princely_musings horatio@denmark.lit true ]]>

The service then SHOULD notify the approved subscriber (see the Notification of Subscription State Changes section of this document).

]]>

In order to deny the request, the owner shall submit the form and set the "pubsub#allow" field to a value of "0" or "false"; as above, the message MUST reflect the 'id' attribute originally provided.

http://jabber.org/protocol/pubsub#subscribe_authorization 123-abc princely_musings horatio@denmark.lit false ]]>

The service then SHOULD notify the denied subscriber (see the Notification of Subscription State Changes section of this document).

]]>

In order to cancel the form submission, the owner shall reply with the form's 'type' attribute set to "cancel".

http://jabber.org/protocol/pubsub#subscribe_authorization ]]>

The service MUST check the "pubsub#allow" field to see if the subscription should be allowed or denied. If the owner cancels the Data Form, then the subscription request MUST remain in the pending state.

A node owner may want to request all of the pending subscription requests for all of their nodes at a service. It is OPTIONAL for a service to implement this feature.

This feature MUST be implemented using the &xep0050; protocol, where the command name ('node' attribute of the command element) MUST have a value of "http://jabber.org/protocol/pubsub#get-pending".

]]>

If no error occurs, the service SHOULD return a data form for managing subscription requests, which MUST contain a single field with a 'var' attribute value of "pubsub#node" whose <option/> elements specify the nodes for which the requesting entity has subscription approval privileges (as an optimization, the service MAY specify only the nodes that have subscription requests pending).

http://jabber.org/protocol/pubsub#subscribe_authorization ]]>

There are several reasons why the pending subscription approval request might fail:

  1. The service does not support the ad-hoc commands protocol.
  2. The service supports ad-hoc commands but does not support the "get-pending" feature.
  3. The requesting entity does not have sufficient privileges to approve subscription requests.
  4. The specified node does not exist.

These error cases are described more fully in the following sections.

If the service does not support the ad-hoc commands protocol, it MUST respond with a &unavailable; error.

]]>

If the service does not support the "get-pending" feature, it MUST respond with a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "get-pending".

]]>

If the requesting entity does not have sufficient privileges to approve subscription requests, the service MUST respond with a &forbidden; error.

]]>

If the requested node does not exist, the service MUST respond with an ¬found; error.

]]>

Upon receiving the data form for managing subscription requests, the owner then MAY request pending subscription approval requests for a given node.

princely_musings ]]>

If no error occurs, the service shall respond with success.

]]>

The service shall then send one subscription approval message for each pending subscription request, as shown above for a single pending subscription request.

Note: A service SHOULD conform to its affiliation policies in maintaining the list of pending subscriptions. In particular, if the affiliation of an entity with a pending subscription is modified to owner or publisher, the service SHOULD automatically approve the subscription request and remove the entity's previous request from the pending list. Similarly, if the affiliation of an entity with a pending subscription is modified to outcast, the service SHOULD automatically reject the subscription request and remove the entity's previous request from the pending list. (If an entity's subscription request is denied, the service SHOULD send a &MESSAGE; to the entity, where the message conforms to the format described in the Notification of Subscription State Changes section of this document.)

A node owner may want to edit the list of subscriptions associated with a given node. Support for this feature ("pubsub#manage-subscriptions") is OPTIONAL.

First the owner retrieves the subscriptions list.

In order to request a list of all subscriptions, a node owner MUST send a subscriptions request, consisting of a <subscriptions/> element whose 'node' attribute specifies the NodeID of the relevant node.

]]>

If no error occurs, the service MUST return the list of subscriptions for entities whose subscription state is "subscribed" or "unconfigured" (it MUST NOT return entities whose subscription state is "none" and SHOULD NOT return entities whose subscription state is "pending"). The result MAY specify multiple <subscription/> elements for the same entity (JID), but each element MUST possess a distinct value of the 'subid' attribute (as shown below).

]]>

There are several reasons why the manage subscriptions request might fail:

  1. The service does not support subscription management.
  2. The requesting entity does not have sufficient privileges to manage subscriptions.
  3. The specified node does not exist.

These error cases are described more fully in the following sections.

If an implementation does not support subscription management, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "manage-subscriptions".

]]>

If the requesting entity is not a node owner, the service MUST return a &forbidden; error.

]]>

If the node does not exist, the service MUST return an ¬found; error.

]]>

Upon receiving the subscriptions list, the node owner MAY modify subscription states. The owner MUST send only modified subscription states (i.e., a "delta"), not the complete list. (Note: If the 'subscription' attribute is not specified in a modification request, then the value MUST NOT be changed.)

]]>
]]>

There are several reasons why the modify subscriptions request might fail:

  1. The service does not support subscription management.
  2. The requesting entity does not have sufficient privileges to manage subscriptions.
  3. The specified node does not exist.

These error cases are described more fully in the following sections.

If an implementation does not support subscription management, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "manage-subscriptions".

]]>

If the requesting entity is not a node owner, the service MUST return a &forbidden; error.

]]>

If the node does not exist, the service MUST return an ¬found; error.

]]>

The owner MAY change multiple subscriptions in a single request. If one of the entity elements specified is invalid, the service MUST return an IQ error (which SHOULD be ¬acceptable;) with the invalid entries, where the subscription returned is the original, un-altered subscription.

]]> ]]>

If errors occur during a modification request for multiple entities, the pubsub service MUST return any <subscription/> element(s) which caused the error. Returned entities which failed to be modified MUST include the existing 'subscription' attribute. Any entity elements which are not returned in an IQ error case MUST be treated as successful modifications. The owner MAY specify multiple <subscription/> elements for the same entity, but each element MUST possess a distinct value of the 'subid' attribute.

In order to remove an entity from the subscriptions list, the owner MUST set the value of the 'subscription' attribute to "none" and the service MUST remove that entity from the subscriptions list and not return it in response to future list requests.

An implementation SHOULD notify an entity whose subscription has changed (see the Notification of Subscription State Changes section of this document).

]]>

A node owner may want to manage the affiliations of entities associated with a given node and to set affiliations for new entities. Support for this feature ("pubsub#modify-affiliations") is OPTIONAL.

First the owner retrieves the affiliation list.

In order to request a list of all affiliated entities, a node owner MUST send an affiliations request, consisting of an <affiliations/> element whose 'node' attribute specifies the NodeID of the relevant node.

]]>

If no error occurs, the service MUST return the list of entities whose affiliation is "owner", "member", "publisher", "publish-only", or "outcast" (it MUST NOT return entities whose affiliation is "none").

]]>

There are several reasons why the affiliated entities request might fail:

  1. The service does not support modification of affiliations.
  2. The requesting entity does not have sufficient privileges to modify affiliations.
  3. The specified node does not exist.

These error cases are described more fully in the following sections.

If an implementation does not support modification of affiliations, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "modify-affiliations".

]]>

If the requesting entity is not a node owner, the service MUST return a &forbidden; error.

]]>

If the node does not exist, the service MUST return an ¬found; error.

]]>

A node owner may want to edit the affiliation of an entity associated with a given node or to set the affiliation for a new entity.

In order to modify an affiliation, a node owner MUST send an IQ set containing the modified affiliation or affiliations. The owner MUST send only modified affiliations (i.e., a "delta"), not the complete list. (Note: If the 'affiliation' attribute is not specified in a modification request, then the value MUST NOT be changed.)

]]>
]]>

There are several reasons why the modify-affiliations request might fail:

  1. The requested affiliation is not supported by the node or service.
  2. The service does not support modification of affiliations.
  3. The requesting entity does not have sufficient privileges to modify affiliations.
  4. The specified node does not exist.

These error cases are described more fully in the following sections.

If an implementation does not support modification of affiliations, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "modify-affiliations".

]]>

If the node or service does not support the requested affiliation, it MUST return a &feature; error, specifying a pubsub-specific error condition of <unsupported/> and a feature of "member-affiliation", "outcast-affiliation", "publisher-affiliation", or "publish-only-affiliation" as appropriate.

]]>

If the requesting entity is not a node owner, the service MUST return a &forbidden; error.

]]>

If the node does not exist, the service MUST return an ¬found; error.

]]>

The owner MAY change multiple affiliations in a single request. If one of the entity elements specified is invalid, the service MUST return an IQ error (which SHOULD be ¬acceptable;) with the invalid entries, where the affiliation returned is the original, un-altered affiliation.

The following example shows an entity attempting to make the owner something other than an affiliation of "owner", an action which MUST NOT be allowed if there is only one owner.

]]> ]]>

The state chart at the beginning of this document is a MUST-IMPLEMENT set of rules for checking possible state transitions. Implementations MAY enforce other (more strict) rules. If errors occur during a modification request for multiple entities, the pubsub service MUST return any <affiliation/> element(s) which caused the error. Returned entities which failed to be modified MUST include the existing 'affiliation' attribute. Any entity elements which are not returned in an IQ error case MUST be treated as successful modifications. The owner MUST NOT specify multiple <affiliation/> elements for the same entity; otherwise the service MUST return a &badrequest; error.

In order to remove an entity from the affiliations list, the owner MUST set the value of the 'affiliation' attribute to "none" and the service MUST remove that entity from the affiliations list and not return it in response to future list requests.

An implementation MAY send an event notification to an entity whose affiliation has changed, which MAY contain a &BODY; element specifying natural-language text regarding the affiliation change and which SHOULD contain the modified affiliation data.

]]>

Publish-subscribe functionality can be integrated into existing instant messaging and presence services (see RFC 3921), such that each registered account functions as a virtual pubsub service (sometimes called "pubsub-on-a-JID"). In such deployments, the root pubsub node for each virtual pubsub service has the same address as the bare JID &BAREJID; of the account, which is typically associated with an IM user (e.g., <hamlet@denmark.lit>). Since an IM user typically has a roster of "buddies" and shares presence information with those buddies, the virtual pubsub service can use roster and presence information to provide some helpful shortcuts for subscribers, in particular the auto-subscribe and filtered-notifications features described in this section.

Note: PEP ties the receipt of PEP notifications to the subscriber's presence, but does not tie the generation of PEP notifications to the publisher's presence. If the publisher wishes to stop generating PEP events (or to generate an "empty" event as can be done for some PEP payloads) before ending its presence session, the publisher MUST direct its client to do so and MUST NOT depend on the PEP service to automatically "zero out" its PEP information when the PEP service receives unavailable presence from the publisher.

If an instant messaging and presence account is also a virtual pubsub service, service discovery information ("disco#info") responses from the bare JID of the account MUST include a feature of "http:/jabber.org/protocol/pubsub#pubsub-on-a-jid":

]]>

Note: Because the account owner's bare JID is the default destination address for any stanzas a client generates, clients often omit the "to" attribute on such stanzas; on this point, see RFC 6120 and (with regard to rosters) RFC 6121.

When a contact is affiliated with the account owner through sharing of XMPP presence, the "auto-subscribe" feature greatly simplifies the subscription process. In particular, support for the "auto-subscribe" has the following implications:

Because the account owner itself is implicitly subscribed to its own XMPP presence (e.g., each XMPP resource receives presence information from all of the account owner's resources), a service MUST consider the account owner to have a pubsub subscription to the account owner's root collection node with a subscription_type of "items" and a subscription_depth of "all". This is true for all access models.

If an entity (i.e., an IM contact) has an XMPP presence subscription to the account owner's bare JID &BAREJID;, a service MUST consider the contact to have a pubsub subscription to the account owner's root collection node with a subscription_type of "items" and a subscription_depth of "all" if:

  1. The node has an access model of "open".
  2. The node has an access model of "presence".
  3. The node has an access model of "roster" and the contact is in the specified roster group.

If the contact does not have permission to receive information from any of the account owner's particular nodes below the level of the root collection node (e.g., because a particular node has an access model of "roster" but the contact is not in the specified roster group), the service MUST NOT send notifications regarding that node to the contact and also MUST NOT return any errors to the contact regarding a potential implicit subscription to that node (e.g., the service MUST NOT return a pubsub subscription error to the contact when the contact sends presence to the account owner).

Note: When an IM contact has a subscription to the account owner's presence, the automated pubsub subscription MUST be based on the JID contained in the 'from' address of the presence subscription request, which for an IM contact will be a bare JID &BAREJID;.

If the node has an open access model, the pubsub service SHOULD also consider an entity to be temporarily and implicitly subscribed to the node if the entity has sent presence to the account owner in the absence of a presence subscription. In this case, the subscription SHOULD be based on the 'from' address of the presence stanza, which will be a full JID &FULLJID;. When the service receives unavailable presence from the full JID, it MUST cancel the temporary subscription.

A contact might not want to receive notifications for all the nodes hosted at a user's virtual pubsub service. A contact SHOULD signal its preferences to the account owner's server by including XEP-0115 information that specifies the NodeIDs for which the contact wishes to receive notifications (if any). This information is used by a pubsub service that supports the "filtered-notifications" feature to send notifications only from those NodeIDs that match the subscriber's preferences.

In order to make this possible, all possible NodeIDs can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the specified NodeID. Thus if Romeo wants to receive notifications for location data (&xep0080;) and tune data (&xep0118;) but not activity data (&xep0108;), his client would advertise support for the following strings in the disco#info results it sends: Including, say, the 'http://jabber.org/protocol/geoloc' NodeID indicates that the client understands the geolocation namespace described in XEP-0080, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation, where the NodeID is the same as the geolocation namespace 'http://jabber.org/protocol/geoloc' (in this case there is a one-to-one correspondence between the namespace name and the NodeID).

  • http://jabber.org/protocol/geoloc+notify
  • http://jabber.org/protocol/tune+notify

This set of strings would then be advertised by including them in the identity+features hash encapsulated via the 'ver' attribute as described in XEP-0115.

]]>

It is the responsibility of the account owner's server to cache XEP-0115 information. When the server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired NodeIDs for the contact's client. The server MUST NOT send notifications related to any NodeIDs that the contact's client has not asked for via the relevant "NodeID+notify" disco#info feature. This enables a client to turn off all notifications (e.g., because of bandwidth restrictions) and to easily receive all desired data formats simply by adding support for the appropriate "NodeID+notify" combination in its disco#info results and client capabililies. However, it also implies that a client can request notifications only on a global basis and cannot request, say, mood information only from certain contacts in the user's roster. Community consensus is that this is an acceptable tradeoff. Also, note that this works only if the account owner has a presence subscription to the contact and the contact has a presence subscription to the account owner.

Some examples may help to illustrate the concept of notification filtering. Here we show presence generated by two of the contacts listed above (benvolio@montague.lit does not have any presence subscriptions to or from juliet@capulet.lit and therefore is not involved in these protocol flows).

]]>

We assume that Juliet's server doesn't know anything about these capabilities, so it sends service discovery information requests to each of the clients on Juliet's behalf (realistically, the capulet.lit server will quickly build up a cache of client capabilities, with the result that it will not need to send these service discovery requests):

]]>

The server shall also query the identity+features for <romeo@montague.lit>:

]]>

(As noted in XEP-0115, the server MUST check the hash provided in the 'ver' attribute against the generation method to ensure that no poisoning has occurred.)

Now we revisit account owner publication and server generation of notifications, with filtering enabled because the server has caps information:

  • If Juliet publishes a tune item to the presence-access "http://jabber.org/protocol/tune" node, her server will send notifications to <nurse@capulet.lit/chamber> and <romeo@montague.lit/orchard> (full JIDs).

  • If Juliet publishes an activity item to the presence-access "http://jabber.org/protocol/activity" node, her server will send notifications only to <nurse@capulet.lit/chamber>.

  • If Juliet publishes a geolocation item to the roster-access "http://jabber.org/protocol/geoloc" node with the "pubsub#roster_groups_allowed" variable set to a value of "Friends", her server will send notifications only to <romeo@montague.lit/orchard> because the nurse is not in that roster group.

This section summarizes the features described herein, specifies the appropriate requirements level for each feature (REQUIRED, RECOMMENDED, or OPTIONAL), and provides cross-references to the section of this document in which each feature is described.

Note: The feature names are all of the form "http://jabber.org/protocol/pubsub#name", where "name" is the text specified in the first column below.

Name Description Support Section
access-authorize The default access model is "authorize". OPTIONAL Nodes Access Models
access-open The default access model is "open". OPTIONAL Nodes Access Models
access-presence The default access model is "presence". OPTIONAL Nodes Access Models
access-roster The default access model is "roster". OPTIONAL Nodes Access Models
access-whitelist The default access model is "whitelist". OPTIONAL Nodes Access Models
auto-create The service supports auto-creation of nodes on publish to a non-existent node. OPTIONAL Automatic Node Creation
auto-subscribe The service supports auto-subscription to a nodes based on presence subscription. RECOMMENDED Auto-Subscribe
collections Collection nodes are supported. OPTIONAL Refer to XEP-0248
config-node Configuration of node options is supported. RECOMMENDED Configure a Node
create-and-configure Simultaneous creation and configuration of nodes is supported. RECOMMENDED Create and Configure a Node
create-nodes Creation of nodes is supported. RECOMMENDED Create a Node
delete-items Deletion of items is supported. RECOMMENDED Delete an Item from a Node
delete-nodes Deletion of nodes is supported. RECOMMENDED Delete a Node
filtered-notifications Notifications are filtered based on Entity Capabilities data. RECOMMENDED Filtered Notifications
get-pending Retrieval of pending subscription approvals is supported. OPTIONAL Manage Subscription Requests
instant-nodes Creation of instant nodes is supported. RECOMMENDED Create a Node
item-ids Publishers may specify item identifiers. RECOMMENDED  
last-published By default the last published item is sent to new subscribers and on receipt of available presence from existing subscribers. RECOMMENDED Event Types
leased-subscription Time-based subscriptions are supported. OPTIONAL Time-Based Subscriptions (Leases)
manage-subscriptions Node owners may manage subscriptions. OPTIONAL Manage Subscriptions
member-affiliation The member affiliation is supported. RECOMMENDED Affiliations
meta-data Node meta-data is supported. RECOMMENDED  
modify-affiliations Node owners may modify affiliations. OPTIONAL Manage Affiliations
multi-collection A single leaf node can be associated with multiple collections. OPTIONAL Refer to XEP-0248
multi-items The service supports the storage of multiple items per node. It requires the pubsub#max_items configuration item to be exposed to the user and allow sensible values (higher than one) to be set in Configure a Node. OPTIONAL  
multi-subscribe A single entity may subscribe to a node multiple times. OPTIONAL Multiple Subscriptions
outcast-affiliation The outcast affiliation is supported. RECOMMENDED Affiliations
persistent-items Persistent items are supported. RECOMMENDED  
presence-notifications Presence-based delivery of event notifications is supported. OPTIONAL  
presence-subscribe Authorized contacts are automatically subscribed to a user's virtual pubsub service. RECOMMENDED Auto-Subscribe
publish Publishing items is supported. REQUIRED Publish an Item to a Node
publish-options Publishing an item with options is supported. OPTIONAL Publishing Options
publish-only-affiliation The publish-only affiliation is supported. OPTIONAL Affiliations
publisher-affiliation The publisher affiliation is supported. RECOMMENDED Affiliations
purge-nodes Purging of nodes is supported. OPTIONAL Purge All Node Items
retract-items Item retraction is supported. OPTIONAL Delete an Item from a Node
retrieve-affiliations Retrieval of current affiliations is supported. RECOMMENDED Retrieve Affiliations
retrieve-default Retrieval of default node configuration is supported. RECOMMENDED Request Default Node Configuration Options
retrieve-default-sub Retrieval of default subscription configuration is supported. OPTIONAL Request Default Subscription Configuration Options
retrieve-items Item retrieval is supported. RECOMMENDED Retrieve Items from a Node
retrieve-subscriptions Retrieval of current subscriptions is supported. RECOMMENDED Retrieve Subscriptions
subscribe Subscribing and unsubscribing are supported. REQUIRED Subscribe to a Node and Unsubscribe from a Node
subscription-options Configuration of subscription options is supported. OPTIONAL Configure Subscription Options
subscription-notifications Notification of subscription state changes is supported. OPTIONAL Notification of Subscription State Changes
Condition Description
&conflict; The node already exists.
&feature; The operation being attempted on a node (or the system) has failed because the service or node does not support the operation; the error SHOULD also specify which feature is unsupported.
&forbidden; An entity does not have sufficient privileges to perform the action, is requesting an operation for another Jabber ID (e.g., francisco@denmark.lit attempts to subscribe bernardo@denmark.lit to a node), or the requesting entity has an affiliation of "outcast".
¬found; The node or item specified for some operation does not exist.
¬allowed; An entity has attempted to perform an action which the service implements; however the service-wide admin or the node owner has disabled the action for that service or node.
¬authorized; An entity has attempted to subscribe to or retrieve items from a node but is not authorized to see the account owner's presence, is not in the appropriate roster group, or is not on the whitelist for subscriptions.
&payment; Subscriptions and item retrieval are based on some kind payment service. Payments would be done out-of-band using some agreed-upon method (not defined herein).
®istration; Entities are required to register before node creation is allowed.

Note: Refer to &xep0086; for more information regarding error syntax.

There are many possible triggers for sending an event notification to an entity for the currently published item or the last published item, as summarized below:

  1. The entity explicitly requests one or more items from the node and is authorized to retrieve items; when the service receives such a request, it sends the items to the entity.
  2. The entity is an authorized subscriber to the node (explicitly via subscription or implicitly based on a role of owner or publisher); when the publisher sends a publish request, the service sends the currently published item to the entity (subject to presence checks and notification filtering if appropriate).
  3. The entity is not subscribed but is eligible to do so and has sent presence containing appropriate entity capabilities data to a service that supports filtered notifications (effectively establishing a "temporary subscription" based on an expressed notification interest); when the service first receives such presence, it sends the last published item to the entity (sending it only once upon first receiving such presence, not on subsequent presence updates that contain the same notification interest).
  4. The entity is not subscribed but is eligible to do so and has sent presence containing appropriate entity capabilities data to a service that supports filtered notifications (effectively establishing a "temporary subscription"); when the publisher sends a publish request that matches the entity's expressed notification interest, the service sends the currently published item to the entity.
  5. The entity gains access to the node because of a change to the node access model; as a result, the service sends the last published item to the entity.
  6. The entity is added to the roster group associated with a node access model of "roster"; as a result, the service sends the last published item to the entity.

When a pubsub service generates notifications, it MUST adhere to the delivery rules implicit in the subscription option configuration for each subscriber. In particular, the 'to' address SHOULD be that of the subscribed JID only. The service SHOULD NOT attempt to guess at the most available resource associated with the subscribed JID (e.g., in the context of instant messaging systems).

As noted above, a pubsub service SHOULD ensure that the &MESSAGE; stanza for each event notification it generates possesses an 'id' attribute with a value. (This notification ID is not to be confused with either the node ID or the item ID.) This ID MUST be unique within the context of the pubsub service in order to ensure proper tracking of any delivery-related errors.

Exactly how a service shall handle delivery-related errors is a matter of implementation. In general, such handling is effectively similar to the bounce processing performed by other message delivery systems, such as mail transfer agents and mailing list software. The following are some suggested guidelines regarding the handling of XMPP-specific error conditions in relation to pubsub event notifications (see RFC 3920 and XEP-0086 regarding XMPP error condition semantics):

  • If the XMPP error is of type "cancel" (e.g., ¬found;), or the error condition is &gone;, the pubsub service SHOULD terminate the subscription of the entity to that node and MAY terminate the subscription of that entity to all nodes hosted at the service.
  • If the XMPP error is of type "auth" (e.g., ®istration;) or "wait" (e.g., &timeout;), or the error condition is &badrequest;, &redirect;, or ¬acceptable;, the pubsub service SHOULD increment a bounce counter for that entity and MAY attempt to resend the event notification after some configurable amount of time. The service MAY terminate the subscription of the entity to that node if the bounce counter has reached some configurable limit.

An implementation 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 MUST set the "pubsub#expire" subscription configuration option to a literal value of "presence".

http://jabber.org/protocol/pubsub#subscribe_options ... presence ... ]]>

The service will then automatically cancel the subscription when it receives presence of type "unavailable" from the subscriber.

An implementation MAY enable the node owner to force all subscriptions to be temporary, which is useful for nodes that are also configured to use presence-based delivery. This setting uses the "pubsub#tempsub" node configuration option set to a value of true.

http://jabber.org/protocol/pubsub#node_config true ]]>

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.

Sending events to users of existing XMPP 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:

  • Use presence-based subscription options as described above.
  • Use delivery semantics as defined by &xep0079;.
  • Specify a message type of "headline", which in most existing server implementations will prevent offline storage.

If a service understands the semantics for a particular payload type and an entity's subscription is so configured (by the "pubsub#include_body" subscription option to true), the service SHOULD include an appropriate XMPP &BODY; child element along with the payloads it sends in event notifications for a given node, where the body's XML character data summarizes or represents the information contained in the payload (this enables clients that do not understand the payload format to present the appropriate information to an end user). For example, the Atom <summary/> element (see RFC 4287) could be mapped to the XMPP &BODY; element. A service MUST NOT provide the "pubsub#include_body" subscription option for a node if it does not have a defined way to transform part or all of the payload format into a sensible message body. A node owner MAY define an XSLT for transforming the payload format into a message body, via the "pubsub#body_xslt" node configuration option. This XSLT is applied by the pubsub service after receiving a publish request and before sending the appropriate notifications, not by the client before sending a publish request.

If the service does not understand the semantics for a particular payload type and therefore cannot transform the payload into a human-readable message body, it SHOULD NOT include a <body/> child.

If a subscriber has multiple subscriptions to the same node, where some of the SubIDs have include_body set to true and others have include_body set to false, the service SHOULD include a body with all notifications.

NodeIDs MUST be treated as unique identifiers within the context of a particular pubsub service.

If item identifiers are used, they MUST be treated as unique within the scope of the node. The combination of the NodeID + ItemID MUST be unique within a given service, and MUST specify a single published item at a single node.

If a publisher publishes an item and the ItemID matches that of an existing item, the pubsub service MUST overwrite the existing item and generate a new event notification.

Because it is possible for a node's configuration to change such that ItemIDs are required (e.g., a change from transient to persistent), a service SHOULD use ItemIDs for internal tracking purposes even if it does not include them with the notifications it generates prior to the configuration change.

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: 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.

How subscription requests are sent to node owners is a matter of implementation. Possibilities include:

  • Send requests to all owners (these may be placed in offline storage as described in XEP-0160) and first approval wins.
  • The service could subscribe to owner presence, and send only to the owners that are online.
  • All owners vote on the new subscriber.
  • Any owner is allowed to veto the subscriber.

An implementation MAY use any of these methods, or some other method not defined herein.

Various actions and events may result in changes to a subscription state:

  • Approval or denial of a subscription request as described in the Manage Subscription Requests use case

  • Cancellation of an existing subscription, for which many "triggers" are possible:

    • The entity simply unsubscribes from the node
    • The node is of type "presence" and the underlying presence subscription is cancelled
    • The node is of type "roster" and the entity is moved to an unauthorized roster group

When a subscription state change occurs, a service SHOULD send a message to the (new, former, or denied) subscriber informing it of the change, where the message contains an <event/> element with a single <subscription/> child that specifies the node, JID, and subscription state. The notification MAY contain a &BODY; element specifying natural-language text regarding the subscription change. The JID to which the service sends the notification is the address that was set in the 'jid' attribute of the subscription request. Examples are shown below.

]]> ]]>

If the service has knowledge of the (former or denied) subscriber's presence, it SHOULD send the message to all of the subscriber's resources; if not, it MUST send the message to the subscriber's affiliated JID.

If a service or node supports this feature, it MUST return a feature of "subscription-notifications" in its response to service discovery information requests.

NodeIDs MAY have semantic meaning in particular profiles, implementations, or deployments of pubsub. However, it is STRONGLY RECOMMENDED that such semantic meaning not be used to encapsulate the hierarchical structure of nodes; instead, node hierarchy SHOULD be encapsulated using collections and their associated child nodes as described in XEP-0248.

When SubIDs are used, Stanza Headers and Internet Metadata (SHIM) headers are to be included in order to differentiate notifications sent regarding a particular subscription. The relevant use cases and scenarios are:

  • Sending notifications regarding newly-published items as described in the Publish an Item to a Node use case.
  • Sending notifications regarding deleted items as described in the Delete an Item from a Node use case.

The SHIM headers are generated by the node to which the subscriber has a subscription, which may be either a leaf node or a collection node (refer to XEP-0248).

SHIM headers are not to be included when the content does not differ based on subscription ID, e.g., when a node sends notification of a configuration change to the node itself, notification that the node has been purged, or notification that the node has been deleted.

An implementation MAY enable the node configuration to specify an association between the event notification and the entity to which the published information pertains, but such a feature is OPTIONAL. Here are some possible examples:

  • In the context of a geolocation notification service using &xep0080;, the user may generate the geolocation information or the information may be generated by an automated service (e.g., a service offered by a mobile telephony provider), but in either case the information is about the user's geolocation and therefore all replies should go to the user (who is probably the node owner).
  • In the context of a group weblog, different users might publish to the weblog and replies might go to the publisher of an entry rather than to the weblog owner.
  • In the context of an integrated pubsub and multi-user chat system, the node owner might be the room owner but all replies need to be sent to the room rather than to the owner.

Therefore we define the "itemreply" node configuration option, with two possible values:

  • "owner" (i.e., the node owner or an alias for the node owners)
  • "publisher" (i.e., the item publisher)

A node owner MUST NOT define more than one of these options.

An example is shown below.

Venice 45.44 12.33 ]]>

Alternatively, if a service implements the personal eventing subset of this protocol, the virtual pubsub service is the account owner's bare JID and notifications are sent from that JID; for details, refer to XEP-0163.

The word "chaining" refers to the practice of subscribing one node to another node. For instance, consider a scenario in which the node <pubsub@example.net/NewsBroadcaster> wants to distribute information received from the node "NewsFeed" at <pubsub.example.com>. While it is theoretically possible for <pubsub@example.net/NewsBroadcaster> to directly subscribe to the NewsFeed node (since the former node is directly addressable as a JID), implementations MUST NOT chain nodes in this fashion. Instead, implementations MUST subscribe from the address of the pubsub service rather than the node (in the example shown here, the subscription would be sent from <pubsub@example.net> rather than <pubsub@example.net/NewsBroadcaster>).

In some systems it may be desirable to provide a subscription "leasing" feature in order to expire old or stale subscriptions. Leases can be implemented using configurable subscription options; specifically, when an entity subscribes, the service would require configuration of subscription options and the configuration form would contain a field of "pubsub#expire". This field MUST contain a dateTime (as specified in &xep0082;).

The leasing process is shown below.

http://jabber.org/protocol/pubsub#subscribe_options ... ... http://jabber.org/protocol/pubsub#subscribe_options ... 2006-02-28T11:59:59Z ... ]]>

The service MAY send a message to the subscriber when the lease is almost over (e.g., 24 hours before the end of the lease term). This MUST be done by sending a &MESSAGE; containing a <subscription/> element qualified by the 'http://jabber.org/protocol/pubsub#event' namespace and including an 'expiry' attribute.

]]>

When the subscriber wants to renew the lease, it would get the current subscription options, change the value of the "pubsub#expire" field, and submit the new subscription options back to the service. If the new expire value exceeds the maximum value allowed for subscription leases, the service MUST change the value of the field to be the current date/time plus the maximum allowed lease period.

http://jabber.org/protocol/pubsub#subscribe_options ... ... http://jabber.org/protocol/pubsub#subscribe_options ... 2006-03-31T23:59:59Z ... ]]>

A service MAY enable entities to subscribe to nodes and apply a filter to notifications (e.g., keyword matching such as "send me all news entries from Slashdot that match the term 'XMPP'"). Such a content-based service SHOULD allow an entity to subscribe more than once to the same node and, if so, MUST use subscription identifiers (SubIDs) to distinguish between multiple subscriptions. In order to prevent collisions, a service that supports content-based subscriptions using SubIDs SHOULD generate SubIDs on behalf of subscribers rather than allowing subscribers to set their own SubIDs. Another way to implement content-based subscriptions is to host one node per keyword or other filter; however, this is likely to require an extremely large number of nodes.

Content-based services SHOULD use subscription options to specify the filter(s) to be applied. Because there many possible filtering mechanisms (many of which may be application-specific), this document does not define any such method. However, filtering mechanisms may be defined in separate specifications.

A fictional example of the subscription options configuration process for content-based pubsub is shown below.

http://jabber.org/protocol/pubsub#subscribe_options ... ... http://jabber.org/protocol/pubsub#subscribe_options ... peasant ... ]]>

The subscriber will then be notified about events that match the keyword.

Alone Now I am alone. O, what a rogue and peasant slave am I! tag:denmark.lit,2003:entry-32396 2003-12-13T11:09:53Z 2003-12-13T11:09:53Z
991d7fd1616fd041015064133cd097a10030819e
]]>

For some nodes, it is desirable to have at most one item associated with the node at any one time (for example, a client may want to store its preferences using a node name that is a namespace controlled by that client). When this pattern is desired, it is RECOMMENDED for the publisher to specify an ItemID of "current" to ensure that the publication of a new item will overwrite the existing item.

]]>

Naturally, the node owner can enforce the singleton node pattern by setting the max_items configuration option to "1".

An XMPP URI (see &rfc5122;) can be used for the purpose of identification or interaction. Some examples are provided below.

The following URI merely identifies a pubsub node.

The following URI identifies a specific item at a node.

The following URI defines how to subscribe to a node (for details, see the URI Query Types section of this document).

The following URI defines how to retrieve a specific item from a node.

The Data Forms shown in this specification include English-language labels for various fields; implementations that will display such forms to human users SHOULD provide localized label text for fields that are defined for the registered FORM_TYPEs.

The data published to a pubsub node might contain sensitive information (e.g., a user's geolocation). Therefore, node owners SHOULD exercise care in approving subscription requests. Security considerations regarding particular kinds of information are the responsibility of the "using protocol".

XMPP PubSub contains a hierarchy of affiliations for the purpose of authorization and access control. A service MUST NOT allow non-owners or other unauthorized entities to complete any actions defined under the Owner Use Cases section of this document.

A service MUST adhere to the defined access model in determining whether to send event notifications or payloads to an entity, or allow an entity to retrieve items from a node. A service MAY enforce additional privacy and security policies when determining whether an entity is allowed to subscribe to a node or retrieve items from a node; however, any such policies shall be considered specific to an implementation or deployment and are out of scope for this document.

In the context of instant messaging systems it is possible for the act of publishing an item to reveal the node owner or item publisher's network availability. However, this risk is mitigated by the following factors:

  1. A node does not necessarily reveal the existence of the publishing entity.
  2. XMPP PubSub systems are not necessarily tied to instant messaging systems.
  3. Even in the context of IM systems, a node provides information distinct from network availability (e.g., user tunes).
  4. Even then, the actual publisher might not be an IM user (e.g., an automated calendaring or geolocation system).

This document does not require interaction with &IANA;.

The ®ISTRAR; includes the following namespaces in its registry of protocol namespaces (see &NAMESPACES;):

  • http://jabber.org/protocol/pubsub
  • http://jabber.org/protocol/pubsub#errors
  • http://jabber.org/protocol/pubsub#event
  • http://jabber.org/protocol/pubsub#owner

The XMPP Registrar includes a category of "pubsub" in its registry of Service Discovery identities (see &DISCOCATEGORIES;), as well as three specific types within that category:

collection A pubsub node of the "collection" type as described in XEP-0248.
leaf A pubsub node of the "leaf" type as described in XEP-0060.
service A pubsub service that supports the functionality defined in XEP-0060. Prior to version 1.5 of XEP-0060, this type was called "generic".

The registry submission is as follows:

pubsub Services and nodes that adhere to XEP-0060. collection A pubsub node of the "collection" type. XEP-0248 leaf A pubsub node of the "leaf" type. XEP-0060 service A pubsub service that supports the functionality defined in XEP-0060. XEP-0060 ]]>

Future submissions to the XMPP Registrar may register additional types.

The XMPP Registrar maintains a registry of service discovery features (see &DISCOFEATURES;), which includes a number of features that may be returned by pubsub services. The following registry submission has been provided to the XMPP Registrar for that purpose.

http://jabber.org/protocol/pubsub#access-authorize The default node access model is authorize. XEP-0060 http://jabber.org/protocol/pubsub#access-open The default node access model is open. XEP-0060 http://jabber.org/protocol/pubsub#access-presence The default node access model is presence. XEP-0060 http://jabber.org/protocol/pubsub#access-roster The default node access model is roster. XEP-0060 http://jabber.org/protocol/pubsub#access-whitelist The default node access model is whitelist. XEP-0060 http://jabber.org/protocol/pubsub#auto-create The service supports automatic creation of nodes on first publish. XEP-0060 http://jabber.org/protocol/pubsub#auto-subscribe The service supports automatic subscription to a nodes based on presence subscription. XEP-0060 http://jabber.org/protocol/pubsub#collections Collection nodes are supported. XEP-0248 http://jabber.org/protocol/pubsub#config-node Configuration of node options is supported. XEP-0060 http://jabber.org/protocol/pubsub#create-and-configure Simultaneous creation and configuration of nodes is supported. XEP-0060 http://jabber.org/protocol/pubsub#create-nodes Creation of nodes is supported. XEP-0060 http://jabber.org/protocol/pubsub#delete-items Deletion of items is supported. XEP-0060 http://jabber.org/protocol/pubsub#delete-nodes Deletion of nodes is supported. XEP-0060 http://jabber.org/protocol/pubsub#filtered-notifications The service supports filtering of notifications based on Entity Capabilities. XEP-0060 http://jabber.org/protocol/pubsub#get-pending Retrieval of pending subscription approvals is supported. XEP-0060 http://jabber.org/protocol/pubsub#instant-nodes Creation of instant nodes is supported. XEP-0060 http://jabber.org/protocol/pubsub#item-ids Publishers may specify item identifiers. XEP-0060 http://jabber.org/protocol/pubsub#last-published The service supports sending of the last published item to new subscribers and to newly available resources. XEP-0060 http://jabber.org/protocol/pubsub#leased-subscription Time-based subscriptions are supported. XEP-0060 http://jabber.org/protocol/pubsub#manage-subscriptions Node owners may manage subscriptions. XEP-0060 http://jabber.org/protocol/pubsub#member-affiliation The member affiliation is supported. XEP-0060 http://jabber.org/protocol/pubsub#meta-data Node meta-data is supported. XEP-0060 http://jabber.org/protocol/pubsub#modify-affiliations Node owners may modify affiliations. XEP-0060 http://jabber.org/protocol/pubsub#multi-collection A single leaf node can be associated with multiple collections. XEP-0060 http://jabber.org/protocol/pubsub#multi-items The service supports the storage of multiple items per node. XEP-0060 http://jabber.org/protocol/pubsub#multi-subscribe A single entity may subscribe to a node multiple times. XEP-0060 http://jabber.org/protocol/pubsub#outcast-affiliation The outcast affiliation is supported. XEP-0060 http://jabber.org/protocol/pubsub#persistent-items Persistent items are supported. XEP-0060 http://jabber.org/protocol/pubsub#presence-notifications Presence-based delivery of event notifications is supported. XEP-0060 http://jabber.org/protocol/pubsub#presence-subscribe Implicit presence-based subscriptions are supported. XEP-0060 http://jabber.org/protocol/pubsub#publish Publishing items is supported. XEP-0060 http://jabber.org/protocol/pubsub#publish-options Publication with publish options is supported. XEP-0060 http://jabber.org/protocol/pubsub#publish-only-affiliation The publish-only affiliation is supported. XEP-0060 http://jabber.org/protocol/pubsub#publisher-affiliation The publisher affiliation is supported. XEP-0060 http://jabber.org/protocol/pubsub#purge-nodes Purging of nodes is supported. XEP-0060 http://jabber.org/protocol/pubsub#retract-items Item retraction is supported. XEP-0060 http://jabber.org/protocol/pubsub#retrieve-affiliations Retrieval of current affiliations is supported. XEP-0060 http://jabber.org/protocol/pubsub#retrieve-default Retrieval of default node configuration is supported. XEP-0060 http://jabber.org/protocol/pubsub#retrieve-items Item retrieval is supported. XEP-0060 http://jabber.org/protocol/pubsub#retrieve-subscriptions Retrieval of current subscriptions is supported. XEP-0060 http://jabber.org/protocol/pubsub#subscribe Subscribing and unsubscribing are supported. XEP-0060 http://jabber.org/protocol/pubsub#subscription-options Configuration of subscription options is supported. XEP-0060 http://jabber.org/protocol/pubsub#subscription-notifications Notification of subscription state changes is supported. XEP-0060 ]]>

XEP-0068 defines a process for standardizing the fields used within Data Forms scoped by a particular namespace, and the XMPP Registrar maintains a registry of such FORM_TYPES (see &FORMTYPES;). Within pubsub, there are four uses of such forms:

  1. Authorization of subscriptions using the 'http://jabber.org/protocol/pubsub#subscribe_authorization' namespace.
  2. Configuration of subscription options using the 'http://jabber.org/protocol/pubsub#subscribe_options' namespace.
  3. Configuration of a node using the 'http://jabber.org/protocol/pubsub#node_config' namespace.
  4. Setting of metadata information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.

The registry submissions associated with these namespaces are defined below.

Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of XEP-0068, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.

http://jabber.org/protocol/pubsub#subscribe_authorization XEP-0060 Forms enabling authorization of subscriptions to pubsub nodes ]]> http://jabber.org/protocol/pubsub#subscribe_options XEP-0060 Forms enabling configuration of subscription options for pubsub nodes ]]> http://jabber.org/protocol/pubsub#meta-data XEP-0060 Forms enabling setting of metadata information about pubsub nodes ]]> http://jabber.org/protocol/pubsub#node_config XEP-0060 Forms enabling configuration of pubsub nodes true 1 ]]>

The XMPP Registrar includes "Collection" and "SubID" in its registry of SHIM headers (see &SHIMHEADERS;). The registry submission is as follows:

Collection The collection via which an event notification was received from the originating node. XEP-0248
SubID A subscription identifer within the pubsub protocol. XEP-0060
]]>

Future submissions to the XMPP Registrar may register additional SHIM headers that can be used in relation to the pubsub protocol, and such submission may occur without updating this specification.

As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).

The "pubsub" querytype is defined herein for interaction with pubsub services, with three keys: (1) "action" (whose defined values are "subscribe", "unsubscribe", and "retrieve"), (2) "node" (to specify a pubsub node), and optionally "item" (to specify a particular item at a node).

]]> ]]> ]]>

The following submission registers the "pubsub" querytype.

pubsub http://jabber.org/protocol/pubsub enables interaction with a publish-subscribe service XEP-0060 action the pubsub action subscribe enables subscribing to a pubsub node unsubscribe enables unsubscribing from a pubsub node node the pubsub node ]]>
The protocol documented by this schema is defined in XEP-0060: http://xmpp.org/extensions/xep-0060.html ]]> This namespace is used for error reporting only, as defined in XEP-0060: http://xmpp.org/extensions/xep-0060.html ]]> The protocol documented by this schema is defined in XEP-0060: http://xmpp.org/extensions/xep-0060.html ]]> The protocol documented by this schema is defined in XEP-0060: http://xmpp.org/extensions/xep-0060.html ]]>

Thanks to Kirk Bateman, Robin Collier, Blaine Cook, Ovidiu Craciun, Brian Cully, Dave Cridland, Guillaume Desmottes, Gaston Dombiak, William Edney, Seth Fitzsimmons, Fabio Forno, Nathan Fritz, Julien Genestoux, Anastasia Gornostaeva, Joe Hildebrand, Curtis King, Tuomas Koski, Petri Liimatta, Tobias Markmann, Pedro Melo, Dirk Meyer, Tory Patnoe, Peter Petrov, Sonny Piers, Christophe Romain, Pavel Šimerda, Andy Skelton, Kevin Smith, Chris Teegarden, Simon Tennant, Matt Tucker, Matthew Wild, Bob Wyman, Matus Zamborsky, and Brett Zamir for their feedback.

Peter Millard, primary author of this specification from version 0.1 through version 1.7, died on April 26, 2006. The remaining co-authors are indebted to him for his many years of work on publish-subscribe technologies.