RE: [offlist] WebDAV Delete post (Flavors of DELETE)

Perhaps this would be a good candidate to solve with status-reporting.  THe
server can do whatever it's configured to do, and send a slightly different
success response depending on whether it truly, really, deleted the file, or
whether it moved it (and can specify location).  This allows the client to
potentially delete the trash version.

I also just realized, Gary, that we can't guarantee that clients will always
be able to force a true delete.  It might be against the wishes of the
administrators of the system.  So a system-wide trash bin might be set up to
not allow stuff to be removed from it.  Useful if auditing is required, no?

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, April 10, 2001 9:27 AM
> To: WebDAV Working Group
> Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE)
>
>
> Good points.  I agree that a client that wants to provide the advanced
> behavior to a downlevel client would have to provide an override
> capability (e.g. some method arguments) for an advanced client
> that wants "the other" functionality.
>
> There remains the question of whether (in this particular case)
> the benefit
> of providing advanced behavior to downlevel clients is worth the cost
> of adding these parameters to the DELETE method (protocol bloat, and all
> that ...).
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
>
> Geoff,
>
> Good suggestion about marshalling in the body rather than the
> headers.  But
> the DELETE/MOVE choice won't work.
>
> The problem is that choosing the default behaviour means working with
> clients that are minimally DAV compatible, and that means that
> one maps the
> request that those clients are going to make (DELETE) to the default
> behaviour.  One puts the onus on clients that understand the difference to
> make the special request (DELETE + I-mean-it-really-blow-it-away).
>
> Ugly, but that's the kind of compromise one has to make when designing a
> protocol piece by piece.  It's the price we pay for having been able to
> finish DAV when we did rather than 10 yrs from now :)
>
> lisa
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Tuesday, April 10, 2001 7:42 AM
> > To: 'Gary Gershon'; Bruce Williams
> > Cc: WebDAV Working Group
> > Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE)
> >
> >
> > On the issue of trash folders:
> >
> > HTTP headers are a poor way of marshalling method specific
> > information.  A header exists in a global namespace, and should be
> > reserved for things that proxies need to look at.
> >
> > So if you want to extend DELETE, I would suggest following the
> > standard WebDAV approach and add an XML request body to the DELETE
> > method.
> >
> > In the specific case of trash folders, I would suggest a different
> > approach.  In particular, I would add an OPTIONS parameter that would
> > let you find out "where is the trash collection for this resource".
> > Then the client could either issue a DELETE or a MOVE to that trash
> > collection, depending on what the user wants to do.
> >
> > Cheers,
> > Geoff
> >
> >
> >    From: Gary Gershon [mailto:gershon@celsus.net]
> >
> >    ...
> >    I think a bit of background on my suggestion that we have an
> >    additional WebDAV HTTP header for delete processing would clarify
> >    its goals:
> >
> >    I've been working on enterprise WebDAV implementations for the last
> >    year, primarily using the Xythos server.  Xythos provides a very
> >    handy option to allow deleted files to be automatically stored in a
> >    trash folder associated with the particular root directory.  This
> >    is great for the "oops" factor where one wants to recover a deleted
> >    file, and complements their automatic versioning facility.
> >
> >    Other implementations, of course, have different schemes, and this
> >    is why it would be good to be able to express the original DELETE
> >    request more fully in WebDAV.
> >
> >    We have four use cases where we do not want this trash-foldering to
> >    happen:
> >
> >    1.  The user wrote something (perhaps in haste, or perhaps
> >        something that was confidential) that he/she does not want to
> >        be subsequently read by others either within the organization,
> >        or through the legal discovery process.
> >
> >    2.  The document was being added by a program within a long-running
> >        unit-of-work and we want to do a rollback, rather than a
> >        commit, after it has already been stored and committed to the
> >        document server.  Here we want to avoid wasting space.
> >
> >    3.  Documents are being moved to long-term archive storage and
> >        deleted from the operational system to free space.  This is
> >        done by a records retention application on a recurring (perhaps
> >        yearly) basis.  By definition, we want to delete it completely
> >        from the operational system.
> >
> >    4.  The user was using the file system to hold documents (and
> >        versions) temporarily as work-in-process.  When the document is
> >        deemed finished ("Published") the temporary work products
> >        should not be retained.
> >
> >    We like having the trash folder, so our current "work-around" to
> >    permanently delete a document is to issue two deletes.  First for
> >    the document, and then for the trash folder copy.  This requires
> >    the client (human or application) to know about the trash folder
> >    and have permission to delete stuff from it.
> >
> >    It would be better if a single DELETE could communicate the entire
> >    request.  This avoids having the client know the structure of the
> >    repository, have access to the trash folder, and avoids
> >    unit-of-work problems when multiple requests are required to
> >    fulfill the delete process.
> >
> >    ...
> >
> >    By adding a new delete header, the goal would be to have WebDAV
> >    fully communicate the client's intent in a single HTTP request.
> >    How the server honors the request depends on the implementation.
> >    If the installation is using a programmable server then they can
> >    customize this behavior to satisfy their business requirements.
> >
> >    I think an environment of appropriate security can thus be built
> >    using WebDAV.  I don't view the 'trash' folder as an OS flaw, but
> >    as a capability that serves to benefit the user community.  It
> >    needs to be implemented and managed to meet business document
> >    retention requirements, and also eliminate the potentially wasteful
> >    accumulation of truly dead documents.  Bruce, I think you are quite
> >    correct, if we are to have a secure environment, it will indeed
> >    take a overt effort to this end, and this requires a thoughtful
> >    technical implementation of WebDAV clients and servers.
> >
> >    Gary
> >
> >    At 11:12 PM 4/8/2001 -0700, you wrote:
> >
> >    Gary,
> >
> >    The delete, delete from trash, clear sectors on disk options you
> >    made reference to brings up something I have always been unclear
> >    about - what is the 'security' level required/provided by WebDAV?
> >    As the range of options you mentoned show, this is a classic
> >    "slippery slope".  Where does it end?
> >
> >    I believe many activities delete and leave items in the 'trash'.
> >    This can in some ways be viewed as a design flaw in the OS, or at
> >    least a flaw at some level of desired security. And this is the
> >    point - - if the desired level of security is above that provided,
> >    in general, by the OS - are we to attempt to make up for this?
> >
> >    If we are to produce a 'secure' enviroment, ( not a bad thing! ), I
> >    believe it will take a overt effort to this end. Otherwise, we will
> >    just introduce complications here and there as we "see problems" to
> >    no real overall gain.
> >
> >    But what do I know? :-)

Received on Tuesday, 10 April 2001 12:42:49 UTC