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

RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000

From: Clemm, Geoff <gclemm@Rational.Com>
Date: Mon, 6 Mar 2000 00:13:27 -0500
Message-ID: <65B141FB11CCD211825700A0C9D609BC02191F40@chef.lex.rational.com>
To: WebDAV WG <w3c-dist-auth@w3.org>
For both current uses of the Overwrite header (COPY and MOVE), the use
of Overwrite means to first delete the resource (if any) that exists at
that location.  I.e.:

   8.9.3 MOVE and the Overwrite Header

   If a resource exists at the destination and the Overwrite header is
   "T" then prior to performing the move the server MUST perform a
   DELETE with "Depth: infinity" on the destination resource.

   8.8.4 COPY and the Overwrite Header

   If a resource exists at the destination and the Overwrite header is
   "T" then prior to performing the copy the server MUST perform a
   DELETE with "Depth: infinity" on the destination resource.

To define its semantics for MKREF to differ in this regard
seems likely to result in confusion and errors on the part of implementors.

In the past, I've proposed that we extend the Overwrite header to allow
a "Merge" value (i.e. Overwrite:Merge).  If we did so, then the use of
of "Overwrite:Merge" would allow us to consistently use MKREF and an
Overwrite header to update the value of the redirect reference. 

Cheers,
Geoff


-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Friday, March 03, 2000 5:30 PM
To: Slein, Judith A
Cc: 'Joe Orton'; WebDAV WG
Subject: RE: Bindings and Redirect Ref. teleconf. Mar. 1, 2000


Why would it have to delete the properties?

Overwrite is defined to "... overwrite the state of a non-null destination
resource ...". It is specified in terms of a COPY/MOVE, and we can state
that for a MKREF, it *only* overwrites the target.

There is no other language that forces us to interpret Overwrite as
"DELETE the resource first [implying the props are deleted]".

I really like Joe's idea.

Cheers,
-g

On Fri, 3 Mar 2000, Slein, Judith A wrote:
> It's certainly a possibility.
> 
> The only problem I can see with relying on MKREF is that it would not just
> update the target, but would replace the resource with a new resource.
> That's probably harmless if it's an HTTP resource with no properties, but
if
> it is a WebDAV resource it might have properties that you would like to
> preserve while updating its target.
> 
> --Judy
> 
> -----Original Message-----
> From: Joe Orton [mailto:joe@orton.demon.co.uk]
> Sent: Wednesday, March 01, 2000 7:05 PM
> To: WebDAV WG
> Subject: Re: Bindings and Redirect Ref. teleconf. Mar. 1, 2000
> 
> 
> > Issue #6: Need to add rationale for why we use relative URLs. Server is
> > required to store it as a relative URL.  Server MUST NOT change the
> relative
> > URL during a MOVE.
> > 
> > Raises the issue of needing separate methods for getting the value of a
> > reference, and modifying the value of a reference.  Tentatively agreed
on
> > REFGET, REFSET (but noone likes these too much).
> 
> The original -00 spec allowed MKREF with Overwrite, could this be used
> instead of REFSET?
> 
> joe
> 

-- 
Greg Stein, http://www.lyra.org/
Received on Monday, 6 March 2000 00:44:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:54 GMT