Re: Structured Fields: handling extension types (#2393)

On Mon, Feb 27, 2023, at 10:22, Mark Nottingham wrote:
> 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

I think that we need more than that change.

This implicitly says that if you defined field X with RFC 8941, then you have to retain an RFC 8941 parser always.  That's not consistent with what you are saying in this email though.

I agree that unexpectedly successful parsing is the only way in which additions to the model manifest.  So we should try to be clearer:

1. We should promise to try to limit changes to the format to those that expand what is accepted.  That is, we should attempt to provide a backwards-compatibility assurance so that fields conformant to older specifications always successfully parse with implementations of newer specifications.

2. We should explain that when extensions to the core are made, that will result in some fields that were NOT conformant with an older specification being parsed successfully by implementations of newer specifications.

3. We should explain that this means that field-specific processing could be exposed to data that it was not previously exposed to.  In the case where the extension is a new data type, like sf-date, there are two scenarios to consider:

   a. The new data type appears where another type was expected.  Existing fields should have specified what types are permitted in most cases and so the error should be detected.  In general, we encourage fields to reject the entire field in these cases, which will ensure that the overall outcome is unchanged.  Fields that diverge from this advice get what they get.

   b. The new data type appears in a place that was previously ignored.  This is where things suddenly start working.  This case need only be acknowledged.

   In the case where the extension changes the content model, we'll need to be a lot more careful.  I don't think that there is an easy answer here, so we'll just have to do the work to ensure that it is safe.  Take the hypothetical case where we allow integers to take a larger range of values.  In that case, there might be field-specific code that packs the integer into a store that was previously big enough, but would now overflow or fail.  A failure might be OK if it caused the entire field to be discarded, but a partial failure or overflow is likely to be unsafe.

I don't want to rule out extensions where extensions make sense, but I don't think that the proposed text covers this sufficiently.

Received on Monday, 27 February 2023 00:16:11 UTC