xeps/inbox/nsver.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Namespace Versioning in urn:xmpp</title>
  <abstract>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.</abstract>
  &LEGALNOTICE;
  <number>XXXX</number>
  <status>Experimental</status>
  <type>Informational</type>
  <sig>Standards</sig>
  <dependencies/>
  <supersedes/>
  <supersededby/>
  <shortname>namespace</shortname>
  &dcridland;
  &stpeter;
  <revision>
    <version>0.0.2</version>
    <date>2015-04-07</date>
    <initials>dc</initials>
    <remark><p>Noticed two conversations in two weeks. Must be time to reify this one. Added two new misconceptions; the author vs registrar one was mine.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2011-05-19</date>
    <initials>dc</initials>
    <remark><p>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.</p></remark>
  </revision>
</header>

<section1 topic='Introduction' anchor='intro'>
  <p>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.</p>
  <p>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.</p>
</section1>

<section1 topic='Rationale' anchor='rationale'>
  <section2 topic='Before The Dawn Of Time' anchor='before'>
    <p>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.</p>
    <p>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.</p>
  </section2>
  <section2 topic='Namespace Versioning' anchor='versioning'>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
  </section2>
</section1>

<section1 topic='Misconceptions' anchor='protocol'>
  <section2 topic="Namespaces can't be versioned!">
    <p>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.</p>
    <p>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.</p>
  </section2>
  <section2 topic='Versions happen on every change'>
    <p>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.</p>
    <p>XEP-0053 Section 4, point 2, stipulates that new namespaces are only minted if the new revision is not backwards-compatible with the old.</p>
  </section2>
  <section2 topic='Namespaces change on advancement'>
    <p>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.</p>
  </section2>
  <section2 topic='Authors are responsible for namespaces'>
    <p>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.</p>
  </section2>
</section1>

<section1 topic='Internationalization Considerations' anchor='i18n'>
  <p>Namespace versions are an internal protocol feature, therefore i18n has no impact.</p>
</section1>

<section1 topic='Security Considerations' anchor='sec'>
  <p>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.</p>
</section1>

<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document requires no interaction with &IANA;. </p>
</section1>

<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>The &REGISTRAR; MAY sleep easier, knowing that people understand these things finally.</p>
</section1>

</xep>