RE: BIND and DAV:checkout-set property

> ... store the URI that the CHECKOUT 
> request was applied to.  This is likely to be the 
> behavior that is most expected by clients that are 
> not written with multiple bindings in mind.

What happens, if the URI that the CHECKOUT request was applied to becomes
unvalid - e.g. because of some UNBIND happened somewhere above in the
hierarchy.

Should UNCHECKOUT or CHECKIN work with alternate paths, i.e. not the URI the
CHECKOUT request was applied to? Yes, I suppose.

Thanks,
Peter
 

> -----Original Message-----
> From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com]
> Sent: Sunday, August 31, 2003 03:57
> To: 'ietf-dav-versioning@w3.org'
> Subject: Re: BIND and DAV:checkout-set property
> 
> 
> 
> RFC-3253 leaves this up to the server implementation. 
> So you can do whatever is easier for your server.   
> If either one is equally easy, I'd suggest (a), 
> and in particular, store the URI that the CHECKOUT 
> request was applied to.  This is likely to be the 
> behavior that is most expected by clients that are 
> not written with multiple bindings in mind. 
> 
> Cheers, 
> Geoff 
> 
> Peter wrote on 08/30/2003 12:14:01 PM:
> 
> > Does a checked-out resource appear in the DAV:checkout-set property 
> > of the version only *once* or with all its mappings? 
> > I.E.: If the checked-out resource is mapped to URI-1 and URI-2, 
> > what's true, a) or b) ? 
> > a) both URIs appear in the DAV:checked-out property value 
> of the version 
> > b) only one URI appears (server-defined) 
> > Same question for other <href> valued properties, e.g. DAV:
> > workspace-checkout-set. 
> > Our server forbids multiple mappings for history and version 
> > resources, so properties like DAV:checked-out or DAV:version-history
> > are not a problem in our case.   
> > Regards, 
> > Peter 
>