Re: RIP: Crypto-Key header field

On 2016-11-23 01:47, Martin Thomson wrote:
> On 22 November 2016 at 19:28, Julian Reschke <> 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