Code change:
6.14. <ins> A potential subscriber sends a 'TRACK_STATUS_REQUEST' message on the control stream to obtain information about the current status of a given track. A TRACK_STATUS message MUST be sent in response to each TRACK_STATUS_REQUEST. 6.15. An endpoint sends a 'TRACK_STATUS' message on the control stream in response to a TRACK_STATUS_REQUEST message. The 'Status Code' field provides additional information about the status of the track.  It MUST hold one of the following values.  Any other value is a malformed message. 0x00: The track is in progress, and subsequent fields contain the highest group and object ID for that track. 0x01: The track does not exist.  Subsequent fields MUST be zero, and any other value is a malformed message. 0x02: The track has not yet begun.  Subsequent fields MUST be zero. Any other value is a malformed message. 0x03: The track has finished, so there is no "live edge."  Subsequent fields contain the highest Group and object ID known. 0x04: The sender is a relay that cannot obtain the current track status from upstream.  Subsequent fields contain the largest group and object ID known. Any other value in the Status Code field is a malformed message. When a relay is subscribed to a track, it can simply return the highest group and object ID it has observed, whether or not that object was cached or completely delivered.  If not subscribed, a relay SHOULD send a TRACK_STATUS_REQUEST upstream to obtain updated information. Alternatively, the relay MAY subscribe to the track to obtain the same information. If a relay cannot or will not do either, it should return its best available information with status code 0x04. The receiver of multiple TRACK_STATUS messages for a track uses the information from the latest arriving message, as they are delivered in order on a single stream. 6.16. </ins> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI.

Related discussion:
text: There is a bit of angst about using SUBSCRIBE to obtain the current Group ID. This PR is a straw man to provide an explicit means of obtaining the group ID. I would be surprised if this ended up in the final RFC, but it might be useful to keep in the draft as a primitive while the other SUBSCRIBE/FETCH stuff moves around.
Summary from meeting. We want to make it more extensible for other things. Scope to things the relay knows, not a substitute for Catalog. Rename to make it more generic.
What about returning latest object in addition to latest group?
OK, changes: I painted my bikeshed TRACKSTATUS, on the grounds that TRACKINFO sounds like more permanent data that maybe out to be in the Catalog. I added last Object ID because Will asked for it and it seemed easy enough. I did not fill Suhas's suggestion to make it optional because the parameterized idea got a lot of pushback in the call, and this seemed adjacent. Please have a look, and if Ian's happy with it he can merge.
I'll also note that we could put a track alias hint in here, but I didn't care enough to add it without more positive feedback.
This is a good start. We can massage the status codes later. They should correspond to some sort of state machine that we define for moqt in general. I'm sure we will have future changes to this, but I think we should merge it.