Original text:
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>  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>  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>  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

Reviewer comments:
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.
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)

Revised text:
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  <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,  <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.  <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