jiebi/CodeConvo huggingface dataset:
Code change:
policy RFC8126 and shall follow the template presented in iana-hsa- template. <ins> Algorithms referenced by algorithm identifiers have to be fully defined with all parameters fixed.  Algorithm identifiers in this registry are to be interpreted as whole string values and not as a combination of parts.  That is to say, it is expected that implementors understand "rsa-pss-sha512" as referring to one specific algorithm with its hash, mask, and salt values set as defined here. Implementors do not parse out the "rsa", "pss", and "sha512" portions of the identifier to determine parameters of the signing algorithm from the string. </ins> 5.1.1.

Related discussion:
text: This text should be more precise about the definition of different signature parameters, including inputs to PSS. All examples have been updated. Examples for ECDSA and HMAC have been added.
Code change:
"third-party" responses or the user agent might not wish to store cookies that exceed some size. <ins> If cookie-name is empty and cookie-value is empty, abort these steps and ignore the cookie entirely. </ins> Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time.

Related discussion:
text: Fixes .
Done
Currently according to the spec, any cookies set with a header should be ignored if their name and value are empty. However, this check is not applied in section 5.4 of the spec, and as a result the CookieStore had a allowed for sites to work around this check. To me, this is a symptom of a bigger issue: 6265bis treats non-HTTP cookies as an afterthought, . I think it's worth opening a separate issue just to track whether we add the empty-name-empty-value check to 5.4 of 6265bis, and if there are other checks on the header in 5.3 that are implied in 5.4 but not made explicit.
CC NAME
As you've noticed, the document currently assumes that 5.4 is only going to be exercised after 5.3. I think this particular issue is distinct from the issue you raise in the other bug, as the only non-HTTP APIs that existed before the async API you're working through used cookie strings, which were parsed just as the header was. Given that new mechanism, it does make sense to move "If both the name string and the value string are empty, ignore the set-cookie-string entirely." from 5.3 to 5.4. Skimming through, I think that's the only restriction that causes cookies to be ignored at the parsing stage.
Minor change so that we won't break "links" if ordering changes, and to explain the change.
Code change:
the content, because a change to the dictionary can result in a change to the decompressed content. <ins> The dictionary is validated using a SHA-256 hash of the content to make sure that the client and server are both using the same dictionary.  The strength of the SHA-256 hash algorithm isn't explicitly needed to counter attacks since the dictionary is being served from the same origin as the content.  That said, if a weakness is discovered in SHA-256 and it is determined that the dictionary negotiation should use a different hash algorithm, the "Use-As- Dictionary" response header can be extended to specify a different algorithm and the server would just ignore any "Available-Dictionary" requests that do not use the updated hash. </ins> 6.2. The CRIME attack shows that it's a bad idea to compress data from

Related discussion:
text: This removes the hashes negotiation and changes the Available-Dictionary request header to explicitly use sha-256 as discussed in URL If sha-256 becomes insufficient, the hash negotiation can then be added (or different mechanisms can be used). This is a rebased version of the (sorry, it got messy so it was cleaner to resubmit a clean one).
Code change:
intermediary can enhance (or interfere) with either direction of the stream. <ins> Intermediaries are expected to forward messages even when protocol elements are not recognized (e.g., new methods, status codes, or field names), since that preserves extensibility for downstream recipients. </ins> An intermediary not acting as a tunnel MUST implement the header field, as specified in field.connection, and exclude fields

Related discussion:
text: I'm disappointed that RFC 6919 doesn't list "ARE EXPECTED TO".
Time for a bis?
In general, an unknown or new method can be handled by a resource by rejecting the request (with 406 for instance). However, some entities (intermediaries in particular) might be forced to engage with methods that are unknown to them. I couldn't find text in or Section 16.1 on this. However, the draft might benefit from advice on this. There are a few things that might be said, with reference to Section 9, which already says much of this: Intermediaries are expected to forward new methods. This enables the deployment of new methods. New methods might be safe, idempotent, or cacheable. Or they might not be. Actions taken need to consider this possibility and act accordingly. For instance, an intermediary that might be able to automatically retry a request cannot do so for an unknown method, which it does not know whether it is idempotent (9.2) or a cache can't cache a response unless the method is known to be cacheable (9.3).
PTAL. I don't think your second bullet is actionable; that's already clear in 16.1, and intermediaries aren't required to do any of those things.
Code change:
Append the result of running Serializing a Key (ser-key) with member's member_name to output. <ins> If member_value is not Boolean true or parameters is not empty: </ins> Append "=" to output. <del> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </ins> <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del> <ins> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> <del> If more members remain in input_dictionary: </del> <ins> If more members remain in input_dictionary: </ins> <del> Append a COMMA to output. </del> <ins> Append a COMMA to output. </ins> <del> Append a single WS to output. </del> <ins> Append a single WS to output. </ins> Return output.

Related discussion:
text: I'm really not sure what happened there, but don't have time to investigate. I suspect GitHub didn't actually merge.
Code change:
permitted to open.  Streams in any of these three states count toward the limit advertised in the <del> setting. </del> <ins> setting.  Streams in either of the "reserved" states do not count as open. </ins> Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that receives a

Related discussion:
text: Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.
Code change:
token issued to an OAuth 2.0 client running inside the workload by the second authorization server. <del> It is important to note that the workload does not use the Service Account Token with resource servers directly but instead obtains access tokens from this second authorization server.  To obtain these access tokens, the OAuth 2.0 client running in the workload uses the JWT client authentication grant, as defined in RFC7523, with the Service Account Token as input.  The obtained access token may be a bearer token, or a proof-of-possession token. fig-arch illustrates the interaction in the architecture graphically. </del> In recommendations we provide more details about how the content of the tokens and the offered security properties.

Related discussion:
text: Taking our last conversation into account I wanted to contribute my take on the problem and wrote the introduction the way I see it. This is not a version that can be merged, but the best way to show it in a diff and allow comments. Let me know what you think.
Code change:
This document <ins> Upon publication, please create the HTTP Priority Parameters registry at https://iana.org/assignments/http-priority [5] and populate it with the types defined in parameters; see register for its associated procedures. </ins> 14.  References 14.1.  URIs

Related discussion:
text: Condensed version of .
Thanks, this looks good to me. It provides a more formal scaffold for the intent that the editors (and design team before them) had in mind for this scheme's extensibility. I do wonder if we might want to name the registry as the slightly more verbose "extensible priority parameters" but since we are not yet establishing a registry it is easy to iterate on that.
Code change:
RFC6454. "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as <del> defined in Section 9.2.1 of HTTPSEM. </del> <ins> defined in Section 9.2.1 of RFC9110. </ins> A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and

Related discussion:
text: Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.
Code change:
RFC6454. "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as <del> defined in Section 9.2.1 of HTTPSEM. </del> <ins> defined in Section 9.2.1 of RFC9110. </ins> A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and

Related discussion:
text: HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!
Code change:
7.3. <ins> This document registers the ALTSVC frame type in the "HTTP/3 Frame Type" registry (Section 11.2.1 of HTTP3). ALTSVC 0xa ALTSVC-frame of this document 7.4. </ins> The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" defines the name space for parameters.  It has been created and will be maintained at <http://www.iana.org/assignments/http-alt-svc- parameters>. <del> 7.3.1. </del> <ins> 7.4.1. </ins> A registration MUST include the following fields:

Related discussion:
text: The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.
Code change:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code) <del> 422 Unprocessable Entity (status code) </del> <ins> 422 Unprocessable Payload (status code) </ins> 426 Upgrade Required (status code) 4xx Client Error (status code class)

Related discussion:
text: See ; the issue is not just about moving the text.
I understand that, I just thought it would be good if we could split this into two changes; that makes it easier later on...
See - I'm on it.
I think I'm ok with the actual changes, but we need a summary for the "Changes from RFC 723" section. Proposal:
NAME I think this is ready to go.
We still need to document this as a normative change from RFC 723.
Done.
LGTM.
As discussed quite a bit, retries in HTTP need to be better defined. In particular, HTTP does not offer a guarantee that any particular request will not be automatically retried.
Messaging - 9.4.1. Retrying Requests contains some things that probably belong in Semantics, probably somewhere up in the architecture section. Beyond that, I think the action here is to clarify a bit more that POST etc. requests are actively retried by many UAs (e.g., most Web browsers) because of H1's connection management issues. NAME can you confirm that that's H1-specific?
generally goaway would determine this in h2
Semantics - 7.2.2 Idempotent Methods talks about retries some. I'm inclined to add a very short reference to it in architecture -- e.g., "Some requests can be retried in the event of failure; see ref" -- around the sentence starting "A client sends an HTTP request..." in 2.1 Client Server Messaging. In h1-messaging, I'd like to add the behaviour that UAs actually implement to the list of examples of how they'd know it's OK to retry. AIUI, that would be something like: NAME is that accurate?
Well, the server could have had an opportunity to process a request, because they routinely start processing based on only a small amount of the header. The fact is that some clients retry based on very weak signals, risking duplicate processing in favour of greater robustness. The retry logic as I understand it is "have I seen any hint of a response? no? retry."
It seems like either clients or the spec should change, then.
Code change:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code) <del> 422 Unprocessable Entity (status code) </del> <ins> 422 Unprocessable Payload (status code) </ins> 426 Upgrade Required (status code) 4xx Client Error (status code class)

Related discussion:
text: I suspect clients will not...
There's two things you might consider here: noting that clients might do some things to retry based on their own determination of when that is appropriate (for example, in the extreme, retrying if the connection breaks before any byte of a response is seen).recommendations about good practice, which probably doesn't want to point at what the most aggressive clients (i.e., browsers) might choose to do Trying to walk the line without making that distinction is probably too hard.
That seems like a good direction, except that the spec currently contains a MUST NOT; "good practice" isn't that strong... MUST NOT (BUT WE KNOW YOU WILL)?
Yep. Part of this work is in aligning the spec with reality. A SHOULD NOT is probably appropriate. No need to resort to RFC 6919 language.
Proposal:
LGTM. s/; f/. F/
While I'm fine with this, I'm stil having a big problem with retries. Some of our (haproxy) users are pressuring us to implement the so-called "L7 retries" by which if the intermediary faces a problem with the server after the request was delivered, it happily retries it, even for a POST! Not only it's a technical problem (requires all requests to be buffered for the time it takes a server to respond) but it's in total violation of all rules. The problem here is that there's an ongoing trend for doing this and users find it normal since it allows them to hide their constantly crashing servers... And usually they consider that the application deals with replay protection by itself so obviously the infrastructure must retry. Thus my big concern here is to figure till what extent an intermediary could reasonably retry, or how we could have signals between UA and server to indicate if the request is retry-safe.
A protocol extension seems reasonable for that case; I think it could be interesting to clients -- both intermediary and otherwise.
Just leaving a note to remember to go through to make sure we got everything.
I had a bunch of editorial suggestions to make and decided to just make them directly to the pull request to save you the time and annoyance. I hope that is okay, since my changes just reduce the prior diffs.
Code change:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code) <del> 422 Unprocessable Entity (status code) </del> <ins> 422 Unprocessable Payload (status code) </ins> 426 Upgrade Required (status code) 4xx Client Error (status code class)

Related discussion:
text: …se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.
Code change:
instance: A user is known at domain A by "johndoe@a.org" but in domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the <del> updated identifer is reflected in returned authorization grant or </del> <ins> updated identifier is reflected in returned authorization grant or </ins> in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above.

Related discussion:
text: and minor other little fixes to fix issues , , an editor's draft preview of these changes here: URL
says this: However, if the authorization grant is a JWT (which it always should be, but see for details), then defines the grant type of the request to be: The other implication of this is that the only way to distinguish the type of JWT assertion is in the JWT itself, which can be done using the field in the JWT header.
Per is an "identifier [...] for the representation of the issued security token" and I think it's admittedly a bit odd but perfectly reasonable to use the URN of the grant type that the token is intended for as the value conveying the representation that token.
With that said however, I do kinda think that'd it be better to limit to JWT authz grant only (a la ) and not tie the issuedtokentype to the grant type.
My point was more about the grant type of the request as described by RFC7523. access token request as defined in of the OAuth Assertion Framework ] with the following specific parameter values and encodings. So if the request contains a JWT, then the grant type value has to be . Which means according to Section 2.4.3 of this spec the issuedtokentype "SHOULD" be , which is silly. So my proposal is to remove the "and SHOULD be passed into the assertion request" part, so that issuedtokentype can be a value that makes sense, and use as the grant type. As I said in the original comment, the implication is then that the JWT header itself would need to include something that indicates the type of JWT it is, otherwise all token exchange requests look the same.
I might argue that it's not actually silly but I won't b/c it'll be moot as PR addresses this with the removal of the "issuedtokentype parameter in the response indicates the type and SHOULD be passed into the assertion request" URL
issuedtokentype (a required parameter of a token exchange response URL) is missing from the example response at URL
NAME can you prepare a PR with an updated example?
Code change:
instance: A user is known at domain A by "johndoe@a.org" but in domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the <del> updated identifer is reflected in returned authorization grant or </del> <ins> updated identifier is reflected in returned authorization grant or </ins> in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above.

Related discussion:
text: example would be fixed by PR
Feedback from Brian Campbell Conceptually having "flexibility for authorization servers to change format and content" sounds nice but I can't help but wonder if that flexibility is actually useful and if this document wouldn't be better served and more straightforward using just JWT authz grants from 7523 (rather than being abstract about using 7521 and the very brief mention of SAML w/out a 7522 ref).
I agree that limiting the authorization grant format to JWT is useful. In fact you've almost already done that by adding the validation to the processing rules here: URL
As discussed in the meeting with the editors and Aaron, we will make the use of JWT explicit.
PR would limit the authorization grant format to RFC7523 JWT
Code change:
3.8.10.4. After a receiver reads in a frame that marks the end of a stream (for <del> example, a data stream with a FINAL flag set), it MUST cease </del> <ins> example, a data stream with a END_STREAM flag set), it MUST cease </ins> transmission of WINDOW_UPDATE frames for that stream.  A sender is not obligated to maintain the available flow control window for streams that it is no longer sending on.

Related discussion:
text: This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.
Code change:
provides a list of representations for the user agent to choose from, and "request payload" negotiation, where the user agent selects the representation for a future request based upon the server's stated <del> preferences in past responses.  Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" (RFC2295), where content selection is performed by an intermediary. These patterns are not mutually exclusive, and each has trade-offs in </del> <ins> preferences in past responses. Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" (RFC2295), where content selection is performed by an intermediary.  These patterns are not mutually exclusive, and each has trade-offs in </ins> applicability and practicality. Note that, in all cases, HTTP is not aware of the resource semantics.

Related discussion:
text: initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...