W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: New (minor) issue for RFC-2518: revising wording in section 8 .3

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 25 Jun 2001 23:36:42 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103625AD5@SUS-MA1IT01>
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

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


   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.


	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!

Received on Monday, 25 June 2001 23:30:19 UTC

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