Document: draft-crocker-email-arch-11.txt
Reviewer: Vijay K. Gurbani
Review Date: Mar 24, 2009
IESG Telechat date: Mar 25, 2009

Summary: This draft is ready for publication as a Proposed Standard.

The draft has 0 major issues, 5 minor issues, and 10 Nits/Editorial comments.

Major issues: None.

Minor issues:
1) Throughout the draft, the text refers to RFC2822.X and RFC2821.Y constructs (e.g., RFC2822.From, etc.)
Now, these¨drafts -- rfc282{1,2} -- have been obsoleted by newer versions. So a general question is, should the draft refer to RFC5322.X¨and RFC5321. instead?  I just bring this up for consistency's sake.  If the ADs and other reviewers are okay with using¨RFC282{1,2}, then please disregard this comment.

2) In various figures (Figs. 1 and 2, for instance), certainlines are drawn using "===" while others are drawn using"...".  Is there a difference of semantics between these representations? There is no legend to guide the reader by in these figures.'

3) S3.3, towards the end of first paragraph: do you think it
is worth mentioning here that people should not derive any specific connotation on enterprise organization by counting the number of dots in the FQDN. I have seen many academic papers do this.  Essentially, the number of dots does not
matter in a DNS name.

4) Table 1: Is the MIME header set by an Author or a MUA? Most MUAs automatically set the MIME header type depending on the configuration of the MUA; in other words, most commercial MUAs are configured to utter the right MIME type when they encounter a certain filename. I have not seen email authors physically set a MIME type unless they are attaching a file for which no predefined MIME type exists. Same comment for RcptTo and ORCPT: Do Authors set this or does the MTA or MDA? 

5) S4.3.2, page 31: "The primary routing mechanism for Internet Mail is the DNS MX record..." My comment is: is the DNS MX record a service lookup mechanism or a routing mechanism?  I believe it is the former (i.e., a service lookup mechanism) and not the latter.

Nits/editorial comments:
1) In S2.2.1, there is the token "<<initial def>>" in the last
paragraph of the section.  It seems superfluous at best, or a place holder of some sort. 

2) S 2.1.3, last sentence:  s/2.2.3. ./2.2.3.

3) S2.2, second half of the second paragraph appears to somehow
magically become centered, leading to jagged endings on both the
left and right margins. 

4) S2.2.2, second paragraph, first line: no need to expand MHS, it has
been expanded elsewhere before this paragraph.

5) S3.1, second paragraph: s/address <addr-spec>/address, <addr-spec> 

6) S3.1, first paragraph, the last two sentences: "Formal Internet ... [RFC2821].".   My question is, if source routing has been deprecated, why mention it at all? 

7) S3.1, third paragraph: s/functions. [RFC2141]/functions [RFC2142].

8) S3.1, page 17, first paragraph on 
that page: this paragraph does not read well. It contains a mish-mash of a run-on sentence and gratuitous capitalization in the first sentence. May be wise to reword it.¨

9) S3.4.1, last paragraph: s/an ID can/a Message-ID can 

10) S4.2.1, towards the end of page 28, there are a couple of occurrences of "*****".  I think these are holdovers from ¨previous edits.