jiebi/CodeConvo huggingface dataset:
Code change:
5.1. <del> (TODO: Write this section) </del> <ins> Proposals SHOULD be evaluated under a variety of bottleneck queue disciplines.  At a minimum, a proposal should reason about an algorithm's response to various AQMs.  Simulation or empirical results are, of course, valuable. Note that evaluation of AQM techniques - as opposed to their impact on specific congestion control proposals - is out of scope of this document.  RFC7567 describes design considerations for AQMs. Among the AQM techniques that might have an impact on a congestion control algorithm are FQ-CoDel RFC8290; Proportional Integral Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332. </ins> 5.2. <ins> (TODO: Write this section) 5.3. </ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649. <del> 5.3. </del> <ins> 5.4. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.

Related discussion:
text: ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.
Code change:
5.1. <del> (TODO: Write this section) </del> <ins> Proposals SHOULD be evaluated under a variety of bottleneck queue disciplines.  At a minimum, a proposal should reason about an algorithm's response to various AQMs.  Simulation or empirical results are, of course, valuable. Note that evaluation of AQM techniques - as opposed to their impact on specific congestion control proposals - is out of scope of this document.  RFC7567 describes design considerations for AQMs. Among the AQM techniques that might have an impact on a congestion control algorithm are FQ-CoDel RFC8290; Proportional Integral Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332. </ins> 5.2. <ins> (TODO: Write this section) 5.3. </ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649. <del> 5.3. </del> <ins> 5.4. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.

Related discussion:
text: But there are of course other congestion controls out there, both standard and non-standard, in support of real-time and other non-greedy applications. Should we mention those as a class? Namecheck some examples?
editors meeting 8836 requirements document 8867 and 8868 are test cases, but informational. Reese: standard stuff is not widely deployed, widely deployed stuff is not standardized. But RMCAT is new. Maybe there aren't well-documented protocols to evaluate vs., so it's hard to require anything here. I'll take a look, will probably have to go to the community.
Editors: We need to consider the interaction between real time and not-real time is evaluating real-time in scope? See 8836, 8867, 8868.
Looks good enough.Thanks for the changes.
Code change:
All of section 2.2 of RFC8693 applies.  In addition, the following applies to implementations that conform to this specification. <del> The "aud" claim in the returned authorization grant MUST identify the requested authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients from presenting access tokens as an authorization grant to an authorization server in a different domain. </del> <ins> The "aud" claim in the returned JWT authorization grant MUST identify the requested authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients from presenting access tokens as an authorization grant to an authorization server in a different domain. </ins> <del> The "aud" claim included in the returned authorization grant MAY identify multiple authorization servers, provided that trust </del> <ins> The "aud" claim included in the returned JWT authorization grant MAY identify multiple authorization servers, provided that trust </ins> relationships exist with them (e.g. through federation).  It is RECOMMENDED that the "aud" claim is restricted to a single authorization server to prevent an authorization server in one

Related discussion:
text: when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant
Code change:
A client can learn that a particular server supports HTTP/2.0 by other means.  A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the ConnectionHeader. <del> This only affects the resolution of "http" URIs; servers supporting HTTP/2.0 are required to support TLSALPN for "https" URIs. </del> <ins> A server can identify such a connection by the use of the "PRI" method in the connection header.  This only affects the resolution of "http" URIs; servers supporting HTTP/2.0 are required to support TLSALPN for "https" URIs. </ins> Prior support for HTTP/2.0 is not a strong signal that a given server will support HTTP/2.0 for future connections.  It is possible for

Related discussion:
text: In URL;list=ietf-http-wg, it was proposed that the PRI method be reserved in the HTTP/1.1 method registration document to avoid possible future reservation and ensure that the magic string remains a reliable way of differentiating HTTP/1.1 connections from HTTP/2.0 connections. There was a +1 and some offline discussion along the same vein, no dissent that I heard or saw. However, I don’t see it in URL, presumably because no RFC exists to reference. The appropriate doc is probably HTTP/2.0 rather than breaking the glass on the prepopulated registrations.
There was a question whether "SM" should also be reserved; I personally don't think so, since that line will never be interpreted as a potentially-valid HTTP request line or header. However, I don't think it would break anything if we did.
Break things, no. Squat on prime name-real-estate, a little.
Code change:
Prefix Information option header values: A prefix is not considered a suitable on-link prefix if the 'L' flag <del> bit is set, but the 'A' flag bit is not set.  This indicates that node addressability is being managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "suitable"&#151;not all hosts can actually use it. </del> <ins> bit is not set, or if neither the 'A' flag bit nor the 'P' flag bit is set.  When the 'A' flag bit is not set, this indicates that individual node addresses within the prefix are being managed using DHCPv6.  If the 'P' flag bit is set, then hosts that wish to allocate their own addresses can do so by acquiring a prefix from which to allocate them using DHCPv6 Prefix Delegation RFC 9663.  Nodes are not required to use DHCPv6 to acquire individual addresses, so a prefix that requires the use of DHCPv6 for that purpose can't be considered "suitable"&#151;not all hosts can actually use it. </ins> Note: there can be layer two networks where neighbor discovery is not supported and therefore we cannot set the 'L' flag bit, but could set

Related discussion:
text: Add text to the suitable prefix section that allows a prefix that is local and has either the A flag or the P flag set to be considered usable, whereas before only prefixes with the A flag set were considered usable.
Code change:
Since the codings listed in "Content-Encoding" are a characteristic of the representation (see HTTP), both the client and the server <del> always compute the upload offset on the content coded data (that is, the representation data).  Moreover, the content codings are retained throughout the entire upload, meaning that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </del> <ins> always compute the values for "Upload-Offset" and optionally "Upload- Length" on the content coded data (that is, the representation data). Moreover, the content codings are retained throughout the entire upload, meaning that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </ins> 14.

Related discussion:
text: As NAME mentioned in URL, is not directly applicable here because it asks the server to send the digest corresponding to the response content, not the received request content. Good point that a client may validate digests while a multi-request upload is progressing. A server could respond with the latest digest of the entire uploaded data (not just the data from the last request) using after POST and PATCH requests. The client can then validate and decide to abort if the digests don't match. This usage would be in line with the PATCH example in . The server responds with the digest of the representation after the PATCH has been applied. The example also notes that the server is not required to respond with the representation itself and could also have returned a 204 (as is done for resumable uploads):
Makes sense, thanks for clarifying. is most likely good enough given that it indicates the current checksum of what the server received.
NAME please, stalk me for a review in the next week :)
NAME It took me a bit more than a week, but here we go: URL Happy to hear your feedback :)
Code change:
limit their values to US-ASCII octets.  A recipient SHOULD treat other octets in field content (obs-text) as opaque data. <ins> Field values containing control ( ) characters such as CR or LF are invalid; recipients MUST either reject a field value containing control characters, or convert them to SP before processing or forwarding the message. </ins> Leading and trailing whitespace in raw field values is removed upon field parsing (field.parsing).  Field definitions where leading or trailing whitespace in values is significant will have to use a

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:
Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user on the basis of unique values encoded in the SD-JWT (Issuer <del> signature, salts, digests, etc.).  More advanced cryptographic schemes, outside the scope of this specification, can be used to prevent this type of linkability. </del> <ins> signature, salts, digests, etc.). To prevent these types of linkability, various methods, including but not limited to the following ones can be used: </ins> 9. <del> We would like to thank Alen Horvat, Brian Campbell, Christian Paquin, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, Shawn Butterfield, and Torsten Lodderstedt for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> We would like to thank Alen Horvat, Arjan Geluk, Brian Campbell, Christian Paquin, David Bakker, Fabian Hauck, Giuseppe De Marco, Kushal Das, Mike Jones, Nat Sakimura, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, and Torsten Lodderstedt for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: Added an option to do pairwise SD-JWTs to prevent Verifier/Verifier linkability Original feedback. Please re-write section 8.2 in the light of the above suggestions.
Code change:
6.3. <del> The Referenced Token MUST be encoded as a "COSE Web Token (CWT)" object according to RFC8392. </del> <ins> The Referenced Token MAY be encoded as a "COSE Web Token (CWT)" object according to RFC8392 or other formats based on COSE. </ins> The following content applies to the CWT Claims Set:

Related discussion:
text: Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho
Code change:
This list MUST NOT be empty, as this would result in creating a signature over the empty string. <del> If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include "*created" and "*request-target" in the list. </del> <ins> Signers SHOULD include "*request-target" in the list. </ins> <del> If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include "date" and "*request-target" in the list. </del> <ins> Signers SHOULD include a date stamp, such as the "date" header or the "*created" field in the list. </ins> Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list

Related discussion:
text: removes algorithm specific rules for content identifiers Current layout is not backward compatible with http-signatures, so it's safe to do it.
The rules that restrict when the signer can or must include certain identifiers appear to be related to the pseudo-revving of the Cavage draft that happened when the algorithm was introduced. We should drop these rules, as it can be expected that anyone implementing this draft will support all content identifiers.
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 (see CORS-CHECK). </del> <ins> origin and passes the CORS check (see FETCH). </ins> 9.3.3.

Related discussion:
text: This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.
Code change:
stream.  RST_STREAM is sent to request cancellation of a stream or to indicate that an error condition has occurred. <del> The RST_STREAM frame contains a single unsigned, 32-bit integer identifying the ErrorCodes.  The error code indicates why the stream is being terminated. </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  Additionally, the RST_STREAM frame contains a single unsigned, 32-bit integer identifying the ErrorCodes.  The error code indicates why the stream is being terminated. </ins> The RST_STREAM frame does not define any flags.

Related discussion:
text: I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.
Code change:
2.1. <del> The ORIGIN frame has a nearly identical layout to that used in HTTP/2, restated here for clarity.  The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. </del> <ins> The ORIGIN frame has a layout that is nearly identical to the layout used in HTTP/2; the information is restated here for clarity.  The ORIGIN frame type is 0x0c (decimal 12), as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. </ins> An Origin-Entry is a length-delimited string.  Specifically, it contains two fields:

Related discussion:
text: This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.
Code change:
Return True. The "match" value is required and MUST be included in the Use-As- <del> Dictionary sf-dictionary for the dictionary to be considered valid. </del> <ins> Dictionary Dictionary for the dictionary to be considered valid. </ins> 2.1.2. <del> The "match-dest" value of the Use-As-Dictionary header is an inner list of sf-string values that provides a list of request destinations </del> <ins> The "match-dest" value of the Use-As-Dictionary header is an Inner List of String values that provides a list of request destinations </ins> for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination).

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:
2.2. The authorization server issues the registered client a client <del> identifier -- a unique string representing the registration </del> <ins> identifier - a unique string representing the registration </ins> information provided by the client.  The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication.  The client identifier is unique to

Related discussion:
text: uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL
Code change:
Due to implementation limitations, it might not be possible to fail TLS negotiation based on all of these requirements.  An endpoint MUST <del> terminate a HTTP/2 connection that is opened on a TLS session that </del> <ins> terminate an HTTP/2 connection that is opened on a TLS session that </ins> does not meet these minimum requirements with a ConnectionErrorHandler of type

Related discussion:
text: l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or
Code change:
algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. <del> "Digest" can be sent in a trailer section.  When using incremental digest-algorithms this allows the sender and the receiver to </del> <ins> "Digest" can be sent in a trailer section.  When an incremental digest-algorithms is used, the sender and the receiver can </ins> dynamically compute the digest value while streaming the content. <del> Two examples of its use are </del> 4. The "Want-Digest" field indicates the sender's desire to receive a

Related discussion:
text: This ended up being more changes than I first intended but I think most of them are uncontroversial and simply improve consistency through the document.
LGTM. Thanks NAME and Happy New Year!
Code change:
When there are multiple dictionaries that match a given request URL, the client MUST pick a single dictionary using the following rules: <del> 1.  For clients that support request destinations, a dictionary that specifies and matches a "match-dest" takes precedence over a match that does not use a destination.  1.  Given equivalent destination precedence, the dictionary with the longest "match" takes precedence. 1.  Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence. </del> <ins> For clients that support request destinations, a dictionary that specifies and matches a "match-dest" takes precedence over a match that does not use a destination. Given equivalent destination precedence, the dictionary with the longest "match" takes precedence. Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence. </ins> 2.3.

Related discussion:
text: This changes the maximum ZStandard compression window to be the larger of 8 MB and the size of the dictionary. This allows for clients to limit the maximum window size to as low as 8 MB if they like (by not advertising support) while also allowing for clients to use larger dictionaries with ZStandard than they would be able to if the global limit was 8 MB.
NAME and NAME could you also take a look and see if the language looks ok?
Context: URL aims to clarify the window size limit for the Content Encoding token as it wasn't clear in RFC8878. Since the Compression Dictionary Transport draft hasn't been published yet, we should also add some window size considerations to it for and to maintain interoperability. I think in Chrome we ended up using . NAME
NAME could you comment on how this impacts Brotli dictionary decode? Is the dictionary independent from the compression window (so we can adopt the same defaults as or do we need to specify something relative to the size of the dictionary? NAME NAME for ZStandard, to allow for delta-encoding large resources, is reasonable or should it be ? We have use cases for delta-encoding wasm applications where the dictionary can easily be upwards of 50 MB.
For Zstandard, the states that the entirety of the dictionary is accessible as long as the input is <= Window Size. Therefore, to give an extreme case, it's possible to have a 50 MB dictionary, and it's entirely accessible even if the Window Size is only 1 KB, but only as long as the data to de/compress is <= 1 KB. As soon as we reach 1 KB + 1, reaching the dictionary is no longer valid. For delta compression, this has consequences. Presuming the reference is ~50 MB, and the updated content is also ~50 MB, one would need a window size of ~50 MB to ensure access into the dictionary during the entire reconstruction process. But if the updated content is just a bit bigger, say ~51 MB, a ~50 MB window size would allow delta operation only during the first ~50 MB, the last ~1 MB would have to be compressed without dictionary. If follows that the size of the dictionary is irrelevant for the Window size. What matters is for how long one wants to access the dictionary while rebuilding the content.