jiebi/CodeConvo huggingface dataset:
Code change:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Related discussion:
text: A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.  Packet loss will cause stream data <del> to be buffered in the QUIC library, awaiting in order delivery, which will increase latency over additional hops.  To mitigate this, a relay SHOULD read and write QUIC stream data out of order subject to flow control limits.  See section 2.2 in QUIC. </del> <ins> to be buffered in the library, awaiting in order delivery, which will increase latency over additional hops.  To mitigate this, a relay SHOULD read and write stream data out of order subject to flow control limits.  See section 2.2 in QUIC. </ins> 6. <del> Both unidirectional and bidirectional QUIC streams contain sequences of length-delimited messages. </del> <ins> Both unidirectional and bidirectional streams contain sequences of length-delimited messages. </ins> An endpoint that receives an unknown message type MUST close the connection.
Code change:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Related discussion:
text: Live content requires significant bandwidth and resources.  Failure to set limits will quickly cause resource exhaustion. <del> MOQT uses QUIC flow control to impose resource limits at the network layer.  Endpoints SHOULD set flow control limits based on the anticipated bitrate. </del> <ins> MOQT uses stream limits and flow control to impose resource limits at the network layer.  Endpoints SHOULD set flow control limits based on the anticipated bitrate. </ins> Endpoints MAY impose a MAX STREAM count limit which would restrict the number of concurrent streams which a MOQT Streaming Format could
Code change:
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

Related discussion:
text: 6.2. <del> The "SETUP" message is the first message that is exchanged by the client and the server; it allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called SETUP parameters; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </del> <ins> The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages exchanged by the client and the server; they allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called SETUP parameters; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </ins> <del> The wire format of the SETUP message is as follows: </del> <ins> The wire format of the SETUP messages is as follows: </ins> The available versions and SETUP parameters are detailed in the next sections.
Code change:
This were replaced in Subscribe Locations (hints)
These parameters have been replaced with explicit fields in the SUBSCRIBE message. All that's left (outside of SETUP) is AUTHORIZATIONINFO in SUBSCRIBE and ANNOUNCE. I would just as soon get rid of non-setup parameters entirely and have an "authinfolength" field in the messages which can be zero. At a minimum, we need to eliminate GROUP and OBJECT_SEQUENCE.
+1 I would go even further and make a dedicated AUTH message.
Whoops, those were deleted but must have been re-added in a merge conflict.

Related discussion:
text: 6.1.1.1. <del> The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects in a SUBSCRIBE message.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  The value is of type varint. 6.1.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects in a SUBSCRIBE message.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted. The value is of type varint. 6.1.1.3. </del> AUTHORIZATION INFO parameter (key 0x02) identifies a track's authorization information in a SUBSCRIBE or ANNOUNCE message.  This parameter is populated for cases where the authorization is required
Code change:
When we added (b) we didn't update this.
SUBSCRIBE_RST as well
and ANNOUNCE_ERROR

Related discussion:
text: Reason Phrase Length: The length in bytes of the reason phrase. <del> Reason Phrase: Provides the reason for subscription error and "Reason Phrase Length" field carries its length. </del> <ins> Reason Phrase: Provides the reason for subscription error. </ins> 6.7.
Code change:
When we added (b) we didn't update this.
SUBSCRIBE_RST as well
and ANNOUNCE_ERROR

Related discussion:
text: Error Code: Identifies an integer error code for subscription failure. <del> Reason Phrase Length: The length in bytes of the reason phrase. Reason Phrase: Provides the reason for subscription error and "Reason Phrase Length" field carries its length. </del> <ins> Reason Phrase: Provides the reason for subscription error. </ins> Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track.
Code change:
When we added (b) we didn't update this.
SUBSCRIBE_RST as well
and ANNOUNCE_ERROR

Related discussion:
text: Error Code: Identifies an integer error code for announcement failure. <del> Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. </del> <ins> Reason Phrase: Provides the reason for announcement error. </ins> 6.13.
Code change:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Related discussion:
text: ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <del> OBJECT message header carry short hop-by-hop Track Id that maps to </del> <ins> OBJECT message header carry short hop-by-hop Track ID that maps to </ins> the Full Track Name (see message-subscribe-ok).  Relays use the Track ID of an incoming OBJECT message to identify its track and find the active subscribers for that track.  Relays MUST NOT depend on OBJECT
Code change:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Related discussion:
text: specified track, as well as associated metadata required to deliver, cache, and forward it.  There are two subtypes of this message.  When the message type is 0x00, the optional Object Payload Length field is <del> present.  When the message type ix 0x02, the field is not present. </del> <ins> present.  When the message type is 0x02, the field is not present. </ins> The format of the OBJECT message is as follows: <del> Track ID: The track identifier obtained as part of subscription and/or publish control message exchanges. </del> <ins> Track ID : The compressed full track name obtained as part of subscription and/or publish control message exchanges. </ins> Group Sequence : The object is a member of the indicated group model-group within the track.
Code change:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Related discussion:
text: 6.4.2. <del> The format of SUBSCRIBE REQUEST is as follows: </del> <ins> The format of SUBSCRIBE is as follows: </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). <ins> Subscribe ID: Session unique identifier for the subscription. "Subscribe ID" is monotonically increasing variable length integer and it MUST uniquely identify a subscription within a session. "Subscribe ID" is used by subscribers and the publishers to identify a given subscription.  Subscribers specify the "Subscribe ID" and it is included in the corresponding SUBSCRIBE_OK or SUBSCRIBE_ERROR. </ins> StartGroup: The Location of the requested group.  StartGroup's Mode MUST NOT be None.
Code change:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Related discussion:
text: publisher MUST NOT send objects from outside the requested start and end. <ins> TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.) </ins> 6.4.3. 6.5.
Code change:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Related discussion:
text: the Full Track Name in the Track ID field of the OBJECT (message- object) message headers of the requested track.  Track IDs are generally shorter than Full Track Names and thus reduce the <del> overhead in OBJECT messages. </del> <ins> overhead in OBJECT messages Subscribe ID: Subscription Identifer from the incoming subscription request for which this message is the response. </ins> Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays
Code change:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Related discussion:
text: A publisher sends a SUBSCRIBE_ERROR control message in response to a failed SUBSCRIBE. <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> <ins> Subscribe ID: Subscription Identifer as defined in message- subscribe-req. </ins> Error Code: Identifies an integer error code for subscription failure.
Code change:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Related discussion:
text: The format of "UNSUBSCRIBE" is as follows: <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> <ins> Subscribe ID: Subscription Identifer as defined in message- subscribe-req. </ins> 6.8.
Code change:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Related discussion:
text: The format of "SUBSCRIBE_FIN" is as follows: <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> <ins> Subscribe ID: Subscription identifier as defined in message- subscribe-req. </ins> Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track.
Code change:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Related discussion:
text: The format of "SUBSCRIBE_RST" is as follows: <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> <ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req. </ins> Error Code: Identifies an integer error code for subscription failure.
Code change:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Related discussion:
text: This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no other uses of bidirectional streams, a peer MAY currently close the <del> connection if it receives a second bidirectional stream. </del> <ins> session as a 'Protocol Violation' if it receives a second bidirectional stream. </ins> The control stream MUST NOT be abruptly closed at the underlying transport layer.  Doing so results in the session being closed as a
Code change:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Related discussion:
text: length-delimited messages. An endpoint that receives an unknown message type MUST close the <del> connection. </del> <ins> session. </ins> 6.1.
Code change:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Related discussion:
text: Senders MUST NOT repeat the same parameter type in a message. Receivers SHOULD check that there are no duplicate parameters and <del> close the connection if found. </del> <ins> close the session as a 'Protocol Violation' if found. </ins> Receivers ignore unrecognized parameters.
Code change:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Related discussion:
text: server MUST reply with one of the versions offered by the client.  If the server does not support any of the versions offered by the client, or the client receives a server version that it did not <del> offer, the corresponding peer MUST close the connection. </del> <ins> offer, the corresponding peer MUST close the session. </ins> [[RFC editor: please remove the remainder of this section before publication.]]
Code change:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Related discussion:
text: possible values, which are of type varint: The client MUST send a ROLE parameter with one of the three values <del> specified above.  The server MUST close the connection if the ROLE </del> <ins> specified above.  The server MUST close the session if the ROLE </ins> 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.