Proposal: Next CAMARA Functional Differences Whitepapers — Research Summary and Prioritized Repo-Led Candidates

[albertoramosmonagas]

Background

The recent CAMARA whitepaper “CAMARA APIs: Functional Differences” generated strong external engagement and proved that focused comparison papers can help API consumers understand which API to use, when, and why.

The key lesson is that these papers should work as decision guides, not as API catalogues.

Objective

This issue proposes the next candidate topics for similar CAMARA whitepapers and asks the Marketing Working Group to confirm the recommended prioritization.

Recommendation

The proposal is to prioritize focused API-family whitepapers before broader vertical whitepapers.

Focused papers are easier to coordinate, more practical for API consumers, and more likely to provide clear market value.

Proposed priorities

Priority	Whitepaper proposal	Scope	Repository issue
P1	CAMARA Location APIs: Functional Differences	Location Retrieval, Location Verification, Geofencing Subscriptions	camaraproject/DeviceLocation#412
P2	CAMARA Device Status APIs: Which Signal to Use When	Device Roaming Status, Device Reachability Status, Connected Network Type, and related subscription APIs where relevant	camaraproject/DeviceRoamingStatus#83
P3	CAMARA Mobility Analytics APIs	Population Density Data, Region Device Count	camaraproject/PopulationDensityData#127

Rationale

P1 — Location APIs is the strongest next candidate after the ongoing CQM work. The APIs are closely related but answer different questions: retrieve location, verify location, or subscribe to location events. This creates a clear and useful comparison for API consumers.

P2 — Device Status APIs is a good second candidate because it can clarify the difference between device reachability, roaming status, connected network type, and related event-based capabilities.

P3 — Mobility Analytics APIs should be treated separately from individual device location APIs. Population Density Data and Region Device Count are about aggregated regional insights, with different semantics, buyers, and use cases.

Why not full vertical whitepapers now?

Full vertical whitepapers may be useful later, but they are not recommended as the immediate next step because they would require broader coordination, mix APIs with different maturity levels, and risk becoming generic catalogue documents.

A better sequence would be:

1. Create focused API-family whitepapers.
2. Validate them with the relevant technical groups.
3. Use them later as building blocks for broader vertical synthesis papers.

Requested input from Marketing WG

Feedback is requested on:

1. whether the proposed repo-led approach is appropriate;
2. whether the priority order is correct;
3. whether full vertical whitepapers should be considered only later;
4. who from Marketing should support the next whitepaper.

CC: @camaraproject/marketing_codeowners, @camaraproject/marketing_maintainers

[albertoramosmonagas]

@MarkusKuemmerle I have closed the current issues on the different repos because we'll first need to discuss them in the TSC to set priorities. Sync26 is coming up, and we don't want participants to lose focus on the work ahead. Once they've been discussed in the TSC, they will be reopened.