Subject: [Gen-art] Gen-ART review for draft-crocker-email-arch-11

From: Vijay Gurbani <[email-masked]>
Date: Wed, 25 Mar 2009 00:01:32 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

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.Y 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), certain
lines 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.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 26 Mar 2009 09:43:38 -0700

(Document Shepherd Tony Hansen added.)

Vijay,

Many thanks for the detailed review.

Responses to the questions and substantive points:

Vijay Gurbani wrote:
> 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.

I've added:

      "There is no formal limit to the number of names in the sequence -- that
is, to the depth of the hierarchy -- nor any standard semantics to the depth."

Is that sufficient?

(The goal of the section is to offer the briefest summary possible, while still 
being useful for the email-arch discussion.)

> 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.

The table is for places that list /identifiers/, rather than /labels/. MIME does
not have any identifiers.

However you are not the first to ask about listing MIME in the table, which 
means that it might help to add text that clarifies or emphasizes this point, 
but I'm not exactly sure what to suggest.

(For reference, since MIME is content, it's the author's MUA that creates it.)

> Same comment for RcptTo and ORCPT: Do Authors set this or does the MTA or
> MDA?

Your query prompted me to chat with a few email folks.  One point that might
make the table a bit clearer is that "Set by" is meant to refer to who
determines the value, rather than who creates the field.  For Rcpt-To, the
author specifies the list of recipients, but it's the Originator who fills out
the form, since it performs the direct protocol actions.  The purpose of the 
table is really about authority over a value, so it needs to reflect who makes 
the information decision, rather than who performs some mechanics.

The author sets the RcptTo. Otherwise, none of the following modules would know
where to send the mail.

ORCPT turns out to be more interesting.  Based on the additional discussions, I
now believe the table should indicate that it is the Originator that sets the
value.  At base, its a handling audit field, which fits nicely into the
Originator's role.

Thanks for probing this.

> 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.

FWIW, this bit of text has often generated some controversy, over the couple of
decades I've used it.  It is the fact that it supports -- and was actually 
motivated by the need for -- indirect transfer, by relaying through an 
intermediary, that is the basis for my own comfort with viewing it as a routing 
protocol.  (There's probably a case even if it were only direct, but that would 
be a lot less interesting.)

And, indeed, I'm not the only one with that view:

    <http://en.wikipedia.org/wiki/MX_record>

    "An MX record or Mail exchanger record is a type of resource record in the
Domain Name System (DNS) specifying how Internet e-mail should be routed"

So I tossed the text into the draft, and waited to see who got heartburn from
it.  In fact, I believe you are the first to comment on it.

> 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?

(You should ignore the hand that is waving as I type this...)

Lots of folk don't realize it's deprecated, and it was around formally for a
long time, though not all that usefully. So the intent of including it is to
help mark the change.

> 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.

So, how's this:

   Old:
    A few types of addresses elaborate on basic email addressing, with a
    standardized, global schema for the <local-part>, Include are
    conventions between authoring systems and Gateways.  They are
    invisible to the public email transfer infrastructure.  When an
    Author is explicitly sending through a Gateway out of the Internet,
    coding conventions for the <local-part> allow the Author to formulate
    instructions for the Gateway.  Standardized examples of such
    conventions are the telephone numbering formats for VPIM [RFC3801],
    such as:

   New:
    Basic email addressing defines the <local-part> as being globally opaque.
    However there are some uses of email that add a standardized, global schema
    to the value, such as between an author and a Gateway.  The <local-part>
    details remain invisible to the public email transfer infrastructure, but
    provide addressing and handling instructions for further processing by the
    Gateway.  Standardized examples of such conventions are the telephone
    numbering formats for VPIM [RFC3801],such as:

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 26 Mar 2009 20:06:44 -0500

> Many thanks for the detailed review.

No problem; it was fun to read the draft on a technology used
everyday.

More inline.

> I've added:
> 
> "There is no formal limit to the number of names in the sequence -- 
> that is, to the depth of the hierarchy -- nor any standard semantics
> to the depth."
> 
> Is that sufficient?

Yes, perfect.

> The table is for places that list /identifiers/, rather than
> /labels/. MIME does not have any identifiers.
> 
> However you are not the first to ask about listing MIME in the table,
>  which means that it might help to add text that clarifies or
> emphasizes this point, but I'm not exactly sure what to suggest.
> 

How about: s/Author/aMUA?  That would solve it (at least from
my perspective.)

>> Same comment for RcptTo and ORCPT: Do Authors set this or does the
>> MTA or MDA?
> 
> Your query prompted me to chat with a few email folks.  One point
> that might make the table a bit clearer is that "Set by" is meant to
> refer to who determines the value, rather than who creates the field.
> 
Ah ... so how about putting this as a comment; i.e.

OLD:
| Layer                | Field          | Set By                    |

NEW:
| Layer                | Field          | Set By (Who determines    |
|                      |                | (the value that goes in   |
|                      |                | the field.)               |

Feel free to edit.

> The author sets the RcptTo. Otherwise, none of the following modules
>  would know where to send the mail.

Sure; this makes more sense now that I know who determines the
value that goes in the RcptTo field.

> ORCPT turns out to be more interesting.  Based on the additional 
> discussions, I now believe the table should indicate that it is the
> Originator that sets the value.  At base, its a handling audit field,
> which fits nicely into the Originator's role.
> 
> Thanks for probing this.

Sure; glad to help ;-)

>> 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.
[...]
> So I tossed the text into the draft, and waited to see who got
> heartburn from it.  In fact, I believe you are the first to comment
> on it.

Oh!  If you think that is fine, then I am okay.  I will defer to
your judgment here.

>> 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?
> 
> Lots of folk don't realize it's deprecated, and it was around
> formally for a long time, though not all that usefully. So the intent
> of including it is to help mark the change.

OK.

>> 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.
> 
> So, how's this:
> 
> Old:
[...]
> New: Basic email addressing defines the <local-part> as being
> globally opaque. However there are some uses of email that add a
> standardized, global schema to the value, such as between an author
> and a Gateway.  The <local-part> details remain invisible to the
> public email transfer infrastructure, but provide addressing and
> handling instructions for further processing by the Gateway.
> Standardized examples of such conventions are the telephone numbering
> formats for VPIM [RFC3801],such as:

Sure; works for me.  One typo in the last line -- s/],such/], such/

Thank you.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/