Re: New Version Notification for draft-kucherawy-rfc3462bis-00

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 t
 hat 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 work
 able.  Whether we can reasonably change that now is a different question.

Keith