%ents; ]>
Field Standardization for Data Forms This document specifies how to standardize field variables used in the context of jabber:x:data forms. &LEGALNOTICE; 0068 Active Informational Standards XMPP Core XEP-0004 formtypes &hildjj; &stpeter; 1.2pre1 2011-10-18 psa Removed mandates about x- prefix. 1.1 2004-07-07 psa Specified ability to standardize field option values. 1.0 2003-08-18 psa Per a vote of the Jabber Council, advanced status to Active. 0.3 2003-06-05 psa Specified rules regarding registration and naming of FORM_TYPEs and associated fields. 0.2 2003-05-09 psa Clarified the relation of FORM_TYPE to registered namespaces; defined registry format; added IQ example. 0.1 2003-01-22 jjh Initial version.

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.
  1. Forms must continue to be presentable to humans for data entry.
  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. 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).
  4. 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.
  5. 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).
  6. Forms must continue to be flexible for implementations; unknown future expansion fields must not be limited.
  7. The chosen approach must work for forms embedded in messages as well as in IQs.

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

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

  1. If the FORM_TYPE is used in the context of a form defined in a XEP published by the &XSF;, it MUST be registered.
  2. If the FORM_TYPE is used in the context of some other XMPP protocol but the form is not defined in a XEP, it MAY be registered.
  3. 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 (e.g., "http://example.com/foo").
  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. 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 following rules apply:

  1. If the field name is defined by the XSF (i.e., in a XEP), the field name MUST be registered with the XMPP Registrar.
  2. 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 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.

These are forms that do not have a hidden field of name FORM_TYPE. Existing processing rules still apply.

vote-thread-reatmon-134 Vote #134 This is the vote to pick a new mascot. Thanks for your time! ]]>

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.

PubSub subscriber request To approve this entity's subscription request, click the OK button. To deny the request, click the cancel button. http://jabber.org/protocol/pubsub generic/pgm-mp3-player sub1@foo.com 09:00-12:00 13:00-17:00 ]]>

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 ]]>

The following example shows a user's interaction with a Multi-User Chat room in order to register with the room.

]]> To register on the web, visit http://shakespeare.lit/ Dark Cave Registration Please provide the following information to register with this room. http://jabber.org/protocol/muc#user ]]> http://jabber.org/protocol/muc#user Brunhilde Entwhistle-Throckmorton thirdwitch http://witchesonline/~hag66/ hag66@witchesonline Just another witch. ]]>

If the FORM_TYPE field is not type="hidden", it does not have the special meaning defined herein.

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

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.

The XMPP Registrar shall maintain a registry of information about submitted FORM_TYPEs.

®PROCESS; FORM_TYPE namespace or namespace derivative associated specification natural-language description of form type ]]>

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.

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:

FORM_TYPE namespace or namespace derivative associated XEP or other document natural-language description of form type ]]>