- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 27 Feb 2023 14:45:33 +0100
- To: ietf-http-wg@w3.org
On 27.02.2023 08:38, Poul-Henning Kamp wrote: > -------- > Mark Nottingham writes: >> <https://github.com/httpwg/http-extensions/issues/2393> >> > >> In the unlikely even that someone generates an 8941 >> field that looks like a date type [...] > > s/unlikely/impossible/ > > No syntactic element in 8941 can begin with "@". > >> field that looks like a date type and it *is* parsed by an 8941 parser, > > s/8941 parser/8941bis parser/ ? > >> If this *is* a problem, what is a reasonable solution? > > There is no problem to solve. That's not helpful. We can of course choose the simplest possible solution: do not extend SF at all. Ever. In which case we should stop the work on sf-date. It would also be somewhat inconsistent with what we said when we agreed on the current spec ("we can always extend it later"). Martin noted that if we ever extend SF, the semantics of previously accepted values should not change. I thought that was evident, but maybe we really need to state that as a requirement on any extension spec. But if we do accept that extensions will happen, we should agree on what it means for specs using SF, and also what it means how that will be reflected in APIs. Mark made a proposal that IMHO removes a normative requirement of the base spec wrt error handling; the fact that we disagree here clearly shows that there is a problem to solve. Best regards, Julian
Received on Monday, 27 February 2023 13:45:50 UTC