Content Comparison

PR #87: Update Device object handling and description

• Other APIs passing a Device object do this by passing a separate parameter named device, even if that is the only object passed in the request.

• This PR:

  • Updates the Device Identifier API to use this pattern
  • Updates documentation on identifying the device from the access token following the current agreement in Commonalities
  • Updates the API error responses following the current agreement in Commonalities
  • Removes 406, and 5XX errors from the OAS definition, as these errors do not need to be explicitly documented and are not relevant to the API use case

MEETING UPDATES

06 Dec 2024:

• Add examples for different request body scenarios
• Leave open for comments until next meeting

03 Jan 2025:

• Updates since last meeting
  • Request body scenario examples added
  • 406 and 5XX errors removed
  • Remaining error examples updated
• PR to remain open for comments until 17 Jan 2025 

07 Feb 2025 

• Now merged

PR #88: Update LastChecked description

• Update description for lastChecked field to make its meaning clearer

• Fixes Issue #80

MEETING UPDATES

06 Dec 2024:

• No comments during meeting. Update issue to make Ramesh Shanmugasundaram aware of PR.

03 Jan 2025:

• Ramesh happy with proposed wording change
• DECISION: PR can be approved and merged

07 Feb 2025 

• Now merged

PR #90: Use identifier instead of identity

• Use the term "identifier" if an identifier is talked about.

• Operators often use the term "identity" when in fact it is an "identifier". Generally an "identity" and an "identifier" are different. There a several definitions for "identity" e.g. in OIDF, IETF and W3C e.g. "a collection of claims". But identity is never used when an identifier is meant.

• I think we should avoid operator-speak and use "identifier" if it is an "identifier".

MEETING UPDATES

03 Jan 2025:

• IMEI definition reverted to International Mobile Equipment Identity
• PR approved and merged

07 Feb 2025 

• Now merged

PR #91: Update error response schema following Commonalities update

• Update error response schema to comply with Commonalities CAMARA_common.yaml

MEETING UPDATES

03 Jan 2025:

• Wait for PR #87 to be merged and then fix any conflicts with this one.
• Goal is to approve and merged the updated PR before next meeting

07 Feb 2025 

• PR now merged

PR #93: Update test cases for meta-release

• Updates test cases for retrieve-identifier path to be more comprehensive
• Adds new test cases for the retrieve-type path

MEETING UPDATES

07 Feb 2025 

• PR was approved and merged offline

PR #98: Update device-identifier.yaml

• Update ICM authorisation and authentication template to comply with ICM r2.2 0.3.0-rc.1

MEETING UPDATES

07 Feb 2025:

• Approved and merged

PR #99: Update x-correlator definition in device-identifier.yaml

• Commonalities r2.2 requires a pattern to be applied to the x-correlator header.

MEETING UPDATES

07 Feb 2025:

• Approved and merged

PR #94: Release r1.2 (Spring'25 M3)

• Publication of Spring'25 M3 release candidate v0.2.0-rc.1

MEETING UPDATES

07 Feb 2025 

• Reviewed by Release Management (Tanja). Some changes to be made.
• Request for compliance with Commonalities 0.5.0-rc.1 and ICM 0.3.0-rc.1
• Issues / PRs raised following Release Management review:
  • ICM template: #98
  • X-Correlator header pattern: #99
  • Error documentation: #101

PR #101: Update error documentation in info.description

• Update error documentation in info.description

  • Some errors
  • Some details are out of date
  • Better explanation of CAMARA or API specific errors
• Needs to be approved and merged for Spring'25 meta-release

MEETING UPDATES

07 Feb 2025:

• Leave open for comments until end of Tuesday 11 Feb 2025, and then merge before requesting final review of PR #94

PR #89: Remove multi-sim text

• Multi-SIM support is not well-understood and should be "solved" for all CAMARA APIs.

• Multi-SIM support was discussed in several CAMARA API subprojects without solution.

• For interoperability reasons API providers should handle the Multi-SIM case in the same manner.

MEETING UPDATES

03 Jan 2025:

• Eric Murray to propose more generic text describing different options for multi-SIM scenario handling

07 Feb 2025 

• Alternative wording proposed in this comment

PR #92: Use scopes and introduce a pairwise pseudonymous identifier

• This PR proposes two changes to the API definition:

  • Introduction of a third device identifier ppid, which is a pairwise pseudonymous identifier for the device
  • Control of fields included in the response by individual scopes, rather than by a single scope covering all possible response fields

MEETING UPDATES

03 Jan 2025:

• Discussion:
  • PPID as third device identifier is fine, but should be introduced as additional endpoint rather than controlling through scopes
  • A better description of the properties of a PPID is required, in addition to the external link
    • For example, if a new SIM (from the same MNO) is used in the physical device, should the PPID be re-generated?
• Eric Murray to comment in PR

07 Feb 2025 

• Cannot now be merged before Spring'25 meta-release. Leave open in case Axel Nennker wants to revise. Otherwise raise new issue on PPID introduction following Spring'25 meta-release.