Draft: draft-ietf-quic-http

Commentary: Section 3.2 : " A client MAY attempt access to a resource with an " https " URI by resolving the host identifier to an IP address , establishing a QUIC connection to that address on the indicated port , and sending an HTTP/3 request message targeting the URI to the server over that secured connection . " draft - ietf - quic - tls states in Section 8.1 : " Unless another mechanism is used for agreeing on an application protocol , endpoints MUST use ALPN for this purpose . " Looking at Section 3.2 with Section 3.1 deleted I think there is an important aspect missing which is expressed in first sentence of Section 3.1 : " HTTP/3 uses the token " h3 " to identify itself in ALPN and    . " In Section 3.3 : " QUIC connections are established as described in [ QUIC - TRANSPORT ] . During connection establishment , HTTP/3 support is indicated by selecting the ALPN token " h3 " in the TLS handshake . Support for other application - layer protocols MAY be offered in the same handshake . " So what I interpret is that the inclusion of the " h3 " ALPN token will be required in the clients messages when establishing an QUIC connection with the intention of communicating using HTTP/3 according to this specification . So I think there are two changes needed here . First that there needs to be a first paragraph in Section 3.2 to state that HTTP/3 uses " h3 " as token in ALPN and    as a lead in , secondly that the sentence first referenced above needs to state that ALPN = " h3 " will be given in the QUIC - TLS handshake . If I understand this correctly , a QUIC connection that has been established using " h3 " ALPN token , i.e. client tells it interested in this application and where the server choice that token in the handshake will be using HTTP/3 according to this specification . It is possible for other ALPN tokens to be application foo using HTTP/3 . Finally do I interpret things correctly that " h3 " is not strictly required but then both client and server need to know that yes , this connection establishment is for the purpose of HTTP/3 ? 
 If some other mechanism is used for agreeing on protocol , ALPN can be omitted , yes . I 'm not convinced that the first paragraph of 3.[2 - 1 ] is the appropriate place to put the token statement ; the section is about discovering an HTTP/3 endpoint given a URL , and the definition of the ALPN token is incidental there . I 've the token to 3.[2 - 1 ] in the paragraph about the connection ; see what you think . 
 I think the proposed text does clarify the issue and makes the default and alternative clear . So this resolves my issue . 
 Based on , labeling this as " editorial "
Paragraph (version A):
A client MAY attempt access to a resource with an "https" URI by
resolving the host identifier to an IP address, establishing a QUIC
connection to that address on the indicated port, and sending an
HTTP/3 request message targeting the URI to the server over that
secured connection.
Paragraph (version B):
A client MAY attempt access to a resource with an "https" URI by
resolving the host identifier to an IP address, establishing a QUIC
connection to that address on the indicated port, and sending an
HTTP/3 request message targeting the URI to the server over that
secured connection.  Unless some other mechanism is used to select
HTTP/3, the token "h3" is used in the Application Layer Protocol
Negotiation (ALPN; see RFC7301) extension during the TLS handshake.
Paragraph (version A):
An HTTP origin advertises the availability of an equivalent HTTP/3
endpoint via the Alt-Svc HTTP response header field or the HTTP/2
ALTSVC frame (ALTSVC), using the Application Layer Protocol
Negotiation (ALPN; see RFC7301) token defined in connection-
establishment.
Paragraph (version B):
An HTTP origin advertises the availability of an equivalent HTTP/3
endpoint via the Alt-Svc HTTP response header field or the HTTP/2
ALTSVC frame (ALTSVC), using the "h3" ALPN token.