RE: Comments on the "new" 2518

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.

Cheers,
Geoff

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 
an
> 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 
correct
> the mess I've just created.  Our own customer experience tells us that, 
in
> this use case, users don't want you to allow them to "shoot themselves 
in
> the foot".
> 
> So, understanding that the specification of MOVE behavior has not 
changed
> 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 
the
> MOVE as an all-or-nothing operation; if the MOVE cannot be performed as 
an
> all-or-nothing operation, return a 412 - precondition failed response 
(or,
> 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] 
On
> 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 
you
> just proposed: old clients should be able to interact with new servers, 
and
> the other way around. Note that this is the main reason why I'm opposed 
to
> change the LOCK refresh marshalling.
> 
> Best regards, Julian
> 
> 
>