[Standards] (MIX) - When to increment Namespace

Kevin Smith kevin.smith at isode.com
Wed Jun 14 07:22:00 UTC 2017

On 14 Jun 2017, at 08:12, Steve Kille <steve.kille at isode.com> wrote:
> Jonas,
>>> I have not pushed as a PR because of namespace numbering.      It seems
>>> likely that if a change is pushed every time we make a protocol tweak,
>>> there is going to be a serious problem of namespace number proliferation.
>>> I think the options are:
>>> 1.  Keep changes on a working branch and defer pushing.    This gives less
>>> visibility of work in progress.
>>> 2.  Push and increment namespace.   Problem noted above.
>>> 3.  Push the PR and leave version number on mix:0.    I think this may be
>>> the pragmatic solution,  provided it does not cause a problem for
>>> those coding.
>> This is a general question. In software library development, one would have
>> a major update (here: things which require a namespace bump) branch and a
>> minor update (here: things which do not require a namespace bump) branch,
>> with the minor changes continuously flowing in the currently supported
>> release.
>> However, the XEP process does not make it easy to have these two branches
>> exist in parallel in a manner which allows easy viewing and discussing.

We basically have this already in XEPs. Here, your ‘major’ versions would be those that introduce incompatibilities and an entity implementing one won’t interop with an entity implementing the other - these are signified with a namespace bump of some sort. The minor versions are those that don’t break interoperability, and only bump the XEP version.

> I think the software analogy is a good one.   It feels sensible to increment namespace at "key delivery points" rather than for each minor protocol twiddle.

Indeed. They only need to be bumped where two entities couldn’t interoperate and need the bump to signify they’re implementing different things.

> An implementation supporting mix:2 might have some fallback if it gets mix:1 PDUs.       I find it harder to see something supporting mix:42 having fallback for a mix:37 PDU.

Yes, namespace proliferation in this way is not great. But while it’s hard to see something supporting both mix:42 and mix:37, it’s impossible to see something supporting mix:3 and mix:3, which are different and incompatible protocol but completely indistinguishable until the entity silently fails to process something you sent.

> MIX 0.9.3 has made a protocol change relative to MIX 0.9.2.     The practical  question is - when do we change from mix:0 to mix:1?

The standard procedure is to bump every time there’s an incompatible change that can’t be mitigated by discovery.

>> In this particular case, I’d suggest seeking consensus`from those who work
>> on implementations. Or maybe someone deeper in the XSF has knowledge
>> about any requirements in the process regarding this, I haven’t looked it up.
> Some expert guidance would be appreciated

The right thing to do here is clear - the namespace should be bumped. The only justification for not doing this is if we were sure that all implementations of the current version (which I think is just Dave at the moment) and their deployments aren’t going to be inconvenienced by this.

My preference here, as I expect many more changes over the next few months as Tarun implements MIX and finds issues, is to bunch up the changes and publish them at once in October (or so) with a namespace bump.


More information about the Standards mailing list