jiebi/CodeConvo huggingface dataset:
Code change:
3.2.2. <del> (TODO: Clarify that real time congestion controls are included, with allowances for the poor documentation / open source availability of these) </del> <ins> General-purpose protocols coexist in the Internet with real-time congestion control protocols, which in general have finite throughput requirements (i.e.  they do not seek to utilize all available capacity) and more strict latency bounds. RFC8868 provides suggestions for real-time congestion control design and RFC8867 suggests test cases.  RFC9392 describes some considerations for the RTP Control Protocol (RTCP).  This document does not change the informational status of those RFCs. New proposals SHOULD consider coexistence with widely deployed real- time congestion controls.  Regrettably, at the time of writing, many algorithms with detailed public specifications are not widely deployed, while many widely deployed real-time congestion controls have incomplete public specifications. To the extent that behavior of widely deployed algorithms is understood, proposals can analyze and simulate the their interaction with those algorithms.  To the extent they are not, experiments can be conducted where possible. Note that in many deployments, real-time traffic is directed into distinct queues via Differentiated Services Code Points (DSCP) or other mechanisms, which substantially reduces the interplay with other traffic.  However, proposals cannot assume that this is always the case. </ins> 3.2.3.

Related discussion:
text: But there are of course other congestion controls out there, both standard and non-standard, in support of real-time and other non-greedy applications. Should we mention those as a class? Namecheck some examples?
editors meeting 8836 requirements document 8867 and 8868 are test cases, but informational. Reese: standard stuff is not widely deployed, widely deployed stuff is not standardized. But RMCAT is new. Maybe there aren't well-documented protocols to evaluate vs., so it's hard to require anything here. I'll take a look, will probably have to go to the community.
Editors: We need to consider the interaction between real time and not-real time is evaluating real-time in scope? See 8836, 8867, 8868.
Looks good enough.Thanks for the changes.
Code change:
Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. <ins> The JWT MUST contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant. The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as an intended audience. The RFC8414 issuer identifier URL of the authorization server MUST be used as a value for an "aud" element to identify the authorization server as the intended audience of the JWT. </ins> The JWT MAY contain an "nbf" (not before) claim that identifies the time before which the token MUST NOT be accepted for processing.

Related discussion:
text: The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.
Code change:
"keyid": The identifier for the key material as a String value. <del> "context": An application-specific context for the signature as a String value.  This value is used by applications to help identify </del> <ins> "tag": An application-specific tag for the signature as a String value.  This value is used by applications to help identify </ins> signatures relevant for specific applications or protocols. Additional parameters can be defined in the iana-param-contents.

Related discussion:
text: Hello, URL introduced parameter, "to allow applications to signal specific usage between the signer and verifier". However, word context is already used more than 40 times, mostly meaning the context of HTTP message. In my opinion, it adds ambiguity to the used vocabulary. Please consider renaming the parameter, e.g. to application, app, usage, use, purpose. Best regards, Robert
Thanks, I noticed a similar term conflict when we added the functionality -- was the proposed name from the folks that suggested the function so that's what we put in. I'm happy to have something else in there: I think is a good suggestion.
Code change:
response itself (e.g., as metadata about the 103 (Early Hints) response). <ins> A server MAY use a 103 (Early Hints) response to indicate only some of the header fields that are expected to be found in the final response.  A client SHOULD NOT interpret the nonexistence of a header field in a 103 (Early Hints) response as a speculation that the header field is unlikely to be part of the final response. </ins> The following example illustrates a typical message exchange that involves a 103 (Early Hints) response.

Related discussion:
text: Clarify that the disappearance of a header field (that once existed in a 103 response) from the following 103 responses does not indicate the retraction of the expectation that the header field will be included in the final response.
ecb2c7e clarifies the general rule that this PR relies on (i.e. the nonexistence of a header field in the 103 response cannot be used as a signal that the header field will be absent in the final response), at the same time addressing Spencer Dawkins' suggestion to clarify that "the server can add header fields in the 200 that were not present in the 103."
In section 2. "103 Early Hints" the last paragraph describes that 103 can be send multiple time. The given example reads as if a server may correct its previous 103 that is made from a cached resource. So the following 103 are correcting the older ones, they are only adding headers to the previous ones or are they replacing them completely? Maybe sentence clarifying this would be good.
This is an interesting question. I think that we should agree on what the expected behavior is before discussing how (or if) we should update the text. Regarding the question, I think that we should consider two (or more) Early Hints responses as expectations from different sources, rather than considering the following one to update the earlier ones. The reason I think so is because nonexistence of a header field in the 103 response does not imply that the header field will not exist in the final response, since we are not required to include in 103 response all the headers that are expected to be included in the final response. So consider the following example: a caching intermediary might generate an Early Hints response from a stale-cached response. That Early Hints response could contain a header field that will never be included within an Early Hints response sent from the origin. In such case, considering both of the Early Hints responses as genuine makes the most sense.
Code change:
(see acting-on-resources). The representation enclosed in the response refers to the resource <del> identified by "Content-Location" (see I-D.ietf-httpbis-semantics Section 6.3.2). </del> <ins> identified by "Content-Location" (see SEMANTICS Section 6.3.2). </ins> "Digest" is thus computed on the enclosed representation.

Related discussion:
text: References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.
Code change:
public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage). <del> 3.4. </del> <ins> 3.5. </ins> A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more

Related discussion:
text: Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.
Code change:
NOTE: As set-cookie-string may originate from a non-HTTP API, it is not guaranteed to be free of CTL characters, so this algorithm <del> handles them explicitly. </del> <ins> handles them explicitly.  Horizontal tab (%x09) is excluded from the CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately. </ins> A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string: <del> If the set-cookie-string contains a %x00-1F / %x7F (CTL) character: Abort these steps and ignore the set-cookie-string entirely. </del> <ins> If the set-cookie-string contains a %x00-08 / %x0A-1F / %x7F character (CTL characters excluding HTAB): Abort these steps and ignore the set-cookie-string entirely. </ins> If the set-cookie-string contains a %x3B (";") character:

Related discussion:
text: This excludes HTAB (%x09) from the CTL characters that normally cause cookie rejection. HTAB is considered whitespace and is handled separately at a later step in the algorithm. Related to
NAME NAME PTAL.
LGTM
In URL, RFC 6265bis was modified to specify truncation of set-cookie-lines at the first {CR, LF, NUL} byte. This is consistent with Chrome's current behavior. NAME that this may enable an attack where an attacker may inject a CR, LF, or NUL byte into a cookie value to cause its truncation, thus changing the value of the cookie. Investigate interop/web compatibility and consider rejecting all cookies containing any control character (rather than truncating).
Addressed by and .
Thanks NAME Do you know if tests have been updated as well and implementations bugs have been filed against browsers that do not do this (yet)?
NAME I just submitted for review an update to the tests, and will soon file bugs based on the findings from running those. I'll post back here with links to any tickets I open. Thanks for asking about this For reference: URL
NAME FYI, here are the corresponding bugs: URL ​​URL URL
Thanks NAME for your work on this!
lgtm, thanks
Code change:
In a cross-device flow, a user starts a scenario on the Initiating Device (e.g., a smart TV) and then uses an Authorization Device (e.g., a smartphone) to authorize access to a resource (e.g., access <del> to a streaming service). </del> <ins> to a streaming service) on the Initiating Device. </ins> Cross-device flows have several benefits, including:

Related discussion:
text: Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!
Code change:
If the server rejects early data at the TLS layer, a client MUST start sending again as though the connection was new.  This could entail using a different negotiated protocol ALPN than the one <del> optimistically used for the early data.  If HTTP/2 is selected after early data is rejected, a client sends another connection preface. Any requests sent in early data MUST be sent again, unless the client decides to abandon those requests. </del> <ins> optimistically used for the early data.  Any requests sent in early data MUST be sent again, unless the client decides to abandon those requests. </ins> This automatic retry exposes the request to a potential replay attack.  An attacker sends early data to one server instance that

Related discussion:
text: Hopefully none of this collides with other PRs in flight.
I think it's fine with this. Adding a bit of pragmatism as you did in the last commit also reminds that the low cost of retrying is not worth a lot of trouble :-)
Code change:
may not be possible if the timestamp token has been obtained outside the processing context in which the COSE object is assembled. <ins> The "3161-ctt" unprotected header is defined as follows: Name: 3161-ctt Label: TBD Value Type: bstr Value Registry: none Description: RFC 3161 timestamp token Reference: sec-tst-hdr-ctt of RFCthis 4. </ins> RFC 3161 timestamp tokens use CMS as signature envelope format. STD70 provides the details about signature verification, and RFC3161 provides the details specific to timestamp token validation.  The

Related discussion:
text: See URL Hi! Unfortunately, we couldn't submit the draft before the meeting and discuss it face-to-face. But here's a -01 fresh from the oven. We absorbed the feedback we got in SF and went ahead with one single header. However, the two modes of use ([1], [2]) define different inputs into the timestamping machinery and therefore create a different binding between COSE and TST. At present, the only way to distinguish between the two semantics is by their position in the COSE message (i.e., protected vs unprotected), which does not look like a good design :-) cheers, thanks [1] URL [2] URL ---------- Forwarded message --------- From: Date: Tue, 7 Nov 2023 at 14:36 Subject: New Version Notification for draft-ietf-cose-tsa-tst-header-parameter-URL To: Henk Birkholz , Maik Riechert , Maik Riechert , Thomas Fossati , A new version of Internet-Draft draft-ietf-cose-tsa-tst-header-parameter-URL has been successfully submitted by Thomas Fossati and posted to the IETF repository. Name: draft-ietf-cose-tsa-tst-header-parameter Revision: 01 Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens Date: 2023-11-07 Group: cose Pages: 6 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: RFC 3161 provides a method for timestamping a message digest to prove that the message was created before a given time. This document defines a CBOR Signing And Encrypted (COSE) header parameter that can be used to combine COSE message structures used for signing (i.e., COSESign and COSESign1) with existing RFC 3161-based timestamping infrastructure. The IETF Secretariat
Code change:
accompany one another.  A common example would be tying together audio and video tracks. <del> 3.2.13. </del> <ins> 3.2.14. </ins> An integer specifying a group of tracks which are alternate versions of one-another.  Alternate tracks represent the same media content,

Related discussion:
text: by adding in a new field to indicate if delta updates (patches) will be used by the publisher. Also updated the examples to match.
Code change:
options they provide to operators (especially the default configuration). <del> Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve this problem. </del> <ins> Intermediaries are no more trustworthy than the people and policies under which they operate; HTTP cannot solve this problem. </ins> 17.3.

Related discussion:
text: The first is an incorrect change -- "advance configuration" means configured prior to the request, not "advanced". The second is indeed a typo.
Roman Danyliw has entered the following ballot position for draft-ietf-httpbis-semantics-16: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: [x] ** Section 2.2. Per “Additional (social) requirements are placed on implementations …”, what’s a “social” requirement? Editors: removed in (URL)
[x] ** Section 4.2.2. http + https origins on the same host uniformly. Editors: added text in
[x] ** Section 5.1. Convention question. Per “Field names … ought to be registered within the …” HTTP field name registry, I have a question about the strength of the recommendation based on the use of the verb “ought” – is that RECOMMENDED? SHOULD? Section 8.3.1, 8.3.2, 8.4.1, 8.8.3, etc use a similar construct. Editors: we intentionally do not to use normative language for registration requirements.
[x] ** Section 7.2. Does this text allow for the possibility for both a Host and :authority be included? Editors: it's syntactically possible in H2 and H3. It's up to those specs to describe what that would mean.
[x] ** Section 9.2.1. In addition to example of the access logs files filling the disk, there could be significant CPU load if the target is a script. Editors: URL
[x] ** Section 17.1. The text provides helpful caution by stressing that “… the user's local name resolution service [is used] to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.” The subsequent text highlights DNSSEC as improving authenticity.
Code change:
options they provide to operators (especially the default configuration). <del> Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve this problem. </del> <ins> Intermediaries are no more trustworthy than the people and policies under which they operate; HTTP cannot solve this problem. </ins> 17.3.

Related discussion:
text: It seems that the integrity provided by DoT or DoH would also be relevant. Editors: added text in (see also URL)
[x] ** Section 17.2 people who run them; HTTP itself cannot solve this problem. No disagreement with the sentiment, but I would recommend not framing it in term of the trustworthiness of the people (i.e., intermediaries with poor security or privacy practices is not necessarily due to the lack of trustworthiness of the engineers operating the service; perhaps these services are also run in of jurisdictions where confidence in them should be reduced). NEW Users need to be aware that intermediaries are no more trustworthy that the entities that operate them and the policies governing them; HTTP itself cannot solve this problem. Editors: URL
[x] ** Section 17.5. More generically describe the attack OLD NEW Editors: d466398e
** Editorial
[x] -- Section 3.5. Should s/advance configuration choices/advanced configuration choices/? Editors: no, advance has the same meaning as "configuration choices made prior to request"
[x] -- Section 4.2.2. This text goes from referring to “secured” in the first sentence to “[acceptable] cryptographic mechanisms” in the second sentence. To link them, perhaps s/are secured/are cryptographically secured/ Editors: "secured" is a defined term for this spec.
[x] -- Section 6.5. Typo. s/section are are/section are/ Editors: URL
[x] -- Section 11.1. The text (at least when read as a .txt) isn’t showing RFC7617 or RFC7616 as references. Editors: it does in HTML: URL
[x] -- Section 14.1.1. Typo. s/gramar/grammar/ Editors: URL
disk, there could be significant CPU load if the target is a script. Yes. But this is the definition of "safe methods", not a discussion of all potential attack vectors of a server.
user's local name resolution service [is used] to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.” The subsequent text highlights DNSSEC as improving authenticity.
Code change:
options they provide to operators (especially the default configuration). <del> Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve this problem. </del> <ins> Intermediaries are no more trustworthy than the people and policies under which they operate; HTTP cannot solve this problem. </ins> 17.3.

Related discussion:
text: It seems that the integrity provided by DoT or DoH would also be relevant. Understood. Q: do we attempt an exhaustive list here, or just mention examples? If we did mention DoT and DoH, woulkd that be exhaustive?
By nature I don't think we can be exhaustive here. If anything, I'd replace DNSSEC with DoH, as it's getting more adoption (both in implementation and deployment) on the web.
http + https origins on the same host uniformly. We already say that in several places, and I don't think repeating ourselves helps the document become more readable or useful.
There are technical interop requirements for the protocol and social requirements to keep people safe on the Internet (or the Web safe from the people abusing it). This is just a short-hand version of old IETF lore, and probably isn't worth repeating in the spec.