jiebi/CodeConvo huggingface dataset:
Code change:
serialization. Let byte_array be the result of applying UTF-8 encoding (Section 3 <del> of UTF8) to input_sequence. </del> <ins> of UTF8) to input_sequence.  If encoding fails, fail serialization. </ins> Let encoded_string be a string containing "%" followed by DQUOTE.

Related discussion:
text: We'd need to add something to 4.1.11, like "for each character (or code point?) in inputsequence, append the result of applying UTF-8 encoding to character to bytearray".
Code change:
SHOULD send a TCP RST to the target.  If the proxy observes a connection error from the target, it SHOULD send a TLS "internal_error" alert to the client, or set the TCP RST bit if TLS <del> is not in use. </del> <ins> is not in use.  These behaviors avoid truncation of transfers between the client and the target on vulnerable protocols (e.g., HTTP/1.1 without TLS) while preserving the confidentiality and integrity guarantees of the "https" scheme. </ins> 3.2. <del> In HTTP/2 and HTTP/3, the client uses the proxy by issuing an "extended CONNECT" request as follows: </del> <ins> In HTTP/2 and HTTP/3, the proxy MUST include SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame RFC9220.  The client uses the proxy by issuing an "extended CONNECT" request as follows: </ins> The :method pseudo-header field SHALL be "CONNECT".

Related discussion:
text: Changes: s/tcpport/targetport/ (aligning with connect-udp) Remove support for multiple IPs and
NAME The discussion at IETF 119 leaned toward removing the multiple-IP mode entirely. Are you suggesting that we should keep it?
This PR contains two changes; I'm not making a suggestion with regard to multiple-IP mode, but I think aligning the variable names in the template makes sense. Did both get dropped, or is that being discarded because it's in the same PR?
OK, I've updated this PR to also drop the multiple-IP support entirely.
The target_host variable is only described vaguely. It should be defined more rigorously. For example, it doesn't specify whether IPv6 scope IDs are allowed or not. I'd recommend reusing the text from RFC 9298.
OK, I've opened to make the definition more rigorous.
Fixed by
The draft currently defines the "targethost" and "tcpport" variables. We should replace "tcpport" with "targetport" for consistency with connect-udp. This consistency isn't just cosmetic, it simplifies reusing the same URI template for both protocols.
The distinction is deliberate, precisely because it facilitates using a single URI template for both protocols. As discussed in , the client can use a single template for various purposes by inspecting the variables that it contains: "targetport" -> connect-udp "tcpport" -> connect-tcp "ipproto" -> connect-ip "dns" -> DoH Using the same name ("targetport") for TCP and UDP would add complexity for client implementors. Instead of being able to determine a priori_ whether a proxy supports TCP and UDP based on the template, the client would have to probe (and periodically re-probe) for this information and maintain dynamic state about which protocols are supported.
What you're saying is that a client can infer support for certain protocols based on the variables present in the URI template. That's not correct, or more precisely it wasn't specified for connect-udp, and it definitely doesn't work for connect-ip (in connect-ip the variables are optional).
OK, I see that it doesn't work for connect-ip, so connect-ip can only be supported by probing or with an out-of-band signal (or with an ecosystem restriction that connect-ip servers must support "target" and "ipproto").
Code change:
SHOULD send a TCP RST to the target.  If the proxy observes a connection error from the target, it SHOULD send a TLS "internal_error" alert to the client, or set the TCP RST bit if TLS <del> is not in use. </del> <ins> is not in use.  These behaviors avoid truncation of transfers between the client and the target on vulnerable protocols (e.g., HTTP/1.1 without TLS) while preserving the confidentiality and integrity guarantees of the "https" scheme. </ins> 3.2. <del> In HTTP/2 and HTTP/3, the client uses the proxy by issuing an "extended CONNECT" request as follows: </del> <ins> In HTTP/2 and HTTP/3, the proxy MUST include SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame RFC9220.  The client uses the proxy by issuing an "extended CONNECT" request as follows: </ins> The :method pseudo-header field SHALL be "CONNECT".

Related discussion:
text: It seems fine for connect-udp and connect-tcp because the variables are mandatory, so it would provide value to UDP+TCP clients (which seem likely to be common).
In that case we should state somewhere that passing around an URI template with these variables implies support for the corresponding mechanism. I'm not sure we'd get consensus on that though.
Thanks for the updates based on the discussion at 119
Code change:
Local IPv6 Unicast Addresses (RFC4193) are randomly allocated prefixes.  A stub router MUST allocate a single ULA Site Prefix for use in providing on-link prefixes to the stub network and the <del> adjacent infrastructure link, as needed. </del> <ins> adjacent infrastructure link as described in state-begin-advertising. </ins> Any ULA Link Prefixes allocated by a stub router SHOULD be maintained across reboots, and SHOULD remain stable over time.  (TBD: mention

Related discussion:
text: Refer to state-begin-advertising to describe the states when ULA site prefix is advertised.
has currently: The "as needed" part here is not so clear and needs to be detailed. E.g. only if an on-link prefix on the AIL is not present, the stub router provides one from its own ULA prefix only if the stub network does not have an on-link prefix or on-mesh prefix (whatever applies), then it creates one from its own ULA prefix. sizes of the involved prefixes? Better to either specify sizes or say it's up to implementation. state some randomness requirements - although for the ULA Global ID it may be clear that it must be randomized; we also have Subnet ID to have requirements for (or not). In any case state these assumptions.
This can be resolved easily by a pointer to other parts of the draft ("as defined in Section N"). Because there are still some pending PRs that impact the text here and add the details, this issue can be postponed until after these PRs are merged.
Code change:
15. <del> RFC7540 stream prioritization relies on dependencies.  Considerations are presented to implementations, describing how limiting state or work commitments can avoid some types of problems.  In addition, CVE- 2019-9513 aka "Resource Loop", is an example of a DoS attack that abuses stream dependencies.  Extensible priorities does not use dependencies, which avoids these issues. </del> frame describes considerations for server buffering of PRIORITY_UPDATE frames.

Related discussion:
text: In Bob's TSVART review, he notes in Tb that the mention the H2 DoS attack in Security seems useful and we should probably expand on it. The mentions of H2 have been whittled down as 7540bis progresses and the reference to CVE-2019-9513 in the security section now seems misplaced. It's cleaner to just remove it so that the section focuses on considerations for using this document. P.S I think this means that MT was right ;)
Code change:
connection-specific header fields as discussed in HTTP, or their messages will be treated by other HTTP/2 endpoints as malformed. <del> 8.1.2.3. The following pseudo-header fields are defined for HTTP/2 requests: All HTTP/2 requests MUST include exactly one valid value for the , , and pseudo-header fields, unless it is a CONNECT.  An HTTP request that omits mandatory pseudo-header fields is malformed. Individual HTTP/2 requests do not carry an explicit indicator of protocol version.  All HTTP/2 messages implicitly have a protocol version of "2.0" (see HTTP). 8.1.2.4. For HTTP/2 responses, a single pseudo-header field is defined that carries the HTTP status code field (see HTTP).  This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed. HTTP/2 responses implicitly have a protocol version of "2.0". 8.1.2.5. </del> <ins> 8.2.3. </ins> The COOKIE uses a semi-colon (";") to delimit cookie-pairs (or "crumbs").  This header field contains multiple values, but does not

Related discussion:
text: This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.
Code change:
8.3. Upon receiving a Presentation, in addition to the checks outlined in <del> sd_jwt_verification, Verifiers MUST ensure that </del> <ins> sd_jwt_verification, Verifiers need to ensure that </ins> To this end, Verifiers MUST follow the following steps (or equivalent):

Related discussion:
text: which can be found at
I think the following change might be cleaner per in Jefferey's review. "9. Check that the Key Binding JWT is valid in all other respects, per [NAME and [NAME -> "9. Check that the Key Binding JWT is a valid JWT in all other respects, per [NAME and [NAME
Sure, that's done in 4442c3a06767498ee24154024d8dff987325b08f
While reviewing URL, I had to understand some of the SD-JWT verification algorithms. I noticed some issues, which I've listed here. I haven't filed individual issues yet because I'm not sure how you'll want to group them. Thanks to NAME for doing a first pass; any remaining mistakes are probably because I didn't take his advice. [x] This should follow URL by specifying "what serialization and serialization features are used". I see that 1.1. Feature Summary mentions the compact serialization, but that doesn't clearly say that this embedded JWT uses it.[x] "The claim name, or key, as it would be used in a regular JWT payload. The value MUST be a string." <- I assume the "value" is the key, and not the key's value in the JSON object? [x] Why is 128 bits only recommended and not required for the salt?[x] This should follow URL by specifying "what serialization and serialization features are used". I see that 1.1. Feature Summary mentions the compact serialization, but that doesn't clearly say that this embedded JWT uses it.[x] This mentions "bytes preceding the KB-JWT in the Presentation", but several other places mention "Key Binding is provided by means not defined in this specification", in which case the relevant bytes don't precede the KB-JWT. These should be consistent.[x] Are "Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that" and "The Holder or the Verifier MUST perform the following (or equivalent) steps when receiving an SD-JWT" accomplishing the same thing? [x] "Separate the SD-JWT" should cite an algorithm for doing that. I think it's "5. SD-JWT Data Formats" which implies it's just "split on '~'"?
Code change:
8.3. Upon receiving a Presentation, in addition to the checks outlined in <del> sd_jwt_verification, Verifiers MUST ensure that </del> <ins> sd_jwt_verification, Verifiers need to ensure that </ins> To this end, Verifiers MUST follow the following steps (or equivalent):

Related discussion:
text: [x] "Ensure that a signing algorithm was used that was deemed secure" disclosure and then call a recursive element-processing-and-replacing function, but this isn't too bad. [x] "Remove all array elements for which the digest was not found" probably won't confuse anyone for long, but my first reading said that an array in the payload like [1, 2, 3] would wind up empty since no digests were found for the elements. [x] "Check that the SD-JWT is valid using claims such as nbf, iat, and exp" should say where those claims are defined and what part of which object they appear on. (URL, and the top level of the payload, not the header, right?) [x] The "required validity-controlling claim"s should probably be an input parameter to this algorithm. Possibly all the IANA-registered JWT claim handling should be passed in, or this algorithm should return all the claims for the caller to deal with.[x] "create a Key Binding JWT" <- refer to the section that says how to do this. [x] "Assemble the SD-JWT for Presentation" <- This should at least refer to "5. SD-JWT Data Formats" and possibly just write out the algorithm of "make an array of the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT, and join the array with '~'."[x] This is clearer that "Verifiers MUST ensure that" is accomplished by the steps in the following algorithm, but I don't like the redundant MUST. You can just say "Verifiers need to ensure that" and then leave the normative requirements to the algorithm. [x] "according to the Verifier's policy" should be an input parameter to this algorithm, that the verifier provides along with the bytes of the presentation. [x] "verify the Key Binding according to the method used" <- how? This might be URL, but you should cite the details. [x] "Determine the public key for the Holder" <- how? This might be the 'cnf' claim, but you should say so. [x] "Ensure that a signing algorithm was used that was deemed secure" <- as above, this should be an input parameter to this algorithm or computed from the public key.
Code change:
8.3. Upon receiving a Presentation, in addition to the checks outlined in <del> sd_jwt_verification, Verifiers MUST ensure that </del> <ins> sd_jwt_verification, Verifiers need to ensure that </ins> To this end, Verifiers MUST follow the following steps (or equivalent):

Related discussion:
text: [x] "Validate the signature" <- again, cite how to do this. [x] "the typ of the Key Binding JWT" <- is that in the header or payload? (cite 5.3. Key Binding JWT and possibly URL) [x] "within an acceptable window." <- should be an input parameter [x] "validating nonce and aud claims" <- The instructions for doing this should be an input parameter to this algorithm. [x] "Check that the Key Binding JWT is valid in all other respects" should call a particular algorithm from the other specs that it cites.[x] Many of these should be normative. For example, base64url is used all over the normative parts of this specification, and it comes from [RFC7515] in this section.
Thanks for the review Jeffrey! I'm acknowledging it with this comment but also noting that there's a lot here so response/action will take some time.
1c1f165ab821dea5350f62225f103bdceff31532 one was an oversight and one was a tooling issue and oversight. I think that covers them tho.
Those other specs don't have algorithms that can be called nor do they have suitable sections to reference directly.
Some contributors want to leave open the option of a more computationally expensive hash with smaller salt values.
Yes and I've tried to remove any ambiguity there by just not using the word "value" with d015a3de2ae50623b4a294590fb2d0249e7d33b5
Per , "JWTs are always represented using the JWS Compact Serialization" the compact serialization is already specified.
That is for the claim in Key Binding JWT so isn't relevant elsewhere.
& Yeah, with 2a0e270f2e1dbfa9664bb5ce4989a2f6a1765217 I basically applied your suggestion to both places.
Yup 7d68d4ed9b91e49a0aa00254475bf7c116669dd6
Yes but I believe it's sufficiently clear in the context of the draft.
This draft is not structured such that it has input parameters to algorithms so suggestions to make something an input parameter to an algorithm are not actionable or practical.
Code change:
8.3. Upon receiving a Presentation, in addition to the checks outlined in <del> sd_jwt_verification, Verifiers MUST ensure that </del> <ins> sd_jwt_verification, Verifiers need to ensure that </ins> To this end, Verifiers MUST follow the following steps (or equivalent):

Related discussion:
text: e9acd5ed665b107776b6b41355680470cde89f2c
is a JOSE header. Will cite sec 5.3. where that's more explicit 64a4c4519668c7a63f1a0be215176657895fa0c8
That sentence starts with "If Key Binding is provided by means not defined in this specification," so there are not specific details to cite. mentions that other ways of proving Key Binding are possible. DPoP/rfc9449 is one possibility but not the only one. Nor a particularly likely one. At least not likely enough to warrant mention here.
The very next part of that sentence says "in the processed payload" and that's a non-exhaustive list of JWT claims for which a citation/reference isn't really needed.
I feel like it's sufficiently clear from context and shouldn't confuse anyone for too long.
Noted.
This draft intentionally doesn't prescribe how keys are distributed, identified, selected, trusted, etc. any more than JWT/JWS do (e.g. URL, URL, etc). A map from (issuer ID, key ID) pairs to public keys is one application but certainly not the only one.
referencing that 072a0605bcb62937e343aaa7812aa8ef86d8379f
That's a somewhat existential and loaded question but common usage of the word doesn't preclude it describing nested items and array elements. And this draft is not alone in that. In the intro it also says, '"Claims" here refers to both object properties (name-value pairs) as well as array elements.'

"create a Key Binding JWT" <- refer to the section that says how to do this. cbee5f8457f447574400377dc6f7c9fe7f1c3c18
a474e2b0b0ff7635af38c2ac95e70b40b2f82798 makes things a little more a bit more prescriptive about suggesting RFC7800 cnf/jwk be used to convey the Key Binding key and references that section from the "Verification by the Verifier" section.
Thank you so much, Brian! overall, agree with all the responses.
Code change:
8.3. Upon receiving a Presentation, in addition to the checks outlined in <del> sd_jwt_verification, Verifiers MUST ensure that </del> <ins> sd_jwt_verification, Verifiers need to ensure that </ins> To this end, Verifiers MUST follow the following steps (or equivalent):

Related discussion:
text: I made few comments on the PR, but one thing to note here too: I think recommending claim per comment is inconsistent with a comment that says that "this draft intentionally doesn't prescribe how keys are distributed, identified, selected, trusted, etc. any more than JWT/JWS do. so I think recommending is redundant and using in examples is sufficient.
That latter comment was about (and in reply to a suggestion about) validating the signature on the Issuer-signed JWT and checking that the signing key belongs to this Issuer. While the former comment is about the holder's public key inside the Issuer-signed JWT itself. Different things so I don't believe there's really an inconsistency in my statements. Nor do I think that being a little more a bit more prescriptive and more clear about using RFC7800 cnf/jwk to convey the Key Binding key is redundant. Rather this review of a review seemed like a good opportunity to provide a little more clarity and guidance in an area the draft that could benefit from such.
one nit, otherwise looks good - thank you, Brian!
Code change:
This section is meant to inform developers, information providers, and users of known security considerations relevant to HTTP message <del> syntax, parsing, and routing.  Security considerations about HTTP semantics and payloads are addressed in Semantics. </del> <ins> syntax and parsing.  Security considerations about HTTP semantics, payloads, and routing are addressed in Semantics. </ins> 11.1.

Related discussion:
text: I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?
Code change:
delays for the connections attempting to use Quick-Start.  The Quick- Start method is discussed as an example in RFC9049. <ins> Strictly speaking, Informational RFCs in the IETF stream need not meet all of the criteria in this document, as they do not carry a formal recommendation from the community.  Instead, the community judges the publication of Informational RFCs based on the value of their addition to the RFC series. </ins> Although out of the scope of this document, proponents of a new algorithm could alternatively seek publication as an Informational or Experimental RFC via the Internet Research Task Force (IRTF).  In

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:
RTP Payload Format for sub-codestream latency JPEG 2000 streaming <del> draft-ietf-avtcore-rtp-j2k-scl-02 </del> <ins> draft-ietf-avtcore-rtp-j2k-scl-03 </ins> Abstract

Related discussion:
text: In regards to not requesting registration in the RTP payload registry, please remove the following sentence in Section 11: The motivation and removal of the registry the above sentence request are in: URL (from Magnus Westerlund)