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

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 10 Apr 2001 18:45:11 -0400

Well, since we've got Roy's attention (:-) ...

If your server does DELETE's to a trash collection (instead of making
it totally disappear), wouldn't that fall under the "capabilities"
of your server?  And if your server maintains that trash collection
at a fixed location (for all resources on that server), why would that
be unreasonable/bad information to include in the OPTIONS response
(I am assuming that we give OPTIONS a request body in which the 
client indicates what OPTIONS information it is interested in).

To emphasize, I don't advocate this approach (i.e. live properties are
fine with me), but the topic has been raised in several threads, and I
haven't seen a convincing argument either way.  (Note: There has been
no lack of definitive statements ... but unfortunately the definitive
statements from different people have not agreed with each other :-).

On the separate topic of header vs. method body, although it is
clear that method semantics of concern to a proxy should be in
headers (so that the proxy doesn't need to process the body),
could you motivate why the detailed request semantics needed only
by the resource implementation shouldn't appear as XML (WebDAV
seems to work reasonably well with request bodies like PROPPATCH
in XML).  Is it important for a proxy to know whether or not a 
DELETE'd resource has been copied/moved to a trash collection?
Or is it some other argument against XML (XML parsers are pretty
trivial).

Cheers,
Geoff

   From: Roy T. Fielding [mailto:[email-masked]]

   On Tue, Apr 10, 2001 at 05:36:25PM -0400, Clemm, Geoff wrote:
   > Some folks prefer to use OPTIONS for things that are true
   > for the whole server, and some folks just
   > hate live properties, but the live property is fine with me.

   OPTIONS is for communicating extensions and capabilities, not for
   identifying the URI of a trash resource.  That is simply an external link
   in hypermedia parlance.

   > As for the issue of whether to marshal in a request header vs. in a
   > request body, a new request header eats up part of a global namespace,
   > whereas an XML request body can use namespaces to keep extensions
   > from stepping on each others toes, so I stand by my
   > preference for using the request body for method specific parameters
   > (of course, for methods like PUT that use the request body for content,
   > that is not an option).

   XML namespaces are no more capable of extensions than a global namespace
   controlled by a standard.  The only difference is who gets to define
them.
   HTTP and XML have different design philosophies in that regard, and so
   far the HTTP one has proven to be right (XML namespaces are 100%
extensible,
   but have almost zero interoperability success).  I'm not sure yet which
   type of extensibility is better for a protocol.  I only know that needing
   to parse XML in order to determine request semantics is totally and
   irretrievably bad design.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 10 Apr 2001 18:54:51 -0700

> Well, since we've got Roy's attention (:-) ...

DAV always has my attention -- I just don't usually have time to argue.
Right now I am procrastinating from doing my taxes.

> client indicates what OPTIONS information it is interested in).

The fact that a server runs on a Pentium III 500MHz CPU falls under
"capabilities" too, but that doesn't mean that an OPTIONS message should
advertize it as such.  OPTIONS was intended for info that defines the
interoperability mechanisms available at the server/resource.
It would have been better defined as a PROPFIND that returned a property
consisting of a link to a URL space containing configurable options as
resources, but OPTIONS predates properties by a long shot.  Alternatively,
we could stick a fork in this subject by deprecating PROPFIND and just
using OPTIONS for all property retrievals.  I bet that would be popular.

> statements from different people have not agreed with each other :-).

Okay, let's try one.  Is it possible for a web server to have multiple
trash cans?  Yes -- that is a resource implementation issue -- the
resource URI hierarchy visible to the client may span hundreds of
separate systems/disks/virtual spaces behind the web server interface.  
So, from an interoperability standpoint, it is pointless to ask the
server itself (without using a URL) for a reference to a trash can
for all of its resources.  Therefore, the relationship between a resource
and its potential trash can must be resource-specific.  That means it
is either a property of the resource or a property of a container of
that resource (which, by inference, makes it a property of the resource).

So it can be a live property or a dead property. If we make it a dead
property, then a client is allowed to set its value, which is something
that could be considered a security problem if the server isn't careful
about checking the value.  OTOH, it might be useful if we wanted to
define a distributed trash can protocol, wherein the server POSTs the
content to the trash can resource as part of the DELETE. *shrug*
Of course, access control on that property becomes an issue, but that
would lead me down the rathole of why the set of properties of a
resource are themselves resources ...

We are then left with the question of what is the most appropriate
mechanism for revealing a property of a resource to the client of a
webdav server?  If the answer is not PROPFIND, then why should any other
property be retrievable via PROPFIND?

Regarding the trash can itself, it is either accessible to clients
as a resource or not accessible at all (because there is no such thing
as accessing something other than a resource on the Web).  If it is a
resource, then what kind of resource is it?  I suppose it could be
anything, but if we want the trash can to be browsable like any other
DAV resource space (as is the case for Macintosh and Windows trash cans),
then the only reasonable choice is a collection resource.  Otherwise
we'd have to define a completely new protocol standard for interoperating
with trash cans, for which I doubt we can find any volunteers.

So, the right protocol is to allow each resource to have an optional
property that is a link to a collection resource that can be operated
upon as a trash can, with appropriate access control.

> Or is it some other argument against XML (XML parsers are pretty

Application-level semantics need to be visible for any intermediary,
not just proxies.  How does the client know that it is talking to
the origin server?  For this specific request semantic, it probably
doesn't matter because the effect on intermediaries is already covered
by the method name.  However, what you stated earlier was a general
principle, which caught my eye because your description contradicts one
of the design principles of HTTP that I described in my dissertation.

As you probably noted, I get a little annoyed whenever webdav contradicts
my dissertation, regardless of whether or not it is the right solution.  ;-)

Back to the original question, I don't see any reason to allow the client
to choose whether or not the DELETE goes to the trash can.  A trash can is,
after all, just a poor man's form of version control.  I think it should be
set as part of the configuration of a containing collection resource,
either by the server internals or by linking to a resource on the server
that knows how to be a trash can.

Cheers,

Roy T. Fielding, Chief Scientist, eBuilt, Inc.
                 2652 McGaw Avenue
                 Irvine, CA 92614-5840  fax:+1.949.609.0001
                 ([email-masked])  <http://www.eBuilt.com>

---

From: Bruce Williams <[email-masked]>
Date: Tue, 10 Apr 2001 19:20:43 -0700

Point! Good security practice is to "firewall" and not reveal too
much.
A subsystem that "tells all" is frowned upon by at least some admins.

Good practice in standards development is to find the "least" that
has to be
defined. Why does this can of worms have to be opened? 

What is the minimal functionality needed and why? Just asking. :-)
If we are VERY clear on what we have to do, we will find a way
to do it, I guess. Otherwise we will "what if" forever.

Bruce Williams            [email-masked]
- ----------------------------------------------------------------------
- --
Hic locus est ubi mors gaudet succurrere vitae

- ----- Original Message -----
From: "Roy T. Fielding" <[email-masked]>
To: "Clemm, Geoff" <[email-masked]>
Cc: "WebDAV Working Group" <[email-masked]>
Sent: Tuesday, April 10, 2001 6:54 PM
Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE)

> DAV always has my attention -- I just don't usually have time to
> argue. Right now I am procrastinating from doing my taxes.
>
> > If your server does DELETE's to a trash collection (instead of
> > making it totally disappear), wouldn't that fall under the
> > "capabilities" of your server?  And if your server maintains that
> > trash collection at a fixed location (for all resources on that
> > server), why would that be unreasonable/bad information to
> > include in the OPTIONS response (I am assuming that we give
> > OPTIONS a request body in which the client indicates what OPTIONS
> > information it is interested in). 
>
> "capabilities" too, but that doesn't mean that an OPTIONS message
> should advertize it as such.  OPTIONS was intended for info that
> defines the interoperability mechanisms available at the
> server/resource.
> It would have been better defined as a PROPFIND that returned a
> property consisting of a link to a URL space containing
> configurable options as resources, but OPTIONS predates properties
> by a long shot.  Alternatively, we could stick a fork in this
> subject by deprecating PROPFIND and just using OPTIONS for all
> property retrievals.  I bet that would be popular. 
>
> > To emphasize, I don't advocate this approach (i.e. live
> > properties are fine with me), but the topic has been raised in
> > several threads, and I haven't seen a convincing argument either
> > way.  (Note: There has been no lack of definitive statements ...
> > but unfortunately the definitive statements from different people
> > have not agreed with each other :-). 
>
> Okay, let's try one.  Is it possible for a web server to have
> multiple trash cans?  Yes -- that is a resource implementation
> issue -- the resource URI hierarchy visible to the client may span
> hundreds of
> separate systems/disks/virtual spaces behind the web server
> interface. So, from an interoperability standpoint, it is pointless
> to ask the server itself (without using a URL) for a reference to a
> trash can for all of its resources.  Therefore, the relationship
> between a resource and its potential trash can must be
> resource-specific.  That means it is either a property of the
> resource or a property of a container of that resource (which, by
> inference, makes it a property of the resource). 
>
> So it can be a live property or a dead property. If we make it a
> dead property, then a client is allowed to set its value, which is
> something that could be considered a security problem if the server
> isn't careful about checking the value.  OTOH, it might be useful
> if we wanted to define a distributed trash can protocol, wherein
> the server POSTs the content to the trash can resource as part of
> the DELETE. *shrug*
> Of course, access control on that property becomes an issue, but
> that would lead me down the rathole of why the set of properties of
> a
> webdav server?  If the answer is not PROPFIND, then why should any
> other property be retrievable via PROPFIND?
>
> as a resource or not accessible at all (because there is no such
> thing as accessing something other than a resource on the Web).  If
> it is a resource, then what kind of resource is it?  I suppose it
> could be anything, but if we want the trash can to be browsable
> like any other DAV resource space (as is the case for Macintosh and
> Windows trash cans), then the only reasonable choice is a
> collection resource.  Otherwise we'd have to define a completely
> new protocol standard for interoperating with trash cans, for which
> I doubt we can find any volunteers.
>
> So, the right protocol is to allow each resource to have an
> optional property that is a link to a collection resource that can
> be operated upon as a trash can, with appropriate access control.
>
> Application-level semantics need to be visible for any
> intermediary, not just proxies.  How does the client know that it
> is talking to
> doesn't matter because the effect on intermediaries is already
> covered by the method name.  However, what you stated earlier was a
> general principle, which caught my eye because your description
> contradicts one of the design principles of HTTP that I described
> in my dissertation. 
>
> As you probably noted, I get a little annoyed whenever webdav
> contradicts my dissertation, regardless of whether or not it is the
> right solution. 
;-)
>
> Back to the original question, I don't see any reason to allow the
> client to choose whether or not the DELETE goes to the trash can. 
> A trash can 
is,
> after all, just a poor man's form of version control.  I think it
> should 
be
> set as part of the configuration of a containing collection
> resource, either by the server internals or by linking to a
> resource on the server that knows how to be a trash can.
>
> Cheers,
>