jiebi/CodeConvo huggingface dataset:
Code change:
Subscribe ID: Subscription identifier as defined in message- subscribe-req. <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:
Subscribe ID: Subscription identifier as defined in message- subscribe-req. <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:
Subscribe ID: Subscription identifier as defined in message- subscribe-req. <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:
Some of these features are also absent in HTTP/2 and HTTP/3. <del> Unlike HTTP/2 and HTTP/3, this format uses a a fixed format for control data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo- fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </del> <ins> Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo-fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no

Related discussion:
text: Typi fix
I had to read that three times to spot your change. Something about that text blinded me to that.
Code change:
that this is the third time that they have been notified and their last opportunity to prevent deletion of their work files.  One or more employees respond by following the URL, entering the code and <del> performing multi-factor authentication.  Once these employees authorized access, the attacker obtains access and refresh tokens from the authorization server and uses it to access the users files, perform lateral attacks to obtain access to other information and continuously refresh the session by requesting new access tokens. These tokens may be exfiltrated and sold to third parties. </del> <ins> performing multi-factor authentication.  Throughout the authentication experience, the user is interacting with a trusted user experience, re-enforcing the legitimacy of the request.  Once these employees authorized access, the attacker obtains access and refresh tokens from the authorization server and uses it to access the users files, perform lateral attacks to obtain access to other information and continuously refresh the session by requesting new access tokens.  These tokens may be exfiltrated and sold to third parties. </ins> 3.4.3.

Related discussion:
text: Included feedback based on
Section 3.6 (the section about an attacker emulating an enterprise application) is the canonical example of an illicit consent grant attack leveraging the device authorization grant. One of the key things that makes this attack particularly scary is the fact that everything the targeted user sees (outside of perhaps the non-ordinary flow involving user_code entry) indicates to them that they're signing into a trusted enterprise application, since you can use a trusted app's client ID when initiating the flow. In reality, however, they're just completing the second leg of a flow initiated by some attacker's script. While you mention "emulating an enterprise application", I don't think that provides the clearest example of why this is particularly scary. I think you could go a bit further and emphasize that everything the user sees in this sort of attack is: a) trusted UX and b) indicates that they're signing into a trusted application.
Code change:
same Last-Modified time, then at least one of those responses would have a <del> value equal to its Last-Modified time.  The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response.  An implementation MAY use a value larger than 60 seconds, if it is believed that 60 seconds is too short. </del> <ins> value equal to its Last-Modified time. </ins> 7.9.3.

Related discussion:
text: : >A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules: I'm hearing that this 60-second window is problematic for videos, where clients often request a partial video segment within a minute of it being published (thanks to e.g., CMAF). Since those requests use , they require a strong validator. Should we revisit this, given that it is an arbitrarily chosen value by our own admission? I agree that some caution is necessary here, but a one-size-fits-all approach doesn't seem viable.
Discussed on call. Sense is to make this much more based upon the judgement of the implementation, rather than just an arbitrary number.
Suggestion:
NAME NAME - this creates a nested unordered list which comes out really strangely in HTML, please check. Maybe it would be better to have the two statements (that are nested) in a single list entry.
Code change:
mechanisms that would give flows with different round- trip times comparable capacity during backoff. <del> 3.1.3. </del> <ins> 3.1.2. </ins> The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases.  Exactly

Related discussion:
text: Reverts ietf-wg-ccwg/rfc5033bis. This was accidentally submitted without review. The conclusion of the editors is that this is out of scope for the document.
Code change:
mechanisms that would give flows with different round- trip times comparable capacity during backoff. <del> 3.1.3. </del> <ins> 3.1.2. </ins> The alternate congestion control mechanism should reduce its sending rate if the round trip time (RTT) significantly increases.  Exactly

Related discussion:
text: Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.
Code change:
An 8-bit field reserved for frame-type specific boolean flags. <del> The least significant bit (0x1) - the END_STREAM bit - is defined for all frame types as an indication that this frame is the last the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Implementations MUST process the END_STREAM bit for all frames whose stream identifier field is not 0x0.  The END_STREAM bit MUST NOT be set on frames that use a stream identifier of 0. The remaining flags can be assigned semantics specific to the indicated frame type.  Flags that have no defined semantics for a particular frame type MUST be ignored, and MUST be left unset (0) when sending. </del> <ins> Flags are assigned semantics specific to the indicated frame type. Flags that have no defined semantics for a particular frame type MUST be ignored, and MUST be left unset (0) when sending. </ins> A reserved 1-bit field.  The semantics of this bit are undefined and the bit MUST remain unset (0) when sending and MUST be ignored

Related discussion:
text: Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.
Code change:
MUST be used by the issuer to include digests of the salted claim values for any claim that is intended to be selectively disclosable. <del> The issuer MUST choose a cryptographically random salt value for each claim value.  The salt value MUST then be encoded as a string.  It is RECOMMENDED to base64url-encode the salt value. </del> <ins> The issuer MUST choose a random salt value for each claim.  It is RECOMMENDED to do so by base64url-encoding a cryptographically secure nonce.  See salt-minlength for further requirements. </ins> The issuer MUST generate the digests over a JSON literal according to RFC8259 that is formed by JSON-encoding an object with the following

Related discussion:
text: Addresses Issue
I also revisited the security recommendations for the salt and made some smaller changes there.
user has 2 SD-JWTs from the same issuer, same blinded claim names can be used to correlate the user. advice to have a fresh blinded claim name for each credential.
Instead of opening a new issue from our conversation this morning - here is the excerpt & suggestion from the document we discussed: First off, maybe it's informational or maybe it's specified - issuers should not include "secrets" in claim labels. If a label for something is actually a secret, it should be treated as such. That said, I get that this scenario must be addressed. Sensitive predicates or graduated disclosure contexts can benefit from this capability. It seems to me that the most useful and easy algorithm to implement is to use the same hash algorithm + salt for the node value to blind the label where: SALTED LABEL = HASHALGO(LABEL + SALT) Of course, this assumes that specific guidance is included for best practice salt generation (fresh entropy gathering for each attribute block salt, sufficient bits of entropy, etc.) for strong cryptographic outcomes. In this representation, the salted hash of the label's value ("name") "9-J2445ap91..." can be addressed directly by the digest "h" value in compact form: Side-note: Informative statements that recommend large sd-jwt claim sets should be 'broken down' into much smaller sets, or individual claims, then wrapped and sealed as a JWP may be better than including too many claims in an sd-jwt.
Right now, it is RECOMMENDED that a random string is chosen for the blinded claim name. HMAC(salt, claim-name) and HASHALGO(LABEL + SALT) would be fine as well, 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. I don't see a real advantage of using HMAC/HASHALGO for the blinded claim name. I therefore propose to stick with the current recommendation. We should stress that a fresh random value must be chosen for each claim in each issued credential.
Code change:
MUST be used by the issuer to include digests of the salted claim values for any claim that is intended to be selectively disclosable. <del> The issuer MUST choose a cryptographically random salt value for each claim value.  The salt value MUST then be encoded as a string.  It is RECOMMENDED to base64url-encode the salt value. </del> <ins> The issuer MUST choose a random salt value for each claim.  It is RECOMMENDED to do so by base64url-encoding a cryptographically secure nonce.  See salt-minlength for further requirements. </ins> The issuer MUST generate the digests over a JSON literal according to RFC8259 that is formed by JSON-encoding an object with the following

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:
MUST be used by the issuer to include digests of the salted claim values for any claim that is intended to be selectively disclosable. <del> The issuer MUST choose a cryptographically random salt value for each claim value.  The salt value MUST then be encoded as a string.  It is RECOMMENDED to base64url-encode the salt value. </del> <ins> The issuer MUST choose a random salt value for each claim.  It is RECOMMENDED to do so by base64url-encoding a cryptographically secure nonce.  See salt-minlength for further requirements. </ins> The issuer MUST generate the digests over a JSON literal according to RFC8259 that is formed by JSON-encoding an object with the following

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:
header field.  The header field is a connection-specific header field that includes <del> parameters that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade. </del> <ins> settings that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade. </ins> A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present or if more than one is present.  A server MUST

Related discussion:
text: In the spirit of the naming simplications of the recent HTTP changes, we can talk about settings in this revision. This aligns better with HTTP/3, though that still uses "settings parameters" (with that ugly double-plural). cc NAME
I mean, it's not too late to Auth48 the same change into H3.... Not quite, anyway.
Code change:
The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to <del> "1". </del> <ins> "true". </ins> 3.3.

Related discussion:
text: Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.