Subject: Re: Questions about ALPN

From: Andrei Popov <[email-masked]>
Date: Fri, 18 Oct 2013 18:12:20 +0000

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?

Cheers,

Andrei

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 19 Oct 2013 15:49:41 +1300

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

---

From: Andrei Popov <[email-masked]>
Date: Mon, 21 Oct 2013 23:48:39 +0000

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:[email-masked]] 
Sent: Friday, October 18, 2013 7:50 PM
To: [email-masked]
Subject: Re: Questions about ALPN

> 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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2013 20:07:20 -0700

>       Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1")

Presumably, SPDY/1 doesn't exist in any real-world implementation,
since it was never deployed.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 21 Oct 2013 20:49:18 -0700

correct.
-=R

---

From: Andrei Popov <[email-masked]>
Date: Tue, 22 Oct 2013 18:02:29 +0000

If folks feel strongly about removing SPDY/1 from the list of initial registrations, I don't mind making this change.

Cheers,

Andrei

From: Roberto Peon [mailto:[email-masked]]
Sent: Monday, October 21, 2013 8:49 PM
To: Martin Thomson
Cc: Andrei Popov; Amos Jeffries; [email-masked]
Subject: Re: Questions about ALPN

correct.
-=R

On Mon, Oct 21, 2013 at 8:07 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 24 Oct 2013 02:29:53 +1300

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

https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#http.version 
clearly states the octets for the protocol name (HTTP-name) are 
%x48.54.54.50.
RFC 2068 and 2616 are not quite so loud about it, the BNF definition is 
written in upper case ("HTTP" "/" ...) and only permit lower-case to 
match against the upper-case definition. In practice the implementations 
use upper-case.

"http/1.1" is a malformed version for RFC 2608/2616 HTTP-version, 
existing only within the fluffy BNF tolerant interpretation. That 
tolerance is in the process of being removed from the HTTP/1.1 
specifications as the draft linked above shows.

When the registries containing HTTP version name token are considered 
ALPN is clearly the odd one out.

I would suggest that it is far easier for the few existing ALPN 
implementations to update themselves (already having demonstrated high 
speed of rollout) with a new draft or even RFC formal version in a 
backward-compatible way than it will be to get uncounted numbers of HTTP 
implementations to add duplicate parsing code for accepting the ALPN 
lower-case token. Or possibly causing them to violate the updated HTTP 
specification in the process if they choose to re-implement existing 
parser code case-insensitive.

Amos

---

From: Andrei Popov <[email-masked]>
Date: Wed, 23 Oct 2013 22:25:41 +0000

I totally agree that the name of the HTTP protocol is all uppercase, and this is how this protocol is named in the ALPN protocol IDs registry:
"Protocol: HTTP/1.1".

ALPN protocol IDs, on the other hand, are opaque octet strings, not intended for display to the user, not required to consist of printable characters, not required to match names of protocols. E.g. 0x01 could be a valid ALPN protocol ID.

In the early days of ALPN, a combination of printable characters happened to be chosen as the protocol ID for HTTP/1.1:
"Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")".

The use of printable characters has some advantages (sometimes makes network capture analysis easier) and disadvantages (may result in more bytes on the wire). We may now wish that a different protocol ID had been chosen, we may even register alternative protocol IDs for HTTP/1.1. However, an interoperable implementation will have to keep sending the old protocol ID for years to come. Based on this, I believe that registering alternative protocol IDs for HTTP/1.1 will create more confusion and inefficiency than keeping the current (possibly imperfect) protocol ID.

Cheers,

Andrei

-----Original Message-----
From: Amos Jeffries [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 6:30 AM
To: [email-masked]
Subject: Re: Questions about ALPN

https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#http.version
clearly states the octets for the protocol name (HTTP-name) are %x48.54.54.50.
RFC 2068 and 2616 are not quite so loud about it, the BNF definition is written in upper case ("HTTP" "/" ...) and only permit lower-case to match against the upper-case definition. In practice the implementations use upper-case.

"http/1.1" is a malformed version for RFC 2608/2616 HTTP-version, existing only within the fluffy BNF tolerant interpretation. That tolerance is in the process of being removed from the HTTP/1.1 specifications as the draft linked above shows.

When the registries containing HTTP version name token are considered ALPN is clearly the odd one out.

I would suggest that it is far easier for the few existing ALPN implementations to update themselves (already having demonstrated high speed of rollout) with a new draft or even RFC formal version in a backward-compatible way than it will be to get uncounted numbers of HTTP implementations to add duplicate parsing code for accepting the ALPN lower-case token. Or possibly causing them to violate the updated HTTP specification in the process if they choose to re-implement existing parser code case-insensitive.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 25 Oct 2013 05:50:57 +1300

> ALPN protocol IDs, on the other hand, are opaque octet strings, not intended for display to the user, not required to consist of printable characters, not required to match names of protocols. E.g.…

Than please make it opaque and not something that to the human eye reads 
like a invalid protocol token from the IANA protocol registry.

> "Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")".

"early days" wow. All of 12 months ago.

Which consultation process made that decision BTW?
* it does not appear to have included the official HTTP protocol HTTPbis 
working group.
* neither does it seems to have involved anyone from IANA, since they 
would likely have pointed you at the official registry of standardized 
protocol names http://www.ietf.org/assignments/service-names/ - this is 
THE list of protocols.

> The use of printable characters has some advantages (sometimes makes network capture analysis easier) and disadvantages (may result in more bytes on the wire).

Are you trying to say "HTTP" are not equally printable characters to the 
ones chosen, without sounding like an idiot?

>   We may now wish that a different protocol ID had been chosen, we may even register alternative protocol IDs for HTTP/1.1. However, an interoperable implementation will have to keep sending the old protocol ID for years to come.

Completely wrong. Handle the old specifiers from experimental ALPN draft 
implementers as you would future undefined or unsupported protocol tags, 
and upgrade the implementations to conform to whatever ALPN documents 
becomes an RFC.

You are going to have to do that anyway. Yet seem to be treating this as 
if Draft status means the document is set in stone. If the 
implementations can't handle changes they are already broken.

>   Based on this, I believe that registering alternative protocol IDs for HTTP/1.1 will create more confusion and inefficiency than keeping the current (possibly imperfect) protocol ID.

... and that is exacty what is being doing with this new lower-cased 
protocol name which differs from how things have been done for 20 years 
or more.

Amos