[Ietf-calsify] Event class

Bernard Desruisseaux bernard.desruisseaux at oracle.com
Sun Aug 29 19:33:14 PDT 2004


Nathaniel,

Here's a use case:

- I create a confidential meeting on my SyncML device.

- I synchronize my device with Oracle Calendar Server.

- Thanks to the CLASS property, Oracle Calendar Server
   will enforce the access control that applies to my
   confidential meetings when people will try to access
   this new meeting on the server.

Was the CLASS property used for access control?  No.

Was the CLASS property useful? Yes, it allowed me to
set the access classification of a new meeting from my
SyncML device.

Who cares what Bernard's access classification "confidential"
means?  Only Bernard and his calendar store.


Now you are going to ask me: « What about iTIP? » (Right? :-))

Answer #1: iCalendar is not only meant for iTIP.

Answer #2: Let me try this analogy:

You receive a document from an IBM colleague stamped with
the words "TOP SECRET" on the first page. As an IBM employee
you know what "TOP SECRET" means per IBM's policies.

If I send you an Oracle document stamped with the word
"CONFIDENTIAL" on the first page you won't exactly know
what "CONFIDENTIAL" means because you are not an Oracle
employee.

Same with iTIP. In some cases the originator and recipients
of iTIP messages will share the semantic of the CLASS
property and in other cases they won't.

Cheers,
Bernard

Nathaniel Borenstein wrote:

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



More information about the Ietf-calsify mailing list