Subject: [Ietf-calsify] Event class

From: satyanarayana.vempati at Sun.COM (Satya Vempati)
Date: Tue Aug 17 14:13:46 2004

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.

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Sat Aug 21 16:10:52 2004

> The spec does not clearly define what each value means.

Yes, I'm puzzled on two levels.  First, what on Earth might have been 
intended by the difference between PRIVATE and CONFIDENTIAL -- I 
honestly don't even have a guess from reading the spec.  Second, what 
are we really asserting when we mark something PRIVATE and then send it 
around in an unencrypted email message?  The spec is actually 
explicitly ambiguous:  "Hence, the semantics of the individual access 
classifications cannot be completely defined by this memo alone."  What 
the heck *can* define them?

This isn't just a pedantic question, because presumably any 
implementation that differentiates between PUBLIC and PRIVATE is giving 
the user some kind of indication/choice about the nature of the 
message, and I rather doubt that the user expectations that might come 
from choosing "PRIVATE" are satisfied by the typical implementation, 
let alone by the results of interoperating between multiple systems.

In short, I question whether this distinction has any value at all, and 
would be interested in knowing what it really means in implementations 
that use it.  -- Nathaniel

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Mon Aug 23 08:03:40 2004

I believe the original intent was that a private meeting can only be seen 
by the owner of the mail store.  Not by an assistant who has access to 
your mail store.

Nathaniel Borenstein <[email-masked]> 
Sent by: [email-masked]
08/21/2004 07:10 PM

To
Satya Vempati <[email-masked]>
cc
[email-masked]
Subject
Re: [Ietf-calsify] Event class

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

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Aug 23 09:55:58 2004

>by the owner of the mail store.  Not by an assistant who has access to 
Yes, I remember discussions where PRIVATE  were not  to be handed out to
non-owners.

The current webDav calendars have almost no access control at all. You
can in many cases do an HTTP get and get the entire calendar. In that
model CLASS has almost no meaning and less privacy.

However in CAP (and CalDav I hope) there is more security and
the ability to enforce the better defined values.

-- 

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/20040823/6486ca1e/smime.bin

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Wed Aug 25 15:22:05 2004

Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide 
made me wonder if we aren't trying to standardize the snowflake.  The 
definitions of such categories (and the number of categories needed) 
could be as unique as our users.

Or to put it another way, defining a tripartite value of 
PRIVATE/CONFIDENTIAL/PUBLIC is ultimately just a [lame] attempt to 
provide access control.  A pointer towards an access list (and a 
default/fallback semantics of PUBLIC) might be both simpler and more 
useful.  -- Nathaniel

On Aug 23, 2004, at 12:55 PM, Doug Royer wrote:

>> I believe the original intent was that a private meeting can only be 
>> seen by the owner of the mail store.  Not by an assistant who has 
>> access to your mail store.
>>

---

From: Chris_Stoner at notesdev.ibm.com ([email-masked])
Date: Wed Aug 25 15:25:51 2004

Or maybe only define PRIVATE/PUBLIC and allow extensions to this using
X-PROPS?  This way we cover the baseline that we think everyone is likely
to want to try to use (and send) but there's still the possibility of going
beyond that...
-CS

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Wed Aug 25 15:39:58 2004

I disagree.  When this appointment is private between sender and invitee 
we need to create to calendar store object to reflect this.  The assistant 
should not be able to see just those items created in this fashion.  The 
access of assistant to calendar in general is a diffent issue.

08/25/2004 06:21 PM

To

Subject

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Wed Aug 25 16:06:46 2004

If the use case involves the calendar store, then the discussion may be 
more relevant on the CalDAV or CAP discussion lists, than on iCalendar.

lisa

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Wed Aug 25 16:09:14 2004

So if I understand correctly you are arguing for the importance of a 
particular special case, in which the roles you envision are a single 
actor and his assistant.  I have no doubt that this is a very common 
use case, but is it so overwhelmingly predominant that it is the only 
use case that is relevant for describing access control, and thus 
deserving of "special treatment" in the standard?

For my part, if I have an assistant with access to my calendar, I doubt 
that I'm *ever* going to put anything into that calendar that I don't 
want my assistant to see, no matter how it gets labeled.  Without real 
access control, paranoia is only prudent.   :-)  -- Nathaniel

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Wed Aug 25 16:17:07 2004

Hi Nathaniel,

--On Wednesday, August 25, 2004 6:21 PM -0400 Nathaniel Borenstein 
<[email-masked]> wrote:

> Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide made
> me wonder if we aren't trying to standardize the snowflake.  The

One choice here might be to remove all concept of access control from the 
data model (iCal) and instead only have that in the access protocol. That 
avoids the need to invent properties to express arbitrary access control 
and trust relationships which cannot be rigorously enforced.

-- 
Cyrus Daboo

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Wed Aug 25 16:23:27 2004

On Aug 26, 2004, at 1:16, Cyrus Daboo wrote:
> One choice here might be to remove all concept of access control from 
> the data model (iCal) and instead only have that in the access 
> protocol. That avoids the need to invent properties to express 
> arbitrary access control and trust relationships which cannot be 
> rigorously enforced.

I've always thought that this property is intended as an informational 
marker, not as a strict access control setting. Like a paper which has 
CONFIDENTIAL in large red letters on the background (you can still read 
it if you got it, but you know that you are not supposed to pass it to 
the competitors sales guy ...).
Personally I find it pretty useful to let the consumer know how he is 
supposed to deal with the information item he received.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: Doug at Royer.com (Doug Royer)
Date: Wed Aug 25 16:26:51 2004

Lets add:

    7) Access control.

Nathaniel Borenstein wrote:

>
> For my part, if I have an assistant with access to my calendar, I 
> doubt that I'm *ever* going to put anything into that calendar that I 
> don't want my assistant to see, no matter how it gets labeled.  
> Without real access control, paranoia is only prudent.   :-)  -- 
> Nathaniel
>  

-- 

-------------- 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/20040825/a0d732e3/smime-0001.bin

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Thu Aug 26 07:50:22 2004

This should be sent as an if program can honor than do it.  If you don't 
send the info than there is no possibility of honoring this information.

Cyrus Daboo <[email-masked]> 
Sent by: [email-masked]
08/25/2004 07:16 PM

To
Nathaniel Borenstein <[email-masked]>, [email-masked]
cc

Subject

Hi Nathaniel,

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Aug 26 08:24:08 2004

Satya Vempati wrote:

> Another area in need of simplification/better explanation is the
> event class: PUBLIC/PRIVATE/CONFIDENTIAL.
> 

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.
Example:

  - User A is allowed to view all the properties of my PUBLIC
    calendar objects.

  - 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! :-)

Cheers,
Bernard

---

From: harrie at inet.it (Harrie Hazewinkel)
Date: Thu Aug 26 08:53:14 2004

> Remember that iCalendar doesn't define an _access control_ model.

True, but it has the CLASS-property. So the statement of
"doesn't" is not completely right. It depends on how you define it.
Only CLASS is a very rough ACM.

> At best, the recipient should view the CLASS property as informative.

We (here at I.Net) have implemented a CAP server with ACL for
as well inidvidual users as with groups.
Your example speaks only of 'viewing' data, but how about modifying
and/or replying(accepting) an invitation. The client needs to know some
information about that. Of course, you may say that is a CAP only issue,
but then again the information must be conveyed in combination with
the VEVENT.

In the end we have custom properties for this, since we are also in the
luck we have the client side. On top of that our CAP server makes sure 
that every user receiving a VEVENT gets only those properties he/she may
view. For instance, if a user may only see DTSTART/DTEND it only sends
those properties (you should not trust the final client to filter them).

The class property is only a mean to provide a 'rough' access control by 
the originator.

> property. How could it be? There is no semantic defined! :-)

Or every one just accepts the CLASS property as informative or
ignores it in the application/client.

Harrie

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Aug 26 11:18:30 2004

> Only CLASS is a very rough ACM.

iCalendar specifies a data representation. It doesn't say anything
about "accessing" data, let alone about "controlling" its access.

An access control model should allow you to specify "who" is
granted or denied which "privilege" on "what". CLASS is only
useful for the "what".

> but then again the information must be conveyed in combination with

Here's an example for modify:

- User B (my assistant) is allowed to modify my PUBLIC and CONFIDENTIAL
   calendar objects.

- User B (my assistant) is not allowed to modify my PRIVATE calendar
   objects.

About replying:

I think you should always have the right to reply to an invitation! :-)
Whether somebody else is granted the right to reply to an invitation on
your behalf is indeed more tricky. Would you base the ACE that grant or
deny the right to reply to invitation on the value of the CLASS property
set by the originator (i.e., organizer)?  Hummm... It would probably be
safer to discard the received CLASS and to specify an ACE for
unspecified CLASS (e.g., deny when in doubt).

> those properties (you should not trust the final client to filter them).

Would you mind sharing your custom properties?

> The class property is only a mean to provide a 'rough' access control by 

Sorry to insist but CLASS specifies classification not control.

Cheers,
Bernard

---

From: satyanarayana.vempati at Sun.COM (Satya Vempati)
Date: Thu Aug 26 11:26:31 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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Desruisseaux
Sent: Thursday, August 26, 2004 8:24 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

> 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_.

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.
Example:

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! :-)

Cheers,
Bernard

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

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Thu Aug 26 12:28:09 2004

I still disagree. 
The property is currently being used by several iCalendar implementations.
It has nothing to do with general access rights on recipients calendar 
store.
The Class of private says the sender prefers this information to remain 
private.  If information is not sent than receiver has no option of 
complying.

08/26/2004 02:26 PM

To
Bernard Desruisseaux <[email-masked]>, 
[email-masked]
cc

Subject
RE: [Ietf-calsify] Event class

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.

-----Original Message-----
From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Bernard 
Desruisseaux
Sent: Thursday, August 26, 2004 8:24 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

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.
Example:

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.

Cheers,
Bernard

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Aug 26 13:20:22 2004

Hi [email-masked],

> 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

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Sun Aug 29 08:22:03 2004

> - User B (my assistant) is not allowed to modify my PRIVATE calendar

This is a wonderfully clear example.  Unfortunately, I can't find this 
interpretation anywhere in RFC 2445.  Have I missed it, or is it simply 
one possible interpretation of the difference between PRIVATE and 
CONFIDENTIAL?  At the very least, this needs to be clarified, but I'm 
not yet convinced it shouldn't simply be eliminated.

I think we are facing a classic tradeoff, insufficiently analyzed.  
There is a very large general problem, which is access lists.  There is 
a very specific application, format and protocol, calendaring, which 
has its own specific access control needs.  The current values of CLASS 
reflect an attempt to follow the 80/20 rule and cover most use cases 
without overly generalized complexity.  The question is, did it work?  
If you can convince me that PUBLIC/PRIVATE/CONFIDENTIAL covers 80% or 
more of the use cases, I will stop objecting to CLASS.  However, I fear 
that most users' environments are sufficiently complex that the 
coverage is probably more like 20% than 80%, in which case CLASS 
complicates the standard for (IMHO) inadequate value.

I don't suppose anyone has anything as useful as ethnographic data to 
help us tell what percentage of the use cases we are actually covering? 
  -- Nathaniel

PS -- As I've been suggesting for other topics... since the CLASS 
property is both informational-only (as per RFC 2445) and arguably 
representationally inadequate, it might be a better idea to remove it 
from the base spec and then (if someone is sufficiently motivated) 
write an additional spec on access control in iCal, which might even 
define a somewhat richer approach that is backwards-compatible with RFC 
2445's CLASS property.  -- NB

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Sun Aug 29 19:33:25 2004

Nathaniel,

Here's a use case:

- I create a confidential meeting on my SyncML device.

- I synchronize my device with Oracle Calendar Server.

- Thanks to the CLASS property, Oracle Calendar Server
   will enforce the access control that applies to my
   confidential meetings when people will try to access
   this new meeting on the server.

Was the CLASS property used for access control?  No.

Was the CLASS property useful? Yes, it allowed me to
set the access classification of a new meeting from my
SyncML device.

Who cares what Bernard's access classification "confidential"
means?  Only Bernard and his calendar store.

Now you are going to ask me: ? What about iTIP? ? (Right? :-))

Answer #1: iCalendar is not only meant for iTIP.

Answer #2: Let me try this analogy:

You receive a document from an IBM colleague stamped with
the words "TOP SECRET" on the first page. As an IBM employee
you know what "TOP SECRET" means per IBM's policies.

If I send you an Oracle document stamped with the word
"CONFIDENTIAL" on the first page you won't exactly know
what "CONFIDENTIAL" means because you are not an Oracle
employee.

Same with iTIP. In some cases the originator and recipients
of iTIP messages will share the semantic of the CLASS
property and in other cases they won't.

Cheers,
Bernard

Nathaniel Borenstein wrote:

> a very specific application, format and protocol, calendaring, which has 
> its own specific access control needs.  The current values of CLASS 
> that most users' environments are sufficiently complex that the coverage 
> is probably more like 20% than 80%, in which case CLASS complicates the 
> standard for (IMHO) inadequate value.
> 
> from the base spec and then (if someone is sufficiently motivated) write 
> an additional spec on access control in iCal, which might even define a 
> somewhat richer approach that is backwards-compatible with RFC 2445's 
> CLASS property.  -- NB
>

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Mon Aug 30 08:25:34 2004

>   this new meeting on the server.

The only problem I have with this example is that it's a special case.  
  What if it's someone else's calendar server, but the same client?  
We're designing open protocols, right?  How can we justify having this 
capability in the language if we can't explain what it means in a 
precise, interoperable way?  The definitions of things like "SENSITIVE" 
might be customer-specific, but they oughtn't to be vendor-specific if 
we can avoid it!

> what "CONFIDENTIAL" means because you are not an Oracle

But the CLASS property doesn't carry all the necessary context.  I know 
what to do with "IBM Confidential" because I have the word "IBM" in 
addition to the word "Confidential".  Similarly, I also understand that 
if I pay you a million dollars (Canadian, of course) for a document 
marked "Oracle Confidential" I don't really have as precise a knowledge 
of what "Confidential" means in this context -- for all I know it could 
be the very lowest of a ten-tier secrecy system that defines concentric 
circles around Larry Ellison, and I could be overpaying heavily for the 
document.  But with CLASS, all I get is "Confidential" -- I don't even 
know *whose* confidential, which could lead to some seriously violated 
user expectations in trying  to interchange data heterogeneously.

It is certainly reasonable to expect that a calendar user should be 
able to tell a calendar store what privacy constraints it wants the 
server to obey, but only if it's going to work no matter what brand of 
server is on the other end.  I am not sure what the right solution is, 
but my mantra remains:  when in doubt, simplify.  If we can't think of 
a clearer way to define these terms, perhaps we should back off to an 
unstructured text field and let vendors use X-values until we *can* 
agree on definitions.

Thinking about the "right" way to do this leads me into more complex 
ideas such as letting it be an explicitly organizationally defined 
field, as in

	CLASS:  [email-masked]

where (somewhere, somehow) ibm.com has defined a list of values and 
their meanings, and one of them means "only show this to IBM people who 
have signed a confidentiality agreement with Oracle corporation that is 
effective in 2005."   Big companies have to draw internal lines like 
that all the time.  it still looks like an access list to me.  If 
access lists are what we need, we should just leave a hook in the 
standard and go to work on access lists when we're done with calendars. 
  :-)

> In some cases the originator and recipients

In essence, I think, you are saying that the meaning of CLASS is 
determined according to the (out-of-spec) interpretation of 
"consenting" software.  I say that this is a recipe for confusion.  I 
think if we're going to define a field to be interchanged between 
heterogeneous software, we should either define what it means or make 
it an uninterpreted, unstructured field, i.e. a "privacy label".

Other ideas?  Access lists are a fairly large problem, and I really 
don't want to try to solve them in the iCal group, but neither do I 
want to perpetuate an ill-defined "poor man's access list" if we can 
help it.  Really, in my mind this all comes down to the lack of clarity 
between PRIVATE and CONFIDENTIAL.  I could live with "PUBLIC," 
"PRIVATE," and user-defined or to-be-defined values, I suppose, because 
the distinction between "the user" and "everyone else" is an easy, 
clean definition.  -- Nathaniel

---

From: patrice.scattolin at oracle.com (Patrice Scattolin)
Date: Mon Aug 30 20:31:31 2004

> unstructured text field and let vendors use X-values until we *can* 

Well we could wait for an industry standard to emerge first and then 
standardised it. This has been the approached used in many other areas 
before.

Furthermore, as good a mantra as it is, it runs straight into the 
current ICal definition which is used and implented in various places. 
While there might be a place for "ICal-Lite", plain old heavy ICal is 
going to exist and be supported for a while. So if you simply by 
removing some items, maybe that's workable since it's essentially 
backwards compatible with the existing software but if you are going to 
go in a different direction you will only increase the clutter in this 
problem space to say nothing of the users of old ICal will then need to 
add these new construct to be able to support the new special semantics 
of ICal-Lite. Especially with unstructured textfield. While it's 
plausible that not all vendors can agree on specific semantics ahead of 
time for all possible values of the CLASS they will be close whereas 
interpreting unstructured fields is an exercise in reverse 
engineering/patching once the products are relased which is far worst.

> help it.  Really, in my mind this all comes down to the lack of 
> clarity between PRIVATE and CONFIDENTIAL.  I could live with "PUBLIC," 
> "PRIVATE," and user-defined or to-be-defined values, I suppose, 
> because the distinction between "the user" and "everyone else" is an 
> easy, clean definition.  

And "CONFIDENTIAL" is defined as "user's trusted circle". We can leave 
the notion of who exactly is in that trusted circle out. For one thing 
nothing says that this  circle of trust won't change during the 
meeting's life and really, who am I to tell anyone how to decide who 
they should trust or where should that list live.

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Aug 30 22:39:46 2004

> __________________

It is not defined at all in rfc-244[567].

Even if we were to define it to mean that, how can it have any meaning 
outside
of the organizers opinion without being able to transfer who is in that 
list? If
you trust me and send me A CONFIDENTIAL VEVENT, I do not have
access to your trusted list. I can only interpret it to mean my-trusteed 
list,
and I forward it to someone I trust, that is not in your trusted list.  
It has
no meaning outside of ACLs (VCARs).

It has no meaning in a REQUEST and other iMIP messages.
It only has context in CAP (or caldav) that contain VCARs.

In CAP you can define a VCAR called " user's trusted circle ", but it
has no meaning to an iMIP message if the VCAR is not transferred with it.

So outside CAP or some kind of ACL's, there is no way to enforce
who gets access.

And at this time PRIVATE and CONFIDENTIAL are not defined, so
any existing implementation can not interoperate with certainty. It is 
busted.

With CAP I could define a VCAR that said that UPN's UPN-A, UPN-B, and
UPN-C were in the VCAR named "user's trusted circle" and define
that any VEVENT with CLASS:CONFIDENTIAL uses that VCAR.
So when a CS/CUA reads the VEVENT and makes the iMIP message
it could decide if you can send it to that UPN, but after I get it, I still
have no clue who is in your trusted circle.

-- 

-------------- 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/20040830/91e76440/smime.bin