jiebi/CodeConvo huggingface dataset:
Code change:
any Signed Statements, a means is required to configure the first Registration Policy that is not the standard issuance of a Signed Statement.  Transparency Services MUST support at least one of these <del> methods: * A built-in default Registration Policy * Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks * An out-of-band authenticated management interface </del> <ins> methods: A built-in default Registration Policy Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks An out-of-band authenticated management interface </ins> 4.1.3.

Related discussion:
text: While working on a unrelated PR, I noticed that lists that do not have a newline between the list and previous paragraph. The end result is in local testing, and presuming upcoming publication to URL, the lists will not render correctly. I added newlines and also change the equivalent Markdown syntax to match preexisting lists from other sections in the draft that have been around longer. Before: ! After: !
LGTM Thanks, NAME
Code change:
To that end, limited-use fields (such as a header confined to a single application or use case) are encouraged to use a name that <del> includes its name (or an abbreviation) as a prefix; for example, if </del> <ins> includes that use (or an abbreviation) as a prefix; for example, if </ins> the Foo Application needs a Description field, it might use "Foo- Desc"; "Description" is too generic, and "Foo-Description" is needlessly long.

Related discussion:
text: Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...
Code change:
Append the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string to members. <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 members. 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:
Objects are assigned an intended delivery order that should be obeyed during congestion (delivery-order) <del> Objects can be dependent on other objects, in which case reordering is required (dependencies). </del> The decoder receives each objects and skips any objects that do not arrive in time (decoder).

Related discussion:
text: It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.
Code change:
"lst": REQUIRED.  JSON String that contains the status values for all the Referenced Tokens it conveys statuses for.  The <del> value MUST be the base64url-encoded (as defined in Section 2 of RFC7515) Status List as specified in status-list. </del> <ins> value MUST be the base64url-encoded Status List as specified in status-list. </ins> "aggregation_uri": OPTIONAL.  JSON String that contains a URI to retrieve the Status List Aggregation for this type of

Related discussion:
text: Redered version: URL
the text is existing in JWT encoding, does it make sense to emphasize this change from standard base64url encoding again in our spec?
I like the solution in sd-jwt - they introduced it as terminology: Should we move that to terminology and reference via base64url in the text?
Code change:
The decoder will receive multiple objects in parallel and out of order. <del> Objects arrive in delivery order, but media usually needs to be processed in decode order.  The decoder SHOULD use a buffer to reassmble objects into decode order and it SHOULD skip objects after a configurable duration.  The amount of time the decoder is willing to wait for an object (buffer duration) is what ultimately determines </del> <ins> Objects arrive in send order, but media usually needs to be processed in decode order.  The decoder SHOULD use a buffer to reassmble objects into decode order and it SHOULD skip objects after a configurable duration.  The amount of time the decoder is willing to wait for an object (buffer duration) is what ultimately determines </ins> the end-to-end latency. Objects MUST synchronize frames within and between tracks using

Related discussion:
text: Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.
Code change:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). <del> 5.6.1. </del> <ins> 5.7.1. </ins> An IETF transport is not tied to a specific Internet path.  The set of routers forming a path can and do change with time, this will also

Related discussion:
text: Created a separate issue to discuss ECN.
The guideline section discusses "Investigating a Range of Environments", with a focus especially on "Random Early Detection (RED) ] and Drop-Tail." The IETF and the IRTF have produced several different proposals for Active Queue management, with somewhat different characteristics. Interestingly, there is a tension there between developing Queue Management that "plays well" with existing congestion control algorithms, and developing congestion control algorithms that "take advantage" of AQM. Not sure what to say there, but at a minimum we should develop expectations about "signals" produced by AQM (e.g., the ECN markings of L4S) and reaction by congestion control algorithms. To go further, the could be a discussion of "honest signals", such as delays, that are very hard to "fake" in routing nodes, other signals such as ECN marks that could be produced by the network at very little cost, and packet losses that fall kind of in between. But we are not writing for the IRTF, so this could be kept brief.
On the topic of AQM, IETF published Characterization Guidelines (RFC7928) and Recommendations (RFC7567) that could be exploited for further discussions in this work.
Martin and Gorry: add a reference to 7567 to AQM behavior and evaluation criteria, which is not in scope for this document talk about evaluating CC interaction with AQM
Something like "CCs should be evaluated against AQMs that are prevalent in the internet" -- is there a reference that provides a taxonomy?
Editors: FQ-CoDel, PIE, L4S (RFC9332) have RFCs Are the others that should be evaluated, and do they have available specs?
Discussed at IETF 118: Many operators are not particularly aware of AQM or these concepts in general Include FIFO in the list Also do at least an AQM "you should evaluate the scenario with FIFO queues and should also consider the impact of various common AQMs and run detailed simulations against them", while maybe name-checking a few particularly relevant ones. Yes, should have criteria for this, and also should not ask people to run NxN interop matrix. Out of scope to mandate AQM
I suggest: Probably ought to include a suitably configured RED also.
Code change:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). <del> 5.6.1. </del> <ins> 5.7.1. </ins> An IETF transport is not tied to a specific Internet path.  The set of routers forming a path can and do change with time, this will also

Related discussion:
text: ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.
Code change:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). <del> 5.6.1. </del> <ins> 5.7.1. </ins> An IETF transport is not tied to a specific Internet path.  The set of routers forming a path can and do change with time, this will also

Related discussion:
text: Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.
Code change:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). <del> 5.6.1. </del> <ins> 5.7.1. </ins> An IETF transport is not tied to a specific Internet path.  The set of routers forming a path can and do change with time, this will also

Related discussion:
text: and .
Also
The text currently reads: "The community should also consider other non-standard congestion controls known to be widely deployed," This is a compromise to land a mostly unrelated PR. NAME doesn't think it's fair to expect participants to test algorithms that aren't fully specified. I would argue that if such specifications exist and the algorithm is systemically important, it absolutely should be modeled. Moreover, if the algorithm is rather loosely described, in many cases there is open source code (often in a Linux fork!) that can be tested on a host, or in simulation frameworks like ns3. If an algorithm is a true black box, with no description besides marketing material, and no open-source code, I agree there is not much to be done. I also believe that while algorithms like this exist, they are not systemically important to the internet.
gorry: ns3 code is not super high fidelity.
Discussed at IETF 118: There's a danger if you see a realtime flow that goes faster than a best effort flow, since realtime is usually constrained by other factors (potentially needing time to move forwards to generate more data) Seems hard to imagine that something not specified is able to place a burden on anybody else. If you want others to do a thing, write it down and document it. Of course, there is no protocol police: we cannot prevent people from deploying whatever they want. Can we provide a carrot for people to play by the rules: Could be a SHOULD consider requirements and how to interact We have: Guidance for people who are writing specs that aren't yet part of the community How do we evaluate those protocols How do we ensure that fairness can exist with these Need to have a commitment from this WG to help and not just throw up new requirements for data and for those bringing new CCs to engage positively. Perhaps spelling this out clearly NAME to file issue to write something encouraging for people early on in the document Christian notes that separate queues between realtime and best effort are not actually a strong requirement To measure capacity you do need some sort of queue, or else you cannot measure
This info RFC has some sensible guidelines on RTP feedback frequency, if we need this: "Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences".
Related to
Condition (1) is concerned with the behavior with respect to Reno and, thanks to our edits, Cubic.
Code change:
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start). <del> 5.6.1. </del> <ins> 5.7.1. </ins> An IETF transport is not tied to a specific Internet path.  The set of routers forming a path can and do change with time, this will also

Related discussion:
text: But there are of course other congestion controls out there, both standard and non-standard, in support of real-time and other non-greedy applications. Should we mention those as a class? Namecheck some examples?
editors meeting 8836 requirements document 8867 and 8868 are test cases, but informational. Reese: standard stuff is not widely deployed, widely deployed stuff is not standardized. But RMCAT is new. Maybe there aren't well-documented protocols to evaluate vs., so it's hard to require anything here. I'll take a look, will probably have to go to the community.
Editors: We need to consider the interaction between real time and not-real time is evaluating real-time in scope? See 8836, 8867, 8868.
Looks good enough.Thanks for the changes.
Code change:
Track Name: Identifies the track name as defined in (track-name). <del> StartGroup: The Location of the requested group.  StartGroup's Mode MUST NOT be None. </del> <ins> StartGroup: The start Group ID, plus 1.  A value of 0 means the latest group. </ins> <del> StartObject: The Location of the requested object.  StartObject's Mode MUST NOT be None. </del> <ins> StartObject: The start Object ID, plus 1.  A value of 0 means the latest object.  This field is not present when Start Group is 0. </ins> <del> EndGroup: The last Group requested in the subscription, inclusive. EndGroup's Mode is None for an open-ended subscription. </del> <ins> EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended and continues to the end of the track. </ins> <del> EndObject: The last Object requested in the subscription, exclusive.  EndObject's Mode MUST be None if EndGroup's Mode is None.  EndObject's Mode MUST NOT be None if EndGroup's Mode is not None. </del> <ins> EndObject: The end Object ID, plus 1.  A value of 0 means the entire group is requested.  This field is not present when End Group is 0. </ins> Track Request Parameters: The parameters are defined in <del> On successful subscription, the publisher SHOULD start delivering objects from the group ID and object ID described above. </del> <ins> On successful subscription, the publisher MUST reply with a SUBSCRIBE_OK, allowing the subscriber to determine the start group/ object when not explicitly specified and the publisher SHOULD start delivering objects. </ins> If a publisher cannot satisfy the requested start or end for the subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'.

Related discussion:
text: If I wanted to receive all objects in group N, I would issue: However the draft sneaks this restriction in, and it would actually be a protocol violation: It wasn't clear to me until chatting with Alan how you're supposed to do it: It's clarified in example 5, but I don't think this is obvious and it feels like an off-by-one. For example, if N was the last group in the broadcast, I can imagine some implementations incorrectly throwing an error or somehow mishandling it.
Individual Comment: This was discussed on the PR here: URL Given how subscribe locations work (end is exclusive), end=N+1/0 means "including through the end of group N". The question is whether we should have more than one way to do things, and defaults when values are not present.
Sorry, bad choice of word there. I meant that it's not immediately obvious why the restriction exists, and what it impacts.
Individual Review: I like removing relative options from subscribe. I don't love the group ID + 1 spelling, but I guess I can live with it. An alternative is to add 4 code points for SUBSCRIBE to indicate the presence/absence of start/end (SUBSCRIBE, SUBSCRIBEFROM, SUBSCRIBETO, SUBSCRIBE_RANGE).
Code change:
specification leaves the implementation of the Registration Policy to the provider of the Transparency Services and its users. <ins> A provider of a Transparency Service indicates what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy by issuing and registering configuration statements. </ins> As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As defined in RFC6024, "A trust anchor represents an authoritative

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:
not present or malformed in the message, the implementation MUST produce an error. <ins> If Covered Content contains an identifier for a Dictionary member that references a header field that is not present, is malformed in the message, or is not a Dictionary Structured Field, the implementation MUST produce an error.  If the header field value does not contain the specified member, the implementation MUST produce an error. If Covered Content contains an identifier for a List Prefix that references a header field that is not present, is malformed in the message, or is not a List Structured Field, the implementation MUST produce an error.  If the header field value contains fewer than the specified number of members, the implementation MUST produce an error. </ins> For the non-normative example Signature metadata in example-metadata, the corresponding Signature Input is:

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:
2.6. Authorization servers MAY transcribe claims when either producing <del> authorization grant at the token exchange flow or access tokens at </del> <ins> authorization grants in the token exchange flow or access tokens in </ins> the assertion flow. : Subject identifier can differ between the parties involved.  For instance: A user is known at domain A by "johndoe@a.org" but in <del> domain B by "doe.john".  The mapping from one identifier to the other MAY either happen in the token exchange step and updated identifer is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </del> <ins> domain B by "doe.john@b.org".  The mapping from one identifier to the other MAY either happen in the token exchange step and the updated identifer is reflected in returned authorization grant or in the assertion step where the updated identifier would be reflected in the access token.  To support this both authorization servers MAY add, change or remove claims as described above. </ins>

Related discussion:
text: Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL
Code change:
The Txn-Token SHOULD contain an "rctx" claim.  This MAY include the IP address information of the originating user, as well as information about the computational entity that requested the Txn- <del> Token. </del> <ins> Token and contextual attributes of the originating request itself. </ins> The JSON value of the "rctx" claim MAY include any values the Txn- Token Service determines are interesting to downstream services that

Related discussion:
text: I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?