Based on further feedback from Ralph Meijer, I suggest that we might
want to add another paragraph to clarify existing usage:
###
For reasons that are lost in the mists of time, some XMPP extension
protocols produced by the XSF, such as Multi-User Chat [9] and
Publish-Subscribe [10], 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.
###
On 5/9/12 9:38 AM, Peter Saint-Andre wrote:
> In its meeting just now, the XMPP Council discussed [1] some changes to
> XEP-0068 (Field Standardization for Data Forms) to align this spec with
> a forthcoming recommendation at the IETF [2] to deprecate the "x-"
> prefix for protocol parameters.
>
> As a result of that discussion, I'm proposing some adjusted wording in
> Section 3.4, as follows:
>
> ###
>
> 3.4 Field Names
>
> For FORM_TYPEs that are registered with the XMPP Registrar, the
> following rules apply:
>
> 1. If the field is defined by the XSF (i.e., in a XEP), the field name
> SHALL be determined in accordance with the usual XSF consensus process
> and the field MUST be registered with the XMPP Registrar.
>
> 2. If the field is defined outside the XSF, the field name SHALL follow
> the extension rules described below and the field MAY be registered with
> the XMPP Registrar.
>
> For FORM_TYPEs that are not registered with the XMPP Registrar, the
> field name SHALL follow the extension fules 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 with a URI
> controlled by the extending organization or project, where the
> namespacing mechanism MUST be Clark Notation [8], e.g., a field name of
> "{http://example.com/pubsub}time_restrictions";.
>
> Note: Older versions of this specification mandated that unregistered
> field names had to begin with the prefix "x-". In accordance with
> Deprecating X- [9], that mandate has been removed. However, existing
> "x-" field names are acceptable and can be registered with the XMPP
> Registrar as described above.
>
> ###
>
> Feedback is welcome before the Council approves version 1.2rc3 of
> XEP-0068 as its next meeting (two weeks from now).
>
> Thanks!
>
> Peter
>
> [1] http://logs.xmpp.org/council/120509/#15:05:08
>
> [2] http://datatracker.ietf.org/doc/draft-ietf-appsawg-xdash/
>
> [8] http://www.jclark.com/xml/xmlns.htm
>
>
