...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
DRAFT
...
MINUTES
Date
Attendees & Representation
...
- Issue: Align security scope with guideline
- Along with previous issue: Based on the new explicit subscriptions guideline in commonalities, change name of geofencing API to include the keyword subscriptions
- PR: update base-path & security-scope for geofencing-subscriptions → fix both PRs, the old one changing the API name and the new one adapting also event name.
- Ready for merge?
- Yes !
- Issue: [Location-Retrieval]: add
POINTas possible Location response- Some comments on the issue. Minimum right now is a CIRCLE with radius=1m, Is it not enough?
- From previous meeting:
- Having the radius as 1 does not seem like a practical problem since even GPS often have a few meters of error margin
- From a documentation perspective clients might think that using a point the precision will be high, which is not the case
- We don't have use cases for precision lower than 1 meter
- Decision: Keep the discussion open. Using circle with 1m radius as points seems enough
- Related with location-verification:
- Javier asks if the WG is open to lower the 2km minumum of radius for CIRCLE location-verification
- There were issues open regarding this topic in the past where several problems and discussions raised
- Javier will open a new issue to continue the discussion
- Discussion:
- Discard point and rely on Circle?
- Agreement from Jose Luis Urien Pinedo Joachim Dahlgren and Ludovic Robert to consider that 1m radius will be good enough (and no need for Point)
- Should we lower minimum radius for location-verification, Javier Carro ?
- Javier Carro has still some discussion with legal team about privacy issue
- Keep this point open.
- Discard point and rely on Circle?
...
- Subscription related issues → Dedicated workshop took place
Geofencing API - Add Subscription type 'area-left-or-entered' to subscribe to both event in one time
- Geofencing API - Defining a standard behavior for first event
- Issue in Commonalities Issue 140
- Proposal to tackle open subscription issues Common proposal to tackle subscription-based open issues. · Issue #185 · camaraproject/Commonalities (github.com) - mains points:
- Align our subscription model with CloudsEvents subscriptions one
- Introduce a
statusattribute in the template as we have fair UCs that can leverage this (Retrieve expired subscriptions for monitoring, deactivate a subscription if an user revoked her/his consent, etc...). API subproject could decide to use it or not. - Improve the model to allow consumers to subscribe to more than one event types with a single subscription but at least for the first meta-release we enforce to have only event type per subscription. After this first meta release decision to handle several event types in one subscription request should be discussed at API sub projet level
- Add
filtersand it's up to API Project to use it. We recommend to be very cautious as it add complexity so it should be keep for very relevant UC. - Add
initialEventinconfigas well to manage request to get event when current situation of a device corresponds to the subscriptions type. .
- A template yaml is available for review here: Create subscription-notification-template.yaml by bigludo7 · Pull Request #189 · camaraproject/Commonalities (github.com)
- Action: Once PR merged Ludovic Robert will close this issue
...