- From: Gary Gershon <gershon@celsus.net>
- Date: Fri, 06 Apr 2001 23:49:01 -0400
- 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 UTC