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

Received on Monday, 13 March 2006 19:43:19 UTC