[Ietf-calsify] Event class
satyanarayana.vempati at Sun.COM
Thu Aug 26 11:26:45 PDT 2004
If we cannot clearly define the semantics of CLASS, or deem it to be merely informative, it may be best to remove it from the spec.
From: ietf-calsify-bounces at osafoundation.org [mailto:ietf-calsify-bounces at osafoundation.org] On Behalf Of Bernard Desruisseaux
Sent: Thursday, August 26, 2004 8:24 AM
To: ietf-calsify at osafoundation.org
Subject: Re: [Ietf-calsify] Event class
Satya Vempati wrote:
> Another area in need of simplification/better explanation is the event
> class: PUBLIC/PRIVATE/CONFIDENTIAL.
> The spec does not clearly define what each value means.
I don't think iCalendar needs to define the semantic of the different _access classifications_.
Remember that iCalendar doesn't define an _access control_ model.
iCalendar allow users to specify the access classification of their calendar objects. The semantic of the different access classifications could either be defined system wide on a calendar store, or on a per user basis (better).
For instance, a calendar store could allow me, through its access control model, to specify which users are allowed to view/modify which properties of calendar objects based on their classification.
- User A is allowed to view all the properties of my PUBLIC
- User A is allowed to view the DTSTART and DTEND of my
CONFIDENTIAL calendar objects.
- User A is not allowed to view my PRIVATE calendar objects.
I do understand that if you receive an iTIP message with the CLASS property set you can't do much about it. But then, is that an issue? It's questionable whether the originator should set this property. At best, the recipient should view the CLASS property as informative.
So far, no interoperability issue have been raised with the CLASS property. How could it be? There is no semantic defined! :-)
Ietf-calsify mailing list
Ietf-calsify at osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
More information about the Ietf-calsify