Should the catalog format constrain the grammar of track namespaces and track names?

[JonathanLennox]

MOQ Transport says:

In this specification, both the Track Namespace and the Track Name are not constrained to a specific encoding. They carry a sequence of bytes and comparison between two Track Namespaces 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.

Should the catalog format indeed constrain the grammar of these fields, whether just be restricting them to be valid UTF-8 or somehow further? (Valid URI? ASCII-Only?). Otherwise we need to deal with arbitrary binary data in the track namespaces and track names, which can be challenging at best to represent in JSON.

[wilaw]

The JSON spec requires UTF-8 support by decoders, so it seems sensible to inherit that flexibility. We should state this explicitly in the spec. I'd like to support our Chinese, Korean and Japanese colleagues with the ability to specify namespace and names in their character sets.

"namespace" : "特别项目/2025年5月1日"
"name":"视频"

If a streaming format wishes to further constrain these names to be URIs, or ASCII, it may do so, however the catalog spec itself should not force those restrictions.

Similarly, if a streaming format wishes to support binary namespace and names, these can be encoded as base64 strings in the catalog and the application would understand how to convert them to their wire format.

"namespace" : "c2FtcGxlbmFtZXNwYWNl"
"name":"c2FtcGxlbmFtZQ=="