IETF Last Call review: changes suggested

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

Received on Monday, 15 January 2007 22:38:22 UTC