jiebi/CodeConvo huggingface dataset:
Code change:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Related discussion:
text: inclusion proof". We prefer to use the term "inclusion path" to avoid confusion with <del> Signed Merkle Tree Proof. </del> <ins> Signed Inclusion Proof. Editors note: We may want to move inclusion path representations to the specification that is required to register a new algorithm in the proposed tree algorithms registry. Editors note: We recommend tree algorithm simple take the inclusion path as opaque bytes. </ins> If the tree size and leaf index is known, then a compact inclusion path variant can be used: <del> Otherwise, the direction for each path step must be included: </del> <ins> Leaf index is also sometimes referred to as sequence number. Otherwise, the direction each path step must be included: </ins> FIXME bit vector: 0 right, 1 left, so no bit labels
Code change:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Related discussion:
text: themselves and both the index and direction can be left out in the path: <del> Note: Including the tree size and leaf index may not be appropriate in certain privacy-focused applications as an attacker may be able to derive private information from them. TODO: Should leaf index be part of inclusion path (IndexAwareInclusionPath) or outside? </del> <ins> Presence of leaf index, and whether it is an input or an output is tree algorithm specific. </ins> <del> TODO: Define root computation algorithm for each inclusion path type TODO: Do we need both inclusion path types? what properties does each type have? [1] </del> <ins> 3.3. </ins> <del> TODO: Should the inclusion path be opaque (bstr) and fixed by the tree algorithm?  It seems this is orthogonal and the choice of inclusion path type should be application-specific. </del> <ins> An inclusion proof is a CBOR array containing a merkle tree root, an inclusion path, extra data for the tree algorithm, and the payload. </ins> <del> 3.3. </del> <ins> 3.4. </ins> <del> A signed Merkle tree proof is a CBOR array containing a signed tree </del> <ins> A signed inclusion proof is a CBOR array containing a signed tree </ins> root, an inclusion path, extra data for the tree algorithm, and the payload. <del> "extra_data" is an additional input to the tree algorithm and is used together with the payload to compute the leaf hash.  A use case for this field is to implement blinding. </del> <ins> "extra-data" is an additional input to the tree algorithm and is used together with the payload to compute the leaf hash.  See sec-leaf- blinding-example for an example use case for this field to enable leaf blinding as described in sec-leaf-blinding. </ins> <del> TODO: maybe rename "extra_data" </del> <ins> 3.5. </ins> <del> 3.4. </del> <ins> 3.5.1. This signed mulitple inclusion proof representation relies on 2 lists to enable proof of inclusion for multiple payloads in a given signed merkle root. </ins> <del> TODO: define a multi-leaf variant of a signed Merkle tree proof like in: </del> <ins> Note that the extra-data may be ommited if not required by the tree algorithm, and that leaf payloads may be detached. TODO: refine multi-leaf variant of a signed inclusion proof like in: </ins> https://github.com/transmute-industries/merkle-proof
Code change:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Related discussion:
text: 4. <del> This document establishes a registry of Merkle tree algorithms with </del> <ins> This document establishes a registry of merkle tree algorithms with </ins> the following initial contents: <del> [FIXME] exploration table, what should go into -00? </del> Each tree algorithm defines how to compute the root node from a sequence of leaves each represented by payload and extra data.  Extra data is algorithm-specific and should be considered opaque. <del> 4.1. </del> <ins> 5. </ins> <del> The "RFC9162_SHA256" tree algorithm uses the Merkle tree definition from RFC9162 with SHA-256 hash algorithm. </del> <ins> TBD </ins> <del> For n > 1 inputs, let k be the largest power of two smaller than n. </del> <ins> 5.1. </ins> <del> where "d(0)" is the payload.  This algorithm takes no extra data. </del> <ins> In cases where a single merkle root and multiple inclusion paths are used to prove inclusion for multiple payloads.  There is a risk that an attacker may be able to learn the content of undisclosed payloads, by brute forcing the values adjacent to the disclosed payloads through application of the cryptographic hash function and comparison to the the disclosed inclusion paths.  This kind of attack can be mitigated by including a cryptographic nonce in the construction of the leaf, however this nonce must then disclosed along side an inclusion proof which increases the size of multiple payload signed inclusion proofs. </ins> <del> 5. </del> <ins> 6. </ins> TBD <del> 6. </del> <ins> 6.1. </ins> <del> TBD </del> <ins> The choice of cryptographic hash function is the primary primitive impacting the security of authenticating payload inclusion in a merkle root.  Tree algorithm designers should review the latest guidance on selecting a suitable cryptographic hash function. </ins> 7.
Code change:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Related discussion:
text: IANA will be requested to register the new COSE Header parameters defined below in the "COSE Header Parameters" registry at some point. <ins> Name: tree_alg Label: TBD Value type: tree_alg Value registry: See Description: Merkle tree algorithm used to produce a COSE Sign1 payload. </ins> 7.2. IANA will be asked to add a new registry "TBD" to the list that <del> appears at https://www.iana.org/assignments/. </del> <ins> appears at IANA Assignments [1]. </ins> The rest of this section defines the subregistries that are to be created within the new "TBD" registry.
Code change:
Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.

Related discussion:
text: 7.2.1. IANA will be asked to establish a registry of tree algorithm <del> identifiers, named "Tree Algorithms", with the following registration procedures: TBD </del> <ins> identifiers, named "Tree Algorithms" to be administered under a Specification Required policy RFC8126. Template: Identifier: The two-byte identifier for the algorithm Tree Algorithm: The name of the algorithm </ins> <del> The "Tree Algorithms" registry initially consists of: </del> <ins> Reference: Where this algorithm is defined </ins> <del> The designated expert(s) should ensure that the proposed algorithm has a public specification and is suitable for use as [TBD]. </del> <ins> Initial contents: Provided in </ins> 8.  References 8.1.  URIs <del> [1] https://github.com/ietf-scitt/cose-merkle-tree-proofs/issues/6 </del> <ins> [1] https://www.iana.org/assignments/ </ins>
Code change:
The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.

Related discussion:
text: The "Connection" header field allows the sender to list desired control options for the current connection. <ins> Connection options are case-insensitive. </ins> When a field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field name within the Connection header field.
Code change:
The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.

Related discussion:
text: message is forwarded and, for each connection-option in this field, remove any header or trailer field(s) from the message with the same name as the connection-option, and then remove the Connection header <del> field itself (or replace it with the intermediary's own connection </del> <ins> field itself (or replace it with the intermediary's own control </ins> options for the forwarded message). Hence, the Connection header field provides a declarative way of
Code change:
The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.

Related discussion:
text: to be deployed without fear that they will be blindly forwarded by older intermediaries. <del> Furthermore, intermediaries SHOULD remove or replace field(s) whose semantics are known to require removal before forwarding, whether or not they appear as a Connection option, after applying those fields' </del> <ins> Furthermore, intermediaries SHOULD remove or replace fields that are known to require removal before forwarding, whether or not they appear as a connection-option, after applying those fields' </ins> semantics.  This includes but is not limited to: <del> The Connection header field's value has the following grammar: Connection options are case-insensitive. </del> A sender MUST NOT send a connection option corresponding to a field that is intended for all recipients of the content.  For example,
Code change:
See URL
Mailing list discussion:
We might want to clarify the nature of the response elsewhere, but this seems fine.

Related discussion:
text: status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more <del> parts of the selected representation that correspond to the satisfiable ranges found in the request's header field (header.range). </del> <ins> parts of the selected representation. </ins> When a 206 response is generated, the server MUST generate the following header fields, in addition to those required in the
Code change:
In Caching 3.3, we say "a cache may store a response body that is not complete" -- I think we should drop "body" In Caching 7.1, we use "payload" -- probably should be "content"

Related discussion:
text: If the request method is GET, the response status code is , and the entire response header section has been received, a cache <del> MAY store a response body that is not complete (message.framing) if the stored response is recorded as being incomplete.  Likewise, a </del> <ins> MAY store a response that is not complete (message.framing) provided that the stored response is recorded as being incomplete.  Likewise, a </ins> response MAY be stored as if it were an incomplete
Code change:
In Caching 3.3, we say "a cache may store a response body that is not complete" -- I think we should drop "body" In Caching 7.1, we use "payload" -- probably should be "content"

Related discussion:
text: 7.1. <del> Storing a malicious payload in a cache can extend the reach of an </del> <ins> Storing malicious content in a cache can extend the reach of an </ins> attacker to affect multiple users.  Such "cache poisoning" attacks happen when an attacker uses implementation flaws, elevated privileges, or other techniques to insert a response into a cache.
Code change:
That needs some tweaks ... the action words like SHOULD are supposed to be targeted to implementation roles, not protocol extensions. Can we just copy the same Note from the Accept section?
I can avoid the SHOULD NOT. I used different text because for transfer codings "we" actually own the registry, while for content types we do not...
Heh, I think it's a stretch of the imagination to think that we control the registry even when we define it ... people still deploy first and register later. In any case, a simple should be sufficient.
I actually reverse my opinion about the SHOULD NOT - we already use BCP14 keywords in the paragraphs before and after this one. So please consider again the pull request.
My .02 - acknowledging that 2119 keywords are only intended for implementations roles, I don't think that throwing up our hands and saying "people will do what they will" is productive. While some people ignore (or just don't read) the RFCs, many do, and when they do, we owe it to them to communicate in the clearest, concise way possible. 2119 keywords are a fantastic tool for doing that.
NAME - so are you ok with this change?
I am - although if we come up with a unified way to deal with requirements consistently across the documents, it might change.
Continuing from URL In the current spec, nothing is said about how to handle transfer-parameters. Notably, nothing is said about the case sensitivity of the parameter key. This results in a conflict with the TE header: if you see a "q" token, you cannot know if it is a transfer-parameter vs a t-ranking. It is noted that the "q" token is case insensitive in section 4.3.
See URL
OK. An edge case of an edge case. Note that among the currently registered transfer codings, none defines parameters. Drastic options might be: Disallow parameters on transfer codings (and thus also on content codings) Remove quality values on transfer coding negotiation. More realistic: in the registration procedure for content/transfer codings, note that a parameter "q" is discouraged (forbidden) due to the ambiguity in "TE". Should I make a proposal for this?
Actually, we have a similar situation for Accept:; see :
Not only "q" but also "Q": case sensitivity isn't mentioned for transfer parameters.

Related discussion:
text: identical, as is the case for the compression codings defined in compression.codings. <ins> The header field (header.te) uses a pseudo parameter named "q" as rank value when multiple transfer codings are acceptable.  Future registrations of transfer codings SHOULD NOT define parameters called "q" (case-insensitively) in order to avoid ambiguities. </ins> Values to be added to this namespace require IETF Review (see RFC8126), and MUST conform to the purpose of transfer coding defined in this specification.
Code change:
HTTP defines its own protocol versions as having two numbers "URL" regardless of anyone's future opinions on the subject. This is necessary for Via and Upgrade. In the past, it has always been assumed that no document claiming to define a version of HTTP would ignore that fact. Regardless, HTTP/1.1 needs to refer to future versions of HTTP within the scope of its own syntax. Hence, the following text (currently in crefs) has been suggested for the last paragraph of the section "Protocol Versioning" in Semantics.
SGTM
Why "ought to be used"? I understand that you want to avoid MUST/SHOULD,..., but why not just "is used"? That would make it:
+1, let's limit the RFC6919 language. You're defining a mapping between formats, not really adding new normative or moral requirements. The "0" is simply how a major-only version is rendered in a URL field.
The background here is that we used 'ought' liberally in 723x (e.g., 49 times in 7231) to give implementers guidance towards good behaviour without affecting conformance for existing deployments. So this is entirely in the spirit of the existing specifications.
That use is often appropriate. In this case, the conditions are such that "is" works. It is also more assertive, which works.
all: try and do your best to focus on the substance of the question rather than the editorial wrappings. Thanks.
The substance of the question is obvious, in my opinion. I'd question whether there's a need for discussion on that. However, the editorial wrappings do actually matter in having the final document communicate what we want it to communicate. It's feedback I'd typically give on a PR rather than the issue, but in this case the issue contains proposed text, so the editorial feedback is here too.
Agree with Mike. I came to this issue almost by chance, I thought it was important because Julian wrote a mail to the mailing list. When I had a look at the issue, the only thing that caught my eye was the "ought", because the substance is indeed obvious (at least to me). If "ought" is used liberally in 723x, there may be good reasons for it, and in many places it may make sense. But I'd ask the editors to go through these 49++ times and see if it wouldn't be possible to replace some of them with "is". "is" just reads so much more easily where it's appropriate than "ought".

Related discussion:
text: sufficiently backwards-compatible to be safely processed by any implementation of the same major version. <ins> When a major version of HTTP does not define any minor versions, the minor version "0" is implied and is used when referring to that protocol within a protocol element that requires sending a minor version. </ins> 4. Each major version of HTTP defines its own syntax for the inclusion
Code change:
The text is almost the same as in RFC 4918, except that I removed the somehow bogus claim that status code 400 wouldn't be right.
Are we updating the IANA registry to point to this document? The only slight concern I have here is that this may unintentionally reinforce the view that "real" status codes are required to be in the core document. If we can find a way to discourage that view, that would be great (but that's a separable issue).
Yes. For all codes. That occurred to me as well.
Ok, should I merge this one?
It's commonly used, but defined in RFC 4918 (WebDAV),, which continues to confuse people. Should we include it in the core specs?
For reference: URL
+1
Discussed in Montreal; support for doing this.

Related discussion:
text: 9.5.19. <ins> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a status code is inappropriate), and the syntax of the request entity is correct but was unable to process the contained instructions.  For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions. 9.5.20. </ins> The status code indicates that the server refuses to perform the request
Code change:
The text is almost the same as in RFC 4918, except that I removed the somehow bogus claim that status code 400 wouldn't be right.
Are we updating the IANA registry to point to this document? The only slight concern I have here is that this may unintentionally reinforce the view that "real" status codes are required to be in the core document. If we can find a way to discourage that view, that would be great (but that's a separable issue).
Yes. For all codes. That occurred to me as well.
Ok, should I merge this one?
It's commonly used, but defined in RFC 4918 (WebDAV),, which continues to confuse people. Should we include it in the core specs?
For reference: URL
+1
Discussed in Montreal; support for doing this.

Related discussion:
text: 415 Unsupported Media Type (status code) 416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) <ins> 422 Unprocessable Entity (status code) </ins> 426 Upgrade Required (status code) 4xx Client Error (status code class)
Code change:
Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok

Related discussion:
text: 9.5.19. <ins> RFC2324 was an April 1 RFC that lampooned the various ways HTTP was abused; one such abuse was the definition of an application-specific 418 status code.  In the intervening years, this status code has been widely implemented as an "Easter Egg", and therefore is effectively consumed by this use. Therefore, the 418 status code is reserved in the IANA HTTP Status Code registry.  This indicates that the status code cannot be assigned to other applications currently.  If future circumstances require its use (e.g., exhaustion of 4NN status codes), it can be re- assigned to another use. 9.5.20. </ins> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a
Code change:
Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok

Related discussion:
text: contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions. <del> 9.5.20. </del> <ins> 9.5.21. </ins> The
Code change:
Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok

Related discussion:
text: status code values summarized in the table of overview.of.status.codes. <ins> Additionally, please update the following entry in the Hypertext Transfer Protocol (HTTP) Status Code Registry: </ins> 13.4. Please update the "Message Headers" registry of "Permanent Message
Code change:
Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok

Related discussion:
text: 415 Unsupported Media Type (status code) 416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) <ins> 418 (Unused) (status code) </ins> 422 Unprocessable Entity (status code) 426 Upgrade Required (status code) 4xx Client Error (status code class)
Code change:
The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.

Related discussion:
text: 5.2.2.1. The "must-revalidate" response directive indicates that once it has <del> become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server. </del> <ins> become stale, the response MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see validation.model. </ins> The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a