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.
Given the EAI experiment, it now appears that this isn't as difficult for
people to get right as we thought.
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.
Given the restrictions it places on security enclosures, I have a hard time
seeing the effect as other than bad.
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".
That's not the argument. The argument is that if there was something out there
that depended on reports appearing at the top level to display them properly,
agents that generate reports not at the top level would have come under
pressure to correct their behavior. But despite the HUGE population of such
agents - pretty much every MUA of any sophistication that's been written can
and does generate nested reports because it doesn't check the subtype when it
forwards a multipart message - nobody seems to care.
Perhaps this is more a function of there not being any special support for
processing reports out there than anything else, but regardless, I think
it's pretty convincing.
I'll also point out that an agent whose report processing is restricted to
top-level reports is not free to error or misbehave when they receive a nested
report. MIME compliance places clear requirements on the handling of multiparts
that don't go away when the subtype isn't recognized. So at most you're going
to get a suboptimal display of a nested report as multipart/mixed. Any other
breakage is clearly not in conformance to RFC 2049.
Of course there are other sorts of reporting processing than displaying them,
such as automatic unsubscription of recipients from mailing list. In such cases
I'm not entirely sure I want them processing reports not at the top level,
restriction or no restriction.
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.
But we have in effect already done the experiment.
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.
THat assumes they were actually written, and that the misbehavior is serious
enough to care about. I'm don't believe either condition applies in the case of
the restriction of reports to the top level.
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.
This is a tough one. The reason it's tough is that there are two cases, both of
which are forbidden but both of which are seen in practice:
(1) The specified CTE is actually present on the nested message or multipart.
(2) The header specifying the CTE is present, but the part isn't actually
encoded.
I saw a fair amount of (1) right after MIME came out. Then (2) started showing
up, and if my experience is in any way typical, cases of (2) currently
outnumber (1) by a factor of 20 or more. But EAI is going to make (1) legal in
some cases, so the pendulum may end up swinging back the other way.
All that said, I don't see how this is relevant to the issue of allowing nested
reports. A proper report is going to have any CTE on the leaf nodes only. If
it's on a non-leaf node, you have (currently) invalid MIME and a problem
that transcends the subtype of multipart you happen to be using.
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.
We certainly intended for this to be a viable approach.
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.
I don't see why. AFAIK nobody is saying the design is unworkable, only that
in hindsight the restriction had a lot more cost and a lot less benefit
than we thought.
Whether we can reasonably change that now is a
different question.
AFAIK the report proposal isn't talking about allowing nested CTEs, only
nested reports.
Ned