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

S Moonesamy <sm+ietf@elandsys.com> Fri, 06 January 2012 21:48 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667881F0C36 for <apps-discuss@ietfa.amsl.com>; Fri, 6 Jan 2012 13:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 80fD7qTf38AX for <apps-discuss@ietfa.amsl.com>; Fri, 6 Jan 2012 13:48:51 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB3E21F842D for <apps-discuss@ietf.org>; Fri, 6 Jan 2012 13:48:51 -0800 (PST)
Received: from SUBMAN.elandsys.com ([41.136.232.119]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q06LmZDA017053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jan 2012 13:48:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1325886528; i=@elandsys.com; bh=KssF7waIyB5Hzb6RyoVTQP3Y5QmXMUvc62SF0soUd/Y=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=jlAyNDdK4+pv7UK1098eD45CsQLwS8D0Ih1Y5pfjTMIWzrjOurgfLu/dApqIf0oPy NXpB4mHFigO7STrhO28XZhQ9w4SQN1CP8m77kkbDq9rkK3JOofo+Bldop1VrYUJK18 xxZiJXsDt+QQR/r9bBRDJ6hz9HMH6wq6E9x2W3yw=
Message-Id: <6.2.5.6.2.20120106125010.0a439be8@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 06 Jan 2012 13:41:24 -0800
To: John Levine <johnl@taugh.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <20120106063934.80082.qmail@joyce.lan>
References: <6.2.5.6.2.20120105165019.063fa0a8@resistor.net> <20120106063934.80082.qmail@joyce.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2012 21:48:52 -0000

Hi John,

Thanks for the feedback.  BTW, your message was copied to appsdir ( 
http://www.ietf.org/mail-archive/web/appsdir/current/msg00687.html ).

At 22:39 05-01-2012, John Levine wrote:
>Hi.  I guess I'm a defacto mj2 implementer.

It's very useful to get input from implementers.

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

Could you send me his email address off-list?

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

That would be the following from Section 2 (it does not include 
changes made in my internal version):

   "Additionally, the use of URIs provides access to multiple transport
    protocols (such as ftp and http) although it is expected that the
    "mailto" protocol [RFC6068] will be the focus of most use of the list
    header fields.  Use of non-mailto protocols should be considered in
    light of those users who do not have access to the specified
    mechanism (those who only have email - with no web access).

I would like to keep a reference to RFC 6068 as "mailto" is commonly 
used.  I'll make the following change:

    Additionally, the use of URIs provides access to multiple URI schemes.

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

The exploders I know of disappeared a couple of years ago.  Section 4 
discusses about nested list and does not mention a union of lists.  I 
planned to implement that feature.  It's useful for cases such as 
IETF mailing lists as most of us are subscribed to several lists and 
end up with an administrative hassle as we have to go through each of 
them to set our preference.  draft-sparks-genarea-mailarch-03 does 
not discuss about such functionality.  I vaguely recall some comments 
during discussions about datatracker enhancements.  I'll suggest 
leaving this section as it is.

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

As Murray pointed that out too, I'll replace that appendix with a note.

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

Thanks, I'll add that.

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

I'll remove the following sentence:

   "There is no need to specify List-Owner if it is the
    same person as the mail system administrator (postmaster)."

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

Ok.

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

SIEVE would be implicit here.  I'll leave the section as it is unless 
there is further feedback.

>Sec 7, I still think nested lists are dead.

If I remove the sections about nested lists in both drafts and leave 
it to the existing RFCs, List-Sequence won't be covered.

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

That's a good point.  I'll leave this comment open.

Regards,
S. Moonesamy