Subject: ALPN ID for HTTP/2 interop

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 13 Nov 2014 21:59:13 +0900

Hi,

We've been doing interop using h2-14 ALPN ID for a while.
Some client/server now only advertise h2-15, others do both h2-14 and h2-15.
Since draft-15 is binary compatible to h2-14, for code simplicity and
interop, it would be better to stick to h2-14, unless we introduce binary
incompatible changes in the future draft.

Thoughts?

Current status of ALPN ID usage:
Firefox nightly: h2-14, h2-15
Chrome canary: h2-15
Google server: h2-15
Twitter: h2-14
nghttp2: h2-14

Best regards,
Tatsuhiro Tsujikawa

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 14 Nov 2014 03:21:00 +1300

On 14/11/2014 1:59 a.m., Tatsuhiro Tsujikawa wrote:
> Hi,
> 
> We've been doing interop using h2-14 ALPN ID for a while. Some
> client/server now only advertise h2-15, others do both h2-14 and
> h2-15. Since draft-15 is binary compatible to h2-14, for code
> simplicity and interop, it would be better to stick to h2-14,
> unless we introduce binary incompatible changes in the future
> draft.
> 
> Thoughts?

That would be non-compliance with both draft h2-14 and h2-15.

Even if h2-15 bytes look identical to h2-14 they may cause different
things to happen in the recipient than you are expecting from an h2-14
recipient. Advertising the latest version is also a statement that you
are going to try and comply with the WG latest interpretation of
behaviour as much as what bytes format you can send/receive.

Amos

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 13 Nov 2014 14:45:47 +0000

On 14/11/2014 1:59 a.m., Tatsuhiro Tsujikawa wrote:
> simplicity and interop, it would be better to stick to h2-14, unless 
> we introduce binary incompatible changes in the future draft.
> 
> Thoughts?

This has affected work I have been performing in the last week, principally between Chrome Canary and nghttp2 (but presumably any client/server combo would be susceptible).

I tend to agree with Amos, in general behavioural differences between versions could lead to interop issues. Being strict with advertising support for what is truly implemented builds greater confidence  "in-band".

In cases where software is capable of supporting multiple versions, can that not be supported in the ALPN negotiation? In the h2-14/h2-15 case, if the differences truly are minimal the branching complexity within the software is minimal.

---

From: Moto Ishizawa <[email-masked]>
Date: Thu, 13 Nov 2014 23:52:24 +0900

+1
I think that advertising the both of h2-14 and h2-15 is better.

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 13 Nov 2014 17:55:21 -0800

The next version of the Chrome Canary (which should come out tomorrow) will
support both h2-14 and h2-15.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Nov 2014 17:14:09 -1000

Note that we have *not* nominated -15 as an implementation / interop draft.

People who are advertising it are doing so at their own risk...

Regards,

> On 13 Nov 2014, at 2:59 am, Tatsuhiro Tsujikawa <[email-masked]> wrote:
> 
> Hi,
> 
> Since draft-15 is binary compatible to h2-14, for code simplicity and interop, it would be better to stick to h2-14, unless we introduce binary incompatible changes in the future draft.
> 
> Thoughts?
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 14 Nov 2014 21:27:48 +0900

> People who are advertising it are doing so at their own risk...

So the rule is clear: in order to join the current global interop,​
implementations must negotiate h2-14 since it is the last draft designated
as implementation.

This clears my immediate concern about interop issue.

Best regards,
Tatsuhiro Tsujikawa

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 19 Nov 2014 18:27:49 +1100

Dang,  wish I had read the WG this morning before work.... have just
updated jetty-9.3.S to support protocol aliases, so our current impl is
recognised as both h2-14 and h2-15.  Our client only sends h2-14

Oh well, the alias mechanism will probably be handy when we go from h2-16
to h2

cheers

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.