- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 24 Sep 2024 17:51:17 -0700
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Francesca Palombini <francesca.palombini@ericsson.com>
OK. I think we've seen enough support to ask for advancement to Proposed Standard, although of course more would be appreciated. CC:ing in Francesca - do we need a formal call in the WG, or is this level of support sufficient to take it* to the next step with the IESG? Cheers, * it = advancing RFC 8297 from Experimental to Proposed Standard. > On 24 Sep 2024, at 5:40 pm, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > > Hey, > > On Wed, Sep 25, 2024, at 00:43, Mark Nottingham wrote: >> I'm CC:ing Kazuho because I talked to him about updating 8297 from Experimental to Proposed Standard at a recent IETF.* >> >> Given the discussion below and responses to it (which I'd characterise as supportive), is anyone willing to submit a draft for the WG to consider here? Otherwise, we can request that the IESG update the status of the RFC without a draft. > > My initial email proposed a few things. To clarify, my interpretation of the thread was that there was some support for changing it from experimental. > > However, there was not support for adding a new client ssignal.which is fine by me. > > There was also some chatter about highlighting deployment considerations about HTTP versions (i.e. it's fine for H2/3 but experience has shown that H1 can be problematic). I tend to agree with that. But I'm not sure the best sort of text to capture it, do we have any other examples of such a consideration? > > Am happy to help things but the natural pen holder would IMO be Kazuho still. > > Cheers > Lucas > >> >> Cheers, >> >> >> * No, I don't remember which one. >> >> >> > On 10 Jun 2023, at 12:09 pm, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: >> > >> > Hi folks, >> > >> > RFC 8297, defining 103 Early Hints was published in 2017. It's been a bit of a sleeper hit, in the last 18 months or so we've seen uptake and deployment on client and server sides. >> > >> > As is natural, we've been gaining experience through deployment. Helping to identify the areas with Early Hints helps, and areas where there might be some possible tweaks. One example is that it isn't always useful to emit a 103 Early Hint in response to every request that is received, because the client's processing context would ignore it. >> > >> > Client Hints (RFC 8942) has some text that deals with considerations we are now learning about Early Hints. For instance, a server could emit an Accept-CH header, and Section 5 of RFC 8942 describes considerations for the cost of sending Client Hints. >> > >> > After some chatter on Twitter the past week, a few different people suggested that something like an Accept-EH request header field might be useful to help clients to indicate when Early Hints are useful or not. If we made this a list of field names, it could allow some tailoring of the emission and content of the hints. >> > >> > My thinking was maybe its time to upgrade Early Hints from experimental and roll in some of the learnings / proposals into the update document. >> > >> > Thoughts? >> > >> > Cheers, >> > Lucas >> >> -- >> Mark Nottingham https://www.mnot.net/ -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 25 September 2024 00:51:23 UTC