W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

RE: II.6, non-reusable version URLs (was: comments on deltav-10.5 from Yaron Goland, Act Two)

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 12 Dec 2000 16:51:01 -0800
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
It would be easy code-wise to use GUIDs in creating version URLs.  However
that's not the issue.  I'm not arguing whether this can be implemented
easily; it certainly can be.  I'm arguing whether it needs to be part of the
protocol specification.  Does it have any bearing on the protocol standard
whether or not a server reuses version URLs?  I think not.  Leave decisions
up to the implementors when they do not affect interoperability.  Or, give
me an argument why interoperability _suffers_ if the server reuses version


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, December 12, 2000 4:08 PM
> To: ietf-dav-versioning@w3.org
> Subject: Re: II.6, non-reusable version URLs (was: comments on
> deltav-10.5 from Yaron Goland, Act Two)
> Note that a server can implement non-reusable version URL's
> fairly easily by extending the version URL with a GUID (such
> as would be used for a lock token).  The non-GUID part of the
> URL would be used to locate the resource and the GUID part of
> the URL would be stored as an implementation attribute on the resource.
> If the resource currently located at the non-GUID part of the URL
> does not have the GUID part of the URL, then the server would return
> a 404 on access to that URL.
> The benefit to the client (as Tim describes below) is significant
> enough to warrant serious consideration for adding it to the protocol.
> Lisa: does your server currently use GUID's for any other purpose
> (such as locking), and if so, would it be a problem to use them
> here?
> Cheers,
> Geoff
> -----Original Message-----
> From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
> The term "version URL" simply means a URL that identifies a version.  In
> your example I'm not sure what you mean by "relative URL".
> Servers may support deleting individual versions (as well as the entire
> versioned resource).  It would be undesirable for servers to reuse version
> URLs since they represent a 'stable' reference to a particular
> state of the
> resource, and may be used as such by other persistent resources.  Clearly
> if the server reuses a URL that would be a bad thing in such
> circumstances.
> Tim
> "Lisa Dusseault" <lisa@xythos.com> on 2000-12-12 08:56:57 PM
> Can somebody clarify what this would mean:
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org On Behalf Of Geoffrey M.
> > ...
> > (II.6) Require that a version URL never be re-used after a version is
> >        deleted.
> Whether or not I agree with this, I find the phrase "version URL" to be
> ambiguous enough that I'm not certain what this comment is supposed to
> mean,
> so I'll start with an example:
>  - foo.doc is created
>  - foo.doc is made versioned and "foo.doc.__v1__" is defined as the
> relative
> version URL
>  - All of foo.doc is deleted
>  - foo.doc is created
>  - foo.doc is made versioned, NOW, according to this suggestion, the
> current
> version CANNOT be called foo.doc.__v1__ therefore is called foo.doc.__v2__
> Is that the intent?  if so, I'd have to disagree with this; although it
> might be desirable for a server to avoid ever having a version
> URL re-used,
> it ought not to be part of the standard.  I don't actually think it's
> relative to the standard, although it may be very relative to good server
> design.
> lisa
Received on Tuesday, 12 December 2000 19:51:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC