[quicwg/base-drafts] Changing protocol elements: Is this text strong enough? (#2985)

[Mike Bishop <[e-mail]>]

> Extensions that could change the semantics of existing protocol components MUST be negotiated before being used. For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. **In this case, it could also be necessary to coordinate when the revised layout comes into effect.**

Unlike HTTP/2, HTTP/3 has no indication when the peer has received and processed SETTINGS.  This means that any extension which redefines a basic protocol element (e.g. HEADERS uses something other than QPACK or uses a different static table; PRIORITY frames should be interpreted differently) has to define its own coordination mechanism -- and that coordination mechanism will be unwieldy (see #84).

#2958 would give the necessary ordering for server settings -- they are effective for all server data -- but would only make sense if one side considered the other's SETTINGS prior to sending its own.  The server cannot do this in the current scheme or in #2958 for 1-RTT connections.

Should we simply remove the misleading suggestions that elements of the mapping can be redefined, pointing people instead to creating replacement frames (HEADERS2, PRIORITYEX, etc.)?  Or is the verbiage here that you're on your own to coordinate that switch sufficient hard-hat warning?

-- 
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/2985