[Top] [All Lists]

RE: email-arch intro

2009-05-14 19:36:25

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

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.

Austin Cheney

-----Original Message-----
From: 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
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

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 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

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