Original text:
parameters in specific circumstances, each described in detail in their own sections:  Additional parameters MAY be defined in a registry established in param-registry. 2.1.1. If the value of the the HTTP field in question is known by the <del> application to be a structured field (STRUCTURED-FIELDS), the component identifier MAY include the "sf" parameter to indicate it is a known structured field.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in STRUCTURED-FIELDS applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. </del>  For example, the following dictionary field is a valid serialization:

Reviewer comments:
This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected using the parameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, then doing a strict serialization on those values.
In general, is this even needed or are we over-engineering here? If the main use case is , do we think it is likely to be signed?
Some fields, like , have an internal syntax that allows unquoted commas and messes things up when multiple lines are combined for the signature base, leading to the potential case where two semantically different inputs have the same signature base. This means that: And: Both produce the same signature input line: Even though the two-line and single-line versions are processed differently by the application. To counter this, we could have a distinct encoding flag that wraps the field values, similar to . This can be used to protect problematic fields like Set-Cookie so that we get something like this for the multiple line version: But you'd get this for the single-line version: The background of this has been discussed in and

Revised text:
parameters in specific circumstances, each described in detail in their own sections: <ins> Multiple parameters MAY be specified together, though some combinations are redundant or incompatible.  For example, the "sf" parameter's functionality is already covered when the "key" parameter is used on a dictionary item.  The "bs" parameter, which requires the raw field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </ins> Additional parameters MAY be defined in a registry established in param-registry. 2.1.1. If the value of the the HTTP field in question is known by the  <ins> application to be a structured field (STRUCTURED-FIELDS), and the expected type of the structured field is known, the signer MAY include the "sf" parameter in the component identifier.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in STRUCTURED- FIELDS applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. Processing of this parameter MUST occur after multiple field values have been combined into a single List or Dictionary structure. </ins> For example, the following dictionary field is a valid serialization: