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

From: Mike Bishop <[email-masked]>
Date: Thu, 22 Aug 2019 08:18:13 -0700

> 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

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 22 Aug 2019 09:11:05 -0700

Thanks for creating this issue. 

I don't think using extension frames completely solves the problem because of the risks of changing the core behaviour so dramatically without endpoint coordination. For example, a client that sends requests only using HEADERS2 would need to wait for a HEADERS2 response before deciding that the extension is supported? That's a pretty big gamble to make.

Given the challenge to design a solution and the reality that we don't need one right now (but that we are chartered to allow H2-like extension mechanisms) I'd be inclined to say remove the specific example and summarise that these components mean frames, unidirectional stream types, request/response message exchanges etc.

-- 
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#issuecomment-523972405

---

From: Mike Bishop <[email-masked]>
Date: Thu, 22 Aug 2019 10:21:11 -0700

I think what a client would do is send HEADERS until it sees the SETTINGS frame and discovers it can use HEADERS2 from now on, including in 0-RTT in the future.  No gamble involved, but the server has to continue to support the "old" elements as well.

-- 
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#issuecomment-523997925

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Aug 2019 17:08:39 -0700

Yes, that is how I would do it.  The idea would be that once you advertise support for HEADERS2, you could receive one at any time, but you might still receive the old version for an indefinite period.  You probably shouldn't even rely on seeing an ACK for the SETTINGS frame bits.

-- 
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#issuecomment-524123468