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

The key thing that differentiates a version from a generic resource is
that its purpose is to capture a particular state of a generic resource,
and therefore it is immutable (unless a server explicitly adds an IsMutable
attribute).  This means that when you use a version URL, you are saying
that you want to see a particular state of a particular resource.

In other words, a version is not like any other resource, and so
a version URL should not be treated like any other resource URL,
but rather should reflect the semantics and purpose of the
version resource.

In particular, version URL's are used in several properties
in the versioning protocol.  They appear as the DAV:predecessor-set
and DAV:successor-set of a version, and the DAV:version-set of a
baseline and the DAV:version-set of an activity.  In each of
these cases, having that URL get rebound to something that does
not reliably capture the appropriate state would violate the
semantics of these properties.

Now we could have special case rules such as "if a version URL appears
in any DAV:predecessor-set or DAV:successor-set or DAV:version-set of
any resource, then that version URL MUST NOT refer to anything other
than that version", or even worse, we could require that each of
these properties contain both a URL and an etag for every version,
and force every client to check the validity of the URL, but it
certainly would be friendlier to a client to have the server do the
work (especially since nobody has argued that this is hard for a
server to do).

Cheers,
Geoff


   From: "Lisa Dusseault" <lisa@xythos.com>

   I now understand Boris' use-case, but it applies equally to regular URLs.
   I'd like to treat version-URLs much like existing URLs.

    - You get a URL somehow

    - You GET the content behind the URL from the server.

    - If you've seen it before, you might have the ETag and know if it's
   different.

    - If you haven't seen it before, you won't have the ETag and can't tell.
    - If the target content was deleted and re-created with the same URL,
   that's life.

   Why do version URLs have to be different from existing URLs?  Why are
   versions special in that clients have to know if the content has changed --
   in a different way than is already used for regular URLs (ETags)?  Let's not
   solve this problem in a different way!

   Since Boris' use-case applies to regular URLs equally well as to version
   URLs, AND since you can even consider it a feature that one can replace the
   content behind a static URL with new content, then a general solution would
   seem to be the answer.  And I think the general solution is in hand.  As
   with regular URLs, if a user intends for something to be the _same_
   document, they use the same URL.  Nothing stops users from replacing the
   content behind a URL.  URLs are static even though the content behind them
   is dynamic; so if a document creator reused the same URL, when they can so
   easily use a different one, clearly they intended to reuse the same URL.

   lisa

   > -----Original Message-----
   > From: ietf-dav-versioning-request@w3.org
   > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
   > Sent: Friday, December 15, 2000 5:54 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)
   >
   >
   > Lisa asked for a use case that
   > motivated requiring that version URL's not be
   > re-used (she suggests having a client that cares
   > just use the etag).  I believe that Boris has
   > provided a reasonable use case here ... do people
   > agree?
   >
   > Note that Lisa's objection was not based on
   > implementation difficulty, but rather lack of
   > motivation for the requirement.
   >
   > Another objection was that this requirement
   > would cause the version URL's to become longer
   > and more obscure.  I personally would be unlikely
   > to "type in" a version URL, but instead would just
   > be "clicking" on one (as in Boris' example below),
   > so the length/obscurity of the version URL matters
   > much less to me than its reliability.
   >
   > Minimally we will say that a version URL SHOULD be
   > unique, but when I wear my client-writer's hat, I
   > find SHOULD's relatively worthless, and only care
   > about MUST's.
   >
   > What do other folks think?
   >
   > Cheers,
   > Geoff
   >
   > -----Original Message-----
   > From: Boris Bokowski/OTT/OTI [mailto:Boris_Bokowski@oti.com]
   > Sent: Wednesday, December 13, 2000 11:51 AM
   > 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)
   >
   >
   > > 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-reportin
   g.htm?vers
   ion=1

   To me, this looks like a good example where in practice, a URL is all you
   can send to me. It's just not practical to send me the ETag as well,
   because there is no easy way for me to check it. I think I would prefer
   clicking on a URL such as
   http://www.sharemation.com/~milele/public/advanced-status-reporting.htm/0074
   1ab6a2c400141e860000c0a80cc2
   or
   http://www.sharemation.com/~milele/public/advanced-status-reporting.htm?vers
   ion=1&etag=1fe4-69-39e7056c
   over checking the ETag myself.

   With reusable version URLs, users would need to know about ETags. Example:
   If you accidentally deleted advanced-status-reporting.htm and then
   re-created it, a URL which just
   says ?version=1 would link to the latest version of that document instead
   of the first version.

   -Boris.

Received on Saturday, 16 December 2000 09:43:54 UTC