- From: Cullen Jennings <fluffy@cisco.com>
- Date: Fri, 25 Nov 2005 09:22:07 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDav <w3c-dist-auth@w3.org>, <w3c-dist-auth-request@w3.org>
I have heard that this is wanted for applications other than a file system. Right now I was sort of looking for examples of applications that did not want to use this. On 11/24/05 12:51 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote: > Cullen Jennings wrote: >> >> So the usual IETF thought pattern around profiles is say we have might >> have profile A and B. Are their clients that want both? Are there >> reasons a server would only support one? How will this negation and if a >> server only does A and a client wants B, what will the interoperation be >> like? > > Let's call that profile "filestore". > > This profile would be a true subset of WebDAV. A server such as Slide > (to take a real-world example) might want to advertise "filestore" on > some resources (such as in a FS backend), but not others (such as a > Tamino XML database). > > A client that would absolutely need the features defined as part of the > "filestore" would simply refuse to interop with some of the resources on > the server. > > IMHO that would still be far better than to forbid servers to implement > useful WebDAV stuff on resources like these (because that's what a MUST > or even a SHOULD requirement would essentially mean). > > We also should keep in mind that we're in HTTP's area here, because > we're talking about PUT. We simply can't overrule HTTP here. We *can* > define a way for servers to advertise that their PUT support fulfills > certain requirement, so that clients can find out. > > Best regards, Julian
Received on Friday, 25 November 2005 17:22:20 UTC