ietf-smtp
[Top] [All Lists]

Re: email-arch intro

2009-05-14 18:25:17

On 5/14/09 Pete Resnick wrote:
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.
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.

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?

Best Regards,

David MacQuigg, PhD
Research Associate
ECE Department, University of Arizona
http://purl.net/macquigg

<Prev in Thread] Current Thread [Next in Thread>