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

Re: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518

From: Jim Luther <luther.j@apple.com>
Date: Wed, 22 Mar 2006 09:02:11 -0800
Message-Id: <4C512FC1-5702-4995-9738-234FBCBE02CA@apple.com>
To: w3c-dist-auth@w3.org

On Mar 21, 2006, at 12:56 PM, Julian Reschke wrote:

> OK,
> trying to summarize:
> - RFC2518 and RFC2518bis suggest best-effort behavior for COPY + MOVE

That is correct.

> - John B says that most users (+ client implementors) would prefer  
> atomic semantics, at least for MOVE

The Mac OS X WebDAV file system also prefers atomic semantics for MOVE.

Since many Mac OS X documents are packaged as bundles (bundles are  
well defined directory structures -- see http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/Concepts/about.html) 
, a MOVE that isn't atomic can corrupt applications, frameworks, plug- 
ins, and documents that are bundles.

> - many servers are not capable of implementing atomic behavior

That is correct.

> - the BIND spec already defines an atomic version of MOVE, which is  

That is correct. I only wish REBIND had been thought of when rfc2518  
was being written. Too late now...

> Questions:
> 1) Is there any reason to modify RFC2518bis' current language?

I don't believe so.

> 2) For implementors who want to use an atomic version of MOVE, is  
> REBIND sufficient?

For future servers and clients, I think REBIND is a good solution.

However, until all clients which need an atomic version of MOVE  
support REBIND, and until all servers those clients need to access  
support REBIND, there's going to be some interoperability problems.  
They are not problems with rfc2518bis -- they are problems in the way  
WebDAV is marketed by some as a protocol for a specific purpose (see http://www.apple.com/macosx/features/networking/ 
  for an example) when WebDAV is really a generic protocol that can be  
used for lots of purposes.

- Jim
Received on Wednesday, 22 March 2006 17:02:22 UTC

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