I was thinking about the draft and I think we need a chapter between
section
3 and 4 about how mail looks at the host level
I do not understand how this improves the architecture discussion. What
problems does it solve?
One reason was to introduce the "novice mail concepts" of mailclient and
mailserver in the mailarchitecture.
So that novices (like me) can grasp what is ment by an MUA, MTA ect.
futher on some agents are "bound together" on one host, so you "need" an
host / mailserver concept.
The discussion is already considerably more complex than most folk --
including
me -- would like. It needs to be as simple as possible, while still
covering
essential characteristics of the service.
I agree it gets considerably more complex than I guessed it would be, but
simplifying something complex as mailarchitecture doesn't help.
.
My hope is that the draft will evolve more to an encyclopedia of the
different viewpoints on mail architecture, and that then interlinks those
viewpoints, than that it just descibes one or two limited viewpoints.
And this is really to get the ALL essential characteristics of the service,
otherwise we will all miss some essential characteristics and that will
devaluate this draft to scratch.
I hope that we can agree with me on this.
(that is why I agree that there is a chapter about adminitrative actors ,
although I do not (yet) see wich essential characteristic it offers)
BTW
I am now thinking that the chapter that I roughly drafted is more an
introduction to chapter 4 (services / mail agents ) then a chapter on its
own.
BTW2
I also that just before this there should be a chapter on maildomains, (and
here it is really about (MX) domains not about administrative actors)
I think that Keith Moore's MON's , an MRN's should go in that chapter.
It needs to be as simple as possible, while still covering
essential characteristics of the service
Also some agents have a