Which alternatives would you show in this introductory basic diagram?
Should we include the protocols (POP, IMAP, HTTP)?
> Can you create a diagram equivalent to Fig. 1, using only the
entities
> and terminology in RFC 5598?
No doubt one could.
If it's a diagram about email, HTTP really has nothing to do with email,
any more than TCP does.
I suspect the intent is to show the implementation choice of a split UA,
with http between the MUA front end and the MUA backend.
But these kinds of references tend to fail by leaving out the
email-specific layer that runs on top of HTTP. Really, in this use,
HTTP is nothing but a transport-level function.
I can't. The problem is that every block is just an ADMD, with no
distinction between one and another, no clues to support a discussion of
their different roles and responsibilities, etc.
You say you want simplicity but then complain that something is too simple.
Imagine you are trying to teach the fundamentals of email systems to
university students in a class on computer networks. Most are not going
to become email system admins. Most will be overwhelmed by the level of
detail in Fig. 5 of RFC 5598. You have one lecture to give these
students a basic understanding of how email systems work. How would you
do it?
I was, indeed, impressed by the level of detail that was required to
create RFC 5598.
I started the effort knowing it would be require some work, but did not
anticipate that it would take 5 years and many, many rounds of community
consultation and community invention. (The transfer of responsibility
/inside/ the MSA and MDA was a true revelation to me.)
I also pressed to include only what really was essential to describe the
/existing/ email service on the Internet. It kept pissing me off that
people would raise a concern with the then-current version of the draft
that was a) not adequately covered by it, and b) could not reasonably be
deferred.
This was a far cry from the original, simple MUA/MTA distinction we
created in 1980.
If your requirement is simplicity, note that each of the Figures 1-4 is
relatively simple. (The fact that they use ASCII Art makes this a bit
less obvious.)
The reason for doing multiple figures is to isolate complexity.
While yes, it is good to start class instruction with simplistic models,
if the classic is to be practical, it needs to get serious students to
appreciate real-world complexities.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp