jiebi/CodeConvo huggingface dataset:
Code change:
If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del> <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins> <del> does not match one already stored (or partially stored) from a prior request. </del> <ins> does not match one that the client has already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Match header field MUST evaluate the condition as per evaluation prior to performing the method.

Related discussion:
text: Our API servers are light-weight and stateless so this is a huge requirement for us. Instead, we would prefer a way simpler approach of always sending back along with responses, but we need to comply with RFC7232 thus this discussion. So, the proposal is to do one of the following (preferred) Remove the following clause from RFC7232: (If aforementioned clause is kept) Explain the reason of not sending in that sub-condition (at least) Change to in that clause.
These requirements were motivated by a tiny edge case related to protecting partial updates after two clients simultaneously try a PUT. However, I can't remember if it was when one succeeds and one fails, or one or both responses are lost and they try again, or something like that, nor can I remember what difference was made by not sending ETag. Hence, I intend to remove the requirement as being too obscure to implement in a testable way.
Code change:
If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del> <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins> <del> does not match one already stored (or partially stored) from a prior request. </del> <ins> does not match one that the client has already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Match header field MUST evaluate the condition as per evaluation prior to performing the method.

Related discussion:
text: We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?
Code change:
The <del> status code indicates that none of the ranges in the request's header field (field.range) overlap the current extent of the or that the set of ranges requested has been rejected due to invalid ranges or an excessive request of small or overlapping ranges. </del> <ins> status code indicates that the set of ranges in the request's </ins> <del> For byte ranges, failing to overlap the current extent means that the </del> <ins> header field (field.range) has been rejected either because none of the requested ranges are satisfiable or because the client has requested an excessive number of small or overlapping ranges (a potential denial of service attack). </ins> <del> of all of the </del> <ins> Each range unit defines what is required for its own range sets to be satisfiable.  For example, byte.ranges defines what makes a bytes range set satisfiable. </ins> <del> values were greater than or equal to the current length of the selected representation.  When this status code is generated in response to a byte-range request, the sender SHOULD generate a </del> <ins> When this status code is generated in response to a byte-range request, the sender SHOULD generate a </ins> header field specifying the current length of the selected representation (field.content-range).

Related discussion:
text: If the powers that be don't agree that the issue requires fixing, it would be nice to get such feedback explicitly and discuss it. If this issue tracker is inactive and the issue should be posted somewhere else, I'd be happy to do it, just point me in the right direction.
We're not currently working on a revision to this document, so an official answer won't be forthcoming for a while. In the meantime, the best thing to do is to discuss it on list, taking the advice you get there. See Roy's response in particular: URL
Just looked this up to see if it's been forgotten... can I assume from the new labels that it's on someone's todo list and will be looked at eventually, even if it'll take a while longer? (btw the link your referenced actually contains another bug, so I'm referring to both, i.e. the whole discussion).
NAME Thanks for resolving the issues! Better late than never :-) Indeed now there is no longer a self-contradition in the spec, but I'm curious, why did you change your mind since the discussion in the link above, where you seemed to prefer a 200 result for an empty resource (even suggesting a MUST), to the current fix which leans towards the 416 by defining it explicitly as unsatisfiable (with the option 200 downgraded to MAY), or at best makes it a tossup which option servers will implement? Did you have any specific pros/cons or use cases in mind? I guess I still prefer a 200 as the simpler and more straightforward solution :-)
An implementation can choose to send 200. Making that a SHOULD or MUST would be a new normative requirement that isn't justifiable for interop.
ok. Thanks again!
Code change:
and and use them, if present, in constructing an authorization request, <del> which is then conveyed to the authorization server via the user agent in order to obtain a new access token complying with the corresponding requirements.  Both </del> <ins> which is then conveyed to the authorization server's authorization endpoint via the user agent in order to obtain a new access token complying with the corresponding requirements.  Both </ins> and

Related discussion:
text: changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Code change:
filtering (e.g., anti-spam filter), these messages can be blocked and prevented from reaching the end-users.  It may be possible to fine- tune content filtering solutions to detect artefacts like QR codes or <del> user codes that are being reused in multiple messages to disrupt spray attacks. Content filtering may be better suited to interrupt large scale spray attacks since some scenarios may require re-transmission of user, QR and access codes.  Content filtering may also be fragmented across multiple communications systems and channels (e-mail, messaging, text etc), making it harder to detect or interrupt attacks that are executed over multiple channels, unless here is a high degree of integration between content filtering systems. </del> <ins> user codes that are included in a message that is sent to multiple recipients in the expectation that at least one of the recipients will be convinced by the message and grant authroization to access restricted resources. Some scenarios may require legitimate re-transmission of user, QR and authorization data (e.g. retries).  To prevent the disruption of legitimate scenarios, content filters may use a threshold and allow a limited number of messages with the same QR or user codes to be transmitted before interrupting the delivery of those messages. Content filtering may also be fragmented across multiple communications systems and channels (e-mail, messaging, text etc), making it harder to detect or interrupt attacks that are executed over multiple channels, unless here is a high degree of integration between content filtering systems. </ins> 5.1.6.

Related discussion:
text: Instead of referencing spray attacks, describe how they work (see )
Instead of referring to spray attacks, describe how an attacker might use the same QR or user code by sending it to the different recipients.
Code change:
PUSH_PROMISE frames. The body of a PUSH_PROMISE includes a "Promised-Stream-ID".  This <del> unsigned 31-bit integer indentifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see </del> <ins> unsigned 31-bit integer identifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see </ins> StreamCreation). PUSH_PROMISE frames MUST be associated with an existing stream.  If

Related discussion:
text: Fix some typos
"overridden" is the correct spelling; can you remove those changes? Thanks.
NAME it was "overriden", I changed it to "overridden". Am I missing something here?
No, I just need to slow down when I read diffs :) Thanks!
:smile:
Code change:
this ordering during congestion without increasing latency. The encoder determines how to behave during congestion by assigning <del> each object a numeric delivery order.  The delivery order SHOULD be followed when possible to ensure that the most important media is delivered when throughput is limited.  Note that the contents within each object are still delivered in order; this delivery order only applies to the ordering between objects. </del> <ins> each object a numeric send order.  The send order SHOULD be followed when possible to ensure that the most important media is delivered when throughput is limited.  Note that the contents within each object are still delivered in order; this send order only applies to the ordering between objects. </ins> A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (prioritization) such that <del> streams are transmitted in delivery order. </del> <ins> streams are transmitted in send order. </ins> <del> A receiver MUST NOT assume that objects will be received in delivery </del> <ins> A receiver MUST NOT assume that objects will be received in send </ins> order for a number of reasons: <del> Newly encoded objects MAY have a smaller delivery order than </del> <ins> Newly encoded objects MAY have a smaller send order than </ins> outstanding objects. <del> Packet loss or flow control MAY delay the delivery of individual </del> <ins> Packet loss or flow control MAY delay the send of individual </ins> streams. The sender might not support QUIC stream prioritization.

Related discussion:
text: Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.
Code change:
Append the result of running Serializing a Key (ser-key) with member's member_name to output. <del> Append "=" to output. </del> <ins> If member_value is not Boolean true or parameters is not empty: </ins> <del> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> Append "=" to output. </ins> <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> If more members remain in input_dictionary:

Related discussion:
text: For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)
Code change:
On its own, verifying a Transparent Statement does not guarantee that its Envelope or contents are trustworthy.  Just that they have been signed by the apparent Issuer and counter-signed by the Transparency <del> Service.  If the Verifier trusts the Issuer, it can infer that an Issuer's Signed Statement was issued with this Envelope and contents, which may be interpreted as the Issuer saying the Artifact is fit for its intended purpose.  If the Verifier trusts the Transparency Service, it can independently infer that the Signed Statement passed the Transparency Service Registration Policy and that has been persisted in the Append-only Log.  Unless advertised in the Transparency Service Registration Policy, the Verifier cannot assume that the ordering of Signed Statements in the Append-only Log matches the ordering of their issuance. </del> <ins> Service.  If the Verifier trusts the Issuer, after validation of the Issuer identity, it can infer that an Issuer's Signed Statement was issued with this Envelope and contents, which may be interpreted as the Issuer saying the Artifact is fit for its intended purpose.  If the Verifier trusts the Transparency Service, it can independently infer that the Signed Statement passed the Transparency Service Registration Policy and that has been persisted in the Append-only Log.  Unless advertised in the Transparency Service Registration Policy, the Verifier cannot assume that the ordering of Signed Statements in the Append-only Log matches the ordering of their issuance. </ins> Similarly, the fact that an Issuer can be held accountable for its Transparent Statements does not on its own provide any mitigation or

Related discussion:
text: Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".
Code change:
Note that an illegal stream identifier is an identifier for a stream that is not currently in the "idle" state. <del> The PUSH_PROMISE frame can include padding.  Padding fields and flags are identical to those defined for DATA. </del> <ins> The total number of padding octets is determined by the value of the Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </ins> 6.7.

Related discussion:
text: The old text stated padding things were identical to DATA frames. That might not be entirely true. So just spell out the requirements expicitly.
I just realised RFC 7540 was always this way, but it doesn't seem right to me. The DATA frame definition includes normative requirements on sender and receiver using the field. I presume the HEADERS frame is supposed the treat padding the same but it isn't written down. edit: plus PUSH_PROMISE
Ah, it's stated in a separate paragraph at the end of each frame definition section. That's annoying but I guess its fine.
Yeah, so the short answer there is that they behave differently in some ways (at least with respect to flow control). If you think there’s a better way to structure the section I think you’re welcome to take a crack at it.
I didn't actually make the leap to flow control, that makes me more inclined to avoid the cross reference to DATA frames. I made to just make everything explicit at the cost of a few more lines of text.
Code change:
Response: <del> 2.2.4.1. </del> <ins> 2.2.3.1. </ins> If the Signed Statement requested is already included in the Append- Only Log: <del> 2.2.4.2. </del> <ins> 2.2.3.2. </ins> If registration of the Signed Statement requested is in progress but not yet included in the Append-Only Log: <del> 2.2.4.3. </del> <ins> 2.2.3.3. </ins> If the Signed Statement requested is neither registered in the log nor subject to an in-progress registration: <del> 2.2.4.4. </del> <ins> 2.2.3.4. </ins> If a client is polling for an in-progress registration too frequently then the Transparency Service MAY, in addition to implementing rate- limiting, return a 429 response: <del> 2.2.4.5. </del> <ins> 2.2.3.5. </ins> For all responses additional eventually consistent operation details MAY be present.  Support for eventually consistent Receipts is implementation specific, and out of scope for this specification. <del> 2.2.5. </del> <ins> 2.2.4. </ins> This endpoint is used to exchange old or expiring receipts for fresh ones.

Related discussion:
text: Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM
Code change:
are capitalized.  To ensure readability, only a core set of terms is included in this section. <ins> The terms "header", "payload", and "to-be-signed bytes" are defined in RFC9052. </ins> 4. In this document, the definition of transparency is intended to build

Related discussion:
text: !
The diagram reflects my intention.
Here's a slightly modified view to remove the lines behind, add arrows consistenty !
Code change:
This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP <del> authentication schemes which need to return additional information during or after authentication. </del> <ins> authentication schemes which need to return information once the client's authentication credentials have been accepted. </ins> Editorial Note (To be removed by RFC Editor)

Related discussion:
text: Herve, could you please open an issue for this, so that we can assure that we track the underlying issue? It's OK to merge the proposal if the editor feels that it's helpful, but we need to make sure the WG gets consensus here. Thanks,
Linked to issue .
Code change:
FINAL flag is sent.  The active sender on the stream MUST be prepared to receive frames after closing the stream. <del> Either the peer can send a RST_STREAM control frame at any time to </del> <ins> Either peer can send a RST_STREAM control frame at any time to </ins> terminate an active stream.  RST_STREAM contains an error code to indicate the reason for termination.  A RST_STREAM indicates that the sender will transmit no further data on the stream and that

Related discussion:
text: Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.