Re: signatures vs sf-date

On Tue, Jan 24, 2023 at 12:01 AM Mark Nottingham <mnot@mnot.net> 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?
>
>
I think the problem is that you can't extend any existing field to use a
parameter of Date type. You can't expect the receiver to know about the
extension nor have the parser robustly skip the Data parameter that it
doesn't care about. Constraining the Date type to new fields, or OOB
feature negotiation, seems like a reasonable constraint TBH. Some text to
call out the potential issues might be nice.

Cheers,
Lucas