pub fn parameter_in_scope(key: u64, message: MessageType) -> boolExpand description
Whether draft-23 lets Message Parameter key appear in message.
Section 9.19.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 session with INVALID_PARAMETER.” 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.
REQUEST_OK and REQUEST_UPDATE list their parameters per kind of request
(Section 9.3 and Section 9.5), and the request is session state, so each is
held to the union of its lists here. RequestOk::check_answers narrows a
REQUEST_OK to one list.
No definition names NAMESPACE, so every parameter is out of scope 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.