Code change:
9.1. The "Connection" header field allows the sender to list desired <del> control options for the current connection.  In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message. </del> <ins> control options for the current connection. </ins> When a field aside from Connection is used to supply control information for or about the current connection, the sender MUST list <del> the corresponding field name within the Connection header field.  A proxy or gateway MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, </del> <ins> the corresponding field name within the Connection header field. Intermediaries MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, </ins> remove any header or trailer field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself (or replace it with the intermediary's own connection

Related discussion:
text: NAME the ABNF is not the source of truth; as discussed, it's the recommended generated form. We have prose in that we use to do things like explicitly allow LFs to be separators and folding to be performed. Given that there is confusion, interoperability issues and security issues around bare CRs, a clear requirement seems proportional - especially when the ABNF does not specify error handling. I could see an argument to downgrade the requirement relating to generation to a note that it's not allowed, and I could see broadening the language in semantics to say that CRLF and LF are also not allowed.
For field values (Semantics), we clarify that these are illegal to generate. For recipients, we can say that for error handling, rejecting or converting to SP is common. Not sure what else needs to be said in Messaging.
I think that the security aspect justifies a new requirement; how about "MUST either reject or remove; suggest replacing with SP"? I was thinking about outside the field values -- mostly in the request-line and status-line. That said, I agree it's much less of a concern there, and I'm OK with dropping it if you think it's not worth it. I'll update the PR if you think the above is workable.
s/MUST either reject or remove/MUST either reject or replace/ ...I guess. Yes, that sounds right to me; although there might be pusback on the MUST (me neutral). The part for Messaging I believe deserves a separate issue and discussion.
NAME I'll make a change note in Messaging. WRT Semantics, the adjacent text about folding effectively deals with LF and CRLF. If you want to go to the trouble of separating into two issues and two pull requests, feel free. I'd rather just get it closed.
/me looks - NAME it already is called out. Please re-review.
On my agenda for today.
opened for field values
Splitting the issue was king of intrusive, sorry for that. The changes for [Messaging] have been merged. For [Semantics] please see URL
Popular clients handle LF, CR, and CRLF as newlines. HTTP only defines CRLF. Previously: URL
To clarify, this is about the CRLF in the HTTP-message production.
Covered here: URL ... but I agree it could be more visible (e.g., in 3).