- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 21 Mar 2006 21:56:26 +0100
- To: w3c-dist-auth@w3.org
- CC: John Barone <jbarone@xythos.com>, 'Geoffrey M Clemm' <geoffrey.clemm@us.ibm.com>, 'Kevin Wiggen' <kwiggen@xythos.com>, w3c-dist-auth-request@w3.org
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