Re: Unicode escape sequence | Re: draft-ietf-httpbis-header-structure-00, unicode range

In message <>, Mark Nottingham wri

>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 

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.


[1] "Almost circular" is a lot more complex than most people imagine.
Highly recommended reading:

[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