jiebi/CodeConvo huggingface dataset:
Code change:
The error may contain additional information to guide the Client on what information to collect next.  This pattern of collecting information, submitting it to the Authorization Challenge Endpoint <del> and then receing an error or authroization code may repeat several </del> <ins> and then receing an error or authorization code may repeat several </ins> times. (D) The client gathers additional information (e.g. passkey, or

Related discussion:
text: Included use cases for OTP, e-mail, SMS confirmation, step-up authentication and registration. Also see and
Code change:
absent from a request, it can only match another request if it is also absent there. <del> A </del> <ins> A stored response with a </ins> header field value containing a member "*" always fails to match.

Related discussion:
text: replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...
Code change:
length "HASH_SIZE". "leaf_info": auxiliary inputs to recompute the leaf digest <del> included in the Merkle tree: the internal hash, the internal data, and the protected header of the countersigner. </del> <ins> included in the Merkle tree: the internal hash and the internal data. </ins> "internal_hash" MUST be a bytestring of length "HASH_SIZE";

Related discussion:
text: Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.
Code change:
information in its signature context to account for the change in authority, this practice requires additional configuration and extra care (see further discussion in security-context-multiple- <del> signatures).  To counter this, the proxy adds its own signature over the new message before passing it along.  The proxy includes the new "@authority" derived component and the Forwarded header, which it added to the message.  The proxy's signature also includes the client's signature value from the original message in its covered components, as a dictionary field member under the label "sig1". Note that since the client's signature already covers the client's Signature-Input value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  While the origin server may not be able to directly verify this original signature, it can verify that the proxy has vouched for the signature's validity.  The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </del> <ins> signatures).  The proxy is in a position to make its own statement to the origin server about the nature of the request that it is forwarding by adding its own signature over the new message before passing it along to the origin server.  The proxy includes the new "@authority" derived component and the Forwarded header, which the proxy has added to the message.  The proxy also includes elements from the original message that are relevant to the origin server's processing, such as the "@method", "@path", and "@query" in this example, even if those components were covered by the original signature.  The proxy additionally includes the client's signature value and signature input from the original message in the new signature's covered components.  In our example application, this is used as a way for the proxy to indicate to the origin server that the proxy has read and verified these values in their original context. While the origin server may not be able to directly verify this original signature, it can verify that the proxy has vouched for the signature's validity.  The origin server also has assurance that the message has been forwarded intact from the trusted proxy. The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </ins> And a signature output value of:

Related discussion:
text: A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?
Code change:
The criteria in evaluation-criteria will be evaluated in the following scenarios.  Unless a proposed congestion control specification explicitly forbids use on the public Internet, the <del> community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. </del> <ins> community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. </ins> The evaluation in each scenario SHOULD occur over a representative range of bandwidths, delays, and queue depths.  Of course, the set of

Related discussion:
text: All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.
Code change:
value MUST be a case-sensitive (see RFC7519) value serving as an identifier for the type of the SD- <del> JWT VC.  A type defines which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any </del> <ins> JWT VC.  The value MUST be a Collision-Resistant Name as defined in Section 2 of RFC7515. A type is associated with rules defining which claims may or must appear in the Unsecured Payload of the SD-JWT VC and whether they may, must, or must not be selectively disclosable.  This specification does not define any </ins> values; instead it is expected that ecosystems using SD-JWT VCs define such values including the semantics of the respective claims

Related discussion:
text: Type identifiers MUST be collision-resistant names as defined in RFC7515 Changed the example to a URI
Code change:
There are some existing methods by which an unrecognized client can make use of an authorization server, such as using Dynamic Client <del> Registration RFC7591, to register the client prior to initiating the </del> <ins> Registration RFC7591 to register the client prior to initiating the </ins> authorization flow.  Future extensions might define alternatives, such as using URLs to identify clients.

Related discussion:
text: Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.
Code change:
Abstract This specification defines status list data structures for <del> representing the status of JSON Web Tokens (JWTs) RFC7519 and CBOR Web Tokens (CWTs) RFC8392.  The status list data structures </del> <ins> representing the status of JSON Web Tokens (JWTs) RFC7519, CBOR Web Tokens (CWTs) RFC8392, and other tokens secured by CBOR Object Signing and Encryption _8152.  The status list data structures </ins> themselves are also represented as JWTs or CWTs. 1. <del> JSON Web Tokens (JWTs) RFC7519 and CBOR Web Tokens (CWTs) RFC8392 as secure token formats, have vast possible applications.  Some of these </del> <ins> JSON Web Tokens (JWTs) RFC7519, CBOR Object Signing and Encryption (COSE) _8152 objects, and CBOR Web Tokens (CWTs) RFC8392 as secure token formats, have vast possible applications.  Some of these </ins> applications can involve issuing a token whereby certain semantics about the token can change over time, which are important to be able to communicate to relying parties in an interoperable manner, such as

Related discussion:
text: This PR adds: CBOR/CWT encoding for status list and status list info Example implementation for CBOR/CWT Not included yet: examples for referenced tokens (COSE, CWT) but that should be trivial to add. URL
The decoded cbor is: The list does not seem to be valid zlib.
I've tried with cyberchef and it seems to work for me: -> zlib inflate =
You are right, I probably tried on the hexstring :D
I assume there will be a lot of comments. I had some troubles with the claim language for non-CWTs btw. Please review and give feedback. NAME NAME NAME
I was wondering whether it would be better to define a CDDL for Status, StatusList and StatusListInfo. Basically, having a high-level CDDl description of all objects and then having some specific sections for JWT, COSE, CWT that define how they are used in the corresponding objects.
Also keep in mind that claim for CWT will require IANA to assign us an integer number, so we can use it in the CWT.
There is a problem with the width of the CBOR diagnostic notation examples. The datatracker only allows a width of 72, but cborg defaults to 100 and apparently can't be configured in CLI mode.
I can write a small JS script that uses the cborg library and configures the width to 72. Would this be even possible? I didn't check by myself.
Yes that would be possible and is the only option I have found so far. I was searching for a pure python solution (which would be cleaner imho) but that seems to be not possible right now.
The abstract, intro, diagrams wrt referenced tokens description should refer to COSE and JOSE instead of CWT/JWT. Otherwise, non-CWT COSE objects such as ISO 18013-5 MSO cannot use this spec. Same applies to SD-JWT VC encoded secured using JWS.
We adjusted the terminology already, but the text in the introduction is not matching yet.
Code change:
Abstract This specification defines status list data structures for <del> representing the status of JSON Web Tokens (JWTs) RFC7519 and CBOR Web Tokens (CWTs) RFC8392.  The status list data structures </del> <ins> representing the status of JSON Web Tokens (JWTs) RFC7519, CBOR Web Tokens (CWTs) RFC8392, and other tokens secured by CBOR Object Signing and Encryption _8152.  The status list data structures </ins> themselves are also represented as JWTs or CWTs. 1. <del> JSON Web Tokens (JWTs) RFC7519 and CBOR Web Tokens (CWTs) RFC8392 as secure token formats, have vast possible applications.  Some of these </del> <ins> JSON Web Tokens (JWTs) RFC7519, CBOR Object Signing and Encryption (COSE) _8152 objects, and CBOR Web Tokens (CWTs) RFC8392 as secure token formats, have vast possible applications.  Some of these </ins> applications can involve issuing a token whereby certain semantics about the token can change over time, which are important to be able to communicate to relying parties in an interoperable manner, such as

Related discussion:
text: In fact COSE is already mentioned at all places, so the question is whether we should align things and say Referenced Token = JOSE/COSE-based
Use reference to RFC9052 instead of RFC8152
As described in the title, detail the CWT representation of the status list which is complementary to the JWT representation.
Maybe a naive question but what's the motivation for this draft having the two representations? When positioned as a companion of the SD-JWT VC draft and aiming for the OAuth WG, it seems like keeping the scope tighter and only having the JWT representation would be sufficient/okay/preferable.
NAME credential formats like mDocs do not have a status/revocation mechanism hence a CWT based representation is beneficial to these applications as they dont typically have JWT support.
I dunno, I'm not convinced that necessitates having multiple status list token representations. Especially in one draft. This draft, which again is being positioned as a companion to the SD-JWT VC. I suspect the work would be more palatable for adoption with a scope that's reflective of that. But maybe that's just me. Thanks for the context.
Code change:
signal that might be useful to nodes behind the server that the client is directly connected to. <del> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. Where both endpoints disable RFC 7540 stream priority, the client is expected to send this scheme's priority signal.  Handling of omitted signals is described in parameters. </del> 3. The priority scheme defined by this document considers only the

Related discussion:
text: The context here is that the document defines independent elements a) the means to deprecate RFC 7540 stream priority using a setting b) the extensible priorities scheme. This text removes conflating those elements and making it appear that Extensible priorities is mandatory. Where someone chooses to use Extensible priorities (good choice!) there is some specific guidance about how to process settings and inform signal setting.
Above, you indicate any scheme can be used, with this being just one option. This does make guidance about PRIOUPDATE frames/header field more difficult later, so maybe some other textual adjustment is needed earlier: e.g., for the remainder of this text ,we assume the use of the scheme defined in this document as the alternate Or, move the following text from below up and adjust a bit send this scheme's priority signal Originally posted by NAME in URL
The text isn't amazingly clear if endpoints have to use Extensible priority when they explicitly disable H2 priority. I suggest we state they do. If anyone really wants to invent a new scheme, they will need to deal with negotiation.
Yeah I see two somewhat contradicting statements: Endpoints are expected to use an alternative, such as the scheme defined in this specification. Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see Section 5 and Section 7.1). I would argue that the former is precise, and that the latter is a bit misleading in recommending endpoints send Extensible Priorities rather than any alternative to H2 priorities. The rationale is as follows. In principle, negotiation is a hop-by-hop mechanism and therefore cannot be used for negotiating the use of an end-to-end signal, which includes the header-field variant of Extensible Priorities. To paraphrase, in a world where end-to-end signals are used for prioritization, multiple signals are expected to co-exist. IMO, SETTINGSDEPRECATERFC7540_PRIORITIES is no more than an optimization, that allows clients to conserve bandwidth (by omitting the PRIORITY frames), servers to reduce complexity (by ignoring PRIORITY frames being received). These benefits are stated correctly in the section.
Thanks Kazuho. I tend to agree. The thing I also wanted to avoid is endpoints disabling RFC 7550 stream priority and then not providing any suitable replacement by accident.
Code change:
signal that might be useful to nodes behind the server that the client is directly connected to. <del> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. Where both endpoints disable RFC 7540 stream priority, the client is expected to send this scheme's priority signal.  Handling of omitted signals is described in parameters. </del> 3. The priority scheme defined by this document considers only the

Related discussion:
text: I think there is agreement that not doing scheduling is pretty bad. But we also highlight that other inputs, beyond this scheme and beyond anything that would be standardised are fine to use too. I'm getting an idea of how we could change the text to address the points made on this issue.
Reading again the current text send this scheme's priority signal. Handling of omitted signals is described in {{parameters}}. This is effectively a differently worded restatement of the guidance for implementers of Extensible Priorities receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values were specified. That is, imagine both endpoints send SETTINGSDEPRECATERFC7540PRIORITIES and a client wants the default prioritization for a request (u=3,i). It can omit the Priority header field and have some expectation that a server implementing Extensible priorities will interpret that as a signal to apply the default. The simple action here is to make SETTINGSDEPRECATERFC7540PRIORITIES independent from any advice to use a specific alternative.
LGTM. I like how you've split the section.
Code change:
the request will have the same intended effect, even if the original request succeeded, though the response might differ. <ins> A user agent MUST NOT automatically retry a request with a non- idempotent method unless it has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied.  For example, a user agent that knows (through design or configuration) that a POST request to a given resource is safe can repeat that request automatically.  Likewise, a user agent designed specifically to operate on a version control repository might be able to recover from partial failure conditions by checking the target resource revision(s) after a failed connection, reverting or fixing any changes that were partially applied, and then automatically retrying the requests that failed. A proxy MUST NOT automatically retry non-idempotent requests. A client SHOULD NOT automatically retry a failed automatic retry. </ins> 7.2.3. Request methods can be defined as "

Related discussion:
text: …se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.
Code change:
catalog object SHOULD only be published only when the availability of tracks changes. <del> Each catalog update MUST be mapped to a discreet moq-transport object. </del> <ins> Each catalog update MUST be mapped to a discreet MOQT Object. </ins> 5. <del> The MOQT Groups and MOQT Objects need to be mapped to moq-transport Streams.  Irrespective of the packagingmode in place, each MOQT Object MUST be mapped to a new moq-transport Stream. </del> <ins> The MOQT Groups and MOQT Objects need to be mapped to MOQT Streams. Irrespective of the mediapackaging in place, each MOQT Object MUST be mapped to a new MOQT Stream. </ins> 6.

Related discussion:
text: The current version of WARP only references CMAF packaging and does not make it clear that WARP is also intended to support LOC (Low Overhaded Container) packaging. LOC is defined by URL Currently the LOC spec defines both a streaming format and a packaging format. Reference for packaging will therefore need to be made to specific subsections of that draft. In the future if LOC packaging is separated from LOC streaming format, then the WARP references can be updated.
Code change:
[1] https://openjdk.java.net/groups/net/httpclient/intro.html <del> [2] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ V1_chap04.html#tag_04_16 [3] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </del> <ins> [2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </ins> V1_chap04.html#tag_04_16

Related discussion:
text: reuses existing definitions for S-F and Unix time.
Doesn't make this PR redundant? (or regressive, really, because references the exact definitions to use - and from structured headers)
This probably