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

"Murray S. Kucherawy" <msk@cloudmark.com> Fri, 06 January 2012 00:10 UTC

Return-Path: <msk@cloudmark.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 6D25D11E807A for <apps-discuss@ietfa.amsl.com>; Thu, 5 Jan 2012 16:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level:
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 tPjt0vHKrOz8 for <apps-discuss@ietfa.amsl.com>; Thu, 5 Jan 2012 16:10:55 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C75711E8083 for <apps-discuss@ietf.org>; Thu, 5 Jan 2012 16:10:55 -0800 (PST)
Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 5 Jan 2012 16:10:48 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 5 Jan 2012 16:10:54 -0800
From: "Murray S. Kucherawy" <msk@cloudmark.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Date: Thu, 05 Jan 2012 16:10:53 -0800
Thread-Topic: [apps-discuss] Feedback on draft-moonesamy-rfc2369bis-01 and draft-moonesamy-rfc2919bis-01
Thread-Index: AczLI7r9X3B/btEuQF28o2tl3JS9jAA30WFQ
Message-ID: <F5833273385BB34F99288B3648C4F06F19C6C15759@EXCH-C2.corp.cloudmark.com>
References: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com>
In-Reply-To: <6.2.5.6.2.20120104113753.0a6e00e0@elandnews.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 00:10:56 -0000

Hi SM,

First, I suggest this be sent to the "ietf-822" list as well as the lists of MLM package developers, such as Mailman.  I'm on both already and can forward it if you like.

A few cursory review points based on a diff of the old ones to the new ones (and apologies for jumping back and forth between documents as I go here):

0) What's the rationale for doing this work now?

1) Have the original authors of these documents been contacted to see if they want to participate in the update?  Has their permission been secured to republish substantial chunks of their original text?  The IPR statement in your draft should reflect this either way.

2) It seems to me both of these would be helped (in the "can't hurt" sense) by an informative reference to RFC5598 just so there's a handy illustration of how all these components fit together.

3) The deletion of Appendix A from RFC2369 is conspicuous.  Why remove all of that supporting discussion?  I suppose since this stuff has been out there for a while now it'd be sufficient to mention in later sections that such discussion exists in the original document.

4) The language at the top of 3.1 sounds vaguely like a minimum compliance statement.  I suggest it be reworked to something simpler, like striking everything from "is the most" up to and including "by definition it".

5) Adding ABNF for each of the header fields would be good.   Right now there's only ABNF for List-Sequence.

6) The various URI constructions might benefit from being enabled by what's specified in draft-gregorio-uritemplate (now in IESG Evaluation, so it might be an RFC soonish), which would allow the defined header fields to contain values expanded by the MUA, something like:

	List-Help: <mailto:list-request@example.com?subject=help?user={user}>

...and then just define that when expanding such templates, "user" is the email address the MUA is using.

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?

8) There's normative language in the Client Implementation appendix, carried over from the previous version.  I think this should be softened, or it should become a non-appendix normative section on its own.  You might, however, get some resistance from people about putting normative guidance to MUAs in a document since it's often said that the IETF the-opposite-of-expert at user interface concerns.

9) There's a mix of SHOULD and should in here.  Since you're citing 2119 they all mean the same thing, but the mixed case will leave some people wondering.  I suggest using SHOULD everywhere that you mean it, and alternatives elsewhere ("might", "are advised to", etc.).

10) List-ID uses the domain name space, even if the domains don't actually exist.  Do we need to talk about IDNA at all here?

11) Kudos for moving a SHOULD out of the Introduction in RFC2369bis.

12) There's a place in Security Considerations where it makes a normative assertion that user-generated List-* fields need to be deleted by the MLM.  I think that should be in a normative part of the document rather than Security Considerations.  Rather, Security Considerations might talk about the risks created if an MLM doesn't comply.

13) The change from "localhost" (which might actually resolve, if that matters) to "invalid" makes sense, but I'm somehow worried about backward-compatibility issues.

14) Section 6 in RFC2919bis seems needlessly verbose about case-insensitive string comparison.  Simply using that term is quite sufficient.

15) Appendix A.1 in RFC2919bis seems way off topic.  I suggest striking it, or adding text to explain why it's not off topic.

16) There's stuff in RFC2369bis Appendix A that recommends MUA application of these fields which uses normative language.  This should probably also be adjusted, or it should become a normative section rather than appendix.

I think that's enough for now.  I'll have more as the work evolves.

-MSK