Subject: [Ietf-calsify] Event classes

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Sun Sep 5 20:35:54 2004

This is similar to the TRANSP problem - we have existing values that
don't quite match implementations and that are quite difficult to grasp.
We need better values to clarify, but we also want existing software to
not have to be rewritten.

PUBLIC is clearly understood and wants no clarification.  PRIVATE and
CONFIDENTIAL mean different things to different implementations - but
this is the whole reason why iCal is not yet a standard.  This is
EXACTLY why calsify exists!  Let us bring to bear the collective brains
of this forum to define these in a way that CAN make sense and that we
can call STANDARD.  All previous implementations will be struggling
anyway to interop, and it is very clear why.

Personally, I tend toward the three visibility labels also in use in
modern computer programming languages: 
	PUBLIC - visible to all
	PROTECTED - visible to me and a few other special entities
	PRIVATE - visible only to me

Various flavors of protected could be concocted, leading to the FRIEND
list and other client-specific notions, but the tag would suffice.  In
all honesty, I don't care if protected is named "CONFIDENTIAL", but I
find it clearer as it is stated above.  Maybe it's because I'm a
programmer, but isn't that really our audience here?

I think we can come to a fairly quick resolution on the names of these
values - but I think there is a more important question afoot.  When do
we transport these properties?  This comes back to the various reasons
we use iCal...

As usual, all these properties make sense to store and transport when
iCal is used by an individual to access their own store.  When I publish
a calendar to a "public" recipient, the answer is moot.  

But What about a private (or other *protected* flavor)? Do the events
reflect their initial visibility? Can the recipient tell if they can see
an appointment because they are special?  Even more interesting is the
meeting request/response case - perhaps an event is private to me
because of the nature of the meeting (e.g. legal consultation) so I mark
it as such.  Obviously the recipient of the request would also see the
event, but may or may not consider it the same level of visibility.  

I would suggest that shared data is always public as far as the
recipient is concerned, especially since the nature of this property is
explicitly NOT to enforce access or visibility but merely to suggest
ways the CUA / CS can avoid doing the wrong thing.  Also, because of
this nature, once data leaves the comfort of its home and goes across
the wire to another client, all bets are off.  Only crypto will solve
that problem, and that is beyond the scope of this property and this
standard.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Sunday, September 05, 2004 4:20 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ietf-calsify] Event classes

Hi Tim,

--On Sunday, September 5, 2004 4:45 PM -0400 [email-masked] wrote:

>          1. PUBLIC - anyone can read this item and see the details
>          2. PRIVATE- only myself and people I delegate can see the 
> details, others can see that time is blocked
>          3. CONFIDENTIAL- only I can see the details, others can see 
> that time is blocked

Your interpretation of PRIVATE & CONFIDENTIAL is not what others have. 
Personally I thought of those in the same way you do, however I found
out that some implementations treat them the other way around (i.e.
PRIVATE is owner only, CONFIDENTIAL is owner + delegates). So it may
well be that the current PRIVATE and CONFIDENTIAL values cannot be
explicitly defined in an interoperable way, and we may need new values,
e.g.:

OWNERONLY - as per your definition (2)
DELEGATES - as per your definition (3)

I don't think there is an issue with PUBLIC.

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