Subject: CAP: Questions concerning CALSTORE vs Capabilities

From: Patrice Lapierre <[email-masked]>
Date: 14 Jan 2002 08:39:28 -0500

The concept of a CALSTORE component is not well explained in 
the draft (there a query example and the table definition table). 
But from what a read, CALSTORE properties also seems very similar 
to the server capabilities.

1. What are the differences between the CAPABILITIES the 
   CALSTORE property?

   I noticed that CALSTORE has some properties that can be 
   modified (i.e. CALMASTER and DEFAULT_VARDS).  

   Is there other differences?

2. The concept of DEFAULT_VARDS is not explained at all in 
   the draft.  Is it necessary for a CUA to be able to set the 
   DEFAULT_VARDS property, or could it be done it an implementation 
   dependent manner?

3. Should duplication be removed?

    The some information appears in both capabilities and CALSTORE
    (MAXDATE, MINDATE and VERSION). Do they mean they have the 
    same meaning in both sections?

4. What criteria should be used to decide where a property 
   belongs?

5. Should the two concepts be merged?

6. CALSTORE is act like an iCalendar component (i.e. BEGIN/END format, 
   can returned in searches). Why not named it VCALSTORE?

---

From: Doug Royer <[email-masked]>
Date: Mon, 14 Jan 2002 11:41:08 -0700

> to the server capabilities.

Yes. We should fix that.

> 1. What are the differences between the CAPABILITIES the

CAPABILITIES should be the implementation version of CAP and
any optional CAP protocol features we specify, or any vendor
extensions (via the experimental X-.. names).

Originally there was no CALSTORE properties, they were all
CAPABILITIES. My guess is that the ones that are in fact
properties and not protocol capabilities migrated to properties
and were never deleted from the capabilities.

>    Is there other differences?

CSID could conceivably be changed in a virtual host environment.

>    DEFAULT_VARDS property, or could it be done it an implementation

It is possible that both are true.

Any implementation specific VCARs are known as decreed VCARs if
they are not changeable by a CUA. Thus by default they are defined
and are DEFAULT_VCARS.

It is also possible for a CUA with VCAR access, to add new VCARs
to the default list. And to alter those default non-decreed VCARs.

>     same meaning in both sections?

Yes, I would like to see only protocol definitions to be
in CAPABILITIES. Cap VERSION and things that can change or
we think might change how the CUA talks to the CS.

> 4. What criteria should be used to decide where a property

I see the query language expanding over time. Also the fanout
being a capability of the CAP protocol soon. So we can't eliminate
capability.

I think they should be capabilities when they are:

	Versions of the CAP server protocol the CS supports.

	New commands that are optional.

	Variations of commands and the CUA needs to
	know what version of a command the CS understands.
	(SQL-COMMANDS-next?, CAR-FULL, ...)

	A vendor needs to specify vendor extensions with
	the experimental X- names - as a capability.

        I think we need to ADD to capabilities - the
        components a CS supports?

I think they should be properties when they only effect
the data and not the command / reply CAP protocol.

> 5. Should the two concepts be merged?

They can't completely. You need to know at a minimum that
the protocol is CAP-V1.0 for example from capability.  I see
the query language expanding over time. I also see fanout being a
capability of the CAP protocol soon, so we can't eliminate
capability.

>    can returned in searches). Why not named it VCALSTORE?

Okay with me. I think the reason they were encapsulated with
BEGIN/END VCALENDAR is because they are iCalendar objects.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 14 Jan 2002 15:53:21 -0500

> they are not changeable by a CUA. Thus by default they are defined

According to the draft, DEFAULT_VCARS contains the default
VCARs for newly created top level calendars, that is, the
VCARS automatically copied in VAGENDA at creation time.

Given that decreed VCAR apply to all calendars on the server,
I don't think it would be appropriate to have them copied in
every VAGENDA by listing them in the DEFAULT_VCARS property.

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: Mon, 14 Jan 2002 15:20:37 -0700

> every VAGENDA by listing them in the DEFAULT_VCARS property.

As we have done away with 'non-top' level calendars, they
do indeed apply to ALL calendars anyway.

Do you want to have two properties? As in:

	DECREED_VCARS	one entry: CARID:decreed or EMPTY.
	DEFAULT_VCARS	multiple entries set by a CUA

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 17 Jan 2002 10:26:46 -0500

> do indeed apply to ALL calendars anyway.

What I meant is that by listing decreed VCAR in DEFAULT_VCAR
would imply that they would be copied in every calendar.

>         DECREED_VCARS   one entry: CARID:decreed or EMPTY.

Why can't we simply store the decreed VCAR under CALSTORE?
No properties needed.

>         DEFAULT_VCARS   multiple entries set by a CUA

Where will the default VCARs be stored?  That is, the
actual VCARs that will be copied in newly created
VAGENDA?  In the CALSTORE?  Furthermore, who is
responsible for copying these VCARs in newly created
VAGENDA?  The CS?

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Thu, 17 Jan 2002 10:14:22 -0700

> would imply that they would be copied in every calendar.

We did away with VCAR inheritance, so the implementation
is free to optimize, but in effect they are copied to
each new calendar created.

So when the spec says COPY, it does not matter if the implementation
is smart about how it does that.

Why do we need to do this? (see below - DENY as default).

> Why can't we simply store the decreed VCAR under CALSTORE?

List all of the VCARs by CARID that all:

	Users
	Administrators (maybe decreed)
	Implementations (decreed) 

  will want to have copied into newly created calendars. Then
place those CARIDs into DEFAUTL_VCARS. Or predefine them in
the spec.

Don't forget that the CALSTORE may have VCARs for itself and you
don't want (just those CALSTORE only VCARs) copied to all newly
created calendars.

Do we require all of the decreed VCARs be in one VCAR
and have a CARID of 'decreed'?  That only works when ONLY
decreed VCARs are copied to new calendars. The DEFAULT_VCARS
property specifies the entire list of VCARs (user, system admin,
and decreed) VCARs that are to be copied to newly created
calendars.

Without requiring the name be something predefined (which people
did not want and no one can name in advance), there has to be a
property that tells you what they are - DEFAULT_VCARS. The CARIDs
in DEFAULT_VCARS tells you which of all the VCARs that exist in the 
CALSTORE, which ones (by CARID)) to copy to newly created calendars.

Remember that the default access is DENY. So if you were
to create a calendar and not predefine some VCARs, no one
has access in any way to that calendar. We could instead
just mandate that all newly created calendars specify their
own VCARs at creation time. But that can't work because 
if they tried to violate implementation specific restrictions,
or site administrative restrictions, the create would fail.
Then they would want to know why it failed. The answer would
be the same result - look up the DEFAULT_VCARS and find out
what are those restrictions. Ether way, we needed a way
for a CUA to find the default VCARS and then it can adjust
how it sets up a new calendar.

> Where will the default VCARs be stored?

In the CALSTORE.

>  That is, the actual VCARs that will be copied in newly created
> VAGENDA?

The ones named in DEFAULT_VCARS will be copied to newly created
calendars from the CALSTORE - to the new calendar. But only
the ones listed in DEFAULT_VCARS - and no others. Plus
any that are CUA lists when it creates a new calendar.

>  In the CALSTORE?

Yes - if you mean where do they come from.

> Furthermore, who is responsible for copying these VCARs in
> newly created VAGENDA?  The CS?

Yes - the CS is responsible for copying them into new calendars
when the new calendars are created and without specific
intervention by the user or CUA.

-
AND WE STILL NEED TO ADD THE known predefined VCARs (REQUESTONLY...)
back into CAP - does anyone have the deleted text?