RE: HOW_TO_IDENTIFY_LOCK_OWNER

So I have followed Julian's advice and gone back and reviewed all the 
mail around this.  Here's my interpretation:

1. There are only 5 people participating in this thread (Geoff, 
Julian, Lisa, Jason, and me).  I note this only because it's 
worrisome to me to declare "consensus" based on such a small 
discussion.  Also because it explains why the rest of this analysis 
actually names names, so to speak :^).

2. All 5 of us seem to feel that leaving DAV:owner alone and under 
the control of clients is the only thing that will allow existing 
clients to keep working.

Conclusion: I think we have "consensus" that DAV:owner should be 
under client control and that the spec should state this.

3. Geoff and Julian seem to feel that we should "deprecate" 
DAV:owner, which I think means they want the spec to say that clients 
should not rely on the DAV:owner field.  They argue that clients can 
not "interoperate" using this field because its value is unspecified. 
I strongly disagree with this, for reasons I've often stated but will 
reiterate briefly: I claim that having a "guaranteed dead" property 
writeable as part of a LOCK request is a very valuable feature of the 
protocol precisely because it allows clients to interoperate using 
conventions *outside* of the protocol.

Conclusion: We don't have consensus about deprecating DAV:owner.

4. Lisa and I (more me than her, but maybe I convinced her :^) both 
seemed to feel that clients should have a way of asking about who 
owns a lock in order to figure out whether a discovered lock is owned 
by them.  Geoff replied that, since we're leaving DAV:owner in the 
hands of the client, then presumably a client could use that field to 
determine whether he owned a lock.  I take from Lisa's lack of 
response that she found that argument persuasive.  I certainly did. 
(Geoff and maybe Julian also seemed to feel strongly that it's 
insecure for servers to give out this kind of information, but while 
I agree with this I don't think that argument is on point: we weren't 
talking about mandating it, just allowing it.)

Conclusion: We have consensus that servers shouldn't have to tell 
clients who owns locks, and further that we don't need a standard way 
for clients to ask about this.

5. Geoff and Julian both seem to feel strongly that there should be 
some protocol-specified way for clients to communicate conventionally 
with each other about who owns a lock.  They seem to feel that this 
was what DAV:owner was intended to be about in the first place, so I 
think they are both agreed about introducing DAV:lockowner as such a 
thing and deprecating DAV:owner.  Jason seemed to find this proposal 
sensible given the conclusion of (2).  Neither Lisa nor I have had 
anything to say about this.

Conclusion: There's a proposal on the table to add DAV:lockowner 
that's probably linked to the proposal to deprecate DAV:owner.  But 
there's been essentially no discussion of it, even by the 5 people 
who've been active so far.

Bottom line: At this point, I think our two points of consensus are:

1. DAV:owner is owned by clients, and the spec should say this.

2. We are not going to add a way for clients to ask who owns a lock.

I would suggest we close out this issue on that consensus.  I have no 
objection to adding an issue about adding a DAV:lockowner field 
(based on Julian's proposal), but I have not seen any evidence that 
actual clients are asking for this; it seems to be more of a hygiene 
issue than anything else.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>

Received on Monday, 28 January 2002 19:07:29 UTC