Removed mentions of presence stanzas; added section on discovering support; added section on substantive changes in Final state.
Incorporated errata: (1) clarified rules regarding inclusion of option and value elements depending on field type; (2) clarified handling of default values; (3) added value elements to list-multi field in Example 2; (4) harmonized spelling of form-processing entity and form-submitting entity.
Incorporated errata: (1) corrected syntax of <reported/> element (<field/> element should not contain a <value/> child); (2) corrected Example 8.
Clarified terminology regarding form-processing entities and form-submitting entities; corrected several small errors in the schema.
Per discussion by the authors and Jabber Council, specified that the 'var' attribute is required for all field types except "fixed", for which the 'var' attribute is optional.
Formalization and further editorial revisions.
Editorial revisions.
Added schema.
Per a vote of the Jabber Council, changed status to Final.
Call for Experience changes (see Changes in Draft State section). This version voted to Final on 2002-12-09.
Per a vote of the Jabber Council, changed status to Draft.
Protocol tweaks based on Standards list discussion.
Protocol tweaks based on implementation and discussion.
Major redesign to attempt to clarify the scope of this document and limit what it is trying to solve.
Protocol update
Protocol update and DocBook version
Initial release
The &X; element qualified by the 'jabber:x:data' namespace SHOULD be included as a first-level child of an XML stanza; the stanza MAY be of any kind (&IQ;, &MESSAGE;, or &PRESENCE;), although it is RECOMMENDED to use &IQ; or &MESSAGE; (see also the restrictions enumerated below).
+The &X; element qualified by the 'jabber:x:data' namespace SHOULD be included either directly as a first-level child of a &MESSAGE; stanza or as a second-level child of an &IQ; stanza (where the first-level child is an element qualified by a "wrapper" namespace); see also the restrictions enumerated below.
The OPTIONAL <title/> and <instructions/> elements enable the form-processing entity to label the form as a whole and specify natural-language instructions to be followed by the form-submitting entity. The XML character data for these elements SHOULD NOT contain newlines (the \n and \r characters), and any handling of newlines (e.g., presentation in a user interface) is unspecified herein; however, multiple instances of the <instructions/> element MAY be included.
The data gathered or provided in a 'jabber:x:data' form can be situated in a number of different contexts. Examples include an empty form that needs to be filled out, a completed form, the results of a submission, a search result, or simply a set of data that is encapsulated using the 'jabber:x:data' namespace. The full context for the data is provided by three things:
@@ -194,7 +200,6 @@For &IQ; stanzas, the root element qualified by the "wrapper" namespace in a form of type "form" or "submit" MUST be returned in a form of type "result". The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the "wrapper" namespace's root element. As defined in &xmppcore;, the 'id' attribute MUST be copied in the IQ result. For data forms of type "form" or "result", the &IQ; stanza SHOULD be of type "result". For data forms of type "submit" or "cancel", the &IQ; stanza SHOULD be of type "set".
For &MESSAGE; stanzas, the <thread/> SHOULD be copied in the reply if provided. The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the &MESSAGE; stanza.
The only data form type allowed for <presence/> stanzas is "result". The &X; element qualified by the 'jabber:x:data' namespace MUST be a child of the &PRESENCE; stanza. In accordance with XMPP Core, use of data forms is not recommended unless necessary to provide information that is directly related to an entity's network availability.
If an entity supports inclusion of the &X; element qualified by the 'jabber:x:data' namespace as a direct child of the &MESSAGE; stanza type, it MUST report support by including a service discovery feature of "jabber:x:data" &NSNOTE; in response to a Service Discovery information request:
+If an entity supports data forms indirectly through inclusion of data forms in a wrapper namespace (rather than directly within a &MESSAGE; stanza), it MUST NOT advertise support for the 'jabber:x:data' namespace, since support is implicit in support for the wrapper protocol.
+There are no security concerns related to this specification above and beyond those described in the relevant section of XMPP Core.
The following protocol changes were incorporated in the Final specification as a result of experience with the Draft specification (described in version 1.0 of this document):
+The following substantive protocol changes have been made while this specification has been in the Final state:
The following substantive protocol changes were made while this specification was in the Draft state:
+