I interpret that as follows.
OLD
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 SHOULD be namespaced with a
URI controlled by the extending organization or project with a
namespacing mechanism of Clark Notation [8], e.g., a field name of
"{http://example.com/pubsub}time_restrictions";.
NEW
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 usin 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";.
It's not clear to me if Clark Notation allows universal names other than
URIs (e.g., Java-style reverse domain names), but then Clark Notation is
not a complete spec but just a convention to place the universal name in
curly braces.
On 5/16/12 8:23 AM, Matthew Miller wrote:
> From the original text, I think it's important to namespace, and I think it's
> important to agree how a namespace is included in the field name. Precisely
> how the namespace substring is formatted is less important; it can be a URI,
> a URN, a Java reverse-domain, or something else.
>
>
> On May 15, 2012, at 17:26, Peter Saint-Andre wrote:
>
>> I've been thinking about this further, and I'm not sure about the MUST
>> for the field name formatting, which in my working copy reads:
>>
>> ###
>>
>> 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";.
>>
>> ###
>>
>> There are two reasons why I'm skeptical.
>>
>> 1. For FORM_TYPE names, we say:
>>
>> For custom protocols, the name SHOULD be an HTTP URI
>> that is managed by the namespace owner (e.g.,
>> "http://example.com/foo";).
>>
>> It seems strange for field names to be MUST and FORM_TYPEs to be SHOULD.
>> We could change FORM_TYPE names to be MUST be an HTTP URI, too, but that
>> runs into reason #2...
>>
>> 2. Depending on the usage scenario, I can envision instances where an
>> organization defining a custom form might use naming scheme (consistent
>> with the xdash spec) other than HTTP URIs, e.g., Java-style reverse
>> domain names (e.g., "com.example.foo"). I see no good reason to force
>> such organizations to convert their field names into HTTP URIs.
>>
>> Therefore, I conclude that "MUST be unique and SHOULD be namespaced with
>> an HTTP URI using Clark Notation" is sufficient for field names, and
>> "MUST be unique and SHOULD be an HTTP URI" is sufficient for FORM_TYPE
>> names.
>>
>> I'll raise this issue in the next Council meeting if there is no
>> discussion on the list before then.
>>
>> On 5/9/12 11:01 AM, Peter Saint-Andre wrote:
>>> 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
>>>>
>>>>
