GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4324

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.

Royer, et al. Experimental [Page 1] RFC 4324 Calendar Access Protocol December 2005

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

Royer, et al. Experimental [Page 2] RFC 4324 Calendar Access Protocol December 2005

          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

Royer, et al. Experimental [Page 3] RFC 4324 Calendar Access Protocol December 2005

 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

Royer, et al. Experimental [Page 4] RFC 4324 Calendar Access Protocol December 2005

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)

Royer, et al. Experimental [Page 5] RFC 4324 Calendar Access Protocol December 2005

 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.

Royer, et al. Experimental [Page 6] RFC 4324 Calendar Access Protocol December 2005

    [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

Royer, et al. Experimental [Page 7] RFC 4324 Calendar Access Protocol December 2005

        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.

Royer, et al. Experimental [Page 8] RFC 4324 Calendar Access Protocol December 2005

 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,

Royer, et al. Experimental [Page 9] RFC 4324 Calendar Access Protocol December 2005

    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

Royer, et al. Experimental [Page 10] RFC 4324 Calendar Access Protocol December 2005

    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.

Royer, et al. Experimental [Page 11] RFC 4324 Calendar Access Protocol December 2005

                  ;
              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

Royer, et al. Experimental [Page 12] RFC 4324 Calendar Access Protocol December 2005

                   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)

Royer, et al. Experimental [Page 13] RFC 4324 Calendar Access Protocol December 2005

                 ;
    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)

Royer, et al. Experimental [Page 14] RFC 4324 Calendar Access Protocol December 2005

 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)

Royer, et al. Experimental [Page 15] RFC 4324 Calendar Access Protocol December 2005

 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)

Royer, et al. Experimental [Page 16] RFC 4324 Calendar Access Protocol December 2005

 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)

Royer, et al. Experimental [Page 17] RFC 4324 Calendar Access Protocol December 2005

 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.

Royer, et al. Experimental [Page 18] RFC 4324 Calendar Access Protocol December 2005

 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.

Royer, et al. Experimental [Page 19] RFC 4324 Calendar Access Protocol December 2005

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.

Royer, et al. Experimental [Page 20] RFC 4324 Calendar Access Protocol December 2005

 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.

Royer, et al. Experimental [Page 21] RFC 4324 Calendar Access Protocol December 2005

 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)

Royer, et al. Experimental [Page 22] RFC 4324 Calendar Access Protocol December 2005

 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

Royer, et al. Experimental [Page 23] RFC 4324 Calendar Access Protocol December 2005

 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])

Royer, et al. Experimental [Page 24] RFC 4324 Calendar Access Protocol December 2005

       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.

Royer, et al. Experimental [Page 25] RFC 4324 Calendar Access Protocol December 2005

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

Royer, et al. Experimental [Page 26] RFC 4324 Calendar Access Protocol December 2005

    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:

Royer, et al. Experimental [Page 27] RFC 4324 Calendar Access Protocol December 2005

          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

Royer, et al. Experimental [Page 28] RFC 4324 Calendar Access Protocol December 2005

 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.

Royer, et al. Experimental [Page 29] RFC 4324 Calendar Access Protocol December 2005

 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.

Royer, et al. Experimental [Page 30] RFC 4324 Calendar Access Protocol December 2005

    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:

Royer, et al. Experimental [Page 31] RFC 4324 Calendar Access Protocol December 2005

    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.

Royer, et al. Experimental [Page 32] RFC 4324 Calendar Access Protocol December 2005

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

Royer, et al. Experimental [Page 33] RFC 4324 Calendar Access Protocol December 2005

                ; "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"

Royer, et al. Experimental [Page 34] RFC 4324 Calendar Access Protocol December 2005

              / 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

Royer, et al. Experimental [Page 35] RFC 4324 Calendar Access Protocol December 2005

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

Royer, et al. Experimental [Page 36] RFC 4324 Calendar Access Protocol December 2005

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.

Royer, et al. Experimental [Page 37] RFC 4324 Calendar Access Protocol December 2005

 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

Royer, et al. Experimental [Page 38] RFC 4324 Calendar Access Protocol December 2005

 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.

Royer, et al. Experimental [Page 39] RFC 4324 Calendar Access Protocol December 2005

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,

Royer, et al. Experimental [Page 40] RFC 4324 Calendar Access Protocol December 2005

 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

Royer, et al. Experimental [Page 41] RFC 4324 Calendar Access Protocol December 2005

 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'

Royer, et al. Experimental [Page 42] RFC 4324 Calendar Access Protocol December 2005

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-

Royer, et al. Experimental [Page 43] RFC 4324 Calendar Access Protocol December 2005

    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.

Royer, et al. Experimental [Page 44] RFC 4324 Calendar Access Protocol December 2005

    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.

Royer, et al. Experimental [Page 45] RFC 4324 Calendar Access Protocol December 2005

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

Royer, et al. Experimental [Page 46] RFC 4324 Calendar Access Protocol December 2005

       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

Royer, et al. Experimental [Page 47] RFC 4324 Calendar Access Protocol December 2005

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

Royer, et al. Experimental [Page 48] RFC 4324 Calendar Access Protocol December 2005

    "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:

Royer, et al. Experimental [Page 49] RFC 4324 Calendar Access Protocol December 2005

       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.

Royer, et al. Experimental [Page 50] RFC 4324 Calendar Access Protocol December 2005

    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

Royer, et al. Experimental [Page 51] RFC 4324 Calendar Access Protocol December 2005

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

8. New Properties

8.1. ALLOW-CONFLICT Property

 Property Name: ALLOW-CONFLICT
 Purpose: This property indicates whether or not the calendar and CS
    supports component conflicts.  That is, whether or not any of the
    components in the calendar can overlap.
 Value Type: BOOLEAN
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in "VAGENDA" and
    "VCALSTORE" component.
 Description: This property is used to indicate whether components may
    conflict, that is, whether their expanded instances may share the
    same time or overlap the same time periods.  If it has a value of

Royer, et al. Experimental [Page 52] RFC 4324 Calendar Access Protocol December 2005

    "TRUE", then conflicts are allowed.  If "FALSE", the no two
    components may conflict.
    If "FALSE" in the "VCALSTORE" component, then all "VAGENDA"
    component "ALLOW-CONFLICT" property values MUST be "FALSE" in the
    CS.
 Formal Definition: The property is defined by the following notation:
       allow-conflict     = "ALLOW-CONFLICT" other-params ":" boolean
    CRLF
 Example: The following is an example of this property for a "VAGENDA"
    component:
       ALLOW-CONFLICT:FALSE

8.2. ATT-COUNTER Property

 Property Name: ATT-COUNTER
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property MUST be specified in an iCalendar object
    that specifies a counter proposal to a group-scheduled calendar
    entity.  When storing a "METHOD" property with the "COUNTER"
    method, there needs to be a way to remember who sent the COUNTER.
    The ATT-COUNTER property MUST be added to all "COUNTER" [iTIP]
    components by the CUA before storing in a CS.
 Description: This property is used to identify the CAL-ADDRESS of the
    entity that sent the "COUNTER" [iTIP] object.
 Formal Definition: The property is defined by the following notation:
       attcounter   = "ATT-COUNTER" other-params ":" cal-address CRLF
 Examples:
          ATT-COUNTER:cap:example.com/Doug
          ATT-COUNTER:mailto:Doug@Example.com

Royer, et al. Experimental [Page 53] RFC 4324 Calendar Access Protocol December 2005

8.3. CALID Property

 Property Name: CALID
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in the "VAGENDA"
    component.
 Description: This property is used to specify a fully-qualified
    CALID.
 Formal Definition: The property is defined by the following notation:
       calid   = "CALID" other-params ":" relcalid CRLF
 Example:
       CALID:cap://cal.example.com/sdfifgty4321

8.4. CALMASTER Property

 Property Name: CALMASTER
 Purpose: The property specifies an e-mail address of a person
 responsible for the calendar store.
 Value Type: URI
 Property Parameters: Non-standard property parameters can be
 specified on this property.
 Conformance: The property can be specified in a "VCALSTORE"
 component.
 Description: The parameter value SHOULD be a MAILTO URI as defined in
 [URL].  It MUST be a contact URI such as a MAILTO URI and not a home
 page or file URI that describes how to contact the calmasters.
 Formal Definition: The property is defined by the following notation:
    calmaster = "CALMASTER" other-params ":" uri CRLF
              ;
    uri       = ; IANA registered uri as defined in [iCAL].
 Example: The following is an example of this property:

Royer, et al. Experimental [Page 54] RFC 4324 Calendar Access Protocol December 2005

       CALMASTER:mailto:administrator@example.com

8.5. CAP-VERSION Property

 Property Name: CAP-VERSION
 Purpose: This property specifies the version of CAP supported.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property is specified in the "VREPLY" component
    that is sent in response to a "GET-CAPABILITY" command.
 Description: This specifies the version of CAP that the endpoint
    supports.  The list is a comma-separated list of supported RFC
    numbers.  The list MUST contain at least 4324.
 Formal Definition: The property is defined by the following notation:
       cap-version   = "CAP-VERSION" other-params ":" text CRLF
 Example: The following are examples of this property:
       CAP-VERSION:4324

8.6. CARID Property

 Property Name: CARID
 Purpose: This property specifies the identifier for an access right
    component.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property MUST be specified once in a "VCAR"
    component.
 Description: This property is used in the "VCAR" component to specify
    an identifier.  A "CARID" property value is unique per container.
 Formal Definition: The property is defined by the following notation:

Royer, et al. Experimental [Page 55] RFC 4324 Calendar Access Protocol December 2005

       carid      = "CARID" other-params ":" text CRLF
 Example: The following are examples of this property:
       CARID:xyzzy-007
       CARID:User Rights

8.7. CAR-LEVEL Property

 Property Name: CAR-LEVEL
 Purpose: The property specifies the level of VCAR supported.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: The property can be specified in a "VREPLY" component
    that is sent in response to a "GET-CAPABILITY" command.
 Description: The value is one from a list of "CAR-NONE", "CAR-MIN",
    or "CAR-FULL-1".  If "CAR-FULL-1" is supplied, then "CAR-MIN" is
    also available.  A "CAR-MIN" implementation only supported the
    "DEFAULT-VCARS" property values listed in the "VCALSTORE"
    component, and a "CAR-MIN" implementation does not support the
    creation or modification of "VCAR" components from the CUA.
 Formal Definition: The property is defined by the following notation:
       car-level        = "CAR-LEVEL" ":" other-params ":"
                                              car-level-values
       car-level-values = ( "CAR-NONE" / "CAR-MIN" / "CAR-FULL-1"
                            / other-levels )
       other-levels     = ; Any name published in an RFC for a
                          ; "CAR-LEVEL" property value.
 Example: The following is an example of this property:
          CAR-LEVEL:CAR-FULL-1

8.8. COMPONENTS Property

 Property Name: COMPONENTS

Royer, et al. Experimental [Page 56] RFC 4324 Calendar Access Protocol December 2005

 Purpose: The property specifies a the list of components supported by
    the endpoint.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: The property can be specified in a "VREPLY" component in
    response to a "GET-CAPABILITY" command.
 Description: A comma-separated list of components that are supported
    by the endpoint.  A component that is not in the list sent from
    the endpoint is not supported by that endpoint.  Sending an
    unsupported component results in unpredictable results.  This
    includes any components inside of other components (VALARM for
    example).  The recommended list is
    "VCALSTORE,VCALENDAR,VREPLY,VAGENDA,
    VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO,VALARM,
    DAYLIGHT,STANDARD,VCAR,VRIGHT,VQUERY".
 Formal Definition: The property is defined by the following notation:
    components     = "COMPONENTS" other-params ":" comp-list CRLF
                   ;
                   ; All of these MUST be supplied only once.
                   ;
    comp-list-req  = "VCALSTORE" "," "VCALENDAR" "," "VTIMEZONE" ","
                     "VREPLY"    "," "VAGENDA"   "," "STANDARD"  ","
                     "DAYLIGHT"
                   ; At least one MUST be supplied. The same value
                   ; MUST NOT occur more than once.
                   ;
    comp-list-min  = ( "," "VEVENT")
                   / ( "," "VTODO")
                   / ( "," "VJOURNAL" )
                   ; The same value MUST NOT occur
                   ; more than once.  If "VCAR" is supplied then
                   ; "VRIGHT" must be supplied.
                   ;
    comp-list-opt  = ( "," "VFREEBUSY" ) / ( "," "VALARM" )
                     / ( "," "VCAR" )    / ( "," "VRIGHT" )
                     / ( "," "VQUERY")   / ( "," x-comp )
                     / ( "," iana-comp )
                   ;
    comp-list      = comp-list-req 1*3comp-list-min *(comp-list-opt)
 Example: The following is an example of this property:

Royer, et al. Experimental [Page 57] RFC 4324 Calendar Access Protocol December 2005

       COMPONENTS:VCALSTORE,VCALENDAR,VREPLY,VAGENDA,
       VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO,
       DAYLIGHT,STANDARD,VFREEBUSY,VCAR,VRIGHT,VQUERY

8.9. CSID Property

 Property Name: CSID
 Purpose: The property specifies a globally unique identifier for the
    calendar store.
 Value Type: URI
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: The property can be specified in a "VCALSTORE"
    component.
 Description: The identifier MUST be globally unique.  Each CS needs
    its own unique identifier.  The "CSID" property is the official
    unique identifier for the CS.  If the BEEP 'serverName' attribute
    was supplied in the BEEP 'start' message, then the CSID will be
    mapped to the virtual host name supplied, and the host name part
    of the CSID MUST be the same as the 'serverName' value.  This
    allows one CS implementation to service multiple virtual hosts.
    CS's are not required to support virtual hosting.  If a CS does
    not support virtual hosting, then it must ignore the BEEP
    'serverName' attribute.
 Formal Definition: The property is defined by the following notation:
       csid = "CSID" other-params ":" capurl CRLF
 Example: The following is an example of this property:
       CSID:cap://calendar.example.com

8.10. DECREED Property

 Property Name: DECREED
 Purpose: This property specifies if an access right calendar
    component is decreed or not.
 Value Type: BOOLEAN

Royer, et al. Experimental [Page 58] RFC 4324 Calendar Access Protocol December 2005

 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property MAY be specified once in a "VCAR"
    component.
 Description: This property is used in the "VCAR" component to specify
    whether the component is decreed or not.  If the "DECREED"
    property value is "TRUE" then the CUA will be unable to change the
    contents of the "VCAR" component and any attempt will fail with an
    error.
 Formal Definition: The property is defined by the following notation:
       decreed      = "DECREED" other-params ":" boolean CRLF
 Example: The following is an example of this property:
       DECREED:TRUE

8.11. DEFAULT-CHARSET Property

 Property Name: DEFAULT-CHARSET
 Purpose: This property indicates the default charset.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in "VAGENDA" and
    "VCALSTORE" calendar component.
 Description: In a "VAGENDA" component this property is used to
    indicate the charset of calendar.  If not specified, the default
    is the first value in the "VCALSTORE" components "DEFAULT-CHARSET"
    property value list.  The value MUST be an IANA registered
    character set as defined in [CHARREG].
 In a "VCALSTORE" component it is a comma-separated list of charsets
    supported by the CS.  The first entry is the default entry for all
    newly created "VAGENDA" components.  The "UTF-8" value MUST be in
    the "VCALSTORE" component "DEFAULT-CHARSET" property list.  All
    compliant
    CAP implementations (CS and CUA) MUST support at least the "UTF-8"
    charset.

Royer, et al. Experimental [Page 59] RFC 4324 Calendar Access Protocol December 2005

    If a charset name contains a comma (,), that comma must be
    backslash-escaped in the value.
 Formal Definition: The property is defined by the following notation:
       default-charset     = "DEFAULT-CHARSET" other-params ":" text
       *( "," text) CRLF
 Example: The following is an example of this property for a "VAGENDA"
 component:
    DEFAULT-CHARSET:Shift_JIS,UTF-8

8.12. DEFAULT-LOCALE Property

 Property Name: DEFAULT-LOCALE
 Purpose: This property specifies the default language for text
    values.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in "VAGENDA" and
    "VCALSTORE" components.
 Description: In a "VAGENDA" component, the "DEFAULT-LOCALE" property
    is used to indicate the locale of the calendar.  The full locale
    SHOULD be used.  The default and minimum locale is POSIX (aka the
    'C' locale).
    In a "VCALSTORE" component, it is a comma-separated list of
    locales supported by the CS.  The first value in the list is the
    default for all newly created VAGENDAs.  "POSIX" MUST be in the
    list.
 Formal Definition: The property is defined by the following notation:
       default-locale     = "DEFAULT-LOCALE" other-params ":" language
                             *( "," language) CRLF
                  ;
       language = ; Text identifying a locale, as defined in [CHARPOL]
 Example: The following is an example of this property:
    DEFAULT-LOCALE:en-US.iso-8859-1,POSIX

Royer, et al. Experimental [Page 60] RFC 4324 Calendar Access Protocol December 2005

8.13. DEFAULT-TZID Property

 Property Name: DEFAULT-TZID
 Purpose: This property specifies the text value that specifies the
    time zones.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property may be specified once in a "VAGENDA" and
    "VCALSTORE" components.
 Description: A multi-valued property that lists the known time zones.
    The first is the default.  Here "TZID" property values are the
    same as the "TZID" property defined in [iCAL].
    If used in a "VCALSTORE" component, it is a comma-separated list
    of TZIDs known to the CS.  The entry is used as the default TZID
    list for all newly created calendars.  The list MUST contain at
    least "UTC".  A "VCALSTORE" components MUST contain one
    "VTIMEZONE" component for each value in the "DEFAULT-TZID"
    property value.
    If used in a "VAGENDA" component, it is a comma-separated list of
    "TZID" property values naming the time zones known to the
    calendar.  The first time zone in the list is the default and is
    used as the localtime for objects that contain a date or date-time
    value without a time zone.  All "VAGENDA" components MUST have one
    "VTIMEZONE" component contained for each value in the "DEFAULT-
    TZID" property value.
    If a "TZID" property value contains a comma (,), the comma must be
    backslash-escaped.
 Formal Definition: This property is defined by the following
    notation:
       default-tzid       = "DEFAULT-TZID" other-params
                            ":" [tzidprefix] text
                            *("," [tzidprefix] text) CRLF
                            ;
       txidprefix         = ; As defined in [iCAL].
 Example: The following is an example of this property:

Royer, et al. Experimental [Page 61] RFC 4324 Calendar Access Protocol December 2005

    DEFAULT-TZID:US/Mountain,UTC

8.14. DEFAULT-VCARS Property

 Property Name: DEFAULT-VCARS
 Purpose: This property is used to specify the "CARID" property ids of
    the default "VCAR" components for newly created "VAGENDA"
    components.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property MUST be specified in "VCALSTORE" calendar
    component and MUST at least specify the following values:
    "READBUSYTIMEINFO", "REQUESTONLY", "UPDATEPARTSTATUS", and
    "DEFAULTOWNER".
 Description: This property is used in the "VCALSTORE" component to
    specify the "CARID" value of the "VCAR" components that MUST be
    copied into now "VAGENDA" components at creation time by the CS.
    All "DEFAULT-VCAR" values must have "VCARS" components stored in
    the "VCALSTORE".
 Formal Definition: The property is defined by the following notation:
       defautl-vcars      = "DEFAULT-VCARS" other-params ":" text
       *( "," text ) CRLF
 Example: The following is an example of this property:
       DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY,
        UPDATEPARTSTATUS,DEFAULTOWNER

8.15. DENY Property

 Property Name: DENY
 Purpose: This property identifies the UPN(s) being denied access in
    the "VRIGHT" component.
 Value Type: UPN-FILTER
 Property Parameters: Non-standard property parameters can be
    specified on this property.

Royer, et al. Experimental [Page 62] RFC 4324 Calendar Access Protocol December 2005

 Conformance: This property can be specified in "VRIGHT" components.
 Description: This property is used in the "VRIGHT" component to
    define the CU or UG being denied access.
 Formal Definition: The property is defined by the following notation:
       deny       = "DENY" other-params ":" upn-filter CRLF
 Example: The following are examples of this property:
       DENY:*
       DENY:bob@example.com

8.16. EXPAND property

 Property Name: EXPAND
 Purpose: This property is used to notify the CS whether to expand any
    component with recurrence rules into multiple instances, in a
    query reply.
 Value Type: BOOLEAN
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in "VQUERY" components.
 Description: If a CUA wishes to see all of the instances of a
    recurring component, the CUA sets EXPAND=TRUE in the "VQUERY"
    component.  If not specified, the default is "FALSE".  Note that
    if the CS has its "RECUR-EXPAND" CS property value set to "FALSE",
    then the "EXPAND" property will be ignored and the result will be
    as if the "EXPAND" value was set to "FALSE".  The results will be
    bounded by any date range or other limits in the query.
 Formal Definition: The property is defined by the following notation:
       expand     = "EXPAND" other-params ":" ("TRUE" / "FALSE") CRLF
 Example: The following are examples of this property:
       EXPAND:FALSE
       EXPAND:TRUE

Royer, et al. Experimental [Page 63] RFC 4324 Calendar Access Protocol December 2005

8.17. GRANT Property

 Property Name: GRANT
 Purpose: This property identifies the UPN(s) being granted access in
    the "VRIGHT" component.
 Value Type: UPN-FILTER
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in "VRIGHT" calendar
    components.
 Description: This property is used in the "VRIGHT" component to
    specify the CU or UG being granted access.
 Formal Definition: The property is defined by the following notation:
       grant     = "GRANT" other-params ":" upn-filter CRLF
 Example: The following are examples of this property:
       GRANT:*
       GRANT:bob@example.com

8.18. ITIP-VERSION Property

 Property Name: ITIP-VERSION
 Purpose: This property specifies the version of ITIP supported.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property is specified in the "VREPLY" component
    that is sent in response to a "GET-CAPABILITY" command.
 Description: This specifies the version of ITIP that the endpoint
    supports.  The list is a comma-separated list of supported RFC
    numbers.  The list MUST contain at least 2446, which is [iTIP]
 Formal Definition: The property is defined by the following notation:

Royer, et al. Experimental [Page 64] RFC 4324 Calendar Access Protocol December 2005

       itip-version   = "ITIP-VERSION" other-params ":" text CRLF
 Example: The following are examples of this property:
       ITIP-VERSION:2446

8.19. MAX-COMP-SIZE Property

 Property Name: MAX-COMP-SIZE
 Purpose: This property specifies the largest size of any object
    accepted.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property is specified in the "VREPLY" component
    that is sent in response to a "GET-CAPABILITY" command.
 Description: A positive integer value that specifies the size of the
    largest iCalendar object that can be accepted in octets.  Objects
    larger than this will be rejected.  A value of zero (0) means no
    limit.  This is also the maximum value of any [BEEP] payload that
    will be accepted or sent.
 Formal Definition: The property is defined by the following notation:
       max-comp-size   = "MAX-COMP-SIZE" other-params ":" posint0 CRLF
 Example: The following are examples of this property:
       MAX-COMP-SIZE:1024

8.20. MAXDATE Property

 Property Name: MAXDATE
 Purpose: This property specifies the date/time in the future, beyond
    which the CS or CUA cannot represent.
 Value Type: DATE-TIME
 Property Parameters: Non-standard property parameters can be
    specified on this property.

Royer, et al. Experimental [Page 65] RFC 4324 Calendar Access Protocol December 2005

 Conformance: The property can be specified in the "VCALSTORE"
    component.
 Description: The date and time MUST be a UTC value and end with 'Z'.
 Formal Definition: The property is defined by the following notation:
       maxdate    = "MAXDATE" other-params ":" date-time CRLF
 Example: The following is an example of this property:
       MAXDATE:20990101T000000Z

8.21. MINDATE Property

 Property Name: MINDATE
 Purpose: This property specifies the date/time in the past, prior to
    which the server cannot represent.
 Value Type: DATE-TIME
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: The property can be specified in the "VCALSTORE"
    component.
 Description: The date and time MUST be a UTC value and end with 'Z'.
 Formal Definition: The property is defined by the following notation:
       mindate    = "MINDATE" other-params ":" date-time CRLF
       date-time = ; As defined in [iCAL].
 Example: The following is an example of this property:
       MINDATE:19710101T000000Z

8.22. MULTIPART Property

 Property Name: MULTIPART
 Purpose: This property provides a comma-separated list of supported
    MIME multipart types supported by the sender.

Royer, et al. Experimental [Page 66] RFC 4324 Calendar Access Protocol December 2005

 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property is specified in the "VREPLY" component
    that is sent in response to a "GET-CAPABILITY" command.
 Description: This property is used in the in the "GET-CAPABILITY"
    command reply to indicate the MIME multipart types supported.  A
    CS and CUA SHOULD support all registered MIME multipart types.
 Formal Definition: The property is defined by the following notation:
       multipart = "MULTIPART" other-params ":" text *( "," text) CRLF
 Example: The following is an example of this property:
       MULTIPART:related,alternate,mixed

8.23. NAME Property

 Property Name: NAME
 Purpose: This property provides a localizable display name for a
    component.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in a component.
 Description: This property is used in the component to specify a
    localizable display name.  If more than one "NAME" properties are
    in a component, then they MUST have unique "LANG" parameters.  If
    the "LANG" parameter is not supplied, then it defaults to the
    "VAGENDA" component's "DEFAULT-LOCALE" first value.  If the
    component is a "VAGENDA", then the default value is the "VAGENDA"s
    component's "DEFAULT-LOCALE" first value.  A "VCALSTORE"
    component's "DEFAULT-LOCALE" first value is the default if the
    component is stored at the "VCALSTORE" level.
 Formal Definition: The property is defined by the following notation:

Royer, et al. Experimental [Page 67] RFC 4324 Calendar Access Protocol December 2005

       name          = "NAME" nameparam ":" text CRLF
                       ;
       nameparam     = other-params [ ";" languageparam ] other-params
                       ;
       languageparam = ; As defined in [iCAL].
 Example: The following is an example of this property:
       NAME:Restrict Guests From Creating VALARMs On VEVENTs

8.24. OWNER Property

 Property Name: OWNER
 Purpose: The property specifies an owner of the component.
 Value Type: UPN
 Property Parameters: Non-standard, alternate text representation and
    language property parameters can be specified on this property.
 Conformance: The property MUST be specified in a "VAGENDA" component.
 Description: A multi-instanced property indicating the calendar
    owner.
 Formal Definition: The property is defined by the following notation:
       owner = "OWNER" other-params ":" upn CRLF
 Example: The following is an example of this property:
       OWNER:jsmith@example.com
       OWNER:jdough@example.com

8.25. PERMISSION Property

 Property Name: PERMISSION
 Purpose: This property defines a permission that is granted or denied
    in a "VRIGHT" component.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in "VRIGHT" components.

Royer, et al. Experimental [Page 68] RFC 4324 Calendar Access Protocol December 2005

 Description: This property is used in the "VRIGHT" component to
    define a permission that is granted or denied.
 Formal Definition: The property is defined by the following notation:
       permission  = "PERMISSION" other-params ":" permvalue CRLF
                     ;
       permvalue = ( "SEARCH" / "CREATE" / "DELETE"
                   / "MODIFY" / "MOVE" / all
                   / iana-cmd / x-cmd )
                     ;
       all         = "*"
                     ;
       iana-cmd    = ; Any command registered by IANA directly or
                     ; included in an RFC that may be applied as
                     ; a command.
                     ;
       x-cmd       = ; Any experimental command that starts with
                     ; "x-" or "X-".
 Example: The following is an example of this property:
    PERMISSION:SEARCH

8.26. QUERY property

 Property Name: QUERY
 Purpose: Specifies the query for the component.
 Value Type: CAL-QUERY
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in "VQUERY" components.
 Description: A "QUERY" is used to specify the "CAL-QUERY" (Section
    6.1.1 for the query.
 Formal Definition: The property is defined by the following notation:
       query      = "QUERY" other-params ":" cal-query CRLF
 Example: The following is an example of this property:
       QUERY:SELECT * FROM VEVENT

Royer, et al. Experimental [Page 69] RFC 4324 Calendar Access Protocol December 2005

8.27. QUERYID property

 Property Name: QUERYID
 Purpose: Specifies a unique ID for a query in the targeted container.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters are specified
    on this property.
 Conformance: This property can be specified in "VQUERY" components.
 Description: A "QUERYID" property is used to specify the unique id
    for a query.  A "QUERYID" property value is unique per container.
 Formal Definition: The property is defined by the following notation:
       queryid      = "QUERYID" other-params ":" text CRLF
 Example: The following are examples of this property:
    QUERYID:Any Text String
    QUERYID:fetchUnProcessed

8.28. QUERY-LEVEL Property

 Property Name: QUERY-LEVEL
 Purpose: This property specifies the level of query supported.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: The property can be specified in the "VREPLY" component
    in response to a "GET-CAPABILITY" command.
 Description: Indicates level of query support.  CAL-QL-NONE is for
    CS's that allow ITIP methods only to be deposited and nothing
    else.
 Formal Definition: The property is defined by the following notation:
       query-level = "QUERY-LEVEL" other-params
                       ":" ( "CAL-QL-1" / "CAL-QL-NONE") CRLF

Royer, et al. Experimental [Page 70] RFC 4324 Calendar Access Protocol December 2005

 Example: The following is an example of this property:
       QUERY-LEVEL:CAL-QL-1

8.29. RECUR-ACCEPTED Property

 Property Name: RECUR-ACCEPTED
 Purpose: This property specifies if the endpoint supports recurring
    instances.
 Value Type: BOOLEAN
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: The property can be specified in the "VREPLY" component
    in response to a "GET-CAPABILITY" command.
 Description: Indicates if recurrence rules are supported.  If "FALSE"
    then the endpoint cannot process any kind of recurring rules.
 Formal Definition: The property is defined by the following notation:
       recur-accepted = "RECUR-ACCEPTED" other-params ":" boolean CRLF
 Example: The following is an example of this property:
       RECUR-ACCEPTED:TRUE
       RECUR-ACCEPTED:FALSE

8.30. RECUR-LIMIT Property

 Property Name: RECUR-LIMIT
 Purpose: This property specifies the maximum number of instances the
    endpoint will expand instances at query or storage time.
 Value Type: INTEGER
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: The property can be specified in the "VREPLY" component
    in response to a "GET-CAPABILITY" command.
 Description: For implementations that have the "STORES-EXPANDED"
    value set to "TRUE", this value specifies the maximum number of

Royer, et al. Experimental [Page 71] RFC 4324 Calendar Access Protocol December 2005

    instances that will be stored and fetched.  For all
    implementations, this is the maximum number of instances that will
    be returned when the "EXPAND" parameter is specified as "TRUE" and
    the results contain an infinite or large number of recurring
    instances.
 Formal Definition: The property is defined by the following notation:
       recur-limit = "RECUR-LIMIT" other-params ":" posint1 CRLF
 Example: The following is an example of this property:
       RECUR-LIMIT:1000

8.31. RECUR-EXPAND Property

 Property Name: RECUR-EXPAND
 Purpose: This property specifies if the endpoint can expand
    recurrences into multiple objects.
 Value Type: BOOLEAN
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: The property can be specified in the "VREPLY" component
    in response to a "GET-CAPABILITY" command.
 Description: If "TRUE", then the endpoint can expand an object into
    multiple instances as defined by its recurrence rules when the
    "EXPAND" property is supplied.  If "FALSE", then the endpoint
    ignores the "EXPAND" property.
 Formal Definition: The property is defined by the following notation:
       recur-expand = "RECUR-EXPAND" other-params ":" boolean CRLF
 Example: The following is an example of this property:
       RECUR-EXPAND:TRUE
       RECUR-EXPAND:FALSE

8.32. RESTRICTION Property

 Property Name: RESTRICTION

Royer, et al. Experimental [Page 72] RFC 4324 Calendar Access Protocol December 2005

 Purpose: This property defines restrictions on the result value of
    new or existing components.
 Value Type: CAL-QUERY
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in "VRIGHT" components,
    but only when the "PERMISSION" property is set to "CREATE",
    "MODIFY", or "*" property value.
 Description: This property is used in the "VRIGHT" component to
    define restrictions on the components that can be written (i.e.,
    by using the "CREATE" or "MOVE" commands) as well as on the values
    that may take existent calendar store properties, calendar
    properties, components, and properties (i.e., by using the
    "MODIFY" command).  Accepted values MUST match any specified
    "RESTRICTION" property values.
 Formal Definition: The property is defined by the following notation:
       restriction  = "RESTRICTION" other-params ":" cal-query CRLF
 Example: The following are examples of this property:
       RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST'
       RESTRICTION:SELECT * FROM VEVENT WHERE
       SELF() IN ORGANIZER
       RESTRICTION:SELECT * FROM VEVENT WHERE 'BUSINESS' IN
       CATEGORIES

8.33. SCOPE Property

 Property Name: SCOPE
 Purpose: This property identifies the objects in the CS to which the
    access rights apply.
 Value Type: CAL-QUERY
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in "VRIGHT" components.

Royer, et al. Experimental [Page 73] RFC 4324 Calendar Access Protocol December 2005

 Description: This property is used in the "VRIGHT" component to
    define the set of objects, subject to the access right being
    defined.
 Formal Definition: The property is defined by the following notation:
       scope    = "SCOPE" other-params ":" cal-query CRLF
 Example: The following is an example of this property:
       SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC'

8.34. STORES-EXPANDED Property

 Property Name: STORES-EXPANDED
 Purpose: This property specifies if the sending endpoint expands
    recurrence rules prior to storing them into the CS.
 Value Type: BOOLEAN
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in a "VREPLY" component
    in response to a "GET-CAPABILITY" command.
 Description: If the value is "TRUE", then the endpoint expands
    recurrence rules and stores the results into the CS.  If this is
    "TRUE", then the "RECUR-LIMIT" property is significant because an
    infinitely-recurring appointment will store no more than "RECUR-
    LIMIT" property values into the CS and all other instances will be
    lost.
 Formal Definition: The property is specified by the following
    notation:
       stores-expanded   = "STORES-EXPANDED" other-params ":" boolean
    CRLF
 The following is an example of this property:
       STORES-EXPANDED:TRUE
       STORES-EXPANDED:FALSE

8.35. TARGET Property

 Property Name: TARGET

Royer, et al. Experimental [Page 74] RFC 4324 Calendar Access Protocol December 2005

 Purpose: This property defines the container that the issued command
    will act upon.  Its value is a capurl, as defined in Section 5.
 Value Type: URI
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in a command component.
 Description: This property value is used to specify the container
    that the command will effect.  When used in a command, the command
    will be performed on the container that has a capurl matching the
    value.
 Formal Definition: The property is specified by the following
    notation:
       target   = "TARGET" other-params ":" ( capurl / relcalid ) CRLF
 Example: The following is an example of this property:
       TARGET:cap://mycal.example.com
       TARGET:SomeRelCalid

8.36. TRANSP Property

 Property Name: TRANSP
 Purpose: This property defines whether a component is transparent or
    not to busy-time searches.  This is a modification to [iCAL]
    "TRANSP" property, in that it adds some values.
 Value Type: TEXT
 Property Parameters: Non-standard property parameters can be
    specified on this property.
 Conformance: This property can be specified in a component.
 Description: Time Transparency is the characteristic of an object
    that determines whether it appears to consume time on a calendar.
    Objects that consume actual time for the individual or resource
    associated with the calendar SHOULD be recorded as "OPAQUE",
    allowing them to be detected by free-busy time searches.  Other
    objects, which do not take up the individual's (or resource's)
    time SHOULD be recorded as "TRANSPARENT", making them invisible to
    free/busy time searches.

Royer, et al. Experimental [Page 75] RFC 4324 Calendar Access Protocol December 2005

 Formal Definition: The property is specified by the following
    notation:
       transp    = "TRANSP" other-params ":" transvalue CRLF
                   ;
       transvalue = "OPAQUE" ;Blocks or opaque on busy time searches.
                 / "TRANSPARENT"
                         ; Transparent on busy time searches.
                 / "TRANSPARENT-NOCONFLICT"
                         ; Transparent on busy time searches,
                         ; and no other OPAQUE or OPAQUE-
                         ; NOCONFLICT objects can overlap it.
                         ;
                 / "OPAQUE-NOCONFLICT"
                         ; Opaque on busy time searches, and
                         ; no other OPAQUE or OPAQUE-NOCONFLICT
                         ; objects can overlap it.
                         ;
                         ; Default value is OPAQUE
    The following is an example of this property for an object that is
    opaque or blocks on free/busy time searches, and no other object
    can overlap it:
       TRANSP:OPAQUE-NOCONFLICT

9. New Components

9.1. VAGENDA Component

 Component Name: VAGENDA
 Purpose: Provide a grouping of properties that defines an agenda.
 Formal Definition: There are two formats of the "VAGENDA" component.
    (1) When it is being created, and (2) how it exists in the
    "VCALSTORE" component.
    A "VAGENDA" component in a "VCALSTORE" component is defined by the
    following notes and ABNF notation:
       CALSCALE -  The value MUST be from the "VCALSTORE" "CALSCALE"
          property list.  The default is the first entry in the
          VCALSTORE CALSCALE list.
       CREATED -  The timestamp of the calendar's create date.  This

Royer, et al. Experimental [Page 76] RFC 4324 Calendar Access Protocol December 2005

          is a READ ONLY property in a "VAGENDA".
       LAST-MODIFIED - The timestamp of any change to the "VAGENDA"
          properties or when any component was last created, modified,
          or deleted.
    agenda      = "BEGIN" ":" "VAGENDA" CRLF
                  agendaprop
                  *(icalobject)     ; as defined in [iCAL]
                  "END" ":" "VAGENDA" CRLF
    agendaprop  = *(
                  ; The following MUST occur exactly once.
                  ;
                    allow-conflict / relcalid / calscale / created
                  / default-charset / default-locale
                  / default-tzid / last-mod
                  ;
                  ; The following MUST occur at least once.
                  ; and the value MUST NOT be empty.
                  ;
                  / owner
                  ;
                  ; The following are optional,
                  ; and MAY occur more than once.
                  ;
                  / name / related-to / other-props / x-comp
                )
    icalobject = ; As defined in [iCAL].
                 ;
    created    = ; As defined in [iCAL].
                 ;
    related-to = ; As defined in [iCAL].
 When creating a VAGENDA, use the following notation:
    agendac     = "BEGIN" ":" "VAGENDA" CRLF
                  agendacprop
                  *(icalobject)     ; as defined in [iCAL].
                  "END" ":" "VAGENDA" CRLF
    agendacprop  = *(
                   ; The following MUST occur exactly once.
                   ;
                     allow-conflict / relcalid / calscale
                   / default-charset / default-locale
                   / default-tzid

Royer, et al. Experimental [Page 77] RFC 4324 Calendar Access Protocol December 2005

                   ;
                   ; The following MUST occur at least once.
                   ; and the value MUST NOT be empty.
                   ;
                   / owner
                   ;
                   ; The following are optional,
                   ; and MAY occur more than once.
                   ;
                   / name / related-to / other-props / x-comp
                  )
 To fetch all of the properties from the targeted "VAGENDA" component
 but do not fetch any components, use:
    SELECT * FROM VAGENDA
 To fetch all of the properties from the targeted VAGENDA and all of
 the contained components, use the special '*.*' value:
    SELECT *.* FROM VAGENDA

9.2. VCALSTORE Component

 Component Name: VCALSTORE
 Purpose: Provide a grouping of properties that defines a calendar
    store.
 Formal Definition: A "VCALSTORE" component is defined by the
    following table and ABNF notation.  The creation of a "VCALSTORE"
    component is an administrative task and not part of the CAP
    protocol.
    The following are notes to some of the properties in the
    "VCALSTORE" component.
       CALSCALE -  A comma-separated list of CALSCALEs supported by
          this CS.  All "VAGENDA" component calendar CALSCALE
          properties MUST be from this list.  This list MUST contain
          at least "GREGORIAN".  The default for newly created
          "VAGENDA" components is the first entry.
       RELATED-TO -  This is a multiple-instance property.  There MUST
          be a "RELATED-TO" property for each of the "VAGENDA"
          components contained in the "VCALSTORE" component, each with
          the "RELTYPE" parameter value set to "CHILD".  Other
          "RELATED-TO" properties may be included.

Royer, et al. Experimental [Page 78] RFC 4324 Calendar Access Protocol December 2005

       CREATED -  The timestamp of the CS creation time.  This is a
          READ ONLY property.
       CSID -  The CSID of this calendar store.  This MUST NOT be
          empty.  How this property is set in the VCALSTORE is an
          administrative or implementation-specific issue and is not
          covered in CAP.  This is a READ ONLY property.  A suggested
          value is the fully-qualified host name or a fully-qualified
          virtual host name supported by the system.
       LAST-MODIFIED -  The timestamp when the Properties of the
          "VCALSTORE" component were last updated or calendars were
          created or deleted.  This is a READ ONLY PROPERTY.
    calstorec     = "BEGIN" ":" "VCALSTORE" CRLF
                 calstoreprop
                 *(vagendac)
                 "END" ":" "VCALSTORE" CRLF
                      ;
    calstoreprop  = *(
                      ; the following MUST occur exactly once
                      ;
                        allow-conflict / calscale / calmaster
                      / created / csid / default-charset
                      / default-locale / default-vcars
                      / default-tzid / last-mod / maxdate / mindate
                      ;
                      ; the following are optional,
                      ; and MAY occur more than once
                      ;
                      / name / related-to / other-props / x-comp
                     )
                   ;
    vagendac     = ; As defined in [iCAL].
                   ;
    last-mod     = ; As defined in [iCAL].
 To fetch all of the properties from the targeted VCALSTORE and not
 fetch the calendars that it contains, use:
    SELECT * FROM VCALSTORE
 To fetch all of the properties from the targeted "VCALSTORE"
 component and all of the contained calendars and all of those
 calendars' contained properties and components, use the special '*.*'
 value:

Royer, et al. Experimental [Page 79] RFC 4324 Calendar Access Protocol December 2005

    SELECT *.* FROM VCALSTORE

9.3. VCAR Component

 Component Name: VCAR
 Purpose: Provide a grouping of calendar access rights.
 Formal Definition: A "VCAR" component is defined by the following
    notation:
       carc    =  "BEGIN" ":" "VCAR" CRLF
                  carprop 1*rightc
                  "END" ":" "VCAR" CRLF
               ;
       carprop = 1*(
               ;
               ; 'carid' is REQUIRED,
               ; but MUST NOT occur more than once
               ;
                carid /
               ;
               ; the following are OPTIONAL,
               ; and MAY occur more than once
               ;
        name / decreed / other-props
       )
 Description: A "VCAR" component is a grouping of properties, and
    "VRIGHT" components, that represents access rights granted or
    denied to UPNs.
    The "CARID" property specifies the local identifier for the "VCAR"
    component.  The "NAME" property specifies a localizable display
    name.
 Example: In the following example, the UPN "foo@example.com" is given
    search access to the "DTSTART" and "DTEND" VEVENT properties.  No
    other access is specified:

Royer, et al. Experimental [Page 80] RFC 4324 Calendar Access Protocol December 2005

       BEGIN:VCAR
       CARID:View Start and End Times
       NAME:View Start and End Times
       BEGIN:VRIGHT
       GRANT:foo@example.com
       PERMISSION:SEARCH
       SCOPE:SELECT DTSTART,DTEND FROM VEVENT
       END:VRIGHT
       END:VCAR
    In this example, all UPNs are given search access to "DTSTART" and
    "DTEND" properties of VEVENT components.  "All CUs and UGs" are
    specified by the UPN value "*".  Note that this enumerated UPN
    value is not in quotes:
       BEGIN:VCAR
       CARID:ViewStartEnd2
       NAME:View Start and End Times 2
       BEGIN:VRIGHT
       GRANT:*
       PERMISSION:SEARCH
       SCOPE:SELECT DTSTART,DTEND FROM VEVENT
       END:VRIGHT
       END:VCAR
    In these examples, full calendar access rights are given to the
    CAL-OWNERS(), and a hypothetical administrator is given access
    rights to specify calendar access rights.  If no other rights are
    specified, only these two UPNs can specify calendar access rights:
       BEGIN:VCAR
       CARID:some-id-3
       NAME:Only OWNER or ADMIN Settable VCARs
       BEGIN:VRIGHT
       GRANT:CAL-OWNERS()
       PERMISSION:*
       SCOPE:SELECT * FROM VAGENDA
       END:VRIGHT
       BEGIN:VRIGHT
       GRANT:cal-admin@example.com
       PERMISSION:*
       SCOPE:SELECT * FROM VCAR
       RESTRICTION:SELECT * FROM VCAR
       END:VRIGHT
       END:VCAR
    In this example, rights to write, search, modify or delete
    calendar access are denied to all UPNs.  This example would

Royer, et al. Experimental [Page 81] RFC 4324 Calendar Access Protocol December 2005

    disable providing different access rights to the calendar store or
    calendar.  This calendar access right should be specified with
    great care, as it removes the ability to change calendar access;
    even for the owner or administrator.  It could be used by small
    devices that do not support changing any VCAR:
       BEGIN:VCAR
       CARID:VeryRestrictiveVCAR-2
       NAME:No CAR At All
       BEGIN:VRIGHT
       DENY:*
       PERMISSION:*
       SCOPE:SELECT * FROM VCAR
       END:VRIGHT
       END:VCAR

9.4. VRIGHT Component

 Component Name: "VRIGHT"
 Purpose: Provide a grouping of properties that describe an access
    right (granted or denied).
 Formal Definition: A "VRIGHT" component is defined by the following
    notation:
       rightc    = "BEGIN" ":" "VRIGHT" CRLF
                   rightprop
                   "END" ":" "VRIGHT" CRLF
                 ;
       rightprop = 2*(
                 ;
                 ; either 'grant' or 'deny' MUST
                 ; occur at least once
                 ; and MAY occur more than once
                 ;
                  grant / deny /
                 ;
                 ; 'permission' MUST occur at least once
                 ; and MAY occur more than once
                 ;
                  permission /
                 ;
                 ; the following are optional,
                 ; and MAY occur more than once
                 ;
                  scope / restriction / other-props
              )

Royer, et al. Experimental [Page 82] RFC 4324 Calendar Access Protocol December 2005

 Description: A "VRIGHT" component is a grouping of calendar access
    right properties.
    The "GRANT" property specifies the UPN that is being granted
    access.  The "DENY" property specifies the UPN that is being
    denied access.  The "PERMISSION" property specifies the actual
    permission being set.  The "SCOPE" property identifies the
    calendar store properties, calendar properties, components, or
    properties to which the access right applies.  The "RESTRICTION"
    property specifies restrictions on commands and results.  If the
    command does not match the restrictions, or if the results of the
    command do not match the restrictions, then it is an access
    violation.

9.5. VREPLY Component

 Component Name: "VREPLY"
 Purpose: Provide a grouping of arbitrary properties and components
    that are the data set result from an issued command.
 Formal Definition: A "VREPLY" component is defined by the following
    notation:
    replyc           =  "BEGIN" ":" "VREPLY" CRLF
                        any-prop-or-comp
                        "END" ":" "VREPLY" CRLF
                     ;
    any-prop-or-comp = ; Zero or more iana or experimental
                       ; properties and components, in any order.
 Description: Provide a grouping of arbitrary properties and
    components that are the data set result from an issued command.
    A query can return a predictable set of arbitrary properties and
    components.  This component is used by query and other commands to
    return data that does not fit into any other component.  It may
    contain any valid property or component, even if they are not
    registered.

9.6. VQUERY Component

 Component Name: VQUERY
 Purpose: A component describes a set of objects to be acted upon.

Royer, et al. Experimental [Page 83] RFC 4324 Calendar Access Protocol December 2005

 Formal Definition: A "VQUERY" component is defined by the following
    notation:
    queryc    =  "BEGIN" ":" "VQUERY" CRLF
                 queryprop
                 "END" ":" "VCAR" CRLF
              ;
    queryprop = 1*(
              ;
              ; 'queryid' is OPTIONAL but MUST NOT occur
              ; more than once. If the "TARGET" property
              ; is supplied then the "QUERYID" property
              ; MUST be supplied.
              ;
               queryid / target
              ;
              ; 'expand' is OPTIONAL but MUST NOT occur
              ; more than once.
              ;
               expand
              ;
              ; the following are OPTIONAL, and MAY occur
              ; more than once
              ;
              / name / other-props
              ;
              ; the following MUST occur at least once if
              ; queryid is not supplied.
              ;
              / query
            )
 Description: A "VQUERY" contains properties that describe which
    properties and components the CS is requested to act upon.
    The "QUERYID" property specifies the local identifier for a
    "VQUERY" component.
    For a search, if the "TARGET" property is supplied in a "VQUERY"
    component, then the CS is to search for the query in the CALID
    supplied by the "TARGET" property value.
    For a create, the "TARGET" property MUST NOT be supplied because
    the destination container is already supplied in the "TARGET"
    property of the "VCALENDAR" component.
 Examples: see Section 6.1.1.

Royer, et al. Experimental [Page 84] RFC 4324 Calendar Access Protocol December 2005

10. Commands and Responses

 CAP commands and responses are described in this section.

10.1. CAP Commands (CMD)

 All commands are sent using the CMD property.
 Property Name: CMD
 Purpose: This property defines the command to be sent.
 Value Type: TEXT
 Property Parameters: Non-standard, id, localize, latency, action or
    options.
 Conformance: This property is the method used to specify the commands
    to a CS; it can exist in any object sent to the CS.
 Description: All of the commands to the CS are supplied in this
    property.  The "OPTIONS" parameter is overloaded and its meaning
    is dependent on the CMD value supplied.
    Formal Definition: The property is defined by the following
    notation:
       cmd              = "CMD" (
                          abort-cmd
                        / continue-cmd
                        / create-cmd
                        / delete-cmd
                        / generate-uid-cmd
                        / get-capability-cmd
                        / identify-cmd
                        / modify-cmd
                        / move-cmd
                        / reply-cmd
                        / search-cmd
                        / set-locale-cmd
                        / iana-cmd
                        / x-cmd
                         ) CRLF
                       ;
       option-value    = "OPTION" "=" paramtext
                       ;
       paramtext       ; As defined in [iCAL].

Royer, et al. Experimental [Page 85] RFC 4324 Calendar Access Protocol December 2005

 Calendaring commands allow a CUA to directly manipulate a calendar.
 Calendar access rights can be granted or denied for any commands.

10.1.1. Bounded Latency

 A CAP command can have an associated maximum latency time by
 specifying the "LATENCY" parameter.  If the command is unable to be
 completed in the specified amount of time (as specified by the
 "LATENCY" parameter value with an "ACTION" parameter set to the "ASK"
 value), then a "TIMEOUT" command MUST be sent on the same channel".
 The reply MUST be a an "ABORT" or a "CONTINUE" command.  If the CUA
 initiated the original command, then the CS would issue the "TIMEOUT"
 command and the CUA would then have to issue an "ABORT" or "CONTINUE"
 command.  If the CS initiated the original command then the CUA would
 have to issue the "TIMEOUT" and the CS would send the "ABORT" or
 "CONTINUE".
 Upon receiving an "ABORT" command, the command must then be
 terminated.  Only the "ABORT", "TIMEOUT", "REPLY, and "CONTINUE"
 commands cannot be aborted.  The "ABORT", "TIMEOUT", and "REPLY"
 commands MUST NOT have latency set.
 Upon receiving a "CONTINUE" command the work continues as if it had
 not been delayed or stopped.  Note that a new latency time MAY be
 included in a "CONTINUE" command indicating to continue the original
 command until the "LATENCY" parameter value expires or the results of
 the original command can be returned.
 Both the "LATENCY" parameter and the "ACTION" parameter MUST be
 supplied to any "CMD" property, or nether can be added to the "CMD"
 property.  The "LATENCY" parameter MUST be set to the maximum latency
 time in seconds.  The "ACTION" parameter accepts the following
 values: "ASK" and "ABORT" parameters.
 If the maximum latency time is exceeded and the "ACTION" parameter is
 set to the "ASK" value, then "TIMEOUT" command MUST be sent.
 Otherwise, if the "ACTION" parameter is set to the "ABORT" value,
 then the command MUST be terminated and return a REQUEST-STATUS code
 of 2.0.3 for the original command.
 If a CS can both start sending the reply to a command and guarantee
 that all of the results can be sent from a command (short of
 something like network or power failure) prior to the "LATENCY"
 timeout value, then the "LATENCY" time has not expired.
 Example:

Royer, et al. Experimental [Page 86] RFC 4324 Calendar Access Protocol December 2005

 In this example the initiator asks for the listeners capabilities.
    I: Content-Type: text/calendar
    I:
    I: BEGIN:VCALENDAR
    I: VERSION:2.0
    I: PRODID:The CUA's PRODID
    I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY
    I: END:VCALENDAR
 # After 3 seconds
    L: Content-Type: text/calendar
    L:
    L: BEGIN:VCALENDAR
    L: PRODID:-//someone's prodid
    L: VERSION:2.0
    L: CMD;ID=xyz12346:TIMEOUT
    L: END:VCALENDAR
 In order to continue and give the CS more time, the CUA would issue a
 "CONTINUE" command:
    I: Content-Type: text/calendar
    I:
    I: BEGIN:VCALENDAR
    I: VERSION:2.0
    I: PRODID:-//someone's prodid
    I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:CONTINUE
    I: END:VCALENDAR
    L: Content-Type: text/calendar
    L:
    L: BEGIN:VCALENDAR
    L: VERSION:2.0
    L: PRODID:-//someone's prodid
    L: CMD;ID=xyz12346:REPLY
    L: BEGIN:VREPLY
    L: REQUEST-STATUS:2.0.3;Continued for 3 more seconds
    L: END:VREPLY
    L: END:VCALENDAR
 Here the "2.0.3" status is returned because it is not an error, it is
 a progress status sent in reply to the "CONTINUE" command.
 To abort the command and not wait any further, issue an "ABORT"
 command:

Royer, et al. Experimental [Page 87] RFC 4324 Calendar Access Protocol December 2005

    I: Content-Type: text/calendar
    I:
    I: BEGIN:VCALENDAR
    I: VERSION:2.0
    I: PRODID:-//someone's prodid
    I: CMD;ID=xyz12346:ABORT
    I: END:VCALENDAR
 # Which would result in a 2.0.3 reply.
    L: Content-Type: text/calendar
    L:
    L: BEGIN:VCALENDAR
    L: VERSION:2.0
    L: PRODID:-//someone's prodid
    L: CMD;ID=xyz12346:REPLY
    L: BEGIN:VREPLY
    L: REQUEST-STATUS:2.0.3;Aborted As Requested.
    L: END:VREPLY
    L: END:VCALENDAR
 If the "ACTION" value had been set to "ABORT", then the listner would
 send a "7.0" error on timeout in the reply to the command that
 initiated the command that timed out.

10.2. ABORT Command

 CMD: ABORT
 Purpose: The "ABORT" command is sent to request that the named or the
    only in-process command be aborted.  Latency MUST not be supplied
    with the "ABORT" command.
 Formal Definition: An "ABORT" command is defined by the following
    notation:

Royer, et al. Experimental [Page 88] RFC 4324 Calendar Access Protocol December 2005

       abort-cmd    = abortparam ":" "ABORT"
                    ;
       abortparam   = *(
                    ;
                    ; the following are optional,
                    ; but MUST NOT occur more than once
                    ;
                      id-param
                    / localize-param
                    ;
                    ; the following is optional,
                    ; and MAY occur more than once
                    ;
                    / other-params
                    )
       The REPLY of any "ABORT" command is:
       abort-reply  = "BEGIN" ":" "VCALENDAR" CRLF
                       calprops
                       abort-vreply
                      "END" ":" "VCALENDAR" CRLF
                    ;
       abort-vreply = "BEGIN" ":" "VREPLY" CRLF
                       rstatus
                       other-props
                       "END" ":" "VREPLY" CRLF

10.3. CONTINUE Command

 CMD: CONTINUE
 Purpose: The "CONTINUE" command is only sent after a "TIMEOUT"
    command has been received to inform the other end of the session
    to resume working on a command.
 Formal Definition: A "CONTINUE" command is defined by the following
    notation:
       continue-cmd   = continueparam ":" "CONTINUE"
                    ;
       continueparam  = *(
                    ;
                    ; the following are optional,
                    ; but MUST NOT occur more than once
                    ;
                         id-param
                       / localize-param

Royer, et al. Experimental [Page 89] RFC 4324 Calendar Access Protocol December 2005

                       / latency-param
                    ;
                    ; the following MUST occur exactly once and only
                    ; when the latency-param has been supplied and
                    ; MUST NOT be supplied if the latency-param is
                    ; not supplied.
                    ;
                       / action-param
                    ;
                    ; the following are optional,
                    ; and MAY occur more than once
                    ;
                       / other-params
                       )
    The REPLY of any "CONTINUE" command is:
       continue-reply   = "BEGIN" ":" "VCALENDAR" CRLF
                          calprops
                          continue-vreply
                          "END" ":" "VCALENDAR" CRLF
                        ;
       continue-vreply  = "BEGIN" ":" "VREPLY" CRLF
                          rstatus
                          other-props
                          "END" ":" "VREPLY" CRLF

10.4. CREATE Command

 CMD: CREATE
 Purpose:  The "CREATE" command is used to create one or more
    iCalendar objects in the store in the "BOOKED" or "UNPROCESSED"
    state.
    A CUA MAY send a "CREATE" command to a CS.  The "CREATE" command
    MUST be implemented by all CSs.
    The CS MUST NOT send a "CREATE" command to any CUA.
 Formal Definition: A "CREATE" command is defined by the following
    notation and the hierarchy restrictions, as defined in Section
    3.2:
       create-cmd     = createparam ":" "CREATE"
                    ;
       createparam    = *(
                    ;

Royer, et al. Experimental [Page 90] RFC 4324 Calendar Access Protocol December 2005

                    ; the following are optional,
                    ; but MUST NOT occur more than once
                    ;
                        id-param
                      / localize-param
                      / latency-param
                    ;
                    ; the following MUST occur exactly once and only
                    ; when the latency-param has been supplied and
                    ; MUST NOT be supplied if the latency-param is
                    ; not supplied.
                    ;
                      / action-param
                    ;
                    ; the following is optional,
                    ; and MAY occur more than once
                    ;
                      / other-params
                     )
 Response:
    One iCalendar object per TARGET property MUST be returned.
    The REPLY of any "CREATE" command is limited to the restriction
    tables defined in [iTIP] for iTIP objects, in addition to this
    ABNF:

Royer, et al. Experimental [Page 91] RFC 4324 Calendar Access Protocol December 2005

    create-reply   = "BEGIN" ":" "VCALENDAR" CRLF
                      creply-props
                      1*(create-vreply)
                      "END" ":" "VCALENDAR" CRLF
                   ;
    create-vreply  = "BEGIN" ":" "VREPLY" CRLF
                     created-id
                     rstatus
                     other-props
                     "END" ":" "VREPLY" CRLF
                   ;
                   ; Where the id is appropriate for the
                   ; type of object created:
                   ;
                   ; VAGENDA = relcalid
                   ; VALARM = sequence
                   ; VCAR = carid
                   ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
                   ; VQUERY = queryid
                   ; VTIMEZONE = tzid
                   ; x-comp = x-id
                   ;
    created-id    = ( relcalid / carid / uid / queryid /
                      tzid / sequence / x-id)
                    ;
    tzid          = ; As defined in [iCAL].
                    ;
    sequence      = ; As defined in [iCAL].
                    ;
    uid           = ; As defined in [iCAL].
                    ;
    x-id          = ; An ID for an x-component.
                    ;
    creply-props  = 4*(
                    ; These are REQUIRED and MUST NOT occur
                    ; more than once.
                    ;
                     prodid /version / target / reply-cmd
                    ;
                    ; These are optional, and may occur more
                    ; than once.
                    ;
                     other-props )
    For a "CREATE" command, the "TARGET" property specifies the
    containers where the components will be created.

Royer, et al. Experimental [Page 92] RFC 4324 Calendar Access Protocol December 2005

    If the iCalendar object being created does not have a "METHOD"
    property, then its state is "BOOKED" and it is not an [iTIP]
    scheduling object.  Use the "DELETE" command to set the state of
    an object to the "DELETED" state (tagged for deletion).  A CUA
    cannot use the "CREATE" command to create an object in the
    "DELETED" state.
    If the intention is to book an [iTIP] object, then the "METHOD"
    property MUST NOT be supplied.  Otherwise, any [iTIP] object MUST
    have a valid [iTIP] "METHOD" property value and it is a scheduling
    request being deposited into the CS with its state set to
    "UNPROCESSED".
 Format Definition: ABNF for a "CREATE" object is:
    create-object = "BEGIN" ":" "VCALENDAR" CRLF
              ; If 'calprops' contain the "METHOD" property
              ; then this 'create-object' component MUST
              ; conform to [iTIP] restrictions.
              ;
              ; calprops MUST include 'create-cmd'
              ;
                    calprops
                    other-props
                    1*(create-comp)
                    "END" ":" "VCALENDAR" CRLF
              ; NOTE: The 'VCALSTORE' component is not included in
              ; 'create-comp' as it is out of scope for CAP to create
              ; a new CS.
              ;
     create-comp =  agendac / carc / queryc
                   / timezonec / freebusyc
                   / eventc / todoc / journalc
                   / iana-comp / x-comp
                   ;
    freebusyc    = ; As defined in [iCAL].
                   ;
    eventc       = ; As defined in [iCAL].
                   ;
    journalc     = ; As defined in [iCAL].
                   ;
    timezonec    = ; As defined in [iCAL].
                   ;
    todoc        = ; As defined in [iCAL].
 In the following example, two new top level "VAGENDA" components are
 created.  Note that the "CSID" value of the server is

Royer, et al. Experimental [Page 93] RFC 4324 Calendar Access Protocol December 2005

 cal.example.com, which is where the new "VAGENDA" components are
 going to be created.
    C: Content-Type: text/calendar
    C:
    C: BEGIN:VCALENDAR
    C: PRODID:-//someone's prodid
    C: VERSION:2.0
    C: CMD;ID=creation01:CREATE
    C: TARGET:cal.example.com
    C: BEGIN:VAGENDA                 <- data for 1st new calendar
    C: CALID:relcalz1
    C: NAME;LANGUAGE=en_US:Bill's Soccer Team
    C: OWNER:bill
    C: CALMASTER:mailto:bill@example.com
    C: TZID:US/Pacific
    C: END:VAGENDA
    C: BEGIN:VAGENDA                 <- data for 2nd new calendar
    C: CALID:relcalz2
    C: NAME;LANGUAGE=EN-us:Mary's personal calendar
    C: OWNER:mary
    C: CALMASTER:mailto:mary@example.com
    C: TZID:US/Pacific
    C: END:VAGENDA
    C: END:VCALENDAR
    S: Content-Type: text/calendar
    S:
    S: BEGIN:VCALENDAR
    S: VERSION:2.0
    S: PRODID:-//someone's prodid
    S: CMD;ID=creation01:REPLY
    S: TARGET:cal.example.com
    S: BEGIN:VREPLY                <- Reply for 1st calendar create
    S: CALID:relcalz1
    S: REQUEST-STATUS:2.0
    S: END:REPLY
    S: BEGIN:VREPLY                <- Reply for 2nd calendar create
    S: CALID:relcalz2
    S: REQUEST-STATUS:2.0
    S: END:VREPLY
    S: END:VCALENDAR
    To create a new component in multiple containers, simply name all
    of the containers in the "TARGET" in the create command.  A new
    "VEVENT" component is created in two TARGET components.  In this
    example, the "VEVENT" component is one new [iTIP] "REQUEST" to be

Royer, et al. Experimental [Page 94] RFC 4324 Calendar Access Protocol December 2005

    stored in two calendars.  The results would be iCalendar objects
    that conform to the [iTIP] replies as defined in [iTIP].
    This example shows two [iTIP] "VEVENT" components being created in
    each of the two supplied "TARGET" properties.  As it contains the
    "METHOD" property, they will be stored in the "UNPROCESSED" state:
    C: Content-Type: text/calendar
    C:
    C: BEGIN:VCALENDAR
    C: VERSION:2.0
    C: PRODID:-//someone's prodid
    C: CMD;ID=creation02:CREATE
    C: METHOD:REQUEST
    C: TARGET:relcalz1
    C: TARGET:relcalz2
    C: BEGIN:VEVENT
    C: DTSTART:20030307T180000Z
    C: UID:FirstInThisExample-1
    C: DTEND:20030307T190000Z
    C: SUMMARY:Important Meeting
    C: END:VEVENT
    C: BEGIN:VEVENT
    C: DTSTART:20040307T180000Z
    C: UID:SecondInThisExample-2
    C: DTEND:20040307T190000Z
    C: SUMMARY:Important Meeting
    C: END:VEVENT
    C: END:VCALENDAR
    The CS sends the "VREPLY" commands in separate MIME objects, one
    per supplied "TARGET" property value.
    S: Content-Type: text/calendar
    S:
    S: BEGIN:VCALENDAR
    S: VERSION:2.0
    S: PRODID:-//someone's prodid
    S: CMD;ID=creation02:REPLY
    S: TARGET:relcalz1  <- 1st TARGET listed.
    S: BEGIN:REPLY      <- Reply for 1st VEVENT create in 1st TARGET.
    S: UID:FirstInThisExample-1
    S: REQUEST-STATUS:2.0
    S: END:VREPLY
    S: BEGIN:REPLY        <- Reply for 2nd VEVENT crate in 1st TARGET.
    S: UID:SecondInThisExample-2
    S: REQUEST-STATUS:2.0
    S: END:VREPLY

Royer, et al. Experimental [Page 95] RFC 4324 Calendar Access Protocol December 2005

    S: END:VCALENDAR
 And the second reply for the 2nd TARGET:
    S: Content-Type: text/calendar
    S:
    S: BEGIN:VCALENDAR
    S: VERSION:2.0
    S: PRODID:-//someone's prodid
    S: CMD;ID=creation02:REPLY
    S: TARGET:relcalz2  <- 2nd TARGET listed
    S: BEGIN:REPLY      <- Reply for 1st VEVENT create in 2nd TARGET.
    S: UID:FirstInThisExample-1
    S: REQUEST-STATUS:2.0
    S: END:VREPLY
    S: BEGIN:REPLY      <- Reply for 2nd VEVENT crate in 2nd TARGET.
    S: UID:SecondInThisExample-2
    S: REQUEST-STATUS:2.0
    S: END:VREPLY
    S: END:VCALENDAR

10.5. DELETE Command

 CMD: DELETE
 Purpose: The "DELETE" command physically removes the QUERY result
    from the store or marks it for deletion.
    A CUA MAY send a "DELETE" command to a CS.  The "DELETE" command
    MUST be implemented by all CSs.
    The CS MUST NOT send a "DELETE" command to any CUA.
 Formal Definition: A "DELETE" command is defined by the following
    notation:
       delete-cmd   = deleteparam ":" "DELETE"
                ;
       deleteparam  = *(
                ;
                ; the following are optional,
                ; but MUST NOT occur more than once
                ;
                     id-param
                    / localize-param
                    / latency-param
                    / option-param "MARK"
                ;

Royer, et al. Experimental [Page 96] RFC 4324 Calendar Access Protocol December 2005

                ; The following MUST occur exactly once and
                ; only when the latency-param has been supplied.
                ; It MUST NOT be supplied if the latency-param
                ; is not supplied.
                ;
                    / action-param
                ;
                ; the following is optional,
                ; and MAY occur more than once
                ;
                    / other-params
                   )
    The "DELETE" command is used to delete calendars or components.
    The included "VQUERY" component(s) specifies the container(s) to
    delete.
    To mark a component for delete without physically removing it,
    include the "OPTIONS" parameter with its value set to the "MARK"
    value in order to alter its state to "DELETED".
    When components are deleted, only the top-most component
    "REQUEST-STATUS" properties are returned.  No "REQUEST-STATUS"
    properties are returned for components inside of the selected
    components.  There MUST be one "VREPLY" component returned for
    each object that is deleted or marked for delete.  Note that if no
    "VREPLY" components are returned, then nothing matched and nothing
    was deleted.
    Restriction Table for the "REPLY" command for any "DELETE"
    command.
       delete-reply   = "BEGIN" ":" "VCALENDAR" CRLF
                        calprops   ; MUST include 'reply-cmd'
                        *(delete-vreply)
                        "END" ":" "VCALENDAR" CRLF
                      ;
       delete-vreply  = "BEGIN" ":" "VREPLY" CRLF
                        deleted-id
                        rstatus
                        "END" ":" "VREPLY" CRLF
                      ;
                      ; Where the id is appropriate for the
                      ; type of object deleted:
                      ;
                      ; VAGENDA = relcalid
                      ; VCAR = carid
                      ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid

Royer, et al. Experimental [Page 97] RFC 4324 Calendar Access Protocol December 2005

                      ; VQUERY = queryid
                      ; ALARM = sequence
                      ; VTIMEZONE = tzid
                      ; x-comp = x-id
                      ; An instance = uid recurid
                      ;
       deleted-id    = ( relcalid / carid / uid / uid recurid
                      / queryid / tzid / sequence / x-id )
 Example: to delete a "VEVENT" component with "UID" value of
    "abcd12345" from the calendar "relcalid-22" from the current CS:
       C: Content-Type: text/calendar
       C:
       C: BEGIN:VCALENDAR
       C: TARGET:relcalid-22
       C: CMD;ID:"random but unique per CUA":DELETE
       C: BEGIN:VQUERY
       C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345'
       C: END:VQUERY
       C: END:VCALENDAR
       S: BEGIN:VCALENDAR
       S: TARGET:relcalid-22
       S: CMD;ID:"random but unique per CUA":REPLY
       S: BEGIN:VREPLY
       S: UID:abcd12345
       S: REQUEST-STATUS:3.0
       S: END:VREPLY
       S: END:VCALENDAR
    One or more iCalendar objects will be returned that contain
    "REQUEST-STATUS" properties for the deleted components.  More than
    one component could have been deleted.  Any booked component and
    any number of unprocessed [iTIP] scheduling components that
    matched the QUERY value in the above example will be returned.
    Each unique "METHOD" property value that was deleted from the
    store MUST be in a separate iCalendar object.  This is because
    only one "METHOD" property is allowed in a single "VCALENDAR"
    BEGIN/END block.

10.6. GENERATE-UID Command

 CMD: GENERATE-UID
 Purpose: The "GENERATE-UID" command returns one or more unique
    identifiers that MUST be globally unique.

Royer, et al. Experimental [Page 98] RFC 4324 Calendar Access Protocol December 2005

    The "GENERATE-UID" command MAY be sent to any CS.  The "GENERATE-
    UID" command MUST be implemented by all CSs.
    The "GENERATE-UID" command MUST NOT be sent to a CUA.
 Formal Definition: A "GENERATE-UID" command is defined by the
    following notation:
       generate-uid-cmd   = genuidparam ":" "GENERATE-UID"
                      ;
       genuidparam        = *(
                      ;
                      ; The following are optional,
                      ; but MUST NOT occur more than once.
                          ;
                            id-param
                          / localize-param
                          / latency-param
                      ;
                      ; The following MUST occur exactly once and
                      ; only when the latency-param has been supplied.
                      ; It MUST NOT be supplied if the latency-param
                      ; is not supplied.
                      ;
                          / action-param
                      ;
                      ; The following is optional,
                      ; and MAY occur more than once.
                      ;
                          / other-params
                      ;
                      ; The following MUST be supplied exactly once.
                      ; The value specifies the number of UIDs to
                      ; be returned.
                      ;
                          / option-param posint1
                        )
 Response:
       gen-reply   = "BEGIN" ":" "VCALENDAR" CRLF
       calprops              ; Which MUST include 'reply-cmd'
       1*(gen-vreply)
       "END" ":" "VCALENDAR" CRLF
       gen-vreply  = "BEGIN" ":" "VREPLY" CRLF
                     1*(uid)
                     rstatus

Royer, et al. Experimental [Page 99] RFC 4324 Calendar Access Protocol December 2005

                     "END" ":" "VREPLY" CRLF
       {%%%IS THIS RIGHT%%%?]
 Example:
       C: BEGIN:VCALENDAR
       C: VERSION:2.0
       C: PRODID:-//someone's prodid
       C: CMD;ID=unique-per-cua-124;OPTIONS=5:GENERATE-UID
       C: END:VCALENDAR
       S: Content-Type: text/calendar
       S:
       S: BEGIN:VCALENDAR
       S: VERSION:2.0
       S: PRODID:-//someone's prodid
       S: CMD;ID=unique-per-cua-124:REPLY
       S: BEGIN:VREPLY
       S: UID:20011121T120000Z-12340@cal.example.com
       S: UID:20011121T120000Z-12341@cal.example.com
       S: UID:20011121T120000Z-12342@cal.example.com
       S: UID:20011121T120000Z-12343@cal.example.com
       S: UID:20011121T120000Z-12344@cal.example.com
       S: REQUEST-STATUS:2.0
       S: END:VREPLY
       S: END:VCALENDAR

10.7. GET-CAPABILITY Command

 CMD: GET-CAPABILITY
 Purpose: The "GET-CAPABILITY" command returns the capabilities of the
    other end point of the session.
    A CUA MUST send a "GET-CAPABILITY" command to a CS after the
    initial connection.  A CS MUST send a "GET-CAPABILITY" command to
    a CUA after the initial connection.  The "GET-CAPABILITY" command
    and reply MUST be implemented by all CSs and CUAs.
 Formal Definition: A "GET-CAPABILITY" command is defined by the
    following notation:
       get-capability-cmd   = capabilityparam ":" "GET-CAPABILITY"
       capabilityparam     = *(
                     ; the following are optional,
                     ; but MUST NOT occur more than once

Royer, et al. Experimental [Page 100] RFC 4324 Calendar Access Protocol December 2005

                     ;
                           id-param / localize-param / latency-param
                     ;
                     ; the following MUST occur exactly once and only
                     ; when the latency-param has been supplied and
                     ; MUST NOT be supplied if the latency-param is
                     ; not supplied.
                     ;
                          / action-param
                     ;
                     ; the following is optional,
                     ; and MAY occur more than once
                     ;
                          / other-params
                          )
    Response:
    The "GET-CAPABILITY" command returns information about the
    implementation at the other end of the session.  The values
    returned may differ depending on current user identify and the
    security level of the connection.
    Client implementations SHOULD NOT require any capability element
    beyond those defined in this specification or future RFC
    publications.  They MAY ignore any nonstandard, experimental
    capability elements.  The "GET-CAPABILITY" reply may return
    different results, depending on the UPN and if the UPN is
    authenticated.
    When sending a reply to a "GET-CAPABILITY" command, all of these
    MUST be supplied.  The following properties are returned in
    response to a "GET-CAPABILITY" command:
       cap-vreply     = "BEGIN" ":" "VCALENDAR" CRLF
                      ; The following properties may be in any order.
                      ;
                      rodid
                      version
                      reply-cmd
                      other-props
                      "BEGIN" ":" "VREPLY" CRLF
                      ; The following properties may be in any order.
                      ;
                      cap-version
                      car-level
                      components

Royer, et al. Experimental [Page 101] RFC 4324 Calendar Access Protocol December 2005

                      stores-expanded
                      maxdate
                      mindate
                      itip-version
                      max-comp-size
                      multipart
                      query-level
                      recur-accepted
                      recur-expand
                      recur-limit
                      other-props
                     "END" ":" "VREPLY" CRLF
                     "END" ":" "VCALENDAR" CRLF
 Example:
       I: Content-Type: text/calendar
       I:
       I: BEGIN:VCALENDAR
       I: VERSION:2.0
       I: PRODID:-//someone's prodid
       I: CMD;ID=unique-per-cua-125:GET-CAPABILITY
       I: END:VCALENDAR
       L: Content-Type: text/calendar
       L:
       L: BEGIN:VCALENDAR
       L: VERSION:2.0
       L: PRODID:-//someone's prodid
       L: CMD;ID=unique-per-cua-125:REPLY
       L: BEGIN:VREPLY
       L: CAP-VERSION:1.0
       L: PRODID:The CS prodid
       L: QUERY-LEVEL:CAL-QL-1
       L: CAR-LEVEL:CAR-FULL-1
       L: MAXDATE:99991231T235959Z
       L: MINDATE:00000101T000000Z
       L: MAX-COMPONENT-SIZE:0
       L: COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR,
       L: VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT,VREPLY
       L: ITIP-VERSION:2446
       L: RECUR-ACCEPTED:TRUE

Royer, et al. Experimental [Page 102] RFC 4324 Calendar Access Protocol December 2005

       L: RECUR-EXPAND:TRUE
       L: RECUR-LIMIT:0
       L: STORES-EXPANDED:FALSE
       L: X-INET-PRIVATE-COMMANDS:1.0
       L: END:VREPLY
       L: END:VCALENDAR

10.8. IDENTIFY Command

 CMD: IDENTIFY
 Purpose: The "IDENTIFY" command allows the CUA to set a new identity
    to be used for calendar access.
    A CUA MAY send an "IDENTIFY" command to a CS.  The "IDENTIFY"
    command MUST be implemented by all CSs.  A CS implementation MAY
    reject all "IDENTIFY" commands.
    The CS MUST NOT send an "IDENTIFY" command to any CUA.
 Formal Definition: An "IDENTIFY" command is defined by the following
    notation:
       identify-cmd    = identifyparam ":" "IDENTIFY"
                     ;
       identifyparam   = *(
                     ;
                     ; the following are optional,
                     ; but MUST NOT occur more than once
                     ;
                         id-param
                       / localize-param
                       / latency-param
                     ;
                     ; the following MUST occur exactly once and only
                     ; when the latency-param has been supplied and
                     ; MUST NOT be supplied if the latency-param is
                     ; not supplied.
                     ;
                       / action-param
                     ;
                     ; the following is optional,
                     ; and MAY occur more than once
                     ;
                       / other-params
                     ;
                     ; The value is the UPN of the requested
                     ; identity.  If option is not supplied it is

Royer, et al. Experimental [Page 103] RFC 4324 Calendar Access Protocol December 2005

                     ; a request to return to the original
                     ; authenticated identity.
                     ;
                       / option-param upn
                       )
 Response:
    A "REQUEST-STATUS" property wrapped in a "VREPLY" component with
    only one of the following request-status codes:
       2.0 Successful.
    6.4 Identity not permitted.  VCAR restriction.
 The CS determines, through an internal mechanism, if the credentials
 supplied at authentication permit the operation as the selected
 identity.  If they do, the session assumes the new identity;
 otherwise, a security error is returned.
 Example:
       C: Content-Type: text/calendar
       C:
       C: BEGIN:VCALENDAR
       C: VERSION:2.0
       C: PRODID:-//someone's prodid
       C: CMD;ID=unique-per-cua-999;OPTIONS=newUserId:IDENTIFY
       C: END:VCALENDAR
       S: Content-Type: text/calendar
       S:
       S: BEGIN:VCALENDAR
       S: VERSION:2.0
       S: PRODID:-//someone's prodid
       S: BEGIN:VREPLY
       S: REQUEST-STATUS:2.0;Request Approved
       S: END:VREPLY
       S: END:VCALENDAR
    Or if denied:

Royer, et al. Experimental [Page 104] RFC 4324 Calendar Access Protocol December 2005

       S: Content-Type: text/calendar
       S:
       S: BEGIN:VCALENDAR
       S: PRODID:-//someone's prodid
       S: VERSION:2.0
       S: BEGIN:VREPLY
       S: REQUEST-STATUS:6.4;Request Denied
       S: END:VREPLY
       S: END:VCALENDAR
    For the CUA to return to its original authenticated identity, the
    OPTIONS parameter is omitted:
    C: Content-Type: text/calendar
    C:
    C: BEGIN:VCALENDAR
    C: VERSION:2.0
    C: PRODID:-//someone's prodid
    C: CMD;ID=unique-per-cua-995:IDENTIFY
    C: END:VCALENDAR
 The CS may accept (2.0) or deny (6.4) the request to return to the
 original identity.
 If a CS considers the "IDENTIFY" command an attempt to violate
 security, the CS MAY terminate the [BEEP] session without any further
 notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply.

10.9. MODIFY Command

 CMD: MODIFY
 Purpose: The "MODIFY" command is used to modify existing components.
    A CUA MAY send a "MODIFY" command to a CS.  The "MODIFY" command
    MUST be implemented by all CSs.
    The CS MUST NOT send a "MODIFY" command to any CUA.
 Formal Definition: A "MODIFY" command is defined by the following
    notation:
       modify-cmd    = modifyparam ":" "MODIFY"
                     ;
       modifyparam   = *(
                     ;
                     ; the following are optional,
                     ; but MUST NOT occur more than once

Royer, et al. Experimental [Page 105] RFC 4324 Calendar Access Protocol December 2005

                     ;
                       id-param
                     / localize-param
                     / latency-param
                     ;
                     ; the following MUST occur exactly once and only
                     ; when the latency-param has been supplied and
                     ; MUST NOT be supplied if the latency-param is
                     ; not supplied.
                     ;
                     / action-param
                     ;
                     ; the following is optional,
                     ; and MAY occur more than once
                     ;
                     / other-params
                     )
    The "MODIFY" command is used to modify existing components.  The
    TARGET property specifies the calendars that contain the
    components that are going to be modified.
    The format of the request is three components inside of
    "VCALENDAR" component:
       BEGIN:VCALENDAR
       BEGIN:VQUERY
       END:VQUERY
       BEGIN:XXX
       END:XXX
       BEGIN:XXX
       END:XXX
       END:VCALENDAR
    The "VQUERY" component selects the components that are to be
    modified.
    The "XXX" above is a named component type (VEVENT, VTODO, ...).
    Both the old and new components MUST be of the same type.
    The old-values is a component and the contents of that component
    are going to change and may contain information that helps
    uniquely identify the original component (SEQUENCE in the example
    below).  If the CS cannot find a component that matches the QUERY
    and does not have at least all of the OLD-VALUES, then a 6.1 error
    is returned.

Royer, et al. Experimental [Page 106] RFC 4324 Calendar Access Protocol December 2005

    The new-values is a component of the same type as old-values and
    new-values contains the new data for each selected component.  Any
    data that is in old-values and not in new-values is deleted from
    the selected component.  Any values in new-values that was not in
    old-values is added to the component.
    In this example, the "VEVENT" component with a "UID" property
    value of 'unique-58' has the "LOCATION" property and "LAST-
    MODIFIED" properties changed, the "VALARM" component with the
    "SEQUENCE" property with a value of "3" has its "TRIGGER" property
    disabled, the "X-LOCAL" property is removed from the "VEVENT"
    component, and a "COMMENT" property is added.
    Because "SEQUENCE" property is used to locate the "VALARM"
    component in this example, both the old-values and the new-values
    contain the "SEQUENCE" property with a value of "3".  If the
    "SEQUENCE" property were to be left out of new-values, it would
    have been deleted.
 Example:
       C: Content-Type: text/calendar
       C:
       C: BEGIN:VCALENDAR
       C: VERSION:2.0
       C: PRODID:-//someone's prodid
       C: TARGET:my-cal
       C: CMD:ID=unique-mod:MODIFY
       C: BEGIN:VQUERY                   <- Query to select data set.
       C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58'
       C: END:VQUERY
       C: BEGIN:VEVENT                   <- Start of old data.
       C: LOCATION:building 3
       C: LAST-MODIFIED:20020101T123456Z
       C: X-LOCAL:some private stuff
       C: BEGIN:VALARM
       C: SEQUENCE:3
       C: TRIGGER;RELATED=END:PT5M
       C: END:VALARM
       C: END:VEVENT                     <- End of old data.
       C: BEGIN:VEVENT                   <- Start of new data.
       C: LOCATION:building 4
       C: LAST-MODIFIED:20020202T010203Z
       C: COMMENT:Ignore global trigger.
       C: BEGIN:VALARM
       C: SEQUENCE:3
       C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M
       C: END:VALARM

Royer, et al. Experimental [Page 107] RFC 4324 Calendar Access Protocol December 2005

       C: END:VEVENT                     <- End of new data.
       C: END:VCALENDAR
    The "X-LOCAL" property was not supplied in the new-values, so it
    was deleted.  The "LOCATION" property value was altered, as was
    the "LAST-MODIFIED" value.  The "VALARM" component with a
    "SEQUENCE" property value of "3" had its "TRIGGER" property
    disabled, and the "SEQUENCE" property value did not change so it
    was not effected.  The "COMMENT" property was added.
    When it comes to inline ATTACHMENTs, the CUA only needs to
    uniquely identify the contents of the ATTACHMENT value in the
    old-values in order to delete them.  When the CS compares the
    attachment data, it is compared in its binary form.  The
    ATTACHMENT value supplied by the CUA MUST be valid encoded
    information.
    For example, to delete the same huge inline attachment from every
    VEVENT in 'my-cal' that has an "ATTACH" property value with the
    old-values:
    BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:-//someone's prodid
    TARGET:my-cal
    CMD:MODIFY
    BEGIN:VQUERY
    QUERY:SELECT ATTACH FROM VEVENT
    END:VQUERY
    BEGIN:VEVENT
    ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
     MIICajCCAdOgAwIBAgICbeUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
     EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
     ...< remainder of attachment data NOT supplied >....
    END:VEVENT
    BEGIN:VEVENT
    END:VEVENT
    END:VCALENDAR
 Here the new-values is empty, so everything in the old-values is
 deleted.
 Furthermore, the following additional restrictions apply:
 1.   One cannot change the "UID" property of a component.

Royer, et al. Experimental [Page 108] RFC 4324 Calendar Access Protocol December 2005

 2.   If a contained component is changed inside of a selected
      component, and that contained component has multiple instances,
      then old-values MUST contain information that uniquely
      identifies the instance or instances that are changing.  It is
      valid to change more than one.  All contained components that
      match old-values will be modified.  In the first modify example
      above, if "SEQUENCE" properties were to be deleted from both the
      old-values and new-values, then all "TRIGGER" properties that
      matched the old-values in all "VALARM" components in the
      selected "VEVENT" components would be disabled.
 3.   The result of the modify MUST be a valid iCalendar object.
 Response:
 A "VCALENDAR" component is returned with one ore more "REQUEST-
 STATUS" property values.
 If any error occurred:
    No component will be changed at all.  That is, it will appear just
    as it was prior to the modify and the CAP server SHOULD return a
    "REQUEST-STATUS" property for each error that occurred.  There
    MUST be at least one error reported.
 If multiple components are selected, then what uniquely identified
 the component MUST be returned (UID, QUERYID, ...) if the component
 contains a unique identifier.  If it does not, sufficient information
 to uniquely identify the modified components MUST be returned in the
 reply.
    S: Content-Type: text/calendar
    S:
    S: BEGIN:VCALENDAR
    S: TARGET:relcalid
    S: CMD;ID=delete#1:REPLY
    S: BEGIN:VREPLY
    S: BEGIN:VEVENT
    S: UID:123
    S: REQUEST-STATUS:2.0
    S: END:VEVENT
    S: END:VREPLY
    S: END:VCALENDAR

Royer, et al. Experimental [Page 109] RFC 4324 Calendar Access Protocol December 2005

10.10. MOVE Command

 CMD: MOVE
 Purpose: The "MOVE" command is used to move components within the CS.
    A CUA MAY send a "MOVE" command to a CS.  The "MOVE" command MUST
    be implemented by all CSs.
    The CS MUST NOT send a "MOVE" command to any CUA.
 Formal Definition: A "MOVE" command is defined by the following
    notation:
       move-cmd    = moveparam ":" "MOVE"
                   ;
       moveparam   = *(
                   ;
                   ; the following are optional,
                   ; but MUST NOT occur more than once
                   ;
                     id-param
                   / localize-param
                   / latency-param
                   ;
                   ; the following MUST occur exactly once and only
                   ; when the latency-param has been supplied and
                   ; MUST NOT be supplied if the latency-param is
                   ; not supplied.
                   ;
                   / action-param
                   ;
                   ; the following is optional,
                   ; and MAY occur more than once
                   ;
                   / other-params
                   ;
                   )
 Response:
       The REQUEST-STATUS in a VCALENDAR object.
    The content of each "result" is subject to the result restriction
    table defined below.
    The access control on the "VAGENDA" component, after it has been
    moved to its new location in the calstore, MUST be at least as

Royer, et al. Experimental [Page 110] RFC 4324 Calendar Access Protocol December 2005

    secure as it was prior to the move.  If the CS is not able to
    ensure the same level of security, a permission-denied "REQUEST-
    STATUS" property value MUST be returned, and the "MOVE" command
    MUST NOT be performed.
    The "TARGET" property value specifies the new location, and the
    "VQUERY" component specifies the old location.
    Restriction Table for the "REPLY" command of any "MOVE" command.
       move-reply  = "BEGIN" ":" "VCALENDAR" CRLF
                      calprops
                      1*(move-vreply)
                     "END" ":" "VCALENDAR" CRLF
       move-vreply  = "BEGIN" ":" "VREPLY" CRLF
                       move-id
                        rstatus
                      "END" ":" "VREPLY" CRLF
                     ; Where the id is appropriate for the
                     ; type of object moved:
                     ;
                     ; VAGENDA = relcalid
                     ; VCAR = carid
                     ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
                     ; VQUERY = queryid
                     ; ALARM = sequence
                     ; An instance = uid recurid
                     ; x-comp = x-id
                     ;
       move-id    =  ( relcalid / carid / uid / uid recurid
                      / queryid / tzid / sequence / x-id)
 Example: moving the VAGENDA Nellis to Area-51
       C: Content-Type: text/calendar
       C:
       C: BEGIN:VCALENDAR
       C: VERSION:2.0
       C: PRODID:-//someone's prodid
       C: CMD:MOVE
       C: TARGET:Area-51
       C: BEGIN:VQUERY
       C: QUERY: SELECT *.* FROM VAGENDA WHERE CALID='Nellis'
       C: END:VQUERY
       C: END:VCALENDAR

Royer, et al. Experimental [Page 111] RFC 4324 Calendar Access Protocol December 2005

       S: Content-Type: text/calendar
       S:
       S: BEGIN:VCALENDAR
       S: VERSION:2.0
       S: PRODID:-//someone's prodid
       S: TARGET:Area-51
       S: BEGIN:VREPLY
       S: CALID:Nellis
       S: REQUEST-STATUS: 2.0
       S: END:VREPLY
       S: END:VCALENDAR

10.11. REPLY Response to a Command

 CMD: REPLY
 Purpose: The "REPLY" value to the "CMD" property is used to return
    the results of all other commands to the CUA.
    A CUA MUST send a "REPLY" command to a CS for any command a CS MAY
    send to the CUA.  The "REPLY" command MUST be implemented by all
    CUAs that support getting the "GET-CAPABILITY" command.
    A CS MUST send a "REPLY" command to a CUA for any command a CUA
    MAY send to the CS.  The "REPLY" command MUST be implemented by
    all CSs.
 Formal Definition: A "REPLY" command is defined by the following
    notation:
       reply-cmd    = replyparam ":" "REPLY"
                      ;
       replyparam    = *(
                      ;
                      ; The 'id' parameter value MUST be exactly the
                      ; same as the value sent in the original
                      ; CMD property.  If the original CMD did
                      ; not have an 'id' parameter, then the 'id'
                      ; MUST NOT be supplied in the REPLY.
                      ;
                  id-param
                      ;
                      ; the following is optional,
                      ; and MAY occur more than once
                      ;
                   / other-params
                      )

Royer, et al. Experimental [Page 112] RFC 4324 Calendar Access Protocol December 2005

10.12. SEARCH Command

 CMD: SEARCH
 Purpose: The "SEARCH" command is used to return selected components
    to the CUA.
    A CUA MAY send a "SEARCH" command to a CS.  The "SEARCH" command
    MUST be implemented by all CSs.
    The CS MUST NOT send a "SEARCH" command to any CUA.
 Formal Definition: A "SEARCH" command is defined by the following
    notation:
        search-cmd   = searchparam ":" "SEARCH"
                     ;
       searchparam   = *(
                     ;
                     ; the following are optional,
                     ; but MUST NOT occur more than once
                     ;
                       id-param
                     / localize-param
                     / latency-param
                     ;
                     ; the following MUST occur exactly once and only
                     ; when the latency-param has been supplied and
                     ; MUST NOT be supplied if the latency-param is
                     ; not supplied.
                     ;
                     / action-param
                     ;
                     ; the following is optional,
                     ; and MAY occur more than once
                     ;
                     / other-params
                     )
    The format of the request is the search command (search-cmd)
    followed by one or more (query) "VQUERY" components
 Response:
    The data in each result set contains one or more iCalendar
    components composed of all the selected results enclosed in a
    single "VREPLY" component per "QUERY".

Royer, et al. Experimental [Page 113] RFC 4324 Calendar Access Protocol December 2005

    Only "REQUEST-STATUS" property and the properties mentioned in the
    "SELECT" clause of the QUERY are included in the components.  Each
    "VCALENDAR" component is tagged with the "TARGET" property.
 Searching for objects
    In the example below, objects on March 10,1999 between 080000Z and
    190000Z are read.  In this case only four properties for each
    object are returned.  Two calendars are specified.  Only booked
    (vs.  scheduled) entries are to be returned (this example only
    selected VEVENT objects are to be returned):
       C: Content-Type: text/calendar
       C:
       C: BEGIN:VCALENDAR
       C: VERSION:2.0
       C: PRODID:-//someone's prodid
       C: CMD:SEARCH
       C: TARGET:relcal2
       C: TARGET:relcal3
       C: BEGIN:VQUERY
       C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
       C:  FROM VEVENT
       C:  WHERE DTEND >= '19990310T080000Z'
       C:  AND DTSTART <= '19990310T190000Z'
       C:  AND STATE() = 'BOOKED'
       C: END:VQUERY
       C: END:VCALENDAR
    The return values are subject to VCAR filtering.  That is, if the
    request contains properties to which the UPN does not have access,
    those properties will not appear in the return values.  If the UPN
    has access to at least one property of the component, but has been
    denied access to all properties called out in the request, the
    response will contain a single "REQUEST-STATUS" property
    indicating the error.
    Here the request was successful, however one of the "VEVENT"
    components contents were not accessible (4.1).

Royer, et al. Experimental [Page 114] RFC 4324 Calendar Access Protocol December 2005

       S: Content-Type: text/calendar
       S:
       S: BEGIN:VCALENDAR
       S: TARGET:relcalid
       S: CMD:REPLY
       S: VERSION:2.0
       S: PRODID:-//someone's prodid
       S: BEGIN:VREPLY
       S: BEGIN:VEVENT
       S: REQUEST-STATUS:4.1
       S: END:VEVENT
       S: BEGIN:VEVENT
       S: REQUEST-STATUS:2.0
       S: UID:123
       S: DTEND:19990310T080000Z
       S: DSTART:19990310T190000Z
       S: SUMMARY: Big meeting
       S: END:VEVENT
       S: END:VREPLY
       S: END:VCALENDAR
    If the UPN has no access to any components at all, the response
    will simply be an empty data set.  The response will look the same
    if the particular components do not exist.
       S: Content-Type: text/calendar
       S:
       S: BEGIN:VCALENDAR
       S: VERSION:2.0
       S: PRODID:-//someone's prodid
       S: CMD:REPLY
       S: TARGET:ralcalid
       S: BEGIN:VREPLY
       S: REQUEST-STATUS:2.0
       S: END:VREPLY
       S: END:VCALENDAR
    If there are multiple targets, each iCalendar reply is contained
    within its own iCalendar object.

10.12.1. Searching for VFREEBUSY

 If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the
 "VFREEBUSY" component in the "COMPONENTS" value in a reply to the
 "GET-CAPABILITY" command, then it is the CS's responsibility (and not
 the CUA's responsibility) to provide the correct "VFREEBUSY"
 information for a calendar.

Royer, et al. Experimental [Page 115] RFC 4324 Calendar Access Protocol December 2005

 If a CUA issues a "CREATE" "VFREEBUSY", such a CS MUST return success
 and not store the "VFREEBUSY" component as the results would never be
 used.
 Such a CS MUST dynamically create the results of a search for
 "VFREEBUSY" components at search time when searching for STATE() =
 'BOOKED' items.
 If a CUA searches for "VFREEBUSY" components with STATE() =
 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components.
 If a CUA searches for "VFREEBUSY" components without specifying the
 STATE, such a CS MUST return the same result as if STATE()='BOOKED'
 had been specified.
 For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE"
 and have the "VFREEBUSY" component in the "COMPONENTS" value in the
 "CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information on
 the CS.  These CSs then MUST return a "VFREEBUSY" component
 calculated from the stored components.  If no "VFREEBUSY" information
 is available for the "TARGET" calendar, then a "VFREEBUSY" with no
 blocked out time will be returned with a success code.  A CUA sets
 the "VFREEBUSY" time on a/those calendars by creating a "VFREEBUSY"
 component without a "METHOD" creating a "BOOKED" entry.
 If a CS does not set the "VFREEBUSY" value in the "COMPONENTS"
 "CAPABILITY" value, the CS does not support the "VFREEBUSY" component
 and all creation and searching for a "VFREEBUSY" component MUST fail.
 Examples of calendars that may be in this category are public event
 calendars that will never require scheduling with other UPNs.

10.13. SET-LOCALE Command

 CMD: SET-LOCALE
 Purpose: The "SET-LOCALE" command is used to select the locale that
    will be used in error codes that are used in the "REQUEST-STATUS"
    property.
    A CUA MAY send a "SET-LOCALE" command to a CS.  The SET-LOCALE
    command MUST be implemented by all CSs.
    The CS MUST NOT send a "SET-LOCALE" command to any CUA.
 Formal Definition: A "SET-LOCALE" command is defined by the following
    notation:
       setlocale-cmd   = setlocaleparam ":" "SET-LOCALE"

Royer, et al. Experimental [Page 116] RFC 4324 Calendar Access Protocol December 2005

                      ;
       setlocaleparam   = *(
                      ;
                      ; the following are optional,
                      ; but MUST NOT occur more than once
                      ;
                          id-param
                        / localize-param
                        / latency-param
                        / setlocale-option
                      ;
                      ; the following MUST occur exactly once and only
                      ; only when the latency-param has been supplied.
                      ; It MUST NOT be supplied if the latency-param
                      ; is not supplied.
                      ;
                        / action-param
                      ;
                      ; the following is optional,
                      ; and MAY occur more than once
                      ;
                        / other-params )
       setlocale-option   = option-param newlocale
                        ;
       newlocale     =  ; Any locale supplied in the initial [BEEP]
                        ; "greeting" "localize" parameter and
                        ; and any charset supported by the CS
                        ; and listed in the DEFAULT-CHARSET property
                        ; of the VCALSTORE
 Examples:
       CMD:OPTIONS=en_US.UTF-8:SET-LOCALE
       CMD:OPTIONS=th_TH.ISO8859-11:SET-LOCALE
       CMD:OPTIONS=es_MX.ISO8859-1:SET-LOCALE
    Restriction Table for the "REPLY" command of any "SET-LOCALE"
    command.
       setlocale-reply  = "BEGIN" ":" "VCALENDAR" CRLF
                          calprops
                          1*(setlocale-vreply)
                         "END" ":" "VCALENDAR" CRLF
       setlocale-vreply  = "BEGIN" ":" "VREPLY" CRLF
                           rstatus
                           "END" ":" "VREPLY" CRLF

Royer, et al. Experimental [Page 117] RFC 4324 Calendar Access Protocol December 2005

10.14. TIMEOUT Command

 CMD: TIMEOUT
 Purpose: The "TIMEOUT" command is only sent after a command has been
    sent with a latency value set.  When received, it means the
    command could not be completed in the time allowed.
 Formal Definition: A "TIMEOUT" command is defined by the following
    notation:
       timeout-cmd   = timeoutparam ":" "TIMEOUT"
       timeoutparam   = *(
                       ; the following are optional,
                       ; but MUST NOT occur more than once
                         id-param
                       / localize-param
                       / other-params
                       )

10.15. Response Codes

 Numeric response codes are returned using the "REQUEST-STATUS"
 property.
 The format of these codes is described in [iCAL] and extended in
 [iTIP] and [iMIP].  The following describes new codes added to this
 set and how existing codes apply to CAP.
 At the application layer, response codes are returned as the value of
 a "REQUEST-STATUS" property.  The value type of this property is
 modified from that defined in [iCAL], in order to make the
 accompanying "REQUEST-STATUS" property text optional.
    Code              Description
    --------------------------------------------------------------
    2.0               Success.  The parameters vary with the
                      operation and are specified.
    2.0.3             In response to the client issuing an
                      "abort" reply, this reply code indicates
                      that any command currently underway was
                      successfully aborted.
    3.1.4             Capability not supported.
    4.1               Calendar store access denied.

Royer, et al. Experimental [Page 118] RFC 4324 Calendar Access Protocol December 2005

    6.1               Container not found.
    6.2               Attempt to create or modify an object
                      that would overlap another object
                      in either of the following two circumstances:
                      (a) One of the objects has a TRANSP
                      property set to OPAQUE-NOCONFLICT or
                      TRANSPARENT-NOCONFLICT.
                      (b) The calendar's ALLOW-CONFLICT
                      property is set to FALSE.
    6.3               Bad args.
    6.4               Permission denied - VCAR restriction.
                      A VCAR exists and the CS will not perform
                      the operation.
    7.0               A timeout has occurred.  The server was
                      unable to complete the operation in the
                      requested time.
    8.0               A failure has occurred in the CS
                      that prevents the operation from
                      succeeding.
    8.1               A query was performed and the query is
                      too complex for the CS.  The operation
                      was not performed.
    8.2               Used to signal that an iCalendar object has
                      exceeded the server's size limit
    8.3               A DATETIME value was too far in the future
                      to be represented on this Calendar.
    8.4               A DATETIME value was too far in the past
                      to be represented on this Calendar.
    8.5               An attempt was made to create a new
                      object, but the unique UID specified is
                      already in use.
    9.0               An unrecognized command was received.
                      Or an unsupported command was received.

Royer, et al. Experimental [Page 119] RFC 4324 Calendar Access Protocol December 2005

    10.4              The operation has not been performed
                      because it would cause the resources
                      (memory, disk, CPU, etc) to exceed the
                      allocated quota.
      --------------------------------------------------------------

11. Object Registration

 This section provides the process for registration of new or modified
 properties, parameters, commands, or other modifications, additions,
 or deletions to objects.

11.1. Registration of New and Modified Entities

 New objects are registered by the publication of an IETF Request for
 Comment (RFC).  Changes to objects are registered by the publication
 of a revision to the RFC in a new RFC.

11.2. Post the Item Definition

 The object description MUST be posted to the new object discussion
 list: ietf-calendar@imc.org.

11.3. Allow a Comment Period

 Discussion on a new object MUST be allowed to take place on the list
 for a minimum of two weeks.  Consensus MUST be reached on the object
 before proceeding to the next step.

11.4. Release a New RFC

 The new object will be submitted for publication like any other
 Internet Draft requesting RFC status.

12. BEEP and CAP

12.1. BEEP Profile Registration

 BEEP replies will be one-to-one (1:1 MSG/RPY) if possible, and one-
    to-many (1:many MSG/ANS) when the "TARGET" property value changes.
    No more than one "TARGET" property value is allowed per reply.
 Profile Identification: specify a [URI] that authoritatively
    identifies this profile.
 http://iana.org/beep/cap/1.0
 Message Exchanged during Channel Creation:

Royer, et al. Experimental [Page 120] RFC 4324 Calendar Access Protocol December 2005

    CUAs SHOULD supply the BEEP "localize" attributes in the BEEP
    "greeting" messages.
    CSs SHOULD supply the BEEP "localize" attributes in the BEEP
    "greeting" messages.
    CUAs SHOULD supply the BEEP "serverName" attribute at channel
    creation time to the CS, so that, if the CS is performing virtual
    hosting, the CS can determine the intended virtual host.  CSs that
    do not support virtual hosting may ignore the BEEP "serverName"
    attribute.
 Messages starting one-to-one exchanges:
    The initial message, after authentication in each direction, MUST
    be a single "text/calendar" object containing a CAP "CAPABILITY"
    CMD.  It must not be part of a MIME multipart message.
    After the initial message, a BEEP "MSG" may contain one or more
    MIME objects (at least one of which MUST be "text/calendar"), and
    each "text/calendar" MIME object MUST contain a CAP "CMD"
    property.
    Multiple iCalendar objects may be sent in a single BEEP message
    either by representing them as separate MIME text/calendar parts
    contained within a MIME multipart/mixed part or by simple
    concatenation within a single text/calendar MIME object.
    In either case, all iCalendar objects that are transmitted
    together must have the same TARGET property.
    The sending of multipart MIME entities over BEEP is not permitted
    for CAP unless the other endpoint has indicated its ability to
    accept them via the appropriate CAPABILITY.
 Messages in positive replies:
    After the initial message, a BEEP "RPY" may contain one or more
    MIME objects (at least one of which MUST be "text/calendar"), and
    each "text/calendar" MIME object MUST contain a CAP "CMD"
    property.  All "text/calendar" MIME objects in a single BEEP "RPY"
    messages MUST have the same "TARGET" property value.
    Multiple iCalendar objects may be sent in a single BEEP message by
    either representing them as separate MIME text/calendar parts
    contained within a MIME multipart/mixed part or by simple
    concatenation within a single text/calendar MIME object.

Royer, et al. Experimental [Page 121] RFC 4324 Calendar Access Protocol December 2005

    In either case, all iCalendar objects transmitted together must
    have the same TARGET property.
    Sending multipart MIME entities over BEEP is not permitted for CAP
    unless the other endpoint has indicated its ability to accept them
    via the appropriate CAPABILITY.
 Messages in negative replies:
    Will contain any valid "text/calendar" MIME object that contains
    CAP "REQUEST-STATUS" property and a CAP "CMD" property with a
    property value of "REPLY".  And where the CS has determined the
    requested operation to be a fatal error.  And when the CS has
    performed NO operation that effected the contents of any part of
    the CS or any calendar controlled by the CS.
 Messages in one-to-many exchanges:
    After the initial message then a BEEP "MSG" may contain one or
    more MIME objects at least one of which MUST be "text/calendar"
    and each "text/calendar" MIME object MUST contain a CAP "CMD"
    property.
    The BEEP "MSG" messages can only contain MIME "multipart" MIME
    objects if the other endpoint has received a CAP "CAPABILITY"
    indicating the other endpoint supports multipart MIME objects.
    This does not prevent the endpoint from sending multiple [iCAL]
    'icalobject' objects in a single BEEP "MSG" so long as all of them
    have the same "TARGET" property value.
    Multiple iCalendar objects may be sent in a single BEEP message by
    either representing them as separate MIME text/calendar parts
    contained within a MIME multipart/mixed part or by simple
    concatenation within a single text/calendar MIME object.
    In either case, all iCalendar objects transmitted together must
    have the same TARGET property.
    The sending of multipart MIME entities over BEEP is not permitted
    for CAP unless the other endpoint has indicated its ability to
    accept them via the appropriate CAPABILITY.
 Message Syntax:
    They are CAP "text/calendar" MIME objects as specified in this
    memo.

Royer, et al. Experimental [Page 122] RFC 4324 Calendar Access Protocol December 2005

 Message Semantics:
    As defined in this memo.

12.2. BEEP Exchange Styles

 [BEEP] defines three styles of message exchange:
    MSG/ANS,ANS,...,NUL -  For one to many exchanges.
    MSG/RPY -  For one to one exchanges.
    MSG/ERR -  For requests the cannot be processed due to an error.
 A CAP request targeted at more than one container MAY use a one- to-
 many exchange with a distinct answer associated with each target.  A
 CAP request targeted at a single container MAY use a one-to-one
 exchange or a one-to-many exchange.  "MSG/ERR" MAY only be used when
 an error condition prevents the execution of the request on all the
 targeted calendars.

12.3. BEEP Connection Details

 All CAP communications must be done securely, so the initial greeting
 includes the TLS profile.
    L: <wait for incoming connection>
    I: <open connection>
    L: RPY 0 0 . 0 110
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri='http://iana.org/beep/TLS' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting/>
    I: END
 At this point, the connection is secure.  The TLS profile 'resets'
 the connection, so it resends the greetings, advertises the CAP
 profiles that are supported, and replies with the profile selected
 (only one profile exists at this time):

Royer, et al. Experimental [Page 123] RFC 4324 Calendar Access Protocol December 2005

    L: <wait for incoming connection>
    I: <open connection>
    L: RPY 0 0 . 0 110
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri='http://iana.org/beep/cap/1.0'/>
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 110
    I: Content-Type: application/beep+xml
    I:
    I: <greeting>
    I:    <profile uri='http://iana.org/beep/cap/1.0'/>
    I: </greeting>
    I: END
 Each channel must be authenticated before work can start, but
 starting a channel involves authentication.  Any SASL profile may be
 included, for example:
    <profile uri='http://iana.org/beep/SASL/OTP'/>
    <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
    <profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
 Example of anonymous channel:
    C: <start number='1'>
    C:    <profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
    C: </start>
    S: RPY 0 1 . 221 87
    S: Content-Type: application/beep+xml
    S:
    S: <profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
    S: END
 Example of DIGEST-MD5 channel:
    C: <start number='1'>
    C:    <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
    C: </start>
    S: RPY 0 1 . 221 87
    S: Content-Type: application/beep+xml

Royer, et al. Experimental [Page 124] RFC 4324 Calendar Access Protocol December 2005

    S:
    S: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
    S: END
 Piggybacking the "CAPABILITY" command.
 The "CAPABILITY" reply may be included during channel start (see
 RFC3080, section 2.3.1.2), as BEEP allows the start command to
 include the initial data transfer.  This reduces the number of round
 trips to initiate a CAP session.

13. IANA Considerations

 This memo defines IANA-registered extensions to the attributes
 defined by iCalendar, as defined in [iCAL], and [iTIP].
 IANA registration proposals for iCalendar and [iTIP] are to be mailed
 to the registration agent for the "text/calendar" [MIME] content-
 type, <MAILTO: ietf-calendar@imc.org> using the format defined in
 section 7 of [iCAL].
 The the IANA has registered the profile specified in Section 12.1,
 and has selected an IANA-specific URI: http://iana.org/beep/cap/1.0.

14. Security Considerations

 Access rights should be granted cautiously.  Without careful
 planning, it is possible to open up access to a greater degree than
 desired.
 The "IDENTIFY" command should be carefully implemented.  If it is
 done incorrectly, UPNs may gain access as other, unintended, UPNs.
 The "IDENTIFY" command may not chain; that is, the identity is always
 validated against the original UPN and not the new UPN.
 Since CAP is a profile of [BEEP], consult [BEEP]'s Section 9 for a
 discussion of BEEP-specific security issues.
 There are risks of allowing anonymous UPNs to deposit REQUEST and
 REFRESH objects (calendar spam and denial-of-service, for example).
 Implementations should consider methods to restrict anonymous
 requests to within acceptable usages.
 CS implementations might consider automatically creating VCARs that
 allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY
 objects for those UIDs if they otherwise do not have access rather
 then opening up world access.  And they may also consider allowing
 COUNTER objects for those ATTENDEEs.

Royer, et al. Experimental [Page 125] RFC 4324 Calendar Access Protocol December 2005

 When an object is booked by a CUA ,the CS reply may wish to include
 warning messages to the CUA for ATTENDEEs that have CAP urls that do
 not have local UPNs as those ATTENDEES may be unable to REPLY or
 REFRESH.  Some CSs may wish this to be an error.
 Although service provisioning is a policy matter, at a minimum, all
 implementations must provide the following tuning profiles:
    o for authentication: http://iana.org/beep/SASL/DIGEST-MD5
    o for confidentiality: http://iana.org/beep/TLS (using the
    TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
    o for both: http://iana.org/beep/TLS (using the
    TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
    certificates)

Royer, et al. Experimental [Page 126] RFC 4324 Calendar Access Protocol December 2005

Appendix A. Acknowledgements

 The following individuals were major contributors to the drafting and
 discussion of this memo, and they are greatly appreciated:
 Alan Davies, Andrea Campi, Andre Courtemanche, Andrew Davison, Anil
 Srivastava, ArentJan Banck, Arnaud Quillaud, Benjamin Sonntag,
 Bernard Desruisseaux, Bertrand Guiheneuf, Bob Mahoney, Bob Morgan,
 Bruce Kahn, Chris Dudding, Chris Olds, Christopher Apple, Cortlandt
 Winters, Craig Johnson, Cyrus Daboo, Damon Chaplin, Dan Hickman, Dan
 Kohn, Dan Winship, Darryl Champagne, David C.  Thewlis, David Nicol,
 David Nusbaum, David West, Derik Stenerson, Eric R. Plamondon, Frank
 Dawson, Frank Nitsch, Gary Frederick, Gary McGath, Gilles Fortin,
 Graham Gilmore, Greg Barnes, Greg FitzPatrick, Harald Alvestrand,
 Harrie Hazewinkel, Helge Hess, Jagan Garimella, Jay Parker, Jim Ray,
 Jim Smith, Joerg Reichelt, John Berthels, John Smith, John Stracke,
 Jonathan Lennox, JP Rosevear, Karen Chu, Katie Capps Parlante, Kees
 Cook, Ken Crawford, Ki Wong, Lars Eggert, Lata Kannan, Lawrence
 Greenfield, Libby Miller, Lisa Dusseault, Lyndon Nerenberg, Mark
 Davidson, Mark Paterson, Mark Smith, Mark Swanson, Mark Tearle,
 Marshall Rose, Martijn van Beers, Martin Jackson, Matthias Laabs, Max
 Froumentin, Micah Gorrell, Michael Fair, Mike Higginbottom, Mike
 Hixson, Murata Makoto, Natalia Syracuse, Nathaniel Borenstein, Ned
 Freed, Olivier Gutknecht, Patrice Lapierre, Patrice Scattolin, Paul
 Hoffman, Paul Sharpe, Payod Deshpande, Pekka Pessi, Peter Thompson,
 Preston Stephenson, Prometeo Sandino Roman Corral, Ralph Patterson,
 Robert Lusardi, Robert Ransdell, Rob Siemborski, Satyanarayana
 Vempati, Satya Vempati, Scott Hollenbeck, Seamus Garvey, Shannon
 Clark, Shriram Vishwanathan, Steve Coya, Steve Mansour, Steve Miller,
 Steve Vinter, Stuart Guthrie, Suchet Singh Khalsa, Ted Hardie, Tim
 Hare, Timo Sirainen, Vicky Oliver, Paul Hill, and Yael Shaham-Gafni.

Appendix B. References

Appendix B.1. Normative References

 [ABNF]      Crocker, D., Ed. and P. Overell, "Augmented BNF for
             Syntax Specifications: ABNF", RFC 4234, October 2005.
 [BEEP]      Rose, M., "The Blocks Extensible Exchange Protocol Core",
             RFC 3080, March 2001.
 [BEEPTCP]   Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081,
             March 2001.
 [BEEPGUIDE] Rose, M., "BEEP, The Definitive Guide", ISBN 0-596-
             00244-0, O'Reilly & Associates, Inc.

Royer, et al. Experimental [Page 127] RFC 4324 Calendar Access Protocol December 2005

 [GUIDE]     Mahoney, B., Babics, G., and A. Taler, "Guide to Internet
             Calendaring", RFC 3283, June 2002.
 [iCAL]      Dawson, F. and D. Stenerson, "Internet Calendaring and
             Scheduling Core Object Specification (iCalendar)", RFC
             2445, November 1998.
 [iTIP]      Silverberg, S., Mansour, S., Dawson, F., and R. Hopson,
             "iCalendar Transport-Independent Interoperability
             Protocol (iTIP) Scheduling Events, BusyTime, To-dos and
             Journal Entries", RFC 2446, November 1998.
 [iMIP]      Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
             Message-Based Interoperability Protocol (iMIP)", RFC
             2447, November 1998.
 [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
             Extensions (MIME) Part One: Format of Internet Message
             Bodies", RFC 2045, November 1996.
 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, BCP 14, March 1997.

Appendix B.2. Informative References

 [CHARREG]   Freed, N. and J. Postel, "IANA Charset Registration
             Procedures", RFC 2278, January 1998.
 [CHARPOL]   Alvestrand, H., "IETF Policy on Character Sets and
             Languages", RFC 2277, January 1998.
 [RFC2822]   Resnick, P., Ed., "Internet Message Format", RFC 2822,
             April 2001.
 [SASL]      Myers, J., "Simple Authentication and Security Layer
             (SASL)", RFC 2222, October 1997.
 [SQL92]     "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka
             ANSI X3.135-1992, aka FIPS PUB 127-2
 [SQLCOM]    ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1
             to ISO/IEC 9075: 1992, also adopted as Amendment 1 to
             ANSI X3.135.1992
 [URLGUIDE]  Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
             "Guidelines for new URL Schemes", RFC 2718, November
             1999.

Royer, et al. Experimental [Page 128] RFC 4324 Calendar Access Protocol December 2005

 [URI]       Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
             Resource Identifiers (URI): Generic Syntax", RFC 3986,
             January 2005.
 [URL]       Berners-Lee, T, Masinter, L., and M. McCahil, "Uniform
             Resource Locators (URL)", RFC 1738, December 1994.
 [X509CRL]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
             X.509 Public Key Infrastructure Certificate and
             Certificate Revocation List (CRL) Profile", RFC 3280,
             April 2002.

Royer, et al. Experimental [Page 129] RFC 4324 Calendar Access Protocol December 2005

Authors' Addresses

 Doug Royer
 IntelliCal, LLC
 267 Kentlands Blvd. #3041
 Gaithersburg, MD  20878
 US
 Phone: +1-866-594-8574
 Fax:   +1-866-594-8574
 EMail: Doug@IntelliCal.com
 URI:   http://Royer.com
 George Babics
 Oracle
 600 Blvd. de Maisonneuve West
 Suite 1900
 Montreal, Quebec  H3A 3J2
 CA
 Phone: +1-514-905-8694
 EMail: george.babics@oracle.com
 Steve Mansour
 eBay
 2145 Hamilton Avenue
 San Jose, CA  95125
 USA
 Phone: +1-408-376-8817
 EMail: smansour@ebay.com

Royer, et al. Experimental [Page 130] RFC 4324 Calendar Access Protocol December 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Royer, et al. Experimental [Page 131]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4324.txt · Last modified: 2005/12/19 22:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki