Re: [Standards] XEP-0068 & "x-"
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 wit
Re: [Standards] XEP-0068 & "x-"
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.
Re: [Standards] XEP-0068 & "x-"
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" 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
Re: [Standards] XEP-0068 & "x-"
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" 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 Notatio
Re: [Standards] XEP-0068 & "x-"
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" 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 th
Re: [Standards] XEP-0068 & "x-"
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).
Re: [Standards] XEP-0068 & "x-"
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 > >
[Standards] XEP-0068 & "x-"
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