W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

RE: [ACL] principal-collection-set

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 10 Oct 2001 19:20:04 +0200
To: "Clemm, Geoff" <gclemm@rational.com>, "DeltaV \(E-mail\)" <ietf-dav-versioning@w3.org>, <ACL@webdav.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKEJCDDAA.julian.reschke@gmx.de>
> From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of
> Clemm, Geoff
> Sent: Wednesday, October 10, 2001 7:07 PM
> To: DeltaV (E-mail); ACL@webdav.org
> Subject: RE: [ACL] principal-collection-set
>
>
> Just to make sure we're on the same page, the interaction between
> the client and a server will not be to ask each resource "where is
> your xxx-collection-set", but rather to ask the first encountered
> resource in a session "where are the xxx-collection-set values on
> your server", and then use those values for the rest of the session.

Maybe I oversee something, but where's the guarantee that in ACL those sets
will be identical for all resources?

I agree with you that some of the arguments are a bit fuzzy (and that I'm
late in this discussion)... HTTP (RFC2616) says about OPTIONS:

"The OPTIONS method represents a request for information about the
communication options available on the
request/response chain identified by the Request-URI. This method allows the
client to determine the options
and/or requirements associated with a resource, or the capabilities of a
server, without implying a resource action or
initiating a resource retrieval."

So are we talking about "communication options" in this case?

> This means that you would not be combining requests for xxx-collection-set
> information with the other property information, but rather will be
> asking for xxx-collection-set information around the same time you
> are asking for OPTIONS information (i.e. what options are supported
> by your server), which is why the xxx-collection-set information is
> currently marshalled via OPTIONS, since *that* allows you to get all
> this "configuration" information in one request.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > 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?
>
> Obviously, it MUST be consistent across deltaV, ACL and future WebDAV
> versions.
>
> I honestly think that 2) is the best solution. For instance, it allows a
> client to collect all it needs to know about a resource with one request.
> _______________________________________________
> acl mailing list
> acl@webdav.org
> http://mailman.webdav.org/mailman/listinfo/acl
>
Received on Wednesday, 10 October 2001 13:19:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT