W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

Flavors of DELETE

From: Gary Gershon <gershon@celsus.net>
Date: Fri, 06 Apr 2001 23:49:01 -0400
Message-Id: <5.0.0.25.2.20010406220005.03135058@pop3.norton.antivirus>
To: WebDAV Working Group <w3c-dist-auth@w3.org>
I didn't see anything in RFC2518 or earlier in my archives of this list 
regarding discussions of the semantics of the DELETE method.   I'd welcome 
the group's thoughts on the following:

A number of file systems and document management systems provide safety 
nets such as a "Recycle Bin" or "Trash Folder" where deleted documents are 
sent  (moved).  This may not always be desirable for technical and business 
reasons.  Windows, for example, recognizes this and provides a keyboard 
shortcut (shift-delete) to indicate that a document should not be sent to 
the Recycle Bin.

Additionally, some systems are implemented to also allow documents to be 
securely deleted by overwriting the file on the disk media  to ensure the 
content of the deleted documents cannot be inadvertently or intentionally 
discovered from unallocated or reallocated media blocks.

I would like to propose an optional header for the DELETE , PUT, MOVE, and 
COPY methods (the latter three can have implicit deletes) which would allow 
specification of these semantics for implementations in which they are 
supported by the underlying system.

As a starter, I was envisioning a header like "Disposition" with a single 
parameter:

	0 (or omitted) = Default server processing,
	1 = Move deleted file to a recovery folder (e.g. Trash),
	2 = Do NOT move deleted file to a recovery folder, and,
	3 = Do NOT move deleted file to a recovery folder AND overwrite its media 
blocks.

If the implementation provided simple automated versioning (short of 
DeltaV), I would suggest extending the semantics of PUT with this header in 
a similar way:

	0 (or omitted) = Default server processing,
	1 = Store as a new version, even if the default may not be to create 
versions for this resource,
	2 = Store as a  replacement version, and do NOT retain the most recent 
previous 	instance as a version, and,
	3 = Store as a replacement version  and do NOT retain the most recent 
previous
	instance as a version  AND overwrite its media blocks.

If these have merit, then there should also be options to "Do NOT retain 
ANY previous instances..."  etc.  This would be equivalent to finalizing or 
publishing the document and disposing of the historical artifacts.

Gary
Received on Friday, 6 April 2001 23:50:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:55 GMT