Re: WebDAV and Service Location Protocol

• From: Daniel Brotsky <dbrotsky@adobe.com>
• Date: 2002年3月20日 23:49:01 +0100
• To: "Lisa Dusseault" <ldusseault@xythos.com>
• Cc: <w3c-dist-auth@w3.org>
• Message-Id: <AC3094E3-3C54-11D6-8467-0003931036B4@adobe.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).
 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