- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 10 Oct 2001 19:24:47 +0200
- To: "Greg Stein" <gstein@lyra.org>, "DeltaV \(E-mail\)" <ietf-dav-versioning@w3.org>, <ACL@webdav.org>
> 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. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl >
Received on Wednesday, 10 October 2001 13:24:09 UTC