W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: Content-Disposition next steps

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 13 Dec 2010 15:13:28 +0100
Message-ID: <4D062A08.4070503@gmx.de>
To: Maciej Stachowiak <mjs@apple.com>
CC: Adam Barth <ietf@adambarth.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Hi there,

..trying to do some cherry-picking...:

On 13.12.2010 10:06, Maciej Stachowiak wrote:
> ...
>> 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.
 > ...

RFC 2047 encoding is currently only done in Firefox (for which I raised 
a bug report a few months ago) and Chrome. For the latter I just raised 
<http://code.google.com/p/chromium/issues/detail?id=66694>; maybe we can 
make some progress on getting rid of this.

Also, RFC 2231/5987 encoding has the interesting property that it can 
handle all the cases where currently interop isn't there (I18N, and 
handling of % and \). If the Safari team is willing to implement this as 
well, we may want to consider changing the RFC 5987 support requirement 
from "SHOULD" to "MUST", in which case we could recommend using it for 
these cases (where most of the remaining disagreement comes from).

That wouldn't help for IE, but at least for all non-IE browsers there'd 
be a reliable way to get these characters over the wire.

Best regards, Julian
Received on Monday, 13 December 2010 14:14:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC