Hi Florido, On 05/03/14 20:19, Florido Paganelli wrote:
Paul, I think this is very bad. http is not webdav.
True, but all HTTP requests are valid WebDAV requests, so all WebDAV endpoints are valid HTTP endpoints.
If one searches for http endpoints that should NOT be done with interfacename, but with Capability or Technology.
I'm not sure I completely agree. Technology doesn't seem appropriate. It's optional and talks more about the mechanical process of providing access -- for example, if dCache provides Windows/SMB access using a particular version of Samba then this could be published as Technology. Capability is better; however, the OGSA definitions are (currently) higher-level functionality; they don't (currently) specify which protocol the endpoint supports. Additional definitions could be added but I'm not sure this is the correct approach.
This http there is a very misleading thing -- in short, so how is an information consumer supposed to infer that endpoint supports webdav??
Easy, if they want WebDAV, they search for an endpoint that supports the webdav profile (however that is specified).
I think we should simply add webdav.
Consider a single endpoint that supports HTTP, WebDAV, CDMI, HTTP-3rd-party-copy, RFC-3230, CalDAV, CardDAV and GroupDAV. If we follow this approach this endpoint must be published 8 times! There are any number of extensions, based on HTTP. I don't think it scales to publish each one as a new object, duplicating almost all of the information.
If the thing is how to discover that webdav is based on http, this is another kind of question... I think of webdav as a protcol itself.
I think you misunderstood: I don't want to publish that webdav is based on http. I want that: o we publish one StorageEndpoint object. o someone searching for HTTP endpoints will find that object. o someone searching for WebDAV endpoints will find that object.
If you think it as an extension of http, maybe you can play with InterfaceExtension in the Endpoint... But I think one should have a StorageAccessProtocol object just for that as well.
Therefore, here's a concrete proposal:
---
A service that supports HTTP or WebDAV protocols MAY publish StorageAccessProtocol objects to represent this. If a StorageAccessProtocol object is published to represent HTTP access then the Type SHOULD be 'http'. If a StorageAccessProtocol object is published to represent WebDAV access then the Type SHOULD be 'webdav'. Since HTTP is a subset of WebDAV, a service that publishes a WebDAV StorageAccessProtocol SHOULD publish a StorageAccessProtocol for HTTP.
I don't like the above. One should tell what the protocol is, not what are its close siblings. Type MUST be webdav. I am against giving such misleading recommendation as the above, they only generate confusion.
I say 'webdav' SHOULD be published if WebDAV is supported. We can make this MUST if you like, but I think SHOULD is strong enough.
When publishing an Endpoint object the describes an HTTP or a WebDAV endpoint with unencrypted access then the URL SHOULD start 'http://' and the InterfaceName SHOULD be 'http'. If the endpoint is encrypted then the URL SHOULD start 'https://' and the InterfaceName SHOULD be 'https'. If the endpoint supports WebDAV then a SupportedProfile of 'http://webdav.org/' SHOULD be published.
In such scenario, what algorithm should the consumer use to discover a webdav endpoint?
SupportedProfile=http://webdav.org/ (or however we choose to label WebDAV support).
Moreover would be nice to stick a domain name to those -- like org.ieee.webdav.
Note that SupportedProfile value is a URL, so something like: SupportedProfile=http://www.ietf.org/rfc/rfc4918.txt For us, the value is a constant. If the URL happens to be a pointer to where the semantics are described then all the better!
I agree that for old standards like http there is no single organization, and is hard to tell, so there can always be exceptions, plain http and https can stay.
For HTTP, we can use the RFC as a reference, for example SupportedProfile=http://www.ietf.org/rfc/rfc2616.txt We could do the same for WebDAV: SupportedProfile=http://www.ietf.org/rfc/rfc4918.txt SupportedProfile=http://www.ietf.org/rfc/rfc5689.txt ... Some thoughts... Paul.