Comments on search-00 draft

Here are my comments on the Internet-Draft
http://www.ietf.org/internet-drafts/draft-reschke-webdav-search-00.txt

a) Abstract mentions DASL WG

The abstract mentions the now-defunct DASL working group.  It should be
corrected.  However, the WebDAV working group has not officially taken on
searching as a required deliverable.  Thus, the abstract can mention the
WebDAV working group as the active working group most related to this work,
and note that search-related announcements are sometimes made on the WebDAV
WG mailing list or in its meetings.  Or the abstract could simply mention
the mailing list and not mention a WG at all.

b) Section 3.4 - extra response elements

"In addition, the server MAY include DAV:response items in the reply where
the DAV:href element contains a URI that is not a matching resource, e.g.
that of a scope or the query arbiter. Each such response item MUST NOT
contain a DAV:propstat element, and MUST contain a DAV:status element
(unless no property was selected)."

This text should include the information about what this provision is for,
what purpose it serves?

If I understand correctly (from later text) what purpose it serves (a place
to hold information about the result set as a whole, e.g. to indicate that
the result set is truncated), then I'd like to see this information
marshalled in something that is NOT a <DAV:response> item.  In other words,
the <DAV:response> items should correspond 1:1 to resources that matched the
request, and nothing else.  This makes it simpler for clients to parse.
Incidentally, it should also make it easier for clients that support
previous versions of DASL, or clients that already do PROPFIND, to support
the SEARCH response.

What I propose is a new element such as <DAV:search-response-info> to appear
in the response alongside all the <DAV:response> elements.  That element can
still contain <DAV:href> and <DAV:status> elements if those are still
useful.

c) Section 2.4.1 - vagueness

"  Query grammars SHOULD define how the response matches the PROPFIND
   response."

This is pretty vague.  Can you explain more?


d) Section 2.5 - odd use of error responses

"   If an error occurred that prevented execution of the query, the
   server MUST indicate the failure with the appropriate status code and
   SHOULD include a DAV:multistatus element to point out errors
   associated with scopes."

This section indicates that 400 Bad Request and 422 Unprocessable Entity are
appropriate failure responses to SEARCH.  However, these responses don't
typically include a DAV:multistatus element.  Do you really intend to
introduce that with this specification?  If so, it would need more
explanation and specification.

e) Section 2.6.1 - more odd use of error responses

This section specifies the use of 400 Bad Request as the error response to
use when there is a scope problem.  I would have suggested instead 405
Method Not Allowed if the Request-URI exists but can't handle the SEARCH
request.  400 Bad Request can be used in so many places it's not very
specific.

Or, since your example suggests that the resources is "not found" instead,
then the server should respond with 404 Not Found as the major response
code.  Then it seems the body would not be required.

In summary, this section seems to be unnecessarily reinventing error
response mechanisms.

f) Section 3.3 - specify allprop behaviour for new properties

We should probably get in the habit of specifying whether newly-defined
properties such as this one (supported-query-grammar-set) should appear in
response to PROPFIND "allprop".  I suggest the answer is no because most
clients won't support search initially.


g) Comment on how clients find search arbiters

I understand we probably don't want to specify what the search arbiters must
be in the general SEARCH case.  For some special kinds of searches, search
arbiters could be very limited or completely unlimited.

However, it would enhance interoperability to specify for DAV:basicsearch
that all collections on a DAV server supporting basicsearch SHOULD be search
arbiters, effectively performing a search for the content within that
collection.  This would make it easy for clients to figure out what search
arbiter to send the SEARCH request to for any given scope.  However, the
specification would have to explain what relationship the scope has to the
Request-URI, and what the server should do if they are different (e.g. use
the scope specified in the body preferentially if it can be handled).

An alternative is that the draft could specify that the search arbiter for
DAV:basicsearch SHOULD be a "root" of a repository. The client would have to
be able to discover the "root" but that's not too hard -- for any collection
that the client wants to search, send an OPTIONS request to that collection,
then to the parent, recursing up the namespace until it either reaches the
root ("/") or stopping at some parent that does not indicate SEARCH support
in OPTIONS response (e.g. http://java-based-dav-server.com/servlet).

Third alternative: for any collection that can be searched with
DAV:basicsearch, include a "DAV:search-arbiter" property that contains a
DAV:href element, containing the URL that MUST be used by the client as the
Request-URI for a SEARCH method that names that collection in its scope.

Lisa

Received on Thursday, 28 March 2002 13:40:40 UTC