- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 6 Nov 2020 05:23:42 +0100
- To: Michael Douglass <mikeadouglass@gmail.com>, James Fuller <jim@webcomposite.com>
- Cc: "HTTPbis WG (IETF)" <ietf-http-wg@w3.org>
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
Received on Friday, 6 November 2020 04:23:59 UTC