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

On 27.02.2023 15:40, Poul-Henning Kamp wrote:
> --------
> Julian Reschke writes:
>> On 27.02.2023 08:38, Poul-Henning Kamp wrote:
>
>> Martin noted that if we ever extend SF, the semantics of previously
>> accepted values should not change. I thought that was evident, but maybe
>> we really need to state that as a requirement on any extension spec.
>
> I see what you are misunderstanding now...
>
> SFbis is not an "extension spec", and there will be no "extension
> specs" for SF (as in: "This adds sf-bla") - that follows directly
> from the strictness principle.
>
> Each revision of SF is free-standing and self-contained.

I agree that these are good principles. But if SFbis extends SF by
adding sf-date, people will call it an extension; like it or not :-).

> If your header is defined to "SF version N", it must be parsed and
> serialized according to that version.

Yes.

> It /may/ be that "SF version N+1" is backwards compatible, or it
> may not be the case:  That will be a judgement call for when that
> version is proposed and approved.

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

> In this case, SFbis /will/ be backwards compatible, because no
> element of a SF-defined field can have '@' as first character, so
> there can be no valid SF fields which could be interpreted differently
> by SFbis implementations and because SF-defined fields cannot not
> contain an sf-date element, mis-serialization is also impossible.

Yes.

> 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.

> (It also means that SF software can be used on SFbis-defined fields,
> provided the definition does not allow for sf-date elements.)
>
> 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.

Best regards, Julian

Received on Monday, 27 February 2023 14:50:19 UTC