Subscription-Issue2: Allow event consumers to subscribe to more than one event types with a single subscription

[shilpa-padgaonkar]

Problem description Currently we expect the event consumers to create a subscription for each event type they want to consume. There are currently discussions in certain subprojects https://github.com/camaraproject/DeviceLocation/issues/138#issuecomment-1894191964 which shows the need where allowing multiple types could offer better experience to the event consumers.

Camara could define a standard way to allow event consumers to subscribe to multiple event types using a subscription, instead of making the event consumer create a new subscription for every single event type.

The "types" array in CloudEvents subscription schema allows a consumer to specify the CloudEvent types eligible to be delivered by the subscription.

Possible evolution Subscription schema could be extended (as in cloudevents subscription) with "types"

Alternative solution

Additional context

149

[bigludo7]

Hello @shilpa-padgaonkar For subscription creation management (as a Telco I'm able to provide this one but not this one), subscription lifecycle management (management of subscriptionMaxEvents in this case), business model (how we manage the subscription should not impact the business model) or for privacy/consent management (how we will be able to indicate that the user deny consent for one of the event type requested), I strongly prefer to keep it simple and stick the type to one.

Of course in future and with more developer feedbacks we can re-open this.

[shilpa-padgaonkar]

Hello @bigludo7 : Thanks for your comments. If I understood correctly, you are fine to use a common subscriptions API but would restrict it to offer just one event type.

If device status subproject (for discussion purpose would only have explicit subscriptions) then we would have 7 distinct API spec files (each spec file would include the subscription related content from the common subscriptions API ) for each of the below event types:

1. roaming-status
2. roaming-on
3. roaming-off
4. change-country
5. connectivity-data
6. connectivity-sms
7. connectivity-disconnected

Each of the above 7 API spec file would have a distinct API name. Is my understanding correct?

[akoshunyadi]

Distinct APIs we would only need if we need different scopes for the different types, right? Otherwise we can use all types in 1 API (in 1 scope).

This issue is also related to the possible filter parameter. If using that, we can define a more generic event types like roaming_status_changed & connectivity_status_changed, so we would have fewer event types per API.

[shilpa-padgaonkar]

@akoshunyadi : I am not sure I fully understand the comment.

In the device status API, (without subscriptions endpoint) there are 2 distinct scopes

• device-status:connectivity:read
• device-status:roaming:read

But when it comes to subscription endpoint (where either roaming or connectivity related event could be requested), there is somehow a common scope defined (which IMHO does not give the true picture): "device-status:subscriptions:create"

And with this subscription any one of the below event types could be subscribed to:

• org.camaraproject.device-status.v0.roaming-status,
• org.camaraproject.device-status.v0.roaming-on,
• org.camaraproject.device-status.v0.roaming-off,
• org.camaraproject.device-status.v0.roaming-change-country,
• org.camaraproject.device-status.v0.connectivity-data,
• org.camaraproject.device-status.v0.connectivity-sms,
• org.camaraproject.device-status.v0.connectivity-disconnected,

This seems to me like some sort of wildcard scope anyway. So when does one decide, that a different scope is needed?

[bigludo7]

Hello To be sure to get your point @shilpa-padgaonkar

Instead of:

  /subscriptions:
    post:
      tags:
        - Device status subscription
      summary: "Create a device status event subscription for a device"
      description: Create a device status event subscription for a device
      operationId: createDeviceStatusSubscription
      security:
        - openId:
            - device-status:subscriptions:create

We should have:

  /subscriptions:
    post:
      tags:
        - Device status subscription
      summary: "Create a device status event subscription for a device"
      description: Create a device status event subscription for a device
      operationId: createDeviceStatusSubscription
      security:
        - openId:
            - device-status:subscriptions:read-roaming-status
            - device-status:subscriptions:read-roaming-on
            - device-status:subscriptions:read-roaming-off
            - device-status:subscriptions:read-roaming-change-country
            - device-status:subscriptions:read-connectivity-data
            - device-status:subscriptions:read-connectivity-sms
            - device-status:subscriptions:read-connectivity-disconnected

Make sense indeed to manage the subscription 'topic' consent from the device user and not the fact that an application developer is authorized to perform the POST operation.

Do we need also specific scope for GET & DELETE /subscriptions.... I'm not sure about this. WDYT?

[shilpa-padgaonkar]

Hello @bigludo7, I imagined more compact naming convention :) but yes, in general this is what I meant (in combination with supporting multiple types). Yes would make sense to add scopes for get and delete subscriptions (but here probably event related info is not needed?).

Another part where I am not so sure is are we creating the right event definition groups? Since we originally had API for device status, this grouping seems straight forward. With additions of new api subprojects like connectivity insights and others, how do we ensure that these groupings are still relevant & events can be discovered and/or do we need some event registry?

[alpaycetin74]

Within the scope of the Geofencing API under Device Location, we tend to think consumers may want to subscribe to more than one event in one request, e.g. "I want to be notified both when the security guard arrives at their post, and leaves their post". I think allowing this capability using an array of events makes it intuitive and scalable.

i.e., I prefer this

subscribe: [event1,event2]

over this:

_subscribe: [event1_and2]

Otherwise, as new events are created, one would also need to create event types to combine the new event with the existing ones.

i.e. in my preferred approach the consumer would just need to add the new event type to the array, if they are interested:

subscribe: [event1,event2,event3]

In the other alternative, one would need to create event3 and all eligible combinations as well:

event3 event1_and3 event2_and3 event1_and2_and3

I don't think this is a user friendly as the first option. Also from the API implementer's perspective, looping over the array and processing each event is probably more straightforward than handling event name combinations.

[PedroDiez]

Hi,

For the time being, we prefer to keep to stick type to one. Agree on some of the rationale provided by Ludovic.

From our view:

• Subscriptions to multiple events may be an scenario not able to be supported by a Telco or even have huge effort to be able to manage it.
• Good points the ones regarding consent management, noy only in creation time but also during subscription lifecycle.

And also from Business view would be needed some aligment/discussion in advance in order how business units from Operators think about applicability / monetization of these models.

[shilpa-padgaonkar]

@PedroDiez and @bigludo7 To address the concerns mentioned by you, I am taking here again the example of device status subproject.

We are not looking currently at a single (generic) subscriptions API which will allow the consumers to subscribe to very distinct event types. We are rather creating different subscription APIs that will offer (very) similar event types that can be subscribed to. As an effort to be more granular, we are also splitting the roaming subscriptions API from the connectivity subscriptions API.

Now, the consumers can only subscribe to connectivity (data, sms, not-connected) event types using a single subscription and for (roaming-on, off, county-change) they will anyway need a different subscription. Also, every event type has its representation in scope. With this new premise, do we still think it will be problematic if the consumer could specify multiple (related) event types when creating a subscription?

WDYT?

The comment above from @alpaycetin74 also points some interest in this direction.

[bigludo7]

Hello @shilpa-padgaonkar, Yes got your point. If we have very granular subscription targeting very close event type my worries about consent or business could be less relevant. The change in Device Status WG moves in this direction.

So I'm wondering if we need to be restrictive on this point.... I mean if a Telco is able to manage multiple event type in one request while another Telco is able to manage only one is there risk on API adoption for you? We change the eventType as an enum but Telco is free to indicate in the documentation that only one eventType should be provided if this telco has specific reason to offer granularity 1,1.

[shilpa-padgaonkar]

Decision to restrict to one type at least for the first meta release