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, 21 Oct 2013 23:48:39 +0000
To: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <7f1b097e458d4cff9b34c96c02628e1c@BL2PR03MB194.namprd03.prod.outlook.com>
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 [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?

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

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