Limiting the lifespan of a subscription

[dfischer-tech]

Problem description Hello, one more other thoughts about the subscription. My understanding... A subscription may terminate under the following conditions:

• The "subscriptionExpireTime" has been reached.
• The "maximumNumberOfReports" has been reached. -- (In the context of 3gpp, the subscription could be cancelled, when the last report has been sent, provided that the "cancelInd" parameter is set to "true".)

Should we not limit the "subscriptionExpireTime" to a specific period to ensure that a subscription does not continue indefinitely in the absence of a triggering event? WDYT?

Possible evolution We limit a subscription to a few months

Alternative solution Other time limits - empirical values

[sachinvodafone]

As per my understanding of the subscription process, we have the following scenarios and outcomes based on whether the client provides subscriptionExpireTime and subscriptionMaxEvents in the request. I believe you are referring to Scenario 3, Outcome 4. In this case, it should be at the client's discretion which outcome they need to entertain.

Scenario 1: Client sends both subscriptionExpireTime and subscriptionMaxEvents in the request: Outcome 1: The server may reject the request if the provided subscriptionExpireTime is not acceptable, returning an error response. Outcome 2: The server accepts the request but modifies the subscriptionExpireTime, sending a different expiresAt value in the response. The subscription will end when either expiresAt or subscriptionMaxEvents is reached. Outcome 3: The server accepts the request but does not include expiresAt in the response. The subscription will continue until subscriptionMaxEvents is reached. Outcome 4: The server accepts the provided subscriptionExpireTime. The subscription will end when the first condition (either subscriptionExpireTime or subscriptionMaxEvents) is reached.

Scenario 2: Client sends only subscriptionMaxEvents in the request: Outcome 1: The server includes an expiresAt value in the response, meaning the subscription will end when either expiresAt or subscriptionMaxEvents is reached. Outcome 2: The server does not include an expiresAt value, so the subscription will continue until subscriptionMaxEvents is reached, or the client must initiate a DELETE operation to terminate it.

Scenario 3: Client does not send either subscriptionMaxEvents or subscriptionExpireTime: Outcome 1: The server includes both expiresAt and subscriptionMaxEvents in the response, so the subscription will end when either expiresAt or subscriptionMaxEvents is reached. Outcome 2: The server includes only expiresAt in the response, meaning the subscription will end when expiresAt is reached, or the client must initiate a DELETE operation to terminate it. Outcome 3: The server includes only subscriptionMaxEvents in the response, meaning the subscription will end when subscriptionMaxEvents is reached, or the client must initiate a DELETE operation to terminate it. Outcome 4: The server includes neither expiresAt nor subscriptionMaxEvents, so the subscription will continue indefinitely until the client initiates a DELETE operation to terminate it.

Scenario 4: Client sends only subscriptionExpireTime in the request: Outcome 1: The server may reject the request if the provided subscriptionExpireTime is not acceptable, returning an error response. Outcome 2: The server accepts the request but modifies the subscriptionExpireTime, sending a different expiresAt value and possibly adding subscriptionMaxEvents. The subscription will end when either expiresAt or subscriptionMaxEvents is reached. Outcome 3: The server accepts the request but does not include expiresAt in the response, possibly adding subscriptionMaxEvents. The subscription will continue until subscriptionMaxEvents is reached. Outcome 4: The server accepts the provided subscriptionExpireTime and may add subscriptionMaxEvents. The subscription will end when the first condition (either subscriptionExpireTime or subscriptionMaxEvents) is reached.

[dfischer-tech]

Hi @sachinvodafone

Thank you for the comprehensive explanation of all the scenarios. Please excuse my delayed response, I was on vacation for the past three weeks.

Yes, I was referring to Scenario 3, Result 4, the case where it is at the client’s discretion to determine which result to consider. My point was simply to highlight that subscriptions, which are not terminated via the client (DELETE operation), could potentially be forgotten and remain indefinitely on the server.

I was suggesting the idea of introducing a maximum lifespan limit for a subscription. (e.g. one year, or 5 years - depending on the subscription use cases and experiences)

However, I am also fine with the server-side handling this by automatically deleting subscriptions older than x years.

Best regards,

[bigludo7]

Hi @dfischer-tech @sachinvodafone For me our model allow server to manage this. As server you can enforce via the expiresAt in the response a lifespan. I'm not confortable to provide a limit in the yaml because it's depending on the UC.

For UC where you use geofencing to track supposedly unmovable device you'll probably prefer to not have expiration date, while for logistical container tracking perhaps the geofencing could be only useful for a couple of days.

So I do not think we need to update our yaml but probably @sachinvodafone explanation should be kept somewhere for future reference.

[dfischer-tech]

Thx - ok - I'm fine with this.