[Ietf-calsify] Event class

[Nathaniel Borenstein]

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
>   objects.

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? 
  -- Nathaniel

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