jiebi/CodeConvo huggingface dataset:
Code change:
The five authentication parameters are offset in various ways throughout the document. Examples: using the Parameter (Section 3.3) using the v Parameter (Section 3.2) The REQUIRED "p" (proof) parameter (Section 4.3) Additionally, the word "directive" is used instead of parameter in Section 4.4. It might be advisable to align the document on always using one of these, with a possible difference where the parameter is being defined.
Agreed. I'll write a PR that standardizes on parameter and not directive "p" when defining a new parameter when referencing the parameter

Related discussion:
text: 4.1. <del> The REQUIRED "k" (key ID) parameter is a byte sequence that </del> <ins> The REQUIRED "k" (key ID) Parameter is a byte sequence that </ins> identifies which key the client wishes to use to authenticate.  This can, for example, be used to point to an entry in a server-side database of known keys. 4.2. <del> The REQUIRED "a" (public key) parameter is a byte sequence that </del> <ins> The REQUIRED "a" (public key) Parameter is a byte sequence that </ins> specifies the public key used by the server to validate the signature provided by the client.  This avoids key confusion issues (see SEEMS- LEGIT).  The encoding of the public key is described in public-key-
Code change:
The five authentication parameters are offset in various ways throughout the document. Examples: using the Parameter (Section 3.3) using the v Parameter (Section 3.2) The REQUIRED "p" (proof) parameter (Section 4.3) Additionally, the word "directive" is used instead of parameter in Section 4.4. It might be advisable to align the document on always using one of these, with a possible difference where the parameter is being defined.
Agreed. I'll write a PR that standardizes on parameter and not directive "p" when defining a new parameter when referencing the parameter

Related discussion:
text: 4.3. <del> The REQUIRED "p" (proof) parameter is a byte sequence that specifies </del> <ins> The REQUIRED "p" (proof) Parameter is a byte sequence that specifies </ins> the proof that the client provides to attest to possessing the credential that matches its key ID. 4.4. <del> The REQUIRED "s" (signature) parameter is an integer that specifies </del> <ins> The REQUIRED "s" (signature) Parameter is an integer that specifies </ins> the signature scheme used to compute the proof transmitted in the "p" <del> directive.  Its value is an integer between 0 and 65535 inclusive </del> <ins> Parameter.  Its value is an integer between 0 and 65535 inclusive </ins> from the IANA "TLS SignatureScheme" registry maintained at <<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. 4.5. <del> The REQUIRED "v" (verification) parameter is a byte sequence that </del> <ins> The REQUIRED "v" (verification) Parameter is a byte sequence that </ins> specifies the verification that the client provides to attest to possessing the key exporter output (see output for details).  This avoids issues with signature schemes where certain keys can generate
Code change:
In Section 8: Given that the exporter can be produced at any point in the lifetime of a TLS connection and that TLS connections can remain open for a very long time, it's not clear that this guarantees freshness in the same way that a nonce does. It might be clearer to state that it guarantees the authenticator is no older than the beginning of the current TLS connection. (I presume that a server can use GOAWAY to get rid of connections it considers unacceptably old.)

Related discussion:
text: the presence of authentication to observers due to clear-text TLS Client Hello extensions. <ins> Since the freshness described above is provided by a TLS key exporter, it can be as old as the underlying TLS connection.  Servers can require better freshness by forcing clients to create new connections using mechanisms such as the GOAWAY frame (see H3). </ins> The authentication proofs described in this document are not bound to individual HTTP requests; if the key is used for authentication proofs on multiple requests on the same connection, they will all be
Code change:
Summarizes all the major changes from 6265bis, replacing the existing draft-by-draft change log.
While there are still a couple open issues that may/may not change this PR, I'd still appreciate an initial look. Thanks!
NAME This is ready for review, I don't believe the pending PR needs to be added to this changelog
Looks generally reasonable to me. Maybe drop the IANA changes summary (too detailed), and try to lead with the important changes (e.g., drop the errata down to last)?
It'd be nice if there were an appendix summarising the changes. We do this for most updates.
Sorry for being a bit dense but what is URL in comparison to that? :)
What's needed is a summary of changes from 6265, not for draft-by-draft. And that needs to stay in the spec upon publication.
NAME I see, thanks!
Is there a rule of thumb for which changes should be included? "Major" changes? Any normative changes? Something in between? Also, do you know of any existing RFCs that are a good example?
Major changes definitely, and any significant normative changes. See eg URL
Catching up on things after being out sick for a ~week. This change LGTM. I think the level of detail is appropriate, and I didn't see anything in the line-by-line changelog that jumped out at me as being big enough to consider missing.

Related discussion:
text: ua-requirements), the user agent will send a Cookie header field that conforms to the following grammar: <ins> While Section 5.4 of RFC9110 does not define a length limit for header fields it is likely that the web server's implementation does impose a limit; many popular implementations have default limits of 8K.  Servers SHOULD avoid setting a large number of large cookies such that the final cookie-string would exceed their header field limit.  Not doing so could result in requests to the server failing. </ins> Servers MUST be tolerant of multiple cookie headers.  For example, an <del> HTTP/2 RFC9113 or HTTP/3 RFC9114 connection might split a cookie header to improve compression. </del> <ins> HTTP/2 RFC9113 or HTTP/3 RFC9114 client or intermediary might split a cookie header to improve compression.  Servers are free to determine what form this tolerance takes.  For example, the server could process each cookie header individually or the server could concatenate all the cookie headers into one and then process that final, single, header.  The server should be mindful of any header field limits when deciding which approach to take. Note: Since intermediaries can modify cookie headers they should also be mindful of common server header field limits in order to avoid sending servers headers that they cannot process.  For example, concatenating multiple cookie headers into a single header might exceed a server's size limit. </ins> 4.2.2.
Code change:
Summarizes all the major changes from 6265bis, replacing the existing draft-by-draft change log.
While there are still a couple open issues that may/may not change this PR, I'd still appreciate an initial look. Thanks!
NAME This is ready for review, I don't believe the pending PR needs to be added to this changelog
Looks generally reasonable to me. Maybe drop the IANA changes summary (too detailed), and try to lead with the important changes (e.g., drop the errata down to last)?
It'd be nice if there were an appendix summarising the changes. We do this for most updates.
Sorry for being a bit dense but what is URL in comparison to that? :)
What's needed is a summary of changes from 6265, not for draft-by-draft. And that needs to stay in the spec upon publication.
NAME I see, thanks!
Is there a rule of thumb for which changes should be included? "Major" changes? Any normative changes? Something in between? Also, do you know of any existing RFCs that are a good example?
Major changes definitely, and any significant normative changes. See eg URL
Catching up on things after being out sick for a ~week. This change LGTM. I think the level of detail is appropriate, and I didn't see anything in the line-by-line changelog that jumped out at me as being big enough to consider missing.

Related discussion:
text: HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". <ins> Note: Previous versions of this specification required that only one Cookie header field be sent in requests.  This is no longer a requirement.  While this specification requires that a single cookie- string be produced, some user agents may split that string across multiple cookie header fields.  For examples, see Section 8.2.3 of RFC9113 and Section 4.2.1 of RFC9114. </ins> 5.8.2. The user agent MAY implement "non-HTTP" APIs that can be used to
Code change:
Summarizes all the major changes from 6265bis, replacing the existing draft-by-draft change log.
While there are still a couple open issues that may/may not change this PR, I'd still appreciate an initial look. Thanks!
NAME This is ready for review, I don't believe the pending PR needs to be added to this changelog
Looks generally reasonable to me. Maybe drop the IANA changes summary (too detailed), and try to lead with the important changes (e.g., drop the errata down to last)?
It'd be nice if there were an appendix summarising the changes. We do this for most updates.
Sorry for being a bit dense but what is URL in comparison to that? :)
What's needed is a summary of changes from 6265, not for draft-by-draft. And that needs to stay in the spec upon publication.
NAME I see, thanks!
Is there a rule of thumb for which changes should be included? "Major" changes? Any normative changes? Something in between? Also, do you know of any existing RFCs that are a good example?
Major changes definitely, and any significant normative changes. See eg URL
Catching up on things after being out sick for a ~week. This change LGTM. I think the level of detail is appropriate, and I didn't see anything in the line-by-line changelog that jumped out at me as being big enough to consider missing.

Related discussion:
text: requests with "unsafe" HTTP methods (as was the case prior to the introduction of the "SameSite" attribute). <del> For example, a login flow may involve a cross-site top-level "POST" request to an endpoint which expects a cookie with login information. For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method.  On the other hand, "None" enforcement would allow the cookie to be sent with all cross-site requests, which may not be desirable due to the cookie's sensitive contents. </del> <ins> For example, the concluding step of a login flow may involve a cross- site top-level "POST" request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login.  For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method, resulting in an unrecoverable failure of the whole login flow. </ins> The "Lax-allowing-unsafe" enforcement mode described in lax-allowing- unsafe retains some of the protections of "Lax" enforcement (as <del> compared to "None") while still allowing cookies to be sent cross- site with unsafe top-level requests. </del> <ins> compared to "None") while still allowing recently created cookies to be sent cross-site with unsafe top-level requests. </ins> As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe" mode necessarily provides fewer protections against CSRF.
Code change:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Related discussion:
text: Clients can send representation metadata (see HTTP) in the request that starts an upload.  Servers MAY interpret this metadata or MAY ignore it.  The "Content-Type" header field (HTTP) can be used to <del> indicate the media type of the file.  The "Content-Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </del> <ins> indicate the media type of the file.  The content coding of the representation is specified using the "Content-Encoding" header field and is retained throughout the entire upload.  When resuming an interrupted upload, the same content coding is used for appending to the upload, producing a representation of the upload resource with one consistent content coding.  The "Content-Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </ins> 4.1.
Code change:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Related discussion:
text: "Upload-Complete" field value (upload-complete) MUST be set to false. The server SHOULD respect representation metadata received during <del> creation (upload-creation) and ignore any representation metadata received from appending. </del> <ins> creation (upload-creation).  An upload append request continues uploading the same representation as used in the upload creation (upload-creation) and thus uses the same content coding, if one was applied.  For example, if the initial upload creation included the "Content-Encoding: gzip" header field, the upload append request resumes the transfer of the gzipped data without indicating again that the gzip coding is applied. </ins> If the server does not consider the upload associated with the upload resource active, it MUST respond with a "404 (Not Found)" status
Code change:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Related discussion:
text: match the offset provided by the immediate previous offset retrieval (offset-retrieving), or the end offset of the immediate previous incomplete successful transfer, the server MUST respond with a "409 <del> (Conflict)" status code. </del> <ins> (Conflict)" status code.  The server MAY use the problem type PROBLEM of "https://iana.org/assignments/http-problem-types#mismatching- upload-offset" in the response; see mismatching-offset. </ins> The server applies the patch document of the "application/partial- upload" media type by appending the request content to the targeted
Code change:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Related discussion:
text: 10. <ins> 10.1. This section defines the "https://iana.org/assignments/http-problem- types#mismatching-upload-offset" problem type PROBLEM.  A server MAY use this problem type when responding to an upload append request (upload-appending) to indicate that the "Upload-Offset" header field in the request does not match the upload resource's offset. Two problem type extension members are defined: the "expected-offset" and "provided-offset" members.  A response using this problem type SHOULD populate both members, with the value of "expected-offset" taken from the upload resource and the value of "provided-offset" taken from the upload append request. The following example shows an example response, where the resource's offset was 100, but the client attempted to append at offset 200: 10.2. This section defines the "https://iana.org/assignments/http-problem- types#completed-upload" problem type PROBLEM.  A server MAY use this problem type when responding to an upload append request (upload- appending) to indicate that the upload has already been completed and cannot be modified. The following example shows an example response: 11. </ins> The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses,
Code change:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Related discussion:
text: apply the redirection directly in an immediate subsequent upload append (upload-appending). <del> 11. </del> <ins> 12. A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the "Transfer-Encoding" header field (RFC9112), applied, which modify the representation of uploaded data in a message.  For correct interoperability, the client and server must share the same logic when counting bytes for the upload offset.  From the client's perspective, the offset is counted after content coding but before transfer coding is applied.  From the server's perspective, the offset is counted after the content's transfer coding is reversed but before the content coding is reversed. 13. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This
Code change:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Related discussion:
text: an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data. <del> 12. </del> <ins> 14. </ins> The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may
Code change:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Related discussion:
text: allowed to have, and restricting the length of time an upload resource can exist. <del> 13. </del> <ins> 15. </ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":
Code change:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Related discussion:
text: Macintosh file type code(s): N/A Windows Clipboard Name: N/A <ins> IANA is asked to register the following entry in the "HTTP Problem Types" registry: IANA is asked to register the following entry in the "HTTP Problem Types" registry: </ins>
Code change:
This is a follow-up to , which defined a problem type for when the server rejects modification for an completed upload. However, the draft didn't specify that such modifications are not allowed. This PR adds this requirement. The section for offset retrieval already includes a definition for when an upload is complete, so this is not repeated in this PR's changes:

Related discussion:
text: indicated by the "Upload-Offset" field value does not equal the total of begin offset plus the number of bytes uploaded in the request. <ins> If the upload is already complete, the server MUST NOT modify the upload resource and MUST respond with a "400 (Bad Request)" status code.  The server MAY use the problem type PROBLEM of "https://iana.org/assignments/http-problem-types#completed-upload" in the response; see completed-upload. </ins> If the request completes successfully and the entire upload is complete, the server MUST acknowledge it by responding with a 2xx (Successful) status code.  Servers are RECOMMENDED to use a "201
Code change:
The draft says there are 4 upgrade tokens, but a fifth one has since been added: connect-ip. It already has text to avoid this issue so it should be a short section.

Related discussion:
text: unnecessary delay in this case, this text is hereby updated as follows: <ins> 5.5. RFC9484 forbids clients from using optimistic upgrade, avoiding this issue. </ins> 6. There are now several good examples of designs that prevent the
Code change:
This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME

Related discussion:
text: <del> Security Considerations for Optimistic Use of HTTP Upgrade </del> <ins> Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 </ins> draft-ietf-httpbis-optimistic-upgrade-latest Abstract <del> The HTTP/1.1 Upgrade mechanism allows the client to request a change to a new protocol.  This document discusses the security </del> <ins> In HTTP/1.1, the client can request a change to a new protocol on the existing connection.  This document discusses the security </ins> considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues.