jiebi/CodeConvo huggingface dataset:
Code change:
to know immediately, header fields describe what needs to be known before receiving content, the content (when present) presumably contains what the recipient wants or needs to fulfill the message <del> semantics, and trailer fields provide additional metadata that can be dropped (safely ignored) when not desired. </del> <ins> semantics, and trailer fields provide optional metadata that was unknown prior to sending the content. </ins> Messages are intended to be

Related discussion:
text: I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.
Code change:
to know immediately, header fields describe what needs to be known before receiving content, the content (when present) presumably contains what the recipient wants or needs to fulfill the message <del> semantics, and trailer fields provide additional metadata that can be dropped (safely ignored) when not desired. </del> <ins> semantics, and trailer fields provide optional metadata that was unknown prior to sending the content. </ins> Messages are intended to be

Related discussion:
text: Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.
Code change:
resolvable endpoint.  The roles of the Issuer (of the Referenced Token), the Status Issuer and the Status Provider may be fulfilled by the same entity.  If not further specified, the term Issuer may refer <del> to an entity acting for all three roles. </del> <ins> to an entity acting for all three roles.  This document describes how an Issuer references a Status List Token and how a Relying Party fetches and validates Status Lists. </ins> <del> The following diagram depicts the relationship between the artifacts: </del> <ins> The following diagram depicts the relationship between the involved roles (Relying Party is equivalent to Verifier of SD-JWT.VC): Status Lists may be composed for expressing a range of Status Types. This document defines basic Status Types for the most common use cases as well as an extensibility mechanism for custom Status Types. </ins> <del> The Referenced Token is referenced by the Status List, which described the status of the Referenced Token.  The Status List is embedded and secured within a Status List Token. </del> <ins> Furthermore, the document defines an extension point that enables other specifications to describe additional status mechanisms and creates an IANA registry. </ins> 1.1. <ins> An example for the usage of a Status List is to manage the status of issued access tokens as defined in section 1.4 of RFC6749.  Token Introspection RFC7662 defines another way to determine the status of an issued access token, but it requires the party trying to validate an access tokens status to directly contact the token issuer, whereas the mechanism defined in this specification does not have this limitation. Another possible use case for the Status List is to express the status of verifiable credentials (Referenced Tokens) issued by an Issuer in the Issuer-Holder-Verifier model SD-JWT.VC. 1.2. </ins> Revocation mechanisms are an essential part for most identity ecosystems.  In the past, revocation of X.509 TLS certificates has been proven difficult.  Traditional certificate revocation lists

Related discussion:
text: The spec creates a registry and claim for status mechanisms and 1 specific mechanism, the status list. We should adjust the introduction to reflect those changes.
Code change:
algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  When an incremental <del> digest-algorithms is used, the sender and the receiver can dynamically compute the digest value while streaming the content. </del> <ins> digest-algorithm is used, the sender and the receiver can dynamically compute the digest value while streaming the content. </ins> 4. The "Want-Digest" field indicates the sender's desire to receive a representation digest on messages associated with the request URI and <del> representation metadata. </del> <ins> representation metadata.  It can be used in both requests and responses. </ins> <del> If a digest-algorithm is not accompanied by a "qvalue", it is treated as if its associated "qvalue" were 1.0. </del> <ins> If a digest-algorithm is not accompanied by a "qvalue" (see Section 12.4.2 ofSEMANTICS), it is treated as if its associated "qvalue" were 1.0. </ins> The sender is willing to accept a digest-algorithm if and only if it is listed in a "Want-Digest" field of a message, and its "qvalue" is

Related discussion:
text: [x] 3. It's probably worth mentioning that they're comma-separated in prose. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] 4. A reference to SEMANTICS 12.4.2 is necessary. See
Code change:
The status of "MD5" and "SHA" has been updated to "insecure", and their description has been modified accordingly. <del> The "id-sha-256" and "id-sha-512" algorithms have been added to the registry. </del> 9.5. This section registers the "Want-Digest" field in the "Hypertext

Related discussion:
text: strip out id-* algorithms from this specid- are complex to address in this document they will be better addressed in URL
Fix typo. Thx NAME I'll wait a couple of days to allow further feedback :)
LGTM modulo the comment I made
Code change:
Specification document(s): accept-ch of this document Related information: for Client Hints <del> 7. </del> <ins> 7.  References </ins> <del> 7.1. Issue 168 (make Save-Data extensible) updated ABNF. Issue 163 (CH review feedback) editorial feedback from httpwg list. Issue 153 (NetInfo API citation) added normative reference. 7.2. Issue 200: Moved Key reference to informative. Issue 215: Extended passive fingerprinting and mitigation considerations. Changed document status to experimental. 7.3. Issue 239: Updated reference to CR-css-values-3 Issue 240: Updated reference for Network Information API Issue 241: Consistency in IANA considerations Issue 250: Clarified Accept-CH 7.4. Issue 284: Extended guidance for Accept-CH Issue 308: Editorial cleanup Issue 306: Define Accept-CH-Lifetime 7.5. Issue 361: Removed Downlink Issue 361: Moved Key to appendix, plus other editorial feedback 7.6. Issue 372: Scoped CH opt-in and delivery to secure transports Issue 373: Bind CH opt-in to origin 7.7. Issue 524: Save-Data is now defined by NetInfo spec, dropping PR 775: Removed specific features to be defined in other specifications 7.8. Issue 761: Clarified that the defined headers are response headers. Issue 730: Replaced Key reference with Variants. Issue 700: Replaced ABNF with structured headers. PR 878: Removed Accept-CH-Lifetime based on feedback at IETF 105 7.9. PR 985: Describe the bytesize cost of hints. PR 776: Add Sec- and CH- prefix considerations. PR 1001: Clear CH persistence when cookies are cleared. 7.10. PR 1064: Fix merge issues with "cost of sending hints". 7.11. PR 1072: LC feedback from Julian Reschke. PR 1080: Improve list style. PR 1082: Remove section mentioning Variants. PR 1097: Editorial feedback from mnot. PR 1131: Remove unused references. PR 1132: Remove nested list. 8.  References 8.1.  URIs </del> <ins> 7.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Related discussion:
text: Apparently the removal of one appendix now has moved all remaining appendics into the main section. They need to be moved back.
LGTM! Thanks for catching that :)
Code change:
4.1. <del> For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is computed as: with extra data defined as: 4.2. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is the payload.  This algorithm takes no extra data. 4.3. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is computed as: with extra data defined as: 4.4. For n > 1 inputs, let k be the largest power of two smaller than n. where "d(0)" is the payload.  This algorithm takes no extra data. 4.5. </del> <ins> The "RFC9162_SHA256" tree algorithm uses the Merkle tree definition from RFC9162 with SHA-256 hash algorithm. </ins> For n > 1 inputs, let k be the largest power of two smaller than n.

Related discussion:
text: For exploration purposes, the document had a number of tree algorithms that are not specified in RFCs or similar. This PR removes them again, transferring them to PRs for further evaluation.
I'm good to merge this from a process standpoint I still hope we can document these in some acceptable way for IETF.
Code change:
deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application server.  A common way this information is conveyed in practice today <del> is by using non-standard headers to carry the certificate (in some </del> <ins> is by using non-standard fields to carry the certificate (in some </ins> encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices <del> respectively made (like what header names are used or are </del> <ins> respectively made (like what field names are used or are </ins> configurable, which parts of the certificate are exposed, or how the certificate is encoded).  A well-known predictable approach to this commonly occurring functionality could improve and simplify

Related discussion:
text: This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)
Code change:
Holders SHOULD store SD-JWTs only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for the private Key Binding key.  Decentralized storage of data, e.g., on <del> End-User devices, SHOULD be preferred for End-User credentials over </del> <ins> user devices, SHOULD be preferred for user credentials over </ins> centralized storage.  Expired SD-JWTs SHOULD be deleted as soon as possible. After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT or the respective Disclosures if they contain privacy-sensitive data. It may be sufficient to store the result of the verification and any <del> End-User data that is needed for the application. </del> <ins> user data that is needed for the application. </ins> 10.3. If the SD-JWT is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the <del> End-User's personal data or correlate the information with previous uses of the same SD-JWT. </del> <ins> user's personal data or correlate the information with previous uses of the same SD-JWT. </ins> Usually, transport protocols for issuance and presentation of credentials are designed to protect the confidentiality of 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:
this specification, the same defenses against attacks that might be mounted that use this information should be applied. <del> 7.5. </del> <ins> 7.6. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this

Related discussion:
text: The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.
Code change:
this specification, the same defenses against attacks that might be mounted that use this information should be applied. <del> 7.5. </del> <ins> 7.6. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this

Related discussion:
text: From BC's comments: URL FAPI Message Signing talks about the RS signing resource responses. This specification could be how the RS publishes the public key, as mentioned in 5.6.6.2 URL
I can see why this one was tricky. One more suggestion to approve, then merge.
Code change:
environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP.  Fingerprinting is considered a privacy concern because it enables tracking of a user <del> agent's behavior over time without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </del> <ins> agent's behavior over time (Bujlow) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </ins> There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable

Related discussion:
text: … section;
Hi Roy, Please consider this reference for the privacy considerations section: Bujlow, T., Carela-Español, V., Solé-Pareta, J., & Barlet-Ros, P. (2017). A survey on web tracking: Mechanisms, implications, and defenses. Proceedings of the IEEE, 105(8), 1476–1510. Regards, Rob
URL
NAME has done a lot of work in this area, so he might have another suggestion. The referenced paper does cover a good amount of techniques that target HTTP itself, so I'd say that it's worth citing unless a better option presents itself.
Code change:
In browser terms, that means that both are either same-origin to the context they are being fetched from or that the response is cross- <del> origin and passes the CORS check (https://fetch.spec.whatwg.org/#cors-check). </del> <ins> origin and passes the CORS check as defined in FETCH. </ins> 9.3.3.

Related discussion:
text: This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL
Code change:
Subscribe ID value is a 'Protocol Violation'. Subscribe ID: The new Maximum Subscribe ID for the session.  If a <del> Subscribe ID equal or larger than this is received in any message, including SUBSCRIBE, the publisher MUST close the session with an error of 'Too Many Subscribes'.  More on Subscribe ID in message- subscribe-req. </del> <ins> Subscribe ID message-subscribe-req equal or larger than this is received by the publisher that sent the MAX_SUBSCRIBE_ID, the publisher MUST close the session with an error of 'Too Many Subscribes'. </ins> 6.21.

Related discussion:
text: This is an attempt at clarifying MAXSUBSCRIBEID, feel free to make suggestions.
lgtm
In 6.16 of draft 6, the draft says that "receipt of a MAXSUBSCRIBEID message with an equal or smaller Subscribe ID value is a 'Protocol Violation'." ; however, later the section mentions that "If a Subscribe ID equal or larger than this is received in any message, including SUBSCRIBE, the publisher MUST close the session with an error of 'Too Many Subscribes'." This is can be ambiguous because technically MAXSUBSCRIBEID is any message. Should all sessions be closed if MAXSUBSCRIBEID message contains an invalid Subscribe ID value? Does any message exclude MAXSUBSCRIBEID if an invalid Subscribe ID value is provided? Clarification on this would be helpful. Thank you!
lgtmAgree with Alan's comment. Otherwise LGTM
Code change:
to change, for configurations to differ between instances in clustered servers, or for network conditions to change. <del> 3.5. </del> <ins> 3.4. </ins> In HTTP/2, each endpoint is required to send a connection preface as a final confirmation of the protocol in use and to establish the

Related discussion:
text: HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.
Code change:
Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first <del> SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </del> <ins> SETTINGS frame.  Receivers that detect a change MAY treat it as a connection error of type PROTOCOL_ERROR. </ins> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any

Related discussion:
text: by taking NAME suggestion of MAY and bolts it to an "if you can detect" caveat
Since this is a change of normative requirement, lets solicit for some more WG input before landing
I noticed the same while reading the document and thought that MAY would be more suitable. Or in more precisely, "MUST ignore any change and MAY treat it as a connection error".
I couldn't see this being discussed in an issue so far. This seems unnecessary. While there is no value to changing the value, it creates a special rule for handling of the setting. In particular, endpoints that don't distinguish between SETTINGS-in-preface and other SETTINGS frames might have trouble generating the special handling necessary to police this rule. While I can see the value to an endpoint in terms of being able to defer creating the whole priority tree mess for new connections until they receive the preface, and maybe avoid creating that stuff entirely. But as long as priority signals are advisory, you get most of the value from a strong recommendation to use the preface, noting that making a change later might be too late. No special exceptions would be needed. I'm sure that the editors will disagree with me here. That's OK, but it's worth noting why this special handling is included in the specification. It's not immediately obvious.
Would it be sufficient to make this a "MAY be treated"? That provides a disincentive to change without requiring special processing.