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: we could try to define what future extensions mean for specs that are written for the current version of the spec My concern with the current state of things is that a parser implementation will need a set of flags, and each new flag will add complexity not only with respect to the parsing code, but also to API and documentation (how do I get the user to select the right mode, or will she always just select all extensions - and why would that be bad...?), and to test coverage (we need a parametrized test suite, right?).
I think that this is a reasonable outcome. Using sf-date before a recipient is prepared to process it can result in the field being dropped. Now, this isn't entirely satisfactory, because an extension within a field will be dropped by a date-unaware SF parser, but that risk can be documented. Extensions to structured fields defined against RFC 8941 probably don't get to use dates then, at least until sf-date-aware parsers are widely enough deployed that the risk is negligible. Documenting this as a caveat is worthwhile; it's only the current set of structured fields that are affected in this way. I don't think that a flag is necessary for sf-date. (I haven't thought much about your retrofit points just yet, I just wanted to put this there as a potential way forward for sf-date.)
Just to clarify: any of these three? Which means that updated parsers will accept sf-date, and thus not be compliant to 8941 anymore. (I'm personally ok with that, but we really should be clear about that)
Yes, that had been my assumption -- a recipient is always going to need to check whether or not the types it recieves are the ones it expected; e.g., if a field is defined to only allow Strings and it receives an Integer, it needs to deal with that. Same for Dates, in this case. I don't think that non-compliance has any significant impact, as discussed above. Happy to clarify it, but I seriously doubt whether it will have any real-world impact to do so. In the case where a field that specifies (or allows through extension) a Date, the appropriate spec needs to refer to the updated RFC so that an updated parser is used. The extension case is a little less obvious, so we're talking through the text to highlight that now.