Original text:
8859-1, supporting other charsets only through use of RFC2047 encoding.  Specifications for newly defined fields SHOULD limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB.  A recipient <del> SHOULD treat other octets in field content (obs-text) as opaque data. </del>  <del> Field values containing CR or NUL characters are invalid and </del>  dangerous, due to the varying ways that implementations might parse <del> and interpret those characters; a recipient of CR or NUL within a field value MUST either reject the message or replace each of those </del>  characters with SP before further processing or forwarding of that message.  Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake <del> of robustness if they only appear within safe field value contexts (e.g., opaque data). </del>  Fields that only anticipate a single member as the field value are referred to as

Reviewer comments:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Revised text:
8859-1, supporting other charsets only through use of RFC2047 encoding.  Specifications for newly defined fields SHOULD limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB.  A recipient  <ins> SHOULD treat other allowed octets in field content (i.e., </ins>  <ins> ) as opaque data. Field values containing CR, LF, or NUL characters are invalid and </ins> dangerous, due to the varying ways that implementations might parse  <ins> and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those </ins> characters with SP before further processing or forwarding of that message.  Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake  <ins> of robustness when they appear within a safe context (e.g., an application-specific quoted string that will not be processed by any downstream HTTP parser). </ins> Fields that only anticipate a single member as the field value are referred to as