Code change:
Abstract <del> This specification nominates a selection of existing HTTP fields as having syntax that is compatible with Structured Fields, so that they can be handled as such (subject to certain caveats). </del> <ins> This specification nominates a selection of existing HTTP fields whose values are compatible with Structured Fields syntax, so that they can be handled as such (subject to certain caveats). </ins> To accommodate some additional fields whose syntax is not compatible, <del> it also defines mappings of their semantics into new Structured Fields.  It does not specify how to negotiate their use. </del> <ins> it also defines mappings of their semantics into Structured Fields. It does not specify how to convey them in HTTP messages. </ins> 1. Structured Field Values for HTTP STRUCTURED-FIELDS introduced a data model with associated parsing and serialization algorithms for use by new HTTP field values.  Fields that are defined as Structured Fields <del> can realise a number of benefits, including: </del> <ins> can bring advantages that include: </ins> Improved interoperability and security: precisely defined parsing and serialisation algorithms are typically not available for

Related discussion:
text: new equivalents using the same names, and if you haven't negotiated support then you have no business sending these variants and expecting them to work. Of course, that means this draft probably can't get away with "We don't define a way to negotiate this, but you do that."
I think we'd avoid needing "OUGHT TO" in that model. That model is more explicit that these are two incompatible representations of these fields. The negotiation requirements become more straightforward, I think: E.g. draft-nottingham-binary-structured-headers meets this requirement because you set a flag on the message, and gates usage on a setting. A hypothetical SF-based HTTP API would also meet this requirement because it's unambiguous that takes some in-memory structured field representation.
Hey David, Yes, I've been somewhat concerned about the potential issues in this area for a while. Minting new field names for the alternative forms was the initial approach, but I was half expecting someone to raise this issue :) One thing: No; the assumption is that a recipient sees SF-Cookie, they'll ignore it unless they've positively opted into it meaning something. Perhaps, as you point out, that should be more explicit -- e.g., say that these fields MUST NOT be processed unless the sender does [magic]. Making sure that evidence of [magic] is propagated properly may be tricky, though. I could also see removing the new field names. That should work for many contexts, although I suspect it might make handling the new forms difficult in some. Prefixing with doesn't seem very attractive to me.
Ah interesting. So I guess the middle option, "require explicit negotiation on the receiver" was actually the intended interpretation. That's not how I read the draft. It says "implementations are prohibited from generating such fields unless they have negotiated support for them with their peer" without saying anything about the recipient's responsibilities. So it sounds like, at minimum, we should update the draft. Getting that right in the presence of a chain of intermediaries is quite subtle however. Suppose we go A -> B -> C and both B and C support mapped fields, but A does not. B must be careful not to forward along a mapped field from A. E.g. it might decline to advertise mapped field support to C because A doesn't support it.