RE: [ACL] principal-collection-set

The argument that "if it can vary on a host, then it should be
marshalled as a property, not as OPTIONS" could equally well be
applied to the DAV header.  After all, often only part of the
URL space on a host supports a given level of WebDAV, as reflected
in the DAV header.  So are you arguing that the next draft of 2518
should convert the DAV header to a DAV:dav property on every resource?  

Note that the "*" argument to OPTIONS is just bogus.  It lets
you ask for information about one of the servers on
a host (probably the server that implements "/") but not for any of
the other servers on that host.

So I see currently two supporters of (2) and one supporter of (1)
(with Jim an apparent additional supporter of (2)).  Anyone else
care?  Anyone want to change their mind?

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Wednesday, October 10, 2001 1:25 PM
To: Greg Stein; DeltaV (E-mail); ACL@webdav.org
Subject: RE: [ACL] principal-collection-set


> From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of
> Greg Stein
> Sent: Wednesday, October 10, 2001 7:22 PM
> To: DeltaV (E-mail); ACL@webdav.org
> Subject: Re: [ACL] principal-collection-set
>
>
> On Wed, Oct 10, 2001 at 12:54:05PM -0400, Clemm, Geoff wrote:
> >...
> > 1) Keep DeltaV with OPTIONS, and make ACL use OPTIONS for consistency
> > 2) Change DeltaV to use properties, and have ACL use properties
> > 3) Have DeltaV and ACL use different ways to obtain xxx-collection-set
> >
> > The main situation I *really* want to avoid is:
> > 4) Change DeltaV to use properties, and have ACL end up using OPTIONS
> >    or some other non-property mechanism inconsistent with DeltaV.
> >
> > So for those folks that care about this (probably not many :-),
> > which choice do you prefer?
>
>
> #1 big time. This high level information belongs in OPTIONS, queried once
> when you first contact the server, to determine what it can support. This
> happens before you know that a PROPFIND can be issued.

I think I might agree if the things we're talking abut *really* could be
queried once.

As I said, OPTIONS is for marshalling "communication options". Those options
apply to either "*" (general options) or to a specific resource. In general,
you can't assume that what's true for resource "x" is also the case for
resouce "y".

> IMO, it's always been bogus to have protocol/implementation info as a
> property. The DAV:lockdiscovery has always given me a twitch.
>

Received on Wednesday, 10 October 2001 14:33:39 UTC