Re: GETting a versioned resource
Chris Kaler (ckaler@Exchange.Microsoft.com)
Tue, 3 Aug 1999 09:57:46 -0700
Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD653@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'Jeff_McAffer@oti.com'" <Jeff_McAffer@oti.com>,
Date: Tue, 3 Aug 1999 09:57:46 -0700
Subject: RE: GETting a versioned resource
I'm saying that if its in the REQUEST, it must be in the RESPONSE.
I, personally, think it should always be in the RESPONSE so you know
what version was used.
I don't like specifying the format of the GUID. I'd prefer to say
that it is a URI.
Chris
-----Original Message-----
From: Jeff_McAffer@oti.com [mailto:Jeff_McAffer@oti.com]
Sent: Tuesday, August 03, 1999 7:59 AM
To: ckaler@Exchange.Microsoft.com; jamsden@us.ibm.com;
ietf-dav-versioning@w3.org
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
>
>
>
>