[apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1
Eliot Lear <lear@cisco.com> Tue, 07 December 2010 07:05 UTC
Return-Path: <lear@cisco.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177FD3A691C; Mon, 6 Dec 2010 23:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.232
X-Spam-Level:
X-Spam-Status: No, score=-110.232 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2a4m+ClJI76; Mon, 6 Dec 2010 23:05:54 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6A8333A672E; Mon, 6 Dec 2010 23:05:53 -0800 (PST)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvIEAOxr/UyQ/khNgWdsb2JhbACDT5sIhF8VAQEWIiKkNopBkQiEVnMEim4
X-IronPort-AV: E=Sophos; i="4.59,310,1288569600"; d="scan'208,217"; a="14777265"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Dec 2010 07:07:17 +0000
Received: from dhcp-10-55-81-114.cisco.com (dhcp-10-55-81-114.cisco.com [10.55.81.114]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oB777HAi018326; Tue, 7 Dec 2010 07:07:17 GMT
Message-ID: <4CFDDD2F.2020201@cisco.com>
Date: Tue, 07 Dec 2010 08:07:27 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org, eai-chairs@tools.ietf.org, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, 'IESG' <iesg@ietf.org>, Ted Hardie <hardie@qualcomm.com>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/alternative; boundary="------------010001010405060808040104"
Subject: [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 07 Dec 2010 07:05:56 -0000
I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-eai-rfc5337bis-01 Title: Internationalized Delivery Status and Disposition Notifications Reviewer: Eliot Lear Review Date: 7 Dec 2010 Summary: This draft is almost ready for publication but has a few *minor* issues that should be considered prior to publication. Great job! Major Issues: none. Cool! Minor Issues: The document does not state clearly what the differences between this specification and RFC5337. Doing so could speed adoption of this specification. As some of the changes seem subtle, such an addition would be particularly welcome. ABNF: Courtesy of Bill Fenner's ABNF checker, there are several changes that could be made for clarity: Upper-casify hex (e.g., 2a->2A) [throughout] Combine "Diagnostic-Code" ":" -> ""Diagnostic-Code:" Combine "Localized-Diagnostic" ":" -> ""Localized-Diagnostic:" Combine "Failure" ":" -> "Failure:" Combine "Warning" ":" -> "Warning:" More importantly, the specification makes use of the =/ operator from RFC 5234, but for constructs that it does not control. I don't know if this was the original intent or not, but I am a little concerned that use of =/ in a construct that is not wholly controlled by a single specification is asking for confusion later. This is an optional specification, right? Finally, in the beginning of the document you discuss whether or not to create a new registration, and indicate that the working group chose not to create a new registration. I can easily imagine good reasoning for this, but perhaps you might elaborate in descriptive language the nature of the choice and why you chose one way rather than the other, especially in light of what may seem like a contrary decision in 5336bis. Regards, Eliot
- [apps-discuss] Review of draft-ietf-eai-rfc5337bi… Eliot Lear
- Re: [apps-discuss] Review of draft-ietf-eai-rfc53… Eliot Lear
- Re: [apps-discuss] Review of draft-ietf-eai-rfc53… Dave CROCKER
- Re: [apps-discuss] Review of draft-ietf-eai-rfc53… Lyndon Nerenberg (VE6BBM/VE7TFX)
- Re: [apps-discuss] Review of draft-ietf-eai-rfc53… Eliot Lear
- Re: [apps-discuss] [apps-review] Review of draft-… Dave CROCKER