RE: MKREF on existing resource

The reason for 3.3.1 was strictly to keep MKREF analogous with PUT, but I
agree that this is not satisfactory if the resource that's being replaced is
a collection.  It also raises a sticky issue about whether MKREF on a direct
references gets passed through.  I like your suggestion that we just forbid
MKREF on an existing resource.  So that's what I'll do unless anyone
objects.

As I was looking through the spec for problems this change might cause, I
noticed another change that probably should be made.  In the section on
dangling direct references, I said that PUT, MKCOL, and MKREF should
succeed, but that really doesn't make sense.  PUT should succeed.  But MKCOL
and MKREF should fail, I think.  MKCOL would fail for a healthy direct
reference, and it would be odd if the fact that a reference was broken could
make it succeed.  The same holds for MKREF if it gets passed through; if it
doesn't get passed through, it should fail because it's being applied to an
existing resource. 

--Judy

Judith A. Slein
CR&T/ADSTC
jslein@crt.xerox.com
8*222-5169


> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Thursday, December 03, 1998 10:05 PM
> To: w3c-dist-auth@w3.org
> Subject: ACR: MKREF on existing resource
> 
> 
> 3.3.1 says "If a MKREF request is submitted for an existing 
> resource, the
> existing resource's content and headers will be overwritten.  
> This behavior
> is analogous to the behavior of the HTTP PUT method. "
> 
> I would prefer to forbid MKREF on an non-null resource.
> 
> My objections to the specified behavior are:
> 
> 1. It is problematic if the resource is a collection.  It 
> gives MKREF some
> of the semantics of DELETE.  Near as I can tell, WebDAV does 
> not allow PUT
> to a collection, or at least leaves it undefined.  Why allow MKREF?
> 
> 2. We don't allow MKCOL on an existing resource, why allow MKREF?
> 
> I don't see any real advantage to it, either.  The only 
> advantage I can see
> is that if there are existing dead properties they will be left
> undisturbed.  If we decided instead that one must DELETE, 
> then the client
> would have to PROPFIND (to get copies of the properties), 
> DELETE, MKREF,
> then PROPPATCH (to replace the properties).  This does not seem
> unreasonably burdensome to me, and it simplifies  things.
> 
> Finally, strictly editorially, I don't know what it means to 
> 'overwrite
> headers'.
> 
> best wishes
> 
> Jim
>   
>

Received on Friday, 4 December 1998 10:13:39 UTC