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: is too restrictive, we'll have to somehow relax the requirement on the serializer (for instance, by stating that the serializer needs to implement 8941 or a successor RFC - that is an RFC that obsoletes 8941). FWIW, I agree that this would be good. But it is not what the spec says.
No, we reference the current document and if that document is updated or obsoleted by something else after publication then you as an implementer go and follow that. That's how updating RFC's already work. All the specs and systems that implemented RFC2616 didn't suddenly break and become invalid when 7230 or later 9110 came out. Here, It's up to the updaters of 8941 to make sure there's A serialization section. Your view of specification dependency is not at all in line with reality.
I see where you're coming from; I'd appreciate if you would do the effort to understand where I'm coming from. The difference here is that any spec that extends 8941 with new types by definition is not backwards compatible. This is because 8941 has no extension points, has drastic error handling and thus requires a wholesale spec update for new things. This is very different from most other RFCs that we're using here. If there is agreement about what we want, why don't we just say it?
To illustrate further: RFC8941-vs-8941bis is like XML1.0-vs-1.1 or HTTP1.1-vs-2.0, not like RFC2616-vs-RFC9112.
That's a very specific definition of 'not backwards compatible' and one that I suspect many would be surprised by. Just because there are no explicitly nominated extension points doesn't mean you can't evolve the specification in a backwards-compatible fashion; the key requirement is that valid inputs per the 'old' version are also valid inputs per the 'new' revision. That is the case for sf-bis. It is true that an invalid input for RFC 8941 will now become valid; specifically, a type value beginning with 'NAME used to generate an error, and now will not (provided that the following characters are appropriate). The reasonable question to ask at this point is whether it's realistic / probable that an application will be depending upon that error being thrown to operate.