Skip to content

r4.1

Pre-release
Pre-release

Choose a tag to compare

View all tags
@camara-release-automation camara-release-automation released this 20 Aug 10:09
r4.1
1f6f44d
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Release Notes

This release candidate contains the definition and documentation of

  • qos-profiles 1.2.0-rc.3
  • qos-provisioning 0.4.0-rc.1
  • quality-on-demand 1.2.0-rc.3

The API definition(s) are based on

  • Commonalities r4.3 (0.8.0)
  • Identity and Consent Management r4.2 (0.5.0)

qos-profiles 1.2.0-rc.3

qos-profiles 1.2.0-rc.3 is a release-candidate version of this API.

Changes documented below are compared to version 1.1.0.

Breaking changes

  • N/A

Added

  • N/A

Changed

  • Aligned the API and its test definitions with CAMARA Commonalities r4.3 (0.8.0) by @RandyLevensalor in #575
    • Common definitions are reused via $ref into code/common/CAMARA_common.yaml (openId, x-correlator, Device, ErrorInfo, and the generic 400/401/404/429 error responses); the 403, 404 and 422 responses of this API remain local code subsets, as the common definitions list codes that cannot occur here
    • Added the mandatory info.description sections (authorization and authentication, additional error responses, request body strictness) and set x-camara-commonalities to 0.8.0
    • Added maxLength and maxItems constraints to QosProfile.description, Availability and its networks array, countryName, and the retrieveQoSProfiles 200 response array
    • Aligned both test definition files with the r4.3 sample service template and added 429 and invalid x-correlator scenarios

Fixed

  • Corrected the targetMinDownstreamRate description by @tlohmar in #543
  • Removed the redundant format: string from the QosProfileName schema by @eric-murray in #549
  • Standardized on the term API consumer (replacing developer) throughout the API description by @tlohmar in #547
  • Used the term QoS Session systematically throughout the API description by @tlohmar in #574

Removed

  • N/A

qos-provisioning 0.4.0-rc.1

qos-provisioning 0.4.0-rc.1 is a release-candidate version of this API.

Changes documented below are compared to version 0.3.0.

Breaking changes

  • The sink credential model is narrowed from PLAIN, ACCESSTOKEN, REFRESHTOKEN to ACCESSTOKEN, PRIVATE_KEY_JWT, following SinkCredential in CAMARA_event_common.yaml of Commonalities r4.3, by @jlurien in #580
    • Listed for awareness: the PLAIN and REFRESHTOKEN values, and the PlainCredential and RefreshTokenCredential schemas, were part of the published 0.3.0 schema and are no longer accepted.
    • A previously compliant API consumer is not affected. The 0.3.0 definition already stated that sinkCredential.credentialType MUST be set to ACCESSTOKEN, so no well-behaving client sent the removed values. Assessed against the previous public API contract, as required by the CAMARA API Design Guide, the change does not restrict well-behaving clients.

Added

  • Added the PRIVATE_KEY_JWT sink credential type and the corresponding PRIVATE_KEY_JWT_NOT_CONFIGURED 422 error code by @jlurien in #580

Changed

  • Aligned the API and its test plan with CAMARA Commonalities r4.3 (0.8.0) by @jlurien in #580
    • Device, DeviceResponse, ErrorInfo, the x-correlator parameter and header, and the generic error responses are reused via $ref into code/common/CAMARA_common.yaml; the API-specific CreateAssignment400, AssignmentConflict409 and CreateAssignment422 responses remain local
    • CloudEvent, SinkCredential and AccessTokenCredential are reused via $ref into code/common/CAMARA_event_common.yaml, with the event expressed as a CloudEvent subtype carrying its own event type enum
    • Added the mandatory info.description sections (authorization and authentication, additional error responses, request body strictness) and set x-camara-commonalities to 0.8.0
    • Added maxLength constraints to AssignmentId, BaseAssignmentInfo.sink and AssignmentInfo.startedAt

Fixed

  • Corrected the required property of EventStatusChanged.data from qosStatus to status, matching the actual property name, by @jlurien in #580
  • Added the missing type on the CloudEvent and Status schemas by @hdamker in #555
  • Removed the redundant format: string from the QosProfileName schema by @eric-murray in #549
  • Corrected the typo "ssignment" to "assignment" by @Kevsy in #515
  • Standardized on the term API consumer (replacing developer) throughout the API description by @tlohmar in #547
  • Corrected the externalDocs.description wording by @hdamker in #595

Removed

  • Removed the PlainCredential and RefreshTokenCredential schemas and the PLAIN and REFRESHTOKEN credential types by @jlurien in #580 (see breaking changes above)

quality-on-demand 1.2.0-rc.3

quality-on-demand 1.2.0-rc.3 is a release-candidate version of this API.

Changes documented below are compared to version 1.1.0.

Breaking changes

  • The sink credential model is narrowed from PLAIN, ACCESSTOKEN, REFRESHTOKEN to ACCESSTOKEN, PRIVATE_KEY_JWT, following SinkCredential in CAMARA_event_common.yaml of Commonalities r4.3, by @hdamker in #579
    • Listed for awareness: the PLAIN and REFRESHTOKEN values, and the PlainCredential and RefreshTokenCredential schemas, were part of the published 1.1.0 schema and are no longer accepted.
    • A previously compliant API consumer is not affected. The 1.1.0 definition already stated that sinkCredential.credentialType MUST be set to ACCESSTOKEN, so no well-behaving client sent the removed values. Assessed against the previous public API contract, as required by the CAMARA API Design Guide, the change does not restrict well-behaving clients.

Added

  • Allowed application servers to be identified by a list of single IPv4 and IPv6 addresses, in addition to a contiguous set of addresses within a subnet, and added test cases for it, by @eric-murray in #522 and #587
  • Added the PRIVATE_KEY_JWT sink credential type and the corresponding PRIVATE_KEY_JWT_NOT_CONFIGURED 422 error code on createSession by @hdamker in #579

Changed

  • Aligned the API and its test definitions with CAMARA Commonalities r4.3 (0.8.0) by @hdamker in #579
    • openId, x-correlator, Device, DeviceResponse, ErrorInfo and the generic error responses are reused via $ref into code/common/; the API-specific code subset error responses remain local
    • Added the mandatory info.description sections (authorization and authentication, additional error responses, request body strictness) and set x-camara-commonalities to 0.8.0
    • Added maxLength, maxItems, minimum, maximum, format and pattern constraints to the remaining local schemas. duration intentionally keeps no API level maximum, as the limit is the maxDuration of the QoS Profile
    • Aligned the QoS status change notifications to the CloudEvents model, consuming the shared CloudEvent and SinkCredential from code/common/CAMARA_event_common.yaml
    • The sinkCredential.credentialType enum is narrowed to ACCESSTOKEN and PRIVATE_KEY_JWT (see breaking changes above)
    • Port now references the common schema with minimum: 1; the previous local copy allowed 0, which is not a usable flow port. Assessed against the previous public API contract, this makes a domain-limited bound machine-readable and rejects no request a well-behaving client would send
    • Aligned the five test definition files, adding 429 and invalid x-correlator scenarios
  • Added dedicated 400 error responses for getSession and deleteSession, so that error codes which cannot occur on those operations are no longer documented, by @maxl2287 in #578
  • Clarified that createSession may return 201 with qosStatus UNAVAILABLE and statusInfo NETWORK_TERMINATED when the network determines during session creation that the requested QoS cannot be provided, and broadened the NETWORK_TERMINATED description accordingly, by @hdamker in #576

Fixed

  • Added explicit response examples for the extend session endpoint by @mohdfarhanakram in #538
  • Added the missing type on the CloudEvent schema by @hdamker in #555
  • Removed the redundant format: string from the QosProfileName schema by @eric-murray in #549
  • Standardized on the term API consumer (replacing developer) throughout the API description by @tlohmar in #547
  • Used the term QoS Session systematically throughout the API description by @tlohmar in #574
  • Removed a redundant sentence on authentication, which is covered by the dedicated section, by @AxelNennker in #551

Removed

  • Removed the PlainCredential and RefreshTokenCredential schemas and the PLAIN and REFRESHTOKEN credential types by @hdamker in #579 (see breaking changes above)

Full Changelog: r3.2...r4.1

Contributors

RandyLevensalor, AxelNennker, and 7 other contributors
Assets 2
Loading