Original text:
insensitive components such as field names, request URI scheme, or host. <del> Addition or removal of leading or trailing whitespace to a field value. Addition or removal of "obs-fold" from field values. </del> Changes to the request target and authority that when applied together do not result in a change to the message's target URI, as defined in HTTP.  We can identify these types of transformations as ones that should not prevent signature verification, even when performed on message components covered by the signature.  Additionally, all changes to

Reviewer comments:
Add reference for obs-fold, add note about transforms,
The spec several times refers to the term obs-fold, but doesn't say where it's defined (-> URL). Furthermore, in 1.3 it claims that addition of obs-fold could be permitted under certain circumstances. That IMHO is incorrect.
Adding the reference makes sense. The signatures spec doesn't change how the messages are created, nor does it make more allowed than it is now, it just tells people what to do with the messages that they have even if they have in them.
: This is misleading. No HTTP permits addition of leading/trailing whitespace. Leading/trailing whitespace in field values by definition is invalid.
While technically true, many (including implementers) won't understand the nuance Here. Given the impact, it's better to be over-inclusive, I think.
If invalid changes are included, then it might be best to either say that some of these changes might be invalid or point specifically to those that are.
Yes, my proposal would be to split the list into two; the second just listing the transformatios that might happen in reality despite bing forbidden.
NAME I agree that we need to prepare developers for the messy reality of HTTP in addition to what's strictly allowed. What else would appear in this second list?
The only other thing that I can see right now is addition of obs-fold.
Speaking of which: there are other transformations like parsing and re-serializing field values, which are certainly allowed. Shouldn't these be mentioned here as well?
NAME Re-serialization of a field value by an intermediary would likely break things in an expected way. It was my impression that this was not allowed by intermediaries in general. A structured field does help this, and the flag protects against that kind of transformation, as mentioned in the section.
I don't think we have a rule anywhere that would keep an intermediary from parsing and re-serializing fields. And even if that was the case, the same would be true for the original point (addition of leading/trailing WS), so I'm trying to understand where we draw the line.

Revised text:
insensitive components such as field names, request URI scheme, or host.  Changes to the request target and authority that when applied together do not result in a change to the message's target URI, as defined in HTTP. <ins> Additionally, there are some transformations that are either deprecated or otherwise not allowed, but still could occur in the wild.  These transformations can still be handled without breaking the signature, and include things such as: Use, addition, or removal of leading or trailing whitespace in a field value. Use, addition, or removal of "obs-fold" in field values (HTTP1). </ins> We can identify these types of transformations as ones that should not prevent signature verification, even when performed on message components covered by the signature.  Additionally, all changes to