W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

RE: re-use of version URL's [was: some comments from Chris Kaler ...]

From: Mark A. Hale <mark.hale@interwoven.com>
Date: Wed, 3 Jan 2001 23:37:36 -0800
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <ietf-dav-versioning@w3.org>
Cc: <ckaler@microsoft.com>, <yarongo@crossgrain.com>, "Ron Daniel" <rdaniel@interwoven.com>
Message-ID: <FCEJIPPGHGNPMFLDIMEFEEMLCHAA.mark.hale@interwoven.com>
Thanks for permitting the thread to continue with additional feedback for

I do believe that unique URL's can be created and maintained by servers.
There were earlier discussions about GUID's and MAC addresses that are just
two of a number of possibilities.

I would like to focus on two of several situations where URL reuse comes
into play.

1.  Hypothetical versioning system with temp spaces
Consider that Joe is editing the following source code:


In which the current version is:


At this time, Joe wishes to explore a synchronous and asynchronous write.
He decides to use version control in a temporary space in which this
particular server has the version URL's:


And after time, Joe has the following:


At his time, Joe decides to use the asynchronous implementation and
subsequently updates his master and now has:


In addition, the temporary spaces are completely deleted and are not
maintained anywhere in the server.  They are gone.

At a future time, Joe may decide again to try another synchronous code
sample with the following version:


put into the following temporary space:


In this case, there is a logical re-use of the same URL with a 'meaningful'
URL address for use by Joe.

I will not argue that this is how we implement our systems but I do think
that the possibility for this kind of implementation should not be

2.  General security clause
The standard security clause for naming (here is a sample clause from RFC
2396 from the Network Working Group):

   Users should beware
   that there is no general guarantee that a URL, which at one time
   located a given resource, will continue to do so.  Nor is there any
   guarantee that a URL will not locate a different resource at some
   later point in time, due to the lack of any constraint on how a given
   authority apportions its namespace.  Such a guarantee can only be
   obtained from the person(s) controlling that namespace and the
   resource in question.  A specific URI scheme may include additional
   semantics, such as name persistence, if those semantics are required
   of all naming authorities for that scheme.

I see two issues of importance.

   1) URL will not locate a different resource at some later point in time
   2) Such a guarantee can only be obtained from the person(s) controlling
that namespace and the resource in question.

In terms of what we are trying to achieve.  I view (1) as being the rule and
(2) as the exception.  In addition, I believe that (2) is a matter of
corporate policy and it is my viewpoint that the argument proposed here is
not strong enough that WebDAV would want to impose any policy guidelines.

Anyway, I hope these help to see the perspective in which I feel SHOULD
should be used.



> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M.
> Clemm
> Sent: Wednesday, January 03, 2001 6:04 AM
> To: ietf-dav-versioning@w3.org
> Cc: ckaler@microsoft.com; yarongo@crossgrain.com
> Subject: re-use of version URL's [was: some comments from Chris Kaler
> ...]
> OK, it looks like this is worth one more thread during last call.
> As Tim pointed out, several members of the working group strongly
> support MUST NOT, so let's look closely at the tradeoffs for saying
> I believe that recent threads on this topic have sufficiently
> motivated why it is valuable for a client to be able to
> count on version URL's not being re-used.  Certainly
> a client certainly doesn't lose anything because of this
> requirement.
> So it is reasonable to conclude that those arguing for "SHOULD NOT"
> are server implementors who feel that it is too costly for them
> to satisfy this requirement.
> In earlier threads, the response has been that a server writer can
> just tack on a GUID to the version URL to guarantee it isn't re-used
> (RFC-2518 describes a variety of mechanisms for cheaply creating
> GUID's).  Perhaps those in favor of SHOULD NOT (Chris? Mark?) could
> explain to the group why this would be a problem?
> Note that several of the techniques described in 2518, don't
> "guarantee" uniqueness, but rather make it extremely unlikely that
> there will be a collision ... I believe that "extremely unlikely" is
> sufficient for satisfying the "MUST NOT".
> Cheers,
> Geoff
>    From: Tim_Ellison@uk.ibm.com
>    This is too bad ... I strongly support "MUST" -- for all the
> reasons that
>    you have heard already from numerous members of the working group.
>    "Mark A. Hale" <mark.hale@interwoven.com> on 2001-01-02 08:59:01 PM
>    I strongly support the use of SHOULD in this case.  Thanks for
> making the
>    change.
>    > I talked with Chris on the phone today, and he asked for a
>    > change and a clarification
>    >
>    > - change the MUST to a SHOULD for the "version URL can never
> be re-used".
>    >
>    > Chris is concerned that various reasonable ways of getting
> version URL
>    > uniqueness have a chance of collision if a given host name is mapped
>    > to a new server.
>    >
>    > In general, I try to avoid SHOULD in favor of MUST whenever possible.
>    > Since there has been a lot of debate on this issue, I suppose I can
>    > live with SHOULD here.
Received on Thursday, 4 January 2001 02:35:02 UTC

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