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>

> 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

> 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.

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