- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 23 Dec 2016 11:36:59 -0500
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, 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 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?). > > Anyway, here is my current thinking: > > a) Remove the UTF8 option > ------------------------- > > Having UTF8 as an option for the H1 serialization is unlikely to > significantly increase the number of paths on which you can use it. > > The subset where it will work, will be the same subset with or without > our blessing: End-to-End fully confined and controlled paths. > > > b) Add BCP137's recommendation unchanged (%x5C.75.27 4*6HEXDIG %x27) > -------------------------------------------------------------------- > > A number of alternatives have been proposed, but I do not think the > relatively minor increase in HPACK and H1 afficiency they offer > warrants "needlessly multiplying entities"[2]. > > > Absent really convincing arguments, that will be my next edit. > > Poul-Henning > > > [1] "Almost circular" is a lot more complex than most people imagine. > Highly recommended reading: http://press.princeton.edu/titles/8624.html > > [2] Occams Razor. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Mark Nottingham https://www.mnot.net/
Received on Friday, 23 December 2016 16:37:25 UTC