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

RE: Comments on the "new" 2518

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 6 Mar 2006 16:16:37 -0500
To: "John Barone" <jbarone@xythos.com>
Cc: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF66332AA7.18FB90E5-ON85257129.0074942D-85257129.0074E01B@us.ibm.com>
The BIND specification (which hopefully will be last-called soon after
the 2518bis last-call is completed), provides this feature in the REBIND
method.  So rather than upgrade your sever to support a new header, you
would upgrade your server to support the REBIND method.  Similarly, if
you wanted to provide atomic DELETE functionality, you would support the
UNBIND method.


John wrote on 03/06/2006 02:33:57 PM:
> The concern for us on a MOVE is that the currently specified behavior is
> contrary to (what our immediate customer experience tells us) many users
> want or expect.  Imagine that I as a user issue a MOVE on the server via 
> integrated file explorer on the desktop.  I start out with a whole
> collection, and I drag-and-drop it to a new location on the server (or
> simply rename it), and I end up with 2 incomplete collections, due to
> permissions or lock conflicts on sub-collections/resource, with no real
> indication as to why it happened, and worse, no indication how to 
> the mess I've just created.  Our own customer experience tells us that, 
> this use case, users don't want you to allow them to "shoot themselves 
> the foot".
> So, understanding that the specification of MOVE behavior has not 
> between 2518 and 2518-bis, Xythos would like to propose the following
> additional capability to the MOVE section:
> Add support for a new header on MOVE, that will allow client 
applications to
> request that the server perform an atomic operation on MOVE, meaning an
> all-or-nothing operation.  We'd like to see the header:
> Allow-partial: T/F
> ... added for MOVEs, with the default value being 'T', to preserve
> backward-compatibility, and a value of 'F' meaning attempt to perform 
> MOVE as an all-or-nothing operation; if the MOVE cannot be performed as 
> all-or-nothing operation, return a 412 - precondition failed response 
> alternatively, a 207 response, that includes all the 412 response for
> specific resources).  If implementing servers choose not to support this
> header, and the value is set to 'F', they MAY return a 400 bad request
> response. 
> -John 
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] 
> Behalf Of Julian Reschke
> Sent: Thursday, March 02, 2006 12:24 AM
> To: Kevin Wiggen
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Comments on the "new" 2518
> Kevin Wiggen wrote:
> > In section 9.1, I know this isn't backwardly compatible but can't we 
> > make the default for PROPFIND = depth 0 and PROPNAME?  Move, Copy, 
> > Delete aren't backward compatible (see other email), why not make this 

> > better.
> MOVE, COPY and DELETE *are* backwards compatible.
> And that's exactly the reason why we didn't make changes like the one 
> just proposed: old clients should be able to interact with new servers, 
> the other way around. Note that this is the main reason why I'm opposed 
> change the LOCK refresh marshalling.
> Best regards, Julian
Received on Monday, 6 March 2006 21:16:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:35 UTC