tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4324

 
 
 

Calendar Access Protocol (CAP)

Part 2 of 5, p. 20 to 52
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
3.  CAP Design

3.1.  System Model

   The system model describes the high level components of a calendar
   system and how they interact with each other.

   CAP is used by a CUA to send commands to, and receive responses from,
   a CS.

   The CUA prepares a [MIME] encapsulated message, sends it to the CS,
   and receives a [MIME] encapsulated response.  The calendaring-related
   information within these messages are represented by iCalendar
   objects.  In addition, the "GET-CAPABILITY" command can be sent from
   the CS to the CUA.

   There are two distinct protocols in operation to accomplish this
   exchange.  [BEEP] is the transport protocol used to move these
   encapsulations between a CUA and a CS.  CAP's [BEEP] profile defines
   the application protocol that specifies the content and semantics of
   the messages sent between the CUA and the CS.

3.2.  Calendar Store Object Model

   [iCAL] describes components such as events, todos, alarms, and
   timezones.  CAP requires additional object infrastructure, in
   particular, detailed definitions of the containers for events and
   todos (calendars), access control objects, and a query language.

   The conceptual model for a calendar store is shown below.  The
   calendar store (VCALSTORE - Section 9.2) contains "VCAR"s, "VQUERY"s,
   "VTIMEZONE"s, "VAGENDA"s and calendar store properties.

   Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s,
   "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s, and calendar
   properties.

   The component "VCALSTORE" is used to denote the root of the calendar
   store and contains all of the calendars.

Top      Up      ToC       Page 21 
   Calendar Store

         VCALSTORE
         |
         +-- properties
         +-- VCARs
         +-- VQUERYs
         +-- VTIMEZONEs
         +-- VAGENDA
         |     |
         |     +--properties
         |     +--VEVENTs
         |     |    |
         |     |    +--VALARMs
         |     +--VTODOs
         |     |    |
         |     |    +--VALARMs
         |     +--VJOURNALs
         |     +--VCARs
         |     +--VTIMEZONEs
         |     +--VQUERYs
         |     +--VFREEBUSYs
         |     |
         |     |   ...
         .
         .
         +-- VAGENDA
         .     .
         .     .
         .     .

   Calendars within a Calendar Store are identified by their unique
   Relative CALID.

3.3.  Protocol Model

   CAP uses [BEEP] as the transport and authentication protocol.

   The initial charset MUST be UTF-8 for a session in an unknown locale.
   If the CS supplied the [BEEP] 'localize' attribute in the [BEEP]
   'greeting', then the CUA may tell the CS to switch locales for the
   session by issuing the "SET-LOCALE" CAP command and supplying one of
   the locales supplied by the [BEEP] 'localize' attribute.  If a locale
   is supplied, the first locale in the [BEEP] 'localize' attribute is
   the default locale of the CS.  The locale is switched only after a
   successful reply.

Top      Up      ToC       Page 22 
   The "DEFAULT-CHARSET" property of the CS contains the list of
   charsets supported by the CS with the first value being the default
   for new calendars.  If the CUA wishes to switch to one of those
   charsets for the session, the CUA issues the "SET-LOCALE" command.
   The CUA would have to first perform a "GET-CAPABILITY" command on the
   CS to get the list of charsets supported by the CS.  The charset is
   switched only after a successful reply.

   The CUA may switch locales and charsets as needed.  There is no
   requirement that a CS support multiple locales or charsets.

3.3.1.  Use of BEEP, MIME, and iCalendar

   CAP uses the [BEEP] application protocol over TCP.  Refer to [BEEP]
   and [BEEPTCP] for more information.  The default port on which the CS
   listens for connections is user port 1026.

   The [BEEP] data exchanged in CAP is a iCalendar MIME content that
   fully conforms to [iCAL] iCalendar format.

   This example tells the CS to generate and return 10 UIDs to be used
   by the CUA.  Note that throughout this memo, 'C:' refers to what the
   CUA sends, 'S:' refers to what the CS sends, 'I:' refers to what the
   initiator sends, and 'L:' refers to what the listener sends.  Here
   initiator and listener are used as defined in [BEEP].

      C: MSG 1 2 . 432 62
      C: Content-Type: text/calendar
      C:
      C: BEGIN:VCALENDAR
      C: VERSION:2.0
      C: PRODID:-//someone's prodid
      C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID
      C: END:VCALENDAR

   NOTE: The following examples will not include the [BEEP] header and
   footer information.  Only the iCalendar objects that are sent between
   the CUA and CS will be shown because the [BEEP] payload boundaries
   are independent of CAP.

   The commands listed below are used to manipulate or access the data
   on the calendar store:

   ABORT -  Sent to halt the processing of some of the commands.
      (Section 10.2)

   CONTINUE -  Sent to continue processing a command that has reached
      its specified timeout time.  (Section 10.3)

Top      Up      ToC       Page 23 
   CREATE -  Create a new object on the CS.  Initiated only by the CUA.
      (Section 10.4)

   SET-LOCALE -  Tell the CS to use any named locale and charset
      supplied.  Initiated by the CUA only.  (Section 10.13)

   DELETE -  Delete objects from the CS.  Initiated only by the CUA.
      Can also be used to mark an object for deletion.  (Section 10.5)

   GENERATE-UID -  Generate one or more unique ids.  Initiated only by
      the CUA.  (Section 10.6)

   GET-CAPABILITY - Query the capabilities of the other end point of the
      session.  (Section 10.7)

   IDENTIFY -  Set a new identity for the session.  Initiated only by
      the CUA.  (Section 10.8)

   MODIFY -  Modify components.  Initiated by the CUA only.  (Section
      10.9)

   MOVE -  Move components to another container.  Initiated only by the
      CUA.  (Section 10.10)

   REPLY -  When replying to a command, the "CMD" value will be set to
      "REPLY" so that it will not be confused with a new command.
      (Section 10.11)

   SEARCH -  Search for components.  Initiated only by the CUA.
      (Section 10.12)

   TIMEOUT -  Sent when a specified amount of time has lapsed and a
      command has not finished.  (Section 10.14)

4.  Security Model

   BEEP transport performs all session authentication.

4.1.  Calendar User and UPNs

   A CU is an entity that can be authenticated.  It is represented in
   CAP as a UPN, which is a key part of access rights.  The UPN
   representation is independent of the authentication mechanism used
   during a particular CUA/CS interaction.  This is because UPNs are
   used within VCARs.  If the UPN were dependent on the authentication
   mechanism, a VCAR could not be consistently evaluated.  A CU may use
   one mechanism while using one CUA, but the same CU may use a

Top      Up      ToC       Page 24 
   different authentication mechanism when using a different CUA, or
   while connecting from a different location.

   The user may also have multiple UPNs for various purposes.

   Note that the immutability of the user's UPN may be achieved by using
   SASL's authorization identity feature.  The transmitted authorization
   identity may be different than the identity in the client's
   authentication credentials [SASL, section 3].  This also permits a CU
   to authenticate using their own credentials, yet request the access
   privileges of the identity for which they are proxying SASL.  Also,
   the form of authentication identity supplied by a service like TLS
   may not correspond to the UPNs used to express a server's access
   rights, requiring a server-specific mapping to be done.  The method
   by which a server determines a UPN, based on the authentication
   credentials supplied by a client, is implementation-specific.  See
   [BEEP] for authentication details; [BEEP] relies on SASL.

4.1.1.  UPNs and Certificates

   When using X.509 certificates for purposes of CAP authentication, the
   UPN should appear in the certificate.  Unfortunately, there is no
   single correct guideline for which field should contain the UPN.

   Quoted from RFC-2459, section 4.1.2.6 (Subject):

         If subject naming information is present only in the
         subjectAlt-Name extension (e.g., a key bound only to an email
         address or URI), then the subject name MUST be an empty
         sequence and the subjectAltName extension MUST be critical.

         Implementations of this specification MAY use these comparison
         rules to process unfamiliar attribute types (i.e., for name
         chaining).  This allows implementations to process certificates
         with unfamiliar attributes in the subject name.

         In addition, legacy implementations exist where an RFC 2822
         name [RFC2822] is embedded in the subject distinguished name as
         an EmailAddress attribute.  The attribute value for
         EmailAddress is of type IA5String to permit inclusion of the
         character '@', which is not part of the PrintableString
         character set.  EmailAddress attribute values are not case
         sensitive (e.g., "fanfeedback@redsox.example.com" is the same
         as "FANFEEDBACK@REDSOX.EXAMPLE.COM").

         Conforming implementations generating new certificates with
         electronic mail addresses MUST use the rfc822Name in the
         subject alternative name field (see sec. 4.2.1.7 of [X509CRL])

Top      Up      ToC       Page 25 
         to describe such identities.  Simultaneous inclusion of the
         EmailAddress attribute in the subject distinguished name to
         support legacy implementations is deprecated but permitted.

   Since no single method of including the UPN in the certificate will
   work in all cases, CAP implementations MUST support the ability to
   configure what the mapping will be by the CS administrator.
   Implementations MAY support multiple mapping definitions, for
   example, the UPN may be found in either the subject alternative name
   field, or the UPN may be embedded in the subject distinguished name
   as an EmailAddress attribute.

   Note: If a CS or CUA is validating data received via [iMIP], if the
   "ORGANIZER" or "ATTENDEE" properties said, for example,
   "ATTENDEE;CN=Joe Random User:MAILTO:juser@example.com", then the
   email address should be checked against the UPN.  This is so the
   "ATTENDEE" property cannot be changed to something misleading like
   "ATTENDEE;CN=Joe Rictus User:MAILTO:jrictus@example.com" and have it
   pass validation.  Note that it is the email addresses that
   miscompare, the CN miscompare is irrelevant.

4.1.2.  Anonymous Users and Authentication

   Anonymous access is often desirable.  For example, an organization
   may publish calendar information that does not require any access
   control for viewing or login.  Conversely, a user may wish to view
   unrestricted calendar information without revealing their identity.

4.1.3.  User Groups

   A User Group is used to represent a collection of CUs or other UGs
   that can be referenced in VCARs.  A UG is represented in CAP as a
   UPN.  The CUA cannot distinguish between a UPN that represents a CU
   or a UG.

   UGs are expanded as necessary by the CS.  The CS MAY expand a UG
   (including nested UGs) to obtain a list of unique CUs.  Duplicate
   UPNs are filtered during expansion.

   How the UG expansion is maintained across commands is
   implementation-specific.  A UG may reference a static list of
   members, or it may represent a dynamic list.  Operations SHOULD
   recognize changes to UG membership.

   CAP does not define commands or methods for managing UGs.

Top      Up      ToC       Page 26 
4.2.  Access Rights

   Access rights are used to grant or deny access to calendars,
   components, properties, and parameters in a CS to a CU.  CAP defines
   a new component type called a Calendar Access Right (VCAR).
   Specifically, a "VCAR" component grants, or denies, UPNs the right to
   search and write components, properties, and parameters on calendars
   within a CS.

   The "VCAR" component model does not put any restriction on the
   sequence in which the object and access rights are created.  That is,
   an object associated with a particular "VCAR" component might be
   created before or after the actual "VCAR" component is defined.  In
   addition, the "VCAR" and "VEVENT" components might be created in the
   same iCalendar object and passed together in a single object.

   All rights MUST be denied unless specifically granted.

   If two rights specified in "VCAR" components are in conflict, the
   right that denies access always takes precedence over the right that
   grants access.  Any attempt to create a "VCAR" component that
   conflicts with a "VCAR" components with a "DECREED" property set to
   the "TRUE" value must fail.

4.2.1.  Access Control and NOCONFLICT

   The "TRANSP" property can take on values -- "TRANSPARENT-NOCONFLICT"
   and "OPAQUE-NOCONFLICT" -- that prohibit other components from
   overlapping it.  This setting overrides access.  The "ALLOW-CONFLICT"
   CS, Calendar or component setting may also prevent overlap, returning
   an error code "6.3".

4.2.2.  Predefined VCARs

   The predefined calendar access CARIDs that MUST be implemented are:

      CARID:READBUSYTIMEINFO -  Specifies the "GRANT" and "DENY" rules
         that allow UPNs to search "VFREEBUSY" components.  An example
         definition for this VCAR is:

            BEGIN:VCAR
            CARID:READBUSYTIMEINFO
            BEGIN:VRIGHT
            GRANT:*
            PERMISSION:SEARCH
            SCOPE:SELECT * FROM VFREEBUSY WHERE STATE() = 'BOOKED'
            END:VRIGHT
            END:VCAR

Top      Up      ToC       Page 27 
      CARID:REQUESTONLY -  Specifies the "GRANT" and "DENY" rules to
         UPNs other than the owner of the calendar and specifies the
         ability to write new objects with the "METHOD" property set to
         the "REQUEST" value.  This CARID allows the owner to specify
         which UPNs are allowed to make scheduling requests.  An example
         definition for this VCAR is:

            BEGIN:VCAR
            CARID:REQUESTONLY
            BEGIN:VRIGHT
            GRANT:NON CAL-OWNERS()
            PERMISSION:CREATE
            RESTRICTION:SELECT VEVENT FROM VAGENDA
                WHERE METHOD = 'REQUEST'
            RESTRICTION:SELECT VTODO FROM VAGEND
                WHERE METHOD = 'REQUEST'
            RESTRICTION:SELECT VJOURNAL FROM VAGEND
                WHERE METHOD = 'REQUEST'
            END:VRIGHT
            END:VCAR

      CARID:UPDATEPARTSTATUS -  Grants authenticated users the right to
         modify the instances of the "ATTENDEE" property set to one of
         their calendar addresses in any components for any booked
         component containing an "ATTENDEE" property.  This allows (or
         denies) a CU the ability to update their own participation
         status in a calendar where they might not otherwise have
         "MODIFY" command access.  They are not allowed to change the
         "ATTENDEE" property value.  An example definition for this VCAR
         (only affecting the "VEVENT" components) is:

            BEGIN:VCAR
            CARID:UPDATEPARTSTATUS
            BEGIN:VRIGHT
            GRANT:*
            PERMISSION:MODIFY
            SCOPE:SELECT ATTENDEE FROM VEVENT
             WHERE ATTENDEE = SELF()
             AND ORGANIZER = CURRENT-TARGET()
             AND STATE() = 'BOOKED'
            RESTRICTION:SELECT * FROM VEVENT
             WHERE ATTENDEE = SELF()
            END:VRIGHT
            END:VCAR

      CARID:DEFAULTOWNER -  Grants to any owner the permission they have
         for the target.  An example definition for this VCAR is:

Top      Up      ToC       Page 28 
            BEGIN:VCAR
            CARID:DEFAULTOWNER
            BEGIN:VRIGHT
            GRANT:CAL-OWNERS()
            PERMISSION:*
            SCOPE:SELECT * FROM VAGENDA
            END:VRIGHT
            END:VCAR

4.2.3.  Decreed VCARs

   A CS MAY choose to implement and allow persistent immutable VCARs
   that may be configured by the CS administrator.  A reply from the CS
   may dynamically create "VCAR" components that are decreed depending
   on the implementation.  To the CUA, any "VCAR" component with the
   "DECREED" property set to "TRUE" cannot be changed by the currently
   authenticated UPN, and, depending on the implementation and other
   "VCAR" components, might not be able to be changed by any UPN using
   CAP (never when the CUA gets a "DECREED:TRUE" VCAR).

   When a user attempts to modify or override a decreed "VCAR" component
   rules, an error will be returned indicating that the user has
   insufficient authorization to perform the operation.  The reply to
   the CUA MUST be the same as if a non-decreed VCAR caused the failure.

   The CAP protocol does not define the semantics used to initially
   create a decreed VCAR.  This administrative task is outside the scope
   of the CAP protocol.

   For example, an implementation or a CS administrator may wish to
   define a VCAR that will always allow the calendar owners to have full
   access to their own calendars.

   Decreed "VCAR" components MUST be readable by the calendar owner in
   standard "VCAR" component format.

4.3.  CAP Session Identity

   A [BEEP] session has an associated set of authentication credentials,
   from which is derived a UPN.  This UPN is the identity of the CAP
   session, and is used to determine access rights for the session.

   The CUA may change the identity of a CAP session by calling the
   "IDENTIFY" command.  The CS only permits the operation if the
   session's authentication credentials are good for the requested
   identity.  The method of checking this permission is implementation-
   dependent, but it may be thought of as a mapping from authentication
   credentials to UPNs.  The "IDENTIFY" command allows a single set of

Top      Up      ToC       Page 29 
   authentication credentials to choose from multiple identities, and
   allows multiple sets of authentication credentials to assume the same
   identity.

   For anonymous access, the identity of the session is "@".  A UPN with
   a null Username and null Realm is anonymous.  A UPN with a null
   Username but non-null Realm (e.g.,"@example.com") may be used to mean
   any identity from that Realm.  This is useful to grant access rights
   to all users in a given Realm.  A UPN with a non-null Username and
   null Realm (e.g., "bob@") could be a security risk and MUST NOT be
   used.

   Because the UPN includes Realm information, it may be used to govern
   calendar store access rights across Realms.  However, governing
   access rights across Realms is only useful if login access is
   available.  This could be done through a trusted server relationship
   or a temporary account.  Note that trusted server relationships are
   outside the scope of CAP.

   The "IDENTIFY" command also provides for a weak group implementation.
   By allowing multiple sets of authentication credentials belonging to
   different users to identify as the same UPN, that UPN essentially
   identifies a group of people, and may be used for group calendar
   ownership, or the granting of access rights to a group.

5.  CAP URL and Calendar Address

   The CAP URL scheme is used to designate both calendar stores and
   calendars accessible using the CAP protocol.

   The CAP URL scheme conforms to the generic URL syntax defined in RFC
   2396 and follows the Guidelines for URL Schemes set forth in RFC
   2718.

   A CAP URL begins with the protocol prefix "cap" and is defined by the
   following grammar.

      capurl   = "cap://" csidpart [ "/" relcalid ]
                      ;
      csidpart = hostport   ; As defined in Section 3.2.2 of RFC 2396
                            ;
      relcalid = *uric      ; As defined in Section 2 of RFC 2396

   A 'relcalid' is an identifier that uniquely identifies a calendar on
   a particular calendar store.  There is no implied structure in a
   Relative CALID (relcalid).  It may refer to the calendar of a user or
   of a resource such as a conference room.  It MUST be unique within
   the calendar store.

Top      Up      ToC       Page 30 
   Here are some examples:

      cap://cal.example.com
      cap://cal.example.com/Company/Holidays
      cap://cal.example.com/abcd1234Usr

   A 'relcalid' is permitted and is resolved according to the rules
   defined in Section 5 of RFC 2396.

   Examples of valid relative CAP URLs:

      opqaueXzz123String
      UserName/Personal

   Calendar addresses can be described as qualified or relative CAP
   URLs.

   For a user currently authenticated to the CS on cal.example.com,
   these two example calendar addresses refer to the same calendar:

      cap://cal.example.com/abcd1234USR
      abcd1234USR

6.  New Value Types

   The following sections contains new components, properties,
   parameters, and value definitions.

   The purpose of these is to extend the iCalendar objects in a
   compatible way so that existing iCalendar "VERSION" property "2.0"
   value parsers can still parse the objects without modification.

6.1.  Property Value Data Types

6.1.1.  CAL-QUERY Value Type

   Subject: Registration of text/calendar MIME value type CAL-QUERY

   Value Name: CAL-QUERY

   Value Type Purpose: This value type is used to identify values and
      contains query statements targeted at locating those values.  This
      is based on [SQL92] and [SQLCOM].

      1.  For the purpose of a query, all components should be handled
          as tables, and the properties of those components should be
          handled as columns.

Top      Up      ToC       Page 31 
      2.  All VAGENDAs and CSs look like tables for the purpose of a
          QUERY, and all of their properties look like columns in those
          tables.

      3.  You MUST NOT do any cross-component-type joins.  That means
          you can ONLY have one component OR one "VAGENDA" component OR
          one "VCALSTORE" component in the "FROM" clause.

      4.  Everything in the "SELECT" clause and "WHERE" clauses MUST be
          from the same component type or "VAGENDA" component OR
          "VCALSTORE" component in the "FROM" clause.

      5.  When multiple "QUERY" properties are supplied in a single
          "VQUERY" component, the results returned are the same as the
          results returned for multiple "VQUERY" components that each
          have a single "QUERY" property.

      6.  The '.' is used to separate the table name (component) and
          column name (property or component) when selecting a property
          that is contained inside a component that is targeted in the
          TARGET property.

      7.  A contained component without a '.' is not the same as
          "component-name.*".  If given as "component-name" (no dot),
          the encapsulating BEGIN/END statement will be supplied for
          "component-name".

   In the following example, '.' is used to separate the "TRIGGER"
   property from its contained component (VALARM), which is contained in
   any "VEVENT" component in the selected "TARGET" property value (a
   relcalid).  All "TRIGGER" properties in any "VEVENT" component in
   relcalid would be returned.

      TARGET:relcalid
      QUERY:SELECT VALARM.TRIGGER FROM VEVENT
      SELECT VALARM FROM VEVENT WHERE UID = "123"

   This returns one BEGIN/END "VALARM" component for each "VALARM"
   component in the matching "VEVENT" component.  As there is no '.'
   (dot) in the VALARM after the SELECT above, it returns:

Top      Up      ToC       Page 32 
      BEGIN:VALARM
      TRIGGER;RELATED=END:PT5M
      REPEAT:4
      ...
      END:VALARM
      BEGIN:VALARM
      TRIGGER;RELATED=START:PT5M
      DURATION:PT10M
      ...
      END:VALARM
      ...
      ...

  If the SELECT parameter is provided as "component-name.*", then only
  the properties and any contained components will be returned.  The
  example:

     SELECT VALARM.* FROM VEVENT WHERE UID = "123"

  will return all of the properties in each "VALARM" component in the
  matching "VEVENT" component:

      TRIGGER;RELATED=END:PT5M
      REPEAT:4
      ...
      TRIGGER;RELATED=START:PT5M
      DURATION:PT10M
      ...
      ...

  In the following SELECT clauses:

     (a) SELECT <a-property-name> FROM VEVENT

     (b) SELECT VALARM FROM VEVENT

     (c) SELECT VALARM.* FROM VEVENT

     (d) SELECT * FROM VEVENT

     (e) SELECT * FROM VEVENT WHERE
             VALARM.TRIGGER < '20020201T000000Z'
             AND VALARM.TRIGGER > '20020101T000000Z'

  Clause (a) elects all instances of <a-property-name> from all "VEVENT"
  components.

Top      Up      ToC       Page 33 
  Clauses (b) and (c) select all "VALARM" components from all "VEVENT"
  components. (b) would return them in BEGIN/END VALARM tags. (c) would
  return all of the properties without BEGIN/END VALARM tags.

  Clause (d) selects every property and every component that is in any
  "VEVENT" component, with each "VEVENT" component wrapped in a
  BEGIN/END VEVENT tags.

  Clause (e) selects all properties and all contained components in all
  "VEVENT" components that have a "VALARM" component with a "TRIGGER"
  property value between the provided dates and times, with each
  "VEVENT" component wrapped in BEGIN/END VEVENT tags.

   Here are two invalid SELECT clauses:

      (f) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT

      (g) SELECT DTSTART,UID FROM VEVENT
            WHERE VTODO.SUMMERY = "Fix typo in CAP"

   Clause (f) is invalid because it contains two '.' characters.

   Clause (g) Is invalid because it mixes VEVENT
   and VTODO properties in the same VQUERY.

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

     cal-query  = "SELECT"   SP   cap-val  SP
                  "FROM"     SP   comp-name SP
                  "WHERE"    SP   cap-expr

                / "SELECT" SP cap-cols SP
                  "FROM"   SP comp-name
                  ;
     cap-val    = cap-cols / param
                / ( cap-val "," cap-val )

                  ; NOTE: there is NO space around the "," on
                  ; the next line
     cap-cols   = cap-col / ( cap-cols "," cap-col)
                  / "*"
                  / "*.*" ; only valid when the target is a "VAGENDA"
                  ;
                  ; A 'cap-col' is:
                  ;
                  ; Any property name ('cap-prop') found in the
                  ; component named in the 'comp-name' used in the

Top      Up      ToC       Page 34 
                  ; "FROM" clause.
                  ;
                  ;   SELECT ORGANIZER FROM VEVENT ...
                  ;
                  ; OR
                  ;
                  ; A component name ('comp-name') of an existing
                  ; component contained inside of the 'comp-name'
                  ; used in the "FROM" clause.
                  ;
                  ;   SELECT VALARM FROM VEVENT ...
                  ;
                  ; OR
                  ;
                  ; A component name ('comp-name') of an existing
                  ; component contained inside of the 'comp-name' used
                  ; in the "FROM" clause followed by a property
                  ; name ('cap-prop') to be selected from that
                  ; component.
                  ; (comp-name "." cap-prop)

                  ;   SELECT VALARM.TRIGGER FROM VEVENT ...

     cap-col    = comp-name
                / comp-name "." cap-prop
                / cap-prop

     comp-name  = "VEVENT"  / "VTODO"     / "VJOURNAL" / "VFREEBUSY"
                / "VALARM"  / "DAYLIGHT"  / "STANDARD" / "VAGENDA"
                / "VCAR"    / "VCALSTORE" / "VQUERY"   / "VTIMEZONE"
                / "VRIGHT"  / x-comp    / iana-comp

     cap-prop   = ; A property that may be in the 'cap-comp' named
                  ; in the "SELECT" clause.

     cap-expr   = "(" cap-expr ")"
                / cap-term

     cap-term   = cap-expr SP cap-logical SP cap-expr
                / cap-factor

     cap-logical= "AND" / "OR"

     cap-factor = cap-colval SP cap-oper SP col-value
                / cap-colval SP "LIKE" SP col-value
                / cap-colval SP "NOT LIKE" SP col-value
                / cap-colval SP "IS NULL"
                / cap-colval SP "IS NOT NULL"

Top      Up      ToC       Page 35 
                / col-value SP "IN" cap-colval
                / col-value SP "NOT IN" cap-colval
                / "STATE()" "=" ( "BOOKED"
                                 / "UNPROCESSED"
                                 / "DELETED"
                                 / iana-state
                                 / x-state )
                  ;
     iana-state = ; Any state registered by IANA directly or
                  ; included in an RFC that may be applied to
                  ; the component and within the rules published.
                  ;
     x-state    = ; Any experimental state that starts with
                  ; "x-" or "X-".

     cap-colval = cap-col /  param
                  ;
     param      = "PARAM(" cap-col "," cap-param ")"
                  ;
     cap-param  = ; Any parameter that may be contained in the cap-col
                  ; in the supplied PARAM() function

     col-value  = col-literal
                / "SELF()"
                / "CAL-OWNERS()"
                / "CAL-OWNERS(" cal-address ")"
                / "CURRENT-TARGET()"
                   ;
     cal-address = ; A CALID as define by CAP
                   ;
     col-literal = "'" literal-data "'"
                   ;
     literal-data = ; Any data that matches the value type of the
                   ; column that is being compared.  That is, you
                   ; cannot compare PRIORITY to "some string" because
                   ; PRIORITY has a value type of integer.  If it is
                   ; not preceded by the LIKE element, any '%' and '_'
                   ; characters in the literal data are not treated as
                   ; wildcard characters and do not have to be
                   ; backslash-escaped.
                   ;
                   ; OR
                   ;
                   ; If the literal-data is preceded by the LIKE
                   ; element it may also contain the '%' and '_'
                   ; wildcard characters.  And, if the literal data
                   ; that is comparing contains any '%' or '_'
                   ; characters, they MUST be backslash-escaped as

Top      Up      ToC       Page 36 
                   ; described in the notes below, in order for them
                   ; not to be treated as wildcard characters.
                   ;
                   ; And, if the literal data contains any characters
                   ; that would have to be backslash-escaped if
                   ; a property or parameter value, then they must
                   ; be backslash-escaped in the literal-data.
                   ; Also, the quote character (') must be backslash
                   ; escaped.  Example:
                   ;
                   ; ... WHERE SUBJECT = 'It\'s time to ski'
                   ;
     cap-oper    = "="
                 / "!="
                 / "<"
                 / ">"
                 / "<="
                 / ">="
                   ;
     SP          = ; A single white space ASCII character
                   ; (value in HEX %x20).
                   ;
     x-comp      = ; As defined in [iCAL] section 4.6.
                   ;
     iana-comp   = ; As defined in [iCAL] section 4.6.

6.1.1.1.  [NOT] CAL-OWNERS()

   This function returns the list of "OWNER" properties for the named
   calendar when used in the "SELECT" clause.

   If called as 'CAL-OWNERS()', it is equivalent to the comma-separated
   list of all of the owners of the calendar that match the provided
   "TARGET" property value.  If the target is a "VCALSTORE", it returns
   the "CALMASTER" property.

   If called as 'CAL-OWNERS(cal-address)', then it is the equivalent to
   the comma-separated list of owners for the named calendar id.  If
   'cal-address' is a CS, it returns the "CALMASTER" property.

   If used in the "WHERE" clause, it returns true if the currently
   authenticated UPN is an owner of the currently selected object
   matched in the provided "TARGET" property.  Used in a CAL-QUERY
   "WHERE" clause and in the UPN-FILTER.

Top      Up      ToC       Page 37 
6.1.1.2.  CURRENT-TARGET()

   This is equivalent to the value of the "TARGET" property in the
   current command.  It is used in a CAL-QUERY "WHERE" clause.

6.1.1.3.  PARAM()

   This is used in a CAL-QUERY.  It returns or tests for the value of
   the named parameter from the named property.

6.1.1.3.1.  PARAM() in SELECT

   When used in a "SELECT" clause, it returns the entire property and
   all of that property's parameters; the result is not limited to the
   supplied parameter.  If the property does not contain the named
   parameter, then the property is not returned.  However, it could be
   returned as a result of another "SELECT" clause value.  If multiple
   properties of the supplied name have the named parameter, all
   properties with that named parameter are returned.  If multiple
   PARAM() clauses in a single "SELECT" CLAUSE match the same property,
   then the single matching property is returned only once.

   Also, note that many parameters have default values defined in [iCAL]
   that must be treated as existing with their default value in the
   properties, as defined in [iCAL], even when not explicitly present.
   For example, if a query were performed with PARAM(ATTENDEE,ROLE) then
   ALL "ATTENDEE" properties would match because, even when they do not
   explicitly contain the "ROLE" parameter, it has a default value and
   therefore must match.

   Therefore, when PARAM() is used in a "SELECT" clause, it is more
   accurate to say that it means return the property, if it contains the
   named parameter explicitly in the property or simply because the
   parameter has a default for that property.

6.1.1.3.2.  PARAM() in WHERE

   When PARAM() is used in the "WHERE" clause, a match is true when the
   parameter value matches the compare clause (according to the supplied
   WHERE values).  If multiple named properties contain the named
   parameter, then each parameter value is compared in turn to the
   condition; if any match, the results would be true for that condition
   the same as if only one had existed.  Each matching property or
   component is returned only once.

   Because a parameter may be multi-valued, the comparison might need to
   be done with an "IN" or "NOT IN" comparator.

Top      Up      ToC       Page 38 
   Given the following query:

      ATTENDEE;PARTSTAT=ACCEPTED:cap://host.com/joe

      SELECT VEVENT FROM VAGENDA
       WHERE PARAM(ATTENDEE,PARTSTAT) = 'ACCEPTED'

   Thus, all "VEVENT" components that contain one or more "ATTENDEE"
   properties that have a "PARTSTAT" parameter with a "ACCEPTED" value
   would be returned.  Also, each uniquely matching VEVENT would be
   returned only once, no matter how many "ATTENDEE" properties had
   matching roles, in each unique "VEVENT" component.

   Also note that many parameters have default values defined in [iCAL].
   Therefore, if the following query were performed on the "ATTENDEE"
   property in the above example:

      SELECT VEVENT FROM VAGENDA
       WHERE PARAM(ATTENDEE,ROLE) = 'REQ-PARTICIPANT'

   It would return the "ATTENDEE" property shown above because the
   default value for the "ROLE" parameter is "REQ-PARTICIPANT".

6.1.1.4.  SELF()

   Used in a CAL-QUERY "WHERE" clause.  Returns the UPN of the currently
   authenticated UPN or their current UPN as a result of an IDENTIFY
   command.

6.1.1.5.  STATE()

   Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED"
   depending on the state of the object.  "DELETED" is a component in
   the marked-for-delete state.  Components that have been removed from
   the store are never returned.

   If not specified in a query then both "BOOKED" and "UNPROCESSED" data
   is returned.  Each unique "METHOD" property must be in a separate
   MIME object, per the [iCAL] section 3.2 restriction.

6.1.1.6.  Use of Single Quote

   All literal values are surrounded by single quotes ('), not double
   quotes ("), and not without any quotes.  If the value contains quotes
   or any other ESCAPED-CHAR, they MUST be backslash-escaped as
   described in section 4.3.11 "Text" of [iCAL].  Any "LIKE" clause
   wildcard characters that are part of any literal data that is
   preceded by a "LIKE" clause or "NOT LIKE" clause and is not intended

Top      Up      ToC       Page 39 
   to mean wildcard search MUST be escaped as described in note (7)
   below.

6.1.1.7.  Comparing DATE and DATE-TIME Values

   When comparing "DATE-TIME" values to "DATE" values and when comparing
   "DATE" values to "DATE-TIME" values, the result will be true if the
   "DATE" value is on the same day as the "DATE-TIME" value.  They are
   compared in UTC no matter what time zone the data may have been
   stored in.

   Local time event, as described in section 4.2.19 of [iCAL], must be
   considered to be in the CUA default timezone that was supplied by the
   CUA in the "CAPABILITY" exchange.

      VALUE-1             VALUE-2            Compare Results

      20020304            20020304T123456    TRUE
      (in UTC-3)          (in UTC-3)

      20020304            20020304T003456    FALSE
      (in UTC)            (in UTC-4)

      20020304T003456Z    20020205T003456    FALSE
      (in UTC-0)          (in UTC-7)

   When "DATE" values and "DATE-TIME" values are compared with the
   "LIKE" clause, the comparison will be done as if the value is a
   [iCAL] DATE or DATE-TIME string value.

      LIKE '2002%' will match anything in the year 2002.

      LIKE '200201%' will match anything in January 2002.

      LIKE '%T000000' will match anything at midnight.

      LIKE '____01__T%' will match anything for any year or
                    time that is in January.
                    (Four '_', '01', two '_' 'T%').

   Using a "LIKE" clause value of "%00%", would return any value that
   contained two consecutive zeros.

   All comparisons will be done in UTC.

Top      Up      ToC       Page 40 
6.1.1.8.  DTEND and DURATION

   The "DTEND" property value is not included in the time occupied by
   the component.  That is, a "DTEND" property value of 20030614T12000
   includes all of the time up to, but not including, noon on that day.

   The "DURATION" property value end time is also not inclusive.  So an
   object with a "DTSTART" property value of 20030514T110000 and a
   "DURATION" property value of "1H" does not include noon on that day.

   When a "QUERY" property value contains a "DTEND" value, then the CS
   MUST also evaluate any existing "DURATION" property value and
   determine if it has an effective end time that matches the "QUERY"
   property supplied "DTEND" value or any range of values supplied by
   the "QUERY" property.

   When a "QUERY" property contains a "DURATION" value, then the CS MUST
   also evaluate any existing "DTEND" property values and determine if
   they have an effective duration that matches the value, or any range
   of values, supplied by the "QUERY" property.

6.1.1.9.  [NOT] LIKE

   The pattern matching characters are the '%' that matches zero or more
   characters, and '_' that matches exactly one character (where
   character does not always mean octet).

   "LIKE" clause pattern matches always cover the entire string.  To
   match a pattern anywhere within a string, the pattern must start and
   end with a percent sign.

   To match a '%' or '_' in the data and not have it interpreted as a
   wildcard character, they MUST be backslash-escaped.  Thus, to search
   for a '%' or '_' in the string:

      LIKE '%\%%'    Matches any string with a '%' in it.
      LIKE '%\_%'    Matches any string with a '_' in it.

   Strings compared using the "LIKE" clause MUST be performed using case
   insensitive comparisoison assumes 'a' = 'A').

   If the "LIKE" clause is preceded by 'NOT' then there is a match when
   the string compare fails.

   Some property values (such as the 'recur' value type), contain commas
   and are not multi-valued.  The CS must understand the objects being
   compared and understand how to determine how any multi-valued or
   multi-instances properties or parameter values are separated, quoted,

Top      Up      ToC       Page 41 
   and backslash-escaped.  THE CS must perform the comparisons as if
   each value existed by itself and was not quoted or backslash-escaped,
   when comparing using the LIKE element.

   See related examples in Section 6.1.1.11.

6.1.1.10.  Empty vs. NULL

   When used in a CAL-QUERY value, "NULL" means that the property or
   parameter is not present in the object.  Paramaters that are not
   provided and have a default value in the property are considered to
   exist with their default value and will not be "NULL".

      If the property exists but has no value, then "NULL" MUST NOT
      match.

      If the parameter exists but has no value, then "NULL" MUST NOT
      match.

      If the parameter not present and has a default value, then "NULL"
      MUST NOT match.

      If the property (or parameter) exists but has no value, then it
      matches the empty string '' (quote quote).

6.1.1.11.  [NOT] IN

   This is similar to the "LIKE" clause, except it does value matching
   and not string comparison matches.

   Some iCalendar objects can be multi-instance and multi-valued.  The
   "IN" clause will return a match if the literal value supplied as part
   of the "IN" clause is contained in the value of any instance of the
   named property or parameter, or is in any of the multiple values in
   the named property or parameter.  Unlike the "LIKE" clause, the '%'
   and '_' matching characters are not used with the "IN" clause and
   have no special meaning.

             BEGIN:A-COMPONENT
      (a)      property:value1,value2        One property, two values.
      (b)      property:"value1,value2"      One property, one value.
      (c)      property:parameter=1,2:x      One parameter, two values.
      (d)      property:parameter="1,2",3:y  One parameter, one value.
      (e)      property:parameter=",":z      One parameter, one value.
      (f)      property:x,y,z                One property, three values
             END:A-COMPONENT

Top      Up      ToC       Page 42 
   In this example:

      'value1' IN property          would match (a) only.
      'value1,value2' IN property   would match (b) only.
      'value%'  IN property         would NOT match any.
      ',' IN property               would NOT match any.
      '%,%' IN property             would NOT match any.
      'x' IN property               would match (f) and (c).
      '2' IN parameter              would match (c) only.
      '1,2' IN parameter            would match (d) only.
      ',' IN parameter              would match (e) only.
      '%,%' IN parameter            would NOT match any.

      property  LIKE 'value1%'      would match (a) and (b).
      property  LIKE 'value%'       would match (a) and (b).
      property  LIKE 'x'            would match (f) and (c).
      parameter LIKE '1%'           would match (c) and (d).
      parameter LIKE '%2%'          would match (c) and (d).
      parameter LIKE ','            would match (e) only.

   Some property values (such as the "RECUR" value type), contain commas
   and are not multi-valued.  The CS must understand the objects being
   compared and understand how to determine how any multi-valued or
   multi-instance properties or parameter values are separated, quoted,
   and backslash-escaped and perform the comparisons as if each value
   existed by itself and not quoted or backslash-escaped when comparing
   using the IN element.

   If the "IN" clause is preceded by 'NOT', then there is a match when
   the value does not exist in the property or parameter value.

6.1.1.12.  DATE-TIME and TIME Values in a WHERE Clause

   All "DATE-TIME" and "TIME" literal values supplied in a "WHERE"
   clause MUST be terminated with 'Z'.  That means that the CUA MUST
   supply the values in UTC.

   Valid:

      WHERE alarm.TRIGGER < '20020201T000000Z'
      AND alarm.TRIGGER > '20020101T000000Z'

   Not valid; it is a syntax error and the CS MUST reject the QUERY:

      WHERE alarm.TRIGGER < '20020201T000000'
      AND alarm.TRIGGER > '20020101T000000'

Top      Up      ToC       Page 43 
6.1.1.13.  Multiple Contained Components

   If a query references a component and a component or property
   contained in the component, any clauses referring to the contained
   component or property must be evaluated on all of the contained
   components or properties.  If any of the contained components or
   properties match the query, and the conditions on the containing
   component are also true, the component matches the query.

   For example, in the query below, if a BOOKED VEVENT contains multiple
   VALARMs, and the VALARM.TRIGGER clause is true for any of the VALARMs
   in the VEVENT, then the UID, SUMMARY, and DESCRIPTION of this VEVENT
   would be included in the QUERY results.

      BEGIN:VQUERY
      EXPAND:TRUE
      QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
      WHERE VALARM.TRIGGER >= '20000101T030405Z'
      AND VALARM.TRIGGER <= '20001231T235959Z'
      AND STATE() = 'BOOKED'
      END:VQUERY

6.1.1.14.  Example, Query by UID

   The following example would match the entire content of a "VEVENT" or
   "VTODO" component with the "UID" property equal to "uid123" , and it
   would not expand any multiple instances of the component.  If the CUA
   does not know  if "uid123" was a "VEVENT", "VTODO", "VJOURNAL", or
   any other component, then all components that the CUA supports MUST
   be supplied in a QUERY property.  This example assumes the CUA is
   only interested in "VTODO" and "VEVENT" components.

   If the results were empty it could also mean that "uid123" was a
   property in a component other than a VTODO or VEVENT.

      BEGIN:VQUERY
      QUERY:SELECT * FROM VTODO WHERE UID = 'uid123'
      QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123'
      END:VQUERY

6.1.1.15.  Query by Date-Time Range

      This query selects the entire content of every booked "VEVENT"
      component that has an instance greater than or equal to July 1,
      2000 00:00:00 UTC and less than or equal to July 30, 2000 23:59:59
      UTC.  This includes single instance "VEVENT" components that do
      not explicitly contain any recurrence properties or "RECURRENCE-
      ID" properties.  This works only for CSs that have the "RECUR-

Top      Up      ToC       Page 44 
      EXPAND" property value set to "TRUE" in the "GET-CAPABILITY"
      exchange.

      BEGIN:VQUERY
      EXPAND:TRUE
      QUERY:SELECT * FROM VEVENT
      WHERE RECURRENCE-ID >= '20000701T000000Z'
      AND RECURRENCE-ID <= '20000730T235959Z'
      AND STATE() = 'BOOKED'
      END:VQUERY

6.1.1.16.  Query for All Unprocessed Entries

   The following example selects the entire contents of all non-booked
   "VTODO" and "VEVENT" components in the "UNPROCESSED" state.  The
   default for the "EXPAND" property is "FALSE", so the recurrence rules
   will not be expanded.

      BEGIN:VQUERY
      QUERYID:Fetch VEVENT and VTODO iTIP components
      QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED'
      QUERY:SELECT * FROM VTODO WHERE STATE() = 'UNPROCESSED'
      END:VQUERY

   The following example fetches all "VEVENT" and "VTODO" components in
   the "BOOKED" state.

      BEGIN:VQUERY
      QUERYID:Fetch All Booked VEVENT and VTODO components
      QUERY:SELECT * FROM VEVENT WHERE STATE() = 'BOOKED'
      QUERY:SELECT * FROM VTODO WHERE STATE() = 'BOOKED'
      END:VQUERY

   The following fetches the "UID" property for all "VEVENT" and "VTODO"
   components that have been marked for delete.

      BEGIN:VQUERY
      QUERYID:Fetch UIDs of marked-for-delete VEVENTs and VTODOs
      QUERY:SELECT UID FROM VEVENT WHERE STATE() = 'DELETED'
      QUERY:SELECT UID FROM VTODO WHERE STATE() = 'DELETED'
      END:VQUERY

6.1.1.17.  Query with Subset of Properties by Date/Time

   In this example, only the named properties will be selected, and all
   booked and non-booked components have a "DTSTART" value from February
   1st to February 10th 2000 (in UTC) will also be selected.

Top      Up      ToC       Page 45 
      BEGIN:VQUERY
      QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT
      WHERE DTSTART >= '20000201T000000Z'
      AND DTSTART <= '20000210T235959Z'
      END:VQUERY

6.1.1.18.  Query with Components and Alarms in A Range

   This example fetches all booked "VEVENT" components with an alarm
   that triggers within the specified time range.  In this case only the
   "UID", "SUMMARY", and "DESCRIPTION" properties will be selected for
   all booked "VEVENTS" components that have an alarm between the two
   date-times supplied.

      BEGIN:VQUERY
      EXPAND:TRUE
      QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
      WHERE VALARM.TRIGGER >= '20000101T030405Z'
      AND VALARM.TRIGGER <= '20001231T235959Z'
      AND STATE() = 'BOOKED'
      END:VQUERY

6.1.2.  UPN Value Type

   Value Name: UPN

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

   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 [RFC2822]
                   ;
                   ;
         dot-atom-text = ; As defined in [iCAL].

   Description: This data type is an identifier that denotes a CU or a
      group of CU.  A UPN is an RFC 2822-compliant email address
      [RFC2822], 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.  And there is
      no requirement that a person's UPN MUST be their e-mail address.

Top      Up      ToC       Page 46 
      A UPN is formatted as a user name followed by "@", followed by a
      Realm in the form of a valid and unique DNS domain name.  The user
      name MUST be unique within the Realm.  In its simplest form it
      looks like "user@example.com".

      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.  For example,
      "@example.com".

   Example:

      The following is a UPN for a CU:

         jdoe@example.com

      The following is an example of a UPN that could be for a group of
      CU:

         staff@example.com

      The following is a UPN for an anonymous CU that belongs to a
      specific realm.  When used as a UPN-FILTER, it applies to all UPNs
      in a specific realm:

         @example.com

      The following is a UPN for an anonymous CU:

         @

6.1.3.  UPN-FILTER Value

   Value Name: UPN-FILTER

   Purpose: This value type is used to identify values that contain a
      user principal name filter.

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

                      ;
                      ; NOTE: "CAL-OWNERS(cal-address)"
                      ;       and "NOT CAL-OWNERS(cal-address)"
                      ;       are both NOT allowed below.
                      ;

Top      Up      ToC       Page 47 
         upn-filter    = "CAL-OWNERS()" /
                         "NOT CAL-OWNERS()" /
                         "*" /
                   [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text )
                      ;
                      ; dot-atom-text is defined in RFC 2822

   Description: The value is used to match user principal names (UPNs).
   For "CAL-OWNERS()" and "NOT CAL-OWNERS()", see Section 8.24.

      *           Matches all UPNs.

      @           Matches the UPN of anonymous CUs
                  belonging to the null realm

      @*          Matches the UPN of anonymous CUs
                  belonging to any non-null realm

      @realm      Matches the UPN of anonymous CUs
                  belonging to the specified realm.

      *@*         Matches the UPN of non-anonymous CUs
                  belonging to any non-null realm

      *@realm     Matches the UPN of non-anonymous CUs
                  belonging to the specified realm

      user@realm  Matches the UPN of the specified CU
                  belonging to the specified realm

      user@*      Not allowed.

      user@       Not allowed.

   Example: The following are examples of this value type:

      DENY:NON CAL-OWNERS()
      DENY:@hackers.example.com
      DENY:*@hackers.example.com
      GRANT:sam@example.com

Top      Up      ToC       Page 48 
7.  New Parameters

7.1.  ACTION Parameter

   Parameter Name: ACTION

   Purpose: This parameter indicates the action to be taken when a
      timeout occurs.

   Value Type: TEXT

   Conformance: This property can be specified in the "CMD" property.

      When present in a "CMD" property, the "ACTION" parameter specifies
      the action to be taken when the command timeout expires.

   Formal Definition: The parameter is defined by the following
      notation:

         action-param     = ";" "ACTION" "=" ( "ASK" / "ABORT" )
                             ; If 'action-param' is supplied then
                             ; 'latency-param' MUST be supplied.

   Example:

         CMD;LATENCY=10;ACTION=ASK:CREATE

7.2.  ENABLE Parameter

   Parameter Name: ENABLE

   Purpose: This parameter indicates whether or not the property should
      be ignored.  For example, it can indicate that a "TRIGGER"
      property in a "VALARM" component should be ignored.

   Value Type: BOOLEAN

   Conformance: This property can be specified in the "TRIGGER"
      properties.

   Description: When a non owner sends an [iTIP] "REQUEST" to a calendar
      that object might contain a "VALARM" component.  The owner may
      wish to have local control over their own CUA and when or how
      alarms are triggered.

      A CUA may add the "ENABLE" parameter to any "TRIGGER" property
      before booking the component.  If the "ENABLE" parameter is set to
      "FALSE", then the alarm will be ignored by the CUA.  If set to

Top      Up      ToC       Page 49 
      "TRUE", or if the "ENABLE" property is not in the "TRIGGER"
      property, the alarm is enabled.  This parameter may not be known
      by pre-CAP implementations, but this should not be an issue as it
      conforms to an 'ianaparam' [iCAL].

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

         enable-param       = "ENABLE" "=" boolean
                              ;
         boolean            = ; As defined in [iCAL].

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

         TRIGGER;ENABLE=FALSE;RELATED=END:PT5M

7.3.  ID Parameter

   Parameter Name: ID

   Purpose: When used in a "CMD" component, it provides a unique
      identifier.

   Value Type: TEXT

   Conformance: This parameter can be specified in the "CMD" property.

   Description: If more than one command is sent, then the "ID"
      parameter is used to uniquely identify the command.

      A CUA may add the "ID" parameter to any "CMD" property before
      sending the command.  There must not be more than one outstanding
      command tagged with the same "ID" parameter value.

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

         id-param         = ";" "ID" "=" unique-id
                          ; The text value supplied is a unique value
                          ; shared between the CUA and CS to uniquely
                          ; identify the instance of command in the
                          ; the current CUA session.  The value has
                          ; no meaning to other CUAs or other sessions.
                          ;
         unique-id        = ; text
                          ;
         text             = ; As defined in [iCAL].

      Example: The following is an example of this parameter component:

Top      Up      ToC       Page 50 
         CMD;UD=some-unique-value:CREATE

7.4.  LATENCY Parameter

   Parameter Name: LATENCY

   Purpose: This parameter indicates time in seconds for when a timeout
      occurs.

   Value Type: TEXT

   Conformance: This property can be specified in the "CMD" property.

   When present in a "CMD" property, the "LATENCY" parameter specifies
      the time in seconds when the command timeout expires.

   Formal Definition: The parameter is defined by the following
      notation:

         latency-param    = ";" "LATENCY" "=" latency-sec
                          ; The value supplied in the time in seconds.
                          ; If 'latency-param' is supplied then
                          ; 'action-param' MUST be supplied.
                          ;
         latency-sec      = posint1

                          ; Default is zero (0) meaning no timeout.

   Example: The following is an example of this parameter:

         CMD;LATENCY=10;ACTION=ASK:CREATE

7.5.  LOCAL Parameter

   Parameter Name: LOCAL

   Purpose: Indicates if the named component should be exported to any
      non-organizer calendar.

   Value Type: BOOLEAN

   Conformance: This parameter can be specified in the "SEQUENCE"
      properties in a "VALARM" component.

   Description: When a non-owner sends an [iTIP] "REQUEST" to a calendar
      that object might contain a "VALARM" component.  The owner may
      wish to have local control over their own CUA and when or how
      alarms are triggered.

Top      Up      ToC       Page 51 
      A CUA may add the "LOCAL" parameter to the "SEQUENCE" property
      before booking the component.  If the "LOCAL" parameter is set to
      "TRUE", then the alarm MUST NOT be forwarded to any other
      calendar.  If set to "FALSE", or if the "LOCAL" parameter is not
      in the "SEQUENCE" property, the alarm is global.

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

         local-param        = "LOCAL" "=" boolean

      Example: The following is an example of this parameter:

         SEQUENCE;LOCAL=TRUE:4

7.6.  LOCALIZE Parameter

   Parameter Name: LOCALIZE

   Purpose: If provided, specifies the desired language for error and
      warning messages.

   Value Type: TEXT

   Conformance: This parameter can be specified in the "CMD" properties.

      When the "LOCALIZE" parameter is supplied, its value MUST be one
      of the values listed in the initial [BEEP] greeting 'localize'
      attribute.

      A CUA may add the "LOCALIZE" parameter to the "CMD" property to
      specify the language of any error or warning messages.

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

         localize-param   = ";" "LOCALIZE" "=" beep-localize
                          ;
         beep-localize    = text ; As defined in [BEEP]
                          ; The value supplied MUST be one value from
                          ; the initial [BEEP] greeting 'localize'
                          ; attribute, specifying the locale to use
                          ; for error messages during
                          ; this instance of the command.

   Example: The following is an example of this parameter:

         CMD;LOCALIZE=fr_CA:CREATE

Top      Up      ToC       Page 52 
7.7.  OPTIONS Parameter

   Parameter Name: OPTIONS

   Purpose: If provided the "OPTIONS" parameter specifies some "CMD"
      property-specific options.

   Value Type: TEXT

   Conformance: This parameter can be specified in the "CMD" properties.

      A CUA adds the "OPTIONS" parameter to the "CMD" property when the
      command needs extra values.

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

         option-param     = ";" "OPTIONS" "=" cmd-specific
                            ;
         cmd-specific     = ; The value supplied is dependent on the
                            ; CMD value.  See the specific CMDs for the
                            ; correct values to use for each CMD.

   Example: The following is an example of this parameter:

         CMD;OPTIONS=10:GENERATE-UID



(page 52 continued on part 3)

Next RFC Part