Re: Content-Disposition next steps

Hi Maciej,

thanks for forwarding.

On 13.12.2010 10:06, Maciej Stachowiak wrote:
> Here are some comments from my colleague Alexey Proskuryakov on your
> proposal. I know these may have been outpaced by the considerable
> discussion since that point, but they still seem like they could be useful.
>
>> I only know about file name decoding - all parsing is of course in
>> CFNetwork, and most logic is in Launch Services, I think.
>>
>> Adam's proposal is a step forward in that it acknowledges the need to
>> process raw non-ASCII bytes in filename, which is the only encoding

That's incorrect in that the base spec already says it's ISO-8859-1 
(although this may be hard to find in the published specs as opposed to 
the Internet Draft we're discussing).

(maybe this is a case where Alexey looked at an old proposal?)

>> style that matters. He also describes the proper algorithm,
>> acknowledging that Chrome doesn't fully implement it. Unsurprisingly,
>> that part was met with resistance from the "we always told you it was
>> ISO-8859-1" crowd.
>>
>> I agree that RFC2047 style encoding shouldn't be supported, and I'm
>> ambivalent about RFC5987. RFC2231/5987 is a step in the wrong
>> direction (opaque encoding for something that doesn't need it), but
>> given that IETF won't cease pushing it, we might as well implement it
>> and be more compatible with Firefox, if not the Web.
>>
>> - WBR, Alexey Proskuryakov

In a perfect world we could declare that the HTTP header encoding is 
UTF-8. But it isn't.

If we *tried* to change the default encoding just for C-D/filename, we 
will still break existing code.

So I'm not sure what the "doesn't need it" refers to.

Best regards, Julian

Received on Monday, 13 December 2010 09:29:02 UTC