Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt

[Alexey Melnikov <[e-mail]>]

Barry Leiba wrote:

>>Ok.  I won't make an issue about this.   I agree that the DSN and MDN
>>RFCs is the right place to put these restrictions.
>>    
>>
>
>I think with this, and with the other comments and reviews so far,
>this version is ready to have a last call in the working group.  Let's
>give it another week for comments, and say that I will send this to
>the ADs on 22 September.  So final comments, please, by the end of 21
>September.
>
I think the document is well written and worth progressing. Some 
specific comments below:

1.  Introduction

   Practical experience has shown that the general requirement of having
   that media type constrained to be used only as the outermost MIME
   type of a message, while well-intentioned, has provided little
   operational benefit and actually limits such things as the
   transmission of multiple administrative reports within a single
   overall message container.  In particular, it prevents one from
   forwarding a report as part of another mulipart MIME message.

typo: multipart

   This memo removes that constraint.  No other changes apart from some
   editorial ones are made.  Other memos might update other documents to
   establish or clarify the constraint where it is more appropriate.

I suggest changing "constraints" to "constraints on use of 
multipart/report", as otherwise this is not very clear.

3.  The multipart/report Media Type

   1.  [REQUIRED] The first body part contains a human readable message.
       The purpose of this message is to provide an easily understood
       description of the condition(s) that caused the report to be
       generated, for a human reader who may not have a user agent
       capable of interpreting the second section of the multipart/
       report.  The text in the first section may be in any MIME
       standards-track media type, charset, or language.

Is "standards-track" really intended here? This seems both overly 
restrictive
and not well specified (where can one find the list of *all* standards-track
media type, or more specifically how long it would take one to find them 
all?).
I suggest replacing with "registered" or "registered with IANA".


7.1.  Normative References

   [OLD-REPORT]
              Vaudreuil, G., "The Multipart/Report Content Type for the
              Reporting of Mail System Administrative Messages",
              RFC 3462, January 2003.

This reference is Informative as far as I can see. That is there is no
need to read and understand RFC 3462 in order to understand and implement
this document.