tech-invite   World Map     

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

RFC 4324

Experimental
Pages: 131
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: ~cal

Calendar Access Protocol (CAP)

Part 1 of 5, p. 1 to 19
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                           D. Royer
Request for Comments: 4324                               IntelliCal, LLC
Category: Experimental                                         G. Babics
                                                                  Oracle
                                                              S. Mansour
                                                                    eBay
                                                           December 2005


                     Calendar Access Protocol (CAP)

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The Calendar Access Protocol (CAP) described in this memo permits a
   Calendar User (CU) to utilize a Calendar User Agent (CUA) to access
   an iCAL-based Calendar Store (CS).  At the time of this writing,
   three vendors are implementing CAP, but it has already been
   determined that some changes are needed.  In order to get
   implementation experience, the participants felt that a CAP
   specification is needed to preserve many years of work.  Many
   properties in CAP which have had many years of debate, can be used by
   other iCalendar protocols.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................5
      1.1. Formatting Conventions .....................................5
      1.2. Related Documents ..........................................6
      1.3. Definitions ................................................7
   2. Additions to iCalendar .........................................11
      2.1.  New Value Types (Summary) ................................14
         2.1.1. New Parameters (summary) .............................14
         2.1.2. New or Updated Properties (summary) ..................14
         2.1.3. New Components (summary) .............................17
      2.2.  Relationship of RFC-2446 (ITIP) to CAP ...................18
   3. CAP Design .....................................................20
      3.1. System Model ..............................................20
      3.2. Calendar Store Object Model ...............................20
      3.3. Protocol Model ............................................21
         3.3.1. Use of BEEP, MIME, and iCalendar .....................22
   4. Security Model .................................................23
      4.1. Calendar User and UPNs ....................................23
         4.1.1. UPNs and Certificates ................................24
         4.1.2. Anonymous Users and Authentication ...................25
         4.1.3. User Groups ..........................................25
      4.2. Access Rights .............................................26
         4.2.1. Access Control and NOCONFLICT ........................26
         4.2.2. Predefined VCARs .....................................26
         4.2.3. Decreed VCARs ........................................28
      4.3. CAP Session Identity ......................................28
   5. CAP URL and Calendar Address ...................................29
   6. New Value Types ................................................30
      6.1. Property Value Data Types .................................30
         6.1.1. CAL-QUERY Value Type .................................30
            6.1.1.1. [NOT] CAL-OWNERS() ..............................36
            6.1.1.2. CURRENT-TARGET() ................................37
            6.1.1.3. PARAM() .........................................37
            6.1.1.4. SELF() ..........................................38
            6.1.1.5. STATE() .........................................38
            6.1.1.6. Use of Single Quote .............................38
            6.1.1.7. Comparing DATE and DATE-TIME Values .............39
            6.1.1.8. DTEND and DURATION ..............................40
            6.1.1.9. [NOT] LIKE ......................................40
            6.1.1.10. Empty vs. NULL .................................41
            6.1.1.11. [NOT] IN .......................................41
            6.1.1.12. DATE-TIME and TIME Values in a WHERE Clause ....42
            6.1.1.13. Multiple Contained Components ..................43
            6.1.1.14. Example, Query by UID ..........................43
            6.1.1.15. Query by Date-Time Range .......................43
            6.1.1.16. Query for All Unprocessed Entries ..............44
            6.1.1.17. Query with Subset of Properties by Date/Time ...44

Top      ToC       Page 3 
            6.1.1.18. Query with Components and Alarms in A Range ....45
         6.1.2. UPN Value Type .......................................45
         6.1.3. UPN-FILTER Value .....................................46
   7. New Parameters .................................................48
      7.1. ACTION Parameter ..........................................48
      7.2. ENABLE Parameter ..........................................48
      7.3. ID Parameter ..............................................49
      7.4. LATENCY Parameter .........................................50
      7.5. LOCAL Parameter ...........................................50
      7.6. LOCALIZE Parameter ........................................51
      7.7. OPTIONS Parameter .........................................52
   8. New Properties .................................................52
      8.1. ALLOW-CONFLICT Property ...................................52
      8.2. ATT-COUNTER Property ......................................53
      8.3. CALID Property ............................................54
      8.4. CALMASTER Property ........................................54
      8.5. CAP-VERSION Property ......................................55
      8.6. CARID Property ............................................55
      8.7. CAR-LEVEL Property ........................................56
      8.8. COMPONENTS Property .......................................56
      8.9. CSID Property .............................................58
      8.10. DECREED Property .........................................58
      8.11. DEFAULT-CHARSET Property .................................59
      8.12. DEFAULT-LOCALE Property ..................................60
      8.13. DEFAULT-TZID Property ....................................61
      8.14. DEFAULT-VCARS Property ...................................62
      8.15. DENY Property ............................................62
      8.16. EXPAND property ..........................................63
      8.17. GRANT Property ...........................................64
      8.18. ITIP-VERSION Property ....................................64
      8.19. MAX-COMP-SIZE Property ...................................65
      8.20. MAXDATE Property .........................................65
      8.21. MINDATE Property .........................................66
      8.22. MULTIPART Property .......................................66
      8.23. NAME Property ............................................67
      8.24. OWNER Property ...........................................68
      8.25. PERMISSION Property ......................................68
      8.26. QUERY property ...........................................69
      8.27. QUERYID property .........................................70
      8.28. QUERY-LEVEL Property .....................................70
      8.29. RECUR-ACCEPTED Property ..................................71
      8.30. RECUR-LIMIT Property .....................................71
      8.31. RECUR-EXPAND Property ....................................72
      8.32. RESTRICTION Property .....................................72
      8.33. SCOPE Property ...........................................73
      8.34. STORES-EXPANDED Property .................................74
      8.35. TARGET Property ..........................................74
      8.36. TRANSP Property ..........................................75

Top      ToC       Page 4 
   9. New Components .................................................76
      9.1. VAGENDA Component .........................................76
      9.2. VCALSTORE Component .......................................78
      9.3. VCAR Component ............................................80
      9.4. VRIGHT Component ..........................................82
      9.5. VREPLY Component ..........................................83
      9.6. VQUERY Component ..........................................83
   10. Commands and Responses ........................................85
      10.1. CAP Commands (CMD) .......................................85
      10.2. ABORT Command ............................................88
      10.3. CONTINUE Command .........................................89
      10.4. CREATE Command ...........................................90
      10.5. DELETE Command ...........................................96
      10.6. GENERATE-UID Command .....................................98
      10.7. GET-CAPABILITY Command ..................................100
      10.8. IDENTIFY Command ........................................103
      10.9. MODIFY Command ..........................................105
      10.10. MOVE Command ...........................................110
      10.11. REPLY Response to a Command ............................112
      10.12. SEARCH Command .........................................113
      10.13. SET-LOCALE Command .....................................116
      10.14. TIMEOUT Command ........................................118
      10.15. Response Codes .........................................118
   11. Object Registration ..........................................120
      11.1. Registration of New and Modified Entities ...............120
      11.2. Post the Item Definition ................................120
      11.3. Allow a Comment Period ..................................120
      11.4. Release a New RFC .......................................120
   12. BEEP and CAP .................................................120
      12.1. BEEP Profile Registration ...............................120
      12.2. BEEP Exchange Styles ....................................123
      12.3. BEEP Connection Details .................................123
   13. IANA Considerations ..........................................125
   14. Security Considerations ......................................125
   Appendix A.  Acknowledgements ....................................127
   Appendix B.  References ..........................................127
       Appendix B.1.  Normative References ..........................127
       Appendix B.2.  Informative References ........................128

Top      ToC       Page 5 
1.  Introduction

   This document specifies the Calendar Access Protocol (CAP).  CAP
   permits a Calendar User (CU) to utilize a Calendar User Agent (CUA)
   to access an iCAL-based Calendar Store (CS) and manage calendar
   information.  In particular, the document specifies how to query,
   create, modify, and delete iCalendar components (e.g., events, to-
   dos, or daily journal entries).  It further specifies how to search
   for available busy time information.  Synchronization with CUAs is
   not covered, but it is believed to be possible using CAP.

   At the time of this writing, three vendors are implementing CAP.  It
   has already been determined that some changes are needed.  In order
   to get implementation experience, the participants felt that a CAP
   specification is needed to preserve many years of work.  Many
   properties in CAP can be used by other iCalendar protocols and have
   had many years of debate.

   CAP is specified as a BEEP (Block Extensible Exchange Protocol)
   "profile" [BEEP] [BEEPGUIDE].  Many aspects of the protocol (e.g.,
   authentication and privacy) are provided within BEEP.  The protocol
   data units of CAP leverage the standard iCalendar format iCAL [iCAL]
   to convey calendar-related information.

   CAP can also be used to store and fetch iCalendar Transport-
   Independent Interoperability Protocol (iTIP) objects [iTIP].  iTIP
   objects used are exactly as defined in [iTIP].  When iCalendar
   objects are transferred between the CUA and a CS, some additional
   properties and parameters may be added; the CUA is responsible for
   correctly generating iCalendar objects to non-CAP processes.

   The definition of new components, properties, parameters, and value
   types are broken into two parts.  The first part summarizes and
   defines the new objects.  The second part provides detail and ABNF
   for those objects.  The ABNF rules for CAP, as for other iCalendar
   specifications, are order-independent.  That is, properties in a
   component may occur in any order, and parameters in any property may
   occur in any order.

1.1.  Formatting Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Calendaring and scheduling roles are referred to in quoted-strings of
   text with the first character of each word in upper case.  For
   example, "Organizer" refers to a role of a "Calendar User" (CU)

Top      ToC       Page 6 
   within the protocol defined by [iTIP].  Calendar components defined
   by [iCAL] are referred to with capitalized, quoted-strings of text.
   All iCalendar components should start with the letter "V".  For
   example, "VEVENT" refers to the event calendar component, "VTODO"
   refers to the to-do component, and "VJOURNAL" refers to the daily
   journal component.

   Scheduling methods defined by [iTIP] are referred to with
   capitalized, quoted-strings of text.  For example, "REPLY" refers to
   the method for replying to a "REQUEST".

   CAP commands are referred to by upper-case, quoted-strings of text,
   followed by the word "command".  For example, '"CREATE" command'
   refers to the command for creating a calendar entry, '"SEARCH"
   command' refers to the command for reading calendar components.  CAP
   commands are named using the "CMD" property.

   Properties defined by this memo are referred to with capitalized,
   quoted-strings of text, followed by the word "property".  For
   example, '"ATTENDEE" property' refers to the iCalendar property used
   to convey the calendar address that has been invited to a "VEVENT" or
   "VTODO" component.

   Property parameters defined by this memo are referred to with
   capitalized, quoted-strings of text, followed by the word
   "parameter".  For example, "PARTSTAT" parameter refers to the
   iCalendar property parameter used to specify the participation status
   of an attendee.  Enumerated values defined by this memo are referred
   to with capitalized text, either alone or followed by the word
   "value".

   Object states defined by this memo are referred to with capitalized,
   quoted-strings of text, followed by the word "state".  For example,
   '"BOOKED" state' refers to an object in the booked state.

   Within a query, the different parts are referred to as a "clause" and
   its value as "clause value" and the clause name will be in uppercase
   enclosed in quotes, for example, 'The "SELECT" claus' or 'if the
   "SELECT" clause value contains ...'.

   In tables, the quoted-string text is specified without quotes in
   order to minimize the table length.

1.2.  Related Documents

   Implementers will need to be familiar with several other memos that,
   along with this one, describe the Internet calendaring and scheduling
   standards.  These documents are as follows.

Top      ToC       Page 7 
      [iCAL] (RFC2445) specifies the objects, data types, properties and
         property parameters used in the protocols, along with the
         methods for representing and encoding them.

      [iTIP] (RFC2446) specifies an interoperability protocol for
         scheduling between different installations.

      [iMIP] (RFC2447) specifies the Internet email binding for [iTIP].

      [GUIDE] (RFC3283) is a guide to implementers and describes the
         elements of a calendaring system, how they interact with each
         other, how they interact with end users, and how the standards
         and protocols are used.

   This memo does not attempt to repeat the specification of concepts
   and definitions from these earlier memos.  Where possible, references
   are made to the memo that provides the specification of these
   concepts and definitions.

1.3  Definitions

   UNPROCESSED, BOOKED, DELETED -  A conceptual state of an object in
      the calendar store.  There are three conceptual states:
      "UNPROCESSED" state, "BOOKED" state, and marked for deletion,
      which is the "DELETED" state.  How the implementation stores the
      state of any object is not a protocol issue and is not discussed.
      An object can be said to be booked, unprocessed, or marked for
      deletion.

      1.  An "UNPROCESSED" state scheduling object has been stored in
          the calendar store but has not been acted on by a CU or CUA.
          All scheduled entries are [iTIP] objects.  No [iTIP] objects
          in the store are in the "BOOKED" state.  To retrieve any
          [iTIP] object, simply do a query asking for any objects that
          are stored in the "UNPROCESSED" state.

      2.  A "BOOKED" state entry is stored with the "CREATE" command.
          It is an object that has been acted on by a CU or CUA and
          there has been a decision to store an object.  To retrieve any
          booked object, simply do a query asking for any objects that
          were stored in the "BOOKED" state.

      3.  A "DELETED" state entry is created by sending a "DELETE"
          command with the "OPTION" parameter value set to "MARK".  To
          retrieve any deleted object, simply do a query asking for any
          objects that were stored in the "DELETED" state.  By default
          objects marked for delete are not returned.  The CUA must
          specifically ask for marked-for-deletion objects.  You cannot

Top      ToC       Page 8 
          ask for components in the "DELETED" state and in other states
          in the same "VQUERY" component, as there would be no way to
          distinguish between them in the reply.

   Calendar -  A collection of logically related objects or entities
      each of which may be associated with a calendar date and possibly
      time of day.  These entities can include calendar properties or
      components.  In addition, a calendar might be related to other
      calendars with the "RELATED-TO" property.  A calendar is
      identified by its unique calendar identifier.  The [iCAL] defines
      the initial calendar properties, calendar components and
      properties that make up the contents of a calendar.

   Calendar Access Protocol (CAP) -  The Internet protocol that permits
      a CUA to access and manipulate calendars residing on a Calendar
      Store.  (This memo.)

   Calendar Access Rights (VCAR) -  The mechanism for specifying the CAP
      operations ("PERMISSION") that a particular calendar user ("UPN",
      defined below) is granted or denied permission to perform on a
      given calendar object ("SCOPE").  The calendar access rights are
      specified with a "VCAR" component.  (Section 9.3)

   Calendar Address -  Also see Calendar URL, which is the same as a CAP
      address.  The calendar address can also be the value to the
      "ATTENDEE" and "ORGANIZER" properties, as defined in [iCAL].
      Calendar URL -  A calendar URL is a URL, defined in this memo,
      that specifies the address of a CS or Calendar.

   Component -  Any object that conforms to the iCalendar object format
      and that is either defined in an Internet Draft, registered with
      IANA, or is an experimental object that is prefixed with "x-".
      Some types of components include calendars, events, to-dos,
      journals, alarms, and time zones.  A component consists of
      properties and possibly other contained components.  For example,
      an event may contain an alarm component.

   Container -  This is a generic name for VCALSTORE or VAGENDA.

   Properties -  An attribute of a particular component.  Some
      properties are applicable to different types of components.  For
      example, the "DTSTART" property is applicable to the "VEVENT",
      "VTODO", and "VJOURNAL" components.  Other components are
      applicable only to an individual type of calendar component.  For
      example, the "TZURL" property may only be applicable to the
      "VTIMEZONE" components.

Top      ToC       Page 9 
   Calendar Identifier (CALID) -  A globally unique identifier
      associated with a calendar.  Calendars reside within a CS.  See
      Qualified Calendar Identifier and Relative Calendar Identifier.
      All CALIDs start with "cap:".

   Calendar Policy -  A CAP operational restriction on the access or
      manipulation of a calendar.  These may be outside the scope of the
      CAP protocol.  An example of an implementation or site policy is,
      "events MUST be scheduled in unit intervals of one hour".

   Calendar Property -  An attribute of a calendar ("VAGENDA").  The
      attribute applies to the calendar, as a whole.  For example, the
      "CALSCALE" property specifies the calendar scale (e.g., the
      "GREGORIAN" value) for the all entries within the calendar.

   Calendar Store (CS) -  The data and service model definitions for a
      Calendar Store as defined in this memo.  This memo does not
      specify how the CS is implemented.

   Calendar Server -  An implementation of a Calendar Store (CS) that
      manages one or more calendars.

   Calendar Store Identifier (CSID) -  The globally unique identifier
      for an individual CS.  A CSID consists of the host and port
      portions of a "Common Internet Scheme Syntax" part of a URL, as
      defined by [URL].  The CSID excludes any reference to a specific
      calendar.  (Section 8.9)

   Calendar Store Components -  Components maintained in a CS specify a
      grouping of calendar store-wide information.

   Calendar Store Properties -  Properties maintained in a Calendar
      Store represent store-wide information.

   Calendar User (CU) -  An entity (often biological) that uses a
      calendaring system.

   Calendar User Agent (CUA) -  The client application that a CU
      utilizes to access and manipulate a calendar.

   CAP Session -  An open communication channel between a CUA and a CS.
      If the CAP session is authenticated, the CU is "authenticated" and
      it is an "authenticated CAP session".

   Contained Component / Contained Properties -  A component or property
      that is contained inside of another component.  For example, a
      "VALARM" component may be contained inside a "VEVENT" component,

Top      ToC       Page 10 
      and a "TRIGGER" property could be a contained property of a
      "VALARM" component.

   Delegate -  A CU (sometimes called the delegatee) who has been
      assigned participation in a scheduled component (e.g., VEVENT) by
      one of the attendees in the scheduled component (sometimes called
      the delegator).  An example of a delegate is a team member told to
      go to a particular meeting in place of another invitee who is
      unable to attend.

   Designate -  A CU who is authorized to act on behalf of another CU.
      An example of a designate is an assistant.

   Experimental -  The CUA and CS may implement experimental extensions
      to the protocol.  They might also have experimental components,
      properties, and parameters.  These extensions MUST start with "x-"
      (or "X-") and should include a vendor prefix (such as "x-
      myvendor-").  There is no guarantee that these experimental
      extensions will interoperate with other implementations.  There is
      no guarantee that they will not interact in unpredictable ways
      with other vendor experimental extensions.  There is no guarantee
      that the same specific experimental extension is not used by
      multiple vendors in incompatible ways.  Implementations should
      limit sending those extensions to other implementations.

   Object -  A generic name for any component, property, parameter, or
      value type to be used in iCalendar.

   Overlapped Booking -  A policy that indicates whether or not
      components with a "TRANSP" property not set to "TRANSPARENT-
      NOCONFLICT" or "OPAQUE-NOCONFLICT" value can overlap one another.
      When the policy is applied to a calendar it indicates whether or
      not the time span of any component (VEVENT, VTODO, ...) in the
      calendar can overlap the time span of any other component in the
      same calendar.  When applied to an individual object, it indicates
      whether or not any other component's time span can overlap that
      individual component.  If the CS does not allow overlapped
      booking, then the CS is unwilling to allow any overlapped bookings
      within any calendar or entry in the CS.

   Owner -  One or more CUs or UGs that are listed in the "OWNER"
      property in a calendar.  There can be more than one owner.

   Qualified Calendar Identifier (Qualified CALID) -  A CALID in which
      both the scheme and CSID of the CAP URI are present.

   Realm -  A collection of calendar user accounts, identified by a
      string.  The name of the Realm is only used in UPNs.  In order to

Top      ToC       Page 11 
      avoid namespace conflict, the Realm SHOULD be postfixed with an
      appropriate DNS domain name (e.g., the foobar Realm could be
      called foobar.example.com).

   Relative Calendar Identifier (Relative CALID) -  An identifier for an
      individual calendar in a calendar store.  It MUST be unique within
      a calendar store.  A Relative CALID consists of the "URL path" of
      the "Common Internet Scheme Syntax" portion of a URL, as defined
      by [URI] and [URLGUIDE].

   Session Identity -  A UPN associated with a CAP session.  A session
      gains an identity after successful authentication.  The identity
      is used in combination with VCAR to determine access to data in
      the CS.

   User Group (UG) -  A collection of Calendar Users and/or User Groups.
      These groups are expanded by the CS and may reside either locally
      or in an external database or directory.  The group membership may
      be fixed or dynamic over time.

   Username -  A name that denotes a Calendar User within a Realm.  This
      is part of a UPN.

   User Principal Name (UPN) -  A unique identifier that denotes a CU or
      a group of CUs.  (Section 6.1.2)

2.  Additions to iCalendar

   Several new components, properties, parameters, and value types are
   added in CAP.  This section summarizes those new objects.

   This memo extends the properties that can go into 'calprops' as
   defined in [iCAL] section 4.6 page 51, to allow [iTIP] objects
   transmitted between a CAP aware CUA and the CS to contain the
   "TARGET" and "CMD" properties.  This memo also adds to the [iCAL]
   ABNF to allow IANA and experimental extensions.  This memo does not
   address how a CUA transmits [iTIP] or [iMIP] objects to non-CAP
   programs.  What follows is ABNF, as described in [ABNF].

      calprops= 2*(

                    ; 'prodid' and 'version' are both REQUIRED,
                    ; but MUST NOT occur more than once.
                    ;
                prodid /version /
                    ;
                    ; These are optional, but MUST NOT occur
                    ; more than once.

Top      ToC       Page 12 
                    ;
                calscale        /
                method          /
                cmd             /
                    ;
                    ; Target is optional, and may occur more
                    ; than once.
                    ;
                target / other-props )
                    ;
      other-props  = *(x-prop) *(iana-prop) *(other-props)
                    ;
      iana-prop   = ; Any property registered by IANA directly or
                    ; included in an RFC that may be applied to
                    ; the component and within the rules published.
                    ;
      x-prop      = ; As defined in [iCAL].
                    ;
      methodp     = ; As defined in [iCAL].
                    ;
      prodid      = ; As defined in [iCAL].
                    ;
      calscale    = ; As defined in [iCAL].
                    ;

   Another change is that the 'component' part of the 'icalbody' ABNF as
   described in [iCAL] section 4.6 is optional when sending a command,
   as shown in the following updated ABNF:

      icalbody = calprops component

                ; If the "VCALENDAR" component contains the "CMD"
                ; property then the 'component' is optional:
                ;
                / calprops     ; Which MUST include a "CMD" property
                ;
      component = ; As defined in [iCAL].

   In addition, a problem exists with the control of "VALARM" components
   and their "TRIGGER" properties.  A CU may wish to set its own alarms
   (local alarms) on components.  These local alarms are not to be
   forwarded to other CUs, CUAs, or CSs.  Similarly, the "SEQUENCE"
   property and the "ENABLE" parameter in local alarms are not to be
   forwarded to other CUs, CUAs, or CSs.  Therefore, for the protocol
   between a CUA and a CS, the following changes from [iCAL] section
   4.6.6 page 67 apply to the CAP protocol:

        alarmc     = "BEGIN" ":" "VALARM" CRLF

Top      ToC       Page 13 
                     alarm-seq
                     other-props
                     (audioprop / dispprop / emailprop / procprop)
                     "END" ":" "VALARM" CRLF
                     ;
       emailprop   = ; As defined in [iCAL]
                     ;
       procprop    = ; As defined in [iCAL]
                     ;
       dispprop    = ; As defined in [iCAL]
                     ;
       audioprop   = ; As defined in [iCAL]
                     ;
       alarm-seq   = "SEQUENCE" alarmseqparams ":" posint0 CRLF
                     ;
       alarmseqparams = other-params [";" local-param] other-params
                     ;
                     ; Where DIGIT is defined in [iCAL]
                     ;
       posint0     = 1*DIGIT
       posint1     = posintfirst 1*DIGIT
                     ;
                     ; A number starting with 1 through 9.
                     ;
       posintfirst = %x31-39
                     ;
       other-params = *(";" xparam) *(";" iana-params)
                                    *(";" other-params)
                     ;
       iana-params = ; Any parameter registered by IANA directly or
                     ; included in an RFC that may be applied to
                     ; the property and within the rules published.
                     ;
       xparam        ; As defined in [iCAL].
                     ;

   The CUA adds a "SEQUENCE" property to each "VALARM" component as it
   books the component.  This property, along with the "LOCAL" and
   "ENABLE" parameters, allows the CUA to uniquely identify any VALARM
   in any component.  The CUA should remove those before forwarding to
   non-CAP-aware CUAs.

   In addition, if a CUA wished to ignore a "TRIGGER" property in a
   "VALARM" component that was supplied to it by the "Organizer", the
   CUA needs a common way to tag that trigger as disabled.  So the
   following is a modification to [iCAL] section 4.8.6.3 page 127:

      trigger    = "TRIGGER" 1*(";" enable-param) (trigrel / trigabs)

Top      ToC       Page 14 
                   ;
      trigrel    = ; As defined in [iCAL].
                   ;
      trigabs    = ; As defined in [iCAL].

   See Section 7.2 and Section 7.5.

2.1.  New Value Types (Summary)

   UPN: The UPN value type is a text value type restricted to only UPN
      values (see Section 6.1.2).

   UPN-FILTER: Like the UPN value type, but also includes filter rules
      that allow wildcards (see Section 6.1.3).

   CALQUERY: The "CAL-QUERY" value type is a query syntax that is used
      by the CUA to specify the rules that apply to a CAP command (see
      Section 6.1.1).

2.1.1.  New Parameters (summary)

   ACTION -  The "ACTION" parameter informs the endpoint if it should
         abort or ask to continue on timeout.  (Section 7.1)

   ENABLE -  The "ENABLE" parameter in CAP is used to tag a property in
      a component as disabled or enabled.  (Section 7.2)

   ID -  The "ID" parameter specifies a unique identifier to be used for
      any outstanding commands.

   LATENCY -  The "LATENCY" parameter supplies the timeout value for
      command completion to the other endpoint.  (Section 7.4)

   LOCAL -  The "LOCAL" parameter in CAP is used to tag a property in a
      component to signify that the component is local or to be
      distributed.  (Section 7.5)

   LOCALIZE -  The "LOCALIZE" parameter specifies the locale to be used
      in error and warning messages.

   OPTIONS -  The "OPTIONS" parameter passes optional information for
      the command being sent.

2.1.2.  New or Updated Properties (summary)

   ALLOW-CONFLICT -  Some entries in a calendar might not be valid if
      other entries were allowed to overlap the same time span.
      (Section 8.1)

Top      ToC       Page 15 
   ATT-COUNTER -  When storing a "METHOD" property with the "COUNTER"
      method, there needs to be a way to remember the "ATTENDEE" value
      that sent the COUNTER.  (Section 8.2)

   CAP-VERSION -  The version of CAP that the implementation supports.
      (Section 8.5)

   CAR-LEVEL -  The level of calendar access supported.  (Section 8.7)

   COMPONENTS -  The list of components supported.  (Section 8.8)

   CSID -  The Calendar Store IDentifier (CSID) uniquely identifies a
      CAP server.  (Section 8.9)

   CALID -  Each calendar within a CS needs to be uniquely identifiable.
      The "CALID" property identifies a unique calendar within a CS.  It
      can be a full CALID or a relative CALID.  (Section 8.3)

   CALMASTER -  The "CALMASTER" property specifies the contact
      information for the CS.  (Section 8.4)

   CARID -  Access rights can be saved and fetched by unique ID - the
      "CARID" property.  (Section 8.6)

   CMD -  The CAP commands, as well as replies are transmitted using the
      "CMD" property.  (Section 10.1)

   DECREED -  Some access rights are not changeable by the CUA.  When
      that is the case, the "DECREED" property value in the "VCAR"
      component will be "TRUE".  (Section 8.10)

   DEFAULT-CHARSET -  The list of charsets supported by the CS.  The
      first entry is the default for the CS.  (Section 8.11)

   DEFAULT-LOCALE -  The list of locales supported by the CS.  The first
      entry in the list is the default locale.  (Section 8.12)

   DEFAULT-TZID -  This is the list of known timezones supported.  The
      first entry is the default.  (Section 8.13)

   DEFAULT-VCARS -  A list of the "CARID" properties that will be used
      to create new calendars.  (Section 8.14)

   DENY -  The UPNs listed in the "DENY" property of a "VCAR" component
      will be denied access, as described in the "VRIGHT" component.
      (Section 8.15)

Top      ToC       Page 16 
   EXPAND -  This property tells the CS if the query reply should expand
      components into multiple instances.  The default is "FALSE" and is
      ignored for CSs that cannot expand recurrence rules.  (Section
      8.16)

   GRANT -  The UPNs listed in the "GRANT" property of a "VCAR"
      component will be allowed access as described in the "VRIGHT"
      component.  (Section 8.17)

   ITIP-VERSION -  The version of [iTIP] supported.  (Section 8.18)

   MAXDATE -  The maximum date supported by the CS.  (Section 8.20)

   MAX-COMP-SIZE -  The largest component size allowed in the
      implementation including attachments in octets.  (Section 8.19)

   MINDATE -  The minimum date supported by the CS.  (Section 8.21)

   MULTIPART -  Passed in the capability messages to indicate which MIME
      multipart types the sender supports.  (Section 8.22)

   NAME -  The "NAME" property is used to add locale-specific
      descriptions into components.  (Section 8.23)

   OWNER -  Each calendar has at least one "OWNER" property.  (xref
      target="OWNER"/>) Related to the "CAL-OWNERS()" query clause.
      (Section 6.1.1.1)

   PERMISSION -  This property specifies the permission being granted or
      denied.  Examples are the "SEARCH" and "MODIFY" values.  (Section
      8.25)

   QUERY -  Used to hold the CAL-QUERY (Section 8.26) for the component.

   QUERYID -  A unique id for a stored query.  (Section 8.27)

   QUERY-LEVEL -  The level of the query language supported.  (Section
      8.28)

   RECUR-ACCEPTED -  If the implementation support recurrence rules.
      (Section 8.29)

   RECUR-EXPAND -  If the implementation support expanding recurrence
      rules.  (Section 8.31)

   RECUR-LIMIT -  Any maximum limit on the number of instances the
      implementation will expand recurring objects.  (Section 8.30)

Top      ToC       Page 17 
   REQUEST-STATUS -  The [iCAL] "REQUEST-STATUS" property is extended to
      include new error numbers.

   RESTRICTION -  In the final check when granting calendar access
      requests, the CS test the results of a command for the value of
      the "RESTRICTION" property in the corresponding "VRIGHT"
      component, to determine if the access meets that restriction.
      (Section 8.32)

   SCOPE -  The "SCOPE" property is used in "VRIGHT"s component to
      select the subset of data that may be acted upon when checking
      access rights.  (Section 8.33)

   SEQUENCE -  When the "SEQUENCE" property is used in a "VALARM"
      component, it uniquely identifies the instances of the "VALARM"
      within that component.

   STORES-EXPANDED -  Specifies if the implementation stores recurring
      objects expanded or not.  (Section 8.34)

   TARGET -  The new "VCALENDAR" component property "TARGET" (Section
      8.35) is used to specify which calendar(s) will be the subject of
      the CAP command.

   TRANSP -  This is a modification of the [iCAL] "TRANSP" property and
      it allows more values.  The new values are related to conflict
      control.  (Section 8.36)

2.1.3.  New Components (summary)

   VAGENDA -  CAP allows the fetching and storing of the entire contents
      of a calendar.  The "VCALENDAR" component is not sufficient to
      encapsulate all of the needed data that describes a calendar.  The
      "VAGENDA" component is the encapsulating object for an entire
      calendar.  (Section 9.1)

   VCALSTORE -  Each CS contains one or more calendars (VAGENDAs), the
      "VCALSTORE" component is the encapsulating object that can hold
      all of the "VAGENDA" components along with any components and
      properties that are unique to the store level.  (Section 9.2)

   VCAR -  Calendar Access Rights are specified and encapsulated in the
      new iCalendar "VCAR" component.  The "VCAR" component holds some
      new properties and at least one "VRIGHT" component.  (Section 9.3)

      VRIGHT -  This component encapsulates a set of instructions to the
      CS to define the rights or restrictions needed.  (Section 9.4)

Top      ToC       Page 18 
   VREPLY -  This component encapsulates a set of data that can consist
      of an arbitrary number of properties and components.  Its contents
      are dependent on the command that was issued.  (Section 9.5)

   VQUERY -  The search operation makes use of a new component, called
      "VQUERY" and a new value type "CAL-QUERY" (Section 6.1.1).  The
      "VQUERY" component is used to fetch objects from the CS.  (Section
      9.6)

2.2.  Relationship of RFC-2446 (ITIP) to CAP

   [iTIP] describes scheduling methods that result in indirect
   manipulation of components.  In CAP, the "CREATE" command is used to
   deposit entities into the store.  Other CAP commands, such as
   "DELETE", "MODIFY", and "MOVE" command values, provide direct
   manipulation of components.  In the CAP calendar store model,
   scheduling messages are conceptually kept separate from other
   components by their state.

   All scheduling operations are as defined in [iTIP].  This memo makes
   no changes to any of the methods or procedures described in [iTIP].
   In this memo, referring to the presence of the "METHOD" property in
   an object is the same as saying an [iTIP] object.

   A CUA may create a "BOOKED" state object by depositing an iCalendar
   object into the store.  This is done by depositing an object that
   does not have a "METHOD" property.  The CS then knows to set the
   state of the object to the "BOOKED" state.  If the object has a
   "METHOD" property, then the object is stored in the "UNPROCESSED"
   state.

   If existing "UNPROCESSED" state objects exist in the CS for the same
   UID (UID is defined in [iCAL]), then a CUA may wish to consolidate
   the objects into one "BOOKED" state object.  The CUA would fetch the
   "UNPROCESSED" state objects for that UID and process them in the CUA
   as described in [iTIP].  Then, if the CUA wished to book the UID, the
   CUA would issue a "CREATE" command to create the new "BOOKED" state
   object in the CS, followed by a "DELETE" command to remove any
   related old [iTIP] objects from the CS.  It might also involve the
   CUA sending some [iMIP] objects or contacting other CSs and
   performing CAP operations on those CSs.

   The CUA could also decide not to book the object.  In this case, the
   "UNPROCESSED" state objects could be removed from the CS, or the CUA
   could set those objects to the marked-for-delete state.  The CUA
   could also ignore objects for later processing.

Top      ToC       Page 19 
   The marked-for-delete state is used to keep the object around so that
   the CUA can process duplicate requests automatically.  If a duplicate
   [iTIP] object is deposited into the CS and there exists identical
   marked-for-delete objects, then a CUA acting on behalf of the "OWNER"
   can silently drop those duplicate entries.

   Another purpose for the marked-for-delete state is so that, when a CU
   decides they do not wish to have the object show in their calendar,
   the CUA can book the object by changing the "PARTSTAT" parameter to
   "DECLINED" in the "ATTENDEE" property that corresponds to their UPN.
   Then the CUA can perform [iTIP] processing such as sending back a
   decline, and then mark that object as marked-fo-delete.  The CUA
   might be configurable to automatically drop any updates for that
   object, knowing the CU has already declined.

   When synchronizing with multiple CUAs, the marked-for-delete state
   could be used to inform the synchronization process that an object is
   to be deleted.  How synchronization is done is not specified in this
   memo.

   Several "UNPROCESSED" state entries can be in the CS for the same
   UID.  However, once consolidated, only one object exists in the CS
   and that is the booked object.  The other objects MUST be removed or
   have their state changed to "DELETED".

   There MUST NOT be more than one "BOOKED" state object in a calendar
   for the same "UID".  The "ADD" method value may create multiple
   objects in the "BOOKED" state for the same UID; however, for the
   purpose of this memo, they are the same object and simply have
   multiple "VCALENDAR" components.

   For example, if you were on vacation, you could have received a
   "REQUEST" method to attend a meeting and several updates to that
   meeting.  Your CUA would have to issue "SEARCH" commands to find them
   in the CS using CAP, process them, and determine the final state of
   the object from a possible combination of user input and programmed
   logic.  Then the CUA would instruct the CS to create a new booked
   object from the consolidated results.  Finally, the CUA could do a
   "DELETE" command to remove the related "UNPROCESSED" state objects.
   See [iTIP] for details on resolving multiple [iTIP] scheduling
   entries.


Next RFC Part