Repository navigation
Introduce the notion of a collection - #422
mickenordin wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Legacy REQUEST_SHARE payloads are rejected without an API version change, while collection fulfillment counts can mix unrelated requests and collection declines can validate without required recipient data.
3 open issues
What changed in this PR
This PR introduces Collections to group resources across locations and resource types, allowing a single share request to cover multiple resources.
Changes:
- Adds optional
collectionIdandcollectionSizeshare metadata for grouping and completion tracking. - Defines collection-based
REQUEST_SHAREpayloads and decline responses. - Updates notification scope rules and registry entries while keeping share updates resource-specific.
| File | Description |
|---|---|
spec.yaml |
Adds collection metadata and collection-request schemas and validation. |
IETF-OCM.md |
Defines Collection semantics, fulfillment and decline behavior, and notification scopes. |
Review effort: Balanced
| - $ref: "#/components/schemas/RequestShare" | ||
| - properties: | ||
| notificationType: | ||
| not: | ||
| enum: [REQUEST_SHARE] |
| this field MUST be omitted. The Receiving Server MAY compare this | ||
| value with the number of distinct `providerId` values received for | ||
| the Collection and recipient from the Sending Server to determine | ||
| whether receipt of the Collection is complete. |
| - properties: | ||
| notificationType: | ||
| not: | ||
| enum: [REQUEST_SHARE] |
glpatcern
left a comment
glpatcern
left a comment
There was a problem hiding this comment.
Thanks Micke, looks generally good (not sure why we got Copilot reviewing it too, its concerns can be dismissed though as what you touched is not yet implemented, as we know, so no backwards compatibility concerns).
There's only one thing to fix on the spec.yaml
| - notificationType | ||
| - senderDomain | ||
| - collectionId | ||
| - shareType | ||
| - notification |
There was a problem hiding this comment.
Not sure this works, the RequestShare object represents the inner object of a notification, whereas here you have again the list of all fields including notificationType, that is already defined one level up
Like we have discussed, I am now proposing the notion of a collection. I made it a little bit more generic than I had previously though, allowing a collection to span multiple resourceTypes, so you can request access to a collection of for example files and webapps in the same request for share.
I also added an optional collectionSize, so that we can build nice uis with pending share requests and know if the are only partially fullfilled.