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
>>>
>>>
- m&m
Matthew A. Miller
<http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
