mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
1.13rc3
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3060 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
47d010e334
commit
25c48571df
232
xep-0060.xml
232
xep-0060.xml
@ -43,20 +43,27 @@
|
||||
<ns>pubsub#owner</ns>
|
||||
<url>http://www.xmpp.org/schemas/pubsub-owner.xsd</url>
|
||||
</schemaloc>
|
||||
<discuss>pubsub</discuss>
|
||||
|
||||
&pgmillard;
|
||||
&stpeter;
|
||||
&ralphm;
|
||||
|
||||
<revision>
|
||||
<version>1.13rc2</version>
|
||||
<date>in progress, 2009-04-16</date>
|
||||
<version>1.13rc3</version>
|
||||
<date>in progress, 2009-04-20</date>
|
||||
<initials>psa</initials>
|
||||
<remark>
|
||||
<ul>
|
||||
<li>Fixed a large number of errata.</li>
|
||||
<li>Removed delete-any feature.</li>
|
||||
<li>Added (implicit) delete-items feature.</li>
|
||||
<li>Corrected a large number of reported errata.</li>
|
||||
<li>Removed delete-any and delete-node features.</li>
|
||||
<li>Added missing delete-items feature.</li>
|
||||
<li>Removed replyto and replyroom config options.</li>
|
||||
<li>Defined "room" value for itemreply config option.</li>
|
||||
<li>Added optional 'publisher' attribute to <item/> element.</li>
|
||||
<li>Added optional <redirect/> child to <delete/> element.</li>
|
||||
<li>Clarified meaning of filtered notifications (they are based on NodeIDs, not payload namespaces).</li>
|
||||
<li>Added pubsub-on-a-jid service discovery feature for explicit discovery that an IM and presence account also functions as a virtual pubsub service.</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
@ -624,6 +631,7 @@ And by opposing end them?
|
||||
<section2 topic='Event Types' anchor='events'>
|
||||
<p>The requirements for the publish-subscribe protocol imply that there are two major dimensions along which we can measure events: persistent vs. transient, and pure notification vs. inclusion of payload. An implementation SHOULD enable an owner to configure a node along both of these dimensions.</p>
|
||||
<p>No matter whether a node is configured for persistent or transient events, a service MAY cache the last item published to the node, in which case it SHOULD send that item to subscribers based on configuration of the "send_last_published_item" option (see the <link url='#impl-caching'>Item Caching</link> section of this document); if the service supports the "http://jabber.org/protocol/pubsub#last-published" feature then the value of this option MUST default to "on_sub_and_presence" (though the service SHOULD allow the node owner to override the default).</p>
|
||||
<p class='box'>Note: The "on_sub_and_presence" setting relates to the <em>subscriber's</em> presence, not the publisher's presence.</p>
|
||||
<p>A pubsub service MUST validate publish requests against the configuration of the node along both of these dimensions (see the <link url='#publisher-publish'>Publish An Item to a Node</link> section of this document for the relevant error conditions).</p>
|
||||
<p>The node configuration and desired event type determine whether an item must be provided by the publisher, whether the item includes a payload in the publish request or notification, and whether an item ID is provided by the publisher or generated by the pubsub service. We can summarize the relevant rules as follows:</p>
|
||||
<table caption='Items, Payloads, and Item IDs'>
|
||||
@ -1300,7 +1308,7 @@ And by opposing end them?
|
||||
</section4>
|
||||
</section3>
|
||||
<section3 topic='Approval Required' anchor='subscriber-subscribe-approval'>
|
||||
<p>For nodes with an access model of "authorize", subscription requests MUST be approved by one of the node owners; therefore the pubsub service sends a message to the node owner(s) requesting authorization (see the <link url='#owner-subreq'>Manage Subscription Requests</link> section of this document). Because the subscription request may or may not be approved, the service MUST return a pending notification to the subscriber.</p>
|
||||
<p>For nodes with an access model of "authorize", subscription requests MUST be approved by one of the node owners unless service policy allows entities with affiliations other than "none" to auto-subscribe (e.g., members and publishers might be allowed to auto-subscribe); therefore the pubsub service sends a message to the node owner(s) requesting authorization (see the <link url='#owner-subreq'>Manage Subscription Requests</link> section of this document). Because the subscription request may or may not be approved, the service MUST return a pending notification to the subscriber.</p>
|
||||
<example caption='Service replies with pending'><![CDATA[
|
||||
<iq type='result'
|
||||
from='pubsub.shakespeare.lit'
|
||||
@ -1387,6 +1395,7 @@ And by opposing end them?
|
||||
<section3 topic='Multiple Subscriptions' anchor='subscriber-subscribe-multi'>
|
||||
<p>An entity may wish to subscribe using different subscription options, which it can do by subscribing multiple times to the same node. Support for this feature ("multi-subscribe") is OPTIONAL.</p>
|
||||
<p>If multiple subscriptions for the same JID are allowed, the service MUST use the 'subid' attribute to differentiate between subscriptions for the same entity (therefore the SubID MUST be unique for each node+JID combination and the SubID MUST be present on the entity element any time it is sent to the subscriber). It is NOT RECOMMENDED for clients to generate SubIDs, since collisions might result; therefore a service SHOULD generate the SubID on behalf of the subscriber and MAY overwrite SubIDs if they are provided by subscribers. If the service does not allow multiple subscriptions for the same entity and it receives an additional subscription request, the service MUST return the current subscription state (as if the subscription was just approved).</p>
|
||||
<p>When the pubsub service generates notifications, it SHOULD send only one notification to an entity that has multiple subscriptions, rather than one notification for each subscription. By "entity" here is meant the JID specified for the subscription, whether bare JID or full JID; however, if the same bare JID has multiple subscriptions but those subscriptions are for different full JIDs (e.g., one subscription for user@domain.tld./foo and another subscription for user@domain.tld/bar), the service MUST treat those as separate JIDs for the purpose of generating notifications.</p>
|
||||
</section3>
|
||||
<section3 topic='Receiving the Last Published Item' anchor='subscriber-subscribe-last'>
|
||||
<p>When a subscription request is successfully processed, the service MAY send the last published item to the new subscriber. The message containing this item SHOULD be stamped with extended information qualified by the 'urn:xmpp:delay' namespace (see &xep0203;) to indicate it is sent with delayed delivery. (Note that in this example the message notification is sent to the bare JID since that is the subscribed JID.)</p>
|
||||
@ -3449,6 +3458,8 @@ And by opposing end them?
|
||||
label='Deliver payloads with event notifications'>
|
||||
<value>1</value>
|
||||
</field>
|
||||
<field var='pubsub#description' type='text-single'
|
||||
label='A description of the node'/>
|
||||
<field var='pubsub#notify_config' type='boolean'
|
||||
label='Notify subscribers when the node configuration changes'>
|
||||
<value>0</value>
|
||||
@ -3574,6 +3585,19 @@ And by opposing end them?
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<delete node='princely_musings'/>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The deletion request MAY include the JID and node of a replacement node to which requests might be redirected.</p>
|
||||
<example caption='Owner deletes a node with redirection'><![CDATA[
|
||||
<iq type='set'
|
||||
from='hamlet@denmark.lit/elsinore'
|
||||
to='pubsub.shakespeare.lit'
|
||||
id='delete1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
|
||||
<delete node='princely_musings'>
|
||||
<redirect jid='hamlet@denmark.lit' node='blog'/>
|
||||
</delete>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
@ -4390,7 +4414,19 @@ And by opposing end them?
|
||||
|
||||
<section1 topic='IM Account Integration' anchor='presence'>
|
||||
<p>Publish-subscribe functionality can be integrated into existing instant messaging and presence services (see <cite>RFC 3921</cite>), such that each registered account functions as a virtual pubsub service (sometimes called "pubsub-on-a-JID"). In such deployments, the root pubsub node for each virtual pubsub service has the same address as the bare JID &BAREJID; of the account, which is typically associated with an IM user (e.g., <hamlet@denmark.lit>). Since an IM user typically has a roster of "buddies" and shares presence information with those buddies, the virtual pubsub service can use roster and presence information to provide some helpful shortcuts for subscribers, in particular the auto-subscribe and filtered-notifications features described in this section.</p>
|
||||
<p>Note: Because the account owner's bare JID functions as a virtual pubsub service, it is OPTIONAL for the owner to include a 'to' address when sending publish requests and completing other publisher and owner use cases. That is, when the IM server receives a pubsub-related IQ stanza of type "get" or "set" from one of the account owner's resources, the server MUST consider the stanza to be addressed to the account owner's bare JID even if the IQ stanza does not include a 'to' address.</p>
|
||||
<p>If an instant messaging and presence account is also a virtual pubsub service, service discovery information ("disco#info") responses from the bare JID of the account MUST include a feature of "http:/jabber.org/protocol/pubsub#pubsub-on-a-jid":</p>
|
||||
<example caption='IM server returns supported features on behalf of IM account'><![CDATA[
|
||||
<iq from='hamlet@denmark.lit'
|
||||
id='bvg194j7'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<identity category='account' type='registered'/>
|
||||
<feature var='http://jabber.org/protocol/pubsub#pubsub-on-a-jid'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Note: Because the account owner's bare JID is the default destination address for any stanzas a client generates, clients often omit the "to" attribute on such stanzas; on this point, see &rfc3920bis; and (with regard to rosters) &rfc3921bis;.</p>
|
||||
<section2 topic='Auto-Subscribe' anchor='auto-subscribe'>
|
||||
<p>When a contact is affiliated with the account owner through sharing of XMPP presence, the "auto-subscribe" feature greatly simplifies the subscription process. In particular, support for the "auto-subscribe" has the following implications:</p>
|
||||
<section3 topic='Account Owner' anchor='auto-subscribe-owner'>
|
||||
@ -4407,17 +4443,17 @@ And by opposing end them?
|
||||
<p>Note: When an IM contact has a subscription to the account owner's presence, the automated pubsub subscription MUST be based on the JID contained in the 'from' address of the presence subscription request, which for an IM contact will be a bare JID &BAREJID;.</p>
|
||||
</section3>
|
||||
<section3 topic='Presence Sharer' anchor='auto-subscribe-directed'>
|
||||
<p>If the node has an open access model, the pubsub service SHOULD also consider an entity to be temporarily and implicitly subscribed to the node if the entity sends presence to the account owner in the absence of a presence subscription. In this case, the subscription SHOULD be based on the 'from' address of the presence stanza, which will be a full JID &FULLJID;. When the service receives unavailable presence from the full JID, it MUST consider cancel the temporary subscription.</p>
|
||||
<p>If the node has an open access model, the pubsub service SHOULD also consider an entity to be temporarily and implicitly subscribed to the node if the entity sends presence to the account owner in the absence of a presence subscription. In this case, the subscription SHOULD be based on the 'from' address of the presence stanza, which will be a full JID &FULLJID;. When the service receives unavailable presence from the full JID, it MUST cancel the temporary subscription.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Filtered Notifications' anchor='filtered-notifications'>
|
||||
<p>A contact might 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). This information is used by a pubsub service that supports the "filtered-notifications" feature to send only those payload types that the subscriber wishes to receive.</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 location data and tune data but not activity 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>A contact might not want to receive notifications for all the nodes hosted at a user's virtual pubsub service. A contact SHOULD signal its preferences to the account owner's server by including <cite>XEP-0115</cite> information that specifies the NodeIDs for which the contact wishes to receive notifications (if any). This information is used by a pubsub service that supports the "filtered-notifications" feature to send notifications only from those NodeIDs that match the subscriber's preferences.</p>
|
||||
<p>In order to make this possible, all possible NodeIDs can be appended with the string "+notify" to indicate that the contact wishes to receive notifications for the NodeID. Thus if Romeo wants to receive notifications for location data (&xep0080;) and tune data (&xep0118;) but not activity data (&xep0108;), his client would advertise support for the following strings in the disco#info results it sends: <note>Including, say, the 'http://jabber.org/protocol/geoloc' NodeID indicates that the client understands the geolocation namespace described in XEP-0080, 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/geoloc+notify</li>
|
||||
<li>http://jabber.org/protocol/tune+notify</li>
|
||||
</ul>
|
||||
<p>This set of namespaces would then be advertised by including the namespaces in the identity+features hash encapsulated via the 'ver' attribute as described in <cite>XEP-0115</cite>.</p>
|
||||
<p>This set of strings would then be advertised by including them in the identity+features hash encapsulated via the 'ver' attribute as described in <cite>XEP-0115</cite>.</p>
|
||||
<example caption='Contact sends presence with caps'><![CDATA[
|
||||
<presence from='romeo@montague.lit/orchard'>
|
||||
<c xmlns='http://jabber.org/protocol/caps'
|
||||
@ -4425,8 +4461,7 @@ And by opposing end them?
|
||||
ver='AFBT0mPr29zQE5aGtCJp97CIS6E='/>
|
||||
</presence>
|
||||
]]></example>
|
||||
<p>It is the responsibility of the account owner's server to cache <cite>XEP-0115</cite> information. 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 class='box'>Note: In the context of personal eventing, the +notify feature means that the subscriber will receive notifications only from the node whose NodeID matches the desired namespace, because there is one node per namespace and one namespace per node.</p>
|
||||
<p>It is the responsibility of the account owner's server to cache <cite>XEP-0115</cite> information. 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 NodeIDs for the contact's client. The server MUST NOT send notifications related to any NodeIDs that the contact's client has not asked for via the relevant "NodeID+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 "NodeID+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.lit does not have any presence subscriptions to or from juliet@capulet.lit and therefore is not involved in these protocol flows).</p>
|
||||
<example caption='Presence with caps'><![CDATA[
|
||||
<presence from='nurse@capulet.lit/chamber'>
|
||||
@ -4920,35 +4955,6 @@ And by opposing end them?
|
||||
<p>NodeIDs MAY have semantic meaning in particular profiles, implementations, or deployments of pubsub. However, it is STRONGLY RECOMMENDED that such semantic meaning not be used to encapsulate the hierarchical structure of nodes; instead, node hierarchy SHOULD be encapsulated using collections and their associated child nodes as described in <cite>XEP-0248</cite>.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Multiple Node Discovery' anchor='impl-multiple'>
|
||||
<p>A user may publish information that adheres to a certain profile at multiple pubsub nodes, and a potential subscriber may want to discover all of these pubsub nodes. The user may make a list of pubsub nodes publicly available for querying even when the user is offline by using the Service Discovery mechanism for "publishing" items (see Section 4 of <cite>XEP-0030</cite>). The potential subscriber may then send a "disco#items" request to the user's bare JID (<user@host>), including the 'node' attribute set to the value of the namespace to which the desired information adheres. The user's server then returns a list of pubsub nodes that meet that criterion (with each pubsub node being a separate Service Discovery item). Here is an example.</p>
|
||||
<example caption='Discovering multiple nodes'><![CDATA[
|
||||
<iq type='get'
|
||||
from='francisco@denmark.lit/barracks'
|
||||
to='hamlet@denmark.lit'
|
||||
id='multi-1'/>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'
|
||||
node='http://www.w3.org/2005/Atom'/>
|
||||
</iq>
|
||||
|
||||
<iq type='result'
|
||||
from='hamlet@denmark.lit'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
id='multi-1'/>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'
|
||||
node='http://www.w3.org/2005/Atom'>
|
||||
<item jid='pubsub.shakespeare.lit'
|
||||
node='princely_musings'
|
||||
name='Princely Musings (Atom)'/>
|
||||
<item jid='thepub.denmark.lit'
|
||||
node='feed-o-rama'
|
||||
name='Backup feed'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Alternatively, a user may be registered with a server that offers personal eventing services, in which case the user will have one node per namespace as described in <cite>XEP-0163</cite>.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Inclusion of SHIM Headers' anchor='impl-shim'>
|
||||
<p>When SubIDs are used, <cite>Stanza Headers and Internet Metadata (SHIM)</cite> headers are to be included in order to differentiate notifications sent regarding a particular subscription. The relevant use cases and scenarios are:</p>
|
||||
<ul>
|
||||
@ -4966,20 +4972,21 @@ And by opposing end them?
|
||||
<li>In the context of a group weblog, different users might publish to the weblog and replies might go to the publisher of an entry rather than to the weblog owner.</li>
|
||||
<li>In the context of an integrated pubsub and multi-user chat system, the node owner might be the room owner but all replies need to be sent to the room rather than to the owner.</li>
|
||||
</ul>
|
||||
<p>Therefore we define three node configuration options:</p>
|
||||
<p>Therefore we define the "itemreply" node configuration option, with three possible values:</p>
|
||||
<ul>
|
||||
<li>pubsub#itemreply -- the per-item policy for replies (the value is "owner" or "publisher").</li>
|
||||
<li>pubsub#replyto -- the specific user JID(s) to which replies should be sent, where the reply-to-JID information is provided by means of a &xep0033; header of type "replyto".</li>
|
||||
<li>pubsub#replyroom -- the multi-user chat room to which replies should be sent, where the reply-to-room information is provided by means of an <cite>Extended Stanza Addressing</cite> header of type "replyroom".</li>
|
||||
<li>"owner" (i.e., the node owner or an alias for the node owners)</li>
|
||||
<li>"publisher" (i.e., the item publisher)</li>
|
||||
<li>"room" (i.e., the MUC room associated with the room)</li>
|
||||
</ul>
|
||||
<p>A node owner MUST NOT define more than one of these options.</p>
|
||||
<p>An example is shown below.</p>
|
||||
<example caption='Event notification with extended stanza addressing'><![CDATA[
|
||||
<example caption='Event notification with publisher JID'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit'
|
||||
to='bassanio@merchantofvenice.lit'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='n48ad4fj78zn38st734'>
|
||||
<item id='i1s2d3f4g5h6bjeh936'>
|
||||
<item id='i1s2d3f4g5h6bjeh936'
|
||||
publisher='portia@merchantofvenice.lit'>
|
||||
<geoloc xmlns='http://jabber.org/protocol/geoloc'>
|
||||
<description>Venice</description>
|
||||
<lat>45.44</lat>
|
||||
@ -4988,9 +4995,6 @@ And by opposing end them?
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
<addresses xmlns='http://jabber.org/protocol/address'>
|
||||
<address type='replyto' jid='portia@merchantofvenice.lit'/>
|
||||
</addresses>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Alternatively, if a service implements the personal eventing subset of this protocol, the virtual pubsub service is the account owner's bare JID and notifications are sent from that JID; for details, refer to <cite>XEP-0163</cite>.</p>
|
||||
@ -5284,6 +5288,25 @@ O, what a rogue and peasant slave am I!
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='PubSub URIs' anchor='impl-uri'>
|
||||
<p>An XMPP URI (see &rfc5122;) can be used for the purpose of identification or interaction. Some examples are provided below.</p>
|
||||
<p>The following URI merely identifies a pubsub node.</p>
|
||||
<example caption='XMPP URI for a node'><![CDATA[
|
||||
xmpp:pubsub.shakespeare.lit?;node=princely_musings
|
||||
]]></example>
|
||||
<p>The following URI identifies a specific item at a node.</p>
|
||||
<example caption='XMPP URI for a pubsub item'><![CDATA[
|
||||
xmpp:pubsub.shakespeare.lit?;node=princely_musings;item=ae890ac52d0df67ed7cfdf51b644e901
|
||||
]]></example>
|
||||
<p>The following URI defines how to subscribe to a node (for details, see the <link url='#registrar-querytypes'>URI Query Types</link> section of this document).</p>
|
||||
<example caption='URI for subscribing to a pubsub node'><![CDATA[
|
||||
xmpp:pubsub.shakespeare.lit?pubsub;action=subscribe;node=princely_musings
|
||||
]]></example>
|
||||
<p>The following URI defines how to retrieve a specific item from a node.</p>
|
||||
<example caption='URI for retrieving a pubsub item'><![CDATA[
|
||||
xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae890ac52d0df67ed7cfdf51b644e901
|
||||
]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Internationalization Considerations' anchor='i18n'>
|
||||
@ -5748,36 +5771,6 @@ O, what a rogue and peasant slave am I!
|
||||
label='The URL of an XSL transformation which can be
|
||||
applied to payloads in order to generate an
|
||||
appropriate message body element.'/>
|
||||
<field var='pubsub#collection'
|
||||
type='text-single'
|
||||
label='The collection with which a node is affiliated'/>
|
||||
<field var='pubsub#contact'
|
||||
type='jid-multi'
|
||||
label='The JIDs of those to contact with questions'/>
|
||||
<field var='pubsub#dataform_xslt'
|
||||
type='text-single'
|
||||
label='The URL of an XSL transformation which can be
|
||||
applied to the payload format in order to generate
|
||||
a valid Data Forms result that the client could
|
||||
display using a generic Data Forms rendering
|
||||
engine'/>
|
||||
<field var='pubsub#deliver_notifications' type='boolean'
|
||||
label='Whether to deliver event notifications'>
|
||||
<value>true</value>
|
||||
</field>
|
||||
<field var='pubsub#deliver_payloads'
|
||||
type='boolean'
|
||||
label='Whether to deliver payloads with event notifications; applies only to leaf nodes'/>
|
||||
<field var='pubsub#itemreply'
|
||||
type='list-single'
|
||||
label='Whether owners or publisher should receive replies to items'>
|
||||
<option label='Statically specify a replyto of the node owner(s)'>
|
||||
<value>owner</value>
|
||||
</option>
|
||||
<option label='Dynamically specify a replyto of the item publisher'>
|
||||
<value>publisher</value>
|
||||
</option>
|
||||
</field>
|
||||
<field var='pubsub#children_association_policy'
|
||||
type='list-single'
|
||||
label='Who may associate leaf nodes with a collection'>
|
||||
@ -5800,6 +5793,42 @@ O, what a rogue and peasant slave am I!
|
||||
<field var='pubsub#children_max'
|
||||
type='text-single'
|
||||
label='The maximum number of child nodes that can be associated with a collection'/>
|
||||
<field var='pubsub#collection'
|
||||
type='text-single'
|
||||
label='The collection with which a node is affiliated'/>
|
||||
<field var='pubsub#contact'
|
||||
type='jid-multi'
|
||||
label='The JIDs of those to contact with questions'/>
|
||||
<field var='pubsub#dataform_xslt'
|
||||
type='text-single'
|
||||
label='The URL of an XSL transformation which can be
|
||||
applied to the payload format in order to generate
|
||||
a valid Data Forms result that the client could
|
||||
display using a generic Data Forms rendering
|
||||
engine'/>
|
||||
<field var='pubsub#deliver_notifications' type='boolean'
|
||||
label='Whether to deliver event notifications'>
|
||||
<value>true</value>
|
||||
</field>
|
||||
<field var='pubsub#deliver_payloads'
|
||||
type='boolean'
|
||||
label='Whether to deliver payloads with event notifications; applies only to leaf nodes'/>
|
||||
<field var='pubsub#description'
|
||||
type='text-single'
|
||||
label='A description of the node'/>
|
||||
<field var='pubsub#itemreply'
|
||||
type='list-single'
|
||||
label='Whether owners or publisher should receive replies to items'>
|
||||
<option label='Statically specify a replyto of the node owner(s)'>
|
||||
<value>owner</value>
|
||||
</option>
|
||||
<option label='Dynamically specify a replyto of the item publisher'>
|
||||
<value>publisher</value>
|
||||
</option>
|
||||
</field>
|
||||
<field var='pubsub#language'
|
||||
type='list-single'
|
||||
label='The default language of the node'/>
|
||||
<field var='pubsub#max_items'
|
||||
type='text-single'
|
||||
label='The maximum number of items to persist'/>
|
||||
@ -5847,12 +5876,6 @@ O, what a rogue and peasant slave am I!
|
||||
<value>open</value>
|
||||
</option>
|
||||
</field>
|
||||
<field var='pubsub#replyroom'
|
||||
type='jid-multi'
|
||||
label='The specific multi-user chat rooms to specify for replyroom'/>
|
||||
<field var='pubsub#replyto'
|
||||
type='jid-multi'
|
||||
label='The specific JID(s) to specify for replyto'/>
|
||||
<field var='pubsub#roster_groups_allowed'
|
||||
type='list-multi'
|
||||
label='The roster group(s) allowed to subscribe and retrieve items'/>
|
||||
@ -5934,7 +5957,7 @@ O, what a rogue and peasant slave am I!
|
||||
</section2>
|
||||
<section2 topic='URI Query Types' anchor='registrar-querytypes'>
|
||||
<p>As authorized by &xep0147;, the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).</p>
|
||||
<p>The "pubsub" querytype is defined herein for interaction with pubsub services, with two keys: (1) "action" (whose defined values are "subscribe" and "unsubscribe") and (2) "node" (to specify a pubsub node).</p>
|
||||
<p>The "pubsub" querytype is defined herein for interaction with pubsub services, with three keys: (1) "action" (whose defined values are "subscribe", "unsubscribe", and "retrieve"), (2) "node" (to specify a pubsub node), and optionally "item" (to specify a particular item at a node).</p>
|
||||
<example caption='Pubsub Subscribe Action: IRI/URI'><![CDATA[
|
||||
xmpp:pubsub.shakespeare.lit?pubsub;action=subscribe;node=princely_musings
|
||||
]]></example>
|
||||
@ -5953,6 +5976,16 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<unsubscribe node='princely_musings'/>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='Pubsub Retrieve Action: IRI/URI'><![CDATA[
|
||||
xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
|
||||
]]></example>
|
||||
<example caption='Pubsub Retrieve Action: Resulting Stanza'><![CDATA[
|
||||
<iq to='pubsub.shakespeare.lit' type='get'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<subscribe node='princely_musings'/>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The following submission registers the "pubsub" querytype.</p>
|
||||
@ -6407,6 +6440,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
|
||||
</xs:choice>
|
||||
<xs:attribute name='id' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='node' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='publisher' type='xs:string' use='optional'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
@ -6545,11 +6579,10 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
|
||||
|
||||
<xs:element name='delete'>
|
||||
<xs:complexType>
|
||||
<xs:simpleContent>
|
||||
<xs:extension base='empty'>
|
||||
<xs:attribute name='node' type='xs:string' use='required'/>
|
||||
</xs:extension>
|
||||
</xs:simpleContent>
|
||||
<xs:sequence>
|
||||
<xs:element ref='redirect' minOccurs='0' maxOccurs='1'/>
|
||||
</xs:sequence>
|
||||
<xs:attribute name='node' type='xs:string' use='required'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
@ -6563,6 +6596,17 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
<xs:element name='redirect'>
|
||||
<xs:complexType>
|
||||
<xs:simpleContent>
|
||||
<xs:extension base='empty'>
|
||||
<xs:attribute name='jid' type='xs:string' use='required'/>
|
||||
<xs:attribute name='node' type='xs:string' use='optional'/>
|
||||
</xs:extension>
|
||||
</xs:simpleContent>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
<xs:element name='subscriptions'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
@ -6599,7 +6643,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=unsubscribe;node=princely_musings
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Gaston Dombiak, Anastasia Gornostaeva, Christophe Romain, Chris Teegarden, Matt Tucker, Bob Wyman, and Brett Zamir for their feedback.</p>
|
||||
<p>Thanks to Blaine Cook, Brian Cully, Dave Cridland, Gaston Dombiak, Seth Fitzsimmons, Anastasia Gornostaeva, Joe Hildebrand, Dirk Meyer, Tory Patnoe, Christophe Romain, Kevin Smith, Chris Teegarden, Matt Tucker, Bob Wyman, and Brett Zamir for their feedback.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Author Note' anchor='authornote'>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user