jiebi/TextFlow huggingface dataset:
Original text:
originating stream state changes to fully closed, all associated promised streams fully close as well. <del> There are no additional type-specific flags defined. </del>  Promised streams are not required to be used in order promised.  The PUSH_PROMISE only reserves stream identifiers for later use.

Reviewer comments:
Replaced 'body' with 'payload' in instances where it would be confusing. Added a flag in the HEADERS frame for header continuations. Added pointers in HEADERS+PRIORITY and PUSH_PROMISE which reference the flags in the HEADERS frame. This should
The continuation bit is inverted with respect to the FINAL flag. Is HEADER_END a better choice? Also, if an unbounded number of frames are permitted, then you need some way to place an upper bound on size. Especially since this requires* that all frames be assembled before processing. Currently, there isn't a default maximum, a setting or an error code.
It could be. I chose this polarity so that it was immediately compatible with what implementations do today for SPDY/2/3 (they don't know about such a bit). If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.
Let's move this discussion to the list.
NAME suggested that his header compression () would include the ability to continue header blocks across frames. We should track this as a separate issue. Important consideration is the way that header blocks mutate session state (for header compression). Interleaving of continued header frames will cause issues if we don't address this. We should also consider whether this is a general facility or not.
I believe we should fix this by declaring that, if there is a continuation happening, no new headers frame is allowed to be sent until the continuation is finished. It just gets too difficult to deal with otherwise. , martinthomson EMAIL:
To clarify - you mean that no headers frame on a different stream can be sent?
yes. It isn't the only possible solution, but it is relatively simple and it seems like it should be a rare enough case... -=R , Mark Nottingham EMAIL:

Revised text:
originating stream state changes to fully closed, all associated promised streams fully close as well.  <ins> PUSH_PROMISE uses exactly the same flags as the HEADERS frame.  See HEADERS for any flags. </ins> Promised streams are not required to be used in order promised.  The PUSH_PROMISE only reserves stream identifiers for later use.
Original text:
request.  Similarly, intermediaries might forward incomplete messages before detecting errors.  A server MAY generate a final response before receiving an entire request when the response does not depend <del> on the remainder of the request being correct.  A server or intermediary MAY use RST_STREAM -- with a code other than REFUSED_STREAM -- to abort a stream if a malformed request or response is received. </del>  These requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because

Reviewer comments:
Two paragraphs up we mandate the use of PROTOCOL_ERROR, so this is not necessary. For .

Revised text:
request.  Similarly, intermediaries might forward incomplete messages before detecting errors.  A server MAY generate a final response before receiving an entire request when the response does not depend  <ins> on the remainder of the request being correct. </ins> These requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because
Original text:
to "open".  A PUSH_PROMISE frame will transition the server-initiated stream identified by the "Promised Stream ID" field in the frame payload from "idle" to "reserved".  When a stream transitions out of <del> the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed".  That is, an endpoint may skip a stream identifier, with the effect being that the skipped stream is immediately closed. </del>  Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream

Reviewer comments:
I improved the text along the lines Jörg suggested. However, I realized that the transition should really be in the diagram. That's basically impossible given the nature of the diagram, but it's worth including in the description at least. For .
This is a good clarification. One note about a whitespace change but the textual changes are :+1:

Revised text:
to "open".  A PUSH_PROMISE frame will transition the server-initiated stream identified by the "Promised Stream ID" field in the frame payload from "idle" to "reserved".  When a stream transitions out of  <ins> the "idle" state, all "idle" streams that might have been opened by the peer with a lower-valued stream identifier immediately transition to "closed".  That is, an endpoint may skip a stream identifier, with the effect being that the skipped stream is immediately closed. </ins> Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream
Original text:
_RFC Editor: please remove this section before publication_ Source code and issues for this draft can be found at <del> https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing-moq- requirements [1]. </del>  1.

Reviewer comments:
This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)

Revised text:
_RFC Editor: please remove this section before publication_ Source code and issues for this draft can be found at  <ins> https://github.com/fiestajetsam/draft-gruessing-moq-requirements [1]. </ins> 1.
Original text:
3. <del> For the sake of completeness this is a description of the known use- cases that have been described which would have applicability to the real-time serving of media over QUIC, and MoQ participants should consider which use case(s) should be part of any work, and which can be excluded.  Previously I-D.draft-rtpfolks-quic-rtp-over-quic defined several key use cases, in addition to several others which may be summarised under the following: Peer-to-peer interactive applications, such as telephony or video conferencing.  This may be in a 1-to-1 scenario, or in a multi- party arrangement.  TODO: add more description here. </del>  Unidirectional live stream contribution.  Two immediate scenarios that best describe this is firstly users on a streaming platform in a remote scenario from their phone live streaming an event or

Reviewer comments:
This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)

Revised text:
3.  <ins> Previously I-D.draft-rtpfolks-quic-rtp-over-quic defined several key use cases, in addition to several others defined elsewhere.  The two use cases that are most applicable today given the existing and known future capabilities of QUIC include: </ins> Unidirectional live stream contribution.  Two immediate scenarios that best describe this is firstly users on a streaming platform in a remote scenario from their phone live streaming an event or
Original text:
4. <del> TODO: Fill this in with detail </del>  5.

Reviewer comments:
This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)

Revised text:
4.  <ins> This section lists requirements for providing real time media streaming over a QUIC connection. 4.1. When initiating a media session, both the sender and receiver should be able to negotiate the codecs, bitrates and other media details based on capabilities and preferences. 4.2. Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently. 4.3. TODO: Unsure if this should be a requirement.  If it is, we have to consider two things: WebTransport supports HTTP/2, are we going to explicitly exclude it?  Also, WebTransport I-D.draft-ietf-webtrans- overview has normative language around congestion control which may be at odds with our potential requirements. 4.4. The protocol SHOULD have capabilities asides from TLS mutual authentication to allow hosts to authenticate one another, this should be kept simple but robust in nature to prevent attacks like credential brute-forcing. </ins> 5.
Original text:
should work with the relevant working groups and present our use- cases.  6. This document makes no requests of IANA.

Reviewer comments:
This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)

Revised text:
should work with the relevant working groups and present our use- cases. <ins> 5.2. Even if multicast and other network broadcasting capabilities are used in delivering media in our use cases, as QUIC doesn't yet support it and it's inclusion would require a lot more complexity in both the specification and client implimentation this should be left out for now. </ins> 6. This document makes no requests of IANA.
Original text:
8.1.  URIs <del> [1] https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing- moq-requirements </del> 

Reviewer comments:
This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)

Revised text:
8.1.  URIs  <ins> [1] https://github.com/fiestajetsam/draft-gruessing-moq-requirements </ins>
Original text:
7.1.  URIs <del> [1] https://github.com/fiestajetsam/draft-gruessing-moq-requirements </del>  [2] https://www.ietf.org/mailman/listinfo/moq

Reviewer comments:
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:

Revised text:
7.1.  URIs  <ins> [1] https://github.com/moq-wg/moq-requirements </ins> [2] https://www.ietf.org/mailman/listinfo/moq
Original 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>  Protocol developers have been considering the implications of the QUIC protocol (RFC9000) on media transport for several years, but the

Reviewer comments:
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!

Revised text:
This document describes the uses cases, requirements, and considerations that should guide the design of the encapsulation of a  <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
Original 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>  3.5.

Reviewer comments:
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!

Revised 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  <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.
Original 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>  congestion control.  They would benefit from unreliable delivery modes to reduce latency.

Reviewer comments:
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!

Revised text:
Interactive client-server applications.  For example, a "click here to speak to a representative" button on a website that starts an  <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.
Original text:
4.2.2.  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

Reviewer comments:
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!

Revised 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
Original 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>  5.2.

Reviewer comments:
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!

Revised text:
When initiating a media session, both the sender and receiver should be able to negotiate the codecs, bitrates and other media details  <ins> based on capabilities and preferences.  It may be prefered to use existing ecosystem for such purposes, e.g.  SDP RFC4566. </ins> 5.2.
Original 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>  7.

Reviewer comments:
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!

Revised 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  <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.
Original 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>  1.

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

Revised text:
https://github.com/fiestajetsam/draft-gruessing-moq-requirements [1]. Discussion of this draft should take place on the IETF Media Over  <ins> QUIC (MoQ) mailing list, at https://www.ietf.org/mailman/listinfo/moq [2]. </ins> 1.
Original 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>  4.6.

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

Revised 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  <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.
Original text:
overview has normative language around congestion control which may be at odds with our potential requirements. <del> 5.7. </del>  The encapsulation SHOULD have capabilities beyond what QUIC provides to allow hosts to authenticate one another, this should be kept

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

Revised text:
overview has normative language around congestion control which may be at odds with our potential requirements.  <ins> 6.8. </ins> The encapsulation SHOULD have capabilities beyond what QUIC provides to allow hosts to authenticate one another, this should be kept
Original text:
TODO: More details are required here <del> 6. </del>  This section covers topics that are explicitly out of scope for the time being. <del> 6.1. </del>  From Section 8.2 of RFC9000:

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

Revised text:
TODO: More details are required here  <ins> 7. </ins> This section covers topics that are explicitly out of scope for the time being.  <ins> 7.1. </ins> From Section 8.2 of RFC9000:
Original text:
NAT traversal, a QUIC protocol extention would be required to support those use cases today. <del> 6.2. </del>  The creation of new media transport protocols should be avoided, and instead we should make use of RTP RFC3550 and the existing ecosystem

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

Revised text:
NAT traversal, a QUIC protocol extention would be required to support those use cases today.  <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
Original text:
in which case we should work with the relevant working groups and present our use-cases. <del> 6.3. </del>  Even if multicast and other network broadcasting capabilities are often used in delivering media in our use cases, QUIC doesn't yet

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

Revised text:
in which case we should work with the relevant working groups and present our use-cases.  <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