jiebi/CodeConvo huggingface dataset:
Code change:
by taking NAME suggestion of MAY and bolts it to an "if you can detect" caveat
Since this is a change of normative requirement, lets solicit for some more WG input before landing
I noticed the same while reading the document and thought that MAY would be more suitable. Or in more precisely, "MUST ignore any change and MAY treat it as a connection error".
I couldn't see this being discussed in an issue so far. This seems unnecessary. While there is no value to changing the value, it creates a special rule for handling of the setting. In particular, endpoints that don't distinguish between SETTINGS-in-preface and other SETTINGS frames might have trouble generating the special handling necessary to police this rule. While I can see the value to an endpoint in terms of being able to defer creating the whole priority tree mess for new connections until they receive the preface, and maybe avoid creating that stuff entirely. But as long as priority signals are advisory, you get most of the value from a strong recommendation to use the preface, noting that making a change later might be too late. No special exceptions would be needed. I'm sure that the editors will disagree with me here. That's OK, but it's worth noting why this special handling is included in the specification. It's not immediately obvious.
Would it be sufficient to make this a "MAY be treated"? That provides a disincentive to change without requiring special processing.

Related discussion:
text: Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first <del> SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </del> <ins> SETTINGS frame.  Receivers that detect a change MAY treat it as a connection error of type PROTOCOL_ERROR. </ins> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any
Code change:
by taking MT's suggestion. This is the right thing to do editorially even if it might make NAME a little sad
It is not necessary to make this claim, or any claim, about the range of values. Such a claim would need to be supported with evidence. I don't think we have such evidence. Internal documentation I have lists about 30 different types of requests that a web browser might make that were put into about 11 different categories; you could make arguments that 30 or 11 is sufficient on that basis. And you might still be wrong. The good thing here is that you don't need to justify the choice of 8 different urgencies. Strike this sentence.

Related discussion:
text: 4.1. The urgency parameter ("u") takes an integer between 0 and 7, in <del> descending order of priority.  This range provides sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. </del> <ins> descending order of priority. </ins> The value is encoded as an sf-integer.  The default value is 3.
Code change:
The change switches the order so that there is a more natural progress from presenting the incremental default of false, to discussing how a server could act on non-incremental requests, then how they might act on incremental requests.
(Emphasis mine.) I think that the goal of this text was to establish an expectation. That is, if a request is marked as incremental, there is no expectation that a server will attempt to send the entirety of a response before starting on other responses. It's a negation of the standard expectation that exists for : responses are transmitted in their entirety where possible. Consider rewording this bit.
Some suggestions, but I think that this is an improvement.Thank you for the PR. LGTM modulo the points below.

Related discussion:
text: The default value of the incremental parameter is false ("0"). <del> A server might distribute the bandwidth of a connection between incremental responses that share the same urgency, hoping that providing those responses in parallel would be more helpful to the client than delivering the responses one by one. </del> <ins> If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses with the same urgency in parallel because the client is not going to process those responses incrementally.  Serving non-incremental responses with the same urgency one by one, in the order in which those requests were generated is considered to be the best strategy. </ins> If a client makes concurrent requests with the incremental parameter <del> set to false, there is no benefit serving responses in parallel because the client is not going to process those responses incrementally.  Serving non-incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </del> <ins> set to true, serving requests with the same urgency in parallel might be beneficial.  Doing this distributes the connection bandwidth, meaning that responses take longer to complete.  Incremental delivery is most useful where multiple partial responses might provide some value to clients ahead of a complete response being available. </ins> The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to
Code change:
We accept that a strong suggestion to use round-robin isn't ideal. And look for other ways to phrase the suggestion of distributing or timeslicing. Fortunately we already had some text in the next paragraph that explained the ways that timing of delivery of incremental resources parts is important to clients and the sorts of things that servers need to consider. So this PR rearranges the text a bit and gives it dust off to make sure it is in line with our understanding now.
This recommendation is too strong. There is still value in allowing requests to complete. This suggests that pieces of all responses be provided concurrently. That leads to more context switching than necessary, or even inefficiencies in transmissions (one byte from each at a time would have excessive overheads). I would instead say:
I agree that "round-robin manner" is poorly defined and could be interpreted as 1 byte of everything. That would be bad. However, the full context of that SHOULD is in relation to the other requirements in that paragraph RECOMMENDing respect with no guidance on what that means seems a bit iffy to me. Your suggestion might get misinterpreted as relaxing the RECOMMEND. Rewriting that paragraph risks kicking the hornets nest of one the most divisive issues we had (URL). I sort of inclined to keep the SHOULD but expand on what we intended to say with "round-robin"
LGTM, some suggestions only.

Related discussion:
text: In order to mitigate this fairness problem, a server could use knowledge about the intermediary as another signal in its prioritization decisions.  For instance, if a server knows the <del> intermediary is coalescing requests, then it could serve the responses in round-robin manner.  This can work if the constrained </del> <ins> intermediary is coalescing requests, then it could avoid serving the responses in their entirety and instead distribute bandwidth (for example, in a round-robin manner).  This can work if the constrained </ins> resource is network capacity between the intermediary and the user agent, as the intermediary buffers responses and forwards the chunks based on the prioritization scheme it implements.
Code change:
Putting the meat of the document in Section 1.2 was a bit odd. Also, the fields descriptions were glommed together.
Weird; didn't happen on local copies.

Related discussion:
text: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <del> 1.2. </del> <ins> 2. </ins> The ORIGIN HTTP/2 frame (RFC7540, Section 4) indicates what origin(s) RFC6454 the sender considers this connection authoritative for (in
Code change:
Putting the meat of the document in Section 1.2 was a bit odd. Also, the fields descriptions were glommed together.
Weird; didn't happen on local copies.

Related discussion:
text: The ORIGIN frame contains the following fields, sets of which may be repeated within the frame to indicate multiple origins: <del> Origin-Len: An unsigned, 16-bit integer indicating the length, in octets, of the Origin field.  Origin: An optional sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is authoritative for. </del> <ins> An unsigned, 16-bit integer indicating the length, in octets, of the Origin field. An optional sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is authoritative for. </ins> The ORIGIN frame does not define any flags.  It can contain one or more Origin-Len/Origin pairs.
Code change:
Putting the meat of the document in Section 1.2 was a bit odd. Also, the fields descriptions were glommed together.
Weird; didn't happen on local copies.

Related discussion:
text: Clients configured to use a proxy MUST ignore any ORIGIN frames received from it. <del> 2. </del> <ins> 3. </ins> Clients that blindly trust the ORIGIN frame's contents will be vulnerable to a large number of attacks; hence the reinforcement that
Code change:
and This is an editorial set of changes to the intro text. The first paragraph in the "motivation for replacement" section is actually broadly applicable motivation for any priority scheme. So we can move that up and highlight that H2 and H3 are multiplexed protocols that have the need of something. This helps us to clarify that mention of HTML document loading is only an example. We also give greater exposition about the actors involved in signalling, highlighting early that servers treat signals as a suggestion and they might follow some of the guidance provided later in the document.
To avoid bitrot, I'm merging.
The introductory material tries to be general, but routinely fails to be, falling back on talking about rendering web pages. If this is the best example, it could be more direct about that. Or, if this is general, it could try to be more careful about limiting its use of "document" and so forth to examples. For example, this lacks sufficient context: And this launches into talking about HTML without saying HTML:
good catch. I do think this is the best example and therefore will take your first suggestion. I'll follow up with a PR.
I have an unpushed branch for this that conflicts with other things, but I believe solves the matter.
says in part: In the first sentence, the endpoint is the one that is applying priority based on signals (or lack thereof) from its peer. In the second, the endpoint is the one providing signals when the peer is the one that acts upon it. This is confusing.
I see what you mean but I don't have a quick fix to hand. Would "one side operates in ignorance of the needs of the other" work?
Possibly. In the first you might say a sender might operate in ignorance of the needs of a receiver; the second might then say that a receive can communicate its view of priority to inform sender behaviour. Not that prioritization is exclusively about prioritization of sending, of course.
the terms in the second sentence were written intentionally fuzzy to accommodate intermediaries in the general statement. IIRC Robin elsewhere suggested just saying client and server but that risks over simplifying or misleading.
I think it might be a good idea to using terms "sender", "receiver", as suggested by NAME
To me, that risks conflating signal sender vs data sender. Someone want to propose a PR?

Related discussion:
text: 2. <del> An important feature of any implementation of a protocol that provides multiplexing is the ability to prioritize the sending of information.  Prioritization is a difficult problem, so it will always be suboptimal, particularly if one endpoint operates in ignorance of the needs of its peer.  Priority signalling allows endpoints to communicate their own view of priority, which can be combined with information the peer has to inform scheduling. </del> RFC 7540 stream priority (see Section 5.3 of RFC7540) is a complex system where clients signal stream dependencies and weights to describe an unbalanced tree.  It suffered from limited deployment and
Code change:
and This is an editorial set of changes to the intro text. The first paragraph in the "motivation for replacement" section is actually broadly applicable motivation for any priority scheme. So we can move that up and highlight that H2 and H3 are multiplexed protocols that have the need of something. This helps us to clarify that mention of HTML document loading is only an example. We also give greater exposition about the actors involved in signalling, highlighting early that servers treat signals as a suggestion and they might follow some of the guidance provided later in the document.
To avoid bitrot, I'm merging.
The introductory material tries to be general, but routinely fails to be, falling back on talking about rendering web pages. If this is the best example, it could be more direct about that. Or, if this is general, it could try to be more careful about limiting its use of "document" and so forth to examples. For example, this lacks sufficient context: And this launches into talking about HTML without saying HTML:
good catch. I do think this is the best example and therefore will take your first suggestion. I'll follow up with a PR.
I have an unpushed branch for this that conflicts with other things, but I believe solves the matter.
says in part: In the first sentence, the endpoint is the one that is applying priority based on signals (or lack thereof) from its peer. In the second, the endpoint is the one providing signals when the peer is the one that acts upon it. This is confusing.
I see what you mean but I don't have a quick fix to hand. Would "one side operates in ignorance of the needs of the other" work?
Possibly. In the first you might say a sender might operate in ignorance of the needs of a receiver; the second might then say that a receive can communicate its view of priority to inform sender behaviour. Not that prioritization is exclusively about prioritization of sending, of course.
the terms in the second sentence were written intentionally fuzzy to accommodate intermediaries in the general statement. IIRC Robin elsewhere suggested just saying client and server but that risks over simplifying or misleading.
I think it might be a good idea to using terms "sender", "receiver", as suggested by NAME
To me, that risks conflating signal sender vs data sender. Someone want to propose a PR?

Related discussion:
text: Many RFC 7540 server implementations do not act on HTTP/2 priority signals.  Some instead favor custom server-driven schemes based on heuristics or other hints, such as resource content type or request <del> generation order.  For example, a server, with knowledge of the </del> <ins> generation order.  For example, a server, with knowledge of an HTML </ins> document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the
Code change:
Editorial change related to . This may not close the issue on its own, so lets resolve that separate.
Simplification; but WFM either way.

Related discussion:
text: Stream ID MUST be within the client-initiated bidirectional stream limit.  If a server receives a PRIORITY_UPDATE (type=0xF0700) with a Stream ID that is beyond the stream limits, this SHOULD be treated as <del> a connection error of type H3_ID_ERROR. </del> <ins> a connection error of type H3_ID_ERROR.  Generating an error is not mandatory because HTTP/3 implementations might have practical barriers to determining the active stream concurrency limit that is applied by the QUIC layer. </ins> The push-stream variant PRIORITY_UPDATE (type=0xF0701) MUST reference a promised push stream.  If a server receives a PRIORITY_UPDATE
Code change:
Editorial change related to . This may not close the issue on its own, so lets resolve that separate.
Simplification; but WFM either way.

Related discussion:
text: dependencies, which avoids these issues. frame describes considerations for server buffering of <del> PRIORITY_UPDATE frames.  HTTP/3 implementations might have practical barriers to determining reasonable stream concurrency limits depending on the information that is available to them from the QUIC transport layer. </del> <ins> PRIORITY_UPDATE frames. </ins> server-scheduling presents examples where servers that prioritize responses in a certain way might be starved of the ability to
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of RFC7540). <del> The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this </del> <ins> The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this </ins> document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are encouraged to use alternative priority signals (for example, header-
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see <del> Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </del> <ins> Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR.  The initial value is 0. </ins> Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: The Priority HTTP header field (header-field) is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific <del> frames (h2-update-frame and h3-update-frame) are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </del> <ins> PRIORITY_UPDATE frames (h2-update-frame and h3-update-frame) are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </ins> In both cases, the set of priority parameters is encoded as a Structured Fields Dictionary (see Section 3.2 of STRUCTURED-FIELDS).
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: 4.2. The incremental parameter ("i") takes an sf-boolean as the value that <del> indicates if an HTTP response can be processed incrementally, i.e. </del> <ins> indicates if an HTTP response can be processed incrementally, i.e., </ins> provide some meaningful output as chunks of the response arrive. The default value of the incremental parameter is false ("0").
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: combine the priority information from client requests and server responses to correct or amend the precedence.  Clients cannot interpret the appearance or omission of a Priority response header as <del> acknowledgement that any prioritization has occurred. </del> <ins> acknowledgement that any prioritization has occurred.  Guidance for how endpoints can act on Priority header values is given in server- scheduling and client-scheduling. </ins> Priority is a Dictionary (Section 3.2 of STRUCTURED-FIELDS):
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: the priority update. The priority update value in ASCII text, encoded using Structured <del> Fields. </del> <ins> Fields.  This is the same representation as the Priority header field value. </ins> When the PRIORITY_UPDATE frame applies to a request stream, clients SHOULD provide a Prioritized Stream ID that refers to a stream in the
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: update. The priority update value in ASCII text, encoded using Structured <del> Fields. </del> <ins> Fields.  This is the same representation as the Priority header field value. </ins> The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST reference a request stream.  If a server receives a PRIORITY_UPDATE
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: because there is no explicit client-signalled initial priority.  A server can apply priority signals provided in an origin response; see the merging guidance given in merging.  In the absence of origin <del> signals, applying default parameter values could be suboptimal.  How ever a server decides to schedule a pushed response, it can signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. </del> <ins> signals, applying default parameter values could be suboptimal.  By whatever means a server decides to schedule a pushed response, it can signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. </ins> 10.1.
Code change:
NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.

Related discussion:
text: Section 6.2.4 of QUIC-RECOVERY, also highlights consideration of application priorities when sending probe packets after Probe Timeout <del> timer expiration.  An QUIC implementation supporting application- </del> <ins> timer expiration.  A QUIC implementation supporting application- </ins> indicated priorities might use the relative priority of streams when choosing probe data. 13. As a general guideline, a server SHOULD NOT use priority information <del> for making schedule decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP </del> <ins> for making scheduling decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP </ins> connection (e.g., HTTP/1.1) might go unused. The remainder of this section discusses scenarios where unfairness is