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.Received on Monday, 28 October 2013 21:13:41 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:38 UTC