Next message: Clemm, Geoff: "RE: Stable URLs"
To: ietf-dav-versioning@w3.org
Message-ID: <OF7AB7521F.06D9F799-ON852568B8.0071B239@ott.oti.com>
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
Date: Wed, 5 Apr 2000 16:55:49 -0400
Subject: Re: Stable URLs
Thanks for the prompt response Geoff, see my comments tagged by <tim/>
below.
Tim
---------
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.
So they do not form a WebDAV "consistent namespace"? So there are no
collections? I don't see how this can be compatible with your later
"acts the same in either dynamic or static namespace" requirement.
<tim/>Correct, stable URLs are totally at the whim of the server. If an
underlying store chooses to maintain all resources in a flat list of GUIDs,
then it is free to do so (and the stable URLs would all be of the form
/<guid>).
(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.
Adding a header that says "switch to a completely different namespace"
is pretty drastic. In particular, why not just use existing namespace
functionality, namely, let the server allocate a meta area of the
server URL namespace, or let the server introduce a "metadata virtual
host"? What does the separate namespace buy you that makes up for the
cost of needing these "stable" flags in the Workspace and
Revision-Selector headers.
<tim/> This came from the requirement to not have any part of the user's
URL space hijacked by the server for storing metadata. I remember previous
long discussions about this.
It buys you the ability to say to clients 'no part of the namespace is out
of bounds to you'.
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.
I don't agree with the last axiom. There will be some methods (such as
MOVE) which will fail for a stable URL but succeed for a dynamic URL.
There are other methods (such as depth:infinity PROPFIND) that will have
a different effect in stable and dynamic URL space.
<tim/>Methods such as MOVE would allow the source to be given as a stable
URL, I agree that the destination may not be stable.
I don't see why depth:infinity would have a different effect, since it
means go to the (collection) resource with the given stable URL, then
follow its members deep. How you got to the resource is immaterial.
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.
I'm not sure what the last sentence is saying. Can you clarify?
<tim/>If you make a request, using a stable URL, that responds with an
<href> tag element, then that href is a stable URL. For example, PROPFIND
depth:infinity would return all the reachable resources and provide
propstat results for them in terms of their stable URL.
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).
If you make the stable namespace a consistent WebDAV namespace, then
PROPFIND will return reasonable member names which will give you the
information you want ... why didn't you want the stable namespace to
be a consistent WebDAV namespace?
<tim/>How will the client/server know which parts of the URL are stable,
and which are not?
http://foo.com/RID:9/REV:12/bar
is this a RID:9 member in collection '/' or the start of a stable URL?
is REV:12 a member of the revision selected for the (collection) resource
'/RID:9/' or a continuation of the stable URL?
<tim/>Making the name a consistent namespace means that the client can
'interpret' or 'decode' the resource URN -- I don't think this makes sense.
Cheers,
Geoff