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 field names MUST conform to one of the following two conditions:
+For FORM_TYPEs that are registered with the XMPP Registrar, the following rules apply:
If the FORM_TYPE is not registered, the field name MAY have any name (presumably managed by the namespace "owner").
+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.
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.
+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.
If the FORM_TYPE field is not hidden, it MUST be ignored as a - context indicator.
+ +If the FORM_TYPE field is not hidden, it MUST be ignored as a context indicator.
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.
-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.)
-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.
-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.
+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. However, if this document is submitted to the IETF later, IANA should be used to standardize the field names rather than the XMPP Registrar.
+This document requires no interaction with &IANA; for now.