> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.