jiebi/CodeConvo huggingface dataset:
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.9. </del> <ins> 6.11. </ins> The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.

Related discussion:
text: Delayed LGTM.
Section 5.1 of the draft says: For the second case above, I think it would be useful to have an explicit signal from the publisher to signal the end of the track. For the third case, the text seems to hint (via a section reference) that if the subscription abruptly terminates with an error, the publisher can send SUBSCRIBE ERROR, but that section says: The draft should clarify if this is allowed following a SUBSCRIBE OK. Also +1 to adding UNSUBSCRIBE ().
+1 we should allow sending a SUBSCRIBE ERROR after a SUBSCRIBE OK.
I was assuming that the catalog change would be the way a track end was indicated then the client would unsubscribe.
As an individual: This seems like a bit of a subtle signal and something more explicit using the Track ID would be preferable for me.
I tend to incline towards Catalog indicating the status the more i think of it. Catalog is source of truth for tracks. Having a catalog update that indicates the following Full Track Name lastobjectid field Also if the catalog is ending, since the producer is going away, then include another optional field finished or something These would be sufficient and a clear way to identify the status end to end.
I think putting the FIN group/sequence in the catalog is clean. It does prohibit relays from cleanly terminating a broadcast early or rewriting group/object sequences, but I think that's fine? However, the wrinkle is that a sender MAY choose to not transmit a group/object. While I don't think this is explicitly stated in the draft, it's a requirement given that relays can only cache data for a finite amount of time. The viewer could get stuck waiting for the FIN group/sequence as signaled in the catalog, even though it is not forthcoming as the relay did not receive the object or already evicted it from the cache.
As an individual: Having an explicit signal outside the catalog will make it easier for relays to clean up track related state. If a publisher is done with a track, they can update the catalog, but it will need to propagate to all subscribers, who in turn need to issue an unsubscribe. Only when all of them unsubscribe (which we still need) can a relay discard the entry in the forwarding table. If the publisher also sends an explicit signal closing off the track, the relay can immediately clean up the state.
We need few things.
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.9. </del> <ins> 6.11. </ins> The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.

Related discussion:
text: Cease the announcement This is an explicit signal from the publisher that it is no longer interested in sending media for the announced tracks. This is sent to the relay to trigger subscription cancellation downstream and clean up local relay state. Terminate the Subscription On subscribe end signal, each receiving entity will forward downstream and clean up local state. If it is the consumer, it stop media pipeline and so on. Unsubscribe For subscribers to explicitly indicate that they are no longer interested in a given track , they will send I am happy to write up a small PR as proposal if we think the general direction is fine.
What is the difference between Cancel the subscription and Unsubscribe?
Unsubscribe is an explicit action from the subscriber and Cancel is the signal from the publisher. May be we should call it ` instead ? I see cancel can be misleading
Got it. Terminate is better than Cancel.
We already have for the publisher to immediately terminate a subscription with a code/reason, so we could reuse that. However, the problem is when the termination occurs. The end of a broadcast would look like: There's a race, as the can arrive before the last objects due to retransmits or congestion control, severing the subscription early. Ideally we wait for all outstanding objects to get delivered and then terminate the subscription. In QUIC terminology, we need a in addition to our existing . The difficult part is determining which objects are still outstanding.
Do we want to distinguish a normal end of subscription (due to EOF), and an unexpected end (due to, e.g., a downstream server crashing)? We do that normally in QUIC (fin vs reset), so it might make sense to do that here.
Image the case where we have A sending to R sending to B. B subscribes to R. A sends ANNOUNCE to R. R subscribes to A. At this point media is flowing from A to R to B. A temporary looses WIFI connectivity and reconnects over 5G with new IP. A sends an ANNOUNCE to R, R subscribes to the new A and perhaps tries to send an error to original ANNOUNCE and end subscribe but A will not get that as that QUIC connection is gone.
Code change:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.9. </del> <ins> 6.11. </ins> The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.

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 the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.9. </del> <ins> 6.11. </ins> The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.

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:
declaration of a selection parameter at the track level overrides the inherited root value. <del> 3.2.18. </del> <ins> 3.2.19. </ins> Certain tracks may depend on other tracks for decoding.  Dependencies holds an array of track names trackname on which the current track is

Related discussion:
text: We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.
Code change:
declaration of a selection parameter at the track level overrides the inherited root value. <del> 3.2.18. </del> <ins> 3.2.19. </ins> Certain tracks may depend on other tracks for decoding.  Dependencies holds an array of track names trackname on which the current track is

Related discussion:
text: Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:
Code change:
The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match- <del> search", "match-dest", "ttl", "id", and "type". </del> <ins> dest", "ttl", "id", and "type". </ins> 2.1.1. The "match" value of the Use-As-Dictionary header is a sf-string <del> value that provides the "pathname" of a URLPattern (https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-pathname). </del> <ins> value that provides the URLPattern to use for request matching (https://urlpattern.spec.whatwg.org/). </ins> <del> The "match" is a URL path relative to the full request URL of the dictionary.  The request URL for the dictionary itself is used as the "baseURL" for constructing the URLPattern (https://urlpattern.spec.whatwg.org/) that is used for matching the dictionary to relevant requests when running dictionary-url-matching. </del> <ins> The URLPattern used for matching does not support using Regular expressions. </ins> <del> The URLPattern used for request matching does not support regular expressions (https://urlpattern.spec.whatwg.org/#token-type-regexp) in the "match". </del> <ins> The following algorithm will return TRUE for a valid match pattern and FALSE for an invalid pattern that MUST NOT be used: </ins> <del> The "match" value is required and MUST be included in the Use-As- Dictionary sf-dictionary for the dictionary to be considered valid. </del> <ins> Let MATCH be the value of "match" for the given dictionary. </ins> <del> 2.1.2. </del> <ins> Let URL be the URL of the dictionary request. </ins> <del> The "match-search" value of the Use-As-Dictionary header is a sf- string value that provides the "search" of a URLPattern (https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-search). </del> <ins> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=URL (https://urlpattern.spec.whatwg.org/). </ins> <del> The "match-search" is the match pattern for the searchpart of the request URL and does not support regular expressions. </del> <ins> If PATTERN has regexp groups then return FALSE (https://urlpattern.spec.whatwg.org/#urlpattern-has-regexp- groups). </ins> <del> The "match-search" value is optional and defaults to the asterisk wildcard token "*". </del> <ins> Return True. </ins> <del> 2.1.3. </del> <ins> The "match" value is required and MUST be included in the Use-As- Dictionary sf-dictionary for the dictionary to be considered valid. 2.1.2. </ins> The "match-dest" value of the Use-As-Dictionary header is a sf-string value that provides a request destination

Related discussion:
text: This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by
Code change:
defined in DIGEST to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. <ins> The expected structured field types (STRUCTURED-FIELDS) of any required or expected covered component fields or parameters. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter of the signature parameters (signature-params) and define rules

Related discussion:
text: Replaces
Thanks!
IMHO we need to be clear what the requirements of SF support are. The way the spec currently is written (referencing RFC 8941) means that SF-shaped field values using the new sf-date format are not supported. I don't think this is what we want, so unless we want to wait for sfbis to be ready, we'll need to add some consideration of how compat with SF extensions/revisions is supposed to work.
The intent of the current text is not to limit the use of the flag to only the currently defined formats. New formats are supported if the signer and verifier support the formats. The agreement of what format to use for a particular field is out of scope for this specification, and needs to be agreed upon by the signer and verifier outside of the signature process. This is true for all the current types and will remain true for any additional types defined in the future.
On a high level, this sounds right. As an implementer of a signature library, calling an SF library, what is your expectation what it'll do with sf-date once the spec is published? What if the sender want to sign an integer param in a dictionary, but the field instance contains another param using sf-date?
I would expect a library of that nature to publish its mapping between field names and SF types, and ideally allow that mapping to be edited by the caller of the library. Otherwise, how would a user of the library be able to provide a type mapping for a custom field that the library doesn't know about, let alone a new sf-type?
Understood. Different layers of libs. What I meant is a generic SF library, that just parses/serializes SF fields.
Then you need to know what you're parsing it in to. SF fields aren't entirely discoverable from the syntax alone, you need to know the type explicitly. I ran into this when implementing my own signature libraries. So the signature library needs to have that mapping, and if the underlying SF library doesn't support some new type, then you can't map to it. Once the dependencies are updated, you can provide that feature up the chain. It all seems pretty standard and simple to me, honestly.
How so? I still don't see the path to interop for any update of the structured field syntax, unless this spec at least provides some hints.
Code change:
defined in DIGEST to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. <ins> The expected structured field types (STRUCTURED-FIELDS) of any required or expected covered component fields or parameters. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter of the signature parameters (signature-params) and define rules

Related discussion:
text: You need to know the top-level type (Dictionary, List, or Item) for each field. The consequence of that (AIUI) is that a recipient wishing to validate a signature that uses will need to understand the top-level type of each 'd field in the signature. It'll also need to support the permissable types in those fields -- e.g., if a field allows Date, the recipient needs to be able to handle that. As a result, it won't be possible to reliably verify a signature if your processor doesn't have knowledge of the top-level type, or if it doesn't have support for an extension type in use in one of those fields. However, there is a chance of verifying it still, if the SF-produced form is sent on the wire and not changed at all in transit, and the processor just ignores processing (and in some ways, this is worse than reliably failing). I think this all can be reasoned out by reading the specs appropriately. Documenting it as a tripping hazard would help users avoid interoperability issues, but this specification is already long and dense, and if we also make it a user guide, it will risk becoming unusable. So, speaking personally -- if the above summary is correct, I could see adding a sentence or two to section 2.1.1 at the most; I could also see leaving it to a separate profile/user guide.
[ chair hat on ] This issue is the last thing holding the Signature spec going to IETF LC. NAME NAME please respond to above, particularly: whether such text is necessary whether such text will address the issue when such text, if necesary, would need to be incorporated (before/after LC). Thanks,
I believe it would be good to have such text; and that it should be in the spec, not in a guide that is unlikely to materialize. It should be incorporated before LC (I hope you mean a new WGLC here...?). Given the amount of changes, we really should spend some time reviewing all that changed, and to verify that the open issues have been addressed properly.
NAME can you propose something? I don't see any reason to rerun WGLC, based upon the current PRs; there are some changes (especially in one or two), but they're based on AD review and can be discussed during IETF LC.