FWIW, I'm strongly opposed to such a change, as it breaks backward
compatibility.
If this really is a serious interoperability issue (and I doubt very much it
is) then perhaps the thing to do is place the restriction in the specific
instances of multipart/report defined thus far. It's unnecessary to restrict
all future use of multipart/report. It's also pointless, since all it will do
is result in the definition of another report container without the
restriction, which is messy and ugly.
Indeed, every single one of these restrictions we thought would be helpful for
MIME implementors (e.g., encoding restrictions on message) has in hindsight
turned out to be both unhelpful and a bad idea. You'd think we'd learn
eventually, but no.
Oh, and I'd buy that this is a real interop issue if you can name some MUA
implemenations which when forwarduing using message/rfc822 encapsulation check
to see if the message being forwarded contains a multipart/report and do
something to correct that "invalid" nesting. (Exactly what it should do is a
little unclear.)
I for one get nested multipart/reports all the time, because people have a
question about a report the natural thing for them to do is forward it.
Ned