[Standards] Namespaces, specifications, and protocol life cycles
stpeter at stpeter.im
Wed Sep 10 14:59:44 UTC 2008
Dave Cridland wrote:
> 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
I see your point.
> A specification might stay stable for months, if not years, with a :tmp:
> namespace, only to change later.
True. We try to avoid that, but it happens.
> 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?
Because we want to make it clear that until a XEP is Draft, it's not
really official. It's merely a form of signalling, as far as I can see.
> 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".
I'm not deeply objecting to the idea, just getting used to it...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards