Re: Éric Vyncke's No Objection on draft-ietf-httpbis-priority-11: (with COMMENT)

Hi Éric,

Thank you for your review. Responses in-line:

On Wed, Dec 15, 2021 at 11:48 AM Éric Vyncke via Datatracker <
noreply@ietf.org> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-httpbis-priority-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document. It is really easy to read
> and it
> should bring real values.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
>
> Special thanks to Tommy Pauly for the shepherd's write-up including the
> section
> about the WG consensus.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> I like the way that urgency and incremental are defined and used.
>
> -- Section 4.1 --
> Please bear with my lack of knowledge here, but I wonder what is the
> expected
> client behaviour in the absence of SETTINGS_NO_RFC7540_PRIORITIES ? Should
> it
> keep using the 2 priority signals ?
>
> I also wonder about the asymmetry between the 2nd and 3rd paragraph, i.e.,
> may
> the client continue to send both priority signales in the 2nd paragraph ?
>

Do you mean Section 2.1, which is on the topic of disabling RFC 7540
priorities?
The way to treat this is as optimiation possibility to save bytes on wire,
or resource usage in endpoints (arising from modelling the RFC 7540
priority trees).

SETTINGS_NO_RFC7540_PRIORITIES initial value is 0, so implementations of
this spec treat RFC 7540 priorities as on, unless they hear otherwise. If a
client does not receive SETTINGS_NO_RFC7540_PRIORITIES=1, then it has
received no in-band signal that allows it to determine if the server is
ignoring HTTP/2 priority signals. There's no wire protocol problems to
worry about here. But if a client just guesses at what a server supports
and gets that wrong, then the server won't get hints that might have helped
improve its prioritization scheduling. Sending both signals is duplicative
but a good way to hedge against wrong guesses. So even if a client does
receive SETTINGS_NO_RFC7540_PRIORITIES=1 there's not much harm in sending
both signals.


> -- Section 4.3 --
> Should the 'community' be defined in "cannot be agreed upon in the
> community" ?
>

This text is borrowed liberally from other HTTP documents for a similar
kind of discussion. See, for instance, the Proxy-Status HTTP Response
header [1]. I'm happy not to define 'community' any further here. Perhaps
our responsible AD or WG chairs have an opinion on the matter though?


> -- Section 6 --
> Does the describe used of u=7 contradict the one described earlier as
> "delivery
> of software updates" in section 4.1 ? Perhaps add the pre-fetch use case in
> section 4.1 ?
>

Section 6 talks about using u=7 for a prefetch, which I would class as a
type of background activity. Prefetching resources is not part of direct
immediate user interaction (imagine it more like an optimization to speed
up the next interaction). As example of where a user agent might initiate a
prefetch is via the use of 103 Early Hints response [2] - a request for
index.html might return a non-final 103 that includes a Link header field
with rel=preload. This is a hint to the user agent that a resource is
related to index.html but the nature of that relationship depends on the
contents of the HTML document. If the user agent prefetches at a
high-valued urgency, it avoids those prefetches interfering with other
concurrent requests to start with. But after index.html is available, the
client's view of priority can change. Those prefetched resources might
suddenly switch to becoming critical to user interaction and
PRIORITY_UPDATE is there for reprioritization.

I'm wary of mentioning prefetch in section 4.1 because non-careful readers
might take it explicitly and overlook section 6. We could forward reference
but this all adds text to what is right now one single illustrative
example. Ultimately it is upon applications using HTTP to determine their
own definition of background tasks, spending text on it could be a
distraction.

-- Section 7.1 --
> Should this be "Type (i) = 0x10" in the figure 1 to match the text
> "(type=0x10)" in the first paragraph ?
>

Thank you for spotting this! On closer inspection there is more story
behind this but I agree we can fix this editorially to make it consistent.
Please see https://github.com/httpwg/http-extensions/pull/1860

[1] -
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-proxy-status-08#section-2.2
[2] - https://datatracker.ietf.org/doc/html/rfc8297