W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: RIP: Crypto-Key header field

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>
Message-ID: <249e067b-7c37-9aa2-2937-2bfbbebd033b@gmx.de>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 23 November 2016 06:15:44 UTC