Re: Call for Adoption: SEARCH method

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.

On 11/5/20 05:33, James Fuller wrote:
> On Thu, 5 Nov 2020 at 10:46, Julian Reschke <julian.reschke@gmx.de> wrote:
>> Am 04.11.2020 um 21:40 schrieb Austin Wright:
>>> ...
>>> I’m very much in favor of a safe variation of POST.
>>>
>>> However,
>>>
>>>> for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or application/xml content types MUST be processed per the requirements established by [RFC5323  <https://tools.ietf.org/html/rfc5323>].
>>> I think this is too restrictive. If it’s not possible to relax the
>>> RFC5323 requirements, I would favor using REPORT instead.
>>> ...
>> We can relax the requirement to apply only to */xml which has a document
>> element in the "DAV:" namespace (see
>> <https://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.2.2.2>, or
>> even restrict it to the two element names defined there).
> +1 ... seems a reasonable compromise to me.
>
> Jim
>