Subject: POLICY in general.

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jan 2000 17:54:54 -0800

Originally the discussions surrounding POLICY it was started when some said
they wanted a simplified access rules for thinner CS's.

Now we can have a compatibility problem if we do not map from
one model into another. So if we keep POLICY, it is time now
to define them, or drop them and only use VCARs. And I think
we can drop them and specify a minimum set of VCARs that
a CS MUST support. And report that set with CAPABILITY.

Will call this minimum set 'CAR-MIN'.

Can a CS support POLICY only? Not from reading the cap-draft-text.
It does not state that anywhere and the ABNF implies both MUST be
supported. It looks like all CS's must support POLICY and
non-POLICY VCAR's. However from hallway conversations, I think
others will have strong opinions on this ...

	... if so SPEAK UP NOW!

(1) READBUSYTIMEINFO - Specifies rights for reading busy time data.

    As I have pointed out in previous email, I think we can eliminate
    this entirely. (See CAPABILITY below also).

	Example:

		replace:
			BEGIN:VCAR
			CARID:name
			GRANT:UPN=<...>;POLICY=READBUSYTIMEINFO
			END:VCAR

		With:

			BEGIN:VCAR
			CARID:READBUSYTIMEINFO
			GRANT:UPN=<...>;OBJECT=VFREEBUSY;ACTION=READ
			DENY:UPN=<...>;OBJECT=VFREEBUSY;ACTION=READ
			END:VCAR

			(or OBJECT=VFREEBUSY,DTSTART,DTEND,DURATION if the WG
			 wants READBUSYTIMEINFO to mean that).

(2) REQUESTONLY - Specifies rights for creating new event invitations, to-do 
    assignments and journal entries.

    As we are going to have to define what this means, then we can
    simply define in in terms of a VCAR and eliminate this as a POLICY.

    It could be (assuming I understand what the intent was):

		BEGIN:VCAR
		CARID:REQUESTONLY
		GRANT:UPN=<...>;OBJECT=ALL;ACTION=CREATE;
		END:VCAR

(3) ACTONBEHALFOF - Specifies rights for any CAP function taken on
    PUBLIC or  PRIVATE calendar components. However, no CAP function
    can be taken on CONFIDENTIAL classified calendar components.

    As we are going to have to define what this means, then we can
    simply define in in terms of a VCAR and eliminate this as a POLICY.

    Perhaps:

		BEGIN:VCAR
		CARID:ACTONBEHALFOF
		GRANT:UPN=<...>
		 ;OBJECT=ORGANIZER;VALUE=<act_for_who_upn>
		 ;OBJECT=SENT-BY;VALUE=SELF
		 ;OBJECT=CLASS;VALUE=PUBLIC,PRIVATE
		 ;ACTION=ALL
		END:VCAR

   ++In addition, 'self' probably would have to have CREATE, MODIFY, DELETE,
   permission in the target calendar.

(4) UPDATEPARTSTATUS - Specifies rights for modifying ones own
    participation status.

    Perhaps:

		BEGIN:VCAR
		CARID:UPDATESTATUS
		GRANT:UPN=<...>
		 ;OBJECT=PARTSTAT;VALUE=ALL
		 ;OBJECT=ATTENDEE;VALUE=SELF
		 ;ACTION=MODIFY
		END:VCAR

(5) OWNER - Specifies the same rights given to the owner of the calendar
    store or calendar.

    Make them an OWNER by adding their OWNER property to the calendar properly
list.
    And then:

		BEGIN:VCAR
		CARID:OWNER
		GRANT:UPN=OWNER;OBJECT=ALL;VALUE=ALL;ACTION=ALL
		END:VCAR

(6) CAPABILITY reply.

	In the current CAP draft in the ABNF it has CAR0, CAR1, CAR2, and CAR3.
	This needs to be changed to CAR-MIN, and CAR-FULL-1

	Define CAR-MIN as the above definitions (Or what ever tweaks the
	WG makes to the above definitions).

	If CAR-MIN is returned by CAPABILITY, then ONLY the ones defined above
	are supported. They can be hard coded into a CS (plus storage for
	which UPNs they apply to), or parsed. Ether way I think this would
	solve both problems (thin CS's and a complete IF supported VCAR).

	If CAR-FULL-1 is returned by CAPABILITY, then all of the VCAR support
	MUST be supported.

	Only one of CAR-MIN or CAR-FULL-1 can be returned by CAPABILITY.