WebDAV conference call
March 24, 2000: 11am
– 12:15 pm
Attendees:
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)
Editor’s note:
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.
Resolved:
- Deadline
for Specification: Fall 2000
- CORE
spec must address:
- Principals
- Maintainance
of principals (group membership, etc.) is outside the spec
- We
will use the term “group” rather than “compound principal”
- ACEs
- An
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
- Rights
- <read>
and <write> must be supported
- CORE
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.
- Properties
- “owner”
should be a property of the document, not the ACL
- 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
Open Issues:
Description
|
Action
|
Specificity: how
do multiple ACEs interact?
|
Discuss on mailing list
|
Does the distinction between users and groups need to be
made in an ACE?
|
Unresolved
|
“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
the request)
|
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?
|
Unresolved
|
Discussion:
- Long
discussion on the definition of CORE / not CORE features
- Initial
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
- Later,
Geoff felt that we need to address the CORE vs. advanced issues throughout
the process
- General
agreement to defer contentious issues to later in the process
- General
goals required for the CORE spec
- Basic
rights, principals, ACEs, etc.
- CORE
spec is designed for maximum interoperability (areas where existing
repositories have widely differing approaches should be avoided)
- User
scenarios must be included
- The
system must be secure (e.g. security on security must be addressed)
- Some
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
- Discussion
of the need for a “checkPermission” method to non-destructively see if a
method could be executed.
- Discussion
on whether or not ACLs should be properties
- Discussion
on required core features
- Principals
- What
is a group? Do we need to allow
users to maintain it?
- Simple
scenario: I store a document, and
want to allow my friends to read it.
How do I do this?
- Discussion
of maintaining a group via WebDAV
- General
agreement that this should be done via multiple ACEs
- Discussion
of “execute” permission
- Discussion
on deadlines again
- Discussion
on document editing
Things that occurred to me while typing these notes:
- We
need to discuss what ACL is used by default (if inheritance is outside of
the CORE spec).
- We
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?