Re: Call for Adoption: SEARCH method

[Julian Reschke <[e-mail]>]

Am 06.11.2020 um 04:46 schrieb Michael Douglass:
>
> On 11/5/20 14:37, Julian Reschke wrote:
>> 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?
>
> Sorry - I think I replied too high up in the thread.
>
> Your later message said:
>
>>
>>> 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).
> I think my suggestion is a valid way of distinguishing between WebDAV
> search and the new search. Given the existing and proposed headers
> there's no need to parse the content to determine if it's a WebDAV search.

But you need to parse the content at some point of time anyway, right?

> If it's a WebDAV search then that's handled however it's done now (or in
> the future).
>
> If it's the new search then I don't see that we need to restrict the
> content to NOT have DAV: namespace elements.

First of all, this whole discussion only affects resources that want to
support *both*, that is, implementations of WebDAV SEARCH which want to
implement non-WebDAV uses as well.

Furhermore, the whole distinction between "new" vs "WebDAV" seems to be
weird. The only difference is that for certain specific payloads, the
existing RFC mandates a very specific response format. That's it.
Different request payload formats are totally free to pick what they
need. We are just *relaxing* the requirements.

Best regards, Julian