Re: [quicwg/base-drafts] Composability of QUIC Extensions (#3332)

[Mike Bishop <[e-mail]>]

The recipient must be able to identify and parse the frames it receives, obviously.  HTTP/3 already recommends redefining, rather than modifying, frames.  This is because frames can be sent before receiving SETTINGS, and coordinating the point in the connection at which things change is... challenging.

QUIC doesn't have this problem directly, because the negotiation takes place before any frames are sent.  (0-RTT implies support for everything that was supported last time.)  So for single extensions that modify frame definitions, this is fine.

The insight here is that multiple extensions which all redefine the same frame will stomp on each other.  This is potentially true with redefinitions as well.  If extension 1 deprecates A and replaces it with X, but extension 2 deprecates A and replaces it with Y, you're either repeating the information (and effects) of the base frame by sending both X and Y, or you're only supplying information to one of the two extensions each time you would have sent A.

It's probably better that extensions define *separate* frames whenever possible and leave the base ones totally alone, even if that means using some kind of reference to the base frame to correlate them.  I don't know that we can go so far as mandating that, though.  Perhaps simply a caution that extensions which modify the core protocol have the potential to interact poorly with other extensions modifying the same component unless that interaction is defined.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3332#issuecomment-573099706