From b002951d6b6e6b2329e0753079ac96c91c252908 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 31 Jul 2007 22:25:03 +0000 Subject: [PATCH] feedback from ralphm git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1103 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0060.xml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/xep-0060.xml b/xep-0060.xml index b9d82659..c979f078 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -1502,7 +1502,7 @@ And by opposing end them? ]]> -

Note: The foregoing example shows some (but by no means all) of the possible configuration options that MAY be provided. If an implementation provides these options using the Data Forms protocol, it MUST use the field variables that are registered with the XMPP Registrar in association with the 'http://jabber.org/protocol/pubsub' namespace (a preliminary representation of those field variables is shown above and in the pubsub#subscribe_options FORM_TYPE section of this document, but MUST NOT be construed as canonical since the XMPP Registrar may standardize additional fields at a later date without changes to this document).

+

Note: The foregoing example shows some (but by no means all) of the possible configuration options that MAY be provided. If an implementation provides these options using the Data Forms protocol, it MUST use the field variables that are registered with the XMPP Registrar in association with the 'http://jabber.org/protocol/pubsub' namespace (a preliminary representation of those field variables is shown above and in the pubsub#subscribe_options FORM_TYPE section of this document, but MUST NOT be construed as canonical since the XMPP Registrar may standardize additional fields at a later date without changes to this document).

Note: Many of the relevant data form fields are of type "boolean" and MUST be handled accordingly. &BOOLEANNOTE;

There are several reasons why the options request might fail:

    @@ -2505,7 +2505,7 @@ And by opposing end them?

    A pubsub service MAY automatically create a node when it receives a publish request sent to a node that does not exist (instead of returning an ¬found; error). When doing so, the service SHOULD apply the default node configuration. If a service supports this functionality, it MUST advertise that fact by including a feature of "http://jabber.org/protocol/pubsub#auto-create" in its disco#info responses.

    -

    A pubsub service MAY support the ability to specify options along with a publish request. Here is an example:

    +

    A pubsub service MAY support the ability to specify options along with a publish request (if so, it MUST advertise support for the "http://jabber.org/protocol/pubsub#publish-options" feature). Here is an example:

    The following rules apply:

      -
    1. The <publish-options/> element MUST contain a data form (see XEP-0004).
      2. -
    2. The FORM_TYPE of the data form MUST be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).
      3. +
    3. The <publish-options/> element SHOULD contain a data form (see XEP-0004).
      4. +
    4. If a data form is included, the FORM_TYPE SHOULD be "http://jabber.org/protocol/pubsub#publish-options" (see XEP-0068).
    5. Fields registered with the XMPP Registrar for that FORM_TYPE MUST specify how they are to be handled by the form-processing entity.

    Specifically, the following field handling methods are defined:

    @@ -4993,6 +4993,12 @@ And by opposing end them? REQUIRED Publish an Item to a Node + + publish-options + Publishing an item with options is supported. + OPTIONAL + Publishing Options + publisher-affiliation The publisher affiliation is supported.