Change:
Call out that since transport parameters are not ALPN specific, when the client offers several, that application protocols should not put restrictions on them that might back them into a corner for future versions.
NAME should take a look.
Currently when a client offers multiple ALPNs when connecting to a QUIC server, it still only offers a single QUIC transport parameters set. This implicitly requires (assumes?) that the single TP set is (must be) valid for every protocol version offered. The same is true for QUIC versions when version negotiation is added. We should allow for the client to offer different settings for different QUIC version or ALPNs (or the corresponding combinations?). If we made a change here, I'd also prefer the solution to not be dependent on any further TLS changes, as this would make the solution much more disruptive. It has been suggested on Slack that the ALPS TLS extension might be good for this, but the fact that it would require TLS changes is a non-starter for QUIC v1. One possible solution for fixing this is to modify the format of the existing TPs to a list of { quicversion, alpn, TPs }, and allow for quicversion to be zero and/or alpn to be empty to indicate unrestricted applicability of these TPs (to all versions/ALPNs). App protocol v1 does not allow server initiated bidi-streams, and it's explicitly an error to set an initial stream count greater than zero. App protocol v2 now has a use for these streams and requires the client to send a count greater than zero.A server supports two related protocols, P1 and P2, but each protocol has a slight different interpretation of unidirectional streams, and require different initial counts to be set.QUIC version 2 wishes to remove or redefine a particular transport parameter. If we don't take a change/fix for this in version 1, it restricts the kinds of changes to TPs we can make in future QUIC versions.
I don't think we should make this change at this point. Regarding separate ALPNs over QUICv1, we can solve this by saying that protocols running over QUIC MUST NOT enforce maximum values for transport parameters. For example HTTP/3 does not use server-initiated bidirectional streams, but there is absolutely no reason for HTTP/3 to require the corresponding transport parameter to be zero. Regarding multiple QUIC versions, I don't understand the problem. The packet containing the transport parameters is a long header that carries the QUIC version, so endpoints just need to interpret transport parameters based on the QUIC version they were sent in.
I agree with NAME I'm not in love with the current transport parameters, but I don't see an abundant reason to change them at this point. I similarly don't think they are actually that coupled to TLS or the QUIC version. As David notes, the interpretation is inherently QUIC-version dependent. We could, for example, completely ditch transport parameters in the TLS extension for QUIC v2 and instead opt for a TRANSPORT_PARAMETERS frame.
For the multiple QUIC versions, my understanding of the direction of version negotiation was that the client would use one version, but include the list of supported versions in its TPs. Then the server could negotiate that to a different QUIC version than the one used in the client initial packet. In that scenario, it would require the TP set to be valid for all versions that the server could negotiate to.
NAME I agree there are other possible solutions for version 2, but as you point out, they likely require a TLS stack change, which I am trying to avoid. I guess this could all be pushed to an extension as well. A new transport parameter that encodes the list of version/ALPN specific parameters... I just don't know how you'd handle the extension being optional.
Also, I still don't have a solution for the "related protocol" example above without adding extra cross-protocol negotiation logic, where the server app knows that the client was offering P1 and P2, and therefore understands how to consume the "combined" TP set in a protocol specific way. OR, I'd have to completely merge the protocols and do the negotiation at the app layer.
NAME it sounds like you're referring to , but I don't think your understanding is correct. In that scenario, the client sends a QUICv1 Initial/ClientHello, and then the server can reply with a QUICv2 Initial/ServerHello. That doesn't require the transport parameter meaning to be the same, the server just needs to know that it's using the v1 interpretation, and the client needs to use the v2 interpretation.
I agree to what NAME and NAME say. In addition to what they have stated, I'd point out that endpoints can loosen the settings by sending frames after the handshake is complete. Most transport parameters are merely used to communicate the initial values. And for other parameters that communicate the final value (e.g., maxackdelay), we can add frames for changing the behavior as we find out the needs.
NAME I guess my line of thinking was that instead of just sending v1 (and indicating support for v2) and the server deciding how to migrate the v1 TPs to v2, the client would be able to send both v1 and v2 TPs (or v1 plus whatever extra v2 requires). Then the server doesn't have to migrate the TPs at all. This might even allow for a greater range of compatible versions. Without this, v1 and v2 could be incompatible because of a change in how a TP is used. I guess if we wanted to go that route, the different TPs could be part of the version negotiation extension draft. NAME applications can theoretically decide how to interpret an initial TP value however it wants. Not allowing for the app to pick different initial values based on the protocol version being used restricts what the app can do. If that's the direction folks want to go, we should probably at least mention this so that protocols take this into account when designing their v1, so they don't back themselves into a corner.
Adding some editorial changes to QUICv1 to reflect this discussion sounds like a fine resolution to me
This reminds me of the conversation about putting SETTINGS into TP, which prompted the creation of the ALPS proposal. I'd like to see a future version of QUIC do a better job with both TPs and application settings, but it's way too late to be making such a substantial change to QUIC v1 at this point.
If someone wants to propose an editorial PR we can consider it as an editorial issue. Failing that I sense we can live with the document as is.
I'm not seeing an action for me in this discussion. I will of course review any PR that someone proposes, but it seems like the minefield is sufficiently well mapped out already.
I'll look into adding some warning text later today.
Discussed at IETF 108. Proposed resolution are editorial changes.

Discussion:
Endpoints use transport parameters to authenticate the negotiation of connection IDs during the handshake; see cid-auth. <ins> Application Layer Protocol Negotiation (ALPN; see ALPN) allows clients to offer multiple application protocols during connection establishment.  The transport parameters that a client includes during the handshake apply to all application protocols that the client offers.  Application protocols can recommend values for transport parameters, such as the initial flow control limits. However, application protocols that set constraints on values for transport parameters could make it impossible for a client to offer multiple application protocols if these constraints conflict. </ins> 7.4.1. Using 0-RTT depends on both client and server using protocol