Resource-based subscription – guidelines for expiration time set by API operator policy

[JoachimDahlgren]

Problem description I have gotten an ask from our development team if CAMARA has specified a default max expiration time for subscriptions. Reading the API-design-guidelines I believe that is not the case.

Bringing this question to the Device Location and Device Status working groups the common thinking seems to be that it is up to the operator of the API to decide if such a default max expiration time should be in use or not. If such restrictions are implemented this could then be communicated back to the API invoker through the expiresAt attribute.

Today there are multiple ways of describing the expiresAt attribute and it is not explicitly stated that there might be a max value enforced by the operator.

• API-design-guidelines.md - “Date when the event subscription will expire. This attribute must not be present in the POST request as it is provided (optionally) by API server”
• Notification Subscription Template - “Date when the event subscription will expire. Only provided when subscriptionExpireTime is indicated by API client or Telco Operator has specific policy about that.”

Expected action For clarity I propose that the guidelines and the notification subscription templates are updated to

1. Clearly state that CAMARA allows an operator policy that limits the time of a resource-based subscription
2. Describe how the existence such a policy is conveyed to the API invoker, for instance through the expiresAt attribute (which then would benefit from an updated and more explicit description)

[jlurien]

It makes sense to add that clarifications if current ones are not well understood. I don't think CAMARA should impose an upper limit globally but we may explicitly indicate that implementations should inform clients about any limit they may have.

[shilpa-padgaonkar]

Fully agree here with @jlurien that Camara should not try to impose an upper limit.