[Standards] Namespaces, specifications, and protocol life cycles

Peter Saint-Andre 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 
> another's.

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...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080910/4a57d821/attachment.bin>

More information about the Standards mailing list