Re: Email System Model

In my view, you have an over simplification and Crocker's doc is 
attempt to model a more complex integrated world. Its one view abeit 
one that attempts to prescribe a model based on STDs and RFCs.  I 
think it could of been done in a more readable fashion, like a 
Requirements/Optional Grid to start work ala RFC 1153
I do think, in my opinion, your first illustration is pretty 
fundamental and much easier to understand, grasp without reading the 
context.  IMO, Dave's doc is too overwhelming for MOST people to read 
- totally only useful for highly IETF trained geeks.
--
Sincerely

Hector Santos
http://www.santronics.com


David MacQuigg wrote:
> I'm splitting this off as a separate topic, so we don't distract from 
> the discussion on email-arch.  In this thread, I welcome discussion of 
> the validity of the model at http://en.citizendium.org/wiki/Email_system.
> This model is focused on what happens at the administrative level in one 
> transit through the Mail Handling System, but it can easily extend to 
> systems involving multiple transits.   To model the situation Austin 
> describes, I would put two "one-transit" models in series.
> Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Mediator
>
> Mediator ==> MSA/Transmitter --> / --> Receiver/MDA ==> Author
>
> The Mediator is a separate user-level Actor, even if it is automated.  
> The final Recipient is the original Author.
> I'm not sure if I fully understand Austin's concern, so I don't know if 
> more elaboration of the model will help.  A model is only as good as its 
> ability to clarify real-world systems, helping with questions like "What 
> happens if ...", or "How should I ...".
> Best Regards,
> David MacQuigg
>
>
> Cheney, Austin wrote:
> > 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
> >