Re: email-arch intro
On 5/14/09 Pete Resnick wrote:
My first reaction to Pete's intro was - Yea, that's great, says it all.
Now I'm not sure what it means. Upon careful reading, it looks like it
is intending to protect protocols and implementations (but not anything
else) from anyone wanting to wield this document as a "club". Why not
just say "This document is intended to describe a complex real-world
system, and provide a model and terminology that will improve our
understanding of that system. It is not intended to add additional
requirements to regular IETF standards, or enforce conformity in any
way." If the model is useful, as I believe it is, it will be widely
used. If not, it won't become an impediment to development of other models.
On 5/14/09 at 6:36 AM -0700, SM wrote:
One of the "problems" with the email-arch is that the document does
not constrain itself to the higher level only. It would have made
matters easier if the document was descriptive instead of prescriptive.
I disagree, and that is one of the reasons for this intro: We want the
architecture to be prescriptive insofar as *any* IETF document is
prescriptive in that it helps interoperability.
Perhaps an example will help. I have been developing an
"administrative-level" model for email systems, which I view as an
extension of Dave's Figure 4. See
http://en.citizendium.org/wiki/Email_system for a more complete
description. I have tried to conform with Dave's terminology, but found
it inadequate to fully describe what is happening at the administrative
level. This doesn't mean Dave's model is wrong, just that it is more
focused on the Relay-level, and provides only a very general description
of the "ADMD level". For a textbook presentation, we need something
more than Figure 4, but less than what is in Dave's draft.
What I worry about is a document like this becoming a basis for
obstructive arguments over terminology. I would like to say in some
future discussion - "Let's use the terminology from RFC-<whatever number
it gets assigned>, but with the following differences:" Then add a few
definitions appropriate to the topic at hand.
Maybe my worries are un-necessary. Let's find out now, rather than
later. Is there anyone here who thinks the differences between my model
and Dave's are a problem? Can you suggest improvements in either model?
David MacQuigg, PhD
ECE Department, University of Arizona