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: TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.) <del> 6.4.3. </del> 6.5. A SUBSCRIBE_OK control message is sent for successful subscriptions.