On Wed Oct 8 05:24:51 2008, Jack Moffitt wrote:
I'd like to see a clearer statement of the problem to solve rather
than so much debate over nuances of a proposed solution. It seems
there is some hesitancy over implementing a protocol containing
:tmp:
in the name. There is also of course the problem if distinguishing
between versions of a particular protocol when it has gone through
some major revisions.
That's essentially the statement you're looking for.
Some protocols look fine for deployment when they're still in this
:tmp: namespace. Others, we find in rare cases, need radical,
non-interoperable change between revisions - it turns out, basically,
that we broke something. Hopefully, this is rare, and hopefully
there's another solution to, in effect, throwing away the protocol
and replacing it with something else.
There is another solution to the reluctance to implement which also
takes some of the ambiguity out of the time line here. That is to
issue the canonical urn as soon as a XEP draft is accepted by the
council. Why wait until it has reached some nebulous maturity
level?
If we accept a XEP, immediately issue it a urn. This is early
enough
in the life cycle that it should not affect implementers, and urns
are
infinite in number. We need not worry about wasting them
First off, I took it that the community felt there was value in
having some form of signal that "This protocol is still under radical
discussion and has not stabilized sufficient to bother coding." This
is a useful signal for people not following every message in the
process. It's just unfortunate that we signal this to people
implementing experimental state protocols, because this can be a very
good time to, well, experiment. And if the experiment works, these
bleeding edge people should be benefiting by being ahead of the game,
not stuck with a non-interoperable protocol that's only
non-interoperable by a side-effect of a bureaucratic housekeeping
process performed by fiat.
Secondly, I'm not worried about "wasting urns" either. My proposal of
using a version number wasn't based on the notion of namespace
collisions or exhaustion, but on the exhaustion of Good Names. I've
seen protocols start off with fine, reasonably catchy names, and then
go through radical refactoring, forcing a name change, and end up
with awkward names.
This last might sound like frivolity, but names are important. We
humans like to name things, and the names mean more than just a
string of letters, irregardless of what any specification tells us
they should mean. Hence the enormous thread on resource naming - and
hence my actually quite serious post comparing resource naming with
usernames, which, from a technical standpoint, would be fine, and has
privacy improvements too. But names have an impact far beyond the
technical. A rose by any other name might well smell as sweet, but
would people still bother smelling it?
So in order to conserve not namespaces, but creativity, I suggested
keeping the name, and attaching something else to it in order to
distinguish the rare, and unfortunate, but sometimes required,
protocol refactorings. I'm not wed to version numbering for this, but
they have advantages in as much as I don't think that people are
likely to consider urn:xmpp:foo:4 as being better or worse than
urn:xmpp:bar:2 - or at least, not in quite the same way as they might
consider urn:xmpp:foo:2008 vs urn:xmpp:bar:2010. But I'm not sure
there is a terribly good solution here.
Technical argument stops here after my first paragraph, incidentally.
The remainder is soft-science, not hard, there are no proofs that
version numbering is better than years, or vice-versa. Technically,
we could assign random names to each protocol (considering each time
a protocol is revised so heavily that it ceases to interoperate as
replacement with a new protocol), but that's not going to sit well
with developers either.
Now, I happen not to be a big fan of years-as-versions. To us - I
hope - an old protocol is a good one, assuming it's seen deployment.
It's a success. But to the market, it's old technology, and the
cutting edge is where it's at. It's why people get excited over
Blackberries - "Latest technology mobile email! Optimized for low
bandwidth!" instead of IMAP "Two decades of deployment! Designed over
2400 baud!".
So, if you don't like version numbers - and I'll admit I just grabbed
at the first thing I could think of:
1) Protocols start off as :tmp:, and in this state, standards
developers can feel free to make incompatible changes.
2) If someone wants to implement them to the point they need a stable
namespace, they can simply ask, and the :tmp: shall be removed. In
other words, only one implementor need do so. Should we last-call
this? Give a week's warning? I don't know, but I suspect that someone
saying "Hey, I'm doing this one, I want to deploy it in the field,
let's drop the :tmp:" would be real encouragement for other folk to
take a serious look at the protocol, so I'm thinking some kind of
Last Call.
3) If - and bear in mind this is unlikely - the protocol is found to
be so broken that it is the only solution, then either a new
namespace is forged - urn:xmpp:foo is the new urn:xmpp:bar - or else
we append good old Latin musical suffixes - "bis", "ter". If things
are so broken we run out of those, we're forced into devising a new
name.
Latin musical suffixes are a bit obscure, of course. The IETF use
them for indicating major revisions to specifications. The advantage
is they have little baggage; "bis" to a musician merely means
"Twice", or "Again", and doesn't mean "Screwed up the first one,
probably screwed up this one too", or "Shiny and new".
Finally, I would remind people that merely having the facility to
devise multiple incompatible protocols with the same name does not,
as Jack hints, imply that this is a good thing to be using. We did
well with XEP-0115 to maintain interoperability with older versions,
and that's the kind of pattern we need to be following here, not to
discard and replace. I hope that's stating the obvious. :-)
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
