Re: 103 Early Hints

As the developer who implemented Early Hints in the Go standard library and
the Caddy web server, I also support moving it out of experimental.

Cheers,

On Wed, Sep 25, 2024 at 3:35 AM Kenichi Ishibashi <
ishibashi.kenichi@gmail.com> wrote:

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