Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt

[Kazuho Oku <[e-mail]>]

Roy, thank you for your comments. My responses inline.

2019年7月13日(土) 3:54 Roy T. Fielding <[e-mail]>:
>
> On Jul 12, 2019, at 7:01 AM, Kazuho Oku <[e-mail]> wrote:
>
> Hello all,
>
> Thank you very much for all the discussion here and elsewhere.
>
> Based on the feedback, Robin, Lucas and I have expanded the number of urgency levels from 3 to 8, including a "background" level. From what we have heard, this would be sufficient; 5 levels is what some browsers use now (and we now provide 5 + background to them).
>
> I hope that this gives them enough space to start with (we can subdivide existing levels later), at the same time associating enough meanings to each of the urgency levels so that the servers can tweak the prioritization scheme.
>
> We can't submit -01 now, but the up-to-date draft can be found at:
>
>     https://kazuho.github.io/draft-kazuho-httpbis-priority/draft-kazuho-httpbis-priority.html
>
> The repository and the issue list can be tracked from https://github.com/kazuho/draft-kazuho-httpbis-priority/.
>
> Please let us know what you think. Thank you in advance.
>
>
> Hi Kazuho,
>
> This is starting to sound a lot like Waka's request priority (hi, lo, HiLo) and request context
> [slide 9 of http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf ]. I agree that defining
> this as an e2e header field is a good way forward. HiLo is progressive with high priority for the
> first block and then regular priority for the rest.

Thank you for sharing the slides. It's reassuring to know that you had
thought about something similar, and still think that it's preferable.

HiLo is interesting. Am I correct in assuming that the intended
primary use case is to transmit the size of the images so that the
browsers can determine the layout at an earlier moment?

While I think that such signal is useful to some extent, I am not sure
how useful it is.

Partly because it is not the best way of notifying the client the
metadata at the earliest moment. In case of images, we typically embed
the size of the image either in the CSS or the IMG tag, so that the
client would not need to wait for the first few bytes of the image.

The other reason is that HiLo does not communicate the reason the
client thinks the first few bytes are important. If we are to have
something like HiLo, I think it would be better to have a richer
signal that tells the server why and / or what needs to be sent ASAP.

Considering these aspects and the fact that the H2 prioritization does
not have this type of signal, I think we can start without having HiLo
in the Priority header.

> Note that there are other (security and privacy) reasons for explicitly communicating the context
> of a request, since it can be used to detect some forms of fraud, phish, or transclusion.
> However, that would need to be in a non-script-settable field.

I agree that such filtering rule would help us to some extent. Though
it would be fragile regardless of the header field defined as
non-script-settable, considering the fact that clients that do not
implement the Priority header extension could pass through the header
field set by the application.

> We should also consider non-browsing priorities, such as indicating intentionally long-lived
> responses that might have a low priority but do require some form of unbuffered regularity
> (e.g., pongs).

I'd argue that one of the non-background urgencies should be used for
a request that require a timely response (e.g., ping-pong).

Maybe the issue in the current draft is that, as others have pointed
out, the terms "non-background" urgencies are too browser-centric. It
might be a good idea to consider renaming "document" to "default" at
least.

> I don't think progressive is an independent parameter unless we intend
> to communicate some sort of block size; otherwise, it is just saying that HoL blocking
> isn't desired, which is not necessary to communicate beyond not setting "background".

I'd argue that the progressive parameter is not related to HoL
blocking. It's rather a way to signal if the user experience would
improve by interleaving the response with others. The intended
use-case is for images that support progressive rendering, as IIUC
generally assumed that interleaving between the responses that carry
images that can be rendered progressively improves user experience.

>
> In general, I like the approach, but I think the structured header syntax is the wrong choice.
> Why send 26 bytes to communicate one (or maybe two) bytes of information?

Honestly speaking I wouldn't mind choosing something else than
Structured Headers as long as the alternative is extensible. At the
same time, I do not think 26 bytes is an issue because I'd assume that
it would be compressed into just a few bytes with HPACK / QPACK.

>
> ....Roy
>


-- 
Kazuho Oku