RE: Questions about ALPN

Except that, as I understand the proposal Martin is referring to, it's a single hash of the (multiple) protocol IDs you support.  It very substantially changes ALPN's matching model, or at the very least adds a second layer.

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

The ALPN draft currently defines protocol IDs as opaque octet strings, so the hash idea would work just great with the current ALPN draft.

Cheers,

Andrei

-----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.