ALPN identifiers in Alt-Svc

[hruellan]

ALPN identifiers from the ALPN spec have been defined in the context of negotiating the application protocol in TLS. In this context, they imply a layering above TLS.
When used outside this context, there is an ambiguity, mainly for the http/1.1 token: does it refer to HTTP/1.1 over TLS, or can it refer also to HTTP/1.1 over TCP?
The draft should resolve this ambiguity by stating that the http/1.1 identifier is used to identify HTTP/1.1 over TLS.

In addition, a new identifier, h1c for example, could be defined to identify HTTP/1.1 over cleartext TCP, in order to allow using Alt-Svc to be used to target an HTTP/1.1 server over cleartext TCP.

[mnot]

Discussed in Texas; agreed that http/1.1 means over TLS.

[reschke]

We currently do not have any text or example that uses the "http/1.1" ALPN identifier. Should we add something?

[mcmanus]

I think its fine as is. no need to promote legacy through cut and paste.

[mnot]

It seems like changes similar to those we put into tunnel-proto for Barry should be sufficient here.

[reschke]

Which, specifically?

[mnot]

I think it was this text:

The ALPN header field carries an indication of client intent only. An ALPN identifier is used here only to identify the application protocol or suite of protocols that the client intends to use in the tunnel. No negotiation takes place using this header field. In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client. Other substrates could negotiate the application protocol differently.

(modified suitably, of course)

[hruellan]

I adapted this text for solving this issue, see: #88.