DRAFT AGENDA
...
- PR #273 feat: add the
statusInfoas parameter to theSessionInfo- PR to resolve issue #267 within v0.11.0
- Tbe merged after v0.10.1 patch release is done
- PR #275 Upping the checkout action in the swagger validation to remove a warning
- Ready to be merged?
- Any further issues regarding linting to be opened?
- PR #228 and #217 still in draft mode.
New Issues
Release planning v0.11.0 / v.1.0.0?
- New sequence towards a "public release" (on our example 0.11.0)
- 0.11.0-alpha.n ... optional releases during development phase
- 0.11.0-rc.n ... sequence of release candidates
- Public release either
- 0.11.0 or
- 1.0.0, depending on fulfilment of criteria and TSC decision
- Milestones
- ...
Existing Issues ()
- #272 Maximum duration 86400 in SessionInfo cannot support 'Extend Session Duration'
- Addressed by PR #277
- #271 X-Correlator required within OAS definition of QualityOnDemand API
- As of last meeting
- Related to this is clarification being discussed at camaraproject/Commonalities#164
- Decision: We will wait for the clarification in Commonalities
- #268 Provision mode for QoD
- As of last meeting:
- The proposal is about introducing a new API for permanent provisioning of a QosProfile. Session will not limited in duration and will be started when a device opens the defined flow.
- Enhancement or even new API - would a discussion in API Backlog make sense?
- Arguments: the API could be considered as a different product. The behaviour will be different and the API will most probably require a different charging model
- One new comment from Kevin Smith within the issue
- Action: API proposal template to be filled for this API (at least describing the differences to QoD Session API) Jorge Garcia Hospital Jose Luis Urien Pinedo
- The template is available here: https://github.com/camaraproject/WorkingGroups/blob/main/APIBacklog/documentation/API-proposal-template.md
- As of last meeting:
- #267 Polling for statusInfo in GET /sessions/{sessionId} not possible
- Bug within v0.10.0
- PR #269 created as short-term patch and merged
- PR #273 created as resolution within v0.11.0 (not to be merged before v0.10.1 patch release)
- #265 Proposal to split QoS Sessions and QoS Profiles into two separate API definitions
- As of last meetings:
- Jose will prepare a PR, just the split without any further changes (incl. copying schemas, decision about common file later)
- PR will be created (only) after the patch release v0.10.1
- Discussion of basepath within the issue (comment from Jose):
- qos-profiles agreed for the profiles.
- v0.11.0 as version for both APIs (as the same functionality was already available in v0.10.0)
- qod or qod-sessions or qos-sessions or quality-on-demand?
- Request for action: please raise your opinions within the issue
- As of last meetings:
- #257 Error behaviour when session cannot be created due to "time cap" limitation
- As of last meeting: PR will be created by Jose.
- No update, waiting for #265
- #249 Duration in QosProfile and SessionInfo
- #265 to be done first
- #245 Update and enhance test definition file for QOD API
- As of last meeting:
- Jose has opened a new issue in Commonalities with request for some additional guidelines (#158)
- No update (no Commonalities meeting in between)
- As of last meeting:
- #244 Align securitySchemes and security of QOD API spec with IdentityAndConsentManagement
- No update; #265 to be done first (split of APIs)
- #238 Updating the project scope in the ReadMe
- see PR #255 above; closed
- #194 Add Application Function Id (afId) or Sponsor Id
- As of last meetings:
- New comments were added within the issue camaraproject/IdentityAndConsentManagement#126 (opened by Syed), to be reviewed.
- Syed will investigate into TMF 931.
- Akos/Syed: backend service will not necessary get the client id via the access token. This might justify to add an application id within the payload.
- No update
- As of last meetings:
- #166 Extend QoS Profile queries to list profiles based on specific users or devices
- As of previous meetings:
- #265 to be done first (split of APIs)
- More clarifications on subscription will be added by Emil
- Description of parameters/filters within the issue needed
- No update
- As of previous meetings:
- #101 List endpoint for active sessions of authenticated user
- As of previous meetings:
- At least two different use cases
- As described originally within the issue: API consumer wants to get a list of open sessions across different subscribers
- within result would be only session created by the API consumer itself
- Herbert: in this case the API consumer will not get additional (personal) information from this endpoint which they haven't received already earlier (during session creation). Potentially possible with 2-legged token?
- Use case added by Jose: API consumer wants to get a list of sessions which are (potentially) already opened for a specific device
- Would require a 3-legged token and potentially consent from end-user?
- As described originally within the issue: API consumer wants to get a list of open sessions across different subscribers
- Discussion to be continued within the issue
- At least two different use cases
- Discussion to be continued based on the summary in https://github.com/camaraproject/QualityOnDemand/issues/101#issuecomment-2015041284
- No update.
- As of previous meetings:
...