[Ietf-calsify] Event class
nsb at guppylake.com
Sat Aug 28 10:01:13 PDT 2004
On Aug 26, 2004, at 2:18 PM, Bernard Desruisseaux wrote:
> Here's an example for modify:
> - User B (my assistant) is allowed to modify my PUBLIC and CONFIDENTIAL
> calendar objects.
> - User B (my assistant) is not allowed to modify my PRIVATE calendar
This is a wonderfully clear example. Unfortunately, I can't find this
interpretation anywhere in RFC 2445. Have I missed it, or is it simply
one possible interpretation of the difference between PRIVATE and
CONFIDENTIAL? At the very least, this needs to be clarified, but I'm
not yet convinced it shouldn't simply be eliminated.
I think we are facing a classic tradeoff, insufficiently analyzed.
There is a very large general problem, which is access lists. There is
a very specific application, format and protocol, calendaring, which
has its own specific access control needs. The current values of CLASS
reflect an attempt to follow the 80/20 rule and cover most use cases
without overly generalized complexity. The question is, did it work?
If you can convince me that PUBLIC/PRIVATE/CONFIDENTIAL covers 80% or
more of the use cases, I will stop objecting to CLASS. However, I fear
that most users' environments are sufficiently complex that the
coverage is probably more like 20% than 80%, in which case CLASS
complicates the standard for (IMHO) inadequate value.
I don't suppose anyone has anything as useful as ethnographic data to
help us tell what percentage of the use cases we are actually covering?
PS -- As I've been suggesting for other topics... since the CLASS
property is both informational-only (as per RFC 2445) and arguably
representationally inadequate, it might be a better idea to remove it
from the base spec and then (if someone is sufficiently motivated)
write an additional spec on access control in iCal, which might even
define a somewhat richer approach that is backwards-compatible with RFC
2445's CLASS property. -- NB
More information about the Ietf-calsify