Folks,
There's a lot of traffic to wade through on this list. Much of it seems
to be unnecessary, or at least premature.
At this point we should be trying to get a common definition of the
problem and identify a set of goals (not necessarily common goals). At
this stage, discussion about specifics of an eventual protocol or
implementation only gets in the way.
For instance, discussion of character encoding schemes (UTF-8 or
otherwise), specification languages like ASN.1, presentation layers like
XML or *ER or 822-style headers or the formats of dates, seems
counterproductive. Those topics should wait until after there's a
common sense of problem definition and scope.
Similarly, discussion of specific techniques for authentication,
spam-prevention, message transfer, providing anonymity, etc. seem
premature. They tempt us to drill down into details that may actually be
irrelevant in the long run, if broader considerations cause us to choose
a very different design than is anticipated.
Sometimes arguments in favor of, or against, a particular technology or
implementation technique are motiviated by broader goals. In those
cases I encourage people to try stating the broader goals. One person
was arguing for including typed data in the presentation layer, so as to
facilitate better gatewaying with netnews. At this stage it makes more
sense to state a goal like "should be easy to gateway with netnews" than
to argue about data representations.
If we narrow our current focus to questions about problem definition and
scope, we'll be able to move much more quickly to discussion about design.
Keith
--
He not busy being born, is busy dying. - Bob Dylan