jiebi/CodeConvo huggingface dataset:
Code change:
overview has normative language around congestion control which may be at odds with our potential requirements. <del> 5.7. </del> <ins> 6.8. </ins> The encapsulation SHOULD have capabilities beyond what QUIC provides to allow hosts to authenticate one another, this should be kept

Related discussion:
text: 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.
Code change:
sufficiently backwards-compatible to be safely processed by any implementation of the same major version. <del> When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version. </del> 5.3. HTTP messages use key/value pairs to convey data about the message,

Related discussion:
text: and only define the versioning there; leave message version requirements in control data. (no content changes)
Code change:
value as defined in RFC9110, which MUST NOT have a list of values or occur multiple times in a request. <ins> example-header in example has an example of the "Client-Cert" header field. </ins> 2.3. In the context of a TLS terminating reverse proxy deployment, the

Related discussion:
text: It might help to refer to the example in section 2.2 and/or 2.3.
Makes sense, can add a couple forward refs.
Code change:
of firmware revisions to verify that the firmware update seen by a single device, is <del> indeed the same as seen by all the devices. </del> <ins> indeed the same as seen by all the devices </ins> reliably discern an update that has been signed by the appropriate and intended signing identity make an informed judgement on all available information about <del> firmware at the install time.  For example, the firmware is still in a good state or otherwise? </del> <ins> firmware at the install time.  (For example, the firmware is still in a good state or otherwise?) </ins> 3.9. Software Integration is a complex activity.  This typically involves <del> getting various software components from multiple suppliers and </del> <ins> getting various software components from multiple suppliers, </ins> producing an integrated package deployed as part of device assembly. For example, car manufacturers source integrated software for their autonomous vehicles from third parties that integrates software components from various sources.  Integration complexity creates a higher risk of security vulnerabilities to the delivered software. <del> Consumer of an integrated software wants: </del> <ins> Consumers of an integrated software wants: </ins> all components presents in a software product listed, and the ability to identify and retrieve them from a secure and tamper-

Related discussion:
text: Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.
Code change:
Within a single list of covered components, each component identifier MUST occur only once.  One component identifier is distinct from <del> another if either the component name or its parameters differ. Multiple component identifiers having the same component name MAY be included if they have parameters that make them distinct.  The order of parameters MUST be preserved when processing a component identifier (such as when parsing during verification), but the order of parameters is not significant when comparing two component identifiers for equality.  That is to say, ""foo";bar;baz" cannot be in the same message as ""foo";baz;bar", since these two component identifiers are equivalent, but a system processing one form is not allowed to transform it into the other form. </del> <ins> another if the component name differs, or if any of the parameters differ for the same component name.  Multiple component identifiers having the same component name MAY be included if they have parameters that make them distinct, such as ""foo";bar" and ""foo";baz".  The order of parameters MUST be preserved when processing a component identifier (such as when parsing during verification), but the order of parameters is not significant when comparing two component identifiers for equality checks.  That is to say, ""foo";bar;baz" cannot be in the same message as ""foo";baz;bar", since these two component identifiers are equivalent, but a system processing one form is not allowed to transform it into the other form. </ins> The component value associated with a component identifier is defined by the identifier itself.  Component values MUST NOT contain newline

Related discussion:
text: A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?
Code change:
2.6. <del> Authorization servers MAY transcribe claims when either producing </del> <ins> Authorization servers MAY transcribe claims when either producing JWT </ins> authorization grants in the token exchange flow or access tokens in the assertion flow.

Related discussion:
text: when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant
Code change:
The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field <del> value as defined in Section 5.5 of RFC9110, which MUST NOT have a list of values or occur multiple times in a request. </del> <ins> value as defined in RFC9110, which MUST NOT have a list of values or occur multiple times in a request. </ins> 2.3.

Related discussion:
text: to
Currently, the references to HTTP semantics and to all HTTP versions are informative. While there are only two references to RFC9110, I find myself skeptical that someone would be able to implement it without knowing HTTP. We might consider making 9110 an normative reference, even if we think the individual pointers into it don't rise to that level.
You could normatively depend on the intermediary definitions in URL
Agreed about making HTTP semantics a normative reference.
Using and alining with 9110's intermediary definitions is likely worthwhile too. However, that's a larger effort that should maybe be considered separately?
I'm not too bothered about just changing labels between informative or normative. Thats easy to do and can be changed easily enough at later date. I think this draft actually does a good job of talking about the specialist case of a TTRP and we should keep that without too much meddling. But if the prose would benefit from shaking out a stronger sense of if implementations have normative requirements (directly or via references), I think this is a good ticket to track that against.
Thanks for the thoughts, Lucas. I'm inclined to not do much meddling.
Code change:
6.10. The CONTINUATION frame (type=0x9) is used to continue a sequence of <del> HeaderBlock.  Any number of CONTINUATION frames can be sent on an existing stream, as long as the preceding frame is on the same stream and is a </del> <ins> HeaderBlock.  Any number of CONTINUATION frames can be sent, as long as the preceding frame is on the same stream and is a </ins> ,

Related discussion:
text: Two issues were raised about the use of the words "existing" and "current" to refer to streams. These were a little squishy, so I tightened the language a little. The text no longer uses either word to refer to streams, instead using stream states to describe where the relevant text applies and favouring "identified" as a fallback.
uses some under specified termonlogy: For example is for a PRIORITY frame which can be sent/received in the any state the same as in the following contexts: Can be translated to the stream's state? For example does it roughly mean ? If so then the usage in the PRIORITY frame section is a bit more confusing because a PRIORITY frame could be the first valid frame sent/received for a stream.
NAME - Thanks for the clarification!
NAME - I do have a question regarding your clarifications to the SETTING frame (specifically the SETTINGSINITIALWINDOWSIZE portion). It seems a bit confusing if a PRIORITY frame has been exchanged on an IDLE stream for the SETTINGSINITIALWINDOWSIZE not to apply to it. Consider the following example: 1) Stream is in the state (no frames exchanged) 2) A PRIORITY frame for stream is received. 3) A SETTINGS frame is received to update SETTINGSINITIALWINDOW_SIZE. ... 4) Stream transitions into the state. Is seems a bit counter intuitive that stream 's window will be the window size prior to step 3. Just imagine there are many more SETTINGS frames exchanged (and other events) before step URL stream 's window will be even more difficult to understand how it got to where it is.
That's a fair point. The current text is: From this, you might infer that a reserved or idle stream isn't affected. Implicit in here is that you don't actually have an active flow control window until streams are in those states. There is no sense in performing any accounting until you are actually sending, right? But then, it's only accounting and that 32-bit number might be allocated and used in some implementations. So, I think that this can be clarified, rather than rely on people only accounting in those states, the text might be better saying: Does that make more sense?
This does make more sense. On a related URL is the rational to prohibit WINDOWUPDATES on the IDLE streams when PRIORITY frames have been exchanged?
Code change:
6.10. The CONTINUATION frame (type=0x9) is used to continue a sequence of <del> HeaderBlock.  Any number of CONTINUATION frames can be sent on an existing stream, as long as the preceding frame is on the same stream and is a </del> <ins> HeaderBlock.  Any number of CONTINUATION frames can be sent, as long as the preceding frame is on the same stream and is a </ins> ,

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:
6.10. The CONTINUATION frame (type=0x9) is used to continue a sequence of <del> HeaderBlock.  Any number of CONTINUATION frames can be sent on an existing stream, as long as the preceding frame is on the same stream and is a </del> <ins> HeaderBlock.  Any number of CONTINUATION frames can be sent, as long as the preceding frame is on the same stream and is a </ins> ,

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:
CACHE_DIGESTs received on a given connection to inform what it pushes to that client; <del> If a given URL has a match in a current CACHE_DIGEST with the STALE flag unset, it need not be pushed, because it is fresh in cache; </del> If a given URL and ETag combination has a match in a current <del> CACHE_DIGEST with the STALE flag set, the client has a stale copy in cache, and a validating response can be pushed; </del> <ins> CACHE_DIGEST, a complete response need not be pushed; The server MAY push a 304 response for that resource, indicating the client that it hasn't changed. </ins> <del> If a given URL has no match in any current CACHE_DIGEST, the client does not have a cached copy, and a complete response can be pushed. </del> <ins> If a given URL and ETag has no match in any current CACHE_DIGEST, the client does not have a cached copy, and a complete response can be pushed. </ins> Servers MAY use all CACHE_DIGESTs received for a given origin as current, as long as they do not have the RESET flag set; a

Related discussion:
text: What I am suggesting that you could change the structure to the following. In addition to the hash value, each entry will contain the moment when the entry becomes stale. The moment can be calculated when the entry is added. For example, if the entry represents a HTTP response with a , can be calculated as . If the entry represents an immutable HTTP response, then should be set to a very large value (e.g.. assuming that underlying type of is ). When building a GCS digest, you would do the following: step 1. prepare an empty list that would contain hashes of fresh responses step 2. prepare an empty list that would contain hashes of stale responses step 3. foreach entry in cuckoofilter: step 3-1. check if the entry is fresh or not, by checking the value of step 3-2. if the entry is fresh, append of the entry to the list of the hashes of fresh responses step 3-3. otherwise, append of the entry to the list of the hashes of stale responses step 4. sort the list of hashes of the fresh responses, encode as GCS, and send step 5. sort the list of hashes of the stale responses, encode as GCS, and send You can skip the operations related to stale objects (i.e. step 2, 3-3, 5) if the server is unwilling to receive stale digests. Whether the approach can be implemented depends on if a client can determine the moment a response becomes stale. I anticipate that it is possible to determine that when you register the entry to Cuckoo filters (which is when you receive the response from the server).
NAME NAME I'm planning to attend the IETF 100 hackathon this weekend in Singapore. (First timer here. ) I'm happy to collaborate on a (URL) implementation of this spec if either of you are around and interested. I'm fairly familiar with the current spec, having implemented it and .
NAME Wonderful! I'll be attending the hackathon on both days (i.e. Saturday and Sunday). I do not think that I would have time to work on Cache Digests, but would love to discuss with you (or help, if you need) about your work on Cache Digests.
Code change:
CACHE_DIGESTs received on a given connection to inform what it pushes to that client; <del> If a given URL has a match in a current CACHE_DIGEST with the STALE flag unset, it need not be pushed, because it is fresh in cache; </del> If a given URL and ETag combination has a match in a current <del> CACHE_DIGEST with the STALE flag set, the client has a stale copy in cache, and a validating response can be pushed; </del> <ins> CACHE_DIGEST, a complete response need not be pushed; The server MAY push a 304 response for that resource, indicating the client that it hasn't changed. </ins> <del> If a given URL has no match in any current CACHE_DIGEST, the client does not have a cached copy, and a complete response can be pushed. </del> <ins> If a given URL and ETag has no match in any current CACHE_DIGEST, the client does not have a cached copy, and a complete response can be pushed. </ins> Servers MAY use all CACHE_DIGESTs received for a given origin as current, as long as they do not have the RESET flag set; a

Related discussion:
text: I've got an incomplete initial reference implementation at URL It doesn't yet include removal and querying (that's what I'll be adding next), but I did run it on a list of ~3250 URL (which I got out of my main profile chrome://cache/) and it seems to be creating reasonable sized digests. One more advantage, the digests seem to be highly compressible when sparse. Results so far: Digest with 1021 entries (so room for ~4K URLs): 5621 in-memory, 5233 gzipped (when filled with 3250 URLs). Digest with 2503 entries (so room for ~10K URLs): 13772 in-memory, 6879 gzipped (same 3250 URLs). Digest with 7919 entries (so room for ~31K URLs): 43560 in-memory, 9984 gzipped (same 3250 URLs). In practice, I think ~1000 entries is most probably enough, but it's good to know we can increase the digest size (to avoid having to recreate it), without significant over-the-wire penalty.
OK, I now have a complete reference implementation and it seems to be working fine. It also exposed an issue with the initial algorithm, forcing table allocation to accommodate a power of 2 number of entries. Latest results for 3250 URLs taken from my cache: One note: the 1021 entries table had 35 collisions, so it seems like it's insufficient for that number of URLs, unless we're willing to absorb extra pushes for ~1% of the resources.
NAME Interesting! It's good to know that we have numbers now. What is the value of P (the false positive ratio) that you used?
P=8 (so 1/256 false positive)
Note that the numbers here may be possible to further optimize. One example is semi-sorting of the buckets which the Cuckoo-Filters paper mentions, and which I have not yet implemented. It adds some runtime complexity, but can reduce the fingerprint size per resource by a full bit, so could have resulted in ~9% smaller digests in this case.
NAME Awesome! Me not being familiar with these data structures (despite reading Wikipedia article ), why does the 1/256 probability (~4/1000) result in 35 collisions?
Code change:
CACHE_DIGESTs received on a given connection to inform what it pushes to that client; <del> If a given URL has a match in a current CACHE_DIGEST with the STALE flag unset, it need not be pushed, because it is fresh in cache; </del> If a given URL and ETag combination has a match in a current <del> CACHE_DIGEST with the STALE flag set, the client has a stale copy in cache, and a validating response can be pushed; </del> <ins> CACHE_DIGEST, a complete response need not be pushed; The server MAY push a 304 response for that resource, indicating the client that it hasn't changed. </ins> <del> If a given URL has no match in any current CACHE_DIGEST, the client does not have a cached copy, and a complete response can be pushed. </del> <ins> If a given URL and ETag has no match in any current CACHE_DIGEST, the client does not have a cached copy, and a complete response can be pushed. </ins> Servers MAY use all CACHE_DIGESTs received for a given origin as current, as long as they do not have the RESET flag set; a

Related discussion:
text: The 35 collisions are on top of the false positive rates, and represents resources that we failed to put into the table to begin with (due to both their buckets being full). That rate of collisions seems high compared to the results in the paper, so I need to dig further to see who's wrong...
The collisions are now fixed. It was an algorithm issue, where the entry to be pushed was always the same one at the end of the bucket. I've change that to be a random fingerprint from the bucket, which significantly improved things. The ref implementation is now collision free almost up to the point where the digest is full.