W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2023

Re: Structured Fields: strict error handling (#2399)

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 27 Feb 2023 08:20:51 +0000
Message-Id: <202302270820.31R8KpGL038465@critter.freebsd.dk>
To: Mark Nottingham <mnot@mnot.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham writes:
> <https://github.com/httpwg/http-extensions/issues/2399>
> [...]
> I made an attempt here:
>   https://github.com/httpwg/http-extensions/commit/167e840515a

I agree that the last comma of 4.2 is problematic.

As I understand it, the use of "not allowed" instead of SHALL NOT
means that it has no formal power in the first place.

Even if we solved that /nothing/ we can write in SF(bis), can prevent
field definitions of the general form:

    "Attempt parsing as sf-foo, if that fails do the following: ..."

Where "..." can be anything, including:

    "do this text-processing, then try sf-foo again".

So I see three possible ways we can go, in my order of preference:

A)  We can delete the last comma of 4.2.

B)  We can make it a strong warning:

      [...] and loosening this requirement in a field definitions will make
      everybody either ignore your field, rather than implement a bespoke
      parser for it, or hate your guts until we run out of IPv6 addresses.


C)  We can introduce some kind of "compliance-mark":

      [...] and fields defined as »100% SF(bis)-serialized™« SHALL NOT
      loosen this requirement in any way.


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 08:21:05 UTC

This archive was generated by hypermail 2.4.0 : Monday, 27 February 2023 08:21:05 UTC