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: Sorry for noticing this so late. I don't think the security considerations of in retrofit work out. (Also CC NAME who is much better at web security than me.) If we introduce two ways to spell some field, we need to worry about whether this can allow various issues when sender and receiver don't agree on what's going on. The draft mostly leaves this to the future, but it does include some about this: This seems to put the onus on the sender, not the receiver. If you don't know the receiver accepts the alternate representation, you can't send it. It includes no corresponding receiver obligation, I guess on the assumption that if you see SF-Cookie, you can assume the sender meant it? I don't think that works. In a browser, the sender is a combination of browser logic (which has the final say) and JS (with a complex trust relationship). The browser logic specifies some which JS cannot set. Other HTTP systems have similar splits: an HTTP serving frontend may get fields from a CGI script or act as an intermediary, but it cannot allow the downstream code to specify fields like . These rules typically look like a blocklist with the default behavior to pass fields through. All this is to say, browsers won't let JS set the field directly, but setting is perfectly fine, up to CORS rules. A receiver may see that text and incorrectly assume that processing is fine, breaking some cookie invariants. Or vs , which will break some sites' CSRF processing. Beyond just blocklists, a retrofit-unaware HTTP cache that processes caching fields but passes through other fields will likely make a mess of the mapped caching fields. If we prefixed the names with , that would at least meet the browsers' rules, though I worry it'll still break other intermediaries. It's also a little unsatisfying of a fix. We could say that a receiver cannot process these either unless it's received some explicit negotiation that the sender knows about this. That's vague and unspecified, but probably would work, depending on what the intent is here. This is a bit handwaivy because I'm not sure what the use cases are here. But if we require explicit sender and receiver negotiation, it's unclear what we're getting out the parallel field names in the first place. It seems to me that's where all this risk comes from.