DRAFT AGENDA

Date

22 Oct 2024

Attendees & Representation

Community: 

Agenda

Antitrust Policy

• Approve previous meeting minutes

  • Approved ?

• Open issues and PRs

Minutes

Release patch r1.3

• To be considered. Candidate fixes:

  • Issue:Update errormessage for unsupported device identifieres Small typo in GENERIC_422_UNSUPPORTED_DEVICE_IDENTIFIERS - example, PR: Update errormessage for unsupported device identifieres

    • New PR reviewed, it could be merged into main

  • Fix links for geofencing-subscriptions in README, add links also to Changelog

  • Decision: We can wait to have something more relevant to create a new patch as it is cosmetic.

  • New issue created to have a tracking: Scope for potential patch r1.3

New

• [geofencing-subscriptions]: MultieventSubscriptionNotSupported instead of PermissionDenied.

  • PR: Correct the example for sub - initialEvent and error MULTIEVENT_SUBSCRIPTION_NOT_SUPPORTED and some typos.

  • The name of the example does not correspond with the content

  • Many typos corrected

  • Makes sense to be corrected to main and be potentially added to future patch r1.3

Old

• Issue [Retrieval] What is the expected behavior when maxAge value is above threshold supported by the operator?

  • Answered by Cetin Alpaycetin

  • No further interaction, it could be closed

• Update location-retrieval with add maxSurface management

  • After issue How to understand the response parameter area in the device retrieval API

  • Review and comment

    • Add a note in the yaml for the minimum → Pending Ludovic Robert ?

    • We will wait before to merge to avoid collision with Meta release patch

• Support of Multi-SIM lines in DeviceLocation APIs

  • Derived from camaraproject/Commonalities#302

    • Some new comments but no conclusions

  • Device Location APIs are specially problematic as location is linked to a physical device, not to a phone number 

  • Discussion during last meeting:

    • The issue has a technical aspect  but it is more important for Product Management.

    • For Location-verification probably we can consider that if any device is in 'the zone' then the result will be true. Perhaps same for geofencing.

    • For location-retrieval the issue is more critical as sending back an array of location is probably not a good solution

    • We need to think about UC

    • Action for each company to work with product team to refine the requirement

• The issue to improve Geofencing with LOOSE, MODERATE, STRICT 'flavor' is still open #133

  • From previous meeting: Should be part of the discussion for next version.

Waiting for commonalities

• Add an “Area” data-type into CAMARA_common.yaml

  • No new comments

  • From previous meeting: 

    • related issue in Commonalities

    • New PR in Commonalities: https://github.com/camaraproject/Commonalities/pull/315

      • To be reviewed

• Evolution of subscription guidelines that may affect geofencing-subscriptions:

  • Resource-based subscription – GET /subscriptions using a 3-legged access token

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

  • Ludovic Robert is working on a global PR for commonalities.

    • Any update?

AOB

From latest TSC:

• Proposal to schedule all meeting within CAMARA anchored on UTC

  • See https://github.com/camaraproject/Governance/issues/164

  • Decisions:

    • No opposition to switch to UTC → All meetings will be anchored in UTC

    • Each community decides on which UTC time they want to anchor their meeting

For DeviceLocation current slots are:

• During CEST: 7:00 UTC → If we choose this one all year around, meetings would be at 9:00 during CEST and at 8:00 during CET

• During CET: 8:00 UTC→ If we choose this one all year around, meetings would be at 10:00 during CEST and at 9:00 during CET

Action: Take a decision during meeting or open a discussion in Github

Action items