One of the principles the group seemed to agree on is that FETCH is for the past and SUBSCRIBE is for the future. Draft-07 however left in SUBSCRIBE(current group) which spans both and seems to violate the principle. I understand that subscribing starting from the current group is likely to be a very common use case, as groups are MOQT join points.
My concern is that all the reasons we decided FETCH semantics were good for past data are being discarded here. If the current group consists of an large number of subgroups or datagrams, the sender can overwhelm the receiver. If the relay has a cache with gaps, we have not explained the interaction.
My strawman is to respond to SUBSCRIBE(current group) with both a FETCH OK and SUBSCRIBE OK, and objects from (current group, 0) to (current group, live edge) are returned in a FETCH stream using those semantics.
My thought was to resolve this with a new message, JOIN, which is decomposed into a FETCH+SUBSCRIBE at a publisher with sufficient local knowledge to do so.
One of the principles the group seemed to agree on is that FETCH is for the past and SUBSCRIBE is for the future. Draft-07 however left in SUBSCRIBE(current group) which spans both and seems to violate the principle. I understand that subscribing starting from the current group is likely to be a very common use case, as groups are MOQT join points.
My concern is that all the reasons we decided FETCH semantics were good for past data are being discarded here. If the current group consists of an large number of subgroups or datagrams, the sender can overwhelm the receiver. If the relay has a cache with gaps, we have not explained the interaction.
My strawman is to respond to SUBSCRIBE(current group) with both a FETCH OK and SUBSCRIBE OK, and objects from (current group, 0) to (current group, live edge) are returned in a FETCH stream using those semantics.