jiebi/CodeConvo huggingface dataset:
Code change:
Includes changes from , as that hits the same paragraph.
why is c4d3528 included?
Hmm, poor rebase on my part I think. I made , you made the changes there, then I made a branch for this and then rebased on top of . It should go away when merged.

Related discussion:
text: to HTTP/2, but are not redefined in this document. [RFC Editor: please remove this paragraph.]  IANA is requested to <del> update references in these registries to refer to this document.  The registration of the </del> <ins> update references to RFC 7540 in the following registries to refer to this document: Application-Layer Protocol Negotiation (ALPN) Protocol IDs, HTTP/2 Frame Type, HTTP/2 Settings, HTTP/2 Error Code, and HTTP Method Registry.  The registration of the </ins> method needs to be updated to refer to preface; all other section numbers have not changed.
Code change:
Includes changes from , as that hits the same paragraph.
why is c4d3528 included?
Hmm, poor rebase on my part I think. I made , you made the changes there, then I made a branch for this and then rebased on top of . It should go away when merged.

Related discussion:
text: This section marks the <del> header field registered in RFC7540 as obsoleted.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </del> <ins> header field registered by RFC7540 in the Hypertext Transfer Protocol (HTTP) Field Name Registry as obsolete.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </ins> 11.2. This section records the <del> upgrade token registered in RFC7540 as obsolete.  This capability has been removed: see versioning.  The registration is updated as </del> <ins> upgrade token registered by RFC7540 in the Hypertext Transfer Protocol (HTTP) Upgrade Token Registry as obsolete.  This capability has been removed: see versioning.  The registration is updated as </ins> follows:
Code change:
A recent xml2rfc update changed the way that the element was rendered in text. Take advantage of that by adding quotes to strings that really do benefit from additional quoting, such as the "PRI ..." preface string. Most of the changes shown in a recent diff are down to losing quotes on header field names and other protocol elements. These do not need to be quoted for their meaning to be clear and unambiguous. The use of for these items improves the HTML rendering, but the loss of line noise in text renderings is a net win (at least in my opinion).
I agree with your reasoning, this seems like a good change.

Related discussion:
text: All numeric values are in network byte order.  Values are unsigned unless otherwise indicated.  Literal values are provided in decimal or hexadecimal as appropriate.  Hexadecimal literals are prefixed <del> with </del> <ins> with " </ins> <del> to distinguish them from decimal literals. </del> <ins> " to distinguish them from decimal literals. </ins> This specification describes binary formats using the convention described in QUIC.  Note that this format uses network byte order and
Code change:
A recent xml2rfc update changed the way that the element was rendered in text. Take advantage of that by adding quotes to strings that really do benefit from additional quoting, such as the "PRI ..." preface string. Most of the changes shown in a recent diff are down to losing quotes on header field names and other protocol elements. These do not need to be quoted for their meaning to be clear and unambiguous. The use of for these items improves the HTML rendering, but the loss of line noise in text renderings is a net win (at least in my opinion).
I agree with your reasoning, this seems like a good change.

Related discussion:
text: The client connection preface starts with a sequence of 24 octets, which in hex notation is: <del> That is, the connection preface starts with the string </del> <ins> That is, the connection preface starts with the string " </ins> <del> . This sequence MUST be followed by a SETTINGS frame (SETTINGS), </del> <ins> ".  This sequence MUST be followed by a SETTINGS frame (SETTINGS), </ins> which MAY be empty.  The client sends the client connection preface as the first application data octets of a connection.
Code change:
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:

Related discussion:
text: The HEADERS+PRIORITY frame is identical to the HEADERS, preceded by a single reserved bit and a 31-bit priority; see StreamPriority. <del> No type-specific flags are defined. </del> <ins> HEADERS+PRIORITY uses exactly the same flags as the HEADERS frame. See HEADERS for any flags. </ins> HEADERS+PRIORITY frames MUST be associated with a stream.  If a HEADERS+PRIORITY frame is received whose stream identifier field is
Code change:
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:

Related discussion:
text: PushResources contains a thorough description of the use of PUSH_PROMISE frames. <del> The body of a PUSH_PROMISE includes a "Promised-Stream-ID".  This </del> <ins> The payload of a PUSH_PROMISE includes a "Promised-Stream-ID".  This </ins> unsigned 31-bit integer identifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see
Code change:
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:

Related discussion:
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> <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.
Code change:
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:

Related discussion:
text: Any number of HEADERS frames can may be sent on an existing stream at any time. <del> The HEADERS frame does not define any type-specific flags. </del> <ins> Additional type-specific flags for the HEADERS frame are: </ins> <del> The body of a HEADERS frame contains a HeaderBlock. </del> <ins> Bit 2 being set indicates that this frame does not contain the entire payload necessary to interpret the HEADERS data.  The payload in any series of headers frames is only interpretable when HDR_CONTINUES has NOT been set, and then only when concatenated with the payload from the unbroken series of HEADERS frames where HDR_CONTINUES was set.  When this bit is set for a HEADERS frame on a particular stream (A), HEADERS frames MUST NOT be sent on other streams until a HEADERS frame has been sent on the same stream (A) where the HDR_CONTINUES bit is unset. The payload of a HEADERS frame contains a HeaderBlock. </ins> The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the
Code change:
Two paragraphs up we mandate the use of PROTOCOL_ERROR, so this is not necessary. For .

Related discussion:
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> <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
Code change:
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:

Related discussion:
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> <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
Code change:
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 :-)

Related discussion:
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> <ins> https://github.com/fiestajetsam/draft-gruessing-moq-requirements [1]. </ins> 1.
Code change:
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 :-)

Related discussion:
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> <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
Code change:
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 :-)

Related discussion:
text: 4. <del> TODO: Fill this in with detail </del> <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.
Code change:
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 :-)

Related discussion:
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.
Code change:
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 :-)

Related discussion:
text: 8.1.  URIs <del> [1] https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing- moq-requirements </del> <ins> [1] https://github.com/fiestajetsam/draft-gruessing-moq-requirements </ins>
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: Note to Readers Source code and issues for this draft can be found at <del> https://github.com/fiestajetsam/draft-gruessing-moq-requirements [1]. </del> <ins> https://github.com/moq-wg/moq-requirements [1]. </ins> Discussion of this draft should take place on the IETF Media Over QUIC (MoQ) mailing list, at https://www.ietf.org/mailman/listinfo/moq