Original text:
default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP.  Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the <del> "h3" ALPN token RFC7301.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </del>  Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of

Reviewer comments:
First stab;
Sorry I missed this during the WGLC. URL contains a lot of good stuff but it seems like it could say more about ALPN. 1) As an editorial comment ALPN is mentioned without expanding the acronym. The term is used, which doesn't seem to be defined anywhere other than the HTTP/3 specification (which might be a problem or not) 2) More substantial, there isn't really mention about any of the TLS or negotiation aspects of ALPN. We might see people try to offer multiple Application Protocols on the same UDP port, and using ALPN to select from them. Maybe this is more likely when QUIC can operate as both a stream-based and datagram-based protocol. 3) Related to 2, new application protocols over QUIC need an ALPN protocol identifier. This is distinct from the Alt-Svc discussion in Section 6; since other protocols won't use Alt-Svc, they might overlook things. The ALPN space is large but we might benefit from some text that gives people pointers on how to register the ALPN IDs they want to use before someone gets them. For reference, I started a list of protocols at URL Not all of those need formal registration but it is a nice illustration.
I'm unfortunately not coming up with some useful/actionable text here. Maybe NAME or NAME has some insight that could help?
It feels like the best way to incorporate this is to expand the "protocol doesn't imply port" discussion to also include "port doesn't imply protocol" before concluding with "not being able to safely make this inference is hard." has a first stab at this, though it doesn't cover as much as NAME first suggested. Feel free to expand on it.

Revised text:
default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. <ins> Additionally, Application-Layer Version Negotiation RFC7301 permits the client and server to negotiate which of several protocols will be used on a given connection.  Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered. Applications using QUIC should register an ALPN token for use in the TLS handshake. </ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the  <ins> "h3" ALPN token.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </ins> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of