Name wildcard; Length vs mask

[TimEvens]

In the case of IPv4 and IPv6, the prefix/length defines the length of bits that are significant. The non-significant bits are considered wild.

A major advantage of using prefix/len is to support an implementation using prefix trees (trie) for various lookups. This enables very efficient and fast lookups for subscriber sets as well as publish authorizations. While this is a huge benefit, it does impose a strict limit on how name Ids are encoded to support wildcarding. The original thought was that if you join meeting X, then you can subscribe to meeting-X/* to get all streams from all participants.

Clients can send multiple streams, simulcast, at different resolutions and frame rates. The receiving client may not be able to handle/consume all those resolutions and rates. Instead, the client may need to subscribe to specific resolutions/rates.

The wildcard using a trailing length only doesn't scale easily to support subscriptions of 1080p or 720p at frame rate 30fps, filtering out 60 or other frame rates. Some subscribers may need to filter by resolution while others need to filter by frame rate and/or resolution. It gets a bit complex to encode that in the wildcard when only the trailing bits are considered wild.

Bit masking on the other hand does support masking bits anywhere within the 128-bits. This allows wildcards anywhere based on a 128 bit mask. The major limitation with bit masking is that it is inefficient in terms of lookup operations as tries cannot be used.

Need to discuss this a bit more. One method is to break up the 128-bits into parts, each of which have a length, to support tries. Another is to cache lookups so that lookups are not per message. Each have their pros and cons.