Re: CAP: VAGENDA and CALSTORE: Component And Property Defintions

[George Babics <georgeb@xxxxxxxxxxx>]

Doug Royer wrote:
> 
> George Babics wrote:
> 
> I broke your text into multiple replies.
> 
> > The following is a proposal for the definitions of the VAGENDA
> > and CALSTORE components and their properties. These definitions
> > are based on the descriptions found in the CAP draft.
> >
> > This is the first iteration. Please review. Once I get people's
> > fixes and suggestions in, I will make a formal proposal.
> >
> > Summary:
> >
> >   The VAGENDA component describes the calendars belonging to users.
> >   It contains VEVENTs, VJOURNALs, VTIMEZONEs, VTODOs, VQUERYs, and
> >   VCARs. The properties that a VAGENDA may have are:
> 
> >    LOCALE: the default language
> >    NAME: the name of the calendar (e.g., "Work")
> 
>   Must NAME be in LOCALE?
> 
>   Can there be multiple instances of this property? - I would say yes.
>    - each with its own unique LANGUAGE parameter? - Yes.

  Yes. It can be multiple. If no LANGUAGE parameter is supplied, the
one in LOCALE (or DEFAULT-LANGAUGE) should be used.

> 
>   If it can not be multiple, then I would say it MUST BE in LOCALE.
> 
> You forgot 'TZID' (in this section) : the default TZ for the VAGENDA
> so that CUAs know what is meant when 'localtime' date-time values
> are used.

  You're right. However, TZID is a parameter and also a property.
Perhaps we should add something like DEFAULT-TZID?

  Where are 'localtime' date-time values used? Do you mean times
without a timzone, e.g., 20020213T100000.

> 
> >   The CALSTORE component is used to contain the properties of
> >   the calendar store. These properties are:
> 
> >     CURRENT-DATETIME: the current date and time on the CS
> 
> Did we agree to drop CURRENT-DATETIME ?
> As an option, if it is wanted, maybe we can return
> the current date-time as part of the greeting or capability reply?

  I would like to drop it. I will remove it from the proposal.
It anyone still thinks we need it, speak up.

> 
> >     MAXDATE: last date time that is supported by the CWS
> >     MINDATE: first date-time that is supported by the CS
> 
> MAXDATE and MINDATE are in capabilities lets take them
> out of CS properties.
> 
> >     RECUR-ACCEPTED: whether the CS accepts recurrence rules
> 
> >     RECUR-EXPAND : whether or not the CS supports the
> >                    expansion of recurrence rules.
> 
> >     RECUR-LIMIT: the maximum number of occurrences or a recurrence
> >                  rule that are expanded by the CS
> 
> Move the above 4 properties into capabilities? As they
> are will effect what commands the CUA sends to the CS.
> 
> >     VERSION: iCalendar version
> 
> Move it to CAP-VERSION and make it a capability?
> I think we agreed that it is CAP version 1.0 which is unrelated
> to iCalendar version.

  There is already a version that is returned by capability.

  I'll remove the VERSION from the calstore.

> 
> The CAPABILITIES section should specify the iCalendar and
> iTIP version that are supported in addition to the CAP-VERSION.

  Yes.

> 
> AND:
> 
>  We drop DEFAULT-VARS from the calendar properties, it only
>  applied to CALSTORE -  correct?

Yes.