on protocol names, and so on.

[Dave Kormann <davek@research.att.com>]

this is mostly a long way of saying 'i agree with erik', but:
i think it's a mistake to think that protocol naming is exactly
matched by method dispatch for the handlers.  messages are messages,
methods are methods.  more specifically: i'd rather not get in the
business of being overly specific about what happens below the
protocol name in a protocol's namespace.  the more we restrict the
structure of that namespace, the more work we create for both protocol
designers and the naming authority.  granted, it's awfully pretty to
have method dispatch mirrored by a hierarchy in the message names, but
(as i've been beaten over the head with recently) the elegance of a
particular implementation isn't necessarily the best argument for
making a design decision.  while i think the definition of what is,
and what's in, a protocol needs really serious help, i mostly believe
that we shouldn't be any more restrictive than we currently are about
what protocol messages look like.

as for 'what does it mean to say i support protocol foo?': i've been
thinking of this as a contract: you agree to abide by the published
design for protocol foo.  that's all.  i firmly don't believe that
saying 'i support protocol foo v10.3' means you support the 'foo-bar'
and 'foo-baz' messages unless those messages are specifically listed
in the protocol specification for foo 10.3.

there's an argument here  that this leaves a big gaping hole if people
have different ideas of what foo 10.3 is.  that's the job of a
protocol registry; we'll want one of those, possibly run by the same
people and with the same procedures as the naming authority.

i'm just mostly rambling here, sorry, but i'm trying to figure out how
to express (and then translate into the spec) what's meant by
protocols.
				dk