[apps-review] Review of -- draft-ietf-appsawg-rfc3462bis-00

Dave CROCKER <dhc@dcrocker.net> Thu, 08 September 2011 13:03 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-review@ietfa.amsl.com
Delivered-To: apps-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0111021F8B36 for <apps-review@ietfa.amsl.com>; Thu, 8 Sep 2011 06:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level:
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 1guboKuc-wph for <apps-review@ietfa.amsl.com>; Thu, 8 Sep 2011 06:03:41 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5169C21F8AF4 for <apps-review@ietf.org>; Thu, 8 Sep 2011 06:03:41 -0700 (PDT)
Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p88D5RDx011450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 06:05:33 -0700
Message-ID: <4E68BD97.8050601@dcrocker.net>
Date: Thu, 08 Sep 2011 06:05:27 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Murray Kucherawy <msk@cloudmark.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 08 Sep 2011 06:05:33 -0700 (PDT)
Cc: Apps Review <apps-review@ietf.org>
Subject: [apps-review] Review of -- draft-ietf-appsawg-rfc3462bis-00
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Apps Area Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2011 13:03:42 -0000

I've been asked to do an appsarea review of this draft.


Review:

Title:        The Multipart/Report Media Type for the Reporting of Mail System
               Administrative Messages
               draft-ietf-appsawg-rfc3462bis-00

Reviewer:     D. Crocker
Review Date:  8 Sept 11


Summary:

    Multipart/Report is an established format for sending reports.  It is 
defined as a MIME media type, motivated by the need to have a standardized 
format for sending email handling reports.  (After the end of an SMTP transfer 
session, the receiving server still might need to report back to the author or 
originator.  It must send this in an independent email.  This media type 
provides a standardized means of packaging and identifying such reports.)   The 
draft promises a set of minor, non-normative document cleanup changes, and one 
significant normative change, that of removing a restriction on use of the media 
type.

    This change permits the media type to be nested within a MIME structure, 
rather than being limited to the top level.  The restriction was motivated by 
the original, primary usage scenario for email reporting, but has proved 
problematic for other scenarios, including something as simple as forwarding a 
received report(!)


Major Issues:

    None.

    In pedagogical terms, the need for this change demonstrates the important 
difference between documenting a usage restriction that applies only to a 
particular scenario, versus imposing an inherent restriction to the underlying 
data type.  Confusing the two limits utility of the data type.  (Formally, the 
confusion here was between the "packaging" of the data type and the scenario 
usage of the data type.)



Minor Issues:

    Appendix A (Document History) needs a note to the RFC Editor to remove the 
section before publishing.



Nits:

    The document repairs non-normative usage of normative vocabulary, to 
eliminate confusion.  It also changes normative vocabulary to be upper case, to 
aid detection.  However it appears that some of these changes were missed:


 > 3. The multipart/report Media Type
...
 > generated, for a human reader who may not have a user agent

may -> might


 > report.  The text in the first section may be in any MIME

may -> MAY   {{ I believe. /d }}


 > details not present in the first body part that may be useful to

may -> might


 > Return of content may be wasteful of network bandwidth and a variety

may -> can


 > 4. The text/rfc822-headers Media Type
...
 > to make them legal 7-bit content, they may be encoded with quoted-

may -> MAY


 > 6. Security Considerations
...
 > reports may cause the sender to incorrectly believe a message was

may -> can


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net