Re: Structured Fields: handling extension types (#2393)

--------
Julian Reschke writes:

> Yes (although I believe that a backwards incompatible change would be a
> very very bad idea).

I fully agree.

> > That means that you can parse/serialize all SF-defined fields with
> > SFbis software.
>
> Not really. A spec might say that extension parameters can be added and
> will be ignored when not understood ("must ignore", not uncommon,
> right?). An SFbis parser will accept those, an SF parser will fail.
> That's an interop problem.

If the specification of the field says it is SF, then a well formed
field cannot contain a sf-date anywhere, extension or not.

If somebody tries to define an extension with sf-date to that field,
they will have to redefine the field to be SFbis first, since SF
simply does not have sf-date.

If you choose to parse some particular SF field with a SFbis parser,
and that parser returns sf-date, then it is the responsibility of
your code, as a consequence of your choice to use a SFbis parser,
to detect /any/ sf-date elements in the return value, even if they
are in extensions you dont know about, and reject the field if
you find any.

I fully expect SF-software to solve that problem for you, by offering
both SF and SFbis, either as separate entrypoints, or as a
parameter to indicate which SF-RFC the field with.

> > But we give no assurances that SFter, should it ever happen, will
> > be equally smooth.
>
> But maybe we should. It's already hard enough to convince spec authors
> to use SF.

It makes no sense to give such an assurance, however weak, when we
have no idea why anybody would even propose a SFter in the first
place.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Monday, 27 February 2023 15:22:06 UTC