jiebi/CodeConvo huggingface dataset:
Code change:
and from those without.  This might be used to reveal which Client Hints are in use, allowing researchers to further analyze that use. <ins> 5. While HTTP header compression schemes reduce the cost of adding HTTP header fields, sending Client Hints to the server incurs an increase in request byte size.  Servers SHOULD take that into account when opting in to receive Client Hints, and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes. Due to request byte size increase, features relying on this document to define Client Hints MAY consider restricting sending those hints to certain request destinations FETCH, where they are more likely to be useful. </ins> 6. This document defines the "Accept-CH" HTTP response field, and

Related discussion:
text: When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).
Code change:
This document establishes a registry for frame types, settings, and error codes.  These new registries appear in the new "Hypertext <del> Transfer Protocol version 2 (HTTP/2) Parameters" section. </del> <ins> Transfer Protocol version 2 (HTTP/2)" section. </ins> This document registers the

Related discussion:
text: From IANA: As we have the patient open already, it might be OK to change the registry name to follow modern conventions.
To clarify, IANA would like us to delete the word "Parameters" from the following text?
Code change:
padding attack would be rejected by the field value processor, even in the case where the attacker could force a signature collision. <ins> 7.5.8. The HTML form parameters format defined in the "application/x-www- form-urlencoded" section of HTMLURL, is widely deployed and supported by many application frameworks.  For convenience, some of these frameworks in particular combine query parameters that are found in the HTTP query and those found in the message content, particularly for POST message with a Content-Type value of "application/x-www- form-urlencoded".  The "@query-param" derived component identifier defined in content-request-query-param draws its values only from the query section of the target URI of the request.  As such, it would be possible for an attacker to shadow or replace query parameters in a request by overriding the signed query parameter with an unsigned form parameter, or vice versa. To counter this, an application needs to make sure that values used for the signature base and the application are drawn from a consistent context, in this case the query component of the target URI.  Additionally, when the HTTP request has content, an application should sign the message content as well, as discussed in security- message-content. </ins> 8. 8.1.

Related discussion:
text: Point out that many frameworks smush together form parameters and query parameters into one bucket, and that can cause unexpected shadowing. Some examples changed to avoid ambiguity.
This is great.
Code change:
When an "http" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the host identifier to an IP address, establishing a TCP connection to <del> that address on the indicated port, and sending an HTTP request message to the server containing the URI's identifying data. </del> <ins> that address on the indicated port, and sending over that connection an HTTP request message containing a request target that matches the client's target URI (target.resource). </ins> If the server responds to such a request with a non-interim HTTP response message, as described in status.codes, then that response is

Related discussion:
text: In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.
Code change:
Let REQUEST_DEST be the value of the destination for the current request. <del> If DEST is not an empty string and If DEST and REQUEST_DEST are not the same value, return FALSE </del> <ins> If DEST is not an empty list and if REQUEST_DEST is not in the DEST list of destinations, return FALSE </ins> Let BASEURL be the URL of the dictionary request.

Related discussion:
text: This changes the field to be a list of destination strings to allow for matching multiple destinations (i.e. document and frame). This allows for matching an empty destination explicitly using an empty string. e.g.
NAME could you PTAL and see if this looks OK for the destination matching?
The spec of compression dictionary transport says: But an empty "" is used for some features such as , , , , , Cache API, Download, prefetch and prerender. (See this ). So currently there is no way to set up a dictionary for such destinations. For example, I want to use a dictionary for fetch() API, but I don't want to use the dictionary for HTML documents. NAME How about using a string "empty" for such empty destination? We are already using "empty" for header of empty destination request. URL Also if we don't need to use an empty string "" for , I think should be a instead of a . We don't need to use double quotes.
Having special values feels a bit strange, particularly since it's only defined in the internal processing part of the w3c spec. If we use a list of strings we can use for an explicit empty destination and use an empty list for matching everything (and as the default). Does that seem reasonable?
OK, sounds reasonable. Thanks.
option was introduced in the Compression Dictionary Transport spec by . But if my understanding is correct, currently it is not allowed to setting multiple types of destinations. So if I want to use a dictionary for HTML files including top frame, and , I need to download the dictionary three times. NAME How about allowing setting multiple types of destinations? Example:
Sounds good (though document/frame is probably the only practical use case). I'll switch it to an inner-list of tokens.
lgtm Sorry for the late reply.
Code change:
A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts <del> secured responses to those requests. </del> <ins> secured responses to those requests.  Note that the definition of what cryptographic mechanisms are acceptable to client and server are usually negotiated and can change over time. </ins> Resources made available via the "https" scheme have no shared identity with the "http" scheme.  They are distinct origins with

Related discussion:
text: In the definition of the https scheme, the phrase "strong encryption" is used. This implies some sort of judgment. I think that the key is that both client and server need to agree on the adequacy of the protections. Noting that this might be contextual is somewhat obvious at that point, but I thought it might be worth pointing out that what is generally acceptable might change over time.
Code change:
authentication, integrity and confidentiality such as Transport-Layer Security RFC8446, to protect the exchange of clear-text credentials and tokens either in the content or in header fields from <del> eavesdropping, tampering, and message forgery (eg. see client-secret, authorization_codes, token-endpoint, and bearer-tokens). </del> <ins> eavesdropping, tampering, and message forgery (e.g., see client- secret, authorization_codes, token-endpoint, and bearer-tokens). </ins> OAuth URLs MUST use the "https" scheme except for loopback interface redirect URIs, which MAY use the "http" scheme.  When using "https",

Related discussion:
text: 657c1b620170b7034d0787ef711218c69572dc51 - Changes "eg." to "e.g.,". 5289949541404795e56cea41f688d43c272b2ab4 - Changes "e.g." to "e.g.,"
Code change:
A proposed congestion control algorithm SHOULD consider coexistence with widely deployed real-time congestion control algorithms. <del> Regrettably, at the time of writing, many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion control algorithms have incomplete public specifications.  It is hoped this situation will change. </del> <ins> Regrettably, at the time of writing (2024), many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion control algorithms have incomplete public specifications.  It is hoped this situation will change. </ins> To the extent that behavior of widely deployed algorithms is understood, a proposed congestion control algorithm can analyze and

Related discussion:
text: Thanks for the edits. I am a big fan of losing fewer words, so I reverted changes that went in the wrong direction.
Code change:
the resource when no content coding is applied (eg.  "Content- Encoding: identity") <del> Reference: FIPS180-3, RFC4648, this document. </del> <ins> Reference: RFC6234, RFC4648, this document. </ins> Status: standard

Related discussion:
text: Simplifies references to sha algorithms pointing to RFC 6234 instead of FIPS180 documents.
NAME ping :)
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
Code change:
Within the same Group, and the same priority level, Objects with a lower Object Id are always sent before objects with a higher Object <del> Id, regardless of the specified Group Order.  If the priority varies within a Group, higher priority Objects are sent before lower priority Objects. </del> <ins> Id, regardless of the specified Group Order.  If the group contains more than one Peep and the priority varies between these Peeps, higher priority Peeps are sent before lower priority Peeps, and Objects in peeps are sent in increasing Object Id order. </ins> The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and instead an UNSUBSCRIBE and SUBSCRIBE can be used.

Related discussion:
text: I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments
Code change:
framing of responses that depends on the corresponding request (such as HEAD) or the value of the status code (such as 204 or <del> 304) </del> <ins> 304); these responses use the same framing as all other messages </ins> Some of these features are also absent in HTTP/2 and HTTP/3.

Related discussion:
text: The original framing might have implied that they can't be sent, where it's just that they are the same as anything else.
In s 6: This is just a bit weird -- some may read it to mean that these messages can't be conveyed in this format.
Code change:
There are many ways that a client could discover the alternative service(s) associated with an origin.  This document describes two such mechanisms: the "Alt-Svc" HTTP header field (alt-svc-field) and <del> the "ALTSVC" HTTP/2 frame type (ALTSVC-frame). </del> <ins> the "ALTSVC" frame type for HTTP/2 and HTTP/3 (ALTSVC-frame). </ins> The remainder of this section describes requirements that are common to alternative services, regardless of how they are discovered.

Related discussion:
text: The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.
Code change:
4.3. <del> The client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent Statement by adding the Receipt to the Unprotected Header of the Signed Statement. </del> <ins> Client applications MAY register Signed Statements on behalf of one or more Issuers.  Client applications MAY request Receipts regardless of the identity of the Issuer of the associated Signed Statement. </ins> When a Signed Statement is registered by a Transparency Service a Receipt becomes available.  When a Receipt is included in a Signed

Related discussion:
text: This is an alternate proposal to to This PR: Keeps Client as : an application making protected Transparency Service resource requests on behalf of the resource owner and with its authorization. Replaces Verifier with Relying Party: a relying party depends on Signed or Transparent Statements to verify an Artifact.,
Thanks, NAME Definitely looking for more input, and I’m also ok to close the PRs and issue and use the existing terminology. My main concern is a Relying Party is a consumer of information. They rely on the receipts and signed statements from the Transparency Service. Which makes it a good candidate to replace Verifier If we replace Client with Relying Party, this confuses what we call the entity that registers signed statements. They are not the issuer, as the issuer signs statements, but is not the entity with access rights to the Transparency Service. Both the producer and consumer need access rights. That was what we had as client.
There is still additional work that needs to be done. Client applications submit signed statements, and obtain receipts, so they can include transparent statements in downstream products. A consumer of a downstream product is a relying party, they either verify the transparent statements themselves, or they delegate the verification role to the "verifier" role.
As discussed on today's call. Folks expressed concern that "Verifier" was not friendly enough to "Consumers or Relying Parties", that are supposed to process receipts. Editors Update: We can choose to: [ ] Accept [ ] Accept [ ] Close both PRs and this issue, and keep the doc with Client and Verifier
NAME wanted to take a look for a proposal
Just an update, I plan to send a PR with proposed changes this week. NAME shall we sync up in the comments or out of band elsewhere?
A.J. Yes, let’s get together and work out a proposal. I’m booked today but tomorrow is open except for 07:00-08:00 and 14:00-15:00 PST (10:00-11:00 and 17:00-18:00 EST) Monty
Sorry, NAME I had to dig a bit to find your email in my inbox from the mailing lists but I found it. Invite sent. I think we can make quick progress and draft a PR tomorrow.
Code change:
4.3. <del> The client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent Statement by adding the Receipt to the Unprotected Header of the Signed Statement. </del> <ins> Client applications MAY register Signed Statements on behalf of one or more Issuers.  Client applications MAY request Receipts regardless of the identity of the Issuer of the associated Signed Statement. </ins> When a Signed Statement is registered by a Transparency Service a Receipt becomes available.  When a Receipt is included in a Signed

Related discussion:
text: Met with NAME and we discussed perspectives and work on this in the near-term, summarized with URL More to follow.
Adding some more notes to plot out the work, Monty and I discussed aligning the diagram with the separate/distinct RATS architecture, but the separate call out of a distinct Relying Party role and how it pertains to agent was discussed when we met, per discussion I missed in today's author/editor meeting. For my future reference, I need to re-review the doc, as well as compare/contrast ,
So I did not make as much tangible progress today and have spent a lot of time thinking and reading as I re-read this SCITT Architecture draft and related WG drafts (RATS, OAuth) where Relying Party is defined. So, before I spend a significant effort in drawing this with aasvg, I would like to quickly highlight the gaps in my understanding via Mermaid so I can quickly iterate. I have tried reading the mailing list but it not 100% clear where the dichotomy between Auditor and Verifier occurred, but they seem overlapping and redundant to me unless Verifier is, in fact, some non-person entity, like the software doing the verification itself (so this goes to what should we rename client to in , separate of this), but does that not in fact mean Auditor is the Relying Party of sorts? It seems Auditor is just giving a specific name to a general kind of consumer and that is not what a Verifier is. So on that note, this is the current version of the SVG diagram in Mermaid ( I hope I got this right, I cannot just have labels like "Issuer" on the left-hand side so I use subgraphs to box those and not do something clever with dotted lines and cause more problems). (Source: URL) It would seem we really need to change the diagram and the terminology to get rid of Auditor altogether, so first, we would move to this. (Source: URL) I was going to do a subsequent edit, but at this point I will have to ask the group: what is a verifier doing that is different from a relying party owner with a relying party? Could you separate one from the other? (Don't you need to replay the log to verify the sequence of statements?)
Code change:
4.3. <del> The client (which is not necessarily the Issuer) that registers a Signed Statement and receives a Receipt can produce a Transparent Statement by adding the Receipt to the Unprotected Header of the Signed Statement. </del> <ins> Client applications MAY register Signed Statements on behalf of one or more Issuers.  Client applications MAY request Receipts regardless of the identity of the Issuer of the associated Signed Statement. </ins> When a Signed Statement is registered by a Transparency Service a Receipt becomes available.  When a Receipt is included in a Signed

Related discussion:
text: For reference, there is so much overlap with I think we need to either add compare statements to terminology and touch up the current state diagram to disambiguate the use of these terms. Screenshot below. ! So would that mean, if they are in fact separate, Edit 2 incrementing after Edit 1 to reflect my understanding would be ... this? (Source: URL) If we start to think this way, do we consider the software (client/agent/what have you) used by the Issuer to be distinct? Similar but with one of two functionalities (an agent/client/what have you can be for Issuers to get receipts of signed statements or a verifier that reads all of them)? /cc NAME I am not sure this update at the end of the day reflects our discussion, but I feel like I lost the thread of what we discussed and seemed concrete in discussion. Translating it into diagram and wording updates has left me scratching my head.
And just for the sake of dissing RATs... ! IMO this is reversed... to rely on something you must trust a verifier or be a verifier. I think what they mean is for the relying party to depend on a verifier, but what it looks like is that a verifier sits in front of an RP.
A verifier can be a person or automation that was configured by a person. This is likely a great conversation for the NAME would you be able to lead that discussion with NAME
hm... if we are talking RATS an entity can take on both the Roles of Verifier and Relying Party at the same time (rendering the creation and conveyance of Attestation Results moot)
It seems now obsoletes the diagrams in URL and review in a previous meeting reflecting improvements and viable changes based upon answers to the questions posed in strawman diagrams in that comment.
Also of not my updates to the potential (and beneficial) overlap and possible alignment between relying party and client per URL
Ping NAME NAME
I wrote some of my thoughts on URL and aj-stein-nist/ietf-wg-scitt, but for me Client was going to replace Relying Party (Client==RP), so I am not sure if making Verifier==RP is what my intent was when I revived the issue, so I will leave to others to decide.