jiebi/CodeConvo huggingface dataset:
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: Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?
Code change:
) response. <ins> If an HTTP/1.1 client receives data on a connection that doesn't have any outstanding requests, it MUST NOT consider them to be a response to a not-yet-issued request; it SHOULD close the connection, since message delimitation is now ambiguous, unless the data consists only of one or more CRLF (which can be discarded, as per message.parsing). </ins> 9.4. HTTP/1.1 defaults to the use of "

Related discussion:
text: I also suggest closing here : the main reason for getting data without a request is an error reported by the server before closing (e.g. 408). Another reason may be a server implementation issue (extra CRLF, inconsistent multiple content-length, inconsistent content-length+transfer-encoding, user-fed incorrect error message). In all these cases the message delimitation is wrong and unrecoverable. Thus the client trying to "fix" it will in the best case be useless (close following), and in the worst case have nasty side effects. In haproxy the only case we try to address is the extra CRLF that a few old servers send slightly after data. If extra bytes are sent immediately after data, we close. If the extra CRLF happens slightly later, we find it while parsing the next response and the CRLF is silently skipped.
Everyone OK with this now?
Well, like Roy, I'd even prefer a MUST close, but I can live with a SHOULD.
It doesn't seem to account for the extra CRLF case. Maybe just add "... unless the data is limited to CRLF"?
CR and CRLF?
I was thinking the same but hesitating. BTW NAME it would be LF and CRLF. But quite frankly we could stick to CRLF only since it's the only known bogus pattern widely deployed in field.
updated.
Code change:
2.4.4. All of section 2.2 of RFC8693 applies.  In addition, the following <del> applies to specification that conform to this specification. </del> <ins> applies to implementations that conform to this specification. </ins> <del> Returned authorization grant MUST be audienced to the requested </del> <ins> Returned authorization grants MUST be audienced to the requested </ins> authorization server.  This corresponds with RFC 7523 Section 3, Point 3 [1] and is there to reduce missuse and to prevent clients <del> from presenting their access tokens as an authorization grant to an authorization server in a different domain. </del> <ins> from presenting access tokens as an authorization grant to an authorization server in a different domain. </ins> The returned authorization grant MAY be audienced to multiple authorization servers, provided that trust relationships exist with them (e.g. through federation).  It is RECOMMENDED that only one audience is used to prevent an authorization server in one <del> domain from presenting the client's authorization grant to another authorization in another trust domain.  For example, this will prevent the authorization server in Domain B from presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. </del> <ins> domain from presenting the client's authorization grant to an authorization server in a different trust domain.  For example, this will prevent the authorization server in Domain B from presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. </ins> 2.4.5.

Related discussion:
text: Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL
Code change:
An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes in HTTP. <del> Conformance includes both the syntax and semantics of protocol elements.  A sender MUST NOT generate protocol elements that convey a meaning that is known by that sender to be false.  A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules.  Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message). </del> <ins> A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules.  Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message). Conformance to HTTP includes both conformance to the particular messaging syntax of the protocol version in use and conformance to the semantics of protocol elements sent.  For example, a client that claims conformance to HTTP/1.1 but fails to recognize the features required of HTTP/1.1 recipients will fail to interoperate with servers that adjust their responses in accordance with those claims. Features that reflect user choices, such as content negotiation and user-selected extensions, can impact application behavior beyond the protocol stream; sending protocol elements that inaccurately reflect a user's choices will confuse the user and inhibit choice. When an implementation fails semantic conformance, recipients of that implementation's messages will eventually develop workarounds to adjust their behavior accordingly.  A recipient MAY employ such workarounds while remaining conformant to this protocol if the workarounds are limited to the implementations at fault.  For example, servers often scan portions of the User-Agent field value, and user agents often scan the Server field value, to adjust their own behavior with respect to known bugs or poorly chosen defaults. </ins> 2.3.

Related discussion:
text: You can point very clearly at the DNT problems, but it's very subtle. And it doesn't detract from the general utility of the text.
Code change:
The document defines the following terms: <del> Digital Map is a data model that provides a view of the operator's </del> <ins> SIMAP is a data model that provides a view of the operator's </ins> networks and services, including how it is connected to other models/data (e.g. inventory, observability sources, and operational knowledge).  It specifically provides an approach to model multi-layered topology and appropriate mechanism to navigate <del> amongs layers and correlate between them.  This model is </del> <ins> amongs layers and correlate between them.  This includes layers from physical topology to service topology.  This model is </ins> applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). The set of principles, guidelines, and conventions to model the <del> Digital Map using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other entities. </del> <ins> Service & Infrastructure Maps (SIMAP) using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other entities. </ins> Defines the core topological entities, their role in the network, core topological properties and relationships both inside each

Related discussion:
text: Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters
Code change:
of the credentials and after completing the onboarding process, their account is activated. <ins> 2.7. An employee is signed into an application on their personal computer and wants to bootstrap the mobile application on their mobile phone. The employee initiates the cross-device flow and is shown a QR code in their application.  The employee launches the mobile application on their phone and scans the QR code which results in the user being signed into the application on the mobile phone. </ins> 3. The benefits of cross-device flows is compelling and is seeing

Related discussion:
text: Added examples to illustrate cases when the authenticated flow is not an effective as a mitigation.
Code change:
6.1. <ins> For all known architectures, all precautions MUST be taken to prevent XSS attacks.  In general, cross-site scripting (XSS) attacks are a huge risk, and can lead to full compromise of the application. 6.2. </ins> For simple system architectures, such as when the JavaScript application is served from a domain that can share cookies with the domain of the API (resource server) and the authorization server,

Related discussion:
text: I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.
Code change:
next hop that the connection is NOT coalesced (see https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99). <del> 7.1.1. </del> <ins> 8.1. </ins> When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend

Related discussion:
text: and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.
Code change:
6.5. <del> Fields (fields) that are sent/received after the header section has ended (usually after the content begins to stream) are referred to as "trailer fields" (or just "trailers", colloquially) and located within a </del> <ins> Fields (fields) that are located within a </ins> <del> .  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post-processing status information. </del> <ins> are are referred to as "trailer fields" (or just "trailers", colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information. </ins> Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics

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. <del> Fields (fields) that are sent/received after the header section has ended (usually after the content begins to stream) are referred to as "trailer fields" (or just "trailers", colloquially) and located within a </del> <ins> Fields (fields) that are located within a </ins> <del> .  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post-processing status information. </del> <ins> are are referred to as "trailer fields" (or just "trailers", colloquially).  Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post- processing status information. </ins> Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics

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:
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2. <del> If a server which advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details response RFC7807. </del> <ins> If a server advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details response RFC7807. </ins> 4.

Related discussion:
text: Remove "which" from a clause where it did not belong, as per feedback from Vijay Gurbani
Code change:
4. <del> TODO Security </del> <ins> 4.1. TODO elaborate on risks of incorrect parsing/decoding leading to erroneuos status data 4.2. TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data 4.3. TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section 4.4. TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture </ins> 5. <del> TODO elaborate on heard privacy </del> <ins> 5.1. TODO elaborate on herd privacy, size of the status list 5.2. TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list 5.3. TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO elaborate on issuers avoiding sequential usage of indices and status lists 5.4. TODO elaborate on issuers generating unique status lists per JWT token that do not offer herd privacy 5.5. TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities </ins> 6.

Related discussion:
text: gathering some ideas on privacy and security considerations
Looking good NAME you should be able to run 'make fix-lint' locally to fix the whitespace issues
Need to remove the trailing whitespaces for the markdown tooling to be happy
Code change:
3. <del> For the sake of completeness this is a description of the known use- cases that have been described which would have applicability to the real-time serving of media over QUIC, and MoQ participants should consider which use case(s) should be part of any work, and which can be excluded.  Previously I-D.draft-rtpfolks-quic-rtp-over-quic defined several key use cases, in addition to several others which may be summarised under the following: Peer-to-peer interactive applications, such as telephony or video conferencing.  This may be in a 1-to-1 scenario, or in a multi- party arrangement.  TODO: add more description here. </del> <ins> Previously I-D.draft-rtpfolks-quic-rtp-over-quic defined several key use cases, in addition to several others defined elsewhere.  The two use cases that are most applicable today given the existing and known future capabilities of QUIC include: </ins> Unidirectional live stream contribution.  Two immediate scenarios that best describe this is firstly users on a streaming platform in a remote scenario from their phone live streaming an event or

Related discussion:
text: This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)
Code change:
Similar to the last criteria, proposed alternate congestion controllers should be assessed in a range of environments.  For instance, proposals should be investigated across a range of <del> bandwidths, round-trip times, levels of traffic on the reverse </del> <ins> capacities, round-trip times, levels of traffic on the reverse </ins> path, and levels of statistical multiplexing at the congested link.  Similarly, proposals should be investigated for robust performance with different queueing mechanisms in the routers,

Related discussion:
text: at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.
Code change:
Similar to the last criteria, proposed alternate congestion controllers should be assessed in a range of environments.  For instance, proposals should be investigated across a range of <del> bandwidths, round-trip times, levels of traffic on the reverse </del> <ins> capacities, round-trip times, levels of traffic on the reverse </ins> path, and levels of statistical multiplexing at the congested link.  Similarly, proposals should be investigated for robust performance with different queueing mechanisms in the routers,

Related discussion:
text: The guidelines section as discussion of "Difficult Environments", starting with "The proposed algorithms should be assessed in difficult environments such as paths containing wireless links." Opinion may vary, but wireless links are probably now part of something between "a vast majority" and "a plurality" of the paths on the Internet.
I agree. Wireless serves the vast majority and are still increasing.
Gorry and Martin: wireless constraints deserve their own section. Three different phenomena to discuss Non-congestion loss Variable bandwidth on the path Jitter due to media access and link-layer retransmission
I changed based on the thread with Christian, and agreed to these insights. I think this ready.
Code change:
able to cleanly switch between time-aligned media tracks at group boundaries. <del> 3.3. </del> <ins> 3.4. </ins> The catalog and media object payloads MAY be encrypted.  Common Encryption CENC with 'cbcs' mode (AES CBC with pattern encryption) is <del> the RECOMMENDED encryption method. </del> <ins> the RECOMMENDED encryption method for CMAF packaged content. </ins> ToDo - details of how keys are exchanged and license servers signaled.  May be best to extend catalog spec to allow the specification of content protection schema, along with any pssh or protection initialization data. <ins> ToDo - content protection for LOC-packaged content. </ins> 4. WARP uses the Common Catalog Format {[COMMON-CATALOG-FORMAT}} to

Related discussion:
text: The current version of WARP only references CMAF packaging and does not make it clear that WARP is also intended to support LOC (Low Overhaded Container) packaging. LOC is defined by URL Currently the LOC spec defines both a streaming format and a packaging format. Reference for packaging will therefore need to be made to specific subsections of that draft. In the future if LOC packaging is separated from LOC streaming format, then the WARP references can be updated.