> On 20/Jul/11 16:18, S Moonesamy wrote:
> > I'll include some of the discussion about updating multipart/report
> > that was brought up by Murray Kucherawy [6]. Ned Freed has no opinion
> > about the venue for the work [7]. John Klensin suggested a focused
> > review discussion and get out a document that
> > updates the base MIME specification if someone has the motivation and
> > time to invest in such an effort [8]. Ned Freed would like to see
> > such changes lifted in separate documents [9]. Murray Kucherawy
> > raised a concern about such an approach as it leaves two versions of
> > multipart/report around [10]. He also stated that he is in favor of a
> > charter that allows the following:
> >
> > "However the WG might reach consensus that certain changes have to be
> > done in order to remove restrictions which were proven to be problematic
> > in the field, or which restrict evolution of the protocols."
> >
> > Please read the above as a rough summary. As usual, if your comments
> > are misinterpreted, post a message to the mailing list.
> FWIW, my opinion on this is that no changes are needed: Since RFC
> 3462 says
> When used to send a report, the Multipart/Report content-type must
> be the top-level MIME content type for any report message
> it obviously implies that the Multipart/Report content-type can also
> be used to send something else, possibly not at top level.
The problem is the term "report" here is too general - any multipart/report
object is in some sense a "report" - it's what the name implies.
In fact because of this the sentence as written really doesn't pass muster in
terms of clarity. It's obviously trying to talk about some subset of
multipart/report usage, but then it muddies things up by using terms that
don't really define a proper subset.
> I think
> that the "report" mentioned there is what Ned called an "active" DSN
> or MDN. He also pointed out that's how the top-level requirement was
> understood by application designers. Hence, clarifications for any
> obscure sentence are not modifications of the protocol, and could be
> filed as errata of the relevant DSs.
Now that's an interesting idea. I agree that implementors seem to have
interpreted this correctly, so maybe we could treat it as an errata.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
