- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Sat, 09 Jul 2005 08:41:15 -0700
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
It depends on whether we're going for Draft Standard or not -- and it was my understanding that Ted is keeping the WG open so we can bring WebDAV to Draft Standard. To go to Draft Standard, we need to take a Proposed Standard and remove the options that aren't implemented, interoperable and tested 2x2. Another option that isn't broadly implemented, if at all, is the support for locks that aren't write locks or aren't exclusive locks (since only exclusive write locks are fully defined). Are there any implementations at all that do locks that aren't write locks? Didn't Adobe or somebody implement shared locks? Lisa On Sat, 09 Jul 2005 00:18:50 -0700, Julian Reschke <julian.reschke@gmx.de> wrote: > > Lisa Dusseault wrote: >> Speaking of RFC2518bis, do we have any support for this option in >> any WebDAV implementations? I don't recall it being tested in past >> interops... >> " A resource MAY be a collection but not be WebDAV compliant. That >> is, >> the resource may comply with all the rules set out in this >> specification regarding how a collection is to behave without >> necessarily supporting all methods that a WebDAV compliant resource >> is required to support. In such a case the resource may return the >> DAV:resourcetype property with the value DAV:collection but MUST NOT >> return a DAV header containing the value "1" on an OPTIONS response." >> If this option isn't implemented or isn't interoperable, let's cut it. > > As far as I can tell, there's no reason to cut it. It doesn't make the > protocol harder to implement, and it may be of value for some servers > that choose to implement a subset of WebDAV only (GroupDAV comes to > mind). > > Best regards, Julian >
Received on Saturday, 9 July 2005 15:41:41 UTC