Skip to main content

parameter_in_scope

Function parameter_in_scope 

Source
fn parameter_in_scope(key: u64, message: MessageType) -> bool
Expand description

Whether draft-19 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.

Three 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, and PUBLISH_NAMESPACE_OK to refer to a REQUEST_OK sent in response to the corresponding request type”, and the same section sends a REQUEST_OK in answer to SUBSCRIBE_TRACKS as well. 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.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, PUBLISH_OK, or REQUEST_UPDATE” message. A parameter definition is free to state its scope elsewhere, and these do.
  • SUBSCRIBE_TRACKS inherits SUBSCRIBE’s whole set. Section 10.19.1: “Any Parameter that can be specified on a Subscription (ie: in SUBSCRIBE) is valid in SUBSCRIBE_TRACKS, unless otherwise specified.” Draft-18 has no such sentence, which is why its SUBSCRIBE_TRACKS admits two types and this one admits fourteen.

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.