mirror of https://github.com/moparisthebest/xeps
1.1pre1
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@267 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
c47e7bbd62
commit
aff62f1015
192
xep-0163.xml
192
xep-0163.xml
|
|
@ -31,6 +31,12 @@
|
|||
<email>kevin@kismith.co.uk</email>
|
||||
<jid>kevdadrum@jabber.ex.ac.uk</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>1.1pre1</version>
|
||||
<date>in progress, last updated 2006-12-12</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>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.0</version>
|
||||
<date>2006-09-20</date>
|
||||
|
|
@ -147,11 +153,10 @@
|
|||
</section1>
|
||||
|
||||
<section1 topic='Concepts and Approach' anchor='approach'>
|
||||
<p>Personal eventing via pubsub ("PEP") is based on six principles:</p>
|
||||
<p>Personal eventing via pubsub ("PEP") is based on the following five principles:</p>
|
||||
<ol start='1'>
|
||||
<li>Every account a pubsub service.</li>
|
||||
<li>One publisher per node.</li>
|
||||
<li>One node per namespace.</li>
|
||||
<li>Use presence.</li>
|
||||
<li>Notifications are filtered based on expressed interests.</li>
|
||||
<li>Smart defaults.</li>
|
||||
|
|
@ -163,24 +168,21 @@
|
|||
<section2 topic='One Publisher Per Node' anchor='approach-publisher'>
|
||||
<p>There is no need for multiple publishers to a PEP service, since by definition the service generates information associated with only one entity. The owner-publisher for every node is the bare JID of the account owner.</p>
|
||||
</section2>
|
||||
<section2 topic='One Node Per Namespace' anchor='approach-onenode'>
|
||||
<p>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). This simplifies node creation, discovery, publishing, and subscribing.</p>
|
||||
</section2>
|
||||
<section2 topic='Use Presence' anchor='approach-presence'>
|
||||
<p>Although generic publish-subscribe services do not necessarily have access to presence information about subscribers, PEP services are integrated with presence in the following ways:</p>
|
||||
<ul>
|
||||
<li>Each messaging and presence account simply <em>is</em> a virtual publish-subscribe service.</li>
|
||||
<li>The default access model is "presence".</li>
|
||||
<li>A contact's subscription to an account owner's personal eventing data is normally handled via the existence of an XMPP presence subscription.</li>
|
||||
<li>Services take account of subscriber presence in the generation of notifications. <note>This works only if the subscription state is "both" (see <cite>RFC 3921</cite>).</note></li>
|
||||
<li>Services take account of subscriber presence in the generation of notifications. (Note: This works only if the subscription state is "both" as explained in <cite>RFC 3921</cite>.)</li>
|
||||
</ul>
|
||||
<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, and the PEP service sends only those notifications that match the contact's expressed notification preferences.</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.</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.</p>
|
||||
<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>
|
||||
</section1>
|
||||
|
||||
|
|
@ -247,7 +249,7 @@
|
|||
<example caption='Account owner creates open node for tune data'><![CDATA[
|
||||
<iq from='juliet@capulet.com/balcony' type='set' id='create-open'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<create node='http://jabber.org/protocol/tune'/>
|
||||
<create node='mytunes'/>
|
||||
<configure>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
|
|
@ -256,6 +258,9 @@
|
|||
<field var='pubsub#access_model'>
|
||||
<option><value>open</value></option>
|
||||
</field>
|
||||
<field var='pubsub#type'>
|
||||
<option><value>http://jabber.org/protocol/tune</value></option>
|
||||
</field>
|
||||
</x>
|
||||
</configure>
|
||||
</pubsub>
|
||||
|
|
@ -263,19 +268,23 @@
|
|||
|
||||
<iq to='juliet@capulet.com/balcony' type='result' id='create-open'/>
|
||||
]]></example>
|
||||
<example caption='Account owner publishes initial item to presence node for activity data'><![CDATA[
|
||||
<example caption='Account owner creates presence node for activity data'><![CDATA[
|
||||
<iq from='juliet@capulet.com/balcony' type='set' id='create-presence'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='http://jabber.org/protocol/activity'/>
|
||||
<item>
|
||||
<activity xmlns='http://jabber.org/protocol/activity'>
|
||||
<relaxing>
|
||||
<partying/>
|
||||
</relaxing>
|
||||
<text xml:lang='en'>My nurse's birthday!</text>
|
||||
</activity>
|
||||
</item>
|
||||
</publish>
|
||||
<create node='whatimdoing'/>
|
||||
<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>
|
||||
</field>
|
||||
<field var='pubsub#type'>
|
||||
<option><value>http://jabber.org/protocol/activity</value></option>
|
||||
</field>
|
||||
</x>
|
||||
</configure>
|
||||
</pubsub>
|
||||
</iq>
|
||||
|
||||
|
|
@ -284,7 +293,7 @@
|
|||
<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='http://jabber.org/protocol/geoloc'/>
|
||||
<create node='whereiam'/>
|
||||
<configure>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
|
|
@ -296,6 +305,9 @@
|
|||
<field var='pubsub#roster_groups_allowed'>
|
||||
<option><value>Friends</value></option>
|
||||
</field>
|
||||
<field var='pubsub#type'>
|
||||
<option><value>http://jabber.org/protocol/geoloc</value></option>
|
||||
</field>
|
||||
</x>
|
||||
</configure>
|
||||
</pubsub>
|
||||
|
|
@ -306,7 +318,7 @@
|
|||
<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='storage:bookmarks'/>
|
||||
<create node='mybookmarks'/>
|
||||
<configure>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
|
|
@ -315,6 +327,9 @@
|
|||
<field var='pubsub#access_model'>
|
||||
<option><value>whitelist</value></option>
|
||||
</field>
|
||||
<field var='pubsub#type'>
|
||||
<option><value>storage:bookmarks</value></option>
|
||||
</field>
|
||||
</x>
|
||||
</configure>
|
||||
</pubsub>
|
||||
|
|
@ -324,109 +339,8 @@
|
|||
]]></example>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Contact Service Discovery' anchor='contact-disco'>
|
||||
<p>A contact MAY send service discovery requests to the account owner's bare JID (&BAREJID;). Although this is not necessary in order to subscribe to the account owner's personal eventing data (as explained in the following section), it is shown here to further illustrate the role of access models.</p>
|
||||
<p>First, benvolio@montague.net sends a disco#info request to juliet@capulet.com:</p>
|
||||
<example caption='Unaffiliated entity queries account owner regarding identity'><![CDATA[
|
||||
<iq from='benvolio@montague.net/home'
|
||||
to='juliet@capulet.com'
|
||||
id='disco2'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If Juliet's server supports PEP (thereby making juliet@capulet.com a virtual pubsub service), it MUST return an identity of "pubsub/pep":</p>
|
||||
<example caption='Server communicates protocol support'><![CDATA[
|
||||
<iq from='juliet@capulet.com'
|
||||
to='benvolio@montague.net/home'
|
||||
id='disco2'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<identity category='pubsub' type='pep'/>
|
||||
<identity category='account' type='registered'/>
|
||||
...
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Second, benvolio@montague.net sends a disco#items request to juliet@capulet.com:</p>
|
||||
<example caption='Unaffiliated entity queries account owner regarding items'><![CDATA[
|
||||
<iq from='benvolio@montague.net/home'
|
||||
to='juliet@capulet.com'
|
||||
id='disco3'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The account owner's server MUST check the access model for each of the account owner's PEP nodes and MUST return as service discovery items only those nodes to which the contact is allowed to subscribe or from which the contact is allowed to retrieve items without first subscribing.</p>
|
||||
<p>Therefore, in this case, the server would return only the "http://jabber.org/protocol/tune" node (since it has an open access model and the contact does not have a presence subscription to the account owner's presence):</p>
|
||||
<example caption='Server returns appropriate items'><![CDATA[
|
||||
<iq from='juliet@capulet.com'
|
||||
to='benvolio@montague.net/home'
|
||||
id='disco3'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'>
|
||||
<item jid='juliet@capulet.com' node='http://jabber.org/protocol/tune'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Next, nurse@capulet.com sends a disco#items request to juliet@capulet.com:</p>
|
||||
<example caption='Contact with presence subscription queries account owner regarding items'><![CDATA[
|
||||
<iq from='nurse@capulet.com/chamber'
|
||||
to='juliet@capulet.com'
|
||||
id='disco4'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>However, in this case, the server would return the "http://jabber.org/protocol/tune" node (open access model) <em>and</em> the "http://jabber.org/protocol/activity" node (presence access model):</p>
|
||||
<example caption='Server returns appropriate items'><![CDATA[
|
||||
<iq from='juliet@capulet.com'
|
||||
to='nurse@capulet.com/chamber'
|
||||
id='disco4'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'>
|
||||
<item jid='juliet@capulet.com' node='http://jabber.org/protocol/tune'/>
|
||||
<item jid='juliet@capulet.com' node='http://jabber.org/protocol/activity'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Finally, romeo@montague.net sends a disco#items request to juliet@capulet.com:</p>
|
||||
<example caption='Contact with presence subscription and in privileged roster group queries account owner regarding items'><![CDATA[
|
||||
<iq from='romeo@montague.net/orchard'
|
||||
to='juliet@capulet.com'
|
||||
id='disco5'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>In this case, the server would return the "http://jabber.org/protocol/tune" node (open access model) <em>and</em> the "http://jabber.org/protocol/activity" node (presence access model) <em>and</em> the "http://jabber.org/protocol/geoloc" node (roster access model):</p>
|
||||
<example caption='Server returns appropriate items'><![CDATA[
|
||||
<iq from='juliet@capulet.com'
|
||||
to='romeo@montague.net/orchard'
|
||||
id='disco5'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'>
|
||||
<item jid='juliet@capulet.com' node='http://jabber.org/protocol/tune'/>
|
||||
<item jid='juliet@capulet.com' node='http://jabber.org/protocol/activity'/>
|
||||
<item jid='juliet@capulet.com' node='http://jabber.org/protocol/geoloc'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Contact Subscription' anchor='contact-subscribe'>
|
||||
<p>If an entity is not subscribed to the account owner's presence, it MUST subscribe to a node using the protocol defined in <cite>XEP-0060</cite>. For instance, here is how benvolio@montague.net would subscribe Juliet's tune information:</p>
|
||||
<example caption='Unaffiliated entity subscribes to an open node'><![CDATA[
|
||||
<iq type='set'
|
||||
from='benvolio@montague.net/home'
|
||||
to='juliet@capulet.com'
|
||||
id='sub1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<subscribe node='http://jabber.org/protocol/tune' jid='benvolio@montague.net'/>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>However, when a contact is affiliated with the account owner through a presence subscription, PEP greatly simplifies the subscription process. This is done by associating the presence subscription with a pubsub subscription to the account owner's root collection node (i.e., bare JID), with a subscription_type of "items" and a subscription_depth of "all".</p>
|
||||
<p>If an entity is not subscribed to the account owner's presence, it MUST discover and then subscribe to a node using the protocol defined in <cite>XEP-0060</cite>. However, when a contact and account owner are subscribed to each other's presence, PEP greatly simplifies the subscription process. This is done by associating the presence subscription with a pubsub subscription to the account owner's root collection node (i.e., bare JID), with a subscription_type of "items" and a subscription_depth of "all".</p>
|
||||
<p>Consider the following presence subscription exchange:</p>
|
||||
<example caption='Presence subscription handshake'><![CDATA[
|
||||
<presence from='nurse@capulet.com' to='juliet@capulet.com' type='subscribe'/>
|
||||
|
|
@ -467,7 +381,7 @@
|
|||
<example caption='Account owner publishes item'><![CDATA[
|
||||
<iq from='juliet@capulet.com/balcony' type='set' id='pub1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='http://jabber.org/protocol/tune'>
|
||||
<publish node='mytunes'>
|
||||
<item>
|
||||
<tune xmlns='http://jabber.org/protocol/tune'>
|
||||
<artist>Gerald Finzi</artist>
|
||||
|
|
@ -490,7 +404,7 @@
|
|||
type='headline'
|
||||
id='foo'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='http://jabber.org/protocol/tune'>
|
||||
<items node='mytunes'>
|
||||
<item>
|
||||
<tune xmlns='http://jabber.org/protocol/tune'>
|
||||
<artist>Gerald Finzi</artist>
|
||||
|
|
@ -509,7 +423,7 @@
|
|||
type='headline'
|
||||
id='foo'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='http://jabber.org/protocol/tune'>
|
||||
<items node='mytunes'>
|
||||
<item>
|
||||
<tune xmlns='http://jabber.org/protocol/tune'>
|
||||
<artist>Gerald Finzi</artist>
|
||||
|
|
@ -531,7 +445,7 @@
|
|||
type='headline'
|
||||
id='foo'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='http://jabber.org/protocol/tune'>
|
||||
<items node='mytunes'>
|
||||
<item>
|
||||
<tune xmlns='http://jabber.org/protocol/tune'>
|
||||
<artist>Gerald Finzi</artist>
|
||||
|
|
@ -568,7 +482,7 @@
|
|||
</presence>
|
||||
]]></example>
|
||||
<p>Note: In <cite>XEP-0115</cite>, the "ext" values are opaque strings with no semantic meaning.</p>
|
||||
<p>It is the responsibility of the account owner's server to cache <cite>XEP-0115</cite> information (including "ext" values and their associated namespaces). 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 namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+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 "namespace+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.</p>
|
||||
<p>It is the responsibility of the account owner's server to cache <cite>XEP-0115</cite> information (including "ext" values and their associated namespaces). When a PEP-enabled server receives presence from a contact, it MUST check that presence information for entity capabilities data and correlate that data with the desired namespaces for the contact's client. The server MUST NOT send notifications related to any data formats that the contact's client has not asked for via the relevant "namespace+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 "namespace+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.</p>
|
||||
<p>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.net does have any presence subscriptions to or from juliet@capulet.com and therefore is not involved in these protocol flows).</p>
|
||||
<example caption='Presence with caps'><![CDATA[
|
||||
<presence from='nurse@capulet.com/chamber'>
|
||||
|
|
@ -634,9 +548,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 "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 "http://jabber.org/protocol/activity" node, 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 "http://jabber.org/protocol/geoloc" node, her server will send notifications only to <romeo@montague.net/orchard>.</p></li>
|
||||
<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>
|
||||
</ul>
|
||||
</section1>
|
||||
|
||||
|
|
@ -681,7 +595,7 @@
|
|||
type='headline'
|
||||
id='foo'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='http://jabber.org/protocol/tune'>
|
||||
<items node='mytunes'>
|
||||
<item>
|
||||
<tune xmlns='http://jabber.org/protocol/tune'>
|
||||
<artist>Gerald Finzi</artist>
|
||||
|
|
@ -699,7 +613,13 @@
|
|||
</section1>
|
||||
|
||||
<section1 topic='Private Data Storage' anchor='privatedata'>
|
||||
<p>As noted, PEP services may be used to implement private data storage, such as defined in &xep0049;. A future version of this document will specify this usage in more detail.</p>
|
||||
<p>As noted, PEP services can be used to implement so-called "private data storage", similar in functionality to the dedicated protocol described in &xep0049; (which is often used for storing client preferences, user bookmarks, and the like). In essence, a private node is a pubsub node whose access model is "whitelist", where there are no entities in the whitelist (the account owner is automatically granted access to the node and therefore receives all node events and can retrieve items from the node at will). This results in the following functionality:</p>
|
||||
<ul>
|
||||
<li>The account owner is able to create as many private data nodes as desired (e.g., for client preferences, bookmarks, public keys, etc.).</li>
|
||||
<li>The account owner is able to create any number of privata data nodes per payload namespace (e.g., different sets of bookmarks).</li>
|
||||
<li>The account owner is able to add and delete private data in a granular fashion (not by updating the entire data store for the relevant namespace as in <cite>XEP-0049</cite>).</li>
|
||||
<li>Each of the account owner's resources will receive notifications related to data updates (based on PEP's dynamic namespace matching).</li>
|
||||
</ul>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Recommended Defaults' anchor='defaults'>
|
||||
|
|
@ -764,4 +684,8 @@
|
|||
<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>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
|
|
|
|||
Loading…
Reference in New Issue