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: It's likely because the field is ignored when parsing fails, but 8941 s 2 allows a field to specify other error handling behaivour.
How so? 8941, Section 4.2 says:
Section 2 has a bit more nuance:
You refer to: ? My reading is that this applies to the preceding text about what happens when parsing does not fail, but additional constraints are not met. If this is not the case, we should consider this to be an inconsistency in requirements and treat it as spec bug. EDIT: opened URL
As pointed out on list, we need to warn people against just using Date as an extension in a field that was defined using 8941.
The warning helps, but it IMHO does not address the larger extensibility problem we have.
NAME can you articulate that (here or in another issue, if it's substantially different / larger)?
I'll try. The main selling point for structured fields IMHO is "a unified parser". You know that a field value is SF-shaped, drop it into the parser, and get a more or less self describing data structure. Great. Now once we add extensions to SF, this get's harder. Starting with the the current proposals: A recipient of a field does not only have to know which top-level field type to parse for, but also whether to switch on support for SF-date or not. Or we would need to say that even when a spec defines a field using 8941, it still's ok to parse it with an sf-date-enabled parser. In that case, it would be up to the recipient to either ignore sf-date-typed extension parameters (if the field definition already allowed future extension), to convert them to an integer, or to reject the parsing result altogether. Retrofit parsing flags: I hope we have consensus that preprocessing values before passing them into the parser will be fragile. So a retrofit-supporting SF parser will either need modes, or the wire syntax for SF could be relaxed so that retrofit would need no new mode. The common concern here is that SF in theory is simple to extend, the process is extremely hard both process-wise and deployment-wise. Ideas: we could simply avoid doing extensions; sf-date is only a "lipstick" flag so that tools can switch on a special display mode - maybe we don't really need it?