Original text:
in time, two tracks within the same scope contain different data, they have to have different full track names.  2.3.2. Each track MAY have one or more associated connection URLs specifying

Reviewer comments:
Thanks NAME - all the proposed changes look like definite improvements. Thanks I need more coffee today.
In HTTP, there are a number of restrictions on what characters are allowed in a path, headers, etc. I don't see any text restricting track names and track namespaces, but the examples are all ASCII, implying the namespace and name are not intended to be completely opaque and are instead intended to be human readable. There's nothing in the spec that prohibits them being treated as opaque identifiers, but I'm unclear if that's the intent and I think it'd be good to explicitly say what we intend.
Most of the restrictions in the HTTP world are derivative of the restrictions in URIs: see RFC 3986, sections 2 and 3. I'd suggest we adopt those limitations and the percent encoding method from HTTP. That allows folks to use a well-known set of methods and aligns with the idea that we might have one or more URI schemes in the MoQ protocol space.
I believe we currently don't have a way to put a track name or a track namespace into a URL, so I don't think those restrictions apply.
I agree that they don't apply now, but if we adopt them it will simplify the set we have to deal with (since we will have the same set as other parts of the protocol). I suspect people will want the namespaces to be easy to generate from FQDNs (which are also the authority part of HTTP URIs), as an example.
IMO a track name should be human readable. Otherwise we should use numeric IDs instead, like most containers. I also think the track namespace should be human readable since it will likely be exposed to the user. Currently you need a URL and track namespace to configure a player/broadcaster. It will be quite common to combine both into a single URL (ex. like my relay) so it would be nice if track namespaces could be encoded into URLs.
Maybe we should ask the flip side: is there a use-case that won't work if track names are utf-8?
Moq transport must not define the interpretation. At the moqt transport layer track name and track namespace are set of octets and relay perform fast match where needed. How things from application domain gets mapped and gets setup with Relay is out of scope of MoQ Transport. Also how an application sets up namespaces with CDN/Relays is out of scope of moq.
We should clarify in the spec to say these are opaque and examples are intended for human readability purposes only.
I don't have any particular heartburn about where this gets defined, but I don't believe that the overall system will function well if the namespaces and track names are defined solely as "octets". We are talking about these as a tuple of namespace and name to create a globally unique identifier. If there isn't a common agreement on how those are composed and of what they are constructed, different systems doing different things will hinder interoperability and/or generate collisions. I would personally prefer the HTTP syntax, but UTF-8 would likely be okay if we specify how to handle things like byte-order marks, joiners, bidi, arabic letter marks and so on. That's a lot of work, but if someone wants to do it, okay. I don't think accepting a bunch of different encodings is helpful and I don't think using non-human readable identifiers is going to fly without a mapping to them (which only shoves the problem up a layer of indirection and adds in something new to fail). If not moqt, where do you want all this defined?
I disagree. We have to recognize that we are distributing the process of minting these identifiers very widely. Allowing people to re-use existing systems to create these is going to get us better scale and present fewer problems. You should expect folks to re-use DNS names to mint namespaces, to take an obvious example.
I don't think I am forbidding any of these. I am just saying it is not something moqt should enforce or we should support all forms of these not just one class of things
I am also strongly in favor of a utf-8 restriction. I'd like to inherit the usability achieved from a globally deployed and understood resource identifiers and to leverage the existing DNS and certificate system for authentication and routing. If we define names in terms of octets then we need to reinvent these conventions, or else have an unnecessarily bi-furcated system in which some addressing occurs via binary octets and others occurs via utf-8 resource locators.
The AUTH parameter is currently defined as an ASCII string. Whatever we use for track names, can the auth token share the same encoding?
Summary of IETF 118 meeting is there are no restrictions on at the moq transport layer but there may be a layers above this. This is to say the compare function for track namespace and track name are the equivalent of posix memcmp.
Looks fine to me. Agree with most of the nits suggested by Ian

Revised text:
in time, two tracks within the same scope contain different data, they have to have different full track names. <ins> 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. </ins> 2.3.2. Each track MAY have one or more associated connection URLs specifying