RE: Questions about ALPN

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.



-----Original Message-----
From: Amos Jeffries [] 
Sent: Friday, October 18, 2013 7:50 PM
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?


Received on Monday, 21 October 2013 23:49:09 UTC