cross-server resource identity
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Wed, 11 Aug 1999 14:19:18 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Aug11.141522.1250.1285133@otismtp.ott.oti.com>
Date: Wed, 11 Aug 1999 14:19:18 -0400
Subject: cross-server resource identity
All,
While I agree with the general idea of leaving replication out of scope,
there appears to be significant requirements for copying resource
revisions between DAV servers/repositories. Given the current protocol
there is no way of uniquely identifying resources (actually revisions)
when they are put in other repositories/servers. The {history-uuid,
revision-id} pair is close to what we need but neither values are
settable. Since we have no server-server protocol, the only way to get a
resource from one server to another is through client-side copy (i.e.,
GET then PUT).
A writable property (perhaps "DAV:revision-uuid") which contains a
guaranteed unique id in a specified form is needed. This id should not
include the actual server but should be something like {repository-id,
versioned-resource-id, revision-id} where:
repository-id = some GUID
versioned-resource-id = some id which is unique relative to a repository
revision-id = as currently defined
If we concatenate these we get a GUID (by virtue of the GUID-ness of the
repository-id and the relative uniqueness of the other ids). Copying
clients can then tag copies with this value and be able to identify when
two resources in different servers are in fact the same resource. So,
for example, when copying, the client can eliminate duplicate copies and
reduce the possibility of merge conflicts.
CHECKIN should set this value if it is not already set on the working
resource. Once the tag is set, it should not be changeable (not sure if
we want to enforce this). When copying to a new server, the destination
server will necessarily need to create a new versioned-resource and thus
versioned-resource-id. Also, the repository-id of the desintation is
guaranteed to be different. The revision-id may or may not be different
(depending on chance). In short, the *computed* DAV:revision-uuid of the
copy will be different than the value actually in the property. This is
ok/expected as this reflects the intended semantics and the property is
not used by the server.
This mechanism does not preserve cross-server history etc. but this is
acceptable (IMHO) as I am only proposing some support for cross-server
identity detection, are not real replication.
Thoughts/comments?
Jeff