W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Our ALPN protocol IDs

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 5 Dec 2013 13:01:49 -0800
Message-ID: <CABkgnnWHrJzBGKzJCsTXHo7OaVEeXZw_4Z9mJyCQU-DGbn+BUQ@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Carsten Bormann <cabo@tzi.org>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 5 December 2013 12:26, Willy Tarreau <w@1wt.eu> wrote:
> so what needs to be documented is more how to pick the best
> version when several ones are compatible between two agents.

That's inherent in ALPN at least: the server picks the option that
suits it best.  The same goes for Upgrade.  Alt-Svc/Alternate-Protocol
let the client pick, unless that means encountering ALPN or Upgrade on
the way there.  The main thing is, all mechanisms will unambiguously
select just one protocol stack.

> I don't see why it would be useful to insist on pretending to be 2.0 when
> connecting to a 2.0 and at the same time expect 2.1 to be transported if
> you can't gain any benefit from this. I even fear that we could reintroduce
> the 1.0/1.1 issues that proxies had to suffer about for decades by doing so.

That's a reasonable point, and I think one that others expressed too.
The amount of flexibility we allow within a single negotiation
protocol version is something we're still discussing.  Some want
basically zero flexibility (I tend to favour this, but not strongly).
Others understandably want to be able to experiment within the
envelope allowed by the protocol.  For HTTP/2.0, that's currently a
very narrow envelope.  That might change if we do something like
http://tools.ietf.org/html/draft-bishop-http2-extension-frames-00
(though I understand that even the author of this draft doesn't really
like this idea any more :)
Received on Thursday, 5 December 2013 21:02:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC