Dave CROCKER wrote:
This has been discussed and debated a bit, over the last 5 years.
On reviewing the list of RFCs that have the word "architecture" in their
title and appear to be detailed description rather than either summaries or
abstractions, I see that some are informational and some are standards
track. None is BCP.
I always felt pretty strongly that it is important for this document to be
standards track, for several reasons.
The motivation for this work was my perception that the community of people
involved with email technology had/has become quite large and diverse,
but that the community did/does not share a sufficiently common and
> thorough sense of the (same) architecture. This gets in the way
> of all sorts of discussions, from technical protocol design up
> (or down?) through operations or even legal policy.
Thats all good and dandy, but that also has a tendency to lock in
methods that upon themselves are standard protocols but not
necessarily used by all nor required for an email system. To name but
The last thing I would like to see is people throwing this document in
someone's face because they might not be using DSN or SIEVE or some
other suggested method in this document.