Subject: IETF Last Call review: changes suggested

From: Lisa Dusseault <[email-masked]>
Date: Mon, 15 Jan 2007 14:38:10 -0800

I received the following comments from an outside reviewer:

> The text should not state a MUST requirement (section 7.3,  
> paragraph 3) and then later revoke that requirement by permiting  
> servers to implement the original behavior.  It seems that locking  
> an unmapped URL MAY (or SHOULD, but not MUST) result in the  
> creation of a non-collection result with empty content, but that  
> regardless the indicated URL MUST be locked.

I'm fine with making this change if others agree.  I could argue that  
any server claiming compliance with "bis" can be required to  
implement the new locking behavior and we don't need to make the old  
behavior a specific option, but I think it's also reasonable to make  
the old behavior a specific option.

>
> 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
> - similarly, if it changes its mind and decided to not create the
>   resource, it needs to use DELETE instead of UNLOCK
> - 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 agree with the reviewer that this would be useful guidance to  
client implementors, and propose to add a subsection to Appendix D  
(Lock-Null resources) that is non-normative.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Jan 2007 14:18:03 +0100

Lisa Dusseault schrieb:
>> The text should not state a MUST requirement (section 7.3, paragraph 
>> 3) and then later revoke that requirement by permiting servers to 
>> implement the original behavior.  It seems that locking an unmapped 
>> URL MAY (or SHOULD, but not MUST) result in the creation of a 
>> non-collection result with empty content, but that regardless the 
>> indicated URL MUST be locked.
> 
> any server claiming compliance with "bis" can be required to implement 
> the new locking behavior and we don't need to make the old behavior a 
> specific option, but I think it's also reasonable to make the old 
> behavior a specific option.

The trick thing here is that the current draft tries to allow two 
different approaches, with a slight preference to the new, simpler 
approach. However, the BCP14 terminology doesn't capture that correctly.

A simple fix would be just to allow one behavior (the new one), but that 
would make some existing servers non-compliant, and my recollection was 
that we didn't want that (and I still think this is the right decision).

Basically, Lock-Null-Resources (LNRs) work fine, but their specific 
behavior is non-trivial and in some cases is extremely hard or 
impossible to implement, while providing little additional value to clients.

>> It would help if there was descriptions of how clients should perform 
>> actions portably given that MAY.  For example:

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?

>>   resource, it needs to use DELETE instead of UNLOCK

No, it doesn't.

>>   client should not pipeline a MKCOL and LOCK but rather do the MKCOL and

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.

> I agree with the reviewer that this would be useful guidance to client 
> implementors, and propose to add a subsection to Appendix D (Lock-Null 
> resources) that is non-normative.

I'm not opposed to adding something here, but first we need to agree 
here what that is...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Jan 2007 16:43:38 +0100

>>>   resource, it needs to use DELETE instead of UNLOCK

I was misreading "DELETE instead of UNLOCK". Of course UNLOCK can be 
used, but it will leave the newly created resource there. Yes, that's a 
change, and to completely get rid of the resource an additional DELETE 
(or a DELETE instead of UNLOCK) is needed.

But that's an edge case. Do we really need additional spec text for that?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 26 Jan 2007 13:58:36 -0800

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 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.

>>>   resource, it needs to use DELETE instead of UNLOCK

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.

> 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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 27 Jan 2007 12:35:42 +0100

Lisa Dusseault schrieb:
> whether to attempt to add guidance for clients dealing with servers that 
> might support Lock-null resources (LNR) or locked, empty resources. 

I don't think we did.

> 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?

I'm not aware of clients that have been confused by the differences 
between LNRs (lock-null resources) and ELRs (empty locked resources).

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

So yes, if we add guidance on this, suggesting to add "Overwrite: T" in 
this case will be harmless.

> 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.  

But it will fail with 404, which I would assume is harmless.

> 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:

Both will work; I don't really think it matters because this is a case 
of recovery from an exceptional state that in practice shouldn't occur 
often.

>> chance of locking a collection created by somebody else. But - 
> 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.

The risk of two clients simultaneously trying to create a resource with 
the same name, but of trying to create a collection, the other one 
trying to create a non-collection seems to be pretty low to me. I'm not 
convinced that we really need to talk about this case.

Best regards, Julian