David MacQuigg,
One difference that I see is an inferred conceptual implementation that
is explicitly not presumed in your model, while being completely
unmentioned or challenged in David Crocker's models. This inferred
conceptual implementation is that a mail server is a mediator in the
communication process between author and intended recipient, but a mail
server can become an participant if were acting as an application
response.
Let me demonstrate this in the model of software as a service. Suppose
I were communicating with a known destination, such as a retailer, who
receives and replies to mail as an automated application system. At the
same time another content application system is installed on the local
mail server of this intended recipient that is capable of intercepting
communications, making decisions upon those communication, and sending
automated responses that beg further communication from the initial
author. In this model application programming and scripting can be
running in response to human supplied communications from the
originating author, while those same applications can also be relaying
data relevant only to the distant end to the intended recipient for
status responses and session content details.
In that model the mail server of the distant end transforms from a
mediator to an intermediate responding agent. Such a model could allow
things such as cloud computing or ecommerce. It is not practiced by
anybody, because a definable characteristic that is uniformly described
and universally understood would have to exist in the content to provide
such a hook for application engagement.
So, in summary, a mail transfer agent MUST NOT be presumed to be
separate from a designated point of intended receipt. Crocker's models
do not mention or challenge this concept, but your model does imply such
a challenge.
Thanks,
Austin Cheney
-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of David MacQuigg
Sent: Thursday, May 14, 2009 5:11 PM
To: ietf-smtp(_at_)imc(_dot_)org
Cc: Pete Resnick; SM; dhc(_at_)dcrocker(_dot_)net
Subject: Re: email-arch intro
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