Re: Gen-ART review of draft-ietf-appsawg-malformed-mail-09
"Murray S. Kucherawy" <superuser@gmail.com> Thu, 07 November 2013 00:48 UTC
Return-Path: <superuser@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238F111E8170; Wed, 6 Nov 2013 16:48:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 xnuelMJ5JChm; Wed, 6 Nov 2013 16:48:57 -0800 (PST)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 326FC11E816D; Wed, 6 Nov 2013 16:48:57 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id ex4so4654026wid.9 for <multiple recipients>; Wed, 06 Nov 2013 16:48:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LhoXC6rh4G2EAQOENjujQQie8BaMRtRK89lx2CzPRJw=; b=vBAval7/vJg4qXzC6f2BvagkvlIcMgHYVNssX9d0KICruFA7JG2EEqf39BzeN/LkGS 0Yl5Eh8SgGbewPmI2JlUBTTaATQ5WvCstj/aUHrKeLDVrlPa+cWTUCBOzesZH2y6ZO3o F6LCcOxg58noMHn1YMiJdj0shUtC7IBVS7RM52iNV702KR5iC8VOnwDu6vSiAkD6qybu URUun3uH2sSFtvE/XktaxqsJK2I4BQK8zkBPeWBlaWhPnQDxHuyrFc5ho0sPLbb1w5im idcrqlqH/9mfg7a/mRdLuiJR7AryRymBb7FKEROmn33QI+j0Nd0jok3iIAd7X36rnv0+ 6++g==
MIME-Version: 1.0
X-Received: by 10.194.205.37 with SMTP id ld5mr812981wjc.67.1383785336344; Wed, 06 Nov 2013 16:48:56 -0800 (PST)
Received: by 10.180.18.202 with HTTP; Wed, 6 Nov 2013 16:48:55 -0800 (PST)
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026AAEBA81@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712026AAEBA81@MX15A.corp.emc.com>
Date: Wed, 06 Nov 2013 16:48:55 -0800
Message-ID: <CAL0qLwbF9KuqmHXRtV6TYEtXx5c0UMgjSp7-wohqKEiUzSKs5w@mail.gmail.com>
Subject: Re: Gen-ART review of draft-ietf-appsawg-malformed-mail-09
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "Black, David" <david.black@emc.com>
Content-Type: multipart/alternative; boundary="047d7bb70c586b148c04ea8ba161"
Cc: "ned.freed@mrochek.com" <ned.freed@mrochek.com>, "ietf@ietf.org" <ietf@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>, "gshapiro@proofpoint.com" <gshapiro@proofpoint.com>, "Barry Leiba (barryleiba@computer.org)" <barryleiba@computer.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2013 00:48:59 -0000
I think I'm going to request creation of my own private Directorate. David seems to get all my Gen-ART reviews, and we could possibly do some optimizing here. :-) On Fri, Nov 1, 2013 at 6:32 PM, Black, David <david.black@emc.com> wrote: > > Nits/editorial comments: > > The word "naked" is used a few times to refer to something that occurs in > isolation, without enclosure in another construct, e.g., a naked CR. This > idiomatic use of "naked" should be explained before it is used. > Fixed; just used "isolated" again. > > In Section 1.1, I have always heard Postel's law as: > - Be conservative in what you send, and > - Be liberal in what you accept. > The change from "do" in this draft to "send" (above) seems useful, as > it should help focus the discussion in the second paragraph of Section > 1.1 - Postel's law, as I have understood it, has never blessed anything > remotely resembling there being "no limits to the liberties that a > sender might take." > There are a bunch of versions. See: http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_Law Some of them say "do", some say "send". Perhaps the most authoritative one is here, in Section 1.1.2: http://tools.ietf.org/html/rfc1122 It says "send". I'll make that a reference and adjust. I concur that the Law doesn't bless the extremes, but I believe the email community has (deliberately or through ignorance) gone there, which is largely the point of this work. > > Section 5's section title "Mail Submission Agents" doesn't seem to be > connected to its MHS and MTA content. It would be useful to add a > sentence to remind readers, including this one ;-), of what Mail > Submission Agents are. > The final sentence of that paragraph specifies what it does, but I see your point about the disconnect in terminology. Will adjust to tie it all together. > > Sections 7.1.* offers degrees of advice qualified by "safely", "usually", > "reasonably" and "should". There appear to be only two concepts: > - "safely": Do this all the time. > - "usually", "reasonably", "should": This is the recommended course > of action, but there may be exceptions. > While RFC 2119 is not intended for Informational documents, this is an > example of the sort of sloppiness that RFC 2119 is intended to clean up. > At the very least, the use of three words for essentially the same concept > is poor form, and RFC 2119 can be used in an Informational document when > appropriate caveats are provided in the terminology section that references > it. > Earlier versions of this draft looked roughly like an applicability statement, and thus had RFC2119 language throughout. We decided that, as you point out, it's mostly advice, and not a way of establishing a capability within Internet Mail, which would be more like what an applicability statement is for. I'm thus inclined not to backtrack, but merely satisfy your "At the very least" clause. > In Section 7.1.4, "Likewise" is not a good way to associate the second > example with the first, because it handles the missing parenthesis in a > rather different fashion (adds quotes instead of inserting the missing > parenthesis character). > Removed. > > In Section 7.7, the first use of "8bit" occurs in "8bit material" but some > of > the subsequent occurrences omit the word "material" - that word should be > used with all occurrences. > Fixed. > > idnits 2.13.00 generated a couple of warnings about obsolete references: > > -- Obsolete informational reference (is this intentional?): RFC 1113 > (ref. > 'PEM') (Obsoleted by RFC 1421) > > -- Obsolete informational reference (is this intentional?): RFC 733 > (Obsoleted by RFC 822) > > In both cases, the reference appears to be intentional, and the warning > should be ignored. > Correct; I'll make sure the AD sees this. Thanks! -MSK
- Gen-ART review of draft-ietf-appsawg-malformed-ma… Black, David
- Re: Gen-ART review of draft-ietf-appsawg-malforme… Murray S. Kucherawy
- Re: Gen-ART review of draft-ietf-appsawg-malforme… Barry Leiba
- RE: Gen-ART review of draft-ietf-appsawg-malforme… Black, David
- Re: Gen-ART review of draft-ietf-appsawg-malforme… John Levine