From 24e446d0dd1b05c5bd180bd2cd66bc9868c15d0a Mon Sep 17 00:00:00 2001 From: stpeter Date: Tue, 18 Oct 2011 15:49:30 -0600 Subject: [PATCH] 1.2pre1 --- xep-0068.xml | 69 +++++++++++++++++----------------------------------- 1 file changed, 22 insertions(+), 47 deletions(-) diff --git a/xep-0068.xml b/xep-0068.xml index f7573b46..64bf7640 100644 --- a/xep-0068.xml +++ b/xep-0068.xml @@ -23,6 +23,12 @@ &hildjj; &stpeter; + + 1.2pre1 + 2011-10-18 + psa + Removed mandates about x- prefix. + 1.1 2004-07-07 @@ -83,23 +89,24 @@
  • If the FORM_TYPE is used in the context of a custom protocol, it MAY be registered.
    • - +

    While the value of the FORM_TYPE attribute SHOULD be considered an opaque string from the application perspective, the following rules apply:

      -
    1. For custom protocols, the name SHOULD be an HTTP URI that is managed by the namespace "owner".
      2. -
    2. For all new protocols approved by the XSF, the name MUST be an HTTP URI or IETF-style URN.
      3. +
    3. For custom protocols, the name SHOULD be an HTTP URI that is managed by the namespace owner (e.g., "http://example.com/foo").
      4. +
    4. For all new protocols approved by the XSF, the name MUST be a "urn:xmpp:*" URN in accordance with Section 4 of &xep0053;.
    5. For "legacy" protocols managed by the XSF, the name SHOULD use the old-style "jabber:*:*" format.
     -

    For FORM_TYPEs that are registered with the XMPP Registrar, the field names MUST conform to one of the following two conditions:

    +

    For FORM_TYPEs that are registered with the XMPP Registrar, the following rules apply:

      -
    1. If the field name is defined by the relevant XEP or by registration, the field name MUST be registered with the XMPP Registrar and MAY have any name (except a name that begins with "x-"), subject to approval by the XMPP Registrar.
      2. -
    2. If the field name is unregistered, the field name MUST begin with "x-".
      3. +
    3. If the field name is defined by the XSF (i.e., in a XEP), the field name MUST be registered with the XMPP Registrar.
      4. +
    4. If the field name is defined outside the XSF, the field name MAY be registered with the XMPP Registrar.
    -

    If the FORM_TYPE is not registered, the field name MAY have any name (presumably managed by the namespace "owner").

    +

    If the FORM_TYPE is not registered, the field MAY have any name (managed by the namespace owner).

    +

    Note: Older versions of this specification mandated that unregistered field names had to begin with the prefix "x-". In accordance with &xdash;, that mandate has been removed.

     - +

    Field values may also be registered; refer to the XMPP Registrar section of this document.

     @@ -132,7 +139,7 @@ ]]>     -

    In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', and all of the fields whose var names start with "pubsub#" would be registered with the XMPP Registrar, associated with that namespace.

    +

    In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', all of the fields whose names start with "pubsub#" are registered with the XMPP Registrar (see &xep0060;), and the custom "time_restrictions" field defined by the organization at example.com uses &clark; in the field name.

    @@ -151,7 +158,7 @@ label="Jabber ID of Subscriber"> sub1@foo.com - 09:00-12:00 13:00-17:00 @@ -161,15 +168,15 @@ ]]>     -

    If the FORM_TYPE field is not hidden, it MUST be ignored as a - context indicator.

    + +

    If the FORM_TYPE field is not hidden, it MUST be ignored as a context indicator.

    Balcony Scene (Act 2, Scene 2) But soft! What light through yonder window breaks? - + http://jabber.org/protocol/shakespeare @@ -179,34 +186,6 @@ - - ]]> -     - -

    When a FORM_TYPE is specified correctly, and an unknown field is found whose name does not start with "x-", a receiver MAY respond with an "Not Acceptable" error.

    - - - Balcony Scene (Act 2, Scene 2) - But soft! What light through yonder window breaks? - - http://jabber.org/protocol/shakespeare - - - - - - - - - - - - - - The field "light" is not acceptable. - - ]]>     @@ -317,16 +296,12 @@

    If the form is used in an IQ, the namespace of the <query/> element SHOULD match the base namespace of the FORM_TYPE. (One possible way of solving this problem would have been to reuse the <query/> tag from the IQ form of jabber:x:data within messages, but that would have meant that existing clients would not have been able to participate in these exchanges.)

    - -

    If the receiving entity believes that a specified field is invalid for the given FORM_TYPE, the receiver MAY respond to the sender with a "Not Acceptable" error; alternatively, the receiver MAY choose to ignore unknown fields.

    -     - -

    Security-conscious programs that are using this approach should be careful to process only agreed-upon fields, with agreed-upon types, or "x-" fields that are understood by a particular implementation and a user of that implementation.

    +

    Security-conscious programs that are using this approach should be careful to process only agreed-upon fields with agreed-upon types.

     -

    This document requires no interaction with &IANA; for now. However, if this document is submitted to the IETF later, IANA should be used to standardize the field names rather than the XMPP Registrar.

    +

    This document requires no interaction with &IANA; for now.