It's almost as if application-layer protocols need two version numbers, one to indicate wire syntax and another to implement semantic capability over time within a compatible syntax. I wonder where I've heard that before?
....Roy > On Apr 28, 2021, at 8:54 AM, Martin Duke <[email protected]> wrote: > > Yesterday there was an interesting conversation on Slack, about whether h3 > needed a new ALPN for QUICv2, that made me realize I had a very lazy mental > model where applications needn't worry about QUIC versions and QUIC versions > could be oblivious to what the app is doing. This isn't true at all. > > The basic dilemma here is that either > > (1) applications need explicit updates when new QUIC versions roll out, if > for no other reason than to say that they are fully compatible. This would > make it hard to get rid of old QUIC versions, and slow deployment of new > ones, as some apps never change. Or > > (2) Each QUIC version has to enumerate which applications work with it and > which don't, which seems... not scalable. Or > > (3) There is a compatibility matrix with quic versions as rows and > applications and columns, and any time a spec adds a row or column it should > fill that row or column out completely. Or > > (4) There are strict limits on future versions so that they don't take away > existing functionality (e.g. there MUST be an ability to get reliable > streams). or > > (5) Applications MUST have application-layer fallbacks if some QUIC features > aren't available (the way MASQUE can use QUIC STREAM frames if DATAGRAM isn't > supported) - or maybe it can throw an application error > > Maybe there's an alternative I can't see. The applicability draft > <https://www.ietf.org/archive/id/draft-ietf-quic-applicability-11.html#name-port-selection-and-applicat> > (currently in WGLC) says that each ALPN unambiguously defines the QUIC > version, which I guess is option (1). > > There are second-order questions like: is this mediated through ALPN or > something else? But the first-order question is which layer has to manage all > this. > >
