- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 30 Apr 2015 17:33:33 +0200
- To: Hervé Ruellan <herve.ruellan@crf.canon.fr>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2015-04-30 17:23, Hervé Ruellan wrote: > > On 04/30/2015 04:43 PM, Julian Reschke wrote: >> (see <https://github.com/httpwg/http-extensions/issues/43>) >> >> > 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. >> >> Right now we do not mention "http/1.1" at all. Should that change? > I think we should remove the ambiguity to make clear that http/1.1 is > over TLS. Looking at <http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids>, only "h2c" is marked as non-TLS. Somewhere does the confusion come from, and what does it have to do with alt-svc right now? Is the idea to put this into alt-svc because we happen to process this doc right now, and it is somewhat related? (I'm fine with that, but I'd like to fully understand what's going on) >> >> > 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. >> >> Is this a use case we want to address? > I think there is a general sense that we should not define such an > identifier to instead promote the usage of TLS. >> >> Best regards, Julian >> > Best regards, > > Hervé Best regards, Julian
Received on Thursday, 30 April 2015 15:34:02 UTC