Draft: draft-ietf-quic-applicability

Commentary: First stab ; 
 Sorry I missed this during the WGLC . 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 does n't seem to be defined anywhere other than the HTTP/3 specification ( which might be a problem or not ) 2 ) More substantial , there is n'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 wo n't use    , 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 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 or has some insight that could help ? 
 It feels like the best way to incorporate this is to expand the " protocol does n't imply port " discussion to also include " port does n't imply protocol " before concluding with " not being able to safely make this inference is hard . " has a first stab at this , though it does n't cover as much as first suggested . Feel free to expand on it .
Paragraph (version A):
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
"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.
Paragraph (version B):
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.
Paragraph (version B):
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
"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.