Re: RFC-2518 LOCK-TOKEN: header

<jra>
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?
</jra>
<jlc>
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
there
exist clients that aren't so careful about avoiding conflicts.

As stated a few months ago, I think server administrators/authors should
consider
their own security and issues when deciding if resources on their site
reveal
the lock-discovery property.  If some clients are stealing tokens and this
is
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
possibility
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
resource.

BTW, was there some issue in this thread that needs to go on the issues
list?
</jlc>

Received on Thursday, 27 January 2000 17:58:49 UTC