Re: GETting a versioned resource
jamsden@us.ibm.com
Fri, 30 Jul 1999 18:43:03 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852567BE.007CD1FC.00@d54mta03.raleigh.ibm.com>
Date: Fri, 30 Jul 1999 18:43:03 -0400
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