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:
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:julian.reschke@gmx.de] 
Sent: Monday, March 13, 2006 11:42 AM
To: John Barone
Cc: 'Geoffrey M Clemm'; 'Kevin Wiggen'; w3c-dist-auth@w3.org;
w3c-dist-auth-request@w3.org
Subject: Re: Comments on the "new" 2518

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

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:

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.
    

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