From 2203f34e1dd3583c2522fa4514e931f7364e1059 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 21 May 2012 16:52:07 -0600 Subject: [PATCH] 1.2rc6 --- xep-0068.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xep-0068.xml b/xep-0068.xml index c3f4325d..3b3f6bd0 100755 --- a/xep-0068.xml +++ b/xep-0068.xml @@ -25,8 +25,8 @@ &hildjj; &stpeter; - 1.2rc5 - 2012-05-16 + 1.2rc6 + 2012-05-21 psa Removed mandates about x- prefix in accordance with IETF BCP, and added more specific recommendations for naming of fields in XSF and non-XSF forms. @@ -102,7 +102,7 @@
  • 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 SHOULD be namespaced with a URI controlled by the extending organization or project with a namespacing mechanism of &clark;, e.g., a field name of "{http://example.com/pubsub}time_restrictions".

    +

    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 using &clark;, 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".

    For reasons that are lost in the mists of time, some XMPP extension protocols produced by the XSF, such as &xep0045; and &xep0060;, 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.

    Note: Older versions of this specification mandated that unregistered field names had to begin with the prefix "x-". In accordance with &xdash;, that mandate has been removed. However, existing "x-" field names are acceptable and can be registered with the XMPP Registrar as described above.