Next message: Geoffrey M. Clemm: "Re: Stable URLs"
To: ietf-dav-versioning@w3.org
Message-ID: <OFDCE80EBC.AE5EF45D-ON852568B8.0066D91F@ott.oti.com>
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Date: Wed, 5 Apr 2000 15:24:33 -0400
Subject: Stable URLs
Here's my proposal for stable URLs.
Assumptions:
(1) A URL that is not "stable", is "dynamic".
(2) Stable URLs are server specific, and cannot be meaningfully parsed
by the client (i.e., reverse engineered into component parts). They can be
thought of as opaque tokens that conform to URL rules so that they can be
passed as request URIs.
(3) Stable URLs are indistinguishable from dynamic URLs. That is,
there is no mangling of URLs to indicate its stability.
(4) There is no visible 'meta' area of a server URL namespace. The
stable URL space is the exclusive domain of the server.
Axioms:
- The stable URl forms the equivalent of a server specific unique identity
of a resource.
- All resources, (revisions, non-versioned resources, working resources,
...) have a stable URL.
- A resource may be reached by zero or more dynamic URLs.
- There is a 1:1 mapping from resource to stable URL.
- Clients can determine the stable URL of any resource they can 'reach' by
stable or dynamic URL.
- Methods have the same effect if applied to a resource via its dynamic or
stable URL.
Usage:
Since URLs can be dynamic or stable for any request to the server, there
must be some indication of its stability in the request. The stability of
URLs in the response is defined in the protocol specification. For
example, some properties are defined as containing stable URLs. Any
request that uses a stable request URI must contains <href> elements that
are themselves stable URLs.
The general form of a request is as follows:
METHOD <request-uri> HTTP/1.1
Workspace: [stable] <workspace-url>
Target-Selector: <keyword> [<param>]
where <keyword> <param> pairs may be one of:
_Unspecified_
The request-uri is a dynamic URL. Select the resource reached
by resolving the request-uri in the context of the request workspace.
If the selected resource is a versioned resource, select a revision
of the versioned resource in the context of the request workspace.
label "my label"
The request-uri is a dynamic URL. Select the revision of the
versioned resource labelled "my label". Select nothing if there
is no such labelled revision. Ignore this header if the target
resource is unversioned.
revid "rev12"
The request-uri is a dynamic URL. Select the revision of the
versioned resource with revision id "rev12". Select nothing if
there is no such revision id. Ignore this header if the target
resource
is unversioned.
metadata
The request-uri is a dynamic URL. Select the versioned resource
itself rather than any revision of it. Return a bad request if the
target
resource is unversioned.
stable
The request-uri is a stable URL. Select the revision of the versioned
resource at the request-uri.
stable metadata
The request-uri is a stable URL. Select the versioned resource
itself rather than any revision of it. Return a bad request if the
target
resource is unversioned.
Problems:
Since discovering the members of a resource is a 'side-effect' of doing a
PROPFIND depth one query, there is no way to find the members of a
collection given a stable URL to that collection, since a PROPFIND using a
stable URL woud return the stable URLs of the members (which cannot be
parsed to reveal their names).
Comments?
Tim