- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 10 Feb 1998 14:18:51 -0800
- To: "'Dylan Barrell'" <dbarrell@opentext.ch>, "'WebDAV'" <w3c-dist-auth@w3.org>
- Cc: "Brian Deen (Exchange)" <briande@exchange.microsoft.com>
The requirement to which you refer was the result of some historical cruft that didn't get properly collected. Once upon a time, about 8 or 9 months ago I believe, this requirement was reasonable. However now it suffers from the flaw that the type of resource to be created is not properly specified. To do so would require a subsequent MKCOL or PUT to clarify its state, in the meantime the resource would be a in strange middle state. While we have dealt with this exact same situation previously, in the case of locking a null resource, our actions there were able to be properly circumscribed by specifying both the exact nature of the resource's behavior while in the middle state and requiring that if the resource was not PUT or MKCOL'd before the lock was removed then the resource would return to its NULL state. Making a similar requirement here is not likely to be worth the added complication to the spec. As such I propose that the requirement: If PROPPATCH is invoked on a null resource (e.g., a deleted resource), an empty resource MUST be created, and the PROPPATCH directives will then be performed on this new resource. be struck from the specification. Yaron > -----Original Message----- > From: Dylan Barrell [SMTP:dbarrell@opentext.ch] > Sent: Monday, February 09, 1998 7:09 AM > To: 'WebDAV' > Subject: 7.2 PROPPATCH > > requiring PROPPATCH to create an empty resource if operated on a > non-existent resource is counter-intuitive and not generally a good design > decision. > > If you need to he ability to create an empty resource then rather modify > PUT to allow the putting of an empty resource. > > Cheers > Dylan
Received on Tuesday, 10 February 1998 17:33:12 UTC