RE: Removing a resource: A compromise that satisfies?

A few comments.

It is important to keep a clean separation between the issues of content
disposition and delete semantics. Content disposition is concerned with
policies about when documents should automatically be deleted, or archived
in some way. For example, one such policy might be to "archive on tape all
revisions older than 1 year then delete them from online storage", or
"delete any email older than 6 months". This is distinct from the semantics
of the client-initiated DELETE command when invoked on a resource.

A content disposition solution involves the definition of predicates, stored
in properties on a resource, for when certain actions are automatically
performed by the server. The semantics of DELETE are concerned with a server
reaction to a client request.

As well, it is useful to separate issues of persistence of revisions on the
authoring server, vs. persistence of revisions across the Web. It should be
clear that, if a resource is ever world-readable, then there is no way to
ensure that it hasn't been archived somewhere <http://www.archive.org/>.
However, it is possible to control persistence of revisions on the authoring
server.

Geoff Clemm writes:
> Add a new postcondition to DELETE that says:
>
> "If a server does not support the version-history feature,
> then it MAY automatically delete a version resource if that
> version no longer appears in the DAV:version-tree report
> of any version-controlled resource."

I support this approach.

John, Lisa: Let me note that one of the foundations of your argument in
favor of this capability is an indirect appeal to authority, namely the
authority of your users/customers. Now, you almost certainly cannot (or
don't want to) reveal the market research that led to your position. But,
let me note that when you (or anyone else on the list) make this kind of
argument, you have a responsibility to ensure that you have, in fact done
due diligence when reflecting your customer's requirements.

I am not asserting that you have, or that you have not done this due
diligence. I am merely noting that it should be done.

John Hall writes:
> allow the VERSION-CONTROL method to turn version-control for a
> resource at a given URL off

I think this is also a good idea. The current approach is problematic for a
client, since it requires the client to know a safe location on the server
to perform the intermediate copy (if one exists). It is not inconceivable
that a client may only have one URL on a server where it is allowed to
write. As well, by dividing the operation up into several steps, it prevents
us from adding any operation-specific semantics to the "remove from version
control" operation.

- Jim

Received on Friday, 15 June 2001 13:27:15 UTC