W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1998


From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 10 Feb 1998 14:18:51 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D0113C883@red-msg-59.dns.microsoft.com>
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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:13 UTC