moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

an XMPP ...

Browse Source
This commit is contained in:
Stefan Strigler 2016-07-18 17:51:31 +02:00
parent 455e42d6f3
commit 4c62b84b7c
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
xep-0060.xml
View File

@ -481,7 +481,7 @@ And by opposing end them?
</ul> </ul>
<!-- =================== MAYS and SHOULDS =================== --> <!-- =================== MAYS and SHOULDS =================== -->
<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> <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> <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 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> <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'> <section2 topic='Subscribe to a Node' anchor='subscriber-subscribe'>
<section3 topic='Request' anchor='subscriber-subscribe-request'> <section3 topic='Request' anchor='subscriber-subscribe-request'>
<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>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> <p>Here is an example of a subscription request.</p>
<example caption='Entity subscribes to a node'><![CDATA[ <example caption='Entity subscribes to a node'><![CDATA[
<iq type='set' <iq type='set'