jiebi/CodeConvo huggingface dataset:
Code change:
unless separate compression dictionaries are used for each source of data.  Compression MUST NOT be used if the source of data cannot be reliably determined.  Generic stream compression, such as that <del> provided by TLS MUST NOT be used with HTTP/2 (TLSFeatures). </del> <ins> provided by TLS MUST NOT be used with HTTP/2 (TLSUsage). </ins> Further considerations regarding the compression of header fields are described in COMPRESSION.

Related discussion:
text: The ALPN RFC does not require that a ALPN implementation provide functionality needed to implement 9.2.2, specifically either to a) use protocol selection to influence the cipher selection; or b) be informed of the cipher selected to influence protocol selection.
Ideally, no, the HTTP/2 spec should not be setting TLS details. HTTP/2 should simply require TLS 1.3, or at least a 1.2.1 with the required improvements done in the relevant spec. This, however, requires a level of coordination between working groups that isn't currently available. This section is just a hack to make a TLS 1.2-h2 variant that's the best that's currently attainable. It's a transitional spec until TLS 1.3 is eventually complete some time in the indeterminate future, just as HTTP/2 is likely to be a transitional spec until HTTP/3 gets written. The cleanest route would be to cut out sections 9.2.1 & 9.2.2 and make a new TLS 1.2.1 spec that satisfies those requirements, then separately publish that and require its usage here. (though, you'd have to come up with some way to handle the minor version number; maybe implement TLS 1.2.1 entirely as an extension) It's probably too late in the HTTP/2 development process to do this, unfortunately, though it would be a cleaner spec with less fiddly bits that can break interoperability.
Discuss on-list, please.
Actually, it's about ethics in game journalism.
Consensus to adopt .
Code change:
F3411-22a does not specify the time source, but GNSS is generally assumed, as latitude, longitude and geodetic altitude must be reported and most small UAS use GNSS for positioning and navigation. <del> F3586-22, to satisfy FAA_RID, specifies use of the US Government operated GPS (with its sub-microsecond accuracy but only 1.5 second precision) and tamper protection of the entire UAS RID subsystem. Thus, in messages sourced by the UA, timestamp accuracy and precision each can be assumed to be 1.5 seconds at worst.  GCS often have access to cellular LTE or other time sources better than the foregoing, and such better time sources would be required to support multilateration in harvestbridforutm, but such better time sources cannot be assumed generally for purposes of security analysis. </del> <ins> Note: For example, to satisfy FAA_RID, F3586-22 specifies tamper protection of the entire RID subsystem and use of the US Government operated GPS.  GPS has sub-microsecond accuracy and 1.5 second precision.  In this example, UA-sourced messages can be assumed to have timestamp accuracy and precision of 1.5 seconds at worst. GCS often have access to cellular LTE or other time sources better than the foregoing, and such better time sources would be required to support multilateration in harvestbridforutm, but such better time sources cannot be assumed generally for purposes of security analysis. </ins> 9.

Related discussion:
text: let's publish an I-D with this PR and the one about Personal Data, then I am approving the I-D for publication
Code change:
12.5.5. The "Vary" header field in a response describes what parts of a <del> request message, aside from the method and target URI, might influence the origin server's process for selecting and representing </del> <ins> request message, aside from the method and target URI, might have influenced the origin server's process for selecting the content of </ins> this response. <del> A Vary field value is a list of request field names, known as the selecting header fields, that might have a role in selecting the representation for this response.  Potential selecting header fields are not limited to those defined by this specification. </del> <ins> A Vary field value is either the wildcard member "*" or a list of request field names, known as the selecting header fields, that might have had a role in selecting the representation for this response. Potential selecting header fields are not limited to fields defined by this specification. </ins> <del> If the list contains "*", it signals that other aspects of the request might play a role in selecting the response representation, possibly including elements outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate "*" in a Vary field value. </del> <ins> A list containing the member "*" signals that other aspects of the request might have played a role in selecting the response representation, possibly including aspects outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate "*" in a Vary field value. </ins> For example, a response that contains

Related discussion:
text: Note that this also rephrases the SHOULD requirement, but doesn't change its effect.
As mentioned in ... >Section 12.5.5
Code change:
We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk, Christian Bormann, Christian Paquin, Dale Bowie, David Bakker, David <del> Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Michael B.  Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Waite, Dick Hardt, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Matthew Miller, Michael Fraser, Michael B. Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard "fnord" Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> Special appreciation is extended to Martin Thomson, who wielded his considerable intellect and influence to change a single occurrence of

Related discussion:
text: From this conversation URL this PR tries to somewhat better explain that explicit typing, per JWT BCP before it, is about distinguishing different types of SD-JWTs. And also be a little more open to other ways of typing, such as cty.
Thanks, looks COMPLETELY REASONABLE to me. inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote: While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Code change:
A sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the Digest-Value applies to. <del> A sequence of octets containing the digest as computed in computing. </del> <ins> A sequence of octets containing the digest as computed in creating and adding. </ins> The CACHE_DIGEST frame defines the following flags:

Related discussion:
text: Resolves URL
cc NAME NAME
Hey Yoav, Thanks; will take a look. Two immediate things: You're getting a error in the markdown; . I see you've added yourself as an author. That's generally the decision of the chair - NAME in this case.
Hopefully fixed. Is there a way to test it locally? Apologies for the noobness. Removed myself.
See URL for build info.
NAME Thank you for working on the proposal. Am I correct in assuming that changes other than the switch to Cuckoo filters and the introduction are unintentional? For example, I see flag of the frame being removed. Do you have a working code that implements Cuckoo filters? I am curious to see it working. The concept of makes sense to me. Maybe we might want to adjust the codepoints and the naming in relation to .
Oh, I now understand the intent of removing the flag. The motive of the proposal is to build a digest without referring to every response object stored in cache. The fact means that it is not be easy for the client to determine the freshness of the entries that is going to be included in the digest. I am sympathetic to the idea, but I am afraid if the approach works well with the current mechanism of HTTP/2 caching. My understanding is that browsers that exist today only consume a pushed response when it fails to find a freshly cached response in its cache. Otherwise, the pushed response never lands in the browser cache. Unless we change the behavior of the browsers to respect the pushed response even if a freshly cached object already exists in its cache, there's a chance that servers would continually push responses that gets ignored by the client (due to the existence of a freshly cached response in the browser cache with the same URL). NAME Assuming that I correctly understand the motive of removing the distinction between a fresh digest and a stale digest, I would appreciate it if you could clarify your ideas on the problem.
Thanks for reviewing, NAME :) My intent was to include all stored resources in the digest, regardless of them being stale or fresh. Entries are added to the digest when a resource is added to the cache and removed from the digest when a resource is removed.
Code change:
A sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the Digest-Value applies to. <del> A sequence of octets containing the digest as computed in computing. </del> <ins> A sequence of octets containing the digest as computed in creating and adding. </ins> The CACHE_DIGEST frame defines the following flags:

Related discussion:
text: The reason is that I think the distinction doesn't make much sense, and maintaining it adds a lot of complexity, basically forcing browsers to recreate the digest for every connection at O(N) cost. Under this premise what servers should do is: Push all the resources that are known not to be in the cache digest Push 304 responses for resources that are in the cache digest, but are likely to be stale (short freshness lifetime, etc) Don't push resources that are in the cache digest and have a long term freshness lifetime or are immutable. Does that make sense? I'm not sure I understand your reference to the push cache vs. the HTTP cache in your comment. In light of my explanation, is there still an issue there in your view?
URL is the reference implementation. Happy to change it. Do you have any specific changes in mind?
NAME Thank you for the explanation. I now understand the intent better. I think that we need to consider two issues regarding the approach. First is the fact that a browser cache may contain more stale responses than fresh resources. Below are the numbers of cached objects found in my Firefox's cache (to be honest the date is from 2016, I haven't been using Firefox in recent weeks and therefore cannot provide up-to-date data). total ---: 2,273 1,003 As you can see, large scale websites tend to have more stale objects than fresh objects. In other words, including information of stale-cached objects increases the size of the digest roughly three times in this case. Since performance-sensitive resources (that we need to push) are likely to be stored fresh (since they are the most likely ones marked as immutable, or near-immutable), transmitting only the digest of freshly-cached responses makes sense. Second is a configuration issue on the server side. One strategy that can be employed by an H2 server (under the current draft) is to receive a digest of freshly cached resources only, compare the digest against the list of resources the browser should preload by only using the URL, and push the missing resources to the client. It is possible for a H2 server to perform the comparison without actually fetching the resource (from origin or from cache) since only the URL would be required for calculating the digest.
Code change:
A sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the Digest-Value applies to. <del> A sequence of octets containing the digest as computed in computing. </del> <ins> A sequence of octets containing the digest as computed in creating and adding. </ins> The CACHE_DIGEST frame defines the following flags:

Related discussion:
text: The proposal prevents such strategy from being deployed since it requires the ETag values to be always taken into consideration (should they be associated to the HTTP responses). In other words, servers would be required to load response headers of the resources to determine if it needs to be pushed, which could be a huge performance degradation on some deployments. Fortunately, servers could avoid the issue by not including ETags for resources that it may push. I think such change on the server-side configuration would be possible, but we need to make sure if we are to take the path (of removing the fresh vs. stale distinction). Let me explain using an example. Consider the following case: client has with and on server-side, the resource has been updated to When receiving a new request from the client, the server cannot determine if the client has URL in its cache. Therefore, would be pushed. The client, when observing (or equivalent tag), tries to load the resource. Since the fresh resource exists within the browser cache, that would be used. The pushed version is ignored and gets discarded (). This would be repeated every time until the cached object either becomes stale or gets removed from the cache. My understanding is that the browser behavior (explained in ) is true for Firefox and also for Chrome. Am I wrong, or missing something? Thank you for the link. I will try to use it. OTOH, do you have some working code that can actually calculate the cache-digest value taking a list of URLs as an input (something like URL)? I ask this because it would give us a better sense in how the actual size of the digest would be. One way to proceed would be to split the discussion of from Cuckoo filters into a separate issue or a PR. I do not have a strong opinion on the naming or the codepoints. What do you think? NAME
NAME Have you considered the approach using Cuckoo filter to generate GCS? I can understand the fact that you do not want to iterate through the browser cache when sending a cache digest. Per-host Cuckoo hash seems like a good solution to the issue. OTOH, as I described in my previous comment, it seems that sending the hash directly has several issues.
Code change:
A sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the Digest-Value applies to. <del> A sequence of octets containing the digest as computed in computing. </del> <ins> A sequence of octets containing the digest as computed in creating and adding. </ins> The CACHE_DIGEST frame defines the following flags:

Related discussion:
text: That is why I am wondering if it would be viable to generate GCS from the per-host Cuckoo filter that would be maintained within the browser. I can see three benefits in the approach, compared to sending the values of Cuckoo filter directly: the size of the digest will be smaller we can keep the distinction between fresh vs. cache. Sending digest of fresh resources only would end up in even smaller digests. Retaining the distinction lowers the bar to deploy cache-digests on the server side. note: you can store the time when the cached object becomes stale in the data associated to the Cuckoo filter entry (assuming that you would have associated data to handle resize, as we discussed in URL). That information can be used when builiding the GCS to determine if a particular object should go into a GCS of fresh resources or that of stale ones less change to the browser push handling (no need to handle pushes of 304 or replace a freshly cached object when an object with the same URL is being pushed) In case of or in the comment above, sending fresh-only digests using GCS would be about 1/3 the size of sending fresh & stale digests using Cuckoo filter. The biggest cost of calculating GCS from Cuckoo hash would be the sort operation. But I think that the cost could be negligible compared to the ECDH operation that we would be doing for every connection, considering the fact that the number of entries that we would need to sort would be small (e.g., up to 1,000 entries of uint32_t), and the fact that sort algorithms faster than O(n log n) radix sort can be deployed (e.g. radix sort). WDYT?
So have a cuckoo filter digest and then put its fingerprints in a GCS? I have not considered that. Need to give it some thought... At the same time, it's not clear to me how that would enable a "stale" vs. "fresh" digests, or handling of improperly cached resources (fresh resources that were replaced on the server).
I would appreciate it if you could consider. To me it seems it's worth giving a thought. Under the approach proposed in this PR, structure that stores the per-host digest would look like below. is required for resizing the filter (e.g., when doubling or halving ).
Code change:
A sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the Digest-Value applies to. <del> A sequence of octets containing the digest as computed in computing. </del> <ins> A sequence of octets containing the digest as computed in creating and adding. </ins> The CACHE_DIGEST frame defines the following flags:

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:
A sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the Digest-Value applies to. <del> A sequence of octets containing the digest as computed in computing. </del> <ins> A sequence of octets containing the digest as computed in creating and adding. </ins> The CACHE_DIGEST frame defines the following flags:

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?