RE: alpn identifiers (not again!)

It boils down to whether versioning is a difference of protocol.  HTTPS denotes HTTP over SSL/TLS over TCP, which is a protocol stack.  But is that HTTP/1.1 or HTTP/2?  TLS 1.3 or SSL3?

Stefan is correct that those include built-in version negotiation mechanisms, so "HTTPS" is sufficiently precise to tell a client how to proceed.  Make a TLS connection and expect to negotiate some variety of HTTP over it.  You're also correct that it doesn't tell the client what version of HTTP (or TLS, for that matter) to expect on those endpoints.  But does the client actually need that information?  It knows what to do.

That said, *everything* in Alt-Svc has to ultimately carry the semantics of the original requesting protocol (HTTP in this case).  You're just telling the client how to reach an HTTP origin over some other combination of underlying protocols -- which may be TLS over TCP, or QUIC over UDP, or some SCTP mapping, or whatever else we dream up in 2024.  It may be immaterial to mention the HTTP semantic layer, since that ultimately has to come anyway.  However, those underlying layers can't currently be denoted by scheme, unless we define alternate schemes that http:// and https:// URIs can be mapped to.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Tuesday, June 9, 2015 10:06 AM
To: Stefan Eissing
Cc: HTTP Working Group
Subject: Re: alpn identifiers (not again!)

On 9 June 2015 at 02:44, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> schemes are needed.

This is the part I'm not convinced of.  I think that it might be more harmful in fact, but I'm not sure that I completely follow your logic.

> URI schemes denote protocol stacks.

This is something I disagree with, so maybe that's where we have a disconnect.  URIs with a https scheme clearly do not describe a protocol stack.

Received on Tuesday, 9 June 2015 17:40:52 UTC