On Nov 9, 2010, at 12:12 PM, Ned Freed wrote:
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.
I probably agree with that.
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.
I don't know how to evaluate that statement. I am certainly aware of
implementations of MIME that use statically allocated buffers for decoding
base64, for instance. Though it's certainly possible to write a decoder that
doesn't work that way, this is easier in some languages than others. We didn't
specify MIME that way specifically because we didn't want to make
implementation overly difficult for those using languages without automatic
garbage collection; nor did we want to invite subtle bugs resulting from naive
implementation. Though not allowing nested encodings has been "unhelpful" in
some ways, on balance I don't know how to say whether in hindsight it's been a
bad idea. But we made the decision for valid reasons, and I haven't seen
anything so "unhelpful" as to convince me that we were totally off base there.
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'm always dubious of arguments of the form "if you can't prove that this
breaks something that's working now, assume that it doesn't break anything".
What we know from long experience is that the set of mail handling programs is
large and that their behavior is diverse. I don't think it's reasonable to try
to determine what will break by experimentation, certainly not by exhaustive
survey. And I think we have an obligation to not break things that were
written to conform to earlier standards, at least not without a very good
reason.
On the other hand, I don't know that I have ever bought the idea that something
that does forwarding is expected to re-encode any multiparts just to make sure
that there are no nested content-transfer encodings. I've always been more of
the opinion that the message portion of a multipart/report (or any
message/rfc822 bodypart) should be treated as an opaque object - not something
that should automatically be presented on receipt or re-encoded when forwarded.
So I think that maybe we didn't specify the behavior of multipart in general
or multipart/report in particular as well as we might have. The goal was to
not require MUAs to have to decode multiple layers of c-t-e. What we did was
to insist that there never be multiple layers of c-t-e, which (given forwarded
messages) never was workable. Whether we can reasonably change that now is a
different question.
Keith