Re: [EAI] Comments on draft-ietf-eai-mailinglistbis-04

[John C Klensin <[e-mail]>]

SM,

Let's be careful here.  A number of the issues you raise are
really about the fundamentals of mailing list management.  I
agree that it would be good if the IETF developed up to date
protocol specifications or best practices guidance in this area.
But they are not in scope for EAI.   For EAI, I think it is in
our interest to keep this document as narrowly focused on
i18n-specific problems as possible.  The WG has discussed the
scope of this document several times since John agreed to do a
draft (and discussed the scope of its predecessor several times
since before it was published).

Moreover, the model in this document (also discussed several
times in the WG and agreed) is to identify issues, not try to
fix the problems or propose protocol changes.

In the hope of actually finishing this document (including IETF
LC) in the next several weeks (or even in our lifetimes given
how controversial MLM topics, among others, tend to be), I'd
really like to keep this focused.  And, again, those broader
issues aren't in charter.

Details inline below.

--On Saturday, July 14, 2012 04:31 -0700 SM <[e-mail]>
wrote:

> Hi John,
> 
> Here are some comments about draft-ietf-eai-mailinglistbis-04.
> The document uses a style which is easy to understand.  It
> tackles mailing lists and non-ASCII email addresses from a
> mail transport and message header perspective only.  I
> mentioned these points as there are other questions which MLM
> implementers take into consideration, e.g. for archival [1]:
> 
>    - Which identifier to use for the list [2]
> 
>    - Which identifier to use for a message
> 
>    - Compatibility with the NNTP environment [3]

All fundamental list management issues.  Out of scope here.  And
the NNTP environment is not inherently more important than any
other environments into which mailing lists might be gatewayed.
For example, I note that you do not discuss the content and
format of mailing list archives, which might be equally relevant
-- and equally out of scope for EAI.

> There are questions such as de-duplication (how to prevent
> duplicate copies of a message), message digests, HTML
> downgrades, etc.  As all this is likely out of scope for EAI I
> am not suggesting that the document address these questions.

I agree, they are out of scope for EAI and the document should
not try to take them on.

> The main issue is what to do about mixed SMTPUTF8 and ASCII
> mailing lists (Section 2.2).  The idea of sending a probe
> message sounds practical.

And is part of the solution space, not the issue description
space.

> In Section 2.2:
> 
>    "To determine whether a message needs to be downgraded for
> ASCII
>     recipients, list software might assume that any message
> received via
>     an SMTPUTF8 SMTP session is an SMTPUTF8 message, or might
> examine the
>     headers and body of the message to see whether it needs
> SMTPUTF8
>     treatment."
> 
> Why not test for "message/global" instead of inspecting
> message content?

IMO, testing for message/global is a subset of inspecting
message content and, in particular, of "examining the headers
and body".  Even if one asked for that text in particular, the
statement above would still have to be present because there are
many ways to have messages that require SMTPUTF8 features
without having message/global present.

>...> 
> The List-Post: header needs the "mailto".  Part of the
> remaining (2369) List- headers (List-Unsubscribe:,
> List-Archive:, List-Help:) can be handled through HTTP.
> 
> The List-Id: header can be considered as an opaque string.
> The information which is displayed can be passed as a comment.
> That allows the issue of IDNs to be side-stepped.  You can
> also avoid the question of downgrading if you use a randomly
> generated string.
> 
> I would treat the 2369 and 2919 List- header separately as you
> have more leeway for the latter (see above paragraph).
> Per-header issues could be identified and discussed on an
> issue-basis.

You are getting very far into the implementation details of
these various headers.  In the case of List-* header fields,
that requires updating the base documents.  That has been
discussed previously and is not on the agenda for this WG.  What
the document says is consistent with the current specs, i.e.,
that anything that is present has to be conformant to them.

> Section 3.2 discusses the "mailto" issue (re percentage sign
> and source routing).  There is one sentence about the IDN
> angle which does not say much.

So what are you suggesting be done about it.  I recommended
removing that discussion; several people in the WG wanted
something minimal there.  The present text appears to meet that
minimal requirement.

> In Section 3.3:
> 
>    "List software typically leaves the original submitter's
> address in
>     the From: line, both so that recipients can tell who wrote
> the
>     message"
> 
> I suggest author instead of submitter.

Submitter was, I believe, deliberate because "author" rapidly
takes on all sorts of ambiguity.  I recommend this issue be
deferred to those hypothetical mailing list management documents
and that the author/editor use his discretion.

> The Security Considerations section is going to raise
> questions.  Given the approach taken to discuss the subject,
> there's not much to say.

Yes.  But this is an issues report, not a protocol spec, so the
problem you anticipate may be unavoidable.

> It's difficult to pick a solution for mailing lists.  I am not
> being critical about the trade-offs as I don't have a fix to
> suggest.

Except for "submitter", I've omitted the editorial nit-picking
and will leave them to John's discretion.  But, more generally,
I really hope that we can focus now on what is absolutely
necessary to get this document out, plus any newly-discovered
showstoppers that show up.

As a preview and unless the WG disagrees, it is my intention
(and, I believe, Joseph's) to deal with any IETF Last Call
comments that open up larger mailing list issues in much the
style of my comments above: they are out of scope and this
document is an issues report not a protocol specification.  I
imagine we made need to repeat that a lot (and it is said
proactively in the draft shepherd's report), but the
alternatives of opening up the general mailing list issues or
trying to revise the List-* header specs would be a disaster (at
least as far as getting the document finished in a timely
fashion).

best,
   john