moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

fix terminolgy

Browse Source 
XMPP vs Jabber
This commit is contained in:
Stefan Strigler 2016-07-18 10:55:29 +02:00
parent ccb7644dea
commit 455e42d6f3
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
xep-0060.xml
View File

@ -243,7 +243,7 @@
<version>1.0</version>
<date>2003-10-28</date>
<initials>psa</initials>
<remark><p>Per a vote of the Jabber Council, advanced status to Draft.</p></remark>
<remark><p>Per a vote of the XMPP Council, advanced status to Draft.</p></remark>
</revision>
<revision>
<version>0.16</version>
@ -444,7 +444,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 +471,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 +481,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 a 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 +1141,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 a 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'
@ -5241,7 +5241,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 +5530,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[