jiebi/CodeConvo huggingface dataset:
Code change:
The client connection preface starts with a sequence of 24 octets, which in hex notation is: <del> That is, the connection preface starts with the string </del> <ins> That is, the connection preface starts with the string " </ins> <del> . This sequence MUST be followed by a SETTINGS frame (SETTINGS), </del> <ins> ".  This sequence MUST be followed by a SETTINGS frame (SETTINGS), </ins> which MAY be empty.  The client sends the client connection preface as the first application data octets of a connection.

Related discussion:
text: A recent xml2rfc update changed the way that the element was rendered in text. Take advantage of that by adding quotes to strings that really do benefit from additional quoting, such as the "PRI ..." preface string. Most of the changes shown in a recent diff are down to losing quotes on header field names and other protocol elements. These do not need to be quoted for their meaning to be clear and unambiguous. The use of for these items improves the HTML rendering, but the loss of line noise in text renderings is a net win (at least in my opinion).
I agree with your reasoning, this seems like a good change.
Code change:
message is forwarded and, for each connection-option in this field, remove any header or trailer field(s) from the message with the same name as the connection-option, and then remove the Connection header <del> field itself (or replace it with the intermediary's own connection </del> <ins> field itself (or replace it with the intermediary's own control </ins> options for the forwarded message). Hence, the Connection header field provides a declarative way of

Related discussion:
text: The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.
Code change:
5.2.1.6. The "no-transform" request directive indicates that the client is <del> asking for intermediaries to avoid transforming the payload, as </del> <ins> asking for intermediaries to avoid transforming the content, as </ins> defined in message.transformations. 5.2.1.7.

Related discussion:
text: ... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.
Code change:
WebSocket protocol.  Additionally, the WebSocket protocol requires high-entropy masking of client-to-server frames (RFC6455). <del> 5.4. </del> <ins> 5.3. </ins> RFC9298 says:

Related discussion:
text: This avoids having to determine whether is an actual existing standard or not. This is an alternative to
Merging for draft cutoff.
The lists an entry for HTTP/.\, and specifically identifies "2.0" as a possible version value, as instructed by . However, this flow seems to have been superseded by "Upgrade: h2c", which was introduced in RFC 7540 and deprecated in RFC 9113. I am not aware of any implementations of "Upgrade: HTTP/2.0" in clients or servers. I think we have two main options: Status Quo: Regard "HTTP/.\" as a mechanism that is formally defined but not implemented anywhere. Provide formal analysis of its security for completeness. Deprecation: Update RFC 9110 in this draft to remove the definition of this upgrade token. Mark "HTTP" as "obsolete" in the Upgrade Tokens Registry.
Moving discussion over to the issue, perhaps. Upgrading to TLS is a defined thing that gets used; I'm not clear that we need to deprecate that. Upgrading to future HTTP versions is a little more interesting. Certainly it's illegal to upgrade to or because upgrade isn't defined by those specifications. RFC 7540 defines a distinct token, RFC 9113 deprecates it, and RFC 9114 does not define an Upgrade path for obvious reasons. It certainly looks like we've decided not to use this mechanism for changing HTTP versions. Does that mean we should eliminate it? I'm not opposed, but I'm also not certain we need to go there.
Moving to TLS with upgrade (i.e., RFC 2817) is now so much of a niche thing that I think that deprecation would be wise. We've heard that it is still in use, but it's certainly not inoperable in quite the same way as other parts of the protocol. Either way, I think it would be better to write a separate document deprecating Upgrade (either completely or more narrowly) than to sneak it in here. This document can point out that it is unsafe in the ways in which it is unsafe, but it doesn't need to make the deeper cut to achieve that.
It seems clear that we don't want to deprecate in this document, so I've removed that text from . I've kept open to discuss the fate of .
Code change:
WebSocket protocol.  Additionally, the WebSocket protocol requires high-entropy masking of client-to-server frames (RFC6455). <del> 5.4. </del> <ins> 5.3. </ins> RFC9298 says:

Related discussion:
text: The WG seems to believe that this mechanism is already deprecated, if it was ever defined at all, and the IANA registry entry is just misleading or incorrect.
The trouble is that exists in a sort of quantum superposition of standardized and deprecated, but that will collapse if we mention it in this draft in any way. The options I see are: Don't claim (as the current text does) to present an exhaustive analysis of the defined Upgrade Tokens, and silently ignore the registration of . Treat it as a live standard. Declare that it was already deprecated. Deprecate it.
I'd say deprecating isn't particularly useful or interesting, since that doesn't impact implementations. If we can't agree on which quantum state we are in and want to be in at the same time, then I'd leave the cat in the box. The more interesting question is: should implementations do something to protect against a dangerous ? For h2, the preface should protect against smuggling. Where do we stand for other versions, is there a risk we should warn implementers about?
My expectation is that implementations of do not exist, and never will, so I don't think it's very useful to provide guidance to them. There's a question of whether one can even speak about a "downward Upgrade" from HTTP/1.1 to 0.9-1.1. Assuming that is allowed, I think 1.0 and 1.1 are safe, if we assume that the HTTP-Version line is sent/repeated at this point. (Does Upgrade: HTTP create a new HTTP connection or re-version the existing one???) They both start with "HTTP/1", which is not a valid method name due to the "/". HTTP/0.9 is possibly more interesting since it does not send an HTTP-Version line. I don't see a way for the server to figure out whether the client is speaking HTTP/1.1 (after the rejected upgrade) or HTTP/0.9 (optimistically). However, I don't think this poses a security threat, so long as the attacker-controlled data is the same in HTTP/1.1 as it is in HTTP/0.9.
Code change:
WebSocket protocol.  Additionally, the WebSocket protocol requires high-entropy masking of client-to-server frames (RFC6455). <del> 5.4. </del> <ins> 5.3. </ins> RFC9298 says:

Related discussion:
text: There could possibly be a problem if the client, believing it is speaking HTTP/0.9, allows untrusted code to manipulate headers that were not special in HTTP/0.9 but are special in HTTP/1.1 (e.g. Content-Length, Transfer-Encoding). But as I said, this strikes me as counting angels on the head of a pin. "Upgrade: HTTP/0.9" is just not a thing, and we should all agree on that and move on.
I totally agree with you. I was more thinking about guidance for intermediaries that support other Upgrades (e.g., WebSocket) for what they should do if they encounter unknown/unexpected upgrade tokens like these. If there is no such guidance, than we can just go back to pretending that doesn't exist
HTTP intermediaries can't really do anything with unrecognized Upgrade tokens in HTTP/1.1. (Not even the useful thing, which would be to convert them to/from for Extended CONNECT.)
Code change:
6.1. <del> The Holder MUST perform the following (or equivalent) steps when receiving a Combined Format for Issuance: </del> <ins> Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT: If any step fails, the SD-JWT is not valid and processing MUST be aborted. </ins> It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the End-User when needed. <ins> 6.2. If a Key Binding JWT is received by a Holder, the SD-JWT SHOULD be rejected. </ins> For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: <del> 6.2. </del> <ins> 6.3. </ins> <del> Upon receiving a Presentation, Verifiers MUST ensure that </del> <ins> Upon receiving a Presentation, in addition to the checks outlined in sd_jwt_verification, Verifiers MUST ensure that </ins> To this end, Verifiers MUST follow the following steps (or equivalent):

Related discussion:
text: changes. created a common sd-jwt verification section wallet processing section talks only about presentation creation verifier processing section talks only about key binding JWT processing and refers to a common sd-jwt verification section Note that the terminology is new - based on the PR that NAME is doing for issue (probably not touching these sections in your PR might be the best to minimize conflict, Brian, or I can push later to your branch - wanted to do this PR while I had the idea fresh in my head). I used as a placeholder.
The direction of this looks good. Thanks for putting together the PR! I made just a few cleanup type comments/suggestions. Some do touch on the terminology, but otherwise think I can avoid this section in the in-progress PR
I do think a document history bullet should be added - "Consolidate processing rules for Holder and Verifier"
As discussed on a recent call - merging this now and closing the associated issues. NAME intends to look at it in the main branch and propose additional changes in a new PR, if there are opportunities for improvement.
Code change:
the "cnf" claim of the corresponding client key attestation JWT. The authorization server MUST reject a JWT that is not valid in <del> all other respects per "JSON Web Token (JWT)". </del> <ins> all other respects per "JSON Web Token (JWT)" RFC7519. </ins> The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. 4. <del> TODO Security </del> <ins> 4.1. Implementers should be aware that the design of this authentication mechanism deliberately allows for a client instance to re-use a single Client Attestation JWT in multiple interactions/requests with an authorization server, whilst producing a fresh Client Attestation PoP JWT.  Client deployments should consider this when determining the validity period for issued Client Attestation JWTs as this ultimately controls how long a client instance can re-use a single Client Attestation JWT. </ins> 5. <del> This document has no IANA actions. </del> <ins> TODO 6. 6.1. This section registers the value "client-assertion-type:jwt-key- attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. o URN: urn:ietf:params:oauth:client-assertion-type:jwt-key- attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC 6.2. This section registers the value "attest_key_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591. o Token Endpoint Authentication Method Name: "attest_key_client_auth" o Change Controller: IESG o Specification Document(s): TBC </ins>

Related discussion:
text: The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.
Code change:
textual value makes the prioritization scheme extensible; see the discussion below. <del> 9. </del> <ins> 10. TBD 11. </ins> This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864:

Related discussion:
text: and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.
Code change:
6.4. While the early Internet was dominated by wired links, the properties <del> of wireless links have become extremely important to Internet performance.  In particular, a proposed congestion control algorithm should be evaluated in situations where some packet losses are due to radio effects, rather than router queue drops; the link capacity varies over time due to changing link conditions; and media access delays and link-layer retransmission lead to increased jitter in round-trip times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. </del> <ins> of wireless links have become important to Internet performance.  In particular, a proposed congestion control algorithm should be evaluated in situations where some packet losses are due to radio effects, rather than router queue drops; the link capacity varies over time due to changing link conditions; and media access delays and link-layer retransmission lead to increased jitter in round-trip times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. </ins> 7.

Related discussion:
text: Suggested final edits. do not infer that BBR is "fixed", but rather say that it contains a "fix" for this. don't overstate the importance:-) fix to start by saying what the para is about (i.e. the section title).
Code change:
If a client receives a dictionary with a type that it does not understand, it MUST NOT use the dictionary. <del> The "type" value is optional and defaults to "raw". </del> <ins> The "type" value is optional and defaults to raw. </ins> 2.1.5.

Related discussion:
text: Switched from using the ABNF field types to the human names (i.e. sf-dictionary to Dictionary) for all of the Structured Field header values. Switched dictionary "type" to a Token (from String).
NAME could you PTAL at the change in referencing the header field types? Specifically, I wasn't sure if I should capitalize the types or not (I did since that's how the structured fields RFC referred to them).
Yep, this looks good. It's common to add something to you Notational Conventions section (or whatever) that says roughly "This specification uses the following terms from [ref to SF]: String, Byte Sequence, Token, ..."
Code change:
If the attribute-name case-insensitively matches the string "Max- Age", the user agent MUST process the cookie-av as follows. <del> If the first character of the attribute-value is not a DIGIT or a "-" character, ignore the cookie-av. </del> <ins> If the attribute-value is empty, ignore the cookie-av. If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av. </ins> If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av. <del> Let delta-seconds be the attribute-value converted to an integer. </del> <ins> Let delta-seconds be the attribute-value converted to a base 10 integer. </ins> Let cookie-age-limit be the maximum age of the cookie (which SHOULD be 400 days or less, see attribute-max-age).

Related discussion:
text: Contains the following changes: Skip parsing the attribute on empty value. Skip parsing the attribute when given Max-Age=- Add mention of "base 10" as guidance for implementers parsing integers from Max-Age. Regarding browser interop: Skip parsing aligns on Safari behavior and against Chrome and Firefox, which will default to session lifetime when any invalid Max-Age attribute is found (based on manual testing, it's difficult to test this with WPT at the moment, see ).
Code change:
7.4.2. <del> Parameter Name: aesgcm128 </del> <ins> Parameter Name: aesgcm </ins> Purpose: Provide an explicit input keying material value for the <del> aesgcm128 content encoding. </del> <ins> aesgcm content encoding. </ins> Reference: this document

Related discussion:
text: In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .
Code change:
In cross-device flows that follow the user-transferred authorization data pattern, the client on the Initiating Device initiates the authorization request, but the user still has to transfer the <del> authorization code to the Initiating Device.  The authorization request may happen as a result of user interaction with the Initiating Device, but may also be triggered without the user's direct interaction with the Initiating Device. </del> <ins> authorization data to the Initiating Device.  The authorization data may take different forms, including a numerical value such as a 6 digit authorization code.  The authorization request may happen as a result of user interaction with the Initiating Device, but may also be triggered without the user's direct interaction with the Initiating Device. </ins> Attackers exploit the user-transferred authorization data pattern by combining the social engineering techniques used to set context for <del> users and tricking users into providing them with access codes sent to their phones.  These attacks are very similar to phishing attacks, except that the attacker also has the ability to trigger the </del> <ins> users and tricking users into providing them with authorization data sent to their phones.  These attacks are very similar to phishing attacks, except that the attacker also has the ability to trigger the </ins> authorization request to be sent to the user directly by the Authorization Server. The unauthenticated channel may also be exploited in variations of <del> the above scenario where the user (as opposed tot he attacker) initiates the flow and is then tricked into sending the authorization data (e.g. access code) to the attacker.  In these flows, the user is already authenticated and they request authroization data to transfer </del> <ins> the above scenario where the user (as opposed to the attacker) initiates the flow and is then convinced using social engineering techniques into sending the authorization data (e.g. a 6 digit authorization code) to the attacker.  In these flows, the user is already authenticated and they request authorization data to transfer </ins> a session or obtain some other privilege such as joining a device to <del> a network.  The authorization data may be represented as a QR code o text message.  The attacker then proceeds to exploit the </del> <ins> a network.  The authorization data may be represented as a QR code or authorization code.  The attacker then proceeds to exploit the </ins> unauthenticated channel by using social engineering techniques to <del> trick the user into initiating a flow and send the QR code or user code to the attacker, which the attacker use to obtain the privileges </del> <ins> convince the user to send the QR code or user code to the attacker. The attacker then use the authroization data to obtain the privileges </ins> that would have been assigned to the user. 3.4.

Related discussion:
text: Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!
Code change:
The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of RFC7540). <del> The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this </del> <ins> The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this </ins> document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are encouraged to use alternative priority signals (for example, header-

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:
the catalog. Each timeline track begins with a header row of <del> MEDIA_PTS,GROUP_ID,OBJECT_ID,WALLCLOCK,METADATA.  This row defines </del> <ins> MEDIA_PTS,GROUP_ID,OBJECT_ID, WALLCLOCK,METADATA.  This row defines </ins> the 5 columns of data within each record. MEDIA_PTS: a media timestamp rounded to the nearest millisecond.

Related discussion:
text: Fixing table references and reformatting certain sections to 80 chars line width.
Table 2 is declared twice, as is Table 3.