From 6e38e498baf18b00a84eecb950e64c9db7686b91 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 17 Apr 2012 20:46:27 -0600 Subject: [PATCH] 1.2rc2 --- xep-0068.xml | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) mode change 100644 => 100755 xep-0068.xml diff --git a/xep-0068.xml b/xep-0068.xml old mode 100644 new mode 100755 index 5a508571..4762be0b --- a/xep-0068.xml +++ b/xep-0068.xml @@ -25,10 +25,10 @@ &hildjj; &stpeter; - 1.2pre1 - 2011-10-18 + 1.2rc2 + 2012-04-17 psa - Removed mandates about x- prefix. + Removed mandates about x- prefix in accordance with IETF recommendations. 1.1 @@ -62,25 +62,22 @@ -

Now that &xep0004; has been finalized, several uses of jabber:x:data forms have been put on the standards track, including &xep0045;. These protocols typically need a way to gather data from both humans (using a GUI format) and computer processes (using a pre-defined but flexible format).

-

The 'jabber:x:data' namespace provides an adequate mechanism for both of these uses, as long as computer processes can rely on the var="" names on a particular type of form.

-

This document proposes a specific mechanism for the ®ISTRAR; to standardize these form field variable names. Thus this document enables existing clients to process forms as they have to this point, but enables protocol authors to specify a mechanism for non-GUI processors of those forms to determine the semantic meanings of those forms.

+

XMPP extensions that reuse &xep0004;, such as &xep0045; and &xep0050;, typically need a way to gather data from both humans (using a GUI format) and computer processes (using a pre-defined but flexible format). The 'jabber:x:data' namespace provides an adequate mechanism for both of these uses, as long as computer processes can rely on the var="" names on a particular type of form. This document defines a mechanism for the ®ISTRAR; to standardize the field names in such forms, thus enabling XMPP clients to process forms as they have to this point while giving protocol authors a way to specify a mechanism for non-GUI processors to determine the semantic meanings of forms and their constituent fields.
  1. Forms must continue to be presentable to humans for data entry.
    2. -
  2. Jabber clients that know how to process generic jabber:x:data messages must be supported; the basic format of jabber:x:data must not change.
    3. +
  3. XMPP clients that know how to process generic jabber:x:data messages must be supported; the basic format of jabber:x:data must not change.
  4. If a form type is used in the context of a standards-track protocol, it should be standardized and registered; however, there is no requirement that all form types must be registered (e.g., form types used in custom applications).
    5. -
  5. If a form type is standardized and registered, field names used in the context of that form type must either be standardized as well or else be clearly labeled as unregistered.
  6. Forms that are not directed to an entity must be able to traverse the entity (e.g., a form sent to a MUC room, intended for the participants of the room, and not the room itself).
  7. Forms must continue to be flexible for implementations; unknown future expansion fields must not be limited.
    8. -
  8. The chosen approach must work for forms embedded in messages as well as in IQs.
    9. +
  9. The chosen approach must work for forms embedded in &MESSAGE; stanzas as well as in &IQ; stanzas.
 -

Within Jabber, namespaces are used to scope data that conforms to a schema (often data that extends the core protocol in some fashion). In addition, namespaces can also provide context for the field variable names used in jabber:x:data forms and reports. This proposal makes that link explicit by defining a mechanism for linking a namespace name with a form and the field names and types used in that form. Specifically, the namespace name is specified in the form as the value of a hidden variable called "FORM_TYPE".

+

Within XMPP, namespaces are used to scope data that conforms to a schema (often data that extends the core protocol in some fashion). In addition, namespaces can also provide context for the field variable names used in jabber:x:data forms and reports. This proposal makes that association explicit by defining a mechanism for linking a namespace name with a form along with the field names and types used in that form. Specifically, the namespace name is specified in the form as the value of a hidden variable called "FORM_TYPE".

The first decision-point is whether a FORM_TYPE needs to be registered with the XMPP Registrar. The following rules apply:

@@ -94,8 +91,8 @@

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 (e.g., "http://example.com/foo").
    2. -
  2. For all new protocols approved by the XSF, the name MUST be a "urn:xmpp:*" URN in accordance with Section 4 of &xep0053;.
    3. -
  3. For "legacy" protocols managed by the XSF, the name SHOULD use the old-style "jabber:*:*" format.
    4. +
  4. For all new protocols approved by the XSF, the name MUST be a "urn:xmpp:*" URN in accordance with &rfc4854; and Section 4 of &xep0053;.
    5. +
  5. For "legacy" protocols managed by the XSF, the name SHOULD use the old-style "jabber:*:*" or "http://jabber.org/protocol/*" format.
 @@ -108,7 +105,7 @@

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.

+

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

 @@ -302,7 +299,7 @@ -

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

+

This document requires no interaction with &IANA;.

 @@ -322,7 +319,7 @@ label='natural-language description of field'/> ]]> -

The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate <form_type/> element. The registrant MAY also register more than one field at a time, each contained in a separate <field/> child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the XEP number or other document identifier). Note that for ease of use the format for the <field/> element in the registry submission is the same as that defined in XEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in that XEP-0004.

+

The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate <form_type/> element. The registrant MAY also register more than one field at a time, each contained in a separate <field/> child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the XEP number or other document identifier). Note that for ease of use the format for the <field/> element in the registry submission is the same as that defined in XEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in XEP-0004.

In addition, a registrant MAY also register particular field option values for fields of type 'list-single' and 'list-multi'. The format for such submissions is as follows: