Original text:
Track Name: Identifies the track name as defined in (track-name). <del> StartGroup: The start Group ID, plus 1.  A value of 0 means the latest group. </del>  <del> StartObject: The start Object ID, plus 1.  A value of 0 means the latest object.  This field is not present when Start Group is 0. </del>  <del> EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended and continues to the end of the track. </del>  EndObject: The end Object ID, plus 1.  A value of 0 means the <del> entire group is requested.  This field is not present when End Group is 0. </del>  Track Request Parameters: The parameters are defined in

Reviewer comments:
I took a stab at another rewrite of Subscribe message which attempts to not use special group and object values. Also add support for multiple subscription flows that have been discussed. As this is a control message, we should be Ok to be elaborate in describing the subscriber needs. This leaves 0 as a special value for the StartObject and EndObject.
NAME updated the PR .. please let me know .. thanks
I like that this would move us away from stealing special values from obejct id / group id space.
This looks good NAME .. thanks for the update
As currently defined, you can SUBSCRIBE starting from the following points: The latest group and latest object An absolute group and latest object An absolute group and absolute object You cannot SUBSCRIBE to a. The latest group with an absolute object b. The latest group from the beginning c. The next group after latest, from the beginning I'd like to remove 2) (absolute group, latest object). If this group is in the past, then likely the group is complete and no new objects will come in that group, so it's equivalent to (absolute group + 1, object 0). If this group is in the future, then it's equivalent to (absolute group, object 0). If the group is current, it's equivalent to latest/latest. Does anyone have a use case that requires this mode? I'd also like to add b) (latest group, first object) and c) (next group, object 0). This can be done now with an extra round trip via TRACKSTATUSREQUEST, so perhaps this is an optimization we can tackle later.
It's currently ambiguous if or happens. When , then is not present but doesn't have a specified default. If then occurs, and if then occurs. The correct behavior is IMO since groups are intended to be sync points. +1 to removing .
And I don't think we should support without a good use-case. It's too racey for ABR and too delayed for initial playback. It's also barely an optimization since the alternative is making the TRACKSTATUSREQUEST, which primarily eats into time that would have been spent waiting for the next group to start anyway.
means you can only start at: b. The latest group from the beginning An absolute group and absolute object Everything else is accomplished with , forcing the subscriber to converts relative values to absolute. I think we should eventually bring back Locations so the publisher can do this conversion too without an additional RTT, but the desire was to simplify start/end ranges.
FWIW, I thought/intended start_group=0 to correspond to b. Also +1 to removing case 2.
Thanks for summary. +1 to remove case 2 (abs/latest). I also thought we had b. today but we need case b so lets update to make it clear we have b (latest/0). I don't think we have a use case for a (latest/abs), +1 on remove. I originally was in favor of case c (next/0) but I have changed my mind for now. IF you need this, you just do case 1 (latest/latest) and toss out object until you get to the next group. If there was not enough bandwidth to do this, then there is probably not enough bandwidth for the next group when it arrives. If we get a bunch of code running and can show that (latest/latest) is not good enough and we really need (next/0), then I will change my mind but for now, I think we can live without (next/0). And +1 to point that TRACKSTATUSREQUEST solves most problems.
A +1 to all these points Regarding starting at the latest group at the beginning, this seems like the default starting use case for many players. Therefore per Luke's comment -
Fixed by

Revised text:
Track Name: Identifies the track name as defined in (track-name).  <ins> Filter Type: Identifies the type of filter, which also indicates whether the StartGroup/StartObject and EndGroup/EndObject fields will be present.  See (sub-filter). StartGroup: The start Group ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins>  <ins> StartObject: The start Object ID within the StartGroup.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. </ins>  <ins> EndGroup: The end Group ID.  Only present for the "AbsoluteRange" filter type. </ins> EndObject: The end Object ID, plus 1.  A value of 0 means the  <ins> entire group is requested.  Only present for the "AbsoluteRange" filter type. </ins> Track Request Parameters: The parameters are defined in