RE: JW2a, JW2b: Search Arbiter resource

Why would we want to force DASL search arbiters to be WebDAV compliant? The
purpose of the arbiter is solely to provide search capabilities for WebDAV
stores. This does not seem to require that the arbiter itself be WebDAV
compliant.

I also do not believe that there will be any interoperability problems with
down level clients as such clients MUST NOT make any functional assumptions
regarding a resource which does not return a DAV compliance header in its
OPTIONS response. Since DASL arbiters are not required to return the DAV
header then there is no danger that down level clients can become confused.

Even if the DASL search arbiter is in a DAV tree there should still be no
problem as WebDAV clients are already required to deal with the situation
that the child of a DAV compliant resource may not necessarily be itself DAV
compliant.

As Alan says, it is fine for a DASL search arbiter to be DAV compliant. It
just shouldn't be required.

		Yaron

> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@ics.uci.edu]
> Sent: Thu, June 24, 1999 5:06 PM
> To: 'DASL'
> Subject: RE: JW2a, JW2b: Search Arbiter resource
> 
> 
> 
> > Jim W:
> >
> > Maybe we have agreement. The key word for me is
> > "required". I don't think properties should be
> > REQUIRED for search arbiters. I never said they
> > should be DISALLOWED. The spec., being quiet on
> > this issue, accommodates my position (it doesn't
> > say they are disallowed, and it doesn't say that
> > you can't have them). Is your position that the
> > spec. should require them, or is it OK to be
> > quiet on that issue for the first release?
> 
> I think search arbiters should be required to support the RFC 
> 2518 base set
> of properties.  If they do, downlevel clients will be able to 
> see search
> arbiters in collections, and will be able to tell that it is 
> not a resource
> type they understand.  I see this limited property support 
> being important
> for interoperability with downlevel DAV clients.
> 
> If the spec. is silent on the properties issue, I feel it will cause
> interoperability issues, since I can easily see a client 
> being developed
> that depends on the property information being present, and 
> behaving poorly
> if it is not.
> 
> - Jim
>

Received on Friday, 25 June 1999 20:42:35 UTC