jiebi/CodeConvo huggingface dataset:
Code change:
parameters).  It can appear in requests and responses.  It is an end- to-end signal of the request priority from the client or the response priority from the server.  merging describes how intermediaries can <del> combine the priority information from client requests and server responses to correct or amend the precedence.  Clients cannot interpret the appearance or omission of a Priority response header as acknowledgement that any prioritization has occurred.  Guidance for how endpoints can act on Priority header values is given in server- scheduling and client-scheduling. </del> <ins> combine the priority information sent from clients and servers. Clients cannot interpret the appearance or omission of a Priority response header field as acknowledgement that any prioritization has occurred.  Guidance for how endpoints can act on Priority header values is given in server-scheduling and client-scheduling. </ins> Priority is a Dictionary (STRUCTURED-FIELDS):

Related discussion:
text: Replace use of "precedence" that could be confusing with something better. With this PR, there are still two remaining occurrences of "precedence," in , and . I think that those two are fine, as they are surrounded by other text explaining the context. I think it'd be clear to readers that we are using the term to describe difference of importance between multiple responses. FIxes Ea of .
Thank you, this looks good. I agree with your rationale about why we don't need to remove all instances.
Code change:
10. <del> We would like to thank Alen Horvat, Arjan Geluk, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Giuseppe De Marco, John Mattsson, Matthew Miller, Justin Richer, Kushal Das, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> We would like to thank Alen Horvat, Arjan Geluk, Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Nat Sakimura, Orie Steele, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Torsten Lodderstedt, and Vittorio Bertocci for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: Fixes Issue
Thanks NAME I think the two folks should be acknowledged and the small change around the claim incorporated. Then I think this should be merged and we should publish a -04 as basically a bug fix. The issue NAME URL found kinda undermines the whole point of SD-JWT and we should have a published version out that fixes that.
When decoys are used (_sd members not corresponding to a disclosure are added) the says to I imagine this is not intended and the holder should ignore missing disclosures instead? Same in
Actually the following in doesn't make sense to me at all since the whole point is to selectively not release disclosures.
Good point/catch Filip. I think the intent was to say that if a disclosure is found that isn't referenced by a _sd hash value, that should be a rejection. But the language got turned around somewhat. I think anyway. It needs to be fixed or clarified regardless though.
Processing by the Holder: This seems fine to me. In the context, "the digests" refers to "the digests of the Disclosures". If there is a Disclosure that hashes to a digest not found in any _sd array, the SD-JWT is invalid. Maybe we can clarify by modifying this to: Verification by the Verifier: This is wrong and should read "If no such Disclosure can be found, the digests MUST be ignored." Thanks for bringing this up, Filip!
Don't we then also need something at the end of Verification by the Verifier - that makes sure all of the provided disclosures match a digest in the payload and reject if that is not the case or am I missing something here?
That would force the Holder to act correctly, but would it provide any benefit beyond that?
The changes above are included in PR - please review NAME NAME
PR merged
Code change:
(appendix.encoding). A segment MAY depend on any number of other segments.  The encoder <del> MUST indicate these dependecies on the wire via the "HEADERS" message (headers). </del> <ins> MUST indicate these dependecies on the wire via the SEGMENT header (segment). </ins> The sender SHOULD NOT use this list of dependencies to determine which segment to transmit next.  The sender SHOULD use the delivery

Related discussion:
text: Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.
Code change:
should work with the relevant working groups and present our use- cases. <ins> 5.2. Even if multicast and other network broadcasting capabilities are used in delivering media in our use cases, as QUIC doesn't yet support it and it's inclusion would require a lot more complexity in both the specification and client implimentation this should be left out for now. </ins> 6. This document makes no requests of IANA.

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:
7.2. <ins> The "scopes_supported" parameter is the list of scopes the resource server is willing to disclose that it supports.  It is not meant to indicate that an OAuth client should request all scopes in the list. The client SHOULD still follow OAuth best practices and request tokens with as limited scope as possible for the given operation, as described in Section 2.3 of OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics. 7.3. </ins> TLS certificate checking MUST be performed by the client, as described in TLSRequirements, when making a protected resource metadata request.  Checking that the server certificate is valid for

Related discussion:
text: "The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."
Code change:
next-hop-aliases <del> A string containing one or more DNS alises used to establish a proxied connection to the next hop. </del> <ins> A string containing one or more DNS aliases or canonical names used to establish a proxied connection to the next hop. </ins> This document

Related discussion:
text: This draft (-00) is using the term "alias" in a slightly different way than used in DNS: A CNAME record has two names, the owner name on the left-hand side or "alias", and the target name on the right-hand side or "canonical name". RFC 8499 (DNS Terminology): In other words, to use the example in the draft: Which might correspond to a DNS response that looked something like: and are DNS aliases (because there are CNAME records with those owner names) whereas is a DNS "canonical name" without an alias. But is included in the example in this draft. This might be confusing for the DNS name at the end of the CNAME chain (which is not an alias from a DNS perspective), so I might suggest changing: to something like:
Code change:
public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage). <del> 3.5. A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers (field.range).  After several such transfers, a cache might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a cache MUST update the stored response header fields using the header fields provided in the new response, as per update. </del> 4. When presented with a request, a cache MUST NOT reuse a stored

Related discussion:
text: so it's adjacent to the other range-related requirements, rather than separated from them by the authenticated requirements.
Code change:
Given an ASCII string as input_string, return a byte sequence. input_string is modified to remove the parsed value. <del> If the first character of input_string is not "*", fail parsing. </del> <ins> If the first character of input_string is not ":", fail parsing. </ins> Discard the first character of input_string. <del> If there is not a "*" character before the end of input_string, </del> <ins> If there is not a ":" character before the end of input_string, </ins> fail parsing. Let b64_content be the result of consuming content of input_string <del> up to but not including the first instance of the character "*". </del> <ins> up to but not including the first instance of the character ":". </ins> <del> Consume the "*" character at the beginning of input_string. </del> <ins> Consume the ":" character at the beginning of input_string. </ins> If b64_content contains a character not included in ALPHA, DIGIT, "+", "/" and "=", fail parsing.

Related discussion:
text: ... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free
Code change:
4.2. <del> The following are design requirements for modelling the Digital Map: </del> <ins> The following are design requirements for modelling the Digital Map. Theey are derived from the core requerements collected from the operators and although there is some duplication, these are focused on summarizing the requirements for the design of the model and API: </ins> Digital Map should contain only topological information.

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3 (partial, just examples), 5, 6, 7
Code change:
3. <del> WARP delivers CMAF-packaged media bitstreams.  This specification references CMAFpackaging to define how CMAF packaged bitstreams are mapped to MoQTransport groups and objects. Both CMAF Object mappings CMAFpackaging Section 4 are supported and a content producer may use either.  To identify to consumers which object mapping mode is being used for a given Track, a new track field is defined as per table 1. </del> <ins> WARP delivers CMAF CMAF and LOC LOC packaged media bitstreams. Either format may be used in a broadcast, or they may be intermixed between tracks.  The packaging format of a track, once declared, MUST remain constant. </ins> 3.1. <del> The packaging mode value is defined by Table 2. </del> <ins> This specification references CMAFpackaging to define how CMAF packaged bitstreams are mapped to MoQTransport groups and objects. Both CMAF Object mappings CMAFpackaging Section 4 are supported and a content producer may use either.  To identify to clients which object mapping mode is being used for a given Track, the catalog "packaging" field MUST use one of the values defined in Table 1.  The values are case-sensitive. Table 1 provides values for the catalog "packaging" field with CMAF packaging. </ins> 3.2. <ins> This specification references Low Overhead Container (LOC) LOC to define how audio and video content is packaged.  With this packaging mode, each EncodedAudioChunk or EncodedVideoChunk sample is placed in a separate MOQT Object.  Samples that belong to the same Group of Pictures (GOP) MUST be placed within the same MOQT Group. Table 2 provides values for the catalog "packaging" field with LOC packaging. 3.3. </ins> WARP Tracks MAY be time-aligned.  Those that are, are subject to the following requirements:

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.
Code change:
3.1. <del> Caches MUST include all received header fields -- including </del> <ins> Caches MUST include all received response header fields -- including </ins> unrecognised ones -- when storing a response; this assures that new HTTP header fields can be successfully deployed.  However, the following exceptions are made:

Related discussion:
text: : I think that MAY should be prose, and should also list retrying the request as an option.
Code change:
3.3. The application will be able to retrieve all services from the <del> Digital Map API for selected network type.  The application will be </del> <ins> Digital Map API for selected network types.  The application will be </ins> able to retrieve the topology for selected services via Digital Map API and from the response it will be able to navigate via the supporting relationship top-down to the lower layers.  That way, it

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits
Code change:
A complete field section consists of either: <del> Field compression is stateful.  One compression context and one decompression context are used for the entire connection.  A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. </del> Each field block is processed as a discrete unit.  Field blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The

Related discussion:
text: As they relate to changes in SETTINGSHEADERTABLE_SIZE. This is the strict, by-the-book interpretation. That is, if the value changes, you have to send the update, even if it is pointless (that is, you aren't changing the size of the table). Note that I'm eliding the point about multiple instructions, which are necessary if the decoder reduces the maximum below the current size. The only nod in that direction is "at least one" and a reference to the section that talks about the need for multiple updates. This pulls in more of RFC 7541 than I might have liked, but we have to deal with the integration somewhere and this seems like a reasonable place to do that. It might have been better to put this text in a -bis revision of RFC 7541, but we decided to leave that document as-is.
LGTM, this is a nice clarification that removes the possibility of a different interpretation that's known to have caused interoperability issues (nghttp2 vs haproxy). Let's merge it!
Oh I see this PR already being merged. Opened .
I think this PR is in the correct direction. Endpoints have to process instructions using dynamic table, even when they advertise SETTINGSMAXHEADERLISTSIZE of zero. That is because the default is 4096. We did fix this problem in QPACK, but HPACK had already shipped. OTOH, I have concerns regarding new text suggesting Dynamic Table Update Size be sent even when there is no change in the size.I agree with Willy, this is a really good clarification.
Code change:
A complete field section consists of either: <del> Field compression is stateful.  One compression context and one decompression context are used for the entire connection.  A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. </del> Each field block is processed as a discrete unit.  Field blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The

Related discussion:
text: This reverts commit 290e381719b2fefe4e6182d3be288c48e8f5fd7e. See for most of the discussion. The key change here is to address by only requiring that the change be signaled when the table size is reduced. When I dug more into this, it's a more disruptive change, so I've made a bunch of additional changes in support of that.
I have one suggestion about a point that seems to be possible to infer from all this but is not explicitly written and may condition the sequencing of operations. Do we want to support multiple settings updates on this parameter, hence announce in the middle of a communication that we changed our local decoder size ? It seems to me that this is the case but it does not appear in the original text where it more likely sounds like the initial size. If we want to support repeated size changes from the decoder, then I agree that it's better to consider that 4096 is initial and that the setting changes it and Kazuho's wording sounds fine. But then it possibly ought to be explicitly mentioned such as: This makes sure that it's safe for an encoder to only process the settings frame once and to send a single DTSU instead of one per SETTINGS frame.
NAME I struggled a little with your text, because I think that is what this already says. However, to address your question about settings changes, I don't think that we do really want multiple settings changes, but that is the protocol we have. So multiple settings changes are possible and implied by the design of SETTINGS. Multiple changes are possible within the same SETTINGS frame, in case you were interested. The designers of this protocol seemed to love unnecessary complexity. There are some good reasons, but it's not clear that those reasons are sufficiently strong to justify the headaches they cause. I would really like it if implementations could just signal once in the preface, handle the preface from their peer and be done with settings. That's how HTTP/3 works and while we might have been forced into it there by the complexities of the QUIC integration, it turned out to be a good outcome in my view. Here, however, we need to deal with the fact that the protocol permits changes.
Code change:
A complete field section consists of either: <del> Field compression is stateful.  One compression context and one decompression context are used for the entire connection.  A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. </del> Each field block is processed as a discrete unit.  Field blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The

Related discussion:
text: Hi NAME I'll have to clone your repo and run the diff here by hand then because I can't figure in this horrible interface how to view the complete set of changes at once resulting from multiple subsequent changes. And it will be easier to reread Kazuho's proposal in context. Regarding "do we want" I didn't imply that we love this situation, just "do we want in order to support this interpretation of the protocol", given that the current text never explicitly states that (as Cory mentioned a while ago, the settings change is acked by a the settings ack) and that even the protocol's original co-author back then already stated that it wasn't meant to be interpreted that way ( URL ). Sure, the result is that we have what we have and we have to deal with it in the best way possible. In that spirit I think that Kazuho's proposal tries to be as closed as possible to the current state of deployment by indicating how some implementations behave vs what others expect and suggesting not to play in the gray area there.
Hervé's post there is quite useful, yes. That supports this overall view. I've cleaned up the comments on the diff view; let me know if what you see works. The diff overall is fairly clean (it's mostly additions).
I'm just a bit confused, where am I supposed to see the unified diff ? the only way I know is by clicking on each individual commit, which is the solution I find inconvenient :-/ Do I have to add a magic ".patch" in the URL bar somewhere ?
There's a "Files changed" tab toward the top of the page: ! Adding ".patch" to the URL is a neat hack for finding something you can download, but usually I find that pulling from the branch is nicer to work with.
Thanks for pointing that one, I always thought it only contained the original PR's changes, not the latest proposed ones :-) I'm seeing this part which remains confusing: "Any change to the maximum value set by the decoder takes effect when..." which I'm reading as "the decode first sets a size, then any change to this size ...", thus reinforces what most servers currently do. I think Kazuho's proposal to move the sentence about initial values solves this: "The dynamic table has a maximum size that is set by a decoder using the SETTINGSHEADERTABLESIZE setting; see XXX.