Code change:
given URI by setting up a QUIC connection to the host and port identified by the "authority" section of the URI.  The "path-abempty" and "query" portions of the URI are communicated to the server using <del> the PATH parameter (path) which is sent in the SETUP message at the start of the session.  The ALPN value RFC7301 used by the protocol is "moq-00". </del> <ins> the PATH parameter (path) which is sent in the CLIENT_SETUP message at the start of the session.  The ALPN value RFC7301 used by the protocol is "moq-00". </ins> 3.2. Endpoints use the exchange of SETUP messages to negotiate the MOQT version and any extensions to use. <del> The client indicates the MOQT versions it supports in its SETUP message (see message-setup).  It also includes the union of all Setup Parameters setup-params required for a handshake by any of those versions. </del> <ins> The client indicates the MOQT versions it supports in the CLIENT_SETUP message (see message-setup).  It also includes the union of all Setup Parameters setup-params required for a handshake by any of those versions. </ins> Within any MOQT version, clients request the use of extensions by adding SETUP parameters corresponding to that extension.  No extensions are defined in this document. <del> The server replies with a SETUP message that indicates the chosen version, includes all parameters required for a handshake in that version, and parameters for every extension requested by the client that it supports. </del> <ins> The server replies with a SERVER_SETUP message that indicates the chosen version, includes all parameters required for a handshake in that version, and parameters for every extension requested by the client that it supports. </ins> New versions of MOQT MUST specify which existing extensions can be used with that version.  New extensions MUST specify the existing

Related discussion:
text: Feel free to change the numbers to any ones you prefer.
There's a single SETUP message, but the contents change based on if the endpoint is a server or a client. . This is difficult to implement in type safe languages. I would implement and , sharing the same ID. However, it's then difficult to implement a generic method as it needs to know the expected role to distinguish between the two. I propose a separate and message akin to how TLS has a separate and . Alternatively, implement to reclassify SETUP and OBJECT as control and data stream headers respectively.
Hmm, so this isn't a problem in my code any longer since made SETUP a special message type. We should still figure out if both the client and server SETUP use the same ID, or separate IDs like TLS.
I still like the idea of, if these message are different, they should have different names as it will just be confusing if they do not.
Agreement these should be different message types, just like TLS.
Conveniently, message id=2 is currently not used. I propose ClientSetup = 1 and ServerSetup = 2.
Thinking about this a bit more, do we want to bake in the assumption that the client always speaks first into the protocol? For raw QUIC, typically, the server would have 1-RTT keys first.
I would love to see something like HTTP/3 SETTINGS where both endpoints can send the message in parallel. That requires version negotiation at a lower level in something like ALPN though. The SERVER SETUP would be sent first in native QUIC while the CLIENT SETUP could be sent first with WebTransport (in parallel with CONNECT).
LGTM