Subject: Re: IETF Last Call review: changes suggested

From: Lisa Dusseault <[email-masked]>
Date: Wed, 7 Feb 2007 17:18:16 -0800

Here's what I've drafted up as possible guidance for clients dealing  
with both RFC2518 and RFC2518bis servers:

       A WebDAV client implemented to this specification might find  
servers that
       create lock-null resources (implemented before this  
specification using
       RFC2518) as well as servers that create locked empty  
resources.  The response
       to the LOCK request will not indicate what type of resource  
was created.
       There are a few techniques which help the client deal with  
either type.

       If the client wishes to avoid accidentally creating either  
lock-null or empty locked
         resources, an "If-Match: *" header can be included with LOCK  
requests to prevent the server from
         creating a new resource.

      If a LOCK request creates a resource and the client  
subsequently wants to
          overwrite that resource using a COPY or MOVE request, the  
client should
         include an "Overwrite: T" header.

       If a LOCK request creates a resource and the client then  
decides to get rid
         of that resource, a DELETE request is supposed to fail on a  
lock-null resource and
         UNLOCK should be used instead. But with a locked empty  
resource, UNLOCK doesn't
         make the resource disappear.  Therefore, the client might  
have to try both requests
         and ignore an error in one of the two requests.

Concrete suggestions for improving this would be welcome.

thx,
Lisa

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

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 18 Feb 2007 11:22:27 +0100

Lisa Dusseault schrieb:
>       create lock-null resources (implemented before this specification 
> using
>       RFC2518) as well as servers that create locked empty resources.  
> The response
>       to the LOCK request will not indicate what type of resource was 
> created.  
>       There are a few techniques which help the client deal with either 
> type.

Drop "implemented to this specification". This applies to all clients.

> requests to prevent the server from

This will work in theory, but I'm pretty sure it doesn't in practice 
because of server bugs (I'll try to write a test case next week). We 
shouldn't recommend this as guidance unless we're pretty sure it works 
in practice.

>      If a LOCK request creates a resource and the client subsequently 
> wants to

Yes. Terminology: it may make sense to define LNR (lock-null resource) 
and ELR (empty locked resource) upfront and use it here. So this would 
read: "If a LOCK request creates an ELR...".

>       If a LOCK request creates a resource and the client then decides 
> to get rid
>         UNLOCK should be used instead. But with a locked empty resource, 
> UNLOCK doesn't
>         make the resource disappear.  Therefore, the client might have 
> to try both requests

It can always do an UNLOCK, then DELETE, and treat a 404 upon the DELETE 
as success.

 > ...

Best regards, Julian