Expand the description of urgencies

[kazuho]

Aside from the use of HTTP headers, the semantic urgency levels is the core of the proposal, but we've been very brief about what each level represents.

This PR expands on that.

[rmarx]

I think these clarifications help a lot in explaining the intended usage and semantics of the current urgency values

[LPardue]

I think these changes are a net positive.

However, these shine light on what I think are some assumptions about the reader's understanding of usability, especially in relation to User Agent's parse/render workflows and the way they might cope with fallbacks.

I think some text in a separate PR could help describe usability. Which might help contrast this prioritisation model against frame- / tree-based. What I mean by this is that H2's model is not subtle enough to articulate a priority of "I'd really like this thing, but if I really had to pick, I could probably manage without it." - or maybe it could but it would incur chatiness and reprioritization.

[kazuho]

@LPardue Thank you for your comments.

However, these shine light on what I think are some assumptions about the reader's understanding of usability, especially in relation to User Agent's parse/render workflows and the way they might cope with fallbacks.

Agreed. While writing down this PR and #30, I intentionally tried to imply that there is some wiggle room in how certain resources (e.g., font) might be generally prioritized by a client, and then suggest how they can be overridden by the server.

But yes, we should try to make it better.

But as you state, making such improvements might take time, and therefore I share the view that we'd better merge PR (or the sort) then do further work on a different PR. In short, please give the updated text a review.

[kazuho]

This PR was subsumed by #34.