Subject: REPORT vs SEARCH

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 6 Oct 2001 19:04:22 -0700

Jim's argument that DASL could be implemented on top of an existing Web
Server, without any DAV features, I find compelling.  In addition, I thought
of a few other reasons:

 - DASL is rather big, and rather 'primary'.  It's not just a part of
another feature, like the reports are part of ACL and part of DeltaV.  As
such, I believe servers will want to advertise support for search directly
in the OPTIONS response.  If Search is just another report, it would seem
wierd to treat it differently.

 - REPORT could become too much of a catch-all.  It shouldn't be.  We need
to resist making REPORT the POST of DAV.

 - It's already implemented as SEARCH in a couple places (including, I
admit, Xythos' implementation).  While I don't consider that argument to
trump the issue, it's certainly a consideration.  If there were real
problems with a separate method with SEARCH I'd agree and push to change
existing implementations -- but there aren't any problems.

Overall, since the arguments for replacing SEARCH with REPORT aren't very
strong arguments, I'd say keep it the way it is.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 7 Oct 2001 18:30:14 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Sunday, October 07, 2001 4:04 AM
> To: Webdav WG
> Subject: REPORT vs SEARCH
>
>
>

Well, I wouldn't *want* to treat it differently.

> to resist making REPORT the POST of DAV.

:-) So instead we're doing this with SEARCH?

I understand Jim's argument about SEARCH being independant of other WebDAV
features. I just fail to see why we couldn't use REPORT's framework which
already does what we need fopr XML-based query grammars.

SEARCH currently doesn't say anything specific about non-XML based query
grammars. It would be trivial to do the same with REPORT.

> existing implementations -- but there aren't any problems.

However, everybody who *did* implement SEARCH and DAV:basicsearch should
keep in mind that

- drafts are work-in-progress and
- that DASL will need to be fixed in some areas, so I don't think that a
finalized draft can be completely compatible to the one that's published.

> strong arguments, I'd say keep it the way it is.

In my opinion, DASL's way to do grammar discovery is broken (it reports
grammars as URIs, while they are really Qualified (XML) names). So this
needs to be replaced with something else anyway. The framework used for
REPORT doesn't have this problem, so why not use it?

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 12 Oct 2001 13:32:47 +0200

I think we have identified something that needs to be clarified in RFC2518:

Given a collection X, where the principal does have rights to list the
collection itself, but not it's members.

Currently our server will distinguish between depth 0 and 1, that is a
PROPFIND with depth 0 will report the collection (and it's properties) OK,
while a PROPFIND with depth 1 will result in something like:

<response>
	<href>X</href>
	<status>HTTP/1.1 403 Forbidden</status>
</response>

This is because once a response element for X is available, there's no other
way to distinguish between the case where the collection actually is empty,
or the collection is non-empty, but the principal doesn't have the right to
list it's members.

Feedback appreciated.

Julian