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".
OK. I'm not deeply objecting to the idea, just getting used to it... Peter
smime.p7s
Description: S/MIME Cryptographic Signature
