RE: BIND vs. non-movable resources in RFC3253

That's an interesting issue.

To answer that, we'll have to finally decide which URIs an RFC3253 server
should report (for instance for DAV:version-history) when there are multiple
bindings. Possible answers are:

a) any
b) all
c) the stable

If the answer is a) or b), this isn't an issue. If the answer is c), then
just continue to report it. It's perfectly legal to return a URI that isn't
mapped anymore (for instance, VHRs and versions may be stored on a separate
server, and there's no way to guarantee consistency with the server the VCR
is on).

Proposal: let's try to clarify how the bindings introduced by RFC3253
actually work (DELETE semantics, reporting of URIs in live properties, ...).
Then we'll have to figure out whether this is compatible with the current
BIND draft.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
> Sent: Tuesday, October 22, 2002 11:04 AM
> To: w3c-dist-auth@w3c.org
> Subject: Re: BIND vs. non-movable resources in RFC3253
>
>
>
> 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:54:31 UTC