Re: IETF Last Call review: changes suggested

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