ietf-smtp
[Top] [All Lists]

Re: Final draft: draft-crocker-email-arch

2007-05-08 11:26:06

On Sun, May 06, 2007 at 02:59:06PM -0700, Dave Crocker wrote:

Folks,

I've sent in draft-crocker-email-arch-07 to the I-D folks.

The html version is at:

 <http://bbiw.net/specifications/draft-crocker-email-arch-07.html>

After two years and six major revisions, this is the version that will be 
submitted to the IESG for standardization.

If you have any final comments, please get them to me.

Looks pretty nice.  Some very small stuff (against the -07 version on
ietf.org, which I would assume is the same):

====================

Change notes say that "Bounce" has been moved out of the MHS (diagram),
and so it is; but there is an MHS Actors subsection (2.2.2) for Bounce
Handler, implying that Bounce Handler is inside the MHS.  This is
confusing.



2.3.  Administrative Actors

   Actors often will are associated with different organizations, each

omit "will"



4.1.  Message Data

      Delivery Status Notification (DSN):

         A Delivery Status Notification (DSN) is a message that can be
         generated by the MHS (MSA, MTA or MDA) and sent to the
         RFC2821.MailFrom address.  The mailbox for this is shown as
         Bounces in Figure 5.  It provides information about message
         transit, such as transmission errors or successful delivery.

Quirk:  the "It" that begins the last sentence appears to refer to the
bounce mailbox, which can be confusing.  Better to say "The DSN".


Also in 4.1:

      Message Disposition Notification (MDN):

         A Message Disposition Notification (MDN) is a message that
         provides information about user-level, Recipient-side message
         processing, such as indicating that the message has been
         displayed [RFC3798] or the form of content that can be
         supported.  [RFC3297] It can be generated by an rMUA and is
         sent to the Disposition-Notification-To address(es).  The
         mailbox for this is shown as Disp in Figure 5.  It

Dangling "It", dang it.


4.1.4.  Identity References in a Message

This section ends with subsections for "List-ID" and "List-*" which are
not included in the table at the beginning of the section.  Is this
intentional?  Relatedly, "IP Address" appears in the table but has
no subsection.



5.3.  Mailing Lists

      RFC2822.TO, RFC2822.CC

         Set by: original Originator

         These usually contains the original list of Recipient
         addresses.

"usually contain" (not contains)



5.4.  Gateways

      RFC2822.Sender

         Set by: Originator Source or Mediator Source

         This can retain the original value or can be set to a new
         address

Punctuation:  most subsections end with a period, this one doesn't.

mm