Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
JoachimDahlgren opened this issue Sep 25, 2024 · 3 comments
Labels
documentation Improvements or additions to documentation Spring25 subscriptions

Comments

@JoachimDahlgren
Copy link

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)
@JoachimDahlgren JoachimDahlgren added the documentation Improvements or additions to documentation label Sep 25, 2024
@jlurien
Copy link
Contributor

jlurien commented Sep 26, 2024

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
Copy link
Collaborator

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

@bigludo7
Copy link
Collaborator

Agree that we should not impose a limit.

I can add a sentence to clarify this point in the guideline.

@rartych could you affect this one to me please.

bigludo7 added a commit to bigludo7/Commonalities that referenced this issue Oct 10, 2024
Add information for exiresAT + limitation to subscriptionMaxEvent and subscriptionExpireTime.
Fixes camaraproject#303
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation Spring25 subscriptions
Projects
None yet
Development

No branches or pull requests

5 participants