Re: One lock per resource per person?

Sure, I can agree with all of this too. What I was attempting to point out
though is that lock tokens by themselves don't do anything unless the
concurrent client applications do something with them. That is, having two
lock tokens by the same principal using concurrent applications is like
having no lock token at all. Either application, having a shared lock token
can do its update and overwrite the other. Its the one lock token scenario
that works, but only if the client applications are aware of how they got
the lock token, so they know there is a possibility that some other
application has one too. Even then doing something with this information is
up to the client, the server and protocol don't add anything. The multiple
authentication approach just makes the locks easier to differentiate.

In any case, potential overwrite conflicts resulting from multiple shared
locks must be managed by client applications using some out of band
mechanism. This is one of the trust levels spelled out in the spec. It
doesn't matter who has the multiple shared locks, only that they are
shared. So I don't know what having a second shared lock on a resource
allows principals to do that they couldn't do with a single lock.





Greg Stein <gstein@lyra.org> on 10/27/99 05:18:38 PM

To:   Jim Amsden/Raleigh/IBM@IBMUS
cc:   w3c-dist-auth@w3.org

Subject:  Re: One lock per resource per person?



On Wed, 27 Oct 1999 jamsden@us.ibm.com wrote:
> What this implies is that a principal is really some unit of concurrent
> processing. That's the only way update conflicts can occur anyway.
However,
> WebDAV specifies the principal as a (potentially) authenticated user
agent,
> which is not generally a process. Of course it could be, but this is
> outside the scope of WebDAV. The current locking semantics leaves the
> responsibility of managing current processing by the same principle with
> the principle, not the protocol and server. The principle can use lock
> tokens to distinguish applications that got the token by locking vs. some
> other out-of-band means. The management of this is, and should be,
outside
> the scope of WebDAV.

I think you're using semantics as an excuse here. I do not read the same
behavior from the spec (I see the same principle as being able to get
multiple, shared locks); therefore, I think you're stating it [as above]
solely in a way to support your hypotheses.

> I would suggest that Gregs example would be better
> handled by the principal wanting to distinguish locks by application A
and
> B using two different authentication aliases.

NO. As a user, I am assigned a *single* authentication alias on the
server. In an NT environment, it is my domain\username; in a Kerberos
environment, it is my login user/ticket; etc. There is no easy way for the
user to just "well, I'll use a second alias to differentiate these." That
is out of the user's scope and reliant upon the network/security
administrator. I *really* don't think the admin is about to say "well,
let's see... they're going to use up to three apps simultaneously against
our DAV server, so I guess that I'll create three users for this person;
oh wait, but what if they want to run four apps? I guess that I tell the
person they can't do that." The admin isn't going to do this for any
number of reasons.

And the user? There is no way they're going to go through a separate
authentication processes with the server simply to use more than one app
at a time. As a user, one of the best things that I like about Windows is
that it automatically supplies my credentials to servers -- that I only
have to supply them once. In the Unix world, I'm starting to change over
to ssh to get similar functionality, but still..

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Received on Wednesday, 27 October 1999 23:31:11 UTC