RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

> 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.

Hi.

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

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0253.html>

?

Thanks,

Julian

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