- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 25 Jun 2001 23:36:42 -0400
- To: Webdav WG <w3c-dist-auth@w3c.org>
From: Alan Kent [mailto:ajk@mds.rmit.edu.au] On Mon, Jun 25, 2001 at 08:53:54AM -0400, Clemm, Geoff wrote: > RFC-2518 currently states in section 8.3: > > The MKCOL method is used to create a new collection. All DAV > compliant resources MUST support the MKCOL method. What does this really mean? Does a resource support MKCOL? RFC-2518 tries to present a model where every URI is mapped to some resource, but that most URIs are mapped to a (or perhaps, "the") null resource. In that model, yes, a resource supports MKCOL (in particular, some null resources and all lock-null resources). Is MKCOL "applied" to the parent collection? A method is usually described as being applied to the request-URL, but I agree that some operations (e.g. MKCOL and DELETE) result in modifications to the parent collection of the request-URL. The URI is the new collection resource to be created isn't it? Yes. If I have a non-collection resource (eg a web page /foo.html), is it mandatory that I be able to do a MKCOL /foo.html/newcoll? Actually, it is required that it fail, since for /foo.html/newcoll to be a consistent DAV namespace, /foo.html MUST be a collection. > But then section 8.3.1 goes on to say: > > If the resource identified by the Request-URI is > non-null then the MKCOL MUST fail. > > I believe the second sentence of 8.3 should be changed to read: > "All DAV compliant null and lock-null resources MUST support > the MKCOL method". I think I sort of agree with what you are saying, but isn't it more that the MKCOL method is really being applied to either the parent collection resource or a lock-null resource (if it exists for the new collection URI)? If we fix the model in 2518, yes. My modified text was intended to be compatible with the model currently exposed by 2518. I am not sure of the wording - my point is that not all "null" resources need to support MKCOL. In general, the fact that a resource supports a method does not mean that the method will succeed when being applied to that resource (for example, a version-controlled resource supports both the CHECKOUT and CHECKIN operations, but only one will succeed at any given time. So in the MKCOL case, a null resource can be said to support the MKCOL operation, even if it will fail when the parent of the null resource is also a null resource (i.e. it is not yet a collection). And related, weren't we trying to reword "null resources" as "unbound URIs" or something? Yes, I think that would be better, but then we would have to say that there are some operations that can be applied to unbound URI's (e.g. MKCOL) > Since any other WebDAV resource is > required to fail the MKCOL request, it seems rather bogus > to require them to "support" it. In particular, this > requirement damages any attempt by a client to populate its GUI with > whether or not a MKCOL operation is appropriate > for a given resource. Bottom line: I agree with the concept, but I am not sure if the new wording is quite right yet. How about from: > The MKCOL method is used to create a new collection. All DAV > compliant resources MUST support the MKCOL method. to The MKCOL method is used to create a new collection. If the URI is a DAV compliant lock-null resource, the resource MUST support the MKCOL method. All DAV compliant collection resources must also support MKCOL for creating new members for the collection. Probably not quite right, unless we are comfortable saying that MKCOL applies to the parent of the request-URL, instead of to the request-URL itself. Hmmm. Getting the wording right is hard isn't it? Yes, it always is! Cheers, Geoff
Received on Monday, 25 June 2001 23:30:19 UTC