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

> On 27 Feb 2023, at 11:00 am, Martin Thomson <mt@lowentropy.net> wrote:
> 
> 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.

Well, that's one option (which someone using retrofit might exercise, as you point out below). The more common one -- and what I think we discussed during 8941 -- was that ignoring the field might not be appropriate, depending on its semantics; e.g., it could have security implications, and the safest thing to do would not be to pretend the field doesn't exist, but to reject the message outright.

There's massive handwaving here, of course, because it's hard to predict what scenarios people use SF in. In my recollection, we intentionally didn't want to tie people's hands too much, because we didn't want to try to predict the future.

> 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?"

It depends on what you're using it for. Keep in mind that retrofit does *not* say that (eg) a cache can substitute a SF parser for its CC parser.

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

I don't think that assumption is true, and it certainly isn't explicit in the spec. I certainly had retrofit in mind from the start.

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

Those concepts are already there. What more do you want to see?

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

Received on Monday, 27 February 2023 03:52:14 UTC