mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-25 10:42:19 -05:00
5b5048be87
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3643 4b5297f7-1745-476d-ba37-a9c6900126ab
225 lines
9.2 KiB
XML
225 lines
9.2 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>PubSub Chaining</title>
|
|
<abstract>This specification defines a method for chaining pubsub nodes together, resulting in lightweight repeaters for pubsub notifications.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0253</number>
|
|
<status>Experimental</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XEP-0050</spec>
|
|
<spec>XEP-0060</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
|
&ralphm;
|
|
&stpeter;
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2009-11-18</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Specifed protocol flow for the chained subscription.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2008-11-13</date>
|
|
<initials>psa</initials>
|
|
<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>
|
|
|
|
<section1 topic='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>
|
|
|
|
<section1 topic='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>
|
|
<example caption='Owner requests chaining'><![CDATA[
|
|
<iq from='admin@consumer.tld/client'
|
|
id='chaining-1'
|
|
to='weatherbot@consumer.tld'
|
|
type='set'
|
|
xml:lang='en'>
|
|
<command xmlns='http://jabber.org/protocol/commands'
|
|
action='execute'
|
|
node='http://jabber.org/protocol/pubsub#chaining'/>
|
|
</iq>
|
|
]]></example>
|
|
<p>Unless an error occurs, the service SHOULD return the appropriate form.</p>
|
|
<example caption='Service returns chaining form to node owner'><![CDATA[
|
|
<iq from='weatherbot@consumer.tld'
|
|
id='chaining-1'
|
|
to='admin@consumer.tld/client'
|
|
type='result'
|
|
xml:lang='en'>
|
|
<command xmlns='http://jabber.org/protocol/commands'
|
|
node='http://jabber.org/protocol/pubsub#chaining'
|
|
sessionid='a73sjjvkla37jfea'
|
|
status='executing'>
|
|
<x xmlns='jabber:x:data' type='form'>
|
|
<title>Chaining Request</title>
|
|
<instructions>Fill out this form to complete your request.</instructions>
|
|
<field type='hidden' var='FORM_TYPE'>
|
|
<value>http://jabber.org/protocol/pubsub#chaining</value>
|
|
</field>
|
|
<field label='The Node ID of the local pubsub node'
|
|
type='text-single'
|
|
var='local-node'>
|
|
<required/>
|
|
</field>
|
|
<field label='The Jabber ID of the remote pubsub service'
|
|
type='jid-single'
|
|
var='remote-service'>
|
|
<required/>
|
|
</field>
|
|
<field label='The NodeID of the remote pubsub node'
|
|
type='text-single'
|
|
var='remote-node'>
|
|
<required/>
|
|
</field>
|
|
</x>
|
|
</command>
|
|
</iq>
|
|
]]></example>
|
|
<example caption='Admin submits chaining form to service'><![CDATA[
|
|
<iq from='admin@consumer.tld/client'
|
|
id='chaining-2'
|
|
to='weatherbot@consumer.tld'
|
|
type='submit'
|
|
xml:lang='en'>
|
|
<command xmlns='http://jabber.org/protocol/commands'
|
|
node='http://jabber.org/protocol/pubsub#chaining'
|
|
sessionid='a73sjjvkla37jfea'
|
|
status='executing'>
|
|
<x xmlns='jabber:x:data' type='submit'>
|
|
<field type='hidden' var='FORM_TYPE'>
|
|
<value>http://jabber.org/protocol/pubsub#chaining</value>
|
|
</field>
|
|
<field var='local-node'>
|
|
<value>Chicagoland</value>
|
|
</field>
|
|
<field var='remote-service'>
|
|
<value>notify.weather.tld</value>
|
|
</field>
|
|
<field var='remote-node'>
|
|
<value>OHR</value>
|
|
</field>
|
|
</x>
|
|
</command>
|
|
</iq>
|
|
]]></example>
|
|
<example caption='Service informs admin of completion'><![CDATA[
|
|
<iq from='weatherbot@consumer.tld'
|
|
id='chaining-2'
|
|
to='admin@consumer.tld/client'
|
|
type='result'
|
|
xml:lang='en'>
|
|
<command xmlns='http://jabber.org/protocol/commands'
|
|
node='http://jabber.org/protocol/pubsub#chaining'
|
|
sessionid='a73sjjvkla37jfea'
|
|
status='completed'/>
|
|
</iq>
|
|
]]></example>
|
|
<p>At this point, the service itself will subscribe to the remote node.</p>
|
|
<example caption='Service subscribes to remote node for chaining'><![CDATA[
|
|
<iq type='set'
|
|
from='weatherbot@consumer.tld/Chicagoland'
|
|
to='notify.weather.tld'
|
|
id='sub1'>
|
|
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
|
<subscribe
|
|
node='OHR'
|
|
jid='weatherbot@consumer.tld/Chicagoland'/>
|
|
</pubsub>
|
|
</iq>
|
|
]]></example>
|
|
<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>
|
|
</section1>
|
|
|
|
<section1 topic='Notifications' anchor='notifications'>
|
|
<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>
|
|
<example caption='Chaining node notifies subscribers'><![CDATA[
|
|
<message from='weatherbot@consumer.tld/bot'
|
|
to='subscriber@consumer.tld'
|
|
id='foo'>
|
|
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
|
<items node='Chicagoland'>
|
|
<item id='ae890ac52d0df67ed7cfdf51b644e901'>
|
|
<example xmlns='urn:xmpp:example'>message</example>
|
|
</item>
|
|
</items>
|
|
</event>
|
|
<addresses xmlns='http://jabber.org/protocol/address'>
|
|
<address type='ofrom' jid='notify.weather.tld'/>
|
|
</addresses>
|
|
</message>
|
|
]]></example>
|
|
</section1>
|
|
|
|
<section1 topic='Determining Support' anchor='support'>
|
|
<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>
|
|
</section1>
|
|
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<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>
|
|
</section1>
|
|
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This document requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>The ®ISTRAR; shall include the following information in its registries.</p>
|
|
<section2 topic='Protocol Namespaces' anchor='ns'>
|
|
<p>The XMPP Registrar shall include 'http://jabber.org/protocol/pubsub#chaining' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
|
</section2>
|
|
<section2 topic='Field Standardization' anchor='registrar-formtype'>
|
|
<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>
|
|
<code caption='Registry Submission'><![CDATA[
|
|
<form_type>
|
|
<name>http://jabber.org/protocol/pubsub#chaining</name>
|
|
<doc>XEP-0253</doc>
|
|
<desc>Forms used for chaining of pubsub nodes.</desc>
|
|
<field var='local-node'
|
|
type='text-single'
|
|
label='The Node ID of the local node'/>
|
|
<field var='remote-node'
|
|
type='text-single'
|
|
label='The NodeID of the remote node'/>
|
|
<field var='remote-service'
|
|
type='jid-single'
|
|
label='The Jabber ID of the remote pubsub service'/>
|
|
</form_type>
|
|
]]></code>
|
|
</section2>
|
|
</section1>
|
|
|
|
<section1 topic='Acknowledgements' anchor='ack'>
|
|
<p>Thanks to Joe Hildebrand for his feedback.</p>
|
|
</section1>
|
|
|
|
</xep>
|