jiebi/CodeConvo huggingface dataset:
Code change:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Related discussion:
text: Our goal in this section is to understand the requirements that result from the use cases described in overallusecases. <ins> 4.1. Note: the intention for the requirements in this document is that they are useful for MOQ working group participants, to recognize constraints, and useful for readers outside the MOQ working group to understand the high-level functionality of the MOQ protocol, as they consider implementation and deployment of systems that rely on the MOQ protocol. </ins> *Note: the initial high-level organization for this section is taken from Suhas Nandakumar's presentation, "Progressing MOQ" Prog-MOQ, at the October 2022 MOQ virtual interim meeting, which was in turn taken
Code change:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Related discussion:
text: TODO: Describe overall, high level requirements that we previously stated in earlier versions of this document. <del> 4.1. </del> <ins> 4.2. </ins> Many of the use cases have bi-directional flows of media, with clients both sending and receiving media concurrently, thus the
Code change:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Related discussion:
text: is unsupported (e.g. a live media server signalling it does not support receiving from a given client). <del> 4.2. </del> <ins> 4.3. </ins> In the initiation of a session both client and server must perform negotiation in order to agree upon a variety of details before media
Code change:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Related discussion:
text: Re-negotiation in an existing protocol should be supported to allow changes in what is being sent of received. <del> 4.3. </del> <ins> 4.4. </ins> As multiple streams of media may be available for concurrent sending such as multiple camera views or audio tracks, a means of both
Code change:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Related discussion:
text: should be supported, but further extended metadata of the contents of the media or its ontology should not be supported. <del> 4.4. </del> <ins> 4.5. </ins> Packaging of media describes how encapsulation of media to carry the raw media will work.  There are at a high level two approaches to
Code change:
This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.

Related discussion:
text: packaging of media, taking into consideration the various technical trade offs that each provide. <del> 4.5. </del> <ins> 4.6. </ins> End-to-end security describes the use of encryption of the media stream(s) to provide confidentiality in the presence of unauthorized
Code change:
NAME I could also include some other non-requirements into the section if you have some to mind.
A similar section seemed helpful during discussion of URL My first nominee (and I'll put that in the corresponding PR) is that we're assuming that we're working with existing media transport protocols like RTP and SRP, rather than inventing a new media transport protocol in the IETF, but we can talk when I have text.
We have this in place, and I think we have enough non-requirements to start with, let's keep adding as appropriate.

Related discussion:
text: 5. <del> This document makes no requests of IANA. </del> <ins> This section covers topics that are explicitly out of scope for the time being. 5.1. The creation of new media transport protocols should be avoided, and instead we should make use of RTP RFC3550 and the existing ecosystem of payload formats and methods of signalling where possible.  It may transpire a need to extend these specificiations; in which case we should work with the relevant working groups and present our use- cases. </ins> 6. <ins> This document makes no requests of IANA. 7. </ins> As this document is intended to create discussion and consensus and introduces no security considerations of its own. <del> 7.  References </del> <ins> 8.  References </ins> <del> 7.1.  URIs </del> <ins> 8.1.  URIs </ins> [1] https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing- moq-requirements
Code change:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Related discussion:
text: This document defines the core behavior for Warp, a live media transport protocol over QUIC.  Media is split into objects based on the underlying media encoding and transmitted independently over QUIC <del> streams.  QUIC streams are prioritized based on the delivery order, </del> <ins> streams.  QUIC streams are prioritized based on the send order, </ins> allowing less important objects to be starved or dropped during congestion.
Code change:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Related discussion:
text: The encoder determines how to fragment the encoded bitstream into objects (media). <del> Objects are assigned an intended delivery order that should be obeyed during congestion (delivery-order) </del> <ins> Objects are assigned an intended send order that should be obeyed during congestion (send-order) </ins> The decoder receives each objects and skips any objects that do not arrive in time (decoder).
Code change:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Related discussion:
text: this ordering during congestion without increasing latency. The encoder determines how to behave during congestion by assigning <del> each object a numeric delivery order.  The delivery order SHOULD be followed when possible to ensure that the most important media is delivered when throughput is limited.  Note that the contents within each object are still delivered in order; this delivery order only applies to the ordering between objects. </del> <ins> each object a numeric send order.  The send order SHOULD be followed when possible to ensure that the most important media is delivered when throughput is limited.  Note that the contents within each object are still delivered in order; this send order only applies to the ordering between objects. </ins> A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (prioritization) such that <del> streams are transmitted in delivery order. </del> <ins> streams are transmitted in send order. </ins> <del> A receiver MUST NOT assume that objects will be received in delivery </del> <ins> A receiver MUST NOT assume that objects will be received in send </ins> order for a number of reasons: <del> Newly encoded objects MAY have a smaller delivery order than </del> <ins> Newly encoded objects MAY have a smaller send order than </ins> outstanding objects. <del> Packet loss or flow control MAY delay the delivery of individual </del> <ins> Packet loss or flow control MAY delay the send of individual </ins> streams. The sender might not support QUIC stream prioritization.
Code change:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Related discussion:
text: The decoder will receive multiple objects in parallel and out of order. <del> Objects arrive in delivery order, but media usually needs to be processed in decode order.  The decoder SHOULD use a buffer to reassmble objects into decode order and it SHOULD skip objects after a configurable duration.  The amount of time the decoder is willing to wait for an object (buffer duration) is what ultimately determines </del> <ins> Objects arrive in send order, but media usually needs to be processed in decode order.  The decoder SHOULD use a buffer to reassmble objects into decode order and it SHOULD skip objects after a configurable duration.  The amount of time the decoder is willing to wait for an object (buffer duration) is what ultimately determines </ins> the end-to-end latency. Objects MUST synchronize frames within and between tracks using
Code change:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Related discussion:
text: this to priority-congestion. The producer may assign a numeric delivery order to each object <del> (delivery-order) </del> <ins> (send-order) </ins> This is a strict prioritization scheme, such that any available bandwidth is allocated to streams in ascending priority order.  The <del> sender SHOULD prioritize streams based on the delivery order.  If two streams have the same delivery order, they SHOULD receive equal bandwidth (round-robin). </del> <ins> sender SHOULD prioritize streams based on the send order.  If two streams have the same send order, they SHOULD receive equal bandwidth (round-robin). </ins> QUIC supports stream prioritization but does not standardize any mechanisms; see Section 2.3 in QUIC.  In order to support
Code change:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Related discussion:
text: priority order. The sender MUST respect flow control even if means delivering streams <del> out of delivery order.  It is OPTIONAL to prioritize retransmissions. </del> <ins> out of send order.  It is OPTIONAL to prioritize retransmissions. </ins> 6.2.
Code change:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Related discussion:
text: Warp encodes the delivery information for a stream via OBJECT headers (message-object). <del> A relay SHOULD prioritize streams (prioritization) based on the delivery order.  A relay MAY change the delivery order, in which case it SHOULD update the value on the wire for future hops. </del> <ins> A relay SHOULD prioritize streams (prioritization) based on the send order.  A relay MAY change the send order, in which case it SHOULD update the value on the wire for future hops. </ins> 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
Code change:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Related discussion:
text: Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group. <del> Object Delivery Order: An integer indicating the object delivery order (delivery-order). </del> <ins> Object Send Order: An integer indicating the object send order (send-order). </ins> Object Payload: The format depends on the track container (containers).  This is a media bitstream intended for the decoder
Code change:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Related discussion:
text: 16.3. <del> The delivery order (delivery-order depends on the desired user experience during congestion: </del> <ins> The send order (send-order depends on the desired user experience during congestion: </ins> <del> if media should be skipped: delivery order = PTS </del> <ins> if media should be skipped: send order = PTS </ins> <del> if media should not be skipped: delivery order = -PTS </del> <ins> if media should not be skipped: send order = -PTS </ins> <del> if video should be skipped before audio: audio delivery order < video delivery order </del> <ins> if video should be skipped before audio: audio send order < video send order </ins> <del> The delivery order may be changed if the content changes.  For example, switching from a live stream (skippable) to an advertisement </del> <ins> The send order may be changed if the content changes.  For example, switching from a live stream (skippable) to an advertisement </ins> (unskippable).
Code change:
NAME does the latest commit address your feedback? thanks
lgtm modulo addressing Luke's comment.

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 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: 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.