From fdccd56700ba5b778a7b2bc861a985f7b97a728c Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Fri, 10 Apr 2015 08:37:56 -0600 Subject: [PATCH] Proto-XEP Namespace Versioning in urn:xmpp --- inbox/nsver.xml | 85 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 inbox/nsver.xml diff --git a/inbox/nsver.xml b/inbox/nsver.xml new file mode 100644 index 00000000..1039598f --- /dev/null +++ b/inbox/nsver.xml @@ -0,0 +1,85 @@ + + +%ents; +]> + + +
+ Namespace Versioning in urn:xmpp + This document describes the common practise of namespace versioning for the urn:xmpp URN namespace, and how this affects (and does not affect) the protocols which have such namespaces. + &LEGALNOTICE; + XXXX + Experimental + Informational + Standards + None + None + namespace + &dcridland; + &stpeter; + + 0.0.2 + 2015-04-07 + dc +

Noticed two conversations in two weeks. Must be time to reify this one. Added two new misconceptions; the author vs registrar one was mine.

 + + + 0.0.1 + 2011-05-19 + dc +

After the third person in a single month thought that namespace versioning is a bad idea, wrote this background informational XEP to explain the rationale behind XEP-0053ยง4.

 + +
+ + +

Over the years that the XMPP registrar has been issuing namespaces for protocols, a number of namespace formats and issuance strategies have been attempted. As of the time of writing, the current one, defined in XEP-0053 Section 4, has proven successful, but many newcomers to the XSF are surprised to see version numbers in namespaces and have often misconstrued these to be in violation of XML namespace handling.

+

This document attempts to provide rationale behind why these were adopted, why they are successful, and why they are not in violation of the XML namespace rules.

+ + + + +

In the beginning, namespaces were simply minted, but relatively early on, it was observed that experimental protocols were often deployed, leading to pollution and devaluation of the namespace. If two incompatible variants of a protocol used the same namespace, then this could easily lead to a situation whereby Draft or Final stage protocols had difficulty deploying because they'd fail to interoperate, and often "choke", when faced with older variants of the protocol.

+

In order to combat this, during the switchover to the "urn:xmpp" URN namespace, URNs of the form "urn:xmpp:tmp:foo" were used for Experimental stage protocols. Only on their advancement to Draft would the "tmp" be removed, meaning that non-tmp forms were sure to be the Draft variant.

+ + +

Although this prevented Draft/Final protocol implementations from being choked by Experimental protocols, and therefore retained the value of the Draft/Final namespace, it left Experimental protocols with weak interoperability. In particular, since a namespace was certain to change at Draft, implementors were discouraged from implementing Experimental protocols to some extent, and it was observed that the benefit of early implementation experience was harmed.

+

Namespace versioning was therefore introduced. Each new XEP is, in effect, allocated an arc or tree of the URN namespace, and any time the protocol is changed such that it would fail to interoperate with older versions of the protocol, a new namespace from this arc is minted. To avoid reuse, limit the creativity needed, and provide some indication to implementors of which variant is newer, numbers are used.

+

However, each new namespace is indeed an entirely new namespace, and not only is no assertion of compatibility made, but it is only when there is either known (or high risk of) incompatibility that a new namespace is minted, so in effect there is an assertion made that the two variants are incompatible. This assertion is, of course, precisely in conformance with the definition (and even spirit) of XML namespaces.

+ + + + + +

With alarming frequency, someone new to the process usually suggests that the XSF has as a body failed to understand that a different namespace - however similar - is an entirely different namespace and thus denotes a different protocol.

+

It is important to realise that this is precisely the desired effect. When a new namespace is minted by this method, the protocol has been changed in an incompatible way, and implementations cannot make any assumption about what that change might consist of.

+ + +

Many changes to specifications do not result in an incompatibility between versions. This can even occur when the wire protocol has actually changed to some degree, if those changes are not observable without optional negotiation for example.

+

XEP-0053 Section 4, point 2, stipulates that new namespaces are only minted if the new revision is not backwards-compatible with the old.

+ + +

There is no particular significance to a namespace ending with ':0', and as such, namespaces do not require a change to a ':1' on advancement to Draft. In fact, a specification requiring such a change (due to incompatible changes introduced during Last Call) might be questionable.

+ + +

While it is typically left to authors to change namespaces, this is technically an XMPP Registrar function. How the Registrar decides whether to create a new namespace by incrementing the version number is unspecified; they might choose to consult with Council or the community.

+ + + + +

Namespace versions are an internal protocol feature, therefore i18n has no impact.

+ + + +

Any attempt to handle unknown protocol namespaces by heuristically treating them as another protocol namespace - including especially other versions of the same protocol namespace root - may expose an attack surface.

+ + + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; MAY sleep easier, knowing that people understand these things finally.

+ + +