jiebi/CodeConvo huggingface dataset:
Code change:
The "type" value is optional and defaults to "raw". <del> 2.1.6. </del> <ins> 2.1.5. </ins> <del> 2.1.6.1. </del> <ins> 2.1.5.1. </ins> A response that contained a response header: Would specify matching any document request for a URL with a path <del> prefix of /product/ on the same Origin as the original request, and expiring as a dictionary in 7 days independent of the cache lifetime of the resource. </del> <ins> prefix of /product/ on the same Origin as the original request. </ins> <del> 2.1.6.2. </del> <ins> 2.1.5.2. </ins> A response that contained a response header:

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.
Code change:
Section 6.2.4 of QUIC-RECOVERY, also highlights consideration of application priorities when sending probe packets after Probe Timeout <del> timer expiration.  An QUIC implementation supporting application- </del> <ins> timer expiration.  A QUIC implementation supporting application- </ins> indicated priorities might use the relative priority of streams when choosing probe data. 13. As a general guideline, a server SHOULD NOT use priority information <del> for making schedule decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP </del> <ins> for making scheduling decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP </ins> connection (e.g., HTTP/1.1) might go unused. The remainder of this section discusses scenarios where unfairness is

Related discussion:
text: NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.
Code change:
"status_list" (status list): REQUIRED when the status list mechanism defined in this specification is used.  It has the same definition as the "status_list" claim in referenced-token- <del> jwt but MUST be encoded as a "StatusListInfo" CBOR structure </del> <ins> jose but MUST be encoded as a "StatusListInfo" CBOR structure </ins> with the following fields: "idx": REQUIRED.  Same definition as "idx" claim in <del> referenced-token-jwt. </del> <ins> referenced-token-jose. </ins> "uri": REQUIRED.  Same definition as "uri" claim in <del> referenced-token-jwt. </del> <ins> referenced-token-jose. </ins> Application of additional restrictions and policy are at the discretion of the verifying party.

Related discussion:
text: Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho
Code change:
complete, the server MUST acknowledge it by responding with a successful status code between 200 and 299 (inclusive).  Server is RECOMMENDED to use "201 (Created)" response if not otherwise <del> specified.  The response MUST NOT include the "Upload-Incomplete" header with the value of true. </del> <ins> specified.  The response MUST NOT include the "Upload-Complete" header with the value of false. </ins> If the request completes successfully but the entire upload is not <del> yet complete indicated by the "Upload-Incomplete" header, the server </del> <ins> yet complete indicated by the "Upload-Complete" header, the server </ins> MUST acknowledge it by responding with the "201 (Created)" status <del> code, the "Upload-Incomplete" header set to true. </del> <ins> code, the "Upload-Complete" header set to true. </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status

Related discussion:
text: The client isn't making assumptions about whether the server has received all the data; it's only expressing to the server that from its perspective, the upload data supplied is now whole. For the server, responding acknowledges the client's view of the complete upload and says, "Yes, the upload is complete on my end, too." Same goes for .
At IETF 117, we agreed on using for requests and responses: URL I will open a PR for this and then we can close this issue.
Code change:
values from the Variants header field that identify the representation it occurs within. <del> Each member of the list contains the selected available-value(s), in the same order as the variants listed in the Variants header field. </del> <ins> Each member of the list contains a set of selected available-value(s) that identify this representation, in the same order as the variants listed in the Variants header field. </ins> <del> Therefore, Variant-Key MUST be the same length (in comma-separated members) as Variants, and each member MUST correspond in position to its companion in Variants. </del> <ins> Therefore, each member of Variant-Key MUST be the same length (in semicolon-separated members) as Variants, and each member's available-values MUST correspond in position to their companions in Variants. </ins> For example: This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language. <del> A more complex example involves listing multiple available-values in a list member, to indicate that the response can be used to satisfy requests with any of those values.  For example: </del> <ins> If the response can be used to satisfy more than one request), they can be listed in additional members.  For example: </ins> indicates that this response can be used for requests whose Accept- Encoding algorithm selects "gzip" or "identity", as long as the Accept-Language algorithm selects "fr" - perhaps because there is no gzip-compressed French representation. <del> This highlights an important aspect of Variant-Key; it is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself. </del> <ins> When more than one Variant-Key value is in a response, the first one present MUST indicate the variant-key for the response it occurs within. </ins> 3.1.

Related discussion:
text: For
from the list Maybe we should be talking about a Variant-Key syntax that lets you specify alternative sets of values, e.g.,
Code change:
This section marks the <del> header field registered in RFC7540 as obsoleted. </del> <ins> header field registered in RFC7540 as obsoleted.  The registration is updated to include the details as required by HTTP: </ins> 11.6.

Related discussion:
text: new registry for fields; see
NAME removed upgrade and changed the registration of this header field to: Is that OK? Or would you prefer a complete registration update, as in: Field Name: HTTP2-Settings Status: Standard Ref.: Section 11.5 of RFC 7540 Comments: This field is obsoleted (this document).
That should be fine.
Code change:
directive (defined by RFC8246) instructs caches to forgo revalidation of fresh responses even when requested by the client. <del> Conditional request header fields that are defined by extensions to HTTP might place conditions on all recipients, on the state of the target resource in general, or on a group of resources.  For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field (RFC4918). </del> Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD

Related discussion:
text: without changing section numbering
implies that a precondition failure is a good safe mode. However, a precondition that isn't recognized by a server will not share this property. A server that does not recognize a header as a precondition will ignore it and likely proceed with handling the request even if the precondition expressed should have failed. Indeed, the same is true if a server ignores preconditions, though the specification effectively . is the only text I could find on defining new preconditions. (One thing I really want to avoid is server's applying special heuristics to headers that start with , because that is one of many poor outcomes if this is left.)
There is also the example in the section above that I suppose we could make a new section on precondition extensions, but they aren't a separate category (like If*). For example, my precondition proposal for 1.1 was an all-inclusive Unless that enclosed a logic bag (structured field value). Note that they have always depended on compliance-when-implemented, since I added the first (If-Modified-Since) in early 1994.
Does this need to be in this specification?
I think we're almost in the extension territory (I like the idea of a header field that lists the applicable precondition fields). As far as this specification goes, simply noting that new preconditions won't share properties of the core preconditions, in particular the expectation that it is understood by servers.
One grammatical nit.
Code change:
suboptimal, particularly if one endpoint operates in ignorance of the needs of its peer. <del> HTTP/2 introduced a complex prioritization signaling scheme that used a combination of dependencies and weights, formed into an unbalanced tree.  This scheme has suffered from poor deployment and </del> <ins> HTTP/2 introduced a complex prioritization scheme that uses a combination of stream dependencies and weights to describe an unbalanced tree.  This scheme has suffered from poor deployment and </ins> interoperability. <del> The rich flexibility of client-driven HTTP/2 prioritization tree building is rarely exercised.  Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </del> <ins> Clients build an HTTP/2 prioritization tree through a series of individual stream relationships, which are transferred to the server using HTTP/2 priority signals in either of three forms.  First, a HEADERS frame with the PRIORITY flag set is an explicit signal that includes an Exclusive flag, Stream Dependency field, and Weight field.  Second, a HEADERS frame with no PRIORITY flag is an implicit signal to use the default priority.  Third, the PRIORITY frame, which is always explicit since it always contains an Exclusive flag, Stream Dependency field, and Weight field. The rich flexibility of tree building is rarely exercised. Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </ins> Many HTTP/2 server implementations do not include support for the priority scheme.  Some instead favor custom server-driven schemes

Related discussion:
text: I do not have a strong opinion, though IIRC, some argued that they prefer default value being 0 rather than 1. That's how we ended up with a "deprecate" flag than "preferred" flag.
I agree with all of Kazuho's points. We explored something different in the past (e.g. URL) but ended up with what we have today, and I don't think there has been significant new information that would change my opinion.
NAME PTAL at this PR that addresses your comment about describing the signals URL
That looks good, but I wonder if 2.1 should explicitly reference that for the definition of h2 priority signals.
Code change:
multiple hops or system boundaries.  Even a simple mechanism for end- to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to <del> a HTML parser, video player etc. for parsing. </del> <ins> an HTML parser, video player, etc. for parsing. </ins> Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could

Related discussion:
text: s/ise-case/use case e.g. -> e.g., nit pass
Code change:
A 425 (Too Early) status code indicates that the server is unwilling to risk processing a request that might be replayed. <del> User agents that send a request in early data MUST automatically retry the request when receiving a 425 (Too Early) response status code.  Such retries MUST NOT be sent in early data. </del> <ins> User agents that send a request in early data are expected to retry the request when receiving a 425 (Too Early) response status code.  A user agent MAY do so automatically, but any retries MUST NOT be sent in early data. </ins> In all cases, an intermediary can forward a 425 (Too Early) status code.  Intermediaries MUST forward a 425 (Too Early) status code if

Related discussion:
text: This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.
Code change:
expensive process. In some cases, however, GET might be unwieldy for expressing queries, <del> because of the limited syntax of the URL; in particular, if binary </del> <ins> because of the limited syntax of the URI; in particular, if binary </ins> data forms part of the query terms, it needs to be encoded to conform <del> to URL syntax. </del> <ins> to URI syntax. </ins> While this is not an issue for short queries, it can become one for larger query terms, or ones which need to sustain a high rate of

Related discussion:
text: This change switches from "URL" to "URI" specifically for two contexts: URI schemes URI syntax (It might be good to also add an explanation somewhere in the Introduction; I can make a proposal if needed)
It is a PR, no?
Weird, it didn't show the UX for PRs before, but does now. shrug
See URL
Code change:
6.1.1.3. <del> MAX_CACHE_DURATION (key 0x04): An integer expressing a number of milliseconds.  If present, the relay MUST NOT start forwarding any individual Object received through this subscription after the specified number of milliseconds has elapsed since the beginning of the Object was received.  This means Objects earlier in a multi- object stream will expire earlier than Objects later in the stream. Once Objects have expired, their state becomes unknown, and a relay that handles a subscription that includes those Objects re-requests them. </del> <ins> MAX_CACHE_DURATION (Parameter Type 0x04): An integer expressing a number of milliseconds.  If present, the relay MUST NOT start forwarding any individual Object received through this subscription after the specified number of milliseconds has elapsed since the beginning of the Object was received.  This means Objects earlier in a multi-object stream will expire earlier than Objects later in the stream.  Once Objects have expired, their state becomes unknown, and a relay that handles a subscription that includes those Objects re- requests them. </ins> 6.2.

Related discussion:
text: Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good
Code change:
MUST be used. <del> The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </del> <ins> This claim value is a case-sensitive string with the hash algorithm identifier.  The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </ins> To promote interoperability, implementations MUST support the

Related discussion:
text: should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"
Code change:
MUST be used. <del> The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </del> <ins> This claim value is a case-sensitive string with the hash algorithm identifier.  The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the IANA "Named Information Hash Algorithm" registry IANA.Hash.Algorithms or a value defined in another specification and/or profile of this specification. </ins> To promote interoperability, implementations MUST support the

Related discussion:
text: No good nit goes unaccepted
In Section 4.1.1 Hash Function Claim it's stated that: I've seen this reference and similar phrasing in other recent specifications and it's never indicated whether these values are case-sensitive or not. Perhaps this is fault of RFC 6920 not being explicit on the matter, but being vague here creates interop issues; I've already witnessed one regarding this very claim. Should these values be considered case-sensitive or not?
I guess it doesn't say so explicitly but the intent is absolutely that the values be considered case-sensitive. We can maybe add a brief statement to that effect.
adds one sentence indicating case-sensitivity.
Excellent, thank you!
Just for clarification, are sha-256 and SHA-256 different claim?
yes, sha-256 and SHA-256 are different
Good Thank you :)
assuming my small nit gets accepted
Code change:
6.3.1. To make sure that a dictionary can only impact content from the same <del> origin where the dictionary was served, the URLPattern used for matching a dictionary to requests is guaranteed to be for the same origin that the dictionary is served from. </del> <ins> origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests (match) is guaranteed to be for the same origin that the dictionary is served from. </ins> 6.3.2.

Related discussion:
text: Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.
Code change:
Duplicate Track Alias: The endpoint attempted to use a Track Alias that was already in use. <ins> Too Many Subscribes: The session was closed because the subscriber used a Subscribe ID equal or larger than the current Maximum Subscribe ID. </ins> GOAWAY Timeout: The session was closed because the client took too long to close the session in response to a GOAWAY (message-goaway) message.  See session migration (session-migration).

Related discussion:
text: Some diffs are due to me reflowing text to fit the line limits, so please ignore those. Once we have this and a limit on announce IDs, it seems likely that we'll be able to get rid of 'Role', but for now it can stay.
Thanks NAME . this looks like a good improvement. I have few clarification questions and bit of extra work for you to add some informative text, if my comment seems ok to you.
Unfortunately, that makes it much more difficult for the server to tell abusive clients from valid ones, as we discovered with the recent HTTP/2 rapid reset attacks. In the end we did develop heuristics, but they're imperfect and in the process we broke a bunch of applications in an effort to defend against DDoS attacks. In contrast, QUIC had a system like this and experienced no issues and we didn't need to develop any new heuristics.
Currently, there's no way to limit the number of simultaneous subscriptions. QUIC stream limits cannot effectively be used to limit the number of subscriptions, so I'd suggest MoQ have a limit. The simplest idea would be to have a limit specified as a parameter in the server's SETUP message. As a related question, even with limits, what happens if a client subscribes to a number of streams that it doesn't have the bandwidth to support? ie: 10 4k video streams and they're on a slow link? Possibly the subscriptions could fail with an error code indicating that the server didn't have enough bandwidth to request them and/or serve them to the client?
rofl I just came here to post the same issue. See: URL I think we follow QUIC and have a MAXSUBSCRIBES frame. The initial value can be set in the SETUP message. The subscribe is considered active until the publisher sends or (TODO). I think we're okay with the subscriber/publisher using arbitrary subscription IDs if there's a single control channel. It would be easier if we required incremental subscribe IDs and you couldn't reuse them though.
Also do we need ? That seems like a potential attack vector too, since it involves inserting into a potentially CDN-wide routing table.