Did we introduce protocol.[webdav|options].URI accidentally

[michielbdejong]

I was thinking about the URI property in WebDAV protocol details, and it occurred to me that 1) current implementations ignore it, so for them it's a breaking change 2) I don't think we actively took a decision to introduce this as a breaking change

I traced it back to https://github.com/cs3org/OCM-API/commit/c54058bcd6e6b406c9e6ae031c3dabecd1d8b398#diff-9cfca4a1b73e1e28e30fb9b0b984aad6d4caaf0819c61ed40ad338600531f745R327 which was part of the addition of multi-protocol as an optional feature, in the PR that fixed #56.

So I think:

• a Receiving Server that is able to process and apply a URI for WebDAV SHOULD announce this
• a Sending Server SHOULD NOT send a URI unless the Receiving Server has announced it understands it

[michielbdejong]

@glpatcern what do you think?

[glpatcern]

Indeed the idea was at the time to not introduce a breaking change, and - without yet introducing a standard way to "announce" and consume announcements (the discovery endpoint was not yet part of the standard...) - the way to disentangle was the name.

* a Receiving Server that is able to process and apply a `URI` for WebDAV SHOULD announce this

* a Sending Server SHOULD NOT send a `URI` unless the Receiving Server has announced it understands it

In the current context, also in view of https://github.com/cs3org/OCM-API/issues/121, that makes sense. And eventually we can deprecate the name and drop it with OCM 2.0.

[glpatcern]

Reviewing this as part of #131, in fact we have protocol.webdav.uri, which is a new property in OCM 1.1 (protocol.webdav did NOT exist in OCM 1.0), and protocol.options that was opaque and never had any uri in it.

Therefore, the capability the Receiving Server should announce is to be able to process a protocol.webdav payload.

[michielbdejong]

We can announce this inside the resourceTypes object of the disco-doc.