jiebi/CodeConvo huggingface dataset:
Code change:
4. <del> This specification defines the media type which describes a VC-SD-JWT with the following components: </del> <ins> This section defines encoding, validation and processing rules for VC-SD-JWTs. </ins> 4.1. <del> 4.1.1. </del> <ins> VC-SD-JWTs compliant with this specification MUST use the media type as defined in {#application-vc-sd-jwt}. 4.2. VC-SD-JWTs MUST be encoded using the SD-JWT Combined Format for Issuance as defined in I-D.ietf-oauth-selective-disclosure-jwt. VC-SD-JWTs MUST contain all Disclosures corresponding to their SD-JWT component except for Decoy Digests as per [@!I-D.ietf-oauth- selective-disclosure-jwt, section 5.1.1.3.]. 4.2.1. This section defines JWT header parameters for the SD-JWT component of the VC-SD-JWT. </ins> The

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:
indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be represented by a 204 No Content response.  If the response includes a <del> body payload, the payload is expected to describe the results of the search operation.  In some cases, the server may choose to respond </del> <ins> content, it is expected to describe the results of the search operation.  In some cases, the server may choose to respond </ins> indirectly to the SEARCH request by returning a 3xx Redirection with <del> a Location header specifying an alternate Request URI from which the search results can be retrieved using an HTTP GET request.  Various non-normative examples of successful SEARCH responses are illustrated in examples. </del> <ins> a Location header field specifying an alternate Request URI from which the search results can be retrieved using an HTTP GET request. Various non-normative examples of successful SEARCH responses are illustrated in examples. </ins> The response to a SEARCH request is not cacheable.  It ought to be noted, however, that because SEARCH requests are safe and idempotent,

Related discussion:
text: content-type / media type header / header field
This should include updating the core spec references; I will update this PR accordingly unless you get to that before me.
See
Code change:
5.1. <ins> Every HTTP message has a protocol version.  Depending on the version in use, it might be carried in the message explicitly, or it might be inferred by the connection that the message is carried on.  A message can change versions as it passes through intermediaries, because the semantics of a HTTP message are independent of its version. </ins> While HTTP's core semantics don't change between protocol versions, the expression of them "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire

Related discussion:
text: This seems out of place, although I understand that versioning is very message-based. I'd suggest putting it in 15. Extending HTTP?
It's not about extending HTTP. The version number literally exists as a field of the message, or at least inherited by the context of the connection, and must be retained by recipients because of version-specific requirements. That's why we need to define both cases as part of the message abstraction.
Fair enough. Can we open the section with a sentence or two that says that it's a field of the message, to give that context? The current text is pretty abstract.
Code change:
ultimately controls how long a client instance can re-use a single Client Attestation JWT. <del> 4.2. </del> <ins> 5.2. </ins> Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt- <del> key-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 [@!RFC6749].  To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion- type:jwt-key-attestation" authentication method.  The client MUST also use the same client attestation key that was used for authentication when the refresh token was issued. </del> <ins> client-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 [@!RFC6749].  To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation" authentication method.  The client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued. </ins> <del> 5. </del> <ins> 6. </ins> <del> 5.1. </del> <ins> 6.1. </ins> Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of

Related discussion:
text: Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.
Code change:
"HTTP Capsule Types" registry: For this draft version of the protocol, the Capsule Type value <del> "0xb739a6d0" shall be used provisionally for testing, under the name "DATA-05". </del> <ins> "0x2028d7ee" shall be used provisionally for testing, under the name "DATA-07". </ins>

Related discussion:
text: This leaves only the Capsule Protocol mode
I do think we should add FINAL_DATA, but I'm fine with merging this first and then discussing that in
As of draft-ietf-httpbis-connect-tcp-05, connect-tcp now optionally supports the capsule protocol. However, this optionality adds non-trivial complexity to implementations. As currently written, if a client wishes to use capsules, the server can reject the use of capsules, and now the client needs to cache that this server doesn't support them. However it's undefined for how long the client should cache this information, and within what scope. We could potentially figure out recommendations for all these questions, but fundamentally it might be best to instead make capsules mandatory for connect-tcp, like they are for connect-udp and connect-ip. That would simplify implementations and improve consistency.
Individually, I think it would be interesting to try out this direction — probably based on implementation experience for how easy it is to add. On one hand, this makes connect-tcp less of a trivial drop-in. On the other, it opens up more possible use cases.
I heard a good deal of support for this direction in the HTTPBIS meeting.
Thanks!
Code change:
Digest field calculations are tied to the "Content-Encoding" and "Content-Type" header fields.  Therefore, a given resource may have <del> multiple different checksum values when transferred with HTTP.  To allow both parties to exchange a simple checksum with no content codings (see Section 8.4.1 of SEMANTICS), two more digest-algorithms are added ("id-sha-256" and "id-sha-512"). </del> <ins> multiple different checksum values when transferred with HTTP. </ins> Digest fields do not provide integrity for HTTP messages or fields. However, they can be combined with other mechanisms that protect

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:
Reason Phrase: Provides the reason for subscription error. <del> Track Alias: When Error Code is TBD, the subscriber SHOULD re- issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session-termination).  TODO: Add a registry for subscribe error codes and make this field conditional. </del> <ins> Track Alias: When Error Code is 'Retry Track Alias', the subscriber SHOULD re-issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session- termination). </ins> 6.7.

Related discussion:
text: This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.
Code change:
Reason Phrase: Provides the reason for subscription error. <del> Track Alias: When Error Code is TBD, the subscriber SHOULD re- issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session-termination).  TODO: Add a registry for subscribe error codes and make this field conditional. </del> <ins> Track Alias: When Error Code is 'Retry Track Alias', the subscriber SHOULD re-issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session- termination). </ins> 6.7.

Related discussion:
text: Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)
Code change:
The IETF specifies standard Internet congestion control algorithms in the RFC-series.  These congestion control algorithms can suffer <del> performance challenges when used in various environments (e.g., high- speed networks, cellular and WiFi wireless technologies, and long distance satellite links), and also when flows carry specific </del> <ins> performance challenges when used in differing environments (e.g., high-speed networks, cellular and WiFi wireless technologies, and long distance satellite links), and also when flows carry specific </ins> workloads (Voice over IP (VoIP), gaming, and videoconferencing). When RFC5033 was published in 2007, TCP RFC9293 was the dominant

Related discussion:
text: Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.
Code change:
defined as an sf-string is allowed to fail when processing this field section: <del> If parsing fails - including when calling another algorithm - the entire field value MUST be ignored (i.e., treated as if the field were not present in the section).  This is intentionally strict, to improve interoperability and safety, and specifications referencing this document are not allowed to loosen this requirement. </del> <ins> If parsing fails, either the entire field value MUST be ignored (i.e., treated as if the field were not present in the section), or alternatively the complete HTTP message MUST be treated as malformed. This is intentionally strict to improve interoperability and safety, and field specifications that use Structured Fields are not allowed to loosen this requirement. </ins> Note that this requirement does not apply to an implementation that is not parsing the field; for example, an intermediary is not

Related discussion:
text: ... or it's a clarification that aligns the text in the two different sections. Sounds like we should discuss on list.
I still dont understand why we have some of the "strict" stuff in 1.1 and some in 4.2. I would move the paragraph from 4.2 to 1.1 to improve the chance people actually read it.
Disagree; implementers are more likely to look at the parsing section, not what they perceive as boilerplate at the top. 1.1 covers the philosophy and general approach; 4.2 talks about the implementation details.
"This is intentionally strict […]" sounded philosophical to me, but whatever :-)
URL It appears that some read the last sentence: as saying that the generic draconian handling of parsing errors can be relaxed.
It's saying that a generic parser will fail, but the field-specific handling of that failure might do somthing else, including try to parse the field using an alternative method. SF cannot constrain what a field does with the output of parsing.
That sounds like "we require draconian error handling, but if there's an error, you are free to do something else". Of course we can't force anybody not to do that, but we should be clear that this is not what the spec says.
Code change:
a URI with a "moqt" scheme.  The "moqt" URI scheme is defined as follows, using definitions from RFC3986: <del> The "authority" portion MUST NOT contain a non-empty "host" portion. </del> <ins> The "authority" portion MUST NOT contain an empty "host" portion. </ins> The "moqt" URI scheme supports the "/.well-known/" path prefix defined in RFC8615.

Related discussion:
text: One small normative change: I relaxed a SHOULD to a MAY when discussing relays writing data out of order. No one is implementing this right now.
Here are some editorial notes on the document Line 72. “MOQT is a generic protocol is designed to work” Line 91-93. “The development of MOQT is driven by goals in a number of areas - specifically latency, the robustness of QUIC, workflow efficiency and relay support.” This sentence is intriguing. What does the robustness of QUIC mean? Latency, workflow efficiency, relay support are not “areas” or maybe area should be defined. (side note on the missing Oxford comma in this sentence) The Section 1.1.1. Latency as a whole is very confusing. HTTP-based streaming is not designed for low latency mostly due to the essential request-response paradigm. Queuing on the path has a insignificant impact on the end-to-end latency for HAS. The “speed at which a protocol can detect queuing” is not related to the relatively high latency issues of HAS. Overall, I see a mix of unrelated subjects here, which makes the paragraph overall meaningless. I would recommend starting the paragraph with a topic sentence (which may be the last one of the current paragraph). Line 120. “Applying QUIC to HAS …” (and the following sentences) is not necessary. The reasons for which QUIC does not bring advantages to HAS are still debatable on many points. This QUIC-on-HAS remark could raise unnecessary questions although the beginning of Section 1.1.2 is clear and sufficient to convey the message. Line 125. “Universal” has a too broad sense. Do you mean “Unicity of protocol in the whole pipeline” (or something like this)? Line 127. “Internet delivered media today has protocols optimized for ingest…” I don’t understand this sentence. Line 127. Some examples of protocols could be good to support these claims. Note that WHIP is an attempt to unify the protocol. Line 146. “to treat relays as first-class citizens of the protocol” is an excellent marketing message but it does not mean anything in a technical norm. Furthermore, see my two reserves above. I’d claim that the current draft is not making relay first-class, on the contrary.
Code change:
a URI with a "moqt" scheme.  The "moqt" URI scheme is defined as follows, using definitions from RFC3986: <del> The "authority" portion MUST NOT contain a non-empty "host" portion. </del> <ins> The "authority" portion MUST NOT contain an empty "host" portion. </ins> The "moqt" URI scheme supports the "/.well-known/" path prefix defined in RFC8615.

Related discussion:
text: Line 179. “a join point” joint? Line 231. “The application is solely responsible for the content of the object payload.” What is the application? It is a bit confusing. It has not been defined. Line 269 .“within a single MOQT scope, subscribing to the same full track name would result in the subscriber receiving the data for the same track.” I am not sure to understand this sentence. Is a single MOQT scope a scope with only one server or do you mean “within a MOQT scope”? the two “same” adjectives are confusing too. Line 273. It would be better to stick to “servers” or to “connection URIs” to refer to the elements of the scope. Line 339. “The portion MUST NOT contain a non-empty portion.” Is it a double negation to say that the ‘authority’ MUST contain an empty ‘host’ portion? Line 357. This sentence may require a MUST. Line 359. “for exchanging …” and following sentences are not related to session initialization. They are rather remarks that would be a fit with the draft Section 4. +1 to the TODO remarks on line 381. This should be in Section 4. Line 654. “it allows the peers…” The term “peer” is used 7 times. It is supposed to be an “endpoint” (as defined Line 173), unless peer and endpoint have different meaning (in which case peer must be defined) Line 693. “A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.” I don’t understand this claim.
Thanks for the feedback. I'm going to mark this as Editorial, but there are a number of points here. If you believe any of them are not editorial (ie: "Line 357. This sentence may require a MUST."), please split into a separate issue.
Will assign to Mo.
NAME Please go through these and fix any that still apply.
Code change:
This specification registers the media type <del> in the W3C Verifiable Credentials (VC) Directory. </del> <ins> in the W3C Verifiable Credentials (VC) Directory VC-DIR. </ins> 9.1.2. The following is a uni-directional transformation algorithm that takes in a VC-SD-JWT conformant to this specification and maps it to <del> the corresponding properties in the W3C VCDM 2.0 [VCDM2.0] which is </del> <ins> the corresponding properties in the W3C VCDM 2.0 VC-DATA which is </ins> based on a JSON-LD vocabulary.  It includes specific handling for JWT claims used in this specification.  The function returns a Verifiable Credential object in the W3C VCDM 2.0 format. <del> The following is a uni-directional transformation algorithm from a VP-SD-JWT onto W3C Verifiable Presentations in pseudo-code: </del> <ins> Procedure: 1.  Let </ins> <del> #### </del> <ins> be the unsecured payload of the VC-SD-JWT reconstructed from the SD- JWT and Disclosures.  1.  Let be an empty JSON object that represents the transformed Verifiable Credential: - Set the property of to .  1.  If the payload contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from the payload.  1.  If the payload contains the property: - Convert the value of from epoch time to an ISO datetime format.  - Assign the converted value to the property of .  - Remove the claim from the payload.  1.  If the payload contains the property: - Assign the value of to the property of .  - Remove the claim from the payload.  1.  Set the property of to the value of the property in the payload.  - Remove the claim from the payload.  1.  Set the property of to a String array and set the first array element to . Add the value of the property in the payload as the second array element.  - Remove the claim from the payload.  1.  If the payload contains the property: - Assign the value of as the property of the object in .  - Remove the claim from the payload.  1.  Else if the payload does not have a property, create an empty object.  1.  Add all remaining claims in the payload to the object of and ignore claims that do not have a corresponding representation. 1.  Output which contains the resulting Verifiable Credential. The following is a non-normative example of a pseudocode algorithm: </ins>

Related discussion:
text: Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.
Code change:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.10. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.10.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.10.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.10.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.

Related discussion:
text: This PR moves track request params to its own section. This was messed up during huge PR merge as part of preparing for IETF117 work. Also it add track namespace length field to Announce_OK message which was omitted.
NAME good catch. updated the commit to address your comment. Thanks
It's an improvement so we should merge, but we do need to clean up how parameters are encoded.You may also want to move the actual definition of Track Request Parameter, it's currently in the SUBSCRIBE REQUEST section.
Code change:
Digest Algorithm: adler32 <del> Description: The ADLER32 algorithm is a checksum specified in RFC1950 "ZLIB Compressed Data Format".  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed).  For example, adler32=03da0195 and adler32=3DA0195 are both valid checksums for the 4-byte message "Wiki".  This algorithm is obsoleted and SHOULD NOT be used. </del> <ins> Description: The ADLER32 algorithm RFC1950.  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed). For example, adler32=03da0195 and adler32=3DA0195 are both valid checksums for the 4-byte message "Wiki".  This algorithm is obsoleted and SHOULD NOT be used. </ins> Reference: RFC1950, this document.

Related discussion:
text: There's not really any reason to describe anything other than the algorithm used and the format of encoding.
From NAME WGLC review This seems like cruft. The important things for the table are clear pointers to the algorithm definition and the encoding of values created by the algorithm.
If it's not broken, don't fix it :P I think we spent too much time wrt old algorithms. I'm in favor of anyone that wants to provide a PR that has consensus.
It is broken -- let's fix it. :)
LGTM