W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2019

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

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 20 Nov 2019 19:18:34 +0000
Message-ID: <CALGR9obRoQ56Jcf_UMW0qiHgGmeRt1y8+8A_8T55XrtgUsWR1g@mail.gmail.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, QUIC WG <quic@ietf.org>, Kazuho Oku <kazuhooku@gmail.com>
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
Received on Wednesday, 20 November 2019 19:18:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:43 UTC