jiebi/CodeConvo huggingface dataset:
Code change:
If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirect URI, the authorization server informs the client by adding the following <del> parameters to the query component of the redirect URI using the "application/x-www-form-urlencoded" format, per application-x-www- form-urlencoded: </del> <ins> parameters to the query component of the redirect URI as described by query-string-serialization: </ins> REQUIRED.  A single ASCII USASCII error code from the following:

Related discussion:
text: This moves the description of serializations to the appendix part of
Though i wonder whether the Authorization Response () section should account for the extension - URL with text like "unless specified otherwise by an extension".
yeah I can add that, sounds reasonable
added a lot of text around how clients form authorization requests, the language does not however account for the optional POST binding at the authorization endpoint. Sections and do not account for the optional POST binding which uses the request body to carry the encoded parameters. In OIDC there's the request parameters.
This has been resolved in , there is now a section that describes the serialization methods in an appendix, which is referenced elsewhere in the spec: URL
LGTM
Code change:
NOTE: A "public suffix" is a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us".  This step is essential for preventing attacker.com from disrupting the <del> integrity of example.com by setting a cookie with a Domain </del> <ins> integrity of site.example by setting a cookie with a Domain </ins> attribute of "com".  Unfortunately, the set of public suffixes (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix

Related discussion:
text: This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.
Code change:
latest group(s).  The publisher then selectively transmits objects based on their group membership. <ins> Groups are ordered numerically by their Group ID. </ins> 2.4. A track is a sequence of groups (model-group).  It is the entity

Related discussion:
text: Explicitly state that these IDs are numbers that can be compared to determine order. This is already implicit in a number of places in the draft.
NAME and NAME Said that group IDs may be sparsely used, particularly in cases when they were chosen in a way to avoid collisions. This sounds like an interesting set of use cases, but previously my understanding was that groups indicated some sort of temporal ordering, even if it's not strict. If Group IDs don't imply temporal ordering and join points, and instead they're a way to publish Objects in a way that don't collide with one another, it seems like a different thing? Top of head strawman: Possibly different users could have the ability to publish Objects as themself for a single track? Having a few specific use cases would be helpful here, because it feels like there are real use cases, and the existing mechanisms might be awkward at best? It would also be useful to understand the use cases so we understand if they're in scope for MoQ.
Possibly relevant to
I have advocated strongly for having Group IDs begin at 0 and increment by 1, with no gaps. This restriction (which is identical to what we have for Objects) brings us some valuable benefits: Arbitrary relays, without any other information, can know if Groups are missing Clients can tell if groups are missing, without having a catalog to define the numbering scheme. I spoke this over with Cullen and Suhas. They mentioned that they have a use-case in which clients will publish data under the same namespace and name, but using different ranges of groups IDs (correct me if I'm wrong there guys) and that therefore GroupIDs cannot increment by 1. My concern is that this one use-case is burdening the transport with a whole ton of complexity around knowing where there are gaps. Witness . I'd like to simplify moq-transport by setting restrictions on GroupsIDs and then help brainstorm alternate solutions to their multi-publisher use-case that are compliant with a simpler version of moqt.
I completely disagree with the use-case NAME and NAME have suggested. A track must have a single publisher and I just can't envision how MoQ would work otherwise. If you have multiple publishers, then make multiple tracks/namespaces. A subscriber can request them all. Or a muxer can request them all and produce a new merged track at incrementing group boundaries.
Code change:
latest group(s).  The publisher then selectively transmits objects based on their group membership. <ins> Groups are ordered numerically by their Group ID. </ins> 2.4. A track is a sequence of groups (model-group).  It is the entity

Related discussion:
text: I am also in favor of Group ID beginning at 0 and incrementing by 1.
There was this issue discussion on groupId and gaps and why relays need not do the book-keeping on gaps between groupIds or such .. URL
I'm totally lost on what problem people think they are trying to solve with this issue. I really object to how we constantly reopen stuff for no reason. The protocol works fine with multiple publishers and out of order groups - we have running code that does that. We have discussed this is the past and the use cases. There is no new data that is like here is why this causes performance problems. We have multiple use cases that take advantage of this. ( some of the variations of group chat, logging, metrics ) GroupID are left to the applications using them to choose. Due to timing and priority issues, if a relay receives group 2, object 1, it can not assume it will never receive another object form group 2. Some applications use them to indicate ordering and dependency. The data model makes it clear they are a join point, and because of that things that have dependencies can use them for the dependent things. The proposal we had for make before break can results in out of oder groups.
Speaking as Chair: NAME The issue as filed is soliciting use cases. Will stated you have some, it would help if you could document them here in as much detail as possible. Other folks seem to be advocating for a particular design without seeing the full picture. It would probably help if we understood the use cases first. I'm surprised to hear about use cases where multiple publishers are publishing to the same track simultaneously in different groups. I don't ever recall talking about this pattern, apologies if I missed it. Victor pointed out here (URL) that arbitrary group or object numbering interact poorly with subscribe ranges/fetch. Because a relay can never know the how the id spaces are populated for a track, the relay/cache has to assume all ids exist until told otherwise by the original publisher. Suhas indicated that if a publisher drops (skips?) a group it will signal that. There are scalability challenges if the 62 bit space is sparse - perhaps people were talking past each other in the issue?
Code change:
latest group(s).  The publisher then selectively transmits objects based on their group membership. <ins> Groups are ordered numerically by their Group ID. </ins> 2.4. A track is a sequence of groups (model-group).  It is the entity

Related discussion:
text: I think the group is struggling because use cases and the protocol design elements they depend on are not well documented, in writing, in a central place. I've gone back and forth about resurrecting the use cases and requirements draft and adding new detailed sections that have this scope (eg: explaining make-before-break, and what moqt protocol elements it requires). Ideally, we would get consensus on the use cases we are trying to support. Would folks find it helpful? I'm wary of having folks invest in writing something if we're not going to read it.
As discussed at length in the other issue, "no relay should not assume any structure between groups". Groups are independent join points and we should not add more application semantics at the MOQT layer . it tends to more bookkeeping which is not really needed.
Let me take a stab at going through the range of solutions that can exists when fetch requests are made for large absolute ranges. For this discussion, I am ignoring caching since it is easy to think through caches independently. When a relay receives a fetch request for large absolute range, one the following can be the response it gets from the upstream Relay receives a marker object for each group that is not included. Relay receives some kind of maker object with range of groups that doesn't exist. [ this is optimization on 1] Relays receives no indication on the groups not included. These options apply similarly regardless of group Ids being sequential or non-sequential and when things are missing or not produced or so. Does this makes sense ? Happy to add a PR to clarify some of these .
NAME NAME and others, We're not looking for solutions to support non-sequential groups yet - we're still looking to get documentation of the application use case that drives the non-sequential group requirement.
So I know this sounds a bit snarky and I really don't mean it that way but have you read URL ? There also been a bunch of similar things. I sort of work on the assumption chairs are reading the drafts in the WG.
:D Thanks for the bump. Well now I've skimmed it at least far enough to see this: I'll take a closer look. Let's use the metrics repo for any discussion about it's design rather than having it here. Are there other use cases you would like to surface here?
Code change:
latest group(s).  The publisher then selectively transmits objects based on their group membership. <ins> Groups are ordered numerically by their Group ID. </ins> 2.4. A track is a sequence of groups (model-group).  It is the entity

Related discussion:
text: Even if the chairs are reading every draft, not everyone else in the wg is.
So lets imagine the client requests the range 0-10,000, but the publisher only produces group ID's at odd numbers. Is the proposal that each relay in the distribution chain send along 5,000 marker objects to indicate the gaps? That doubles the number of objects sent in response to each subscription. Compare that to a scheme in which groups IDs are sequential and zero markers need to be sent. Surely a marker-less scheme is more efficient in caches and across the wire?
So the use case for fetch has generally been VOD and getting the most recent 15 seconds on live streaming video. Both of these case would make sense to use sequential groups so I don't see this problem. The use case people have brought up about sparse groups are not so much cases where getting the old data makes much sense and also some of them the applications know what the groups are if they wanted them. I'm of course not suggesting a classic VOD use case would use non sequential groups, however it might on scalable codecs, but what I don't see why the relays do anything different if groups have to be sequential or not. Consider a live streaming like use case where groups are sequential and it is stream per group. A relay gets 3 streams coming in to it and on stream A get gets an object in group 1, on stream B it just waiting and has not received anything yet. And on stream C it gets an object from group 3. I probably don't want to have the relays not send objects from group C because they are waiting for something that might arrived from group 2. I'm not understanding what people think they want to do in the relays that requires the groups to be sequential. Overall, we need a design for fetch (lacking a better name for subscribe to old data). If fetch ends up for priority reasons to be delivered over a single stream, then it upstream just puts in order stream. Of course other designs are possible but am not getting what people want and why
My intent was not to provide a solution. I was instead proposing non-normative clarification text on the solution space which applies similarly regardless of the groupId structure.
Code change:
latest group(s).  The publisher then selectively transmits objects based on their group membership. <ins> Groups are ordered numerically by their Group ID. </ins> 2.4. A track is a sequence of groups (model-group).  It is the entity

Related discussion:
text: However, I feel once we resolve fetch api, flow control and limits around handling large absolute ranges, we can revisit to see if groupId are still the issue or not.
Are logging and metrics the motivating use cases for multiple publishers of the same track? Reading the drafts, it doesn't appear like that is the intent, or you could get collisions. If you have any use cases like this, can you share them?
Individual Comment: Based on how SUBSCRIBE is defined now, I think both group IDs and object IDs have to indicate an ordering. If I SUBSCRIBE at a given start group and object, only published objects with groups numerically greater than or equal to that will be delivered. This is similar with SUBSCRIBE_UPDATE specifying the end of a subscription. Object IDs are also numerically comparable for prioritization within their group and priority level. There's text all over the draft implying these comparisons are valid, for example in stream-per-track, group IDs cannot go backwards. If an application wants to pick IDs at random, use a hash scheme, or dole out ranges to multiple publishers where newer things have numerically smaller IDs, then some funny interactions and protocol violations may ensue. No one has publicly specified a use case yet for doing this.
Code change:
Abstract <del> This document defines the HTTP header field "Client-Cert" that allows a TLS terminating reverse proxy to convey the client certificate of a mutually-authenticated TLS connection to the origin server in a common and predictable manner. </del> <ins> This document defines HTTP extension header fields that allow a TLS terminating reverse proxy to convey the client certificate information of a mutually-authenticated TLS connection to the origin server in a common and predictable manner. </ins> 1.

Related discussion:
text: based on .
This PR would address both and
also would
based on some twitter feedback URL
NAME wrote: might be needed/wanted by the backend application (to independently evaluate the cert chain, for example, although that seems like it would be terribly inefficient) and that any intermediates as well as the root should also be somehow conveyed, which is an area for further discussion should this draft progress. One potential approach suggested by a few folks is to allow some configurability in what is sent along with maybe a prefix token to indicate what's being sent - something like Client-Cert: FULL \ \ \Client-Cert: EE \ as the strawman. Or a perhaps a parameter or other construct of {{?RFC8941}} to indicate what's being sent. It's also been suggested that the end-entity certificate by itself might sometimes be too big (esp. e.g., with some post-quantum signature schemes). Hard to account for it both being too much data and not enough data at the same time. But potentially opening up configuration options to send only specific attribute(s) from the client certificate is a possibility for that. In the author's humble opinion the end-entity certificate by itself strikes a good balance for the vast majority of needs and avoids optionality. But, again, this is an area for further discussion should this draft progress.
I would propose a separate header for the chain that would use the structure List value format.
I'd also argue strongly for enabling the certificate chain (even if as a list of sha256 checksums of entities in the chain). End-entity certificates are effectively namespaced by the rest of the chain, so not including the full chain and/or not tying the end-entity cert to the chain are some of the top foot-guns I've found with people using this.
I like NAME suggestion: separating the EE certificate out is sensible. The assumption here is that the terminating proxy validates the signature from the EE cert when establishing the connection. That makes it different. That said, the origin server might need to assemble and validate the chain, so including all the data presented in TLS is likely necessary. (I don't think hashes are as generically useful; space savings can be achieved with header compression, assuming that you use VERY large tables.)
From a header compression standpoint, I suspect we should note that multiple instances of the header will compress more efficiently than a single instance with a long list, assuming there are multiple possible intermediate cert paths.
Code change:
MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Incomplete" header set to true. <ins> If the request includes the "Upload-Complete: ?1" header field and a valid "Content-Length" header field, the client attempts to upload a fixed-length resource in one request.  In this case, the upload's final size is the value of the "Content-Length" header field and the server MUST record the upload's final size to ensure its consistency with future Upload Appending Procedures. </ins> If the client received an informational repsonse with the upload URL, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500

Related discussion:
text: Closes URL I am not super sure about the wording here, but this is a start. The sentences seem quite long and maybe the rules could also be expressed in fewer words.
I wonder if it is also possible to expose this final upload size in the response to Offset Retrieving Procedures. I don't think we can set in the HEAD responses because that would indicate that the server already has this amount of bytes, which is not correct.
If the client acknowledged its final upload size at any point ( + ), it should still know it in the future, so I don't think we need a way for the server to echo it in the offset retrieving response. If the server disagrees with the client, then someone's data representation has changed, and we shouldn't continue the upload anyway.
Looks good. Wondering if these could be reduced to SHOULDs though. It wouldn't really affect interop if the server didn't implement this.
Fair point, let's leave such functionality out of the draft. While it is true that clients usually won't really notice if the server does or does not support this, I think we can be stricter here and require this additional safety catch here. It will help to create a more standard landscape of resumable upload servers. Unless there is something against requiring this, we can keep it a MUST IMO.
I just updated this PR to use the Upload-Complete header as agreed on in
The arguments for SHOULD are: This check requires additional code and complexity. MUSTs are situations that a minimal implementation has to handle anyway and we are just strict about how to handle them. For people using chunked uploads, this check is only useful if the last chunk is interrupted which is sort of an edge case. Maybe we can generalize the check if we adopt ranged PATCH. I don't have a strong opinion on this, so either way is OK with me.
When the server receives a series of appends: If the offset+length is inconsistent, the server should reject the upload.
To clarify; Is what you are saying here that the provided during the upload creation procedure should act as the total size of the file, similar to Upload-Length in tus1x?
I am not sure if we want this. I ran into this exact problem because your NIOResumableUpload implementation uses this logic (see URL). We currently have the header to indicate the completeness of the upload.
Code change:
MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Incomplete" header set to true. <ins> If the request includes the "Upload-Complete: ?1" header field and a valid "Content-Length" header field, the client attempts to upload a fixed-length resource in one request.  In this case, the upload's final size is the value of the "Content-Length" header field and the server MUST record the upload's final size to ensure its consistency with future Upload Appending Procedures. </ins> If the client received an informational repsonse with the upload URL, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500

Related discussion:
text: Based on this information, the server can determine if an upload is complete or not without relying on . Adding to the upload logic would mean that we have two indicators for upload completeness, which could potentially disagree with each other. Personally, I think we should not use to determine the upload's completeness and only determine it based on whether the client set in a successful request. For each Upload Creation Procedure or Upload Appending Procedure, the should be set to the number of bytes that the client wants to send in this individual procedure. For example, if you want to transmit 100 bytes in the first POST request, set (or not if you use ). If you want to transmit 200 bytes in the following PATCH request, set . If you want to finish the upload then, set and the upload is considered complete with its 300 bytes of content.
The issue in NIOResumableUpload was a bug, not how this is supposed to work. Offset + Content-Length = final upload size when the upload is complete, and if the client has told the server about the final size, it shouldn't be allowed to change its mind.
Echoing what Guoye said, should not determine the upload's completeness, but if an request has a , then the server can expect and enforce the final upload size based on that . This prevents a client from appending more bytes to their upload than the server anticipated. Ex. Client starts an upload , Server expects a final upload size of 100 bytes Upload is interrupted, offset-retrieving, server sends Client now tries to append an extra ~10GB Client sends , , Server can reject this request
I see, thanks for the explanation. That makes sense. Basically, in conjunction with let the server know the final upload size, which should not be changed
How does that work if the last append has in conjunction with . The Content-Length needs to match the number of bytes in the append message.
Final size = upload-offset + content-length if the upload is complete
So the first ever request with Upload-Incomplete: ?0 and content-length sets the expected final size. Every other request must have a content-length less than that value?
Yeah, once the final length is determined, it cannot be changed by subsequent requests.
OK I think that makes sense but it's not obvious from the spec. We should try and make it more accessible with some new or different text.