Hi Tom, Thanks for your sharing your thoughts. I'd like to respond in more direct detail but fear I might tread on the conversation toes. To talk around a general topic of discussion, I've been noodling the philosophy of priorities today. One thing that emerges to me is that a client parsing a document has a _vague idea_ what the resource is, it can determine some information from link relation, element, file extension etc but it is only a partial picture. Clients typically assign their H2 priorities at this stage, based on the intended usage. What they can't know exactly is the selected representation [1], which is determined by the server. For example, whether a JPEG image is encoded as progressive or baseline. The nature of the selected representation may affect how the client would use it, and it is challenging for a server to reflect this back into all the flavours of H2 priority tree that exist. And although a client could perhaps apply reprioritisation to the in-flight response (after it learns information), chances are that it will happen too late. Since the selected representation is chosen during the lifetime of an end-to-end connection, it is difficult to define a static signal that can work for all. So my opinion is that the proposal is less about one side running roughsod over the other, but all sides attempting to paint a fuller picture using a common set of accessible terms. Of course this might go askew, your example of a background priority getting "upgraded" has come up - there is space in the spec for this to be addressed IMO. Kinds regards Lucas [1] https://tools.ietf.org/html/rfc7231#section-3
Received on Friday, 12 July 2019 23:28:04 UTC