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

["Murray S. Kucherawy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Alexey Melnikov
> Sent: Saturday, September 17, 2011 8:48 AM
> To: [e-mail]
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt
> 
> 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

Fixed.

> 
>    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.

How about (pasting directly from the XML source):

     <t> 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
         constraints on use of multipart/report in contexts where
         such are needed. </t>

> 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".

Works for me.  I just copied the text from the original here, but this change seems fine.

> 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.

Fixed.

-MSK