jiebi/CodeConvo huggingface dataset:
Code change:
client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see header-field and h2-update-frame). When the client receives the first SETTINGS frame that contains the <del> SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending </del> <ins> SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending </ins> PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the

Related discussion:
text: RFC 7540 priorities are already deprecated.
That's the kind of thing I expect reviewers to question if we made a typo :) How about just changing the text to "using a setting to disable RFC 7540 priorities was inspired by I-D.lassey-priority-setting? Alternatively, we could just drop the mention altogther, although I think the context is useful.
"disable" WFM.
Proposed changes look good. In addition, I think we might want to change : For this case, maybe changing deprecate to depreciate would be the minimum required change.
Code change:
. <del> A server can only push responses that are cacheable (see RFC7234); promised requests MUST be safe (see RFC7231) and MUST NOT include a request body. </del> 8.2.1. Server push is semantically equivalent to a server responding to a

Related discussion:
text: I think the section could benefit from rearrangement some after this, but I'll leave that until later.
Once that's done, I'll have a look to see if there is anything that can be done to improve the section structure. The expanded material might need a new section heading and maybe some re-framing. Suggestions are, as always, very welcome.
I'll tweak this to soften the SHOULD and MAY.
Code change:
specification RFC8693 are also not used in Txn-Token responses.  The "expires_in" is not required since the issued token has an "exp" field, which indicates the token lifetime.  The "scope" field is <del> omitted from the request and therefore omitted in the response. </del> <ins> omitted from the response in favor of the "purp" claim in the Txn- Token. </ins> 9.2.

Related discussion:
text: Added text to address issue
The following text in 2.2.2 is too open ended and should be refactored. First, the text should include specific guidance on replacement tokens to require scopes to remain the same or be down-scoped on replacement. Second, the draft should include a mechanism to ensure that scopes cannot be increased, or an increase in scope can be detected by downstream services. Finally, add text to the security considerations section regarding the risks of replacement tokens and/or a malicious txn-token-sts.
As far as I understand it, replacement txn-tokens is just a profile to Token Exchange. The Token Exchange RFC defines that an issued token can only have the same or a smaller scope than the presented token. I would assume this applies to replacement tokens as well. If the replacement token mechanism is intended to deviate from Token Exchange in this regard, this should probably be mentioned specifically.
NAME please review PR and see if I addressed your comments.
Completed. Looks good to me.
LGTM.
Code change:
8. <del> TODO: fill out currently missing registries: * MOQT version numbers * SETUP parameters * Track Request parameters * Subscribe Error codes * Announce Error codes * Track format numbers * Message types * Object headers </del> <ins> TODO: fill out currently missing registries: MOQT version numbers SETUP parameters Track Request parameters Subscribe Error codes Announce Error codes Track format numbers Message types Object headers </ins> TODO: register the URI scheme and the ALPN

Related discussion:
text: Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Code change:
8. <del> TODO: fill out currently missing registries: * MOQT version numbers * SETUP parameters * Track Request parameters * Subscribe Error codes * Announce Error codes * Track format numbers * Message types * Object headers </del> <ins> TODO: fill out currently missing registries: MOQT version numbers SETUP parameters Track Request parameters Subscribe Error codes Announce Error codes Track format numbers Message types Object headers </ins> TODO: register the URI scheme and the ALPN

Related discussion:
text: Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.
Code change:
8. <del> TODO: fill out currently missing registries: * MOQT version numbers * SETUP parameters * Track Request parameters * Subscribe Error codes * Announce Error codes * Track format numbers * Message types * Object headers </del> <ins> TODO: fill out currently missing registries: MOQT version numbers SETUP parameters Track Request parameters Subscribe Error codes Announce Error codes Track format numbers Message types Object headers </ins> TODO: register the URI scheme and the ALPN

Related discussion:
text: Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review
Code change:
The authorization server MAY add, remove or change claims.  See transcribing-claims. <del> 2.3.4. </del> <ins> 2.3.3. </ins> The authorization grant format and content is part of a contract between the authorization servers.  To achieve a maintainable and

Related discussion:
text: parameter removed from token exchange request section as this is already specified in RFC8693 Resource/audience section merged into request section. added more author details
Code change:
framing, which describes whether the message is a request or response and how subsequent sections are formatted; see framing. <del> For a response, any number of interim responses, each consisting of an informational status code and header section. </del> <ins> For a response, any number of informational responses, each consisting of an informational status code and header section. </ins> Control data.  For a request, this contains the request method and target.  For a response, this contains the status code.

Related discussion:
text: Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm
Code change:
New CCs MUST evaluate the potential harm to other flows when the multiple paths share a common congested bottleneck (or share resources that are coupled between different paths, such as an <del> overall capacity limit), and SHOULD consider the fairness with other flows.  Synchronisation of CC mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated.  At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. </del> <ins> overall capacity limit), and SHOULD consider the potential for harm to other flows.  Synchronisation of CC mechanisms (e.g., where multiple flows change their behaviour on similar timeframes) can also contribute to harm and/or reduce fairness, these effects also ought to be evaluated.  At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet. </ins> 6.

Related discussion:
text: Maybe I am overly sensitive, but this way of discussing the issue feels dated, from a time when transport and congestion control where specified jointly. I think that ceased to be the case many years ago, for example with implementations of TCP providing choices between multiple congestion algorithms. (Indeed, DCCP itself provides a choice between two algorithms.) The Bis draft should probably present the issue differently.
Speaking of fairness, I also wonder if there is an accurate definition for it. There has been activity on the topic at the IETF (on in academia) : URL URL URL should this be discussed in the draft ?
Discussed at IETF 117: Matt: Replace fairness with freedom from starvation. Fairness only makes sense at low bandwidth. Christian: Not focus entirely at fairness, non-starvation goal is good. Gorry: Suggestion to put it in other draft, but not in this one Overall, get rid of it all together for now
In academia a next metric is to look at harm rather than fairness: URL
That's a pretty good reference, Mirja!
The reality is that Cubic has a horrific effect on the Internet: it is pretty efficient at building queues and making life terrible for others. The classic example is the parent busy on a video conference from home, and then seeing the perceived quality go down sharply because the teenager started downloading a movie... Which means I would take "fairness with Cubic" with a huge grain of salt. As is, yes, let it run and get some bandwidth, but make sure that it gets seriously penalized, so there is an incentive to replace it by something better...
A more serious problem is harm to tiny transactions using any protocol. They have to rely on timeouts for loss recovery. I suggest replacing this with absolute upper bounds on loss rates. E..g. see: URL Likewise for excessive standing queues, and to a lessor extent excessive CE marks.
Modulo the comments I've already posted, LGTMThe last changes by NAME probably mitigate my issues. I think we will have to come back to definition of harm and to the "self compete" part, but this is good enough for the next iteration of the draft.
Code change:
An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token.  This specification defines three <del> grant types -- authorization code, refresh token, and client credentials -- as well as an extensibility mechanism for defining </del> <ins> grant types - authorization code, refresh token, and client credentials - as well as an extensibility mechanism for defining </ins> additional types. 1.3.1.

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:
TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.) <del> 6.4.3. </del> 6.5. A SUBSCRIBE_OK control message is sent for successful subscriptions.

Related discussion:
text: Based on
Consider the following sequence of groups and objects, some already produced , some that will be produced in the future. The largest group ID is currently 23 and the largest object ID is 3 (it also happens to be the last object in the group). ! Our definitions for RelativePrevious and RelativeNext are shown here. Example 6.4.3.1 for 'now' shows In our example, largest group is 23, however Largest Object + 1 is 4, which does not exist. We need to adjust the definition of RelativeNext to allow for the fact that the next object may be in a different group. There may be some players who simply want the relay to send the next available Object, in this example Object 0 of group 24. There is no current way to reliably ask for this, because StartGroup mode cannot be 'none', and we don't know which group that object will belong to. It may be in the currently largest group, or it may be in the next group. A solution here would be to relax the constraint that StartGroup mode cannot be 'none'. If we then request it would instruct the relay "Send me your next object, no matter which group it belongs to". In 6.4.3 we have examples titled 'Now', 'Current', "previous" and 'Next". 'Now', 'Current' are synonymous to most readers. We need to better titles to illustrate what is actually being requested here. Additionally, "Previous' doesn't indicate whether we want the previous group, or previous object. Similarly for next.
Individual Comment: You are right that the example (and the text likely) don't show the full range of possibilities for what the next object will be. The intent was that Start = Prev/0, Next/0 will get you the next object, which could be any object in the current group greater than largest, or the first object in the next group. This is how my implementation handles it. I don't see a way to get only the next object in the current draft, however, because of the ambiguity you describe.
Code change:
TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.) <del> 6.4.3. </del> 6.5. A SUBSCRIBE_OK control message is sent for successful subscriptions.

Related discussion:
text: If I wanted to receive all objects in group N, I would issue: However the draft sneaks this restriction in, and it would actually be a protocol violation: It wasn't clear to me until chatting with Alan how you're supposed to do it: It's clarified in example 5, but I don't think this is obvious and it feels like an off-by-one. For example, if N was the last group in the broadcast, I can imagine some implementations incorrectly throwing an error or somehow mishandling it.
Individual Comment: This was discussed on the PR here: URL Given how subscribe locations work (end is exclusive), end=N+1/0 means "including through the end of group N". The question is whether we should have more than one way to do things, and defaults when values are not present.
Sorry, bad choice of word there. I meant that it's not immediately obvious why the restriction exists, and what it impacts.
Individual Review: I like removing relative options from subscribe. I don't love the group ID + 1 spelling, but I guess I can live with it. An alternative is to add 4 code points for SUBSCRIBE to indicate the presence/absence of start/end (SUBSCRIBE, SUBSCRIBEFROM, SUBSCRIBETO, SUBSCRIBE_RANGE).
Code change:
would cause the following values to be associated: <del> 12.1.3. </del> <ins> 12.5.2. </ins> The "Accept-Charset" header field can be sent by a user agent to indicate its preferences for charsets in textual response content.

Related discussion:
text: initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...
Code change:
protocols that do not have strong ordering guarantees across streams, like HTTP/3 HTTP3. <del> Multiple experiments from independent research (MARX, MEENAN) have shown that simpler schemes can reach at least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the web use case. </del> <ins> Experiments from independent research (MARX) have shown that simpler schemes can reach at least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the web use case. </ins> 2.1.

Related discussion:
text: I was noted that the citation to Pat Meenan's blog post lacked scientific experimental data and a decent permalink. Since we already acknowledge Pat's original scheme proposal in the acknowledgements, lets just remove this one. To avoid anyone picking up on a lack of multiple citations to match the multiple experiments statement, lets drop that qualifier too.
Makes sense. Thank you for the PR.
Code change:
is used to express a type: <del> 4.1.2.2. </del> <ins> 4.2.2.2. </ins> <del> The following are non-selectively disclosable registered JWT claims that SD-JWTs of VC-SD-JWTs contain for specific purposes: </del> <ins> VC-SD-JWTs MAY use any claim registered in the "JSON Web Token Claims" registry as defined in RFC7519. </ins> <del> The following are selectively disclosable registered JWT claims that SD-JWTs of VC-SD-JWTs contain for specific purposes: </del> <ins> If present, the following registered JWT claims MUST be included in the SD-JWT and MUST NOT be included in the Disclosures, i.e. cannot be selectively disclosed: </ins> <del> 4.2. </del> <ins> The following registered JWT claims MAY be contained in the SD-JWT or in the Disclosures and MAY be selectively disclosed: 4.2.2.3. Additional public claims MAY be used in the SD-JWT or in the Disclosures depending on the application. 4.3. </ins> The following is a non-normative example of a Credential acting as the input for the VC-SD-JWT:

Related discussion:
text: I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.
Code change:
Error code: "entryNotFound" <del> 2.1.4. </del> <ins> 2.2.4. </ins> <del> 2.1.4.1. </del> <ins> 2.2.4.1. </ins> <del> 2.1.4.2. </del> <ins> 2.2.4.2. </ins> One of the following:

Related discussion:
text: Strawman proposal for: URL PoC implementation here URL
Definite start in the right direction - I would say it is enough to get in and build on
general thumbs upLGTM After a chat with Richard Barnes, I think there are a few things happening with and key binding, that we should probably consider independently for scitt: Registration Policies that require fresh signatures from issuers. Registration Policies that require issuer's to commit to a recent tree head. Registration Policies that require additional context binding and a fresh signature from the issuer bound to special context. 1 and 2 are basically both about "time". If the Transparency Service does not trust the issuer to be honest about time, the transparency service can force the issuer to include a time commitment from the transparency service in their registration with binding to their confirmation public key. In the case the "nonce" is a timestamp, the TS rejects key binding tokens that are outside some window. In the case the "nonce" is a recent tree head, the TS rejects key binding tokens that are not to a tree head inside some window. In the case the "nonce" is a "challenge token", the nonce is some special context, the TS rejects key binding tokens that lack this special context. There is an opportunity to make the registration none interactive and one shot, assuming the following is acceptable: The key binding token nonce is a "recent timestamp / tree head" The transparency service rejects key binding tokens with nonces that are not "recent" There is an opportunity to make the registration interactive and context binding, assuming the following is acceptable: The transparency service includes specific context the issuer must commit to in their "challenge token". The issuer uses the challenge token as the nonce in their key binding token. The transparency service rejects key binding tokens with nonces that omit required context In this second case, imagine a "dynamic registration policy" Holder (Issuer) asks Verifier (Transparency Service) for a challenge token for a Customs Entry for 16056100.