Re: Priorities I-D for Thursday HTTPbis meeting (Fwd: New Version Notification for draft-kazuho-httpbis-priority-04.txt)

Hi Mikkel,

To comment as a co-author but speaking only for myself:

On Wed, 20 Nov 2019, 20:57 Mikkel Fahnøe Jørgensen, <mikkelfj@gmail.com>
wrote:

> Looking forward to digging further into this.
>
> This is not a feedback in the actual design, only the document structure
> and presentation. While this may come across a bit negative, I’m really
> happy with simplifying the priority scheme of HTTP/2..
>
> Some quick observation when approaching the document initially. I writing
> this before having a full grasp of the concepts because that is the only
> time to provide a newcomer perspective.
>


Thanks for taking the time to review, fresh eyes are great.


> I think the document could be reorganised and much earlier specify how it
> achieves prioritisation and use less text (initially) on HTTP/2 by mere
> stating the the scheme can work with both HTTP/1, 2, 3 and possibly future
> versions while stating that special mechanisms can be used to opt-out of
> existing HTTP/2, and leave it at that.
>

I agree here. The present document is an amalgamation of several doc, this
has acted as a mechanism to support the design team and improve the
iteration seed. As a specification we can make improvements here, both in
structure and modularity.


> After reading 1/3 of document, I still have no clue how the priority
> scheme works (except I have some guess based on earlier ideas that have
> floatet) and I have had to deal with a lot of HTTP/2 legacy that I am not
> necessarily interested in. HTTP/3 doc has also move away from implicit
> HTTP/2 familiarity, at least last time I checked.
>

To reinterpret you point, I think that the concepts of urgency and
precedence would benefit from better description (issues #31[1] and
#32[2]). But I also wonder if you are saying that there is too much or too
little HTTP/2 specific/related content? Or am I missing out on your point
here?


> The document talks about intermediate hop reprioritisation without making
> clear what that is or what purpose it serves. I can only assume load
> balancers and reverse proxies. From a QUIC background that also leaves me
> wondering what that means - since each hop is necessarily also end to end,
> unless there is an extension wrapper frame, but that makes no sense.
>

The intent is to address the HTTP semantic layer but dip into HTTP
version-specifics where necessary. We rely on readers being familiar with
HTTP semantic concepts and terminology but can probably do a better job of
referencing. Since QUIC has no concept of priority, but the serialisation
of HTTP does and is ultimately coupled to the transport layer, it can be a
bit tricky to pick the subject. Happy to take some suggestions on specific
ways to improve here


> Once I got to the business end of the document, the document starts by
> telling which headers not send when it is not at all clear what those
> headers are about in th first place.
>
> It’s also confusing what a protocol specific frame means, or why it cannot
> all be done with HTTP headers.
>

It would help to point to a specific section or paragraph. RFC 7540 Section
8 and HTTP/3 draft 24 section 4.1 detail message exchanges - I don't
especially feel the need to duplicate text in this document but accept that
it might help to reference these in the text.

Cheers
Lucas