jiebi/CodeConvo huggingface dataset:
Code change:
Track Request Parameters: The parameters are defined in track-req- params. <del> 6.6.1. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. 6.6.1.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </del> 6.7. The receiver sends an "ANNOUNCE OK" control message to acknowledge

Related discussion:
text: Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review
Code change:
6.1. SD-JWT VPs MUST be encoded using the SD-JWT Combined Format for <del> Presentation as defined in I-D.ietf-oauth-selective-disclosure-jwt. </del> <ins> Presentation as defined in Section 5.4. of I-D.ietf-oauth-selective- disclosure-jwt. </ins> <del> SD-JWT VPs MAY contain a Holder Binding JWT as described in I-D.ietf- oauth-selective-disclosure-jwt. </del> <ins> SD-JWT VPs MAY contain a Holder Binding JWT as described in Section 5.4.1. of I-D.ietf-oauth-selective-disclosure-jwt. </ins> 6.1.1.

Related discussion:
text: Only minor editorial changes such as typos.
Only minor editorial changes such as typos -> no peer-review required at this stage.
Code change:
specific to the underlying transport protocol usage transport- protocols. <del> 2.4. A transport session is established for each track bundle.  The client issues a CONNECT request with a URL which the server uses for identification and authentication.  All control messages and prioritization occur within the context of a single transport session, which means a single track bundle.  When WebTransport is used, multiple transport sessions may be pooled over a single QUIC connection for efficiency. </del> 3. <del> MoQTransport works by transferring objects over QUIC streams.  The application determines how live content is fragmented into tracks, groups, and objects. </del> 3.1. At the point of this writing, the working group has not reached

Related discussion:
text: This PR by itself doesn't make a lot of sense but I'm ok rolling with it if it's part of the grand plan
Code change:
specific to the underlying transport protocol usage transport- protocols. <del> 2.4. A transport session is established for each track bundle.  The client issues a CONNECT request with a URL which the server uses for identification and authentication.  All control messages and prioritization occur within the context of a single transport session, which means a single track bundle.  When WebTransport is used, multiple transport sessions may be pooled over a single QUIC connection for efficiency. </del> 3. <del> MoQTransport works by transferring objects over QUIC streams.  The application determines how live content is fragmented into tracks, groups, and objects. </del> 3.1. At the point of this writing, the working group has not reached

Related discussion:
text: NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.
Code change:
4.1. <del> The "aesgcm128" parameter is decoded and used as the input keying material for the "aesgcm128" content encoding.  The "aesgcm128" parameter MUST decode to at least 16 octets in order to be used as input keying material for "aesgcm128" content encoding. </del> <ins> The "aesgcm" parameter is decoded and used as the input keying material for the "aesgcm" content encoding.  The "aesgcm" parameter MUST decode to at least 16 octets in order to be used as input keying material for "aesgcm" content encoding. </ins> <del> Other key determination parameters can be ignored if the "aesgcm128" </del> <ins> Other key determination parameters can be ignored if the "aesgcm" </ins> parameter is present. 4.2.

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:
1.8. <del> OAuth 2.0 provides a rich authorization framework with well-defined </del> <ins> OAuth 2.1 provides a rich authorization framework with well-defined </ins> security properties.  However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable

Related discussion:
text: Edited intro to reflect what this document is about changed some OAuth 2.0 references to OAuth 2.1 when referring to this document changed document name to follow ID standard name (repo and filename should be updated as well?) pulled out acknowledgments as this doc will be different
Code change:
3.2.1. <del> Confidential or credentialed clients MUST authenticate with the authorization server as described in client-authentication when making requests to the token endpoint. </del> <ins> Confidential clients MUST authenticate with the authorization server as described in client-authentication when making requests to the token endpoint. </ins> Client authentication is used for:

Related discussion:
text: OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.
Code change:
2.1. <ins> 2.1.1. A US state official in State A needs to access the database of State B to retrieve information about a customer who is a citizen of State B.  The official first gains access to the State A gateway by logging in and authenticating to their local front-end system.  The gateway then passes the official's request and identity to a central information sharing system that all states use to share data. Finally, the central system obtains credentials to access the State B gateway and routes the request from the official, along with the officials identity, to the State B gateway to access the customer's information in the State B database. 2.1.2. A home devices company provides a "Camera API" to enable access to home cameras.  Partner companies use this Camera API to integrate the camera feeds into their security dashboards.  Using 2-legged OAuth between the partner and the Camera API, a partner can request the feed from a home camera to be displayed in their dashboard.  The user has an account with the camera provider.  The user may be logged in to view the partner provided dashboard, or they may authorize emergency access to the camera.  The home devices company must be able to independently verify that the request originated and was authorized by a user who is authorized to view the feed of the requested home camera. 2.1.3. A user attempts to access a service that is implemented as a number of on-prem and cloud-based microservices.  Both the on-premise and cloud-based services are segmented by multiple trust boundaries that span one or more on-premise or cloud service environments.  Every microservice can apply an authorization policy that takes the context of the original user, as well as intermediary microservices into account, irrespective of where the microservices are running and even when a microservice in one trust domain calls another service in another trust domain. 2.1.4. A client requests a report from a "local" resource that incorporates data from one or more associated sources.  Each source is in a separate trust domain.  Trust domains have a federated identity framework (e.g.  PKI) and authorization framework, but may have varied and asymmetric specific trust relationships (e.g. transitive trust is not guaranteed).  Trust relationships are established between authorization servers in each trust domain, and exercised through messages passed between the authorization servers that assert identity and authorization claims.  The identity of requesters is chained throughout, but authorization claims are limited to what is necessary to each request. 2.2. </ins> The Identity Chaining flow outlined below describes how these specification are used and work together.  Two examples in the suffix give more concrete examples.  One where a resource server acts as the

Related discussion:
text: Added use cases. We may want to refine these, or move them into a non-normative section later.
Code change:
or IRTF review are invited to publish as an Informational RFC via the Independent Stream Editor (ISE). <del> 3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 4. Algorithms can be designed for general Internet deployment or for use

Related discussion:
text: I suggest that we swap the section 3 and 2 in the sequence of sections so that the readers understand the interpretation of normative text before they read about it. URL
Code change:
attack can be detected. A final (but significant) goal is to provide for ease of <del> implementation, deployment and operation.  This mechanism should have a minimal impact upon performance, and should not require extensive </del> <ins> implementation, deployment and operation.  This mechanism is expected to have a minimal impact upon performance, and a trivial </ins> administrative effort to configure. 1.2.

Related discussion:
text: for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.
Code change:
can change versions as it passes through intermediaries, because the semantics of a HTTP message are independent of its version. <del> While HTTP's core semantics don't change between protocol versions, the expression of them "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire format.  Additionally, HTTP allows incremental, backwards-compatible changes to be made to the protocol without changing its version through the use of defined extension points (extending). The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's corresponding specification of HTTP.  For example, the version "HTTP/1.1" is defined by the combined specifications of this document, "HTTP Caching" Caching, and "HTTP/1.1" Messaging. HTTP's major version number is incremented when an incompatible message syntax is introduced.  The minor number is incremented when changes made to the protocol have the effect of adding to the message semantics or implying additional capabilities of the sender. The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients). </del> A client SHOULD send a request version equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is

Related discussion:
text: and only define the versioning there; leave message version requirements in control data. (no content changes)
Code change:
single reserved bit and a 31-bit priority; see StreamPriority. HEADERS+PRIORITY uses the same flags as the HEADERS frame, except <del> that a HEADERS+PRIORITY frame with a CONTINUES bit MUST be followed by another HEADERS+PRIORITY frame.  See HEADERS for any flags. </del> <ins> that a HEADERS+PRIORITY frame without the END_HEADERS flag set MUST be followed by another HEADERS+PRIORITY frame.  See HEADERS for any flags. </ins> HEADERS+PRIORITY frames MUST be associated with a stream.  If a HEADERS+PRIORITY frame is received whose stream identifier field is

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:
security issues discussed here and provide clear guidance on how clients can avoid them. <ins> 6.1. Some Upgrade Tokens, such as "TLS", are defined for use with any ordinary HTTP Method.  The upgraded protocol continues to provide HTTP semantics, and will convey the response to this HTTP request. The other Upgrade Tokens mentioned in existing do not preserve HTTP semantics, so the method is not relevant.  All of these Upgrade Tokens are specified only for use with the "GET" method. Future specifications for Upgrade Tokens should restrict their use to "GET" requests if the HTTP method is otherwise irrelevant and a request body is not required.  This improves consistency with other Upgrade Tokens and reduces the likelihood that a faulty server implementation might process the request body as the new protocol. </ins> 7. Clients that send HTTP CONNECT requests on behalf of untrusted TCP

Related discussion:
text: important, an OPTIONS request can be used to perform the upgrade to HTTP/2, at the cost of an additional round trip. On the other hand, RFC 9113 , so the topic of this issue is compatible with that notion with a bit of wordsmithing.
Well phrased. More concretely, for servers which read (and buffer) the full request -- including request header and request body -- before processing the request, this is a non-issue. However, many servers make routing and other decisions after the request headers are received. To handle upgrade after the request has been handled, all requests would need to check for Upgrade at the end of handling requests, not at the beginning, which is more common in code that I have seen and in code that I have written. I think it would be ideal if Upgrade requests for new Upgrade tokens were sent to endpoints for which an alternate resource is not provided if the Upgrade does not succeed. If a request with Upgrade is rejected, the HTTP status could reflect that. At the moment, a client can request "GET /altresource.mp4 HTTP/1.1" with "Upgrade: websocket" and the RFCs specify that /altresource.mp4 should be delivered in its entirety before the server switches to WebSockets, and the HTTP response headers included Upgrade: websocket, along with Content-Length or Transfer-Encoding: chunked for /altresource.mp4. The combination of request/response bodies for resources tangential to the Upgrade request is what I would like to see avoided in future Upgrade tokens. As NAME worded so well, I think there are sharp security edges here, and complications in implementations. HTTP/2 extended CONNECT is a better approach as it is only the :protocol change request, and does not include a request body or a request for an alternate resource, at least as I understand RFC 8441 to describe HTTP/2 extended CONNECT for . Another example of where request bodies can potentially be mishandled is if an origin server passes the Upgrade request to a backend via CGI, FastCGI, SCGI, reverse proxy, or something else. Even if the origin server handles the request body properly with the Upgrade request, I certainly do not trust an amateur PHP program to handle the request body properly before switching protocols.
Code change:
security issues discussed here and provide clear guidance on how clients can avoid them. <ins> 6.1. Some Upgrade Tokens, such as "TLS", are defined for use with any ordinary HTTP Method.  The upgraded protocol continues to provide HTTP semantics, and will convey the response to this HTTP request. The other Upgrade Tokens mentioned in existing do not preserve HTTP semantics, so the method is not relevant.  All of these Upgrade Tokens are specified only for use with the "GET" method. Future specifications for Upgrade Tokens should restrict their use to "GET" requests if the HTTP method is otherwise irrelevant and a request body is not required.  This improves consistency with other Upgrade Tokens and reduces the likelihood that a faulty server implementation might process the request body as the new protocol. </ins> 7. Clients that send HTTP CONNECT requests on behalf of untrusted TCP

Related discussion:
text: (Yes, I am sure that somewhere, someone handles this properly, but I am willing to wager there are also places where an empty request body is incorrectly assumed by naive scripts.) To be proactive, lighttpd 1.4.74 and later will by default ignore Upgrade in all requests with a request body unless lighttpd 1.4.74 or later is explicitly configured to enable request body along with Upgrade via URL (gw == gateway in lighttpd, for CGI, reverse proxy, and other backends) tl;dr: I am not asking to restrict HTTP/1.1 Upgrade only to the GET method. I would like to request that optimistic-upgrade add guidance suggesting that future Upgrade tokens should suggest/recommend use in requests without a request body, and note that some proxies or origin servers may ignore HTTP/1.1 Upgrade when a non-empty request body is present. Thank you for your consideration.
Since we are discussing this publicly, I hope these details are appropriate. lighttpd 1.4.56 and later supports the HTTP/1.1 (now deprecated by the RFCs), but lighttpd ignores unconditionally if a request body is present. Among the reasons for doing so -- in addition to simpler implementation -- is that if an attacker controlled the request body content and wrote it in such a way to start with HTTP/2 Connection Preface and an HTTP/2 request, and if the server failed to handle the HTTP/1.1 request body before switching to HTTP/2 protocol, then an attacker could inject HTTP/2 requests via that mishandled (on the server) HTTP/1.1 request body.
As I understand, this problem is specific to HTTP/1.1. I'm not sure if we could add new requirements, unless we change the core HTTP documents and can modify all existing HTTP clients that use upgrade to adopt the new behavior. At the same time, IMO it would be perfectly reasonable to point out the "sharp edges" and provide guidelines to new extensions that would leverage the upgrade mechanism. In that respect, I like the idea of recommending use of GET but not any other HTTP method for new extensions, as suggested in the original post from NAME
NAME Yes, the request header is specific to HTTP/1.1. I can imagine a future Upgrade token which requires POST with some sort of (short) request body containing authentication and/or payment information.
Code change:
security issues discussed here and provide clear guidance on how clients can avoid them. <ins> 6.1. Some Upgrade Tokens, such as "TLS", are defined for use with any ordinary HTTP Method.  The upgraded protocol continues to provide HTTP semantics, and will convey the response to this HTTP request. The other Upgrade Tokens mentioned in existing do not preserve HTTP semantics, so the method is not relevant.  All of these Upgrade Tokens are specified only for use with the "GET" method. Future specifications for Upgrade Tokens should restrict their use to "GET" requests if the HTTP method is otherwise irrelevant and a request body is not required.  This improves consistency with other Upgrade Tokens and reduces the likelihood that a faulty server implementation might process the request body as the new protocol. </ins> 7. Clients that send HTTP CONNECT requests on behalf of untrusted TCP

Related discussion:
text: Even so, I still like the idea of recommending that any new HTTP/1.1 Upgrade tokens prefer to use GET without a request body, or to use other methods if a request body is required. Aside: NAME you might be interested in adding some Upgrade tests to URL, specifically for request smuggling where servers support and might not properly handle an unexpected request body. (lighttpd always ignores if request body is non-zero length.)