- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 27 Feb 2023 14:40:05 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: ietf-http-wg@w3.org
-------- 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