On Wed, 31 Jul 2019 at 21:02, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > Hi Matthew, > > > On Tue, 30 Jul 2019, 22:25 Matthew Kerwin, <matthew@kerwin.net.au> wrote: > >> >> At the risk of bike-shedding, I think calling it "enable" is a bit of an >> issue. The setting, as an advertisement of the sender's capability, should >> say something like "will ignore" (for disabling 7540 priorities) or "can >> understand" (for enabling some other scheme). >> >> Unless we also feel the need to advertise "will not send"? >> > > It's difficult for a server to guess at the client intent. Not sending > PRIORITY information is also a signal to prioritise the request with > default RFC7540 parameters (depend on root node with weight 16). So having > a clear signal from client to server along the lines of "I don't intend to > send, and don't infer any RFC7540 meaning from it" avoids that problem and > my impression from Montreal was that this is a desirable goal. > A hint, then. Different from all the "I will understand if you do this" settings. I feel it's important to reiterate, though, that the setting *can not* say "don't infer meaning from it" -- you can't use a setting to tell the other end how to respond to your frames, only how you will respond to theirs. What happens if the client connects to a server that doesn't understand the setting? Are you using it as a negotiation-lite signal, so the client won't switch off its 7540-priority-tree code path until both ends have said they're happy doing so? > In Montreal we also discussed a possible experiment where the H2 PRIORITY > frame contents would be repurposed, which requires a compatible server to > read it correctly. In this case the signal would be more like "will send in > an RFC7540-incompatible format". > > Lucas > Eurgh, why? Are we that short on frame types? Cheers -- Matthew Kerwin https://matthew.kerwin.net.au/
Received on Wednesday, 31 July 2019 23:10:16 UTC