- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 23 Dec 2016 16:13:29 +0000
- To: Mark Nottingham <mnot@mnot.net>
- 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>
-------- 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 ? 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.
Received on Friday, 23 December 2016 16:14:00 UTC