Re: signatures vs sf-date

> On 24 Jan 2023, at 4:52 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 24.01.2023 01:01, Mark Nottingham wrote:
>> 
>>>> On 24 Jan 2023, at 3:09 am, Julian Reschke <julian.reschke@gmx.de> 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. 

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



> As we can see, this only works
> great until we extend the format.
> 
> Best regards, Julian