Next message: jamsden@us.ibm.com: "Versioning 4.0 review"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568BB.00558C3C.00@d54mta03.raleigh.ibm.com>
Date: Sat, 8 Apr 2000 11:34:20 -0400
Subject: Re: Stable URLs
Geoff,
We're making progress, just a couple more comments.
1. As Tim pointed out yesterday, why are we even considering these stable
URLs for down-level client support? Why isn't this just a client binding
issue? If a down-level client wants a stable URL to access revisions of a
versioned resource, some other versioning aware client could provide them
through bindings. Some versioning clients may even do this automatically. I
don't see why the server and protocol need to get involved in this kind of
policy issue. Workspaces and revision selection, plus bindings provides
everything needed.
2. Where does the protocol actually require these stable bindings for its
own purposes?
3. If we have to have stable bindings (note I'm using that term now as I
still think servers need to be free to impliment and reorganize their
stores independently of the WebDAV protocol), then why not have the "human"
URLs be live properties accessed through the stable bindings instead of
using a report?
|------------------------+------------------------>
| | "Geoffrey M. Clemm" |
| | <geoffrey.clemm@ratio|
| | nal.com> |
| | Sent by: |
| | ietf-dav-versioning-r|
| | equest@w3.org |
| | |
| | 04/07/2000 10:40 PM |
| | |
|------------------------+------------------------>
>------------------------|
| |
| To: |
| ietf-dav-versioning@w|
| 3.org |
| cc: |
| Subject: |
| Re: Stable URLs |
>------------------------|
From: jamsden@us.ibm.com
We can't insist that all resources have stable URLs. No current web
server does this that I know of, and it may be impossible to
support for many non-versioning inplementations.
I agree.
Stable URLs should follow WebDAV namespace collection rules.
I agree.
Some methods that operate through the stable URL might fail, like MOVE.
I agree
Even if the stable URLs did follow WebDAV namespace conventions,
the members of the collections identified by the intermediate URL
segments would probably not be meaningful names. However, they
would be members, and could be discovered using PROPFIND.
I agree.
Perhaps the BINDing spec needs to have some coupling with these
stable URLs, and the protocol should provide some way to view all
the bindings to a stable URL in order to obtain the more meaningful
names.
There is an (optional) "DAV:parents" property defined in the bindings
protocol, which contains a list of URL's of the collections that contain
bindings to that resource.
For revisions, these names could be the versioned resource
URL and a revision id.
The revision-id is available by running PROPFIND for DAV:revision-id
on the stable URL. Getting a versioned resource URL (I assume by
this you mean a user meaningful URL, as opposed to just a stable
URL for the versioned resource) is a bit harder.
For this, we need a versioning specific REPORT (since the binding
protocol won't know about versioned resource target behavior).
I think what we want here is a REPORT that takes a stable URL to
a revision or versioned resource, and returns a user URL (in the
default workspace) for that revision or versioned resource, and
returns an error if that revision or versioned resource is not
visible in the default workspace. (And yes, Tim, that's the report
you said you didn't want :-). It would then be reasonable to
allow a Workspace header to be specified for this report, so that
the client can request a user URL in *that* workspace for that revision
or versioned resource. We could call it the "DAV:user-url-report".
Cheers,
Geoff