I am completely aware that if a model is too complicated for
understandability of the intended consuming audience it will be
completely ignored. There are several standards, both on and off the
internet, where this has commonly occurred. Perhaps the most well known
case is W3C's WAI2 standard, which produced much excessive whining
because of the complexity of practice required to achieve that standard.
Much of this whining was unfounded and did nothing, in this one case,
but extend the development process of the document. The current ECMA
Script standard, however, is so complex that nobody seem to be capable
of adequately translating it to something that people new to the
language are capable of understanding. This results in many books on
the subject that are wrong or miss necessary fundamentals. As a result
people commonly ignore the recommended methods of writing the language
and do whatever the hell they want so long as it does not break
immediately in a single limited context, which will result in a break.
A standard must not, however, strive to limit the subject of its
description merely for the point of simplicity. When limitation occurs
from such simplification innovation of otherwise unexplored approaches
is blocked even if the stated limitations were unintentional. In my
opinion blocking innovation is supremely more harmful than a standard
which is ignored because that harm is immediately evident and not
commonly known opposed to harm from an ignored standard which is not
immediately evident but is well known and understood.
As a result I would rather the models be too complex for us mere mortals
to grasp so long as they are accurate and do not impose constraints that
not absolutely necessary. I understand this is complicated work as such
constraints may appear as common usage and not viewed as a constraining
practice.
Thanks,
Austin Cheney
-----Original Message-----
From: Hector Santos [mailto:hsantos(_at_)santronics(_dot_)com]
Sent: Sunday, May 17, 2009 9:27 AM
To: David MacQuigg
Cc: ietf-smtp(_at_)imc(_dot_)org; Cheney, Austin
Subject: 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