W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: Move and Delete (was: bind draft issues)

From: Clemm, Geoff <gclemm@rational.com>
Date: Tue, 4 Mar 2003 16:41:19 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED6DE@SUS-MA1IT01>
To: "'WebDAV'" <w3c-dist-auth@w3.org>

Several points that Jason made here were implementation issues
(e.g. Win32 locking, and file system mappings), so those points
are not something that would appear in the spec.

The other statement he made is just locking functionality defined
by RFC2518, not something new introduced by the binding protocol.
As Julian has pointed out, multiple mappings to the same resource
is part of HTTP, and was inherited by WebDAV, not something new
defined by the binding protocol.  So multiple bindings have always
existed in WebDAV.  The binding protocol just gives a client a way
to create them.


-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Tuesday, March 04, 2003 2:52 PM
To: 'Jason Crawford'
Cc: 'WebDAV'
Subject: RE: Move and Delete (was: bind draft issues)

> > Would you be able to do that -- unmap a collection -- even 
> if one of its
> > children were locked? The person with the lock would then 
> lose it and
> > their resource, right?
> What you are implying is correct.
> If a child is locked via a WebDAV lock and the binding to be 
> DELETEd is
> protected by the protected URL of that lock, then it can't be 
> unmapped.
> If the inode of the child is locked, then I believe it can be 
> unmapped.
> If it's locked by a Win32 lock then it probably can't be unmapped in
> the file system, so it's probably best to reject the DELETE at the
> WebDAV layer.

I don't think the bindings specification makes clear what you've just
said here. It's probably because you've internalized a data model that's
been discussed on the list, and are making conclusions based on the
model.  This kind of information should be added to the specification,
because even when models are written down, they can easily be
interpreted differently by newcomers. 

Received on Tuesday, 4 March 2003 16:41:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC