moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

1.10pre3

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1128 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-08-08 22:31:28 +00:00
parent 9c0ee09a5d
commit 7306da331e
1 changed files with 10 additions and 73 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
xep-0060.xml
View File

@ -49,10 +49,10 @@
&ralphm;
<revision>
<version>1.10pre2</version>
<date>in progress, last updated 2007-07-17</date>
<version>1.10pre3</version>
<date>in progress, last updated 2007-08-08</date>
<initials>psa</initials>
<remark><p>In accordance with XMPP Council consensus, moved the auto-create, auto-subscribe, filtered-notifications, and last-published features from XEP-0163 to this specification and defined them more precisely; defined one disco#info feature for each default access model; added publish-options functionality.</p></remark>
<remark><p>In accordance with XMPP Council consensus, moved the auto-create, auto-subscribe, filtered-notifications, and last-published features from XEP-0163 to this specification and defined them more precisely; added publish-options functionality.</p></remark>
</revision>
<revision>
@ -609,14 +609,6 @@ And by opposing end them?
</tr>
</table>
<p>A generic publish-subscribe implementation SHOULD support all of the defined access models, although specialized publish-subscribe implementations MAY support only a subset of the access models. Which access models are provided in a particular deployment is a matter of service provisioning (e.g., some restricted deployments may wish to lock down permissions so that only the "authorize" and "whitelist" access models are provided, or even only the "whitelist" access model).</p>
<p>A pubsub service SHOULD advertise its default access model for newly-created nodes by returning one of the following values in its disco#info responses:</p>
<ul>
<li>http://jabber.org/protocol/pubsub#access-authorize</li>
<li>http://jabber.org/protocol/pubsub#access-open</li>
<li>http://jabber.org/protocol/pubsub#access-presence</li>
<li>http://jabber.org/protocol/pubsub#access-roster</li>
<li>http://jabber.org/protocol/pubsub#access-whitelist</li>
</ul>
<p>A node creator or owner can override the default access model by specifying an appropriate value for the 'pubsub#access_model' configuration field (see the <link url='#owner-create'>Create a Node With Default Configuration</link> and <link url='#owner-configure'>Configure a Node</link> sections of this document).</p>
</section2>
@ -2544,45 +2536,15 @@ And by opposing end them?
</pubsub>
</iq>
]]></example>
<p>The following rules apply:</p>
<p>The &lt;publish-options/&gt; element SHOULD contain a data form (see <cite>XEP-0004</cite>), whose FORM_TYPE SHOULD be "http://jabber.org/protocol/pubsub#publish-options" (see <cite>XEP-0068</cite>).</p>
<p>How the fields are to be handled is up to the the pubsub service, which in the language of XEP-0004 functions as a form-processing entity.</p>
<p>For example, the service may treat the field as a precondition, in which case the service should proceed as follows:</p>
<ol>
<li>The &lt;publish-options/&gt; element SHOULD contain a data form (see <cite>XEP-0004</cite>).</li>
<li>If a data form is included, the FORM_TYPE SHOULD be "http://jabber.org/protocol/pubsub#publish-options" (see <cite>XEP-0068</cite>).</li>
<li>Fields registered with the XMPP Registrar for that FORM_TYPE MUST specify how they are to be handled by the form-processing entity.</li>
<li>If the node exists and the precondition is not met, then the publish shall fail with a &conflict; error condition and a pubsub-specific condition of &lt;precondition-not-met/&gt;.</li>
<li>If the node exists and the precondition is met, then the publish succeeds.</li>
<li>If the node does not exist and the service supports the "auto-create" feature, then the service shall auto-create the node with default configuration in all respects except those specified in the preconditions, and the publish succeeds.</li>
<li>If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.</li>
</ol>
<p>Specifically, the following field handling methods are defined:</p>
<ul>
<li>metadata -- the field specifies metadata that shall be attached to the item</li>
<li>override -- the field specifies an override of the node configuration only for this item</li>
<li>precondition -- the field specifies a precondition for publication of the item, which shall be checked against the node configuration</li>
</ul>
<p>These are defined more fully below.</p>
<section4 topic='Metadata Fields' anchor='publisher-publish-options-metadata'>
<p>A service shall handle metadata fields as follows:</p>
<ol>
<li>If the node exists, then the publish shall succeed and the service shall attach the metadata to the item.</li>
<li>If the node does not exist and the service supports the "auto-create" feature, then the service shall auto-create the node with default configuration and the publish shall succeed and the service shall attach the metadata to the item.</li>
<li>If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.</li>
</ol>
</section4>
<section4 topic='Override Fields' anchor='publisher-publish-options-override'>
<p>A service shall handle override fields as follows:</p>
<ol>
<li>If the node exists and the override cannot be applied because the publisher lacks permissions to override the feature, then the publish shall fail with a &forbidden; error condition and a pubsub-specific condition of &lt;override-forbidden/&gt;.</li>
<li>If the node exists and the override can be applied, then the publish shall succeed.</li>
<li>If the node does not exist and the service supports the "auto-create" feature, then the service shall auto-create the node with default configuration but apply the override to the item, and the publish shall succeed.</li>
<li>If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.</li>
</ol>
</section4>
<section4 topic='Precondition Fields' anchor='publisher-publish-options-precondition'>
<p>A service shall handle precondition fields as follows:</p>
<ol>
<li>If the node exists and the precondition is not met, then the publish shall fail with a &conflict; error condition and a pubsub-specific condition of &lt;precondition-not-met/&gt;.</li>
<li>If the node exists and the precondition is met, then the publish succeeds.</li>
<li>If the node does not exist and the service supports the "auto-create" feature, then the service shall auto-create the node with default configuration in all respects except those specified in the preconditions, and the publish succeeds.</li>
<li>If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.</li>
</ol>
</section4>
</section3>
</section2>
@ -5629,31 +5591,6 @@ O, what a rogue and peasant slave am I!
<section2 topic='Service Discovery Features' anchor='registrar-features'>
<p>The XMPP Registrar maintains a registry of service discovery features (see &DISCOFEATURES;), which includes a number of features that may be returned by pubsub services. The following registry submission has been provided to the XMPP Registrar for that purpose.</p>
<code><![CDATA[
<var>
<name>http://jabber.org/protocol/pubsub#access-authorize</name>
<desc>The default access model is authorize.</desc>
<doc>XEP-0163</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#access-open</name>
<desc>The default access model is open.</desc>
<doc>XEP-0163</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#access-presence</name>
<desc>The default access model is presence.</desc>
<doc>XEP-0163</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#access-roster</name>
<desc>The default access model is roster.</desc>
<doc>XEP-0163</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#access-whitelist</name>
<desc>The default access model is whitelist.</desc>
<doc>XEP-0163</doc>
</var>
<var>
<name>http://jabber.org/protocol/pubsub#auto-create</name>
<desc>The service supports automatic creation of nodes on first publish.</desc>