jiebi/CodeConvo huggingface dataset:
Code change:
Track Namespace: Identifies a track's namespace as defined in (track-name). <del> 6.11. </del> <ins> 6.13. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without

Related discussion:
text: Once again data is flowing from A to R to B. I think it would be bad if the new ANNOUNCE, or an error on the QUIC connection from A to R caused a termination or error of the subscribe between B and R. I'm think it is better for B to unsubscribe if it is not receiving the media it wold expect.
Having explicit messages reflecting the actions would be my inclination as well. I thought it might be beneficial to explain the role of the above proposed messages with few flow diagrams Here is the happy path flow (it ignores Subscribe_OK and response flows to keep the flow focussed)
Summary thoughts: Want to support disconnection without propagation to all subscribers (ie: If there were two publishers) Need a way to cleanly unsubscribe from a track (UNSUBSCRIBE) - Like STOPSENDING? Need a way to indicate that a relay is no longer the place to subscribe to for a track (ie: UNANNOUNCE) But UNANNOUNCE does not indicate an unsubscription. Need a way to indicate the track is FIN'd and ending, could use the catalog or put in the protocol (or both) Likely want a way to drain a relay, such as an HTTP GOAWAY style functionality. (Could be SUBSCRIBETERMINATE) Timeouts do need to be handled, even if they're not the ideal/clean case. Want to know whether the relay wants to stop publishing or the origin did, so a client can decide whether to re-sub. NOTE: Objects can be dropped, hard to know if they'll ever arrive. Cullen will summarize a proposal. Note that the relay doesn't really need to know about tracks or what its subscribing to. An open issue is how to do FIN, whether it as part of Objects, only the catalog, a separate message, etc.
Rough notes on proposal in the call: The catalog updates and says what the last message in a track is. Catalogs are a way that endpoints can say there will never be more on a track. The annouce has an equivalent un-Annouce message. It changes routing of future subscribes but does not change state of existing subscribes. The entity that send an subscribe and send an un-subscribe The entity that receives a subscribe can send a go-away which will let the entity that sent the subscribe go do something new ( like subscribe to something else ).
Code change:
Track Namespace: Identifies a track's namespace as defined in (track-name). <del> 6.11. </del> <ins> 6.13. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without

Related discussion:
text: We might need to figure out what data goes in the go away to given info that the clients enough info to do the right thing. Timeout can happen, and connections disappearing, and we need to sort out what impact that has but that is not the primary way to cause flow of media to change. Update: Key issue here is when the relays see the go away, do they drop the related forwarding state for the subscription, or do they just forward the update to the subscribers and wait for the subscribers to remove the subscription.
NAME NAME thanks for capturing the notes. I will work on set of small PRs to capture some of the items from the summary.
The point I was trying to clarify on the last call was that catalog already has a mechanism for a publisher to communicate to all subscribers that the track it has advertised as being available is no longer available. A clean FIN if you like. We can, as has been pointed out, create a control message which says the same thing. But then we have a weird asymmetry in which a publisher notifies clients of track availability through a catalog update but then uses control messages to do the reverse. For good design with clean encapsulation, we should seek symmetry in operation. We should either use control messages to advertise the availability/unavailability of tracks , or use catalogs, but not a hybrid of both. In my understanding of moq-transport, control messages have utility that is scoped to the current hop. They negotiate the format in which data will be exchanged on that hop and issue commands to subscribe/unsubscribe/announce etc. Those commands have no applicability to any other hops on the distribution chain. A catalog however is a contract between a publishers and all subscribers. Unlike control messages, it holds data that is not interpreted hop-by-hop and is intended for targets that can be many hops away. I think relays should be as simple as possible. In my conception, they should not understand whether tracks are being published or not. Their job is to move objects. Their view of the world is around objects and they do not need to understand what tracks are. While of course we can build all sorts of track intelligence in to relays, I think if we can build a base protocol which is agnostic to tracks, then it will be scalable and robust, and cleverness with tracks can evolve in the streaming formats without affecting deployed networks of relays.
Code change:
<del> Description: The SHA-1 algorithm FIPS180-1.  The output of this </del> <ins> Description: The SHA-1 algorithm RFC3174.  The output of this </ins> algorithm is encoded using the base64 encoding RFC4648.  The SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459. <del> Reference: FIPS180-3, RFC4648, this document. </del> <ins> Reference: RFC3174, RFC6234, RFC4648, this document. </ins> Status: obsoleted

Related discussion:
text: Simplifies references to sha algorithms pointing to RFC 6234 instead of FIPS180 documents.
NAME ping :)
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
Code change:
prefixes are only an aid to recognizing the purpose of a field, and do not trigger automatic processing. <del> 16.3.3. </del> <ins> 16.3.2.2. A major task in the definition of a new HTTP field is the specification of the field value syntax: what senders should generate, and how recipients should infer semantics from what is received. Authors are encouraged (but not required) to use either the ABNF rules in this specification or those in RFCSTRF to define the syntax of new field values. Authors are advised to carefully consider how the combination of multiple field lines will impact them (see field-order).  Because senders might send erroneously send multiple values, and both intermediaries and HTTP libraries can perform combination automatically, this applies to all field values -- even when only a single value is anticipated. Therefore, authors are advised to either delimit values that contain commas (e.g., with the rule; see quoted.strings, or the String data type in RFCSTRF), or encode or escape them.  This ensures that commas in the payload of the field value are not confused with those used to delimit list values. For example, the field value only allows commas inside quoted strings, and so can be reliably parsed, even when multiple values are present.  The field value provides a counter-example that should not be emulated: because URIs can include commas, it is not possible to reliably distinguish between a single value that includes a comma from two values. </ins> <del> Authors of specifications defining new fields are advised to consider documenting: </del> <ins> Authors of fields with a singleton value (see field-values) are additionally advised to document how to treat messages where the multiple members are present (a sensible default would be to ignore the field, but this might not always be the right choice). </ins> 16.4.

Related discussion:
text: Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...
Code change:
8.2. <del> Claim Name: "azc" </del> <ins> Claim Name: "azd" </ins> <del> Claim Description: The authorization context </del> <ins> Claim Description: The authorization context details </ins> Change Controller: IESG Specification Document: Section txn-token-claims of this specification <ins> Claim Name: "req_ctx" Claim Description: The requester context Change Controller: IESG Specification Document: Section requester-context of this specification Claim Name: "purp" Claim Description: The purpose of the transaction Change Controller: IESG Specification Document: Section purpose of this specification </ins> 9. 9.1.

Related discussion:
text: Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.
Code change:
12. <del> TBD Declare whether JWT and CWT representations can be used interchangeably by the same issuer.  For instance, declare whether a status list can reference both JWT and CWT tokens. </del> <ins> 12.1. The lifetime of a Status List (and the Status List Token) depends on the lifetime of its Referenced Tokens.  Once all Referenced Tokens are expired, the Issuer may stop serving the Status List (and the Status List Token). Referenced Tokens may be regularly re-issued to increase security or to mitigate linkability and prevent tracking by Relying Parties.  In this case, every Referenced Token MUST have a fresh Status List entry. Referenced Tokens may also be issued in batches, such that Holders can use individual tokens for every transaction.  In this case, every Referenced Token MUST have a dedicated Status List entry.  Revoking batch issued Referenced Tokens might reveal this correlation later on. </ins> 13.

Related discussion:
text: Closes # URL
batch issued credentials might be revealed in an status list update, which might correlate the related referenced tokens/credentials
improve privacy/prevent tracking by regular re-issuance of referenced tokens
Code change:
The set of origins (as per RFC6454) that a given connection might be used for is known in this specification as the Origin Set. <del> By default, a connection's Origin Set is uninitialised.  When an ORIGIN frame is first received and successfully processed by a client, the connection's Origin Set is defined to contain a single origin, composed from: </del> <ins> By default, the Origin Set for a connection is uninitialised.  When an ORIGIN frame is first received and successfully processed by a client, the connection's Origin Set is defined to contain an initial origin.  The initial origin is composed from: </ins> Scheme: "https" <del> Host: the value sent in Server Name Indication (RFC6066 </del> <ins> Host: the value sent in Server Name Indication (SNI, RFC6066 </ins> Section 3), converted to lower case Port: the remote port of the connection (i.e., the server's port)

Related discussion:
text: The consequences for ORIGIN + Alt-Svc with a port change aren't awesome, but this should at least remove any confusion.
Are you going to take another go at this?
Sorry, I let this one drop because I missed your suggestion, which is good.
Thanks!
Code change:
A final (but significant) goal is to provide for ease of implementation, deployment and operation.  This mechanism is expected <del> to have a minimal impact upon performance, and a trivial </del> <ins> to have a minimal impact upon performance, and require a trivial </ins> administrative effort to configure. 1.2.

Related discussion:
text: consistent use of instead of "http" make S1.1, P3 a bit more readable
Code change:
<del> OAuth Status List </del> <ins> Token Status List </ins> draft-ietf-oauth-status-list-latest Abstract

Related discussion:
text: URL
I noticed the draft was renamed from the name it previously had at the last IETF meeting where it was adopted. The previous name was "JWT and CWT Status List" and the new name is "OAuth Status List". I understand not wanting to have "JWT" and "CWT" in the name, but the new name is somewhat confusing, since it makes it sound like there is a status of OAuth itself somehow. I suggest renaming this to "OAuth Token Status List" to avoid confusion.
See We got feedback from multiple people and hence decided to go for as this seemed a reasonable choice by many. I would not change the title now again before the cutoff, but I'm happy to discuss so in Prague.
FWIW my comments/feedback on and related conversations were only about the document identifier being For the draft title, I'd go with "Token Status List" as suggested URL Note that the document identifier (guess it's called docname in the markdown) needs to start with draft-ietf-oauth- because of IETF convention and the draft being an OAuth WG item. But the document title doesn't have to have "OAuth" in it.
After reviewing the discussion I also would support "Token Status List". And yes, it looks like the discussion in was about the draft URL, not the title.
The name of the issue is "Feedback from call of adoption: Draft title". How should it not be about the title then?
I was commenting on the fact that literally all of the comments only mentioned the draft URL.
I already stated in the ML, but I support `Token Status List"
"Token Status List" seems the most supported option, if there is no objection, we would rename next week. I would suggest removing “OAuth” from the title of the draft and make it “Token Status List”. “OAuth Token Status List” sounds like status list mechanism defined in this draft is only for the tokens used in OAuth/RFC6749, which it is not. Huge +1.
Code change:
<del> OAuth Status List </del> <ins> Token Status List </ins> draft-ietf-oauth-status-list-latest Abstract

Related discussion:
text: Best, Kristina From: OAuth On Behalf Of Michael Jones Sent: Monday, October 23, 2023 10:29 PM To: URL ; Aaron Parecki Cc: oauth Subject: Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List To Aaron’s naming points, I would be fine changing the title in the draft from “OAuth Status List” to “OAuth Token Status List”, if there’s working group consensus to do so. We could have that discussion in Prague. The name change was motivated by feedback from multiple sources that the old name “JWT and CWT Status List” was too specific in token types, seeming to unnecessarily tie our hands. That said, I don’t think we need to change the draft identifier “draft-ietf-oauth-status-list”. I doubt that there’s another kind of status list happening in the working group that might cause confusion. ;-) Besides, the draft identifier is actually ephemeral. Should the working group draft progress, it will be replaced by an RFC number. Cheers, -- Mike From: OAuth > On Behalf Of Rifaat Shekh-Yusef Sent: Monday, October 23, 2023 7:48 AM To: Aaron Parecki > Cc: oauth > Subject: Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List I also noticed you didn't mark it as replacing the individual draft in datatracker. You can email EMAIL and request that they mark it as replacing URL so that the history tracks better. I fixed that. Regards, Rifaat On Mon, Oct 23, 2023 at 10:35 AM Aaron Parecki > wrote: Tobias, Paul, Christian, I just noticed the new working group adopted version of this draft: URL I posted this comment on Github, but I'll repeat it here for others. I find the new name "OAuth Status List" confusing. While I understand wanting to remove "JWT" and "CWT" from the name, I was not aware of that discussion during the call for adoption. I would suggest renaming this to "OAuth Token Status List" instead. I also noticed you didn't mark it as replacing the individual draft in datatracker. You can email EMAIL and request that they mark it as replacing URL so that the history tracks better.
Code change:
<del> OAuth Status List </del> <ins> Token Status List </ins> draft-ietf-oauth-status-list-latest Abstract

Related discussion:
text: I also noticed that there are significant changes to the draft between the individual and working group versions. Typically it is better to post a verbatim copy of the individual draft as the adopted version, and then make changes in a -01 version. Thanks! Aaron On Sat, Oct 14, 2023 at 5:56 AM Rifaat Shekh-Yusef > wrote: All, Based on the feedback to this call for adoption, we declare this document adopted as a WG document. Authors, Please, submit this as a working group document at your earliest convenience. Regards, Rifaat & Hannes On Tue, Oct 3, 2023 at 8:51 PM John Bradley > wrote: +1 for adoption All, This is an official call for adoption for the JWT and CWT Status List draft: URL Please, reply on the mailing list and let us know if you are in favor or against adopting this draft as WG document, by Oct 13th. Regards, Rifaat & Hannes OAuth mailing list EMAIL URL OAuth mailing list EMAIL URL
Code change:
credential to the Issuer.  It is important to note that the timing of such requests could potentially serve as a side-channel. <del> Verifier/Verifier unlinkablility and presentation unlinkablility can be achieved using batch issuance: A batch of credentials based on the </del> <ins> Verifier/Verifier unlinkability and presentation unlinkability can be achieved using batch issuance: A batch of credentials based on the </ins> same claims is issued to the Holder instead of just a single credential.  The Holder can then use a different credential for each Verifier or even for each session with a Verifier.  New key binding

Related discussion:
text: BTW NAME please do a quick PR adding yourself to the Acknowledgements section, if you;'d like.
Thanks NAME !
Code change:
Parameters: The parameters are defined in version-specific-params. <del> 6.16. </del> <ins> 6.17. </ins> The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the

Related discussion:
text: Some diffs are due to me reflowing text to fit the line limits, so please ignore those. Once we have this and a limit on announce IDs, it seems likely that we'll be able to get rid of 'Role', but for now it can stay.
Thanks NAME . this looks like a good improvement. I have few clarification questions and bit of extra work for you to add some informative text, if my comment seems ok to you.
Unfortunately, that makes it much more difficult for the server to tell abusive clients from valid ones, as we discovered with the recent HTTP/2 rapid reset attacks. In the end we did develop heuristics, but they're imperfect and in the process we broke a bunch of applications in an effort to defend against DDoS attacks. In contrast, QUIC had a system like this and experienced no issues and we didn't need to develop any new heuristics.
Currently, there's no way to limit the number of simultaneous subscriptions. QUIC stream limits cannot effectively be used to limit the number of subscriptions, so I'd suggest MoQ have a limit. The simplest idea would be to have a limit specified as a parameter in the server's SETUP message. As a related question, even with limits, what happens if a client subscribes to a number of streams that it doesn't have the bandwidth to support? ie: 10 4k video streams and they're on a slow link? Possibly the subscriptions could fail with an error code indicating that the server didn't have enough bandwidth to request them and/or serve them to the client?
rofl I just came here to post the same issue. See: URL I think we follow QUIC and have a MAXSUBSCRIBES frame. The initial value can be set in the SETUP message. The subscribe is considered active until the publisher sends or (TODO). I think we're okay with the subscriber/publisher using arbitrary subscription IDs if there's a single control channel. It would be easier if we required incremental subscribe IDs and you couldn't reuse them though.
Also do we need ? That seems like a potential attack vector too, since it involves inserting into a potentially CDN-wide routing table.
Code change:
Parameters: The parameters are defined in version-specific-params. <del> 6.16. </del> <ins> 6.17. </ins> The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the

Related discussion:
text: A few months ago, I would have said we should go with the HTTP/2 style design of just having a limit on number of streams, but given the recent issues, I'd be inclined towards the QUIC style of specifying the max number. But I think that works better if we also have a subscription ID that's monotonically increasing for subscriptions, ie: Announces also likely need some limits, but I'm less clear on how that might work.
I propose a monotonically increasing in the message. You can't reuse Subscribe IDs. We add a message containing the maximum allowed ID and possibly a SETUP parameter to set the initial value. The corresponding messages use that ID instead of echoing the full track name. This removes ambiguity and overhead. We would still have Track ID for compressing the full track name (maybe renamed?). You could have multiple SUBSCRIBE reference the same Track ID but contain different Subscribe IDs. For example: Same for .
Adding a Subscribe ID used as you're describing SGTM and as you said remove any ambiguity about what subscription is being referenced. Unless we are absolutely never going to have multiple subscriptions, I believe we'll need a Subscribe ID.
This is related to
may be better to name it as transaction_id . since it is id tied to a given subscribe transaction ..
As a follow-up to adding a Subscribe ID, we'll add a SETUP field or param to indicate the initial value and a MAXSUBSCRIBEID frame to increase the limit, similar to QUIC flow control.
The consensus at the session today was to go with a QUIC style approach, so I wrote There was interest in a similar approach for announces, but announces don't yet have an ID, so that will have to wait.
Will assign to Mike English
This seems like a really complicated way to limit the subscribes. I understand how it mirror streams but that had pretty different constrains. Why don't we just have an subscribe error of "too many subscriptions"? Discussed open issues in the 7 August 2024 virtual, not recorded here. Remaining issue (just do a SUBSCRIBE_ERROR?) went to the list and chairs declared rough consensus, although at least 2 participants would prefer not to have this.