RE: BIND vs. non-movable resources in RFC3253

Note: This precondition actually violates the requirement
earlier in the text that a server support cyclic bindings.
But probably a server should be allowed to reject cyclic
bindings, so I'm happy to add this pre-condition (and remove
the current requirement), if nobody objects.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, October 25, 2002 4:55 PM
To: Clemm, Geoff; DeltaV (E-mail); w3c-dist-auth@w3c.org
Subject: RE: BIND vs. non-movable resources in RFC3253


Geoff,

thanks. I think I've got at least one other precondition:

DAV:bind-loops-allowed

(explanation: we don't want the server to produce a 5xx error code for this
case)

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Clemm, Geoff
Sent: Friday, October 25, 2002 10:46 PM
To: DeltaV (E-mail); w3c-dist-auth@w3c.org
Subject: RE: BIND vs. non-movable resources in RFC3253


It looks like we have finally narrowed down this thread to 
one issue for 3253, which I've added as 14.4_CLARIFY_VH_DELETE_2 
(i.e. can you delete the stable binding to a version history 
or version, if there are other bindings).  Any discussion of 
14.4_CLARIFY_VH_DELETE_2 should be mailed to the deltav mailing 
list, not to the general webdav mailing list. 
For the binding spec, Julian asks for two new preconditions 
for BIND, which I will go ahead and add, unless someone objects 
(they both seem reasonable to me).  Any discussion of these two 
new preconditions for BIND should be mailed to the general 
webdav mailing list. 
Cheers, 
Geoff 
  
-----Original Message----- 
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
... 
The issue here is that if we allow a DELETE to fail because other bindings 
exist, a client may never be able to delete a binding (because due to race 
conditions, there will always be additional bindings left). I'm not saying 
that this can be avoided, however it *really* sounds ugly. As I said, I 
haven't seen a convincing argument why we need this restriction in RFC3253 
(and yes, this discussion should be moved to the other mailing list). 
> Can we agree that servers can reject DELETE/MOVE requests and move the 
> versioning specific discussion to the versioning mailing list? 
Yes. Still, we may have to define additional precondition values for 
- resource does not support additional bindings 
- new member name can't be used (in deltav: because it was already used for 
a stable URI) 
Julian 
-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760