RE: [ACL] principal-collection-set

DAV:supported-method-set was added because different
resources on the same server will have different DAV:supported-method-set,
therefore when you are populating a GUI, you need this information
for each resource separately (to help determine what icon to display
for the resource), and this can be retrieved in one roundtrip with
a Depth PROPFIND.

This is in contrast to DAV:xxx-collection-set, which usually is consistent
across the resources in a given GUI tree display, and therefore would be
wasteful/redundant to request separately for each resource in that display.

Cheers,
Geoff

-----Original Message-----
From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Wednesday, October 10, 2001 3:01 PM
To: Eric Sedlar; DeltaV (E-mail); Acl@Webdav.Org
Subject: RE: [ACL] principal-collection-set


Please remind me why then supported-method-set was added to deltaV...

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Eric Sedlar
> Sent: Wednesday, October 10, 2001 9:01 PM
> To: DeltaV (E-mail); Acl@Webdav.Org
> Subject: 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 18:06:18 UTC