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

RE: [ACL] principal-collection-set

From: Peter Raymond <Peter.Raymond@merant.com>
Date: Thu, 11 Oct 2001 10:11:07 +0100
Message-ID: <20CF1CE11441D411919C0008C7C5A13B02AD3B61@stalmail.eu.merant.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>, "Clemm, Geoff" <gclemm@rational.com>, "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>, ACL@webdav.org

Let me make sure I understand your "multiple server" scenario correctly:

Imagine some parts of the namespace are being maintained by different
the namespaces used to store version-histories, baselines, workspaces,
principals etc may differ.

Consider the situation where I have a workspace hosted at:


and in that workspace we have a collection which has a binding to a resource
on some 
other server), eg:

http://www.server1.merant.com/dav/project1/src has a member which is a
binding to

If my client connects to server1 and does a OPTIONS on /dav and gets back
DAV:version-history-set they might get:


If the client did a PROPFIND on
for it's DAV:version-history property it might return:


It seems to make sense that the version histories for resources live on the
server as those resources.  Which implies that if you have "cross-server"
then different collection sets apply to different parts of the namespace.

So I guess I support option number 2.

I also like the idea of all the specifications being consistent.

Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
WWW: http://www.merant.com

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: 11 October 2001 09:38
To: Clemm, Geoff; 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
> Clemm, Geoff
> 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.

Yes, that's what I'm concerned about. Without going too much into
detail, I have a server with an internal plugin-structure and all
"server" protocol values (xxx-set, DAV header, methods) can and will
vary. For now, they can vary with each collection. If we have BINDINGs
in the future, it may vary with each resource.

So, getting those values "once for the session" is wrong and clients
following that advice are broken.


> 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 Thursday, 11 October 2001 05:13:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC