moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2025-03-03 10:02:00 -05:00
Code Issues Releases Wiki Activity

Merge pull request #215 from sstrigler/xep-0060-jabber

Browse Source 
Fix terminology
This commit is contained in:
Sam Whited 2016-08-19 09:35:47 -07:00 committed by GitHub
commit 5444ba9b8f
1 changed files with 22 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
xep-0060.xml
View File

@ -49,6 +49,16 @@
&stpeter;
&ralphm;
<revision>
<version>1.13.1</version>
<date>2016-07-21</date>
<initials>ss</initials>
<remark>
<ul>
<li>Fix wording, replace Jabber with XMPP where applicable.</li>
</ul>
</remark>
</revision>
<revision>
<version>1.13</version>
<date>2010-07-12</date>
@ -444,7 +454,7 @@ And by opposing end them?
<di><dt>Authorize Access Model</dt><dd>A node access model under which an entity can subscribe only through having a subscription request approved by a node owner (subscription requests are accepted but only provisionally) and only subscribers may retrieve items.</dd></di>
<di><dt>Address</dt><dd>(1) A JID as defined in &xmppcore;, or (2) the combination of a JID and a &xep0030; node.</dd></di>
<di><dt>Collection Node</dt><dd>A type of node that contains nodes and/or other collections but no published items. Collections make it possible to represent more sophisticated relationships among nodes. Collection nodes are defined in &xep0248;.</dd></di>
<di><dt>Entity</dt><dd>A JID-addressable Jabber entity (client, service, application, etc.).</dd></di>
<di><dt>Entity</dt><dd>A JID-addressable XMPP entity (client, service, application, etc.).</dd></di>
<di><dt>Event</dt><dd>A change in the state of a node.</dd></di>
<di><dt>Instant Node</dt><dd>A node whose NodeID is automatically generated by a pubsub service.</dd></di>
<di><dt>Item</dt><dd>An XML fragment which is published to a node, thereby generating an event.</dd></di>
@ -471,7 +481,7 @@ And by opposing end them?
<!-- =================== REQS ======================== -->
<section1 topic='Requirements' anchor='reqs'>
<p>Requirements for a pubsub service can be driven by end-user needs as well as the needs of other components and services which can use the service. First, a pubsub service implemented using Jabber MUST provide the basic features that implement a pure publish-subscribe pattern:</p>
<p>Requirements for a pubsub service can be driven by end-user needs as well as the needs of other components and services which can use the service. First, a pubsub service implemented using XMPP MUST provide the basic features that implement a pure publish-subscribe pattern:</p>
<!-- ================== MUSTS =================== -->
<ul>
<li>An entity MUST be able to publish events to a service such that all subscribers to a node receive notification of the event. See <link url='#publisher-publish'>Publish an Item to a Node</link>.</li>
@ -481,7 +491,7 @@ And by opposing end them?
</ul>
<!-- =================== MAYS and SHOULDS =================== -->
<p>Some of the possible uses of a Jabber-based pubsub service will require other features, but these features are OPTIONAL and therefore not mandatory for compliance with this specification. However, if these features are implemented, they MUST adhere to the protocol described herein in to be compliant. These features include:</p>
<p>Some of the possible uses of an XMPP-based pubsub service will require other features, but these features are OPTIONAL and therefore not mandatory for compliance with this specification. However, if these features are implemented, they MUST adhere to the protocol described herein in to be compliant. These features include:</p>
<ul>
<li>A service MAY cache the last item published to a node (even if the "persistent-items" option is set to false); if it does default "cache-last-item" to true, it SHOULD send the last published item (or notification thereof) to subscribed entities based on configuration of the "send_last_published_item" field.</li>
<li>A node owner SHOULD be able to specify who may subscribe to a node.</li>
@ -1141,7 +1151,7 @@ And by opposing end them?
<section2 topic='Subscribe to a Node' anchor='subscriber-subscribe'>
<section3 topic='Request' anchor='subscriber-subscribe-request'>
<p>When a Jabber entity wishes to subscribe to a node, it sends a subscription request to the pubsub service. The subscription request is an IQ-set where the &lt;pubsub/&gt; element contains one and only one &lt;subscribe/&gt; element. The &lt;subscribe/&gt; element SHOULD possess a 'node' attribute specifying the node to which the entity wishes to subscribe. The &lt;subscribe/&gt; element MUST also possess a 'jid' attribute specifying the exact XMPP address to be used as the subscribed JID -- often a bare JID &BAREJID; or full JID &FULLJID;.</p>
<p>When an XMPP entity wishes to subscribe to a node, it sends a subscription request to the pubsub service. The subscription request is an IQ-set where the &lt;pubsub/&gt; element contains one and only one &lt;subscribe/&gt; element. The &lt;subscribe/&gt; element SHOULD possess a 'node' attribute specifying the node to which the entity wishes to subscribe. The &lt;subscribe/&gt; element MUST also possess a 'jid' attribute specifying the exact XMPP address to be used as the subscribed JID -- often a bare JID &BAREJID; or full JID &FULLJID;.</p>
<p>Here is an example of a subscription request.</p>
<example caption='Entity subscribes to a node'><![CDATA[
<iq type='set'
@ -4843,7 +4853,7 @@ And by opposing end them?
to='pubsub.shakespeare.lit'
id='items3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='princely_musings'
<items node='princely_musings'
ver='v103'/>
</pubsub>
</iq>
@ -5241,7 +5251,7 @@ And by opposing end them?
</section2>
<section2 topic='Not Routing Events to Offline Storage' anchor='impl-offline'>
<p>Sending events to users of existing Jabber servers may force event notifications to be routed to offline storage for later delivery (as described in &xep0160;). This may not always be desirable. The possible ways of preventing this behavior include:</p>
<p>Sending events to users of existing XMPP servers may force event notifications to be routed to offline storage for later delivery (as described in &xep0160;). This may not always be desirable. The possible ways of preventing this behavior include:</p>
<ul>
<li>Use presence-based subscription options as described above.</li>
<li>Use delivery semantics as defined by &xep0079;.</li>
@ -5530,7 +5540,7 @@ And by opposing end them?
</section2>
<section2 topic='Content-Based Pubsub Systems' anchor='impl-content'>
<p>A service MAY enable entities to subscribe to nodes and apply a filter to notifications (e.g., keyword matching such as "send me all news entries from Slashdot that match the term 'Jabber'"). Such a content-based service SHOULD allow an entity to subscribe more than once to the same node and, if so, MUST use subscription identifiers (SubIDs) to distinguish between multiple subscriptions. In order to prevent collisions, a service that supports content-based subscriptions using SubIDs SHOULD generate SubIDs on behalf of subscribers rather than allowing subscribers to set their own SubIDs. <note>Another way to implement content-based subscriptions is to host one node per keyword or other filter; however, this is likely to require an extremely large number of nodes.</note></p>
<p>A service MAY enable entities to subscribe to nodes and apply a filter to notifications (e.g., keyword matching such as "send me all news entries from Slashdot that match the term 'XMPP'"). Such a content-based service SHOULD allow an entity to subscribe more than once to the same node and, if so, MUST use subscription identifiers (SubIDs) to distinguish between multiple subscriptions. In order to prevent collisions, a service that supports content-based subscriptions using SubIDs SHOULD generate SubIDs on behalf of subscribers rather than allowing subscribers to set their own SubIDs. <note>Another way to implement content-based subscriptions is to host one node per keyword or other filter; however, this is likely to require an extremely large number of nodes.</note></p>
<p>Content-based services SHOULD use subscription options to specify the filter(s) to be applied. Because there many possible filtering mechanisms (many of which may be application-specific), this document does not define any such method. However, filtering mechanisms may be defined in separate specifications.</p>
<p>A fictional example of the subscription options configuration process for content-based pubsub is shown below.</p>
<example caption='A content-based subscription'><![CDATA[
@ -5859,7 +5869,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<var>
<name>http://jabber.org/protocol/pubsub#last-published</name>
<desc>
The service supports sending of the last published item to new
The service supports sending of the last published item to new
subscribers and to newly available resources.
</desc>
<doc>XEP-0060</doc>
@ -6211,7 +6221,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<field var='pubsub#description'
type='text-single'
label='A description of the node'/>
<field var='pubsub#item_expire'
<field var='pubsub#item_expire'
type='text-single'
label='Number of seconds after which to automatically purge items'/>
<field var='pubsub#itemreply'
@ -6283,7 +6293,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<value>open</value>
</option>
</field>
<field var='pubsub#purge_offline'
<field var='pubsub#purge_offline'
type='boolean'
label='Whether to purge all items when the relevant publisher goes offline'/>
<field var='pubsub#roster_groups_allowed'
@ -6302,7 +6312,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<value>on_sub_and_presence</value>
</option>
</field>
<field var='pubsub#tempsub'
<field var='pubsub#tempsub'
type='boolean'
label='Whether to make all subscriptions temporary, based on subscriber presence'/>
<field var='pubsub#subscribe' type='boolean'
@ -6326,7 +6336,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
<doc>XEP-0060</doc>
<desc>
Forms enabling publication with options; each field must specify whether it
defines METADATA to be attached to the item, a per-item OVERRIDE of the node
defines METADATA to be attached to the item, a per-item OVERRIDE of the node
configuration, or a PRECONDITION to be checked against the node configuration.
</desc>
<field var='pubsub#access_model'