Re: signatures vs sf-date

[Julian Reschke <[e-mail]>]

On 06.02.2023 06:22, Watson Ladd wrote:
> 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

Hm, no. My request was that the spec just states whether implementations
are *allowed* to support future extensions.

> ...

Best regards, Julian