WebDAV conference call
March 24, 2000: 11am
– 12:15 pm
Barry Lind – Xythos
Anne Hopkins, Randy Lehner, Sean Lyndersay – Microsoft
Jim Whitehead – UCIrvine
Greg Stein – Apache.org
Geoff Clemm – Rational Software
Eric Sedlar – Oracle (taking notes)
Bernard Chester – (Unknown affiliation)
These notes will be divided into three sections: “Resolved”, “Open Issues”, and “Discussion”. This way, if I don’t want to read the entire
meeting notes (for example if I attended the meeting), I can quickly see what was
supposedly agreed on, so I can raise a red flag about those points, before the
editors write it up in the spec.
for Specification: Fall 2000
spec must address:
of principals (group membership, etc.) is outside the spec
will use the term “group” rather than “compound principal”
ACL has a list of ACEs. Each
server has a maximum number of ACEs per ACL, which is implementation
dependent. The current proposal
is to require implementers to support at least 1 ACE granting permission
to a user, and 1 ACE granting permission to a group. Implementations are required to implement
a minimum of zero ACEs applying to a user or a group
and <write> must be supported
spec controls read access to the ACL via the read access to the other
properties. Only the owner can
update the ACLs. If the owner is
deleted, administrative action must be taken.
should be a property of the document, not the ACL
is a property of a resource, from a “model” point of view. How they are marshaled across the
wire (e.g. via PROPPATCH or ACL methods) should be left to discussion at
the end of the process.
- An “execute”
right is outside the scope of the spec for now, pending discussions on an “is_executable”
property on arbitrary WebDAV resources
do multiple ACEs interact?
Discuss on mailing list
Does the distinction between users and groups need to be
made in an ACE?
“checkPermissions” method: “do I have rights to do the following operation if I tried it”
Bernard or anyone else interested to come back with a
specific proposal. (This may be very
complex to implement—the entire method to be checked must be encapsulated in
Who are the document editors
Email Jim Whitehead if you are interested, and he will get
agreement from those parties to define a process.
Do we need an owner?
Can’t I just use a user principal?
discussion on the definition of CORE / not CORE features
discussions had agreement that we should work on a spec that doesn’t address
what is required for implementations, but merely what we could agree on quickly
Geoff felt that we need to address the CORE vs. advanced issues throughout
agreement to defer contentious issues to later in the process
goals required for the CORE spec
rights, principals, ACEs, etc.
spec is designed for maximum interoperability (areas where existing
repositories have widely differing approaches should be avoided)
scenarios must be included
system must be secure (e.g. security on security must be addressed)
discussion of read/write permission on ACLs themselves. General agreement to defer access
control on ACLs to “advanced”, with the owner-based model for CORE
of the need for a “checkPermission” method to non-destructively see if a
method could be executed.
on whether or not ACLs should be properties
on required core features
is a group? Do we need to allow
users to maintain it?
scenario: I store a document, and
want to allow my friends to read it.
How do I do this?
of maintaining a group via WebDAV
agreement that this should be done via multiple ACEs
of “execute” permission
on deadlines again
on document editing
Things that occurred to me while typing these notes:
need to discuss what ACL is used by default (if inheritance is outside of
the CORE spec).
need to enumerate error conditions (at least “Too many ACEs”)
- Do we
need a way to discover how many ACEs a server can support in an ACL?