XMPP extensions that reuse Data Forms (XEP-0004) [1], such as Multi-User Chat (XEP-0045) [2] and Ad-Hoc Commands (XEP-0050) [3], 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 XMPP Registrar [4] 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.
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:
While the value of the FORM_TYPE attribute SHOULD be considered an opaque string from the application perspective, the following rules apply:
For FORM_TYPEs that are registered with the XMPP Registrar, the following rules apply:
For FORM_TYPEs that are not registered with the XMPP Registrar, the field name SHALL follow the extension rules described below and the field typically will not be registered with the XMPP Registrar.
The "namespace" of a field is assumed to be inherited from the FORM_TYPE. When an organization or project defines a field that is used in the context of a FORM_TYPE it does not manage (e.g., a non-XSF field contained in a form whose FORM_TYPE is managed by the XSF, or a third-party field contained in a form whose FORM_TYPE is managed by some other organization), the name of the field MUST be namespaced using Clark Notation [8], where the universal name portion SHOULD be a URI controlled by the extending organization or project, e.g., a field name of "{http://example.com/pubsub}time_restrictions".
For reasons that are lost in the mists of time, some XMPP extension protocols produced by the XSF, such as Multi-User Chat (XEP-0045) [2] and Publish-Subscribe (XEP-0060) [9], prefix their field names with strings like "muc#" and "pubsub#". There is no good reason to apply that convention to new XSF extensions. Indeed, there is even no good reason to apply that convention to the names of new fields defined by the XSF for those existing XSF extensions; however, the practice is harmless for those existing extensions (since a string such as "{http://jabber.org/protocol/pubsub#subscribe_authorization}pubsub#subscriber_jid" can be considered equivalent to a string such as "pubsub#subscriber_jid"), and this document does not actively recommend deprecating the convention.
Note: Older versions of this specification mandated that unregistered field names had to begin with the prefix "x-". In accordance with RFC 6648 [10], that mandate has been removed. However, existing "x-" field names are acceptable and can be registered with the XMPP Registrar as described above.
Field values MAY also be registered; refer to the XMPP Registrar section of this document.
FORM_TYPE names, field names, and field values MUST be compared as strings. The use of URIs in FORM_TYPE names and field names is simply a recommended method for insuring uniqueness, and other such methods are acceptable (e.g., Java-like reverse domain names such as "com.example.foo").
These are forms with type="form" or type="result" that do not have a hidden field of name FORM_TYPE or forms with type="submit" that do not have any field of name FORM_TYPE. Existing processing rules still apply.
<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>
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 Publish-Subscribe (XEP-0060) [9]), and the custom "time_restrictions" field defined by the organization at example.com uses Clark Notation in the field name.
<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#subscribe_authorization</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="{http://example.com/pubsub}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>
If the FORM_TYPE field is not hidden in a form with type="form" or type="result", it MUST be ignored as a context indicator.
<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>
The following example shows a user's interaction with a Multi-User Chat room in order to register with the room. Note that as per Data Forms (XEP-0004) [1] the form field "type" attribute may be omitted in data forms of type "submit".
<iq
from='hag66@shakespeare.lit/pda'
to='darkcave@macbeth.shakespeare.lit'
type='get'
id='reg1'>
<query xmlns='jabber:iq:register'/>
</iq>
<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>
<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>
If the FORM_TYPE field is not type="hidden" in a data form with type "form" or type "result", it does not have the special meaning defined herein. Data forms with the type "submit" are free to omit any explicit field type declaration (as per Data Forms (XEP-0004) [1] § 3.2), as the type is implied by the corresponding "form"-type data form. As consequence, implementations MUST treat a FORM_TYPE field without an explicit type attribute, in data forms of type "submit", as the FORM_TYPE field with 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 the Internet Assigned Numbers Authority (IANA) [11].
The XMPP Registrar shall maintain a registry of information about submitted FORM_TYPEs.
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 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>
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
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.
## 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. ##
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.
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 <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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.
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>.
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".
1. XEP-0004: Data Forms <https://xmpp.org/extensions/xep-0004.html>.
2. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.
3. XEP-0050: Ad-Hoc Commands <https://xmpp.org/extensions/xep-0050.html>.
4. 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 <https://xmpp.org/registrar/>.
5. 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 <https://xmpp.org/about/xmpp-standards-foundation>.
6. RFC 4854: A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc4854>.
7. XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>.
8. Clark Notation, a syntax to allow universal names written as a URI in curly brackets followed by the local name; developed by James Clark. <http://www.jclark.com/xml/xmlns.htm>.
9. XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>.
10. RFC 6648: Deprecating the X- Prefix and Similar Constructs in Application Protocols <http://tools.ietf.org/html/rfc6648>.
11. 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/>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
END