- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Thu, 11 Jul 2002 09:34:18 +0200
- To: "Tim Ellison" <tim@ellison.name>, <ietf-dav-versioning@w3.org>
> From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Tim Ellison > Sent: Tuesday, July 09, 2002 10:39 PM > To: ietf-dav-versioning@w3.org > Subject: RE: error condition for delete of VHR when VCR is in checked-in > c ollection > > > > > I think we need to distinguish between > > > > a) references to version histories / versions that are correct, > > but specific > > users may not dereference/GET them (I don't have any problem with > > that), and > > Agreed. > > > b) references that are dead (because the resource they point to > is gone). > > > > In case b), there's no way a subsequent CHECKIN or CHECKOUT can satisfy > > RFC3253's postconditions, so I'd consider this a broken state. There > > shouldn't be a protocol-tolerated way to get into this state, right? > > Agreed. ...and there is no way in HTTP to ensure that a resource is gone, > so we are cool, right? I don't understand this one. So... - DAV:href references to versions may be broken -- for instance because the versioning server is only loosely coupled, and the versions actually live in a different system. That the references point to non-accessible/gone resources isn't really a problem during checking in / checking out -- but for instance UNCHECKOUT or UPDATE may fail later. - My point is that this is an error condition. Yes, it may happen. But, I think it is wrong that a client can get into this state by just doing RFC3253-allowed requests. At the very least, the DELETE sematics for VHRs should *warn* programmers that the side effects of the deletion of a VHR may be surprising :-)
Received on Thursday, 11 July 2002 03:34:58 UTC