Subject: ALPN token to use for first implementation draft

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jul 2017 15:12:37 -0700

The TLS draft implies (though I suppose one could argue) that QUIC should
always negotiate ALPN. The HTTP draft specifies "hq-<version>" but we're not
doing HTTP for the first implementation draft.

We want to get into the habit of using ALPN, so I think we should define
one.
Perhaps "implementation-1"?

-Ekr

---

From: Patrick McManus <[email-masked]>
Date: Mon, 10 Jul 2017 13:17:46 -0400

In the spirit of "doing more than the first implementation requires" (which
is explicitly in scope by 1st implementation), I'll have my client send
ALPN hq-04 and my server select that if offered, but neither end will fail
if its peer doesn't reciprocate.

Remember - hackathon this coming weekend. Jabber is an option!

-P

---

From: Ian Swett <[email-masked]>
Date: Wed, 12 Jul 2017 12:53:36 -0400

I have a slight preference for keeping the draft number in the alpn token,
so I'd lean towards hq-04.

I'm pretty sure the Chromium implementation will support some non-IETF
standard HTTP over QUIC based on the first implementation milestone, so
it's not a complete lie.

On Mon, Jul 10, 2017 at 1:17 PM, Patrick McManus <[email-masked]>
wrote:

> In the spirit of "doing more than the first implementation requires"
> (which is explicitly in scope by 1st implementation), I'll have my client
> send ALPN hq-04 and my server select that if offered, but neither end will
> fail if its peer doesn't reciprocate.
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Jul 2017 09:57:50 -0700

hq-04 sounds good. In that case, I think we should move towards being
strict about it, though, assuming we agree.

-Ekr