jiebi/CodeConvo huggingface dataset:
Code change:
Parsers MUST support Tokens with at least 512 characters. <ins> Note that Tokens are defined largely for compatibility with the data model of existing HTTP fields, and may require additional steps to use in some implementations.  As a result, new fields are encouraged to use Strings. </ins> 3.3.5. Byte Sequences can be conveyed in Structured Fields.

Related discussion:
text: Just if the best practice we pick does not align with the data model we picked, we have done something seriously wrong.
We already have best practice about Display Strings in the spec (in that we steer people away from them if they don't need them). We have a separation between Tokens and Strings because they were visible on the wire in pre-existing headers, and we wanted to be able to retrofit / 'pave the cowpaths'. In some cases, they are interchangeable; in others, they are not. I suspect that if we documented best practice for new fields, we'd say "probably use Strings most of the time" because of the underlying reason I raised this issue for -- APIs have very natural mappings for Strings, but for Tokens you probably need some sort of wrapper object or equivalent strategy, so that you can distinguish them from Strings. I'll put together a PR nudging people that way.
Sounds good! So I guess the decision tree is then: Do you need display strings? If yes, use that and only that. Do you have a legacy reason to use tokens? If use, do whatever your legacy reasons need. Otherwise, just use ASCII strings.
Code change:
The stub router may receive a router advertisement containing one or more suitable on-link prefixes on the AIL.  If any of these prefixes are different than the prefix the stub router is advertising as the <del> on-link suitable prefix, and the Stub Router flag is not set in in the Router Advertisement flags field, the stub router moves the </del> <ins> on-link suitable prefix, and the 'Stub Router' flag bit is not set in in the Router Advertisement flags field, the stub router moves the </ins> interface to STATE-DEPRECATING (state-deprecating). <del> If the stub router bit is set in the RA header flags field, then one of the following must be true in order for that prefix to be </del> <ins> If the 'Stub Router' flag bit is set in the RA header flags field, then one of the following must be true in order for that prefix to be </ins> considered suitable: 5.1.2.5.

Related discussion:
text: Flag bits can be referred to as "bit", "flag", or "flag bit". This issue is an editorial reminder to update to a consistent term later on. E.g. "flag" or "flag bit" is most clear I think.
Assigning to myself, to make a PR later on. Everyone and NAME feel free to suggest preferred term. I find "flag bit" the most clear.
Code change:
is important to note that transparency logs might include sensitive information. <del> Depending on the leaf algorithm used, a log operator might be able to count unique entries. </del> <ins> Depending on the verifiable data structure used, a service provider might be able to count unique entries. </ins> <del> In the case that a leaf is produced from a cose sign 1 envelope, </del> <ins> In the case that an entry is produced from a cose sign 1 envelope, </ins> adding information to the unprotected header can be used to produce a <del> unique leaf entry. </del> <ins> unique entry. </ins> However, this could impact privacy, and some transparency service operators might prefer only integrity protected content be made

Related discussion:
text: This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions
Code change:
Abstract This document extends the OAuth 2.0 Authorization Framework RFC6749 <del> with new grant types to support first-party native applications that want to control the user experience of the process of obtaining authorization from the user. </del> <ins> with a new endpoint "authorization_challenge_endpoint" to support first-party native applications that want to control the process of obtaining authorization from the user using a native experience. </ins> In many cases, this can provide an entirely browserless experience suited for native applications, only delegating to the browser in

Related discussion:
text: I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.
Code change:
7.2.3. <del> Request methods can be defined as " " to indicate that responses to them are allowed to be stored for future reuse; for specific requirements see Caching.  In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD. </del> <ins> For a cache to store and use a response, the associated method needs to explicitly allow caching, and detail under what conditions a response can be used to satisfy subsequent requests; a method definition which does not do so cannot be cached.  For additional requirements see Caching. This specification defines caching semantics for GET, HEAD, and POST, although the overwhelming majority of cache implementations only support GET and HEAD. </ins> 7.3.

Related discussion:
text: HTTP Methods have 3 boolean properties, all of which says a registration needs to define, but only "Safe" and "Idempotent" were included in the registry while "Cacheable" was omitted. I filed this as URL, but it probably makes more sense as a change for ter.
I think the only concern I have here is that people often misinterpret "cacheable" - e.g., see .
FWIW, that's because it isn't a boolean property of the method, but rather a capability inherent in the system in which one aspect is the method semantics. I'd prefer to remove that from the registration table. We could still require that the registration describe how and under what conditions the method semantics might be cacheable.
It's not in the registration table, and I tend to agree it should be kept out for the reasons above.
This was discussed regarding Variants, and I think the answer will be the same; we should record this sort of thing in documentation elsewhere, e.g., the .
URL says but then the method definitions themselves seem to consistently say After this discussion, I think the method definitions ("The response is cacheable") are more correct, and that therefore my initial suggestion in this erratum is incorrect. URL repeats the less-correct form by listing "cacheable" along with "safe" and "idempotent" as properties of the method. I think removing "cacheable" from that list, and changing "If the new method is cacheable, ..." to something like would have prevented me from getting confused enough to file this issue. Do the experts here like that direction?
Note that RFC7540 Section 8.2 relies on that distinction by saying that pushed requests MUST be cacheable in order to be pushed, but conditionally defines what happens if the delivered response does turn out to be cacheable. Eliminating the distinction entirely would leave 7540 slightly unmoored.
I think the proposed edit to considerations for new methods is helpful; we could address the 7540 concern by parenthetically adding "also known as cacheable methods" or similar. Note also the first bullet of . If we can come up with a better phrase than "defined as cacheable" that's great, but it needs to be distinct from response cacheability.
Code change:
7.2.3. <del> Request methods can be defined as " " to indicate that responses to them are allowed to be stored for future reuse; for specific requirements see Caching.  In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD. </del> <ins> For a cache to store and use a response, the associated method needs to explicitly allow caching, and detail under what conditions a response can be used to satisfy subsequent requests; a method definition which does not do so cannot be cached.  For additional requirements see Caching. This specification defines caching semantics for GET, HEAD, and POST, although the overwhelming majority of cache implementations only support GET and HEAD. </ins> 7.3.

Related discussion:
text: ietf104: mark needs to research the 7540 question to determine if this can be made editorial based on jyasskin's above comment
7540 points directly to 723x for this, so we have some leeway. I think we can address this by parenthetically stating that a method that does not define the conditions under which it can be used by a cache is by definition not cacheable. Will do a PR.
Looks good to me.
Code change:
MUST NOT forward fields that contain any of the values that are listed as prohibited above. <del> Field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed except as defined by the processing rules for the field. </del> <ins> A recipient MAY treat a message that contains a field name or value that includes other characters disallowed by HTTP and HTTP as malformed. When a request message violates one of the requirements above, it SHOULD be responded to using the 400 (Bad Request) status code HTTP before the stream is reset, unless a more suitable status code is defined, or the status code cannot be sent (e.g., because the error occurs in a trailer field). Note that field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed; the requirements above only apply to the generic syntax for field values as defined in HTTP. </ins> 8.1.2.1.

Related discussion:
text: See as an alternative.
Thanks everyone for your patience here. It's good to see this work out :)
Validating fields for characters has raised a concern where we don't have a clear delineation between framing and semantics. So the way that endpoints handle those cases is unclear. For requests in particular, the choice between resetting a stream and sending a 4xx response is unclear. It would be good if we could have more consistent overall behaviour here, but we have seen from the character composition issue (see ) that different implementations will enforce the rules at different layers. We probably need to allow for some flexibility. NAME has volunteered to help us navigate this somewhat nuanced issue.
I think this is reasonable. LGTM
Code change:
HeaderBlock. The HEADERS frame can include padding.  Padding fields and flags are <del> identical to those defined for DATA. </del> <ins> identical to those defined for DATA.  Padding that exceeds the size remaining for the header block fragment MUST be treated as a . </ins> Prioritization information in a HEADERS frame is logically equivalent to a separate

Related discussion:
text: LGTM
Merged by RFC editor.
This wasn't obvious, but all descriptions of padding reference DATA: However, this is subtly wrong, as NAME notes. The actual text should be:
Code change:
3.3. <del> An item is can be a integer (integer), decimal (decimal), string </del> <ins> An item can be a integer (integer), decimal (decimal), string </ins> (string), token (token), byte sequence (binary), or Boolean (boolean).  It can have associated parameters (param).

Related discussion:
text: Small editorial fix. I'm also not comfortable with "a integer", maybe remove "a"? Anyway that's a nitpick.
Thanks NAME
LGTM
Code change:
8.5. Digest fields may expose details of encrypted payload when the <del> checksum is computed on the unencrypted data.  For example, the use of the "id-sha-256" digest-algorithm in conjunction with the encrypted content-coding RFC8188. </del> <ins> checksum is computed on the unencrypted data. </ins> The checksum of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases

Related discussion:
text: strip out id-* algorithms from this specid- are complex to address in this document they will be better addressed in URL
Fix typo. Thx NAME I'll wait a couple of days to allow further feedback :)
LGTM modulo the comment I made
Code change:
priority in every stream or datagram header.  As such, the subscriber's priority is a property of the subscription and the original publisher's priority is a property of the Track and the <del> Objects it contains.  In both cases, a lower value indicates a higher </del> <ins> Peeps it contains.  In both cases, a lower value indicates a higher </ins> priority, with 0 being the highest priority. The Subscriber Priority is considered first when selecting a

Related discussion:
text: I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments
Code change:
operating congestion controls. For these reasons, data center congestion controls are often distinct <del> from those running elsewhere on the Interenet.  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </del> <ins> from those running elsewhere on the Interenet (see controlled- environments).  A proposed congestion control need not coexist well with all other algorithms if it is intended for data centers, but the proposal SHOULD indicate which are expected to safely coexist with it. </ins> 7.

Related discussion:
text: Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"
Code change:
12.4. <del> This memo updates the "CRC32c" digest algorithm in the HTTP Digest </del> <ins> This memo updates the "CRC32c" digest-algorithm in the HTTP Digest </ins> Algorithm Values [6] registry: Digest Algorithm: CRC32c

Related discussion:
text: is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.
Code change:
applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see cache-response-directive). <del> A cache MUST NOT send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path) or doing so is explicitly allowed (e.g., by the max- stale request directive; see cache-request-directive). </del> <ins> A cache MUST NOT send stale responses unless it is disconnected or doing so is explicitly allowed (e.g., by the max-stale request directive; see cache-request-directive). </ins> 4.3.

Related discussion:
text: For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.
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: Issue Add normative requirement for device binding of auth session and require the authorization server to enforce it.
Should we prohibit the auth_session from moving off-device to avoid resumption of the session on another device (avoid risks of session theft or session take-over).
auth_session is expected to be device bound
Discussion Add statement that authorization sessions are device bounds. Make it Normative in spec.
Resolved in
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: Proposed update based on feedback in issue Open question for reviewers (and NAME whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpopjkt) or an authorization challenge endpoint specific one?
Commented over in URL that I think the single method of the DPoP proof header is sufficient and preferred.
I would tend to agree that we should stick with only the header option for DPoP.
I'm good with that. Will create a PR to reflect this.
NAME and NAME I made the changes. please review and feel free to merge if ready.
Because the client interacts directly with the Authorization Challenge Endpoint the authorization code binding can and probably should be done via the DPoP proof rather than the dpop_jkt parameter. This is similar to what but here you could probably get away with just using the DPoP proof.
That makes sense, we should do it the same way that's recommended for PAR.
NAME I was reading the rationale for requiring both the dpopjkt parameter and adding the DPoP header to the PAR request: URL It looks like the goal was to keep client libraries simple so that they don't need to distinguish between PAR or front channel flows. If we remove dpopjkt, do we make it harder for implementors of client libraries? Given that this is a new end-point (Authorization Challenge Endpoint) and a native client, we may not need to keep support for both and we can be more prescriptive, but I wonder if we might cause confusion for implementors as we have established dpopjkt as the least common denominator (the reason for allowing it to be used with PAR end points). Perhaps we should have similar guidance to DPoP on supporting both dpopjkt and allowing the DPoP Header to be added to the Authorization Challenge Response? I guess the question is really if we settle dpop_jkt as a the least common denominator in all DPoP impementations?
I think the in PAR was more about keeping the commonalty of authz request parameters and their treatment on both sides. Not so much about being a least common denominator. I think this Authorization Challenge Endpoint is different enough that just using the DPoP proof is the way to go.