jiebi/CodeConvo huggingface dataset:
Code change:
Context: Empty <del> Length: Four bytes </del> <ins> Length: Eight bytes The value of the exporter is split into two four-byte values.  The first four bytes are used for the "SETTINGS_HTTP_CLIENT_CERT_AUTH" value, while the following four bytes are used for the "SETTINGS_HTTP_SERVER_CERT_AUTH" value. </ins> <del> The resulting exporter is converted to a setting value as: </del> <ins> Each is converted to a setting value as: </ins> That is, the most significant bit will always be set, regardless of the value of the exporter.  Each endpoint will compute the expected <del> value from their peer.  If the setting is not received, or if the </del> <ins> values from their peer.  If the setting is not received, or if the </ins> value received is not the expected value, the frames defined in this <del> document SHOULD NOT be sent. </del> <ins> document SHOULD NOT be sent in the indicated direction. </ins> 2.2. When both peers have advertised support for HTTP-layer certificates <del> as in setting, either party can supply additional certificates into the connection at any time.  This means that clients or servers which predict a certificate will be required could supply the certificate before being asked.  These certificates are available for reference by future "USE_CERTIFICATE" frames. </del> <ins> in a given direction as in setting, the indicated endpoint can supply additional certificates into the connection at any time.  That is, if both endpoints have sent "SETTINGS_HTTP_SERVER_CERT_AUTH" and validated the value received from the peer, the server may send certificates.  If both endpoints have sent "SETTINGS_HTTP_CLIENT_CERT_AUTH" and validated the value received from the peer, the client may send certificates. Implementations which predict a certificate will be required could supply the certificate before being asked.  These certificates are available for reference by future "USE_CERTIFICATE" frames. </ins> Certificates supplied by servers can be considered by clients without further action by the server.  A server SHOULD NOT send certificates

Related discussion:
text: Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.
Code change:
as possible, this document only specifies the format of Signed Statements (which must be used by all Issuers) and a very thin wrapper format for Receipts, which specifies the Transparency Service <del> identity and the agility parameters for the Merkle Tree Proof.  Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle-tree- proofs. </del> <ins> identity and the agility parameters for the Signed Inclusion Proofs. Most of the details of the Receipt's contents are specified in the COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle- tree-proofs. </ins> This section describes at a high level, the three main roles and associated processes in SCITT: Issuers and the Signed Statement

Related discussion:
text: This PR makes it clearer that merkle trees are not required, and what the structure of a receipt is.
Just to be clear, we very much appreciate the work on the cose merkle proof format and intend to use that by default where we can.
And also of course, LGTM
If you approved this PR, you should probably review and approve URL
NAME I added the changes from the IETF Hackathon, including the new statement-specific registration information in the receipt and the description of transparent statement verification algorithm. The examples will have to be aligned to the new CDDL
These improvements seem excellent... I would approve them, if I could, but I opened the PR.
NAME , can you please re-review your "requested changes" review
Merging as Henks comment was resolved
I also suggest we merge then work on the details. LGTM:+1:
Code change:
packaging of media, taking into consideration the various technical trade offs that each provide. <del> 4.5. </del> <ins> 4.6. </ins> End-to-end security describes the use of encryption of the media stream(s) to provide confidentiality in the presence of unauthorized

Related discussion:
text: This is short, but we should say something about why we're working on this section. Comments are, of course, encouraged.
NAME is hoping that discussion of some requirements at a level that is not protocol-specific would be helpful. It's not helpful to include protocol-specific requirements in this document. This document should explain that.
Code change:
No Error: The session is being terminated without an error. <del> Generic Error: An unclassified error occurred. </del> <ins> Internal Error: An implementation specific error occurred. </ins> Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.

Related discussion:
text: To allow subscribers to indicate that no new subscriptions will be routed to the publisher for a given namespace. Happy to bikeshed on the name and whether we really need another frame for this.
The problem is not possible for the subscriber to reject an ANNOUNCE afterwards. This would be very useful, for example to inform a publisher that no more subscriptions will be routed to them for whatever reason. Examples: The auth parameter in ANNOUNCE has expired. Another publisher has sent an overriding ANNOUNCE (reconnect?) The broadcast has been closed remotely, ex. some moderation tool. Without this message, the only recourse for the subscriber is to close the connection. This won't work if multiple ANNOUNCE messages are pooled over the same connection, nor is it clean.
I propose two options: can be sent after . We add and to mirror . I personally hate 3 separate messages for a subscriber to close an announce, or a publisher to close a subscription. See
very trivial bikeshed comment ... I would prefer to call it something other RESET ( and also other places we use RESET ). I get the TCP analogy but I think that is the wrong way to think about this. I would prefer something like REVOKE.
how about ANNOUNCE_CANCEL to cancel an open announce ?
Conclusion is that we do need to add a new frame to end an ANNOUNCE. Additionally, there was a principle stated that we should not rely on closing the session as the typical or optimal way to close state and close either an ANNOUNCE or SUBSCRIBE.
On the call today, people tend to prefer ANNOUNCECLOSE over ANNOUNCECANCEL as a name. They also prefer merging SUBSCRIBERESET and SUBSCRIBEFIN into a single message, possibly SUBSCRIBE_CLOSE.
On an editorial note, it'd be nice to have subsections for publisher/subscriber to make it clearer to the reader.
If we're going to combine and , then we should just combine and now. My desire is to have four messages: publisher create: ANNOUNCE publisher close: UNANNOUNCE subscriber accept: ANNOUNCEOK subscriber close: ANNOUNCESTOP The same goes for subscriptions: subscriber create: SUBSCRIBE subscriber close: UNSUBSCRIBE publisher accept: SUBSCRIBEOK publisher close: SUBSCRIBESTOP
Code change:
No Error: The session is being terminated without an error. <del> Generic Error: An unclassified error occurred. </del> <ins> Internal Error: An implementation specific error occurred. </ins> Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.

Related discussion:
text: PR updated, PTAL
This came out of discussion on When a relay receives an SUBSCRIBE it may need to issue its own SUBSCRIBE to a publisher that has previously ANNOUNCE'd a namespace matching that track. The current draft doesn't specify how this match is done. A relay could implement an exact match on Track Namespace (requires a tweak to SUBSCRIBE), or could do a longest prefix match on track name vs all ANNOUNCE'd namespaces, or possibly something else. Is it ok to leave this up to implementations or should the draft specify this behavior more exactly? If more than one matching type is allowed, does it need to be negotiated, and by whom (publisher, subscriber, or both)?
An issue that came up in interop that is somewhat related - NAME relay was implemented to take the namespace from the connect URL, because in his use-case, ANNOUNCE can be made redundant with the connect URL (eg it contains a namespace and enough auth). However, this caused an interop problem because my chat application assumes a certain functionality from relays, and that includes supporting ANNOUNCE messages to determine routing to publishers. Do we need to be more prescriptive about relay behavior?
ANNOUNCE is what my implementation expects as well. A producer can announce track namespaces at any point (after being connected). Overloading connect URL with track info is limiting
This is going to be a slightly long comment but this is how I think this should work. The catalog has two fields for the track namespace , and track name. We also specify in the catalog a way to form a URL from these two fields. See Teds proposal and that is catalog specific. The things we put in these track namespaces and track name fields are already canonicalized in a way defined by the catalog and URL. When the application using the moq transport puts these two fields into message, they are treated as just a bunch of bits and any comparison of them is done with bitwise compare. A relay that needs to check if a namespace matches another does not need to worry about string prep or escape encoding of the bits, the will all have been done when the catalog was formed. This allows the relays to work faster by just doing bitwise compare yet at the same time allows us to use URI at the application level. The transport draft just needs to deal with a bag of bits.
Code change:
No Error: The session is being terminated without an error. <del> Generic Error: An unclassified error occurred. </del> <ins> Internal Error: An implementation specific error occurred. </ins> Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.

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:
No Error: The session is being terminated without an error. <del> Generic Error: An unclassified error occurred. </del> <ins> Internal Error: An implementation specific error occurred. </ins> Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.

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:
No Error: The session is being terminated without an error. <del> Generic Error: An unclassified error occurred. </del> <ins> Internal Error: An implementation specific error occurred. </ins> Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.

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:
No Error: The session is being terminated without an error. <del> Generic Error: An unclassified error occurred. </del> <ins> Internal Error: An implementation specific error occurred. </ins> Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.

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:
conveyed by other means.  As such, a HTTP/2 message containing Connection MUST be treated as malformed. <del> This means that an intermediary transforming a HTTP/1.x message to </del> <ins> This means that an intermediary transforming an HTTP/1.x message to </ins> HTTP/2 will need to remove any header fields nominated by the Connection header field, along with the Connection header field itself.  Such intermediaries SHOULD also remove other connection-

Related discussion:
text: l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or
Code change:
The "Early-Data" header field is included in requests that might have been forwarded by an intermediary prior to the TLS handshake <del> completing. </del> <ins> with its client completing. </ins> The 425 (Too Early) status code is defined for a server to indicate that a request could not be processed due to the

Related discussion:
text: I think that these are the main places where we weren't clear enough about the relevant TLS role.
LGTM
Code change:
11.7. <del> Previous versions of this document (RFC7540) registered an upgrade token.  This capability has been removed: see versioning. </del> <ins> RFC7540 registered an upgrade token.  This capability has been removed: see versioning. </ins>

Related discussion:
text: At two points in the document, it refers to "previous versions of this document," which I take to mean RFC 7540, since we don't discuss differences from previous drafts when we publish the RFC. Is there a reason not to simply say "RFC 7540" in these places, similar to the discussion in 5.3?
Probably not.