RE: Comments on the "new" 2518

> 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

Received on Tuesday, 14 March 2006 18:31:38 UTC