Internet Mail Architecture
RFC 5598

Note: This ballot was opened for revision 14 and is now closed.

(Ron Bonica) Yes

Comment (2009-06-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I am voting "YES" on this document because I think that it provides an excellent exposition on a very important topic. However. I have a few comments:

- I share Tim's question about why it is PS as opposed to INFORMATIONAL
- Section 1.2 borders on philosophical musing. I wonder if the document wouldn't be improved by its omission
- Indentation broken above figure in section 2.2

(Alexey Melnikov) Yes

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2009-06-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This document is excellent - informative, well-organized, readable.

I'm conflicted about whether to publish the document as Standards Track or Informational.

One specific concern is that there are just a few (fewer than 10, if I searched correctly) occurrences of RFC 2119 requirements language.  Why are those few instances sufficiently important to be included in this doc?  Do those uses of RFC 2119 language establish new behavior or do they reflect requirements from other RFCs.  If the latter, why not cite those RFCs rather than including the requirements language in this doc?  If there are new requirements in this doc, will implementors know to look through the entire doc to find and implement those requirements?

My preference would be publication as Informational, with replacement of any RFC 2119 requirements with pointers to the RFCs in which those requirements are established.

Editorial nits: In section 2.2, I don't think this text should be centered:

      Figure 3 shows the relationships among transfer participants in
   Internet Mail.  Although it shows the Originator (labeled Origin) as
   distinct from the Author and Receiver (labeled Recv) as distinct from
        Recipient,  each pair of roles usually has  the same actor.
      Transfers typically entail one or more Relays.  However direct
       delivery from the Originator to Receiver is possible.  Intra-
          organization mail services usually have only one Relay.

In section 3.1, where are "<addr-spec>" and "<local-part>" defined?  Really tiny nit (which I'm almost embarrassed to mention) - "local-part" appears in the index while "addr-spec" does not.

Section 4 (page 23) - another centering problem?

     This figure shows function modules and the standardized protocols
                            used between them.

(Lisa Dusseault) No Objection

Comment (2009-06-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

In section 1.1, History:

"End-to-end Internet Mail exchange... these components and characteristics

*  No prior arrangement between MTAs or between Authors and

*  No prior arrangement between point-to-point transfer services
   over the open Internet"

The absence of prior arrangement is not a requirement.  What this text should read is "no necessary prior arrangement" in each case.  Later text acknowledges this, but this text reads as if prior arrangement is never there.

In Figure 2: 
I don't understand the point of the diagram, particularly the two different kinds of arrows, and the meaning of the return arrows.  I had some of the same trouble with Figure 1 but this one is worse.  

End of section 2.1:  "Whenever any MHS actor sends information to back to an Author or
Originator in the sequence of handling a message, that actor is a

This defines all kinds of automated agents as Users.  E.g. if my company runs an outgoing mail filter, which looks for possible leaks or inappropriate content, and that filter generates a message saying my original message was trapped in quarantine, that filter has now been defined as a User.  I find this counter-intuitive and don't understand why it's a useful or necessary definition.  Would the outgoing mail filter still be a User if it sent me an instant message instead of a mail message? 

This point is carried on later in discussion of why a Mediator is a User even if it's automated, because it can receive replies.  Not all automated sources of messages or filters of messages are able to receive replies.

If it were not too late to change the terminology, I would suggest "User-level Actor".  Then later in the document one could say things like "A Gateway is a hybrid of user-level and relay-level functions."

Even without a change in terminology, one way of explaining this that I deduced from the document, that may be a useful alternate way of putting it,  is that "User" Actors may generate, modify or look at the whole message, Relay layer actors generate, modify or look at only relay headers, and packet layer do not look at any of it.

Figure 5 makes sense except I don't know what (S) and (D) mean at the boundaries of the MHS.... ahhh, I later discover this is explained pages later.    I think the first line of the legend should have "-- lines indicate primary (possibly indirect) transfers or roles)" instead of "==" for the first two characters.

Section 6.3, Internationalization:  "POP and IMAP do not introduce internationalization issues".  I'm sure this is true in some limited sense, but it's not actually useful.  POP and IMAP have i18n issues of their own (sorting a list of messages by the Subject header) and could conceivably introduce i18n issues for the MHS.  Perhaps the wording "POP and IMAP are mostly affected by the internationalization enhancements developed elsewhere, which at times has resulted in changes to POP and IMAP to handle incoming strings that may be internationalized."

(Adrian Farrel) No Objection

Comment (2009-05-31 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This is a really helpful document. I'm glad it has been written.

I would be more comfortable with this I-D as Informational. As the Absatract points out, the document provides a description of the current architecture. But I can't get up enough steam on the topic to Discuss it.

It would have been better if the I-D had passed idnits cleanly before submission for review. Most of the nits are simply fixed (by the authors or the RFC Editor).

But looking at idnits would reveal the existence of a downref. I don't see any reference to a downref in the last call announcement in the data tracker. Was it flagged, or did it get lost in the change from Info to Std Track? Surely another reason to stay on the Std Track.

I would suggest that it is not necessary to use 2119 language in this document since it describes how things are. The I-D does not need to make proscriptive statements as those are already made in the referenced RFCs. Instead, the I-D can say "as defined in [RFCxxx] the MUA must blah-blah"

Not sure that the index is necessary. It certainly hints at a bunch of extra work for the RFC Editor.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

Comment (2009-06-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This should be informational.

On the call today, I would like to make sure that I understand what is to happen with the PDF version of the draft.

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-06-03)
No email
send info
Figure 2 is never referenced in the text.

Figure 2/Section 2.1.3

The Return Handler does not appear in the figure, and the text in 2.1.3 does not provide any
rationale or connecting text.  While it would unduly complicate the figure, it might be nice to
close the loop in section 2.1.3.

Section 2.2.4 Receiver

I thought that the Receiver would operate "with dual allegiance" just as the Originator does
(see section 2.2.1), but the brief text in 2.2.4 does not make any references to the ADMD.
Doesn't the Receiver represent the local operator of the MHS regarding incoming message,
just as the originator represents the local operator of the MHS regarding outgoing messages?

(Dan Romascanu) No Objection

(Robert Sparks) No Objection