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

[Dave CROCKER <[e-mail]>]

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