- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Fri, 5 Jan 2001 11:52:49 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: Greg Stein <gstein@lyra.org> As Geoff stated: you can use version-controlled resources, labels, or baseline selectors to create human-readable URLs. The version resource URL is (IMO) typically private and does not need to be readable. Primarily, the URL needs to be *stable* and *persistent*. This thread brings to mind a related topic, which has an even more negative impact on interoperability then weakening the MUST to a SHOULD, namely "mutable versions". A mutable version is actually even worse than a server re-using a version URL, because it provides a way for a *client* to break versioning semantics. But I believe the thread on "re-use of version URL's" points out an interoperable solution to the "mutable version" issue. In particular, clients that want mutable versions want to use the same "name" to apply to one state at one time, and another state at another time. But we already have a mechanism for doing this in the protocol, namely labels. In particular, if a mutable versioning client uses *labels* to identify versions of interest, then we get interoperability. When a mutable versioning client wants to "change" the state of a version, they just create a new version and apply that label to it, and that *label* then acts as a "mutable version identifier". The only thing we are currently missing to make this work, is to provide a way for a mutable versioning client to tell a mutable versioning server that it wants to create a new version as a replacement of an existing version. But all we need for this is a "label" parameter to the checkin command, which tells the server which labeled version this is supposed to "replace" (effectively combining a "checkin" with a "move label" operation). So I propose that we replace the current "mutable version" option with the ability to specify a label in a CHECKIN request. This gives us one fewer option as well as significantly improved interoperability, while still providing the semantics required by a "mutable versioning" client and server. Any objections? Cheers, Geoff
Received on Friday, 5 January 2001 11:53:38 UTC