jiebi/CodeConvo huggingface dataset:
Code change:
key as described above and the claim name in <del> MUST be replaced by a placeholder value that does not leak information about the claim's original name.  The same placeholder value is to be used in the II-Disclosures and HS-Disclosures described below. </del> <ins> MUST be replaced by a placeholder name that does not leak information about the claim's original name.  The same placeholder name will be used in the II-Disclosures ( ) and HS-Disclosures ( ) described below. To this end, the issuer MUST choose a random placeholder name for each claim that is to be blinded.  It is RECOMMENDED to do so by base64url-encoding a cryptographically secure nonce.  See blinding- claim-names for further requirements. </ins> 5.2.1.1.

Related discussion:
text: NAME it's not super clear to me how: would alleviate your concerns here: "but there's more room for errors, especially as holders/verifiers might expect a specific format and then reject an SD-JWT when, e.g., the issuer chose a wrong encoding or similar" Maybe I'm missing something obvious but I don't see much difference in how holders & verifiers would treat these various approaches. They still have to reconcile with the encoding and/or hashing algorithms expressed in the security envelope.
My point was about the selection of the blinded clame name (or 'placeholder claim name' as it is called in the current draft). We have two options on the table: Select a random string as the placeholder Select the placeholder as some function of the original claim name (the label in your proposal) and the salt What I wanted to express is that I think option 1 is better. From a security perspective, both are equivalent. There is no need to choose the placeholder claim name in a particular way, we just need to ensure that it does not leak information about the original claim name. Just numbering all placeholder claim names would be fine as well (as long as the numbering does not reveal anything, e.g., the position of the original claim in the list of claims.) But for option 2, I see two drawbacks: We need to explain more, in particular how to assemble the input for the function, similar to the discussion we had about the hidden claim values. For example, we need to define how the original claim name and the salt are concatenated such that there can be no prefix collisions. A verifier receiving an SD-JWT with blinded claim names according to option 2 may be tempted to (needlessly) check that the claim name was created in a particular way by recalculating the hash. If the issuer has made a mistake when calculating the hash or the verifier makes a mistake, this check will fail. Since such a check is not needed, it would be better if we don't set this trap in the first place. I see no advantages of option 2 over option 1, so I propose to go for option 1.
I see, thanks for explaining that. I'm fine with option 1 if the goal is to reduce cognitive complexity for the application developers - it makes sense.
Code change:
key as described above and the claim name in <del> MUST be replaced by a placeholder value that does not leak information about the claim's original name.  The same placeholder value is to be used in the II-Disclosures and HS-Disclosures described below. </del> <ins> MUST be replaced by a placeholder name that does not leak information about the claim's original name.  The same placeholder name will be used in the II-Disclosures ( ) and HS-Disclosures ( ) described below. To this end, the issuer MUST choose a random placeholder name for each claim that is to be blinded.  It is RECOMMENDED to do so by base64url-encoding a cryptographically secure nonce.  See blinding- claim-names for further requirements. </ins> 5.2.1.1.

Related discussion:
text: PR and PR
I agree with these changes, but it really made me think that we need to clarify various options we have introduced how claims in SD-JWT can be represented as it is becoming a bit hard to follow.. issue filed
Code change:
originating stream state changes to fully closed, all associated promised streams fully close as well. <del> There are no additional type-specific flags defined. </del> <ins> PUSH_PROMISE uses exactly the same flags as the HEADERS frame.  See HEADERS for any flags. </ins> Promised streams are not required to be used in order promised.  The PUSH_PROMISE only reserves stream identifiers for later use.

Related discussion:
text: Replaced 'body' with 'payload' in instances where it would be confusing. Added a flag in the HEADERS frame for header continuations. Added pointers in HEADERS+PRIORITY and PUSH_PROMISE which reference the flags in the HEADERS frame. This should
The continuation bit is inverted with respect to the FINAL flag. Is HEADER_END a better choice? Also, if an unbounded number of frames are permitted, then you need some way to place an upper bound on size. Especially since this requires* that all frames be assembled before processing. Currently, there isn't a default maximum, a setting or an error code.
It could be. I chose this polarity so that it was immediately compatible with what implementations do today for SPDY/2/3 (they don't know about such a bit). If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.
Let's move this discussion to the list.
NAME suggested that his header compression () would include the ability to continue header blocks across frames. We should track this as a separate issue. Important consideration is the way that header blocks mutate session state (for header compression). Interleaving of continued header frames will cause issues if we don't address this. We should also consider whether this is a general facility or not.
I believe we should fix this by declaring that, if there is a continuation happening, no new headers frame is allowed to be sent until the continuation is finished. It just gets too difficult to deal with otherwise. , martinthomson EMAIL:
To clarify - you mean that no headers frame on a different stream can be sent?
yes. It isn't the only possible solution, but it is relatively simple and it seems like it should be a rare enough case... -=R , Mark Nottingham EMAIL:
Code change:
frame cannot be used until the peer has given a positive signal that this is acceptable.  In this case, it could also be necessary to <del> coordinate when the revised layout comes into effect. </del> <ins> coordinate when the revised layout comes into effect.  Note that treating any frame other than frames as flow controlled is such a change in semantics, and can only be done through negotiation. </ins> This document doesn't mandate a specific method for negotiating the use of an extension, but notes that a SettingValues could be used for

Related discussion:
text: Two small changes here. First, adding unnegotiated semantics to reserved bits in existing frames feels like a REALLY bad idea, since you're almost guaranteed to have collisions, so I'm suggesting we remove that as something that extensions can do unannounced. Second, we permit negotiated changes to existing semantics, so I'm suggesting that instead of saying only DATA will ever be flow controlled, we say that making anything else flow-controlled is a changed semantic that has to be negotiated.
(And as a side-note, section 6.9 implies that there may be frames other than DATA which are flow-controlled defined elsewhere: "Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frame.")
Code change:
upload resource in parallel.  This helps avoid race conditions, and data loss or corruption.  The server is RECOMMENDED to take measures to avoid parallel upload transfers: The server MAY terminate any <del> creation (upload-creation) or append (upload-appending) for the same upload URL.  Since the client is not allowed to perform multiple transfers in parallel, the server can assume that the previous attempt has already failed.  Therefore, the server MAY abruptly terminate the previous HTTP connection or stream. </del> <ins> creation (upload-creation) or append for the same upload URL.  Since the client is not allowed to perform multiple transfers in parallel, the server can assume that the previous attempt has already failed. Therefore, the server MAY abruptly terminate the previous HTTP connection or stream. </ins> If the offset indicated by the "Upload-Offset" field value does not match the offset provided by the immediate previous offset retrieval

Related discussion:
text: There were a few cases of the section linking to itself, which I find distracting, so lets remove them.
Good catch, thank you!
Code change:
dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a <del> SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> SUBSCRIBE_RESET (see message-subscribe-reset). Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session with a 'Protocol Violation'. </ins> A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has 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:
dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a <del> SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> SUBSCRIBE_RESET (see message-subscribe-reset). Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session with a 'Protocol Violation'. </ins> A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has 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:
dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a <del> SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> SUBSCRIBE_RESET (see message-subscribe-reset). Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session with a 'Protocol Violation'. </ins> A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has 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:
dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a <del> SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> SUBSCRIBE_RESET (see message-subscribe-reset). Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session with a 'Protocol Violation'. </ins> A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has 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:
dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a <del> SUBSCRIBE_RST (see message-subscribe-rst). </del> <ins> SUBSCRIBE_RESET (see message-subscribe-reset). Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session with a 'Protocol Violation'. </ins> A relay MUST not reorder or drop objects received on a multi-object stream when forwarding to subscribers, unless it has 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.