Re: webdav-collection-protocol-00: can we dispense with Mandatory?

My opinion is that either

   1) adding a referential member is exactly equivalent to creating
      a resource with no content, in which case you don't need M-PUT
      (just use PUT); or

   2) adding a referential member is not creating a resource with no
      content; it is instead creating a resource that exists as a
      namespace indirection for some other resource, in which case
      using PUT would not be appropriate at all.

It seems to me that the latter is what you intend, so defining ADDREF
is the appropriate action.

Neither case requires the use of the Mandatory draft's extension mechanism.

>So what about the Position header?  We could just get rid of it, and make
>clients do a separate PROPPATCH operation to place a new collection member
>where they want it in an ordering.
>
>If we keep the Position header, we need something like Mandatory to insure
>that the request will fail if the header is not recognized.

Not necessary for ADDREF.  If the header is not recognized, then ADDREF
will not be allowed either.  Besides, the chances that an application would
want the server to reject the request in this case are nonexistant --
ordering is always at the discretion of the server and there is no
alternative if the server doesn't even understand the Position header.

>There is one other case, not currently in the collections spec, that might
>need Mandatory.  We may decide that we need a way to specify, at the time a
>collection is created, that it be an ordered collection.  If we introduce a
>new Ordered header for use with MKCOL to accomplish this, we need a way to
>make the request fail if the server doesn't comply with the ordered
>collections part of WebDAV.

Again, such usage is only necessary if the client actually wants the
server to fail the request.  That is rarely the case for namespace
operations (so rare, in fact, that I know of no application area that
would ever want such functionality).

In any case, the Mandatory syntax allows such a requirement to be
defined independently of your own extensions, so define the protocol as
if you know the server will support the extension (which will be true
for all but the very first interaction with that server) and then just
remind the reader that they can use the Mandatory prefix if desired.
The only thing you need to define is the URI for the semantics, which
in this case would be the RFC of your eventual standard (or any
<DAV:thingy> you might prefer).

....Roy

Received on Wednesday, 10 June 1998 22:17:34 UTC