Subject: CAP: What is the purpose of CAR-MIN?

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 01 Feb 2002 15:36:50 -0500

In my quest to find the purpose of CAR-MIN, I've been
able to identify the following requirements.  None of
which requires that a CS should report a different level
of CAP support.

As it stands, CAP doesn't need two different values for
the <car> capability.

1- CS MUST implement VCARs for the following predefined
   CARIDs: READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS,
   and DEFAULTOWNER;

   Rational: At one point in time people in this WG believed
             it would make CUA's life easier.

   Comment : CAP doesn't impose any restriction on the
             definition of these VCARs.  It simply suggests
             definitions for them.

2- It MUST be possible for a CS to deny all users the right
   to write, modify and delete any VCARs.

   Rational: A CS might want to hard code all its VCAR.

   Comment : Can easily be done with a decreed VCAR,
             potentially hard coded.             

3- It MUST be possible for a CS to deny all users the right
   to write, modify and delete VCARs other than VCARs with
   the predefined CARID.

   Comment : Can easily be done with a decreed VCAR,
             potentially hard coded.             

4- It MUST be possible for a CUA to search for VCAR based
   on their CARID (predefined or not).

   Comment : As is the case for all search operation,
             an empty response will be returned when
             no VCAR matches the VQUERY.

5- The VCAR with the predefined CARIDs MAY be decreed.

   Comment : Need to agree on way to differenciate
             decreed VCARs from non-decreed VCARs.
             See Doug's proposal (i.e., "decreed"
             parameter for the CARID property).

6- VCAR MUST have a CARID unique within the scope of the
   VAGENDA (or CALSTORE) in which they are stored.

   Rational: Identifiers are useful to manage objects.

Open Issue:

1- Can a CS deny the right to READ the VCARs with the
   predefined CARIDs?  Why not?

Regards,
Bernard
-- 
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: Fri, 01 Feb 2002 15:51:21 -0700

>              it would make CUA's life easier.

No. It makes small CS's possible.
>    predefined CARIDs?

It could, but that would defeat the point of having
predefined VCARs. Are you proposing a third level:

	CAR-NONE ?

---

From: Doug Royer <[email-masked]>
Date: Fri, 01 Feb 2002 15:58:13 -0700

> As it stands, CAP doesn't need two different values for

Explain how a CUA can know if a CS can only handle
the CAP predefined VCARs?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 04 Feb 2002 10:39:55 -0500

> the CAP predefined VCARs?

So, that would be THE purpose of CAR-MIN?

Now can you explain how a CUA can know if it can
modify the CAP predefined VCARs of a CAR-MIN CS?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Feb 2002 10:14:52 -0700

> modify the CAP predefined VCARs of a CAR-MIN CS?

It can't.

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Feb 2002 10:15:35 -0700

It can't.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 04 Feb 2002 13:26:01 -0500

> > modify the CAP predefined VCARs of a CAR-MIN CS?

Then, to "hard code the answer to the predefined VCARs
in its ROM", a CS will need to be CAR-FULL-1.  Right?

It seems as all we really need is yet another predefined
CARID to specify VCAR's access right, and not different
levels of CAR support.  Such a VCAR could be defined to
specify that only VCAR with predefined CARID can be read
and/or modified.  As all other predefined VCARs, this VCAR
could be decreed or not.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Feb 2002 13:52:37 -0700

> in its ROM", a CS will need to be CAR-FULL-1.  Right?

No. It can just copy the predefined (decreed) data to the CUA. 
A CAR-MIN CS implementation would never need to understand how to
parse a VCAR. And a CAR-MIN CS would never have the ability to
serve out any non-predefined (non-DEFAULT-VCARS) VCAR.

If a CS implementation needs to allow the CUA to create
any non-pre-defined VCARs, it is NOT a CAR-MIN CS.

> CARID to specify VCAR's access right,

Why not include it as part of the predefined VCAR?

I think I found a bug in the new VCAR proposal as last
proposed. You used to be able to specify multiple GRANT/DENY
in a VCAR, now they seem to be limited to one set per VCAR.
We used to be able to do this (may be we still can as I am
still learning the new proposal):

   BEGIN:VCAR
   CARID:REQUESTONLY

   GRANT:NONOWNER
   PERMISSION:WRITE
   RESTRICTION:METHOD = 'REQUEST'

   GRANT:OWNER
   PERMISSION:MODIFY
   SCOPE:SELECT * FROM VCAR WHERE CARID = 'REQUESTONLY'
   RESTRICTION:CARID = 'REQUESTONLY'

   END:VCAR

How do I do the above two (or more) things in one VCAR
using the new VCAR proposal?

> and not different
> levels of CAR support.

Restricting a predefined vcar has nothing to do with if a CS
MUST fully understand all VCARs.

>  Such a VCAR could be defined to

Or we need to remove the restriction from the current VCAR
proposal that limits the predefined VCAR itself from specifying
if it can be modified.

A spur of the moment proposal is a change to Bernards VCAR
proposal, allow something like:

	BEGIN:VCAR
	CARID:REQUESTONLY
	GRANT:UPN=NONOWNER();PERMISSION="WRITE"
         ;RESTRICTION="METHOD=REQUEST"
	GRANT:UPN=OWNER();PERMISSION=MODIFY
         ;SCOPE="SELECT * FROM VCAR WHERE CARID = 'REQUESTONLY'"
         ;RESTRICTION="METHOD=MODIFY"
	END:VCAR

That would again allow multiple rules per VCAR and use
the CAP-QL as the selection language.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 04 Feb 2002 17:39:10 -0500

> any non-pre-defined VCARs, it is NOT a CAR-MIN CS.

That's not the issue.

If a CS hard codes its predefined VCARs it needs to
deny all users the right to WRITE, MODIFY and DELETE
them.  Currently, there is no predefined VCARs meant
to allow the CS to specify that information.  So, as
of now, a CAR-MIN CS cannot hard code its predefined
VCAR.

> Why not include it as part of the predefined VCAR?

I wouldn't have any problem adding a predefined VCAR
with CARID:DEFAULTVCAR (I'm open to suggestion for a
better name).

Now, given that this predefined VCAR could specify which
VCAR you are allowed to READ, WRITE, MODIFY and DELETE,
we no longer need CAR-MIN.  This predefined VCAR is all
we need to fulfil the purpose for which CAR-MIN existed.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 04 Feb 2002 17:40:27 -0500

> still learning the new proposal):

That's not a bug.  This limitation was highlighted in
the introduction of my proposal:

  Bernard Desruisseaux wrote:
  >
  > - A VCAR component, as defined in this proposal, can only
  >   define a single access right.  If there is a need to group
  >   multiple access rights in a single VCAR (e.g., to share
  >   the same CARID and/or NAME properties) we could always
  >   group the properties GRANT, DENY, PERMISSION, SCOPE, and
  >   RESTRICTION in a component (e.g., VRIGHT).

BTW, following our discussions (no two VCARs can have
the same CARID within the same scope), I've already
modified my proposal to allow multiple access rights
to be defined in a single VCAR.  I'm planning to post
an updated version of my proposal tomorrow.

> MUST fully understand all VCARs.

All I said is that the CUA MUST have a way to know if it can
modify, create, delete predefined VCARs.  There is no such way
with a CAR-MIN CS.  That's a problem.

> proposal that limits the predefined VCAR itself from specifying

There is no such restriction.  I think we just need to
add one more predefined VCAR to solve the problem.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Feb 2002 16:42:36 -0700

> the introduction of my proposal:

That is a matter of opinion. We need to get it back
so that it can be done.

> an updated version of my proposal tomorrow.

:-)

> with a CAR-MIN CS.  That's a problem.

No, there is a way - define it in the same VCAR.

> add one more predefined VCAR to solve the problem.

No - the problem (bug) exists in ALL VCARs. You in the
proposal removed the ability for a VCAR to be complex.
We need to fix that.

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Feb 2002 16:39:31 -0700

Bernard Desruisseaux wrote:
> them.

No - it only needs to deny all users the right to
WRITE, MODIFY, and DELETE 'decreed' VCARs.

>  Currently, there is no predefined VCARs meant

No. You still (above) seem to think that predefined means
decreed - they are not the same thing.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 05 Feb 2002 09:34:37 -0500

> WRITE, MODIFY, and DELETE 'decreed' VCARs.

Defining a VCAR as "decreed" is all that is needed
to deny all those rights.  Correct?

> > we no longer need CAR-MIN.  This predefined VCAR is al

It is clear to me that they are not the same.

Regards,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 05 Feb 2002 10:15:49 -0500

> No, there is a way - define it in the same VCAR.

The VCAR with CARID:REQUESTONLY should only specify
whether users are granted or not the right to WRITE
iCalendar objects that contain METHOD:REQUEST.

If that's not the case, then let's drop all VCARs
with predefined CARID as they won't be any easier
to parse/interpret than any other VCAR.

> > > proposal that limits the predefined VCAR itself from specifying

I understand what you meant now, and I can say that
I'm against removing this restriction.

I will state this restriction clearly in my proposal
as I don't think it was written anywhere.

> proposal removed the ability for a VCAR to be complex.

I've already added back this ability in my proposal, but
it should not be used for the purpose you mentioned.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 09:46:43 -0700

> to deny all those rights.  Correct?

Defining a VCAR as decreed only means it is NOT changeable
by the CUA. I would think that a CS implementation SHOULD
tag that decreed VCAR as read-only - and we still need
a way to have multiple GRANT/DENY per VCAR so that
one single VCAR can specify complex GRANT/DENY permissions
such as this.

I think that your had said that you are going to send
a proposal that will allow multiple GRANT/DENY in one
VCAR. True?

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 05 Feb 2002 12:12:22 -0500

> one single VCAR can specify complex GRANT/DENY permissions

What do you mean exactly?

1- We simply have to add "DECREED:TRUE" in the VCAR
   component to specify that it is "decreed", that
   is, that it is NOT changeable (which imply that
   you can't WRITE, MODIFY, and DELETE it);

2- All users should explicitly be denied the right
   to WRITE, MODIFY and DELETE decreed VCAR by means
   of a VCAR (potentially the same VCAR);

3- In addition to "DECREED:TRUE", all users should
   explicitly be denied the right to WRITE, MODIFY
   and DELETE decreed VCAR by means of a VCAR
   (potentially the same VCAR).

> a proposal that will allow multiple GRANT/DENY in one

True.

Regards,
Bernard