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

Re: RFC-2518 LOCK-TOKEN: header

From: <ccjason@us.ibm.com>
Date: Thu, 27 Jan 2000 17:57:03 -0500
To: jamsden@us.ibm.com
cc: w3c-dist-auth@w3.org
Message-ID: <85256873.007E2C35.00@D51MTA03.pok.ibm.com>

OK. Now I see what you're getting at. I didn't understand you were
proposing something that isn't in RFC2518 - lock tokens to prevent merge
conflicts for COOPERATING clints. (I know you said it a number of times, I
just kept interperting it from the point of view of the existing spec.)
This is an interesting approach, and one that could be more acceptable if
we had ACLs. But what does it hurt to require the lock token/authorization
pair? Especially in the case of shared locks? Wouldn't this allow the
server to "help" the clients cooperate? Isn't this the more traditional
notion of locking?
I agree with Jim's hint here.  The authentication is a good idea... as is
having the server enforce it.

As for merge conflicts, also having a revision ID/Lastmod and resource ID
and a header
line to verify these is a good idea.  But also having the server enforce
tokens and authentication as mentioned above seems like a good idea if
exist clients that aren't so careful about avoiding conflicts.

As stated a few months ago, I think server administrators/authors should
their own security and issues when deciding if resources on their site
the lock-discovery property.  If some clients are stealing tokens and this
resulting in trouble, the servers should not reveal lock tokens via
lock-discovery. 2518 allows them to determine their own policy.

As for the need to peak at ld to find a lock token if one (client) has
misplaced their's...
the server administrator needs to weigh this possibility against the
of token stealing.  That being said, the client can't count on that
property even
existing.  Or that it's absense means there are no locks on a given

BTW, was there some issue in this thread that needs to go on the issues
Received on Thursday, 27 January 2000 17:58:49 UTC

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