Proposal: CAMARA Device Status APIs Whitepaper — Which Signal to Use When

[albertoramosmonagas]

Summary

Following the discussion in TSC, the understanding is that each Sub Project can decide whether and when to pick up possible whitepaper-related topics, with the current priority remaining Sync26.

Based on that, I'm opening this issue to check whether the Device Status Sub Project sees value in a future API-consumer-facing whitepaper explaining the functional differences between the main device-status-related APIs:

• Device Reachability Status
• Device Reachability Status Subscriptions
• Device Roaming Status
• Device Roaming Status Subscriptions
• Connected Network Type
• Connected Network Type Subscriptions

The goal would be to help API consumers understand the difference between reachability, roaming status, connected network type, and the related event-driven capabilities. You can see an example here from a recent CAMARA whitepaper: CAMARA APIs: Functional Differences

Request

This issue is only intended to confirm whether the topic and scope make sense from the Device Status Sub Project perspective. No immediate drafting, review, API change, semantic change, or Sync26-related action is expected from maintainers. If the group sees value in the topic, it can be picked up after the current release priorities, at the pace decided by the Sub Project.

Since the former DeviceStatus repository has been split into separate repositories, this issue is also intended to confirm which repository, if any, should be used as the main coordination point for this topic.

Initial positioning

These APIs expose related but different operational signals. The whitepaper should not become a generic Device Information catalogue. Other APIs such as Device Identifier, Device Data Volume, Subscription Status, or Network Access Management are not proposed as part of the initial core scope.

Questions

1. Does the group see value in this topic from an API-consumer perspective?
2. Is the proposed scope correct?
3. Should subscription APIs be included together with the corresponding retrieval/status APIs, or treated separately?
4. Should any API be added or explicitly excluded?
5. Are there semantic differences, limitations, or implementation constraints that should be captured if this topic is eventually drafted?
6. Which repository should be used as the main coordination point, considering the split of the former DeviceStatus repository?

CC: @camaraproject/marketing_codeowners, @camaraproject/marketing_maintainers, @camaraproject/device-roaming-status_codeowners, @camaraproject/device-roaming-status_maintainers, @camaraproject/device-reachability-status_codeowners, @camaraproject/device-reachability-status_maintainers, @camaraproject/connected-network-type_codeowners, @camaraproject/connected-network-type_maintainers