Structured Fields: handling extension types (#2393)

<https://github.com/httpwg/http-extensions/issues/2393>

With my editor hat on:

We've been discussing this issue for a while and aren't making progress, so broader feedback would be much appreciated. 

I'll attempt to describe it; Julian, please respond if I get something wrong.

In RFC8941, we did not specify any extension mechanism for new types, and required fairly draconic error handling (if only by virtue of specifying precise algorithms, with somewhat clear instructions about how errors should be handled; see previous issue).

Now, we're adding a new Date type. Julian points out that if you use a parser for the new spec (rfc8941bis) for a field that was defined in reference to rfc8941, you've introduced a problem: if something that looks like a date type (beginning with "@") is sent to a 8941 parser, it will result in an error, whereas when you send it to a rfc8941bis parser, you'll get a date.

Personally, I don't believe this is a problem. A field that was defined with reference to 8941 won't be using Date types, and so it's a somewhat pathological case. In the unlikely even that someone generates an 8941 field that looks like a date type and it *is* parsed by an 8941 parser, parsing will succeed, but the value passed to the consuming application will have a type of 'date', not anything recognised by the consumer, so it still should result in an error.

I do agree that we need to caution fields to be precise about what's allowed/expected, and we have a PR:
  https://github.com/httpwg/http-extensions/pull/2396/files

If this *is* a problem, what is a reasonable solution? E.g., must we say that a 8941bis parser MUST NOT be used on a field defined for 8941 (which I believe is a non-starter)? Are there other options?

What are people's thoughts here?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Sunday, 26 February 2023 23:22:49 UTC