Subscription & events for Commonalities 0.5.0 #313
Conversation
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
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 ! |
| - 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]>
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.