jiebi/CodeConvo huggingface dataset:
Code change:
IETF community under the banner of "Media Over QUIC", provides analysis about those use cases, recommends a subset of use cases that cover live media ingest, syndication, and streaming for further <del> exploration, and describes considerations that should guide the design of protocols to satisfy these use cases. </del> <ins> exploration, and describes requirements that should guide the design of protocols to satisfy these use cases. </ins> 1.1.

Related discussion:
text: If we renamed the document as "Live Media Over QUIC", it would be more accurate, and the BOF proponents could point to this draft and ask people with other use cases if their use cases overlap with the live media use cases, perhaps allowing the BOF to recommend doing the live media use cases in this draft, and inviting people to provide comments on this draft explaining their use cases, so the IESG would know what to do with them. Your thoughts?
I don't object to the name change but I don't feel strongly.
That name works for me too.
We should revisit after the BOF, when we know what the scope of the document will be. :sunglasses:
So, this is slightly more complicated than I had hoped. The use cases in the draft span "Media Over QUIC". The considerations (and, if we get that far, requirements) in the draft only cover "LIVE Media Over QUIC". So, let's leave this one open, until we find out the right thing to do, and then we can Do The Right Thing. :innocent:
I would propose we rename (again) to "Media over QUIC Use Cases and Requirements", for a few reasons: Scope of use cases that the WG will work on isn't yet settled, and it's likely that we may need to cover some (but not all) interactive use cases as well as hybrid interactive/live. I still think we should set the protocol requirements in the document - this frees up the charter to describe scope and milestone, and our draft (if WG adopted) to set the use cases and what we will require of the deliverables. If WG adopted, the details of what is in and out can be made via WG consensus. This follows a similar title format to and other documents like it. NAME thoughts?
Code change:
3.5. <del> The transport session can be terminated at any point.  When native </del> <ins> The Transport Session can be terminated at any point.  When native </ins> QUIC is used, the session is closed using the CONNECTION_CLOSE frame (QUIC).  When WebTransport is used, the session is closed using the CLOSE_WEBTRANSPORT_SESSION capsule (WebTransport).

Related discussion:
text: My understanding is that MoQ is always hop-by-hop encrypted by virtue of working over QUIC or WebTransport, and therefore a "relay" as described in the draft can only inspect Track/Group/Object metadata if it terminates QUIC. The document should clarify the requirements.
I agree with Alan. As a QUIC enthusiast, I guess the current draft implicitly suggests hop-by-hop QUIC termination at relay, e.g., which is necessary to enable cache at relay while having MOQT Message Type and OBJECT metadata as QUIC payload. Yet it is definitely more clarified for readers to explicitly see that information in an early section (e.g., sec 1.1.4).
Given MoQ is over either QUIC or WebTransport, I believe it's impractical to restrict it to only QUIC based transports.
The context of the question is whether one can build an MoQ relay that can view object properties without terminating the TLS session underpinning MoQ or WebTransport (eg an untrusted middlebox).
LG, but given Webtransport is also a substrate MoQ runs over, I think we want to avoid using QUIC connection?LGTM
Code change:
response when the request payload was big enough to justify use of a compression coding but the client failed do so. <del> 12.1.5. </del> <ins> 12.5.4. </ins> The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred in the

Related discussion:
text: initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...
Code change:
project" would show them the secret project that they're authorized to see, but if "projects.example" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along <del> with the request. "projects.com" will render a 404 error to avoid </del> <ins> with the request. "projects.example" will render a 404 error to avoid </ins> leaking secret information, and the user will be quite confused. Developers can avoid this confusion by adopting a session management

Related discussion:
text: URL was incomplete, leaving a number of inadvertant references to sites, or the TLD. This patch, hopefully, is less incomplete. h/t NAME and NAME for pointing this out.
WDYT, NAME
Code change:
how those content encoding(s) can be removed. The "Encryption" header field uses the extended ABNF syntax defined <del> in Section 1.2 of RFC7230 and the "parameter" rule from </del> <ins> in Section 1.2 of RFC7230 and the "parameter" and "OWS" rules from RFC7231. </ins> If the payload is encrypted more than once (as reflected by having multiple content-codings that imply encryption), each application of

Related discussion:
text: : These rules do not permit whitespace between a semicolon and a parameter, which was probably intended (judging from the examples and from similar rules elsewhere in HTTP). They should be rewritten as follows: and the import of the rule from RFC 7230 should be noted in the preceding text (“The "Encryption" header field uses the extended ABNF syntax . . .” and similarly for ).
Thanks for picking this up.
Code change:
7.1. <del> Various attacks might be amplified by being stored in a shared cache. Such "cache poisoning" attacks use the cache to distribute malicious content to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. </del> <ins> Various attacks might be amplified by being stored in a cache.  Such "cache poisoning" attacks happen when an attacker uses implementation flaws, elevated privileges, or other techniques to insert a response into a cache.  This is especially effective when shared caches are used to distribute malicious content to many clients. </ins> One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see

Related discussion:
text: A private cache that can be manipulated so that it mistakenly creates a cache entry might not have the reach of a shared cache, but it can still be a problem. Cache poisoning occurs when a cache can be written to by an entity other than the one that the cache would normally recognize as being authorized to write to it. Take the websocket poisoning where a cache misread a websocket stream as HTTP queries and established cached records under arbitrary origins. This would allow for poisoning of entries normally not controlled by the host that was using the websocket. Even though that might have been a single user affected by the poisoning, the effect was serious enough and motivated the inclusion of masking in websocket.
Simple :)
Code change:
Then the sorted-variants would be: <del> Which means that the sorted-keys would be: </del> <ins> Which means that the result of the cache algorithm would be: </ins> Representing a first preference of a French, gzip'd response.  Thus, if a cache has a response with:

Related discussion:
text: I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?
Code change:
following ways: Clients MUST NOT consult DNS to establish the connection's <del> authority for new requests.  The TLS certificate MUST stil be used to do so, as described in RFC7540 Section 9.1.1. </del> <ins> authority for new requests.  The TLS certificate MUST still be used to do so, as described in RFC7540 Section 9.1.1. </ins> Clients sending a new request SHOULD use an existing connection if the request's origin is in that connection's Origin Set, unless

Related discussion:
text: Fix one typo. Technically, a set is always a subset of itself. Therefore current wording implies that if two connections have identical Origin Sets, then neither should be used for new requests, and both should be closed. Fix this by saying "proper subset" instead of "subset".
Thanks!
Code change:
record the set of prefixes that have been advertised on infrastructure and the maximum valid lifetime that was advertised. On restart, the router should assume that hosts on the infrastructure <del> link have received advertisements for any such prefixes, and should immediately deprecate them, and continue to do so until the maximum valid lifetime has elapsed after restart. [WG: we could actually just not advertise the prefix, rather than deprecating it.  In this case, the host should wind up preferring some other prefix for new connections anyway, because it will have a later preferred lifetime expiry.  As long as we remember the route and resume forwarding for it, existing connections can continue until the prefix becomes invalid. Further experience with this shows that this solution doesn't work well at all.  Ideally the stub routers would all use some identifier specific to the stub network to construct the prefix advertised on the AIL.  At present Thread uses the Thread "extended PAN ID", which is a 64-bit quantity.  Perhaps something like the SSID could be used for a WiFi stub network.  I don't think there's a way to specify this generally.  But it seems as if the solution proposed here probably isn't worth doing.] </del> <ins> link have received advertisements for any such prefixes. When possible, it is best if all stub routers serving a particular stub network use the same 64-bit prefix on the AIL.  For example, Thread stub routers use bits from the Thread Extended PAN ID to generate the ULA prefix's Global ID and Subnet ID.  The Global ID generation conforms to RFC4193 because the Extended PAN ID is generated randomly using the same mechanism that is specified in RFC 4193 for the ULA prefix bits. </ins> 5.2.2.

Related discussion:
text: This means that if there are several stub routers connected to the same AIL and the same Thread network, they will all always advertise the same ULA on the AIL if there's no usable prefix there. This has a really nice benefit of increasing the stability of numbering on the wire in the presence of stub router reboots. This prefix isn't routable, so if the stub router gets connected to a different AIL, there's not much it can do about it. It's not actually clear what to do in this situation, since if there's another stub router still connected to the old AIL, we have ambiguous routing to that prefix on the stub network. In the case of Thread, we don't consider this a serious concern, since thread has similar locality to home networks: if you can't reach the home router, you probably can't reach the thread network you were connected to before either.
Not all aspects described here are fully clear yet, and there's a tension between this text and other PR text that says ULA Site Prefix is used to generate the AIL ULA link prefix. But it's best to merge the new text now and use that as a basis for further review!
Code change:
The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared <del> cache.  A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable. </del> <ins> cache. </ins> If the private response directive specifies one or more field names, this requirement is limited to the field values associated with the

Related discussion:
text: I think this is the right thing to do; we added too much text here in 7234.
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
I'll trust you on the actual change :-)
Code change:
the Priority request header field set to "u=7" (background).  Then, when the user navigates to a page which references the new JavaScript file, while the prefetch is in progress, the browser would send a <del> reprioritization frame with the priority field value set to "u=0" (prerequisite). </del> <ins> reprioritization frame with the priority field value set to "u=0". </ins> In HTTP/2 and HTTP/3, after a request message is sent on a stream, the stream transitions to a state that prevents the client from

Related discussion:
text: A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.
Code change:
Intent/service assurance <del> Service E2E and per-link KPIs on the Digital Map (connectivity status, high-availability, delay, jitter, and loss) </del> <ins> Service E2E and per-link KPIs on SIMAP (connectivity status, high- availability, delay, jitter, and loss) </ins> Capacity planning

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:
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection <del> with the client, such as is described in RFC8446 or RFC5246, and </del> <ins> with the client, such as is described in TLS or RFC5246, and </ins> validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following

Related discussion:
text: update refs for HTTP Semantics, HTTP/3, and QPACK to point to the now RFCs 9110/9114/9204 for
Thanks Mike. That was much easier than using the "suggestions" option. I merged and then fixed(!?) the YAML header with . I think this one is good to go now?
Yes, good to go!
I-D.ietf-httpbis-semantics -> RFC 9110
Also HTTP/3 ietf-quic-http -> RFC9114 QPACK ietf-quic-qpack -> RFC9204
Code change:
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection <del> with the client, such as is described in RFC8446 or RFC5246, and </del> <ins> with the client, such as is described in TLS or RFC5246, and </ins> validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following

Related discussion:
text: attempt NAME "simple alternative" in to say the chain is in the same order as it appears in TLS rather than copying the language from TLS
There's a bunch of text in the draft about putting the certificate chain in the right order. This tries to crib from TLS and ends up being somewhat tricky to get right as TLS has a bunch of carefully worded and - frankly - ambiguous rules. As a simple alternative, how about we just state that the certificates need to appear in the same order as the client sent them in TLS.
Makes sense. Will look at adjusting the text accordingly.
I think this is a bit more fundamental than just the order. It's really a question of whether this is a certificate path, or a pile of input certificates to run verification over. That is, either: The origin runs path building, taking the unordered/unverified pile of input certificates from the header, in TLS order. The proxy runs path building and passes the result in the header. The origin assumes a path has been built and is merely applying ACLs based on some aspect of the resulting path. A mismatch here could result in security issues. For instance, suppose the origin wants to only allow chains issued by intermediate certificate I1 to access . If the header means (1) but the origin expects (2), this ACL is trivially bypassable: Client has a certificate chain EE -> I2 -> CA. Client connects to proxy and sends {EE, I2, CA, I1}. (Or perhaps {EE, I2, I1, CA}. Or whatever else. Different verifiers are differently permissive about path-building. Perhaps it omits I2 altogether and the path-builder picks it up some other way.) Even if the proxy runs certificate verification, a path-building verifier will build the EE -> I2 -> CA path and just consider I1 as a random unused certificate. , per the TLS order rule, contains {EE, I2, CA, I1} Origin server checks this and concludes "aha, this was issued by I1 and can access the resource". Conversely, the semantics are (2), the proxy needs to have enough information to validate the certificate, up to a valid trust anchor for the application. If you all intended to punt that to the origin, that's a different protocol.
Code change:
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection <del> with the client, such as is described in RFC8446 or RFC5246, and </del> <ins> with the client, such as is described in TLS or RFC5246, and </ins> validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following

Related discussion:
text: If the spec says TLS order, it's implicitly saying the interpretation is (1). But as that leaves a security-critical check to the origin, it should be explicit about this. Also, as it leaves all certificate validity to the origin, it'd need to further define an error-handling story to properly tell the client the certificate was invalid. But I know of no client that uses HTTP-level errors to clear client certificate decisions, only TLS alerts. I think (2) may be a more robust/compatible.
It is definitely 1. You do 2 and you don't need this client-cert-chain field at all. That doesn't mean that a proxy can't be configured to do the work and pass the info along. But one of the two needs to be in the hook for enforcement. A consequence of 1 is that alerts at the TLS layer won't be used to signal errors, aside from those that the proxy detects (or has to, like if the signature is invalid). That is ok, mostly. The main protocol issue here that might be a problem is validation of signatureschemecert. I can't see how failing to validate that would be a significant problem though.
In on the PR that introduced the chain I was aiming for 2. But eventually relented to MT. Some additional considerations about the security implications are likely warranted though.
I see. If it's (1), that should probably be clearer in the draft. That also means the draft needs to define an error-signaling scheme. Moreover, if the proxy doesn't then translate that error into TLS alerts, we'd need changes in clients for servers relying on this to work right. I'll file a bug.
I ran into real reservations as I looked at making this change. I still don't like pushing the trust chain validation to the origin. For many reasons. The proxy also has no means of signaling to the client which trust anchors the origin is okay with. The current text is somewhat ambiguous about what goes in Client-Cert-Chain but I think that's actually better than saying it has to be same as in the TLS handshake. I dunno, I think I might raise the question of WTF actually goes in Client-Cert-Chain at the next interim or real meeting.
At the last virtual interim (in May/June yikes!)
Code change:
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection <del> with the client, such as is described in RFC8446 or RFC5246, and </del> <ins> with the client, such as is described in TLS or RFC5246, and </ins> validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following

Related discussion:
text: Martin kindly suggested that I was making this too complicated and to just make the change (paraphrasing). I've tried to do that with changes in PR .
This works well enough on the critical points. Some points about readability though.
Code change:
Changes to the "request-target" and "Host" header field that when applied together do not result in a change to the message's <del> effective request URI, as defined in Section 5.5 of HTTP. </del> <ins> effective request URI, as defined in Section 5.5 of MESSAGING. </ins> Additionally, all changes to content not covered by the signature are considered safe.

Related discussion:
text: separates MESSAGING and SEMANTICS concepts (Eg. fields)
Thanks! :tada:
The spec relies only on HTTP Semantics and not on HTTP/1.1 messaging. [ ] improve wording [ ] switch to http-core Check all references to Messaging and consider replacing them using Semantic. See URL
NAME NAME NAME I was re-reading the spec after the more recent filed issues, and I think that switching this draft to HTTP Core terminology (eg. I-D.ietf-httpbis-semantics ) we could have a more consistent background for taking the right decisions about things like transformations, intermediaries.
This should be taken care of with , NAME please re-open with comment if there are more things to be done.
Code change:
information in multipart.byteranges for the media type "multipart/ byteranges". <ins> Furthermore please update the registry note about "q" parameters with a link to field.accept of this document. </ins> 18.9. Please update the "Service Name and Transport Protocol Port Number"

Related discussion:
text: The text in the document says: The Media Type Designated Experts' suggested to make that stronger, and have the following note on the : Let's agree on either "discouraged" or "prohibited", and align the text in the document and in the IANA registry note.
I believe what the IANA registry says is good, so what's left to do is to align our spec text with that. My understanding is that no new text in the IANA Considerations is needed, as the change to the registry already happened.
If we agree to add the reference to this RFC in the IANA note, once the RFC is published, I can ask IANA to do that.
Good point. We could add that to the IANA Considerations. Should I?
I think that would make sense. Let's hear from others.