Subject: Flavors of DELETE

From: Gary Gershon <[email-masked]>
Date: Fri, 06 Apr 2001 23:49:01 -0400

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

---

From: "Jason Crawford" <[email-masked]>
Date: Sat, 7 Apr 2001 12:41:15 -0400

My tendency would be to recommend that we finish clarifying the current
semantics of rfc2518 before we add additional concepts.  Of course we can
do this with an eye to what you've proposed so as not to preclude it as an
extension later.

------------------------------------------
Phone: 914-784-7569,   [email-masked]