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

I'd never recommend to any client to stop using ETags for this purpose!
Sounds dangerous.  The client always ought to rely on the ETag to see
if things have changed.  Require clients to use ETag for what it was
designed, and further, require clients to be able to deal with re-use
of version URLs.  It's good medicine.

Now, my second line of defense for this is usability.  Assuming somebody
will want to put version links as URLs in web pages, or in emails, then
it would be more usable to at least be able to construct short, possibly
meaningful version URLs.  The use of a GUID will preclude this.

FWIW, here's what a Xythos Version URL for a real file looks like:
http://www.sharemation.com/~milele/public/advanced-status-reporting.htm?vers
ion=1

lisa

> -----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 5:45 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)
>
>
> A client will often care (very much) about whether it can store a
> URL somewhere (in a document, as a property, etc.), and be able to
> count on it to always identifying exactly that version.  If the
> protocol does not guarantee that this will be the case, it will have
> to use some additional info (etag, perhaps) for determining whether
> or not this URL still identifies the same version.  But there are
> many situations where all you can store is a URL, and there's no
> way to say "and check that the destination of this URL still has
> this same etag value".
>
> Cheers,
> Geoff
>
>
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
>
> 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
> URLs.
>
> lisa
>
>
> > -----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 21:18:38 UTC