Subject: Our ALPN protocol IDs

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Dec 2013 15:44:29 +1100

Patrick opened <https://github.com/http2/http2-spec/pull/323> a little while back, wherein he suggests we shorten our protocol identifier to just "h2". 

What do people think about this?

Similarly, the ALPN draft registers "HTTP/1.1". Thinking about this, is it appropriate to specify the minor protocol version (which implies compatibility on the wire) in the ALPN identifier?

I.e., should we advise the TLS WG to just make this "HTTP/1" or even just "h1"?

Cheers,

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Dec 2013 09:59:42 +0100

On 05 Dec 2013, at 05:44, Mark Nottingham <[email-masked]> wrote:

> Thinking about this, is it appropriate to specify the minor protocol version (which implies compatibility on the wire) in the ALPN identifier?

So how would the negotiation of the minor version be done?
I don’t see how that is done in HTTP/2.0 (except when upgrading from 1.1).

Maybe it is worth adding a section that explains the protocol evolution model of HTTP/2.0.
(My benchmark case here would be plugging in a different compression scheme for 2.1.)

(If the result of such a discussion is that ALPN is a good way to indicate HTTP/2.1 capability early and upfront, we should plan now for the tokens that the HTTP/2.xes get.)

Grüße, Carsten

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 09:39:45 -0800

> So how would the negotiation of the minor version be done?

For which version(s)?

For HTTP/1.x, the negotiation between HTTP/1.1 and HTTP/1.0 (and 0.9)
uses rules already established.

For HTTP/2.x, the negotiation between HTTP/2.0 and a hypothetical
HTTP/2.1 would use ALPN and "h2" and maybe "h2.1".  Any unique string
would suffice.

> I don’t see how that is done in HTTP/2.0 (except when upgrading from 1.1).

Yes, HTTP/2.0 explicitly doesn't allow version negotiation "within"
the protocol.  We have ALPN and intend to use it ...and nothing else.

> Maybe it is worth adding a section that explains the protocol evolution model of HTTP/2.0.

Like this?

  Any new, incompatible version of HTTP will use a different
identifier string.  For instance, a hypothetical HTTP/2.1 might be
identified by the string "DUCK".

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 09:41:42 -0800

> Thinking about this, is it appropriate to specify the minor protocol version (which implies compatibility on the wire) in the ALPN identifier?

We've talked about this: if we mess with things, new identifiers are
cheap.  Encoding semantics into version identifiers only leads to
pain.  Leave the space opaque.  If we want to specify new compatible
changes to the protocol, we can use a setting or something like that
if indicating its support is crucial.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Dec 2013 18:49:44 +0100

> HTTP/2.1 would use ALPN and "h2" and maybe "h2.1".  Any unique string

Works for me.
(Thinking about how the new identifiers will look like still doesn’t hurt.)

> identified by the string "DUCK”.

Well, is HTTP/2.1 going to be “incompatible” with HTTP/2.0?
(Mark seems to think there is some form of compatibility as long as we don’t change the major version.
That’s why I’d like to see something written up about the evolution model, even if it is by nature going to be tentative.)

Grüße, Carsten

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 10:00:37 -0800

> Well, is HTTP/2.1 going to be “incompatible” with HTTP/2.0?

That's not a question that can be answered without a crystal ball, so
how about I answer a different question.  If HTTP/2.1 turns out to be
incompatible, it will need to be negotiated using a new identifier.
If it turns out to be compatible, then we'll work something out.

I know that sounds a little unsatisfying, but it's the incompatible
changes that hurt, and we have discussed a way to avoid bad stuff from
happening when we need to do that.  Plotting out a path for compatible
changes doesn't really add value.  That said, feel free to propose
something.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Dec 2013 20:07:30 +0100

On 05 Dec 2013, at 19:00, Martin Thomson <[email-masked]> wrote:

> [..] Plotting out a path for compatible

Clearly, if we already knew what needs to be changed, we’d do it now.
So this is preparing for the unknown.  
I don’t agree that spending a few cycles on thinking about this would not add value.
However, it also seems to me that SETTINGS already provides a good way forward for this kind of smooth evolution.
If people share the gut feeling that that’s true, the needed cycles may already have been spent.

The more important thing is actually agreeing that ALPN labels are cheap and this is indeed the way forward for changes that go beyond what can be done with a SETTINGS-like mechanism.  I.e., we assume HTTP/2.x will always be carried in something that provides out-of-band negotiation (and something extra would need to be done for, say, the port 100 idea).

Grüße, Carsten

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 5 Dec 2013 21:26:50 +0100

On Thu, Dec 05, 2013 at 08:07:30PM +0100, Carsten Bormann wrote:
> Clearly, if we already knew what needs to be changed, we?d do it now.

I'd say that if the client supports both 2.0 and 2.1 and wishes to experiment
with a server supporting both versions, then both will advertise h2 and h2.1
(for example), so what needs to be documented is more how to pick the best
version when several ones are compatible between two agents.

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.

Just my two cents,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 13:01:49 -0800

On 5 December 2013 12:26, Willy Tarreau <[email-masked]> wrote:
> so what needs to be documented is more how to pick the best

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.

> 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 :)

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 05 Dec 2013 21:19:30 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>

>the protocol. We have ALPN and intend to use it ...and nothing else.

well.. this presumes we're only going to work inside a TLS framework.

Roll out the mandatory TLS argument again.

I don't think we can rely on only ALPN.

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 05 Dec 2013 21:20:32 +0000

by current definitions of what constitutes minor vs major version 
numbers, 2.1 would be compatible with 2.2.  If it isn't you'll call it 
3.0.

------ Original Message ------
From: "Carsten Bormann" <[email-masked]>
To: "Martin Thomson" <[email-masked]>
Cc: "Mark Nottingham" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 6/12/2013 6:49:44 a.m.
Subject: Re: Our ALPN protocol IDs
>That’s why I’d like to see something written up about the evolution 
>model, even if it is by nature going to be tentative.)
>
>Grüße, Carsten
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 06 Dec 2013 11:35:03 +1300

On 2013-12-06 07:00, Martin Thomson wrote:
> On 5 December 2013 09:49, Carsten Bormann wrote:

If 2.1 turns out to be incompatible at the binary level from 2.0 it 
qualifies for being 3.0 in accordance with the versioning RFC.

Keep in mind that "compatible" with 2.x means only the frame header 
binary pattern (frame type, length, stream ID, flags) and semantics of 
handling unknown frames in 2.0.

So 2.1 may use completely different frame types and payload formatting 
and still be "compatible" enough to qualify for only a minor version 
bump.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 06 Dec 2013 11:42:09 +1300

> So this is preparing for the unknown.

Not necessarily. There are several changes which only make sense in a 
pure-2.0 end-to-end connection. Such as dropping Cookies and converting 
Session Cookie values to a HTTP layer frame header.
We cannot do this at all right now, but can prepare 2.0 extension points 
for defining it in a 2.1 update in 5-20 years time.

> However, it also seems to me that SETTINGS already provides a good way
> forward for this kind of smooth evolution.

+1.

We need to concentrate on making 2.0 more efficient without the 
compression overheads, and work on updating/replacing RFC 2660 with 2.0 
mechanisms.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 14:43:04 -0800

On 5 December 2013 13:20, Adrien de Croy <[email-masked]> wrote:
> by current definitions of what constitutes minor vs major version numbers,
> 2.1 would be compatible with 2.2.  If it isn't you'll call it 3.0.

We lost strong ties to that convention when we dumped the version
field from the protocol.  We can, if we like, choose new conventions
for 2 and onward.

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 05 Dec 2013 23:31:16 +0000

is there no version transmitted anywhere (outside of ALPN).... or are we 
going to rely on ALPN to communicate that?

I'll have a big problem if we're talking about framing everything in TLS 
just so we can use ALPN.

Normal protocol design mandates having a version field somewhere in some 
message.  I've never found in practise this to be unnecessary, and any 
custom protocol I've ever worked with where someone omitted a version 
stamp, has been a nightmare when it comes to making changes.

So if we've truly dropped all version fields from the protocol I would 
strongly urge revisiting that decision.

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Carsten Bormann" <[email-masked]>; "Mark Nottingham" <[email-masked]>; 
"HTTP Working Group" <[email-masked]>
Sent: 6/12/2013 11:43:04 a.m.
Subject: Re: Our ALPN protocol IDs
>>numbers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 6 Dec 2013 11:04:59 +1100

> That’s why I’d like to see something written up about the evolution model, even if it is by nature going to be tentative.)

No - what I'm trying to say is that the notion of a minor version in a protocol like HTTP is a red herring; at most it's a marketing "package" to denote new features. 

If changes are backwards-compatible, there's no need to change the protocol identifier on the wire; if they aren't, it's not a minor revision.

Regards,

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 16:27:17 -0800

> going to rely on ALPN to communicate that?

ALPN carries all the important and relevant version information, yes.

Version information is all carried in the identifier string (currently
"HTTP/2.0").  This same identifier is used in ALPN and Upgrade (and
Alt-Svc and DNS and whatever other places we choose to signal support
of HTTP/2.0).

Note that this is all outside of the protocol, and is always required
to be present, though we acknowledge that the presence of the
identifier might be implicit (as it would be in the port 100
proposal).

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 06 Dec 2013 02:26:50 +0000

right, so if we decide that HTTP/2.0 won't be forced to go over TLS, 
then we can't rely on ALPN even being there.

At that point it would be problematic to assume a mapping between port 
and version.  Much easier and more deterministic to put a version field 
back into (at least) the initial message(s).

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Carsten Bormann" <[email-masked]>; "Mark Nottingham" <[email-masked]>; 
"HTTP Working Group" <[email-masked]>
Sent: 6/12/2013 1:27:17 p.m.
Subject: Re: Our ALPN protocol IDs

---

From: Patrick McManus <[email-masked]>
Date: Thu, 5 Dec 2013 21:36:28 -0500

there is no requirement on which peer sends first, so there really can't be
a handshake even as part of the initial settings and/or magic bits.. an
upgrade of a running session perhaps, but not a negotiation. *PN ftw.

On Thu, Dec 5, 2013 at 9:26 PM, Adrien de Croy <[email-masked]> wrote:

>
> right, so if we decide that HTTP/2.0 won't be forced to go over TLS, then
> we can't rely on ALPN even being there.
>
> At that point it would be problematic to assume a mapping between port and
> version.  Much easier and more deterministic to put a version field back
> into (at least) the initial message(s).
>
> Adrien
>
>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 06 Dec 2013 02:40:19 +0000

I'd still advertise the highest supported version.  The receiver can 
then at least decide what to do.

Any protocol I ever had the misfortune to work with that didn't have a 
version field was a train wreck when it came to extending or changing 
it.

------ Original Message ------
From: "Patrick McManus" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Martin Thomson" <[email-masked]>; "Carsten Bormann" 
<[email-masked]>; "Mark Nottingham" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 6/12/2013 3:36:28 p.m.
Subject: Re: Our ALPN protocol IDs
>there is no requirement on which peer sends first, so there really 
>can't be a handshake even as part of the initial settings and/or magic 
>bits.. an upgrade of a running session perhaps, but not a negotiation. 
>*PN ftw.
>
>
>>and version.  Much easier and more deterministic to put a version 
>>field back into (at least) the initial message(s).
>>
>>Adrien
>>
>>
>>
>>Cc: "Carsten Bormann" <[email-masked]>; "Mark Nottingham" 
>><[email-masked]>; "HTTP Working Group" <[email-masked]>

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 06 Dec 2013 19:05:59 +1300

On 6/12/2013 3:40 p.m., Adrien de Croy wrote:
> version field was a train wreck when it came to extending or changing it.
> 
> 
> 
> 
> From: "Patrick McManus"
>>> At that point it would be problematic to assume a mapping between
>>> port and version.  Much easier and more deterministic to put a
>>> version field back into (at least) the initial message(s).
>>>
>>> Adrien
>>>

We do have the Connection Header magic which is transmitted on all
connections regardless of mechanism used to start the protocol. This
contains the "HTTP/2.0" moniker embeded, so it would seem we do already
have the version transmitted in some form already. It is just not
transmitted per-message like HTTP/1.

** all version 3.0 need do is change the magic

** version 2.x are supposed to be binary capable, so I would think these
are all limited to extensions adding new frames types and mechanism
semantics.

No train wreck or problems there. *provided* we get a clear consensus
and definition of what 2.0 proxies etc is to do with those
unknown/future frame types.

Amos

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 6 Dec 2013 09:55:46 +0100

Le Ven 6 décembre 2013 01:04, Mark Nottingham a écrit :

> If changes are backwards-compatible, there's no need to change the
> protocol identifier on the wire; if they aren't, it's not a minor
> revision.

If you don't advertise minor you give up on adding features in a minor
version. Only knowing the major version means you have to restrict
yourself to using what was available in the .0 version.

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 6 Dec 2013 09:57:35 +0100

> unknown/future frame types.

Security people will ask to drop anything unknown since if it's unknown it
can't be evaluated for malfeasance potential.

-- 
Nicolas Mailhot

---

From: Yoav Nir <[email-masked]>
Date: Fri, 6 Dec 2013 11:14:48 +0200

> can't be evaluated for malfeasance potential.
A firewall proxy would definitely do that. So unless we want to kill 
extensibility, we have two options:
  - New extension frames require an advertised new version that 
firewalls can downgrade if they don't support, or
  - That client and server can live with those frames getting dropped.

Other proxies, like caches that don't evaluate malfeasance can just 
forward unknown frames.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Dec 2013 08:59:50 -0800

>> can't be evaluated for malfeasance potential.

And justifiably so.  If X is known, and Y isn't, there's always the
risk that Y alters the interpretation of X in ways that ultimately
affect security.  That's physics.

>  - New extension frames require an advertised new version that firewalls can
> downgrade if they don't support, or

Probably not.  At that point, you have a whole new protocol anyhow.

>  - That client and server can live with those frames getting dropped.

This is where I think that we were heading.  In the example above,
this means that any unknown Y cannot alter the semantics such that its
absence would be problematic.  This allows the paranoid a license to
drop unknown stuff; but it also limits the scope of the damage if
extensions are passed.

---

From: James Cloos <[email-masked]>
Date: Fri, 06 Dec 2013 19:07:59 -0500

>>>>> "AdC" == Adrien de Croy <[email-masked]> writes:

AdC> is there no version transmitted anywhere (outside of ALPN)....
AdC> or are we going to rely on ALPN to communicate that?

The rfc 2616 Upgrade (as per the current draft for port 80 use) can
specify versions, too.  As an example, a client could ask for:

  Upgrade: HTTP/2.0, HTTP/2.1
  Connection: Upgrade

The 101 Switching Protocols responce will state which token the server
is upgrading to.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 7 Dec 2013 14:53:59 +1100

> yourself to using what was available in the .0 version.

No, it must means you don’t indicate the addition of new features to a linear minor version number — which we don’t (and can’t) use anyway in HTTP/1 (because lots of software already rejects HTTP/1.2 outright).

Deciding not to link new features into a new version != disallowing new features.