Original text:
the following fields should usually not be included in the signature unless the application specifically requires it:  8. 8.1.

Reviewer comments:
Includes some new text and several small cleanups.
did you forget to merge it?
Sorry, there was ice cream cake and I got distracted
Some header field values are case-insensitive, in whole or in part. The canonicalization rules do not account for this, thus a case change to a covered header field value causes verification to fail.
While I'd just put a warning on that, it would be great to have some examples/use cases for that.
Intermediaries are permitted to strip comments from the header field value, and consolidate related sequences of entries. The canonicalization rules do not account for these changes, and thus they cause signature verification to fail if the header is signed. At the very least, guidance on signing or not signing headers needs to be included.
Let's add a paragraph with some caveats and header examples.

Revised text:
the following fields should usually not be included in the signature unless the application specifically requires it: <ins> 7.21. The create-sig-input uses the value of an HTTP field as its component value.  In the common case, this amounts to taking the actual bytes of the field value as the component value for both the signer and verifier.  However, some field values allow for transformation of the values in semantically equivalent ways that alter the bytes used in the value itself.  For example, a field definition can declare some or all of its value to be case-insensitive, or to have special handling of internal whitespace characters.  Other fields have expected transformations from intermediaries, such as the removal of comments in the "Via" header field.  In such cases, a verifier could be tripped up by using the equivalent transformed field value, which would differ from the byte value used by the signer.  The verifier would have have a difficult time finding this class of errors since the value of the field is still acceptable for the application, but the actual bytes required by the signature base would not match. When processing such fields, the signer and verifier have to agree how to handle such transformations, if at all.  One option is to not sign problematic fields, but care must be taken to ensure that there is still security-coverage for the application.  Another option is to define an application-specific canonicalization value for the field before it is added to the HTTP message, such as to always remove internal comments before signing, or to always transform values to lowercase.  Since these transformations are applied prior to the field being used as input to the signature base generation algorithm, the signature base will still simply contain the byte value of the field as it appears within the message.  If the transformations were to be applied after the value is extracted from the message but before it is added to the signature base, different attack surfaces such as value substitution attacks could be launched against the application.  All application-specific additional rules are outside the scope of this specification, and by their very nature these transformations would harm interoperability of the implementation outside of this specific application.  It is recommended that applications avoid the use of such additional rules wherever possible. </ins> 8. 8.1.