Function check_message_parameters_are_known 

fn check_message_parameters_are_known(
    parameters: &[KeyValuePair],
) -> Result<(), CodecError>

Refuse a Message Parameter whose type this draft does not define.

Section 9.2: “All Message Parameters MUST be defined in the negotiated version of MOQT or negotiated via Setup Parameters. An endpoint that receives an unknown Message Parameter MUST close the session with PROTOCOL_VIOLATION.”

This is the one rule in the parameter paragraph that changed direction at this draft. Drafts 11 through 15 say, at draft-15 Section 9.2, “Receivers MUST allow duplicates of unknown parameters”, which takes for granted that unknown parameters arrive and are carried. Draft-16 narrows that sentence to “unknown Setup Parameters” and adds this one beside it, in the same paragraph — so a type this codec cannot name is carried in a SETUP and ends the session anywhere else.

KNOWN_MESSAGE_PARAMETERS is what “defined in the negotiated version” means here, and it is checked against Section 13.2 rather than assembled from the types this codec happens to read. A missing entry would close sessions over parameters the draft assigns, which is the expensive way to be wrong.

The other half of the sentence — “or negotiated via Setup Parameters” — is not something a codec can settle. It describes an extension the two endpoints agreed on in their SETUP, and this codec implements no such extension, so every type outside the registry is unknown to it.