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

Alexey Melnikov <> Sat, 17 September 2011 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 209EA21F8A69 for <>; Sat, 17 Sep 2011 08:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.512
X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0TdMHNTiyfnj for <>; Sat, 17 Sep 2011 08:45:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4C45F21F8A67 for <>; Sat, 17 Sep 2011 08:45:35 -0700 (PDT)
Received: from [] ( []) by (submission channel) via TCP with ESMTPA id <>; Sat, 17 Sep 2011 16:47:51 +0100
Message-ID: <>
Date: Sat, 17 Sep 2011 16:48:13 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
References: <> <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Sep 2011 15:45:36 -0000

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
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 
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 
I suggest replacing with "registered" or "registered with IANA".

7.1.  Normative References

              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.