Re: New draft: draft-daboo-webdav-mkcol-00.txt

Looking at RFC 4918, I found this:

 > A MKCOL request message may contain a message body. The precise
 > behaviour of a MKCOL request when the body is present is undefined,
 > but limited to creating collections, members of a collection, bodies
 > of members, and properties on the collections or members.

So there is no need for an "extension". All we need is a substantiation
of what is undefined and also one correction of what is wrong in RFC 4918.

Here is a proposal:
===================

1. MKCOL request with a propertyupdate XML body
-----------------------------------------------

When the body of a MKCOL request contains an propertyupdate XML
element, the server must process it according to RFC 4918, 9.2
PROPPATCH Method. If this fails, the requests fails and the collection
MUST NOT be created.

The propertyupdate XML element may contain a set XML element for
the resourcetype property. This MUST be the first set XML element.
The resourcetype requested is a specialised type of a collection.
The server MUST recognize this special type of collection and MUST be
able to handle it; otherwise the request MUST fail.

2. Response to MKCOL with a propertyupdate XML body
---------------------------------------------------

Different form PROPPATCH a response body is not required; but a body
MAY be submitted if it is necessary or useful.
On a successful request the body may be a response XML element, to
inform the client about property values that are automatically created
by the server on creation of the collection.
When the request fails because the server can not set the properties as
requested or the server does not recognize the requested resourcetype, a
multistatus response body SHOULD specify the exact reason of the
failure, as in RFC 4918, 9.2.1 Status Codes for Use in 'propstat'
Element.

For response status codes RFC 4918, 9.3.1 MKCOL Status Codes, applies
with the addition of 207 Multistatus to report errors processing the
propertyupdate body. Within a multistatus response body '501 Not
Implemented' indicates, that the server does not recognize the
requested resourcetype.

3. Clarification of RFC 4918, 15.9 resourcetype Property
--------------------------------------------------------

While for DAV:collection it seems obvious, that resourcetype is a live
property, this might not be the case for custom resourcetypes.
To avoid confusion:
resourcetype always is a live property. Contrary to RFC 4918, a server
SHOULD not accept unknown child elements in resourcetype.

End of proposal.

There is no need for a new DAV header value, as this is not an 
extension. If a server can not handle a request body with MKCOL, the 
request MUST fail anyway and the client will know about this.

There are some concerns about using propertyupdate:

- consistency with all the later WebDAV specs
   We can be consistent with RFC 4918 or with later WebDAV specs,
   but not both. This is about RFC 4918.

Remark: For me it is important, to treat this as a substantiation of
what is underspecified in RFC 4918, and not as an extension. As 
developer of a WebDAV client, I feel quite uneasy with the discussion 
about RFC 4918, as well as with all this extension. It looks like the 
preferred way to handle shortcomings in RFC 4918 is to invent new 
Extensions (preferably focused on just one use case with no thought 
about consistency). But we either fix the basics or we end up in a 
complete mess. (Note: the major HTTP servers still have serious faults 
in their implementation of the basic protocol.)

Another remark: I did not follow the process of creating Versioning 
Extensions to WebDAV, so maybe I am missing an important argument. But I 
can not see the use of about 10 pairs of XML elements, all defined as
<?ELEMENT method-name ANY> and <?ELEMENT method-name-response ANY>. This 
looks like one generic response-request container element in different 
disguises.

- compatibility with existing MKxxx methods
   To be compatible with these, the MKCOL body must be able to transport
   all the information they need. If an application that uses one of
   this MKxx methods wants to use MKCOL, it has to redesign the MKCOL
   method anyway. It is not of much help for compatibility to include
   the top level element of the MKxxx method as child of a new top level
   element of the MKCOL method.

The resource type must always be defined with DAV:resourcetype. Allowing 
different methods for this, like mkxxx-body XML elements with enclosed 
properties, will make the MKCOL request body inconsistent from the very 
beginning.

- is resourctype a live property
   I think RFC 4918 is wrong. Allowing a server to accept unknown
   resourcetypes is incompatible with a live property. RFC 4918
   suggests to mix up resourcetype and contenttype.

Werner

Received on Saturday, 1 December 2007 22:32:36 UTC