Code change:
transformed into an underlying data model which is then mapped into that defined by Structured Fields. <del> Note that while implementations can parse and serialise compatible fields as Structured Fields subject to the caveats in compatible, a sender cannot generate mapped fields from mapped and expect them to be understood and acted upon by the recipient without prior negotiation.  This specification does not define such a mechanism. </del> 1.1. <ins> Retrofitting data structures onto existing and widely-deployed HTTP fields requires careful handling to assure interoperability and security.  This section highlights considerations for applications that use Retrofit Structured Fields. While the majority of field values seen in HTTP traffic should be able to be parsed or mapped successfully, some will not.  An application using Retrofit Structured Fields will need to define how unsuccessful values will be handled. For example, an API that exposes field values using Structured Fields data types might make the field value available as a string in cases where the field did not successfully parse or map. The mapped field values described in mapped are not compatible with the original syntax of their fields, and so cannot be used unless parties processing them have explicitly indicated their support for that form of the field value.  An application using Retrofit Structured Fields will need to define how to negotiate support for them. For example, an alternative serialization of fields that takes advantage of Structured Fields would need to establish an explicit negotiation mechanism to assure that both peers would handle that serialization appropriately before using it. See also the security considerations in security. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in

Related discussion:
text: Giving alternate names interferes with pass-through logic across the pipeline. Maybe we can get a more robust story, inspired a bit by (I'm just assuming this is one of the main use cases here) is to say: The text representation of is what it is. If this part of the system uses the text form, use the existing syntax The structured field representation of is this mapped thing. If this part of the system uses structured fields, use that syntax At boundaries where forms change, convert. We need to be a bit careful about fallibility here, but perhaps: Conversion from text to other forms is allowed to fail, since you can just fallback to the text form. Conversion from other forms to text probably needs to be stricter? The difference between mapped and normal fields is the structured field and text representations don't directly align, so they need to be treated a bit special Like I said, this is handwaivy and definitely incomplete. But it feels to me like something in this might be more sound. It makes it more obvious we have to be sure what representation we're using at each layer and there's no risk of one side thinking something is a generic header and another thinking it's an alternative representation of a special header.
This seems like a plausible risk to me. I'm not as familiar with non-browser use cases, but I can certainly imagine confusion that would result from clients being able to create mismatches between and . I can imagine ways to deal with this in browsers (in addition to NAME suggestions, we could add as a , just as we've done for and ). It's unclear how helpful that would be for non-browser usecases.
Main nuisance with prefix is that, on the receiver side, you don't know a priori if the client is an updated browser, which knows about the prefix, or a preexisting browser which does not. I suppose you could do UA sniffing, but let's not design a system that requires UA sniffing to work if we can help it! :-)
That's fair. would be safe without a change to Fetch. Still, given my expectations about the current deployment of mapped fields, I think we could reasonably get ahead of them in the browser world. Not at all sure about the rest of the ecosystem...
I like the direction that if you've already negotiated support, you could just replace the legacy headers with their spiffy (SFfy?)