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


From: Jason Crawford <ccjason@us.ibm.com>
Date: Thu, 27 Jun 2002 11:44:56 -0400
To: "Clemm, Geoff" <gclemm@Rational.Com>
Cc: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
Message-ID: <OFA5D85D9E.344E06FA-ON85256BE5.0054A2BB@us.ibm.com>

> I agree that 2 and 3 are sufficiently important use cases
> to support the DAV:source protocol element.

> I think one
> can make a reasonable case that 4 is also handled by
> DAV:source (i.e. it is a reasonable extension of 3).
Four.  That's the items that says we need a way to
know what URI to delete to remove the mapping of this
resource at this URI.

I think that would require a bit more discussion... but
we can do that now...

If a resource has multiple sources listed, we'd need to
designate which one is the one that causes the deletion
at this URI.   That's why I suggested that a single
resource be able to have multiple roles.  I was
envisioning a DELETE role... among others.

Is this reasonable?

There is also the case of a dynamic resourse that is
mapped to at URI via some manual/explicit process. An
example would be some servlet engines I've seen.  There
is a registry that says that a certain class handles
requests at a certain URL.  There must be other examples.
I assume in these servers, it's an unmapping process
that's really what is wanted.... not necessarily
the destruction of the implementation of the resource
at that URI.

In this case, the resource to delete might vary.

1) The URI itself might be deletable.
2) The server might create a virutual resource just for
    the purpose of giving the clieting something to delete
    to cause the unmapping.
3) The server might have some other process for unmapping
    the resource and not support the DELETE method to do
    the unmapping of that resource.

Is all of the a reasonable analysis?  If so, do we allow
case (3)?  If so, what do we suggest the server should
do to denote behavior (3)?

Received on Thursday, 27 June 2002 11:52:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC