- From: Watson Ladd <watsonbladd@gmail.com>
- Date: Sun, 5 Feb 2023 21:22:12 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, Lucas Pardue <lucaspardue.24.7@gmail.com>, ietf-http-wg@w3.org
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 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
Received on Monday, 6 February 2023 05:22:35 UTC