XEP-0068: Field Standardization for Data Forms

Abstract:This document specifies how to standardize field variables used in the context of jabber:x:data forms.
Authors:Joe Hildebrand, Peter Saint-Andre
Copyright:© 1999 - 2010 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Active
Type:Informational
Version:1.1
Last Updated:2004-07-07

NOTICE: This Informational specification defines a best practice or protocol profile that has been approved by the XMPP Council and/or the XSF Board of Directors. Implementations are encouraged and the best practice or protocol profile is appropriate for deployment in production systems.

Table of Contents


1. Introduction
2. Requirements
3. Approach
    3.1. Overview
    3.2. Whether to Register
    3.3. Naming Convention
    3.4. Field Names
    3.5. Field Values
4. Use Cases
    4.1. Unspecified Form
    4.2. Correctly Specified FORM_TYPE
    4.3. Incorrectly Specified FORM_TYPE
    4.4. Message with Bad Field
    4.5. IQ Example
5. Implementation Notes
6. Error Codes
7. Security Considerations
8. IANA Considerations
9. XMPP Registrar Considerations
    9.1. Registries
       9.1.1. FORM_TYPEs Registry
         9.1.1.1. Process

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

Now that Data Forms [1] has been finalized, several uses of jabber:x:data forms have been put on the standards track, including Multi-User Chat [2]. 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 XMPP Registrar [3] 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.

2. Requirements

  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.

3. Approach

3.1 Overview

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

3.2 Whether to Register

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 XMPP Standards Foundation (XSF) [4], 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.

3.3 Naming Convention

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. For all new protocols approved by the XSF, the name MUST be an HTTP URI or IETF-style URN.
  3. For "legacy" protocols managed by the XSF, the name SHOULD use the old-style "jabber:*:*" format.

3.4 Field Names

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

  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. If the field name is unregistered, the field name MUST begin with "x-".

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

3.5 Field Values

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

4. Use Cases

4.1 Unspecified Form

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

Example 1. Message with no FORM_TYPE

<message 
    from='juliet@capulet.com/balcony'
    to='romeo@montague.net/garden'>
  <thread>vote-thread-reatmon-134</thread>
  <x xmlns='jabber:x:data' type='form'>
    <title>Vote #134</title>
    <instructions>
      This is the vote to pick a new mascot. 
      Thanks for your time!
    </instructions>
    <field var='mascot' type='list-single'>
      <required/>
      <option label='Light Bulb'><value>light_bulb</value></option>
      <option label='Penguin'><value>penguin</value></option>
      <option label='Moose'><value>moose</value></option>
      <option label='Triangle Man'><value>triangle_man</value></option>
      <option label='Other'><value>other</value></option>
    </field>
  </x>
</message>

4.2 Correctly Specified FORM_TYPE

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.

Example 2. Message with FORM_TYPE

<message to="node-owner" from="pubsub.jabber.org">
    <x xmlns="jabber:x:data" type="form">
       <title>PubSub subscriber request</title>
       <instructions>To approve this entity's subscription request,
            click the OK button. To deny the request, click the
            cancel button.</instructions>
       <field var="FORM_TYPE" type="hidden">
           <value>http://jabber.org/protocol/pubsub</value>
       </field>
       <field var="pubsub#node" type="hidden">
           <value>generic/pgm-mp3-player</value>
       </field>
       <field var="pubsub#subscriber_jid" type="jid-single" 
              label="Jabber ID of Subscriber">
           <value>sub1@foo.com</value>
       </field>
       <field var="x-time_restrictions" type="text-multi" 
              label="Limit to these time ranges">
           <value>09:00-12:00</value>
           <value>13:00-17:00</value>
       </field>
    </x>
</message>

4.3 Incorrectly Specified FORM_TYPE

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

Example 3. Message with bad FORM_TYPE

<message to="juliet@capulet.com" from="romeo@montague.net/garden">
    <x xmlns="jabber:x:data" type="form">
       <title>Balcony Scene (Act 2, Scene 2)</title>
       <instructions>But soft! What light through yonder window breaks?</instructions>
       <!-- Not hidden.  Treated as any other text-single field: -->
       <field var="FORM_TYPE" type="text-single">
         <value>http://jabber.org/protocol/shakespeare</value>
       </field>
       <field var="light" type="list-multi">
           <option label="Juliet">Sun</option>
           <option lable="Maid">Moon</option>
           <option label="Eyes">Stars</option>
       </field>
    </x>
</message>

4.4 Message with Bad Field

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.

Example 4. Message with bad field

<message to="juliet@capulet.com" from="romeo@montague.net/garden">
    <x xmlns="jabber:x:data" type="form">
       <title>Balcony Scene (Act 2, Scene 2)</title>
       <instructions>But soft! What light through yonder window breaks?</instructions>
       <field var="FORM_TYPE" type="hidden">
           <value>http://jabber.org/protocol/shakespeare</value>
       </field>
       <field var="light" type="list-multi">
           <option label="Juliet">Sun</option>
           <option lable="Maid">Moon</option>
           <option label="Eyes">Stars</option>
       </field>
    </x>
</message>

<message from="juliet@capulet.com" to="romeo@montague.net/garden" type="error">
  <error code="406" type='modify'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
      The field "light" is not acceptable.
    </text>
  </error>
</message>

4.5 IQ Example

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

Example 5. User Requests Registration Requirements

<iq
    from='hag66@shakespeare.lit/pda'
    to='darkcave@macbeth.shakespeare.lit'
    type='get'
    id='reg1'>
  <query xmlns='jabber:iq:register'/>
</iq>

Example 6. Service Returns Registration Form

<iq 
    type='result'
    from='darkcave@macbeth.shakespeare.lit'
    to='hag66@shakespeare.lit/pda'
    id='reg1'>
  <query xmlns='jabber:iq:register'>
    <instructions>
      To register on the web, visit http://shakespeare.lit/
    </instructions>
    <x xmlns='jabber:x:data' type='form'>
      <title>Dark Cave Registration</title>
      <instructions>
        Please provide the following information
        to register with this room.
      </instructions>
      <field
          type='hidden'
          var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#user</value> 
      </field>
      <field 
          type='text-single'
          label='First Name'
          var='muc#user_first'>
        <required/>
      </field>
      <field 
          type='text-single'
          label='Last Name'
          var='muc#user_last'>
        <required/>
      </field>
      <field 
          type='text-single'
          label='Desired Nickname'
          var='muc#user_roomnick'>
        <required/>
      </field>
      <field 
          type='text-single'
          label='Your URL'
          var='muc#user_url'/>
      <field 
          type='text-single'
          label='Email Address'
          var='muc#user_email'/>
      <field 
          type='text-multi'
          label='FAQ Entry'
          var='muc#user_faqentry'/>
    </x>
  </query>
</iq>

Example 7. User Submits Registration Form

<iq 
    type='set'
    from='hag66@shakespeare.lit/pda'
    to='darkcave@macbeth.shakespeare.lit'
    id='reg2'>
  <query xmlns='jabber:iq:register'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='FORM_TYPE'>
        <value>http://jabber.org/protocol/muc#user</value> 
      </field>
      <field var='muc#user_first'>
        <value>Brunhilde</value>
      </field>
      <field var='muc#user_last'>
        <value>Entwhistle-Throckmorton</value>
      </field>
      <field var='muc#user_roomnick'>
        <value>thirdwitch</value>
      </field>
      <field var='muc#user_url'>
        <value>http://witchesonline/~hag66/</value>
      </field>
      <field var='muc#user_email'>
        <value>hag66@witchesonline</value>
      </field>
      <field var='muc#user_faqentry'>
        <value>Just another witch.</value>
      </field>
    </x>
  </query>
</iq>

5. Implementation Notes

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

6. Error Codes

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.

7. Security Considerations

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.

8. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [5] 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.

9. XMPP Registrar Considerations

9.1 Registries

9.1.1 FORM_TYPEs Registry

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

9.1.1.1 Process

In order to submit new values to this registry, the registrant shall define an XML fragment of the following form and either include it in the relevant XMPP Extension Protocol or send it to the email address <registrar@xmpp.org>:

<form_type>
  <name>FORM_TYPE namespace or namespace derivative</name>
  <doc>associated specification</doc>
  <desc>natural-language description of form type</desc>
  <field
      var='the_field_name'
      type='the_field_type'
      label='natural-language description of field'/>
</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>
  <name>FORM_TYPE namespace or namespace derivative</name>
  <doc>associated XEP or other document</doc>
  <desc>natural-language description of form type</desc>
  <field
      var='the_field_name'
      type='the_field_type'
      label='natural-language description of field'>
    <option label='natural-language description of option'>
      <value>the_value</value>
    </option>
  </field>
</form_type>

Appendices

Appendix A: Document Information

Series: XEP
Number: 0068
Publisher: XMPP Standards Foundation
Status: Active
Type: Informational
Version: 1.1
Last Updated: 2004-07-07
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0004
Supersedes: None
Superseded By: None
Short Name: formtypes
Registry: <http://xmpp.org/registrar/formtypes.html>
Source Control: HTML  RSS

Appendix B: Author Information

Joe Hildebrand

Email: jhildebr@cisco.com
JabberID: hildjj@jabber.org

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2010 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.

2. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

3. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

4. The XMPP Standards Foundation (XSF) is an independent, non-profit membership organization that develops open extensions to the IETF's Extensible Messaging and Presence Protocol (XMPP). For further information, see <http://xmpp.org/xsf/>.

5. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 1.1 (2004-07-07)

Specified ability to standardize field option values. (psa)

Version 1.0 (2003-08-18)

Per a vote of the Jabber Council, advanced status to Active. (psa)

Version 0.3 (2003-06-05)

Specified rules regarding registration and naming of FORM_TYPEs and associated fields. (psa)

Version 0.2 (2003-05-09)

Clarified the relation of FORM_TYPE to registered namespaces; defined registry format; added IQ example. (psa)

Version 0.1 (2003-01-22)

Initial version. (jjh)

END