[confession on]
Keith, I personally apologize if I contributed to any unnecessary
divergence. No doubt, I prepare to keep the thought process as general as
possible. But I guess, like many, we seem to wish to prove or have a need
to explain the "why" in any consideration. We have thousands of man-hours
here and I'm sure the training is vast from managers to technical designers.
So that needs to be considered when a group like this is put together.
My point is that sometimes it helps to "think ahead" of what is the
available technology and more importantly, the emerging technologies. Not
sure if that was done back in early SMTP days, it did a hell of a great job
to say the least, but one thing for sure the "philosophical mindset" for the
possibilities, although considered, was as Dorothy Parker might say "Thrown
into waste basket with full force."
It is my hope this does not happen this time around. I agree that the
details of "XML" for example, is not necessary, but it needs to be
considered as you suggested within the context of a generalized statement:
o Easy support for emerging B2B business Standards [grayed out comment:
XML/SOAP]
Of course, the devil is in the details, but when coupled the concept with
other considerations such as:
o Easy support for client/server authentication
One or the other may or may not be necessary and that can help the
refinement of the requirements "document" by having some level of initial
(hopefully not so deep) detailed discussions. I say that because I provided
my input on the onset of this mailing list following your lead, and I was
flabbergasted when someone else take the input from what seem to be "his
known friends" and completely ignored my own input. He put it on a odd ball
"Wiki" web site when I myself was slapped across the head for suggesting a
similar web site input/consolidation idea.
I have no problem with a selective group of people performing the final
requirements. But I do wish to get my input in there and if I am going to
generalized it, I would like to know why it was not considered.
Thanks for your time
[confession off]
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: <mail-ng(_at_)imc(_dot_)org>
Cc: <moore(_at_)cs(_dot_)utk(_dot_)edu>
Sent: Tuesday, February 03, 2004 2:07 PM
Subject: suggestions for reducing message volume
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