Hello, historic reasons are IMO the main ones.
Dave's proposal is to avoid breaking already working implementation. It's purely practical, not psycological. The :tmp: proposal was a good start. But we see it was not good enough. I suggest thinking and talking a bit before we agree on a new way. Dave's reasons are good but the particualar schema could be still improved. Just to point out: Some protocols further subdivide its URNs * urn:xmpp:tmp:[name]:[section] * urn:xmpp:[name]:[section] where section may be a discovery feature PubSub namespace or whatever. Replacing it by * urn:xmpp:[name]:[version]:[section] (consistently with what Dave said) If you use this style of versioning, I suggest to (if there are no severe reasons against): 1) use the major versions of the XEPs as major versions are usually intended for this sort of incompatible redesign. This would avoid confusion with "just another revision number" and help maintain backwards compatibility where necessary. Examples: * urn:xmpp:pubsub:2 (if PubSub reaches version 2.x, otherwise we'd better keep http://jabber.org/protocol/pubsub) * urn:xmpp:pubsub:2:errors (same but for http://jabber.org/protocol/pubsub#errors) 2) drop the 'tmp' and use major version 0.x instead (as it's already done) Examples: * urn:xmpp:search:0 * urn:xmpp:search:0:users * urn:xmpp:search:0:servers Note: This would also affect the best practice in protocol changes and versioning. I personally believe this would provide more help than harm. For version 0, incompatible changes would by allright, for higher versions it would be sensible to add new features as optional (we still have discovery) and possibly, in the future, they would be marked REQUIRED all at once with a major protocol change. I believe the incompatible changes for higher versions would be rare. Pavel On Tue, 9 Sep 2008 18:04:32 +0200 Jehan <[EMAIL PROTECTED]> wrote: > > Hello, > > this is interesting, but does it bring something else than just > psychology (not to make people afraid... which is already a good > point, for sure)? > > I am not sure this is really necessary to force the maturity of a > protocol if we have no way to really check it (which means: no real > implementation). > > But there is a very interesting point also: currently a feature never > gives its version (as far as I can remember). You only have a version > for core XMPP (in the opening stream tag), but not for the additionnal > features inside the stream. > > And I finish by a question for my personal knowledge, because I guess > this has been discussed somewhere: why are the protocol namespaces ( > http://www.xmpp.org/registrar/namespaces.html ) in different forms, > and especially the one in the form of an http url (for instance: > "http://jabber.org/protocol/activity"; )? Is it just historic for older > XEP? Or another reason? > > Jehan > > -- 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
