Subject: Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

From: SM <[email-masked]>
Date: Fri, 15 May 2009 01:29:27 -0700

At 05:27 13-04-2009, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'Internet Mail Architecture '
>    <draft-crocker-email-arch-12.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the

In the Introduction section:

   "The underlying technical standards for Internet Mail comprise a rich
    array of functional capabilities.  The specifications form the core:

       *  Simple Mail Transfer Protocol (SMTP) [RFC0821], [RFC2821],
          [RFC5321] moves a message through the Internet.

       *  Internet Mail Format (IMF) [RFC0733], [RFC0822], [RFC2822],
          [RFC5321] defines a message object."

RFC 733 was obsoleted by RFC 822.

Section 2.2.1 of the draft defines the Originator as:

  "The Originator ensures that a message is valid for posting and then
   submits it to a Relay."

In Section 2.2.3:

   "The basic test of Gateway design is whether an Author on one side of
    a Gateway can send a useful message to a Recipient on the other side,
    without requiring changes to any components in the Author's or
    Recipient's mail services other than adding the Gateway."

As it is the Originator doing the submission, "Author" should be 
replaced by "Originator" in the above paragraph.

In Section 3.4 of RFC 5322, it is mentioned that:

   "A mailbox receives mail.  It is a conceptual entity that does not
    necessarily pertain to file storage."

Section 3.1 of the draft has:

   "A mailbox sends and receives mail.  It is a conceptual entity
    which does not necessarily pertain to file storage."  [RFC5322]

In Section 3.3 of the draft:

   "The name is structured as a hierarchical sequence of names, separated by
    dots (.), with the top of the hierarchy being on the right end of the
    sequence.  There can be many names in the sequence -- that is, the
    depth of the hierarchy can be substantial."

Section 3.1 of RFC 1035 uses "sequence of labels" instead of 
"sequence of names".

Section 4.4 of the draft mentions that the the MIME Header is set by 
the Author.  It should be the Originator as that is done when the 
message is submitted.

        "RFC5321.ORCPT:   Set by - Author.

          This is an optional parameter to the RCPT command, indicating
          the original address to which the current RCPT TO address
          corresponds, after a mapping was performed during transit.  An
          ORCPT is the only reliable way to correlate a DSN from a multi-
          recipient message transfer with the intended recipient."

Table 1 lists ORCPT as being set by the Originator.

As the "RcptTo" is at the SMTP layer, it might be more appropriate to 
have it "Set By" the Originator instead of the Author.

        "RFC5321.Return-Path:   Set by - Originator

          The MDA records the RFC5321.MailFrom address into the
          RFC5322.Return-Path field."

The RFC5321.Return-Path looks like a typo.  It should be 
RFC5322.Return-Path and it is "Set by" the MDA according to the Table 1.

RFC 2298 is obsoleted by RFC 3798.  There is a typo (RFC 2304) in the 
reference for RFC3192.  If the author of the draft wants to reference 
RFC 2821 and RFC 2822, he could make it an Informative reference 
instead of a Normative reference.  The author of MAIL-I18N mentioned 
that the document should not be referenced in a modern architecture document.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 May 2009 08:33:23 -0700

(just in time for shipping the final version for IESG consideration after Last 
Call...)

> RFC 733 was obsoleted by RFC 822.

The text is not normative and is providing the historical chain of development 
for transfer and content specifications.

> replaced by "Originator" in the above paragraph.

The words for Originator are "posting" and "submits".  "Send" is a different 
word.  It is commonly used in a variety of ways, some rather vague.  As shown in 
Figure 2, there really is a logical connection between Author and Recipient. 
Referring to the use of that connection as sending to a Recipient.

One of the key points behind a layered architecture like this is that these 
higher-level, logical, end-to-end relationships are primary.  Author and 
Recipient perceive themselves as sending to each other.  They mostly don't 
perceive all the underlying mechanism.

>    which does not necessarily pertain to file storage."  [RFC5322]

fixed. thanks.

> Section 3.1 of RFC 1035 uses "sequence of labels" instead of "sequence 
> of names".

Hmmmm.  Ok. Since the cited specifications do say 'label', I've switched the 
text to say that, although I personally view 'names' as more helpful to the reader.

> Section 4.4 of the draft mentions that the the MIME Header is set by the 
> Author.  It should be the Originator as that is done when the message is 
> submitted.

Section 4.1.4, Table 1?

The Author, not the Originator, defines the body.  MIME structuring and labeling 
is defining the body.  It is very much *not* the job of the Originator, which 
has more clerical duties.

> Table 1 lists ORCPT as being set by the Originator.

fixed.

> have it "Set By" the Originator instead of the Author.

The Legend for Table 1 notes:

      "Set By - The actor role responsible for specifying the identifier value 
(and this can be different from the actor that performs the fill-in function for 
the protocol construct)"

Again referring to the logical view, Authors send to Recipients.  Authors 
specify Recipients.  The underlying mechanism that populates the RcptTo SMTP 
command is following a choice made by the Author.

> RFC5322.Return-Path and it is "Set by" the MDA according to the Table 1.

RFC 5321, Section 4.4:

    "When the delivery SMTP server makes the "final delivery" of a
    message, it inserts a return-path line at the beginning of the mail
    data."

RFC 5322, Section 3.6.7 -Trace Fields:

    "A full discussion of the Internet mail use of trace fields is
    contained in [RFC5321]"

As usual, it is indeed confusing to have redundant definitions in two different 
specifications.  Happily, here, one makes clear the other is the controlling 
spec for this item.

So email-arch does have an error, here, but it's the opposite of what you note. 
  Now fixed.

> RFC 2298 is obsoleted by RFC 3798. 

fixed.

> There is a typo (RFC 2304) in the 
> reference for RFC3192. 

ewwwww.  good catch. fixed.

>  If the author of the draft wants to reference 
> RFC 2821 and RFC 2822, he could make it an Informative reference instead 
> of a Normative reference. 

It needs to be normative.

  The author of MAIL-I18N mentioned that the
> document should not be referenced in a modern architecture document.

Late-stage development of Section 6.3, Internationalization went through some 
iterations.  Reference to MAIL-I18N has now been removed.

Thanks for the diligent detail.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 May 2009 20:07:52 -0400

Hi.

This is a tiny nit, but, since -13 has not yet been posted...

A few of the references list organizations and not authors as
authors and should probably be fixed.    [RFC5335] sort of leapt
out at me.  A quick scan also turned up [RFC1652], but I have
not done a comprehensive check for others.

    john

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 May 2009 19:10:46 -0700

> This is a tiny nit, but, since -13 has not yet been posted...

Thanks.

Since the latest draft has been modified to respond to your recent observations 
about internationalization and the role of an architecture document I'm glad to 
see that your concerns are reduced to these few typos.

d/
-- 

   Dave Crocker

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 16 May 2009 09:06:05 +0100

>not done a comprehensive check for others.
John,
I think RFC Editor can handle these.

---

From: SM <[email-masked]>
Date: Sat, 16 May 2009 08:28:50 -0700

Hi Dave,
At 08:33 15-05-2009, Dave CROCKER wrote:
>The text is not normative and is providing the historical chain of 
>development for transfer and content specifications.

If you want to provide the historical chain of development, you'll 
have to start with RFC 1341 for MIME.  Mail routing is covered in RFC 
974.  There's also RFC 1123 which updates or annotates portions of 
RFC 821 to conform to current usage (at that time).  RFC 1123 
discouraged all source routing and tried to abolish explicit source 
routing for mail delivery.

>The words for Originator are "posting" and "submits".  "Send" is a 
>different word.  It is commonly used in a variety of ways, some 
>rather vague.  As shown in Figure 2, there really is a logical 
>connection between Author and Recipient. Referring to the use of 
>that connection as sending to a Recipient.
>
>One of the key points behind a layered architecture like this is 
>that these higher-level, logical, end-to-end relationships are 
>primary.  Author and Recipient perceive themselves as sending to 
>each other.  They mostly don't perceive all the underlying mechanism.

The paragraph is about the basic test of Gateway design.  At the 
higher level, they may be a perception that the author is "sending" a 
message to the recipient.  But we are not operating at that level as 
the section is about gateways.  The end points are the sender (in 
your draft the Originator fits in there) and the recipient.  We are 
looking at the "connection" between these points where a change in 
"addressing", for example, isn't required for the message to get through.

>Hmmmm.  Ok. Since the cited specifications do say 'label', I've 
>switched the text to say that, although I personally view 'names' as 
>more helpful to the reader.

That would have been helpful for a less technically inclined audience.

>Section 4.1.4, Table 1?

Yes.

>The Author, not the Originator, defines the body.  MIME structuring 
>and labeling is defining the body.  It is very much *not* the job of 
>the Originator, which has more clerical duties.

We are talking about the "Message Body" here.  That should not be 
confused with the message content (what the recipient views and not 
the raw message.  My use of the word "content" may not be technically 
correct).  MIME structuring is not really part of the content from 
the author's perspective if the author and originator are not the 
same person.  It's up to the originator to see that the message 
conforms to Internet Mail standards (Section 2.2.1 of the draft).
>As usual, it is indeed confusing to have redundant definitions in 
>two different specifications.  Happily, here, one makes clear the 
>other is the controlling spec for this item.

Your comment elicited a smile. :-)  You mentioned RFC 5322, Section 
3.6.7 which references RFC 5321 to explain trace fields.  The draft 
references RFC 2505 for trace information.

>So email-arch does have an error, here, but it's the opposite of 
>what you note.  Now fixed.

This brings us back to the document conventions used in the draft 
where the first part of a structured field cites the specification 
for the field.  RFC 5322 has a registration for "Return-Path" in the 
Permanent Message Header Field Names registry.  The "Received" header 
field registration references both RFC 5321 and RFC 5322.

>It needs to be normative.

At the beginning of your reply, you said that the text with a 
reference to RFC 2821 and RFC 2822 is not normative.  In the draft 
STD 10 and STD 11 are Informational references.

Regards,
-sm

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 May 2009 21:57:11 +0200

On 5/16/09 5:28 PM, SM wrote:
> 974.  There's also RFC 1123 which updates or annotates portions of RFC 
> 821 to conform to current usage (at that time).  RFC 1123 discouraged 
> all source routing and tried to abolish explicit source routing for 
> mail delivery.

I think Dave is aware of that as he was in the room when that text was 
written (I was one of the people writing it).

Eliot