Restore number of parameters in SUBSCRIBE #352
Conversation
There was a problem hiding this comment.
I don't think this is right but I could be wrong. I never fully understand the syntax from RFC 9000 because it is very confusing and I don't think we should use it because of that but ....
My understanding of the syntax of
x (L) ...
is that will encode on the wire the number of things of size L in x. See section 1.3 of RFC 9000.
Clearly we need the number of things in this but we don't need it twice. Am I missing the boat on this ? I'm sure Martin knows this stuff better than me.
|
I don't think that's right. I can argue by example: the format (..) ... does not have "number of things" prepended without explicity stating so in the spec. x (L) ...: Given that definition, I read x (..) ... as it is repeated zero or more time, and the length of each is variable. It says nothing about the explicitly writing the number of actions. |
|
I think Martin is correct, but I also find it a little confusing because section 1.3 of MOQT adds the notation x (b) for binary data, which really includes a length field followed by that many bytes. But that is currently only defined for binary data. This also recently changed for the new OBJECT messages. They used to have Object Payload (b) but now they are defined as Object Payload (...) with the length explicitly defined as Object Payload Length (i). Tracknames etc. still use the x(b) notation. Maybe it would be good to be consistent on all of these. We could remove x(b) or use something similar for binary fields and parameters. |
|
OK ... look at the high level, we all agree we need the count on the wire, we are only poking at the arcane syntax to represent that and it is clearly not clear. So lets go with this PR as is but would people be OK if moved all the syntax to ABNF. I think that would be far more clear, is widely used in ietf docs, and I think would work out much better for implementers. I'm happy to use any other well defined things instead but I'm not keep on using something where none of us are sure and I know developers are confuse. |
|
Dug into it and 100% agree with this PR. Sorry it took a bit to get there. Deleting other comments so as not to cause confusion later. |
Fixes #349