jiebi/CodeConvo huggingface dataset:
Code change:
NAME does the updated text with OPEN ISSUE looks about right to you. I personally feel we should revisit all the terms and get to a common understaning across the documents. For -05 an OPEN ISSUE seems like OK. thoughts ?
LGTM

Related discussion:
text: BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> TODO: The terms defined here doesn't capture the ongoing discussions within the Working Group (either as part of requirements or architecture documents).  This section will be updated to reflect the discussions. </ins> Commonly used terms in this document are described below. 1.3.
Code change:
NAME please check the latest commit . thanks
Something is wrong, this PR appears blank
editorial nit if it can be addressed, otherwise LGTM

Related discussion:
text: Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del> <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del> <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.
Code change:
NAME please check the latest commit . thanks
Something is wrong, this PR appears blank
editorial nit if it can be addressed, otherwise LGTM

Related discussion:
text: BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> TODO: The terms defined here doesn't capture the ongoing discussions within the Working Group (either as part of requirements or architecture documents).  This section will be updated to reflect the discussions. </ins> Commonly used terms in this document are described below. 1.3.
Code change:
NAME please check the latest commit . thanks
Something is wrong, this PR appears blank
editorial nit if it can be addressed, otherwise LGTM

Related discussion:
text: 2. <ins> MoQT has a hierarchical object model for data, comprised of objects, groups and tracks. </ins> 2.1. <del> The basic element of MoQTransport is an </del> <ins> The basic data element of MoQTransport is an </ins> .  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and <del> potential dependencies. model-group Objects carry associated metadata such as priority, TTL, or other information usable by a relay, but relays MUST treat the object payload as opaque. The application is solely responsible for the contents of objects. This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del> <ins> potential dependencies. model-group Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> 2.2. A <del> is collection of objects, part of a larger track (model-track). A group behaves as a join point for subscriptions.  A new subscriber may not want to receive the entire track, and will instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. The application is responsible for how objects are placed into groups.  In general, objects within a group SHOULD NOT depend on objects in other groups. </del> <ins> is a collection of objects and is a sub-unit of a track (model- track).  Objects within a group SHOULD NOT depend on objects in other groups.  A group behaves as a join point for subscriptions.  A new subscriber might not want to receive the entire track, and may instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. </ins> 2.3. A <del> is a sequence of objects (model-object) organized into groups (model- group).  A subscriber can request individual tracks at group boundaries, including any new objects while the track is active. </del> <ins> is a sequence of groups (model-group).  It is the entity against which a consumer issues a subscription request.  A subscriber can request to receive individual tracks starting at a group boundary, including any new objects pushed by the producer while the track is active. </ins> 2.3.1.
Code change:
This PR by itself doesn't make a lot of sense but I'm ok rolling with it if it's part of the grand plan

Related discussion:
text: specific to the underlying transport protocol usage transport- protocols. <del> 2.4. A transport session is established for each track bundle.  The client issues a CONNECT request with a URL which the server uses for identification and authentication.  All control messages and prioritization occur within the context of a single transport session, which means a single track bundle.  When WebTransport is used, multiple transport sessions may be pooled over a single QUIC connection for efficiency. </del> 3. <del> MoQTransport works by transferring objects over QUIC streams.  The application determines how live content is fragmented into tracks, groups, and objects. </del> 3.1. At the point of this writing, the working group has not reached
Code change:
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.

Related discussion:
text: Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del> <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del> <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.
Code change:
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.

Related discussion:
text: BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> TODO: The terms defined here doesn't capture the ongoing discussions within the Working Group (either as part of requirements or architecture documents).  This section will be updated to reflect the discussions. </ins> Commonly used terms in this document are described below. 1.3.
Code change:
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.

Related discussion:
text: specific to the underlying transport protocol usage transport- protocols. <del> 2.4. A transport session is established for each track bundle.  The client issues a CONNECT request with a URL which the server uses for identification and authentication.  All control messages and prioritization occur within the context of a single transport session, which means a single track bundle.  When WebTransport is used, multiple transport sessions may be pooled over a single QUIC connection for efficiency. </del> 3. <del> MoQTransport works by transferring objects over QUIC streams.  The application determines how live content is fragmented into tracks, groups, and objects. </del> 3.1. At the point of this writing, the working group has not reached
Code change:
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.

Related discussion:
text: group.  The two proposals are listed in send-order and ordering-by- priorities.  We expect further work before a consensus is reached. <del> 3.2. TODO: Add text describing iteration of group and intra object priorities within a group and their relation to congestion response. Add how it refers to </del> 4. This document defines a protocol that can be used interchangeably
Code change:
No real changes here (other than adding a missing period) but changes newlines for checker tools
LGTM, as it seems to just whitespaces only change.

Related discussion:
text: how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription. <del> model describes the object model employed by MOQT </del> <ins> model describes the object model employed by MOQT. </ins> session covers aspects of setting up a MOQT session.
Code change:
No real changes here (other than adding a missing period) but changes newlines for checker tools
LGTM, as it seems to just whitespaces only change.

Related discussion:
text: The application MAY use any error message and SHOULD use a relevant code, as defined below: <del> Session Terminated No error occurred; however the endpoint wishes </del> <ins> Session Terminated: No error occurred; however the endpoint wishes </ins> to terminate the session. <del> Generic Error An unclassified error occurred. </del> <ins> Generic Error: An unclassified error occurred. </ins> Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.
Code change:
The stuff we had to italicize the stuff in html is inserting underscores in the .txt file so I just want to remove this until for now until we figure this out. Did not change anything other than making the words not italicized
Thanks for catching this , the rendered TXT file looks different for these things. Merging it for now and we can work on figuring out the right markdown syntax.

Related discussion:
text: 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 <del> ; 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> 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> The wire format of the SETUP message is as follows:
Code change:
Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.

Related discussion:
text: The ROLE parameter is mandatory for the client.  All of the other parameters are optional. <del> 6.1.1.1. </del> <ins> 6.1.2.1. </ins> 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
Code change:
Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.

Related discussion:
text: or it is different from what the server expects based on the application. <del> 6.1.1.2. </del> <ins> 6.1.2.2. </ins> The PATH parameter (key 0x01) allows the client to specify the path of the MoQ URI when using native QUIC (QUIC).  It MUST NOT be used by
Code change:
Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.

Related discussion:
text: 6.6. <ins> A subscriber issues a "UNSUBSCRIBE" message to a publisher indicating it is no longer interested in receiving media for the specified track. The format of "UNSUBSCRIBE" is as follows: Full Track Name: Identifies the track as defined in (track-name). 6.7. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is