Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caps Disco #136

Open
wants to merge 3 commits into
base: caps-disco-base
Choose a base branch
from
Open

Caps Disco #136

wants to merge 3 commits into from

Conversation

michielbdejong
Copy link
Contributor

In my presentation about OCM at CS3 2023 in Barcelona I had this slide about CAPabilitieS DISCOvery ;)
cs3-2023-bcn-ocm 001

Now I'm thinking if we put good capability discovery into the /.well-known/ocm / /ocm-provider document, then discovery doesn't even have to rely on the apiVersion field we have there. Older implementations will just have less entries in the capabilities object, or the object will be missing from the document altogether.

@michielbdejong
Copy link
Contributor Author

The current resourceTypes object is weird because it seems to be used both to advertise what types of resources a server can receive, and to advertise details about how this server acts as a resource server.

@glpatcern
Copy link
Member

Concerning apiVersion, IMHO its useful for humans, as the branding, and should NOT be relied upon to decide on caps. Yet it is used for that by Nextcloud.

@michielbdejong
Copy link
Contributor Author

Capabilities should be about being able to process something you receive.
Being able to send something or not is not so interesting to discover.

Copy link
Member

@glpatcern glpatcern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, I think we can include the full list in the spec as per #121 !

@@ -236,10 +236,10 @@ Step 7: The JSON response body is the data that was discovered.
The JSON response body offered by the Discoverable Server SHOULD contain the following information about its OCM API:

* REQUIRED: enabled (boolean) - Whether the OCM service is enabled at this endpoint
* REQUIRED: apiVersion (string) - The OCM API version this endpoint supports. Example: `"1.1.0"`
* REQUIRED: apiVersion (string) - The OCM API version this endpoint supports. MUST start with `"1."` and clients MUST ignore the rest of the string.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd not impose restrictions here on the content. Maybe just It is provided for information purposes only: clients SHOULD NOT infer capabilities based on its value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Discovery caps - Aka is the /mfa-capable endpoint really necessary?
2 participants