jiebi/CodeConvo huggingface dataset:
Code change:
problematic and presents possible mitigations, or where unfairness is desirable. <del> TODO: Discuss if we should add a signal that mitigates this issue. For example, we might add a SETTINGS parameter that indicates the next hop that the connection is NOT coalesced (see https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99). </del> 10.1. When an intermediary coalesces HTTP requests coming from multiple

Related discussion:
text: The I-D contains the following TODO we might add a SETTINGS parameter that indicates the next hop that the connection is NOT coalesced (see URL). I'd like to track that discussion here. Namely, with all the changes in the meantime, does NAME think that there is still a problem that needs fixing? OR can we close with no action?
I don't think anything additional is needed. We've got the two standard header options to indicate an intermediary is involved, that was the main point of the original discussion in Singapore IIRC. I think this won't matter all that much in practice, given warmed up edge-to-origin connections, pops being able to serve cached resources in between, etc. Origin owners really concerned with performance will know if their setup is coalescing or not (then the question is if origin server software allows tweaking prioritization behavior, but that's a general concern). CDN owners seeing bad origin behaviour will probably just overwrite the priority information instead of forwarding in practice. In short, I think the current text should suffice here, as I don't think many servers would support switching to RR when seeing an explicit "warning: coalescing intermediary" signal either way.
Thanks NAME In that case I've created to simply remove the TODO text, which will act to resolve this issues.
Code change:
with a certificate, a client presents its X.509 certificate RFC5280 and proves possession of the corresponding private key to a server when negotiating a TLS connection or the resumption of such a <del> connection.  In contemporary versions of TLS RFC8446 RFC5246 this requires that the client send the Certificate and CertificateVerify messages during the handshake and for the server to verify the </del> <ins> connection.  In contemporary versions of TLS TLS TLS1.2 this requires that the client send the Certificate and CertificateVerify messages during the handshake and for the server to verify the </ins> CertificateVerify and Finished messages. <del> HTTP/2 restricts TLS 1.2 renegotiation (RFC7540) and prohibits TLS </del> <ins> HTTP/2 restricts TLS 1.2 renegotiation (RFC9113) and prohibits TLS </ins> 1.3 post-handshake authentication RFC8740.  However, they are sometimes used to implement reactive client certificate <del> authentication in HTTP/1.1 RFC7230 where the server decides whether </del> <ins> authentication in HTTP/1.1 RFC9112 where the server decides whether </ins> to request a client certificate based on the HTTP request.  HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated

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:
with a certificate, a client presents its X.509 certificate RFC5280 and proves possession of the corresponding private key to a server when negotiating a TLS connection or the resumption of such a <del> connection.  In contemporary versions of TLS RFC8446 RFC5246 this requires that the client send the Certificate and CertificateVerify messages during the handshake and for the server to verify the </del> <ins> connection.  In contemporary versions of TLS TLS TLS1.2 this requires that the client send the Certificate and CertificateVerify messages during the handshake and for the server to verify the </ins> CertificateVerify and Finished messages. <del> HTTP/2 restricts TLS 1.2 renegotiation (RFC7540) and prohibits TLS </del> <ins> HTTP/2 restricts TLS 1.2 renegotiation (RFC9113) and prohibits TLS </ins> 1.3 post-handshake authentication RFC8740.  However, they are sometimes used to implement reactive client certificate <del> authentication in HTTP/1.1 RFC7230 where the server decides whether </del> <ins> authentication in HTTP/1.1 RFC9112 where the server decides whether </ins> to request a client certificate based on the HTTP request.  HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated

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:
Some Verifiers may systematically fetch all Transparent Statements using the CWT_Claims Subject and assess them alongside the Transparent Statement they are verifying to ensure freshness, <del> completeness of evidence, and the promise of non-equivocation. </del> <ins> completeness of evidence, and Non-equivocation. </ins> Some Verifiers may choose to subset the collection of Statements, filtering on the payload type (Protected Header "3"), the CWT <del> (Protected Header "13") Issuer claim, or other non-opaque properties. </del> <ins> (Protected Header "15") Issuer claim, or other non-opaque properties. </ins> Some Verifiers may systematically resolve Issuer DIDs to fetch the latest corresponding DID documents.  This behavior strictly enforces

Related discussion:
text: Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences
Code change:
resource.  This way, the integrity of an individual request can be protected. <del> 15. </del> <ins> 16. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This

Related discussion:
text: splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!
Code change:
resource.  This way, the integrity of an individual request can be protected. <del> 15. </del> <ins> 16. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This

Related discussion:
text: The definition of upload creation requests allows the client to include the entire file, some file data or no data at all. While we provide this flexibility, we don't give guidance on when which approach is best suited. This PR adds this missing piece and explains how an optimistic client can attempt to upload the file in one request and how a careful client uses a separate request for creating the upload. In addition, it also mentions how to transparently upgrade to resumable uploads, which wasn't explained in detail before. Let me know if you have any feedback on this.
Are "Optimistic Upload Creation" and "Upgrading To Resumable Uploads" the exact same way? Maybe the 3rd way could be checking first before uploading?
The way they are described right now they are similar, yes. In theory, an optimistic upload creation can also be used where the client doesn't upload the entire file, but just a large part of it (think 500 MB of a 10 GB file). When upgrading a non-resumable request to a resumable upload, this act of division is not allowed. But I am not sure if we should go into that much detail here. If not, then we can merge these two sections. Upload limits are a good point! With the careful upload, the client also knows the limits before sending the first PATCH request. The optimistic client must be prepared to receive a 104 response with limits that it has to adapt to. We can mention that a careful client may also send an OPTIONS request before hand if it deems that necessary.
I think upload-limit can just be enforced on the server side. If it sends a 104 and a 5xx response, the client would automatically retry. We have deployed a client-side implementation that is not aware of the upload-limit header field.
Thanks for all of your comments! I updated the PR to put the section about upgrading to resumable uploads under the optimistic upload creation since they are similar. I also added a brief mention of Upload-Limit and shortened the text a bit. Let me know if you think the text needs more adjustments.
Just a minor nit. Otherwise I think this is a very good addition and agree with NAME that we should add some text with regards to the .
Code change:
resource.  This way, the integrity of an individual request can be protected. <del> 15. </del> <ins> 16. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This

Related discussion:
text: Proposal for optimistic: The client needs to adapt to the header provided in the intermediate response and fail the request if the file is larger than the maximum allowed size. Proposal for Careful: The client can use the header provided in the to verify that the file is allowed to be uploaded before sending any data.Some editorial suggestions, but one big question: What is the material difference between the first and third strategy? Could these be the same strategy?
Code change:
end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. <ins> Objects within a group are ordered numerically by their Object ID. </ins> 2.2. A subgroup is a sequence of one or more objects from the same group

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:
end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. <ins> Objects within a group are ordered numerically by their Object ID. </ins> 2.2. A subgroup is a sequence of one or more objects from the same group

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:
end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. <ins> Objects within a group are ordered numerically by their Object ID. </ins> 2.2. A subgroup is a sequence of one or more objects from the same group

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:
end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. <ins> Objects within a group are ordered numerically by their Object ID. </ins> 2.2. A subgroup is a sequence of one or more objects from the same group

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:
end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. <ins> Objects within a group are ordered numerically by their Object ID. </ins> 2.2. A subgroup is a sequence of one or more objects from the same group

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.