[apps-discuss] Fwd: Review of -- draft-ietf-appsawg-rfc3462bis-00

S Moonesamy <sm+ietf@elandsys.com> Wed, 14 September 2011 09:20 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 45A9821F8C95 for <apps-discuss@ietfa.amsl.com>; Wed, 14 Sep 2011 02:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level:
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 bsWBU+FSxZPQ for <apps-discuss@ietfa.amsl.com>; Wed, 14 Sep 2011 02:20:51 -0700 (PDT)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id AD54421F8C61 for <apps-discuss@ietf.org>; Wed, 14 Sep 2011 02:20:51 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.235.20]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8E9Mrpn022760 for <apps-discuss@ietf.org>; Wed, 14 Sep 2011 02:22:59 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315992180; bh=W2yZRwwgZB3uEuvEJDQhap7PzWU=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=y6DdeGJ4GChXk+9MvpmiU/eWTTrlSeX/Tfz/kRD1uxS2jXiH1gupOi1qEr/DoIRWy VGgeygYPyyW82p4bgURyggJLfCkDCz/Vj6gUJjjhBQMvXZR8RrcFDLP18DB220xKTj hV4TfSEbPpTq9NQIAequ7enUG6+qe00WirL+/ryE=
Message-Id: <6.2.5.6.2.20110914022059.09f04af0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 14 Sep 2011 02:22:46 -0700
To: apps-discuss@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [apps-discuss] Fwd: Review of -- draft-ietf-appsawg-rfc3462bis-00
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: Wed, 14 Sep 2011 09:20:54 -0000

I am forwarding the review performed by Dave Crocker.

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
_______________________________________________
apps-review mailing list
apps-review@ietf.org
https://www.ietf.org/mailman/listinfo/apps-review