[EAI] Shepherd report review of mailinglist-02

[Joseph Yee <[e-mail]>]

Hi.

We have just completed a draft of the Shepherd's report and
corresponding pass through the document prior to handing
the mailinglist document off to IESG.

The review turned up several editorial and related issues.  If
possible, we would like to see them corrected into a -03 before
the document is handed off for IETF Last Call.   Getting nits
fixed at this point often saves a lot of time quibbling about
them later.

WG participants: some of these issues are substantive, see
notes 8, 9, and 11 below.

Authors of other documents.  This type of review is a painful
and time-consuming process.  I used to defer parts of it until
AUTH48, but have learned my lesson: it needs to be done either
before we request IETF Last Call, during or after that Last
Call when ADs or other members of the community start
nit-picking, or during AUTH48.  It only gets more painful at
later stages.   If possible, review your own documents to see
if you can spot and fix these sorts of things before I/we have
to.

John, if you don't have time to make these changes within the
next few days but can supply document source and any comments,
we will try to get a new version out.  we really, really want
this document in IETF LC before Vancouver if that is at all all
possible and we are running out of time.

(1) Abstract

Please change "does not offer implementation or deployment
advice." to "does not specify a protocol or offer
implementation or deployment advice." or, if you prefer "does
not specify protocol changes or offer implementation or
deployment advice."

    Reason: The Shepherd's Report format contains a lot of
        questions that are really relevant only to protocol specs.
        The writeup becomes much more clear if one can say "not a
        protocol spec" and that is less likely to be nit-picked if
        the abstract says that up front.

(2) Introduction, paragraph 3.

Text reads "...This agent sets the envelope return address..."
Please either insert "normally" or "usually" in front of "sets"
or provide a citation to something that requires this.  If you
want to go down the latter path, the relevant citation is
Section 3.9 of RFC 5321 but note that a narrow reading of those
text essentially prohibits a mail exploder from adding "List-*"
headers.

Nit: s/rathern/rather/

(3) Section 1.1, 1.2, and maybe elsewhere.

Nit: "mailing list agent" is fine, as is "mailing list exploder"
(the term used in RFC 5321) but making mailing lists animate
can only cause confusion.  So "Some mailing lists alter
message header fields..." needs adjustment.

(4) Section 1.2, first sentence

Did you want "...mail transport protocol does not differentiate
between..."

(5) Section 1.2, paragraph 3

Old:
        "first, mailing lists might choose to reject all messages
        from internationalized addresses."
New:
        "first, mailing list agents might choose to reject all messages
        from internationalized addresses perhaps because they have
        not been upgraded to handle such messages."
Reason: A little obscure otherwise.  And see note (3) supra.

Old:
        if the members are UTF-8
New:
        if the members are SMTPUTF8
Reason: That has been the convention in the WG and we really
don't need someone reminding us during IETF LC that a message
that contains nothing but ASCII characters is perfectly valid
UTF-8.  Same comment about "EAI messages", etc.

(6) Section 1.2, paragraph 4.

The antecedents in this paragraph are ambiguous.  Since the
paragraph is important, it should be painfully clear.  Suggest
(without changing more of your text than necessary):

   Conceptually, a mailing list's internationalization can be
divided
   into three capabilities: First, does the list itself have a
   non-ASCII submission address or does the message submitter
   use a non-ASCII return-path address?  Second, does the list
   manager accept subscriptions for addresses containing
   non-ASCII character?  And third, does the agent accept
   messages that require SMTPUTF8 capabilities even if neither
   of the other two conditions apply?

Is that what you meant?  Note that the rewording also got rid
of the idea of a UTF-8 address (see note 5).   FWIW, RFC 5321
thinks that a "return-path" is the name of a header field that
doesn't exist prior to final delivery (and a mailing list
exploder is essentially prohibited from adding one and is
supposed to remove it if it appears).  The term you are looking
for is probably "reverse-path" or "backward-pointing address"
but probably no one will notice this unless he or she spent too
much time buried in 5321 and its predecessors.  The return-path
issue also appears in Section 2.3 and perhaps elsewhere.

Also s/EAI messages/SMTPUTF8 messages/, probably globally.


(7) Section 2, first paragraph.

The paragraph seems to be more confusing than it needs to be.

For example,

Old:
   In both cases,
   the message might have only one recipient, or might have
   multiple recipients.
New:
   In both cases,
   the message might be addressed only to the list address, or
   might have recipients in addition to the lis6.

Then the next sentence, which mixes what is coming into the
list exploder with what goes out, could be made single-purpose.

FWIW, I've never seen a large list handled by putting hundreds
of messages into a single SMTP envelope and handing off to a
conventional submission server.  Even with pipelining, the
requirement for a response to each RCPT command is excessive.
Unless that has changed since I've been actively involved with
email operations, you might want to tone "Often" down a bit.

(8) Section 2.1 (warning: substantive)

In a world in which we encourage explicit confirmation as part
of an email subscription process for other reasons (ones with
which you are thoroughly familiar), putting something that
requires SMTPUTF8 handling into the automated confirmation
message would not be burdensome.  Things get complicated if the
list management software wants to take some other action if the
message is rejected at SMTP time (SMTPUTF8 is not offered by
the recipient (would-be subscriber's MTA) or the confirmation
does not arrive.  But, if the policy is "no address that is not
SMTPUTF8-capable need apply" as this paragraph suggests, that
seems fairly easy.

Whether that is worth mentioning is up to you, or, if anyone
has a strong opinion, the WG.


(9) Section 2.2.  (Substantive)

We've essentially said that in-transit message downgrading is
impossible unless the message contains no non-ASCII addresses
and has non-ASCII material only in header fields in which
encoded words can be used.  Absent a whole series of provisions
that you haven't discussed, a mailing list exploder is in no
better shape to downgrade messages for ASCII-only recipients
than a relay.  But here the text says:

   ...list
   software might divide the recipients into two sets, EAI and
ASCII
   recipients, and create a downgraded version of EAI list
messages to
   send to ASCII recipients.

Which sounds misleading and/or like handwaving.    It seems to
me that you either need to spell out the cases of interest
(e.g., "no backward-pointing or additional recipient non-ASCII
addresses, no funky headers that cannot be forced into encoded
words, no signatures over anything relevant") or otherwise
respecify this section.

(10) Section 2.3

"EAI name", "EAI bounce address", etc.  See note 5.

The notion of "modifying" an address is confusing here.  What
you are really suggesting is the use of an ASCII address
instead of the SMTPUTF8 forms that would normally result from
applying traditional rules.

The RFC Editor will  require that you spell out VERP,
supply a reference, or both.  "Both" is almost certainly
preferable.

(11) Section 3.1  (possibly substantive in part)

Title should be "Internationalized List Headers", "Non-ASCII
List Headers", or "SMTPUTF8 List Headers", not "EAI list
headers".

In paragraph 3:
   The most commonly-used URI schemes in List-* headers tend to
be HTTP
   and mailto, although they sometimes include HTTPS and FTP,
and in
   principle can contain any valid URI.

Use "MAILTO", not "mailto" unless you want you waste your time
and ours in a silly argument.

Paragraph 4 is problematic because the whole state of IRIs is
up in the air right now.  It might be better to say something
like:

   Even if a scheme permits an internationalized form, it
   should use a pure ASCII form of the URI described in
   [RFC3986].  Future work may extend
   these header fields or define replacements to directly
   support non-encoded UTF-8 outside the ASCII repertoire in these
   and other header fields, but in the absence of such extension
   or replacement, non-ASCII characters can only be included by
   encoding them as ASCII.

That avoids references to anything but 3986, which is very
stable.  Even though this is an Informational document, the
statement as originally written creates normative references
to 3867  and should create one to [I-D.duerst-iri-bis].  We
really don't want to go there if it can be avoided.

Nit: s/abd/and/

(12) While there have been periodic discussions in the
community about whether the "Normative/ Informative" split
really makes sense for Informational documents, the current
rule is that it is required for the IETF Stream.  While we
could, in principle, make an issue of it, it hardly seems worth
it.  So please split the list up.   Note also that
[I-D.duerst-iri-bis] does not appear to be  not cited in the
current draft and the reference is outdated.  Please get rid of
it unless you have reason to retain it _and_ are absolutely
certain that reason doesn't involve a normative reference.

I think that ends up with the following

Normative:  RFC 3986; RFC6409 (marginal, but a full standard
and hence harmless)

Informative: RFC 2369, RFC 2919 (both mentioned only as
examples)

Questionable: RFC 3987 and RFC 6068  (used only as part of
the specification of "the URI-encoded form" in Section 3.1).  I
urge getting rid of them entirely since it is easy to have the
discussion that is relevant to this document without them and
they (especially 3987, which draft-ietf-iri-3987bis (the real
[I-D.duerst-iri-bis] proposes to obsolete incompatibly.

(13) ID nits tool considers the lack of IANA section an issue, even
this document does not specify any protocol.


Best,
John Klensin and Joseph Yee, co-chair of EAI