W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001


From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 31 Jul 2001 09:00:00 +0200
To: "Ilya Kirnos" <ilya.kirnos@oracle.com>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCOEECCMAA.julian.reschke@gmx.de>
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos
> Sent: Tuesday, July 31, 2001 3:59 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
> > This would be fine with me as well.  It basically says that if a LOCK
> > is applied to an unmapped URI, the LOCK is automatically preceded with
> > a PUT with a zero-length body.  As Stefan and Lisa say, having a
> > zero length resource remain when the LOCK is removed will not cause
> > a problem with existing clients, and clients that care about IIS
> already
> > cannot expect to be able to apply MKCOL to a "lock null" resource.
> > If we didn't already have clients that expected a LOCK on an unmapped
> > URI to succeed, I'd prefer to just say that the LOCK just returns 404
> > on an unmapped URI, but I can live with this compromise proposal.
> I agree: my first choice would  be for abandoning the concept of a null
> lock, but if people feel strongly they should be kept, the semantics
> should be changed to allow the server to create an actual file to track
> the lock.
> Among other things, this allows other protocols to have at least a shot
> at playing nice with DAV locks.  This point (interoperability with other
> protocols) has been brought up a couple of times in this discussion
> already, and is an important consideration for the server I'm working on
> (Oracle iFS), and I suspect for others as well.  It can't just be
> ignored.


If you happen to work on Oracle IFS, would it be possible to give us some
feedback on the WebDAV compliance issues listed in




Received on Tuesday, 31 July 2001 03:00:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:23 UTC