W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

Re: WebDAV and Service Location Protocol

From: Daniel Brotsky <dbrotsky@adobe.com>
Date: Wed, 20 Mar 2002 23:49:01 +0100
Cc: <w3c-dist-auth@w3.org>
Message-Id: <AC3094E3-3C54-11D6-8467-0003931036B4@adobe.com>
To: "Lisa Dusseault" <ldusseault@xythos.com>
Great find, Lisa.  This is an issue we've been starting to focus on at 
Adobe, as well.  I would be willing to collaborate on defining a WebDAV 
extension for SLP Service Agents (and interested clients).


On Wednesday, March 20, 2002, at 10:34 PM, Lisa Dusseault wrote:

> I've been looking into the problem of locating WebDAV servers on an
> intranet.  Companies that have  WebDAV servers on their net may not 
> wish to
> have users manually configure various clients with the names of all 
> those
> servers.  In researching this problem, I've found only one 
> standards-based
> approach, and that's SLP.
> Who would be interested in defining a WebDAV extension so that Service
> Location Protocol (SLP) clients can distinguish WebDAV servers from 
> plain
> Web servers?  Any feedback on how this should work?  Or are there other
> options I'm ignorant of?
> The SLP specification:  http://www.ietf.org/rfc/rfc2608.txt
> SLP home page, links to open source project: http://www.srvloc.org/
> SLP and the Macintosh: http://www.opendoor.com/shareway/SLP.html
> Some background...
> SLP models
> SLP works in one of two models.  In the direct client-to-server model, 
> the
> client multicasts requests for a particular kind of service to the local
> network. Services of that type respond directly (unicast) to the 
> client.  I
> see problems with this model because it would require a WebDAV server to
> receive multicast.
> The second SLP model involves a directory agent to register services:
>  +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
>  | User  |                    | Directory |                   |Service |
>  | Agent |                    |   Agent   |                   | Agent  |
>  +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+
> This model seems easier for WebDAV servers to implement (they just have 
> to
> send their registration and accept the response).
> Service URLs
> Services advertise themselves using service names or schemes.  As HTTP
> servers, WebDAV servers would probably therefore advertise themselves 
> with
> the 'http' service type.  E.g.
> 	service:http://myserver.com
> A client request for "service:http" would match against all HTTP and 
> WebDAV
> servers advertising themselves in this way.  For all matches, a list of
> attributes for the service can be returned to the client.  I suspect the
> attribute list is the right place to advertise WebDAV support.  This
> optimizes in a few directions:
>  - to find all HTTP servers, whether WebDAV or not, the client only 
> needs to
> send one service match request.
>  - to find all WebDAV servers, the client only needs to send one 
> request,
> and has to filter out the non-WebDAV responses.
>  - It is not necessary for the client to send OPTIONS to all HTTP 
> servers to
> discover WebDAV support.  However, to discover additional WebDAV
> functionality that may be required unless we add additional detail.
>  - HTTP/WebDAV servers only need to advertise themselves once, as a http
> service with WebDAV support attributes.
> This approach follows the approach for printers, which you can follow
> through examples in the RFC.
> Lisa
Received on Wednesday, 20 March 2002 17:49:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:25 UTC