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

From: SM <[email-masked]>
Date: Sat, 14 Jul 2012 04:31:43 -0700

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]

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.

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.

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?

In Section 3.1:

    "[RFC2919] specifies that "The list identifier will, in most cases,
     appear like a host name in a domain of the list owner."  Since
     these headers were defined in the context of ASCII mail, these
     headers permit only ASCII text including in the URLs.

I suggest moving the last sentence in that paragraph before the 
"[RFC2919]" sentence as it applies to the RFC 2369 header fields.

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.

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.

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.

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

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.

Regards,
-sm

1. The archives may be managed by the mailing list operator or by a 
third-party.

2. I assumed that RFC 2919 answered that question.  The implementer 
tried to devise
    a unique id even though there was a RFC published years ago about that.

3. http://packages.python.org/mailman/src/mailman/handlers/docs/nntp.html

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jul 2012 11:49:04 -0400

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 <[email-masked]>
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]:
> 

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.

> Why not test for "message/global" instead of inspecting

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.

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

> 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

---

From: "John R Levine" <[email-masked]>
Date: 14 Jul 2012 12:10:18 -0400

I thought that they were perfectly reasonable suggestions (other than 
message/global, which was a misunderstanding), and I'm not planning to 
address any of them.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 14 Jul 2012 18:39:18 +0200

> message/global, which was a misunderstanding), and I'm not planning to

Thanks.

I dreaded the coming thread.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jul 2012 12:45:44 -0400

--On Saturday, July 14, 2012 12:10 -0400 John R Levine
<[email-masked]> wrote:

> I thought that they were perfectly reasonable suggestions
> (other than message/global, which was a misunderstanding), and
> I'm not planning to address any of them.

I didn't mean to suggest that they were unreasonable.  I am just
trying to carry out my perceived mandate as co-chair to get this
done.  Now.

   john

---

From: SM <[email-masked]>
Date: Sat, 14 Jul 2012 10:31:55 -0700

Hello,
>protocol specifications or best practices guidance in this area.

I'll preface this message by saying that I consider my comments as addressed.

It would be good but I don't think it's realistic to ask for that in 
this document.

>But they are not in scope for EAI.   For EAI, I think it is in

Ok.

>without having message/global present.

Ok.

>that anything that is present has to be conformant to them.

Ok.

>something minimal there.  The present text appears to meet that

I'll go with the WG view to have something minimal (no change suggested).

>and that the author/editor use his discretion.

Ok.

At 09:10 14-07-2012, John R Levine wrote:
>I thought that they were perfectly reasonable suggestions (other 
>than message/global, which was a misunderstanding), and I'm not 
>planning to address any of them.

Ok.

Regards,
-sm

---

From: "John R Levine" <[email-masked]>
Date: 14 Jul 2012 14:10:09 -0400

The only difference is a placeholder IANA considerations section, which I 
forgot to add last time around.

Regards,