Subject: Re: POLICY in general.

From: Doug Royer <[email-masked]>
Date: Sun, 27 Feb 2000 13:53:54 -0800

I just put this in CAP + a tweak or two the the ABNF to make it work.

Doug Royer wrote:
> 
> 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.