W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: Call for Adoption: SEARCH method

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 5 Nov 2020 20:37:14 +0100
To: Michael Douglass <mikeadouglass@gmail.com>, James Fuller <jim@webcomposite.com>
Cc: "HTTPbis WG (IETF)" <ietf-http-wg@w3.org>
Message-ID: <50f1e5d6-54b3-a73a-3ea8-1876151245af@gmx.de>
Am 05.11.2020 um 19:05 schrieb Michael Douglass:
> I also support not limiting the content type. I can imagine implementing
> a search extension to existing XML based protocols.
> RFC5323 Section 3 say's
>     Clients can determine which query grammars are supported by an
>     arbiter by invoking OPTIONS on the search arbiter.  If the resource
>     supports SEARCH, then the DASL response header will appear in the
>     response.  The DASL response header lists the supported grammars.
>     Servers supporting the WebDAV extensions [RFC3253  <https://tools.ietf.org/html/rfc3253>] and/or [RFC3744  <https://tools.ietf.org/html/rfc3744>]
>     MUST also:
>     o  report SEARCH in the live property DAV:supported-method-set for
>        all search arbiter resources, and
> ...
> Presumably a WebDAV compliant client knows whether or not SEARCH is
> supported as a WebDAV service
> So:
> If it's in DAV:supported-method-set it's WebDAV SEARCH
> If it's in the "Accept-Search" Header Field it's the new SEARCH
> and you can't have both. No need to parse the content.
> ...

Yes, but...

The content type in the payload is supposed to describe the query
semantics. I would expect any new use of SEARCH to actually use a
payload format that is more specific than text/xml or application/xml.

Am I missing something here?

Best regards, Julian
Received on Thursday, 5 November 2020 19:37:31 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 5 November 2020 19:37:33 UTC