Guidance for dealing with both kinds of resources created by LOCK (was Re: IETF Last Call review: changes suggested)

I'm not quite sure we've dealt with the high-order question yet of  
whether to attempt to add guidance for clients dealing with servers  
that might support Lock-null resources (LNR) or locked, empty  
resources.  It's my impression that some servers have already moved  
away from LNRs to do the new locked, empty resources; other servers  
never implemented LNRs fully or never did locking.  Clients have  
probably already figured out how to work with both kinds of servers  
by now.  Julian, your opinion seems rather lukewarm or indifferent.   
Did anybody else have an opinion?

Perhaps if we run into difficulties agreeing on what guidance to  
provide we can abandon the effort.

More inline, relevant if we do try to provide guidance...

On Jan 17, 2007, at 5:18 AM, Julian Reschke wrote:

>
>>> It would help if there was descriptions of how clients should  
>>> perform actions portably given that MAY.  For example:
>>> - if a client locks an unmapped URL and then decides to COPY or MOVE
>>>   another resource to that name, it needs to include an  
>>> "Overwrite: T"
>>>   header in the COPY/MOVE
>
> It needs that with the new approach, and it seems to me it was  
> undefined with LNRs. Do we have any evidence of interoperability  
> issues here?

I don't have evidence of interoperability, but I agree the Overwrite  
header is clearly needed with the new approach, and I can't think it  
would hurt with a LNR server.  So I can't think of a drawback to  
including this as part of the guidance.

>
>>> - similarly, if it changes its mind and decided to not create the
>>>   resource, it needs to use DELETE instead of UNLOCK
>
> No, it doesn't.

In a later mail you mentioned also being able to do UNLOCK then  
DELETE.  That won't result in a success with a LNR -- the DELETE will  
fail.  OTOH, I'm not clear whether a DELETE will be allowed to  
succeed on an LNR -- it may fail and only an UNLOCK will make the LNR  
go away.  So perhaps the guidance should be:
	- attempt first to UNLOCK, expect success on either kind of server
	- then send a DELETE and ignore 404 Not Found responses

OR attempt first to DELETE, and if that fails try UNLOCK...?  This is  
the optimistic approach, particularly assuming most servers will  
eventually support the new model.

>
>>> - if a client wants to creat a new, empty collection and lock it,  
>>> the
>>>   client should not pipeline a MKCOL and LOCK but rather do the  
>>> MKCOL and
>>>   only send a LOCK if it succeeds.  Pipelining them can result in  
>>> the
>>>   client locking a collection that someone else created or even the
>>>   locking of something other than a collection.  (Or maybe I'm
>>>   overlooking something here...)
>
> I'd say that by not pipelining them the client actually increases  
> the chance of locking a collection created by somebody else. But -  
> thinking of it - why is that a problem anyway? It really doesn't  
> matter who created the collection, as long as it's there and locked  
> after the two requests, right? It's not as if *two* clients can  
> succeed in locking them.

We could add the guidance that if the client pipelines MKCOL and LOCK  
together and sees that the MKCOL failed but the LOCK succeeded, it  
needs to realize that it may have created a locked, empty resource or  
it may have locked some other client's collection -- and thus the  
client probably needs to UNLOCK or figure out what kind of resource  
it has locked before proceeding.

Lisa

Received on Friday, 26 January 2007 21:58:45 UTC