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

From: S Moonesamy <[email-masked]>
Date: Wed, 14 Sep 2011 02:22:46 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-review