jiebi/CodeConvo huggingface dataset:
Code change:
willing to accept trailer fields in the forwarded response.  Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the <del> trailer section as a whole will not be dropped by any of the clients. </del> <ins> trailer section(s) will not be dropped by any of the clients. </ins> Because of the potential for trailer fields to be discarded in transit, a server SHOULD NOT generate trailer fields that it believes

Related discussion:
text: Does this mean it's now valid to interleave HTTP/2 DATA frames and HEADER frames?
Does this mean we cannot implement this on HTTP/2?
The feature was removed during WGLC, but no -- it would have required a new frame type.
Okay, so chunk extensions remains a unique feature of HTTP/1 chunked encoding and there is no plan to expand that further?
Yes.
As discussed in and URL, mid-stream trailers (i.e., those that arrive before the end of the payload body) are interesting. A few things to discuss: [ ] What are some potential use cases?[ ] We recently stopped automatically combining trailers into headers, as that created a lot of issues. What about these -- are they yet again distinct from trailers as well as headers? Or can they be "downgraded" into trailers automatically? In other words, when transitioning from a hop that supports these from one that doesn't, are they just dropped onto the floor?[ ] Related - is the expectation that implementations will create separate APIs for these, or would it be that trailers are just available / writable early?[ ] What relationship does one of these have to the payload body? E.g., could I write one that "knows" exactly where in the body it occurs, so that it could sign a chunk of the body relative to it? Or could a handling implementation change its ordering in relation to body bytes?
Some preliminary considerations. Incremental checksums eg. Service management (eg. convey the ETA of the transfer, ...) Sending signatures of partial body (in mid-stream) has some complexities respect to sending a signature of the whole message in the header/trailer section, and requires a security URL trailers, when used for integrity can't be dropped without informing the user agent They probably need to be defined as 1#field-item because mid-stream trailers will be sent multiple times (eg. one per chunk) Whenever they are tied to the partial transmitted representation, they will eventually be unuseful when merged, unless they have some associative propertyThey will be especially useful when tied to a portion of the body They will be significantly less useful when not tied to a portion of the body
Potential use cases mostly limited to long-lived streaming traffic, i.e.
Code change:
willing to accept trailer fields in the forwarded response.  Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the <del> trailer section as a whole will not be dropped by any of the clients. </del> <ins> trailer section(s) will not be dropped by any of the clients. </ins> Because of the potential for trailer fields to be discarded in transit, a server SHOULD NOT generate trailer fields that it believes

Related discussion:
text: long-lived "uploading/downloading" in-band signaling support such as load reporting, app-level flow-control, authn update etc Semantics trailers are a special case of mid-stream metadata, e.g. only trailers are able to convey the status of the entire transaction or the entire resource (body) our experience is that in-order delivery is useful and often assumed, since the underlying transport (for HTTP body) is in-order and reliable. Out-of-order metadata is likely a use case for connection-level metadata, IMO with the above assumption on in-order delivery, you really only need one API for delivering in-stream or trailer metadata Multi-part without in-stream metadata, you would have to use multipart (with all the overhead) for structured data, the original content-type can be preserved, e.g. JSON stream; and for media data, the content-type may have to be application/octet-stream
Copying over the questions from NAME over in URL, as they are good ones:
The semantic model of trailers is that they provide additional metadata that may (or may not) be useful to recipients but was not available prior to the initial body data sent. How the are useful and what they might contain would be defined by the field name. A recipient is free to drop the trailer metadata. A mid-stream trailer frame would have the same role in flow control as a HEADERS frame, which is none at the current time. The proposed frames would not have any specific position, but the values inside trailer fields might identify specific positions (on their own, regardless of framing). A cache would either drop the values or store them separately as trailer fields in the order received.
HTTP/2's flow control only cares about DATA frames. But all frames are subject to TCP's flow control. In HTTP/3, all frames are sent on streams which is subject to QUIC's flow control. Responding to the original question, I don't know what a "new form of flow control" would look like and I don't see how one would improve things.
What's the minimal change that would need to happen to semantics to enable this in a future version of HTTP (or an extension to an existing one)?
I think you would need to make "trailer part" less special, and simply say that a version of HTTP can define a way to carry additional field sections during or after the body.
Code change:
willing to accept trailer fields in the forwarded response.  Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the <del> trailer section as a whole will not be dropped by any of the clients. </del> <ins> trailer section(s) will not be dropped by any of the clients. </ins> Because of the potential for trailer fields to be discarded in transit, a server SHOULD NOT generate trailer fields that it believes

Related discussion:
text: H1-H3 currently define a way to carry only one such block, but an extension could provide more.
Code change:
The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration.  Some Transparency Services may publish every Signed Statement in their logs, to <del> facilitate their dissemination and auditing.  Others may just return Receipts to clients that present Signed Statements for Registration, and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents. </del> <ins> facilitate their dissemination and auditing.  Transparency Services MAY return Receipts to client applications synchronously or asynchronously. </ins> A collection of Signed Statements must not leak information about the contents of other Signed Statements registered on the Transparency

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:
The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration.  Some Transparency Services may publish every Signed Statement in their logs, to <del> facilitate their dissemination and auditing.  Others may just return Receipts to clients that present Signed Statements for Registration, and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents. </del> <ins> facilitate their dissemination and auditing.  Transparency Services MAY return Receipts to client applications synchronously or asynchronously. </ins> A collection of Signed Statements must not leak information about the contents of other Signed Statements registered on the Transparency

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:
The Transparency Service is trusted with the confidentiality of the Signed Statements presented for Registration.  Some Transparency Services may publish every Signed Statement in their logs, to <del> facilitate their dissemination and auditing.  Others may just return Receipts to clients that present Signed Statements for Registration, and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents. </del> <ins> facilitate their dissemination and auditing.  Transparency Services MAY return Receipts to client applications synchronously or asynchronously. </ins> A collection of Signed Statements must not leak information about the contents of other Signed Statements registered on the Transparency

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.
Code change:
example: Members whose value is Boolean true MUST omit that value when <del> serialised, unless it has Parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has Parameters: </del> <ins> serialised.  For example, here both "b" and "c" are true: </ins> Note that this requirement is only on serialisation; parsers are <del> still required to correctly handle the true value when it appears in Dictionary values. </del> <ins> still required to correctly handle the true Boolean value when it appears in Dictionary values. </ins> A Dictionary with a member whose value is an Inner List of tokens:

Related discussion:
text: Ping NAME
LGTM from here, thanks!
Julian asked in e-mail why we can't have a dictionary with a default True value that is parameterised:
I think we could replace: With:
NAME NAME NAME thoughts?
Example-Field: ;param=on-default-boolean Is this a dictionary? What is the key here? (I see that the value is supposed to be implicit true, but I'm not grokking the implied syntax) If I ignore that (assuming I've misinterpreted something), I like the idea of allowing implicit True. The serialization algorithm needs a bit more surgery to support this as the canonical form, probably replacing: with something like: (unless we also modify Serializing an Item to optionally omit True values, but we can't just do that unconditionally, or else a simple Item header would be empty if True.) This is the same issue as URL, I think -- back in December you thought that it would take more drastic changes. If this is everything that it needs, though, it seems reasonable. None of the canonical tests break with this (except for a couple of serialization tests, which just need to be updated), and I don't see any obvious cases that would be parsed incorrectly.
Sorry, that was unrelated, accidentally copied from the email. Ignore. I'll work up a PR and see how it looks.
Awesome. Now, how about also collapsing the "false" value a bit. So instead of having a=?0 just say !a ?
IMHO explicit is better than implicit: I am not sure that is a good choice. I am not even sure that defaulting is a good choice.
Tantalizingly close to making Dictionary a superset of List. I can't think of anything that would break.
Code change:
5.3. <del> TODO: This section shall cover aspects of relay failover and protocol interactions. 5.4. TODO: This section shall cover reconnect considerations for clients when moving between the Relays. 5.5. </del> TODO: Refer to priority-congestion.  Add details to describe relay behavior when merging or splitting streams and interactions with congestion response. <del> 5.6. </del> <ins> 5.4. </ins> MOQT encodes the delivery information for a stream via OBJECT headers (message-object).

Related discussion:
text: I believe some of this is covered by the recently updated GOAWAY section and I'm not sure what else to add here.
I don't think these TODOs have been covered yet. That being said, I would rather we file issues for these so there can be a conversation, rather than litter the draft with TODOs.
I'm unsure what's unresolved, but if you can file new issues as appropriate and link them to this PR, that would be helpful.
Code change:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code) <ins> 421 Misdirected Request (status code) </ins> 422 Unprocessable Payload (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)

Related discussion:
text: I haven't checked the errata yet, but I have to go now and this is worth reviewing.
Maybe end the last paragraph with: "Because of this default, senders in general should mark it as non-cacheable using ...".
sry, accidentally merged early; we still need to deal with the erratum
I don't understand what happened here, but master does not contain the changes that github thinks have been merged.
Yes, I tried to undo my mistake.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
A much belated approval from me. This looks good.
Code change:
416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code) <ins> 421 Misdirected Request (status code) </ins> 422 Unprocessable Payload (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)

Related discussion:
text: This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
Code change:
The component identifier is a dictionary member identifier or a named query parameter identifier that references a member that is not present in the component value, or whose value is malformed. <del> E.g., the identifier is ""example-dictionary";key="c"" and the value of the "Example-Dictionary" header field is "a=1, b=2", which does not have the "c" value. </del> <ins> E.g., the identifier is ""example-dict";key="c"" and the value of the "Example-Dict" header field is "a=1, b=2", which does not have the "c" value. </ins> In the following non-normative example, the HTTP message being signed is the following request:

Related discussion:
text: Update query parameter generation in examples,
I verified that B.2.3 is fixed, but did not implement the "ttrp" example.
The Example from uses the following request defined in B.2 The signing string is meant to be But that does not work because in the request we have and the date in the signing string is one minute later
Thanks, all the examples need to get re-generated and I'll work on that soon. The current generation script is at URL ... it's very manual right now but I'm thinking of reworking it to do actual HTTP message parsing under the hood like we have at URL instead, so we don't end up with inconsistencies like this in the results.
I am also developing a test suite for the examples in the spec, which is why I am reporting the bugs I find here :-) That can help you later verify that your new setup is correct. I just found a last error in the Signing String. The Signing string given there is my test tells me that the diff should be: But the implementation having is correct I think.
Examples have been regenerated by , please check the new example for consistency.
Just saw this other comment, yes it looks like there's a bug in the query value generator that drops the question mark!
Btw. My EU project just ended, so I am looking for extension projects. But perhaps someone here knows companies that need me to work on the implementation? (Ie,Java or JS or Scala)... I don't really know where one can ask this. A bit of a specialized thing :-)
NAME please check the updated examples in -- I re-ran the script with some bugfixes in place which should fix both B.2.3 and the TTRP example in the appendix.
Code change:
Because unsafe request methods (safe.methods) such as PUT, POST or DELETE have the potential for changing state on the origin server, <del> intervening caches can use them to keep their contents up to date. </del> <ins> intervening caches are required to invalidate stored responses to keep their contents up to date. means that the cache will either remove all stored responses whose target URI matches the given URI, or will mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. Note that this does not guarantee that all appropriate responses are invalidated globally; a state-changing request would only invalidate responses in the caches that it travels through. </ins> <del> A cache MUST invalidate the effective Request URI (effective.request.uri) as well as the URI(s) in the </del> <ins> A cache MUST invalidate the target URI (target.resource) as well as the URI(s) in the </ins> and

Related discussion:
text: NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.