[QUIC] draft-shade-quic-http2-mapping comments

[Julian Reschke <[e-mail]>]

Hi there,

thanks for splitting the documents. Here are some early comments on 
draft-shade-quic-http2-mapping.

At some point we'll need to decide what HTTP/2-over-Quic is. Is it just 
a mapping to a different mapping to a different transport, or is it the 
next major revision of HTTP, thus essentially HTTP/3.

I'm asking because these seem to be conflicting goals, and it would be 
good to clarify that as soon as possible. That said:

The slides showed in the IETF Berlin Bof session specifically mentioned 
that a client success rate of 93% might be good enough (or close to 
that), as we can always fall back to HTTP/2-over-TLS. I do not disagree 
with that, but it essentially means that the client-visible semantics 
MUST be the same as for HTTP/2 (in particular as HTTP/2 over TLS in 
theory could fall back to HTTP/1.1 over TLS). The impact of this might 
be different for a browser such as Chrome compare to other users of HTTP.

Now looking at Section 2, "QUIC advertisement", specifically:

> 2.  QUIC advertisement
>
>    A server advertises that it can speak HTTP/2-over-QUIC via the Alt-
>    Svc HTTP response header.  It does so by including the header in any
>    response sent over a non-QUIC (e.g.  HTTP/2 over TLS) connection:
>
>    Alt-Svc: quic=":443"

Well, you'd need to register an ALPN identifiers "quic" for that. The 
problem is that (AFAIU) APLN tokens in theory are used to negotiate 
protocols over TLS, which is not the case here. I know that there are 
precedents with that, but if we really want to turn ALPN identifiers 
into a generic protocol negotiation mechanism, we really should talk to 
the TLS WG and potentially revise RFC 7301. (Alternatively, we could 
revise Alt-Svc, in which case you should talk to the HTTPbis WG).

>    In addition, the list of QUIC versions supported by the server can be
>    specified by the v= parameter.  For example, if a server supported
>    both version 33 and 34 it would specify the following header:
>
>    Alt-Svc: quic=":443"; v="34,33"

That would require registration in the "Alt-Svc Parameter Registry" (RFC 
7838, Section 7.3). That said, while working on HTTP/2 we did *not* use 
the final ALPN token, but just used the draft names as tokens; that 
seems to be much simpler, more robust, and doesn't require (a) 
registering an extension parameter and (b) properly parsing it.

> ...

Best regards, Julian