[Standards] Namespaces, specifications, and protocol life cycles

Pavel Simerda pavlix at pavlix.net
Wed Sep 10 14:50:22 UTC 2008

On Wed, 10 Sep 2008 15:29:53 +0100
Dave Cridland <dave at cridland.net> 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.
> 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".

After thinking it through, I agree with you. But then I think we should
push the 0-version (after :tmp:) when we expect wider implementation and
not :tmp:. This is much earlier than we do with non-:tmp: versions now.


> Dave.


Pavel __imerda
Freelancer v oblasti po____ta__ov__ch s__t__, komunikace a bezpe__nosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

More information about the Standards mailing list