That's fine with me too.  So does this mean that lockdiscovery
property (if readable) MUST contain all the locks and all their lock
tokens?  Does that mean that in reply to a LOCK request which
successfully creates a new lock, the server MUST include the full
lockdiscovery property including not just the new lock but also other
locks?


Lisa


On Nov 15, 2005, at 8:40 PM, Geoffrey M Clemm wrote:


<excerpt>

<fixed><x-tad-smaller>Sorry, I misread your message.  The text that I
was objecting to was</x-tad-smaller></fixed> 

<fixed><x-tad-smaller>the clauses:</x-tad-smaller></fixed> 


<fixed><x-tad-smaller>> if there were a client bug, a crash, a LOCK
reply "lost in the mail"</x-tad-smaller></fixed> 


<fixed><x-tad-smaller>in:</x-tad-smaller></fixed> 


<fixed><x-tad-smaller>> servers SHOULD provide lock tokens for all
locks so </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > that if there were a client bug, a crash, a
LOCK reply "lost in the </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > mail", or a need for an owner or
administrator to remove somebody else's </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > stale lock. </x-tad-smaller></fixed>


<fixed><x-tad-smaller>but the text you were proposing was
just:</x-tad-smaller></fixed> 


<fixed><x-tad-smaller>>  "Anyone can</x-tad-smaller></fixed>

<fixed><x-tad-smaller> >   find out anyone else's lock token by
performing lock discovery."</x-tad-smaller></fixed> 


<fixed><x-tad-smaller>which is fine.  I'd prefer making that explicit
(e.g. "A lock token </x-tad-smaller></fixed>

<fixed><x-tad-smaller>discovered by a client via lock discovery SHOULD
NOT be used by that</x-tad-smaller></fixed> 

<fixed><x-tad-smaller>client for anything other than an UNLOCK
request, even if the user</x-tad-smaller></fixed> 

<fixed><x-tad-smaller>is authenticated as owning that lock"), but I
don't insist that this</x-tad-smaller></fixed> 

<fixed><x-tad-smaller>be added (as long as the converse is not added
:-).</x-tad-smaller></fixed> 


<fixed><x-tad-smaller>Cheers,</x-tad-smaller></fixed> 

<fixed><x-tad-smaller>Geoff</x-tad-smaller></fixed>



<fixed><x-tad-smaller>Lisa Dusseault <<lisa@osafoundation.org> wrote
on 11/15/2005 10:59:10 PM:</x-tad-smaller></fixed>


<fixed><x-tad-smaller> > I agree with you, but isn't the client
supposed to UNLOCK by using the </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > lock token?  If so then how does it learn
it... ?</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > Lisa</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > On Nov 15, 2005, at 7:53 PM, Geoffrey M Clemm
wrote:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > I can only repeat what I posted a few weeks
ago ... a client should</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > never steal a lock taken out by an earlier
client by re-using the</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > lock token of that earlier client ... it
should do so by UNLOCK'ing</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > the resource and requesting its own lock.
 That way if the original</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > lock owner is still alive or comes back to
life, the earlier client's</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > attempt to use the original lock token to
update the resource will </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > fail,</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > thus preventing the changes made by the
later client from being </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > overwritten.</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > So I object to the text in the current
draft, because it encourages</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > clients to do the wrong thing, and
encourages servers to support </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > clients</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > doing the wrong thing.</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > Cheers,</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > Geoff</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > w3c-dist-auth-request@w3.org wrote on
11/15/2005 09:13:51 PM:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > I'm still concerned about a possible
inconsistency here.  Sorry if </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > I'm  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > being dense, but I thought that we had a
previous consensus (a long </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > time ago) that servers SHOULD provide
lock tokens for all locks so </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > that  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > if there were a client bug, a crash, a
LOCK reply "lost in the </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > mail",  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > or a need for an owner or administrator
to remove somebody else's </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > stale  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > lock.  Some text currently in the draft
to that extent:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  >    "Anyone can</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  >     find out anyone else's lock token by
performing lock discovery."</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > So given that implies that lock
discovery can find out all lock </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > tokens  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > (given permission), and that the
lockdiscovery property is returned </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > in  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > the LOCK response body, doesn't that
mean that the lock token is  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > returned both in the LOCK response
headers (Lock-Token) and body?</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > Also, we had previously discussed at an
interop which is the </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > "right"  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > place to put the lock token and
concluded that servers ought to put </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > the  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > token in both places because we found
during interoperability</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > testing  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > that we had clients that looked in one
place, and other clients </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > that  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > looked in the other, so we might as well
continue supporting both.</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > Lisa</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > On Nov 6, 2005, at 12:09 PM, Julian
Reschke wrote:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > > For the record,</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > > I don't think that the recent
discussion has brought up any new </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > points  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > > that need to be said here, so I'd like
to again recommend to </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > close the  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > > issue with the following change (as
seen in  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > >
<<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > > 0242.html>).</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > > Proposed resolution for  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > >
<<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23>: [...]</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > > NEW:</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > >    A lock token is a type of state
token, represented as a URI, </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > which</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > >    identifies a particular lock.  Each
lock has exactly one</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > unique lock</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > >    token, which is returned upon a
successful LOCK creation </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > > operation  </x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > > in</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > >    the "Lock-Token" response header
defined in Section 9.6.</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > > Best regards, Julian</x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  > ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  ></x-tad-smaller></fixed>

<fixed><x-tad-smaller> > >  ></x-tad-smaller></fixed>

</excerpt>