- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 26 Aug 2022 13:18:14 +1000
- To: Tommy Pauly <tpauly@apple.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Roberto Polli <robipolli@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On 24 Aug 2022, at 1:32 pm, Tommy Pauly <tpauly@apple.com> wrote: > > - If we expect to have binary header values in a future version (HTTP/4, say), Aside - I think this can be negotiated as an extension, rather than requiring a full new version. > we’ll have the same intermediary scenarios we have today with converting between versions. Correct. > Certainly we could use the rules to correctly convert between the date-text version and the numeric version, but it would be more complexity than just moving an integer value over (and handling an @ or marking a flag), and buggy implementations may lead to values being closely translated but not perfectly translated. Absolutely -- and that's true for parsing existing dates and translating them into an integer as well. > - If the benefit we’re providing by using the date-text format is to make things more easily human readable, I’ll likely want to have the choice to view the date while debugging in whatever timezone I prefer and using whatever date presentation format I prefer. So, the tools will ideally be translating the value anyway. Possibly, although as Julian says, many will be looking at the 'raw' or 'default' text. Another factor that I've been keeping very much in mind is adoption -- whether the format's readability in HTTP/1.1 will affect decisions as to whether to adopt the type (e.g., HTTPAPI). That's hard to predict in the long run, unfortunately. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Friday, 26 August 2022 03:18:35 UTC