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

RE: Questions about ALPN

From: Andrei Popov <Andrei.Popov@microsoft.com>
Date: Mon, 28 Oct 2013 20:51:39 +0000
To: Alexey Melnikov <alexey.melnikov@isode.com>, Martin Thomson <martin.thomson@gmail.com>
CC: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <e268c651fabf453a86a9b0608d615d59@BL2PR03MB194.namprd03.prod.outlook.com>
The ALPN draft currently defines protocol IDs as opaque octet strings, so the hash idea would work just great with the current ALPN draft.



-----Original Message-----
From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] 
Sent: Monday, October 28, 2013 10:52 AM
To: Martin Thomson
Cc: Joseph Salowey (jsalowey); Andrei Popov; ietf-http-wg@w3.org
Subject: Re: Questions about ALPN

On 28/10/2013 17:29, Martin Thomson wrote:
> On 28 October 2013 04:32, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
>> So I would also like to see use cases for UTF-8 data which is not US-ASCII.
> How about a use case that is neither ASCII nor UTF-8?
> There was concern raised about the overall size of the option when 
> there are multiple strings in the set.  Aside from changing from 
> 16-bit lengths to 8-bit lengths (something I'd prefer, but am not 
> going to jump up and down over), the following was suggested.
> >From any set of strings, you can create another string that acts as a
> stand-in for all of the set.  That string is the output of a hash of 
> some canonical form of the input set (maybe sort, encode, hash).
I am not yet sure about the hash idea yet, but if this is something that needs to be supported, then it is either binary or can be hex- or base64 encoded (and then it is ASCII). Either way, the binary case needs to have some text in the ALPN draft.

Received on Monday, 28 October 2013 20:52:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC