Overwrite:T behavior for COPY

In the versioning protocol, it is very important to give a client the
ability to update an existing resource via a COPY.  Unfortunately,
2518 currently says that a COPY with Overwrite:T MUST delete the
destination resource first, which means you are not updating the
resource, but rather are creating a new resource.

For versioning, this means that a COPY whose Destination is a 
version-controlled resource creates a new non-version-controlled
resource at the Destination, rather than adding a new version to
the version history of the version-controlled resource.  This
"delete" behavior has similar bad interactions with access control,
since someone that is allowed to update a resource, but not allowed
to delete that resource, would not be allowed to execute the COPY.

In earlier versions of the versioning protocol, a new value, "update"
was proposed for the Overwrite header (in addition to "T" and "F"),
to support this update behavior of COPY.

Alternatively, one could introduce an "Update" header.

A third alternative was suggested at the recent IETF meeting
by Roy Fielding, namely, that the "update" behavior was actually
the behavior intended for COPY with Overwrite:T, so the
right thing to do is to make this clarification in the
versioning protocol, rather than introducing a new "update" value
for Overwrite or a new Update header.

The consensus of the attendees of the WebDAV working group meeting
was to follow Roy's suggestion, and use this third alternative,
so this is what now appears in the latest versioning draft (10.11).

Does anyone object to this third alternative?

In particular, note that this does result in different behavior when a
collection is being copied.  In particular, the "delete" semantics
removes members that are currently in the destination but do not have
corresponding members in the source, while the "update" semantics does
not remove any members, but only updates existing members and adds new
members.

Note: Please comment on this soon, since the current plan is to submit
the versioning protocol to the IESG in January.

Cheers,
Geoff

Received on Thursday, 21 December 2000 11:56:43 UTC