Thus I've checked in 1.2rc5: http://xmpp.org/extensions/tmp/xep-0068-1.2.html
http://xmpp.org/extensions/diff/api/xep/0068/diff/1.1/vs/1.2rc5 http://xmpp.org/extensions/diff/api/xep/0068/diff/1.2rc4/vs/1.2rc5 (the diffs don't render yet, but should soon) On 5/16/12 6:48 AM, Peter Saint-Andre wrote: > Exactly. > > On 5/15/12 11:44 PM, Joe Hildebrand wrote: >> That sounds fine to me. The real requirement is that the author is certain >> that the field name is not going to collide with anyone else's field name >> that might have a different meaning. >> >> >> On 5/15/12 5:26 PM, "Peter Saint-Andre" <[email protected]> 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 >>>>>
