Code change:
6.2.2.1. <del> The ROLE parameter (key 0x00) allows the client to specify what roles it expects the parties to have in the MOQT connection.  It has three possible values, which are of type varint: </del> <ins> The ROLE parameter (key 0x00) allows each endpoint to independently specify what funnctionality they support for the session.  It has three possible values, which are of type varint: </ins> <del> The client MUST send a ROLE parameter with one of the three values specified above.  The server MUST close the session if the ROLE parameter is missing, is not one of the three above-specified values, or it is different from what the server expects based on the application. </del> <ins> Both endpoints MUST send a ROLE parameter with one of the three values specified above.  Both endpoints MUST close the session if the ROLE parameter is missing or is not one of the three above-specified values. </ins> 6.2.2.2.

Related discussion:
text: Say the use-case Participant in media conference joins as subscriber only since he is driving and want to listen in Then at some point mid session , he wants to contribute and he now becomes as publisher and subscriber what is the expected flow in this case ?
Current draft doesn't really explain what ROLE parameter is for, only that client needs to send it - what was original idea? Why not just always allow everyone to send and receive data?
It seems a better way to control if you can send and receive might just be if the client has the appropriate auth tokens for each role. I lean towards remove this if we don't need it, but if we need it, I have would be fine with a design where the client says which roles it is capable of , and the server response contains which roles it is allowed to do.
I think ROLE is good for negotiating half-functionality. If the remote endpoint cannot send media (ex. player), then sending a SUBSCRIBE is invalid. If the remote endpoint cannot receive media (ex. OBS), then sending a ANNOUNCE/OBJECT is invalid. This removes a burden on implementations, as most will only care about specific role. NAME brings up a good point. If an endpoint could switch roles, then it should advertise full functionality. That would include publishing an empty catalog which it can append it later when it wishes to publish tracks.
I don't think I seem much use for the Role - it seems like something the application would know at a higher layer. But I have no objection to including it if others do see a need for it. It's not like it makes life harder for applications that don't use it.
If the ROLE is used to enforce the half-functionality, then it needs to be clear what should be done when invalid message is received. Sending a GOAWAY? Sending a generic error message? Does the connection need to be terminated? I think most of the time, application will just choose the full functionality in case of role switching on the fly and avoid the invalid response code(just ignore the invalid message).
Oh hey, I found a good use-case for ROLE. If my client connects with ROLE=publisher, then the server knows that it should not send ANNOUNCE messages. The messages are useless and actually triggered a deadlock in my broadcaster, since the application was not reading them and overflowed the receive channel.