Clarification on Subscription Process Responses

[sachinvodafone]

HI Team ,
I would like to confirm the following:

Scenario 1: When a client creates a subscription for devices, the process is asynchronous. If the client requests the subscription status for all devices and some subscriptions have been completed while others are still in progress, what response will the client receive? Will the response include information only about the completed subscriptions, or will it also indicate that the remaining subscriptions are still being processed (i.e., a partial response showing that processing is ongoing)?

Scenario 2: When a client attempts to retrieve the subscription of specific devices using a “subscription ID” and the subscription has already been deleted or expired, what response can the client expect?

[maxl2287]

Responding to your scenarios:

Scenario 1: As of now you cannot create one subscription for multiple devices. You can create a subscription including multiple subscription-types to subscribe on for one device.
Based on the current definition, you can as of now just create one subscription on a type per request.
Lets imagine we allow the client to subscribe to multiple types within one request for a device asynchronously.
The client will receive a subscriptionId as an outcome, while the subscription-creation process is still ongoing.

When the client requests then GET /subscriptions/{subscriptionId}, then you will get the subscription model, including the current status.
The status is described as:

        status:
          type: string
          description: |-
            Current status of the subscription - Management of Subscription State engine is not mandatory for now. Note not all statuses may be considered to be implemented. Details:
              - `ACTIVATION_REQUESTED`: Subscription creation (POST) is triggered but subscription creation process is not finished yet.
              - `ACTIVE`: Subscription creation process is completed. Subscription is fully operative.
              - `INACTIVE`: Subscription is temporarily inactive, but its workflow logic is not deleted.
              - `EXPIRED`: Subscription is ended (no longer active). This status applies when subscription is ended due to `SUBSCRIPTION_EXPIRED` or `ACCESS_TOKEN_EXPIRED` event.
              - `DELETED`: Subscription is ended as deleted (no longer active). This status applies when subscription information is kept (i.e. subscription workflow is no longer active but its meta-information is kept).
          enum:
            - ACTIVATION_REQUESTED
            - ACTIVE
            - EXPIRED
            - INACTIVE
            - DELETED

In your case the status will be "ACTIVATION_REQUESTED", when not all subscriptions are partial active.
So you may receive already callbacks, but maybe for some type-subscriptions not.

Scenario 2: This depends on the provider implementation. It's up to the provider to decide, if it deletes directly the subscription after it was deleted by the user or expired. But in such cases a final subscription-ends-event will be send to the sink / webhook.
If this is already deleted and the clients request for this subscription, then the provider can either:

a. Response with 404 that the resource is not anymore found
b. The resource is not yet deleted. The provider can respond then with 200 - OK and the status: DELETED or EXPIRED.

[sachinvodafone]

1. on "ACTIVATION_REQUESTED" for synchronous response (POST /subscriptions ) : the expectation is that the subscription creation and activation should happen immediately. Therefore, using "ACTIVATION_REQUESTED" as a status in a synchronous context would indeed be confusing and not typically appropriate and it must be "ACTIVE" in response.
2. On the other hand, in an asynchronous request scenario:The "ACTIVATION_REQUESTED" : status makes sense because it indicates that the subscription creation request has been received and is being processed, but the activation is not immediate.
3. In case of "ACTIVATION_REQUESTED" , I am unable to relate "startsAt" and "expireAT" attributes. When a subscription is in "ACTIVATION_REQUESTED" state, it means that the subscription creation process has been initiated but is not yet complete.
   Typically, during this phase, the exact start and expiration times may not be known or finalized because the subscription itself is not yet active.
4. In above example for scenario 1 for "asynchronous" request , when the client requests then GET /subscriptions/{subscriptionId} , user may get "ACTIVATION_REQUESTED" . Shouldn't we send the response when it first create the subscription also like : ```
   {
   "subscriptionId": "550e8400-e29b-41d4-a716-446655440000",
   "status": "ACTIVATION_REQUESTED"
   }

[maxl2287]

About 3: Exactly. startsAt means the actual start of the subscription, with the start of the subscription-creation process. expiresAt is just used, when either defined by the subscriptionExpireTime set by the Client or when the Telco Operator defines an expiration time.

About 4: Sending the initial response with a status of ACTIVATION_REQUESTED when the subscription is first created might lead to incorrect expectations.

Imagine the scenario where, during the short time between the initial request and the response being sent to the client, the asynchronous process completes successfully, and the subscription status becomes ACTIVE. If the API still responds with ACTIVATION_REQUESTED, it would provide outdated information to the client. This could lead to confusion, as the client would not be aware that the activation has already been completed.

[sachinvodafone]

On Point 3: As per the API design guideline, startsAt is defined as the 'Date when the event subscription will begin/began.' However, it does not specify whether this refers to the start of the subscription creation process or the actual time when the subscription becomes active, which is caused a confusion to me.

On the top if Point 2 statement is correct that "ACTIVATION_REQUESTED" will be valid for only "asynchronous" request then startAT and expireAT will not be relevant at all.

Point 4: In this case, the 'ACTIVATION_REQUESTED' status wouldn't be relevant at all, as the race condition will always be a concern.

[maxl2287]

Point 3: I aggree. Maybe this is also something what can be requested on Commonalities.

[sachinvodafone]

Created a discussion on commonalities camaraproject/Commonalities#244