Re: GETting a versioned resource

Chris Kaler (ckaler@Exchange.Microsoft.com)
Wed, 6 Oct 1999 15:33:10 -0700 

Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD93F@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'jamsden@us.ibm.com'" <jamsden@us.ibm.com>, ietf-dav-versioning@w3.org
Date: Wed, 6 Oct 1999 15:33:10 -0700 
Subject: RE: GETting a versioned resource

I think this is more than a good idea -- it is required -- at least if I
requested a specific revision.

This is the only way I can know if a proxy server somewhere stripped
the revision request header.

Chris

-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Wednesday, August 11, 1999 10:59 AM
To: ietf-dav-versioning@w3.org
Subject: RE: GETting a versioned resource




Returning the versioned resource id/revision id in the response (headers)
sounds
like a good idea. That way the client can be know exactly what revision it
got
and can get it back regardless of the revision selection rule in the
(perhaps
default) workspace.

I don't think we can specify the GUID for a revision as each server will
likely
need to generate them in some repository specific way.





Jeff_McAffer@oti.com (Jeff McAffer OTT) on 08/03/99 10:58:37 AM

To:   ckaler@Exchange.Microsoft.com (Chris Kaler Exchange), Jim
      Amsden/Raleigh/IBM@IBMUS, ietf-dav-versioning@w3.org
(ietf-dav-versioning)
cc:

Subject:  RE: GETting a versioned resource





Just to be clear about this, I am takling about having the versioned
resource id and revision id in the RESPONSE to a GET request (and perhaps
others).  I think Chris is agreeing with this but feel that Jim is
talking about REQUEST headers.

Also to clarify Jim's #4, how do people feel about us specifying that the
format of this GUID.  That is, I would propose we use the versioned
resoruce id and revision id pair as the GUID for a particular revision of
a particular resource.  This saves us having to have/generate/maintain
yet another GUID.

Jeff

> -----Original Message-----
> From: Chris Kaler Exchange [mailto:ckaler@Exchange.Microsoft.com]
> Sent: Sunday, August 01, 1999 9:58 PM
> To: 'jamsden@us.ibm.com'; ietf-dav-versioning
> 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
>
>
>
>