version ranges

[Erik Ostrom <eostrom@research.att.com>]

vijay expressed a concern about the semantics of version ranges.  i
agree that it's a problem and that it's too late to fix it (for 2.1).
however, i think the situation is not too dire.

>Endpoint A initiates contact with EndPoint B and
>says it supports protocol foo in the ranges 1.0 through
>2.0. EndPoint B says it supports protocol foo in the ranges 1.5
>through 2.5. The guy who wrote B was unaware that actually
>there is such a thing as an implemented 2.0.

we've stated that most packages are supposed to begin with a
reverse-dns prefix, e.g., dns-com-att-research-magic.  given this, it
seems like most communication problems that could lead to version
mismatch would have to happen within a single organization.

admittedly, such a thing is possible.  but at least we can hope it
won't be epidemic.

the core protocols (and the version numbers in the #$#mcp message)
don't have the dns hierarchy working in their favor.  we know from
experience that it's quite possible for multiple endpoints to have
different knowledge of #$#mcp version numbers.  there's some hope that
we won't go through this again:  increased publicity for the spec,
lessons learned the first time through, and a more general protocol
(so it's less _necessary_ to mess with the core protocols to
accomplish something new) may help.

that leaves the non-core, non-dns protocols and our vague intent to
create a naming authority.  if we create a naming authority, i guess
we can try to make it keep a grip on protocol versions with that.

i think the version number problem, although significant, is less
risky in practice than the likelihood that we will not form any naming
authority (or we will, but it will take two and a half years, or we
will, but many people won't hear about it) and people will begin
populating the non-dns namespace anyway, leading to inevitable
conflicts.

--erik