diff --git a/xep-0060.xml b/xep-0060.xml index c979f078..9fc7c80e 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -49,10 +49,10 @@ &ralphm; - 1.10pre2 - in progress, last updated 2007-07-17 + 1.10pre3 + in progress, last updated 2007-08-08 psa -

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.

 +

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.

 @@ -609,14 +609,6 @@ And by opposing end them?

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).

-

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:

-

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 Create a Node With Default Configuration and Configure a Node sections of this document).

@@ -2544,45 +2536,15 @@ And by opposing end them? ]]> -

The following rules apply:

+

The <publish-options/> element SHOULD contain a data form (see XEP-0004), whose FORM_TYPE SHOULD be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).

+

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.

+

For example, the service may treat the field as a precondition, in which case the service should proceed as follows:

    -
  1. The <publish-options/> element SHOULD contain a data form (see XEP-0004).
    2. -
  2. If a data form is included, the FORM_TYPE SHOULD be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).
    3. -
  3. Fields registered with the XMPP Registrar for that FORM_TYPE MUST specify how they are to be handled by the form-processing entity.
    4. +
  4. 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 <precondition-not-met/>.
    5. +
  5. If the node exists and the precondition is met, then the publish succeeds.
    6. +
  6. 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.
    7. +
  7. If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.
-

Specifically, the following field handling methods are defined:

- -

These are defined more fully below.

- -

A service shall handle metadata fields as follows:

-
    -
  1. If the node exists, then the publish shall succeed and the service shall attach the metadata to the item.
    2. -
  2. 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.
    3. -
  3. If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.
    4. -
- - -

A service shall handle override fields as follows:

-
    -
  1. 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 <override-forbidden/>.
    2. -
  2. If the node exists and the override can be applied, then the publish shall succeed.
    3. -
  3. 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.
    4. -
  4. If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.
    5. -
- - -

A service shall handle precondition fields as follows:

-
    -
  1. 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 <precondition-not-met/>.
    2. -
  2. If the node exists and the precondition is met, then the publish succeeds.
    3. -
  3. 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.
    4. -
  4. If the node does not exist and the service does not support the "auto-create" feature, then the publish shall fail.
    5. -
- @@ -5629,31 +5591,6 @@ O, what a rogue and peasant slave am I!

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.

- http://jabber.org/protocol/pubsub#access-authorize - The default access model is authorize. - XEP-0163 - - - http://jabber.org/protocol/pubsub#access-open - The default access model is open. - XEP-0163 - - - http://jabber.org/protocol/pubsub#access-presence - The default access model is presence. - XEP-0163 - - - http://jabber.org/protocol/pubsub#access-roster - The default access model is roster. - XEP-0163 - - - http://jabber.org/protocol/pubsub#access-whitelist - The default access model is whitelist. - XEP-0163 - http://jabber.org/protocol/pubsub#auto-create The service supports automatic creation of nodes on first publish.