jiebi/CodeConvo huggingface dataset:
Code change:
properties of that path can vary, with similar impacts on congestion control <del> 5.7. </del> <ins> 5.8. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A

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:
properties of that path can vary, with similar impacts on congestion control <del> 5.7. </del> <ins> 5.8. </ins> Multipath transport protocols permit more than one path to be differentiated and used by a single connection at the sender.  A

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:
publisher MUST NOT send objects from outside the requested start and end. <ins> TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.) </ins> 6.4.3. 6.5.

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:
In order to mitigate this fairness problem, a server could use knowledge about the intermediary as another signal in its prioritization decisions.  For instance, if a server knows the <del> intermediary is coalescing requests, then it could serve the responses in round-robin manner.  This can work if the constrained </del> <ins> intermediary is coalescing requests, then it could avoid serving the responses in their entirety and instead distribute bandwidth (for example, in a round-robin manner).  This can work if the constrained </ins> resource is network capacity between the intermediary and the user agent, as the intermediary buffers responses and forwards the chunks based on the prioritization scheme it implements.

Related discussion:
text: We accept that a strong suggestion to use round-robin isn't ideal. And look for other ways to phrase the suggestion of distributing or timeslicing. Fortunately we already had some text in the next paragraph that explained the ways that timing of delivery of incremental resources parts is important to clients and the sorts of things that servers need to consider. So this PR rearranges the text a bit and gives it dust off to make sure it is in line with our understanding now.
This recommendation is too strong. There is still value in allowing requests to complete. This suggests that pieces of all responses be provided concurrently. That leads to more context switching than necessary, or even inefficiencies in transmissions (one byte from each at a time would have excessive overheads). I would instead say:
I agree that "round-robin manner" is poorly defined and could be interpreted as 1 byte of everything. That would be bad. However, the full context of that SHOULD is in relation to the other requirements in that paragraph RECOMMENDing respect with no guidance on what that means seems a bit iffy to me. Your suggestion might get misinterpreted as relaxing the RECOMMEND. Rewriting that paragraph risks kicking the hornets nest of one the most divisive issues we had (URL). I sort of inclined to keep the SHOULD but expand on what we intended to say with "round-robin"
LGTM, some suggestions only.
Code change:
Integer. The "min-size" key specifies a minimum size for a resumable <del> upload, counted in bytes.  The server will not create an upload </del> <ins> upload, counted in bytes.  The server MAY NOT create an upload </ins> resource if the client indicates that the uploaded data is smaller <del> than the minimum size.  The value is an Integer. </del> <ins> than the minimum size by including the "Content-Length" and "Upload-Complete: ?1" fields, but the server MAY still accept the uploaded data.  The value is an Integer. </ins> The "max-append-size" key specifies a maximum size counted in bytes for the request content in a single upload append request

Related discussion:
text: This PR clarifies a few things around the Upload-Limit field from : The last upload append request may now be smaller than the minimum append size specified in . For example, if a 510 MB upload is split into 100 MB requests, the last request can just be 10 MB. It clarified how a client can indicate the entire upload length when creating a new upload via the Content-Length header. The PR also mentions that no resumable upload resource may be created if the minimum size is not met, but the server might still accept and process the data (although without offering resumability) The Upload-Limit header is added to informational response in an example
Code change:
Integer. The "min-size" key specifies a minimum size for a resumable <del> upload, counted in bytes.  The server will not create an upload </del> <ins> upload, counted in bytes.  The server MAY NOT create an upload </ins> resource if the client indicates that the uploaded data is smaller <del> than the minimum size.  The value is an Integer. </del> <ins> than the minimum size by including the "Content-Length" and "Upload-Complete: ?1" fields, but the server MAY still accept the uploaded data.  The value is an Integer. </ins> The "max-append-size" key specifies a maximum size counted in bytes for the request content in a single upload append request

Related discussion:
text: The definition of upload creation requests allows the client to include the entire file, some file data or no data at all. While we provide this flexibility, we don't give guidance on when which approach is best suited. This PR adds this missing piece and explains how an optimistic client can attempt to upload the file in one request and how a careful client uses a separate request for creating the upload. In addition, it also mentions how to transparently upgrade to resumable uploads, which wasn't explained in detail before. Let me know if you have any feedback on this.
Are "Optimistic Upload Creation" and "Upgrading To Resumable Uploads" the exact same way? Maybe the 3rd way could be checking first before uploading?
The way they are described right now they are similar, yes. In theory, an optimistic upload creation can also be used where the client doesn't upload the entire file, but just a large part of it (think 500 MB of a 10 GB file). When upgrading a non-resumable request to a resumable upload, this act of division is not allowed. But I am not sure if we should go into that much detail here. If not, then we can merge these two sections. Upload limits are a good point! With the careful upload, the client also knows the limits before sending the first PATCH request. The optimistic client must be prepared to receive a 104 response with limits that it has to adapt to. We can mention that a careful client may also send an OPTIONS request before hand if it deems that necessary.
I think upload-limit can just be enforced on the server side. If it sends a 104 and a 5xx response, the client would automatically retry. We have deployed a client-side implementation that is not aware of the upload-limit header field.
Thanks for all of your comments! I updated the PR to put the section about upgrading to resumable uploads under the optimistic upload creation since they are similar. I also added a brief mention of Upload-Limit and shortened the text a bit. Let me know if you think the text needs more adjustments.
Just a minor nit. Otherwise I think this is a very good addition and agree with NAME that we should add some text with regards to the .
Code change:
Integer. The "min-size" key specifies a minimum size for a resumable <del> upload, counted in bytes.  The server will not create an upload </del> <ins> upload, counted in bytes.  The server MAY NOT create an upload </ins> resource if the client indicates that the uploaded data is smaller <del> than the minimum size.  The value is an Integer. </del> <ins> than the minimum size by including the "Content-Length" and "Upload-Complete: ?1" fields, but the server MAY still accept the uploaded data.  The value is an Integer. </ins> The "max-append-size" key specifies a maximum size counted in bytes for the request content in a single upload append request

Related discussion:
text: Proposal for optimistic: The client needs to adapt to the header provided in the intermediate response and fail the request if the file is larger than the maximum allowed size. Proposal for Careful: The client can use the header provided in the to verify that the file is allowed to be uploaded before sending any data.Some editorial suggestions, but one big question: What is the material difference between the first and third strategy? Could these be the same strategy?
Code change:
6.5.1. <del> Trailer sections are only possible when supported by the version of </del> <ins> A trailer section is only possible when supported by the version of </ins> HTTP in use and enabled by an explicit framing mechanism.  For example, the chunked coding in HTTP/1.1 allows a trailer section to be sent after the content (chunked.trailer.section).

Related discussion:
text: I think it would be better to separate this into the purely editorial changes (all except TRACE), and then give the change to TRACE the full treatment separately (it's a normative change after all). Will work on the former first.
Sorry for this being a question. I answered the same question for -caching by searching through and realizing that while caching might be a version-independent extension, a practical consequence of the structure of documents is that it is inextricably linked to -semantics. That's cool. Having the definition of HTTP/N rely on -caching is eminently sensible. There is a normative reference to -messaging though. Why would HTTP/3 care about that? If this were software, I'd be horrified by pulling in a dependency like that. Most of the references to -messaging are strictly examples. I could only see two cases where there was a potentially normative dependency: recommends "message/http" and . These seem like they could be broken (the second easier than the first, certainly) and the reference made normative.
I agree that this would be good.
A SHOULD-level requirement to use message/http. Moving the media type definition over is not going to help, because it essentially defines the HTTP/1.1 wire format as media type. It seems the only way to fix this would be to relax the SHOULD. That one could probably be replaced with a reference to the transfer coding registry (which is what counts here), and the pointer to the spec text would then become informative.
History in and linked issues.
Concrete recommendation for 1: a server (intermediary) responding to TRACE MUST generate a representation of the request that it received in any format. The message/http is one possible way to represent a request message, so that can be an informative reference instead.
Code change:
6.5.1. <del> Trailer sections are only possible when supported by the version of </del> <ins> A trailer section is only possible when supported by the version of </ins> HTTP in use and enabled by an explicit framing mechanism.  For example, the chunked coding in HTTP/1.1 allows a trailer section to be sent after the content (chunked.trailer.section).

Related discussion:
text: Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.
Code change:
received all objects in a subgroup from the start of the subscription.  If a relay, it can forward stream FINs to its own subscribers once those objects have been sent.  A relay MAY treat <del> receipt of EndOfGroup, EndOfSubgroup, GroupDoesNotExist, or EndOfTrack objects as a signal to close corresponding streams even if the FIN has not arrived, as further objects on the stream would be a protocol violation. </del> <ins> receipt of EndOfGroup, GroupDoesNotExist, or EndOfTrack objects as a signal to close corresponding streams even if the FIN has not arrived, as further objects on the stream would be a protocol violation. </ins> Similarly, an EndOfGroup message indicates the maximum Object ID in the Group, so if all Objects in the Group have been received, a FIN

Related discussion:
text: We don't discuss how to use it anyway. This was suggested in
Done
There are references to EndOfSubgroup in the FIN PR, so one of the two PRs is going to have to delete them.
Code change:
COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- tree-proofs. <del> This section describes at a high level, the three main roles and associated processes in SCITT: </del> <ins> fig-concept-relationship illustrates the three main roles and associated processes that comprise a Transparency Service, independent of any one use case. </ins> <del> Issuers and Signed Statements </del> <ins> Issuers that use their credentials to create Signed Statements about Artifacts.  Issuer Credentials are also used to verify the Signed Statements within the Transparency Service registration process, and Transparent Statements. </ins> <del> Transparency Service and the registration process </del> <ins> Transparency Services that evaluate Signed Statements against Registration Policies, using credentials to sign Receipts upon successful Registration. </ins> <del> Relying Parties of the Transparent Statements and the Receipt validation process </del> <ins> Relying Parties that: collect Receipts, combining them with the Signed Statements to create a Transparent Statement; retrieve Transparent Statements for analysis of Statements about Artifacts; uses credentials to authenticate the Signed Statement and the Receipts of the Transparent Statement (e.g. verification); replay segments of Transparent Statements checking for the consistency of the Transparency Service's Append-only Log (e.g. auditing) In addition, fig-concept-relationship illustrates multiple Transparency Services and multiple Receipts as a single Signed Statement MAY be registered with one or more Transparency Service. Each Transparency Service produces a Receipt, which may be aggregated in a single Transparent Statement, demonstrating the Signed Statement was registered by multiple Transparency Services. The arrows indicate the flow of information. </ins> The subsequent sections describe the main concepts, namely Transparency Service, Signed Statements, Registration, and

Related discussion:
text: Note: This PR assumes is merged, and may need to be updated to fit within the context of 's final text.
Figure 1 needs to be explained and referenced in the text. The arrows in the figure need to be explained The figure shows two different boxes and the semantic needs to be explained
Code change:
behaviours, and the Augmented Backus-Naur Form (ABNF) notation of RFC5234 to illustrate expected syntax in HTTP header fields.  In doing so, uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from <del> RFC5234.  It also includes the OWS and tchar rules from RFC7230. </del> <ins> RFC5234.  It also includes the tchar rule from RFC7230. </ins> When parsing from HTTP header fields, implementations MUST follow the algorithms, but MAY vary in implementation so as the behaviours are

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:
is proffered by the alternative service, is not necessarily checked for validity, expiration, issuance by a trusted certificate authority or matched against the name in the URI.  Therefore, the alternative <del> service MAY provide any certificate, or even select TLS cipher suites </del> <ins> service can provide any certificate, or even select TLS cipher suites </ins> that do not include authentication. A client MAY perform additional checks on the offered certificate if

Related discussion:
text: for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.
Code change:
Attackers exploit cross-device flows by initiating an authorization flow on the Initiating Device and then use social engineering techniques to change the context in which the request is presented to <del> the user in order to trick them into granting authorization on the </del> <ins> the user in order to convince them to grant authorization on the </ins> Authorization Device.  The attacker is able to change the context of the authorization request because the channel between the Initiating Device and the Authorizing Device is unauthenticated.  These attacks <del> are also known as illicit consent grant attacks. </del> <ins> are also known as Cross-Device Consent Phishing (CDCP) attacks. </ins> 3.1.

Related discussion:
text: Introduce the Cross-Device Consent Grant label (see )
e.g. Malicious Context Change Authorization Request or something like that.
Ideas from Pieter's slides: Illicit Consent Grant Attack? Describes outcome, not the mechanism Attacker-in-the-Middle Attack? Describe attacker capability, but both too broad and too narrow Authorization Context Manipulation Attack? Describes the mechanism Authorization Context Manipulation Exploit Describe mechanism, hints that protocol functions as expected. What about "Phishing for Consent"? Describes the mechanim which depends to some extend on social engineering (phishing) Describes the outcome (consent) Other names shared via e-mail by George Fletcher: Zishing Azishing "Cross-Device Authorization Exploit" "Social Engineering Token Theft" "Authorization Flow Manipulation Exploit" FlowJack AuthJack TokenJack Context Manipulation Authorization Exploit Permitphishing, Authishing
"Cross-Device Consent Phishing"?
Some references on Consent Phishing: URL URL URL
CDCP - Cross Device Consent Phishing - the abbreviation works well.
Two editorial nits, the rest looks good to me! Thank you!
Code change:
Track Namespace: Identifies a track's namespace as defined in (track-name). <ins> Error Code: Identifies an integer error code for canceling the announcement. Reason Phrase: Provides the reason for announcement cancelation. </ins> 6.10. A potential subscriber sends a 'TRACK_STATUS_REQUEST' message on the

Related discussion:
text: It's meant to be sent by the subscriber, indicating that the announce is no longer accepted. The fields should mirror ANNOUNCE_ERROR so the subscriber can indicate stuff like authentication expired, another announce was received, etc.
LG, but I noticed: "If a publisher receives new subscriptions for that namespace after receiving an ANNOUNCECANCEL, it SHOULD close the session as a 'Protocol Violation'." I believe that's racy, because the SUBSCRIBE and ANNOUNCECANCEL can be inflight at the same time? Also, shouldn't it be "after sending an ANNOUNCE_CANCEL", or am I misunderstanding the text?lgtm