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

From: George Babics <[email-masked]>
Date: Tue, 12 Feb 2002 17:15:32 -0500

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:

    ALLOW-CONFLICT: whether conflicts are allowed in the agenda
    CALSCALE: default calendar scale used (e.g. Gregorian)
    CHARSET: default character set
    CREATED: the time the VAGENDA was created
    LOCALE: the default language
    LAST-MODIFIED: the last time the VAGENDA was modified
    NAME: the name of the calendar (e.g., "Work")
    OWNER: the users that own the calendar
    RELATED-TO: other VAGENDAs that are linked to this one
    RELCALID: identifier for the VAGENDA
    TOMBSTONE: whether the VAGENDA is marked as deleted or not

  The CALSTORE component is used to contain the properties of
  the calendar store. These properties are:

    CALMASTER: e-mail address of the calendar administrator
    CSID: unique identifier for the CALSTORE
    CURRENT-DATETIME: the current date and time on the CS
    DEFAULT-VCARS: default access rights
    MAXDATE: last date time that is supported by the CWS
    MINDATE: first date-time that is supported by the CS
    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
    VERSION: iCalendar version

    Note that some of the above properties are not defined here
    since they are defined in iCalendar. The only exception is
    the "NAME" property that is defined in the VCAR proposal.

The following should be modified in the CAP draft due
to these definitions:

  - These definitions should appear in section 11 "Extensions To iCalendar"
  - Section 10 should be removed since they are its contents are 
    contained within these definitions and the restriction tables for
    the various commands.
  - The following properties should be added to the restriction tables that refer
    to VAGENDA: ALLOW-CONFLICT, CALSCALE, CREATED, DEFAULT-VCARS, LOCALE,
    LAST-MODIFIED, RELATED-TO, TOMBSTONE, CHARSET
  - The following should be removed from the VAGENDA section of the restriction
    tables: CALMASTER. It is not a VAGENDA property.
  - Simplify the definition of UPN in section 1.3 since a formal
    definition is supplied here.

The following have been changed vis-a-vis the CAP draft:

  - Renamed VAGENDA property LANGUAGE to LOCALE since LANGUAGE
    is defined as a parameter in RFC 2445.
  - Removed the CHILD and PARENT properties from VAGENDA, since
    the list seems to be in favour of using RELATED-TO instead.
  - Added TZID to CALSTORE since it is needed if a local time
    is specified for CURRENT-DATETIME
  - Refer to RFC 2822 rather than RFC 822, since the latter has
    been obsoloted by the former.

Open Issues:
  
  - Should OWNER be a multi-valued property, or should it be
    single valued and allowed to occur more than once.
    If the latter than we can easily add parameters if they
    are needed in the future, e.g,
      OWNER;TYPE=MAIN:cap:[email-masked]
  - Should the calendar store component be CALSTORE or
    VCALSTORE.
  - Should the CHARSET property become DEFAULT-CHARSET and
    should we instead define a charset value type?
  - Do the RECUR-EXPAND and RECUR-LIMIT properties still make sense
    given the recent changed to VQUERY?
  - We still need to decide what type of characters are valid for
    RELCALID. We should comply with RFC 2396 (URI Generic Syntax)
   (See section 2, URI Characters and Escape Sequences).
  - What should be the name of the property used to specify the
    default language for a calendar: LANGUAGE, DEFAULT-LANGUAGE,
    LOCALE?
  - Should we use METHOD:DELETE instead of the TOMBSTONE property
    to indicate whether a VAGENDA has been marked as deleted?
  - Do we need a limit for bonded recurrences? RECUR-LIMIT only applies
    to unbounded recurrences.
  - According to the definition of VERSION in iCalendar, VERSION MUST
    appear once in a VCALENDAR. The VERSION in CALSTORE is slightly
    different, in that it defines the version of iCalendar user in
    the calendar store, and not the version of an iCalendar. Furthermore,
    by adding a version to CALSTORE we may have:

    BEGIN:VCALENDAR
    VERSION:2.0
    ...
    BEGIN:CALSTORE
    VERSION:2.0
    ...
    END:CALSTORE
    END:VCALENDAR

    Which is inconsistent with the RFC 2445 definition:

      Conformance: This property MUST be specified by an iCalendar object,
      but MUST only be specified once.

   Perhaps we should use ICALENDAR-VERSION?

   However, if CALSTORE is contained in a VCALENDAR, then CALSTORE
   doesn't need a VERSION at all?

===============================================================================

Proposed new text in CAP:

x.x Property Value Data Types

x.x.1 UPN

   To: [email-masked]

   Subject: Registration of text/calendar MIME value type UPN

   Value Name: UPN

   Purpose: This value type is used to identify values that contain
   user principal name of CU or group of CU.

   Formal Definition: The value type is defined by the following
   notation:

     upn        = "@" /
                  [ dot-atom-text ] "@" dot-atom-text

                  ; dot-atom-text is defined in RFC 2822

   Description: This data type is an identifier that denotes a
   CU or a group of CU. A UPN is a RFC 2822 compliant e-mail address,
   with exceptions listed below, and in most cases it is deliverable
   to the CU. In some cases it is identical to the CU's well known
   email address.  A CU's UPN MUST never be an e-mail address that is
   deliverable to a different person as there is no requirement that
   a person's UPN must be his e-mail address.

   In certain cases a UPN will not be RFC 2822 compliant.  When
   anonymous authentication is used, or anonymous authorization is
   being defined, the special UPN "@" will be used.  When
   authentication must be used, but unique identity must be
   obscured, a UPN of the form @DNS-domain-name may be used.

   Example:
   
     The following is a UPN for a CU:

       [email-masked]

     The following is a UPN for a group of CU:

       [email-masked]

     The following is a UPN for an anonymous CU belonging to
     a specific realm:
 
       @acme.com

     The following is a UPN for an anonymous CU:

       @

x.2 Component Properties

x.2.1 Agenda Component Properties

x.2.1.1 Allow-Conflict Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property ALLOW-CONFLICT

   Property Name: ALLOW-CONFLICT

   Purpose: This property indicates whether or not the calendar
   supports event conflicts. That is, whether or not any of the
   events in the calendar can overlap.

   Value Type: BOOLEAN

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VAGENDA" calendar
   components.

   Description: In a "VAGENDA", this property is used to indicate
   whether events may conflict. If it has a value of TRUE, then
   conflicts are allowed. If FALSE, the no two events may conflict.
   If not specified, the default is TRUE.

   Format Definition: The property is defined by the following notation:

     allow-conflict     = "ALLOW-CONFLICT" allowconflictparam ":" boolean CRLF

     allowconflictvalue  = *(";" xparam)

   Example: The following is an example of this property for a "VAGENDA"
   calendar component:

     ALLOW-CONFLICT:FALSE

x.2.1.2 Charset Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property CHARSET

   Property Name: CHARSET

   Purpose: This property indicates the default charset for localized
   strings.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VAGENDA" calendar
   components.

   Description: In a "VAGENDA", this property is used to indicate the
   charset of the localized strings of all its components. If not
   specified, the default is UTF-8. The value MUST be an IANA registered
   character set as defined in [RFC 2278].

   Format Definition: The property is defined by the following notation:

     charset     = "CHARSET" charsetparam ":" text CRLF

     charsetparam  = *(";" xparam)

   Example: The following is an example of this property for a "VAGENDA"
   calendar component:

     CHARSET:Shift_JIS

x.2.1.3 Locale Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property LOCALE

   Property Name: LOCALE

   Purpose: This property specifies the default language for text values.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VAGENDA" calendar
   components.

   Description: In a "VAGENDA", this property is used to indicate
   the default language for text values in the components, e.g.,
   "VEVENT", of the "VAGENDA."

   Format Definition: The property is defined by the following notation:

     locale     = "LOCALE" localeparam ":" language CRLF

     localeparam  = *(";" xparam)

     locale = <Text identifying a language, as defined in [RFC 3066]>

   Example: The following is an example of this property:

     LOCALE:da

x.2.1.4 Owner Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property OWNER

   Property Name: OWNER

   Purpose: The property specifies an owner of a calendar.

   Value Type: UPN

   Property Parameters: Non-standard, alternate text representation and
   language property parameters can be specified on this property.

   Conformance: The property MUST be specified at in a "VAGENDA" component.

   Description: A multi-instanced property indicating the calendar owner.

   Format Definition: The property is defined by the following notation:

     owner = "OWNER" ownerparam ":" upn CRLF

     ownerparam = *(";" xparam)

   Example: The following is an example of this property:

   OWNER:[email-masked]
   OWNER:[email-masked]

x.2.1.5 Relative Calendar Identifier Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property RELCALID
 
   Property Name: RELCALID

   Purpose: The property specifies an identifier for a "VAGENDA." It must be
   unique within the CS.

   Value Type: URI

   Property Parameters: Non-standard, alternate text representation and
   language property parameters can be specified on this property.

   Conformance: The property MUST be specified in a "VAGENDA" component.

   Description: The parameter value MUST be a UTF-8 string. It MUST NOT
   be empty.

   [EDITORS NOTE: the actual format of the string has not been defined
   yet. In cap 06 it is made out of 7 bit printable characters. People
   suggested it be a utf-8 string. It is an issue being looked at by Pat
   or Steve. See the issues list.]

   Format Definition: The property is defined by the following notation:

     recalid = "RELCALID" recalidparam ":" uri CRLF

     recalidparam = *(";" xparam)

   Example: The following is an example of this property:

   RELCALID:hjik123A001

x.2.1.6 Tombstone Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property TOMBSTONE

   Property Name: TOMBSTONE

   Purpose: This property indicates whether or not the calendar
   has been marked as deleted.

   Value Type: BOOLEAN

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VAGENDA" calendar
   components.

   Description: When this property is TRUE it indicates that the
   calendar component has been marked as deleted. If FALSE, then
   it indicates that the calendar component has not been marked as
   deleted. The default value is FALSE.

   Format Definition: The property is defined by the following notation:

     tombstone     = "TOMBSTONE" tombstoneparam ":" boolean CRLF

     tombstoneparam  = *(";" xparam)

   Example: The following is an example of this property:

     TOMBSTONE:FALSE

x.2.2 Calendar Store Component Properties

x.2.1.1 Calmaster Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property CALMASTER
 
   Property Name: CALMASTER

   Purpose: The property specifies an e-mail address of a person responsible
   for the calendar store.

   Value Type: URI

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property can be specified in a "CALSTORE" component.

   Description: The parameter value MUST be a MAILTO URI as defined in [RFC
   1738].

   Format Definition: The property is defined by the following notation:

     calmaster = "CALMASTER" calmasterparam ":" uri CRLF

     calmasterparam = *(";" xparam)

     uri = <as defined by RFC 2445>

   Example: The following is an example of this property:

   CALMASTER:mailto:[email-masked]

x.2.1.2 Calendar Store Identifier Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property CSID

   Property Name: CSID

   Purpose: The property specifies a the globally unique identifier
   for the calendar store.

   Value Type: URI

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property can be specified in a "CALSTORE" component.

   Description: The identifier MUST be globally unique. If not specified,
   it is the same as the hostname.

   Format Definition: The property is defined by the following notation:

     csid = "CSID" csid ":" uri CRLF

     csid = *(";" xparam)

   Example: The following is an example of this property:

   CSID:cap://calendar.acme.com

x.2.1.3 Current Date-Time Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property CURRENT-DATETIME

   Property Name: CURRENT-DATETIME

   Purpose: This property specifies the current time of the CS.

   Value Type: DATE-TIME

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property MUST be specified once in "CALSTORE".

   Description: The date and time MAY be a local time.

   Format Definition: The property is defined by the following notation:

     current-datetime    = "CURRENT-DATETIME" current-datetimeparam ":" date-time CRLF

     current-datetimeparam  = *(";" xparam)

   Example: The following is an example of this property:

     CURRENT-DATETIME;TZID=US-Eastern:20020210T165547

x.2.1.4 Default Access Rights Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property DEFAULT-VCARS

   Property Name: DEFAULT-VCARS

   Purpose: This property is used to specify the CARID of the
   default VCAR components for newly created VAGENDA components.

   Value Type: TEXT

   Property Parameters: Only non-standard property parameters can be
   specified on this property.

   Conformance: This property MUST be specified in "CALSTORE" calendar
   components and MUST at least specify the following values:
   READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER.

   Description: This property is used in the "CALSTORE" calendar
   component to specify the CARID of the VCAR components that
   must be copied in VAGENDA at creation time.

   Format Definition: The property is defined by the following notation:

     def-vcars      = "DEFAULT-VCARS" def-vcarsparam ":" text
                     *( "," text ) CRLF

     def-vcarsparam = *( ";" xparam )

   Example: The following is an example of this property:

     DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY
     DEFAULT-VCARS:UPDATEPARTSTATUS,DEFAULTOWNER

x.2.1.5 Maximum Date Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property MAXDATE

   Property Name: MAXDATE

   Purpose: This property specifies the date/time in the future
   beyond which the server cannot represent.

   Value Type: DATE-TIME

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property can be specified once in "CALSTORE".

   Description: The date and time MUST be a UTC value. If not specified,
   then 99991231T235959Z will be assumed.

   Format Definition: The property is defined by the following notation:

     maxdate    = "MAXDATE" maxdateparam ":" date-time CRLF

     maxdateparam  = *(";" xparam)

   Example: The following is an example of this property:

     MAXDATE:20990101T000000Z

x.2.1.6 Minimum Date Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property MINDATE

   Property Name: MINDATE

   Purpose: This property specifies the date/time in the past prior
   to which the server cannot represent.

   Value Type: DATE-TIME

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property can be specified once in "CALSTORE".

   Description: The date and time MUST be a UTC value. If not specified,
   then 00000101T000000Z will be assumed.

   Format Definition: The property is defined by the following notation:

     mindate    = "MINDATE" mindateparam ":" date-time CRLF

     mindateparam  = *(";" xparam)

   Example: The following is an example of this property:

     MINDATE:19710101T000000Z

x.2.1.7 Recurrences Accepted Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property RECUR-ACCEPTED

   Property Name: RECUR-ACCEPTED

   Purpose: This property indicates whether or not the calendar
   store accepts recurrence rule.

   Value Type: BOOLEAN

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "CALSTORE" calendar
   components.

   Description: Boolean value will be set to TRUE if the server will accept
   recurrence rules. It will be set to FALSE if the server will not accept
   recurrence rules. The default is TRUE.

   Format Definition: The property is defined by the following notation:

     recur-accepted     = "RECUR-ACCEPTED" recur-acceptedparam ":" boolean CRLF

     recur-acceptedparam  = *(";" xparam)

   Example: The following is an example of this property:

     RECUR-ACCEPTED:FALSE

x.2.1.8 Recurrences Expand Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property RECUR-EXPAND

   Property Name: RECUR-EXPAND

   Purpose: This property indicates whether or not the CS supports the
   expansion of recurrence rules.

   Value Type: BOOLEAN

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "CALSTORE" calendar
   components.

   Description: If set to TRUE, the CS supports the expansion of recurrence
   rules. If set to FALSE, the CS is incapable of expanding recurrence rules.
   The default is TRUE.

   Format Definition: The property is defined by the following notation:

     recur-expand     = "RECUR-EXPAND" recur-expandparam ":" boolean CRLF

     recur-expandparam  = *(";" xparam)

   Example: The following is an example of this property:

     RECUR-EXPAND:FALSE

x.2.1.9 Recurences Limit Component Property

   To: [email-masked]

   Subject: Registration of text/calendar MIME property RECUR-LIMIT

   Property Name: RECUR-LIMIT

   Purpose: This property describes how the CS handles unbounded recurrences.

   Value Type: INTEGER

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "CALSTORE" calendar
   components.

   Description: This numeric value describes how the CS handles
   unbounded recurrences. The value is only valid if RECURRENCE is TRUE. If
   the value is 0 it means that the server supports unbounded recurrence rules.
   If it is non-zero, it is a positive integer indicating the number of
   instances that will be created when the server expands an unbounded recurrence
   rule when fetched from the CS. A CUA MUST query for date ranges when this value
   is zero.

   Format Definition: The property is defined by the following notation:

     recur-limit     = "RECUR-LIMIT" recur-limitexpand ":" boolean CRLF

     recur-limitexpand  = *(";" xparam)

   Example: The following is an example of this property:

     RECUR-LIMIT:100

x.x.2 Calendar Components

x.x.2.1 Agenda Component

   To: [email-masked]

   Subject: Registration of text/calendar MIME component VAGENDA

   Component Name: VAGENDA

   Purpose: Provide a grouping of component properties that defines an
   agenda.

   Formal Definition: A "VAGENDA" calendar component is defined by the
   following notation:

     agendac     = "BEGIN" ":" "VAGENDA" CRLF
                    agendaprop
                   "END" ":" "VAGENDA" CRLF

     agendaprop  = *(
                     ; the following MUST occur exactly once

                     created / owner / recalid / last-mod /

                     ; the following are optional,
                     ; but MUST NOT occur more than once

                     allow-conflict / calscale / charset / locale /
                     tombstone / 

                     ; the following are optional,
                     ; and MAY occur more than once

                     name / iana-token / x-prop
                    )

x.x.2.2 Calendar Store Component

   To: [email-masked]

   Subject: Registration of text/calendar MIME component CALSTORE

   Component Name: CALSTORE

   Purpose: Provide a grouping of component properties that defines a
   calendar store.

   Formal Definition: A "CALSTORE" calendar component is defined by the
   following notation:

     calstorec     = "BEGIN" ":" "CALSTORE" CRLF
                     calstoreprop
                     "END" ":" "CALSTORE" CRLF

     calstoreprop  = *(
                       ; the following MUST occur exactly once

                       calmaster / current-datetime / version /

                       ; the following must occur at least once

                       default-vcar /

                       ; the following are optional,
                       ; but MUST NOT occur more than once

                       maxdate / mindate / recur-accepted / recur-expand /
                       recur-limit / csid /

                       ; the following are optional,
                       ; and MAY occur more than once

                       related / iana-token / x-prop
                      )

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 16:35:20 -0700

George Babics wrote:

I broke your text into multiple replies.

>    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.

  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.

>     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?

>     MINDATE: first date-time that is supported by the CS

MAXDATE and MINDATE are in capabilities lets take them
out of CS properties.

>                  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.

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

AND:

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

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 16:57:45 -0700

>       OWNER;TYPE=MAIN:cap:[email-masked]

I agree - multi instance.

>   - Should the calendar store component be CALSTORE or

I noticed in 2445, it says that ALL iCalendar objects
start with a 'V', so I guess we should do that.

>     should we instead define a charset value type?

Yes I agree - DEFAULT-CHARSET is a better choice for a name.

Yes I agree - we do need to specify what the format is, I am sure
that some RFC covers that.

AND: And I think that a charset-list should be returned in
the capabilities reply  - with the first one being the default 
for the CS and any other being what the CS supports.

>     given the recent changed to VQUERY?

I think they should be capabilities.

AND: we need to re-add expansion limits to VQUERY, what
if something goes on forever - how many will EXPAND:TRUE 
with NO date time limit return with out it?

>     RELCALID. We should comply with RFC 2396 (URI Generic Syntax)

Yes - and say that RELCALID MUST BE 8 bit capable so that
when URI's are 8-bit we will not require any changes.

>     default language for a calendar: LANGUAGE, DEFAULT-LANGUAGE,

I would opt for DEFAULT-LOCALE. It's not LANGUAGE, its the locale.
or maybe LOCALE.

And making the BEEP 'localize' attribute sent in the BEEP greeting RPY
a MUST in the CAP greeting so CUA can select the locale for
any CS error messages.

>     to indicate whether a VAGENDA has been marked as deleted?

Yes - I agree.

>     to unbounded recurrences.

A CUA reading on a TCP connection is not forced to read
more that it wants. If you get too much. Stop reading and throw
away the rest - or/and abort the command using a separate channel.

We need a limit in the VQUERY so that unbounded recurrence
rules don't go on for ever. A CUA might not know in advance
if "SELECT * FROM VEVENT" with EXPAND:TRUE has any recurrence
rules set - so we need to allow the CUA to bound the number
of replies.

>     by adding a version to CALSTORE we may have:

The 2445 VERSION is the version of the 2445 record format, is not
the VERSION of iTIP or CAP.

Do we mandate it as part of ANY query reply - so the CUA knows
that the data coming back conforms to iCalendar 2.0 record format?

>    Perhaps we should use ICALENDAR-VERSION?

How about CAP-VERSION as it is the VERSION of the CAP protocol.
And lets move it from a property to a capability.

>    doesn't need a VERSION at all?

Again - CAP protocol version vs iCalendar record format.

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 17:07:06 -0700

>    Conformance: This property can be specified in "VAGENDA" calendar

Components or component?

>    conflicts are allowed. If FALSE, the no two events may conflict.

... If FALSE, then ... (not 'the')

And how about replace:

	If FALSE, then no two events may conflict

With:
	If FALSE, then no two components or their expanded
        instances can share the same time or overlap the same
        time periods.

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 17:17:15 -0700

>    Conformance: This property can be specified in "VAGENDA" calendar

Again, components or component?

>    character set as defined in [RFC 2278].

Dilemma: How do you know the charset the reply that includes
CHARSET is going to come back in? Example, the default charset
for a calendar is X, then how can you read X if you don't know
that X is described in the X charset?

Proposal - We add this to the VQUERY notes:

   When querying for only the CHARSET property and nothing else,
   the results MUST be returned in the UTF-8 charset as in
   the following example:

        TARGET:relcalid
 	QUERY:SELECT CHARSET FROM VAGENDA

   When querying and CHARSET is one of at least one more
   property, then the CHARSET is returned in the CHARSET charset
   as shown by the following example:

       TARGET:relcalid
       QUERY:SELECT * FROM VAGENDA

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 17:24:32 -0700

>    Conformance: This property can be specified in "VAGENDA" calendar

Component not components.

>      locale = <Text identifying a language, as defined in [RFC 3066]>

Add (IANA values are 3-8 characters per 3066)?

  And the preferred values are the ones  that include both
  the language and country.

>      LOCALE:da

Change to (or some other 3 to 8 letter IANA registered value:

	LOCALE:fr_CA

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 17:32:32 -0700

>    it is the same as the hostname.

I think we need to add the same 8-bit note here, so that
when there are 8-bit URIs, we don't have to add anything.

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 17:35:30 -0700

> x.2.1.3 Current Date-Time Component Property

I again propose that we drop this from CAP and make
it part of the capability reply and that it must
be in UTC and it MUST be supplied.

	<current-date-time>20020212T173455Z</current-date-time>

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 17:42:17 -0700

>    must be copied in VAGENDA at creation time.

Add:
  And as CARIDs may contain spaces, those values must be
  wrapped in quotes.

>      DEFAULT-VCARS:UPDATEPARTSTATUS,DEFAULTOWNER

Add something like:

       DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY
        ,UPDATEPARTSTATUS,DEFAULTOWNER,"My Private CARID"

---

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

Add:

			x-component

---

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

George Babics wrote:

I propose all of these be dropped as properties and
moved into categories - as they effect what the CUA
will send on the wire to the CS and reduce the chattiness
of the protocol by not having to do both a get-capabilities
and query.

---

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

George Babics wrote:

Add:

			vcar

Do we want to add:

			x-component

---

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

> start with a 'V', so I guess we should do that.

I also think that we should call it VCALSTORE, but
on the other hand, it should be noted that RFC 2445
also defines two components that don't start with 'V'.

  >   standardc  = "BEGIN" ":" "STANDARD" CRLF
  >                tzprop
  >                "END" ":" "STANDARD" CRLF
  >
  >   daylightc  = "BEGIN" ":" "DAYLIGHT" CRLF
  >                tzprop
  >                "END" ":" "DAYLIGHT" CRLF

Are these not considered "calendar components"?
The reason I'm asking is that I might have to
rename "VRIGHT" to "RIGHT".

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, 12 Feb 2002 19:09:47 -0700

> also defines two components that don't start with 'V'.

:-)

> rename "VRIGHT" to "RIGHT".

I think that those were a mistake. 

Ether way - not a big issue - that name that is.

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 10:22:51 -0500

>    - 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.

> so that CUAs know what is meant when 'localtime' date-time values

  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 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.

> I think we agreed that it is CAP version 1.0 which is unrelated

  There is already a version that is returned by capability.

  I'll remove the VERSION from the calstore.

> iTIP version that are supported in addition to the CAP-VERSION.

  Yes.

>  applied to CALSTORE -  correct?

Yes.

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 11:24:39 -0500

> I agree - multi instance.

I'll make the change.

> start with a 'V', so I guess we should do that.

I'll rename it.

> Yes I agree - DEFAULT-CHARSET is a better choice for a name.

  I'll rename it.

> for the CS and any other being what the CS supports.

  I agree.

> I think they should be capabilities.

  Yes, they should probably be capabilities.
    
> with NO date time limit return with out it?

  Doesn't RECUR-LIMIT also apply to VQUERY?
 
> >     to indicate whether a VAGENDA has been marked as deleted?

  I'll make the change.

> away the rest - or/and abort the command using a separate channel.

  However, the CS may also not want to expand all occurrences.
I believe the CS should be able to have limits to the number of
occurrences it expands. A good way to attack the CS would be for
a few CUA to create recurring events that occur every second for
the next 100 years, then to read the expanded events a few times.

 Perhaps RECUR-LIMIT should apply to both bounded and unbounded
recurrences?

> >    Perhaps we should use ICALENDAR-VERSION?

  The version is already part of the VCALENDAR object that is returned:

BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
...
END:VEVENT
END:VCALENDAR

  RFC 2445 states that the VERSION and PRODID must occur exactly
once. However, most of our examples are missing them. From RFC 2445:

  An iCalendar object MUST include the "PRODID" and "VERSION" calendar
  properties. In addition, it MUST include at least one calendar
  component.

> Again - CAP protocol version vs iCalendar record format.

The iCalendar, iTIP, and CAP versions are already returned by the capability
command.

I'll remove VERSION from the calendar store component.

George

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 11:28:10 -0500

> George Babics wrote:
[snip]

> a MUST in the CAP greeting so CUA can select the locale for

From an earlier post that I made:

  On second thought, I am not sure if we should use
  LOCALE. RFC 2277, "IETF Policy on Character Sets and Languages",
  uses the POSIX definition of locale:

     The POSIX standard [POSIX] defines a concept called a "locale", which
     includes a lot of information about collating order for sorting, date
     format, currency format and so on.

   I do not think this is what we want to mean by LOCALE.

   The concept of language in RFC 2277 seems to fit what we want
   this property to mean.

   Given all this, how about using DEFAULT-LANGUAGE?

   But then, BEEP seems to use the "localize" attribute means language,
   so perhaps LOCALE is OK?

What is our DEFAULT-LOCALE supposed to mean? Default language" Default language
and some other localized settings?

George

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 11:35:39 -0500

> >    Conformance: This property can be specified in "VAGENDA" calendar

Fixed all of them.

> ... If FALSE, then ... (not 'the')

Fixed.

>         instances can share the same time or overlap the same

Is this not implied by "no two events may conflict"?

George

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 11:39:23 -0500

>   the language and country.

Done.

> Change to (or some other 3 to 8 letter IANA registered value:

Done.

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Feb 2002 09:47:06 -0700

> without a timzone, e.g., 20020213T100000.

Yes that is what I meant - thanks.

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 11:55:46 -0500

>   And as CARIDs may contain spaces, those values must be

  I don't think so. Spaces are valid values for "text." For instance,
CATEGORIES is defined as a multi-valued property, each value of type
"text." From RFC 2445, this is a valid CATEGORY:

  CATEGORIES:BUSINESS,HUMAN RESOURCES

>         ,UPDATEPARTSTATUS,DEFAULTOWNER,"My Private CARID"

It can be:

  DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY
  ,UPDATEPARTSTATUS,DEFAULTOWNER,My Private CARID

George

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 11:57:23 -0500

I agree. They should be moved into the capabilities.

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 12:09:01 -0500

> >                        related / iana-token / x-prop

Why?

Done.

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 12:07:03 -0500

Added.

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Feb 2002 10:18:36 -0700

>   Doesn't RECUR-LIMIT also apply to VQUERY?

I think they are the sam thing?
Or are they different?

>  Perhaps RECUR-LIMIT should apply to both bounded and unbounded

Yes -I agree.

>   properties. In addition, it MUST include at least one calendar

Okay - I am really lost :-)

Was your point that we need to add it to all query replies?
(That is what I thought you meant)

Or that we need to add it as a property (or capability)?

---

From: George Babics <[email-masked]>
Date: Wed, 13 Feb 2002 12:29:15 -0500

> Or that we need to add it as a property (or capability)?

 I was simply saying that the version of iCalendar used
in each object is already returned in every VCALENDAR,
since it is a requirement in RFC 2445. 
(Also the examples in CAP are missing the PRODID and VERSION
in the VCALENDARs.)

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Feb 2002 11:08:45 -0700

>    I do not think this is what we want to mean by LOCALE.

I thought that fr_CA is a locale, and depending on if you apply
in in your POSIX program (On my system the POSIX 'LC' values
are set to):

LANG=en_US

LC_CTYPE="en_US"	Character classification and case conversion.

LC_NUMERIC="en_US"	Non-monetary numeric formats.

LC_TIME="en_US"		Date and time formats.

LC_COLLATE="en_US"	Collation order.

LC_MONETARY="en_US"	Monetary formats.

LC_MESSAGES="en_US"	Formats of informative and diagnostic
			messages and interactive responses.

LC_ALL="en_US"

A CS would ignore LC_TIME for DATE, TIME, and DATE-TIME
property values. But a locale aware CS could be smart
about error messages, time and data 'messages', and so on.

So if we return the 'locale' then an application program can
decide which or how the POSIX locale issues to apply
to the command.

[the terms 'full' and 'partial' I made up here because I 
 did not know what to call them]

The full locale could be (per 2277):

	en_US.iso-8859-1

I  think that CAP needs to use SHOULD and encourage implementations
to return the full locale as first choice, partial locale (no charset)
as a second choice, just the language as a third choice and per
2277 if not defined, the default locale is 'POSIX' (aka 'C' or
english).

BEEP 'localize' only supports the partial locale ("en_US" and no
charset)
as the charset would be in the MIME header for the data.

As I have pointed out in a separate email, I think we do need
to specify the partial locale at least so that when the CS
sorts strings it can set LC_COLLATE to the supplied (or calendar
default) locale for that query and the CU sees the results
sorted in a way that makes sense to the CU.

So I propose:

	We use LOCALE as defined in 2277 and encourage implementations
	to supply as much of the locale information as available
	for the CU to get the desired result.

	Any CUA or CS that does not fully support locales simply
	does not return them in the 'localize' attribute of
	the BEEP greeting reply. And a CUA can only expect a CS
	to support a locale if it is supplied in the 'localize'
	attribute.

(and per 2277 - if we have not yet)

	The default and minimum locale is POSIX if not supplied
        in the UTF-8 charset as defined in RFC-2277.

>    But then, BEEP seems to use the "localize" attribute means language,

The BEEP localize is a RFC-3066 value which seems
to be a partial locale - and does not include charset.

> What is our DEFAULT-LOCALE supposed to mean? Default language"
> Default language and some other localized settings?

I think it had existed for one reason - to allow the CS
to localize the error messages.

I would like to also use it for LC_COLLATE when the CS sorts
by strings.

And I really don't care if we call it 'FOO' as long as
the definition is clear.

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Feb 2002 11:12:46 -0700

> Is this not implied by "no two events may conflict"?

Two points:

	(1) 'events' implied VEVENT to me.

	(2) I just was not clear from reading the text if
            it meant expanded or not. (You and I know what
            it means, but it did not say that).

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Feb 2002 11:18:18 -0700

>   ,UPDATEPARTSTATUS,DEFAULTOWNER,My Private CARID

As can:

   DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY
   ,UPDATEPARTSTATUS,DEFAULTOWNER,"My,Private CARID"

It is not my intent to encourage a comma in a value.
But between iCalendar, iTIP, iMIP and CAP; there does 
not seem to be many examples that show how multi-valued
data can sometimes contain commas, escaped characters,
or even includes the '\n' in a value.

For example, from the CAP text as it exists,
this is a valid CARID:

	CARID:"This, is a \n two line CARID"

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Feb 2002 11:21:10 -0700

> > >                        related / iana-token / x-prop

That is where the DEFAULT-VCARS are stored.
In the CALSTORE - correct?

---

From: George Babics <[email-masked]>
Date: Thu, 14 Feb 2002 09:40:46 -0500

>         (1) 'events' implied VEVENT to me.

  Do you mean that "Overlapped Booking" should apply to all
types of components? I think that the definitions should apply to
VEVENTs only and not to components as you had in your definition.
We do not want VEVENTs conflicting with VTODOs. Nor do we want
VTODOs conflicting with other VTODOs.

>             it means, but it did not say that).

  I took the text as is from version 06 of CAP. If we need to explain
that the components are expanded and what conflicts mean, we should do
so at the beginning of the definition.

> conflicts are allowed. If FALSE, the no two events may conflict.

  Then if we need to specify what conflicts mean and that the conflicts
apply to expansions, we should say something like:

   Description: In a "VAGENDA", this property is used to indicate
   whether events may conflict. That is, if their expanded
   instances may share the same time or overlap the same time periods.
   If it has a value of TRUE, then conflicts are allowed.  
   If FALSE, the no two events may conflict.

George

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Feb 2002 09:13:46 -0700

George Babics wrote:
> types of components?

Yes that was my belief.

> I think that the definitions should apply to

I think we are agreeing. So we should change the word
'events' to components?

My belief was that is was to never allow two things to
book the same time in the same calendar.

	VEVENT - rent the snowmobile at 10:am
	TODO   - change the oil in the snowmobile - at 10am

If it applied to all components, then one of them
would have never been booked.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 19 Feb 2002 11:20:03 -0500

> In the CALSTORE - correct?

The VCAR components stored in the VCALSTORE component specify
the access rights for the VCALSTORE itself.  For instance, a
VCAR component could specify whether users are granted the
right to create new VAGENDA components themselves or not.
The VCALSTORE MAY (MUST?) contain a copy of the DEFAULT-VCARS
but these VCAR components should not be confused with the actual
VCAR components that will be copied into newly created VAGENDA
components.

Where the DEFAULT-VCARS, that will be copied into newly
created VAGENDAs, are actually stored is an administration
issue.  Administration is out of scope.

Regards,
Bernard