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

Unwrapping the proposal:

> If parsing fails -- including when calling another algorithm -- the entire field value MUST be ignored (i.e., treated as if the field were not present in the section), unless the field definition specifies another behavior. It is RECOMMENDED that fields not modify this requirement, as it enhances interoperability and safety.

Can you speak more about the rationale behind this approach?

I generally see SF as middleware in field processing.  That is, it performs a transformation from bytes into the abstract SF data model.  Field-specific processing can then be limited to describing how to consume an Integer or Dictionary or whatever.  This is a distinct advantage over classic field processing, where the entirety of processing is field-specific.

A design choice we made with SF was to be strict.  That is, if SF processing fails, no output is produced.  This change allows fields to dabble: they can try SF processing and then back out if it doesn't work.

I can see how that might work for retrofitting onto something like Cache-Control, but isn't it already the case that Cache-Control, following legacy HTTP rules, can opt to use SF however it chooses?  That is, it can say "try SF, and if it produces no output, try this instead?"  Now, we might not want new fields to do that, but if we're retrofitting and we want to index on compatibility, dabbling might be the right answer.

RFC 8941 carries a massive assumption, which is that fields will choose to use SF exclusively and only deal with what SF produces.  This includes the failure cases where it produces nothing at all.  This small change undoes that just a little bit, which is - I believe - why Julian is uncomfortable with it.  So maybe rather than a small targeted change, this needs a change in framing and structure:

1. Define the SF transform and data model.
2. Describe how we would prefer SF be used for new fields.

Looking at the draft, that's not really a big change in text.  It mostly touches the introduction, which implicitly couples these two concepts.

Received on Monday, 27 February 2023 00:00:41 UTC