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: Fri, 15 Dec 2000 18:54:15 -0800
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <CNEEJCPIOLHKIOFNFJDPEEKNCAAA.lisa@xythos.com>
To clarify my position...

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 Friday, 15 December 2000 21:54:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT