jiebi/CodeConvo huggingface dataset:
Code change:
Value registry: See <del> Description: Merkle tree consistency proof for the given tree_alg. </del> <ins> Description: Merkle tree consistency proof for the given verifiable_data_structure. 8.1.2. IANA will be asked to establish a registry of tree algorithm identifiers, named "Verifiable Data Structures" to be administered under a Specification Required policy RFC8126. Template: Identifier: The two-byte identifier for the algorithm Algorithm: The name of the data structure Reference: Where the data structure is defined Initial contents: Provided in </ins> <del> 7.1.2. </del> <ins> 8.1.3. </ins> IANA will be asked to establish a registry of tree algorithm <del> identifiers, named "Tree Algorithms" to be administered under a Specification Required policy RFC8126. </del> <ins> identifiers, named "Verifiable Data Structures Proof Types" to be administered under a Specification Required policy RFC8126. </ins> Template: Identifier: The two-byte identifier for the algorithm <del> Tree Algorithm: The name of the algorithm </del> <ins> Algorithm: The name of the proof type algorithm </ins> <del> Reference: Where this algorithm is defined </del> <ins> Reference: Where the algorithm is defined </ins> Initial contents: Provided in

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 consistency proof for the given tree_alg. </del> <ins> Description: Merkle tree consistency proof for the given verifiable_data_structure. 8.1.2. IANA will be asked to establish a registry of tree algorithm identifiers, named "Verifiable Data Structures" to be administered under a Specification Required policy RFC8126. Template: Identifier: The two-byte identifier for the algorithm Algorithm: The name of the data structure Reference: Where the data structure is defined Initial contents: Provided in </ins> <del> 7.1.2. </del> <ins> 8.1.3. </ins> IANA will be asked to establish a registry of tree algorithm <del> identifiers, named "Tree Algorithms" to be administered under a Specification Required policy RFC8126. </del> <ins> identifiers, named "Verifiable Data Structures Proof Types" to be administered under a Specification Required policy RFC8126. </ins> Template: Identifier: The two-byte identifier for the algorithm <del> Tree Algorithm: The name of the algorithm </del> <ins> Algorithm: The name of the proof type algorithm </ins> <del> Reference: Where this algorithm is defined </del> <ins> Reference: Where the algorithm is defined </ins> Initial contents: Provided in

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:
.  Note that <del> can be sent and received in any stream state.  Frame of unknown types are ignored. </del> <ins> can be sent and received in any stream state.  Frames of unknown types are ignored. </ins> An example of the state transitions for an HTTP request/response exchange can be found in HttpSequence.  An example of the state

Related discussion:
text: There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.
Code change:
3.2.9. The name space under which the track name is defined.  See section <del> 2.3 of MoQTransport.  The track namespace is required to be specified for each track object.  If the track namespace is declared in the root of the JSON document, then its value is inherited by all tracks and catalogs and it does not need to be re-declared within each track or catalog object.  A namespace declared in a track object or catalog object overwrites any inherited name space. </del> <ins> 2.3 of MoQTransport.  If the track namespace is declared in the root of the JSON document, then its value is inherited by all tracks and catalogs and it does not need to be re-declared within each track or catalog object.  A namespace declared in a track object or catalog object overwrites any inherited name space.  The track namespace is optional.  If it is not declared at the root or track level, then each track MUST inherit the namespace of the catalog track. </ins> 3.2.10.

Related discussion:
text: Consensus for merging at IETF meeting.
Per the discussion at URL, it would be useful that if the namespace were absent, that track names would inherit the namespace of the catalog track in which they were defined. This capability allows for relative naming, which aids in portability.
I know there has been lots of debate on this but it seems reasonable.
Code change:
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses <del> TLS, such as "h2" RFC7540. </del> <ins> TLS, such as "h2" RFC7540, or "http/1.1" RFC7301.  Note that HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of RFC7230). </ins> A client that receives such an advertisement MAY make future requests intended for the associated origin (RFC6454) to the identified

Related discussion:
text: We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.
Code change:
frames to obscure the size of messages.  Padding is a security feature; see padding. <del> The DATA frame contains the following fields: </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The DATA frame contains the following additional fields: </ins> The DATA frame defines the following flags:

Related discussion:
text: I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.
Code change:
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

Related discussion:
text: 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"
Code change:
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <del> OBJECT message header carry short hop-by-hop Track Id that maps to </del> <ins> OBJECT message header carry short hop-by-hop Track ID that maps to </ins> the Full Track Name (see message-subscribe-ok).  Relays use the Track ID of an incoming OBJECT message to identify its track and find the active subscribers for that track.  Relays MUST NOT depend on OBJECT

Related discussion:
text: This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.
Code change:
frame with "TO_BE_CONTINUED" unset MUST be treated as a connection error of type "PROTOCOL_ERROR". <ins> If the "UNSOLICITED" flag is not set, the "CERTIFICATE" frame also contains a Request-ID indicating the certificate request which caused this exported authenticator to be generated.  The value of this flag and the contents of the Request-ID field MUST NOT differ between frames with the same Cert-ID. </ins> Upon receiving a complete series of "CERTIFICATE" frames, the receiver may validate the Exported Authenticator value by using the exported authenticator API.  This returns either an error indicating

Related discussion:
text: Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.
Code change:
3.1.2. Parameters are an ordered map of key-values pairs that are associated <del> with an item (item) or inner-list (inner-list).  The keys are required to be unique within the scope of a map of parameters, and the values are bare items (i.e., they themselves cannot be parameterised; see item). </del> <ins> with an item (item) or inner-list (inner-list).  The keys are unique within the scope of a map of parameters, and the values are bare items (i.e., they themselves cannot be parameterised; see item). </ins> The ABNF for parameters in HTTP headers is:

Related discussion:
text: NAME thanks for the review, see latest commit. is talking about the abstract model for dictionaries, so they are required to be unique. I've removed "required to be" so that people don't misread this.
allows a sender to generate multiple header fields with the same name, if the field is defined as a comma-separated list [i.e., #(values)], and that such duplicates are semantically equivalent to them concatenated into a single header field. I think that this property has been useful for us, when annotating header fields. Can we allow such duplicates for Structured Headers too, when a list or a dictionary is being used? Note that we have merged based on the assumption that it is okay to require the consumer of SH header fields to have the knowledge on what the top type is.
That's always been the intent; are you saying that we should have text specifically enabling this for serialisation of dictionaries and lists?
Good to know that that has been the intent. Yes, I think we should clarify that explicitly for dictionaries and lists, because RFC 7230 can be interpreted to allow duplicates only for those using notation (which we do not use in SH). Also, it might be a good idea to revisit the rule for duplicate dictionary values, as I'd assume that people would try to append a header field without checking the values that already exist. IMO, the rule should be that the dictionary element that appears later overwrites the one that precedes.
PTAL
NAME Thank you! cb76bf1 looks good to me. Is your intention to retain the forbidding of duplicate dictionary values, even when the dictionary members are split into different header fields? For example, in the hypothetical world where cache-control is sent using SH, all the cache-control directives in the following example would be considered invalid and ignored. I am not strongly opposed to that, though my weak preference goes to requiring decoders to use the dictionary member that appears later when there is a collision.
NAME the problem is that ignoring duplicates can cause security issues for some headers (the headers that WebAppSec in the W3C are particularly sensitive about this). The only way to address it would be to add a flag to the API to control what to do with dups -- but that adds complexity (more to specifications than to implementations, but still). I'm not crazy about that; what do others think?
Code change:
3.1.2. Parameters are an ordered map of key-values pairs that are associated <del> with an item (item) or inner-list (inner-list).  The keys are required to be unique within the scope of a map of parameters, and the values are bare items (i.e., they themselves cannot be parameterised; see item). </del> <ins> with an item (item) or inner-list (inner-list).  The keys are unique within the scope of a map of parameters, and the values are bare items (i.e., they themselves cannot be parameterised; see item). </ins> The ABNF for parameters in HTTP headers is:

Related discussion:
text: NAME Thank you for the explanation. But I wonder if it is actually the case that what those specifications forbid is having duplicate header fields, rather than forbidding duplicate dictionary members (or maybe both). By quickly searching on URL, I was able to find the prohibition on having duplicate header fields, but could not find a rule that forbids having duplicate policy tokens. Assuming that at least such specifications forbid having duplicate header fields, and based on the fact that SH draft does not forbid that (when a list or dictionary is used), I think there is no reason for the SH draft to forbid having duplicate dictionary members.
NAME NAME any comments re: the above? Specifically, if SH swallowed duplicate dictionary values rather than raising an error, would that be a concern from a security standpoint?
Given a header like , it seems like we have a few options: Fail parsing. Return . Return . Return . I think I can come up with arguments for any of these options, though I'd find 4 a bit surprising as a spec author, insofar as I'd have to deal with unexpected lists for all my dictionary values. of URL skips duplicate CSP directives. That is, it picks 2 out of the list above, choosing to retain only the first value for a given name. I do wonder whether that was the right decision, but it is consistent across browsers and provides developers with predictable behavior. We throw a warning into the console in Chrome for this case, and that's probably Good Enough.
This sounds like a bad API for working with structured header values. I'd hope that eventually we offer better APIs for operating on (what Fetch calls) header lists. I think historically there were some arguments for always using first or last based on likelihood of where header injection would happen. But I'm not sure how sound any of that rationale was. I don't think a client can reasonably protect against it. Therefore, what's most important is that the result is unambiguous and that it doesn't matter how you "spell" multiple values (commas or multiple fields or a combination) in the traditional header syntax.
Anyone have preferences between Mike's options 2 and 3?
NAME I think option 3 is preferable, because that would allow server administrators to override parameters by appending header fields.
Code change:
3.1.2. Parameters are an ordered map of key-values pairs that are associated <del> with an item (item) or inner-list (inner-list).  The keys are required to be unique within the scope of a map of parameters, and the values are bare items (i.e., they themselves cannot be parameterised; see item). </del> <ins> with an item (item) or inner-list (inner-list).  The keys are unique within the scope of a map of parameters, and the values are bare items (i.e., they themselves cannot be parameterised; see item). </ins> The ABNF for parameters in HTTP headers is:

Related discussion:
text: I agree that NAME that it's a hack, though sadly, I do not think we can get rid of such practice through API design on the server side. People are so used to dealing with each line of header fields than working through a API that deals with a set of header fields as a whole.
There are CDNs that offer JS or Wasm APIs effectively using et al. Once structured header values are more baked and have dedicated on-the-wire support I'd definitely like to add first-class support to objects.
I weakly prefer "first one wins" (2). It's only an aesthetic preference, however: I don't have any principled reason to pick 2 over 3 or vice-versa. I can live with either for the reasons NAME spells out.
If I had pick, I probably agree with NAME reasoning.
PTAL
Thank you for the changes. Looks good to me now. FWIW, I was bit surprised to learn that we do not mention how a duplicate is processed alongside the type definitions in . I checked and now I understand that the formal definition is provided in section 4.