jiebi/CodeConvo huggingface dataset:
Code change:
5.1. The "Signature" HTTP Authentication Scheme uses asymmetric <del> cryptography.  User agents possess a user ID and a public/private key pair, and origin servers maintain a mapping of authorized user IDs to their associated public keys.  When using this scheme, the "u", "p", </del> <ins> cryptography.  User agents possess a key ID and a public/private key pair, and origin servers maintain a mapping of authorized key IDs to their associated public keys.  When using this scheme, the "k", "p", </ins> and "s" parameters are REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication- Signature" and the associated context is empty.  The nonce is then signed using the selected asymmetric signature algorithm and transmitted as the proof directive. <del> For example, the user ID "john.doe" authenticating using Ed25519 </del> <ins> For example, the key ID "basement" authenticating using Ed25519 </ins> ED25519 could produce the following header field (lines are folded to fit): 5.2. The "HMAC" HTTP Authentication Scheme uses symmetric cryptography. <del> User agents possess a user ID and a secret key, and origin servers maintain a mapping of authorized user IDs to their associated secret key.  When using this scheme, the "u", "p", and "h" parameters are </del> <ins> User agents possess a key ID and a secret key, and origin servers maintain a mapping of authorized key IDs to their associated secret key.  When using this scheme, the "k", "p", and "h" parameters are </ins> REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication-HMAC" and the associated context is empty.  The nonce is then HMACed using the selected HMAC algorithm and transmitted as the proof directive. <del> For example, the user ID "john.doe" authenticating using HMAC-SHA-512 </del> <ins> For example, the key ID "basement" authenticating using HMAC-SHA-512 </ins> SHA could produce the following header field (lines are folded to fit):

Related discussion:
text: The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.
Code change:
Status: standard <del> Description: The sha-256 digest of the representation-data of the resource when no content coding is applied (eg.  "Content- Encoding: identity") Reference: RFC6234, RFC4648, this document. Status: standard </del> <ins> ID-SHA-256: : * Description: The sha-256 digest of the representation-data of the resource when no content coding is applied (eg.  "Content-Encoding: identity") * Reference: RFC6234, RFC4648, this document.  * Status: standard </ins> If other digest-algorithm values are defined, the associated encoding MUST either be represented as a quoted string, or MUST NOT include

Related discussion:
text: NAME I was tired of the warnings of line too long, so I've reflowed a lot of the examples and also most of the text while I was at it. The Python code example was tricky, please pay attention to that as I may have mangled it.
LGTM
Code change:
allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies. <del> HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.  Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </del> 3.8. A

Related discussion:
text: The discussion of seems like it would be more appropriate under 'connections' rather than 'intermediaries.'
Code change:
claims.  This limitation needs to be taken into account by Issuers when creating the structure of the SD-JWT. <del> 10.8. </del> <ins> 10.7. </ins> An Issuer MUST NOT allow any content to be selectively disclosable that is critical for evaluating the SD-JWT's authenticity or

Related discussion:
text: Attempt to better explain how salt in the Disclosure makes guessing the preimage of the digest infeasible Consolidate salt entropy and length security consideration subsections
question from an email, my response: The exchange makes me think a brief mention/explanation what salt does/provides in the SD-JWT context would be a worthwhile addition. Maybe just add or modify a sentence or two in sec 10.3. And/or something in URL where the salt value in the Disclosure is introduced/described.
Hi Brian, just check for understanding: does the issuer send the clear text values of the disclosed claims to the holder and verifier or does the issuer only send the salted hashes? +------------+ +------------+ | Issues SD-JWT including all Disclosures | v +------------+ +------------+ | Presents SD-JWT including selected Disclosures | v +-------------+ + + +-------------+ +-------------+| +-------------+
I'm sorry but I don't quite understand the question or how it relates to the small change I'm suggesting in this issue.
FYI, I was asked what the salt does by an IETF attendee yesterday. I support explaining this in the draft.
PR has some proposed text
Code change:
Content-Language header field Content-Length header field Content-Location header field <ins> Content-MD5 header field </ins> Content-Range header field Content-Type header field cache

Related discussion:
text: I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.
Code change:
The unqualified "private" response directive indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user).  It also indicates that a private cache MAY store the <del> response, subject to any other cache directives present, even if the response would not otherwise be heuristically cacheable by a private cache. </del> <ins> response, subject the constraints defined in response.cacheability, even if the response would not otherwise be heuristically cacheable by a private cache. </ins> If a qualified private response directive is present, with an argument that lists one or more field names, then only the listed fields are limited to a single user: a shared cache MUST NOT store the listed fields if they are present in the original response, but <del> MAY store the remainder of the response message without those fields. </del> <ins> MAY store the remainder of the response message without those fields, subject the constraints defined in response.cacheability. </ins> The field names given are not limited to the set of header fields defined by this specification.  Field names are case-insensitive.

Related discussion:
text: NAME see revision.
The language for and indicates that they override the rest of the caching model unconditionally; as discussed in , that is too broad. Also, is often used even though the message is still cacheable, because developers misunderstand its semantics.
The text in question for private: to any other cache directives present, even if the response would not otherwise be heuristically cacheable by a private cache. lists one or more field names, then only the listed fields are limited to a single user: a shared cache [...] &MAY; store the remainder of the response message without those fields. I think there are two problems here: 1) "subject to any other cache directives present" is too narrow; the requirements in 3. Storing Responses in Caches go far beyond cache directives (e.g., method and status code cache ability). 2) The second paragraph omits any such condition. I think this can be addressed by replacing the clause above with something like "subject to the other requirements in [ref to section 3]", and repeating it in the second paragraph. We'd also need to add to the list in section 3 (probably below .
For public, we have: response even if it would otherwise be prohibited, subject to the constraints of any other response directives present. In other words, public explicitly marks the response as cacheable. Similar to above, I think it should be "subject to the constraints defined in [ref to section 3]. A note like this would also help:
LGTM.
Code change:
Reason Phrase Length: The length in bytes of the reason phrase. <del> Reason Phrase: Provides the reason for subscription error and "Reason Phrase Length" field carries its length. </del> <ins> Reason Phrase: Provides the reason for subscription error. </ins> 6.7.

Related discussion:
text: When we added (b) we didn't update this.
SUBSCRIBE_RST as well
and ANNOUNCE_ERROR
Code change:
enforcing a Registration Policy.  It also maintains a service key, which is used to endorse the state of the Append-only Log in Receipts.  All Transparency Services MUST expose standard endpoints <del> for Registration of Signed Statements and Receipt issuance, which is described in TODO: scrapi.  Each Transparency Service also defines its own Registration Policies, which MUST apply to all entries in the Append-only Log. </del> <ins> for Registration of Signed Statements and Receipt issuance.  Each Transparency Service also defines its own Registration Policies, which MUST apply to all entries in the Append-only Log. </ins> The combination of Identity, Registration Policy evaluation, and the Transparency Service endpoint constitute the trusted part of the

Related discussion:
text: This is a simple dependency management PR to decouple SCRAPI from the architecture spec. See SCRAPI can be a layer above, and reference the architecture (dependency) as in HTTP implementation. Decoupling allows us to move forward with the architecture doc, continuing to iterate on SCRAPI independently.
Code change:
6.3.1. To make sure that a dictionary can only impact content from the same <del> origin where the dictionary was served, the "match" pattern used for matching a dictionary to requests MUST be for the same origin that the dictionary is served from. </del> <ins> origin where the dictionary was served, the URLPattern used for matching a dictionary to requests is guaranteed to be for the same origin that the dictionary is served from. </ins> 6.3.2.

Related discussion:
text: This switches the custom wildcard matching to use with regexp support disabled. URLPattern is being used by the service worker routing API's and is what the web side is standardizing on for anything that pattern-matches URLs. This splits the match pattern into explicit path and search (query param) components and forces the origin to be inherited from the dictionary request URL. Also included here is a new field for to allow for matching on request destinations. The biggest use case for that will be for allowing site-wide HTML dictionaries to do something like and for the dictionary to not be sent for every request across the site (images, etc). See issues , ,
Code change:
The communication between a TTRP and backend server needs to be secured against eavesdropping and modification by unintended parties. <del> The configuration options and request sanitization are necessarily functionally of the respective servers.  The other requirements can </del> <ins> The configuration options and request sanitization are necessary functionality of the respective servers.  The other requirements can </ins> be met in a number of ways, which will vary based on specific deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the

Related discussion:
text: AD review feedback (thread at URL) and some minor editorial updates
thanks Mike, nits have been addressed
Looks good; two nits.
Code change:
unless separate compression dictionaries are used for each source of data.  Compression MUST NOT be used if the source of data cannot be reliably determined.  Generic stream compression, such as that <del> provided by TLS MUST NOT be used with HTTP/2 (TLSUsage). </del> <ins> provided by TLS MUST NOT be used with HTTP/2 (see TLSUsage). </ins> Further considerations regarding the compression of header fields are described in COMPRESSION.

Related discussion:
text: The latter part is vestigal, from the time when gzip C-E was mandated. Remove it. Here, I'm less concerned.
Code change:
(see output}), and forward it to the upstream HTTP server, then the upstream server performs the validation. <del> The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. </del> <ins> This document defines the "Signature-Auth-Context" request header field for this latter purpose.  The Signature-Auth-Context header field's value is a Structured Field Byte Sequence (see STRUCTURED- FIELDS) that contains the 48-byte key exporter output (see output), without any parameters.  For example: </ins> Note that both of these mechanisms require the upstream HTTP server to trust the intermediary.  This is usually the case because the intermediary already needs access to the TLS certificate private key <del> in order to respond to requests. </del> <ins> in order to respond to requests.  HTTP servers that parse the Signature-Auth-Context header field MUST ignore it unless they have already established that they trust the sender. </ins> 9.

Related discussion:
text: Please correct me if I'm wrong, but IIUC, the crux of this PR is that to allow any client that can present a valid pair of Authorization and Signature-Auth-Context header fields to obtain a protected resource. Assuming that if we would be allowing such behavior, I wonder why we need to require clients to export keys from TLS session, rather than just coming up with some arbitrary authentication context and present it to the server? Or if it is the case that there are situations in which we have to require clients to use keys exported from TLS session, doesn't it mean that there are cases where servers must ignore Signature-Authentication-Context header field or drop it?
NAME no this is only for trusted intermediaries. If a server receives a Signature-Auth-Context header from an untrusted source then it drops it. That's somewhat mentioned on line 470, but I'll add normative text.
Code change:
allowed to have, and restricting the length of time an upload resource can exist. <del> 16. </del> <ins> 17. </ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Related discussion:
text: As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.
Code change:
Clients can send representation metadata (see HTTP) in the request that starts an upload.  Servers MAY interpret this metadata or MAY ignore it.  The "Content-Type" header field (HTTP) can be used to <del> indicate the media type of the file.  The "Content-Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </del> <ins> indicate the media type of the file.  The content coding of the representation is specified using the "Content-Encoding" header field and is retained throughout the entire upload.  When resuming an interrupted upload, the same content coding is used for appending to the upload, producing a representation of the upload resource with one consistent content coding.  The "Content-Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </ins> 4.1.

Related discussion:
text: defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!
Code change:
Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at <del> https://github.com/httpwg/http-extensions/labels/client-cert-header </del> <ins> https://github.com/httpwg/http-extensions/labels/client-cert-field </ins> [3]. 1.

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:
9.2. <del> Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. 9.3. </del> When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is included in a Txn-Token, an attacker may extract the Access Token

Related discussion:
text: See meeting notes here where we agreed to remove this: URL
The language in section needs to refer to the RFC and specify how to use them with Txn-Tokens
Code change:
times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. <ins> 4.3. Congestion control performance is affected by the queue discipline applied at the bottleneck link.  The default queue discipline that MUST be evaluated is drop-tail, First In First Out (FIFO).  See aqm for evaluation of other queue disciplines. </ins> 5. The criteria in evaluation-criteria will be evaluated in the

Related discussion:
text: Created a separate issue to discuss ECN.
The guideline section discusses "Investigating a Range of Environments", with a focus especially on "Random Early Detection (RED) ] and Drop-Tail." The IETF and the IRTF have produced several different proposals for Active Queue management, with somewhat different characteristics. Interestingly, there is a tension there between developing Queue Management that "plays well" with existing congestion control algorithms, and developing congestion control algorithms that "take advantage" of AQM. Not sure what to say there, but at a minimum we should develop expectations about "signals" produced by AQM (e.g., the ECN markings of L4S) and reaction by congestion control algorithms. To go further, the could be a discussion of "honest signals", such as delays, that are very hard to "fake" in routing nodes, other signals such as ECN marks that could be produced by the network at very little cost, and packet losses that fall kind of in between. But we are not writing for the IRTF, so this could be kept brief.
On the topic of AQM, IETF published Characterization Guidelines (RFC7928) and Recommendations (RFC7567) that could be exploited for further discussions in this work.
Martin and Gorry: add a reference to 7567 to AQM behavior and evaluation criteria, which is not in scope for this document talk about evaluating CC interaction with AQM
Something like "CCs should be evaluated against AQMs that are prevalent in the internet" -- is there a reference that provides a taxonomy?
Editors: FQ-CoDel, PIE, L4S (RFC9332) have RFCs Are the others that should be evaluated, and do they have available specs?
Discussed at IETF 118: Many operators are not particularly aware of AQM or these concepts in general Include FIFO in the list Also do at least an AQM "you should evaluate the scenario with FIFO queues and should also consider the impact of various common AQMs and run detailed simulations against them", while maybe name-checking a few particularly relevant ones. Yes, should have criteria for this, and also should not ask people to run NxN interop matrix. Out of scope to mandate AQM
I suggest: Probably ought to include a suitably configured RED also.
Code change:
times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. <ins> 4.3. Congestion control performance is affected by the queue discipline applied at the bottleneck link.  The default queue discipline that MUST be evaluated is drop-tail, First In First Out (FIFO).  See aqm for evaluation of other queue disciplines. </ins> 5. The criteria in evaluation-criteria will be evaluated in the

Related discussion:
text: ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.
Code change:
times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. <ins> 4.3. Congestion control performance is affected by the queue discipline applied at the bottleneck link.  The default queue discipline that MUST be evaluated is drop-tail, First In First Out (FIFO).  See aqm for evaluation of other queue disciplines. </ins> 5. The criteria in evaluation-criteria will be evaluated in the

Related discussion:
text: Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.