jiebi/CodeConvo huggingface dataset:
Code change:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

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:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

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:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

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:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

Related discussion:
text: Add some normative text and requires both client and server to send their role. I can also see the argument for removing this entirely, but it's in the current draft, so if we're going to keep it, I'd like to define it better.
Having a flag in SETUP doesn't stop from someone sending unsupported messages. A faulty implementation or intentionally malicious endpoint can send unsupported messages. A receiver should be prepared to handle unsupported messages regardless.
Right, an implementation is still going to crash if it receives an unsupported message, but there's a difference between signaling that upfront and yolo. A one-sided implementation will look something like this: The purpose of the ROLE parameter is to avoid accidentally triggering that default, as it will close the connection. For example, I absolutely want to have a way to get per-viewer feedback: a track produced by each viewer. Without this ROLE field, a viewer might cause a crash if it sends an to the server, or the server might cause a crash if it sends a to the viewer. It will only work if both endpoints explicitly flag . The only alternative to the ROLE field is to implement the entire protocol, but that's unnecessarily restrictive. Take HTTP for example, it's almost taken for granted that an implementation is for a client or a server, but rarely both. I imagine that will also be the case with MoQ with the sole exception of relays. OBS is not going to implement subscribing, and VLC is not going to implement publishing. Even in my URL library that does support both modes, I ran into a deadlock because of ROLE=both. My publisher was not consuming ANNOUNCE messages because it was not expecting them. Explicitly signaling ROLE=publisher would have prevented this, making it a protocol violation to send half of the messages in the draft.
A resilient implementation state machine will be something like Since for unsupported messages, you don't want a protocol action as it will be DOS surface, for example. Also, Many of the conferencing examples will mostly always be send and receive by default. Our client for example does pub and subscribe always. I personally feel the implementation constraints are resolvable and I feel still unconvinced for a ROLE parameter.
Heh, please don't do that. This is exactly why we have version/extension negotiation; not supporting a message after negotiating it is a protocol violation.
Code change:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

Related discussion:
text: Otherwise, my endpoint has to assume that your endpoint could ignore messages, and the MoQ draft in general, on a whim. Just tell me that you don't support ANNOUNCE via ROLE. Otherwise I would have to send an ANNOUNCE, start a timer, and guess that no OK/ERROR means no support? Probing for support is miserable. You close the connection on an unsupported message. Just send ROLE=both then. Not every conferencing is bidirectional though, for example clubhouse-style. At Discord we also have a dedicated connection for screen sharing (don't ask) and a very explicit role=publisher vs role=subscriber flag.
I don't think this is necessarily true. Without ROLE, you can still choose to only implement half the protocol and reject the messages you don't support. Every client has to be built to be resilient to arbitrary incoming messages. It can't break because the other side said their role was subscriber but then they send you an ANNOUCE. Therefore sending an upfront role seems like a promise to behave in a certain way. A system that relies on promises to not break will be brittle. I agree that ROLE seems superfluous.
I want publisher and subscriber support to be optional. That way it's only necessary to implement half of the draft on many cases. A CDN distribution edge would be one such situation. In fact, it's a hardening measure to ensure the edge cannot receive a ANNOUNCE which might otherwise cause a vulnerability. And generally speaking, if something is optional, then it should be negotiated. Otherwise you end up with Schroeder's extension. Silently ignoring unknown/unsupported messages is just terrible protocol design and it's s far better to close the connection with a protocol violation instead. That's the point of the ROLE parameter. But yeah let's chat about it on Wed.
Individual Comment: Every implementation has to have that switch statement and some not-crash action when it receives a message it doesn't support. Some logical options are: Ignore the message Send the corresponding error message (eg SUBSCRIBEERROR, ANNOUNCEERROR) with an error code like "not-implemented" Close the entire connection I think the value of ROLE is that it gives a consistent behavior early in the life of the session. If I want to send subscribes and the peer says they are subscriber only, I close the connection.
Code change:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

Related discussion:
text: But I still have to have the switch statement because of broken or malicious peers. The MUST in this PR can be improved by explaining what happens when you don't like the value you see, or the peer sends messages inconsistent with its advertised role.
In that case the peer will close the connection since it knows that it is subscribe only implementation and the role in the setup is supreflous
This is the type of things where I don't think we need it but it does not break anything, is not a big deal to implement, and does not hit performance. Given other people feel strongly this is needed, I can easily live with this. If this helps us get to consensus, I'm fine with adding it. I think the rewrite makes things clearer than they were before.
Discussion concluded that supporting this was not that difficult and it's a clear signal of what's supported, to so AI is to fix up the PR to clarify behavior.
Sec 6.1.1.1 specifies client sending or ROLE, and says nothing of server-sent. I guess server-sent ROLE is not needed, but maybe we should fail if it is sent?
I filed about the role parameter. The client doesn't actually know what the server intends to do. The server should be able to reply with its functionality, which might be a subset of what the client can support.
The SETUP message contains a ROLE parameter. In the current draft, the client specifies the value, indicating if the client will send data (0x1), if the server will send data (0x2), or if both endpoints will send data (0x3). A conferencing client supports the ability to send and receive media, and would always send role=0x3 because it supports both functionalities. However, it's unaware of the server functionality, and the server has no way of informing the client if it intends to send media. This matters because a generic client needs to know if it shows a black screen and/or should send a SUBSCRIBE message (ex. for /catalog). I propose that both endpoints send the ROLE parameter: 0x1 = publisher, 0x2 = consumer, 0x3 = both. This gives the server the ability to specify its own functionality.
Wondering if we even need Role in the first place .. can it be changed mid-session ?
Code change:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

Related discussion:
text: Say the use-case Participant in media conference joins as subscriber only since he is driving and want to listen in Then at some point mid session , he wants to contribute and he now becomes as publisher and subscriber what is the expected flow in this case ?
Current draft doesn't really explain what ROLE parameter is for, only that client needs to send it - what was original idea? Why not just always allow everyone to send and receive data?
It seems a better way to control if you can send and receive might just be if the client has the appropriate auth tokens for each role. I lean towards remove this if we don't need it, but if we need it, I have would be fine with a design where the client says which roles it is capable of , and the server response contains which roles it is allowed to do.
I think ROLE is good for negotiating half-functionality. If the remote endpoint cannot send media (ex. player), then sending a SUBSCRIBE is invalid. If the remote endpoint cannot receive media (ex. OBS), then sending a ANNOUNCE/OBJECT is invalid. This removes a burden on implementations, as most will only care about specific role. NAME brings up a good point. If an endpoint could switch roles, then it should advertise full functionality. That would include publishing an empty catalog which it can append it later when it wishes to publish tracks.
I don't think I seem much use for the Role - it seems like something the application would know at a higher layer. But I have no objection to including it if others do see a need for it. It's not like it makes life harder for applications that don't use it.
If the ROLE is used to enforce the half-functionality, then it needs to be clear what should be done when invalid message is received. Sending a GOAWAY? Sending a generic error message? Does the connection need to be terminated? I think most of the time, application will just choose the full functionality in case of role switching on the fly and avoid the invalid response code(just ignore the invalid message).
Oh hey, I found a good use-case for ROLE. If my client connects with ROLE=publisher, then the server knows that it should not send ANNOUNCE messages. The messages are useless and actually triggered a deadlock in my broadcaster, since the application was not reading them and overflowed the receive channel.
Code change:
6.9. <del> A publisher issues a "SUBSCRIBE_RST" message to all subscribers </del> <ins> A publisher issues a "SUBSCRIBE_RESET" message to all subscribers </ins> indicating there was an error publishing to the given track and subscription is terminated. <del> The format of "SUBSCRIBE_RST" is as follows: </del> <ins> The format of "SUBSCRIBE_RESET" is as follows: </ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req.

Related discussion:
text: The same would be true with the reverse; a subscriber will not be able to process any SUBSCRIBE messages. I like the ability to specify half-functionality. At the very least the library should support half-functionality (ex. automatically reply with ANNOUNCE_ERROR) but it's even better if it's enforced by the protocol.
LGTM me. Ship it!I wonder if it helps to discuss the role of role parameter during authors call for a short bit NAME
Code change:
The <del> is comprised of, at a minimum, the request method and target URI used to retrieve the stored response; the method determines under which circumstances that response can be used to satisfy a subsequent request.  However, many HTTP caches in common use today only cache GET responses, and therefore only use the URI as the cache key, forwarding other methods. </del> <ins> is the information a cache uses to select a response and is comprised of, at a minimum, the request method and target URI used to retrieve the stored response; the method determines under which circumstances that response can be used to satisfy a subsequent request.  However, many HTTP caches in common use today only cache GET responses, and therefore only use the URI as the cache key, forwarding other methods. </ins> If a request target is subject to content negotiation, the cache might store multiple responses for it.  Caches differentiate these

Related discussion:
text: This might be obvious, but the -caching draft never concretely says that a cache key is the information that a cache uses to select a single cached response. It just : "The cache key is comprised of, [...]"
LGTM
Code change:
Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0". <del> If the number of characters appended in the previous step is greater than 12, fail serialisation. </del> Append "." to output. If input_decimal's fractional component is zero, append "0" to output. <del> Else if input_decimal's fractional component has up to three digits, append them represented in base 10 (using only decimal </del> <ins> Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal </ins> digits) to output. <del> Otherwise, append the first three digits of input_decimal's fractional component (represented in base 10, using only decimal digits) to output, rounding the final digit to the nearest value, or to the even value if it is equidistant. </del> Return output. 4.1.6.

Related discussion:
text: Round to three decimal places first, then check the domain, then do all the actual serialising. It's potentially not very l13n-friendly; feel free to change "decimal point" or "to the left" etc., if something is more appropriate.
... still isn't right, as Kari noticed. E.g., a value of won't get rounded to .
Step 1 of all serialisation algorithms could be related to sanitising/casting/failing-on noncanonical data. Turn your random number into a Decimal, including rounding to three digits. Fail if it's or no worries from here on Actually, Key, Integer, String, Token, Byte Sequence, and Boolean already do this, so Decimal is the only scalar type that doesn't.
With the current algorithm, if it is allowed as input, -0.0004 will get serialized as , rather than . corrects that as well.
Code change:
(F) The client now possesses an access token to access the protected resource in Domain B. <del> 2.2. </del> <ins> 2.3. </ins> This specification does not define authorization server discovery.  A client MAY contact the resource and leverage the WWW-Authentication response (see section 3 of RFC6750), maintain a static mapping or use other means to identify the authorization server. <del> 2.3. </del> <ins> 2.4. </ins> Once the authorization server is identified the client performs token exchange as defined in RFC8693 with its own authorization server in order to obtain an authorization grant as specified in section 1.3 of RFC6749. <del> 2.3.1. </del> <ins> 2.4.1. </ins> The parameters described in section 2.1 of RFC8693 apply here with the following restrictions: <del> 2.3.2. </del> <ins> 2.4.2. </ins> An authorization server SHOULD deny the request on an unknown resource or audience.  In cases where federation to any

Related discussion:
text: Added use cases. We may want to refine these, or move them into a non-normative section later.