jiebi/CodeConvo huggingface dataset:
Code change:
Reason Phrase: Provides the reason for subscription error. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: The catalog draft pushes the work to the URL definition, and the URL definition does the heavy lifting but that is where this type of stuff should be
NAME Just to clarify that when you say "bitwise compare" you also mean exact matching the entire namespace field from announce to the one in subscribe?
I would like to decouple the media layer from the transport layer. A tool like ffmpeg should be able to generate a MoQ catalog without knowing the namespace it will be served from, much like a tool like zip should be able to generate a file without knowing the path it will be stored. HLS/DASH provides this functionality with absolute or relative paths. If the playlist contains relative paths, then it can be served from any HTTP host/path provided the segments are served from the same host/path. If you want to decouple the two (ex. application serves playlist, CDN serves segments), then you use absolute URLs. To accomplish the same thing, the namespace should be optional in a MoQ catalog. This would mean media tracks are served from the same namespace as the catalog: whatever that might be.
To expand further, I think that MoQ broadcasts should be namespace agnostic: a broadcast ingested with namespace XXX is NOT required to be delivered as XXX. I understand where Cullen is coming from: an application like WebEx can use the same namespace for contribution/distribution because it controls the full pipeline. The application has all of the information required for all future routing/identification so it can set it on the first hop and expect any relays to blindly proxy. However, for a more generic or distributed system, this is not true. A client like OBS knows nothing about how the broadcast will eventually be distributed, fanned out, or the requirements of potentially multiple CDNs that might be used, nor will those requirements be the same between vendors (present or future). So I don't think we should require that input namespace == output namespace. In the HTTP world, this would be like requiring that all HTTP paths match the origin. It's quite restrictive and just means a CDN needs find another way to perform routing via a custom header/parameter. I propose we emulate the HTTP model where there's non in-band notification that a path/namespace was modified. An origin might serve and a CDN might decide to serve it as .
Code change:
Reason Phrase: Provides the reason for subscription error. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: Any namespace remapping from XXX -> YYY is business logic and not signaled over the wire. If you don't want any remapping, then that's a business agreement between you and the CDN, wherein you may need to encode namespaces in a vendor-specific way.
I think we have agreement on that from past discussions. Can the catalog draft have a mechanism to inherit the namespace for tracks from somewhere else, like a relative URL in an HTML page? I'm not sure this is relevant for how relays perform matching between SUBSCRIBE and ANNOUNCE though. The only available information in announce is the namespace.
Yeah I'm probably rambling about something unrelated. But in order to support namespace remapping, the downstream ANNOUCE/SUBSCRIBE won't necessarily match the upstream ANNOUCE/SUBSCRIBE.
This is a useful property. I opened to address this issue and PR URL to fix it.
So if the input full track name does not equal output full track name ( for some version of matching the two ), what is it that tells the relays there is mapping between the two. I'm not objecting to some other way to do this, I just don't understand what it is that tells the relays to do that. Keep in mind relays do not need to read the catalog.
To clarify the "bitwise compare" ... yes I mean exact matching the entire namespace field from announce to the one in subscribe? If the namespace was utf-8 or even a url restricted utf-8, that would match. I am just aruging that a relay should not have to verify every string is a valid utf-8 string, it should just match the bits.
HTTP proxies will not modify the path by default. A downstream request for arrives, there's some rules to match it to a backend, and then an upstream request for is sent. A simple MoQ relay would work the same way. However, you can configure a HTTP proxy to perform special behavior, including rewriting the path. Note that a the HTTP server does rewrite the HLS/DASH playlist provided they are using relative URLs since both the playlist and segment would match the same prefix rules. For example, here's a simple nginx configuration: I would allow the same exact thing for MoQ, but of course use our terminology instead. I think a key improvement with MoQ over HTTP is actually the namespace/name tuple.
Code change:
Reason Phrase: Provides the reason for subscription error. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: I propose: A relay SHOULD NOT change the track name. That means a producer can make a track called "video_480p" and reference it in a catalog, inheriting the current namespace. A relay MAY change the track namespace when negotiated out-of-band. It's RECOMMENDED that an application support being served from arbitrary namespaces, including using relative namespaces when tracks reference each other. Basically, the track name is controlled by the application (encoder/decoder) while the track namespace is controlled by the relay (hop-by-hop). This makes a ton of sense if the namespace is primarily meant for routing (critical for relays), and it allows relays to do stuff like encode the route or a unique ID into the namespace itself.
Going back to the original issue Alan posted (if I understand it correctly), I think we need to support out-of-band negotiation given the nature of fanout. Maybe we can provide something in-band but it won't always be possible. For example, an OBS client sends: In theory, the server could reply with the information required to watch the broadcast (final hop), including any remapping along the way: But this gets really messy when you factor in auth, multiple CDNs, multiple edge hosts, and just the nature of ingest being on the other side of the pipe from distribution. In this example, I think the application has to negotiate with Akamai on how they need to ingest and how they need to egress. I'm not opposed to using extensions to make this mapping explicit though. It would be cool to have a scheme that defines routing/authentication using globally unique namespace, kind of like a decentralized CDN. But it shouldn't be required as part of the base protocol and there's a LOT of sharp edges to figure out.
Individual Comment: My opinion is that anything that does this kind of rewriting is out-of-band, at least for now? For a completely generic relay input=output.
Yes. I opened issue URL to address this and PR URL to fix it. I really like the flexibility that relative names bring. We know this works at scale for current web and media delivery across disparate systems. I'd hope that relative track names are the normal mode of operation. We should allow absolute namespaces in catalogs to allow mixing between sources, however I think this will be an edge case. By default, a relay SHOULD NOT modify the track namespace or track name.
Code change:
Reason Phrase: Provides the reason for subscription error. <ins> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Related discussion:
text: However, what a distribution network does within the bounds of its own network is up to it. As it restores the original namespace and name at its boundaries (to match the catalog), then external systems cannot tell and distribution intent is preserved. Additionally, there will be business logic and distribution agreements between CDNs, coordinated by the content distributor, to rewrite namespaces between networks. Such namespace rewriting is common between networks and should not be prohibited. Here's how I envisage a scalable solution working. When a twitch user wants to use OBS to publish, they would log in to URL and authenticate against the Twitch CMS. It would vend them two URLS: a connect and publish URL a playback URL to share with their followers The OBS client would use this to The client then publishes twitch/kixelated/catalog, a track which describes two relative tracks - audio and video. The playback client connects to URL and subscribes to premiergaming/gamer34/catalog. After parsing the catalog it subscribes to The Fastly relays have been configured by Twitch, out-of--band, so that when they go forward to origin (which is Akamai), they do a namespace rewrite to The subscriptions make their way back to the OBS instance. The encoder prepare Moqt Objects with in their headers. As these are received by Fastly, business logic rewrites them to , caches them as such and they are delivered to the client.
As per the discussions in person, it is more nuanced than renaming few bits in the header. It might break e2e encryption /auth for example or reencryption in some cases. As this is very application specific, one needs to be take into consideration the costs as it may not be just rewrite few bits in and out of network edges. The more appropriate or clearer framing may be - whenever the name changes, it is ,in a way, republishing the content with a new name ..
just to note, the network wouldn't have access to the catalog
Conclusion is that we'll use exact matching like specified in
Thanks for the update I'm not sure how to wordsmith this but +1 to what it is saying.
Code change:
TLS authentication of the server and HTTP request signing using a secret key. <ins> arch-chain illustrates the communication between different workloads. Two aspects are important to highlight: First, there is a need to consider the interaction with workloads that are external to the trust domain (sometimes called cross-domain).  Second, the interaction does not only occur between workloads that directly interact with each other but instead may also take place across intermediate workloads (in an end-to-end style). </ins> 3.2.2. In a typical system of workloads additional information is needed in

Related discussion:
text: Updated figure in
NAME I made a slight update to remove the word authentication in the text since authentication is one specific type of interaction, there may be many others. This might also be a good place to introduce "context" that is propagated (although that seems to be more a topic of the next section
Code change:
URN Namespace for IETF Use [3] somehow.  Or maybe nothing.  Or maybe something else. <del> TODO: "tth" and maybe "oth" claim in JSON Web Token Claims Registry [4] </del> <ins> TODO: "tth", "wth" and maybe "oth" claim in JSON Web Token Claims Registry [4] </ins> 7.1.

Related discussion:
text: Adds 'wth' claim to WPT to bind WPT to WITs.
NAME please also update the relevant IANA section so we don't forget.
I realize I missed a meeting but why did we add this?
What's the threat? Different WITs with the same cnf key and a compromised middle thing?
I just don't see it...
Iss in the WPT is even less useful with this too.
Yes, currently we don't have strong binding between WPT and WIT. Only the fact that . I don't understand the "even less" part but I see that this is somewhat duplicated now.
Should be: WIT sub == WPT iss. And just to state it explicitly: people are likely to extend the WIT with various "junk" (i.e., policy) and that wouldn't be covered otherwise.
Code change:
The ability to selectively disclose a subset of these claims depending on the Verifier becomes crucial to ensure minimum disclosure and prevent Verifiers from obtaining claims irrelevant for <del> the transaction at hand. One example of such a multi-use JWT is a verifiable credential, a tamper-evident credential with a cryptographically verifiable authorship that contains claims about a subject.  SD-JWTs defined in this document enable such selective disclosure of claims. </del> <ins> the transaction at hand.  One example of such a multi-use JWT is a verifiable credential, a tamper-evident credential with a cryptographically verifiable authorship that contains claims about a subject. SD-JWTs defined in this document enable such selective disclosure of JWT claims. Similar to the JWT specification on which it builds, this document is a product of the Web Authorization Protocol (oauth) working group. However, while both JWT and SD-JWT have potential OAuth 2.0 applications, their utility and application is certainly not constrained to OAuth 2.0.  JWT was developed as a general-purpose token format and has seen widespread usage in a variety of applications.  SD-JWT is a selective disclosure mechanism for JWT and is similarly intended to be general-purpose specification. </ins> In an SD-JWT, claims can be hidden, but cryptographically protected against undetected modification.  When issuing the SD-JWT to the

Related discussion:
text: for add a bit more context/background to the intro about the indented general applicability of SD-JWT and the relation to JWT and the OAuth WG
Code change:
purposes, it might be advantageous to split lists into multiple instances. <del> The first certificate in the list SHOULD directly certify the end- entity certificate provided in the "Client-Cert" header; each following certificate SHOULD directly certify the one immediately preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that the server is known to possess any omitted certificates. However, for maximum compatibility, servers SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings. </del> 2.4. This section outlines the applicable processing rules for a TLS

Related discussion:
text: attempt NAME "simple alternative" in to say the chain is in the same order as it appears in TLS rather than copying the language from TLS
There's a bunch of text in the draft about putting the certificate chain in the right order. This tries to crib from TLS and ends up being somewhat tricky to get right as TLS has a bunch of carefully worded and - frankly - ambiguous rules. As a simple alternative, how about we just state that the certificates need to appear in the same order as the client sent them in TLS.
Makes sense. Will look at adjusting the text accordingly.
I think this is a bit more fundamental than just the order. It's really a question of whether this is a certificate path, or a pile of input certificates to run verification over. That is, either: The origin runs path building, taking the unordered/unverified pile of input certificates from the header, in TLS order. The proxy runs path building and passes the result in the header. The origin assumes a path has been built and is merely applying ACLs based on some aspect of the resulting path. A mismatch here could result in security issues. For instance, suppose the origin wants to only allow chains issued by intermediate certificate I1 to access . If the header means (1) but the origin expects (2), this ACL is trivially bypassable: Client has a certificate chain EE -> I2 -> CA. Client connects to proxy and sends {EE, I2, CA, I1}. (Or perhaps {EE, I2, I1, CA}. Or whatever else. Different verifiers are differently permissive about path-building. Perhaps it omits I2 altogether and the path-builder picks it up some other way.) Even if the proxy runs certificate verification, a path-building verifier will build the EE -> I2 -> CA path and just consider I1 as a random unused certificate. , per the TLS order rule, contains {EE, I2, CA, I1} Origin server checks this and concludes "aha, this was issued by I1 and can access the resource". Conversely, the semantics are (2), the proxy needs to have enough information to validate the certificate, up to a valid trust anchor for the application. If you all intended to punt that to the origin, that's a different protocol.
Code change:
purposes, it might be advantageous to split lists into multiple instances. <del> The first certificate in the list SHOULD directly certify the end- entity certificate provided in the "Client-Cert" header; each following certificate SHOULD directly certify the one immediately preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that the server is known to possess any omitted certificates. However, for maximum compatibility, servers SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings. </del> 2.4. This section outlines the applicable processing rules for a TLS

Related discussion:
text: If the spec says TLS order, it's implicitly saying the interpretation is (1). But as that leaves a security-critical check to the origin, it should be explicit about this. Also, as it leaves all certificate validity to the origin, it'd need to further define an error-handling story to properly tell the client the certificate was invalid. But I know of no client that uses HTTP-level errors to clear client certificate decisions, only TLS alerts. I think (2) may be a more robust/compatible.
It is definitely 1. You do 2 and you don't need this client-cert-chain field at all. That doesn't mean that a proxy can't be configured to do the work and pass the info along. But one of the two needs to be in the hook for enforcement. A consequence of 1 is that alerts at the TLS layer won't be used to signal errors, aside from those that the proxy detects (or has to, like if the signature is invalid). That is ok, mostly. The main protocol issue here that might be a problem is validation of signatureschemecert. I can't see how failing to validate that would be a significant problem though.
In on the PR that introduced the chain I was aiming for 2. But eventually relented to MT. Some additional considerations about the security implications are likely warranted though.
I see. If it's (1), that should probably be clearer in the draft. That also means the draft needs to define an error-signaling scheme. Moreover, if the proxy doesn't then translate that error into TLS alerts, we'd need changes in clients for servers relying on this to work right. I'll file a bug.
I ran into real reservations as I looked at making this change. I still don't like pushing the trust chain validation to the origin. For many reasons. The proxy also has no means of signaling to the client which trust anchors the origin is okay with. The current text is somewhat ambiguous about what goes in Client-Cert-Chain but I think that's actually better than saying it has to be same as in the TLS handshake. I dunno, I think I might raise the question of WTF actually goes in Client-Cert-Chain at the next interim or real meeting.
At the last virtual interim (in May/June yikes!)
Code change:
purposes, it might be advantageous to split lists into multiple instances. <del> The first certificate in the list SHOULD directly certify the end- entity certificate provided in the "Client-Cert" header; each following certificate SHOULD directly certify the one immediately preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that the server is known to possess any omitted certificates. However, for maximum compatibility, servers SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings. </del> 2.4. This section outlines the applicable processing rules for a TLS

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:
SUBSCRIBE_RST (see message-subscribe-rst). A relay MUST not reorder or drop objects received on a multi-object <del> stream when forwarding to subscribers. </del> <ins> stream when forwarding to subscribers, unless it has application specific information. </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription

Related discussion:
text: This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.
Code change:
SUBSCRIBE_RST (see message-subscribe-rst). A relay MUST not reorder or drop objects received on a multi-object <del> stream when forwarding to subscribers. </del> <ins> stream when forwarding to subscribers, unless it has application specific information. </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription

Related discussion:
text: Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)
Code change:
Abstract <del> An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. </del> <ins> HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers.  In practice, clients are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy. </ins> <del> This specification defines an extensible and configurable set of HTTP request header fields, colloquially known as Client Hints, to address this.  They are intended to be used as input to proactive content negotiation; just as the Accept header field allows user agents to indicate what formats they prefer, Client Hints allow user agents to indicate device and agent specific preferences. </del> <ins> This specification defines a response header, Accept-CH, that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." It also defines an initial set of Client Hints. </ins> Note to Readers

Related discussion:
text: Suggested elaboration / re-focusing in the introduction to clarify how CH fits into things.
CI failed due to rfc-URL DNS failure; should be transient.
Feedback addressed, I think.
Thanks for working on this! A few comments...Looks great, thanks Mark! Based on recent direction and discussions, the sections that mention "defines initial set of hints" and reference to User-Agent header may need to be updated, but we'll tackle that in a separate thread.