jiebi/CodeConvo huggingface dataset:
Code change:
guessed by the attacker.  It is vitally important to adhere to this principle.  As such, the salt MUST be created in such a manner that it is cryptographically random, long enough and has high entropy that <del> it is not practical for the attacker to guess.  Each salt value MUST be unique. </del> <ins> it is not practical for the attacker to guess.  A new random value MUST be chosen for each claim. </ins> 7.4. <del> The length of the randomly-generated portion of the salt MUST be at least 128 bits. </del> <ins> The RECOMMENDED length of the randomly-generated portion of the salt is at least 128 bits. </ins> 7.5.

Related discussion:
text: added HMAC algorithm to supported identifiers replaced with to enable random value being a cryptographic key
NAME ready from my side
Looks good, I just had a few nitpicks here and there.
resolve conflicts, change to sddigestderivation_alg check if renders correctly...
Verbal approval from NAME
NAME sorry for the late revision it seems that here we have merge conflicts exposed URL
thanks! yes, fixed them in a PR that was merged
Code change:
Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are HeaderBlock. This has especially advantageous impact upon request sizes in the <del> common case, allowing many requests to be compressed into one TCP packet. </del> <ins> common case, allowing many requests to be compressed into one packet. </ins> 2.1.

Related discussion:
text: There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.
Code change:
Key header field (crypto-key) can be included to describe how the content encryption key is derived or retrieved. <del> The "aesgcm128" content-coding uses a single fixed set of encryption </del> <ins> The "aesgcm" content-coding uses a single fixed set of encryption </ins> primitives.  Cipher suite agility is achieved by defining a new content-coding scheme.  This ensures that only the HTTP Accept- Encoding header field is necessary to negotiate the use of encryption. <del> The "aesgcm128" content-coding uses a fixed record size.  The resulting encoding is a series of fixed-size records, with a final record that is one or more octets shorter than a fixed sized record. </del> <ins> The "aesgcm" content-coding uses a fixed record size.  The resulting encoding is a series of fixed-size records, with a final record that is one or more octets shorter than a fixed sized record. </ins> The record size determines the length of each portion of plaintext that is enciphered, with the exception of the final record, which is

Related discussion:
text: In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .
Code change:
The "Client-Cert" header field defined herein is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a single HTTP <del> header field-value as defined in Section 3.2 of RFC7230, which MUST </del> <ins> header field value as defined in Section 3.2 of RFC7230, which MUST </ins> NOT have a list of values or occur multiple times in a request. 2.3.

Related discussion:
text: This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)
Code change:
Else, if type is "integer" and char is ".", append char to input_number and set type to "float". <del> Otherwise, fail parsing. </del> <ins> Otherwise, prepend char to input_string, and exit the loop. </ins> If type is "integer" and input_number contains more than 19 characters, fail parsing.

Related discussion:
text: Makes "Parse a Number from Text" not be greedy, and return (not fail) when it encounters a non-digit character.
I'm pretty sure it works. Steps 5 & 6 ensure there's always at least one digit. All the calling contexts of "Parsing an Item from Text" (including the top-level algorithm in §4.2) inspect the next character, and handle it appropriately.
SGTM
Section 4.2.6 (Parsing a Number from Text) is ambiguous. It makes no mention of the exit condition from the while loop in step 7 on parsing a number from an input buffer.
I don't see it. The loop terminates with "fail parsing" in 7.4 (invalid character), or 7.5/7.6 (too many digits); or terminates successfully by virtue of "input_string is not empty" becoming untrue.
An example might clarify what I find ambiguous. Let us suppose that the input string is "-11-1, 4, 3", and that we are parsing a list. We'd call parseItem(), which would then invoke parseNumber(). When should parseNumber() stop reading in characters? Should it read in "-11" and then leave the rest to the next parsing function, or should it read in "-11-1" and then fail parsing? The other sections are unambiguous as to when to stop reading in characters (for instance, section 4.2.7 step 4.3 states that parsing of a string would stop when you encounter a DQUOTE, and section 4.2.9 step 3 states that parsing of binary content would stop when you encounter an ending asterisk).
Oh I see what you're saying. Yes, step 7.4 shouldn't be so aggressive.
Code change:
An origin server that receives an If-None-Match header field MUST evaluate the condition prior to performing the method (evaluation). <del> If the field value is "*", the condition is false if the origin server has a current representation for the target resource.  If the field value is a list of entity-tags, the condition is false if one of the listed tags match the entity-tag of the selected representation. </del> <ins> To evaluate a received If-None-Match header field: </ins> An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond

Related discussion:
text: URL This sentence describes cases where the selected representation exists and has an entity-tag. Shall we also specify that "if the selected representation does not exist or does not have an entity-tag, then the condition is false"?
Code change:
Statement pertains to.  (See Subject under terminology Terminology.) Issuers MAY use different signing keys (identified by "kid" in the <del> resolved key manifest) for different Artifacts, or sign all Signed </del> <ins> protected header) for different Artifacts, or sign all Signed </ins> Statements under the same key. An Issuer can make multiple Statements about the same Artifact.  For

Related discussion:
text: There is no explanation in draft, GitHub, or mailing lists about resolved key manifest. This change proposes replacement with protected header like other portions of the document.
resolved key manifest) for different Artifacts, or sign all Signed Statements under the same key. What does "resolved key manifest" mean?
LGTM
Code change:
HEADERS frames can be sent on a stream in the "idle", "reserved (local)", "open", or "half-closed (remote)" state. <del> The HEADERS frame payload has the following fields: </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The HEADERS frame payload has the following additional fields: </ins> The HEADERS frame defines the following flags:

Related discussion:
text: I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.
Code change:
The "match-dest" value of the Use-As-Dictionary header is an Inner List of String values that provides a list of Fetch request <del> destinations for the dictionary to match (see REQUEST-DESTINATION). </del> <ins> destinations for the dictionary to match (see FETCH). </ins> An empty list for "match-dest" MUST match all destinations.

Related discussion:
text: This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.
Code change:
is initially created for "http" URIs without authenticating the server cannot be used for "https" URIs until the server certificate is successfully authenticated.  Section 3.1 of RFC2818 describes the <del> basic mechanism, though the authentication considerations in I- D.ietf-httpbis-alt-svc also apply. </del> <ins> basic mechanism, though the authentication considerations in Section 2.1 of I-D.ietf-httpbis-alt-svc also apply. </ins> Connections that are established without any means of server <del> authentication (for instance, the purely anonymous TLS cipher suites), cannot be used for "https" URIs. </del> <ins> authentication (for instance, the purely anonymous TLS cipher suites) cannot be used for "https" URIs. </ins> 5.

Related discussion:
text: I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.
Code change:
12.6. <del> This memo updates the "ADLER32" digest algorithm in the HTTP Digest </del> <ins> This memo updates the "ADLER32" digest-algorithm in the HTTP Digest </ins> Algorithm Values [8] registry: Digest Algorithm: ADLER32

Related discussion:
text: is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.
Code change:
encoding in HTTP/2.  A request or response containing uppercase header field names MUST be treated as malformed. <ins> All pseudo-header fields MUST appear in the header block before regular header fields.  Any request or response that contains any pseudo-header field that appears in a header block after a regular header field MUST treated as malformed. 8.1.2.2. </ins> HTTP/2 does not use the Connection header field to indicate "hop-by- hop" header fields; in this protocol, connection-specific metadata is conveyed by other means.  As such, a HTTP/2 message containing

Related discussion:
text: Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).
Code change:
An Origin-Entry is a length-delimited string.  Specifically, it contains two fields: <del> An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field. An OPTIONAL sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender asserts this connection is or could be authoritative for. </del> 3. This document introduces no new security considerations beyond those

Related discussion:
text: NAME Adds the BCP14 boilerplate in a Notation Conventions section. As part of that, I noticed we don't reference any explanation of the frame layout language used -- it's the same used in QUIC and HTTP/3 -- so I added an RFC 9000 ref to pick that up in the same section.
Code change:
the URI; if "query" is present, the client MUST concatenate "?", followed by the "query" portion of the URI to the parameter. <del> 6.2.2.3. </del> <ins> 6.2.2.2. </ins> The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The

Related discussion:
text: The role somewhat limited what actions were valid, but it's not clear that was important. Also, some things can be limited by MAXSUBSCRIBEID now.
I understand that a ClientSetup is sent that includes the role of if the client only wants to send objects, the role of if it only wants to receive objects, and the role of if it wants to both send and receive objects. And I believe that basically only the following relationships can be established: Client: vs Server: Client: vs Server: Client: vs Server: My questions are as follows: If a ClientSetup with or role parameters were to arrive at an ingestion-only server, how would the server handle it? Is it required that the server returns that the client does not expect and the client understands the server's intention? If a client that has already sent or receives a ServerSetup containing , is it acceptable to use that connection as is? There may be some security risks in this case. Thank you!
As a side note, if the conclusion in will be that Role Parameter is unnecessary or no consideration are required as endpoint behavior, then this issue would be unnecessary.
Not clear what the use case is. Seems like a foot gun in that it can be set wrong for how the connection is used.
I don't care if we leave it or keep it. Just adding this as I got questions about why have it.
Having the client voluntarily declare itself to abide by a certain role is not preventing the relay form having to do any work. A malicious client will declare one role but then act differently. Any relay open to the public has to protect itself against unauthorized ANNOUNCE and SUBSCRIBE control messages, irrespective of what role was declared. Therefore the upfront role declaration is superfluous.
I tend to agree it's not doing anything helpful here, and sent out to remove it.
Only suggestion to adjust other setup parameter keys now that you have removed 0x00. Given we don't have a strong need for this, glad to see it go for now and we can add back later if we find a strong need for it.
Code change:
header to the request to indicate to the server that it has a dictionary available to use for compression. <del> The "Available-Dictionary" request header is a lowercase Base16-encoded RFC4648 SHA-256 hash of the contents of a single </del> <ins> The "Available-Dictionary" request header is a Structured Field STRUCTURED-FIELDS sf-binary SHA-256 hash of the contents of a single </ins> available dictionary. <del> Its syntax is defined by the following ABNF: </del> The client MUST only send a single "Available-Dictionary" request header with a single hash value for the best available match that it has available.

Related discussion:
text: Adds a new "Content-Dictionary" with the hash of the dictionary used when encoding the HTTP response. For
NAME this adds the dictionary hash to the HTTP response when used. Right now it is a . Let me know if you think it should be a instead.
Mostly for developer ergonomics to make it easier to deploy. In the case of static resources using previous versions as dictionaries (v1 to v2 of URL), one method for enabling that is to compress the new version using the old version on the cli as part of the push to production and store the dictionary-compressed artifact as a file on the server next to the full file. Then at serving time, compare the value of the request header with the file names on the server for the given URL to see if a delta-compressed artifact is available. Structured fields encode the binary data as base-64 encoded strings which aren't filesystem-friendly so there would need to be some steps at serving time to decode the header, convert it to ascii and then check. It's not insurmountable but it's a bit more processing and a straight string match could be handled directly with templating in server config. Lowercase hex was picked since that's what all of the cli tools for generating hashes emit.
Is a reasonable name for the response header? I'd actually prefer but it felt like that might be over-stepping since there could be some other generic need for associating a dictionary with a HTTP-response but maybe I'm being overly-cautious.
I don't think that authoring convenience outweighs the advantages of having a unified grammar here. It's not like base64 is some esoteric function. If you are talking about sha256sum, here's a toy: URL
I agree with NAME - don't. To make the sf value filesystem friendly, you just need to strip a few characters and remap "/".
Keep in mind that hashes are not hex strings. A SHA-256 hash is 32 bytes of binary data. The hex thing is just what some tools happen to output. But anything consuming this programmatically to, e.g., compare the hash against something would be best served by the underlying bytes. Using base64 is also slightly more compact on the wire. And if binary structured fields gets off the ground, it can be even more compact.
Code change:
header to the request to indicate to the server that it has a dictionary available to use for compression. <del> The "Available-Dictionary" request header is a lowercase Base16-encoded RFC4648 SHA-256 hash of the contents of a single </del> <ins> The "Available-Dictionary" request header is a Structured Field STRUCTURED-FIELDS sf-binary SHA-256 hash of the contents of a single </ins> available dictionary. <del> Its syntax is defined by the following ABNF: </del> The client MUST only send a single "Available-Dictionary" request header with a single hash value for the best available match that it has available.

Related discussion:
text: My main concern is trading off a unified grammer of using sf-binary in the headers vs consistency with tooling and how the dictionaries are represented once it gets out of the protocol. In the dynamic case, this could be something like the web server checking to see if the requested dictionary is available (on disk) in response to a request. I don't know how each web server will choose to build that but having files named with the hash is an easy common starting point. Otherwise each chooses what the ascii representation of the 32-byte hash should be for their case. On the static case, I'm not so much worried about not having a tool that can create base64-encoded strings of sha256 hashes (it's trivial as you pointed out). I'm more concerned about the transformations that need to happen at serving time to decode the hash, convert it into an ascii representation and then check if that variant of the encoded file is available. It's certainly all doable, but it requires base64decode and binhex (or some equivalents) to be available in the layer where the checks are being done - or to rely on application code. Specifically, I was thinking that it would be easy enough in VCL or an existing Nginx or Apache config to do something like: If request header is present and validates against a [0-9a-f]+ regex and 'br-d' is available in the request header try returning + '.' + request['Accept-Encoding'] + '.br-d' (and add relevant response headers) otherwise return Doing similar processing with base64-encoded hashes has a step to convert it into an unspecified format that is platform-specific and may not be doable without either running application code or updating the server with base64decode + binhex support. It likely doesn't matter for the case of applications and servers that are dictionary-aware and can operate on the raw hashes (and enjoy the ~20 byte request header savings) but it is a tradeoff that pushes complexity further up the stack so I just want to make sure that is the tradeoff that we want to make.
Having a finally consistent grammar for HTTP is the precursor to get consistent tooling. It may be more convenient to do something else in the short term, but in the long term we'd just be adding to the mess of inconsistency in HTTP.