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

Mark Nottingham writes:
> <>
> [...]
> I made an attempt here:

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