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

   From: Greg Stein <gstein@lyra.org>

   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.

   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 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).

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

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

   On Mon, 6 Mar 2000, Jim Whitehead wrote:
   > 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
   > 
   > > 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/
   > >
   > 

   -- 
   Greg Stein, http://www.lyra.org/

Received on Monday, 6 March 2000 23:46:10 UTC