Re: [quicwg/base-drafts] Frame type extensions (#58)

[Mike Bishop <[e-mail]>]

Scale was the argument for not using the ALPN token for h2 extensions.  I like the posture that we settled on there:

- Unknown frame types are ignored -- clients MAY send extensions that don't require peer understanding (hints, for example) without confirmation.  Obviously, if you have a signal yes/no, you can save some wasted bytes.
- Frames that are state-changing or otherwise alter the contract of the core spec require positive acknowledgement that the peer understands them before sending (alternatives to HEADERS, DATA, etc.)

"Alters the contract of the core spec" may be worth a version bump, since you might have incompatible extensions.  And in general, anything that is MUST-understand and in the client's 0-RTT needs to be a version number change.  You can get away without it in most other cases.

The other thing that sticks out here -- this has the potential to make versions non-incremental.  What does that do to the version negotiation, where the client might not want to burn an RTT attempting the fanciest variant it knows, but would like to discover server support for other variants for future use?

-- 
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/58#issuecomment-265263806