Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New APIproposal_CapabilitiesandRuntimeRestrictions_T-MobileUS.md #74

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

New APIproposal_CapabilitiesandRuntimeRestrictions_T-MobileUS.md #74

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions ...tion/API proposals/APIproposal_CapabilitiesandRuntimeRestrictions_T-MobileUS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
| **Field** | Description |
| ---- | ----- |
| API family name | Capability and Runtime Restrictions |
| API family owner | T-Mobile US |
| API summary | CAMARA Service APIs are designed with many optional parameters and features. It’s unreasonable to expect each API Producer (i.e. Operator) to support all these optional parameters. In addition, some supported features and parameters may not be enabled at Service API invocation time, based on network state, who might be invoking and/or for whom/which device, location, …) There is currently no mechanism to exchange such information with API Consumers (i.e. Application Service Providers (ASP)/Developers/Aggregators) and keep the CAMARA APIs the same across the Exposure Gateways. <br /> API Family is intended to cover the following areas:<br />1. Exchange of runtime restrictions (i.e. not supported parameters/features)<br />2. Exchange of capabilities (i.e. enabled/not enabled a set of parameters/features)<br />3. Topology exchange (i.e. abstraction) for capability-footprint association<br /><br />For the first area following examples can be given:<br />1. Device identifier in QoD can be of type Phone Number, IPv4 Address, IPv6 Address, Network Access Identifier (NAI). One operator may support all of these identifiers in which case there will not be a need to list any restrictions towards the schema in the QoD API, however another operator supports only Phone Number, thus will need to inform ASPs not to use them.<br />2. If there is a regulation specific maximum accuracy level that must be set greater than the minimum Radius defined in ‘location-retrieval.yaml’, operator must be able to overwrite this new minimum.<br /><br />For the capabilities following example can be given:<br />1. While the operator may not support only one of the default set of QoD Profiles, at the time of invocation, one ore more of the supported QoD profiles may not be available due to network state and/or location. Invocation of QoD with not-enabled QoD profile will result in error and lead to bad developer experience. Operators must be able to efficiently exchange this information.|
| Technical viability | Yes (reuse of JSON Validation Schema with little to no impact to current API designs) |
| Commercial viability | This is not a product, but rather Service Management API which falls under CAMARA purview.|
| YAML code available? | YES |
| Validated in lab/productive environments? | In progress |
| Validated with real customers? | NO |
| Validated with operators? | NO |
| Supporters in API Backlog Working Group | T-Mobile US |