search

kazuho / draft-kazuho-httpbis-priority

Other
6 stars 4 forks source link

Split prioritization into scheme and header sections #80

Closed ianswett closed 4 years ago

ianswett commented 4 years ago

I added a bit of text to introduce the 'Urgency' prioritization scheme, but besides that this is just moving text around. I think the header section now needs more explanation, but that can be added in a different PR.

I'm happy to pick a different name from 'Urgency' as well, but it seemed like the most obvious choice.

LPardue commented 4 years ago

@ianswett I think there is more work required to make this all hold together. I made a more extensive comment on possible improvements and GitHub lost it. How critical do you feel it is for this to be included in the draft?

ianswett commented 4 years ago

I'd like to split the prioritization scheme from how its conveyed, since I think it's good to separate concerns, but it doesn't have to be done in the way I did it in this PR.

I'd also like more detail on how the header works(ie: is it cacheable), in this section, opposed to some text in "Why use an End-to-End Header Field?" but we're running low on time for that.

ianswett commented 4 years ago

After re-reading your comments, I think we're thinking about how this works somewhat differently.

I'm thinking of the core of the proposal being the scheme, and then there are two ways(header and frame) to convey that information. Maybe you're thinking the core is the header itself?

LPardue commented 4 years ago

I think your concept could work but the current text doesn't do that well. We would need to talk about scheme parameters of urgency (an integer,) and progressive (a bool) in abstract sense. Parameters are extensible and unknown one must be ignored.

Then we can talk about specific encoding of parameters, which is structured headers dictionary members: sh-integer and sh-boolean. And that the rlencoded dictionary of parameters is what gets sent.

The text is not quite there in splitting these out

LPardue commented 4 years ago

Closing "split"-related candidate changes because they have rotted. We may chose to address the goal of these changes, and we may chose to restructure the document, and we may chose to do both of those things together; but I don't think this PR helps.