- 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>
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 UTC