- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Fri, 4 Dec 1998 23:48:10 -0500
- To: jdavis@parc.xerox.com
- Cc: w3c-dist-auth@w3.org
I concur on the preference to forbid MKREF on a non-null resource. We are planning on using references extensively for versioning, but after a quick survey, I could find no instances where I needed to do a MKREF on an existing resource. Cheers, Geoff From: Jim Davis <jdavis@parc.xerox.com> 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 23:53:14 UTC