Code change:
6.8. <del> A publisher issues a "SUBSCRIBE_FIN" message to all subscribers indicating it is done publishing objects on the subscribed track. </del> <ins> A publisher issues a "SUBSCRIBE_DONE" message to indicate it is done publishing Objects for that subscription.  The Status Code indicates why the subscription ended, and whether it was an error. </ins> <del> The format of "SUBSCRIBE_FIN" is as follows: </del> <ins> The format of "SUBSCRIBE_DONE" is as follows: </ins> Subscribe ID: Subscription identifier as defined in message- subscribe-req. <del> 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. Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track. Final Object: The largest Object ID sent by the publisher in an OBJECT message in the "Final Group" for this track. 6.9. A publisher issues a "SUBSCRIBE_RESET" message to all subscribers indicating there was an error publishing to the given track and subscription is terminated. The format of "SUBSCRIBE_RESET" is as follows: Subscribe ID: Subscription Identifier as defined in message- subscribe-req. Error Code: Identifies an integer error code for subscription failure. </del> <ins> Status Code: An integer status code indicating why the subscription ended. </ins> Reason Phrase: Provides the reason for subscription error.

Related discussion:
text: 4) You got everything I have but i'm not sure if that's everything
is somewhat relevant to this issue.
As mentioned in , there are 3 different ways for a publisher to close a subscriber, each with minor differences. : I never sent you an object. : There are no more objects to send after group/object X/Y. : There are more objects after group/object X/Y... but I won't send them. A few things: I think it should be renamed since it's not the only ERROR message. Maybe ? The only difference is that one has an error code. Otherwise they both include a final group/object and it's up to the application/library to decide if they wait for the final object(s). I'd like to only implement this once but right now I have to copy/paste any code to handle these almost identical messages. What if we merged them and use error code 0 to signal a FIN. The reason phrase should be removed as part of . There really needs to be a state machine like with this many ways to terminate a subscription. I think these are all protocol violations: then then then My interpretation of the draft is that a followed by a is invalid, which is not obvious and unlike QUIC. I don't think so. The library/relay behavior doesn't change based on . The only thing that miiiight differentiate between the two is the application, which can use errors codes for this purpose. At the very least I would merge these two messages. But I would also like to explore a single way for the publisher to close a subscription. The application can signal the nuanced differences between errors (ex. error code 404 vs 410). The library/relay doesn't care, it just forwards the error code.
Individual Comment: The inspiration for FIN vs RST in moq came from HTTP caching. If a resource has no content-length, and the caching proxy has received N bytes, does it have the entire resource, or does it need to refetch the tail? If that response was terminated with a FIN (H2 or H3), then it has the whole resource. If it was terminated by a RST, it can't assume that it does. So the value I see in these two messages is for a moq relay is similar.