jiebi/CodeConvo huggingface dataset:
Code change:
Response MAY be compressed by an available dictionary. <del> 6.3.2.2. </del> <ins> 8.3.2.2. </ins> For requests that are not same-origin (same-origin), the "mode" of the request can be used to determine the readability of the response.

Related discussion:
text: Consequently, by the time the payload to compress reaches 1 MB, it should already contain all references it needs to compress the rest of the file. I would not expect a large impact of the custom dictionary beyond that point, let alone beyond 8 MB. The plan would be for the library to do this adaptation automatically. The user would not have to know anything about it, though it's better if the user understands that the library selects the closest window size which is <= to the limit, so that they are not surprised if, upon inspection, the final window size is not byte-identical to the set limit. A good API documentation will likely help to reach this objective If by implementors you mean "server side programmers", they would have to know what's the implicit window size limit when a client requests a format (essentially the rule you are currently defining). Then they would set this limit as a compression parameter, and the library will take care of the adaptation into window size.
Yes. (Keeping in mind of course that most traffic in question will presumably be under the 8 MB floor and so none of this complexity will apply.) Right now the zstd library has limited controls about setting detailed window constraints. We'll need to add a new option to give users that fine-grained control. We can do that with an eye towards user simplicity. Frankly, I'm also very open to also adding a flag (and equivalent compression parameter in the library) that would just look at the size of the dictionary (which zstd necessarily has access to) and would configure the window accordingly. In that case, users wouldn't have to do any math at all.
OK, I chaged the structure and language so that they are no longer streams of bytes compressed with a given algorithm but are now specifically and . The references for those named formats have the window restrictions (which for Zstandard includes the 1.25x dictionary requirement). Currently the byte stream itself is still a native Brotli/Zstandard stream, just with specific settings but this also makes it cleaner if we decide to . PR with the update is here: URL
lgtm with nits, thank you!LGTM!
Code change:
5.2. <del> This document defines the Signature header field, whose value contains a list of named parameters.  IANA is asked to create and maintain a new registry titled "HTTP Signature Parameters" to record and maintain the set of named parameters defined for use within the Signature header field.  Initial values for this registry are given in iana-param-contents.  Future assignments and modifications to existing assignment are to be made through the Expert Review registration policy RFC8126 and shall follow the template presented in iana-param-template. </del> <ins> This document defines the "Signature-Input" Structured Header, whose member values may have parameters containing metadata about a message signature.  IANA is asked to create and maintain a new registry titled "HTTP Signature Metadata Parameters" to record and maintain the set of parameters defined for use with member values in the "Signature-Input" Structured Header.  Initial values for this registry are given in iana-param-contents.  Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy RFC8126 and shall follow the template presented in iana-param-template. </ins> 5.2.1. 5.2.2. The table below contains the initial contents of the HTTP Signature <del> Parameters Registry.  Each row in the table represents a distinct entry in the registry. </del> <ins> Metadata Parameters Registry.  Each row in the table represents a distinct entry in the registry. </ins> 6.

Related discussion:
text: Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)
Code change:
Protocol flows that span multiple end-user devices are in widespread use today.  These flows are often referred to as cross-device flows. A common example is a user that uses their mobile phone to scan a QR <del> code from their SmartTV, giving an app on the TV access to their </del> <ins> code from their smart TV, giving an app on the TV access to their </ins> video streaming service.  Besides QR codes, other mechanisms are often used such as PIN codes that the user has to enter on one of the devices, or push notifications to a mobile app that the user has to

Related discussion:
text: Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >
Code change:
If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a <del> ConnectionErrorHandler of type SETTINGS_TIMEOUT. </del> <ins> ConnectionErrorHandler of type SETTINGS_TIMEOUT.  In setting a timeout, some allowance need to be made for processing delays at the peer; a timeout that is solely based on the round trip time between endpoints might result in spurious errors. </ins> 6.6.

Related discussion:
text: This isn't TCP RTT based. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
Code change:
If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a <del> ConnectionErrorHandler of type SETTINGS_TIMEOUT. </del> <ins> ConnectionErrorHandler of type SETTINGS_TIMEOUT.  In setting a timeout, some allowance need to be made for processing delays at the peer; a timeout that is solely based on the round trip time between endpoints might result in spurious errors. </ins> 6.6.

Related discussion:
text: This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.
Code change:
If the Transparency Service cannot process a client's request, it MUST return an HTTP 4xx or 5xx status code, and the body SHOULD be a <del> JSON problem details object (RFC9457) containing: </del> <ins> Concise Problem Details object (RFC9290) containing: </ins> <del> type: A URI reference identifying the problem.  To facilitate </del> <ins> title: A human-readable string identifying the error that prevented the Transparency Service from processing the request, ideally short and suitable for inclusion in log messages. detail: A human-readable string describing the error in more depth, ideally with sufficient detail to enable the error to be rectified. instance: A URN reference identifying the problem.  To facilitate </ins> automated response to errors, this document defines a set of standard tokens for use in the type field within the URN namespace of: "urn:ietf:params:scitt:error:". <del> detail: A human-readable string describing the error that prevented the Transparency Service from processing the request, ideally with sufficient detail to enable the error to be rectified. </del> <ins> response-code: The HTTP error response code relating to this error. application/concise-problem-details+cbor </ins> <del> Error responses SHOULD be sent with the "Content-Type: application/ problem+json" HTTP header. </del> <ins> NOTE: SCRAPI is not a CoAP API.  Nonetheless Constrained Problem Details objects (RFC9290) provide a useful CBOR encoding for problem details and avoids the need for mixing CBOR and JSON in endpoint implementations. </ins> As an example, submitting a Signed Statement with an unsupported signature algorithm would return a "400 Bad Request" status code and

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:
that receives a frame that causes their advertised concurrent stream limit to be <del> exceeded MUST treat this as a StreamErrorHandler.  An endpoint that wishes to reduce the value of </del> <ins> exceeded MUST treat this as a StreamErrorHandler of type or .  An endpoint that wishes to reduce the value of </ins> to a value that is below the current number of open streams can either close streams that exceed the new value or allow streams to

Related discussion:
text: Rather than just PROTOCOLERROR, allow REFUSEDSTREAM. REFUSED_STREAM is a more lenient error. It allows clients to retry requests. Servers might also set the GOAWAY stream number to a lower value if they upgraded.
"5.1.2 Stream Concurrency" says about SETTINGSMAXCONCURRENT_STREAMS: "Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a HEADERS frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a stream error (Section 5.4.2)" But which stream error code should be used? Almost all other references to stream errors in the spec say "treated as a stream error of type XXX"
Also, if this is a stream error, what happens if the client has a CONTINUATION already in flight right behind the current-streams-violating HEADERS frame? The server would then return a stream error to the HEADERS frame, and then see the CONTINUATION frame that's not associated with an in-progress header block. I suppose a server should maintain enough state to remember that it sent a stream error on that stream ID and simply ignore any following CONTINUATION frames instead of returning a connection error?
The server knows that a continuation frame is coming as it is flagged in the HEADERS frame. Regardless, to ensure against corrupting the compression state, even if it is thrown out, all HEADERS/CONTINUATION data must go through the compression context unless you're closing the connection. This is even true for stream IDs that are not in a valid state (though I'd hope in those cases that the receiver would close the connection after immediately sending an error). , Brad Fitzpatrick EMAIL wrote:
NAME good point. My tests don't cover the case of a CONTINUATION having valuable compression context needed for future valid streams. I will update the test suite I'm building.
Discussed on-list; let's go with .
Code change:
NOTE: A "public suffix" is a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us".  This step <del> is essential for preventing attacker.com from disrupting the integrity of site.example by setting a cookie with a Domain attribute of "com".  Unfortunately, the set of public suffixes </del> <ins> is essential for preventing "attacker.example" from disrupting the integrity of "site.example" by setting a cookie with a Domain attribute of "example".  Unfortunately, the set of public suffixes </ins> (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at

Related discussion:
text: URL was incomplete, leaving a number of inadvertant references to sites, or the TLD. This patch, hopefully, is less incomplete. h/t NAME and NAME for pointing this out.
WDYT, NAME
Code change:
its operation is robust when there is a significant change in the minimum delay. <del> 7.3. </del> <ins> 7.4. </ins> The "Internet of Things" (IoT) is a broad concept, but when evaluating a proposed congestion control algorithm, it is often

Related discussion:
text: From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.
Code change:
string comparisons is always a function of the total length of the strings, and not a function of the number of matched characters. <ins> A decoder needs to ensure that larger values or encodings of integers do not permit exploitation.  Decoders MUST limit the size of integers, both in value and encoded length, that it accepts (see integer.representation). </ins> Another common security problem is when the remote endpoint successfully causes the local endpoint to exhaust its memory.  This compressor attempts to deal with the most obvious ways that this

Related discussion:
text: On Sun, Oct 20, 2013 at 05:23:50PM -0700, Roberto Peon wrote: Here's a proposal for that.
Code change:
parameters for the <del> response header defined by RFC6750, which the resource server can use to explicitly communicate to the client the required authentication strength or recentness. </del> <ins> authentication scheme challenge defined by RFC6750, which the resource server can use to explicitly communicate to the client the required authentication strength or recentness. </ins> The client can use that information to reach back to the authorization server with an authorization request specifying the

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:
Many Issuers issue Signed Statements about different Artifacts under the same DID, so it is important for everyone to be able to immediately recognize by looking at the Envelope of a Signed <del> Statments what Artifact it is referring to.  This information is </del> <ins> Statements what Artifact it is referring to.  This information is </ins> stored in the Feed header of the Envelope.  Issuers MAY use different signing keys (identified by "kid" in the resolved key manifest) for different Artifacts, or sign all Signed Statements under the same

Related discussion:
text: With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1