[Standards] Namespaces, specifications, and protocol life cycles

Dave Cridland dave at cridland.net
Wed Sep 10 14:29:53 UTC 2008

On Wed Sep 10 02:54:19 2008, Peter Saint-Andre wrote:
> Dave Cridland wrote:
>> the advantage here is that if the protocol is stable earlier than  
>> its move to Draft - and actually, this is normally the case, a lot  
>> of the pre-draft stuff is specification wrangling rather than  
>> proptocol redesign - people can go ahead and implement it, and  
>> it'll continue to work.
>> Otherwise, as we get closer to Draft, we're actually putting  
>> people off implementation at the very moment we want to encourage  
>> it.
> I think that's the key bit.
> But how much are developers scared off by the need to support both  
> urn:xmpp:tmp:foo and urn:xmpp:foo? It seems to me that's just a  
> simple switch statement in your code.

No, it's not, because urn:xmpp:tmp:* is actually meaningless. These  
namespaces are used for documents in wild fluidity, and one  
implementation's urn:xmpp:tmp:foo may well be completely different  
from another's.

A specification might stay stable for months, if not years, with a  
:tmp: namespace, only to change later.

And in any case, if urn:xmpp:tmp:foo really is just a swich statement  
away from urn:xmpp:foo, then why bother with tmp at all?

FWIW, I definitely prefer to have :tmp: instead of a 0-version,  
because it makes it clear that version changing is unusual, whereas   
:tmp: really means "unknown namespace".

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list