Subject: CAP: DEFAULT_VCARS

From: Doug Royer <[email-masked]>
Date: Mon, 19 Nov 2001 10:58:53 -0700

In:

10.1 Calendar Store Properties

Is:

             DEFAULT_VCARS  N     TEXT      A multivalued property
                                            containing the default VCARs
                                            for newly created top level
                                            calendars. Each entry is a
                                            CARID. It MUST include at a
                                            minimum
                                            READBUSYTIMEINFO,REQUESTONLY,
                                            UPDATEPARTSTATUS, and
                                            DEFAULTOWNER.

As part of the debate that separated SQL into SQL-MIN and SQL-92,
there was an agreement (Insisted upon by I think Frank and perhaps
Bruce), for some pre-defined VCARS. They were agreed to be:

  READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER.

The following text (or equivalent) needs to be added:

(Perhaps as section 2.4.4.3)

x.x.x.x Default VCARs

In order for any calendar to function, there must be a minimum
set of VCARs defined. This specification does not mandate the contents
of these VCARs as that is a site policy and an implementation detail.

These default VCARs can be hard coded into the implementation
or stored as immutable VCARs by QUERYNAME. They MUST BE readable by
an UPN that has access, using a METHOD:READ of a VQUERY for the calendar
and MUST BE in VCAR format.

The administration of these VCARs can be through CAP or any
implementation specific or site policy administration tools provided
by the implementation.

These predefined VCARs can be defined at the calendar store level
and inherited by calendars as they are created.

Implementations should verify any modifications (if allowed) of
these default VCARs by the calendar OWNER to ensure that the
OWNER still has access consistent with site policy. This will ensure
that a faulty or malicious CUA can not remove the OWNERs rights to
their own calendar.

Note that READBUSYTIMEINFO, REQUESTONLY, and UPDATEPARTSTATUS default
VCARs apply to everyone except the OWNER of the calendar. The only
exception is that a site may include a DENY that prevents the calendar
OWNER from METHOD:MODIFY or METHOD:DELETE of the target default VCAR.
The owners access is otherwise through the DEFAULTOWNER default VCAR
and any other non-default VCARs that may be defined.

CARIDs of these names MUST BE defined for all calendars at all
times (possibly defined by inheritance from the store or parent 
calendar). The contents are not defined as they are subject to
OWNER and site policy. And these default VCARs are:

	READBUSYTIMEINFO
	REQUESTONLY
	UPDATEPARTSTATUS
	DEFAULTOWNER

And they are described in the four subsections that below.

x.x.x.x.1 READBUSTIMEINFO VCAR

A READBUSYTIMEINFO VCAR MUST BE defined for each calendar (possibly
inherited from the calendar store or parent calendar). This
VCAR applies to everyone except the calendar OWNER. This VCAR
may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR.

This VCAR defines the default VCAR for reading both any VFREEBUSY
components and any other components or properties that would help a CUA 
determine if a calendar was busy.

An example might be to allow everyone to read any VFREEBUSY components,
and any DTSTART, DTEND, and DURATION values from a VEVENT where the
VEVENT was booked (VEVENT with METHOD set to CREATE), within the calendar
in order to determine if the calendar is busy. This example also DENYs
the OWNER permission to MODIFY or DELETE this VCAR.

	BEGIN:VCAR
	CARID:READBUSYTIMEINFO
	GRANT:UPN=*;OBJECT=VFREEBUSY;VALUE=*
	GRANT:OBJECT=VEVENT;VALUE=DTSTART,DTEND,DURATION
	 ;OBJECT=METHOD;VALUE=CREATE
	DENY:UPN=owner;OBJECT=VCAR;OBJECT=CARID;VALUE=READBUSYTIMEINFO
	 ;OBJECT=METHOD;VALUE=MODIFY,DELETE
	END:VCAR

Or to just allow VFREEBUSY:

	BEGIN:VCAR
	CARID:READBUSYTIMEINFO
	RAND:UPN=*;OBJECT=VFREEBUSY;VALUE=*
	END:VCAR

x.x.x.x.2 REQUESTONLY

A REQUESTONLY VCAR MUST BE defined for each calendar (possibly
inherited from the calendar store or parent calendar). This
VCAR applies to everyone except the calendar OWNER. This VCAR
may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR.

The REQUESTONLY VCAR sets the GRAND and DENY values for performing
a METHOD:REQUEST on a calendar. This VCAR applies to everyone
except the OWNER.

If an OWNER, administrator or site policy, wishes anyone to be able
to make requests of the calendar time using REQUEST for VEVENTs
or VTODOs, they might use this example VCAR:

	BEGIN:VCAR
	CARID:REQUESTONLY
	GRANT:UPN=*;OBJECT=VEVENT,VTODO;VALUE=*
	 ;OBJECT=METHOD;VALUE=REQUEST
	END:VCAR

If this calendar were private to the OWNER and the OWNER did
not wish anyone else the ability to REQUEST time on the calendar,
the owner might use this VCAR:

	BEGIN:VCAR
	CARID:REQUESTONLY
	END:VCAR

As the default for any access is DENY, only the CARID:REQUESTONLY
MUST BE defined (because all default VCARs defined in this specification
MUST BE defined).

x.x.x.x.3 UPDATEPARTSTATUS

A UPDATEPARTSTATUS VCAR MUST BE defined for each calendar (possibly
inherited from the calendar store or parent calendar).  This
VCAR applies to everyone except the calendar OWNER. This VCAR
may DENY the calendar OWNER the ability to MODIFY or DELETE this VCAR.

This VCAR informs CUAs if they have permission to update ATTENDEEs
participation status (PARTSTAT) in the calendar using METHOD:MODIFY
for the current sessions identity. This VCAR applies only
to the ATTENDEE property and its PARTSTAT parameter. The session
identy must also have an ATTENDEE property with their value
in the target componet.

If an OWNER did wish to allow anyone that could login and be identified
by the CS permission to update their own participation status in
a VEVENT except anonymous users:

	BEGIN:VCAR
	CARID:UPDATEPARTSTATUS
	GRANT:UPN=*;OBJECT=VEVENT;OBJECT=ATTENDEE;VALUE=self
	 ;OBJECT=PARTSTATUS;VALUE=*;OBJECT=METHOD;VALUE=MODIFY
	DENY:UPN=anonmous;OBJECT=VEVENT;OBJECT=ATTENDEE;VALUE=*
	 ;OBJECT=PARTSTATUS;VALUE=*;OBJECT=METHOD;VALUE=MODIFY
	END:VCAR

And to DENY anyone this could be used.

	BEGIN:VCAR
	CARID:UPDATEPARTSTATUS
	END:VCAR

Any UPN that has a DENY, must use the iTIP METHOD:REPLY to notify
the calendar OWNER of any updates.

x.x.x.4 DEFAULTOWNER

A REQUESTONLY VCAR MUST BE defined for each calendar (possibly
inherited from the calendar store or parent calendar).  This
VCAR applies to only the calendar OWNER. This VCAR may DENY the
calendar OWNER the ability to MODIFY or DELETE this VCAR.

This VCAR defines the calendars OWNERs rights to the target calendar.
An owner might be given unlimited access to a calendar:

	BEGIN:VCAR
	CARID:DEFAULTOWNER
	GRANT:UPN=owner;OBJECT=*;VALUE=*
	END:VCAR

Or of the site policy only allowed a calendar OWNER to have VEVENTs and
to be able to read the VCARs (perhaps because the site only allows
the default VCARs and they are not alterable by the OWNER).

	BEGIN:VCAR
	CARID:DEFAULTOWNER
	GRANT:UPN=owner;OBJECT=VEVENT;OBJECT=METHOD;VALUE=*
	GRANT:UPN=owner;OBJECT=VCAR;OBJECT=METHOD;VALUE=READ
	END:VCAR

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 20 Nov 2001 17:18:24 -0500

>                                             READBUSYTIMEINFO,REQUESTONLY,

Do we need this calendar store properties given that
we have VCAR inheritance?  Currently, the specs only
says that these VCARs MUST be implemented, not that
they be created in every VAGENDA (maintenance hell).

> and MUST BE in VCAR format.

What do you mean by "stored as immutable VCARs by QUERYNAME" ?

>         GRANT:UPN=owner;OBJECT=VCAR;OBJECT=METHOD;VALUE=READ

I notice that none of the RIGHTS value type of the VCARs
specified above make use of the ACTION rule part defined
in the document "Proposed changes to iCalendar needed for
CAP" (iCal-updates) which is available at the following URL:

http://calsch.org/ietf/iCal-updates.html

Where can I get the most up to date specification of VCARs?

Regards,
Benrard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Wed, 21 Nov 2001 14:15:04 -0700

> they be created in every VAGENDA (maintenance hell).

The intent was that they are the default VCARs for a new calendar.
The reason they are listed is so a CUA can query for them and
find out what they contain. Otherwise the only way to find out
is to create a new calendar, then query for all of its VCARs, then
delete the calendar if is all you really wanted to know was what
the default calendar VCARs were.

> What do you mean by "stored as immutable VCARs by QUERYNAME" ?

I meant that the name MUST exist and be accessible from a VQUERY.

> Where can I get the most up to date specification of VCARs?

Someone ripped it out of CAP - plus what you point to is old text.
RIGHTS were replaced with GRANT/DENY. And the ABNF for those
is missing from CAP.

---

From: George Babics <[email-masked]>
Date: Wed, 21 Nov 2001 16:29:05 -0500

The VCAR specification in:

  was the latest one. It used to be in CAP, but was ripped
out, and put into a separate document, since we thought it
belonged in iCalendar.

George

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 21 Nov 2001 17:44:12 -0500

> the default calendar VCARs were.

Sorry.  My question should have been:

   Do we need "default VCARs for newly created top level
   calendars" given that we have VCAR inheritance?

That is, a newly created top level calendar automatically inherits
the VCARs directly contained under CALSTORE.  The default VCARs
could simply be all the VCARs directly contained under CALSTORE.

I don't understand why we would need to copy the default VCARs
in every top level calendar.

> RIGHTS were replaced with GRANT/DENY. And the ABNF for those

The GRANT and DENY properties don't replace RIGHTS,
they are RIGHTS value types.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Wed, 21 Nov 2001 16:36:36 -0700

> in every top level calendar.

I was getting these confused:

	11.1 Calendar Store Properties / DEFAULT_VCAR
	11.2 Calendar Properties / DEFAULT_VCAR

I agree, 11.2 DEFAULT_VCARS is not needed.

> they are RIGHTS value types.

Sorry - there used to be a RIGHTS property in CAP.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 21 Nov 2001 20:06:19 -0500

> I agree, 11.2 DEFAULT_VCARS is not needed.

Why do you think 11.1 DEFAULT_VCARS is needed?

The list of DEFAULT_VCARS is simply the list of
all the VCARs directly contained under the
CALSTORE.  There is no need to define this one
as well.  It can be obtained with a simple VQUERY.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Fri, 23 Nov 2001 14:51:51 -0700

Bernard Desruisseaux wrote:
> CALSTORE. 

No, it is a list of the defined CARIDs at the CS level.
Not all VCARs at the CS level need to be named with a CARID.

> There is no need to define this one

It lists any predefined VCARS that exist by CARID.

It allowed small devices to determine which 'predefined' VCARs
the CS knows, that the small CUA understands. So the small CUA
can just query for what it wants and does not have to do a full
VQUERY of what might be a large set of VCARs - then sort them.
REQUESTONLY is by definition limited to what the authenticated
entity can do, so the small CUA does not have to care about anything
other than understanding that what comes back applied to the current
authenticated entity.

A small CUA can say: 'I know the function of CARID:REQUESTONLY', but
I don't care about the rest of them.

There was a lot of resistance to not having predefined CARID's by
function VQUERYable by name. So then the debate went to, how
do I find out which predefined CARIDs does the CS support? The
answer was to add DEFAULT_VCAR at the CS level. Then we agreed
that any predefined 'access' MUST BE identifiable by a VCAR.
Then others asked - 'how can we expand this list in the future?'.
Then others asked what about any current VCAR with a CARID at the
CS level, so then DEFAULT_VCARs was expanded to include any VCAR in the CS
that had a CARID. In that way any CARID in DEFAULT_VCAR might
be a predefined CARID, and it no long matters to the CUA, it simply
gets a list, some of which may be predefined in an RFC.