Indeed, although "must" appears
many times in the draft, it is unclear whether the draft (when published
as an RFC) would be Informational or Standards Track; if the latter, RFC
I intend to seek Proposed Standard status. I did a review of other RFCs that
cover architecture and it is quite common for them to be on standards track.
Hence, yes, we (I) need to be very careful about the document's use of the
magic normative vocabulary. Thanks for bringing this up.
I've just gone through the draft and checked all occurrences of the magic
words. Most seem ok, to me, though I capitalized them to emphasize their
normative nature. A few others have been changed to use non-magic wording,
especially when the normative specification for the item being discussed is
actually contained in an existing standards specification.
(An example is whether a Received header must/should/may be recorded; this is
specificed in RFC2821 and I would rather not have the email-arch draft
replicate such statements, since it invites loss of synchrony among the
documents.)
2119 should probably be specified as a normative reference with
appropriate use of MUST, SHOULD, etc. to clarify requirements,
ack.
SpamAssassin is not an RFC. It is therefore not part of the standard
Internet mail architecture per se.
Even better: It also is an implementation, rather than an archtecture. The
email-arch draft reminds folks to be careful about that distinction.
Can it
implement SPF for example?
SPF is not an RFC. It is therefore not part of the standard Internet mail
architecture per se. It is fatally flawed w.r.t. that architecture, as
previously discussed here.
If it WERE documented (and standardized), should it be in the email-arch
document? My feeling is no, in that there are many things left out of the
document and these sorts of evaluation mechanisms are, so far, a long way from
being core to the service. Reference to filtering is the one concession to
the emerging area of standardized, remote specification of specialized
handling. (along with the conneg stuff.)
The document tries to describe the core, modern Internet Mail service. At
that, it describes a remarkably complicated service. It would be better to
find ways to simplify it, to improve its use as a framework for technical
discussion. (That is what I view an architecture document as seeking to
accomplish, more than anything.)
So my own view is that the goal is to leave OUT as much detail as we can
tolerate.
Both DSN and MDN are based on the RFC 3462 (nee 1892) MIME
multipart/report media type. MIME itself is not a necessary part of the
Internet mail architecture or Internet Message Format; as noted in the
MIME RFCs, MIME is "largely orthogonal to" the Internet Message Format.
Here is where the subjective assessment comes in, in terms of what to include
and what to exclude from the architecture document: Yes, individual messages
and, perhaps, even individual implementations, can operate without supporting
MIME, even today. However the global service certainly relies on its
presence. So I believe that MIME is not orthogonal or optional in an Internet
Mail architecture discussion.
One might quibble about some aspects of its inclusion in draft figure 5
(the gap in one of the lines, the fact that Sieve can be implemented
entirely in the rMUA or entirely in the MDA, etc.), but it is a widely
used Standards Track part of the architecture and should not be removed
from the draft.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net