Re: [appsdir] [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01

"John Levine" <johnl@taugh.com> Fri, 06 January 2012 06:40 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: appsdir@ietfa.amsl.com
Delivered-To: appsdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AEB11E80AE for <appsdir@ietfa.amsl.com>; Thu, 5 Jan 2012 22:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.835
X-Spam-Level:
X-Spam-Status: No, score=-105.835 tagged_above=-999 required=5 tests=[AWL=-3.236, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq0ZOrxPsITT for <appsdir@ietfa.amsl.com>; Thu, 5 Jan 2012 22:40:02 -0800 (PST)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6B11E8076 for <appsdir@ietf.org>; Thu, 5 Jan 2012 22:39:58 -0800 (PST)
Received: (qmail 92145 invoked from network); 6 Jan 2012 06:39:56 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Jan 2012 06:39:56 -0000
Date: Fri, 06 Jan 2012 06:39:34 -0000
Message-ID: <20120106063934.80082.qmail@joyce.lan>
From: John Levine <johnl@taugh.com>
To: appsdir@ietf.org
In-Reply-To: <6.2.5.6.2.20120105165019.063fa0a8@resistor.net>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 7bit
Cc: sm+ietf@elandsys.com
Subject: Re: [appsdir] [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01
X-BeenThere: appsdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Apps Area Review List <appsdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/appsdir>, <mailto:appsdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/appsdir>
List-Post: <mailto:appsdir@ietf.org>
List-Help: <mailto:appsdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/appsdir>, <mailto:appsdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2012 06:40:03 -0000

>for feedback from a mailman developer and other MLM implementors.

Hi.  I guess I'm a defacto mj2 implementer.

>>1) Have the original authors of these documents been contacted to 
>>see if they want to
>
>I emailed to the original authors.  If anyone has an up to date 
>contact for them, please email me. 

Josh Baer is easy enough to find, once you know he's the one in Austin,
not the art critic.

General comments on 2369bis:

It's basically fine, but I have a few suggestions.  As an editorial
matter, the constant harping to use mailto: everywhere gets old.  I'd
suggest saying it up front and noting that mail users aren't
necessarily able to use any other kind of URI, then drop it.  The
other 99.9% of mail users, of course, find a web page a lot easier
than trying to send mail and hope for a response.

Section 4 seems obsolete.  Does anyone use nested lists any more, at
least nested lists visible to the users?  The idea used to be to save
bandwidth by sending one copy of a list message to an exploder closer
to the users, but I don't know anyone who still does that.  You can
get pretty much the same effect by sorting the deliveries by target
MX, and then send one copy per MX with multiple MAIL TO.

Appendix B strikes me as MUA user interface design advice by people
who know nothing about UI design.  I'd just drop it, or replace it
with a short note that the plan is for MUAs to recognize and interpret
the list headers and use them to present a list management interface
to the user that matches the rest of the MUA's interface.

>>3) The deletion of Appendix A from RFC2369 is conspicuous.  Why 
>>remove all of that supporting discussion?

Because it's not very interesting any more.  I suppose you could put
in a sentence saying that the design discussion in RFC 2369 may
be useful to help understand the design of list headers.

>>7) In 3.5 of RFC2369bis (and of its antecedent), the "There is no 
>>need" sentence seems odd.  If the MUA is supposed to use 
>>"postmaster" to contact the owner in the case of a list that doesn't 
>>add this, what domain name should it use?

I agree that's wrong.  Just add the fripping header, please.

>I have not tested whether existing implementations bounce user 
>generated messages which contain List- headers.

mj2 typically deletes and replaces them.  In theory it could recognize
and bounce, but I don't know anyone who's configured it that way.

Comments on 2919bis:

In sec 2, the list ID is typically a hostname in the domain of the
list itself, not of the list owner.  I run lists with addresses like
listname@lists.gurus.org, but I as the owner have an address in
another domain.

In sec 3, most of the places it refers to the MUA are at least as
applicable to the MDA.  I do all of my list sorting at delivery time,
not in the MUA, and I suspect a lot of SIEVE users do the same.

Sec 7, I still think nested lists are dead.

>Subject tags are commonly used as list identifiers (this mailing list 
>uses them).  Appendix A.1 explains the difference between a List 
>Identifier and a subject tag in terms of uniqueness.  If I have to 
>provide an explanation, I would have to get into mail filtering, e.g. 
>why use List-ID instead of subject tags to move messages from this 
>mailing list into a separate mailbox.

I'd just point out that the subject is associated with the message,
not the list.  As a concrete example, if I send a personal reply
to the author of a list message, the subject will still have the
list tag, but it won't have a list-ID.

R's,
John