Re: Structured Fields: handling extension types (#2393)

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