Re: [quicwg/base-drafts] PUSH_ID as a frame (#2526)

[Lucas Pardue <[e-mail]>]

+1 to levelling up, I'll take acknowledge my guilt here. But before I move on:

> push_id then yes you would read 0x1 which is conveniently a server initiated bidirectional stream which is not allowed anyway, so you could reject it immediately

If your at the stage of parsing QUIC STREAM frame payload, you should already know exactly what the stream ID is.

Some historic points I remember:

In Paris MT presented some ideas for unidirecitonal streams. This relates to issue https://github.com/quicwg/base-drafts/issues/281 and PR https://github.com/quicwg/base-drafts/pull/701.

Push and control streams were identified then. And we were happy with reserving specific stream IDs for certain things. All non-reserved streams were server push streams. Subsequent data on the stream only makes logical sense to handle if you know what push it relates to, so those bytes go first. 

Roll forward some, QPACK design requires additional streams so those get reserved to. Around Kista, the topic of unidirectional stream types comes up. Without types, we make uncoordinated unidirecitonal stream extensions quite a difficult thing. So add more bytes at the start of stream and remove reservations.

> For example, one could make a counter argument: why are we framing SETTINGS at all given that it is the first message on the control stream ?

The SETTINGS frame can contain a set of parameters, indeed it SHOULD contain at least one GREASE setting. A single SETTINGS frame that describes the length of all parameters is quite useful, you know when the peer has finished sending all of them. I don't see as much value for PUSH_PROMISE because you're just framing a single integer that describes its own length already. 

-- 
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/2526#issuecomment-474088075