Subject: [TLS] Questions about ALPN

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2014 11:54:03 -0400

[Disclaimer: I'm new here - I just subscribed to this list so that I 
could discuss this point. So don't assume I have much context.]

I've been seeing suggestions here and there recently to use ALPN as a 
registry of protocols for various purposes. So I went looking to find 
out what that was. And I found draft-friedl-tls-applayerprotoneg. IIUC 
this is *the* authoritative definition of ALPN.

 From the friedl draft I understand its use in the context of TLS. I 
would like to understand if the *intended* scope of applicability is 
broader, and if so, what it is.

For instance, the draft doesn't mention DTLS. But I have found 
discussion elsewhere that says it is intended to be used for DTLS. I do 
understand that DTLS and TLS are closely related, and apparently it is 
intended that both will share the same Next Protocol Negotiation 
mechanism. And that means that each will need a registry of protocol 
names that may be used within this negotiation.

OTOH, it is far from clear that the *same* registry should be used for 
both TLS and DTLS. The two transports have significantly different 
characteristics, so that many application protocols will only work over 
one or the other. (Or if they work over both, they might arguably be 
*different* protocol variants.)

And what about using the ALPN registry for protocols that run on top of 
transports other that TLS and DTLS? Is that appropriate?

IMO at the very least the IANA Considerations section of this draft 
should be beefed up as follows:

- Specify the policy IANA is to use for deciding whether to accept
   a new registration in the ALPN registry. (You can't define a new
   registry without this.)

- Specify clearly the information that is to appear in the ALPN
   registry. IMO, in addition to the name this needs to include
   *at least* the transport protocol(s) over which the application
   layer protocol is valid.

- Specify the transport layer protocols that are valid transports
   of ALPN protocols.

- Specify the acceptable syntax of ALPN names

- Specify guidelines for when it is appropriate to add a new protocol
   to the ALPN registry. (E.g., when it is intended to be used in
   NPN negotiation in TLS and DTLS.)

Without some clarity here I fear that people will be tempted to use this 
registry for registering names of arbitrary protocols that run over 
arbitrary other protocols. (E.g., as an alternative to the IANA registry 
of SDP "proto" values.)

	Thanks,
	Paul

---

From: Adam Langley <[email-masked]>
Date: Wed, 9 Apr 2014 09:04:07 -0700

On Wed, Apr 9, 2014 at 8:54 AM, Paul Kyzivat <[email-masked]> wrote:
> For instance, the draft doesn't mention DTLS. But I have found discussion
> elsewhere that says it is intended to be used for DTLS.

Yes, it applies to DTLS also, although I don't know anyone use it for such yet.

> OTOH, it is far from clear that the *same* registry should be used for both
> TLS and DTLS. The two transports have significantly different
> characteristics, so that many application protocols will only work over one
> or the other. (Or if they work over both, they might arguably be *different*
> protocol variants.)

I believe there is only one registry. I don't think that there's
danger of ambiguity here. If the connection is DTLS then it's
obviously the DTLS varient of the protocol that should be used.

> transports other that TLS and DTLS? Is that appropriate?

I don't think so.

>   a new registration in the ALPN registry. (You can't define a new

The policy is Expert Review as given in the draft.

>   *at least* the transport protocol(s) over which the application

I don't think this additional bureaucracy is useful. I can't imagine a
situation where this is going to help someone.

> - Specify the transport layer protocols that are valid transports

Mentioning DTLS is something that I think has general agreement for
inclusion in the next revision of the draft.

> - Specify the acceptable syntax of ALPN names

ALPN names are bytestrings, there's no syntax.

>   NPN negotiation in TLS and DTLS.)

I would hope the expert in the Expert Review would notice a request
that was so confused that they were applying for an ALPN string when
not using (D)TLS!

Cheers

AGL

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Apr 2014 09:28:38 -0700

What Adam said, except...

> that was so confused that they were applying for an ALPN string when

Oops:
http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-11.1

Actually, I think that this is a good (re)use of the registry.  Sure,
it doesn't make sense to identify protocols within (D)TLS, but often
non-(D)TLS protocols need to be identified alongside (D)TLS protocols,
as is the case with the above.  (If you are confused about the where
this happens exactly, see
http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-6.11).

---

From: Adam Langley <[email-masked]>
Date: Wed, 9 Apr 2014 09:49:33 -0700

> http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-6.11).

I wouldn't add h2c to the ALPN registry for this case, but I don't
feel strongly.

Cheers

AGL

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2014 12:52:41 -0400

> The policy is Expert Review as given in the draft.

Sorry - I was looking at an old version that didn't have that.

> situation where this is going to help someone.

Doesn't seem like much "bureaucracy" to me.
But the reference to the protocol specification probably is sufficient. 
(That wasn't in the old version I was looking at.)

> inclusion in the next revision of the draft.

Good!

> ALPN names are bytestrings, there's no syntax.

OK. It would be good to instruct IANA on uniqueness constraints.
Clearly the Identification Sequence must be unique. I guess that the 
protocol name should also be unique.

> that was so confused that they were applying for an ALPN string when

Now that I know Expert Review is being used, that helps.

I am a designated expert reviewer for a few IANA registries. And I can 
say from experience that I would like the document that establishes the 
registry to provide guidelines to me about what to look for. This may be 
obvious to the authors. But as time passes it can become less obvious.

	Thanks,
	Paul

---

From: Andrei Popov <[email-masked]>
Date: Wed, 9 Apr 2014 17:29:35 +0000

I'm with Adam on this: ALPN registry is defined under the "Transport Layer Security (TLS)" heading, so adding protocol IDs that will never be negotiated in the course of the (D)TLS handshake to this registry could be confusing.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Wednesday, April 9, 2014 9:50 AM
To: Martin Thomson
Cc: [email-masked]
Subject: Re: [TLS] Questions about ALPN

> http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-6.11).

I wouldn't add h2c to the ALPN registry for this case, but I don't feel strongly.

Cheers

AGL

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Apr 2014 11:03:38 -0700

On 9 April 2014 10:29, Andrei Popov <[email-masked]> wrote:
> ALPN registry is defined under the "Transport Layer Security (TLS)" heading

Maybe we should instead consider whether that is an appropriate
location for the registry.

This is a very interesting property from an application perspective,
I'd certainly be disappointed if this were to be pigeon-holed into a
TLS-only thing.

(I'll point out that I tend to think that most, if not all,
application protocols would benefit from exclusively using TLS.  But
that's not a universally shared view :)

---

From: Andrei Popov <[email-masked]>
Date: Wed, 9 Apr 2014 18:19:16 +0000

The original intent was to create a registry of application protocols negotiable within the (D)TLS handshake, so that applications would know which protocol to speak once the (D)TLS channel is established, and avoid extra round-trips.

If we were to broaden the applicability of this registry beyond (D)TLS, how would you suggest scoping it? Would it be just a general, all-purpose list of application protocol IDs?

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, April 9, 2014 11:04 AM
To: Andrei Popov
Cc: Adam Langley; [email-masked]
Subject: Re: [TLS] Questions about ALPN

> ALPN registry is defined under the "Transport Layer Security (TLS)" 

Maybe we should instead consider whether that is an appropriate location for the registry.

This is a very interesting property from an application perspective, I'd certainly be disappointed if this were to be pigeon-holed into a TLS-only thing.

(I'll point out that I tend to think that most, if not all, application protocols would benefit from exclusively using TLS.  But that's not a universally shared view :)

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Apr 2014 11:37:27 -0700

> If we were to broaden the applicability of this registry beyond (D)TLS, how would you suggest scoping it? Would it be just a general, all-purpose list of application protocol IDs?

That's pretty much it.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2014 14:49:28 -0400

>> If we were to broaden the applicability of this registry beyond (D)TLS, how would you suggest scoping it? Would it be just a general, all-purpose list of application protocol IDs?

What is your definition of "application level protocol"?

I could understand it if it was protocols that are defined to run over 
some common transport, or set of transports with some common 
characteristics. For instance, over reliable, bidirectional, byte stream 
protocols. That would cover TLS, TCP, and possibly some forms of data 
channels, among others. But that would exclude DTLS.

BTW, this could also encompass websocket sub-protocols.

	Thanks,
	Paul

---

From: Andrei Popov <[email-masked]>
Date: Wed, 9 Apr 2014 18:59:20 +0000

If the ALPN registry is scoped to (D)TLS (as it is in the current ALPN draft), then we can say ALPN protocol IDs are for those protocols running within the (D)TLS channel.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, April 9, 2014 11:49 AM
To: [email-masked]
Subject: Re: [TLS] Questions about ALPN

I could understand it if it was protocols that are defined to run over some common transport, or set of transports with some common characteristics. For instance, over reliable, bidirectional, byte stream protocols. That would cover TLS, TCP, and possibly some forms of data channels, among others. But that would exclude DTLS.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2014 15:24:27 -0400

> If the ALPN registry is scoped to (D)TLS (as it is in the current ALPN draft), then we can say ALPN protocol IDs are for those protocols running within the (D)TLS channel.

That would work for me.

But Martin seems to be suggesting going a different way. So that it 
would include things that could run over TCP or TLS. And then if you are 
going to allow DTLS, then why not UDP? Then we can talk about things 
that could run over websockets, and data channels.

But then you have gotten to naming pretty much anything over anything.

IMO there is a choice to be made:

- define this operationally, as things negotiated with NPN

- OR, things that run over a lower layer with a common set of
   characteristics. In this case, either pick a single set
   of characteristics (e.g., reliable, bidirectional, byte stream)
   or define a separate sub-registry for each set of characteristics.

	Thanks,
	Paul

---

From: Andrei Popov <[email-masked]>
Date: Wed, 9 Apr 2014 19:40:22 +0000

My preference is to keep ALPN registry (D)TLS specific, otherwise the requirements for the registry become too nebulous.

Also, IMHO things like "HTTP/2 over TLS" and "HTTP/2 over TCP" aren't IDs of individual protocols because they describe entire stacks of protocols. While there may be uses for such identifiers, I don't think they belong in the ALPN registry.

Cheers,

Andrei

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, April 9, 2014 12:24 PM
To: Andrei Popov; [email-masked]
Subject: Re: [TLS] Questions about ALPN

That would work for me.

But Martin seems to be suggesting going a different way. So that it would include things that could run over TCP or TLS. And then if you are going to allow DTLS, then why not UDP? Then we can talk about things that could run over websockets, and data channels.

	Thanks,
	Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 09 Apr 2014 15:40:56 -0400

> location for the registry.

whether we place the alpn registry under (D)TLS or not, including all
the httpbis labels becomes slightly weird.

if ALPN is *not* just for (D)TLS, then h2 is weird because it seems to
specify not only the inner protocol in question but also the outer
protocol -- what would h2 mean if it was specified in, say, an novel SSH
ALPN-identified channel?  would it be SSH-wrapping-TLS-wrapping-HTTP?
or just SSH-wrapping-HTTP?

if ALPN is just for (D)TLS, then h2c is weird because it is defined to
not be usable in (D)TLS either.

out of curiosity, how is h2c expected to interact with tcpcrypt, (if
that ever gets off the ground) or with IPSEC?  By definition, it's http
over "cleartext TCP".  But TCP over IPSEC is encrypted, as would be
TCPCrypt.  The obvious answer (which is "yeah yeah, it's still h2c,
ignore that your TCP channel itself is encrypted") doesn't line up with
the explicit wording of the draft ("cleartext TCP").  maybe it should
say something like "HTTP directly inside TCP" to head off this
hairsplitting.

regards,

	--dkg

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Apr 2014 13:04:12 -0700

On 9 April 2014 12:40, Andrei Popov <[email-masked]> wrote:
> things like "HTTP/2 over TLS" and "HTTP/2 over TCP" aren't IDs of individual protocols because they describe entire stacks of protocols

A protocol that is layered on another protocol includes all the
properties of that protocol in the same way that I gain all the
advantages (and disadvantages) of a library when I link to it.  But
that protocol presents a new API that completely subsumes the included
protocol.  To the users of that protocol, they see HTTP/2 (over TCP,
over IP, over 1Gb Ethernet, over copper) and that is similar, but
necessarily different to HTTP/2 (over TLS, over TCP, etc...).
Therefore they can - and should - be identified differently.

It might be that we use a single identifier to refer to things that
are, in all the aspects we care about, identical.  That's called
generalization, and it might not always be appropriate.

The idea that X over Y and X over Z might be nice in theory, but it's
rare that this abstraction isn't leaky at some level.  There are cases
that we might not care to distinguish between, particularly below the
IP layer, but even there the effects can be visible.  We just pretend
really hard that we're properly insulated by all those layers.  Better
to call X over Y = X1 and X over Z = X2 and avoid the confusion issue.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 9 Apr 2014 20:23:56 +0000

At the time when the protocol negotiation is being performed via ALPN, the choices between copper and radio, Ethernet and token ring, TCP and UDP, TLS and DTLS have already been made. At the time ALPN negotiation is in progress, it is too late to negotiate lower-level protocols. It makes sense, however, to negotiate higher-level protocols to run within the (D)TLS channel.

This is why I feel that "HTTP/2 over TLS" makes little sense specifically in the context of ALPN, and "HTTP/2 over TCP" makes even less sense in this context. Both of these protocol stack identifiers may be useful outside the context of ALPN, as you correctly explain.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, April 9, 2014 1:04 PM
To: Andrei Popov
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [TLS] Questions about ALPN

On 9 April 2014 12:40, Andrei Popov <[email-masked]> wrote:
> things like "HTTP/2 over TLS" and "HTTP/2 over TCP" aren't IDs of 
> individual protocols because they describe entire stacks of protocols

A protocol that is layered on another protocol includes all the properties of that protocol in the same way that I gain all the advantages (and disadvantages) of a library when I link to it.  But that protocol presents a new API that completely subsumes the included protocol.  To the users of that protocol, they see HTTP/2 (over TCP, over IP, over 1Gb Ethernet, over copper) and that is similar, but necessarily different to HTTP/2 (over TLS, over TCP, etc...).
Therefore they can - and should - be identified differently.

It might be that we use a single identifier to refer to things that are, in all the aspects we care about, identical.  That's called generalization, and it might not always be appropriate.

The idea that X over Y and X over Z might be nice in theory, but it's rare that this abstraction isn't leaky at some level.  There are cases that we might not care to distinguish between, particularly below the IP layer, but even there the effects can be visible.  We just pretend really hard that we're properly insulated by all those layers.  Better to call X over Y = X1 and X over Z = X2 and avoid the confusion issue.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Apr 2014 13:53:50 -0700

> This is why I feel that "HTTP/2 over TLS" makes little sense specifically in the context of ALPN, and "HTTP/2 over TCP" makes even less sense in this context. Both of these protocol stack identifie…

Agreed.

I think that we only disagree on the scope of the registry.  I'll note
that we've consensus in httpbis to use the greater scope, and will
(reluctantly) establish a separate registry if we need to.  We'll
probably put in a non-overlapping + inclusion requirement for the ALPN
registry to avoid issues.  It would be easier for us to just use
ALPN's registry.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 10 Apr 2014 17:31:08 +0000

Well, I feel strongly enough about this to try and explain my position on the mailing list. However, It is much more important to me that ALPN be useful for HTTP/2, so if the "expert review" process approves adding your protocol stack IDs to the ALPN registry, I will not object :)

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, April 9, 2014 1:54 PM
To: Andrei Popov
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [TLS] Questions about ALPN

Agreed.

I think that we only disagree on the scope of the registry.  I'll note that we've consensus in httpbis to use the greater scope, and will
(reluctantly) establish a separate registry if we need to.  We'll probably put in a non-overlapping + inclusion requirement for the ALPN registry to avoid issues.  It would be easier for us to just use ALPN's registry.

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 11 Apr 2014 14:37:25 +0400

Hi,

I believe the registration process should not be tied to ANPL. The simplest
thing is to define a portfolio (in a separated document or in a section in
your document) to define the name of the new protocols.

BTW, in 2007, I have submitted a document on MTLS protocol to multiplex
several application sessions over a single TLS session. I think you didn't
read the draft, but your document is a use-case of it
(see draft-badra-hajjeh-mtls-02). The TLS WG co-chairs (during 2007-2008)
were aware of the document and of the patent as well.

Best regards,
Badra

On Thu, Apr 10, 2014 at 9:31 PM, Andrei Popov <[email-masked]>wrote:

> Well, I feel strongly enough about this to try and explain my position on
> the mailing list. However, It is much more important to me that ALPN be
> useful for HTTP/2, so if the "expert review" process approves adding your
> protocol stack IDs to the ALPN registry, I will not object :)
>
> Cheers,
>
> Andrei
>
> > This is why I feel that "HTTP/2 over TLS" makes little sense
> specifically in the context of ALPN, and "HTTP/2 over TCP" makes even less
> sense in this context. Both of these protocol stack identifiers may be
> useful outside the context of ALPN, as you correctly explain.
>
> Agreed.
>
> (reluctantly) establish a separate registry if we need to.  We'll probably
> put in a non-overlapping + inclusion requirement for the ALPN registry to
> avoid issues.  It would be easier for us to just use ALPN's registry.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Apr 2014 08:43:34 +1000

I can understand how this feels weird from a TLS perspective.

From the application's standpoint, however, it doesn't make sense to have two different spaces for identifiers -- one for all possible protocols / versions / stacks, and one for how they're negotiated over TLS.

If TLS doesn't make this a generic space, we're very likely to see many applications -- not just HTTP -- need to establish registries that duplicate / overlap with ALPN's. 

Cheers,

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

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 14 Apr 2014 16:57:06 -0700

I think the worry is that there is a combinatorial problem when you
try to have identifiers for every possible mixture of protocol and
transport merged into a single number, similar to how cipher suite
numbers are problematic.

Additionally, adding a new low-level transport would break things:
As an example, suppose you already have defined "http/2 over TCP" and
"http/2 over TLS (over TCP)" and all servers recognize these code
points.  Now whoever wants to create "http/2 over HNTP" (hypothetical
new transport protocol) will need to have all http server software
everywhere learn the new code point whether it is aware of HNTP or not,
before http/2 could be used reliably over HNTP.

So instead of making this mistake, I'd like to see a single code point
for application protocol (e.g. http/2) which would be used by TLS in
ALPN and then you can combine that with another code point representing
the transport if you need this level of distinction ("TCP", "SCTP",
"UDP", "TLS over TCP", "DTLS over UDP", etc.).

Mike

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Apr 2014 10:09:48 +1000

> transport merged into a single number, similar to how cipher suite

Yes, that's come up in our discussions a number of times.

I think our intended use of ALPN tokens is a bit different. Ciphersuite agility is about combining a number of different components to get security properties, and as such there are a fairly large number of them.

If we have a large number (i.e., more then a reasonable handful) of ways to negotiate HTTP, on the other hand, we risk an interop failure.

I.e., the negative consequences of a combinatorial explosion are promoting *good* behaviour here.

> before http/2 could be used reliably over HNTP.

Why? 

> "UDP", "TLS over TCP", "DTLS over UDP", etc.).

That would lead people to believe that they can use HTTP over DTLS (for example), which isn't defined and isn't interoperable. Someone would have to go and write the document "how to use HTTP/2 over DTLS", and then we'd need a way to indicate to the peer that this is supported. 

Transport abstractions are "leaky" -- as the shift from HTTP/1 to HTTP/2 has shown, the specifics of the underlying transport matters very much to how we design and use the protocol. We can't define an application protocol in complete isolation from the transport (although we can take steps to make introducing a new transport less painful).

To be very clear -- in HTTPbis, we've decided to use the ALPN token to indicate that a particular stack of protocols is in use, whether or not TLS is in use. If the TLS WG doesn't like that use of their protocol element, OK, but we're likely to start pushing back on TLS defining what an application is and is not, and that's a much larger discussion.

Cheers,

>> If TLS doesn't make this a generic space, we're very likely to see many applications -- not just HTTP -- need to establish registries that duplicate / overlap with ALPN's. Cheers,
>>> From: Martin Thomson [mailto:[email-masked]] Sent: Wednesday, April 9, 2014 1:54 PM
>>> To: Andrei Popov

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 14 Apr 2014 18:02:03 -0700

>> before http/2 could be used reliably over HNTP.

Suppose that "http/2 over TCP" and "http/2 over TLS" are assigned the
code points 23 and 38 respectively (I'm just making up numbers).  A TLS
stack can be programmed to recognize both of these numbers in ALPN as
"http/2" for its purposes.

But then some time later, someone registers "http/2 over HNTP" at code
point 139.  The same TLS stack can not possibly know that protocol 139
in ALPN means http/2 without an upgrade, leading to a failure.

Also you'd then have to define "smtp over HNTP", "ftp over HNTP", etc.
for all applications that could be delivered over HNTP.  Much better to
just register one new transport code point for HNTP and you're done.

> That would lead people to believe that they can use HTTP over DTLS (for
> example), which isn't defined and isn't interoperable. Someone would have
> to go and write the document "how to use HTTP/2 over DTLS", and then we'd
> need a way to indicate to the peer that this is supported.

I'm not saying that every combination needs to make sense.  Keeping the
code point spaces for transport and application separate will require
many fewer registrations and allow for more robust software.

Mike

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Apr 2014 11:01:38 -0700

> in ALPN means http/2 without an upgrade, leading to a failure.

That's exactly the failure we're actually looking for here.  Something changed.

(BTW, it's strings: "h2" for HTTP/2 over TLS, "h2c" for HTTP/2 over TCP)

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 15 Apr 2014 11:58:31 -0700

> That's exactly the failure we're actually looking for here.  Something changed.

Can you please explain why you want things to fail and in what circumstances?

> (BTW, it's strings: "h2" for HTTP/2 over TLS, "h2c" for HTTP/2 over TCP)

Opaque strings are just (large) numbers.  Hopefully you're not suggesting
that the string be inspected for some structure, e.g. it matches a regular
expression such as /^h2/.

Mike

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Apr 2014 12:58:13 -0700

> Can you please explain why you want things to fail and in what

Does HNTP provide an exact replica of the protocol contract that TCP
provides HTTP/2?  If not, I want to know.  If it is exact in all the
ways that matter, might as well use "h2".

> expression such as /^h2/.

No way.  People keep suggesting that the strings become less than
opaque, and we've always fought that off.  I was just providing the
info.

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 15 Apr 2014 15:17:51 -0700

> ways that matter, might as well use "h2".

If you foresee only ever defining "h2" (meaning secure HTTP2 over TLS)
and "h2c" (meaning unsecured HTTP2), then why even mention TCP at all?

I'm fine with the proposal if there will only be two different strings
that lead to HTTP2 and most protocols need only one identifier.

Mike

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Apr 2014 17:22:05 -0700

> and "h2c" (meaning unsecured HTTP2), then why even mention TCP at all?

I have no prescient abilities.  We do know that TCP is what HTTP/2 uses though.

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 15 Apr 2014 18:11:01 -0700

> I have no prescient abilities.  We do know that TCP is what HTTP/2 uses though.

What I'm trying to understand is the need to mention TCP at all since
there is nothing about HTTP (that I'm aware of) which requires TCP
specifically, other than its guarantees of reliability and in-order
delivery, a.k.a. a stream.

Can't we just have "HTTP/2 with TLS" and "HTTP/2 without TLS" and know
that the underlying transport is a stream in both cases (possibly TCP,
possibly something else)?

Mike

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Apr 2014 12:24:40 +1000

> possibly something else)?

This is true in the abstract, but concretely, when I want to connect to <http://example.org/>, I need to know a number of things, including:

* What version of HTTP to use
* What underlying transport it's bound to (TCP, SCTP, QUIC, whatever)
* Whether to use TLS or not (if using TLS for http:// URIs, a.k.a. "opportunistic encryption" takes off)

Previously, these were all obvious, because there weren't any backwards-incompatible versions of HTTP, the only transport used was TCP, and TLS was indicated by HTTPS URIs. 

We're pretty quickly moving into a world where none of these assumptions hold true, so we need a mechanism to denote the specifics to the client. HTTPbis has chosen to use the ALPN identifier to do this, because we need a way of talking about the protocol *stack* in use not only in TLS, but also in "vanilla" HTTP (see the Alternative Services draft), and possibly even in DNS in the future.

Cheers,