Change:
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 Alt-Svc." 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 Alt-Svc 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 added 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"

Discussion:
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 <del> secured connection. </del> <ins> 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. </ins> Connectivity problems (e.g., blocking UDP) can result in QUIC connection establishment failure; clients SHOULD attempt to use TCP-

An HTTP origin advertises the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 <del> ALTSVC frame (ALTSVC), using the Application Layer Protocol Negotiation (ALPN; see RFC7301) token defined in connection- establishment. </del> <ins> ALTSVC frame (ALTSVC), using the "h3" ALPN token. </ins> For example, an origin could indicate in an HTTP response that HTTP/3 was available on UDP port 50781 at the same hostname by including the