Subject: Comments on the "new" 2518

From: "Kevin Wiggen" <[email-masked]>
Date: Wed, 1 Mar 2006 17:45:53 -0800

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.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Mar 2006 09:23:33 +0100

Kevin Wiggen wrote:
> In section 9.1, I know this isn’t backwardly compatible but can’t we 
> 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

---

From: "John Barone" <[email-masked]>
Date: Mon, 6 Mar 2006 11:33:57 -0800

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Julian Reschke
Sent: Thursday, March 02, 2006 12:24 AM
To: Kevin Wiggen
Cc: [email-masked]
Subject: Re: Comments on the "new" 2518

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 6 Mar 2006 16:16:37 -0500

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

> And that's exactly the reason why we didn't make changes like the one 
you

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 6 Mar 2006 14:04:20 -0800

I am on the fence for how to go with this issue,  but I do note that  
your solution doesn't solve John's problem.  There are many existing,  
deployed clients who already implement MOVE and John wants WFS to  
behave appropriately for them without forcing widespread client (in  
some cases, operating system) upgrade.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Mar 2006 23:59:28 +0100

Lisa Dusseault wrote:
> deployed clients who already implement MOVE and John wants WFS to behave 
> appropriately for them without forcing widespread client (in some cases, 
> operating system) upgrade.

Sorry?

John asked for an extension that allows clients to state that MOVE 
should be atomic (the default staying non-atomic for backwards 
compatibility).

Geoff pointed out that that extension already exists and is called REBIND.

Clients that would want to take advantage of it would need to be 
upgraded in both cases. And, as a matter of fact, they would still need 
to be able to handle servers with non-atomic MOVE implementations.

What am I missing?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 6 Mar 2006 16:59:39 -0800

I read 'T' for 'F' when I initially read John's email, so I guess  
that would require clients to change their code to get atomicity.   
John would a solution that required clients to change their code to  
require atomicity be acceptable?

Lisa

On Mar 6, 2006, at 2:59 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> I am on the fence for how to go with this issue,  but I do note  
>> that your solution doesn't solve John's problem.  There are many  
>> existing, deployed clients who already implement MOVE and John  
>> wants WFS to behave appropriately for them without forcing  
>> widespread client (in some cases, operating system) upgrade.
>
> Sorry?
>
> upgraded in both cases. And, as a matter of fact, they would still  
> need to be able to handle servers with non-atomic MOVE  
> implementations.
>
> What am I missing?
>
> Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 6 Mar 2006 20:16:23 -0500

The request from an unmodified client cannot be interpreted
by a server as requiring atomic move semantics,
since 2518 requires the standard request to be
interpreted as "best effort".  Therefore a client is going to
have to modify its request to indicate it wants atomic
move semantics, and should use the request we already have
defined (REBIND).

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Mar 2006 09:43:58 +0100

John Barone wrote:
 > ...

For the record: but that's exactly the same behavior that the user gets 
when moving data across partitions or network shared.

 > ...
> ...

So what will the client do if the server fails the request? Retry with 
Allow-Partial: T? How would that be reflected in the UI?

Best regards, Julian

---

From: "John Barone" <[email-masked]>
Date: Thu, 9 Mar 2006 08:34:40 -0800

So, Xythos' opinion is actually that MOVE should be atomic.  That's what our
customers tell us they expect, that's what we want to provide for them.  And
honestly, I can think of a real good reason why I'd want to start off with a
whole collection, and end up with 2 incomplete collections, that have to be
cleaned up.  This not only causes problems for the user who performed the
operation, but also, potentially, any users that had/have read access to the
collection(s) (source and/or target).  

I was trying to strike a middle ground, since what we're proposing is a
change to the spec.  The bottom line, is that we'd much prefer the spec.
changed to say that MOVE SHOULD be atomic, meaning all-or-nothing, and then
provide some mechanism (maybe Header) to indicate otherwise.  Yes, our
proposed "compromise" would require clients to change, so in that sense it's
not ideal from our perspective.  We could change our client technology to
make use of the proposed header, but other ubiquitous clients (i.e. Web
Folders, MS Dav Client, Mac Dav Client) would not necessarily do likewise,
and would result in a less than ideal solution for our customers.  I don't
see the suggestion of implementing REBIND as a workable solution, since that
entails implementing/supporting an entirely different spec. for both server
and client, introducing a whole host of additional requirements and
functionality.  While Xythos can certainly choose to implement the Bind
spec. on its server, there's nothing to say that clients (particularly the
most ubiquitous ones our customers are using) would follow suite; in fact,
I'd venture to say they wouldn't, at least not in the foreseeable future.
Besides, what we're talking about is the basic WebDAV spec. (2518,
2518-bis), which has established client and server applications supporting
it.  I don't see suggesting the use of REBIND (which means implementing the
Bind spec.) as particularly germane to this discussion.  The issue at hand
is the behavior and functionality provided by the MOVE method.

Regarding your comments Julian...

>For the record: but that's exactly the same behavior that the user 
>gets when moving data across partitions or network shared.
     
... not sure what OS/filesystem you're referring to here, but if I recall
correctly, on Windows, if you try to drag-and-drop a directory across drives
(local or network), the OS/filesystem will actually force a copy, and thus a
best-effort result would be expected, and is not in dispute (for COPY) by
Xythos.

Regards,

-John 

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Tuesday, March 07, 2006 12:44 AM
To: John Barone
Cc: 'Kevin Wiggen'; [email-masked]
Subject: Re: Comments on the "new" 2518

John Barone wrote:
> 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".
 > ...

For the record: but that's exactly the same behavior that the user gets when
moving data across partitions or network shared.

 > ...
> 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
> 
> 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

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 9 Mar 2006 16:04:54 -0500

John wrote on 03/09/2006 11:34:40 AM:
> customers tell us they expect, that's what we want to provide for them.

I think there are two reasonable desires being expressed here:

(1) Your customers want "move" (the logical operation they invoke from 
your client)
to be atomic.  Fair enough.  You should do what you can to satisfy that 
desire.

(2) Your customers want "MOVE" (the WebDAV method) to be implemented 
atomically
(and not "best effort") by your repository.  Fair enough.  You are of 
course
free to make MOVE be atomic in your repository (that is certainly what we 
do).
2518 says that it "SHOULD" be best effort, but given a "SHOULD" from 2518,
and a "want" from my customers, I'll go with the "want" from my customers
every time (:-).

But note that neither of these desires imply that we need to change the
definition of MOVE from "SHOULD be best effort" (as defined in 2518) to
"SHOULD be atomic".  There is no point in doing that because it would just
be misleading ... a large number (probably, majority) of WebDAV servers do
not make MOVE atomic (unsurprising, since 2518 states that MOVE
SHOULD be "best effort", which means non-atomic).  Changing the definition
in 2518bis would just mislead clients into incorrectly expecting a MOVE
to be implemented atomically on the server.  Any attempt to make this 
change is pointless because:
- existing servers won't magically change their behavior on MOVE just 
  because the language in the new spec has changed
- most of the servers that support best-effort MOVE do so because they
  cannot implement atomic MOVE.  Given the choice of changing their 
implementation
  so that it fails all MOVE calls from a client (because it cannot 
guarantee
  they are atomic), or continuing to act in a 2518 compliant manner and
  implements a best-effort MOVE, I have   no doubt as to which option they 
will pick.

So what is the only interoperable recourse?  Have your server implement
atomic MOVE, and define an extension to the protocol that allows a
client to say "I insist on an atomic MOVE".  There are two possibilities:
add a new header to MOVE (that says "I want this to be atomic"), or add
a new method whose semantics are "atomic MOVE".  The difference between
these two is that with a new header, an old server may just ignore the
header it doesn't recognize, and do the non-atomic MOVE anyway, whereas
with a new method, you are guaranteed that an old server will just fail
the operation.  When designing the Bind protocol, we concluded that the 
new method is preferable since the client can simulate the "fall-back
to non-atomic" behavior by just issuing a MOVE after a failed REBIND,
but cannot simulate the "fail if not supported" with just the header.

> And

The repositories that implement a best-effort move argue that this
is what their users want.  Trying to convince them that their users are 
wrong
or that they do not understand what their users want is usually not a very
productive use of any of our time (:-).

> not ideal from our perspective.

That's not a middle ground ... that is misleading clients into coding 
against
an incorrect assumption ... changing the spec has no effect on all the 
existing
servers that do a best effort MOVE, and all the server implementors who 
believe
that their customers prefer a best effort MOVE and therefore would not 
agree to
the spec change in any case.

> We could change our client technology to
> and would result in a less than ideal solution for our customers.

If you think that users of those clients would prefer that your server
perform an atomic move (and fail a MOVE if it cannot be guaranteed to be
atomic), your server is free to do so. 

>  I don't
> functionality.

You are confusing two issues: how to marshall an atomic move request, and 
whether
that marshalling is packaged up with other features.  We can easily 
unpackage
the REBIND request into a separately supportable feature, if that is what
is desired.  As indicated above, you cannot get some functionality from 
existing
servers by declaring in some future spec that what they are currently 
doing
violates a new "SHOULD".  That is what would be unworkable.  Whereas you 
can
implement atomic MOVE on your server, and also upgrade your clients 
and servers to support an explicit REBIND.

>  While Xythos can certainly choose to implement the Bind

I don't see how that is relevant to this discussion.
The only reason you are implementing REBIND on your server is to be 
friendly
to those clients that explicitly want a REBIND.  For all
existing clients, you just implement MOVE atomically, since you believe 
that is
what your users want.

> is the behavior and functionality provided by the MOVE method.

And that behavior is etched in the stone of many tens (hundreds?) of 
thousands
of existing servers.  That just isn't something that is up for debate.  So 
the only
relevant discussion for this topic is on how to marshall the new atomic 
behavior.

Cheers,
Geoff

---

From: "John Barone" <[email-masked]>
Date: Mon, 13 Mar 2006 09:54:33 -0800

You state that the SHOULD language surrounding the "best-effort" behavior of
MOVE allows us to implement the operation as "all-or-nothing" and still be
compliant with the spec.; fair enough.  However, I'd think that the SHOULD
language in a spec. should lean in the direction of the desired/expected
behavior.   From Xythos' perspective, "best-effort" is not the desired
behavior, but then again, we're just one voice.  If the belief is that
"best-effort" is the consensus for the desired behavior when MOVEing a
collection, then so be it.  However, if in future revisions the language
changes to a MUST, then Xythos would have to argue vigorously against such a
change.

whether 
unpackage 
> is desired.
 
I don't know that I was confusing these 2 issues at all, since I don't
recall you stating or implying that REBIND (or some similar method) could be
unpackaged and included in this spec., until now.  
If we were to add such a method to the 2518-bis spec., then I'd suggest
method names of MOVE-ALL, MOVE-ATOMIC, or MOVE-COMPLETE, rather than REBIND,
which just doesn't have the same meaning when taken out of the context of
the binding spec.

Regards,
 
-John

  _____  

From: Geoffrey M Clemm [mailto:[email-masked]] 
Sent: Thursday, March 09, 2006 1:05 PM
To: John Barone
Cc: 'Julian Reschke'; 'Kevin Wiggen'; [email-masked];
[email-masked]
Subject: RE: Comments on the "new" 2518

(1) Your customers want "move" (the logical operation they invoke from your
client) 
to be atomic.  Fair enough.  You should do what you can to satisfy that
desire. 

(2) Your customers want "MOVE" (the WebDAV method) to be implemented
atomically 
(and not "best effort") by your repository.  Fair enough.  You are of course

  so that it fails all MOVE calls from a client (because it cannot guarantee

that their customers prefer a best effort MOVE and therefore would not agree
to 

You are confusing two issues: how to marshall an atomic move request, and
whether 
that marshalling is packaged up with other features.  We can easily
unpackage 
the REBIND request into a separately supportable feature, if that is what 
is desired.  As indicated above, you cannot get some functionality from
existing 
servers by declaring in some future spec that what they are currently doing 
violates a new "SHOULD".  That is what would be unworkable.  Whereas you can

I don't see how that is relevant to this discussion. 
The only reason you are implementing REBIND on your server is to be friendly

to those clients that explicitly want a REBIND.  For all 
existing clients, you just implement MOVE atomically, since you believe that
is 
what your users want. 

Cheers, 
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Mar 2006 20:03:30 +0100

John Barone wrote:
> You state that the SHOULD language surrounding the "best-effort" 
> behavior of MOVE allows us to implement the operation as 
> "all-or-nothing" and still be compliant with the spec.; fair enough.  
> However, I'd think that the SHOULD language in a spec. should lean in 
> the direction of the desired/expected behavior.   From Xythos' 
> perspective, "best-effort" is not the desired behavior, but then again, 
> we're just one voice.  If the belief is that "best-effort" is the 
> consensus for the desired behavior when MOVEing a collection, then so be 
> it.  However, if in future revisions the language changes to a MUST, 
> then Xythos would have to argue vigorously against such a change.
> ...

Hi,

I'd like to emphasize that - as far as I can tell - nobody is suggesting 
any change like that. The RFC2518 language IMHO accurately reflects the 
fact that an implementation of MOVE varies a lot based on the underlying 
technology, and that there simply *are* cases where it can't be done 
atomically.

Require it to be atomically, and those implementations that can't do it 
will either ignore the requirement, or stop supporting MOVE. I don't 
think this is what anybody wants.

Best regards, Julian

---

From: "John Barone" <[email-masked]>
Date: Mon, 13 Mar 2006 11:30:04 -0800

Perhaps I'm beating a dead horse on this point, but I'll throw in one final
$.02, before I let it go...  

> think this is what anybody wants.

We're not proposing *requiring* the all or nothing behavior, and never have.
We're just trying to make the point that in a spec., one would think that
SHOULD language leans in the direction of the desired behavior.  In other
words, you're recommending what the behavior should be.  In the case of
moving a collection, Xythos doesn't agree that the behavior SHOULD be
"best-effort", but rather "all-or" nothing.  If the consensus is that
"best-effort" is indeed the desired behavior, then fine, we're in the
minority.  

If however, the SHOULD language is there because (as you put it Julian, and
I think Geoff alluded to) "The RFC2518 language IMHO accurately reflects the
fact that an implementation of MOVE varies a lot based on the underlying
technology, and that there simply *are* cases where it can't be done
atomically." (i.e. a lot of servers *can't* implement it that way, for
whatever reason), then perhaps we should look more closely at why the
language is the way it is.  Do we sacrifice desired behavior for feasibility
in implementation?  You could also argue the point that strictly from a
compliance perspective "SHOULD be all-or-nothing" wouldn't change the
compliance of existing servers; although it would certainly change the
"intended" behavior.

... like I said, my final $.02 on that particular point, and now I'll let it
go.  However, I would like to continue pursuing adding the ability for a
client to request an all-or-nothing MOVE operation.  It would be nice to add
a METHOD:

MOVE-ALL (or MOVE-ATOMIC, or MOVE-COMPLETE)

... which MAY be implemented by a server, and if implemented MUST result in
an all-or-nothing MOVE.

Regards,

-John  

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, March 13, 2006 11:04 AM
To: John Barone
Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; [email-masked];

John Barone wrote:
> perspective, "best-effort" is not the desired behavior, but then 
> again, we're just one voice.  If the belief is that "best-effort" is 
> the consensus for the desired behavior when MOVEing a collection, then 
> so be it.  However, if in future revisions the language changes to a 
> MUST, then Xythos would have to argue vigorously against such a change.
> ...

Hi,

I'd like to emphasize that - as far as I can tell - nobody is suggesting any
change like that. The RFC2518 language IMHO accurately reflects the fact
that an implementation of MOVE varies a lot based on the underlying
technology, and that there simply *are* cases where it can't be done
atomically.

Require it to be atomically, and those implementations that can't do it will
either ignore the requirement, or stop supporting MOVE. I don't think this
is what anybody wants.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Mar 2006 20:42:05 +0100

> "best-effort" is indeed the desired behavior, then fine, we're in the

No, I think that's a misunderstanding about what "SHOULD" (as defined in 
RFC2119) means. When the spec says "SHOULD", that indicates that clients 
can in general rely on that.

If what you're after is text that tells server implementors that an 
atomic MOVE in general is more useful than a best-effort move, I do 
agree that this wouldn't hurt. However may impression is that a server 
implementor who *can* do it atomically will do it anyway, so I'm not 
sure whether it really helps.

> ... which MAY be implemented by a server, and if implemented MUST result in

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).

Best regards, Julian

---

From: "John Barone" <[email-masked]>
Date: Tue, 14 Mar 2006 10:31:20 -0800

> 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?
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.

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.  

-John 

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, March 13, 2006 11:42 AM
To: John Barone
Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; [email-masked];

John Barone wrote:
> Perhaps I'm beating a dead horse on this point, but I'll throw in one 
> final $.02, before I let it go...
> 
>> Require it to be atomically, and those implementations that can't do 
>> it will either ignore the requirement, or stop supporting MOVE. I 
>> don't think this is what anybody wants.
> 
> We're just trying to make the point that in a spec., one would think 
> that SHOULD language leans in the direction of the desired behavior.  
> In other words, you're recommending what the behavior should be.  In 
> the case of moving a collection, Xythos doesn't agree that the 
> behavior SHOULD be "best-effort", but rather "all-or" nothing.  If the 
> consensus is that "best-effort" is indeed the desired behavior, then 
> fine, we're in the minority.

No, I think that's a misunderstanding about what "SHOULD" (as defined in
RFC2119) means. When the spec says "SHOULD", that indicates that clients can
in general rely on that.

If what you're after is text that tells server implementors that an atomic
MOVE in general is more useful than a best-effort move, I do agree that this
wouldn't hurt. However may impression is that a server implementor who *can*
do it atomically will do it anyway, so I'm not sure whether it really helps.

> If however, the SHOULD language is there because (as you put it 
> Julian, and I think Geoff alluded to) "The RFC2518 language IMHO 
> accurately reflects the fact that an implementation of MOVE varies a 
> lot based on the underlying technology, and that there simply *are* 
> cases where it can't be done atomically." (i.e. a lot of servers 
> *can't* implement it that way, for whatever reason), then perhaps we 
> should look more closely at why the language is the way it is.  Do we 
> sacrifice desired behavior for feasibility in implementation?  You 
> could also argue the point that strictly from a compliance perspective 
> "SHOULD be all-or-nothing" wouldn't change the compliance of existing 
> servers; although it would certainly change the "intended" behavior.
> 
> 
> ... like I said, my final $.02 on that particular point, and now I'll 
> let it go.  However, I would like to continue pursuing adding the 
> ability for a client to request an all-or-nothing MOVE operation.  It 
> would be nice to add a METHOD:
> 
> ... which MAY be implemented by a server, and if implemented MUST 
> result in an all-or-nothing MOVE.

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).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Mar 2006 19:41:34 +0100

> and simply implement pieces of the binding spec. to provide this capability?

Exactly.

> 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.

> 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

---

From: Manfred Baedke <[email-masked]>
Date: Tue, 14 Mar 2006 20:11:36 +0100

John,

as far as I can see, you are proposing to extend WebDAV by a method
that has the semantics of an atomic MOVE. Since the BIND spec is a
WebDAV extension and the REBIND method has exactly the desired
semantics, I do not see your point. Why is it important if your
extension is defined by the same spec?

Regards,

Manfred

John Barone wrote:

implementing

implement

-John

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Monday, March 13, 2006 11:42 AM
To: John Barone
Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; [email-masked];

John Barone wrote:

We're not proposing *requiring* the all or nothing behavior, and never

have.

Best regards, Julian

---

From: "John Barone" <[email-masked]>
Date: Wed, 15 Mar 2006 09:30:26 -0800

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:[email-masked]] 
Sent: Tuesday, March 14, 2006 10:42 AM
To: John Barone
Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; [email-masked];
[email-masked]
Subject: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518

John Barone wrote:
> 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

---

From: Jim Luther <[email-masked]>
Date: Wed, 15 Mar 2006 11:15:35 -0800

John,

I come from a background of working mostly with file system network  
protocols (AFP, SMB, NFS, etc) which are designed to be used between a  
file system client and a file server. I first started working with  
HTTP/WebDAV a few years ago, I made a lot of assumptions that HTTP/ 
WebDAV would work like file system protocols. I've learned that a lot  
of those assumptions are wrong.

I think the abstract of rfc2616 makes it clear that my assumptions  
were wrong, "The Hypertext Transfer Protocol (HTTP) is an application- 
level protocol for distributed, collaborative, hypermedia information  
systems. It is a generic, stateless, protocol which can be used for  
many tasks beyond its use for hypertext, such as name servers and  
distributed object management systems, through extension of its  
request methods, error codes and headers [47]. A feature of HTTP is  
the typing and negotiation of data representation, allowing systems to  
be built independently of the data being transferred."

So, the Mac OS X WebDAV file system client and Apple's iDisk server  
are using WebDAV/HTTP as a file system protocol, and the WebDAV/HTTP  
protocols are generic enough for that to work. However, because MOVE  
and COPY are not guaranteed to be atomic (all-or-nothing behavior),  
because what you PUT to a server isn't guaranteed to be what exactly  
what you GET back, and because of other behaviors that are not  
guaranteed by the HTTP/WebDAV specs to work the way a specific client  
would *like* them to work, I've come to the conclusion that all a  
WebDAV file system client can do is guarantee interoperability with  
specific WebDAV servers -- those WebDAV servers which behave like file  
servers.

So, I agree with you that atomic MOVE and COPY operations are needed  
for *our* clients, but I also understand that the WebDAV/HTTP specs  
aren't going to guarantee that behavior.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Mar 2006 21:56:26 +0100

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

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Jim Luther <[email-masked]>
Date: Wed, 22 Mar 2006 09:02:11 -0800

> - RFC2518 and RFC2518bis suggest best-effort behavior for COPY + MOVE

That is correct.

> 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...

> 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