Code change:
chances of the field value remaining untouched through intermediaries.  Where that approach is not possible and multiple instances of a field need to be sent separately, it is RECOMMENDED <del> that signers and verifiers process any list-based fields by parsing out individual field values and combining them based on the strict </del> <ins> that signers and verifiers process any list-based fields taking all individual field values and combining them based on the strict </ins> algorithm below, to counter possible intermediary behavior.  When the field in question is a structured field of type List or Dictionary, <del> this effect can be accomplished more directly by using the strict </del> <ins> this effect can be accomplished more directly by requiring the strict </ins> structured field serialization of the field value, as described in http-field-structured. <del> Note that some HTTP fields, such as Set-Cookie COOKIE, do not follow a syntax that allows for combination of field values in this manner (such that the combined output is unambiguous from multiple inputs). Even though the component value is never parsed by the message signature process and used only as part of the signature base in create-sig-input, caution needs to be taken when including such </del> <ins> Note that some HTTP fields, such as Set-Cookie (COOKIE), do not follow a syntax that allows for combination of field values in this manner (such that the combined output is unambiguous from multiple inputs).  Even though the component value is never parsed by the message signature process and used only as part of the signature base in create-sig-input, caution needs to be taken when including such </ins> fields in signatures since the combined value could be ambiguous. The "bs" parameter defined in http-field-byte-sequence provides a method for wrapping such problematic fields.  See security-non-list

Related discussion:
text: This isn't combination at the HTTP level by the client or intermediary, this is combination by either the signer or verifier when making the signature base. It's a MUST here because there needs to be only one way to do it at that step. If the lines are already combined then leave them combined.
hm. ok. So one confusing thing here is that HTTP 5.2 is already only about combining field values. So the "Specifically" is a distraction. Also, 5.2 does not mandate using COMMA SP. The section doing that is 5.3.
Also...: I think I misread that as a recommendation to parse individual field values into a list, before recombining everything. Maybe "parsing out individual field values" needs to be rephrased.
You would only parse out individual values if you: 1: Know the overall syntax/grammar of the field 2: Know that it's a list separated by commas 3: Can't send everything as a single field line 4: Know that an intermediary is going to mess with things sent as multiple lines in a way that you don't want The recommendation is really only for that one corner case, not for every value.
I agree with that, but the spec really needs to be clearer here.
(but I'll note that github's way of displaying diffs in long lines makes it extrremely hard to find out what actually changed)