[Top] [All Lists]

Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt

2005-03-30 10:23:54

 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 

 2119 should probably be specified as a normative reference with
 appropriate use of MUST, SHOULD, etc. to clarify requirements,


 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 

 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.

  Dave Crocker
  Brandenburg InternetWorking
  dcrocker  a t ...

<Prev in Thread] Current Thread [Next in Thread>