Function parameter_in_scope 

pub fn parameter_in_scope(key: u64, message: MessageType) -> bool

Whether draft-20 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 definition names.

Four things about this draft the arms below fold in:

• Six 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, SUBSCRIBE_TRACKS_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.
• The five Range Filters state their scope in Section 5.1.4 — draft-19’s Section 5.1.3 — rather than in their own subsections: the Track Property filter “MAY appear multiple times in a SUBSCRIBE_TRACKS message or REQUEST_UPDATE for it”, and “all other filter parameters MAY appear multiple times in a FETCH, SUBSCRIBE, SUBSCRIBE_TRACKS, or REQUEST_UPDATE (on a subscription, from the subscriber only) message”. Draft-19 listed PUBLISH_OK in that second sentence and draft-20 removed it.
• SUBSCRIBE_TRACKS inherits SUBSCRIBE’s whole set. Section 10.20.1 — the renumbering of draft-19’s 10.19.1 — keeps the sentence verbatim: “Any Parameter that can be specified on a Subscription (ie: in SUBSCRIBE) is valid in SUBSCRIBE_TRACKS, unless otherwise specified.”
• PUBLISH_OK is gone from six definitions. OBJECT_DELIVERY_TIMEOUT (0x02), SUBGROUP_DELIVERY_TIMEOUT (0x06), FORWARD (0x10), SUBSCRIBER_PRIORITY (0x20), LOCATION_FILTER (0x21) and NEW_GROUP_REQUEST (0x32) each dropped it, and several gained PUBLISH instead; the Range Filters dropped it via Section 5.1.4. EXPIRES (0x08) is the only parameter that still names it. A subscriber that wants to change something now sends a REQUEST_UPDATE after the PUBLISH_OK, and sending any of the six on a PUBLISH_OK is a Section 10.2.1 violation. Because PUBLISH_OK and REQUEST_OK are one wire type, this table cannot see the difference: M::RequestOk is admitted wherever any of the six OK names is, so the practical effect here is that the six lose their M::RequestOk arm entirely.

FETCH_OK has no arm in the table below, and that is the draft’s doing rather than an omission here: Section 10.14 gives it a Parameters field and no parameter definition names it, so every type this draft defines is “some other type of message” there.

PUBLISH_STATE_NOTIFY is admitted by exactly three parameters, and treating that list as closed is a decision this codec makes. Section 10.10 says only “The semantics of each parameter, including whether it may appear in PUBLISH_STATE_NOTIFY, are defined by the parameter”, and LARGEST_OBJECT (0x09), FORWARD (0x10) and LOCATION_FILTER (0x21) are the three whose definitions name it. The draft implies the closure and never states it, so anything else there is refused under Section 10.2.1 on that reading.

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.