WebDAV and Service Location Protocol

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:18:21 UTC