jiebi/CodeConvo huggingface dataset:
Code change:
3.2. <del> CCF uses the following algorithm to recompute the payload of the signature based on the "inclusion-proof" header: </del> <ins> CCF uses the following algorithm to verify an inclusion receipt: </ins> 4.

Related discussion:
text: NAME NAME I have read through URL, and made some edits here as discussed to correct the leaf definition. This is deliberately quite light on details, but I am obviously very happy to expand wherever necessary.
NAME I had not seen the updates made in URL, I have attempted to merge them in here.
NAME if/when you have a chance, I would be grateful for a review and some feedback on how to take this forward :)
NAME I have tried to address your feedback, I hope I did not miss anything.
NAME may I ask you to check if the changes correctly addressed your feedback, and what the next steps are?
NAME thank you for the discussion yesterday, I have and added requested assignments for the labels. Please let me know if I need to do anything else before this can be merged.
:+1: let's pull this in and prepare for WG adoption call
Code change:
cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect <del> on the current stream.  For a stream that is in the "half closed </del> <ins> on the identified stream.  For a stream that is in the "half closed </ins> (remote)" or "closed" - state, this frame can only affect processing <del> of the current stream and not frame transmission. </del> <ins> of the identified stream and its dependent streams and not frame transmission on that stream. </ins> The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent

Related discussion:
text: Two issues were raised about the use of the words "existing" and "current" to refer to streams. These were a little squishy, so I tightened the language a little. The text no longer uses either word to refer to streams, instead using stream states to describe where the relevant text applies and favouring "identified" as a fallback.
uses some under specified termonlogy: For example is for a PRIORITY frame which can be sent/received in the any state the same as in the following contexts: Can be translated to the stream's state? For example does it roughly mean ? If so then the usage in the PRIORITY frame section is a bit more confusing because a PRIORITY frame could be the first valid frame sent/received for a stream.
NAME - Thanks for the clarification!
NAME - I do have a question regarding your clarifications to the SETTING frame (specifically the SETTINGSINITIALWINDOWSIZE portion). It seems a bit confusing if a PRIORITY frame has been exchanged on an IDLE stream for the SETTINGSINITIALWINDOWSIZE not to apply to it. Consider the following example: 1) Stream is in the state (no frames exchanged) 2) A PRIORITY frame for stream is received. 3) A SETTINGS frame is received to update SETTINGSINITIALWINDOW_SIZE. ... 4) Stream transitions into the state. Is seems a bit counter intuitive that stream 's window will be the window size prior to step 3. Just imagine there are many more SETTINGS frames exchanged (and other events) before step URL stream 's window will be even more difficult to understand how it got to where it is.
That's a fair point. The current text is: From this, you might infer that a reserved or idle stream isn't affected. Implicit in here is that you don't actually have an active flow control window until streams are in those states. There is no sense in performing any accounting until you are actually sending, right? But then, it's only accounting and that 32-bit number might be allocated and used in some implementations. So, I think that this can be clarified, rather than rely on people only accounting in those states, the text might be better saying: Does that make more sense?
This does make more sense. On a related URL is the rational to prohibit WINDOWUPDATES on the IDLE streams when PRIORITY frames have been exchanged?
Code change:
cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect <del> on the current stream.  For a stream that is in the "half closed </del> <ins> on the identified stream.  For a stream that is in the "half closed </ins> (remote)" or "closed" - state, this frame can only affect processing <del> of the current stream and not frame transmission. </del> <ins> of the identified stream and its dependent streams and not frame transmission on that stream. </ins> The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent

Related discussion:
text: It seems like if a stream is allowed to be put into the priority tree (via a PRIORITY message) and its window size controllable (via SETTINGS) then why would a WINDOWUPDATE also not be allowed? I look to the following statement and think that accounting may already be required to track the PRIORITY and SETTINGS updates. The WINDOW_UPDATE accounting seems like it is very similar (or may be close to identical depending on the implementation).
We want to strictly limit the amount of state that is maintained for non-open streams. Currently, that is limited to priority. Opening that to more state isn't really necessary. For WINDOWUPDATE, there is only the case where you want to open the flow control window immediately after opening a stream, which currently causes a potential stall on the remote/sender side. As specified, you can create a priority graph that is separate from the other stream state (flow control in particular). If we allowed WINDOWUPDATE in idle (or reserved), then you need to commit more state. We already acknowledge that priority information needs special handling outside of the key stream states, so the risk is both accounted for, and already present. The most important factor though is that priority is expendable. Under DoS, you can drop priority on the floor. You can't do the same for flow control. Therefore, any state commitment needs to be strictly bounded for that.
Right. So for these cases the peer creating the stream will have to wait to expand (or shrink) the window until after the stream has transitioned out of the IDLE state. So state may not be required however if a peer wants to change the window for that stream then state will be necessary to keep and act upon when the state transition occurs. I"m not sure I follow. WINDOW_UPDATE is allowed in reserved according to . Priority is an interesting portion of the spec. It almost seems like you could ignore priority all together and be compliant :)
Hmm, strange how you forget these things. Yes, you can send WINDOWUPDATE in "reserved (remote)". This allows a client to affect the flow control window of the server that has promised a push. This is something that I know Firefox uses so that it can resume stalled pushes when it knows that they are needed. No extra credits over the initial window size are given to pushed streams until they are recognized as necessary.
Code change:
cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect <del> on the current stream.  For a stream that is in the "half closed </del> <ins> on the identified stream.  For a stream that is in the "half closed </ins> (remote)" or "closed" - state, this frame can only affect processing <del> of the current stream and not frame transmission. </del> <ins> of the identified stream and its dependent streams and not frame transmission on that stream. </ins> The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent

Related discussion:
text: You can't send WINDOWUPDATE in "reserved (local)". After all, the other side (the client) won't be sending anything on that stream. So none of this really affects processing of the setting :)
I think I agree with you in general (it is not necessary). I agree that minimizing state on IDLE streams seems like more of a driving force, and I also recognize that the peer can wait to send WINDOW_UPDATES until transitioning out of IDLE. I can also imaging a scenario that if an endpoint puts the node into a priority tree, it is possible they have an estimate of what they are going to be sending. It may then follow the theme of "a more flexible expressions of priority" (from ) to also be able to control the window of those streams (at a finer granularity than the SETTINGS frame). Anyways thanks for the discussion and clarification.
Editorial problem, I hope: The spec uses the phrase "current stream" in two places (both related to PRIORITY), but without any definition of what that means: 1) "5.1 Stream States: ... half closed (local) ... PRIORITY frames received in this state are used to reprioritize streams that depend on the current stream." 2) "6.3 Priority ... Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the current stream." I don't have alternate wording proposals because I'm not exactly sure what those sentences are trying to say. Note that I'm only talking about "current stream" in the singular. I see no confusion with the use of "current streams" (plural) in "6.9.2 Initial Flow Control Window Size".
"subject stream" or "identified stream" would work effectively well. I'll take suggestions.
Both sound fine, but "identified stream" is already used often in the spec and "subject stream" is never used.
Excuse me for trolling this issue but I couldn't help but notice how evil the issue number is.
Code change:
However, an XSS attack would still result in the attacker being able to initiate a new OAuth flow, and/or unregister the Service Worker. <del> 6.3.3. </del> <ins> 6.4.3. </ins> To limit the risk of token exfiltration:

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:
different digest values. To allow both parties to exchange a Digest of a representation with <del> no content codings (see Section 7.1.2 of SEMANTICS) two more </del> <ins> no content codings (see Section 7.1.2 of SEMANTICS) two more digest- </ins> algorithms are added ("id-sha-256" and "id-sha-512"). 1.3.

Related discussion:
text: is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.
Code change:
These flows typically involve using a mobile phone to scan a QR code or enter a user code displayed on the first device (e.g., Smart TV, <del> Kiosk, Personal Computer etc.). </del> <ins> Kiosk, Personal Computer or other electronic devices.). </ins> 3.1.

Related discussion:
text: See issue
NAME NAME if you have a moment, can you take a look and approve? I want to merge all PRs and publish an update.
Consider removing the use of etc with either concrete examples or replace with text.
Code change:
deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the insertion and consumption of the "Client-Cert" and "Client-Cert- <del> Chain" header fields occurring only on that connection. Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to that server. Other deployments that meet the requirements set forth herein are also possible. </del> <ins> Chain" header fields occurring only on that connection.  I-D.ietf- httpbis-message-signatures gives one example of this with an application of HTTP Message Signatures.  Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to that server.  Other deployments that meet the requirements set forth herein are also possible. </ins> 5.

Related discussion:
text: h/t NAME
The security considerations pay some good attention to the concerns of the actors that might deal with the headers defined in client-certs. It crossed my mind that you could mention header protection mechanisms, like Signatures, as one way to harden things.
Yeah, Signatures could be mentioned in there as a possible additional measure.
Code change:
Specification document(s): dpr of this document Related information: for Client Hints <del> 6.5. </del> <ins> 6.6. </ins> Header field name: Save-Data Applicable protocol: HTTP

Related discussion:
text: and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.
Code change:
A server that does not wish clients to reuse connections can indicate that it is not authoritative for a request by sending a 421 (Not <del> Authoritative) status code in response to request (see </del> <ins> Authoritative) status code in response to the request (see </ins> NotAuthoritative). 9.1.2.

Related discussion:
text: Could have been "a" just as easily, but I felt like a two-character pull request was just overkill.
Code change:
Due to policy the request MAY be denied (for instance if the federation from domain A is not allowed) <del> 2.4.3. </del> <ins> 2.5.3. </ins> The authorization server MAY leverage claims from the present authorization grant for claim population of the access token.  The

Related discussion:
text: Added use cases. We may want to refine these, or move them into a non-normative section later.
Code change:
12. <del> TBD </del> 12.1. <ins> This specification requests registration of the following Claims in the IANA "JSON Web Token Claims" registry IANA.JWT established by RFC7519. 12.2. </ins> This section requests registration of the "application/sd-jwt" media type RFC2046 in the "Media Types" registry IANA.MediaTypes in the manner described in RFC6838.

Related discussion:
text: Added JWT claims registration requests to IANA (to fix issue ) URL
This was meant as a placeholder/reminder for JWT Claims Registration requests to IANA that would be needed eventually. The and claims should be registered. I'm not sure about to be honest, which is ironic b/c I'm supposed to know about such things (see the so-called experts ). But it's somewhat different than the other claims in the registry. But, I dunno, requesting registration is probably the way to go w/ .
I share your unsureness, and agree that requesting registration is the way to go. btw in the spec, we have a text registered claim, so if we decide not to register it, that text needs to be updated.
Wait... really, where?
PR has been merged.
Code change:
3. <del> The prohibition on renegotiation in section 9.2.1 of RFC7540 additionally applies to TLS 1.3 post-handshake authentication. </del> HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post- handshake authentication as a connection error (see section 5.4.1 of

Related discussion:
text: This addresses feedback from the list: URL URL NAME NAME does this look good to you?
Very nice, thanks. You almost managed to do this with a net reduction in total lines. The only additions here are my fault. Respect.
Code change:
<del> Media over QUIC Requirements and Use Cases </del> <ins> Media over RTP over QUIC Requirements and Use Cases </ins> draft-gruessing-moq-requirements-latest Abstract This document describes the uses cases, requirements, and <del> considerations that should be part of the design of a real-time media protocol over QUIC RFC9000. </del> <ins> considerations that should be form the design of the encapsulation of a real-time media transport protocol operating over QUIC RFC9000. </ins> Note to Readers

Related discussion:
text: Hi, NAME I think this looks mostly fine (it looks like the abstract is a tiny bit garbled, but we can fix stuff like that in an editorial pass). Based on the changed title, I'm assuming that we aren't worrying about SRT and RUSH in this draft - that's probably a good call, because I don't think their requirements are going to look much like RTP over QUIC requirements. There will be some places that I will need to tighten up what I wrote, because they were still in scope when I was typing. I'll merge this, and see where I end up in an hour or two of typing.
I needed a bit more context for this: I'm probably confused by "The protocol". URL says it provides this authentication using TLS 1.3 handshake. Are you thinking of something in addition to the QUIC cryptographic handshake? (Assuming the definition of "Media Transport Protocol" in ), something provided by the Media Transport Protocol level? Or something else?
Something in addition to the QUIC cryptographic handshake (in which I am talking about TLS mutual authentication here, where client presents a valid certificate to server, and verifies the server certificate). Consider: Existing protocols in this space usually offer some "shared secret" of some variety as part of either/or an authentication handshake, and encryption of media: which are just secret values set in the field during connection handshake (see § 6.4) - but note they also support a cert-based approach which more closely matches TLS mutual auth where the Stream ID and user define the authorisation Before RIST Main profile there hasn't been a need for a lot of certificate-based authentication and so existing folk in field would use these types of shared secret patterns, and that having to keep PKI for devices may be problematic. Consider things like encoding hardware deployed in remote locations. Other options could be considered, like using a more SIP-like approach, but we would have to be careful not to bring the rest of the SIP kitchen sink with its round peg that might not fit in the square QUIC slot. I get this requirement presently is a bit flaky in part because the requirements are a bit unclear. Perhaps I put a little more description on the requirement, or remove it from the draft now, and leave it for a "ask later". Thoughts?
Code change:
<del> Media over QUIC Requirements and Use Cases </del> <ins> Media over RTP over QUIC Requirements and Use Cases </ins> draft-gruessing-moq-requirements-latest Abstract This document describes the uses cases, requirements, and <del> considerations that should be part of the design of a real-time media protocol over QUIC RFC9000. </del> <ins> considerations that should be form the design of the encapsulation of a real-time media transport protocol operating over QUIC RFC9000. </ins> Note to Readers

Related discussion:
text: NAME I think (1) adding the explanation that this is beyond the authentication mechanism provided by QUIC, and (2) leaving it in the draft, with a note that more detail is needed, and will be added as discussion proceeds, is all that's needed for now.
Closing this as I think it has been addressed, please by all means speak up if we still should do work here.
I THINK what we are doing, is roughly Start with current "Media - Media Transport Protocol", where "Media Transport Protocol" might be RTP Encapsulate in QUIC, to give "Media - Media Transport Protocol - QUIC" If that's right, we should be using "Media Transport Protocol" to describe the first layer under "Media", and what we're doing might better be described as something like "Media Transport Protocol Encapsulation" ("in QUIC"). Whatever we choose, we should be consistent - the Abstract says which would make me believe that we're designing a replacement for existing media transport protocols, but then under "Non-requirements, we have I think that the second quote is correct, so we just need to be clearer in the first quote.
I agree with this, and it should be fixed. Would you like me to clean it up or do you want to roll it in with other changes?
Hi, NAME would it be OK if you did this cleanup? I think adding the picture of the two protocol stacks, in some form, will be super helpful for readers.
I think we can close this as our nomenclature for the document is kind of done now the -00 is out.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.
Code change:
8.2.3. The COOKIE uses a semicolon (";") to delimit cookie-pairs (or <del> "crumbs").  This header field contains multiple values, but does not use a COMMA (",") as a separator, which prevents cookie-pairs from being sent on multiple field lines (see HTTP).  This can </del> <ins> "crumbs").  This header field contains multiple values but does not use a COMMA (",") as a separator, thereby preventing cookie-pairs from being sent on multiple field lines (see HTTP).  This can </ins> significantly reduce compression efficiency as updates to individual cookie-pairs would invalidate any field lines that are stored in the HPACK table.

Related discussion:
text: : We had trouble parsing this sentence. If the suggested text is not correct, please clarify what prevents cookie-pairs from being sent on multiple field lines. Original: This header field contains multiple values, but does not use a COMMA (",") as a separator, which prevents cookie-pairs from being sent on multiple field lines (see Section 5.2 of [HTTP]). Suggested: This header field contains multiple values but does not use a COMMA (",") as a separator, thereby preventing cookie-pairs from being sent on multiple field lines (see Section 5.2 of [HTTP]).
Code change:
COSE Envelope of the Signed Statement.  The key of the map entry corresponds to the name of the policy, while its value (including its type) is policy-specific.  For instance, the "register_by" policy <del> defines the maximum timestamp by which a Signed Statemnet can be </del> <ins> defines the maximum timestamp by which a Signed Statement can be </ins> registered, hence the associated value contains an unsigned integer. While this design ensures that all verifiers get the same guarantee

Related discussion:
text: With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1