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

Hoping I'm not going to beat a dead horse here, but instead offer  
something a little different.

Would it help everybody if the requirement wasn't made of servers at  
all?  If the real purpose of the requirement on server behavior is to  
set expectations for clients, well we can do that better with direct  
requirements of clients:

   "Clients MUST be prepared to handle complete or partial failure of  
a MOVE request.  Partial failure could mean that some files remain at  
the source while some are at the destination, or even that some files  
are duplicated in both places.  Servers MUST NOT move partial files,  
and SHOULD NOT leave duplicate files in both places at the end of a  
MOVE request."

Lisa

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
>
> - John B says that most users (+ client implementors) would prefer  
> atomic semantics, at least for MOVE
>
> - many servers are not capable of implementing atomic behavior
>
> - the BIND spec already defines an atomic version of MOVE, which is  
> REBIND.
>
> Questions:
>
> 1) Is there any reason to modify RFC2518bis' current language?
>
> 2) For implementors who want to use an atomic version of MOVE, is  
> REBIND sufficient?
>
>
> My p.o.v.:
>
> re 1) Not convinced yet.
>
> re 2) Yes.
>
> While looking at this I noticed another editorial issue in 9.9,  
> which currently starts with:
>
> 9.9.  MOVE Method
>
>    The MOVE operation on a non-collection resource is the logical
>    equivalent of a copy (COPY), followed by consistency maintenance
>    processing, followed by a delete of the source, where all three
>    actions are performed atomically.  The consistency maintenance step
>    allows the server to perform updates caused by the move, such as
>    updating all URLs other than the Request-URI which identify the
>    source resource, to point to the new destination resource.
>    Consequently, the Destination header MUST be present on all MOVE
>    methods and MUST follow all COPY requirements for the COPY part of
>    the MOVE method.  All WebDAV compliant resources MUST support the
>    MOVE method.  However, support for the MOVE method does not  
> guarantee
>    the ability to move a resource to a particular destination.
>
>    For example, separate programs may actually control different  
> sets of
>    resources on the same server.  Therefore, it may not be possible to
>    move a resource within a namespace that appears to belong to the  
> same
>    server.
>
> I think the first paragraph break is in the wrong position and  
> should be two sentences earlier:
>
> 9.9.  MOVE Method
>
>    The MOVE operation on a non-collection resource is the logical
>    equivalent of a copy (COPY), followed by consistency maintenance
>    processing, followed by a delete of the source, where all three
>    actions are performed atomically.  The consistency maintenance step
>    allows the server to perform updates caused by the move, such as
>    updating all URLs other than the Request-URI which identify the
>    source resource, to point to the new destination resource.
>    Consequently, the Destination header MUST be present on all MOVE
>    methods and MUST follow all COPY requirements for the COPY part of
>    the MOVE method.
>
>    All WebDAV compliant resources MUST support the
>    MOVE method.  However, support for the MOVE method does not  
> guarantee
>    the ability to move a resource to a particular destination.
>    For example, separate programs may actually control different  
> sets of
>    resources on the same server.  Therefore, it may not be possible to
>    move a resource within a namespace that appears to belong to the  
> same
>    server.
>
> (adding to <http://greenbytes.de/tech/webdav/draft-reschke-webdav- 
> rfc2518bis-latest.html#rfc.issue.edit>)
>
> Best regards, Julian
>
>
> John Barone wrote:
>> Well, I still don't see mixing and matching methods from various  
>> specs. as a
>> coherent way of addressing the notion of atomicity (all-or-nothing  
>> behavior)
>> in this spec. 2518-bis.  But, that's neither here nor there; the  
>> bottom line
>> is that Xythos seems to be the only ones who feel that this is a  
>> useful
>> addition to the spec., so I'll let this drop as well.
>> -John -----Original Message-----
>> From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday,  
>> March 14, 2006 10:42 AM
>> To: John Barone
>> Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; w3c-dist-auth@w3.org;
>> w3c-dist-auth-request@w3.org
>> Subject: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518
>> John Barone wrote:
>>>> Again, what's wrong with REBIND? You can implement REBIND without
>>> implementing
>>>> anything else in the BIND spec. For that matter, you'd probably  
>>>> want to
>>> implement
>>>> UNBIND as well (as DELETE shares the non-atomic properties with  
>>>> MOVE).
>>> I don't understand what's proposed here.
>>>
>>> Are you proposing that we leave the 2518-bis spec. silent on this  
>>> matter, and simply implement pieces of the binding spec. to  
>>> provide this
>> capability?
>> Exactly.
>>> If so, that doesn't make any sense to me, since what we're really  
>>> talking about is a different spec. with different requirements.   
>>> The way I see it, that has no bearing on this spec. or this  
>>> discussion.
>> Well, both specs are discussed here, and both are supposed to be  
>> submitted
>> to the IESG at roughly the same time.
>>> If instead you're proposing that we add a method REBIND to this  
>>> spec., with an appropriate definition; my concern is that REBIND  
>>> has a specific meaning that's fleshed out by the context provided  
>>> in the binding spec., but that meaning doesn't translate to the  
>>> 2518-bis spec., where we're talking about MOVEs, COPYs, and  
>>> DELETEs, not BINDs,
>> UNBINDs, and REBINDs.
>> That seems to be a very theoretical argument, unless you can show  
>> exactly
>> how REBIND isn't what you need...
>> Best regards, Julian
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

Received on Friday, 12 May 2006 00:06:21 UTC