Function parameter_in_scope 

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

Whether draft-22 lets Message Parameter key appear in message.

Section 9.20.1: “Each Message Parameter definition indicates the message types in which it can appear, and each control message definition lists the parameters it allows. If a parameter 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 16.7), carrying the message types that entry’s own definition names. The lists in the message definitions say the same thing from the other side.

Four things about this draft the arms below fold in:

• Six of the names are one wire type. Section 1.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.” Section 9.3 gives each of the six its own list, and which list applies depends on the request the REQUEST_OK answers, which is session state and not in the frame. So a REQUEST_OK is held to the union of the six: EXPIRES (0x08) and LARGEST_OBJECT (0x09).
• REQUEST_UPDATE is the same shape. Section 9.5 lists its parameters per kind of request being updated, and the request is named by a Request ID this frame cannot resolve, so REQUEST_UPDATE is held to the union of the five lists. A session that knows the request can hold an update to the narrower list; this table cannot, and it does not guess.
• The five Range Filters state their scope in Section 3.3.2 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”.
• SUBSCRIBE_TRACKS takes the parameters Section 9.18 lists, plus LOCATION_FILTER (0x21) and FILL_PARAMETERS (0x23), and the two extra are a decision this codec makes. Section 9.18: “The parameters that can appear in a SUBSCRIBE_TRACKS are AUTHORIZATION_TOKEN, FORWARD, GROUP_ORDER, SUBGROUP_FILTER, OBJECTID_FILTER, PRIORITY_FILTER, OBJECT_PROPERTY_FILTER, TRACK_PROPERTY_FILTER and INCLUDE_PROPERTIES.” That is exactly the set whose own definitions name SUBSCRIBE_TRACKS, and it is the “unless otherwise specified” in Section 3.6.2’s “Any Parameter that can be specified on a Subscription (ie: in SUBSCRIBE) is valid in SUBSCRIBE_TRACKS, unless otherwise specified”, so OBJECT_DELIVERY_TIMEOUT (0x02), RENDEZVOUS_TIMEOUT (0x04), SUBGROUP_DELIVERY_TIMEOUT (0x06), SUBSCRIBER_PRIORITY (0x20) and NEW_GROUP_REQUEST (0x32) are refused there under Section 9.20.1. Section 3.6.2 then closes: “To join Tracks initiated via the resulting PUBLISHes, the subscriber can specify a Location Filter and optionally include FILL_PARAMETERS in the SUBSCRIBE_TRACKS” — two parameters that neither the list nor their own definitions place in this message. On those two alone the section conflicts with the list, the definitions and Section 9.20.1’s rule, and the conflict is the one drafts 20 and 21 carry. This codec follows Section 3.6.2 for them: it is the one sentence telling a subscriber what to put in this message, and a scope miss ends the session.

FETCH_OK has no arm in the table below, and that is the draft’s doing rather than an omission here: Section 9.12 gives it a Parameters field and says “No parameters are currently defined for FETCH_OK”, so every type this draft defines is “some other type of message” there.

PUBLISH_STATE_NOTIFY is admitted by exactly three parameters. Section 9.10 closes the list itself: “The parameters that can appear in a PUBLISH_STATE_NOTIFY are LARGEST_OBJECT, FORWARD and LOCATION_FILTER.”

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.