- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 23 Nov 2016 07:15:02 +0100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 2016-11-23 01:47, Martin Thomson wrote: > On 22 November 2016 at 19:28, Julian Reschke <julian.reschke@gmx.de> wrote: >> 1) The way "keyid" is currently specified makes it an octet sequence, that >> may or may not be valid UTF-8 and could even include NUL. Is that really the >> intention? We've seen the consequences of this with ALPN identifiers, which >> required us to define a funky escaping mechanism in alt-svc, so we could put >> them into places that take strings. This not only affects related specs, but >> also APIs for code that handles encryption encoding (such as: what's the >> datatype for the key in dictionaries?) > > The virtue of this is that a particular profile can define this field > as it chooses, to meet its own requirements. If you intend to use > this with strings, then you can constrain to ASCII or UTF-8 as you see > fit. > ... I see lot of additional works and potential bugs by allowing non-UTF-8 octet sequences, and something like zero advantages. Best regards, Julian
Received on Wednesday, 23 November 2016 06:15:37 UTC