jiebi/CodeConvo huggingface dataset:
Code change:
waiting for a "401 (Unauthorized)" response before each new connection through the proxy. <ins> 3.4. Unlike the datagram-oriented templated HTTP proxying specifications CONNECT-IP, this specification does not make use of the Capsule Protocol RFC9297.  A future specification could define a procedure for performing TCP proxying using the Capsule Protocol, but no such procedure is defined here. When implementing this specification, clients and servers MUST NOT send a "Capsule-Protocol: ?1" header field. </ins> 4. This section discusses some behaviors that are permitted or

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:
waiting for a "401 (Unauthorized)" response before each new connection through the proxy. <ins> 3.4. Unlike the datagram-oriented templated HTTP proxying specifications CONNECT-IP, this specification does not make use of the Capsule Protocol RFC9297.  A future specification could define a procedure for performing TCP proxying using the Capsule Protocol, but no such procedure is defined here. When implementing this specification, clients and servers MUST NOT send a "Capsule-Protocol: ?1" header field. </ins> 4. This section discusses some behaviors that are permitted or

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:
most situations, violating field-specific constraints should have the same effect.  Thus, if a header is defined as an Item and required to be an Integer, but a String is received, the field will by default be <del> ignored.  If the field requires different error handling, this should be explicitly specified. </del> <ins> ignored.  If the field requires different handling for type mismatches it should be explicitly specified, but note that field definitions cannot override how parsing failures are handled. </ins> Both Items and Inner Lists allow parameters as an extensibility mechanism; this means that values can later be extended to

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:
Transparency Services MUST also maintain a list of trust anchors, which SHOULD be used by Relying Parties to authenticate Issuers, and which MAY be included in a Registration Policy statement.  For <del> instance, a trust anchor could be an X.509 root certificate, the discovery URL of an OpenID Connect identity provider, or any other COSE compatible PKI trust anchor. </del> <ins> instance, a trust anchor could be an X.509 root certificate, a pointer to an OpenID Connect identity provider, or any other COSE- compatible trust anchor. </ins> Registration Policies and trust anchors MUST be made transparent and available to all Relying Parties of the Transparency Service by

Related discussion:
text: I don't understand the motivation behind replacing "any other COSE compatible PKI trust anchor." with "a JSON Web Key Set". Is there an issue with COSE compatible PKI trust anchors that is driving this change?
NAME : What is an example of a "any other COSE compatible PKI trust anchor." besides the JSON Web Key Set?
Good question NAME if JSON Web Key Set is indeed the only possible COSE compatible PKI trust anchor then I see no issues with this change.
I support Steve's suggested change.
I think the point here is to keep it open and not limit to what exists today.
NAME I have not worked on COSE for one minute, but I get the impression that a SCITT Transparency statement could include identities other than X.509, which seems to imply that another form of "trust anchor" is plausible, i.e. a PGP chain of Trust or even a SCITT trusted party - am I mistaken.
These are just examples anyway and as such the list is unbounded. But if you give examples, as you do today, then it better might be good to give examples that are understandable by readers. That is what I have been trying to do. I listed the only COSE example I am aware of.
LGTM to changes
Code change:
user's bookmarks/favorites), the user agent MUST either exclude the Referer header field or send it with a value of "about:blank". <ins> The Referer header field value need not convey the full URI of the referring resource; a user agent MAY truncate parts other than the referring origin. </ins> The Referer header field has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals

Related discussion:
text: defines Referer and says: There are two other things that I think are relevant to mention here: Referer is often suppressed when the referring resource is "https" at a different origin than the request target. Referer can contain only an origin rather than the referring resource identity. might not be worth citing here as it is probably too specific to browsers, but these other constraints are worth noting. Especially the first as this has real security consequences. Though the text in is excellent as a high-level principle, the steps that are taken to avoid URI leakage are meaningful and very relevant to this section.
Is that "often suppressed" or "always suppressed by good user agents"? I agree that we should update Referer to be consistent with current privacy guidelines.
It is "always suppressed by good user agents, unless the referring origin explicitly asks for it not to be suppressed". These go beyond privacy guidelines into security. Despite the general acknowledgments of the position stated in Section 17.9, there are still resources that leak security-sensitive information through their URL. The notion of a capability URL remains a powerful, and widely used, tool.
Code change:
promised streams fully close as well. PUSH_PROMISE uses the same flags as the HEADERS frame, except that a <del> PUSH_PROMISE frame with a CONTINUES bit MUST be followed by another PUSH_PROMISE frame.  See HEADERS for any flags. </del> <ins> PUSH_PROMISE frame without the END_HEADERS flag set MUST be followed by another PUSH_PROMISE frame.  See HEADERS for any flags. </ins> Promised streams are not required to be used in order promised.  The PUSH_PROMISE only reserves stream identifiers for later use.

Related discussion:
text: This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.
Code change:
Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the TTRP was mutually-authenticated and, if so, the certificate thereby <del> presented by the client. Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </del> <ins> presented by the client.  Access control decisions based on the client certificate (or lack thereof) can be conveyed by selecting response content as appropriate or with an HTTP 403 response, if the certificate is deemed unacceptable for the given context.  Note that TLS clients that rely on error indications at the TLS layer for an unacceptable certificate will not receive those signals. </ins> When the value of the "Client-Cert" request header field is used to select a response (e.g., the response content is access-controlled),

Related discussion:
text: update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204
Code change:
Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the TTRP was mutually-authenticated and, if so, the certificate thereby <del> presented by the client. Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </del> <ins> presented by the client.  Access control decisions based on the client certificate (or lack thereof) can be conveyed by selecting response content as appropriate or with an HTTP 403 response, if the certificate is deemed unacceptable for the given context.  Note that TLS clients that rely on error indications at the TLS layer for an unacceptable certificate will not receive those signals. </ins> When the value of the "Client-Cert" request header field is used to select a response (e.g., the response content is access-controlled),

Related discussion:
text: If a client without a client cert would see a 403, then I think it makes sense to mention that sending a 403 is what would reasonably happen here. I don't know if clients would do something automatically, but presenting the 403 error at least indicates that authentication was the problem.
PR basically adds this sentence, "Access control decisions based on the client certificate (or lack thereof) can be conveyed by selecting response content as appropriate or with an HTTP 403 response, if the certificate is deemed unacceptable for the given context."
This is sufficient. A similar experience exists today when a client presents a certificate which is valid, but which does not grant access to the requested resource. While it's not ideal in certain ways -- the client might possess other certificates that would grant access if given an appropriate selector -- the server might also prefer not to share that list. This draft isn't attempting to create new solutions from scratch -- it's attempting to outline what is currently done in assorted custom ways to help coalesce these into a single format. Those custom mechanisms don't provide TLS alert translation either, so far as I'm aware.
Code change:
Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the TTRP was mutually-authenticated and, if so, the certificate thereby <del> presented by the client. Forward proxies and other intermediaries MUST NOT add the "Client- Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. </del> <ins> presented by the client.  Access control decisions based on the client certificate (or lack thereof) can be conveyed by selecting response content as appropriate or with an HTTP 403 response, if the certificate is deemed unacceptable for the given context.  Note that TLS clients that rely on error indications at the TLS layer for an unacceptable certificate will not receive those signals. </ins> When the value of the "Client-Cert" request header field is used to select a response (e.g., the response content is access-controlled),

Related discussion:
text: Martin kindly suggested that I was making this too complicated and to just make the change (paraphrasing). I've tried to do that with changes in PR .
This works well enough on the critical points. Some points about readability though.
Code change:
that is supporting a software package management system, might be referenced from the APIs exposed for package management.  Providing an ability to request a fresh receipt for a given software package, <del> or to request a list of Signed Statements and Artifacts associated with a software package. </del> <ins> or to request a list of Signed Statements associated with the software package. </ins> 4.2.

Related discussion:
text: from :
MUST and "enough" does not seem suffiMay be we have to tighten up the you can retrieve the signed statement to something in the future that may only get the hashmore correct than before, still a MUST that is tad bit hard to follow. the change in this scope is okay
Code change:
9.3.2. The HEAD method is identical to GET except that the server MUST NOT <del> send content in the response and the response always terminates at the end of the header section.  HEAD is used to obtain metadata about </del> <ins> send content in the response.  HEAD is used to obtain metadata about </ins> the without transferring its representation data, often for the sake of

Related discussion:
text: Though I think that this text is correct, an HTTP/3 response only ends when the stream is closed, not at the end of the header section. I think that it's not necessary to say this bit anyway.
The related parts were done in so this bit can be applied now as editorial.
Code change:
"400 Bad Request" to the ALTO client; the body of the response follows the generic ALTO error response format specified in Section 8.5.2 of RFC7285.  Hence, an example ALTO error response has <del> the format: </del> <ins> the format shown in ex-bad-reques. </ins> Note that "field" and "value" are optional fields.  If the "value" field exists, the "field" field MUST exist.

Related discussion:
text: Please add captions to all figures and call them in the text rather than "below" thing :-) Thanks.
Code change:
supports HTTP/2. The means by which support for HTTP/2 is determined is different for <del> "http" and "https" URIs.  Discovery for "http" URIs is described in discover-http.  Discovery for "https" URIs is described in discover- https. </del> <ins> "http" and "https" URIs.  Discovery for "https" URIs is described in discover-https.  HTTP/2 support for "http" URIs can only be discovered by out-of-band means, and requires prior knowledge of the support as described in known-http. </ins> 3.1.

Related discussion:
text: HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.
Code change:
6.3. <del> TBD </del> <ins> The Referenced Token MUST be encoded as a "COSE Web Token (CWT)" object according to RFC8392. The following content applies to the JWT Claims Set: "1" (issuer): REQUIRED.  Same definition as "iss" claim in (#referenced-token-jwt). "TBD" (status): REQUIRED.  The status claim is encoded as a "Status" CBOR structure and MUST include at least one data item that refers to a status mechanism.  Each data item in the "Status" CBOR structure comprises a key-value pair, where the key must be a CBOR text string (Major Type 3) specifying the identifier of the status mechanism, and the corresponding value defines its contents.  This specification defines the following data items: "status_list" (status list): REQUIRED when the status list mechanism defined in this specification is used.  It has the same definition as the "status_list" claim in (#referenced- token-jwt) but MUST be encoded as a "StatusListInfo" CBOR structure with the following fields: "idx": REQUIRED.  Same definition as "idx" claim in (#referenced-token-jwt). "uri": REQUIRED.  Same definition as "uri" claim in (#referenced-token-jwt). Application of additional restrictions and policy are at the discretion of the verifying party. The following is a non-normative example for a decoded payload of a Referenced Token: TBD: example 6.4. The Referenced Token MUST be encoded as a "COSE_Sign1" or "COSE_Sign" CBOR structure as defined in "CBOR Object Signing and Encryption (COSE)" RFC8152. It is required to encode the status mechanisms Referenced Tokens refer to using the "Status" CBOR structure defined in (#referenced- token-cwt). It is RECOMMENDED to use "status" for the label of the field that contains the "Status" CBOR structure. Application of additional restrictions and policy are at the discretion of the verifying party. The following is a non-normative example for a decoded payload of a Referenced Token: TBD: example </ins> 7.

Related discussion:
text: In fact COSE is already mentioned at all places, so the question is whether we should align things and say Referenced Token = JOSE/COSE-based
Use reference to RFC9052 instead of RFC8152
As described in the title, detail the CWT representation of the status list which is complementary to the JWT representation.
Maybe a naive question but what's the motivation for this draft having the two representations? When positioned as a companion of the SD-JWT VC draft and aiming for the OAuth WG, it seems like keeping the scope tighter and only having the JWT representation would be sufficient/okay/preferable.
NAME credential formats like mDocs do not have a status/revocation mechanism hence a CWT based representation is beneficial to these applications as they dont typically have JWT support.
I dunno, I'm not convinced that necessitates having multiple status list token representations. Especially in one draft. This draft, which again is being positioned as a companion to the SD-JWT VC. I suspect the work would be more palatable for adoption with a scope that's reflective of that. But maybe that's just me. Thanks for the context.
Code change:
should be supported, but further extended metadata of the contents of the media or its ontology should not be supported. <del> 4.4. </del> <ins> 4.5. </ins> Packaging of media describes how encapsulation of media to carry the raw media will work.  There are at a high level two approaches to

Related discussion:
text: This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.
Code change:
credentials to a counterfeit client after obtaining resource owner authorization. <del> The authorization server MAY establish a client authentication method with public clients, which converts them to credentialed clients. However, the authorization server MUST NOT rely on credentialed client authentication for the purpose of identifying the client. </del> The client MUST NOT use more than one authentication method in each request to prevent a conflict of which authentication mechanism is authoritative for the request.

Related discussion:
text: OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.