I can understand why you don't want to change the MIME spec at this point.
However, I consider any MIME implementation that does not make all of the
header fields available to MIME processing to be broken by design,
regardless
We could debate that point. Wee could even note that broken
behavior is not exactly new to the email world (how DOES it EVER work???)
In the current case we have good indication that there is a substantial
installed base that behaves in this way and that I believe we won't get
away with jerking them around unless we go through IETF formal hoops. Such
hoops can be jumped through but the basic requirement is that there be
massively big benefit for the massively big pain that will ensue. Hard to
believe that the current issue qualifies.
Dave is absolutely right here. Now, Roy may argue that there's an existing
installed base of HTTP out there, and it deserves consideration too. And I have
no problem with this whatsoever -- if we have to bend the rules to accomodate a
few specific exceptions to the rules because of an installed base that got
deployed before the inconsistency was discovered, then fine, we'll bend them
for that. But this doesn't mean that the rule has to go. It doesn't and
shouldn't. And the specifications should be fixed to at a minimum point out
that this is a special, one-time thing.
But the matter currently at hand is a completely new field. There is no
installed base for it at all. And it is far from clear that we even
want this to be a separate field, regardless of what we call it -- the
arguments for at least some of this being placed in content-disposition field
parameters seemed pretty reasonable to me. I would like to get more feedback on
whether people think this needs to be a separate field or needs to be part of
the content-disposition information.
Ned