[Ballot comment]
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.

[Ballot comment]
In section 1.1, History:

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

*  No prior arrangement between MTAs or between Authors and
  Recipients

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

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

[Ballot comment]
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

[Ballot comment]
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?

[Ballot discuss]
I am marking this as a DISCUSS to ensure it is discussed on the call.  I will move to
No Objection on the call regardless of how this is decided.

I believe that this document should be an Informational RFC.  A variety of reasons for
standards track or BCP have been raised, but I did not find them very compelling.  I would
like to hear from ADs that support PS or BCP regarding their rationale...

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

These are the 7 significant technical flaws I identified during AD review of -09.  I'm including them here to avoid redundant work by other reviewers.

1. Originator vs. Author

Section 2.1.1 confuses the concept of "originator" with the concept of "author".  RFC 2822 uses the term originator to refer to _both_ the author and the sender.  RFC 2821 uses the term originator to refer to the owner of the rfc2821.MailFrom address.  In general, the "originator" concept is an umbrella for these sub-roles.  In the common case these concepts refer to a single individual or entity.  But if the author and sender are different, something RFC 2822 clearly permits, then the concept of "originator" and "author" are different.

I'd define "originator" as the entity or entities responsible for creation and initial submission of a message.  I'd define "author" as the entity or entities responsible for creation of message content.

2. New terminology vs. Standards Track terminology

While I don't object to the creation of new terminology for concepts where we have existing standards track terminology (especially if people find the new terminology more comfortable), I do object to defining new terminology to replace existing standards track terminology in the core technical specifications (821, 822, 2821, 2822) without referencing the existing terminology.

For example, the term "bounce handling address" or "bounce address" is new in this document.  RFC 2821 uses the term "originator address" and the term "reverse-path" for this concept.  Readers need to know these terms refer to the same thing in order to understand the architecture and technical specifications together as a whole.

One other example:
* As defined, "bounce" means the same thing as "DSN".  If you mean this, say so.

3. Envelope vs. Message

The envelope is not part of the message in RFC 2821 or 2822.  This is critical to the architecture of the system.  Section 4.1, second paragraph directly contradicts this fact and needs to be corrected.  I suggest listing "envelope" as a separate item in the list in section 4 to make this clearer.

4. ENVID set by originator not source

The "ENVID" parameter has to be set by the originator in section 4.1.4.  If the Source role (MSA) adds "ENVID" it's useless except for mail administrator tracking as the originator doesn't know it and thus can't use it.

5. oMS drafts, queued and unsent folders

IMAP allows drafts to appear in _any_ folder so no drafts folder is present in the IMAP oMS model.  Furthermore, IMAP does not have a message submission function (by design) so it makes no sense to have a queued folder on the IMAP server since it can't actually be queued there as part of the standard.  I don't think I've ever seen an unsent.  Thus the statement about these folders contradicts the existing standards track design of the MS as specified by IMAP. To the extent POP is a mailstore access protocol (although I prefer to think of it as maildrop access), it has no capability for folders at all.  So both of the IETF's "mailstore" protocol designs contradict this statement.

6. push delivery vs. pull delivery vs. maildrop/message-store access

These are three separate and distinct concepts.  In section 4.3.3, third paragraph, the document confuses the latter two badly.  POP and IMAP live outside the MHS and thus have nothing whatsoever to do with delivery.  Pull delivery is provided by one of two protocols: ETRN (RFC 1985) or ODMR (RFC 2645).  Removing the problematic paragraph would be one acceptable way to fix this.

7. Aliases vs. Mailing Lists

To make these terms useful, there needs to be a clear and unambiguous way to distinguish them.  The definitions in the present document overlap making it impossible to identify the correct label for a given constructions.  This needs to be fixed.  To give you a suggestion on how to fix this (although I don't insist you use this suggestion) -- within my organization the way we distinguish these two concepts is that an alias does not alter the RFC2821.MailFrom and a mailing list always alters the RFC2821.MailFrom.

    (1.a)
        Who is the Document Shepherd for this document?

Tony Hansen

Has the Document Shepherd personally reviewed this version of
the document
yes
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?
yes

    (1.b)
        Has the document had adequate review both from key members of
the interested community and others?
yes
Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
no

    (1.c)
        Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

no

    (1.d)
        Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the
IESG should be aware of?

no

For example, perhaps he or she is
uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

    (1.e)
        How solid is the consensus of the interested community behind
this document?

pretty solid

Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a
whole understand and agree with it?

This document has been discussed broadly within the email community. A
large number of people in this community have spoken up at one time or
another with words of encouragement and positive suggestions for
improvements. There has been some compromise on some of the terminology,
but rough consensus appears to have been achieved on the compromises.

    (1.f)
        Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
no

    (1.g)
        Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See www.ietf.org/ID-Checklist.html and
tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met
all formal review criteria it needs to, such as the MIB Doctor,
media type and URI type reviews?
yes

There is one nit that now appears: a newer version of one of the
referenced internet drafts (draft-hutzler-spamops-06) was published at
the same time as the latest version of this draft. This would be fixed
in auth48 or any revised version coming out of IESG/IETF review.

    (1.h)
        Has the document split its references into normative and
informative?
yes
Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state?

no

If such normative references exist, what is the strategy for
their completion?
n/a

Are there normative references that are downward references, as
described in [RFC3967] (Bush, R. and T. Narten, ?Clarifying when
Standards Track Documents may Refer Normatively to Documents at
a Lower Level,? December 2004.)? If so, list these downward
references to support the Area Director in the Last Call
procedure for them [RFC3967] (Bush, R. and T. Narten,
?Clarifying when Standards Track Documents may Refer Normatively
to Documents at a Lower Level,? December 2004.).
no

    (1.i)
        Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document?

yes

If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA
registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?
n/a

    (1.j)
        Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF
rules, MIB definitions, etc., validate correctly in an automated
checker?
none

    (1.k)
        The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Writeup?
Recent examples can be found in the "Action" announcements for
approved documents. The approval announcement contains the
following sections:

===
        Technical Summary

  Public discussion of the Internet Mail service often lacks
common terminology and a common frame of reference for these
components and their activities.  Having a common reference
model and terminology makes a basic difference when talking
about problems with the service, changes in policy, or
enhancement to the service's functionality.  This document
offers an enhanced Internet Mail architecture that targets
description of the existing service, in order to facilitate
clearer and more efficient technical, operations and policy
discussions about email.

        Working Group Summary

This document was discussed within the mail community on the
mailing lists dedicated to SMTP and the Mail Format. Some of the
terms came about as a compromise after long discussions, but
rough consensus was achieved on all points. Members of the
working groups dealing with IMAP and LEMONADE were aware of this
effort, but it was not an appropriate topic for those working
groups to place on their charters. There is no other current
working group dealing with the mail system in general.

        Document Quality

This document does not create a protocol specification.

The acknowledgments indicate that Graham Klyne, Pete Resnick
and Steve Atkins provided thoughtful insight on the framework
and details of the original drafts. A number of other people
have provided additional reviews and insights.

        Personnel

        Who is the Document Shepherd for this document? Tony Hansen
Who is the Responsible Area Director? Chris Newman