%ents; ]>
PubSub Chaining This specification defines a method for chaining pubsub nodes together, resulting in lightweight repeaters for pubsub notifications. &LEGALNOTICE; 0253 Deferred Standards Track Standards Council XMPP Core XEP-0050 XEP-0060 NOT_YET_ASSIGNED &ralphm; &stpeter; 0.2 2009-11-18 psa

Specifed protocol flow for the chained subscription.

 0.1 2008-11-13 psa

Initial published version.

 0.0.2 2008-10-07 psa

Added ofrom header to notifications.

 0.0.1 2008-08-12 rm/psa

First draft.

To enable lightweight repeaters for &xep0060; notifications, we need the ability to subscribe one pubsub node to another pubsub node. This specification defines a method for doing so, using &xep0050;.

The owner of a pubsub node can subscribe that "local" node to a "remote" node using the flow described below. In these examples, the node owner is admin@consumer.tld, the local node is weatherbot@consumer.tld/Chicagoland, and the remote node has a NodeID of "OHR" at the pubsub service notify.weather.tld.

]]>

Unless an error occurs, the service SHOULD return the appropriate form.

Chaining Request Fill out this form to complete your request. http://jabber.org/protocol/pubsub#chaining ]]> http://jabber.org/protocol/pubsub#chaining Chicagoland notify.weather.tld OHR ]]> ]]>

At this point, the service itself will subscribe to the remote node.

]]>

Now subscribers who are local to the consumer.tld XMPP service can subscribe directly to weatherbot@consumer.tld/Chicagoland instead of the remote pubsub node at notify.weather.tld. We therefore refer to weatherbot@consumer.tld/Chicagoland as a "chaining node" and the remote node as a "chained node".

When a chaining node delivers a notification to its subscribers, it SHOULD include an &xep0033; header of "ofrom" to specify the chained node or service that generated the notification (note: this header is not yet defined in XEP-0033).

message
]]>

If a pubsub service supports Ad-Hoc Commands, it MUST advertise the commands it supports via &xep0030; (as described in XEP-0050: Ad-Hoc Commands); such commands exist as well-defined discovery nodes associated with the service. In particular, if a pubsub service supports chaining it MUST advertise a command of "http://jabber.org/protocol/pubsub#chaining".

The ability to subscribe one node to another node introduces the possibility of exposing non-public information in a public way, since the access controls for the node that originates a notification might not be known or enforced by the downstream node. Therefore, the upstream node (or its owner) is advised to make a careful access decision before allowing a downstream node (or any other entity) to subscribe.

Note: The upstream node can discover the identity of the downstream node by sending a service discovery information ("disco#info") request to the downstream node, and MAY cancel or decline the downstream node's subscription if it determines that the node has an identity of "pubsub/leaf" or "pubsub/collection".

This document requires no interaction with &IANA;.

The ®ISTRAR; shall include the following information in its registries.

The XMPP Registrar shall include 'http://jabber.org/protocol/pubsub#chaining' in its registry of protocol namespaces (see &NAMESPACES;).

&xep0068; defines a process for standardizing the fields used within &xep0004; scoped by a particular namespace (see &FORMTYPES;). The reserved fields for the 'http://jabber.org/protocol/pubsub#chaining' namespace are specified below.

http://jabber.org/protocol/pubsub#chaining XEP-0253 Forms used for chaining of pubsub nodes. ]]>

Thanks to Joe Hildebrand for his feedback.