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: I'm leaning towards CLOSED instead of CLOSE because CLOSE implies its a requested action, so to me SUBSCRIBE_CLOSE sounds like something the subscriber would send, not the publisher. For a similar reason, I like CANCEL slightly better than STOP, but both work. UNANNOUNCE and UNSUBSCRIBE are good words, but I think it's better to follow a pattern in this case and I like NAME sequence of messages.
NAME CANCEL and CLOSED are slightly better, sure. NAME there MUST still be an OK before objects can be sent. That way the receiver can tell upon receipt of the CLOSED if the subscription was ever active.
So to add an OK, we need to add another state. The question for me is what is the use case where we need to deliver that information in the end of the subscribe.
This discusion is probably easier looking at state machine diagrams
Sections 6.8 and 6.9 strongly imply that SUBSCRIBEFIN/RST are sent at the true end of the track. So are they not sent at the conclusion of a SUBSCRIBE that does not cover the end of the track? For example, if the last object of a track is (10, 12), and there's one subscribe for (4,0) to (5, 100) Is there a SUBSCRIBEFIN? If not, how does the subscriber know that in fact (5, 60) is the last object in that subscription? If so, does Final Group and Final Object refer to the last object in the subscription?
Individual Comment: Putting my HTTP hat on for a second, when you ask for something with unknown length, you infer from a graceful termination that the last thing you got was the true end of that resource. If you send a range request, the graceful termination at the end does not convey that the last thing was the true end. Once the object expires, you can issue another request to the same name and potentially get a totally different thing. Does this model work for moq, or do we need something different?
There are three different things you might want to communicate to a receiver at the end of the subscribe: 1) You got all of the objects in the range; 2) You got almost all of the objects, but some were dropped for latency/bandwidth reasons 3) The track was truncated for some reason and possibly, 4?