jiebi/CodeConvo huggingface dataset:
Code change:
single byte for every operation and thus keeping implementations simpler and less error prone. <del> The overall status list is encoded as a byte array.  Depending on </del> <ins> The overall Status List is encoded as a byte array.  Depending on </ins> the "bit-size" each byte corresponds to 8/(#bit-size) statuses (8,4,2, or 1).  The status of each Referenced Token is identified <del> using an index that maps to one or more specific bits within the byte array.  The index starts counting at 0 and ends with "size" - 1(being the last valid entry).  The bits within an array are counted from least significant bit "0" to the most significant bit ("7").  All bits of the byte array at a particular index are set to a status value. </del> <ins> using the "index" that maps to one or more specific bits within the byte array.  The index starts counting at 0 and ends with "size" - 1(being the last valid entry).  The bits within an array are counted from least significant bit "0" to the most significant bit ("7").  All bits of the byte array at a particular index are set to a status value. </ins> The complete byte array is compressed using gZIP RFC1952.

Related discussion:
text: after writing this I figured out changing the byte ordering, i.e. starting with byte 0 on the left might be a little more intuitive?
Yeah with fresh eyes I definately think that would be better.
reversed byte order and added the index to the ascii art
Code change:
The value is encoded as an sf-integer.  The default value is 3. <del> This parameter indicates the sender's recommendation, based on the expectation that the server would transmit HTTP responses in the order of their urgency values if possible.  The smaller the value, the higher the precedence. </del> <ins> Endpoints use this parameter to communicate their view of the precedence of HTTP responses.  The chosen value of urgency can be based on the expectation that servers might use this information to transmit HTTP responses in the order of their urgency.  The smaller the value, the higher the precedence. </ins> The following example shows a request for a CSS file with the urgency set to "0":

Related discussion:
text: . By replacing "sender" with "client", we make the urgency and incremental section more consistent with how they discuss these concepts.
Paraphrasing NAME feedback, in S 4.1 we say we might consider clearer statements about the actors are i.e. who sends this parameter, and who actions it.
For clarity, it's mainly the term "sender" in "sender's recommendations" that I find unclear here, since the server can also "send" Priority information, where it doesn't always reflect the server's "recommendation" when doing so (e.g., sometimes it's just echo'ing the client's value).
We don't really need to hammer home the "recommendation" concept, that's explained elsewhere in the document. I'll propose an editorial change to this text to focus on the thing we care about
Code change:
service MAY enforce its own Registration Policies for authorizing entities to register their Signed Statements to the append-only Log. Some Transparency Services may also enforce authorization policies <del> limiting who can write, read and audit specific Feeds or the full </del> <ins> limiting who can write, read and audit specific Subjects or the full </ins> registry.  It is critical to provide interoperability for all Transparency Services instances as the composition and configuration of involved supply chain entities and their system components is

Related discussion:
text: PR addressing the conversation around Feed is redundant with Subject, as defined in CWT This PR intentionally contrasts Choice for folks to vote upon: [ ] Rename Feed to Subject [ ] Should we also include CWT_Claims, which contains the subject
Copied over from: URL A feed is a great base for how we can create a series of statements for different artifacts, getting freshness for a receipt/or VEX report. The current definition likely needs to expand a bit to account for: What are the versions of a specific artifact What are all the statements for a version of an artifact What is the latest statement for a specific of a specific versioned : (eg: what's the latest or for the software? If the is a referenced , which stores SBOMs, Scan Reports, how do we drill into each if they all use the same payload of satementByReference?
I'm not sure if "feed" represents the right concept, when it seems to me that the API to the registry will need to offer the ability to query records for specific orgs-products-models-releases, and collect all the relevant records, which likely include a number of ledger entries to various related artifacts. With that said, can imagine also the notion of a different API which would provide a feed of updates to the registry, esp. to allow a mirrored version or to perhaps aggregate from several source registries.
This is a good point and one possible improvement that was already brought up at the previous IETF meeting is to enable some structure in the feed header. For instance, using an array of strings would capture many of the common patterns (such as product > model > release), and allow some advanced functions in the API (such as prefix-based querying). Another approach would be to allow each issuer to structure their feed using arbitrary CBOR representations; while this captures many more complex usages (e.g. packages for different Linux distributions, binaries for different architectures) it becomes harder for the transparency service to understand what constitutes related claims (it requires interpretation of the feed format), and thus, harder to define auditing APIs.
NAME I've got the notes on feeds and I've been working on a proposal. Would you like to collaborate on it? Deferring to 117 for prioritization, but a great discussion as many things will be built upon feeds.
Code change:
service MAY enforce its own Registration Policies for authorizing entities to register their Signed Statements to the append-only Log. Some Transparency Services may also enforce authorization policies <del> limiting who can write, read and audit specific Feeds or the full </del> <ins> limiting who can write, read and audit specific Subjects or the full </ins> registry.  It is critical to provide interoperability for all Transparency Services instances as the composition and configuration of involved supply chain entities and their system components is

Related discussion:
text: A note from the We'll be iterating on this a bit more, to create some use cases and examples for how feeds help producers and consumers benefit from SCITT.
See: URL There are several problems with this definition. It conflates using aggregations over an header parameter, with the header parameter. It confuses how the TS uses the attribute with how the uses the attribute (same problem as above). Suggested changes: Registration policies only apply to the feed identifier, they do not apply to the feed resource. See URL regarding the Transparency Service exposing the Feed Resource.
LGTM!LGTM
Code change:
Value registry: See <del> Description: Merkle tree inclusion proof for the given tree_alg. </del> <ins> Description: Merkle tree inclusion proof for the given verifiable_data_structure. </ins> Name: consistency_proof

Related discussion:
text: This PR attempts to generalize "merkle tree alg" and associated tags for "merkle tree proof types", to: "verifiable data structure" and associated "verifiable data structure proof types". This is intended to support similar structures that provide similar proof types, but that are not based on merkle trees. We are specifically thinking of cryptographic accumulators, and the merkle^2 paper.
I'm not attached to "verifiable data structure" or "verifiable data structure proof types", just needed a word that didn't imply "trees".
The overall "verifiable data structure" generalization is fine, and doesn't impact the structure of the document too much. However, I am not fully satisfied with generalization of proof types. It seems very strange that TBD1 ("binary merkle tree using sha256", a tag that appears in the protected header of the COSE signed root) and TBD2 ("binary merkle tree using sha256, inclusion proof", a tag that appears in the CBOR type for inclusion proof associated with TBD1). It seems clear that TBD2 and TBD3 are refinements of TBD1 that should ideally be in a separate registry. Furthermore, as discussed last week, the notion of proof type (inclusion proof, consistency proof, freshness proof...) is a lot more meaningful than the notion of verfiable data structure type for protocols that build on COMETRE. Therefore, it may be natural to define either a universal type for each proof type, or at least agree on the convention that proofs for all verifiable data structures must be CBOR tagged with the same proof type, which is then defined as a separate registry. Each RFC that extends COMETE must define a new verifiable data structure but may or may not extend the proof type registry. For instance, it would allow the CCF_ledger to use the same CBOR tags for inclusion proof and consistency proof instead of having to define 3 tags with different semantics.
Code change:
Value registry: See <del> Description: Merkle tree inclusion proof for the given tree_alg. </del> <ins> Description: Merkle tree inclusion proof for the given verifiable_data_structure. </ins> Name: consistency_proof

Related discussion:
text: There were basically 2 paths discussed: (implemented in this PR) treealg (TBD1): RFC9162 (1) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): BitcoinMerkleTree (2) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): Merkle^2 Tree (3) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg search proof (TBD4): bytes based on treealg non inclusion proof (TBD5): bytes based on treealg (previously discussed at IETF 115) treealg (TBD1) : "RFC9162SHA256INCLUSIONPROOF" (TBDA) proof (TBDB): bytes based on alg treealg (TBD1) : "RFC9162SHA256CONSISTENCYPROOF" (TBDC) proof (TBDB): bytes based on alg Other things to consider... Can an unprotected header contain multiple proofs for a single type? Can an unprotected header contain multiple proofs of multiple types?
NAME NAME thank you for the reviews. All the CDDL examples will need some help, and certainly there is a lot more editorial work that needs to be done to fully align to this approach. I tried to do the minimum in this PR to host the discussion, but if we merge this, there will need to be further cleanup.
I should point out that the deletion of the consistency proof CDDL, means that it shows up before you define it below. If you think that is ok, I am fine with it.Approved, acknowledging the need for further editorial work & CDDL examplesI agree with Orie's choices; "verifiable data structure" and "proof type" are good generalizations, and I prefer the 2-layer algorithm as e.g. some verifiers may care about a commitment to a VDS even if they don't use a particular proof type.
Code change:
these: Note that double-quote delimiters are almost always used with the <del> quoted-string production; using a different syntax inside double- quotes will likely cause unnecessary confusion. </del> <ins> quoted-string production (quoted.strings); using a different syntax inside double-quotes will likely cause unnecessary confusion. </ins> Many fields (such as

Related discussion:
text: Hi! I post here my combined comments for draft-ietf-httpbis-semantics-16, as I don't think they deserve one issue each :) I hope that's fine. My comments range from minor to very minor to nit, and are mostly editorials and clarifications. As this can possibly be me, I'll leave it up to you to decide if they can be useful to improve readability, or not. Thanks for your work! Francesca [x] 1. ----- Additional (social) requirements are placed on implementations, FP: I am not sure I understand the meaning behind the term "social requirement". Editors: URL (URL) [x] 2. ----- 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. FP: I had a hard time parsing this sentence (starting at "and is used..."), maybe breaking it up with commas would be enough. Especially the two "that" are unclear to me. Editors: URL (URL) [x] 3. ----- RFC 3986, which allows for an empty path to be used in references, FP: very minor, I'd prefer "in URI references". Editors: URL, change applied in URL [x] 4. ----- The process for determining that access is defined by the URI scheme and often uses data within the URI components, such as the authority component when the generic syntax is used. However, authoritative FP: I had to read the sentence above 3 times before realizing that the subject of "is defined" is not "access", but "The process", and understanding it. Editors: URL, change applied in URL [x] 5. ----- A client MAY discard or truncate received field lines that are larger FP: I assume and It might have been good to clarify that "truncate" a field lines is equivalent to dropping a member of the list of values. Editors: URL [x] 6. ----- Note that double-quote delimiters are almost always used with the quoted-string production; using a different syntax inside double- FP: I am not sure I understand "quoted-string production" Editors: added missing fwd reference - URL [x] 7.
Code change:
these: Note that double-quote delimiters are almost always used with the <del> quoted-string production; using a different syntax inside double- quotes will likely cause unnecessary confusion. </del> <ins> quoted-string production (quoted.strings); using a different syntax inside double-quotes will likely cause unnecessary confusion. </ins> Many fields (such as

Related discussion:
text: ----- content, it is often desirable for the sender to supply, or the recipient to determine, an identifier for a resource corresponding to that representation. FP: It might have been good here to give a hint or example on why such identifiers could be desirable. Editors: URL (URL) [x] 8. ----- Fields (Section 5) that are located within a trailer section are are referred to as "trailer fields" (or just "trailers", FP: s/are are/are Editors: URL [x] 9. ----- All responses, regardless of the status code (including interim responses) can be sent at any time after a request is received, even if the request is not yet complete. A response can complete before FP: I think at this point in the text there is no definition of what qualifies a request or response being "complete". Editors: actually, the definition is earlier in the text; added a reference anyway: URL [x] 10. ----- An intermediary MAY combine an ordered subsequence of Via header field list members into a single member if the entries have identical received-protocol values. For example, FP: Is there any requirement on the intermediary to be able to collapse the ordered sequence into a single member (such as storing and being able to expand this information)? Might want to expand a little. Editors: Declined because there is no requirement to do so. We already explain that one might want to do so for information hiding of intermediaries within a private network (URL and URL) [x] 11. ----- This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access FP: I might be missing the motivation for it, but this paragraph seems strange to me. Why is it important that the client cannot be held accountable for it? The concern I have is that the text seems to be saying "safe is essentially read only/not harmful/..., but not really". (And same for idempotent) Editors: URL [x] 12. ----- referring to making a GET request.
Code change:
these: Note that double-quote delimiters are almost always used with the <del> quoted-string production; using a different syntax inside double- quotes will likely cause unnecessary confusion. </del> <ins> quoted-string production (quoted.strings); using a different syntax inside double-quotes will likely cause unnecessary confusion. </ins> Many fields (such as

Related discussion:
text: A successful response reflects the quality of "sameness" identified by the target URI. In turn, FP: I am confused by this terminology: quality of "sameness". Editors: URL [x] FP: The text could add something for when it is acceptable or expected to make sense (so why this is a SHOULD). Editors: Because the protocol has historically preferred to separate semantics from parsing requirements so that the semantics can be extended over time without breaking parsers. It is a SHOULD NOT for GET because the original protocol did not define a meaning for such message content and some implementations took advantage of that leniency to implement and deploy features that work among consenting implementations but are non-interoperable with intermediaries and other implementations. Hence, it's a bad idea, but the protocol does not prevent it from happening. See for why this is impossible to change. [x] 14. ----- A server SHOULD NOT use the From header field for access control or authentication. FP: Same as the previous comment, when is it acceptable to use the From header field for access control or authentication? Editors: URL [If it is acceptable to the server that does it, then HTTP doesn't care in terms of interop, but it is still a bad idea because the protocol has other mechanisms for doing access control and authentication which are less likely to be leaked by accident (URL)] [x] 15. ----- FP: I don't know if I missed it, and please correct me if I did, but I was hoping to find a sentence stating something of the sort for the header fields: "If not otherwise stated, these fields can be used with any method or response code". Editors: URL [x] 16. ----- FP: Most of the header fields contain examples, which I find helpful. I think it would be good to have examples for all of them (including TE, Trailer). Editors: URL [x] 17. ----- | Accept. Future media types are discouraged from registering | any parameter named "q". FP: I wonder if it would be worth making a not out of it in the media type registry (so that it's easily remembered by experts) Editors: URL [x] 18. ----- Note that an If-None-Match header field with a list value containing "\" and other values (including other instances of "\") is unlikely to be interoperable.
Code change:
these: Note that double-quote delimiters are almost always used with the <del> quoted-string production; using a different syntax inside double- quotes will likely cause unnecessary confusion. </del> <ins> quoted-string production (quoted.strings); using a different syntax inside double-quotes will likely cause unnecessary confusion. </ins> Many fields (such as

Related discussion:
text: FP: what does it mean for a header field specific value to be not-interoperable? I am also not sure how "*" between the list of values would be processed. 2. above does not specify it, only stating: If the field value is a list of entity-tags, the condition is false if one of the listed tags matches the entity-tag of the selected representation. FP: I would possibly interpret this as "search for tags matching the entity tag - ignore all others". Editors: URL and URL [x] 19. ----- senders might send erroneously send multiple values, and both FP: remove one "send". Editors: URL [x] 20. ----- the String data type of [RFC8941]), or a field-specific encoding). FP: remove the first parenthesis. Editors: URL [x] 21. ----- FP: This is more of a check, but I see that all references only point to sections. I hope this will be translated into "x.x.x of RFCthis", is that correct? Editors: URL
You mean in the tables for IANA registrations? That's for brevity; IANA knows how to deal with that.
The media type registry is not owned by "us". I don't think we have the authority to change it.
I will look into this with IANA and the DEs and get back. Just to be clear, the document states "future media types are discouraged..." but what we really mean is "experts should be conservative with assigning ..." , is that accurate? Yes, in theory we'd like to discourage media types to be registering "q", but the practical way to make sure that doesn't happen is to make the DEs react to it if it does.
maybe "...whenreferring to that protocol version..."? NAME ?
Yes, thanks!
I don't think it's restricted to that.
For instance, to provide a bookmark/make something accessable for a subsequent GET... NAME - do you want to add that?
I don't get that question. The spec allows collapsing. It doesn't require it. Could you please clarify your question?
The motivation is that if something is defined as "safe", I can URL do that operation without being held accountable.
Code change:
these: Note that double-quote delimiters are almost always used with the <del> quoted-string production; using a different syntax inside double- quotes will likely cause unnecessary confusion. </del> <ins> quoted-string production (quoted.strings); using a different syntax inside double-quotes will likely cause unnecessary confusion. </ins> Many fields (such as

Related discussion:
text: For instance, I can always GET a URI (such as for prefetch/preload/indexing) and if the server does do something stupid with that request (such as deleting a resource, or adding something to a shopping basked), it's their problem. Re idempotenty: this makes it possible to repeat a request.
The text states that intermediaries are allowed to collapse "an ordered subsequence of Via header field list members into a single member", and they can only do so "if the entries have identical received-protocol values." So I read 2 rules: the order matter, i.e. if (A,B) collapses to C, (B,A) does not map to C (A,B) must have identical recived-protocol values I was wondering about any additional rules that the intermediaries have to follow in order to collapse the list into one: for example, is it ever expected for the intermediary to remember that this single member was this collapsed ordered sequence? Are they ever requested to un-collapse?
Order matters for the purpose of collapsing. If you have "D, E, F", and E has a different protcol than D or F, you can't collapse. If "A, B" can be collapsed, so can "B, A" (because they have the same protocol) We are not saying that, so there is no expectation that the collapsing can be undone.
Ok, so yes I understand - the idea of this text is to say: "this is the intent, BUT be aware that implementations might do something stupid and not comply with this intent." I guess what I got stuck with was "the client can't be held accountable", as it wasn't clear to me what would it mean for a client to be held accountable, as clients in general are not aware of what's the action on the server their request will result in.
This might require a separate issue. A field value containing more than one list element and including "*" is invalid, and the spec really doesn't say what that means. The intent of saying "interoperable" is (IMHO) to prevent people from assuming the different servers will do the same thing with it. I believe we should clarify that a value like that is invalid, and thust MUST NOT be sent. NAME , NAME ?
That refers to URL - I guess we should cite that? NAME ?