Clarify access methods (#87)

* Clarify access methods

As follow up of #86, the OCM v1.0 method is deprecated, and a v1.1 client must pass the shared secret as bearer token.

* Addressing comment

README.md

@@ -44,9 +44,9 @@ In response to a share creation, the receiving server MAY send back a [notificat
 ### Share Access
 To access a share, the receiving server MAY use multiple ways, depending on the received payload and on the `protocol.name` property:
 
-* If `protocol.name` = `multi`, the receiver SHOULD make a HTTP PROPFIND request to `protocol.webdav.uri` to access the remote share. If `protocol.webdav.sharedSecret` is not empty, the receiver SHOULD pass it as a `Authorization: bearer` header.
+* If `protocol.name` = `multi`, the receiver MUST make a HTTP PROPFIND request to `protocol.webdav.uri` to access the remote share. If `protocol.webdav.sharedSecret` is not empty, the receiver MUST pass it as a `Authorization: bearer` header.
 
-* If `protocol.name` = `webdav`, the receiver SHOULD inspect the `protocol.options` property. If it contains a `sharedSecret`, as in the [legacy example](https://cs3org.github.io/OCM-API/docs.html?branch=develop&repo=OCM-API&user=cs3org#/paths/~1shares/post), then the receiver SHOULD make a HTTP PROPFIND request to `https://<sharedSecret>:@<host><path>`, where `<host>` is the remote server, and `<path>` is obtained by querying the [Discovery](#discovery) endpoint at the remote server and getting `resourceTypes[0].protocols.webdav`.
+* If `protocol.name` = `webdav`, the receiver SHOULD inspect the `protocol.options` property. If it contains a `sharedSecret`, as in the [legacy example](https://cs3org.github.io/OCM-API/docs.html?branch=develop&repo=OCM-API&user=cs3org#/paths/~1shares/post), then the receiver SHOULD make a HTTP PROPFIND request to `https://<sharedSecret>:@<host><path>`, where `<host>` is the remote server, and `<path>` is obtained by querying the [Discovery](#discovery) endpoint at the remote server and getting `resourceTypes[0].protocols.webdav`. Note that this access method is _deprecated_ and may be removed in a future release of the Protocol.
 
 In both cases, when the share is a folder and the receiver accesses a resource within the share, it SHOULD append its relative path to that URL.
 

spec.yaml

@@ -449,8 +449,9 @@ definitions:
                 properties specified below.
                 Otherwise, at least `webdav` is expected to be supported, and
                 its options MAY be given in the opaque `options` payload for
-                compatibility with v1.0 implementations (see examples).
-                CAREFUL: client implementers should be aware that v1.1 servers
+                compatibility with v1.0 implementations (see examples). Note
+                though that this format is deprecated.
+                Warning: client implementers should be aware that v1.1 servers
                 MAY support both `webdav` and `multi`, but v1.0 servers MAY
                 only support `webdav`.
             options: