Subscription & events for Commonalities 0.5.0 #313
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add SUBSCRIPTION_UNPROCESSABLE in terminationReason enum for subscription ends event. Solve camaraproject#243
Explicit subscription-end termination reason usage. Fix camaraproject#243
Update the "sink" property description Fix camaraproject#289
Update the "sink" property descriptionFix camaraproject#289
bigludo7
requested review from
shilpa-padgaonkar,
rartych,
patrice-conil,
RubenBG7 and
PedroDiez
as code owners
Add information for exiresAT + limitation to subscriptionMaxEvent and subscriptionExpireTime. Fixes camaraproject#303
fix line 1757
Proposal for camaraproject#276 - POST /subscriptions response will have only `id` - removed `sinkCredentials` from GET representation
Add a note on combined usage of initialEvent and subscriptionMaxEvents (camaraproject#299)
Add part for: - camaraproject#304 - camaraproject#299 - partial camaraproject#295
Fixe line 1580
PedroDiez
reviewed
Oct 18, 2024
Co-authored-by: Pedro Díez García <[email protected]>
Co-authored-by: Pedro Díez García <[email protected]>
Co-authored-by: Pedro Díez García <[email protected]>
Co-authored-by: Pedro Díez García <[email protected]>
Co-authored-by: Pedro Díez García <[email protected]>
Co-authored-by: Pedro Díez García <[email protected]>
Co-authored-by: Pedro Díez García <[email protected]>
Co-authored-by: Pedro Díez García <[email protected]>
Co-authored-by: Pedro Díez García <[email protected]>
Highlight Subscription status value table
Add link to artifacts/camara-cloudevents/event-subscription-template.yaml
Fix link
Thanks you Pedro ! |
Co-authored-by: Rafal Artych <[email protected]>
PedroDiez
previously approved these changes
Nov 22, 2024
Co-authored-by: Pedro Díez García <[email protected]>
PedroDiez
reviewed
Nov 22, 2024
| - If 3-legged access token is used, the POST and GET responses must not provide any device identifier. | ||
| - If 2-legged access token is used, the presence of a device identifier in the response is mandatory and should be the same identifier type than the one provided in the request. | ||
|
|
||
| Application of data minimization design must be considered by the API working group for event structure definition. |
There was a problem hiding this comment.
If we mandate above that in case of 2-legged access token response must include device identifier, how will the API working groups take decisions about data minimization?
There was a problem hiding this comment.
We have discussed a bit this topic in Device Location sub projet.
If we use the 2-legs the device identifier must be mandatory but then in the subscription answer and in the notification itself we can avoid to send this identifier. I proposed some suggestion here: camaraproject/DeviceLocation#270 like adding a capability for the API consumer to indicate if the device & area information must be part of the event.
I think we probably cannot add more in commonalities for this release due to deadline but we can continue to explore the topic in API sub project. WDYT?
Co-authored-by: Shilpa Padgaonkar <[email protected]>
Co-authored-by: Shilpa Padgaonkar <[email protected]>
Co-authored-by: Shilpa Padgaonkar <[email protected]>
Co-authored-by: Shilpa Padgaonkar <[email protected]>
2 tasks
This was
linked to
issues
Nov 25, 2024
rartych
approved these changes
Nov 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
This PR covers update to subscriptions & events part for Commonalities 0.5.0
Resolution: covered in this PR. Make a proposal in new part 11.7
Resolution: covered in this PR
Resolution: To be done - seems we have an alignement to make device optional. Direct impact with API misuse #259 - Need to be sync with @eric-murray - aligned with Eric PR Update error codes and info.description template for device / phone number identifiers #324
Resolution: covered in this PR. Added a sentence in the yaml and in the DG to clarify us of initialEvent vs subscriptionMaxEvents counting.
Follow the principle of data minimization for events based on explicit subscriptions #295- Adding a section on this topic in the DG document - Check for additional content with @shilpa-padgaonkar. Request with a larger scope thanResolution: Discussion still open in the issue
subscriptionsResolution: Waiting for Support & Aligment of 504 Exception in CAMARA APIs #308 resolution - This one followed by @PedroDiez - Will apply on notification/subscriptions when 308 solved. 504 is not part of the event-subscriptions-template.yaml. From same discussion 415, 500 & 503 removed
Include Reference Link to CAMARA API Design Guidelines in Notification Cloud Events Artifact #290(@rartych - removed from this PR )Resolution: Very simple one but need to be done once we split the document. Probably to be removed from this PR as we'll merge this one before the splitting
Resolution: covered in this PR
Resolution: covered in this PR
Resolution: covered in this PR
Which issue(s) this PR fixes:
Fixes #243, #276, #289, #291, #300, #303, #304, #326
Special notes for reviewers:
Not ready for review
Changelog input
Additional documentation
This section can be blank.