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

Hi Robin,

2019年7月11日(木) 19:15 Robin MARX <robin.marx@uhasselt.be>:

> Hello Kazuho,
>
> Yes, you are right, my apologies. Patrick's proposal recently changed to
> the approach proposed by Ian Swett in
> https://github.com/quicwg/base-drafts/pull/2700 and I was still thinking
> of the old version.
>
> I see that you have a PR that splits urgency up into about 8 numerical
> levels (https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/34),
> each with their own semantics and logic.
> This feels a bit like SPDY priorities-on-steroids and is indeed a nice
> middle ground between Patrick's 64 levels and your original 3. I still
> don't like the naming of the groups, but to settle that I guess we will
> need to resort to a duel at dawn ;)
> I've left some notes on the PR adding some additional examples to the text
> to further clarify intended usage. With something like that in, I feel it's
> a workable proposal.
>

I'm glad to hear that, and more importantly, thank you for the detailed
feedback. I think that PR #34 is becoming much more mature thanks to your
comments, and I'm feeling more confident that it is the correct approach.


>
> With best regards,
> Robin
>
> On Thu, 11 Jul 2019 at 05:46, Kazuho Oku <kazuhooku@gmail.com> wrote:
>
>>
>>
>> 2019年7月10日(水) 18:19 Robin MARX <robin.marx@uhasselt.be>:
>>
>>> Hello Kazuho,
>>>
>>> I agree that more extensive signaling would be research project with a
>>> medium/high turn around time.
>>> I think that there might have been a mis-interpretation from my end on
>>> that count though: I interpreted this draft as a way to be able to postpone
>>> the prioritization to after H3 / not make finishing H3 dependent on it.
>>> My assumption was that we would ship H3 with the draft-21 changes (aka:
>>> very similar to H2's setup) and then augment/extend that with this approach
>>> e.g., 6 months afterwards.
>>>
>>> Instead, if I understand you correctly, it is the intent to finish this
>>> together with H3 and expect browsers/clients to implement this together
>>> with H3 as its default (and only?) standardized prioritization option.
>>>
>>
>> Yes. That is the intent.
>>
>> My view is that if we are to have something other than the H2-based
>> design, it's beneficial to do it before or as the H3 hits the market. This
>> is because then we could use H3 as the vehicle for providing something
>> better, at the same time easing the pain of people implementing the complex
>> H2-based scheme.
>>
>>
>>> As such, it is my fear that we would be trying to rush this, to have
>>> "something" ready by the deadline, without properly testing or
>>> "researching" how it would work or if it covers all use cases. Afaict,
>>> that's going dangerously close to how we got the H2 setup in the first
>>> place...
>>> If it's the intent to have something simpler for H3 that allows for
>>> rudimentary tie-ins for server-side prioritization and that works well with
>>> existing browser setups, I feel Patrick Meenan's original proposal is far
>>> superior and more flexible than the current proposal in the draft for this
>>> purpose, while being nearly as simple/straightforward.
>>> To be clear: we could still use the "HTTP header" approach, just not the
>>> "urgency" and "progressive" aspects then (e.g., priority= level=63,
>>> concurrency=3).
>>>
>>
>> I think that there is a slight misunderstanding here.
>>
>> Assuming that the Patrick's proposal your are referring to is
>> https://github.com/pmeenan/http3-prioritization-proposal, concurrency is
>> a boolean parameter. In terms of functionality, it is identical to the
>> "progressive" parameter of the Priority header proposal.
>>
>> Therefore, the only difference between the two proposals regarding how
>> the priorities are expressed are:
>> * if each urgency has a meaning
>> * the number of the urgency levels (3 vs. 64)
>>
>> That said, I can see that just having 3 levels would be too restrictive
>> for browsers.
>>
>> If we are to propose the header-based approach as "the" priority scheme
>> for H3, I think we should try to provide a way to transplant the urgency
>> levels (that are currently internal to the browsers) to the "urgency"
>> parameter.
>>
>>
>>> Later work after the "research project" is done could then add
>>> additional header values to allow more use cases / semantics etc.
>>>
>>> With best regards,
>>> Robin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, 10 Jul 2019 at 03:25, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>
>>>> Hi Robin,
>>>>
>>>> 2019年7月9日(火) 22:56 Robin MARX <robin.marx@uhasselt.be>:
>>>>
>>>>> Hello Kazuho,
>>>>>
>>>>> Thanks for the comments, most of which I agree with. The clarification
>>>>> from Lucas elsewhere that the frame could contain an "opaque encoded
>>>>> header" makes things a bit more pleasant for me.
>>>>> I have created some issues on github to further explain some of my
>>>>> points, as I feel some of your comments don't really answer my other
>>>>> reservations.
>>>>>
>>>>> 5) and 7) On the semantics of the used header names and values:
>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/27
>>>>>     My point was more general that the semantics of what you have now
>>>>> do not map (perfectly) to the semantics that are already in-place when
>>>>> talking about browser resource loading and this can create confusion down
>>>>> the road.
>>>>>     Simply clarifying what your "re-defined" blocking means does not
>>>>> help prevent confusion all that much imo.
>>>>>     With your examples at the end as well, for me you are "abusing"
>>>>> the blocking indicator to manipulate sending behaviour, rather than
>>>>> communicating the actual semantics of a blocking resource (a CSS in the
>>>>> document is still render blocking, even if it is less important than one in
>>>>> the <head>).
>>>>>
>>>>
>>>> By saying "communicating the actual semantics of a blocking resource",
>>>> I assume that you are suggesting to send something like "this is a request
>>>> initiated by a style tag in body." Generally speaking, I think signaling
>>>> that sort of signal is a good idea.
>>>>
>>>> OTOH, that's going to be a research project. I am open to defining such
>>>> signals alongside "urgency" that's being proposed by the document. OTOH,
>>>> "switching" to that approach would mean that it'd be less likely that we'd
>>>> have an alternative prioritization scheme adopted when we ship H3.
>>>>
>>>> Therefore, it is my view that what we should do now is encode the
>>>> priority levels that the browsers use today, at the same time assigning
>>>> meanings to each of the priority levels.
>>>>
>>>> We need to assign meanings so that servers can tweak the prioritization
>>>> scheme, because the server needs to know what type of resource is assigned
>>>> to each level.
>>>>
>>>> Consider the case where a server wants to send HTML before CSS (it's
>>>> not a terrible idea, that's what Chrome suggests using the H2 scheme now).
>>>> That'd be only possible when the client uses a signal like "document",
>>>> "blocking". If the signals were named like "highest" or "medium" (or "5" or
>>>> "4"), and without the knowledge of to which of the two HTML and CSS will be
>>>> associated to, it would be impossible for a server to prioritize HTML above
>>>> CSS (or in the opposite order).
>>>>
>>>>
>>>>>     Resolution to this can be as simple as re-naming the values to
>>>>> prevent confusion.
>>>>>
>>>>
>>>> We can discuss about the names.
>>>>
>>>>
>>>>> 6) On the array of use cases / semantics that can be
>>>>> represented/should be representable:
>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/28
>>>>>     You say for example that promoting an image to a hero image is not
>>>>> the intent of the example. I can then ask: how would you indicate a
>>>>> hero-image server to client then? There doesn't seem to be a way in the
>>>>> current setup to (properly) do this.
>>>>>
>>>>
>>>> You can set the urgency. For example, if the server believes that an
>>>> image is as important as the document itself in terms of "using" the
>>>> document, it can set the value of the response header to "Priority:
>>>> urgency=document." That would be the instruction to the H2/H3 terminator
>>>> that the response should be given the same priority level as the HTML.
>>>>
>>>>
>>>>>     You could say that the server simply uses its internal knowledge
>>>>> and sends that image first, but then the whole "this is usable by
>>>>> intermediates"-argument becomes less powerful.
>>>>>     I feel we should communicate as much metadata as possible back to
>>>>> the server to allow it to make complex decisions, if it so chooses. The
>>>>> server can still ignore most of the metadata if it decides to implement a
>>>>> simpler scheme.
>>>>>     In essence, the metadata communicated in the header should, imo,
>>>>> be relatively de-coupled from the concrete implementations at the server
>>>>> (and the current HTTP/2 setups)
>>>>>
>>>>> With best regards,
>>>>> Robin
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 9 Jul 2019 at 03:42, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>>>
>>>>>> Hi Robin,
>>>>>>
>>>>>> Thank you for the comments. My responses below.
>>>>>>
>>>>>> 2019年7月8日(月) 23:56 Robin MARX <robin.marx@uhasselt.be>:
>>>>>>
>>>>>>> Hello Kazuho and Lucas,
>>>>>>>
>>>>>>> Thank you for the draft. Most of this feedback I've given elsewhere
>>>>>>> as well, but to keep everything in one place:
>>>>>>>
>>>>>>> 1) I really like the header-based approach. It's extensible, allows
>>>>>>> us to make progress on H3, is easier to use/understand,
>>>>>>> can be "backported" to H2, has other nice properties which you touch
>>>>>>> upon in the text (intermediates, caching, etc.)
>>>>>>>
>>>>>>
>>>>>> I'm delighted to hear that.
>>>>>>
>>>>>>
>>>>>>> 2) I really dislike the header-based approach. It makes
>>>>>>> re-prioritization a mess. You don't touch upon this (yet) in the draft,
>>>>>>> but the discussion on github (
>>>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/wiki/Roughing-out-reprioritization)
>>>>>>> proposes
>>>>>>> using a separate, special H3/H2 level frame to provide this. This
>>>>>>> just feels -very- dirty to me. The problem is that I can't really think
>>>>>>> of a (much) better solution, other than referring to re-prioritized
>>>>>>> resource A in resource B's headers, which is a whole other can of worms.
>>>>>>> I'm not
>>>>>>> really opposed to using the separate frame if that's the only
>>>>>>> option, but it still takes away some of the nice properties of 1)
>>>>>>>
>>>>>>
>>>>>> While I can see how you feel sad, I am not worried, because
>>>>>> reprioritization can also be HTTP-version-independent in terms of API. The
>>>>>> only difference would be how the prioritization hints (in text) are encoded
>>>>>> as frames.
>>>>>>
>>>>>>
>>>>>>> 3) I really like the switch to "absolute"/"stateless" priority
>>>>>>> levels/semantics (as you're referred to them elsewhere), as opposed to
>>>>>>> building the tree directly.
>>>>>>> This really helps for (partial) server-side (re-)prioritization. It
>>>>>>> does require the server (implementers) to know a bit more about how
>>>>>>> browsers work, but
>>>>>>> I don't really see that as a big issue (given that we provide
>>>>>>> guidance and examples on proper options)
>>>>>>>
>>>>>>
>>>>>> :+1:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 4) I don't feel the current defined priority fields+values cover the
>>>>>>> use cases though. You touch upon this in section 5.2, but I disagree with
>>>>>>> you there:
>>>>>>> For me, these new priority primitives are the core of the proposal
>>>>>>> (not the header-based approach. I would champion these new semantics in a
>>>>>>> frame-based setup as well)
>>>>>>> and imo these should be nailed down (semi-)completely before
>>>>>>> considering this approach. There should probably be more degrees of
>>>>>>> "urgency" \
>>>>>>> (e.g., as Patrick Meenan mentioned things like "deferred" and
>>>>>>> "background'), and there should maybe be something like
>>>>>>> "importance"/"weight"/"precedence"/...
>>>>>>> to be more fine-grained within resources of the same "urgency" level.
>>>>>>>
>>>>>>
>>>>>> I think that adding "deferred" is easy, assuming that we would agree
>>>>>> on the meaning. It would mean the responses that should be sent _after_ the
>>>>>> "non-blocking" responses.
>>>>>>
>>>>>> Re "background," I think we need to discuss how we want to prioritize
>>>>>> them. Should we assign it a yet lower precedence (than "deferred")? Or
>>>>>> should we state that it should be given some amount of bandwidth regardless
>>>>>> of other responses?
>>>>>>
>>>>>> As mentioned in
>>>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/12,
>>>>>>> it might be good
>>>>>>> to look at the existing work on the Priority Hints spec, seeing as
>>>>>>> they probably have already looked at much of this as well.
>>>>>>>
>>>>>>> 5) I am also not sure about the interpretation of the current
>>>>>>> fields. For example, as noted by Patrick (
>>>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/13),
>>>>>>> blocking has a specific meaning and it doesn't map 100% to your
>>>>>>> current text.
>>>>>>>
>>>>>>
>>>>>> I assume this to have been fixed by
>>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/14.
>>>>>> IIUC, Patrick's concern was that "blocks the processing of the document"
>>>>>> seems to be applicable to JavaScript files loaded in <BODY>. In #14 we've
>>>>>> changed the text to "blocks using the document", and I think it's clearer
>>>>>> that urgency=blocking does not necessarily apply to such JavaScript files.
>>>>>>
>>>>>>
>>>>>>> Similarly, what does progressive mean exactly? IIUC JS and CSS can
>>>>>>> be parsed/compiled
>>>>>>> in a streaming fashion in modern engines as well, it's mainly their
>>>>>>> application that is delayed until they are fully available.
>>>>>>>
>>>>>>
>>>>>> When used by a client, it is a signal that indicates if the client
>>>>>> prefers receiving the responses with the bandwidth being distributed among
>>>>>> similar responses, or if it prefers receiving the response one by one.
>>>>>>
>>>>>> Similarly, is a non-progressively encoded jpeg
>>>>>>> counted as "progressive"? How does the browser know if a JPEG will
>>>>>>> be progressive or not when making the request? I feel you've got the
>>>>>>> answers, but the usage of these
>>>>>>> specific terms can make it more difficult to actually use this
>>>>>>> scheme in practice.
>>>>>>>
>>>>>>
>>>>>> For images, a browser should set progressive to 1, when it can assume
>>>>>> that the image can be rendered progressively, as doing so improves user
>>>>>> experience.
>>>>>>
>>>>>> Servers would benefit from setting progressive to 0 for baseline JPEG
>>>>>> images, assuming that sending the first few percent of the file does not
>>>>>> improve user experience.
>>>>>>
>>>>>> Assuming that what I've stated here makes sense, I think it might be
>>>>>> a good idea to clarify these points using examples in the draft.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 6) This is also clear a bit from the example in section 3 (switching
>>>>>>> image from progressive to non-progressive). I -assume- the goal here is to
>>>>>>> do something like a "hero" image,
>>>>>>> which you want to send before other images. However, it feels to me
>>>>>>> that "abusing" the progressive field for this is not the best way to go
>>>>>>> about that.
>>>>>>>
>>>>>>
>>>>>> As stated above, that's not the intent.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 7) Most of this comes together in the fact that I'm having a hard
>>>>>>> time thinking of how to represent existing H2 logic/browser use cases in
>>>>>>> this new scheme.
>>>>>>> E.g., how would you derive Chrome's current "dynamic fifo" from this
>>>>>>> metadata? How would you implement Patrick Meenan's proposed 'ideal' setup
>>>>>>> from these directives?
>>>>>>> Having a couple of concrete examples would help to understand your
>>>>>>> intents and probably also to ferret out some missing pieces.
>>>>>>>
>>>>>>
>>>>>> I agree that talking about mappings is a good idea. I think it would
>>>>>> be something like:
>>>>>>
>>>>>> HTML -> urgency=document, progressive=?1
>>>>>> JS, CSS in HEAD -> urgency=blocking, progressive=?0
>>>>>> images -> urgency=non-blocking, progressive=?1
>>>>>> async-loaded JS -> urgency=deferred, progressive=?0
>>>>>>
>>>>>> There's some wiggle room for fonts and JS, CSS being used inside
>>>>>> BODY. Depending on how important they seem to be, a client can set urgency
>>>>>> to "blocking" (if it essentially prevents the document from being used), to
>>>>>> "document" (if it thinks that the resources are as important as characters
>>>>>> and tags inside the HTML document), to "non-blocking" (if it thinks that
>>>>>> they are not important in terms of using the document), or even to
>>>>>> "deferred" (consider the case of a script tag at the body of the HTML
>>>>>> loading some analytic script).
>>>>>>
>>>>>> If we are to be fine with one particular approach, I think we can
>>>>>> recommend that. But we do not need to struggle to reach consensus on one
>>>>>> particular algorithm, because in the proposed approach, servers can correct
>>>>>> the precedence of mis-prioritized requests under the proposed scheme.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> TL;DR: I see this draft as a combination of two proposals:
>>>>>>> A) a new way to define priority levels/semantics (i.e., "how will
>>>>>>> the resource be used " rather than "when should you send it") : all for
>>>>>>> this!
>>>>>>>          Needs more work though, current draft doesn't (fully)
>>>>>>> support use cases and imo, it should.
>>>>>>> B) sending those new levels via headers instead of frames: many
>>>>>>> advantages, and "feels right"
>>>>>>>         Except for the re-prioritization bit...
>>>>>>>
>>>>>>> With best regards,
>>>>>>> Robin
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 8 Jul 2019 at 15:00, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Today, Lucas and I have submitted the following draft, that defines
>>>>>>>> an
>>>>>>>> HTTP header field for driving prioritization.
>>>>>>>>
>>>>>>>> https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
>>>>>>>>
>>>>>>>> In short, the draft defines an end-to-end HTTP header field called
>>>>>>>> "Priority" for transmitting prioritization hints in absolute values
>>>>>>>> that have meanings. It is much simpler than the prioritization
>>>>>>>> scheme
>>>>>>>> of H2 that communicates and uses a "tree". Not only the client, but
>>>>>>>> also the server can send the prioritization hints, in order to
>>>>>>>> improve
>>>>>>>> the way the responses are prioritized. The prioritization scheme is
>>>>>>>> independent to HTTP versions; it can be used on both H2 and H3 (and
>>>>>>>> also on H1 for providing hints to intermediaries).
>>>>>>>>
>>>>>>>> For more detail, please refer to the draft.
>>>>>>>>
>>>>>>>> Background: back in May in London, the QUIC WG had a discussion on
>>>>>>>> if
>>>>>>>> porting the prioritization scheme of H2 to H3 is the way to go [1].
>>>>>>>>
>>>>>>>> I think there were two major arguments for having something
>>>>>>>> different:
>>>>>>>> * Prioritization scheme of H2 is complex, and porting it to H3
>>>>>>>> increases the complexity [2].
>>>>>>>> * With the H2 scheme, it is hard for the server to tweak the
>>>>>>>> prioritization tree, because clients build their trees in their own
>>>>>>>> ways [3][4].
>>>>>>>>
>>>>>>>> The arguments against were:
>>>>>>>> * Redesigning prioritization for H3 is likely to delay the
>>>>>>>> standardization and time-to-market.
>>>>>>>> * Having something different in H3 is an act of "adding" complexity
>>>>>>>> to
>>>>>>>> HTTP as a whole.
>>>>>>>>
>>>>>>>> This discussion has led us to wonder if there could be a technical
>>>>>>>> solution that resolves the issues of the H2 scheme (see the pro
>>>>>>>> arguments), at the same time minimizing the downsides.
>>>>>>>>
>>>>>>>> And we came up with this proposal. I think the key selling points of
>>>>>>>> the proposal are:
>>>>>>>>
>>>>>>>> * Much simpler thanks to each request carrying an absolute priority
>>>>>>>> value. No need to synchronize a "tree".
>>>>>>>> * Because the priority value sent by the client indicates how each
>>>>>>>> request / response affects the use of other responses (e.g.,
>>>>>>>> "blocking", "non-blocking"), the server can understand the intent of
>>>>>>>> the client and further optimize the delivery order.
>>>>>>>> * Use of the HTTP header field as the conveyer of the priority value
>>>>>>>> allows an origin server to indicate hints to an intermediary that
>>>>>>>> terminates the H2/H3 connections from the client. For example, an
>>>>>>>> origin server can indicate higher precedence for some images that
>>>>>>>> matter more to the user, while giving lower precedence to others.
>>>>>>>> * Another benefit of using an HTTP header field instead of a frame
>>>>>>>> is
>>>>>>>> that prioritization logic becomes independent from HTTP versions.
>>>>>>>> That
>>>>>>>> would help both clients and servers improve the quality of their
>>>>>>>> implementation, as well as fostering website owners fine-tune the
>>>>>>>> prioritization through the use of the Priority response header.
>>>>>>>> * A header-based prioritization scheme can be improved as time goes,
>>>>>>>> as HTTP headers are extensible by their nature. It also means that a
>>>>>>>> header-based design can be rolled out at an earlier stage than a
>>>>>>>> frame-based design.
>>>>>>>>
>>>>>>>> To paraphrase, the header-based design provides simplicity,
>>>>>>>> extensibility, room to evolve, and the possibility to roll out
>>>>>>>> early.
>>>>>>>> This could be the only prioritization scheme for H3. Separating
>>>>>>>> prioritization into a version-independent approach simplifies H3,
>>>>>>>> taking some load away from QUIC WG.
>>>>>>>>
>>>>>>>> Of course, H3 needs to hit the market with a prioritization scheme,
>>>>>>>> we
>>>>>>>> need to agree on that particular scheme. But I think we might be
>>>>>>>> able
>>>>>>>> to agree on the need for a header-based prioritization scheme, that
>>>>>>>> a
>>>>>>>> server can tweak, that uses absolute priorities. If that is the
>>>>>>>> case,
>>>>>>>> I think we have fair chance on agreeing on something pretty soon.
>>>>>>>>
>>>>>>>> To summarize, with the proposed design, I think we have the chance
>>>>>>>> of
>>>>>>>> making prioritization better as we roll out HTTP/3, without getting
>>>>>>>> the standardization process delayed.
>>>>>>>>
>>>>>>>> Please let us know what you think. Thank you in advance.
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/quicwg/wg-materials/blob/master/interim-19-05/priorities.pdf
>>>>>>>> [2] https://github.com/quicwg/base-drafts/issues/2739
>>>>>>>> [3] https://github.com/quicwg/base-drafts/issues/2740
>>>>>>>> [4] In
>>>>>>>> https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0008.html
>>>>>>>> ,
>>>>>>>> Robin points out that server intervention is necessary for best
>>>>>>>> performance.
>>>>>>>>
>>>>>>>> ---------- Forwarded message ---------
>>>>>>>> From: <internet-drafts@ietf.org>
>>>>>>>> Date: 2019年7月8日(月) 21:51
>>>>>>>> Subject: New Version Notification for
>>>>>>>> draft-kazuho-httpbis-priority-00.txt
>>>>>>>> To: Kazuho Oku <kazuhooku@gmail.com>, Lucas Pardue <
>>>>>>>> lucaspardue.24.7@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> A new version of I-D, draft-kazuho-httpbis-priority-00.txt
>>>>>>>> has been successfully submitted by Kazuho Oku and posted to the
>>>>>>>> IETF repository.
>>>>>>>>
>>>>>>>> Name:           draft-kazuho-httpbis-priority
>>>>>>>> Revision:       00
>>>>>>>> Title:          The Priority HTTP Header Field
>>>>>>>> Document date:  2019-07-08
>>>>>>>> Group:          Individual Submission
>>>>>>>> Pages:          9
>>>>>>>> URL:
>>>>>>>>
>>>>>>>> https://www.ietf.org/internet-drafts/draft-kazuho-httpbis-priority-00.txt
>>>>>>>> Status:
>>>>>>>> https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
>>>>>>>> Htmlized:
>>>>>>>> https://tools.ietf.org/html/draft-kazuho-httpbis-priority-00
>>>>>>>> Htmlized:
>>>>>>>> https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-priority
>>>>>>>>
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>>    This document describes the Priority HTTP header field.  This
>>>>>>>> header
>>>>>>>>    field can be used by endpoints to specify the absolute
>>>>>>>> precedence of
>>>>>>>>    an HTTP response in an HTTP-version-independent way.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>>> submission
>>>>>>>> until the htmlized version and diff are available at tools.ietf.org
>>>>>>>> .
>>>>>>>>
>>>>>>>> The IETF Secretariat
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Kazuho Oku
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Robin Marx
>>>>>>> PhD researcher - web performance
>>>>>>> Expertise centre for Digital Media
>>>>>>>
>>>>>>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
>>>>>>>
>>>>>>> www.uhasselt.be
>>>>>>> Universiteit Hasselt - Campus Diepenbeek
>>>>>>> Agoralaan Gebouw D - B-3590 Diepenbeek
>>>>>>> Kantoor EDM-2.05
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Kazuho Oku
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Robin Marx
>>>>> PhD researcher - web performance
>>>>> Expertise centre for Digital Media
>>>>>
>>>>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
>>>>>
>>>>> www.uhasselt.be
>>>>> Universiteit Hasselt - Campus Diepenbeek
>>>>> Agoralaan Gebouw D - B-3590 Diepenbeek
>>>>> Kantoor EDM-2.05
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Kazuho Oku
>>>>
>>>
>>>
>>> --
>>>
>>> Robin Marx
>>> PhD researcher - web performance
>>> Expertise centre for Digital Media
>>>
>>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
>>>
>>> www.uhasselt.be
>>> Universiteit Hasselt - Campus Diepenbeek
>>> Agoralaan Gebouw D - B-3590 Diepenbeek
>>> Kantoor EDM-2.05
>>>
>>>
>>>
>>
>> --
>> Kazuho Oku
>>
>
>
> --
>
> Robin Marx
> PhD researcher - web performance
> Expertise centre for Digital Media
>
> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
>
> www.uhasselt.be
> Universiteit Hasselt - Campus Diepenbeek
> Agoralaan Gebouw D - B-3590 Diepenbeek
> Kantoor EDM-2.05
>
>
>

-- 
Kazuho Oku