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
'SHOULD NOT'.

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:

	http://someWebDAVServer.com/code/write.c

In which the current version is:

	http://someWebDAVServer.com/write.c/ver/1.17

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:

	http://someWebDAVServer.com/write.c/temp/synchronous/1.0
	http://someWebDAVServer.com/write.c/temp/asynchronous/1.0

And after time, Joe has the following:

	http://someWebDAVServer.com/write.c/temp/synchronous/1.8
	http://someWebDAVServer.com/write.c/temp/asynchronous/1.10

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

	http://someWebDAVServer.com/write.c/ver/1.18

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:

	http://someWebDAVServer.com/write.c/ver/1.20

put into the following temporary space:

	http://someWebDAVServer.com/write.c/temp/synchronous/1.0

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
restricted.

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.

	Thanks,

	Mark





> -----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
> MUST NOT vs. SHOULD NOT.
>
> 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 GMT

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