- From: Andrei Popov <Andrei.Popov@microsoft.com>
- Date: Mon, 21 Oct 2013 23:48:39 +0000
- To: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi Amos, The ALPN draft currently specifies the following initial set of registrations: Protocol: HTTP/1.1 Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1") Protocol: SPDY/1 Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1") Protocol: SPDY/2 Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2") Protocol: SPDY/3 Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3") These protocol IDs are currently used in a number of deployed implementations, so they would have to be preserved even if their upper-case versions were also registered. To avoid confusion, I would recommend against registering upper-case versions of these protocol IDs. Thanks, Andrei -----Original Message----- From: Amos Jeffries [mailto:squid3@treenet.co.nz] Sent: Friday, October 18, 2013 7:50 PM To: ietf-http-wg@w3.org Subject: Re: Questions about ALPN On 19/10/2013 7:12 a.m., Andrei Popov wrote: > > Hi Mark, > > SPDY and HTTP/1.1 protocol IDs are defined in the ALPN draft so that > ALPN can be immediately used to negotiate the same protocols as NPN. > We had originally defined an HTTP/2 protocol ID as well, but removed > it from the latest versions of the draft so that the HTTPbis WG can > specify the appropriate protocol ID(s). > > ALPN protocol IDs are defined as opaque non-empty octet strings, which > allows for a compact representation of a large number of IDs. This > does not prevent the HTTPbis WG from defining US-ASCII or UTF-8 > protocol IDs for use on the Web. Do you have concerns about the > representation of protocol IDs in ALPN? > In addition to the worry about ALPN draft defining any there is the issue of case-sensitivity for the ones it does list. When I last read the draf it most definitely did NOT specify SPDY and HTTP/1.1 - it did specify some non-existent spdy/* and http/1.1 tokens. Has that been corrected? Amos
Received on Monday, 21 October 2013 23:49:09 UTC