Function parameter_may_repeat 

fn parameter_may_repeat(key: u64) -> bool

Whether draft-20 lets a message carry parameter type key more than once.

Section 10.2 states the default: “Senders MUST NOT repeat the same Parameter Type in a message unless the parameter definition explicitly allows multiple instances of that type to be sent in a single message.” Two definitions do.

• AUTHORIZATION_TOKEN (0x03), Section 10.2.2: “The AUTHORIZATION TOKEN parameter MAY be repeated within a message as long as the combination of Token Type and Token Value are unique after resolving any aliases.”
• The five Range Filters (0x25 through 0x29), Section 5.1.4 — draft-19’s 5.1.3: “The Track Property filter parameter MAY appear multiple times in a SUBSCRIBE_TRACKS message or REQUEST_UPDATE for it. 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.”

A zero Type Delta is “the same type again”, not an error

The two rules interact, and the draft does not say how. Section 10.2 also requires that “Parameters MUST be serialized in ascending order by Type”, so a second instance of a repeatable type produces a Type Delta of 0 — well formed only if the decoder reads a zero delta as a repeat rather than as a malformation. That reading is the one taken here; the alternative makes Section 5.1.4’s permission unusable, because there is no other encoding for a second filter of the same type.

What the filters may not do is repeat the same (Parameter Type, SetID, Property Type) triple, and Section 5.1.4 answers that with a REQUEST_ERROR carrying INVALID_FILTER rather than with a session close. A reply an endpoint sends is not a frame a decoder refuses, so nothing here enforces it — see crate::range_filter for the reader an endpoint uses to decide.