LPardue
commented
4 years ago Having two frame types was the initial idea I had in mind but decided not to use in order provide some design slack. I'm happy to revisit / iterate things to tighten the slack but we should note the constraints and risk areas for change.
The design for PRIORITY_UPDATE assumes it is a reprioritization signal only sent on H3 control stream. That drives the need to refer to request or push by an ID.
The HTTP WG seem split on how the initial priority should be signalled. If it were to be a frame on the request stream, then we'd likely want a PRIORITY frame that can omit the ID, because that will waste bytes. This is how the pre-21 H3 frame worked, assigning 2 bits to express if the element ID was present. If using initial priority frames turns out to be preferred (not my preference fwiw), then you could define 3 frame types that achieve the same thing as reserving a byte and defining special meaning to bits.
I think the final design will be influenced by further developments in the process.
On Sat, Nov 23, 2019 at 7:04 PM ianswett notifications@github.com wrote:
Currently, we're using a byte to have a 1-bit value indicating whether the ID is a push ID. This also makes the framing a bit more complex to parse, since all other H3 frames contain only varints and blobs. We could solve the consistency problem by making it a varint with two valid values, but that's a bit odd to me.
I think it'd be simpler to have two frame types that are adjacent, one to indicate it's a Push ID and one to indicate it's a request Stream ID.
Admittedly, we're encoding a string as the value, so saving a byte doesn't seem that important, but it seems like a cleaner design to me.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/120?email_source=notifications&email_token=ABSELNKN672U5QBOWOJOHX3QVF5DVA5CNFSM4JQ3O6M2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H3SPAWA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSELNMQKEONVTVB2NY3D2DQVF5DVANCNFSM4JQ3O6MQ .
ianswett
kazuho
Currently, we're using a byte to have a 1-bit value indicating whether the ID is a push ID. This also makes the framing a bit more complex to parse, since all other H3 frames contain only varints and blobs. We could solve the consistency problem by making it a varint with two valid values, but that's a bit odd to me.
I think it'd be simpler to have two frame types that are adjacent, one to indicate it's a Push ID and one to indicate it's a request Stream ID.
Admittedly, we're encoding a string as the value, so saving a byte doesn't seem that important, but it seems like a cleaner design to me.