Proposed editorial change for deltav spec (WAS: [ACL] principal-c ollection-set)

This was posted on the ACL mailing list.  It proposes marshalling
the xxx-collection-set as properties, rather than as OPTIONS.
See the ACL mailing list for additional messages in this thread.

Cheers,
Geoff

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@Rational.Com]
Sent: Wednesday, October 10, 2001 11:25 AM
To: 'Jim Whitehead'; ACL@webdav.org
Subject: RE: [ACL] principal-collection-set


Well, all I can say is "arghhh".  I really don't care whether
the xxx-collection-set is marshalled via properties or OPTIONS
(or by REPORT, for that matter).  I've probably changed it 3
or 4 times in the DeltaV spec as the consensus shifted back and
forth.  The last shift (a few months ago) settled on using OPTIONS,
so that's what is in the DeltaV draft.  So although I don't
care which way we marshall it, I *do* care that we try to be
consistent from one WebDAV application to another.  Having the
ACL spec do it one way and the DeltaV spec do it another way
would be very unfortunate.

So if folks *REALLY* care that it be marshalled as properties
rather than as OPTIONS, and will vigorously support that
position going forward, I would consider trying to surgically
alter the DeltaV spec in the final editing pass to reflect this
consensus.

On the other hands, if folks don't really care that much about
it (and I don't really see how one could care that much about it),
I'd prefer to leave the DeltaV spec alone, and adopt the convention
that xxx-collection-set information is marshalled via an OPTIONS
call, and reflect this convention in the ACL spec by having the
DAV:principal-collection-set marshalled via an OPTIONS call.

Cheers,
Geoff


-----Original Message-----
From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Thursday, October 04, 2001 4:49 PM
To: ACL@webdav.org
Subject: RE: [ACL] principal-collection-set


Keith Wannamaker writes:
> It was noted on the call a few weeks ago, I think by Geoff,
> that principal-collection-set should not be a live property.
> Instead, it should be an element in an OPTIONS body, using
> the <D:options> / <D:options-response> construct presented
> in the DeltaV draft.
>
> Is this a consensus?  Should the draft be updated?

After the development of the WebDAV protocol, it was noted that some of the
properties defined in RFC2518 were really "protocol metadata" and not
resource metadata. DAV:supportedlock is one example.

Since that time, I haven't heard a compelling argument for why you would
prefer to use OPTIONS over PROPFIND for retrieving protocol metadata.
Arguably, you can make an argument in the reverse direction: existing HTTP
client libraries do not expect OPTIONS to have a body, and many WebDAV
libraries build upon existing HTTP libraries.

I suppose one argument is that since client wanting to set ACLs will do an
OPTIONS on a resource to retrieve the searchable properties list, it might
as well also get the list of principal collections at the same time.  Of
course, the same argument works in reverse: if the searchable properties
list is placed in a property, then both the searchable properties and the
principal collections could be retrieved with a single PROPFIND.

Since we already have an existing mechanism for retrieving protocol metadata
(PROPFIND), I'm inclined to *not* use OPTIONS, and make an additional
property for the searchable properties list.

Received on Wednesday, 10 October 2001 12:12:28 UTC