John,
JCK> While I tend to agree with Ned that looking at the history is
JCK> not particularly useful
Let's defer history to a beer BOF. We do not need to pursue that for
the goal of the doc.
I originally thought that historical context would help resolve
questions about the current state of things; instead it is proving to be
distraction.
JCK> I note that we don't make any attempt to distinguish
JCK> among single-component MTAs (of the emacs rmail command, or the
JCK> bin/mail variety, or up the complexity scale from it) depending
JCK> on whether they facilitate leaving messages in the mail store
JCK> after reading or require either deleting them or moving them
JCK> somewhere
Unfortunately I could not fully parse the above and couldn't understand
the portion that did parse. It appears that you are saying something
about an MTA possibly retaining a message after the message has been read. This
makes no sense to me. Please clarify.
By way of anticipation, I'll note that someone suggested that the way to
talk about this stuff is strictly in terms of transfer of
responsibility. (A quick search of my email didn't find who suggested
it.) I now think it is _exactly_ the right thing to consider, in terms
of the overall service, including the distinction between a message
transfer queue versus a message store.
JCK> Using similar logic, I think I'd join others in discouraging
JCK> hair-splitting about what is and is not a legitimate mail store.
Here, I think, we have a more serious, present-tense disagreement.
What motivated the architecture draft was my sense that we do not have
anything close to a clear, precise, shared understanding of email
global service design. That cripples efforts to discuss enhancements.
We have lots of people with wonderfully detailed knowledge about
particular implementations, but no sense of what is localized design in
the implementation and what is system-wide architecture.
Interoperability among independent implementations requires clarity
about such issues. And the Message Store is now a full-fledged member of
the email architecture family, as is the MDA, supposedly. So I think we
have an obligation to define it precisely and clearly.
Whether the definition that achieves consensus is mine, yours, or
someone else's is entirely secondary to me. (Alas, that doesn't mean I
won't also lobby for mine vigorously...)
JCK> The reality is that we have fairly few firm boundaries in this
JCK> business
Correct, and thanks for such a concise problem statement.
We suffer a kind of Through the Looking Glass world when talking about
email service enhancements, unless they are so low-level as to be too
mundane to worry about. As soon as we want to do anything interesting
with this global service, we are very nearly unable to achieve any
meaningful communication.
So, sorry, but I think that our obligation is specify some clear, firm
sets of functions and boundaries that are shared by the community.
JJCK> the
JCK> sort of model you are trying to develop is probably best seen as
JCK> descriptive, rather than normative. If you try to make it
JCK> normative, I think there are big problems ahead.
I have not, and will not, be worrying about the document label for this,
anytime soon.
I am concerned that the community have a consensus based conceptual tool
for aiding standards-oriented design efforts. I am particularly
concerned that new folk coming into this community have nothing but
widely disparate code to consult.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>