W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: Move and Delete (was: bind draft issues)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 5 Mar 2003 01:07:25 +0100
To: "Jason Crawford" <nn683849@smallcue.com>, "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Clemm, Geoff" <gclemm@Rational.Com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKEHBGKAA.julian.reschke@gmx.de>

> From: Jason Crawford [mailto:nn683849@smallcue.com]
> Sent: Wednesday, March 05, 2003 12:56 AM
> To: Julian Reschke
> Cc: Clemm, Geoff; 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
> ...
> > > Or... you can just reject BIND requests to directories.  :-)
> >
> > Even if I'd do that, the current wording of the BIND draft does
> not allow
> me
> > to keep my current RFC2518-compliant DELETE implementation. I feel this
> is a
> > problem.
> Right.  To claim BIND spec support, you have enhance the implementation to
> support *this*  2518 compliant approach.... or to avoid a situations where
> bind spec
> violations would happen.   It's not unreasonable to expect one to have to
> add code
> in order to support a new feature like multiple-bindings.

Actually, I'd have to remove code.

The issue isn't that the server can't *technically* do this -- it's that the
this semantics isn't compatible with the existing DELETE semantics of our
system. Just removing the collection binding without checking that all
internal members may be deleted as well simply is *not* an option.

So basically we have the choice between

- supporting multiple bindings, but not the BIND method described in the
draft, or
- simply ignore this requirement.

I'd rather have a spec that I can implement without having to break a
specific requirement (in particular if i'm not convinced it adds value to my
use case).


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 4 March 2003 19:07:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:27 UTC