Termination Reason SUBSCRIPTION_DELETED

[daniel-dierich]

Problem description
Hi all, I noticed that as of now there is no Termination Reason defined for the case of the User deleting his subscription.

Possible evolution
I would propose to add the Termination Reason:

SUBSCRIPTION_DELETED - Subscription was deleted by the requester

[gregory1g]

do you mean that application cancelled its subscription to simswap events or the end user terminated its contract with the MNO?

[daniel-dierich]

I mean the first. If an user or application requests to delete the subscription using the API.

[gregory1g]

I see. Looks reasonable for me. But this is a generic use case relevant for all subscription API - one should bring this to commonalities (if it is not there yet).

[daniel-dierich]

I am not sure if it was already brought up in commonalities, but I will check it.
I do know that this is already featured in geofencing and device status. Just for reference:

https://github.com/camaraproject/DeviceStatus/blob/03ff0bf2256b65342f426567b57614e46834ae74/code/API_definitions/device-reachability-status-subscriptions.yaml#L855

https://github.com/camaraproject/DeviceStatus/blob/03ff0bf2256b65342f426567b57614e46834ae74/code/API_definitions/device-roaming-status-subscriptions.yaml#L912

https://github.com/camaraproject/DeviceLocation/blob/6521dffbc3a486e4125082b0a1086b97e143332c/code/API_definitions/geofencing-subscriptions.yaml#L929

[daniel-dierich]

It is already part of commonalities: camaraproject/Commonalities#238

Does this mean it is valid to add to the SimSwap API spec? Should I prepare a PR?

[bigludo7]

@daniel-dierich Yes please !
@fernandopradocabrillo As this value is defined with current commonalities version (Autumn 2024 meta release) this fix could be added in the future r1.4 and not waiting 2.1 right?

[fernandopradocabrillo]

@daniel-dierich Yes please ! @fernandopradocabrillo As this value is defined with current commonalities version (Autumn 2024 meta release) this fix could be added in the future r1.4 and not waiting 2.1 right?

agree! but in theory this is changing the API functionality, maybe we should go for a v0.1.2

[bigludo7]

@daniel-dierich Yes please ! @fernandopradocabrillo As this value is defined with current commonalities version (Autumn 2024 meta release) this fix could be added in the future r1.4 and not waiting 2.1 right?

agree! but in theory this is changing the API functionality, maybe we should go for a v0.1.2

Arghh you're right @fernandopradocabrillo . Perhaps we should keep this one & #175 for next meta release.
It did not change the PR but it avoids to another release.
With all the change on subscription we'll have to craft a v0.2 anyway

WDYT?