[Standards] Namespaces, specifications, and protocol life cycles
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
> 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
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
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards