- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 23 Dec 2016 18:19:18 +0100
- To: Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>, Matthew Kerwin <matthew@kerwin.net.au>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP working group mailing list <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@varnish-cache.org>
On 2016-12-23 17:36, Mark Nottingham wrote: > >> On 23 Dec. 2016, at 11:13 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> >> -------- >> In message <C8F21FA8-8B03-4E9C-B0E8-CD3C9CF028CE@mnot.net>, Mark Nottingham wri >> tes: >> >>> And, as discussed previously, there aren't a lot of use cases for >>> non-ASCII header values in standards (because few have a payload that's >>> exposed to end users), so the reward for taking that risk is >>> questionable. >> >> But isn't that an almost circular[1] argument, when there is no >> safe standardized way to put non-ASCII into header values in the >> first place ? > > There is -- RFC5987 encoding. Not pretty or efficient, but implemented and interoperable. Used in Content-Disposition, Link (although not much), and not much else AFAIK (Julian?). It's used in the new Digest spec, but I don't believe it's implemented yet. > ... Best regards, Julian
Received on Friday, 23 December 2016 17:21:03 UTC