Code change:
2. <del> The HTTP fields listed in compatible-fields can usually have their values handled as Structured Fields according to the listed parsing and serialisation algorithms in STRUCTURED-FIELDS, subject to the listed caveats. </del> <ins> The HTTP fields listed in compatible-fields have values that can be handled as Structured Field Values according to the parsing and serialisation algorithms in STRUCTURED-FIELDS corresponding to the listed top-level type, subject to the caveats in compatible-caveats. </ins> <del> The listed types are chosen for compatibility with the defined syntax of the field as well as with actual internet traffic.  However, not all instances of these fields will successfully parse.  This might be because the field value is clearly invalid, or it might be because it is valid but not parseable as a Structured Field. </del> <ins> The top-level types are chosen for compatibility with the defined syntax of the field as well as with actual internet traffic. However, not all instances of these fields will successfully parse as a Structured Field Value.  This might be because the field value is clearly invalid, or it might be because it is valid but not parseable as a Structured Field. </ins> An application using this specification will need to consider how to handle such field values.  Depending on its requirements, it might be advisable to reject such values, treat them as opaque strings, or <del> attempt to recover a structured value from them in an ad hoc fashion. </del> <ins> attempt to recover a Structured Field Value from them in an ad hoc fashion. 2.1. </ins> Note the following caveats regarding compatibility: 3. Some HTTP field values have syntax that cannot be successfully parsed <del> as Structured Fields.  Instead, it is necessary to map them into a separate Structured Field with an alternative name. </del> <ins> as Structured Field values.  Instead, it is necessary to map them into a Structured Field value. </ins> For example, the Date HTTP header field carries a date: Its value would be mapped to: <del> As in compatible, these fields are unable to carry values that are not valid Structured Fields, and so an application using this specification will need to how to support such values.  Typically, handling them using the original field name is sufficient. Each field name listed below indicates a replacement field name and a means of mapping its original value into a Structured Field. </del> <ins> Unlike those listed in compatible, these representations are not compatible with the original fields' syntax, and MUST NOT be used unless they are explicitly and unambiguously supported.  For example, this means that sending them to a next-hop recipient in HTTP requires prior negotiation.  This specification does not define how to do so. </ins> 3.1. <del> The field names in url-fields (paired with their mapped field names) have values that can be mapped into Structured Fields by treating the original field's value as a String. </del> <ins> The field names in url-fields have values that can be mapped into Structured Field values by treating the original field's value as a String. </ins> <del> For example, this Location field </del> <ins> For example, this Location field: </ins> <del> could be mapped as: </del> <ins> would have a mapped value of: </ins> 3.2. <del> The field names in date-fields (paired with their mapped field names) have values that can be mapped into Structured Fields by parsing their payload according to HTTP and representing the result as a Date. </del> <ins> The field names in date-fields have values that can be mapped into Structured Field values by parsing their payload according to HTTP and representing the result as a Date. </ins> <del> For example, an Expires field could be mapped as: </del> <ins> For example, an Expires field's value could be mapped as: </ins> 3.3. <del> The field value of the ETag header field can be mapped into the SF- ETag Structured Field by representing the entity-tag as a String, and the weakness flag as a Boolean "w" parameter on it, where true </del> <ins> The field value of the ETag header field can be mapped into a Structured Field value by representing the entity-tag as a String, and the weakness flag as a Boolean "w" parameter on it, where true </ins> indicates that the entity-tag is weak; if 0 or unset, the entity-tag is strong. <del> For example, this: </del> <ins> For example, this ETag header field: would have a mapped value of: If-None-Match's field value can be mapped into a Structured Field value which is a List of the structure described above.  When a field value contains "*", it is represented as a Token. </ins> <del> If-None-Match's field value can be mapped into the SF-If-None-Match Structured Field, which is a List of the structure described above. When a field value contains "*", it is represented as a Token. </del> <ins> Likewise, If-Match's field value can be mapped into a Structured Field value in the same manner. </ins> <del> Likewise, If-Match's field value can be mapped into the SF-If-Match Structured Field in the same manner. </del> <ins> For example, this If-None-Match field: </ins> <del> For example: </del> <ins> would have a mapped value of: </ins> 3.4. The field values of the Cookie and Set-Cookie fields COOKIES can be <del> mapped into the SF-Cookie Structured Field (a List) and SF-Set-Cookie Structured Field (a List), respectively. </del> <ins> mapped into Structured Fields Lists. </ins> In each case, a cookie is represented as an Inner List containing two Items; the cookie name and value.  The cookie name is always a

Related discussion:
text: Or it might reject all mapped field names from A, on grounds that it must have been invalid. Moreover, "intermedaries" has to be intepreted very loosely. Every processing step in the entire HTTP pipeline needs to carefully manage these alternate names. This seems a disaster waiting to happen. I think I'm now convinced this is the only plausible option. Regarding "many contexts" and "some", do you have use cases in mind here? I saw draft-nottingham-binary-structured-headers, but I gather there are others? Something to keep in mind is that this draft intentionally punts figuring out the negotiation design to the future anyway. That means this is also the more flexible option. If we define , etc., now, we have permanently committed ourselves to this security problem. If we decline to define now, we can still choose. We can always define the parallel field names later, should something that needs them come up. (Of course, I'd raise the security problem again, but it'll be easier to reason about with a concrete use case! )
I guess this raises another question: how do we handle mapped field values that cannot be represented in the underlying text representation? Given how many intermediaries and intermediary-like constructs are involved in HTTP pipelines, and given how every HTTP system today uses the current syntax, I suspect mapped values that cannot be represented in the original syntax have to be treated as an error. Which means I think we need to go through the exercise of writing SF-to-text converters for each mapped field and then narrowing the allowed inputs until that converter is infallible.
It sounds like removing the field names is the best path forward. Yes, for those, the application using retrofit needs a fallback, just as it does for compatible fields. If that isn't obvious from the document, it should be clarified -- perhaps in a new 'Using Retrofit Fields' section.
I could very well be incorrect, but it sounds we want to have alternatives per each hop. Does that mean that these mappings would be best represented by ther per-hop pseudo headers that we have in H2 and H3? Not that I feel that doing so would be the best option, though.
Ooh yeah, per-hop is a good way to think about this! For pseudoheader vs. something else, I suspect it'll depend on use?