jiebi/CodeConvo huggingface dataset:
Code change:
The status codes listed below are defined in this specification.  The reason phrases listed here are only recommendations -- they can be <del> replaced by local equivalents without affecting the protocol. </del> <ins> replaced by local equivalents or left out altogether without affecting the protocol. </ins> Responses with status codes that are defined as heuristically cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410,

Related discussion:
text: "The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the protocol." "URL left out altogether..." ?
(need to check where the fix went)
Code change:
containing the relation type "preload" and start fetching the target resource. <del> However, this MUST NOT affect how the final response is processed; when handling it, the client MUST behave as if it had not seen the informational response.  In particular, a client MUST NOT process the header fields included in the final response as if they belonged to the informational response, or vice versa. </del> <ins> However, these header fields only provide hints to the client; they do not replace the header fields on the final response.  Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational response itself (e.g., as metadata about the 103 (Early Hints) response). </ins> An intermediary MAY drop the informational response.  It MAY send HTTP/2 (RFC7540) server pushes using the information found in the 103

Related discussion:
text: This is a PR that essentially rebases the change proposed in . To me the change proposed by NAME is a clear improvement. I believe that we should merge this.
Regarding The requirement in the last sentence needs to be re-worded, since includes parsing and the client is clearly parsing those header fields and using them.
I would rewrite the paragraph as
Collision with my suggested edits; closing. Please ask to reopen if you still think there's a problem; we can address it in WGLC.
Code change:
applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign. <del> To verify using this algorithm, the verifier applies the "RSASSA-PSS- VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input string ("M") re-created as described in verify.  The hash function SHA-256 RFC6234 is applied to the signature input string to create the digest content to which the verification function is applied. The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results of the verification function are compared to the http message signature to determine if the signature presented is valid. </del> <ins> To verify using this algorithm, the verifier applies the "RSASSA- PKCS1-V1_5-VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input string ("M") re-created as described in verify.  The hash function SHA-256 RFC6234 is applied to the signature input string to create the digest content to which the verification function is applied.  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results of the verification function are compared to the http message signature to determine if the signature presented is valid. </ins> 3.3.3.

Related discussion:
text: This text should be more precise about the definition of different signature parameters, including inputs to PSS. All examples have been updated. Examples for ECDSA and HMAC have been added.
Code change:
clients signal stream dependencies and weights to describe an unbalanced tree.  It suffered from limited deployment and interoperability and was deprecated in a revision of HTTP/2 HTTP2. <del> However, in order to maintain wire compatibility, HTTP/2 priority signals are still mandatory to handle (see HTTP2). </del> <ins> HTTP/2 retains these protocol elements in order to maintain wire compatibility (see HTTP2), which means that they might still be used in the absence of alternative signaling, such as the scheme this document describes. </ins> Clients can build RFC 7540 trees with rich flexibility but experience has shown this is rarely exercised.  Instead they tend to choose a

Related discussion:
text: Not a complete solution, but hopefully helpful. More to come for those who are less cautious than I.
Thank you, this looks clear and accurate to me.
Code change:
URN: urn:ietf:params:oauth:token-type:txn_token <del> Common Name: Transaction Token </del> <ins> Common Name: Transaction Token </ins> <del> Change Controller: IESG </del> <ins> Change Controller: IESG </ins> <del> Specification Document Section txn-token-request of this specification </del> <ins> Specification Document Section txn-token-request of this specification </ins> URN: urn:ietf:params:oauth:token-type:self_signed <del> Common Name: Token type for Self-signed JWT </del> <ins> Common Name: Token type for Self-signed JWT Change Controller: IESG Specification Document: Section self-signed-subject-token-type of this specification URN: urn:ietf:params:oauth:token-type:unsigned_json </ins> <del> Change Controller: IESG </del> <ins> Common Name: Token type for Unsigned JSON Object Change Controller: IESG </ins> <del> Specification Document: Section subject-token-types of this specification </del> <ins> Specification Document: Section unsigned-json-subject-token- type of this specification </ins> 11.2.

Related discussion:
text: The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments
Code change:
URN: urn:ietf:params:oauth:token-type:txn_token <del> Common Name: Transaction Token </del> <ins> Common Name: Transaction Token </ins> <del> Change Controller: IESG </del> <ins> Change Controller: IESG </ins> <del> Specification Document Section txn-token-request of this specification </del> <ins> Specification Document Section txn-token-request of this specification </ins> URN: urn:ietf:params:oauth:token-type:self_signed <del> Common Name: Token type for Self-signed JWT </del> <ins> Common Name: Token type for Self-signed JWT Change Controller: IESG Specification Document: Section self-signed-subject-token-type of this specification URN: urn:ietf:params:oauth:token-type:unsigned_json </ins> <del> Change Controller: IESG </del> <ins> Common Name: Token type for Unsigned JSON Object Change Controller: IESG </ins> <del> Specification Document: Section subject-token-types of this specification </del> <ins> Specification Document: Section unsigned-json-subject-token- type of this specification </ins> 11.2.

Related discussion:
text: The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"
Code change:
The key exporter context contains the following fields: The Signature Algorithm and Port fields are encoded as unsigned <del> 16-bit integers in network byte order.  The Key ID, Scheme, Host, and Real fields are length prefixed strings; they are preceded by a Length field that represents their length in bytes.  These length fields are encoded using the variable-length integer encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. </del> <ins> 16-bit integers in network byte order.  The Key ID, Public Key, Scheme, Host, and Real fields are length prefixed strings; they are preceded by a Length field that represents their length in bytes. These length fields are encoded using the variable-length integer encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. The encoding of the public key is determined by the Signature Algorithm in use as follows: This document does not define the public key encodings for other algorithms.  In order for a SignatureScheme to be usable with the Signature HTTP authentication scheme, its public key encoding needs to be defined in a corresponding document. </ins> 4.2.

Related discussion:
text: Currently, modifying an HTTPS stack to support this draft only requires a signature implementation and a TLS key exporter API. Using a MAC would require a MAC primitive and opens the question "which MAC should we use?"
That's an easy question: you are using HKDF to get the values, so HMAC is a logical choice. The only reason I suggested that is that I'm increasingly nervous about these bespoke constructions. We understand what sign and mac provides.
I think we need to first identify what property it is we actually want, and then see what is the simplest way to get there. NAME what is the property we want?
NAME had a long chat about this today. We didn't come to any solid conclusions - the authentication property here is really subtle and the attacker model not yet clear. This is going to need some really careful work and detailed formal analysis to get right. In terms of this discussion, my personal take would be: I don't think a mac & sign approach is going to give you anything strictly better or different than an exporter + signature approach. In both cases its just a question of what you put in the exporter / mac. Having the public key conveyed in the header and bound explicitly in the exporter (rather than via the keyid) seems like a conservative and reasonable approach.
Thanks for thinking through this! I've written up to add the public key to both the context and the header
Code change:
In this scenario, the connection between the browser and Application Server SHOULD be a session cookie provided by the Application Server. <ins> 6.2.1. </ins> Security of the connection between code running in the browser and this Application Server is assumed to utilize browser-level protection mechanisms.  Details are out of scope of this document,

Related discussion:
text: Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy
Code change:
5.2.2. In order to be able to provide addressability either on the stub <del> network or on an adjacent infrastructure network, a stub router MUST </del> <ins> network or on an adjacent infrastructure network, a SNAC router MUST </ins> allocate its own ULA Site Pefix.  ULA prefixes, described in Unique Local IPv6 Unicast Addresses (RFC4193) are randomly allocated prefixes.  A SNAC router MUST allocate a single ULA Site Prefix for

Related discussion:
text: Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)
Code change:
6.1.1.1. <del> AUTHORIZATION INFO parameter (key 0x02) identifies a track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or ANNOUNCE message.  This parameter is populated for cases where the </del> <ins> AUTHORIZATION INFO parameter (Parameter Type 0x02) identifies a track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or ANNOUNCE message.  This parameter is populated for cases where the </ins> authorization is required at the track level.  The value is an ASCII string. 6.1.1.2. <del> The DELIVERY TIMEOUT parameter (key 0x03) MAY appear in a SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message.  It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received.  The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference.  There is no explicit signal that an Object was not sent because the delivery timeout was exceeded. </del> <ins> The DELIVERY TIMEOUT parameter (Parameter Type 0x03) MAY appear in a SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message.  It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received.  The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference.  There is no explicit signal that an Object was not sent because the delivery timeout was exceeded. </ins> If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription.  The publisher SHOULD

Related discussion:
text: Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good
Code change:
fixed "node_certificate" and "signature", and the bytestrings "internal_hash" and "internal_data" provided with the envelope. <del> Produce the receipt using the Service Identifier and this receipt contents. </del> <ins> Produce the receipt using the countersigner protected header and this receipt's contents. </ins> 6.

Related discussion:
text: Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.
Code change:
QUIC and HTTP/3 frames, but called messages to avoid the media terminology. <del> Each stream MUST start with a "HEADERS" message (headers) to indicates how the stream should be transmitted. </del> Messages SHOULD be sent over the same stream if ordering is desired. For example, "PAUSE" and "PLAY" messages SHOULD be sent on the same stream to avoid a race.

Related discussion:
text: Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.
Code change:
5.4.1. The Holder MAY add an optional JWT to prove Holder Binding to the <del> Verifier.  The precise contents of the JWT are out of scope of this specification.  Usually, a </del> <ins> Verifier. 5.4.1.1. This section defines the contents of the Holder Binding JWT. The JWT MUST contain the following elements: * in the JOSE header, * : REQUIRED.  MUST be , which explicitly types the Holder Binding JWT as recommended in Section 3.11 of RFC8725.  * : REQUIRED.  A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry.  MUST NOT be or an identifier for a symmetric algorithm (MAC).  * in the JWT body, * : REQUIRED.  The value of this claim MUST be the time at which the Holder Binding JWT was issued using the syntax defined in RFC7519.  * : REQUIRED.  The intended receiver of the Holder Binding JWT.  How the value is represented is up to the protocol used and out of scope of this specification.  * : REQUIRED.  Ensures the freshness of the signature.  The value type of this claim MUST be a string.  How this value is obtained is up to the protocol used and out of scope of this specification. To validate the signature on the Holder Binding JWT, the Verifier MUST use the key material in the SD-JWT.  If it is not clear from the SD-JWT, HB-JWT MUST specify which key material the Verifier needs to use to validate HB-JWT using JOSE header parameters such as </ins> and <del> claim are included to show that the proof is intended for the Verifier and to prevent replay attacks.  How the </del> <ins> . </ins> <del> or other claims are obtained by the Holder is out of scope of this specification. </del> <ins> Below is a non-normative example of a Holder Binding JWT header: </ins> <del> Example Holder Binding JWT payload: </del> <ins> Below is a non-normative example of a Holder Binding JWT payload: </ins> <del> Which is then signed by the Holder to create a JWT like the following: </del> <ins> Below is a non-normative example of a Holder Binding JWT produced by signing a payload in the example above: </ins> Whether to require Holder Binding is up to the Verifier's policy, based on the set of trust requirements such as trust frameworks it

Related discussion:
text: Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm
Code change:
fields (e.g., "Alt-Svc" RFC7838, "Strict-Transport-Security" RFC6797). <del> Classic HTTP CONNECT proxies can be used to reach a target host that is specified as a domain name or an IP address.  However, because only a single target host can be specified, proxy-driven Happy Eyeballs and cross-IP fallback can only be used when the host is a domain name.  For IP-targeted requests to succeed, the client must know which address families are supported by the proxy via some out- of-band mechanism, or open multiple independent CONNECT requests and abandon any that prove unnecessary. </del> 1.3. This specification describes an alternative mechanism for proxying

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").