fn parameter_in_scope(key: u64, message: MessageType) -> boolExpand description
Whether draft-18 lets Message Parameter key appear in message.
Section 10.2.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 15.7), carrying the message types that entry’s own subsection names.
Five of the names are one wire type. Section 10.5: “This document uses the shorthand PUBLISH_OK, REQUEST_UPDATE_OK, TRACK_STATUS_OK, SUBSCRIBE_NAMESPACE_OK, and PUBLISH_NAMESPACE_OK to refer to a REQUEST_OK sent in response to the corresponding request type.” Which one a given REQUEST_OK is depends on the request its Request ID answers, which is session state and not in the frame, so each of those names widens the same arm and a REQUEST_OK is held to their union. Draft-17 needed none of this: there PUBLISH_OK is its own message type, and the two drafts’ tables differ accordingly.
Where a name is qualified — “REQUEST_UPDATE (for a subscription)”, “REQUEST_UPDATE for a SUBSCRIBE_NAMESPACE or SUBSCRIBE_TRACKS request” — the qualifier says which instance of the destination is meant rather than naming another, and settling it needs the same session state, so the message type alone decides.
FETCH_OK has no arm in the table below, and that is the draft’s doing rather than an omission here: Section 10.13 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.