Original text:
parameter (urgency), sending higher urgency responses before lower urgency responses. <del> It is RECOMMENDED that, when possible, servers respect the incremental parameter (incremental).  Non-incremental responses of the same urgency SHOULD be served one-by-one based on the Stream ID, which corresponds to the order in which clients make requests.  Doing so ensures that clients can use request ordering to influence response order.  Incremental responses of the same urgency SHOULD be served in round-robin manner. </del> The incremental parameter indicates how a client processes response <del> bytes as they arrive.  Non-incremental resources are only used when all of the response payload has been received.  Incremental resources are used as parts, or chunks, of the response payload are received. Therefore, the timing of response data reception at the client, such as the time to early bytes or the time to receive the entire payload, plays an important role in perceived performance.  Timings depend on resource size but this scheme provides no explicit guidance about how a server should use size as an input to prioritization.  Instead, the following examples demonstrate how a server that strictly abides the scheduling guidance based on urgency and request generation order </del>  could find that early requests prevent serving of later requests. At the same urgency level, a non-incremental request for a large

Reviewer comments:
We accept that a strong suggestion to use round-robin isn't ideal. And look for other ways to phrase the suggestion of distributing or timeslicing. Fortunately we already had some text in the next paragraph that explained the ways that timing of delivery of incremental resources parts is important to clients and the sorts of things that servers need to consider. So this PR rearranges the text a bit and gives it dust off to make sure it is in line with our understanding now.
This recommendation is too strong. There is still value in allowing requests to complete. This suggests that pieces of all responses be provided concurrently. That leads to more context switching than necessary, or even inefficiencies in transmissions (one byte from each at a time would have excessive overheads). I would instead say:
I agree that "round-robin manner" is poorly defined and could be interpreted as 1 byte of everything. That would be bad. However, the full context of that SHOULD is in relation to the other requirements in that paragraph RECOMMENDing respect with no guidance on what that means seems a bit iffy to me. Your suggestion might get misinterpreted as relaxing the RECOMMEND. Rewriting that paragraph risks kicking the hornets nest of one the most divisive issues we had (URL). I sort of inclined to keep the SHOULD but expand on what we intended to say with "round-robin"
LGTM, some suggestions only.

Revised text:
parameter (urgency), sending higher urgency responses before lower urgency responses.  The incremental parameter indicates how a client processes response  <ins> bytes as they arrive.  It is RECOMMENDED that, when possible, servers respect the incremental parameter (incremental).  Non-incremental resources can only be used when all of the response payload has been received.  Therefore, non-incremental responses of the same urgency SHOULD be served in their entirety, one-by-one, based on the stream ID, which corresponds to the order in which clients make requests. Doing so ensures that clients can use request ordering to influence response order. Incremental responses of the same urgency SHOULD be served by sharing bandwidth amongst them.  Incremental resources are used as parts, or chunks, of the response payload are received.  A client might benefit more from receiving a portion of all these resources rather than the entirety of a single resource.  How large a portion of the resource is needed to be useful in improving performance varies.  Some resource types place critical elements early, others can use information progressively.  This scheme provides no explicit mandate about how a server should use size, type or any other input to decide how to prioritize. The following examples demonstrate how a server that strictly abides the scheduling guidance based on urgency and request generation order </ins> could find that early requests prevent serving of later requests. At the same urgency level, a non-incremental request for a large