Code change:
2.1.1. If the value of an HTTP field is known by the application to be a <del> 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. </del> <ins> structured field type (as defined in STRUCTURED-FIELDS or its extensions or updates), 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 formal serialization rules specified in STRUCTURED-FIELDS (or the applicable formal serialization section of its extensions or updates) 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. </ins> If multiple field values occur within a message, these values MUST be combined into a single List or Dictionary structure before serialization. <ins> If the application does not know the type of the field, or the application does not know how to serialize the type of the field, the use of this flag will produce an error.  As a consequence, the signer can only reliably sign fields using this flag when the verifier's system knows the type as well. </ins> For example, the following dictionary field is a valid serialization: If included in the signature base without parameters, its value would

Related discussion:
text: Also, that only affects the toplevel type of the structured field. It does not address the case where an extension parameter is added is an sf-date (or any future new type).
NAME until you propose text, it will be hard to say what kind of text you think would close this issue.
Except for this issue and two others recently raised by you (which will be considered as IETF LC issues), all of the issues and PRs you mention were generated by the AD review before IETF LC; this is a normal part of the process that does not require going back to WGLC unless the AD asks for WG review, which . NAME made a reasonable proposal. If you disagree with it, make your own.
If the proposal was: Then this isn't sufficient as it only applies to the toplevel type (see URL). NAME - I believe you are in the best position to make a proposal; but that said; I can try something later today.
So, we have in 2.1.1: This implies that the "sf" parameter can only be used on fields that conform to RFC 8941, no extensions allowed. I would suggest clarifying that, at the end of 2.1.1, with: "Note that the normative requirement to use the SF serialization algorithm precludes any use of future extensions of the structured field syntax. Support for future versions of SF will require an update to this specification." I believe this matches what NAME suggested.
Except that your proposed text is incorrect. The implication you are drawing is not true, nor what others have taken from that text. The use of the parameter does not preclude extensions to RFC 8941, as has been discussed at length here and on the mailing list. Extensions to sf types would not require changes to the signatures spec. I propose closing this issue without change to the signatures spec.
Sorry. Mark asked me to propose text, and that's what I did. The text has a normative requirement to use an RFC8941 serializer, so the proposed text is correct. That we disagree here is proof that a clarification is needed. If you feel that that p.o.v.