jiebi/CodeConvo huggingface dataset:
Code change:
A <del> frame can alter the initial flow control window size for all current streams.  When the value of </del> <ins> frame can alter the initial flow control window size for all streams in the "open" or "half closed (remote)" state.  When the value of </ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and

Related discussion:
text: It seems like if a stream is allowed to be put into the priority tree (via a PRIORITY message) and its window size controllable (via SETTINGS) then why would a WINDOWUPDATE also not be allowed? I look to the following statement and think that accounting may already be required to track the PRIORITY and SETTINGS updates. The WINDOW_UPDATE accounting seems like it is very similar (or may be close to identical depending on the implementation).
We want to strictly limit the amount of state that is maintained for non-open streams. Currently, that is limited to priority. Opening that to more state isn't really necessary. For WINDOWUPDATE, there is only the case where you want to open the flow control window immediately after opening a stream, which currently causes a potential stall on the remote/sender side. As specified, you can create a priority graph that is separate from the other stream state (flow control in particular). If we allowed WINDOWUPDATE in idle (or reserved), then you need to commit more state. We already acknowledge that priority information needs special handling outside of the key stream states, so the risk is both accounted for, and already present. The most important factor though is that priority is expendable. Under DoS, you can drop priority on the floor. You can't do the same for flow control. Therefore, any state commitment needs to be strictly bounded for that.
Right. So for these cases the peer creating the stream will have to wait to expand (or shrink) the window until after the stream has transitioned out of the IDLE state. So state may not be required however if a peer wants to change the window for that stream then state will be necessary to keep and act upon when the state transition occurs. I"m not sure I follow. WINDOW_UPDATE is allowed in reserved according to . Priority is an interesting portion of the spec. It almost seems like you could ignore priority all together and be compliant :)
Hmm, strange how you forget these things. Yes, you can send WINDOWUPDATE in "reserved (remote)". This allows a client to affect the flow control window of the server that has promised a push. This is something that I know Firefox uses so that it can resume stalled pushes when it knows that they are needed. No extra credits over the initial window size are given to pushed streams until they are recognized as necessary.
Code change:
A <del> frame can alter the initial flow control window size for all current streams.  When the value of </del> <ins> frame can alter the initial flow control window size for all streams in the "open" or "half closed (remote)" state.  When the value of </ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and

Related discussion:
text: You can't send WINDOWUPDATE in "reserved (local)". After all, the other side (the client) won't be sending anything on that stream. So none of this really affects processing of the setting :)
I think I agree with you in general (it is not necessary). I agree that minimizing state on IDLE streams seems like more of a driving force, and I also recognize that the peer can wait to send WINDOW_UPDATES until transitioning out of IDLE. I can also imaging a scenario that if an endpoint puts the node into a priority tree, it is possible they have an estimate of what they are going to be sending. It may then follow the theme of "a more flexible expressions of priority" (from ) to also be able to control the window of those streams (at a finer granularity than the SETTINGS frame). Anyways thanks for the discussion and clarification.
Editorial problem, I hope: The spec uses the phrase "current stream" in two places (both related to PRIORITY), but without any definition of what that means: 1) "5.1 Stream States: ... half closed (local) ... PRIORITY frames received in this state are used to reprioritize streams that depend on the current stream." 2) "6.3 Priority ... Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the current stream." I don't have alternate wording proposals because I'm not exactly sure what those sentences are trying to say. Note that I'm only talking about "current stream" in the singular. I see no confusion with the use of "current streams" (plural) in "6.9.2 Initial Flow Control Window Size".
"subject stream" or "identified stream" would work effectively well. I'll take suggestions.
Both sound fine, but "identified stream" is already used often in the spec and "subject stream" is never used.
Excuse me for trolling this issue but I couldn't help but notice how evil the issue number is.
Code change:
as a connection error of type PROTOCOL_ERROR. Until the client receives the SETTINGS frame from the server, the <del> client SHOULD send both the priority signal defined in the HTTP/2 priority scheme and also that of this prioritization scheme.  When the client receives the first SETTINGS frame that contains the </del> <ins> client SHOULD send the signals of the HTTP/2 priority scheme (see motivation) and the signals of this prioritization scheme (see header-field and h2-update-frame).  When the client receives the first SETTINGS frame that contains the </ins> SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending

Related discussion:
text: says: 'deprecated' isn't the right word here; perhaps 'disabled by a peer'? Also, here and a few other places refer to 'the HTTP/2 priority signals' without enumerating them. To be precise, that should be done somewhere. I think that means: The PRIORITY flag in HEADERS and its associated Exclusive flag, Stream Dependency field, and Weight field The PRIORITY frame type
How about instead "once a client learns that the server supports this priority scheme, it SHOULD stop sending HTTP/2 priority signals" After all, this spec can only really have something to say about the stuff it defines and the h2 priority stuff. (Plus what Mark says about being very clear about what "HTTP/2 priority signals" means.
NAME I like the suggestion but that does not work as is. The draft defines two separate concepts: an HTTP/2 SETTINGS flag that allows an endpoint to deprecate the use of H2 priorities, and a different prioritization scheme. While the two are expected to be used together on HTTP/2, they aren't required to. defines the SETTINGSDEPRECATEHTTP2PRIORITIES flag as a way to opt out of using the HTTP/2 priority scheme, in favor of using an alternative such as the scheme defined in this specification_. That said, I tend to wonder what NAME and NAME are suggesting is that the current draft is a bit verbose. At the moment, it uses to define what "deprecation" means, then the term to define how the client acts when the peer "deprecates." Hence . I would appreciate your reviews. Makes sense.
That raises a different issue. The setting is phrased in the negative, where it could be positive. That is, I support priority mechanism X. That works equally well and doesn't have issues in the case that we have to design a third scheme.
Yes, I think I would prefer a model of advertising support for (potentially multiple) schemes and then saying that the client SHOULD NOT send more than one scheme on a given connection.
NAME NAME While I do not oppose strongly, I think there are number of things that we have to consider: Technically, we can create a mechanism that allows the two sides of a hop agree on one prioritization scheme.
Code change:
as a connection error of type PROTOCOL_ERROR. Until the client receives the SETTINGS frame from the server, the <del> client SHOULD send both the priority signal defined in the HTTP/2 priority scheme and also that of this prioritization scheme.  When the client receives the first SETTINGS frame that contains the </del> <ins> client SHOULD send the signals of the HTTP/2 priority scheme (see motivation) and the signals of this prioritization scheme (see header-field and h2-update-frame).  When the client receives the first SETTINGS frame that contains the </ins> SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending

Related discussion:
text: However, that's going to be a bit complicated, because SETTINGS is a frame that is sent by the two endpoints before receiving one from the peer. Therefore, the minimal mechanism would be something like each endpoint sending a list of schemes that it supports, and then both endpoint choose a scheme from a intersection of the two lists using a predefined logic (e.g., client's list of schemes are ordered by its preference, and the most preferred one also supported by the server will be selected). But before designing a negotiation scheme, I think it's worth asking one question: do we want a negotiation scheme for HTTP/3? If the answer is no, I'm not sure if we need something more than a deprecation scheme for HTTP/2, when what we are trying to do is a back port from HTTP/3. Even with HTTP/2, there's isn't a necessity to negotiate the prioritization scheme. IIRC, the two reasons we introduced the deprecation flag (which IMO is an optimization) are: to reduce the burden of setting up the h2 prioritization tree on the server-side to conserve bandwidth All that said, I think my argument is that having deprecation flag is a good way to punt to the future the cost of designing a solution that we might not need. Because the deprecation flag makes h2 and h3 on par. If we find that we need to replace the new prioritization scheme in the future, then we could introduce a negotiation scheme that works for both H2 and H3. Note also that the new prioritization scheme is extensible.
Not needing to fully specify how they're selected right now is certainly a valid point. But the only difference between a deprecation flag and an indication of support is the orientation of the default value. In HTTP/2, the orientation is that the peer might support that feature, but many don't. So there's value in being explicit both directions; the honest choice for default is "don't know." Indicating support for each scheme gives us more leeway in the future, and we can recommend that implementations which don't support the old scheme explicitly disavow it.
Regarding default, I tend to believe that it should be "supportsh2priorities," because clients should continue sending h2 priorities to h2 servers that do not implement the new extension. That leaves us to the discussion of orientation.
Code change:
as a connection error of type PROTOCOL_ERROR. Until the client receives the SETTINGS frame from the server, the <del> client SHOULD send both the priority signal defined in the HTTP/2 priority scheme and also that of this prioritization scheme.  When the client receives the first SETTINGS frame that contains the </del> <ins> client SHOULD send the signals of the HTTP/2 priority scheme (see motivation) and the signals of this prioritization scheme (see header-field and h2-update-frame).  When the client receives the first SETTINGS frame that contains the </ins> SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending

Related discussion:
text: I do not have a strong opinion, though IIRC, some argued that they prefer default value being 0 rather than 1. That's how we ended up with a "deprecate" flag than "preferred" flag.
I agree with all of Kazuho's points. We explored something different in the past (e.g. URL) but ended up with what we have today, and I don't think there has been significant new information that would change my opinion.
NAME PTAL at this PR that addresses your comment about describing the signals URL
That looks good, but I wonder if 2.1 should explicitly reference that for the definition of h2 priority signals.
Code change:
2. <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. 3. </ins> This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations

Related discussion:
text: I suggest that we swap the section 3 and 2 in the sequence of sections so that the readers understand the interpretation of normative text before they read about it. URL
Code change:
. <ins> 8. In some applications or transport protocols, it is desirable to encapsulate an SD-JWT into an outer JWT container.  For example, an implementation may enclose multiple credentials and presentations, independent of their format, in a JWT to enable application-layer encryption during transport. For such use cases, a compact serialized SD-JWT SHOULD be included as a single string value and a JSON serialized SD-JWT SHOULD be included as a JSON object value.  Key Binding MAY be achieved by signing the envelope JWT instead of including a separate Key Binding JWT. The following non-normative example payload shows a compact serialized SD-JWT Presentation enveloped in a JWT.  The SD-JWT is shown as the value of an claim where is the Issuer-signed JWT and is a Disclosure.  The SD-JWT does not contain a Key Binding JWT as the outer container can be signed instead. This next non-normative example payload shows a JSON serialized SD- JWT enveloped in a JWT.  The JSON serialized SD-JWT appears as the value of an claim and the disclosures are included separately as a top-level claim.  Key Binding is achieved by the signature on the enclosing JWT. Other specifications or profiles of this specification may define alternative formats for transporting an SD-JWT that envelope multiple such SD-JWTs into one object and provide Key Binding using means other than the Key Binding JWT. </ins> 9. Security considerations in this section help achieve the following

Related discussion:
text: -Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere -Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs -Swap Enveloping SD-JWTs and JSON Serialization sections Editor's Copy from this PR: URL URL
I think this also addresses
Code change:
required to be unique within the scope of the dictionary they occur within. <ins> Each member of the dictionary can also have associated parameters - an ordered map of key-value pairs where the keys are short, textual strings and the values are items (item).  There can be zero or more parameters on a member, and their keys are required to be unique within that scope. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the members.

Related discussion:
text: Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.
Code change:
field, which indicates the token lifetime.  The "scope" field is omitted from the request and therefore omitted in the response. <del> 8.2. </del> <ins> 9.2. </ins> Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. <del> 8.3. </del> <ins> 9.3. </ins> When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is

Related discussion:
text: Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"
Code change:
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

Related discussion:
text: 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?
Code change:
This document describes a use of HTTP Alternative Services RFC7838 to decouple the URI scheme from the use and configuration of underlying <del> encryption, allowing a "http" URI RFC7230 to be accessed using Transport Layer Security (TLS) RFC5246 opportunistically. </del> <ins> encryption.  It allows HTTP/2 RFC7540 to access a "http" URI RFC7230 using Transport Layer Security (TLS) RFC5246 with Opportunistic Security RFC7435. </ins> <del> Serving "https" URIs requires avoiding Mixed Content W3C.CR-mixed- content-20160802, which is problematic in many deployments.  This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding these issues, while still providing </del> <ins> This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding the problem of serving Mixed Content (describe in W3C.CR-mixed-content-20160802) while still providing </ins> protection against passive attacks. <del> Opportunistic Security RFC7435 does not provide the same guarantees as using TLS with "https" URIs; it is vulnerable to active attacks, and does not change the security context of the connection. </del> <ins> Opportunistic Security does not provide the same guarantees as using TLS with "https" URIs; Opportunistic Security is vulnerable to active attacks, and does not change the security context of the connection. </ins> Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon").

Related discussion:
text: NAME thoughts?
Seems fine, with the edits Mark suggested. I'll merge and make those changes unless Paul gets to it first.
Looks pretty good to me, some tweaks here.