Code change:
"Hypertext Transfer Protocol (HTTP) Field Name Registry" registry maintained at <https://www.iana.org/assignments/http-fields/>. <del> Just as in HTTP/1.x, field names are strings of ASCII characters that are compared in a case-insensitive fashion.  Field names MUST be converted to lowercase prior to their encoding in HTTP/2.  A request or response containing uppercase header field names MUST be treated as malformed. </del> <ins> Field names are strings of ASCII characters that are compared in a case-insensitive fashion.  Field names MUST be converted to lowercase when constructing a HTTP/2 message.  A request or response containing an uppercase character ('A' to 'Z', ASCII 0x41 to 0x5a) in a field name MUST be treated as malformed. HPACK is capable of carrying field names or values that are not valid in HTTP.  Though HPACK can carry any octet, fields are not valid in the following cases: A request or response that contains a field that violates any of these conditions MUST be treated as malformed.  In particular, an intermediary that does not process fields when forwarding messages MUST NOT forward fields that contain any of the values that are listed as prohibited above. Field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed except as defined by the processing rules for the field. </ins> 8.1.2.1.

Related discussion:
text: Three vectorizeable field-value checks (NUL, LF, CR) all ensuring valid HTTP/1.1 framing. 4 single-byte comparisons against the first byte of the field-value. This problem is solved by not doing that. The ABNF in -semantics, if enforced, is a strict superset of the requirements here except for (2). If your implementation will enforce the requirements in -semantics, you can choose to not enforce these ones at the h2 layer, knowing that the -semantics layer will cover you. The RFC does not bind your implementation, only your observable behaviour: if your implementation ends up rejecting header fields that meet these characteristics, it doesn't matter why you did it, only that you did.
I don't get that. We're still talking about field names, right?
No, all of this applies to names and values:
Well. Validating names and values are very different things. It would be best to clearly separate these topics.
I get it that there is a minimum standard being set. In section "HTTP Fields" it says that h2 implementations MUST treat as malformed any fields that violate any of the described conditions and an intermediary MUST NOT forward any such headers. Then again in section "Intermediary Encapsulation Attacks" is says the validations of the "HTTP Fields" MUST be implemented, which is kind of a duplication as they are already at MUST strength. I don't see any normative text that says that an implementation MAY or SHOULD validate against the HTTP ABNF and that if they do so then that is a superset of the conditions in section "HTTP Fields" I would very much prefer to see text in the "HTTP Fields" section that clearly says h2 implementations MAY validate against the HTTP ABNF and that any implementations that do not MUST validate fields against the following conditions. I'll have a try at this later today.... stand by....
NAME I'm reading your comments as supportive of the technical change, but a strong preference for a different way of presenting the information. I want to clarify that this change is about the mandatory validation that endpoints perform on fields. It looks like we all agree with stipulating a minimum amount of validation that applies to all implementations, especially those that would otherwise just forward fields without processing.