Subject: [Ietf-calsify] Event classes

From: TimHare at comcast.net ([email-masked])
Date: Sun Sep 5 13:53:32 2004

In my opinion, there are two things to be done regarding CLASS:

         1. Define the meaning of the three values explicitly
         2. Let implementations handle the values

I'm not going to read the spec here, I'm going to reason from past 
experience (a mainframe calendaring product-that-was-not-PROFS) and say 
good definitions for the three values are:

         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

Use cases:
         1. PUBLIC - a meeting on my schedule
         2. PRIVATE- an appointment regarding contract negotiations on my 
schedule
         3. CONFIDENTIAL- an appointment for a medical screening

To me, the idea of CLASS is to indicate roughly how this item should be 
handled;  the implementation can use whatever mechanisms that they would 
like to provide this handling. There is no guarantee that a particular 
implementation will handle CONFIDENTIAL or PRIVATE correctly - but then, 
the market should take care of those cases, no? Or the legal system after 
Joe Users' CONFIDENTIAL appointment with his mistress is revealed to the 
PUBLIC (i.e.  Mrs. User!).

Tim Hare
Interested Bystander, Non-Inc.

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Sun Sep 5 16:20:06 2004

Hi Tim,

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

>          2. PRIVATE- only myself and people I delegate 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

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 6 11:30:27 2004

Great idea. New implementations will know what to do with them.
RFC 2445 defined the CLASS value to include 'iana-token'.

Existing implementations should default to PUBLIC as defined in 2445
for CLASS when they do not understand the value.

And we deprecate CONFIDENTIAL and PRIVATE.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040906/888cf7a8/smime-0001.bin

---

From: elias at cse.ucsc.edu (Elias Sinderson)
Date: Tue Sep 7 10:00:15 2004

Doug Royer wrote:

> Great idea. New implementations will know what to do with them. RFC 
> 2445 defined the CLASS value to include 'iana-token'.

+1 - given that there is no interoperability wit respect to CONFIDENTIAL 
and PRIVATE event classes among existing implementations, they should be 
deprecated. Also, it should be noted that introducing additional event 
classes does not further the interoperability goals of the iCal 
standardization effort.

Personally, I do not feel that it is appropriate to definine access 
control mechanisms within this specification at all. Servers should 
implement and utilize existing interoperable access control mechanisms 
for iCal access. Defining new access control mechanisms for iCal 
introduces unnecessary complexity, fractures the existing specification 
landscape and takes us farther away from the stated goal of 
interoperability and standardization.

Regards,
Elias

---

From: pregen at egenconsulting.com ([email-masked])
Date: Tue Sep 7 18:44:23 2004

I agree.

Elias wrote: 
<snip> 
>Defining new access control mechanisms for iCal 

Pregen

Elias Sinderson <[email-masked]> 
Sent by: [email-masked]
09/07/2004 13:00

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] Event classes

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