Re: [Bug 23] lock discovery vs shared locks

I'm still concerned about a possible inconsistency here.  Sorry if I'm  
being dense, but I thought that we had a previous consensus (a long  
time ago) that servers SHOULD provide lock tokens for all locks so that  
if there were a client bug, a crash, a LOCK reply "lost in the mail",  
or a need for an owner or administrator to remove somebody else's stale  
lock.  Some text currently in the draft to that extent:

   "Anyone can
    find out anyone else's lock token by performing lock discovery."

So given that implies that lock discovery can find out all lock tokens  
(given permission), and that the lockdiscovery property is returned in  
the LOCK response body, doesn't that mean that the lock token is  
returned both in the LOCK response headers (Lock-Token) and body?

Also, we had previously discussed at an interop which is the "right"  
place to put the lock token and concluded that servers ought to put the  
token in both places because we found during interoperability testing  
that we had clients that looked in one place, and other clients that  
looked in the other, so we might as well continue supporting both.

Lisa

On Nov 6, 2005, at 12:09 PM, Julian Reschke wrote:

>
> For the record,
>
> I don't think that the recent discussion has brought up any new points  
> that need to be said here, so I'd like to again recommend to close the  
> issue with the following change (as seen in  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/ 
> 0242.html>).
>
> Proposed resolution for  
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23>: [...]
>
> NEW:
>    A lock token is a type of state token, represented as a URI, which
>    identifies a particular lock.  Each lock has exactly one unique lock
>    token, which is returned upon a successful LOCK creation operation  
> in
>    the "Lock-Token" response header defined in Section 9.6.
>
>
> Best regards, Julian
>

Received on Wednesday, 16 November 2005 02:14:00 UTC