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: URL This does not work. It's impossible to split multiple values (be it a list-based field or not) without knowledge of the field value's grammar. For example, what is the canonicalized value for: ?
The value would be Since it was sent as two instances, you combine the instances with a comma and space. The language to split the field values was added late based on several conversations about list type fields and how they can be combined, but we can remove this. If someone needs additional armoring they can use the "sf" flag on a list formatted field.
Ok, but what the spec currently says would result in: URL that sentence really needs to go.
No, it would not result in that, because as you point out those are not separate field values that can be separated.
So what does: mean then? When is it "necessary"? How does the code know that for any given field name?
I think what is meant is that you take a list of the values of a given field (one member of the list for each header line) and then concatenate them by separating them with ", ". In scala this is or just to make it explicit
Thanks NAME - I get that, but that doesn't address the question I asked...
Ok, I see the problem is: I would not know how to do that, whereas I do know how to seperate the fields in the list.
We need to be very clear with the terminology. What do you mean by "seperate the fields in the list"? Do you have an example?
If you are talking to me, I meant what the code above showed: the list is the list of header values (for a given header name). And I meant seperating the values of that list. I don't know how to write that up well in the spec though...
Ok, AFAIU: just drop "If necessary, separate individual values found in a field instance." from the spec.
URL I don't quite get the reasoning for the second "MUST". Why does it matter? What would break if the client uses a single comma, which is also allowed by HTTP? IMHO the exact delimiter sequence here does not matter at all, as long as it is allowed per HTTP. Note that HTTP allows combining field values, it does not allow splitting them afterwards.