- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Tue, 22 Oct 2002 11:03:56 +0200
- To: w3c-dist-auth@w3c.org
As I interpret RFC 3253, the "stable URL"'s purpose is
a) to give each version and VHR a permanent identifier
b) to allow clients to retrieve content and properties with
this identifier.
The BIND resourceid could be used for (a). To achieve (b), the
resource id needs to be a URL.
Similar to the BIND spec, where the resource id is never altered
or lost, the "stable URL" is never altered or lost for a given
version/VHR.
Therefore:
The "stable URL" can only go away, when the resource ceases
to exist (from RFC 2518/3253 point of view).
Otherwise:
Allowing DELETE/MOVE to succeed on the "stable URL" would
allow the following case:
A client DELETEs/MOVEs a "stable URL" successfully, although
other bindings like 'xxx' to the version still exists.
A client PROPFINDs 'xxx'. Will it see a version resource?
Assuming 'no' is not to be considered.
A client makes a version tree REPORT on the VHR of 'xxx'. Under
which URL will the version be reported? The "stable URL" is
gone. However, 'xxx' cannot be used:
If you use 'xxx' for reporting that version in the version tree, clients
will assume that 'xxx' is a "stable URL" and, possibly, embed 'xxx'
into documents or mails as pointing to *the* version. But 'xxx'
is not specially protected and can be bound to any resource in
the future.
Summary:
URLs for versions/version histories, etc., when placed in deltav
live properties and reports *must* be "stable URL"s. They are
http identifiers which are bound to the lifetime of the resource.
//Stefan
Received on Tuesday, 22 October 2002 05:04:29 UTC