Draft: draft-ietf-quic-applicability

Commentary: Okay I made another pass on the text based on comments , however , it did n't get any short but maybe it 's slight more clear now . Please re - review ! ( Also I moved some paragraphs around to improve the text flow ; so the PR now looks bigger than it is . So we also need to update the section title now , which is " Port Selection and Application Endpoint Discovery " ? ) 
 Applicability Sec 8 : 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 . I was going to start a discussion about this at IETF 111 . I think we should think hard about this ; if there are a lot of versions with small differences to the application , this could result in a ridiculous cloud of RFCs . 
 Is there a change to make to this document in WGLC , or is this a note to be careful in the future ? 
 I personally do n't like this linkage , and think the ALPN should just define the application . While linking the version does smooth out version negotiation , it can result in an explosion in the ALPN registry . I 'll start a thread on the list about this , since I suppose it ca n't wait for the discussion at 111 that I was planning . 
 The point this was discussed already at length and the manageability document is just reflecting what has been decided for h3 . So if at all you 'd need to raise an issue on the h3 draft but I guess that 's also too late . 
 I disagree that the text of the H3 draft mandates this : That is a long way from saying " roll a new ALPN for each QUIC version " . Maybe everyone tacitly agrees we should roll a new ALPN , and I 'm in the rough . But I 'd like to confirm that . 
 See quicwg / base - drafts 
 How about rewording the sentence to reflect reality , roughly Since QUIC v1 ( RFC9000 ) deferred defining a version negotiation mechanism . HTTP/3 ( RFC - to - be - whatever ) deferred deciding how it would map to other QUIC versions . HTTP/3 requires QUIC v1 and defines the ALPN token ( " h3 " ) to only apply to that version . This solves a versioning problem at the cost of future flexibility . Application protocol mappings written for QUIC v1 or other QUIC versions may be able to benefit from version negotiation mechanisms that did not exist during the development of HTTP/3 ( RFC - to - be - whatever ) . Coupling QUIC version to ALPN tokens is one approach but not the only approach . 
 I believe the text already says that this does n't have to be applied by other application . The cited text is really only meant to described what was decided from h3 as an example . We can definitely reword this for reflect the consensus more clearly as proposed by Lucas . 
 Lucas , I would welcome your proposal as kicking the can down the road and not enshrining an approach that I think is bad . I would also like to continue the ALPN / versioning discussion , but it does n't have to block the applicability draft . 
 I can make it shorter . Maybe not as short as would have it , but still shorter :)
Paragraph (version A):
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 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 RFC7838 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.
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 RFC7838 for an HTTP origin to advertise the
availability of an equivalent HTTP/3 endpoint on a certain UDP port
by using the "h3" Application-Layer Protocol Negotiation (ALPN)
RFC7301 token.
Paragraph (version B):
ALPN 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 are required to register
an ALPN token for use in the TLS handshake.
Paragraph (version B):
As QUIC version 1 deferred defining a complete version negotiation
mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token
("h3") to only apply to that version.  So far no single approach has
been selected for managing the use of different QUIC versions,
neither in HTTP/3 nor in general.  Application protocols that use
QUIC need to consider how the protocol will manage different QUIC
versions.  Decisions for those protocols might be informed by choices
made by other protocols, like HTTP/3.