Re: signatures vs sf-date

[Julian Reschke <[e-mail]>]

On 24.01.2023 07:36, Mark Nottingham wrote:
>
>> On 24 Jan 2023, at 4:52 pm, Julian Reschke <[e-mail]> wrote:
>>
>> On 24.01.2023 01:01, Mark Nottingham wrote:
>>>
>>>>> On 24 Jan 2023, at 3:09 am, Julian Reschke <[e-mail]> wrote:
>>>>
>>>> What about a dictionary, where you're only looking for "x" (expected to
>>>> be an integer), but the sender adds an extension parameter "y" as sf-date?
>>>>
>>>> A conforming parser (of the current spec) will reject the whole field
>>>> value, and the recipient will not be able to see the value for "x".
>>>
>>> If you are parsing a field that uses Date, its specification will refer to sf-bis, not RFC8941. Therefore, you will need to use an implementation that claims conformance to sf-bis. What's the problem?
>>
>> The problem is that a generic library will not lookup the header definition.
>
> That’s immaterial; it’s the *use* of the library that’s important.

OK, so how will that work with the signatures spec then? (Signing a part
of a SF field that might have an sf-date extension parameter)

>> IMHO an important point of SF is that we can throw fields at the parser
>> without *any* out of band information.
>
> That’s not true; you’ve always needed field specific information (the top level type). This was discussed at length and widely known, so the assertion is a bit surprising.

Correct, you need to know it's a structured field.

What's new is that there might be different types (sf-date supoort or
not, retrofit support or not, further extensions...).

What I'm looking for is a strategy that avoid tons of flags in parsers,
and confusing APIs when using them.

> ...

Best regards, Julian