Code change:
For example, a fictitious Foo-Example header field might be specified as: <ins> Note that because the definition of a Structured Field references a specific RFC for Structured Fields, the types available for use in its value are limited to those defined in that RFC.  For example, a field whose definition references this document can have a value that uses the Date type (date), whereas a field whose definition references RFC 8941 cannot, because it will be treated as invalid (and therefore discarded) by implementations of that specification. Also note that this limitation also applies to future extensions to a field; for example, a field that is defined with reference to RFC 8941 cannot use the Date type, because some recipients might still be using an RFC 8941 parser to process it. However, this document is designed to be backwards-compatible with RFC 8941; a parser that implements the requirements here can also parse valid Structured Fields whose definitions reference RFC 8941. The effect of upgrading a Structured Fields implementation is that some field values that were invalid according to RFC 8941 might become valid when processed.  For instance, though it would not be valid for a field defined against RFC 8941, a field might include include a Date value.  An RFC 8941 implementation would reject the entire field, whereas an updated Structured Field implementation might permit the value.  In some cases, the resulting Date value will be rejected by field-specific logic, but values in fields that are otherwise ignored (such as extension parameters) might not be detected and the field might subsequently be accepted and processed. </ins> 3. This section defines the abstract types for Structured Fields, and

Related discussion:
text: Regarding retrofit -- I don't think preprocessing is seriously considered by anyone at this point; the question is whether we make it a flag in sf-bis, or 'monkey patch' the spec from afar, just for the purpose of retrofit. So far we seem to be leaning towards the former, but there are risks (as discussed). Note that if we have flags, they're in the parser, but they needn't be exposed to people doing end-user parsing of fields. Or, as discussed elsewhere, we could decide to drop those compatibility fixes. Let's keep discussion of that on issue . I'm not unsympathetic here. I was much more excited about a Date that looked developer-friendly in HTTP/1; now I fear it's not going to be adopted (the HTTPAPI is very lukewarm about it).
Ok, here's an implementation question. In the branch for sf-date, URL currently handles dates as extensions of integers. So somebody expecting an integer would actually see an integer, unless when aware of the new type URL (extending NumberItem). Would you consider that a problematic approach? (I got there just because of code re-use from integers, AFAIR it was not a conscious decision (yet)).
It'd be problematic if the implementation didn't have any way of distinguishing Dates from Integers, because that would be impossible to round-trip -- the serialiser wouldn't know which form to pick.
See linked PR.
Well, if the caller knows about the new types, it will be able to check. The serializer does know about the new types, so round-tripping would happen correctly even if the user of the API wasn't aware of the extension.
Ok, the PR makes things clearer, in that: you can't use sf-date, even inside an extension parameter, unless you update the spec defining the field, and code calling an SF parser will now have to specify which version of SF to use (that's ok with just the three top-level types and one additional flag, but it will get messy if more extensions are being defined)
I would like to avoid the second if possible. That is, you can process with a newer SF version, but you can't produce with a newer SF version.