Code change:
An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes in HTTP. <del> Conformance includes both the syntax and semantics of protocol elements.  A sender MUST NOT generate protocol elements that convey a meaning that is known by that sender to be false.  A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules.  Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message). </del> <ins> A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules.  Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message). Conformance to HTTP includes both conformance to the particular messaging syntax of the protocol version in use and conformance to the semantics of protocol elements sent.  For example, a client that claims conformance to HTTP/1.1 but fails to recognize the features required of HTTP/1.1 recipients will fail to interoperate with servers that adjust their responses in accordance with those claims. Features that reflect user choices, such as content negotiation and user-selected extensions, can impact application behavior beyond the protocol stream; sending protocol elements that inaccurately reflect a user's choices will confuse the user and inhibit choice. When an implementation fails semantic conformance, recipients of that implementation's messages will eventually develop workarounds to adjust their behavior accordingly.  A recipient MAY employ such workarounds while remaining conformant to this protocol if the workarounds are limited to the implementations at fault.  For example, servers often scan portions of the User-Agent field value, and user agents often scan the Server field value, to adjust their own behavior with respect to known bugs or poorly chosen defaults. </ins> 2.3.

Related discussion:
text: -- URL This doesn't seem to be enforceable in any way. This isn't really talking about whether the syntax is valid, but about the semantics, so it's easy to disavow knowledge of falsehood (my browser isn't necessary aware that me typing "the sky is pink" is false). I think that it might be better to simply observe that it is contrary to function - and possibly interests - of a sender to generate protocol elements that convey semantics that are incorrect or contrary to the interests of the sender. Normative language implies interoperability failure if it is ever violated, and I don't think that is the case here.
It is enforceable. If a sender communicates a syntactically valid construct that is deliberately misleading, then the recipient's behavior in response will be equally confusing to all parties. We saw exactly that both in the deployment of HTTP/1.1 and in the early deployment of DNT. Both resulted in interop failure, and both failures were only corrected after the standards were enforced by recipients refusing to accept invalid signals.
We might be talking past each other. NAME - could you give us a concrete example that this text is trying to rule out?
Or, for example, P3P, where people deliberately set false and misleading policies so that browsers wouldn't complain. Roy, it's a nice thought, but this is the kind of regulation that's done by law, not architecture.
Both laws and RFCs are defining standards of conduct. The difference with laws is sovereign enforcement, not social versus technical. In any case, this has been true of HTTP implementation (Apache httpd, for example) since 1996. A server will check for compliance based on User-Agent version match and ignore protocol signals that are known to be false or at least unreliably implemented by that sender. Browsers do the same for some servers that deliver default Content-Type settings by mistake. We consider the workarounds to be standards-compliant because of this MUST NOT. And, as I said, we enforce that ALL OF THE TIME.
Discussed at Feb 21 interim; add context to help readers understand why this requirement is here / important. NAME to PR.
Context... ? Then add an example, probably a fictitious one out of deference for the sensitivities in all the truly good examples.
This works very nicely. Thanks Roy.