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

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 Tuesday, 21 March 2006 20:58:01 UTC