[Standards] Namespaces, specifications, and protocol life cycles

Pavel Simerda pavlix at pavlix.net
Tue Sep 9 17:14:06 UTC 2008


historic reasons are IMO the main ones.

Dave's proposal is to avoid breaking already working
implementation. It's purely practical, not psycological.

The :tmp: proposal was a good start. But we see it was not good enough.
I suggest thinking and talking a bit before we agree on a new way.

Dave's reasons are good but the particualar schema could be still

Just to point out:

Some protocols further subdivide its URNs
 * urn:xmpp:tmp:[name]:[section]
 * urn:xmpp:[name]:[section]
where section may be a discovery feature PubSub namespace or whatever.
Replacing it by
 * urn:xmpp:[name]:[version]:[section]
(consistently with what Dave said)

If you use this style of versioning, I suggest to (if there are no
severe reasons against):

1) use the major versions of the XEPs as major versions are usually
intended for this sort of incompatible redesign. This would avoid
confusion with "just another revision number" and help maintain
backwards compatibility where necessary.
 * urn:xmpp:pubsub:2
   (if PubSub reaches version 2.x, otherwise we'd better keep
 * urn:xmpp:pubsub:2:errors
   (same but for http://jabber.org/protocol/pubsub#errors)

2) drop the 'tmp' and use major version 0.x instead (as it's already
 * urn:xmpp:search:0
 * urn:xmpp:search:0:users
 * urn:xmpp:search:0:servers

Note: This would also affect the best practice in protocol changes and
versioning. I personally believe this would provide more help than harm.
For version 0, incompatible changes would by allright, for higher
versions it would be sensible to add new features as optional (we
still have discovery) and possibly, in the future, they would be
marked REQUIRED all at once with a major protocol change.

I believe the incompatible changes for higher versions would be rare.


On Tue, 9 Sep 2008 18:04:32 +0200
Jehan <Jehan.3fh9on at no-mx.jabberforum.org> wrote:

> Hello,
> this is interesting, but does it bring something else than just
> psychology (not to make people afraid... which is already a good
> point, for sure)?
> I am not sure this is really necessary to force the maturity of a
> protocol if we have no way to really check it (which means: no real
> implementation).
> But there is a very interesting point also: currently a feature never
> gives its version (as far as I can remember). You only have a version
> for core XMPP (in the opening stream tag), but not for the additionnal
> features inside the stream.
> And I finish by a question for my personal knowledge, because I guess
> this has been discussed somewhere: why are the protocol namespaces (
> http://www.xmpp.org/registrar/namespaces.html ) in different forms,
> and especially the one in the form of an http url (for instance:
> "http://jabber.org/protocol/activity" )? Is it just historic for older
> XEP? Or another reason?
> Jehan


Pavel Šimerda
Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

More information about the Standards mailing list