- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 6 Feb 2023 09:30:01 +0100
- To: ietf-http-wg@w3.org
On 06.02.2023 06:22, Watson Ladd wrote: > On Sun, Feb 5, 2023 at 9:14 PM Julian Reschke <julian.reschke@gmx.de> wrote: >> >> On 05.02.2023 21:36, Watson Ladd wrote: >>> On Mon, Jan 23, 2023 at 10:48 PM Julian Reschke <julian.reschke@gmx.de> 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
Received on Monday, 6 February 2023 08:30:17 UTC