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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

SM wrote:
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.

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


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.

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.


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]

fixed. thanks.


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

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.


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

fixed.


As the "RcptTo" is at the SMTP layer, it might be more appropriate to 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.



       "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 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
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]