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

From: "John Levine" <[email-masked]>
Date: 1 Sep 2011 14:31:04 -0000

Assuming we all agree that the rule requiring multipart/report at
the top level of a DSN goes in in other places, it looks fine to me.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Sep 2011 10:56:29 -0700

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Thursday, September 01, 2011 7:31 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-00.txt
> 

Right, and I think Tony said he'd crack open DSN and NDN if they needed to be updated to reflect this.  (But then I seem to recall looking at them and, to my surprise, finding that they already said what's needed.)

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 1 Sep 2011 21:45:17 +0200

On 30 August 2011 20:52, Barry Leiba wrote:

> For convenience, a link to the document is here:
>   http://tools.ietf.org/html/draft-ietf-appsawg-rfc3462bis

Thanks.  IMO the announce bot should be updated to offer this
popular link in addition to the official link.  What would it
take to arrange this?

> Let's see if we can make that date by getting reviews in now.

Editorial nit section 2: s/BCP 14/RFC 2119/, a new BCP 14
could be different, and RFC 2119 suggests to write RFC 2119.

I like the original "content-type" better than the perfectly
correct "media type", because it indicates the Content-Type
header field.

The draft follows the philosophy that any "may" (etc.) MUST
be either upgraded to MAY or replaced by "might" (or similar).
While I consider this line of thinking as patent nonsense, in
this draft the outcome is fine.  Because I don't believe in
this odd philosophy I won't tell you where I saw a surviving
lower case "should" ;-)

Maybe s/return path/return-path/ in the last paragraph of
section 3.  This could also go to a new "i18n considerations"
with a pointer to the EAI work:  The assumption that at least
the header is 7-bit clean is not more strictly true.  EAI is
out of scope, but nevertheless the 7-bit header assumption is
now far less clear than in 2003.

Section 4: s/this memo/rfcxxxx/  I forgot the xml2rfc magic
word for "this RFC", but if "this memo" ends up literally in
an IANA registry it makes no sense.  I do not trust that the
RFC editor or the IANA get such subtle details right.  Ditto
in section 3.

Section 4 encoding:  Do you really want "mail headers" here,
or should this be "mail header fields"?

Please replace "the header contains all header fields" by
"the header consists of header fields", and add a reference
to [MAIL] (RFC 5322) section 3.5.  Notably "the first blank
line" does not always terminate the header, if readers think
that "blank" includes WSP* CRLF.  It's a terminology question,
maybe s/blank/empty/ would be clearer.

References:  Nothing in [OLD-REPORT] is normative, because the
draft will replace and obsolete it.  In [OLD-REPORT] [DSN] and
[DRPT] were normative, I fail to see why these references are
demoted:  Please move both [DSN-FORMAT] and [DSN-SMTP] back to
normative.

Please add a section explaining the differences from RFC 3462
intended to be kept in the full Internet Standard.  I guess
that the existing document history is not intended to be kept,

Please add the required "downref" warning for all references
on standards track, same idea as for YAM 4409bis.  And please
inform the document shepherd that a publication as Internet
Standard is hereby "requested", or something :-)

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Sep 2011 14:51:55 -0700

Hi Frank,

> From: Frank Ellermann [mailto:[email-masked]]
> Sent: Thursday, September 01, 2011 12:45 PM
> To: Barry Leiba
> Cc: Murray S. Kucherawy; [email-masked]

The RFC Editor will update the references if they change between now and when this actually gets published. This is pretty standard boilerplate.

> this odd philosophy I won't tell you where I saw a surviving

There are two, actually.  I changed one to "needs to" and left the other.

> now far less clear than in 2003.

I'm not really sure we need to say more than what's already there.  This text looks fine with or without EAI being applied.  Does anyone else with good EAI fu have a comment here?

> RFC editor or the IANA get such subtle details right.  Ditto

The RFC Editor typically makes that change during the run-up to AUTH48.  I've used both the [RFCXXXX] and [this memo] notation before, so I'll change it to the latter.

> or should this be "mail header fields"?

I think it's correct as-is (and unchanged since RFC3462).

> maybe s/blank/empty/ would be clearer.

This text is copied verbatim from RFC3462 and there's been no complaint that this is unclear and no errata posted.  What do others think?

> demoted:  Please move both [DSN-FORMAT] and [DSN-SMTP] back to

I disagree. You don't need to read and understand DSN-FORMAT and DSN-SMTP to implement this specification.  Thus, they're not normative here.

> that the existing document history is not intended to be kept,

Such sections are typically deleted before publication anyway.

The current Introduction section spells out the differences.  Really, there's only one.

> Standard is hereby "requested", or something :-)

Such warnings typically go in the PROTO writeup, not in the document itself, as I understand it.

-MSK

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 2 Sep 2011 01:49:16 +0200

On 1 September 2011 23:51, Murray S. Kucherawy wrote:

Hi,

 [2119bis]

> The RFC Editor will update the references if they change
> between now and when this actually gets published. This is
> pretty standard boilerplate.

The problem isn't a new 2119bis published before 3462bis, but
a new BCP 14 published after 3462bis with incompatible terms.

The standard boilerplate (as specified in 2119) says "2119",
and with a fresh existing 2119bis I-D all I can say is "there
be dragons".  If you like a fight with dragons it's okay, you
have been warned.

 [i18n/EAI]
> I'm not really sure we need to say more than what's already
> there.  This text looks fine with or without EAI being applied.

What's not more fine is its silent message header = US-ASCII
assumption, and switching this paragraph into an i18n section
with an informative EAI WG reference could help readers, who
are not yet aware of it.  I certainly don't insist on it, it's
just what I would try to warn readers, and besides I like the
BCP 18 (IETF charset policy) rule about "i18n considerations".

 [obs-FWS]

> This text is copied verbatim from RFC3462 and there's been no
> complaint that this is unclear and no errata posted.

The "blank line" business is copied verbatim, and the <obs-FWS>
issue is addressed in RFC 5234 and RFC 5322 among many others.

Would "empty" be clearer than "blank"?  I don't trust that my
"DEnglish" means anything for others, but I'm sure about some
<obs-FWS> issues discovered long after RFC 3462 was published.

The "header contains all header fields" is not a verbatim copy,
and it sounds odd, because it contains nothing else, but that
could be again a bad case of "DEnglish" on my side.  Whatever
this paragraph tries to say, the real specification including
warts such as <CFWS> and <obs-FWS> is in RFC 5322 section 3.5
(and more), and it is *not* as simple as RFC 3462 puts it.

 [Xref]
> You don't need to read and understand DSN-FORMAT and DSN-SMTP
> to implement this specification.  Thus, they're not normative
> here.

ACK, maybe RFC 3462 got this wrong when it replaced *all* old
RFC 1892 "references" by new RFC 3462 "normative references" -
the complete lack of "informative references" is suspicious.

 [diff]
> Really, there's only one.

ACK.  And very necessary, for starters it must be possible to
send an abusive multipart/report within a multipart/report.

> document itself, as I understand it.

NAK, there are two procedures, one old and horrible, and the new
and painless RFC 4897 procedure.  For an application of the new
procedure compare:
<http://tools.ietf.org/html/draft-ietf-yam-rfc4409bis-02#appendix-B>

Otherwise I'd say next stop WG LC followed by PubReq,

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Sep 2011 17:03:02 -0700

> Sent: Thursday, September 01, 2011 4:49 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Ah, I see what you mean.  I'll take that out.

> The "header contains all header fields" is not a verbatim copy,

RFC3462:
   The Text/RFC822-Headers body part should contain all the RFC822
   header lines from the message which caused the report.  The RFC822
   headers include all lines prior to the blank line in the message.
   They include the MIME-Version and MIME Content-Headers.

This one:
   The text/rfc822-headers body part SHOULD contain all the mail header
   fields from the message that caused the report.  The header includes
   all header fields prior to the first blank line in the message.  They
   include the MIME-Version and MIME content description fields.

There's a slight update to use the current preferred language (header fields instead of header lines, for example), but it's otherwise the same.

The first paragraph of the same section makes a specific reference to RFC5322 (as "[MAIL]").

I'm happy to make a change if it actually clarifies something, but if there isn't evidence that people are confused by the current text then I'd prefer to keep further text changes to a minimum.

> <http://tools.ietf.org/html/draft-ietf-yam-rfc4409bis-02#appendix-B>

I guess the co-chairs or the ADs should weigh in on which of these they prefer.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 2 Sep 2011 04:23:50 -0000

>I'm not really sure we need to say more than what's already there.
>This text looks fine with or without EAI being applied.  Does anyone
>else with good EAI fu have a comment here?

The EAI group has this reasonably well under control.  There's a draft
that updates the DSN spec, and adds new EAI mime types message/global,
message/global-headers, message/global-delivery-status, and
message/global-disposition-notification.

See draft-ietf-eai-rfc5337bis-dsn-03.txt 

Note that EAI no longer is making any attempt to be backward
compatible to systems that can't handle 8BITMIME, so you don't have to
worry about it.

Dunno what the schedule is for the DSN draft, since it hasn't gotten
much attention lately.  Tony Hansen is the primary author so you can
ask him if you're wondering.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Sep 2011 13:25:36 -0700

RFC3462 is currently DS.  There's some question as to whether or not this revision qualifies to remain at DS, or forces a recycle at PS.

The only material change is the removal of a constraint.  On the face of it, it would seem that this doesn't disqualify it from remaining at DS.  In addition, Ned has said that many implementations ignore the constraint, so it's harmless to remove it.   (Ned, could you elucidate on this in support of one position or the other?)

On the other hand, absent specific data about whether or not this change might break anything, it might be more correct to do a turn back at PS until we get some feedback (or, perhaps, the absence of it).

So, this is a point we need to discuss.

Discussion?

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Fri, 2 Sep 2011 16:36:12 -0400

> RFC3462 is currently DS.  There's some question as to whether or not
> this revision qualifies to remain at DS, or forces a recycle at PS.

Chair comment:
The decision about the ultimate status of the document will be made by
the IESG, but input from the working group is important.  I'd like to
hear from people either way: if you think this change is acceptable to
make in a Draft Standard document, please say; if you think this
change requires us to move the document back to Proposed Standard,
please say.  If you think we can't decide this without more
discussion, testing, research, or whatever, please say that as well,
and specify what you think needs to be done.

Barry, document shepherd

---

From: Ned Freed <[email-masked]>
Date: Fri, 02 Sep 2011 14:01:10 -0700 (PDT)

> RFC3462 is currently DS.  There's some question as to whether or not this
> revision qualifies to remain at DS, or forces a recycle at PS.

Why not try for recycle at DS and see what the IESG says?

> The only material change is the removal of a constraint.  On the face of it,
> it would seem that this doesn't disqualify it from remaining at DS.

In general that's not true - removal of a constraint that would affect
implementations generating the format in some way is something I would
see as requiring a reset to proposed.

But since this doesn't affect the associated direct uses of multipart/report -
the constraint is not removed for them - it's difficult to argue that this has
any effect on the usage described in original DSN/MDN specifications. It does
affect new uses of multipart/report for other purposes, but that's fine.

> In addition, Ned has said that many implementations ignore the constraint, so
> it's harmless to remove it.   (Ned, could you elucidate on this in support of
> one position or the other?)

AFAIK in practice nobody ever tried to prevent *indirect* uses of
multipart/report in places other than top-level, e.g., no MUA I'm aware of
will, when incorporating a DSN/MDN as part of a forwarded message, digest, or
whatever, change the media type to avoid violating this constraint, it seems
that implementations have already had to deal with it and haven't had any
problems.

But really, I don't see why we should wring our hands over this. Let's make the
change and ask for a recycle at draft, possibly asking for small exception in
order to relax the constraint without a reset. Make sure this is mentioned in
the last call - let's please not repeat *that* mistake. And if there are no
objections and the IESG goes along, fine, and if not, it gets reset to proposed
and we advance it without republising in exactly six months. I mean, it's not
like we have to do the interop thing over again in this case.

> On the other hand, absent specific data about whether or not this change
> might break anything, it might be more correct to do a turn back at PS until we
> get some feedback (or, perhaps, the absence of it).

Why not let the powers-that-be make this call? That's why they get the big
bucks ;-)

				Ned

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 3 Sep 2011 00:34:27 +0200

On 2 September 2011 22:36, Barry Leiba wrote:

> The decision about the ultimate status of the document will be
> made by the IESG, but input from the working group is important.

The draft should be in a form allowing them to pick STD.  IMO the
decision can be only PS (incompatible change) or STD (some minor
resctriction removed).  What would be a plausible reason for DS ?

-Frank

---

From: Ned Freed <[email-masked]>
Date: Fri, 02 Sep 2011 16:31:04 -0700 (PDT)

> resctriction removed).  What would be a plausible reason for DS ?

AFAICT the argument to move to full standard has not been made, and I for one
am a bit uncomfortable with removing a restriction during such a move.
Remember: draft is about interoperability, where a case can be made that this
change is harmless, full is about deployment, and that's harder to justify.

So I don't really support a move to full, and a recycle at proposed seems
unnecessary.  Ergo, recycle at draft.

				Ned

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 3 Sep 2011 02:11:32 +0200

On 3 September 2011 01:31, Ned Freed wrote:

> AFAICT the argument to move to full standard has not been made

Well, I tried some days ago.  The interoperability reports for DS
are rather old, but at least they do not mention "multipart/report
not at the top level" issues:

<http://www.ietf.org/iesg/implementation/report-rfc1891-1894.txt>

> full is about deployment, and that's harder to justify.

If all these "significant" and "successful" in RFC 2026 4.1.3 are
to be interpreted as "e.g., 4409bis", then I'd have no idea how
to demonstrate a similar significance or success of RFC 3462...

...for 4409bis I could at least produce "significant" amounts of
messages posted by me, or the "successful" publication of a BCP
formerly known as draft-hutzler-spamops.

Maybe you don't like "three steps" because you interpret RFC 2026
4.1.3 more strictly.  I consider the "third step" as last chance
to fix errata and polish a good DS before it's seriously time to
start something new and better at PS (e.g., 282?, 532?, 532?bis).

-Frank

---

From: Ned Freed <[email-masked]>
Date: Fri, 02 Sep 2011 18:20:58 -0700 (PDT)

> start something new and better at PS (e.g., 282?, 532?, 532?bis).

Frank, I honestly don't have a clue what you're driving at in any of this. I
was directly asked to give my opinion about whether a recycle at proposed or at
draft made more sense for this document and I responded. That's it.

All this stuff about moving to full standard seems to have come entirely from
left field, so unless some others step up and say they support attempting such
a move - which given the recent 4409bis experience I'd say has less than
snowball's chance in hell of being successful - I really don't see any point in
continuing this discussion.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Sat, 3 Sep 2011 08:44:06 -0400

> continuing this discussion.

I agree.  If we hear a bunch of other opinions that say we should use
this as an opportunity to advance 3462 to full Standard, I will
consider putting it to the IESG that way.  Otherwise, the goal is to
revise 3462 in place, as Draft Standard.

So let's continue: reviews, comments, and responses to the question of
whether 3462bis has to go back to PS or not.

Barry, document shepherd

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 04 Sep 2011 20:05:22 +0100

>Why not try for recycle at DS and see what the IESG says?
For such a small issue I don't see much problems with recycling at DS, 
especially if there is evidence that the restriction being removed is 
not obeyed in non DSN contexts.

>the last call - let's please not repeat *that* mistake.
>
Good point.

>And if there are no

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Sep 2011 06:12:53 -0700

> see as requiring a reset to proposed.

It might not be obvious why merely removing a restriction should be considered 
that risky.

An example that comes to mind is having a specification that calls for use of 
ASCII and then removing the 'restriction' on using the 8th bit, to permit 
support for UTF-8.

That would certainly kill interoperability between UTF-8 senders and ASCII 
(legacy) receivers.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 08 Sep 2011 17:35:34 +0300

Sorry for late response..

I actually think that removal of the requirement which is hardly useful 
should not be a constraint for advancing the document as Full Standard.  
If somebody feels that such constrain is useful, and it is really 
useful, then removing it requires recycling as PS.  However, with a 
constructive change being done, this isn't a problem.

Mykyta Yevstifeyev

02.09.2011 23:25, Murray S. Kucherawy wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 08 Sep 2011 18:11:26 +0300

This draft, Section 3 says:

>     Required parameters:  boundary, report-type

Is the "report-type" parameter values tracked somewhere?  Is there an 
IANA registry for this parameter, or is it going to be created?

Mykyta Yevstifeyev

30.08.2011 7:18, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF.
>
> 	Title           : The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages
> 	Author(s)       : Murray S. Kucherawy
> 	Filename        : draft-ietf-appsawg-rfc3462bis-00.txt
> 	Pages           : 13
> 	Date            : 2011-08-29
>
>     The multipart/report Multipurpose Internet Mail Extensions (MIME)
>     media type is a general&quot;family&quot; or&quot;container&quot; type for electronic
>     mail reports of any kind.  Although this memo defines only the use of
>     the multipart/report media type with respect to delivery status
>     reports, mail processing programs will benefit if a single media type
>     is used for all kinds of reports.
>
>     This memo obsoletes RFC3462.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3462bis-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-rfc3462bis-00.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Sep 2011 09:23:12 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mykyta Yevstifeyev
> Sent: Thursday, September 08, 2011 8:11 AM

The document says: "The report-type parameter ... is the MIME sub-type of the second body part of the multipart/report."  Since MIME types are registered, the report-type value is always a value in that registry, so no new registry is needed.

---

From: Ned Freed <[email-masked]>
Date: Thu, 08 Sep 2011 10:06:16 -0700 (PDT)

> The document says: "The report-type parameter ... is the MIME sub-type of the
> second body part of the multipart/report."  Since MIME types are registered,
> the report-type value is always a value in that registry, so no new registry is
> needed.

However, the fact that a given media subtype is suitable for use as report-type
value needs to be noted in the registration. Perhaps a note to this effect
is in order in this document.

BTW, there's no need for an additional field for this. We can just note it
under intended usage.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Sep 2011 14:14:07 -0700

After consulting with Ned off-list, I've added a new section right above the IANA Considerations that reads thus (pardon the XML):

        <section anchor="new_reports" title="Registering New Report Types">
                <t> Registration of new media types for the purpose of
                    creating a new report format SHOULD note in the Intended
                    Usage section of the media type registration that the type
                    being registered is suitable for use as a report-type
                    in the context of this specification. </t>
        </section>

Support or concerns?

-MSK

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Sep 2011 12:37:45 -0400

On Aug 30, 2011, at 2:25 PM, Murray S. Kucherawy wrote:

>> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
>> Sent: Monday, August 29, 2011 9:19 PM
>> To: [email-masked]
>> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc3462bis-
>> 00.txt
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Applications Area Working
>> Group Working Group of the IETF.
>> 
> This is a straight conversion from the individual submission, which contained what I think was the consensus from the Quebec City meeting plus some list discussion afterwards.  Review please (especially Ned and Keith!).

I'm not happy with the current draft.  I would prefer that it say something about use of multipart/report when generating DSNs and MDNs.

I am in agreement that multipart/report should potentially be able to appear anywhere.  e.g. it should be possible to forward a message containing a multipart/report, and it should be possible for that forwarded message to fail to be delivered and be included in its entirety in a DSN.

Keith

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Sep 2011 09:57:56 -0700

> From: Keith Moore [mailto:[email-masked]]
> Sent: Wednesday, September 14, 2011 9:38 AM
> To: Murray S. Kucherawy
> I'm not happy with the current draft.  I would prefer that it say
> something about use of multipart/report when generating DSNs and MDNs.

I think the discussion I've heard so far is satisfied with the fact that the DSN and MDN drafts repeat the "top-most" requirement, so there's no need to assert it here as well (making it a requirement for those and all future uses of multipart/report, which is exactly what MARF does not want).

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Sep 2011 13:09:03 -0400

> I think the discussion I've heard so far is satisfied with the fact that the DSN and MDN drafts repeat the "top-most" requirement, so there's no need to assert it here as well (making it a requirem…

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.

Keith

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Sep 2011 13:19:49 -0400

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

Barry, document shepherd

---

From: Ned Freed <[email-masked]>
Date: Wed, 14 Sep 2011 11:40:53 -0700 (PDT)

> the ADs on 22 September.  So final comments, please, by the end of 21

Ship it!

				Ned

---

From: Pete Resnick <[email-masked]>
Date: Fri, 16 Sep 2011 14:48:38 -0500

On 9/4/11 2:05 PM, Alexey Melnikov wrote:
>>> this

I had intended to reply to this last week but it got lost in the shuffle:

"Try not. Do or Do not. There is no try." :-)

Speaking as the AD who's going to bring this to the IESG, I say: Let's 
have the WG *tell* the IESG what the interoperability implication of 
this is and *tell* the IESG what is appropriate. That is, the IESG is in 
no better position (and likely a worse one) than the WG participants to 
judge whether this change affects interoperability of the protocol. If 
you all say, "This restriction has not been implemented in any 
significant way, and for future work interoperability will be helped by 
removing the restriction", that justifies recycling at DS. If you all 
say, "We know of some implementations that will barf on this change and 
therefore we should probably have a bit to see how this deploys", that 
justifies PS.

> not obeyed in non DSN contexts.

Speaking for myself, I agree.

My current read of the list is that the WG feels that the restriction 
has not been significantly implemented and that DS is appropriate, but I 
will will leave it to the chair to make that call and leave it to the 
document shepherd to convey that in the writeup.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 17 Sep 2011 16:48:13 +0100

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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 17 Sep 2011 18:52:14 +0300

17.09.2011 18:48, Alexey Melnikov wrote:
> media type, or more specifically how long it would take one to find 
> them all?).

As registration guidelines for MIME types are "Expert Review" I also 
don't think such constraint is useful here.

Mykyta

---

From: Ned Freed <[email-masked]>
Date: Sat, 17 Sep 2011 09:56:14 -0700 (PDT)

> don't think such constraint is useful here.

+1

				Ned

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 17 Sep 2011 23:15:04 +0200

Make that +2, only looking at the diff turns out to be a
bad idea again and again, at some point in time I should
know that.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 18 Sep 2011 22:55:45 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Saturday, September 17, 2011 8:48 AM

Fixed.

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

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

> need to read and understand RFC 3462 in order to understand and implement

Fixed.

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Sep 2011 12:41:50 +0100

Hi Murray,

Murray S. Kucherawy wrote:
 [...]

>         constraints on use of multipart/report in contexts where
Works for me.

>Works for me.  I just copied the text from the original here, but this change seems fine.
Ok. I hope other WG participants have no objections to this change.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 19 Sep 2011 16:07:07 +0300

>>         constraints on use of multipart/report in contexts where

I don't think other documents might "update" this one.  I think 
"complement" is OK here.

Mykyta

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 21 Sep 2011 16:25:47 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Wednesday, September 14, 2011 10:20 AM

Hey, that's today!

Want the -01 posted tonight then?

-MSK