<abstract>This specification defines a method for chaining pubsub nodes together, resulting in lightweight repeaters for pubsub notifications.</abstract>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2008-10-07</date>
<initials>psa</initials>
<remark><p>Added ofrom header to notifications.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2008-08-12</date>
<initials>rm/psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>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;.</p>
</section1>
<section1topic='How It Works'anchor='howitworks'>
<p>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.</p>
<p>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".</p>
<p>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 <cite>XEP-0033</cite>).</p>
<p>If a pubsub service supports Ad-Hoc Commands, it MUST advertise the commands it supports via &xep0030; (as described in <cite>XEP-0050: Ad-Hoc Commands</cite>); 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".</p>
<p>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.</p>
<p>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".</p>
<p>&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.</p>