const REPEATABLE_PARAMETER: u64 = 0x03;Expand description
The one parameter type whose own definition lets it repeat.
Section 9.2.1.1: “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.” That is the “unless the parameter definition explicitly allows multiple instances” carve-out of Section 9.2, and on this draft it is the only one — none of the other eleven version-specific parameters, nor any of the six setup parameters, says the like.
The trailing condition is not enforced here. Resolving an alias needs the session’s token cache, which a codec framing one message does not have; uniqueness of the resolved pair is a session rule and not a wire rule. What is enforced is the permission itself, which is what a duplicate check needs to know.
The same code point, 0x03, in both namespaces: Section 9.2.1.1 assigns it to the message parameter and Section 9.3.1.5 defines the setup parameter as “See Section 9.2.1.1”, so a sender may repeat it in a SETUP as well. The name is the same on draft-14, whose Section 9.2.1.1 states the permission in the shorter form; the earlier name, AUTHORIZATION INFO, belongs to drafts 07 through 10, which stated no permission at all.