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: Thu, 24 Nov 2016 07:20:53 +0100
To: Martin Thomson <martin.thomson@gmail.com>, Martin J. Dürst <duerst@it.aoyama.ac.jp>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <23699f01-1a0f-1b2f-edcd-c21dbce4d5a8@gmx.de>
On 2016-11-24 00:27, Martin Thomson wrote:
> On 23 November 2016 at 18:51, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
>>> I see lot of additional works and potential bugs by allowing non-UTF-8
>>> octet sequences, and something like zero advantages.
>> Yes indeed. Not knowing what character encoding is used for a string, or not
>> knowing whether something is binary or text, it a lot of pain, and no
>> "virtue" at all. We have a lot of experience with that; let's not repeat
>> these same mistakes over and over again.
> This presumes that the field is a string.  We already have a use for
> it that treats it as an octet sequence.  If someone cares to designate


> a usage that needs strings, then UTF-8 is available to them.

Which implies that those who define the use of dictionaries and the way 
they are transmitted have full control over what keyids are used. Is 
this the case?

Best regards, Julian
Received on Thursday, 24 November 2016 06:21:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 24 November 2016 06:21:37 UTC