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: Otherwise, my endpoint has to assume that your endpoint could ignore messages, and the MoQ draft in general, on a whim. Just tell me that you don't support ANNOUNCE via ROLE. Otherwise I would have to send an ANNOUNCE, start a timer, and guess that no OK/ERROR means no support? Probing for support is miserable. You close the connection on an unsupported message. Just send ROLE=both then. Not every conferencing is bidirectional though, for example clubhouse-style. At Discord we also have a dedicated connection for screen sharing (don't ask) and a very explicit role=publisher vs role=subscriber flag.
I don't think this is necessarily true. Without ROLE, you can still choose to only implement half the protocol and reject the messages you don't support. Every client has to be built to be resilient to arbitrary incoming messages. It can't break because the other side said their role was subscriber but then they send you an ANNOUCE. Therefore sending an upfront role seems like a promise to behave in a certain way. A system that relies on promises to not break will be brittle. I agree that ROLE seems superfluous.
I want publisher and subscriber support to be optional. That way it's only necessary to implement half of the draft on many cases. A CDN distribution edge would be one such situation. In fact, it's a hardening measure to ensure the edge cannot receive a ANNOUNCE which might otherwise cause a vulnerability. And generally speaking, if something is optional, then it should be negotiated. Otherwise you end up with Schroeder's extension. Silently ignoring unknown/unsupported messages is just terrible protocol design and it's s far better to close the connection with a protocol violation instead. That's the point of the ROLE parameter. But yeah let's chat about it on Wed.
Individual Comment: Every implementation has to have that switch statement and some not-crash action when it receives a message it doesn't support. Some logical options are: Ignore the message Send the corresponding error message (eg SUBSCRIBEERROR, ANNOUNCEERROR) with an error code like "not-implemented" Close the entire connection I think the value of ROLE is that it gives a consistent behavior early in the life of the session. If I want to send subscribes and the peer says they are subscriber only, I close the connection.