Code change:
Based on
Consider the following sequence of groups and objects, some already produced , some that will be produced in the future. The largest group ID is currently 23 and the largest object ID is 3 (it also happens to be the last object in the group). ! Our definitions for RelativePrevious and RelativeNext are shown here. Example 6.4.3.1 for 'now' shows In our example, largest group is 23, however Largest Object + 1 is 4, which does not exist. We need to adjust the definition of RelativeNext to allow for the fact that the next object may be in a different group. There may be some players who simply want the relay to send the next available Object, in this example Object 0 of group 24. There is no current way to reliably ask for this, because StartGroup mode cannot be 'none', and we don't know which group that object will belong to. It may be in the currently largest group, or it may be in the next group. A solution here would be to relax the constraint that StartGroup mode cannot be 'none'. If we then request it would instruct the relay "Send me your next object, no matter which group it belongs to". In 6.4.3 we have examples titled 'Now', 'Current', "previous" and 'Next". 'Now', 'Current' are synonymous to most readers. We need to better titles to illustrate what is actually being requested here. Additionally, "Previous' doesn't indicate whether we want the previous group, or previous object. Similarly for next.
Individual Comment: You are right that the example (and the text likely) don't show the full range of possibilities for what the next object will be. The intent was that Start = Prev/0, Next/0 will get you the next object, which could be any object in the current group greater than largest, or the first object in the next group. This is how my implementation handles it. I don't see a way to get only the next object in the current draft, however, because of the ambiguity you describe.
If I wanted to receive all objects in group N, I would issue: However the draft sneaks this restriction in, and it would actually be a protocol violation: It wasn't clear to me until chatting with Alan how you're supposed to do it: It's clarified in example 5, but I don't think this is obvious and it feels like an off-by-one. For example, if N was the last group in the broadcast, I can imagine some implementations incorrectly throwing an error or somehow mishandling it.
Individual Comment: This was discussed on the PR here: URL Given how subscribe locations work (end is exclusive), end=N+1/0 means "including through the end of group N". The question is whether we should have more than one way to do things, and defaults when values are not present.
Sorry, bad choice of word there. I meant that it's not immediately obvious why the restriction exists, and what it impacts.
Individual Review: I like removing relative options from subscribe. I don't love the group ID + 1 spelling, but I guess I can live with it. An alternative is to add 4 code points for SUBSCRIBE to indicate the presence/absence of start/end (SUBSCRIBE, SUBSCRIBEFROM, SUBSCRIBETO, SUBSCRIBE_RANGE).

Related discussion:
text: Track Name: Identifies the track name as defined in (track-name). <del> StartGroup: The Location of the requested group.  StartGroup's Mode MUST NOT be None. </del> <ins> StartGroup: The start Group ID, plus 1.  A value of 0 means the latest group. </ins> <del> StartObject: The Location of the requested object.  StartObject's Mode MUST NOT be None. </del> <ins> 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. </ins> <del> EndGroup: The last Group requested in the subscription, inclusive. EndGroup's Mode is None for an open-ended subscription. </del> <ins> 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. </ins> <del> EndObject: The last Object requested in the subscription, exclusive.  EndObject's Mode MUST be None if EndGroup's Mode is None.  EndObject's Mode MUST NOT be None if EndGroup's Mode is not None. </del> <ins> EndObject: The end Object ID, plus 1.  A value of 0 means the entire group is requested.  This field is not present when End Group is 0. </ins> Track Request Parameters: The parameters are defined in <del> On successful subscription, the publisher SHOULD start delivering objects from the group ID and object ID described above. </del> <ins> On successful subscription, the publisher MUST reply with a SUBSCRIBE_OK, allowing the subscriber to determine the start group/ object when not explicitly specified and the publisher SHOULD start delivering objects. </ins> If a publisher cannot satisfy the requested start or end for the subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'.