2025-10-15 Population Density Data - Meeting Minutes
CAMARA Population Density Data API - Follow-up meeting #26 - 2025-10-15
October 15th, 2025
Attendees
Name | Company |
|---|---|
@Jorge Garcia Hospital | TEF |
@Alberto Ramos Monaga | TEF |
@Violeta González | TEF |
@Rafal Artych | DT |
@Patrice Conil | Orange |
|
|
|
|
Approval of previous meeting minutes & documentation (1)
Meeting minutes: [Decision]
Agenda
Approval of previous meeting minutes and meeting agenda
Open issues and PRs
Agenda 1: Clarifications for asynchronous response in callback #533
Agenda 2: Spring26 meta-release scope
Timeline and next steps
AoB
Open Issues & PRs
# | Company | Summary |
|---|---|---|
TEF | Draft until next meta-release: Delete additional text for RFC date time format | |
TEF | Issue (Release Management): The asynchronous response in PredictiveConnectivityData and Population Density Data does not comply with Commonalities r3.3 (uses application/json instead of CloudEvents). Status: An issue (#533) has been created in the commonalities group to address this issue. Once a decision has been made, it will be applied to this issue. | |
Orange | Some model names use SNAKE_CASE in place of CamelCase: NO_DATA, LOW_DENSITY, and DENSITY_ESTIMATION models do not respect naming conventions defined in Commonalities |
API proposal review (2)
Agenda 1: Clarifications for asynchronous response in callback #533
Problem description
Some APIs such as Population Density and Predictive Connectivity Data support asynchronous responses for large or time-consuming requests by allowing a sink (callback URL).
Current CAMARA guidelines define two subscription types — instance-based (implicit) and resource-based (explicit) — and specify that event notifications use CloudEvents.
The open question is whether asynchronous responses (triggered once per request) should also adopt the CloudEvents structure, or remain simple JSON payloads.
Discussion summary
Patrice Conil and Pedro Diez both argued that an asynchronous response is not an event but rather a deferred response, which happens once and whose value lies in the payload, not in the occurrence of the event itself. Therefore, using CloudEvents adds unnecessary overhead and does not conceptually fit this case.
The group agreed that the key question is whether CAMARA should mandate CloudEvents as the default envelope for asynchronous responses, or allow plain JSON responses for simplicity.
Next step
→ The group will discuss and reach a consensus on this topic in an upcoming meeting before applying any decision or documentation update.
Agenda 2: Spring26 meta-release scope
AoB (4)
N/A
Discussion Summary
# | Summary | Status/conclusion |
|---|---|---|
N/A | N/A | N/A |
Next steps
N/A