jiebi/CodeConvo huggingface dataset:
Code change:
Description: Merkle tree algorithm used to produce a COSE Sign1 payload. <del> 7.2. </del> <ins> Name: inclusion_proof Label: TBD_2 Value type: inclusion_proof Value registry: See Description: Merkle tree inclusion proof for the given tree_alg. </ins> <del> IANA will be asked to add a new registry "TBD" to the list that appears at IANA Assignments [1]. </del> <ins> Name: consistency_proof </ins> <del> The rest of this section defines the subregistries that are to be created within the new "TBD" registry. </del> <ins> Label: TBD_2 </ins> <del> 7.2.1. </del> <ins> Value type: consistency_proof Value registry: See Description: Merkle tree consistency proof for the given tree_alg. 7.1.2. </ins> IANA will be asked to establish a registry of tree algorithm identifiers, named "Tree Algorithms" to be administered under a

Related discussion:
text: These changes focus this draft on the minimal definitions required to secure the data structures defined in RFC9162 using CBOR and COSE. Extraneous information has been removed. There is a wip implementation available here: URL There is a demo here: URL
LGTM!sry 4 the l8 approvalI recommend merging now
Code change:
This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language. <del> Note that Variant-Key is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself.  In the example above, it might be that a gzip'd version of the French content is not available, in which case the response will include: </del> <ins> A more complex example involves listing multiple available-values in a list member, to indicate that the response can be used to satisfy requests with any of those values.  For example: </ins> <del> even though Content-Encoding does not contain "gzip". </del> <ins> indicates that this response can be used for requests whose Content- Encoding algorithm selects "gzip" or "identity", as long as the Content-Language algorithm selects "fr" - perhaps because there is no gzip-compressed French representation. This highlights an important aspect of Variant-Key; it is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself. </ins> 3.1. <del> This algorithm generates a normalised string for Variant-Key, suitable for comparison with values generated by cache. </del> <ins> This algorithm generates a list of normalised strings from Variant- Key, suitable for comparison with values generated by cache. </ins> Given stored-headers, a set of headers from a stored response, a <del> normalised variant-key for that message can be generated by: </del> <ins> normalised list of variant-keys for that message can be generated by: Let variant-keys be an empty list. </ins> Let variant-key-header be a string, the result of selecting all field-values of stored-headers whose field-name is "Variant-Key" and joining them with a comma (","). <del> Remove all whitespace from variant-key-header. </del> <ins> Let value-list be the result of splitting variant-key-header on commas (","). For each value in value-list: Remove all whitespace from value. Let items be the result of splitting value on ";". append items to variant-keys. </ins> <del> Return variant-key-header. </del> <ins> Return the result of running Compute Possible Keys (find) on variant-keys, an empty string and an empty list. </ins> 4.

Related discussion:
text: For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)
Code change:
4.2. <del> The current interop version is 4. </del> <ins> The current interop version is 5. </ins> Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version

Related discussion:
text: allows another status code to be returned for offset retrieval requests. This might break interoperability between existing implementation, so this PR bumps the interop version to make this change more visible.
Code change:
waiting for the upload to complete before scanning a full file, or disabling resumable uploads. <ins> Resumable uploads are vulnerable to Slowloris-style attacks SLOWLORIS.  A malicious client may create upload resources and keep them alive by regularly sending "PATCH" requests with no or small content to the upload resources.  This could be abused to exhaust server resources by creating and holding open uploads indefinately with minimal work. Servers SHOULD provide mitigations for Slowloris attacks, such as increasing the maximum number of clients the server will allow, limiting the number of uploads a single client is allowed to make, imposing restrictions on the minimum transfer speed an uploads is allowed to have, and restricting the length of time an upload resource can exist. </ins> 11. IANA is asked to register the following entries in the "Hypertext

Related discussion:
text: This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?
Code change:
The "ID-SHA-256" and "ID-SHA-512" algorithms have been added to the registry. <del> 9.8. </del> <ins> 9.9. </ins> This section registers the "Want-Digest" header field in the "Permanent Message Header Field Names" registry (RFC3864).

Related discussion:
text: Obsolete ADLER-32 but don't forbid it.
NAME will this work for you?
I think the pull request is OK as-is, but might be improved slightly. In particularly, I'm wondering if SHOULD NOT is too strong for the server. A server could support ADLER32 without that support impacting on cryptographic data integrity provided that server also supports a cryptographically secure hash; e.g., SHA-512. Clients that wish to protect against malicious actor changes would use the SHA-512 hash and not request (or ignore) the ADLER32 value. Therefore, I would suggest that, for the server, the document says a server MAY implement ADLER32. I think it is perfectly reasonable for the document to say the client SHOULD NOT use ADLER32, for the reasons stated. That said, I can't decide if this distinction is really helpful, so I defer to your judgement, here.
I'm not so sure we want to make a distinction between client and server as you write it. Both client and server can attach Digest header to request or response. It is the receiver of Digest that is exposed to the risk of using a weak digest. The current language avoids mentioning either endpoint so we leave it to implementers. I'm not opposed to spelling things out more clearly but we'd really need to nail down what we mean by "using Digest algorithms" because that relates to requesting them, generating them, regenerating them (proxy), validating them (endpoint or proxy) etc.
That's a good point about client/server. Sorry, I had that wrong. As you say, it's the recipient of a Digest that must decide whether the algorithm is sufficient. This recipient may be either the client or the server. I think the document is right to point out the dangers of accepting a weak digest. Perhaps there is a useful distinction between generating a digest and accepting a digest; e.g., an agent MAY support generating a weak digest but SHOULD NOT accept a weak digest.
Not wrong, just partially true. That could work for me. I'll leave it to NAME to decide what he things makes sense to do.
NAME NAME as this issue is for ADLER, I moved the discussion to As it's in the listed algorithms, the server MAY already implement ADLER32, though it SHOULD NOT be used by both sides of the communication. I think sender and receiver should behave consistently (see again).
Merging as for the positive feedback from NAME and NAME comment URL
Code change:
4. This document describes a number of ways that a message can be <del> invalid.  Invalid messages MUST NOT be processed except to log an error and produce an error response. </del> <ins> invalid.  Invalid messages MUST NOT be processed further except to log an error and produce an error response. </ins> The format is designed to allow incremental processing. Implementations need to be aware of the possibility that an error

Related discussion:
text: Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm
Code change:
10. <ins> The use of TLS is necessary to provide many of the security properties of this protocol.  Many of the claims in this section do not hold unless TLS is used as described in TLSUsage. </ins> 10.1. HTTP/2 relies on the HTTP definition of authority for determining

Related discussion:
text: ... or the analysis in the security considerations. We had to walk a more careful path when RFC 7540 was published, so we were careful to legitimize h2c. In the years since, things have changed and we can be more direct. This isn't a "don't use h2c", but more of a disclaimer as far as security goes.
Maybe a hangover from trying to tear up the photos of the "http" URI and upgrade dance. But this seems to read oddly. On one hand: on the other: I don't have a solid suggestion to improve things.
How about we just remove "h2c" from the latter statement.
OK, that isn't going to fly. I just tried it. Pulling that string is unwise. We agreed to keep "prior knowledge" in the document, and the "h2c" ALPN token is part of that. The "h2c" upgrade token has been removed already. (Too subtle? Probably.)
Code change:
The original datum becomes the payload of the signed COSE message. <ins> The message imprint sent to the TSA (RFC3161) MUST be the hash of the payload field of the COSE signed object. </ins> 2.2. fig-cose-then-timestamp shows the case where the signature(s) field

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:
The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see <del> Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </del> <ins> Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR.  The initial value is 0. </ins> Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the

Related discussion:
text: NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.
Code change:
A shared cache MUST NOT use a cached response to a request with an header field (header.authorization) to satisfy any subsequent request <del> unless a response directive that allows such responses to be stored is present. </del> <ins> unless the response contains a </ins> <del> In this specification, the following </del> <ins> field with a response directive (cache-response-directive) that allows it to be stored by a shared cache and the cache conforms to the requirements of that directive for that response. </ins> <del> response directives (cache-response-directive) have such an effect: must-revalidate, public, and s-maxage. </del> <ins> In this specification, the following response directives have such an effect: must-revalidate (cache-response-directive.must-revalidate), public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage). </ins> 3.3.

Related discussion:
text: This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.
Code change:
(appointed by the IESG or their delegate).  Fields with the status 'permanent' are Specification Required (RFC8126). <del> Registration requests consist of at least the following information: </del> <ins> Registration requests consist of the following information: </ins> And, optionally:

Related discussion:
text: For
Registration requests consist of at least the following information: [...] Specification document(s): Reference to the document that specifies the field, preferably If the registration consists of "at least" a group of information that includes a specification document, doesn't that mean the policy is always "Specification Required", not just for permanent registrations?
I think the intent here was to encourage but not require a specification for provisional registration. Will PR.
Code change:
9.3. <ins> The authorization challenge endpoint is capable of directly receiving user credentials and returning authorization codes.  This exposes a new vector to perform credential stuffing attacks, if additional measures are not taken to ensure the authenticity of the application. An authorization server may already have a combination of built-in or 3rd party security tools in place to monitor and reduce this risk in browser-based authentication flows.  Implementors SHOULD consider similar security measures to reduce this risk in the authorization challenge endpoint.  Additionally, the attestation APIs SHOULD be used when possible to assert a level of confidence to the authorization server that the request is originating from an application owned by the same party. 9.4. </ins> Typically, mobile and desktop applications are considered "public clients" in OAuth, since they cannot be shipped with a statically configured set of client credentials RFC8252.  Because of this,

Related discussion:
text: I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.
Code change:
reachable, it is necessary that each partition of the stub network have its own prefix.  When such a partition occurs, the stub routers must detect that it has occurred.  If a stub router is currently <del> providing a prefix on the stub network, it need take no action.  If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network. It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </del> <ins> providing a prefix on the stub network, it needs to take no action. If a stub router had not been providing a prefix on the stub network, and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix on the stub network.  It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s). </ins> When partitions of this type occur, they may also heal.  When a partition heals in a situation where two stub routers have both been

Related discussion:
text: AIL is used as an acronym in multiple places but not defined. also put colons on the glossary terms
I don't think there was consensus (even close) on the use of CPE router, unfortunately. I don't really agree with s/need/needs to/, but maybe s/need take no action/does not need to take action/ for better clarity?
Code change:
undefined or unknown, unless the field's specification specifically disallows them. <del> When serialised as a textual HTTP field, Members are ordered as </del> <ins> When serialized as a textual HTTP field, Members are ordered as </ins> serialized and separated by a comma with optional whitespace.  Member keys cannot contain uppercase characters.  Keys and values are separated by "=" (without whitespace).  For example:

Related discussion:
text: There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.
Code change:
This document defines a new response header, Accept-CH, that allows an origin server to explicitly ask that clients send these headers in <del> requests, for a period of time bounded by the Accept-CH-Lifetime response header.  It also defines guidelines for content negotiation </del> <ins> requests.  It also defines guidelines for content negotiation </ins> mechanisms that use it, colloquially referred to as Client Hints. Client Hints mitigate the performance concerns by assuring that

Related discussion:
text: Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM
Code change:
of SEMANTICS. The definitions "representation", "selected representation", <del> "representation data", "representation metadata", and "payload data" in this document are to be interpreted as described in SEMANTICS. </del> <ins> "representation data", "representation metadata", and "content" in this document are to be interpreted as described in SEMANTICS. </ins> Algorithm names respect the casing used in their definition document (eg.  SHA-1, CRC32c) whereas digest-algorithm tokens are quoted (eg.

Related discussion:
text: Use "content" instead of "payload data".
to reference semantics-14, including "payload data" --> "content".
Code change:
A stream that only has frames sent in one direction can be tentatively considered to be closed once a frame containing a <del> FINAL flag is sent.  The active sender on the stream MUST be </del> <ins> END_STREAM flag is sent.  The active sender on the stream MUST be </ins> prepared to receive frames after closing the stream. Either peer can send a RST_STREAM control frame at any time to

Related discussion:
text: This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.