Re: [EAI] Shepherd report review of mailinglist-02

["John R Levine" <[e-mail]>]

Thanks for this, I'll do a new version later this week.  I also have some 
comments from the WG that I was waiting to fold in.

R's,
John


On Tue, 10 Jul 2012, Joseph Yee wrote:

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

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.