- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 13 Dec 2010 15:13:28 +0100
- 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