[glue-wg] New Endpoint and Service types

[Paul Millar]

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.