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: 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.