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

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

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

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.

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.

That means that you can parse/serialize all SF-defined fields with
SFbis software.

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

-- 
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 14:40:20 UTC