Re: WebDAV and Service Location Protocol

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).

     dan

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