Re: alpn identifiers (not again!)

> On Jun 9, 2015, at 10:40 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> 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?

URI schemes delineate naming authorities and their underlying namespaces.
The protocol stacks are a separate issue, defined largely by client config.
This is explained in RFC7230.

> 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's one way to configure a client, yes.

> 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.  

Well, the alt service needs to be capable of supporting the semantics of *this* request,
which in most cases will be a GET or OPTIONS, and understand what to make of a request target.
All information protocols tend to support those semantics.  Presumably, the client will only
pick alt protocols that it would prefer over the one it is currently using, and thus has
some instruction on how to translate the old request into the new protocol(s).

> 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.

Alias schemes, yes.  Alias schemes are fine, but only if the client is instructed to
rewrite them as the more general scheme for presentation and links, since aliases in
general cause all sorts of damage to the Web.  Alt-Svc could then be replaced by a
Link rel=alternate, and not need to be limited to HTTP semantics.  But, that would have
the disadvantage of not being a hack specific to h2, so it is harder to parse and might
play havoc with folks who use Link for useful things.

Anyway, what you are basically saying is that ALPN identifiers are poorly suited for
this purpose, whereas a list of composed protocol name-ports like http.tcp.8080 or
h2c.ssh.tcp.22 would not have those limitations.  Whether or not we call those composed
names a scheme doesn't seem to matter, unless we use them as schemes.

....Roy

Received on Tuesday, 9 June 2015 19:02:24 UTC