'Expires' in SUBSCRIBE_OK makes it unclear what the final group and object will be

[ianswett]

Subscriptions always end with either SUBSCRIBE_FIN or SUBSCRIBE_RESET, except when they Expire and then no control message is sent. This complicates the state machine and adds another case to handle.

The subscriber needs to start a timer or something similar to know when the subscription will end, and it doesn't get to know the final group or object ID.

[kixelated]

I'd like to get rid of expires, but my thought was that it's a signal to SUBSCRIBE again before the timeout to avoid interruption. Otherwise, there would be a SUBSCRIBE_RESET with an "expired" error code containing the final group/object.

[ianswett]

I agree that a subscriber can deal with this field, but I don't know what purpose it serves for the publisher/relay? It's different from an idle connection timeout, because assuming there is data flowing for the subscription, it would never go idle.

Unlike QUIC, I don't see value in having a 'silent close' for subscriptions, because typically we expect subscriptions to have data flowing at a somewhat regular interval.

Also, there's no guarantee that the subscription will last until the expiry time, it can always end early with SUBSCRIBE_FIN or SUBSCRIBE_RESET.

[ianswett]

Based on last week's conversation, the Expires field doesn't change the state of the subscription by itself, a publisher would still have to send a FIN or RESET to close it.

It's still unclear as to what a subscriber should do with it. There was a fair amount of discussion around refreshing one's authorization. It's unclear if that would be done with a SUBSCRIBE_UPDATE or something similar or via UNSUBSCRIBE/SUBSCRIBE?

[fluffy]

Would the solution to this be when the relay expires a subscription, it sends a control message ? This might all become clearer once we figure out re authentication but at a high level, I want some way that the relays can clean up state on a time line that is under relay control particularly when poorly implemented clients make subscriptions.

[afrind]

I think this was resolved by #406 -

A subscription remains active until the publisher of the track terminates the track with a SUBSCRIBE_DONE (see {{message-subscribe-done}}).