Subject: Re: forced VCAR (was: revised security section)

From: [email-masked]
Date: Thu, 27 Jan 2000 14:12:19 -0500

Is this a CS overriding the request CAR specified by a CUA with it's own 
default CAR?
If so, I assume that an exception would also be returned to the requesting 
CUA by the CS.
-- Frank

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 27 Jan 2000 15:33:52 -0500

>If so, I assume that an exception would also be returned to the requesting 

Yes.

---

From: David Madeo <[email-masked]>
Date: Fri, 28 Jan 2000 02:09:25 -0500

> >If so, I assume that an exception would also be returned to the requesting

Richard accused me of asking for the world yesterday, but I'd like to clarify
what I was thinking when I proposed this.

Assuming Doug can go through and get rid of policies and replace them with
"VCAR scenarios often encountered in the real world", I'd like to see the
"forced VCAR" be a mandatory addition to every calendars set of VCAR's.
Users should be able to (subject to implementation configuration) create
additional VCARs that complement but do not remove or override the forced
VCAR's.

This does not raise the inheritance issue Rich was concerned.  The VCAR is
stored with the calendar just like everything else.  The server just knows that
that particular VCAR can't be changed by the end user.

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Jan 2000 08:35:32 -0800

> that particular VCAR can't be changed by the end user.

How about a new optional property 'ACCESS':

   x.y.z ACCESS

   Property Name: ACCESS

   Purpose: Specifies if the component it is contained within is modifiable
   by any CUA.

   Format Definition: The property is defined by the following
   notation:

     accessparam	= "ACCESS" ":" ( "READ-ONLY" / "READ-WRITE" )

   Description: This property can be specified within a component.
   The parameter specifies if the property can be modified by a CUA.
   This property does not effect any non CUA vendor specific administrative
   tool from modifying the values in the component.

   If not specified in the component the component is READ-WRITE assuming the
   authenticated UPN has component MODIFY or DELETE access.

   Example. A rule to give full access to all localdomain users:

	BEGIN:VCAR
	CARID:access-1-ex
	ACCESS:READ-ONLY
	GRANT:UPN=@localdomain.com;ACTION=ALL;OBJECT=ALL
	END:VCAR

(The example assumes that @domain means any authenticated user at
 domain. And not any local domain user as anonymous).

-Doug

---

From: "Paul B. Hill" <[email-masked]>
Date: Fri, 28 Jan 2000 17:24:50 -0500

At 02:09 AM 1/28/2000 -0500, David Madeo wrote:
>I'd like to see the

Hi,

I'm trying to figure out what Dave means by mandatory. During the 
conversation in Cambridge I thought that Dave was hoping for a MAY 
implement but felt that MUST was not necessary, and was unlikely to be 
accepted.

Dave, are you talking about the how a server might implement this feature, 
or the language that has to go into the draft?

No that I think about it even more, is this subject appropriate for the 
draft at all? It would never appear as a part of the protocol on the wire, 
right? The only thing that would need to be defined for the protocol is 
what would be conveyed to the CUA if it tried to write a VCAR that the CS 
would not honor.

Paul