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

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 6 Mar 2000 00:13:27 -0500

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:[email-masked]]
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:[email-masked]]
> 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/

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 6 Mar 2000 12:18:50 -0800

I agree with Geoff -- the Overwrite header isn't ideal for this case, since
it has "delete first" semantics, and is always associated with the
Destination of a COPY/MOVE, not the Request-URI.

- Jim

---

From: Greg Stein <[email-masked]>
Date: Mon, 6 Mar 2000 13:32:37 -0800 (PST)

I read the section 9.6 in the spec about the Overwrite header itself. It
doesn't mention anything about DELETE. You guys are (IMO, incorrectly)
associating Overwrite with MOVE/COPY. I feel that the right way to look at
it is "what does MOVE/COPY do when Overwrite is present?" Another way to
say it is that you're creating too strong of a binding between the
semantics of the COPY/MOVE methods and the presence of that header.

By your logic, every method should have its own set of associated headers.
We should never share headers. We'll have Overwrite, MKREF-Overwrite, etc.

I wouldn't be upset with a "merge" definition, but I did have to respond
to the way you guys are approaching the problem :-)

Cheers,
-g

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Mon, 6 Mar 2000 23:45:57 -0500 (EST)

From: Greg Stein <[email-masked]>

   I read the section 9.6 in the spec about the Overwrite header itself. It
   doesn't mention anything about DELETE. You guys are (IMO, incorrectly)
   associating Overwrite with MOVE/COPY.

In understanding the meaning of a header, I believe it is valid
to consider both what the definition of the header says, as well
as what the header means when used with current methods.

If all defined uses of the Overwrite:T header means to delete the
current resource at the Destination location before performing the
request, then I think one should be cautious about having it mean
something else for a new method.

Now if there is something about the current usage that doesn't
apply to the new method, then I think it is reasonable to ignore
that aspect of the current usage.  For example, I wouldn't be
that concerned about having Overwrite:T apply to the Request-URL
for MKREF, since there is no Destination header.

But I'd be concerned about the ignoring the "delete existing resource"
usage.  This is a very reasonable behavior for a MKREF request.
In particular, what if a client *wanted* to say to "delete the
current resource at this location and then create a redirect
reference there".  Having the Overwrite:T header mean
this for some methods, and mean "update the existing resource"
for other methods seems likely to cause errors and confusion.

But I continue to be supportive of an Overwrite:Merge or
Overwrite:Update form of the Overwrite header to handle this
case.  I believe it is appropriate for this to be an alternative
Overwrite value rather than a new header, since this an
alternative to Overwrite:T or Overwrite:F, not some orthogonal
behavior.

   I feel that the right way to look at
   it is "what does MOVE/COPY do when Overwrite is present?" Another way to
   say it is that you're creating too strong of a binding between the
   semantics of the COPY/MOVE methods and the presence of that header.

I certainly think we should share headers, but that
`MKREF Overwrite:F' should mean "fail the MKREF if there
already is a resource at that location", and `MKREF Overwrite:T' should
mean "delete the resource at that location, and then perform the MKREF"
(since that's what they mean for COPY and MOVE).

Does the approach sound more reasonable with this additional explanation,
or do you still object?  (It sounds like at least 2 of us are OK with
the "Merge" suggestion, but I think JimW doesn't like it ... although
I'm not sure why not ... maybe it's time to put him on the spot :-).

Cheers,
Geoff