Subject: [Ietf-calsify] Event class

From: PStephenson at gw.novell.com (Preston Stephenson)
Date: Fri Aug 27 07:15:13 2004

We map the PRIVATE to an internal status and control the access to the
item.
Do we need to come up with the concept of certain properties being
reserved words?
New implementations would not need to support them, but must pass them
on if they receive an iCal object with the property.
I don't think we want to mark them as deprecated, though.
Preston

>>> "Cameron Stillion" <[email-masked]> 08/26/04 4:00
PM >>>

The answer is yes, our implementation of Private actually limits
access
to users with ACLs to the item.  The private bit is used to filter in
views, printing, free/busy extraction and rendering, etc.  All of
these
are really just Application Rendering functionality, I suppose, but it
implies functionality as well.  If I can't see your private items, I
also can't move them, even if I have read/write access to your
calendar.

Of course, exporting this information (into an iCal format)
potentially
exposes private items in a way that is unenforcable outside the
client.
This is a matter of giving the user prominent notice and allowing them
to decide what they really want.  Currently, when the data leaves the
client, all bets are off, and the privacy is unenforceable.  But that
only happens when the user asks for it.

We have, in other contexts, asserted that iCal is a native storage
format as well as a transport schema.  In the guise of a native
storage
format, we should absolutely support the notion of CLASS so that
clients
(especially current implementations) can apply the notions they have,
and continue to support the features they perform.  In the guise of a
transport format, CLASS is somewhat interesting to clients with
similar
notions, but the user should understand that fidelity and
functionality
tend to wane in translation.

There is perhaps room for more clarification surrounding what we
propose
good clients ought to do with the critical values of PRIVATE and
PUBLIC,
but I'd avoid requiring anything special, especially of thin clients.
Supporting other values seems very reasonable, considering the
client-specific behavior we presume in the first place.

Cameron

-----Original Message-----
From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Cyrus
Daboo
Sent: Thursday, August 26, 2004 1:23 PM
To: [email-masked]; [email-masked] 
Subject: RE: [Ietf-calsify] Event class

Hi [email-masked],

--On Thursday, August 26, 2004 3:28 PM -0400
[email-masked] wrote:

> The property is currently being used by several iCalendar
implementations.

Do any of those implementations actually do anything with that
property
other than display it to the user? e.g. do they prevent users from
storing the event in a public calendar if its marked as PRIVATE? If
they
do not do that then I think all we need to do is clarify the current
text for the property to explicitly state it is only for informational
purposes and CUAs should not attempt to process the value themselves
beyond alerting the user.

The alternative is to specify exactly what is expected to happen when
a
CUA receives a component with a class property. e.g. if its set to
PRIVATE then the CUA MUST ensure that only the recipient can access
the
event when it is saved to the local/remote calendar store. That means
clearly specifying the meaning of PUBLIC/PRIVATE/CONFIDENTIAL etc.

Perhaps people can explain exactly what there implementations
currently
do with CLASS. Maybe its come up in interops?

--
Cyrus Daboo
_______________________________________________
Ietf-calsify mailing list
[email-masked] 
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify 

_______________________________________________
Ietf-calsify mailing list
[email-masked] 
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify