jiebi/CodeConvo huggingface dataset:
Code change:
the signature parameters structure.  Initial values for this registry are given in iana-param-contents.  Future assignments and modifications to existing assignments are to be made through the <del> Expert Review registration policy RFC8126 and shall follow the template presented in iana-param-template. </del> <ins> Expert Review registration policy RFC8126. The DE is expected to ensure that the name follows the template presented in iana-param-template, including that the length of the name is not excessive while still being unique and recognizable for its defined function.  The DE is expected to ensure that the defined functionality is clear and does not conflict with other registered parameters.  The DE is expected to ensure that the definition of the metadata parameter includes its behavior when used as part of the normal signature process as well as when used in an Accept-Signature field. </ins> 6.3.1.

Related discussion:
text: Comment by NAME I would suggest being explicit about the meaning of "active" and especially "deprecated": these are terms everywhere in RFCs (I am aware), but sometimes they are open for interpretation, and we keep discussing their meaning. It would be good to avoid that situation from this doc.
Comment by NAME The new registries do not have any guidance for the designated experts as to what registrations should be accepted or denied (conformance with template, point squatting, availability of reference specification, etc). See of RFC8126: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request.
Code change:
The CONTINUATION frame includes optional padding.  Padding fields and flags are identical to those defined for DATA. <ins> 6.11. The ALTSVC frame (type=0xa) advertises the availability of an alternative service to the client.  It can be sent at any time for an existing client-initiated stream or stream 0, and is intended to allow servers to load balance or otherwise segment traffic; see AltSvc for details (in particular, Section 2.4, which outlines client handling of alternative services). An ALTSVC frame on a client-initiated stream indicates that the conveyed alternative service is associated with the origin of that stream. An ALTSVC frame on stream 0 indicates that the conveyed alternative service is associated with the origin contained in the Origin field of the frame.  An association with an origin that the client does not consider authoritative for the current connection MUST be ignored. The ALTSVC frame is intended for receipt by clients; a server that receives an ALTSVC frame MUST treat it as a connection error of type PROTOCOL_ERROR. The ALTSVC frame contains the following fields: PID_LEN: An unsigned, 8-bit integer indicating the length, in bytes, of the PROTOCOL-ID field. Reserved: for future use. Port: An unsigned, 16-bit integer indicating the port that the alternative service is available upon. Max-Age: An unsigned, 32-bit integer indicating the freshness lifetime of the alternative service association, as per AltSvc, Section 2.2. Protocol-ID: A sequence of bytes (length determined by PID_LEN) containing the ALPN protocol identifier of the alternative service. HOST_LEN: An unsigned, 8-bit integer indicating the length, in 8-bit characters, of the Host field. Host: A sequence of characters (length determined by HOST_LEN) containing an ASCII string indicating the host that the alternative service is available upon. Origin: An optional sequence of characters (length determined by ORGN_LEN) containing ASCII serialisation of an origin (RFC6454, Section 6.2) that the alternate service is applicable to. The ALTSVC frame does not define any flags. </ins> 7. Error codes are 32-bit fields that are used in

Related discussion:
text: HTTP/2 has different properties to HTTP/1 regarding server-side load, because load balancers etc. currently exploit HTTP/1's short connections. HTTP/2 has much longer-lived connections, making it more difficult to load balance traffic. A mechanism to direct the client to use a different server/port would mitigate this. While GOAWAY could be used to do this, it introduces latency as the new connection is set up.
Alt-Svc?
URL
NAME is this really in the next milestone? It doesn't seem like we're ready yet.
Should get out a draft momentarily; if we don't make it, that's fine, but if we can, it'd be good to have a bit of discussion first.
NAME this missed the boat. Can I request that you put together something we can discuss in London instead.
Yes, it's on the list for discussion there. The boat technically is delayed at dock...
Discussed in London; agreed to using ALTSVC frame for this.
Code change:
designed congestion control algorithms have the opportunity to improve the state of the art. <del> 3.1.4. </del> <ins> 3.1.3. </ins> When multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows. <del> 3.1.5. </del> <ins> 3.1.4. A great deal of congestion control analysis concerns the steady-state behavior of long flows.  However, many internet flows are relatively short-lived.  If they never experience a packet loss, they remain in the "slow start" mode of operation RFC5681 that features exponential congestion window growth. </ins> <del> (TODO: Discuss short and long flows) </del> <ins> Proposals will consider how new and short-lived flows affect long- lived flows, and vice versa. </ins> 3.2.

Related discussion:
text: Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.
Code change:
value set to the current resumption offset for the target resource. The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete.  The response <del> MAY include the "Upload-Limit" header field if corresponding limits on the upload resource exist. </del> <ins> MUST include the "Upload-Length" header field set to the upload's final size if one was recorded during the upload creation (upload- creation).  The response MAY include the "Upload-Limit" header field if corresponding limits on the upload resource exist. </ins> An upload is considered complete only if the server completely and successfully received a corresponding creation request (upload-

Related discussion:
text: Closes URL A client can express its interest in digests using during upload creation. The server can then respond with after POST and PATCH requests to share its digest with the client. The client computes its digest as well during the upload and compares the digest to spot issues. The representation digest of an upload resource covers the entire bytes that have been uploaded so far (i.e. right until the upload offset). NAME NAME Is this in line with the semantics of RFC 9530?
NAME Need a week for the review :)
Preliminary feedback: I'd simplify the language/split text on multiple lines; Describe processing in separate subsections, e.g.
Thank you for the feedback, Roberto. I added subsections for representation and content digests in URL I think this division helps the reader and also makes sense since representation digests can cover the entire upload, while content digests only cover one request. Let me know if you think differently.
URL added some guidelines on how a client may include integrity fields to upload requests for protecting the integrity of a single request or the entire upload. However, this either requires the client to compute the digest upfront (before sending a request or starting the upload), or the use of request trailers, which is not very widespread and not always possible (e.g. the ). Instead of requiring the client to compute the digest upfront, the server and client could calculate the digests while the upload is ongoing. Once the upload is completed, the server can send its digest to the client in the response to the request that completed the upload. The client can then compare the server's digest to its computed value. If they don't match, it can raise an error to the end user and decide to not continue using the uploaded data. The client should indicate its interest in the server's digest when an upload is created, so the server is not required to compute the digest if the client has no interest. I am wondering if the from can be used for this. Can a client include in the first upload creation request, but the server delivers the digest potentially later in a response for a subsequent request? An upload may be spread across multiple requests.
Should also be supported? For multi request uploads, there's really no use to continue if request 3 of 100 got corrupted.
Code change:
value set to the current resumption offset for the target resource. The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete.  The response <del> MAY include the "Upload-Limit" header field if corresponding limits on the upload resource exist. </del> <ins> MUST include the "Upload-Length" header field set to the upload's final size if one was recorded during the upload creation (upload- creation).  The response MAY include the "Upload-Limit" header field if corresponding limits on the upload resource exist. </ins> An upload is considered complete only if the server completely and successfully received a corresponding creation request (upload-

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)
Code change:
8.4.3. The "Accept-Charset" header field can be sent by a user agent to <del> indicate what charsets are acceptable in textual response content. This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets. </del> <ins> indicate its preferences for charsets in textual response content. For example, this field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets. </ins> Charset names are defined in charset.  A user agent MAY associate a quality value with each charset to indicate the user's relative

Related discussion:
text: (alternative approach)
AcceptAccept-CharsetAccept-Encoding`](URL) request headers is of very limited use, because: With a qvalue higher than another value, it says "send anything in preference to something specific", which isn't useful With a qvalue lower than another media type, it says "send a more specific value in preference to something else", which is already implied by HTTP With a qvalue of 0, it says "don't ever send other value" -- but a server can always ignore that, because this is an optional-to-implement extension In media types (e.g., ), it has been cargo culted a lot, but doesn't actually give the server information it can use. Can we deprecate in these headers, or at least restrict its use / give better guidance?
Discussed in Montreal; support for documenting limitations / caveats.
We can't deprecate it. We can explain when and where it isn't useful.
+1 to generalize this. However, we may want to still reference these rules from each individual header field definition.I think the first sentence needs some editorial work, but +1 to committing this first.
Code change:
Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription <del> aggregation allows relays to make only a single forward subscription for the track.  The published content received from the forward </del> <ins> aggregation allows relays to make only a single upstream subscription for the track.  The published content received from the upstream </ins> subscription request is cached and shared among the pending subscribers.

Related discussion:
text: Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM
Code change:
Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription <del> aggregation allows relays to make only a single forward subscription for the track.  The published content received from the forward </del> <ins> aggregation allows relays to make only a single upstream subscription for the track.  The published content received from the upstream </ins> subscription request is cached and shared among the pending subscribers.

Related discussion:
text: This is a bit different from HTTP, but having at least one SUBSCRIBE_OK succeed ensures the track exists in some sense, as well as allowing a relay to populate the Group Order field. This is intended as a clarification, but it adds normative language.
LGTM
Code change:
Reference: RFC3174, RFC6234, RFC4648, this document. <del> Status: deprecated </del> <ins> Status: insecure </ins>

Related discussion:
text: Thanks, nice solution.
The latest draft of the Digest Fields RFC [0] deprecates all non-cryptographically secure algorithms (notably, MD5 and CRC32c). Given that the RFC is "not intended to be a general protection against malicious tampering with HTTP messages," I'd like to propose not deprecating at least these two algorithms, or changing "deprecated digest algorithms MUST NOT be used" to "should be used with caution" or similar. CRC32c is a very useful algorithm because it is composable (crc(A+B) == combine(crc(A), crc(B))). See [1] for an explainer and [2] for an implementation of combine() in zlib. MD5 is ubiquitous. AWS S3 and Google Cloud Storage both use it (see [3], which has similar syntax to this RFC except that the crc32c is base64 instead of hex). [0] URL [1] URL [2] URL [3] URL Sorry if this is the wrong forum. I saw some links from the w3c mailing list archive that looked like more discussions were happening here than there.
Hi NAME this is the right place, thanks for opening the issue. Do you have a use case where you'd like to use these algorithms with the Digest or Content-Digest header? They are pretty old and pretty bad at their intended purpose - what caution can we offer? The statement comes from URL, which is really about making it clear that applications do care about protecting messages also need to apply signatures that protect HTTP header or trailer sections. Otherwise, an attacker could just change the header at the same time as changing the representation.
Thanks for the fast reply. My use case is for detecting file corruption in internal HTTP communication, where we trust the network/server/client. Since it's internal, we don't have to obey a standard, but I was hoping to provide the CRC32C and MD5 that we already store to our end users -- provide something instead of nothing. Those algorithms provide an adequate level of error detection by our rough calculation (considering that TCP and other layers also checksum). Intel's implementation of CRC32C [0] runs at >19 GB/s, whereas SHA256 runs at only ~360 MB/s.
Code change:
Reference: RFC3174, RFC6234, RFC4648, this document. <del> Status: deprecated </del> <ins> Status: insecure </ins>

Related discussion:
text: We also take advantage of the ability of CRC32C to be combined, so we can concatenate files in O(1) time and get their CRC32C without calculating a SHA256/512 or MD5 over the whole content. We serve some millions of files. Google Cloud Storage and AWS S3 probably store many trillions of files and provide CRC32C+MD5 and MD5, respectively.1 It would be pretty impactful for servers to be able to pass along these digests and might make it worthwhile for browsers to start verifying digests for downloads (e.g. revive [1]). I might be under-appreciating the security intents of this RFC, but there is clear mention of the other benefits of the RFC (below), which are ones that non-cryptographically secure hashes are often good enough for. [0] URL [1] URL Edit: 1 Clarification: The S3 object is an MD5 in many scenarios, and S3 uses for integrity checks during uploads. They do not explicitly store the MD5 for all objects though.
Corruption in the network does happen, but HTTPS is a far better way of managing that risk. I know that you say that you trust them, but I would be worried about the network/server/client being - or becoming - untrustworthy. Obviously, if you are into high-volume transfers of bulk data, you are going to do what you need to do; specialized applications have specialized constraints. But that doesn't make unsecured transfers any less inadvisable; I'd stand by the deprecation here as a general statement.
Hi NAME Thanks for joining the discussion! Let me clarify one point: This just means that the part protected by Digest (the representation) is only a subset of an HTTP message. For the rest, while I agree on some of your considerations, eg. we had a very long discussion on that URL Maybe, since crc32 & co - while deprecated - are still defined in the digest algorithm table, I think that you wouldn't have particular interoperability issues if you need to use them in a specific environment.
Thanks NAME for the pointers to the earlier discussions. I'd thought I'd searched but somehow missed those.
Code change:
Reference: RFC3174, RFC6234, RFC4648, this document. <del> Status: deprecated </del> <ins> Status: insecure </ins>

Related discussion:
text: I'll yield, although I remain in favor of saying these "SHOULD NOT" instead of "MUST NOT" be used at least because of their ubiquity, performance and the composability of CRCs. One last question: does the Digest header provide better security than, or any additional beyond, what TLS provides? My reading of the RFC is that TLS is the typical primary protection layer (since doesn't protect headers; indeed, itself could be altered) and is primarily useful for finding ~bugs. (PS: I really like the digests, nice idea.)
NAME you've made some good points. Adding accommodation for these algorithms, given the proliferation of e.g. MD5 for this kind of integrity checking could be better than nothing, or hoping that everyone would run a SHA-algo over all of their existing assets. The thorny part is how to square the circle on relaxing the rule and providing clear, meaningful guidance to implementers. The MUSTNOT helps set a clear bar, this means its unambiguous what the spec thinks about the relationship of Digest to secure usage scenarios. Anything else needs careful wording and is hard to get right. The current MUSTNOT is slightly odd in so far as we don't state the ramifications if it is used. Part of that is a product of how Digest has been defined and how apps use it
NAME The actual work on digest was driven by its usage in signing http messages (eg URL and URL ) This is at a different layer wrt TLS. So you can see Digest as a building block for creating non-repudiable HTTP exchanges without altering the payload (since signatures are conveyed via http headers). Hth, R.
Personally -- I think there's something here worth considering. AIUI the primary use case for headers is not adversarial -- it's end-to-end (i.e., through various intermediaries, toolkits, perhaps a data store) integrity. If someone has lots of content they've calculated CRC or MD5 for, it seems reasonable to allow them to use it in ; not only is it more efficient, but it saves them recalculating a value for all of that content (and possibly getting it wrong -- that's effectively "end-to-end over time"). OTOH, there are adversarial use cases for too -- mostly, signing the digest as a proxy for signing the content.
Code change:
Reference: RFC3174, RFC6234, RFC4648, this document. <del> Status: deprecated </del> <ins> Status: insecure </ins>

Related discussion:
text: Here, using CRC or MD5 can be bad, and shouldn't be encouraged (or perhaps allowed) by the spec. This leads me to think that deprecating them isn't the right thing to do; instead, what about marking them as insecure in the registry, and putting language into the spec to explain how to use that? If folks think that's a good idea, I can do a PR.
Thanks for the background NAME . NAME NAME I think that sounds reasonable to state something like "insecure digests {MUST NOT be used|are not suitable} for protection against malicious actors." The final part of this I think would be allowing for the insecure digests.
I like NAME idea of introducing "insecure". It's not trivial how to state that insecure algorithms must not be used in signatures/adversarial use cases. I'm waiting for Mark's proposal :)
Maybe "Checksum Only" to imply a more narrow purpose. "Insecure" is not the opposite of "secure".
LGTMA pragmatic approach.
Code change:
2.1.3. <del> The "ttl" value of the Use-As-Dictionary header is a sf-integer value that provides the time in seconds that the dictionary is valid for (time to live). The "ttl" is independent of the cache lifetime of the resource being used for the dictionary.  If the underlying resource is evicted from cache then it is also removed but this allows for setting an explicit time to live for use as a dictionary independent of the underlying resource in cache.  Expired resources can still be useful as dictionaries while they are in cache and can be used for fetching updates of the expired resource.  It can also be useful to artificially limit the life of a dictionary in cases where the dictionary is updated frequently which can help limit the number of possible incoming dictionary variations. The "ttl" value is optional and defaults to 1209600 (14 days). 2.1.4. </del> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" value is present then it MUST be sent to the server in a "Dictionary-

Related discussion:
text: I'm not 100% sure it's just a workaround and origin-compressing against previous releases at build time may be preferable for some cases. The most extreme case that comes to mind is something like a huge WASM app (like Photoshop) where the files are upwards of 50MB (well, huge relative to the usual web page resources). Presumably the CDN could still do the work to do the compression (maybe as an offline job for future requests) so it doesn't require the origin to do it necessarily but it's a lot more reasonable in the extreme cases. That said, I think we can still get buy without a separate TTL and adding one later if it ends up being useful can be done as an enhancement without breaking the existing case.
I like red patches. Thanks.