mirror of https://github.com/moparisthebest/xeps
1.1pre2
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@279 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
01b50d7d3b
commit
3c8497e559
108
xep-0163.xml
108
xep-0163.xml
|
|
@ -32,10 +32,10 @@
|
|||
<jid>kevdadrum@jabber.ex.ac.uk</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>1.1pre1</version>
|
||||
<date>in progress, last updated 2006-12-12</date>
|
||||
<version>1.1pre2</version>
|
||||
<date>in progress, last updated 2006-12-19</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Replaced hardcoded NodeIDs (one node per namespace) with server-side namespace matching; more fully specified use of PEP for private data storage.</p></remark>
|
||||
<remark><p>Replaced hardcoded NodeIDs (one node per namespace) with server-side namespace matching; specified semantic layering of data format, wrapper, and NodeID; defined registry for NodeIDs; more fully specified use of PEP for private data storage.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.0</version>
|
||||
|
|
@ -148,18 +148,21 @@
|
|||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>The XMPP &xep0060; extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;. <note>Currently, many "extended presence" formats are sent using the &PRESENCE; stanza type; however, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable.</note> However, the full, generic pubsub protocol is often thought of as complicated and therefore has not been widely implemented. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines simplified protocol semantics that can be followed by instant messaging client and server developers, hopefully resulting in the deployment of personal eventing services across the Jabber/XMPP network.</p>
|
||||
<p>The XMPP &xep0060; extension ("pubsub") can be used to broadcast state change events associated with a Jabber/XMPP account or user, such as those described in &xep0080; or &xep0107;.
|
||||
<note>Currently, many "extended presence" formats are sent using the &PRESENCE; stanza type; however, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable.</note>
|
||||
However, the full, generic pubsub protocol is often thought of as complicated and therefore has not been widely implemented. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines simplified protocol semantics that can be followed by instant messaging client and server developers, hopefully resulting in the deployment of personal eventing services across the Jabber/XMPP network.</p>
|
||||
<p><em>Note: This document does not show error flows related to the various publish-subscribe use cases referenced herein, since they are exhaustively defined in <cite>XEP-0060</cite>. The reader is referred to <cite>XEP-0060</cite> for all relevant protocol details related to the XMPP publish-subscribe extension.</em></p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Concepts and Approach' anchor='approach'>
|
||||
<p>Personal eventing via pubsub ("PEP") is based on the following five principles:</p>
|
||||
<p>Personal eventing via pubsub ("PEP") is based on the following principles:</p>
|
||||
<ol start='1'>
|
||||
<li>Every account a pubsub service.</li>
|
||||
<li>One publisher per node.</li>
|
||||
<li>Use presence.</li>
|
||||
<li>Notifications are filtered based on expressed interests.</li>
|
||||
<li>Smart defaults.</li>
|
||||
<li>Semantic layering.</li>
|
||||
</ol>
|
||||
<p>These principles are described more fully below.</p>
|
||||
<section2 topic='Every Account a Pubsub Service' anchor='approach-everyjid'>
|
||||
|
|
@ -179,11 +182,20 @@
|
|||
<p>These uses of presence simplify the task of developing compliant clients (cf. &xep0134;).</p>
|
||||
</section2>
|
||||
<section2 topic='Filtered Notifications' anchor='approach-filter'>
|
||||
<p>By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &xep0115; information in the presence notifications it sends to the account owner. The PEP service then sends only those notifications that match the contact's expressed notification preferences, based on the "pubsub#type" of the nodes that match.</p>
|
||||
<p>By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &xep0115; information in the presence notifications it sends to the account owner. The PEP service then sends only those notifications that match the contact's expressed notification preferences, based on the "pubsub#type" of the nodes that match -- where the payload type is the wrapper namespace (if any) or, in the absence of a wrapper, the data format namespace (as described below under <link url='#approach-layering'>Semantic Layering</link>).</p>
|
||||
</section2>
|
||||
<section2 topic='Smart Defaults' anchor='approach-defaults'>
|
||||
<p>Most pubsub configuration options and metadata are not needed for personal eventing. Instead, PEP services offer smart defaults to simplify node creation and management. The only required configuration options are the access model and the pubsub type (payload namespace).</p>
|
||||
</section2>
|
||||
<section2 topic='Semantic Layering' anchor='approach-layering'>
|
||||
<p>There are several layers of meaning in personal eventing: <note>Version 1.0 of this specification included the principle that "there is only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there is one pubsub node for geolocation events, one node for tune events, and one node for mood events)." The rationale for this principle was simplification of node creation, discovery, publishing, and subscribing. However, node discovery and subscribing are already simplified through the use of presence extensions. In addition, hardcoding NodeIDs in this way violates the core pubsub principle that NodeIDs shall be opaque. Therefore the "one node per namespace" principle was removed in version 1.1 of this specification in favor of NodeID registration.</note></p>
|
||||
<ol>
|
||||
<li>The innermost layer is the data format. This can be a generic format (such as jabber:x:data as defined in &xep0004; or Atom as defined in &rfc4287;) or a specific format such as &xep0108; or &xep0118;. If generic, it may be contained within a wrapper element (middle layer) to form the payload type; if specific, the format alone is the payload type.</li>
|
||||
<li>The optional middle layer is a wrapper around a generic data format. For instance, the Atom format could be used to describe a wide range of particular information types, such as a weblog; or the jabber:x:data format could be used to structure a wide variety of forms. In this case, it may be desirable to define an optional wrapper element and namespace to differentiate between distinct uses of the data format; the wrapper and data format together describe the payload type.</li>
|
||||
<li>The outermost layer is the NodeID. Although NodeIDs are opaque in the core pubsub specification, PEP defines a registry of NodeIDs for use in personal eventing as a means of differentiating between particular instances of the payload type (e.g., &xep0048; for groupchat rooms as opposed to web pages).</li>
|
||||
</ol>
|
||||
<p>Thus there is a one to many relationship between data formats and wrappers, and a one to many relationship between wrappers and NodeIDs. The examples below show the function of semantic layering in PEP.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Scenario' anchor='scenario'>
|
||||
|
|
@ -193,7 +205,7 @@
|
|||
<p>An owner-publisher juliet@capulet.com who publishes the following information:</p>
|
||||
<ol start='1'>
|
||||
<li>Tune information that anyone may see (i.e., an access model of "open")</li>
|
||||
<li>Activity information that only subscribers to her presence may see (i.e., an access model of "presence")</li>
|
||||
<li>Tune information that only subscribers to her presence may see (i.e., an access model of "presence")</li>
|
||||
<li>Geolocation information that only contacts in her "Friends" group may see (i.e., an access model of "roster" with a group of "Friends")</li>
|
||||
<li>Bookmark information that only the account owner may see (i.e., an access model of "whitelist")</li>
|
||||
</ol>
|
||||
|
|
@ -246,20 +258,20 @@
|
|||
<section1 topic='Account Owner Node Creation' anchor='owner-create'>
|
||||
<p>When an account owner attempts to publish an item to a PEP node and that node does not already exist, the PEP service MUST automatically create the node with default configuration. <note>This similar to the room creation process in <cite>XEP-0045: Multi-User Chat</cite>.</note> However, if the account owner wishes to create a node with a configuration other than the default (e.g., a node with an access model of "open", "roster", or "whitelist"), the account owner MUST follow the node creation protocol specified in <cite>XEP-0060</cite>.</p>
|
||||
<p>For example, Juliet would send the following stanzas in order to create the nodes mentioned above:</p>
|
||||
<example caption='Account owner creates open node for tune data'><![CDATA[
|
||||
<example caption='Account owner creates open node for blog data'><![CDATA[
|
||||
<iq from='juliet@capulet.com/balcony' type='set' id='create-open'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<create node='mytunes'/>
|
||||
<create node='blog1'/>
|
||||
<configure>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#node_config</value>
|
||||
</field>
|
||||
<field var='pubsub#access_model'>
|
||||
<option><value>open</value></option>
|
||||
<value>open</value>
|
||||
</field>
|
||||
<field var='pubsub#type'>
|
||||
<option><value>http://jabber.org/protocol/tune</value></option>
|
||||
<value>http://weblog.example.org/schema</value>
|
||||
</field>
|
||||
</x>
|
||||
</configure>
|
||||
|
|
@ -268,20 +280,20 @@
|
|||
|
||||
<iq to='juliet@capulet.com/balcony' type='result' id='create-open'/>
|
||||
]]></example>
|
||||
<example caption='Account owner creates presence node for activity data'><![CDATA[
|
||||
<example caption='Account owner creates presence node for tune data'><![CDATA[
|
||||
<iq from='juliet@capulet.com/balcony' type='set' id='create-presence'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<create node='whatimdoing'/>
|
||||
<create node='mytunes'/>
|
||||
<configure>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#node_config</value>
|
||||
</field>
|
||||
<field var='pubsub#access_model'>
|
||||
<option><value>presence</value></option>
|
||||
<value>presence</value>
|
||||
</field>
|
||||
<field var='pubsub#type'>
|
||||
<option><value>http://jabber.org/protocol/activity</value></option>
|
||||
<value>http://jabber.org/protocol/tune</value>
|
||||
</field>
|
||||
</x>
|
||||
</configure>
|
||||
|
|
@ -293,20 +305,20 @@
|
|||
<example caption='Account owner creates roster access node for geolocation data'><![CDATA[
|
||||
<iq from='juliet@capulet.com/balcony' type='set' id='create-roster'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<create node='whereiam'/>
|
||||
<create node='mylocation'/>
|
||||
<configure>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#node_config</value>
|
||||
</field>
|
||||
<field var='pubsub#access_model'>
|
||||
<option><value>roster</value></option>
|
||||
<value>roster</value>
|
||||
</field>
|
||||
<field var='pubsub#roster_groups_allowed'>
|
||||
<option><value>Friends</value></option>
|
||||
<value>Friends</value>
|
||||
</field>
|
||||
<field var='pubsub#type'>
|
||||
<option><value>http://jabber.org/protocol/geoloc</value></option>
|
||||
<value>http://jabber.org/protocol/geoloc</value>
|
||||
</field>
|
||||
</x>
|
||||
</configure>
|
||||
|
|
@ -318,17 +330,17 @@
|
|||
<example caption='Account owner creates whitelist node for bookmark data'><![CDATA[
|
||||
<iq from='juliet@capulet.com/balcony' type='set' id='create-whitelist'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<create node='mybookmarks'/>
|
||||
<create node='storage:bookmarks:conference'/>
|
||||
<configure>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#node_config</value>
|
||||
</field>
|
||||
<field var='pubsub#access_model'>
|
||||
<option><value>whitelist</value></option>
|
||||
<value>whitelist</value>
|
||||
</field>
|
||||
<field var='pubsub#type'>
|
||||
<option><value>storage:bookmarks</value></option>
|
||||
<value>storage:bookmarks</value>
|
||||
</field>
|
||||
</x>
|
||||
</configure>
|
||||
|
|
@ -337,6 +349,13 @@
|
|||
|
||||
<iq to='juliet@capulet.com/balcony' type='result' id='create-whitelist'/>
|
||||
]]></example>
|
||||
<p>In the foregoing examples, we assume the following semantic layering:</p>
|
||||
<ul>
|
||||
<li>The open node has an unregistered NodeID of "blog1", a wrapper namespace of "http://weblog.example.org/schema", and a data format of "http://www.w3.org/2005/Atom" (where we assume that the wrapper namespace is defined by some other specification to include only elements qualified by the data format namespace).</li>
|
||||
<li>The presence node has an unregistered NodeID of "mytunes" and a payload type of "http://jabber.org/protocol/tune".</li>
|
||||
<li>The roster node has an unregistered NodeID of "mylocation" and a payload type of "http://jabber.org/protocol/geoloc".</li>
|
||||
<li>The whitelist node has a registered NodeID of "storage:bookmarks:conference" and a payload type of "storage:bookmarks".</li>
|
||||
</ul>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Contact Subscription' anchor='contact-subscribe'>
|
||||
|
|
@ -467,9 +486,9 @@
|
|||
|
||||
<section1 topic='Contact Notification Filtering' anchor='contact-filter'>
|
||||
<p>A contact may not want to receive notifications for all payload types. A contact SHOULD signal its preferences to the account owner's server by including <cite>XEP-0115</cite> information that specifies the namespaces for which the contact wishes to receive notifications (if any).</p>
|
||||
<p>In order to make this possible, all possible payload namespaces can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the payload format. Thus if Romeo wants to receive notifications for activity data and geolocation data but not tune data, his client would advertise support for the following namespaces in the disco#info results it sends: <note>Including, say, the 'http://jabber.org/protocol/geoloc' namespace indicates that the client understands the geolocation namespace, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation.</note></p>
|
||||
<p>In order to make this possible, all possible payload namespaces can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the payload format. Thus if Romeo wants to receive notifications for tune data and geolocation data but not blog data, his client would advertise support for the following namespaces in the disco#info results it sends: <note>Including, say, the 'http://jabber.org/protocol/geoloc' namespace indicates that the client understands the geolocation namespace, whereas including the 'http://jabber.org/protocol/geoloc+notify' namespace indicates that the client wishes to receive notifications related to geolocation.</note></p>
|
||||
<ul>
|
||||
<li>http://jabber.org/protocol/activity+notify</li>
|
||||
<li>http://jabber.org/protocol/tune+notify</li>
|
||||
<li>http://jabber.org/protocol/geoloc+notify</li>
|
||||
</ul>
|
||||
<p>This set of namespaces would then be advertised as a <cite>XEP-0115</cite> "ext" value, such as the following:</p>
|
||||
|
|
@ -515,10 +534,10 @@
|
|||
id='disco123'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://exodus.jabberstudio.org/caps#0.9'/>
|
||||
<feature var='http://weblog.example.org/schema'/>
|
||||
<feature var='http://weblog.example.org/schema+notify'/>
|
||||
<feature var='http://jabber.org/protocol/tune'/>
|
||||
<feature var='http://jabber.org/protocol/tune+notify'/>
|
||||
<feature var='http://jabber.org/protocol/activity'/>
|
||||
<feature var='http://jabber.org/protocol/activity+notify'/>
|
||||
<feature var='http://jabber.org/protocol/geoloc'/>
|
||||
<feature var='http://jabber.org/protocol/geoloc+notify'/>
|
||||
</query>
|
||||
|
|
@ -539,8 +558,8 @@
|
|||
id='disco234'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'
|
||||
node='http://www.chatopus.com/ec#2.1'/>
|
||||
<feature var='http://weblog.example.org/schema'/>
|
||||
<feature var='http://jabber.org/protocol/tune'/>
|
||||
<feature var='http://jabber.org/protocol/activity'/>
|
||||
<feature var='http://jabber.org/protocol/geoloc'/>
|
||||
<feature var='http://jabber.org/protocol/geoloc+notify'/>
|
||||
</query>
|
||||
|
|
@ -548,9 +567,9 @@
|
|||
]]></example>
|
||||
<p>Now we revisit account owner publication and server generation of notifications, with filtering enabled because the server has caps information:</p>
|
||||
<ul>
|
||||
<li><p>If Juliet publishes a tune item to the open-access "mytunes" node (pubsub type "http://jabber.org/protocol/tune" node, her server will send notifications to <benvolio@montague.net> (bare JID) and to <nurse@capulet.com/chamber> (full JID) but not to <romeo@montague.net/orchard>.</p></li>
|
||||
<li><p>If Juliet publishes an activity item to the presence-access "whatimdiong" node (pubsub type "http://jabber.org/protocol/activity"), her server will send notifications only to <nurse@capulet.com/chamber>.</p></li>
|
||||
<li><p>If Juliet publishes a geolocation item to the roster-access "whereiam" node (pubsub type "http://jabber.org/protocol/geoloc"), her server will send notifications only to <romeo@montague.net/orchard>.</p></li>
|
||||
<li><p>If Juliet publishes a blog item to the open-access "blog1" node (pubsub type "http://weblog.example.org/schema" node, her server will send notifications to <benvolio@montague.net> (bare JID) and to <nurse@capulet.com/chamber> (full JID) but not to <romeo@montague.net/orchard>.</p></li>
|
||||
<li><p>If Juliet publishes a tune item to the presence-access "mytunes" node (pubsub type "http://jabber.org/protocol/tune"), her server will send notifications only to <nurse@capulet.com/chamber>.</p></li>
|
||||
<li><p>If Juliet publishes a geolocation item to the roster-access "mylocation" node (pubsub type "http://jabber.org/protocol/geoloc"), her server will send notifications only to <romeo@montague.net/orchard>.</p></li>
|
||||
</ul>
|
||||
</section1>
|
||||
|
||||
|
|
@ -626,7 +645,7 @@
|
|||
<p>A PEP service MUST:</p>
|
||||
<ul>
|
||||
<li>Support the node discovery, node creation, node deletion, publish item, subscribe, unsubscribe, and item retrieval use cases specified in <cite>XEP-0060</cite>.</li>
|
||||
<li>Support the "owner" and "subscriber" affiliations.</li>
|
||||
<li>Support the "owner" affiliation and (for subscribers) an affiliation of "none".</li>
|
||||
<li>Support the "presence" access model and set it to the default.</li>
|
||||
<li>Support the "open", "roster", and "whitelist" access models.</li>
|
||||
<li>Treat the account owner's bare JID (&BAREJID;) as a collection node (i.e., as the root collection node for the account's virtual pubsub service).</li>
|
||||
|
|
@ -637,7 +656,10 @@
|
|||
<p>A PEP service MAY support other use cases, affiliations, access models, and features, but such support is OPTIONAL.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Implementation Notes' anchor='imple'>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<section2 topic='Registered NodeIDs' anchor='impl-nodeids'>
|
||||
<p>A service SHOULD support all NodeIDs that are registered with the XMPP Registrar as described in the <link url='#registrar-pepnodes'>PEP Nodes</link> section of this document. This support shall include enforcement of the NodeID within the context of a given account, the payload type (whether wrapper or data format namespace), and any other configuration defaults as specified in the registry (this enables clients to perform seamless publish-and-create in one step).</p>
|
||||
</section2>
|
||||
<section2 topic='Cancelling Subscriptions' anchor='impl-subscriptions'>
|
||||
<p>In order to ensure appropriate access to information published at nodes of type "presence" and "roster", a PEP service MUST re-calculate access controls when:</p>
|
||||
<ol start='1'>
|
||||
|
|
@ -674,6 +696,22 @@
|
|||
</category>
|
||||
]]></code>
|
||||
</section2>
|
||||
<section2 topic='PEP Nodes Registry' anchor='registrar-pepnodes'>
|
||||
<p>The XMPP Registrar shall create a registry of PEP nodes.</p>
|
||||
®PROCESS;
|
||||
<code><![CDATA[
|
||||
<node>
|
||||
<id>the NodeID for the PEP node</id>
|
||||
<desc>a natural-language description of the PEP node</desc>
|
||||
<spec>the specification in which the PEP node is specified</spec>
|
||||
<field var='pubsub_configuration_field_name'>
|
||||
<value>default_value</value>
|
||||
</field>
|
||||
</node>
|
||||
]]></code>
|
||||
<p>Note: The "pubsub_configuration_field_name" and "default_value" strings are as registered for the "pubsub#node_config" FORM_TYPE by <cite>XEP-0060</cite>.</p>
|
||||
<p>The registrant may register more than one PEP node at a time, each contained in a separate <node/> element.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
|
|
@ -681,11 +719,7 @@
|
|||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>The authors wish to thank the participants in the XMPP Interoperability Testing Event held July 24 and 25, 2006, who provided valuable feedback that resulted in radical simplification of the protocol.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Draft Modifications' anchor='mods'>
|
||||
<p>Version 1.0 included the principle that "there is only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there is one pubsub node for geolocation events, one node for tune events, and one node for mood events)." The rationale for this principle was simplification of node creation, discovery, publishing, and subscribing. However, node discovery and subscribing are already simplified through the use of presence extensions. In addition, hardcoding NodeIDs in this way violates the core pubsub principle that NodeIDs shall be opaque. Therefore the "one node per namespace" principle was removed in version 1.1 of this specification.</p>
|
||||
<p>The authors wish to thank the participants in the XMPP Interoperability Testing Event held July 24 and 25, 2006, who provided valuable feedback that resulted in radical simplification of the protocol. Thanks also to Ralph Meijer and Ian Paterson for helpful discussions related to payload types and NodeID registration.</p>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
|
|
|
|||
Loading…
Reference in New Issue