jiebi/CodeConvo huggingface dataset:
Code change:
3.1. The protocol defined in this document is identified using the string <del> "HTTP/2.0".  This identification is used in the HTTP/1.1 Upgrade header field, in the TLSALPN field, and other places where protocol </del> <ins> "h2".  This identification is used in the HTTP/1.1 Upgrade header field, in the TLSALPN field, and other places where protocol </ins> identification is required. <del> Negotiating "HTTP/2.0" implies the use of the transport, security, framing and message semantics described in this document. </del> <ins> Negotiating "h2" implies the use of the transport, security, framing and message semantics described in this document. </ins> Only implementations of the final, published RFC can identify <del> themselves as "HTTP/2.0".  Until such an RFC exists, implementations MUST NOT identify themselves using "HTTP/2.0". </del> <ins> themselves as "h2".  Until such an RFC exists, implementations MUST NOT identify themselves using "h2". </ins> <del> Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of editorial convenience only.  Implementations of draft versions MUST NOT identify using this string.  The exception to this rule is the string included in the connection header sent by clients immediately after establishing an HTTP/2.0 connection (see ConnectionHeader); this fixed length sequence of octets does not change. </del> <ins> Examples and text throughout the rest of this document use "h2" as a matter of editorial convenience only.  Implementations of draft versions MUST NOT identify using this string. </ins> Implementations of draft versions of the protocol MUST add the string <del> "-draft-" and the corresponding draft number to the identifier before the separator ('/').  For example, draft-ietf-httpbis-http2-03 is identified using the string "HTTP-draft-03/2.0". </del> <ins> "-" and the corresponding draft number to the identifier.  For example, draft-ietf-httpbis-http2-09 is identified using the string "h2-09". </ins> Non-compatible experiments that are based on these draft versions <del> MUST instead replace the string "draft" with a different identifier. </del> <ins> MUST append the string "-" and a experiment name to the identifier. </ins> For example, an experimental implementation of packet mood-based <del> encoding based on draft-ietf-httpbis-http2-07 might identify itself as "HTTP-emo-07/2.0".  Note that any label MUST conform to the "token" syntax defined in HTTP-p1.  Experimenters are encouraged to </del> <ins> encoding based on draft-ietf-httpbis-http2-09 might identify itself as "h2-09-emo".  Note that any label MUST conform to the "token" syntax defined in HTTP-p1.  Experimenters are encouraged to </ins> coordinate their experiments on the ietf-http-wg@w3.org mailing list. 3.2.

Related discussion:
text: TLS Client Hello's between 256 and 512 bytes need to be rounded up to 512 for compatibility reasons. This incents us to keep Client Hello parameters as small as possible to avoid the rounding - this change shortens the ALPN token of HTTP/2.0 to be simply "h2"
Discussed in Zurich; we will take this and hold back the eventual heat death of the universe a byte at a time.
Code change:
HTTP/2.0 <del> 0x48 0x54 0x54 0x50 0x2f 0x32 0x2e 0x30 ("HTTP/2.0") </del> <ins> 0x68 0x32 ("h2") </ins> This document (RFCXXXX)

Related discussion:
text: TLS Client Hello's between 256 and 512 bytes need to be rounded up to 512 for compatibility reasons. This incents us to keep Client Hello parameters as small as possible to avoid the rounding - this change shortens the ALPN token of HTTP/2.0 to be simply "h2"
Discussed in Zurich; we will take this and hold back the eventual heat death of the universe a byte at a time.
Code change:
over time, it is possible that a client might have more than one viable connection to an origin open at any time.  When this occurs, clients SHOULD not emit new requests on any connection whose Origin <del> Set is a subset of another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. </del> <ins> Set is a proper subset of another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. </ins> 3.

Related discussion:
text: Fix one typo. Technically, a set is always a subset of itself. Therefore current wording implies that if two connections have identical Origin Sets, then neither should be used for new requests, and both should be closed. Fix this by saying "proper subset" instead of "subset".
Thanks!
Code change:
The allowed values for "bits" are 1, 2, 4 and 8. "lst": REQUIRED.  Byte string (Major Type 2) that contains the <del> Status List as specified in status-list-json. </del> <ins> Status List as specified in status-list. </ins> "aggregation_uri": OPTIONAL.  Text string (Major Type 3) that contains a URI to retrieve the Status List Aggregation for this

Related discussion:
text: Status List claim was referencing Chapter 4.1 instead of Chapter 4, which made it ambiguous whether to base64url-encode or not
Code change:
6.5. <del> The checksum of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof of integrity "at rest" unless the whole (e.g. encoded) content is persisted. </del> <ins> Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. For example, GZIP supports mulitple compression levels.  Such encoding parameters are generally not communicated as representation metadata, for instance different compression levels would all use the same "Content-Encoding: gzip" field.  Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm content coding defined RFC8188. Since it is possible for there to be variation within content coding, the checksum conveyed by the integrity field cannot be used to provide a proof of integrity "at rest" unless the whole (e.g. encoded) content is persisted. </ins> 6.6.

Related discussion:
text: some content-coding are "not deterministic" ;) not only encryption-related ones.
NAME great! I applied them :) Feel free to merge!
merged, thanks
James Manger wrote:
yeah I think RFC 8188 was the target of the section here. NAME can you recall? What can we add to make this section a bit more clear?
That's correct. And the suggestion wrt different compression levels is correct to! This is worth mentioning and maybe highlight that it applies to a specific kind of content codings.
Code change:
Re-negotiation in an existing protocol should be supported to allow changes in what is being sent of received. <del> 4.3. </del> <ins> 4.4. </ins> As multiple streams of media may be available for concurrent sending such as multiple camera views or audio tracks, a means of both

Related discussion:
text: This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.
Code change:
the signature parameters used for the current signature are included in this field. <del> 2.5. </del> <ins> 2.4. </ins> The signature input is a US-ASCII string containing the content that is covered by the signature.  To create the signature input string,

Related discussion:
text: Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?
Code change:
When there is more than one value present for a given directive (e.g., two <del> header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid.  Caches are encouraged to consider responses that have invalid freshness information to be stale. </del> <ins> header field lines or multiple Cache-Control: max-age directives), either the first occurrence should be used, or the response should be considered stale.  If directives conflict (e.g., both max-age and no- cache are present), the most restrictive directive should be honored. Caches are encouraged to consider responses that have invalid freshness information (e.g., a max-age directive with non-integer content) to be stale. </ins> 4.2.2.

Related discussion:
text: : I think that MAY should be prose, and should also list retrying the request as an option.
Code change:
When there is more than one value present for a given directive (e.g., two <del> header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid.  Caches are encouraged to consider responses that have invalid freshness information to be stale. </del> <ins> header field lines or multiple Cache-Control: max-age directives), either the first occurrence should be used, or the response should be considered stale.  If directives conflict (e.g., both max-age and no- cache are present), the most restrictive directive should be honored. Caches are encouraged to consider responses that have invalid freshness information (e.g., a max-age directive with non-integer content) to be stale. </ins> 4.2.2.

Related discussion:
text: says: What about multiple ?
I think the right approach here is to require adherence to the most restrictive directive received, but I want to write some more tests first.
OK, the . In a nutshell: No implementation follows the more conservative when multiple are received, either on the same line or separate lines If the directives occur on the same line, most implementations (except Firefox and Apache) prefer the first occurrence. If the directives occur on separate lines, the behaviour is about the same, except that nginx flips and prefers the second line. OTOH most implementations do honour a stricter directive (e.g., or in the presence of more liberal ones like ; the only exceptions there are nuster (a new implementation) and Fastly (this is a known issue). So it seems like the most interoperable thing to do would be to document that when a directive with an argument (like ) appears, the first occurrence should take precedence; however, conflicting directives (like and ) should defer to the strictest.
Code change:
The "id" value is optional. <del> 2.1.5. </del> <ins> 2.1.4. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Related discussion:
text: This removes the dictionary-specific ttl and switches to using the dictionary resource freshness as the mechanism for expiring dictionaries.
NAME could you please take a look and see if this looks ok? NAME could you look at the language around the freshness of the resource relative to cache-control and stale-while-revalidate and make sure I expressed it properly (and it is something we're ok with leveraging)?
Why does the dictionary lifetime need to be independent of the cache lifetime? Having an object that is cached with a separate lifetime seems unnecessary. I would have said that clients can cache a dictionary for as long as they want (as always), but no longer than the lifetime stated in the cache-control field. Now, you might say that a server might want a resource to be usable in its own right (i.e., as an ordinary resource) for one duration, with a separate lifetime for its use as a dictionary. I see two reasons that this isn't much of a compelling argument: A server can forget about a dictionary and not provide delta compression at any time, so there is no real need for the dictionary lifetime to be shorter than the cache lifetime. Client caches won't want to retain something for longer than its validity, so I don't see much chance that a resource will be kept past its cache lifetime. Resources like this are likely exclusively used as a dictionary. There isn't much value for those resources having a separate lifetime in that case.
The main reason for a separate lifetime for the dictionaries is to allow for sites to reduce the possible variations that are in the wild and reduce the number of variations of that come in and constrain the number of previous releases that they need to compress artifacts for. Otherwise, a dictionary "miss" will result in a full version of the resource getting added to caches for every possible version of where delta-compressed artifacts aren't available. Caches can probably manage that OK on their own, but by reducing the dictionaries to a known window it both provides a lever of control on the variations and also allows for clients to "hit" on a cached version of the resource when they have an old dictionary.
This has been rattling around in the back of my head for the last month or so and I wanted to get my thoughts down for discussion.
Code change:
The "id" value is optional. <del> 2.1.5. </del> <ins> 2.1.4. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Related discussion:
text: I think it might be possible to use the existing validity of max-age and stale-while-revalidate to achieve the same result but I'm a bit worried about the complexity that would bring to users. There are 2 main scenarios that express the tension: Versioned immutable resources that change the URL when the content changes. Well-known URLs that are cacheable but update the content in-place (libraries for analytics, ads, embeds, etc). For the purposes of this example, lets assume that the resources are updated twice a day and that 80% of repeat traffic re-visits within 10 days of their previous visit. Assuming a serving architecture with a server-side cache (CDN, load balancer, etc): In both cases, the response is cacheable and keyed based on the dictionary that the client sends as available (). The main concern is how to tune the requests so that the cache behaves like it does today, minimizing traffic to the origin. The "current" version of the resource will be the only one actively fetched by the application independent of when the user last visited. The current best-practice is to cache them for a long time (1 year) and mark them as immutable. Without dictionaries that means that the cache will effectively only see requests for the current version of the resource and all previous versions can age out of the cache (even if they have a long time-to-live, just by virtue of never being accessed). There will be one request to the origin (or a small number) while the cache gets populated but all future requests will always be served from the edge cache. With dictionaries, the cache key depends on when the client last visited the page since the dictionary will be the version of the resource they have in their cache. That means 80% of the requests will be covered by 21 cache keys (one without a dictionary and 20 delta-compressed variants) but that there will be 700+ variants in the wild if the 1-year resource expiration is reused for the dictionary. The cache could manage access frequency to store just the 21 "hot" variants for the last 10 days but the 20% of visits that are using older dictionaries will result in cache misses that require going back to the origin. If a developer shortens the resource cache lifetime to a shorter time, like 5 days, knowing their release schedule then the problem largely goes away.
Code change:
The "id" value is optional. <del> 2.1.5. </del> <ins> 2.1.4. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Related discussion:
text: That would require tying the dictionary use to the expiration of the resource and not allow for it to be used even if it is still in cache (but expired). That would mean we are now imposing a short cache lifetime on an immutable resource in order to optimize the hit rate of the middle caches. It feels like explicitly managing the dictionary lifetime at the same place where the dictionary details are specified might be cleaner. For well-known URLs that are not immutable and change the content in-place, we want to be able to use the previous version(s) of a resource as a dictionary for the "current" version. To be able to do that we need the dictionary to be viable beyond the expiration time of the resource. Since we need to hard-clip the use of the dictionaries to prevent cache key issues we'd need to have the dictionaries use something like the time window to allow for a revalidation request of an expired resource while still using the dictionary but allowing for a hard-clip of the dictionary validity at the end of the stale-while-revalidate time. It's theoretically possible but it feels like we're tying the dictionary TTL into the cache heuristics in ways that might not be intended and might also be easy to get wrong.
"well-known" is a term of art you might want to avoid here. I get your intent. It looks like there is a fairly good suggestion for . It might take a bit of time for a cache to be able to work out the length of time from the last access that represents a good time horizon for use. But that seems manageable. The resources that churn is an interesting one. It seems like you are assuming that the cache lifetime is short, such that a replacement version is requested AFTER the cache lifetime expires. Your option does seem like a possible way of managing this, but I'd be unsure whether stale resources are good for use. You'd have to specify that behavior (reasonable, but it would need to be specified). It might be that a longer cache lifetime also works well enough. Clients do tend to re-check earlier than expiration in many cases, which would ensure that the resource is fresh in use, while making the overlap work well.
NAME NAME does using the resource max-age + stale-while-revalidate as and expiration for the client-side dictionary work ok for you (with a recommendation that immutable resources specify expirations based on their typical release cycle)?
Code change:
The "id" value is optional. <del> 2.1.5. </del> <ins> 2.1.4. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Related discussion:
text: I think that having an explicit life time for the dictionary is a little bit more flexible than relying on cache-control headers, but I think that by itself should outlive most dictionary uses I can think of, especially given that the CDN is unlikely to keep those resources in its own cache beyond that period as well.
NAME I'm not sure I understand (or we're not talking about the same part of the issue). The main concern for caches is how long clients consider a dictionary valid for which will dictate how long of a window a given resource will see request headers from. e.g. for a dictionary with a max-age of 1 year, clients will advertise that dictionary as being available for up to a year. If there are 1,000 updates to the resource used as a dictionary (not impossible for a js app that has 3 releases per day) then there will be 1,000 variants of the dictionary in the wild at any given time (with more frequent requests for more recent dictionaries but still some infrequent long-tail requests). To prevent cache misses, it would be beneficial to cap the dictionary validity to a smaller window where most return traffic falls in and have older clients download the full resource from cache rather than missing and going back to the origin. It also caps how many delta-compressed versions need to be created. The discussion point is if that "client valid" time for a dictionary should be its own separate value or if sites should adjust their max-age to be more reasonable instead if they want to limit the variants (capping the validity to the max-age but requiring a shorter max-age rather than blindly setting everything to 1-year).
Worst-case, a separate ttl could be added later if using the resource expiration ends up being a problem blocking adoption.
It seems like there are two different mental models of how caching and cache-misses could work. The difference between them may be contributing to the confusion. The first is that the CDN is keeping "resource A compressed against dictionary X" as a cache item, and if a client makes a request for "resource A compressed against dictionary Z", the CDN needs to go back to origin to retrieve that combination. The second is that the CDN is keeping "resource A" and "resource Z" as cache items, and if a client makes a request for "resource A compressed against dictionary Z", the CDN either has Z locally or not.
Code change:
The "id" value is optional. <del> 2.1.5. </del> <ins> 2.1.4. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.

Related discussion:
text: If not, it will compress resource A in a different way the client supports. (Of course, this doesn't prevent the CDN from having some amount of second-layer caching to avoid recompressing frequent combinations.) Personally, I tend to think the second tends to have better properties -- you don't have an explosion of cache entries or origin requests for the long tail, you simply fall back to a non-dictionary compression scheme. CDNs might choose to count usage as a dictionary as a cache hit for Z, making it stay in cache as long as it continues to be used by clients, but might not choose to fetch Z again if it ages out of the cache. (The interesting quirk from a CDN perspective is that a single resource might have multiple old versions still getting "hits.") The two then probably imply different ways of thinking about lifetimes. In the first case, you could want a separate lifetime on the dictionary to feed into how long the CDN needs to keep around the f(A,Z) item. In the second, the lifetimes of the individual objects likely suffice. (For that matter, if the client is identifying the version of Z it has, then it doesn't really matter whether that object is fresh or not, only whether the server still possesses the indicated version.)
The main use case for this is for something like a web app at build time where they pre-compress the resources at build time for some number of previous releases. At serving time, the CDN doesn't have any special dictionary logic and just honors the headers to vary on and the origin checks for pre-compressed assets using the requested dictionary (in my apps that I was doing this with, I just added the hash to the end of the file name and did a quick file check). On a miss, the origin sends the full resource which ends up in a separate cache key on the CDN. This allows for origins to support dictionary-compressing the content without their CDN or load balancer having to have implemented it.
Right, that's a reasonable workaround for CDNs that don't know about this spec. But wouldn't we rather the CDNs could implement the spec and calculate the delta at the edge? Wouldn't that be the desired end state? Perhaps I'm wrong, or perhaps I've wandered into an architectural question bigger than this issue.