RE: [ACL] principal-collection-set

I vote for #1, for consistency with the use of OPTIONS and the DAV header
in RFC2518, which we don't have the ability to change at this point.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Wednesday, October 10, 2001 11:33 AM
> To: Greg Stein; DeltaV (E-mail)
> Subject: 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:57:38 UTC