Re: Issues remaining with Bind draft

Geoffrey M Clemm wrote:

>>OK, now I see. This precondition also exists on BIND (where it makes a 
>>lot of sense), however I'm not sure why we would need it for REBIND. 
>>Geoff, do you remember why it appears here?
> 
> 
> I think it is just an error (resulting from copying all of the BIND
> preconditions to the REBIND method).
> 
> So I think deleting the precondition would be the right thing to do.
> 
> ..

Done. See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.6_precondition_binding_allowed>

>>>>>Does REBIND destroy locks, as MOVE does? It shouldn't, unless 
>>>>>there's  a compelling reason for backward compatibility.
>>>>
>>>>No, it should. REBIND is a "strong" MOVE (that will never attempt a 
>>>>"weak" resource move using COPY/DELETE). That's the only semantical 
>>>>difference to MOVE, and thus locks behave just like they do with 
> 
> MOVE.
> 
>>>I disagree, but in either case, the spec needs to say this one way or 
>>>another.
>>
>>OK, we may have to add this piece of information, because it's not 
> 
> obvious.
> 
> I agree with Julian that locking semantics require this behavior, and I
> agree that it would be reasonable to add this as an explicit 
> post-condition
> of the REBIND method.  We would then need to add a similar post-condition 
> to
> the UNBIND method.
 > ..

See 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.6_lock_behaviour>.

Can you suggest a specific text?

Regards, Julian

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

Received on Friday, 19 March 2004 09:12:26 UTC