Original text:
There are 4 types of filters: Latest Group (0x1) : Specifies an open-ended subscription with <del> objects from the beginning of the current group. </del>  Latest Object (0x2): Specifies an open-ended subscription beginning <del> from the current object of the current group. </del>  AbsoluteStart (0x3): Specifies an open-ended subscription beginning from the object identified in the StartGroup and StartObject fields.

Reviewer comments:
This came up during interop - A relay received a subscribe with start={g=RelativeNext/0 o=Absolute/0}. Since the relay had not received any objects, it defaulted largest to 0 and interpreted the subscribe as starting at {g=1, o=0}. When {g=0,o=0} arrived, it was not forwarded. But there's a reasonable interpretation that it should have forwarded treated this as the beginning of the next subscription. This is partially related to and maybe
If the subscriber wanted to get the largest group, it would have made request start = {g=RelativePrevious/0, o=None} .. This would have the interpretation that subscribe starts at {g=0, o=0} when {g=0, o=0} arrives. This would also work when {g=0, o=22} arrives. If my understanding of locations is correct, then the original request of {g=RelativeNext/0 o=Absolute/0} is incorrect for the answer being expected ..
I think it's reasonable to return 0,0 The subscriber uses RelativeNext if it doesn't want old data. If no data has been generated, then that requirement is still met.
But that's ambiguous. Since Group and Object IDs are zero-based, that response also describes the situation in which the relay has received the first object from the first group, which is clearly a different state. Can we solve this problem by specifying that both GroupID and Object ID are >= 1 of they exist, and 0 if they do not? This can be used to describe the situation in which the subscription is active but the publisher has not yet produced any objects.
Oh to clarify, the SUBSCRIBE_OK should return None/None as the latest group/object. The first OBJECT delivered would be 0/0. And yeah we could switch object/group to be 1-indexed instead of 0-indexed. None=0
Individual Comment: Agreed that in this particular case, the client was not really asking for what they wanted. The "Largest group/object" language comes from the draft, though, and I think it's ambiguous what it means to a relay that hasn't seen any objects. My interpretation of the spirit of the draft is that 0/0 would be forwarded in this case if the client asked to start Next/0 (eg: there's a bug in my relay), but if so, we should make it clear in the draft how it's supposed to work.
Is this
I think I can see the intent with what's there, but the draft could use some editorial text clarifying what "next/0" means when subscribe OK was "no content available".
I thought we decided on call that we were not going to steal bits from the group id / object id to indicate meta data what is going on. After that call I was expecting to see some explicit flag for "no content available" if that is what needed to be sent.
After merging , Subscribe OK has the flag you are referring to: https://moq-URL I left this issue open because I think there's still some ambiguity that can be resolved with editorial text.
makes sense - thanks
NAME can you write some editorial text to clarify this if you have something in mind?
I tried to write some text, but I got confused. Ignoring object locations for a second and just focusing on groups, I think this is what we want, but I'm unsure how to define "current" when there are no objects: I think the simplest way to resolve this is to treat the next seen group ID as the "next" one and anything attempting to match only "current" matches either a) nothing or b) . I recognize that b) may be controversial in that we don't require unitary increase in group IDs. Practically I think subscribers should usually ask for [RelativePrev/0, None] (give me the current group if you know it or the next seen group if you don't). If we assume that the publisher only says "ContentExists: false" when it hasn't published anything, and relays only repeat this when they get it from publishers, then it's somewhat easier to assume that anything before "next" simply doesn't exist. I'm unsure if this covers publisher restart cases well enough though. There's also an asymmetry in this case in that there's no message to communicate how the relative requests were interpreted, as SUBSCRIBE_OK now does when the largest object is known. Further, the algorithm for how to interpret relative object locations in groups with an unknown "largest object" may be even murkier, but let's agree what the groups mean and then move on to objects.
Now that is merged I think I can make a PR to address the concern. I think it would be something like:
LGTM

Revised text:
There are 4 types of filters: Latest Group (0x1) : Specifies an open-ended subscription with  <ins> objects from the beginning of the current group.  If no content has been delivered yet, the subscription starts with the first published or received group. </ins> Latest Object (0x2): Specifies an open-ended subscription beginning  <ins> from the current object of the current group.  If no content has been delivered yet, the subscription starts with the first published or received group. </ins> AbsoluteStart (0x3): Specifies an open-ended subscription beginning from the object identified in the StartGroup and StartObject fields.