jiebi/CodeConvo huggingface dataset:
Code change:
I believe some of this is covered by the recently updated GOAWAY section and I'm not sure what else to add here.
I don't think these TODOs have been covered yet. That being said, I would rather we file issues for these so there can be a conversation, rather than litter the draft with TODOs.
I'm unsure what's unresolved, but if you can file new issues as appropriate and link them to this PR, that would be helpful.

Related discussion:
text: 5.3. <del> TODO: This section shall cover aspects of relay failover and protocol interactions. 5.4. TODO: This section shall cover reconnect considerations for clients when moving between the Relays. 5.5. </del> TODO: Refer to priority-congestion.  Add details to describe relay behavior when merging or splitting streams and interactions with congestion response. <del> 5.6. </del> <ins> 5.4. </ins> MOQT encodes the delivery information for a stream via OBJECT headers (message-object).
Code change:
I think the intent of the draft was clear but this makes it explicit not to open a uni stream before setup exchange is done.
It's unclear what messages are allowed to be sent or received during the SETUP handshake. Here's my intuition: Until receiving the SETUP, the client: MUST NOT send messages MUST buffer any received messages. Until receiving the SETUP, the server: MUST NOT send messages. MUST NOT receive messages. The client needs to buffer messages because the server is unaware of when the client receives the SETUP. There's no equivalent to HANDSHAKE_DONE, and adding something like that would add an RTT anyway.
A potential optimization exists if the message encoding if the same for all supported versions (invariants). For example, if the client only advertises support for versions 1,2,3 and those versions share the same SUBSCRIBE encoding and meaning. This seems unlikely, given a separate version was created in the first place, and seems very brittle. If this was the case, then the client could process any invariant messages immediately and buffer the others. However, the client still couldn't send messages unless the server buffered any received messages.
The most flexible optimization would be the one where you could encode the SUBSCRIBE_REQUEST for every version you offer as a field in SETUP parameters. TLS does not do exactly that, but there are some things in ClinetHello that are only applicable for certain versions.

Related discussion:
text: The first stream opened is a client-initiated bidirectional control stream where the peers exchange SETUP messages (message-setup).  All <del> messages defined in this draft are sent on the control stream after the SETUP message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </del> <ins> messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the SETUP message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </ins> This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no
Code change:
It's only used a few times and now that Namespace and Name are an opaque sequence of bytes, it's even less compelling.
Take the line from your drafts that says There is no valid way to parse the right hand of this. We have things like "Full Track Name Length" and "Full Track Name". I do not think we should have ambiguous syntax for things that require precision. I think it would also be good to have things that can be directly mapped to common programming languages. This moves beyound simply editorial, or specification is underspecified and ambiguous until we fix this.
One possible solution would be use underscore or CamelCase
Oh, and the longer we leave this dumpster fire, the more painful it will be to fix.
love it

Related discussion:
text: associated with it.  A track name identifies an individual track within the namespace. <del> A tuple of a track name and a track namespace together is known as a full track name: </del> A MOQT scope is a set of servers (as identified by their connection <del> URIs) for which full track names are guaranteed to be unique.  This implies that within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.  It is up to the application using MOQT to define how broad or narrow the scope has to be.  An application that deals with connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those CDNs. The full track name is the only piece of information that is used to identify the track within a given MOQT scope and is used as cache key.  MOQT does not provide any in-band content negotiation methods similar to the ones defined by HTTP (RFC9110); if, at a given moment in time, two tracks within the same scope contain different data, they have to have different full track names. </del> <ins> URIs) for which the tuple of Track Name and Track Namespace are guaranteed to be unique and identify a specific track.  It is up to the application using MOQT to define how broad or narrow the scope is.  An application that deals with connections between devices on a local network may limit the scope to a single connection; by contrast, an application that uses multiple CDNs to serve media may require the scope to include all of those CDNs. Because the tuple of Track Namespace and Track Name are unique within an MOQT scope, they can be used as a cache key.  MOQT does not provide any in-band content negotiation methods similar to the ones defined by HTTP (RFC9110); if, at a given moment in time, two tracks within the same scope contain different data, they have to have different names and/or namespaces. </ins> In this specification, both the Track Namespace and the Track Name are not constrained to a specific encoding.  They carry a sequence of
Code change:
It's only used a few times and now that Namespace and Name are an opaque sequence of bytes, it's even less compelling.
Take the line from your drafts that says There is no valid way to parse the right hand of this. We have things like "Full Track Name Length" and "Full Track Name". I do not think we should have ambiguous syntax for things that require precision. I think it would also be good to have things that can be directly mapped to common programming languages. This moves beyound simply editorial, or specification is underspecified and ambiguous until we fix this.
One possible solution would be use underscore or CamelCase
Oh, and the longer we leave this dumpster fire, the more painful it will be to fix.
love it

Related discussion:
text: Subscribers interact with the Relays by sending a SUBSCRIBE (message- subscribe-req) control message for the tracks of interest.  Relays MUST ensure subscribers are authorized to access the content <del> associated with the Full Track Name.  The authorization information can be part of subscription request itself or part of the encompassing session.  The specifics of how a relay authorizes a user are outside the scope of this specification. </del> <ins> associated with the track.  The authorization information can be part of subscription request itself or part of the encompassing session. The specifics of how a relay authorizes a user are outside the scope of this specification. </ins> The subscriber making the subscribe request is notified of the result of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the
Code change:
It's only used a few times and now that Namespace and Name are an opaque sequence of bytes, it's even less compelling.
Take the line from your drafts that says There is no valid way to parse the right hand of this. We have things like "Full Track Name Length" and "Full Track Name". I do not think we should have ambiguous syntax for things that require precision. I think it would also be good to have things that can be directly mapped to common programming languages. This moves beyound simply editorial, or specification is underspecified and ambiguous until we fix this.
One possible solution would be use underscore or CamelCase
Oh, and the longer we leave this dumpster fire, the more painful it will be to fix.
love it

Related discussion:
text: SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. For successful subscriptions, the publisher maintains a list of <del> subscribers for each full track name.  Each new OBJECT belonging to the track is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> subscribers for each track.  Each new OBJECT belonging to the track within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RST (see message-subscribe-rst). </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription
Code change:
Currently, VarInts have two lengths: In the parameter length. In the first two bits of the parameter value. The decision in was that the two MUST match, which is a good solution without a full reform. However: Ignoring seems like the wrong play. For example, we know the role parameter (0x0) is a VarInt in the current draft. However this text says I MUST ignore any errors when parsing this varint and pretend like the parameter was never sent, which is both unenforceable and a major foot-gun (silently ignoring parameters). I think we close the connection with an error if there's an error parsing a known parameter.
If a parameter is unknown, then the parser doesn't know if the value is a varint and therefore can't check the length match. I thought it was better to have consistent behavior than not, because it's easier to write and easier to reason about. But if this has actual downstream consequences, I could be convinced otherwise.
I don't know what I was smoking when I came up with this title. My concern is that when a known parameter has the wrong length, the text says the decoder MUST ignore it. But it likely has the wrong length due to a bug, so this will cause unintended (non-fatal) behavior.
I understand what you mean. My point was that an unknown parameter has an inevitable result, and trying to make the processing for known parameters the same had some advantages. We'll discuss today.
Conclusion was to make it an error instead of skipping over the field if there's a length mismatch.
LG, though we can bikeshed about the error code name.

Related discussion:
text: of the Parameter Value field in bytes. Each parameter description will indicate the data type in the <del> Parameter Value field.  If the parameter value is a varint, but the self-encoded length of that varint does not match the Parameter Length field, the receiver MUST ignore the parameter using the value in the Parameter Length field. </del> <ins> Parameter Value field.  If a receiver understands a parameter type, and the parameter length implied by that type does not match the Parameter Length field, the receiver MUST terminate the session with error code 'Parameter Length Mismatch'. </ins> 6.1.1.
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: SUBSCRIBE_RST (see message-subscribe-rst). A relay MUST not reorder or drop objects received on a multi-object <del> stream when forwarding to subscribers. </del> <ins> stream when forwarding to subscribers, unless it has application specific information. </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: subscription request is cached and shared among the pending subscribers. <ins> The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below: </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: 5.4. MOQT encodes the delivery information for a stream via OBJECT headers <del> (message-object). </del> <ins> (message-object).  A relay MUST NOT modify Object properties when forwarding. </ins> A relay MUST treat the object payload as opaque.  A relay MUST NOT combine, split, or otherwise modify object payloads.  A relay SHOULD
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: Track Alias: Identifies the Track Namespace and Track Name as defined in message-subscribe-req. <del> The Track Namespace and Track Name identified by the Track Alias is different from the one specified in the subscription identified by </del> <ins> If the Track Namespace and Track Name identified by the Track Alias are different from those specified in the subscription identified by </ins> Subscribe ID, the receiver MUST close the session with a Protocol Violation. Other fields: As described in canonical-object-fields. <ins> An "OBJECT_PREFER_DATAGRAM" message carries a single object in a datagram or a stream.  There is no explicit length of the payload; it is determined by the length of the datagram or stream.  If this message appears on a stream, it MUST be the first message on a unidirectional stream. An Object received in an "OBJECT_PREFER_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram". To send an Object with "Object Forwarding Preference" = "Datagram", determine the length of the fields and payload, and compare the length with the maximum datagram size of the session.  If the object size is less than or equal maximum datagram size, send the serialized data as a datagram.  Otherwise, open a stream, send the serialized data and terminate the stream.  An implementation SHOULD NOT send an Object with "Object Forwarding Preference" = "Datagram" on a stream if it is possible to send it as a datagram. </ins> 6.3.3. When multiple objects are sent on a stream, the stream begins with a
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the <del> same "Object Send Order". </del> <ins> "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: new one and send the "STREAM_HEADER_TRACK" if needed, then serialize the the following object fields. <ins> A sender MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object ID is less than or equal to a previously sent Object ID within a given group on that stream. </ins> When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID". <del> All objects on the stream have the same "Object Send Order". </del> <ins> All objects on the stream have the "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group".
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. <ins> A sender MUST NOT send an Object on a stream if its Object ID is less than a previously sent Object ID within a given group in that stream. </ins> 6.3.4. Sending a track on one stream:
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: objects from the group ID and object ID described above. If a publisher cannot satisfy the requested start or end for the <del> subscription it MAY send a SUBSCRIBE_ERROR with code TBD.  A publisher MUST NOT send objects from outside the requested start and end. </del> <ins> subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'. A 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.)
Code change:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Related discussion:
text: Reason Phrase: Provides the reason for subscription error. <del> Track Alias: When Error Code is TBD, the subscriber SHOULD re- issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session-termination).  TODO: Add a registry for subscribe error codes and make this field conditional. </del> <ins> Track Alias: When Error Code is 'Retry Track Alias', the subscriber SHOULD re-issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session- termination). </ins> 6.7.
Code change:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Related discussion:
text: SUBSCRIBE_RST (see message-subscribe-rst). A relay MUST not reorder or drop objects received on a multi-object <del> stream when forwarding to subscribers. </del> <ins> stream when forwarding to subscribers, unless it has application specific information. </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription
Code change:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Related discussion:
text: subscription request is cached and shared among the pending subscribers. <ins> The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below: </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE
Code change:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Related discussion:
text: 5.4. MOQT encodes the delivery information for a stream via OBJECT headers <del> (message-object). </del> <ins> (message-object).  A relay MUST NOT modify Object properties when forwarding. </ins> A relay MUST treat the object payload as opaque.  A relay MUST NOT combine, split, or otherwise modify object payloads.  A relay SHOULD
Code change:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Related discussion:
text: send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del> <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and