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

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

or

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

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