Clarify FTN construction #1008
Clarify FTN construction #1008
Conversation
afrind
added
the
Editorial & Minor Design
draft-ietf-moq-transport.md
Outdated
| @@ -501,6 +501,10 @@ 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. | |||
|
|
|||
| Repeating the bytes corresponding to tuples between the Track Namespace | |||
| and the Track Name is an invalid construction. Endpoints encountering such | |||
| a construction MUST terminate the session with a 'Protocol Violation' error. | |||
There was a problem hiding this comment.
Uh, I think I know what you are getting at but this seems pretty confusing. How about
Publishers MUST NOT create a tracks names that are the same as namespace tuples inside the same namespace.
There was a problem hiding this comment.
Or something like this?
The combined tuple consisting of a Full Track Name's Namespace tuple fields and its Track Name MUST NOT also be a Track Namespace or a prefix of a Track Namespace.
|
And to be clear, I agree with the design here - just hard to figure out how to phrase the text |
The fact that we concatenate namespace and name down to a common tuple , and that we need to consider this PR in order to disambiguate the two, suggests we should re-evaluate Simplify naming by removing the distinction between Track Namespace and Track Name. The primary argument for closing that was the complexity of wildcard subscriptions. But that was prior to the PUBLISH workflow being considered. If a client wants to subscribe to all of example.com, and they have the permissions to, then let them. Relays never need to know the differentiation of namespace and names as they only ever operate on the concatenation of the two. ANNOUNCE is naturally wildcard-enabled, as is SUBSCRIBE_ANNOUNCES. |
| To avoid confusion and potential ambiguity, the combined tuple consisting of a | ||
| Full Track Name's Namespace tuple fields and its Track Name MUST NOT also be a | ||
| Track Namespace or a prefix of a Track Namespace. Endpoints encountering such a | ||
| construction MUST terminate the session with a 'Protocol Violation' error. |
There was a problem hiding this comment.
I'm not sure this will be trivial to check for all implementations, so I'd be inclined towards SHOULD.
Fixes #1005