moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-22 07:38:52 -05:00
Code Issues Releases Wiki Activity

Table 5 clarifications

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1213 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-09-13 18:53:32 +00:00
parent 6ed5c5bf19
commit 3b5a972c3a
1 changed files with 11 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
xep-0060.xml
View File

@ -589,20 +589,22 @@ And by opposing end them?
<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>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>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>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>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>Whether an item must be provided by the publisher, and whether an item ID is provided by the publisher or generated by the pubsub service, depends on the type of event being published. We can summarize the relevant rules as follows:</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='Event Types, Items, and Item IDs'> <table caption='Items, Payloads, and Item IDs'>
<tr><th>&#160;</th><th>Notification</th><th>Payload</th></tr> <tr><th>&#160;</th><th>Notification-Only Node *</th><th>Payload-Included Node *</th></tr>
<tr> <tr>
<td><strong>Persistent</strong></td> <td><strong>Persistent Node **</strong></td>
<td>Publisher MUST include an &ITEM; element, which MAY be empty or contain a payload; if item ID is not provided by publisher, it MUST be generated by pubsub service</td> <td>Publish request MUST include an &ITEM; element, which MAY be empty or MAY contain a payload; even if publish request contains a payload, pubsub service MUST NOT include the payload in notifications; if publish request did not include item ID, pubsub service MUST generate item ID</td>
<td>Publisher MUST include an &ITEM; element that contains the payload; if item ID is not provided by publisher, it MUST be generated by pubsub service</td> <td>Publish request MUST include an &ITEM; element, which SHOULD contain a payload; if publish request included a payload, notifications MUST include the payload; if publish request did not include item ID, pubsub service MUST generate item ID</td>
</tr> </tr>
<tr> <tr>
<td><strong>Transient</strong></td> <td><strong>Transient Node **</strong></td>
<td>Publisher MUST NOT include an &ITEM; element (therefore item ID is neither provided nor generated) but the notification will include an empty &ITEMS; element</td> <td>Publish request MUST NOT include an &ITEM; element; payload is not included in publish request or notifications, although notifications MUST include an empty &ITEMS; element; item ID is neither provided in publish request nor generated by pubsub service</td>
<td>Publisher MUST include an &ITEM; element that contains the payload, but the item ID is OPTIONAL</td> <td>Publish request MUST include an &ITEM; element, which SHOULD contain a payload; if publish request included a payload, notifications MUST include the payload; pubsub service MAY generate an item ID</td>
</tr> </tr>
</table> </table>
<p>* Note: Whether the node is notification-only or includes payloads is determined by the "pubsub#deliver_payloads" configuration field.</p>
<p>** Note: Whether the node is persistent or transient is determined by the "pubsub#persist_items" configuration field.</p>
</section2> </section2>
<section2 topic='Node Types' anchor='nodetypes'> <section2 topic='Node Types' anchor='nodetypes'>