Re: signatures vs sf-date

[Watson Ladd <[e-mail]>]

On Sun, Feb 5, 2023 at 9:14 PM Julian Reschke <[e-mail]> wrote:
>
> On 05.02.2023 21:36, Watson Ladd wrote:
> > On Mon, Jan 23, 2023 at 10:48 PM Julian Reschke <[e-mail]> wrote:
> > <snip much context>
> >>
> >> What I'm looking for is a strategy that avoid tons of flags in parsers,
> >> and confusing APIs when using them.
> >
> > I'm a little confused by what you want. Is the situation the following:
> >
> > I put in a new kind of field for a new field My-Field. That new kind
> > isn't understood by existing code, implementations that want My-Field
> > to be parsed need to update their parser to parse the new kind.
>  > ...
>
> That's a simple approach. It works well for new code that wants to parse
> new fields.
>
> But what about existing code that just gets maintenance? If the parser
> is updated (without any toggles), it will start accepting syntax it's
> not supposed to accept (for that field).

But we started off with the signature spec potentially mandating
support for -bis. In that case by using signatures you're opting into
the new version. There are no fields where rejection of what's there
is required right?

I feel like I'm missing the difficulty that's supposed to be posed here.

>
> Best regards, Julian
>
>


-- 
Astra mortemque praestare gradatim