W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2007

IETF Last Call review: changes suggested

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 15 Jan 2007 14:38:10 -0800
Message-Id: <E70CFD50-8DC3-4C0A-AF09-63A39A40613D@osafoundation.org>
To: WebDAV WG <w3c-dist-auth@w3.org>

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC