Original text:
For example, a fictitious Foo-Example header field might be specified as:  3. This section defines the abstract types for Structured Fields, and

Reviewer comments:
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? 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. 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. That means that rejection by a receiver isn't guaranteed, but it offers a path toward upgrade at some point (we could decide, collectively, that it is OK to use sf-date in an extension for an older field definition. We might do that based on adoption rates for the new SF version, and memorialize it with an update to the field, but we wouldn't necessarily need to pick a new field name in order to avoid the compatibility risk (we'd just be managing the probability of it happening).
It would be interesting to see more feedback from people defining APIs for SF support...
How does the PR imply that?
Well, if a spec refers to an SF-shaped field based on RFC 8941, parsing it with an 8941bis parser (allowing sf-date) would be incorrect. RFC 8941 requires draconian error handling, after all. When we defined RFC 8941, we consciously specced draconian error handling + no extension points (until the spec is updated), so that's the consequence. I fear that we are in a very fundamental disagreement about how extending the structured field syntax is supposed to happen given the constraints we put into 8941.
Perhaps it would be best to take this to the list. I don't see anyone else who yet shares your point of view, so it would be good to circulate it with a wider audience.
(with two nits)

Revised text:
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