jiebi/CodeConvo huggingface dataset:
Code change:
values are static, and MUST be prepared to update the stored "auth_session" value if one is received in a response. <ins> To mitigate the risk of session hijacking, the 'auth_session' MUST be bound to the device, and the authorization server MUST reject an 'auth_session' if it is presented from a different device than the one it was bound to. </ins> See auth-session-security for additional security considerations. 6.

Related discussion:
text: Also, doing DPoP key binding of the needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.
Closing this as it was resolved in
looks okay to me (pending conflicts that need to be resolved)
Code change:
request. An origin server that receives an If-Match header field MUST evaluate <del> the condition prior to performing the method (evaluation). </del> <ins> the condition as per evaluation prior to performing the method. </ins> To evaluate a received If-Match header field:

Related discussion:
text: this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.
Code change:
server to allow the client to use Extended CONNECT. The semantics of the pseudo-header fields and setting are identical <del> to those in HTTP/2 as defined in RFC8441.  HTTP/3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </del> <ins> to those in HTTP/2 as defined in RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </ins> SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.

Related discussion:
text: NAME I think I did the needful here by cargo-culting . Does this look good to you?
Thanks for the suggestions!
(not tested, but if it ends generating the desired output...)
Code change:
HTTP/2 being negotiated with a prohibited cipher suite if the application protocol and cipher suite are independently selected. <ins> 9.2.3. TLS 1.3 includes a number of features not available in earlier versions.  This section discusses the use of these features. HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat a TLS post- handshake CertificateRequest message as a ConnectionErrorHandler of type PROTOCOL_ERROR. The prohibition on post-handshake authentication applies even if the client offered the "post_handshake_auth" TLS extension.  Post- handshake authentication support might be advertised independently of TLS-ALPN.  Clients might offer the capability for use in other protocols, but inclusion of the extension cannot imply support within HTTP/2. TLS13 defines other post-handshake messages, NewSessionTicket and KeyUpdate, which can be used as they have no direct interaction with HTTP/2.  Unless the use of a new type of TLS message depends on an interaction with the application-layer protocol, that TLS message can be sent after the handshake completes. TLS early data MAY be used to send requests, provided that the guidance in RFC8470 is observed.  Clients send requests in early data assuming initial values for all server settings. </ins> 10. 10.1.

Related discussion:
text: A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).
Code change:
Startup by switching to a pacing_gain well below 1.0, until any estimated queue has been drained.  It uses a pacing_gain of BBRDrainPacingGain = 0.35, chosen via analysis BBRDrainPacingGain and <del> experimentation (on YouTube) to try to drain the queue in less than one round-trip: </del> <ins> experimentation to try to drain the queue in less than one round- trip: </ins> In Drain, when the amount of data in flight is less than or equal to the estimated BDP, meaning BBR estimates that the queue at the

Related discussion:
text: Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.
Code change:
parameters for this signature, including the covered content list with all associated parameters. <del> "alg": The HTTP message signature algorithm from the HTTP Message Signature Algorithm Registry, as an "sf-string" value. "keyid": The identifier for the key material as an "sf-string" value. </del> "created": Creation time as an "sf-integer" UNIX timestamp value. Sub-second precision is not supported.

Related discussion:
text: This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.
Code change:
integrity.  It also coined the term "instance" and "instance manipulation" in order to explain concepts that are now more universally defined, and implemented, as HTTP semantics such as <del> "selected representation data" (SEMANTICS). </del> <ins> selected representation data (SEMANTICS). </ins> Experience has shown that implementations of RFC3230 have interpreted the meaning of "instance" inconsistently, leading to interoperability

Related discussion:
text: Right now, it's inconsistent in the document. HTTP core just uses an unquoted version so I'm inclined to just use that
Code change:
uses the following ABNF rules: "VCHAR", "SP", "DQUOTE", "LF".  This document uses the following ABNF rules from STRUCTURED-FIELDS: "sf- string", "inner-list", "parameters".  This document uses the <del> following ABNF rules from HTTP: "field-content". </del> <ins> following ABNF rules from HTTP and HTTP1: "field-content", "obs- fold", "obs-text". </ins> In addition to those listed above, this document uses the following terms:

Related discussion:
text: Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base
Code change:
An initial set of settings registrations can be found in SettingValues. <ins> 8.4. 8.4.1. This section describes a header field for registration in the Permanent Message Header Field Registry.  RFC3864 HTTP2-Settings http standard IETF RFC XXXX (this document) This header field is only used by the client in the Upgrade-based negotiation. The HTTP2-Settings header field is used in the Upgrade-based negotiation by the client.  It is sent from the client to the server to provide the payload for its SETTINGS frame in anticipation of the server responding with HTTP/2.0 frames. The HTTP2-Settings header field MUST NOT appear more than once in an HTTP request and MUST NOT appear at all in an HTTP response. </ins>

Related discussion:
text: :Client advertising settings during Upgrade dance URL
I assume that this header field is hop-by-hop in the HTTP/1.1 sense and should appear in the Connection header field.
Ooops, yes! Just checked that in.
This issue is to track whether the client should advertise its settings (e.g. contents of SETTINGS frame) as part of the Upgrade GET (e.g. as HTTP/1.1 headers in the GET request). Normally, the first HTTP/2.0 frame the client emits is the SETTINGS frame. This means the server will receive the client's settings before getting the SYNSTREAM from the client. However, in the Upgrade Dance the server receives the GET and has to respond with a 101 HTTP/1.1 response followed by the HTTP/2.0 SYNREPLY. The ugliness here is that the server will be in a situation where it has to send the SYN_REPLY (and possibly DATA frames and possibly start push streams) without knowing the client's settings. This means the server may blow the client’s flow control buffers, or emit a pushed stream even though the client is incapable of processing pushed streams, etc. If we include the settings as part of the initial Upgrade GET then 1) Server receives the pre-requisite initials settings and the initial GET request in a single package. Makes life simpler. 2) Brings us to parity with the SSL route where the server will have the cilent's SETTINGS before it starts working on the initial request.
Discussed at SF Interim; targetting 1st implementation draft. Gabriel to make proposal.
Addressed via "HTTP2-Settings Header Field" section.
Code change:
A dictionary with a member whose value is an inner-list of tokens: <del> Typically, a header field specification will define the semantics of individual member names, as well as whether their presence is </del> <ins> A dictionary with a mix of singular and list values, some with parameters: Typically, a header field specification will define the semantics using individual member names, as well as whether their presence is </ins> required or optional.  Recipients MUST ignore names that are undefined or unknown, unless the header field's specification specifically disallows them.

Related discussion:
text: Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.
Code change:
collected.abnf shows the collected grammar with all list operators expanded to standard ABNF notation. <del> The following core rules are included by reference, as defined in RFC5234: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible USASCII character). </del> <ins> The following core rule is included by reference, as defined in RFC5234: DIGIT (decimal 0-9). </ins> Semantics defines the following rules:

Related discussion:
text: "The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character)." Of these, only DIGIT is actually used.
Code change:
format of this claim MAY be a Subject Identifier as specified in SubjectIdentifiers. <del> An "azc" claim, whose value is a JSON object that contains values </del> <ins> An "azd" claim, whose value is a JSON object that contains values </ins> that remain constant in the call chain. <del> figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token: </del> <ins> 5.2.2. The JWT body MAY have the following claims: 5.2.2.1. The Txn-Token MAY contain an "req_ctx" claim, whose value is a JSON object the describes the requester context of the transaction.  This MAY include the IP address information of the originating user, as well as information about the computational entity that requested the Txn-Token. The JSON value of the "req_ctx" claim MAY include any values the Txn- Token Service determines are interesting to downstream services that rely on the Txn-Token.  The following claims are defined so that if they are included, they have the following meaning: * "req_ip" The IP address of the requester.  This MAY be the end-user or a robotic process that requested the Transaction * "authn" The authentication method used to idenitfy the requester.  Its value is a URN that uniquely identifies the method used.  * "req_wl" The requesting workload.  A URN that uniquely identifies the computational entity that requested the Txn-Token.  This entity MUST be within the Trust Domain of the Txn-Token. 5.2.2.2. The Txn-Token MAY contain a "purp" claim, whose value specifies the purpose of the transaction.  The format of this claim is a JSON string. 5.2.3. The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token: </ins> 6.

Related discussion:
text: Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.
Code change:
The resulting values are encoded as follows: <del> If the encoding were not applied, the resultant value would be: </del> <ins> If the encoding were not applied, the resultant values would be: </ins> <del> This base string violates the constraints on component values, and is therefore invalid. </del> <ins> This base string contains characters that violate the constraints on component names and values, and is therefore invalid. </ins> 2.2.9.

Related discussion:
text: Encodes query parameter names to match values, to avoid non-ascii or otherwise problematic values.
In 2.2.8: What if the query parameter contains non-ASCII characters? I think this needs to say that the name parameter needs to contain the raw (percent-encoded) name.
Good catch, I believe you're correct.
Code change:
A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit the number of responses that can be concurrently pushed by a server. <del> Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables server push by preventing the server from creating the necessary streams.  This does not prohibit a server from sending PUSH_PROMISE frames; clients need to reset any promised streams that are not wanted. </del> <ins> Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero prevents the server from opening the streams necessary to push responses. However, this does not prevent the server from reserving streams using PUSH_PROMISE frames, because "reserved" streams do not count toward the concurrent stream limit.  Clients that do not wish to receive pushed resources need to reset any unwanted reserved streams or set SETTINGS_ENABLE_PUSH to 0. </ins> Clients receiving a pushed response MUST validate that either the server is authoritative (see authority) or the proxy that provided

Related discussion:
text: This is confusing; hopefully this rewrite is a little less so. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
Code change:
A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit the number of responses that can be concurrently pushed by a server. <del> Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables server push by preventing the server from creating the necessary streams.  This does not prohibit a server from sending PUSH_PROMISE frames; clients need to reset any promised streams that are not wanted. </del> <ins> Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero prevents the server from opening the streams necessary to push responses. However, this does not prevent the server from reserving streams using PUSH_PROMISE frames, because "reserved" streams do not count toward the concurrent stream limit.  Clients that do not wish to receive pushed resources need to reset any unwanted reserved streams or set SETTINGS_ENABLE_PUSH to 0. </ins> Clients receiving a pushed response MUST validate that either the server is authoritative (see authority) or the proxy that provided

Related discussion:
text: This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.
Code change:
Status List as specified in status-list-json. The following example illustrates the CBOR representation of the <del> Status List: </del> <ins> Status List in Hex: </ins> <del> The following is the CBOR diagnostic output of the example above: </del> <ins> The following is the CBOR Annotated Hex output of the example above: </ins> 5.

Related discussion:
text: Changes the CWT example to a Hex and annotated Hex version instead of diagnstic. Rendered version: URL Did you have time to check this example with your team NAME
We have a CWT in 6.3 in diagnostic notation and decided to add a raw (hex) example to the annex
Code change:
.  A schedulable object in MoQT is either: <del> An object that belongs to a peep where that object would be the next object to be sent in that peep. </del> <ins> An object that belongs to a subgroup where that object would be the next object to be sent in that subgroup. </ins> An object that belongs to a track with delivery preference Datagram. <del> Since a single peep or datagram has a single publisher priority, it can be useful to conceptualize this process as scheduling peeps or datagrams instead of individual objects on them. </del> <ins> Since a single subgroup or datagram has a single publisher priority, it can be useful to conceptualize this process as scheduling subgroups or datagrams instead of individual objects on them. </ins> A

Related discussion:
text: (recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM