jiebi/CodeConvo huggingface dataset:
Code change:
NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"? In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:

Related discussion:
text: over loss, and may be more accepting of having slightly more latency to increase guarantee of delivery. <del> 3.3.1. </del> <ins> 3.2.1. </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/
Code change:
NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"? In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:

Related discussion:
text: data sent by the receiver, and the media may go through additional steps of transcoding or transformation before being distributed. <del> 3.3.2. </del> <ins> 3.2.2. </ins> Where media is sent onwards to another platform for further distribution and not directly used for presentation to an audience,
Code change:
NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"? In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:

Related discussion:
text: larger than final distribution output.  Streams may be redundant with failover mechanisms in place. <del> 3.3.3. </del> <ins> 3.2.3. </ins> Where media is received from a live broadcast or stream either as a broadcast with fixed duration or as ongoing 24/7 output.  The number
Code change:
NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"? In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:

Related discussion:
text: 7.1.  URIs <del> [1] https://github.com/fiestajetsam/draft-gruessing-moq-requirements </del> <ins> [1] https://github.com/moq-wg/moq-requirements </ins> [2] https://www.ietf.org/mailman/listinfo/moq
Code change:
I suspect this may require a little bit more thought, but want to sense-check the direction. NAME any feedback you have would be welcome.
NAME NAME thank you both for your feedback, I've rewritten the block again based on your feedback and hope this is a lot more clearer.
MoQ Transport, in combination with a MoQ Streaming Format, needs to support mechanisms to allow ad insertion. This ad insertion: Should be compliant with current IAB and SCTE standards such as SCTE-35, which specifies signals that can be used to identify advertising breaks, advertising content, and programming content. VAST (Video Ad Serving Template) VPAID (Video Player Ad-serving Interface Definition) VMAP (Video Multiple Ad Playlist) Should be able to participate in both server-side and client side ad insertion schemes. The server-side solution may have a mode in which the ad is stitched seamlessly into the primary content and the ad boundaries are indistinguishable to the client. Should be dynamic in nature, allowing for just-in-time decisions to be made for choosing which content to insert. Should allow access to, and compatibility with, a subset of existing ad inventory.
Some of my initials thoughts: To stick to the separation model of "church and state", we should also have agility to support more than SCTE-35/IAB specs in the transport layer Is it required that all streaming formats must support event tracks? Or is the requirement here that just the transport through the catalog enables it? Is there a benefit to describing these requirements more generically - although enabling advertising for live broadcast is clearly the obvious use case having this functionality could be useful for other reasons, such as: In teleconferencing, a presenter switching one (or all) viewer's video to a different source such as the slide show or the presenters camera Falling viewers over to another source when the current one ends e.g Twitch's "raiding"
Given the PR above is merged, I'm closing this noting the above issue on ingest will carry on.

Related discussion:
text: of the past 30 seconds and replay them in order to "synchronize" the video decoder. <ins> 4.8.6. In all of the applicable use cases defined in overallusecases it may be necessary for consumers to be aware of changes to the source of media being inserted, or be instructed to consume media from a different source.  These may be done for the insertion of advertising or for operational movement of consumers, amongst other reasons. Within the media insertion scenario an existing stream being consumed may change as a result of a different source being spliced which necessitates the decoder being reset as parameters such as video frame rate, image resolution etc may have changed.  For redirection, consumers may be signalled to consume media from a different source which may also require re-initialization of decoder. In both of these scenarios, triggering may occur either through an event provided in the media such as a SCTE-35 marker, or through an external trigger.  Both should be supported. </ins> 4.9. 4.9.1.
Code change:
One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!

Related discussion:
text: This document describes the uses cases, requirements, and considerations that should guide the design of the encapsulation of a <del> real-time media transport protocol as a payload in the the QUIC protocol RFC9000. </del> <ins> real-time media transport protocol as a payload in the QUIC protocol RFC9000. </ins> Protocol developers have been considering the implications of the QUIC protocol (RFC9000) on media transport for several years, but the
Code change:
One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!

Related discussion:
text: and delivery of SRT on top of QUIC using datagram frame types.  This specification sets some requirements regarding how the two interact and leaves considerations for congestion control and pacing to <del> prevent conflict between the two protocols. </del> <ins> prevent conflict between the two protocols.  Apart from that, SRT provides a native suport for stream multiplexing, thus contributing this missing functionality to QUIC datagrams. </ins> 3.5.
Code change:
One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!

Related discussion:
text: Interactive client-server applications.  For example, a "click here to speak to a representative" button on a website that starts an <del> interactive WebRTC call.  Such applications avoid the NAT traversal issues that complicate peer-to-peer use of QUIC, and can benefit from stream demultiplexing and (if appropriate algorithms are provided) </del> <ins> interactive WebRTC call.  Because a connection is being established to a known server, such applications avoid the NAT traversal issues that complicate peer-to-peer use of QUIC, and can benefit from stream demultiplexing and (if appropriate algorithms are provided) </ins> congestion control.  They would benefit from unreliable delivery modes to reduce latency.
Code change:
One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!

Related discussion:
text: 4.2.2. <ins> While a media is being contributed in real time via an ingest point to a streaming platform, there may be a need to distribute the media between several servers and/or perform a load balancing of the incoming traffic.  The platform may peform transcoding at one or several points, or distribute (route) the media as is to one or many egress points.  Such a distribution and load balancing may happen with or without the access to the encrypted payload. 4.2.3. </ins> Distribution from platform to audience.  Whilst use of WebRTC or RTSP today for On-Demand media streaming is not typical with adaptive streaming like HLS and DASH being predominantly used as WebRTC is
Code change:
One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!

Related discussion:
text: When initiating a media session, both the sender and receiver should be able to negotiate the codecs, bitrates and other media details <del> based on capabilities and preferences. </del> <ins> based on capabilities and preferences.  It may be prefered to use existing ecosystem for such purposes, e.g.  SDP RFC4566. </ins> 5.2.
Code change:
One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!

Related discussion:
text: often used in delivering media in our use cases, QUIC doesn't yet support multicast, and would require a QUIC protocol extension to do so.  In addition, the inclusion of multicast would introduce more <del> complexity in both the specification and client implimentations. </del> <ins> complexity in both the specification and client implimentations.  On the other hand, UDP multicast may be considered as the last mile delivery transport outside of QUIC transport, thus it would be beneficial for a protocol to provide such an opportunity (e.g.  RTP/ QUIC -> RTP/UDP). </ins> 7.
Code change:
This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.

Related discussion:
text: https://github.com/fiestajetsam/draft-gruessing-moq-requirements [1]. Discussion of this draft should take place on the IETF Media Over <del> QUIC (MOQ) mailing list, at https://www.ietf.org/mailman/listinfo/ moq. </del> <ins> QUIC (MoQ) mailing list, at https://www.ietf.org/mailman/listinfo/moq [2]. </ins> 1.
Code change:
This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.

Related discussion:
text: comprise of multiple audio or video outputs with different codecs or bitrates.  This may also include other types of media essence such as subtitles or timing signalling information (e.g. markers to indicate <del> change of behaviour in client such as advertisement breaks) </del> <ins> change of behaviour in client such as advertisement breaks).  The use of "live rewind" where a window of media behind the live edge can be made available for clients to playback, either because the local player falls behind edge or because the viewer wishes to play back from a point in the past. </ins> 4.6.
Code change:
This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.

Related discussion:
text: overview has normative language around congestion control which may be at odds with our potential requirements. <del> 5.7. </del> <ins> 6.8. </ins> The encapsulation SHOULD have capabilities beyond what QUIC provides to allow hosts to authenticate one another, this should be kept
Code change:
This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.

Related discussion:
text: TODO: More details are required here <del> 6. </del> <ins> 7. </ins> This section covers topics that are explicitly out of scope for the time being. <del> 6.1. </del> <ins> 7.1. </ins> From Section 8.2 of RFC9000:
Code change:
This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.

Related discussion:
text: NAT traversal, a QUIC protocol extention would be required to support those use cases today. <del> 6.2. </del> <ins> 7.2. </ins> The creation of new media transport protocols should be avoided, and instead we should make use of RTP RFC3550 and the existing ecosystem
Code change:
This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.

Related discussion:
text: in which case we should work with the relevant working groups and present our use-cases. <del> 6.3. </del> <ins> 7.3. </ins> Even if multicast and other network broadcasting capabilities are often used in delivering media in our use cases, QUIC doesn't yet