Re: GETting a versioned resource

Chris Kaler (ckaler@Exchange.Microsoft.com)
Sun, 1 Aug 1999 18:51:53 -0700 

Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD63A@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'jamsden@us.ibm.com'" <jamsden@us.ibm.com>, ietf-dav-versioning@w3.org
Date: Sun, 1 Aug 1999 18:51:53 -0700 
Subject: RE: GETting a versioned resource

Good catch -- this has to be there because a proxy/server may drop headers
and if it isn't there you have no way of knowing if the server honored the
request for a specific version.

Chris

-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Friday, July 30, 1999 3:43 PM
To: ietf-dav-versioning@w3.org
Subject: Re: GETting a versioned resource




This was supposed to be included. You should be able to request resource by:
1. its URL in which case an unversioned resource, working resource, or
resource
using the default workspace is returned in that precedence order.
2. its URL and any of its revision names (revision id and any labels). This
overrides the workspace.
3. its URL and a specific workspace which returns the revision selected by
that
workspace if any.
4. its GUID URL, a server dependent/generated URL that references the
particular
revision.

We had considered allowing any revision selector (label, revision id,
configuration, activity, workspace; anything that can appear in a revision
selection rule entry), but as I recall, simplified it to nothing, revision
name,
or workspace. I would be happy to consider the more regular and flexible
approach of supporting any revision selector.






Jeff_McAffer@oti.com (Jeff McAffer OTT) on 07/30/99 04:16:37 PM

To:   ietf-dav-versioning@w3.org (ietf-dav-versioning)
cc:

Subject:  GETting a versioned resource





All,

I would like to propose that the response to a GET request include the
"versioned resource id" and "revision id" in its header.  This allows
clients to GET something and know for sure what they got.  The
alternative is a complex sequence of Lock, Get, PropFind, Unlock
requests.  These header fields would be blank as appropriate if the
fetched resource is a) not versioned or b) a working resource (the
versioned resource id could still be set in this case).

There may be other methods for which this information or this style is
applicable.  For example, HEAD.

Thoughts?

Jeff