jiebi/CodeConvo huggingface dataset:
Code change:
[3] #Content Filtering <del> [4] #Example B1: Illicit access to a video streaming service (User Transferred Pattern) </del> <ins> [4] #Example B1: Illicit access to a video streaming service (User- Transferred Session Data Pattern) </ins> [5] #Example B4: Illicit Transaction Authorization (Client Transferred Pattern) <del> [6] #Example B5: Illicit Network Join (Hybrid Pattern) </del> <ins> [6] #Example B5: Illicit Network Join (User-Transferred Authorization Data Pattern) </ins> <del> [7] #Example B7: Illicit session transfer (Hybrid Pattern) </del> <ins> [7] #Example B7: Illicit session transfer (User-Transferred Authorization Data Pattern) </ins> <del> [8] #Example A5: Add a device to a network (Hybrid) </del> <ins> [8] #Example A5: Add a device to a network (User-Transferred Authorization Data Pattern) </ins> <del> [9] #Example A7: Transfer a session (Hybrid) </del> <ins> [9] #Example A7: Transfer a session (User-Transferred Authorization Data Pattern) </ins>

Related discussion:
text: Changed name of "User transferred" attack to User Transferred Session Data Pattern - see Issue
Is this a duplicate with PR ?
Resolving issue
Resolving
Code change:
The Receipt structure is a CBOR array with two items, in order: <del> "service_id": The service identifier as tstr. </del> <ins> "protected": The protected header of the countersigner. </ins> "contents": The proof as a CBOR structure determined by the tree algorithm.

Related discussion:
text: Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.
Code change:
streams.  Most importantly, priority can be used to select streams for transmitting frames when there is limited capacity for sending. <del> Each stream is prioritized into a group.  Each group is identified using an identifier that is selected by the client.  Each group is </del> <ins> Stream can be prioritized by marking them as dependent on the completion of other streams (pri-depend).  Each dependency is </ins> assigned a relative weight, a number that is used to determine the relative proportion of available resources that are assigned to that <del> group. Within a priority group, streams can also be marked as being dependent on the completion of other streams. </del> <ins> dependency. </ins> Explicitly setting the priority for a stream is input to a prioritization process.  It does not guarantee any particular

Related discussion:
text: The priority groups are abandoned in favor of a single weighted dependency tree. The root node of the tree is the connection, assigned the stream identifier 0x0. By default, streams are assigned a stream dependency of 0x0 with a weight of 16.
Just read through it, I think it looks good. I'd like to understand how weight of the stream is calculated and changed. Here is my understanding: The effective weight of each stream is determined by traversing tree node, taking into account of distribution of weight of parent stream among siblings. This effective weight is temporal on the tree and initial weight is unchanged for a stream, so when reprioritizing that stream, its weight is initial one. For example, suppose we have the following dependency tree: X<--(w)--Y means that Y depends on X with weight w (and w is initial weight). Calculated effective weight is like this: If parent stream is closed, then its initial weight is distributed to among the child streams and this updates initial weight of child stream. So, after A was closed, the initial weight of streams becomes like this:
NAME thanks for this. I'll have to read through this more carefully before I comment. NAME that seems right. Note that this means that a server might want to maintain more precision on it's weight values than the 8 bits we mandate in the protocol. That said, if there are deep dependency trees and you are killing off nodes that are high up, at some point you will need to round off, so I think that how much precision is allocated is largely a discretionary thing.
Looks good. , Martin Thomson EMAIL:
It seems that we can make a stream to depend on stream 0x0 exclusively, which makes all existing connections its descendant. This is not possible in the current draft version. I wonder this can be directly proxy-able since stream 0x0 is imaginable stream.
Yea, the idea is that '0' is a reserved stream ID, and so it is safe to use it as a flag for saying that (effectively) any stream with '0' as a parent has no parent. , Tatsuhiro Tsujikawa wrote:
Well, then we should explicitly say that receiver must treat exclusive bit as 0 if stream ID field is 0.
Code change:
streams.  Most importantly, priority can be used to select streams for transmitting frames when there is limited capacity for sending. <del> Each stream is prioritized into a group.  Each group is identified using an identifier that is selected by the client.  Each group is </del> <ins> Stream can be prioritized by marking them as dependent on the completion of other streams (pri-depend).  Each dependency is </ins> assigned a relative weight, a number that is used to determine the relative proportion of available resources that are assigned to that <del> group. Within a priority group, streams can also be marked as being dependent on the completion of other streams. </del> <ins> dependency. </ins> Explicitly setting the priority for a stream is input to a prioritization process.  It does not guarantee any particular

Related discussion:
text: NAME I would add an explicit hint to implementers that having more than 8 bits of internal precision is a good thing. NAME I think we should leave open the possibility to insert a new stream between the connexion and all its children, even if it's probably a large re-prioritization.
I think large re-prioritization is not a problem. If proxy gets such requests and it aggregates several frontend connections to single backend connection, inserting under stream 0x0 with exclusive flag set seems to be impossible in backend.
If it aggregates to a different backend connection it is not impossible to proxy. Consider streams A and B depend on stream 0x0 and are proxied to some backend connection as streams X and Y. If we get a new streams, C, that exclusively depends on 0x0, we can proxy it as stream Z by dropping the exclusive dependency and then re-prioritizing streams X and Y to depend on stream Z.
Yes, it works like that. But if we just don't allow 0x0 with exclusive dependency, we can do all priority stuff via proxy without doing any extra handling except for stream ID mappings.
Yep, true -- I don't have much of a preference -- if clients feel like it is not an important use case than I am perfectly happy to disallow it.
Is it possible to move this discussion to the mailing list? If you need comments from a client, I'm happy to take a look later. On Tue Apr 15 2014 at 9:39:56 AM, Jeff Pinner EMAIL wrote:
Code change:
4. In case of using HTTP CONNECT to a TURN server the security <del> consideration of RFC7231 apply.  It states that there "are </del> <ins> considerations of RFC7231 apply.  It states that there "are </ins> significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic.  Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets." <del> The Tunnel-Protocol request header field described in this document is an optional header and HTTP Proxies may of course not support the header and therefore ignore it.  If the header is not present or ignored then the proxy has no explicit indication as to the purpose of the tunnel on which to provide consent, this is the generic case that exists without the Tunnel-Protocol header. </del> <ins> The `Tunnel-Protocol` request header field described in this document is an optional header.  Clients and HTTP Proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is indistinguishable from the case where either client or proxy does not support the `Tunnel-Protocol` header. </ins>

Related discussion:
text: This changes the grammar and text to permit multiple ALPN tokens in the header. This is necessary for HTTP tunnels ("http/1.1" and "h2") as well as some WebRTC cases. I made some editorial changes at the same time. I'll split those out if we don't accept this.
Code change:
state of the Append-only Log, encoded in an old Receipt, is consistent with the current Append-only Log state. <del> 5.2.3.3. </del> <ins> 5.2.4.3. </ins> Everyone with access to the Transparency Service can check the correctness of its contents.  In particular:

Related discussion:
text: Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.
Code change:
"confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", and "verify". <ins> The term "payload" is to be interpreted as described in Section 3.3 of RFC7231. </ins> Unless otherwise noted, all the protocol parameter names and values are case sensitive.

Related discussion:
text: align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.
Code change:
not, however, learn any claim values not disclosed in the Disclosures. <del> This document also describes an optional mechanism for Holder </del> <ins> This document also specifies an optional mechanism for Holder </ins> Binding, or the concept of binding an SD-JWT to key material controlled by the Holder.  The strength of the Holder Binding is conditional upon the trust in the protection of the private key of

Related discussion:
text: Discussions around defining SD-JWT-VC show that it would be very helpful for interoperability if HB JWT is normatively defined in SD-JWT specification itself. Using HB JWT is optional, but if used, it should be compliant to the definitions in SD-JWT. How to represent validity (iat, exp, nbf) will probably need the most discussion... also we should introduce an abbreviation .... cc NAME
need to re-generate example 4b, and 4a to update hb jwt header....
cc NAME please take a look (can't ask review from you...)
This change is sufficient to warrant an entry in the doc history like just, "Defined the structure of the Holder Binding JWT"
done, thank you, Brian
lgtm
Code change:
Location: R Required: Optional JSON Type: Boolean <del> A boolean that if true indicates that the publisher MAY issue </del> <ins> A Boolean that if true indicates that the publisher MAY issue </ins> incremental (delta) updates - see patch.  If false or absent, then <del> the publisher gaurantees that they will NOT issue any incremental </del> <ins> the publisher guarantees that they will NOT issue any incremental </ins> updates and that any future updates to the catalog will be independent.  The default value is false.  This field MUST be present if its value is true, but may be omitted if the value is false.

Related discussion:
text: Fixing table references and reformatting certain sections to 80 chars line width.
Table 2 is declared twice, as is Table 3.
Code change:
Given a string as input: If input is not a sequence of characters, or contains characters <del> outside the range allowed by VCHAR, fail serialisation. </del> <ins> outside the range allowed by VCHAR or SP, fail serialisation. </ins> Let output be an empty string.

Related discussion:
text: Step 4.4 equates "the range %x00-1f or %x7f" to "not in VCHAR", but VCHAR doesn't include %x20; this change adds "or SP" and imports SP from RFC5234.
Thanks!
Code change:
Add name this_key with value member to dictionary. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, return dictionary. Consume the first character of input_string; if it is not COMMA, fail parsing. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> If input_string is empty, there is a trailing comma; fail parsing.

Related discussion:
text: An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.
Code change:
The "error" parameter's value is an sf-token that is a Proxy Error Type.  When present, it indicates that the intermediary encountered <del> an issue when obtaining a response. </del> <ins> an issue when obtaining this response. </ins> The presence of some Proxy Error Types indicates that the response was generated by the intermediary itself, rather than being forwarded

Related discussion:
text: I noticed that parameters are generally defined in terms of what happened to generate this response, whether or not the next hop was actually contacted. The exception is , which says: I think it's potentially valuable for a response to indicate what protocol it was fetched over even if it comes from cache. The remedy would be to remove that statement and align this with the other parameters by talking about 'this response'. Probably also making that more prominent in . Thoughts, NAME
Thanks!
Code change:
A OBJECT message contains a range of contiguous bytes from from the specified track, as well as associated metadata required to deliver, <del> cache, and forward it. </del> <ins> cache, and forward it.  There are two subtypes of this message.  When the message type is 0x00, the optional Object Payload Length field is present.  When the message type ix 0x02, the field is not present. </ins> The format of the OBJECT message is as follows:

Related discussion:
text: and . There was consensus in Cambridge that removing the special meaning of zero length gets rid of difficult code, removes potental foot guns, saves a byte, and enables actual zero length payloads, which supposedly has use cases.
Since message (6. Messages) will be the main piece of info of MOQ I think we should try to minimize its size. Assuming most of the messages send to the wire will be objects inside a quic stream, the length should be NOT needed. Could we use 1 bit in "type" to indicate if length is present, we could save some bytes without overcomplicating the protocol
The length of a QUIC stream is only known after the FIN bit is received(ie the end of QUIC stream). Putting the length in the message header can ensure the size of stream is known at the beginning of the stream.
The size of an OBJECT is a varint so that's a single byte when 0. Even in the situation where you're sending an OBJECT per frame, that's what like 100 OBJECTs per second?. That's 100B/s while the media might average 375,000B/s (3Mb/s). But yeah, we can optimize when the draft is closer to completion and things are more concrete. I like how QUIC STREAM frames are encoded, where the frame type indicates if fields are present (ex. length).
This issue is related to the question of what types of lengths we'll support, and whether we'll support those that go to the end of a quic stream (aka infinite length). "unknown" payloads where they're a delimiter of some sort had no support, because you have to do extra parsing. This issue is about two types: Object and Object + Length, which has support from the WG. Martin to roll into PR
From Cambridge: Martin will put this in a separate PR once lands
Code change:
simplifies processing and avoids timezone management required by specifications such as RFC3339. <del> 2.3. </del> <ins> 2.5. </ins> The signature's Expiration Time (signature-metadata) is identified by <del> the "(expired)" identifier. </del> <ins> the "*expires" identifier. </ins> Its canonicalized value is a Decimal String containing the signature's Expiration Time expressed as the number of seconds since the Epoch, as defined in Section 4.16 [4] of POSIX.1. <del> 2.4. </del> <ins> 2.6. </ins> The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the <del> "(request-target)" identifier. </del> <ins> "*request-target" identifier. </ins> Its value is canonicalized as follows:

Related discussion:
text: Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)
Code change:
determined by looking at the message itself, after decoding or reconstituting parts that have been compressed or elided in transit, without requiring an understanding of the sender's current <del> application state (established via prior messages). </del> <ins> application state (established via prior messages).  However, a client MUST retain knowledge of the request when parsing, interpreting, or caching a corresponding response.  For example, responses to the method look just like the beginning of a response to , but cannot be parsed in the same manner. </ins> Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some

Related discussion:
text: … in that the request must be understood in order to parse and interpret the response.
Well, the simple version is a normative statement in sheep's clothing. Let's just make it normative.
Section 6 claims that . It uses the word "intended", which is an intention that is broadly achieved, with only one exception that I'm aware of at the syntactic level. Having recently implemented message/http, I discovered that some response messages cannot be processed without knowledge of the corresponding request. This is pretty annoying and might be worth noting as a possible exception here. As noted in the response to a HEAD request might include Content-Length, but the content of the response is always empty. At a semantic level, I don't think that any response can be considered without knowledge of the request, so I don't think that self-descriptiveness can possibly apply there. Besides, this section is clearly intended to provide an abstract definition of the syntax and not semantics.
See also
Code change:
host name if the target URI contains a fully qualified domain name. A proxy MUST NOT modify the "absolute-path" and "query" parts of the <del> received target URI when forwarding it to the next inbound server, except as noted above to replace an empty path with "/" or "*". </del> <ins> received target URI when forwarding it to the next inbound server except as required by that forwarding protocol.  For example, a proxy forwarding a request to an origin server via HTTP/1.1 will replace an empty path with "/" (origin-form) or "*" (asterisk-form), depending on the request method. </ins> A proxy MUST NOT transform the content (content) of a message that contains a no-transform cache-control response directive

Related discussion:
text: In semantics 7.7: I found where (in the discussion of normalization in §4.2.3) we say to replace the empty path with "/" for non-OPTIONS requests. I couldn't find anywhere "above" where it was noted to replace an empty path with "*" (presumably, for the OPTIONS requests), though.
This is a reference to text that was moved to HTTP/1.1 because it is version specific. I suggest we replace it with
LGTM
Code change:
non-selectively disclosable and hide only the other sub-claims: <del> There would be no Disclosure for </del> <ins> In this case there would be no Disclosure for </ins> <del> in this case. </del> <ins> since it is provided in the clear. </ins> 5.7.3.

Related discussion:
text: based roughly on feedback from Anders to draft-ietf-oauth-selective-disclosure-jwt at URL