From: Tim_Ellison@oti.com (Tim Ellison OTT) To: ietf-dav-versioning@w3.org (ietf-dav-versioning) Message-ID: <2000Feb17.101159.1250.1478927@otismtp.ott.oti.com> Date: Thu, 17 Feb 2000 10:13:18 -0500 Subject: RE: Members of a collection Adding status codes puts this condition 'in your face', that is a good thing or a bad thing depending upon your point of view. As a server kind of guy I like it, but clients may not. Tim ---------- >From: Clemm, Geoff >To: ietf-dav-versioning >Subject: RE: Members of a collection >Date: Wednesday, February 16, 2000 11:02PM > >I agree that this is not a problem, but it might be worth >having a couple of special status codes, i.e.: >4xx (No Such Revision) >4xx (No Such Working Resource) >and then reserve 404 for when there is no versioned resource >(or any other resource) at that URL. What do folks think? > >Cheers, >Geoff > > >> -----Original Message----- >> From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com] >> Sent: Wednesday, February 16, 2000 5:05 PM >> To: ietf-dav-versioning@w3.org >> Subject: Members of a collection >> >> >> >> To determine the members of a collection on a versioning >> server, a client >> issues a PROPFIND. In a non-versioning world if you are told >> that /foo/ has >> a member /foo/bar then you have a pretty good chance that you can GET >> /foo/bar. However, in a versioning world your workspace may >> not select any >> revision of /foo/bar, so you 'see' that /foo/ has a /foo/bar >> but you get a >> 404 when you try to GET /foo/bar. >> >> This is going to be particularly interesting for 'browser' >> type applications >> that reveal one layer of the namespace at a time. However, I >> claim that >> this is no different than a non-versioning server showing its >> members, then >> a member being DELETEd before the client GETs it. One >> difference is that >> the versioning anomaly is more likely to happen. >> >> Just an observation. >> Tim >> > >