Subject: CAP: Definition of CAR-MIN

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

I would like to propose the following definition for the
CAR capability "CAR-MIN".

  The CAR capability "CAR-MIN" indicates that the CS only
  supports VCARs with the following predefined CARIDs:
  READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and
  DEFAULTOWNER.

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: Tue, 05 Feb 2002 09:47:51 -0700

>   READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and

And and:

	or any IANA or X-NAME.

Okay?

---

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

> >   READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS and

Why would you want/need that?

If the CS wants/needs to support more than the four (4)
VCARs with predefined CARIDs it simply has to advertize
itself as a CAR-FULL-1 CS.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 11:07:57 -0700

> Why would you want/need that?

So that they can be extended.
So vendors can have extensions.

> itself as a CAR-FULL-1 CS.

No. Not if the CS can't parse VCARS.

---

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

---

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

> So vendors can have extensions.

Then, it's my turn to ask:

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

> No. Not if the CS can't parse VCARS.

Irrelevant.  A CAR-FULL-1 CS could hard code all
its VCARs and tag them as "decreed", as long as
one of the VCAR denies all users to write, modify
and delete VCARs.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 12:51:48 -0700

>   the CAP predefined VCARs?

	(1) The CS advertises CAR-MIN which tells the CUA that
            the CS can not parse VCARs.

        (2) The CUA looks at 'DEFAULT-VCARS' to determine what
            VCARs the CS knows, which is going to be at least
            the predefined CAP VCARs. 

        (3) The predefined VCARs can only be queried by CARID.

> one of the VCAR denies all users to write, modify

Any CS that can not PARSE VCARs better advertise CAR-MIN.
And it better place the VCARs that it knows in DEFAULT-VCARS.
And it better reply to the predefined VCARs by CARID when queried.

If a CS can PARSE VCARs it can advertise CAR-FULL-1, and
it is still free to mark them read only (decreed).

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 05 Feb 2002 16:50:45 -0500

>             the CS can not parse VCARs.

This is not true.  Else, why would CU waste their valuable
time modifying the VCARs with predefined CARID?

>             the predefined CAP VCARs.

DEFAULT-VCARS is not meant to advertize the VCARs the
CS knows, but the VCAR that MUST be copied in newly
created VAGENDA.  That's different.

>         (3) The predefined VCARs can only be queried by CARID.

a) Again, this was never mentioned on the list.

b) This is of no help.  The question was: "how a CUA can know
   if a CS can only handle the CAP predefined VCARs?"

c) Why shouldn't I be able to query the predefined
   VCARs by other properties?  There is no such
   restriction for other components, and there
   are no reasons to handle VCAR differently.

> Any CS that can not PARSE VCARs better advertise CAR-MIN.

Why?

> And it better place the VCARs that it knows in DEFAULT-VCARS.

Not necessarily (see above).

> And it better reply to the predefined VCARs by CARID when queried.

Yes.  But not only "by CARID".

> it is still free to mark them read only (decreed).

Yes, it CAN (i.e., this is not a MUST).

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 15:50:38 -0700

> created VAGENDA.  That's different.

You missed some of the thread.

For CAR-MIN CS's, it is the FULL list of VCARs the CS understands.

Why? Because the (long ago) debate was something like this:

   If I have a CAR-MIN CS, only the 'predefined VCARs' exist?

   YES.

   Do we know the full set that may be needed?

   NO.

   Then if we extend them (define more), how will a CUA
   know which ones are defined witout having to create more
   capability replies?

   Lets put them in the DEFAULT_VCARS, as a CAR-MIN CS
   would only have the 'predefined' VCARs in the DEFAULT-VCARS
   property - because when a CAR-MIN CS advertises that it
   is a CAR-MIN CS, it is telling the world that the predefined
   VCARS are the the only VCARs it supports.

   So for a CAR-MIN CS, no other VCARs can exists?

   TRUE.

   Then for a CAR-MIN CS - DEFAULT-VCARS is the full list of
   predefined (or x-) VCARS that exist for this CS.
   As the CS CAN NOT use any other than the predefined VCARs,
   there can't be any more or less for any calendar.

-Doug