Subject: All the ways we use iCal (was: [Ietf-calsify] Event class)

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Wed Sep 1 12:19:05 2004

That is a great clarification of the EVENT CLASS problem.

To answer the question - I am not building a CS, I'm building a CUA that
talks to other CUAs, and I am in complete control of my Private and/or
Confidential access lists.  But I see your point.

And now that you mention it, I see that there are really three purposes
that we are trying to use iCal for:

1) Native file format for storage of calendars
     [ I suppose this could be client or server. ]
2) Transport format for exchanging calendars between users or CUAs
	[ rich client model where server-involvement 
	  is not required or even necessarily desired.
 	  Business Logic is implemented on the client. ]
3) Transport format for sending calendar data either:
	from CS to CS, or from CS to CUA
	[ thin client model where server-involvement
	  is required, and business logic is implemented there. ]

Looking at it this way, it seems that these three purposes are likely to
have slightly different needs, and it does seem that many of our
discussions get hung up on these differing purposes.

Is it possible to remove any of these purposes from our intention of
what iCal *should* be? Doug and Nathaniel have each mentioned at one
time or another that we should focus on the transport perspective, and
not the storage format. I also wonder if perspective #2 and #3 should be
considered separately - or one as a subset of the other...

Would it make sense to focus on these one at a time, or to differentiate
the support for specific properties based on these three dimensions?  I
realize I'm asking a broader question about the way we approach
resolving our differences surrounding the collective iCal standards -
but maybe we can move forward more easily with this kind of approach.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, August 31, 2004 10:07 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

>...
>In fact, I would expect that when a calendar is published or sent via 
>e-mail, my client had better exclude the events marked as PRIVATE or 
>CONFIDENTIAL (modulo some sort of override...)  It would be 
>unacceptable to include them and simply mark them as such.  Perhaps 
>this is another case of a property that should almost never be sent, 
>but that may be stored.
>
>  
>

I agree with both points. And the fact that  it is undefined and the
implementation specifics are disputed is the point. Patrice's
explanation is not consistent with yours. So would his CUA accessing
your CS give away your CONFIDENTIAL data?  It looks like yes as long as
who he wanted to iMIP it to, was in his trusted list.

Is the idea of CLASS useful - yes.
Is their consistent and interoperable usage of the CLASS property - no.

CLASS needs to be re-done in a way that new CUA's and CS's know exactly
what is expected, which (CUA or CS) is to enforce the access control.
And when to set it, forward it, or deny access to it.

-- 

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

---

From: Doug at Royer.com (Doug Royer)
Date: Wed Sep 1 16:15:21 2004

>Confidential access lists.  But I see your point.
'CS' is defined in iTIP to mean the other end of the connection when a CUA
is getting data from a CUA (such as iMIP) . CAP had not yet been invented.

The 'S' stands for SERVICE not server in iTIP.

The issue is can one vendor talk with another vendors data
in a way that everyone knows what to do with the data. It seems
to me the answer is "no" with respect to the CLASS property.

So again I think that the idea may be good if defined in an unambiguous
way. However there is no way to use the same name (CLASS) and
tell which (old or new) usage of the CLASS property is intended. I think
we need to deprecate CLASS and define CLASS2 . Then clearly
define CLASS2.

>     [ I suppose this could be client or server. ]
agree.

> 	  Business Logic is implemented on the client. ]
At  this level it looks to me as if not all vendors use the same meaning
of the CLASS value. Plus some transport the CLASS property, others do not.
This means that it is not an interoperable property - correct?

>	  is required, and business logic is implemented there. ]
The transfer of data between a CUA and CAP-CS is an extension of 
transport (iTIP)
Not a replacement. So the same problem exists as in (2) above.

There is no CS to CS protocol defined yet.

And the business logic can be in the CS and CUA. It depends on the usage
of the calendar information and application.  Access control is in a 
CAP-CS - yes.

-- 

-------------- 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/20040901/aaf99de4/smime.bin