jiebi/CodeConvo huggingface dataset:
Code change:
6.1. <del> The Issuer is using the following input JWT Claims Set: </del> <ins> The following data about the user comprises the input JWT Claims Set used by the Issuer: </ins> <del> The Issuer in this case made the following decisions: </del> <ins> In this example, the following decisions were made by the Issuer in constructing the SD-JWT: </ins> The following payload is used for the SD-JWT: <del> The following Disclosures are created by the Issuer: </del> <ins> The respective Disclosures are created by the Issuer: </ins> <del> The payload is then signed by the Issuer to create the following JWT: </del> <ins> The payload is then signed by the Issuer to create the following Issuer-signed JWT: </ins> <del> The following is the issued SD-JWT: </del> <ins> Adding the Disclosures produces the SD-JWT: </ins> 6.2.

Related discussion:
text: Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw.
Code change:
6.1. <del> The Issuer is using the following input JWT Claims Set: </del> <ins> The following data about the user comprises the input JWT Claims Set used by the Issuer: </ins> <del> The Issuer in this case made the following decisions: </del> <ins> In this example, the following decisions were made by the Issuer in constructing the SD-JWT: </ins> The following payload is used for the SD-JWT: <del> The following Disclosures are created by the Issuer: </del> <ins> The respective Disclosures are created by the Issuer: </ins> <del> The payload is then signed by the Issuer to create the following JWT: </del> <ins> The payload is then signed by the Issuer to create the following Issuer-signed JWT: </ins> <del> The following is the issued SD-JWT: </del> <ins> Adding the Disclosures produces the SD-JWT: </ins> 6.2.

Related discussion:
text: if you call it processed payload, that is fine by me but it should be added to 8.1.
+ 1000000000% !
Defining terms is good. Dehydrated/hydrated would be bad. ;-)
PR URL has a small addition to sec 8.1 for this
agree to common law definition
Code change:
6.1. <del> The Issuer is using the following input JWT Claims Set: </del> <ins> The following data about the user comprises the input JWT Claims Set used by the Issuer: </ins> <del> The Issuer in this case made the following decisions: </del> <ins> In this example, the following decisions were made by the Issuer in constructing the SD-JWT: </ins> The following payload is used for the SD-JWT: <del> The following Disclosures are created by the Issuer: </del> <ins> The respective Disclosures are created by the Issuer: </ins> <del> The payload is then signed by the Issuer to create the following JWT: </del> <ins> The payload is then signed by the Issuer to create the following Issuer-signed JWT: </ins> <del> The following is the issued SD-JWT: </del> <ins> Adding the Disclosures produces the SD-JWT: </ins> 6.2.

Related discussion:
text: resolves URL which is really based on URL
some of URL likely applies here too
Notes on section 6: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere in this section
notes on appendix: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere after URL say more about the input JWT Claims Set URL use the processed SD-JWT payload name URL say more about the input JWT Claims Set URL names URL input URL name
Code change:
8.1. <del> IF APPROVED, IANA is requested to add the following entry to the HTTP Upgrade Token Registry: Value: "connect-tcp" Description: Proxying of TCP payloads Reference: (This document) </del> <ins> IF APPROVED, IANA is requested to add the following entries to the HTTP Upgrade Token Registry: </ins> For interoperability testing of this draft version, implementations <del> SHALL use the value "connect-tcp-05". </del> <ins> SHALL use the values "connect-tcp-06" and "connect-tcp-capsule-06. </ins> 8.2.

Related discussion:
text: We started this discussion in the comments of but it deserves its own issue. Now that has landed, capsule support is mandatory for servers but clients can decide whether or not to use it by sending the header. Another way forward would be to just say that connect-tcp always uses capsules. Some reasons why: it simplifies server implementations it simplifies client implementations that want capsules it would be consistent with every other that uses capsules it avoids reusing to mean something different from what was intended in RFC 9297 Since I don't see any real-world reason to use without capsules, this sounds like the best path forward to me cc NAME NAME NAME
I'm sympathetic to the argument that there may be cases where someone wants templates tcp without the overhead of capsules. So how about we move the capsule negotiation to the upgrade token? I.e. one token if you want capsules, another if you don't. Then it makes the use of capsule-protocol header more consistent with how it's already used in other connect-foo docs.
That's a good compromise. That allows me to only implement the upgrade token that enables capsules and not have to deal with the complexity of negotiation. Another option would be to say that if then the capsule extends to the end of the stream. That works because stream offsets only go to UINT64_MAX so that length cannot ever be valid. It's a shame we didn't do that in 9297 though
I think this approach works for the sender to indicate its disinterest to use capsules. But it does not allow the receiver to refuse use of capsules by the sender. By saying using connect-tcp without capsules, I think we are referring to endpoints that do not want to implement capsule support at neither send-side or receive-side. Assuming that is the case, I think using different upgrade token is the way to go, if somebody asks for connect-tcp without capsules.
OK, PR up: URL Please review.
WfmThanks!
Code change:
more than one Peep and the priority varies between these Peeps, higher priority Peeps are sent before lower priority Peeps.  If the specified priority of two Peeps in a Group are equal, the lower Peep <del> ID has priority.  Within a Peep, Objects MUST bs sent in increasing </del> <ins> ID has priority.  Within a Peep, Objects MUST be sent in increasing </ins> Object ID order. The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and

Related discussion:
text: Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?
Code change:
utilized the per-flow available bandwidth, and sets both BBR.full_bw_now and BBR.full_bw_reached to true. <del> Upon starting a full pipe detection process, the following initialization runs: </del> <ins> Upon starting a full pipe detection process (either on startup or when probing for an increase in bandwidth), the following steps are taken: </ins> While running the full pipe detection process, upon an ACK that acknowledges new data, and when the delivery rate sample is not application-limited (see delivery-rate-samples), BBR runs the "full pipe" estimator: <del> BBR waits three rounds to have solid evidence that the sender is not detecting a delivery-rate plateau that was temporarily imposed by the receive window.  Allowing three rounds provides time for the receiver's receive-window auto-tuning to open up the receive window and for the BBR sender to realize that BBR.max_bw should be higher: in the first round the receive-window auto-tuning algorithm grows the receive window; in the second round the sender fills the higher receive window; in the third round the sender gets higher delivery- rate samples.  This three-round threshold was validated by YouTube experimental data. </del> <ins> BBR waits three packet-timed round trips to have reasonable evidence that the sender is not detecting a delivery-rate plateau that was temporarily imposed by congestion or receive-window auto-tuning. This three-round threshold was validated by experimental data to allow the receiver the chance to grow its receive window. </ins> 4.3.1.3.

Related discussion:
text: Minor clarifications to the prose Removes explicit references to Youtube
I am going to redo this on top of the markdown version. cc NAME NAME
Thanks, this 4-commit version with purely editorial changes looks great to merge now. Thanks!
Text LG, but we should decide if we want to impose the line limits I've seen in other Github IETF projects.
Code change:
response to indicate successful completion of the request. <del> An origin server SHOULD ignore unrecognized header and trailer fields received in a PUT request (i.e., do not save them as part of the resource state). </del> An origin server SHOULD verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or will not be changed by the PUT.  This is

Related discussion:
text: As discussed on call, we need to say that PUT requests can contain response headers, and what that means.
Code change:
The following is a non-normative example of a decoded SD-JWT header: <ins> Note that this draft used as the value of the header from its inception in July 2023 until November 2024 when it was changed to to avoid conflict with the media type name registered by the W3C's Verifiable Credentials Data Model draft.  In order to facilitate a minimally disruptive transition, it is RECOMMENDED that Verifiers and Holders accept both and as the value of the header for a reasonable transitional period. </ins> 3.2.2. This section defines the claims that can be included in the payload

Related discussion:
text: Update the anticipated media type registration request from to per the Dublin Accord (last slide of URL)
Code change:
proxy-revalidate (cache directive) public (cache directive) <del> R Response is Stale (warn-text) Revalidation Failed (warn-text) </del> S s-maxage (cache directive) shared cache stale strong validator <del> T Transformation Applied (warn-text) </del> V validator

Related discussion:
text: I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
Code change:
learn what range the server has currently available and initiate an indeterminate-length transfer.  For example: <del> With the Content-Range response header indicating the (or ranges) available.  For example: </del> <ins> With the Content-Range response header field indicating the (or ranges) available.  For example: </ins> The client can then issue a request for a range starting at the end value (using a very large value for the end of a range) and receive

Related discussion:
text: Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03
Code change:
SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459. <del> Reference: [FIPS-180-3], RFC4648, this document. </del> <ins> Reference: FIPS180-3, RFC4648, this document. </ins> Status: obsoleted

Related discussion:
text: fixes typo in reference
FYI, there is (at least) a 180-4 now.
Code change:
This specification defines the JWT claim <del> . The </del> <ins> (for verifiable credential type).  The </ins> value MUST be a case-sensitive

Related discussion:
text: This PR renames the claim to , as per the discussion in
I oppose against this change. I suggest to use 'vct' instead.
I'm good with . For the record, I think it's important to move away from , because URL uses the claim name, but with a different syntax. Keeping the naming conflict will inevitably lead to grief.
Naming is hard. Regarding dct: isn't it obvious for an internet standard that we refer to digital credentials?
Neither dct nor vct are intuitive for me, so I am pretty unsure. But between dct and vct, I would prefer dct. A term Verifiable credentials got enough feedback that it has strong too strong of an association to W3C VC-DATA-MODEL. And Digital credentials seems to be a term that is acceptable to generalize.
Why is "Verifiable Credential Type" (vct) not intuitive to you? This would match the current definition of . Isn't this what this claim is about? That is why I'm actually in favor of over , .
I meant that abbreviations are not intuitive to me. And "type" is a pretty JSON-LD specific construct AFAIK so I was hoping we could have a deeper discussion on whether it should be called "claimset" or something. If we are to move away from "type" claim name. on dct and vct, as I explained, I prefer something that is not associated to W3C VCDM and digital credentials seems to be pretty well understood.
If the color of the bikeshed is still open for debate, how about just for credential type?
I like 3-letter-names more than 2-letter-names for some reason. Also, is more accurate since the spec is about SD-JWT VCs => Verifiable Credentials. I'd be still in favor of for that reason.
is fine for me. Updated the PR accordingly.
is fine for me too. was just an off-hand idea
Merging this PR since a lot of approvals. We will have a larger conversation on what is inferred by the value in a separate issue.
I suggest to use 'vct'.LGTM. We should address NAME concern in a separate issue.This is an improvement.
Code change:
The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration.  Some Transparency <del> Services may publish every Transparent Statement in their logs, to </del> <ins> Services may publish every Signed Statement in their logs, to </ins> facilitate their dissemination and auditing.  Others may just return Receipts to clients that present Singed Statements for Registration, and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents. <del> A collection of Transparent Statements must not leak information about the contents of other Transparent Statements registered on the Transparency Service. </del> <ins> A collection of Signed Statements must not leak information about the contents of other Signed Statements registered on the Transparency Service. </ins> Nonetheless, Issuers should carefully review the inclusion of private/confidential materials in their Statements.  For example,

Related discussion:
text: NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later
Code change:
[2] http://httpwg.github.io/ [3] https://github.com/httpwg/http-extensions/labels/client-cert- <del> header </del> <ins> field </ins>

Related discussion:
text: This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)
Code change:
5.2.2.6. <del> The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache.  (See caching.authenticated.responses for additional details related to the use of public in response to a request containing </del> <ins> The "public" response directive overrides certain conditions that would otherwise make a cache unable to store the response. Specifically, see caching.authenticated.responses regarding the use of public in response to a request containing </ins> <del> , and response.cacheability for details of how public affects responses that would normally not be stored, due to their status codes not being defined as heuristically cacheable; see heuristic.freshness.) </del> <ins> , and response.cacheability for how public affects responses that would normally not be stored, due to their status codes not being defined as heuristically cacheable; see heuristic.freshness. </ins> 5.2.2.7.

Related discussion:
text: I think this is the right thing to do; we added too much text here in 7234.
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
I'll trust you on the actual change :-)
Code change:
proofs of non inclusion. Specific verifiable data structures, such those describes in RFC9162 <del> and I-D.draft-steele-cose-merkle-tree-proofs are out of scope for this document. </del> <ins> and I-D.draft-ietf-cose-merkle-tree-proofs are out of scope for this document. </ins> 4.1.4.

Related discussion:
text: Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.
Code change:
For example, the following cookies would always be rejected: <del> While the would be accepted if set from a secure origin (e.g. "https://site.example/"), and rejected otherwise: </del> <ins> While the following would be accepted if set from a secure origin (e.g.  "https://site.example/"), and rejected otherwise: </ins> 4.2.

Related discussion:
text: Add what seems to be a missing word in the __Host example text.
Thanks!
Thank you!
Code change:
ContentExists: 1 if an object has been published on this track, 0 if not.  If 0, then the Largest Group ID and Largest Object ID <del> fields will not be present. </del> <ins> fields will not be present.  Any other value is a protocol error and MUST terminate the session with a Protocol Violation (session- termination). </ins> Largest Group ID: The largest Group ID available for this track. This field is only present if ContentExists has a value of 1.

Related discussion:
text: This is a proposal to illustrate the changes needed to address one aspect of URL . In creating this, I explicitly didn't state copy the normative action on dealing with a 0 or 1 value. See URL for that.
9/25 interim: No objections to this direction, but make it MUST close if not 0 or 1. NAME can merge when he's satisfied the discussion has completed.
I updated this to use MUST.
https://moq-URL states This seems at odds with the QUIC design ethos of being very strict about receiving things that are obviously broken. This matter is wrapped up in URL and the proposed change (URL), so I wanted to track the question separately. I suspect we might want a bigger pass over the recomendations about when to detect a protocol error and how to handle it but I don't want to miss this specific issue in case it was done for a good reason.
I don't think this is editorial, since it affects the expectations on what a receiver is expected to do
To clarify, the proposal is to change the SHOULD terminate to a MUST terminate? I expect that's what everyone will do anyway, so this SG
Yes that would be my proposal here. And in addition, a separate review of other fields for consistency.
Discussed in today's interim. MUST rolled into URL and merged. So closing issue as done.
This change seems small and sensible, especially since every time I see (f) I think it's a float, not a flag.Don't feel strongly one way or the other but this looks good to me.