jiebi/CodeConvo huggingface dataset:
tree alg (label: TBD): REQUIRED.  Merkle tree algorithm.  Value type: int / tstr. <del> tree size (label: TBD): OPTIONAL.  Merkle tree size as the number of leaves.  Value type: uint. </del> A COSE profile of this specification may add further header <del> parameters, for example to identify the signer. </del> <ins> parameters, for example to identify the signer or add a timestamp. Envelope Payload: A Merkle tree root according to the tree alg. </ins> <del> Payload: Merkle tree root hash bytes according to tree alg (i.e., header params tell you what the alg id is here) </del> <ins> The envelope payload can be detached, since it can be recomputed by the verifier. </ins> <del> Note: The payload is just a byte string representing the Merkle tree root hash (and not some wrapper structure) so that it can be detached (see defintion of payload in https://www.rfc-editor.org/rfc/ rfc9052#section-4.1) and easily re-computed from an inclusion path and leaf bytes.  This allows to design other structures that force re-computation and prevent faulty implementations (forgetting to match a computed root with one embedded in a signature). </del> <ins> Forcing a verifier to perform re-computation can prevent faulty implementations. </ins> <del> One example of a Signed Merkle Tree Proof is a "transparent signed statement" or "claim" as defined in I-D.ietf-scitt-architecture. </del> <ins> One example of a Signed Inclusion Proof is a "transparent statement" as defined in I-D.ietf-scitt-architecture. </ins> 3.2.
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
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
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.
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.
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>
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,
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
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.
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
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
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
The "no-cache" response directive indicates that the response MUST <del> NOT be used to satisfy a subsequent request without successful validation on the origin server.  This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses. </del> <ins> NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see validation.model. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses. </ins> If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent request,
5.2.2.3. The "no-store" response directive indicates that a cache MUST NOT <del> store any part of either the immediate request or response.  This directive applies to both private and shared caches.  "MUST NOT </del> <ins> store any part of either the immediate request or response, and MUST NOT use the response to satisfy any other request. This directive applies to both private and shared caches.  "MUST NOT </ins> store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best- effort attempt to remove the information from volatile storage as
requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a <del> cache MUST: </del> <ins> cache MUST use the header fields provided in the new response, aside from </ins> <del> delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any header fields in the stored response with warn-code 2xx; and, use other header fields provided in the new response, aside from , to replace all instances of the corresponding header fields in the stored response. </del> <ins> , to replace all instances of the corresponding header fields in the stored response. </ins> 4.
forward path) or doing so is explicitly allowed (e.g., by the max- stale request directive; see cache-request-directive). <del> A cache SHOULD generate a header field with the 110 warn-code (see warn.110) in stale responses.  Likewise, a cache SHOULD generate a 112 warn-code (see warn.112) in stale responses if the cache is disconnected. A cache SHOULD NOT generate a new header field when forwarding a response that does not have an header field, even if the response is already stale.  A cache need not validate a response that merely became stale in transit. </del> 4.3. When a cache has one or more stored responses for a requested URI,
response also lacks a validator, then that stored response is identified for update. <del> For each stored response identified for update, the cache MUST: delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any header fields in the stored response with warn-code 2xx; and, </del> <ins> For each stored response identified for update, the cache MUST use the header fields provided in the </ins> <del> use other header fields provided in the response to replace all instances of the corresponding header fields in the stored response. </del> <ins> response to replace all instances of the corresponding header fields in the stored response. </ins> 4.3.5.
consider the stored response to be stale. If a cache updates a stored response with the metadata provided in a <del> HEAD response, the cache MUST: delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any </del> <ins> HEAD response, the cache MUST use the header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the </ins> <del> header fields in the stored response with warn-code 2xx; and, use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the header field. </del> <ins> header field. </ins> 4.4.
8.3. <del> Please update the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at <https://www.iana.org/assignments/http-warn-codes> with the registration procedure of warn.code.registry and the warn code values summarized in the table of header.warning. </del> <ins> Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn Codes" registry at <https://www.iana.org/assignments/http-warn-codes> to the effect that Warning is obsoleted. </ins> Index <del> 1 110 (warn-code) 111 (warn-code) 112 (warn-code) 113 (warn-code) 199 (warn-code) 2 214 (warn-code) 299 (warn-code) </del> A Age header field age
6. <del> User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation </del> <ins> Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons that can be used to redisplay a representation </ins> retrieved earlier in a session. <del> The freshness model (expiration.model) does not necessarily apply to history mechanisms.  That is, a history mechanism can display a previous representation even if it has expired. </del> <ins> Likewise, some Web browsers implement caching of images and other assets within a page view; they may or may not honor HTTP caching semantics. </ins> <del> This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store). </del> <ins> The requirements in this specification do not necessarily apply to how applications use data after it is retrieved from a HTTP cache. That is, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. This does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache- Control: no-store). </ins> 7.
4.3.1. <del> When sending a conditional request for cache validation, a cache sends one or more precondition header fields containing metadata from its stored response(s), which is then compared by recipients to determine whether a stored response is equivalent to a current representation of the resource. </del> <ins> When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request using a stored response by copying the method, request-target, and request header fields used for identifying the secondary cache key caching.negotiated.responses. It then updates that request with one or more precondition header fields.  These contain validator metadata sourced from stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource. </ins> One such validator is the timestamp given in a
A client sends an HTTP request to a server in the form of a <del> message, beginning with a request-line that includes a method, URI, and protocol version (request.line), followed by header fields containing request modifiers, client information, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> message, beginning with a method (methods) and URI, followed by header fields containing request modifiers, client information, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). </ins> A server responds to a client's request by sending one or more HTTP <del> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase (status.line), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> messages, each beginning with a success or error code (status.codes), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). A connection might be used for multiple request/response exchanges. </ins> The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> A connection might be used for multiple request/response exchanges, as defined in persistent.connections. </del> Responses (both final and non-final) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the
changes being summarized in changes.from.rfc.7230.  The other parts of RFC7230 are obsoleted by "HTTP/1.1 Messaging" Messaging.  This document also obsoletes RFC7231 (see changes.from.rfc.7231), RFC7232 <del> (see changes.from.rfc.7232), RFC7233 (see changes.from.rfc.7233), and RFC7233 (see changes.from.rfc.7235), and RFC7615 (see changes.from.rfc.7615). </del> <ins> (see changes.from.rfc.7232), RFC7233 (see changes.from.rfc.7233), RFC7233 (see changes.from.rfc.7235), RFC7233 (see changes.from.rfc.7538), and RFC7615 (see changes.from.rfc.7615). </ins> 1.1.
contains a short hypertext note with a hyperlink to the different URI(s). <ins> 9.4.9. The status code indicates that the has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.  Clients with link editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible. The server SHOULD generate a header field in the response containing a preferred URI reference for the new permanent URI.  The user agent MAY use the Location field value for automatic redirection.  The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s). A 308 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness). </ins> 9.5. The
authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. <del> A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below). </del> <ins> Aside from the well-known exception noted below, a sender MUST NOT generate multiple header fields with the same field name in a message, or append a header field when a field of the same name already exists in the message, unless that field's definition allows multiple field values to be recombined as a comma-separated list [i.e., at least one alternative of the field's definition allows a comma-separated list, such as an ABNF rule of #(values)]. </ins> A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the