Re: 103 Early Hints

As a browser developer who implemented Early Hints, I support moving it out
of experimental.

Thanks,

2024年9月25日(水) 9:54 Mark Nottingham <mnot@mnot.net>:

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