fn parameter_in_scope(key: u64, message: MessageType) -> boolExpand description
Whether draft-17 lets Message Parameter key appear in message.
Section 9.3.1: “Each Message Parameter definition indicates the message types in which it can appear. If it appears in some other type of message, the receiving endpoint MUST close the connection with a PROTOCOL_VIOLATION.” One arm per entry in the Message Parameters registry (Section 14.3), carrying the message types that entry’s own subsection names.
Where a name is qualified, the qualifier describes one of the destinations rather than adding another. LARGEST_OBJECT “MAY appear in SUBSCRIBE_OK, PUBLISH or in REQUEST_OK (in response to REQUEST_UPDATE or TRACK_STATUS)” names three message types, and drafts 18 and 19 write that same rule as SUBSCRIBE_OK, PUBLISH, REQUEST_UPDATE_OK and TRACK_STATUS_OK once those responses have names of their own.
FETCH_OK has no arm in the table below, and that is the draft’s doing rather than an omission here: Section 9.15 gives it a Parameters field and no parameter definition names it, so every type this draft defines is “some other type of message” there.
The table decides scope only. A type this draft does not define has no scope
to be outside of and is answered by CodecError::UnknownMessageParameter,
which is why the final arm carries rather than refuses.