RE: [ACL] principal-collection-set

"Once per session" was probably not the best analogy here.
I should have said: "A client issues an OPTIONS call once
for each server with which it interacts, and a PROPFIND call
once for each resource with which it interacts".  If the client
has no idea where the server boundaries are, then yes, it might
have to issue an OPTIONS call for every resource, but the
DAV protocol requires it to do this anyway, since that's the
only way to discover the DAV feature level (via the DAV header).

The key point for me here is that DAV has already made
the decision to make the feature set supported by a server
available through an OPTIONS call (via the DAV header), and
not through live properties.  To be consistent with this
choice, other server level options (such as xxx-collection-set)
should be marshalled this way as well.

But as I indicated earlier, I personally don't think it matters
much which way we go here, but the process for editorial updates
to the DeltaV protocol is that only unanimous (minor) changes
get made.  This is a minor change, but it is not unanimous (i.e.
Greg is strongly against it, and Eric prefers to keep it the way
it is), so that means that DeltaV stays as it is (the last call
period is over).  Which then means I am strongly in favor of
marshalling xxx-collection-set in ACL in OPTIONS, to keep it 
consistent with DeltaV (and DAV).

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Thursday, October 11, 2001 4:38 AM
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.

Received on Thursday, 11 October 2001 08:43:18 UTC