A track is a sequence of groups (Section 2.3). It is the entity against which a subscriber issues a subscription request. A subscriber can request to receive individual tracks starting at a group boundary, including any new objects pushed by the publisher while the track is active.
2.4.1. Track Naming and Scopes
In MOQT, every track is identified by a Full Track Name, consisting of a Track Namespace and a Track Name.
Track Namespace is an ordered N-tuple of bytes where N can be between 1 and 32. The structured nature of Track Namespace allows relays and applications to manipulate prefixes of a namespace. If an endpoint receives a Track Namespace tuple with an N of 0 or more than 32, it MUST close the session with a Protocol Violation.
Track Name is a sequence of bytes that identifies an individual track within the namespace.
In this specification, both the Track Namespace tuple fields and the Track Name are not constrained to a specific encoding. They carry a sequence of bytes and comparison between two Track Namespace tuple fields or Track Names is done by exact comparison of the bytes. Specifications that use MoQ Transport may constrain the information in these fields, for example by restricting them to UTF-8. Any specification that does needs to specify the canonicalization into the bytes in the Track Namespace or Track Name such that exact comparison works.
2.4.2. Scope
A MOQT scope is a set of servers (as identified by their connection URIs) for which the tuple of Track Name and Track Namespace are guaranteed to be unique and identify a specific track. It is up to the application using MOQT to define how broad or narrow the scope is. An application that deals with connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those CDNs.
Because the tuple of Track Namespace and Track Name are unique within an MOQT scope, they can be used as a cache key. MOQT does not provide any in-band content negotiation methods similar to the ones defined by HTTP ([RFC9110], Section 10); if, at a given moment in time, two tracks within the same scope contain different data, they have to have different names and/or namespaces.
2.4.3. Connection URL
Each track MAY have one or more associated connection URLs specifying network hosts through which a track may be accessed. The syntax of the Connection URL and the associated connection setup procedures are specific to the underlying transport protocol usage Section 3.