Editorial follow-up from 1601

[ianswett]

I just got a moment to read #1601 and had some editorial suggestions.

[ianswett]

Thanks Lucas, I accepted your suggestion.

[kazuho]

Thank you for the PR. Looks good modulo the point below.

[kazuho]

I think I understand the intent of this paragraph but I'm not sure if it's entirely accurate. As stated in the paragraph above (starting from line 154), there is a standard way of coalescing HTTP/2 priority trees into one.

Maybe something like: HTTP/2 priority signal of an HTTP request is expressed as a value relative to that of other requests sharing the same connection and therefore it is impossible to express priority signals without the knowledge of how the requests are coalesced?

Separately, as this would be a problem statement, I think it might make sense to move before the paragraph right above this one, because we continue to say "Considering the problems (snip) and the difficulties in adapting it to HTTP/3..."

[LPardue]

You're right that H2-to-H2 can work. However, Ian's previous text said versions prior to HTTP/2. I was trying to be clever and use "other versions" to mean HTTP/1.1 and HTTP/3. There is no way to map RFC 7540 style priorities to H3, we gave up on that as noted in the paragraph above. I would say the prime motivation for giving up in H3 was not intermediary complication, which your suggested reordering might imply.

[kazuho]

Thanks, I see. I think my concerns are:

• The paragraph proposed is a mixture of problem statement and solution. That does not fit well into the current structure of the section that writes down the problems and then explaining the solution in the final paragraph below. I think we'd better cut down this paragraph to a problem statement, at the same time adding text to the final paragraph of the section to explain why the particular solution was chosen (if necessary).
• As a problem statement, I'm not sure if it suites the most to state that the problem as about intermediaries. The insight that we have is that the crux of the problem is that Semantics does not have the concept of a "connection." Not only intermediaries but also HTTP client library API suffer from the problem. I'm fine with using intermediaries as an example.

So maybe something like: HTTP/2 priority signal of an HTTP request is expressed as a value relative to that of other requests sharing the same HTTP/2 connection. Such design requires the understanding of the underlying protocol version and how the requests are coalesced in order to use priority signals. This has been a burden to HTTP endpoints that generate or forward requests at the HTTP Semantic layer.

[ianswett]

I'm happy with whatever you two prefer.

[LPardue]

overtakn by #1697 which incorporates your changes Ian. Thank you!