Network Working Group                                         S. Mansour
Internet-Draft                                              AOL/Netscape
Expires: May 21, August 30, 2002                                        D. Royer
                                                     INET-Consulting LLC
                                                               G. Babics
                                                                 Steltor
                                                                 P. Hill
                                              Massachusetts Institute of
                                                              Technology
                                                       November 20, 2001
                                                          March 01, 2002

                     Calendar Access Protocol (CAP)
                        draft-ietf-calsch-cap-06
                        draft-ietf-calsch-cap-07

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt. http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 21, August 30, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001). (2002).  All Rights Reserved.

Abstract

   The Calendar Access Protocol (CAP) is an Internet protocol that
   permits a Calendar User (CU) to utilize a Calendar User Agent (CUA)
   to access an [iCAL] [RFC2445] based Calendar Store (CS).  This memo defines
   the CAP specification.

   The CAP definition is based on requirements identified by the
   Internet Engineering Task Force (IETF) Calendaring and Scheduling
   (CALSCH) Working Group.  More information about the IETF CALSCH
   Working Group activities can be found on the IMC web site at
   http://www.imc.org/ietf-calendar http://
   www.imc.org/ietf-calendar and at the IETF web site at
   http://www.ietf.org/html.charters/calsch-charter.html[1]. http://
   www.ietf.org/html.charters/calsch-charter.html [1].  Refer to the
   references within this memo for further information on how to access
   these various documents.

Table of Contents

   1.        Introduction . . . . . . . . . . . . . . . . . . . . . .    5
   1.1       Formatting Conventions . . . . . . . . . . . . . . . . .    5
   1.2       Related Documents  . . . . . . . . . . . . . . . . . . .    6
   1.3       Definitions  . . . . . . . . . . . . . . . . . . . . . .    6
   2.        CAP Design . . . . . . . . . . . . . . . . . . . . . . .   12
   2.1       System Model . . . . . . . . . . . . . . . . . . . . . .   12
   2.2       Calendar Store Object Model  . . . . . . . . . . . . . .   12
   2.3       Protocol Model . . . . . . . . . . . . . . . . . . . . .   13
   2.4       Security Model . . . . . . . . . . . . . . . . . . . . .   14
   2.4.1     Calendar User and UPNs . . . . . . . . . . . . . . . . .   14
   2.4.1.1   UPNs and Certificates  . . . . . . . . . . . . . . . . .   14
   2.4.1.2   Anonymous Users and Authentication . . . . . . . . . . .   16   15
   2.4.1.3   User Groups  . . . . . . . . . . . . . . . . . . . . . .   16
   2.4.2     Access Rights - Summary  . . . . . . . . . . . . . . . .   16
   2.4.2.1   Calendar Access Right (VCAR) . . . . . . . . . . . . . .   17   16
   2.4.2.2 Decreed   Predefined VCARs . . . . . . . . . . . . . . . . . . . . .   17
   2.4.3   Inheritance  . .
   2.4.2.3   Decreed VCARs  . . . . . . . . . . . . . . . . . . . .   18
   2.4.4
   2.4.3     CAP Session Identity . . . . . . . . . . . . . . . . . .   18   19
   2.5       Roles  . . . . . . . . . . . . . . . . . . . . . . . . .   18   20
   2.6     Calendar Addresses       CAP URL  . . . . . . . . . . . . . . . . . . .   19 . . . .   20
   2.7       Calendar Addresses . . . . . . . . . . . . . . . . . .   21
   2.8       Extensions to iCalendar  . . . . . . . . . . . . . . . .   20
   2.8   21
   2.9       Relationship of RFC 2446 (ITIP) to CAP . . . . . . . . .   20   21
   3.        Protocol Framework . . . . . . . . . . . . . . . . . . .   22   23
   3.1       BEEP Exchange Styles . . . . . . . . . . . . . . . . . .   22   23
   3.2       Use of XML, BEEP, MIME and iCalendar . . . . . . . . . . . . .   22   23
   3.3       Bounded Latency  . . . . . . . . . . . . . . . . . . . .   23   24
   4.      Formal Command Syntax  .        New Value Types  . . . . . . . . . . . . . . . .   26
   4.1     Searching and Filtering . . .   27
   4.1       CAL-QUERY Value Type . . . . . . . . . . . . .   26
   4.1.1   Grammar For Search Mechanism . . . .   27
   4.1.1     CAP-QL notes . . . . . . . . . .   26
   4.1.2   SQL-MIN notes . . . . . . . . . . .   31
   4.2       CAP-QL notes . . . . . . . . . .   27
   4.1.3   Querying Experminental Properties . . . . . . . . . . .   28
   4.1.4   37
   4.3       Example, Query by UID  . . . . . . . . . . . . . . . . .   28
   4.1.5   42
   4.4       Query by Date-Time range . . . . . . . . . . . . . . . .   29
   4.1.6   42
   4.5       Query for all Non-Booked Entries . . . . . . . . . . . .   29
   4.1.7   43
   4.6       Query with Subset of Properties by Date/Time . . . . . .   29
   4.1.8   44
   4.7       Components With Alarms In A Range  . . . . . . . . . . .   30   44
   5.        Access Rights  . . . . . . . . . . . . . . . . . . . . .   31   45
   5.1     VCAR Inheritance . . . . . . . . . . . . . . . . . . . .   31
   5.2       Access Control and NOCONFLICT  . . . . . . . . . . . . .   31   45
   6.        Commands and Responses . . . . . . . . . . . . . . . . .   32   46
   6.1       Session Commands . . . . . . . . . . . . . . . . . . . .   32   46
   6.1.1     "generate-uid" Command . . . . . . . . . . . . . . . . .   32   46
   6.1.2     "get-capability" Command . . . . . . . . . . . . . . . .   33   47
   6.1.3     "identify" Command . . . . . . . . . . . . . . . . . . .   35   49
   6.1.4     "noop" Command . . . . . . . . . . . . . . . . . . . . .   35   50
   6.2       Calendaring and Scheduling Commands  . . . . . . . . . .   36   51
   6.2.1     Restriction Tables . . . . . . . . . . . . . . . . . . .   36   51
   6.2.2   Common Attributes     Calendaring Commands . . . . . . . . . . . . . . . . .   52
   6.2.2.1   "create" Command . .   37
   6.2.2.1 "id" Attribute . . . . . . . . . . . . . . . . .   52
   6.2.2.2   "move" Command . . . .   37
   6.2.3   Common Elements . . . . . . . . . . . . . . . .   57
   6.2.2.3   "delete" Command . . . .   37
   6.2.3.1 "data" Element . . . . . . . . . . . . . . .   60
   6.2.2.4   "modify" Command . . . . . .   37
   6.2.3.2 "select" Element . . . . . . . . . . . . .   62
   6.2.2.5   "search" Command . . . . . . .   37
   6.2.3.3 "source" Element . . . . . . . . . . . .   66
   6.2.2.6   Response Codes . . . . . . . .   39
   6.2.3.4 "target" Element . . . . . . . . . . . .   71
   7.        Initial Registrations  . . . . . . . .   39
   6.2.4   Calendaring Commands . . . . . . . .   73
   7.1       BEEP Profile Registration  . . . . . . . . . .   40
   6.2.4.1 "create" Command . . . .   73
   7.2       Registration: The System (Well-Known) TCP port number
             for CAP  . . . . . . . . . . . . . . . .   40
   6.2.4.2 "delete" Command . . . . . . .   73
   8.        CAP DTD  . . . . . . . . . . . . .   50
   6.2.4.3 "modify" Command . . . . . . . . . .   75
   9.        Properties . . . . . . . . . .   53
   6.2.4.4 "move" Command . . . . . . . . . . . .   76
   9.1       Calendar Store Properties  . . . . . . . . .   59
   6.2.4.5 "search" Command . . . . .   76
   9.2       Calendar Properties  . . . . . . . . . . . . . . .   62
   6.3     Scheduling Commands . .   77
   10.       Security Considerations  . . . . . . . . . . . . . . .   80
   11.       Extensions To iCalendar  .   72
   6.3.1   "schedule" Command . . . . . . . . . . . . . .   81
   11.1      Property Value Data Types  . . . . .   72
   6.3.2   Processing Scheduling Components . . . . . . . . .   81
   11.1.1    UPN  . . .   74
   6.3.3   iTIP Examples . . . . . . . . . . . . . . . . . . . . .   76
   6.3.3.1 Sending and Receiving an iTIP request .   81
   11.1.2    UPN Filter . . . . . . . .   76
   6.3.3.2 Handling an iTIP refresh . . . . . . . . . . . . . .   82
   11.2      Calendar Components  . . . . . . . .   81
   6.3.3.3 Sending and accepting an iTIP counter . . . . . . . . .   83
   6.3.3.4 Declining an iTIP counter
   11.2.1    Agenda Component . . . . . . . . . . . . . . .   86
   7.      Response Codes . . . .   83
   11.2.2    Calendar Store Component . . . . . . . . . . . . . . .   84
   11.2.3    Calendar Access Right Component  . .   89
   8.      BEEP Profile Registration . . . . . . . . .   85
   11.2.4    VRIGHT Calendar Component  . . . . . .   91
   9.      CAP DTD . . . . . . . .   88
   11.3      Component Properties . . . . . . . . . . . . . . . .   92
   10.     Implementation Issues .   89
   11.3.1    Allow-Conflict Component Property  . . . . . . . . . .   89
   11.3.2    Charset Component Property . . . . . . . .   95
   11.     Properties . . . . . .   90
   11.3.3    Default Locale Component Property  . . . . . . . . . .   91
   11.3.4    Default Time Zone Property . . . . . . .   96
   11.1 . . . . . . .   91
   11.3.5    Owner Component Property . . . . . . . . . . . . . . .   92
   11.3.6    Relative Calendar Identifier Component Property  . . .   93
   11.3.7    Calendar Store Component Properties  . . . . . . . . .   94
   11.3.7.1  Calmaster Component Property . . . . . .   96
   11.2    Calendar Properties . . . . . . .   94
   11.3.7.2  Calendar Store Identifier Component Property . . . . .   94
   11.3.7.3  Default Access Rights Component Property . . . . . .   97
   12.     CAP Item Registration .   95
   11.3.7.4  Maximum Date Component Property  . . . . . . . . . . .   96
   11.3.7.5  Minimum Date Component Property  . . . . .  100
   12.1    Registration of New and Modified CAP Entities . . . . .  100
   12.2    Registration of New Entities .   97
   11.3.8    Descriptive Component Properties . . . . . . . . . . .   97
   11.3.8.1  REQUEST-STATUS property  . .  100
   12.2.1  Define the Item . . . . . . . . . . . . .   97
   11.3.8.2  CALID Property Parameter . . . . . . .  100
   12.2.2  Post the item definition . . . . . . . .   98
   11.3.8.3  Time Transparency  . . . . . . . .  101
   12.2.3  Allow a comment period . . . . . . . . . .   99
   11.3.8.4  Name Component Property  . . . . . . . . .  101
   12.2.4  Submit the proposal for approval . . . . . .  100
   11.3.9    Calendar Access Right Component Properties . . . . . .  101
   12.3
   11.3.9.1  VCAR Identifier Component Property Change Control . . . . . . . . . .  101
   11.3.9.2  VCAR Decreed Component Property  . . . . . . . . . . .  102
   13.     IANA Considerations
   11.3.10   Right Component Properties . . . . . . . . . . . . . .  102
   11.3.10.1 Grant Component Property . . . . . .  103
           Authors' Addresses . . . . . . . . .  103
   11.3.10.2 Deny Component Property  . . . . . . . . . . . . . . .  103
   A.      Acknowledgments
   11.3.10.3 Permission Component Property  . . . . . . . . . . . .  104
   11.3.10.4 Scope Component Property . . . . . . . . . . . . . . .  105
   B.      Bibliography
   11.3.10.5 Restriction Component Property . . . . . . . . . . . .  106
   12.       CAP Item Registration  . . . . . . . . . .  106
           Full Copyright Statement . . . . . .  107
   12.1      Registration of New and Modified CAP Entities  . . . .  107
   12.2      Registration of New Entities . . . . . . . . . . . . .  107
   12.2.1    Define the Item  . . . . . . . . . . . . . . . . . . .  107
   12.2.2    Post the item definition . . . . . . . . . . . . . . .  108
   12.2.3    Allow a comment period . . . . . . . . . . . . . . . .  108
   12.2.4    Submit the proposal for approval . . . . . . . . . . .  108
   12.3      Property Change Control  . . . . . . . . . . . . . . .  109
   13.       IANA Considerations  . . . . . . . . . . . . . . . . .  110
             Authors' Addresses . . . . . . . . . . . . . . . . . .  111
   A.        Acknowledgments  . . . . . . . . . . . . . . . . . . .  112
   B.        Bibliography . . . . . . . . . . . . . . . . . . . . .  113
             Full Copyright Statement . . . . . . . . . . . . . . .  115

1. Introduction

   This document specifies how a Calendar User Agent (CUA) interacts
   with a Calendar Store (CS) to manage calendar information.  In
   particular, it 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.

   CAP is specified as a BEEP "profile".  As such many aspects of the
   protocol (e.g., authentication and privacy) are provided within the
   BEEP core
   [BEEP].  The protocol data units leverage the standard iCalendar
   format [iCAL] [RFC2445] to convey calendar related information.

   CAP can also be used to store and fetch [iTIP] objects and when those
   objects are used here in this memo, they mean exactly the same as
   defined in [iTIP].

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)
   within the protocol defined by this memo. [iTIP].  Calendar components defined
   by [iCAL] [RFC2445] are referred to with capitalized, quoted-strings of
   text.  All calendar components start with the letter "V".  For
   example, "VEVENT" refers to the event calendar component, "VTODO"
   refers to the to-do calendar component and "VJOURNAL" refers to the
   daily journal calendar 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".

   Calendar

   CAP commands are referred by lower-case, quotes-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.

   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 of a "Calendar User".  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".

   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:

   [iCAL]

   [RFC2445] (RFC2445) which specifies the objects, data types,
   properties and property parameters used in the protocols, along with
   the methods for representing and encoding them,

   [iTIP] (RFC2446) which specifies an interoperability protocol for
   scheduling between different implementations.  The related documents
   are:

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

   [GUIDE] (draft/rfc...) which 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 other memos.  Where possible, references
   are made to the memo that provides for the specification of these
   concepts and definitions.

1.3 Definitions

   Booked

         An entry in a calendar has one of two three conceptual states.  It
         is
      scheduled scheduled, booked or it is booked.  A scheduled marked for delete.  A scheduled entry
         has been stored in the calendar store but has not been acted on
         by a calendar user (CU) or calendar user agent (CUA).  A
         scheduled entry contains a METHOD property set to an [iTIP]
         method.  A booked entry is a has its METHOD property set to CREATE.
         A marked for delete component does not have a has its METHOD property. property set to
         DELETE
   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 other calendar properties
         or calendar components.  In addition, a calendar might be
         hierarchically related to other sub-calendars. calendars with the RELATED-TO
         property.  A calendar is identified by its unique calendar
         identifier.  The [iCAL] [RFC2445] defines calendar properties,
         calendar components and component properties that make up the
         content of a calendar.

   Calendar Access Protocol (CAP)

         The standard Internet protocol that permits a Calendar User
         Agent to access and manipulate calendars residing on a Calendar
         Store.  (this memo)

   Calendar Access Rights (CAR)

         The mechanism for specifying the CAP operations ("ACTION") ("PERMISSION")
         that a particular calendar user ("UPN") are is granted or denied
         permission to perform on a given calendar object ("OBJECT"). ("SCOPE").
         The calendar access rights are specified with the "VCAR"
         calendar components within a CS and calendar.

   Calendar Component

         An object within a calendar or a calendar store (CS).  Some
         types of calendar components include calendars, events, to-dos,
         journals, alarms, time zones and freebusy data.  A calendar
         component consists of component properties and possibly other sub-
      components.
         sub-components.  For example, an event may contain an alarm
         component.

   Calendar Component Properties

         An attribute of a particular calendar component.  Some calendar
         component properties are applicable to different types of
         calendar components.  For example, DTSTART is applicable to
         VEVENT, VTODO, VJOURNAL calendar components.  Other calendar
         components are applicable only to an individual type of
         calendar component.  For example, TZURL is only applicable to
         VTIMEZONE calendar components.

   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 of the scope of the CAP
         protocol.  For example, "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, CALSCALE specifies the
         calendar scale (e.g., GREGORIAN) for the whole calendar.

   Calendar Service

         An implementation of a Calendar Store that manages one or more
         calendars.

   Calendar Store (CS)

         The data and service model definition for a Calendar Service.

   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]. [RFC1738].

   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 calendar store-wide
         information.

   Calendar User (CU)

         An entity (often biological) that uses a calendaring system.

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

   CAP Session

         An open communication channel between a CUA and a Calendar
         Service.

   Contained Component / Contained Properties

         A component or property that is contained inside a component.
         VALARM for example may be contained inside of a VEVENT.  And
         TRIGGER is a contained property of a VALARM.

   Delegate

         A calendar user (sometimes called the delegatee) who has been
         assigned participation in a scheduled calendar component (e.g.,
         VEVENT) by one of the attendees in the scheduled calendar
         component (sometimes called the delegator).  An example of a
         delegate is a team member told to go to a particular meeting.

   Designate

         A calendar user who is authorized to act on behalf of another
         calendar user.  An example of a designate is an assistant.

   Fan Out

      The calendaring and scheduling process by which a calendar
      operation on one calendar is also performed on every other
      calendar specified in the operation.

   Hierarchical Calendars

      A CS feature where a calendar has a hierarchical relationship with
      another calendar in the CS.  The top-most calendars in the
      hierarchical relationship have the CS as their parent.  There may
      be multiple top-most calendars in a given CS.  Within a given
      hierarchical relationship, all sub-calendars have a calendar with
      a "parent" relationship.  In addition, sub-calendars may have a
      relationship with another calendar that has a "child"
      relationship.  The hierarchical calendar feature is not a storage
      relationship of the calendars within the CS.  Instead it is a
      feature that relates access control rights to calendar content
      between different calendars in the CS.  The hierarchical
      relationship of a calendar is specified in the "PARENT" and
      "CHILDREN" calendar properties.

   Overlapped Booking

         A policy which indicates whether or not OPAQUE events can
         overlap one another.  When the policy is applied to a calendar
         it indicates whether or not the time span of any entry (VEVENT,
         VTODO, ...) in the calendar can overlap the time span of any
         other entry in the same calendar.  When applied to an
         individual entry, it indicates whether or not any other entry's
         time span can overlap that individual entry.

   Owner

         One or more CUs or UGs that have "OWNER" calendar access rights
      for a calendar.  The owner is specified are listed in the "OWNER" calendar
      property.
         property in a calendar.

   Qualified Calendar Identifier (Qualified CalID)

         A CalID where both the <scheme> and <csid> 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 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
      is MUST BE unique within a calendar store.  It is recommended to be
      globally unique.  A Relative CalID
         consists of the portion of the "scheme part" of a Qualified
         CalID following the Calendar Store Identifier.  This is the
         same as the "URL path" of the "Common Internet Scheme Syntax"
         portion of a URL, as defined by [URL]. [RFC1738].

   Session Identity

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

   Sub-calendars

      Calendars that have a "child" hierarchical relationship with
      another calendar, its "parent".

   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 which 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 CU.  A UPN
         is a RFC 822 compliant email address, with exceptions listed
         below, and in most cases it is deliverable to the CU.  In some
         cases it is identical to the CU's well known email address.  A
         CU's UPN MUST never be an e-mail address that is deliverable to
         a different person as there is no requirement that a person's
         UPN must be his e-mail address.  It consists of a Realm in the
         form of a valid, and unique, DNS domain name and a unique
         Username.  In  it's simplest form it looks like
         "user@example.com".

         In certain cases a UPN will not be RFC 822 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".  Usage of these special cases is
         further discussed in the authentication and authorization
         sections of this document.

2. CAP Design

2.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 "Calendar User Agent" (CUA) to send commands to and
   receive responses from a "Calendar Service".

   The CUA prepares a [MIME] encapsulated command, sends it to the CS,
   and receives a [MIME] encapsulated response.  The calendaring related
   information within these messages are represented by iCalendar
   objects.

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

2.2 Calendar Store Object Model

   [RFC2445] describes components such as events, todos, alarms, and
   timezones.  [CAP] requires more object infrastructure.  In
   particular, detailed definitions of the containers for events and
   todos (calendars), access control objects, and a query language.
   [CAP] defines the following new objects which will be discussed in
   detail in this memo

   Component   Description
   ---------   -----------------------------------------
   VCAR        An access control object
   VQUERY      A query object
   VAGENDA     A container that holds components and which is owned
               by one or more CUs.

   The conceptual model for a calendar store is shown below.  The conceptual model for a calendar store is shown below.  The
   calendar store contains VCARs, VQUERYs, VTIMEZONEs, VAGENDAs and
   calendar store properties.

   Calendars (VAGENDAs) contain VEVENTs, VTODOs, VJOURNALs, VCARs,
   VTIMEZONEs, VQUERYs and calendar properties.  Calendars may also
   contain other calendars (VAGENDAs).

   The special keyword VCALSTORE is used to denote the a root of the
   calendar store.  It is a point from which searches can begin.  It is
   the container for VTIMEZONEs, VQUERYs, and toplevel VAGENDAs.

   Calendar Store
    VCALSTORE
     |
     +-- VCARs
     +-- VQUERYs
     +-- VTIMEZONEs
     +-- VAGENDA
     |     |
     |     +--VEVENTs
     |     |    |
     |     |    +--VALARMs
     |     +--VTODOs
     |     |    |
     |     |    +--VALARMs
     |     +--VJOURNALs
     |     +--VCARs
     |     +--VTIMEZONEs
     |     +--VQUERYs
     |     +--VAGENDAs
     |     |    |
     |     |    +--VEVENTs
     |     |    |    |
     |     |    |    +--VALARMs
     |     |    +--VTODOs
     |     |    |    |
     |     |    |    +--VALARMs
     |     |    +--VJOURNALs
     |     |    +--VCARs
     |     |    +--VTIMEZONEs
     |     |    +--VQUERYs
     |     |    +--VFREEBUSY
     |     |    +--VAGENDAs
     |     |    |   |
     |     |    |   ...

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

   In this model, VSCHEDULE is a set of scheduling messages that have
   not yet been applied to the calendar.  Components in VSCHEDULE are
   discussed in more detail below.

2.3 Protocol Model

   The commands listed below are used to manipulate the data on the
   calendar store.  Their usage and semantics are defined in Section 6.

   CAP Commands
   -----------------------------------------------------------
   Command         Description
   -----------------------------------------------------------
   create          Create a new calendar component.

   delete          Delete calendar components.
   generate-uid    Generate one or more unique ids.
   get-capability  Query the capabilities of the CS. CAP server
   identify        Set a new identity for calendar access.
   modify          Modify calendar components.
   move            Move calendar components to another container.
   noop            Do nothing.
   schedule        Add an [iTIP] object to the VSCHEDULE set.
   search          Search for calendar components.
   -----------------------------------------------------------

2.4 Security Model

2.4.1 Calendar User and UPNs

   A Calendar User (CU) is an entity that can be authenticated.  It is
   represented in CAP as a UPN, which is the subject 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 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

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

   From RFC-2459, section 4.1.2.6 (Subject):

         If subject naming information is present only in the subjectAlt-
      Name
         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 822 name
         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.com" is the same as
         "FANFEEDBACK@REDSOX.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 [RFC
         2459]) 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" property said (e.g.) "ATTENDEE;CN=Joe
   Random User:MAILTO:juser@example.com" then the email address should
   be checked against the UPN, and the CN should also be checked. UPN.  This is so the "ATTENDEE" property
   cannot be changed to something misleading like "ATTENDEE;CN=Joe
   Rictus User:MAILTO:juser@example.com" and have it pass validation.
   This validation will also defeat other attempts at confusion.

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

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

   The CS should not preserve UG expansions across operations.  A UG may
   reference a static list of members, or it may represent a dynamic
   list.  Each operation SHOULD generate its own expansion in order to
   recognize changes to UG membership.

   CAP does not define commands or methods for managing UGs.

2.4.2 Access Rights - Summary

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

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

   All rights MUST be denied unless specifically granted; individual
   VCARs MUST be specifically granted to an authenticated CU.

   The access for a particular UPN is granted.

   If two rights specified in VCAR components are in conflict, the union of all grants for right
   that
   UPN minus denies access always takes precedence over the union of its denies. right that grant
   access.

2.4.2.1 Calendar Access Right (VCAR)

   Access rights within CAP are specified with the "VCAR" calendar
   component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID"
   component properties.

   Properties within an iCalendar object are unordered.  This also is
   the case for the "GRANT", "DENY" and "CARID" "VCAR" properties.  Likewise,
   there is no implied ordering required for components of a "RIGHTS"
   value type other than that specified by the ABNF.  [EDITOR'S NOTE,
   this requires a lot of review.  We think that this paragraph may be
   incorrect.]

   For details on the VCAR syntax please see section <forward ref> Section 2.4.2

2.4.2.2 Decreed Predefined VCARs

   A CS MAY choose to

   Predefined calendar access CARIDs that MUST be implemented are:

   CARID:READBUSYTIMEINFO - grants all authenticated users the right to
   read VFREEBUSY components.  Suggested definition for this VCAR:

               BEGIN:VCAR
               CARID:READBUSYTIMEINFO
               BEGIN:VRIGHT
               GRANT:*
               PERMISSION:READ
               SCOPE:SELECT * FROM VFREEBUSY
               END:VRIGHT
               END:VCAR

   CARID:REQUESTONLY - grants to users other than the owner of the
   calendar the right to write new events with the property METHOD set
   to REQUEST.  Suggested definition for this VCAR:

               BEGIN:VCAR
               CARID:REQUESTONLY
               BEGIN:VRIGHT
               GRANT:NONOWNER
               PERMISSION:WRITE
               RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST'
               END:VRIGHT
               END:VCAR

   CARID:UPDATEPARTSTATUS - grants all authenticated users the right to
   modify the instances of the ATTENDEE property set to one of their
   calendar adresses in the VEVENT and VTODO components for which the
   ORGANIZER property is set to the address of the VAGENDA in which the
   VEVENT or VTODO is stored, given that the submitted value of the
   ATTENDEE property is one of their calendar adresses.  Suggested
   definition for this VCAR:

               BEGIN:VCAR
               CARID:UPDATEPARTSTATUS
               BEGIN:VRIGHT
               GRANT:*
               PERMISSION:MODIFY
               SCOPE:SELECT att FROM VEVENT
                USING_PROPERTIES ATTENDEE att
                WHERE SELF() IN CAL-OWNERS(att) AND ORGANIZER = CURRENT-CALID()
               RESTRICTION:SELECT * FROM VEVENT
                WHERE SELF() IN CAL-OWNERS(ATTENDEE)
               END:VRIGHT
               BEGIN:VRIGHT
               GRANT:*
               PERMISSION:MODIFY
               SCOPE:SELECT att FROM VTODO
                USING_PROPERTIES ATTENDEE att
                WHERE SELF() IN CAL-OWNERS(att) AND ORGANIZER = CURRENT-CALID()
               RESTRICTION:SELECT * FROM VTODO
                WHERE SELF() IN CAL-OWNERS(ATTENDEE)
               END:VRIGHT
               END:VCAR

   CARID:DEFAULTOWNER - grants to the owner all permissions on all the
   objects in the calendar.  Suggested definition for this VCAR:

               BEGIN:VCAR
               CARID:DEFAULTOWNER
               BEGIN:VRIGHT
               GRANT:OWNER
               PERMISSION:*
               SCOPE:SELECT * FROM VAGENDA
               END:VRIGHT
               END:VCAR

2.4.2.3 Decreed VCARs

   A CS MAY choose to implement and allow persistent immutable VCARs,
   that are configured by the CS administrator, which apply to all
   calendars on the server.

   When a user attempts to modify or override a decreed VCAR 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.  The GRANT property allows the OWNERs
   all (OBJECT=*) access to their own calendar objects.  The DENY property
   disallows anyone (UPN=*) from being able to delete or modify this
   VCAR.

      BEGIN:VCAR
   CARID:Users
      CARID:ctjmocfbr-01
      NAME:Users Default Access
   GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=*
   DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;
    VALUE="Users Default Access"
    ;OBJECT=METHOD,VALUE=DELETE,MODIFY
      DECREED:TRUE
      BEGIN:VRIGHT
      GRANT:OWNER
      PERMISSION:*
      SCOPE:SELECT * FROM VAGENDA
      END:VRIGHT
      BEGIN:VRIGHT
      DENY:*
      PERMISSION:DELETE
      PERMISSION:MODIFY
      SCOPE:SELECT * FROM VCAR WHERE CARID = 'ctjmocfbr-01'
      END:VRIGHT
      END:VCAR

   Decreed VCARs MUST be BE readable by the calendar owner in standard VCAR
   format.

2.4.3 Inheritance

   Calendars inherit VCARs from their parent calendar.  Calendars whose
   parent is the Calendar Store inherit VCARs from the Calendar Store.

   VCARs specified in a calendar or a sub-calendar override all
   inherited VCARs.

2.4.4 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" CAP command.  The Calendar Service 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 may be thought of as a mapping from
   authentication credentials to UPNs.  The "identify" command allows a
   single set of 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.  A UPN with a null Username, but non-
   null Realm, such as "@foo.com" may be used to mean any identity from
   that Realm, which is useful to grant access rights to all users in a
   given Realm.  A UPN with a non-null Username and null Realm, such as
   "bob@" could be a security risk and MUST NOT be used.

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

2.5 Roles

   CAP defines methods for managing [iCAL] [RFC2445] objects in a Calendar
   Store and exchanging [iCAL] [RFC2445] objects for the purposes of group
   calendaring and scheduling between "Calendar Users" (CUs) or "User
   Groups" (UGs).  There are two distinct roles taken on by CUs in CAP.
   The CU who creates an initial event or to-do and invites other CUs as
   attendees takes on the role of "Organizer".  The CUs asked to
   participate in the event or to-do take on the role of "Attendee".
   Note that "role" is also a descriptive parameter to the "ATTENDEE"
   property.  Its use is to convey descriptive context to an "Attendee"
   such as "chair", "REQ-PARTICIPANT" or "NON-PARTICIPANT" and has
   nothing to do with the scheduling workflow.

2.6 Calendar Addresses

   Calendar addresses are URIs that are modeled after URLs [URL]. CAP
   uses the following forms of URI.

      [[<scheme>]://<csid>[:<port>]/]<relativeCALID>

   where:

      <scheme> URL

   The CAP URL scheme is "cap", the protocol described in this memo.

      <csid> is the Calendar Store ID.  It is the network address of the
      computer on which used to designate calendar stores, and
   calendars accessible using the CAP server is running.

      <port> is optional. protocol.

   The port must be present in CAP URL scheme conform to the generic URL if syntax, defined in RFC
   2396, and follows the Guidelines for URL Schemes, set forth in RFC
   2718.

   A CAP server does not listen on URL begins with the default port number.

      <relativeCALID> protocol prefix "cap" and is defined by the
   following grammar.

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

   'relcalid' is an identifier that uniquely identifies the a calendar on a
   particular calendar store.  There is no implied structure in a
   Relative CALID.  It is an arbitrary string of
      printable 7 bit ASCII characters.  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.  It is recommended that the

   Examples:

         cap://cal.example.com
         cap://cal.example.com/abcd1234QWER

   Relative CALID be globally unique.

   If the <scheme> and <csid> CAP URLs are present the calendar address is said
   to be "qualified".  Senders permitted and are required resolved according to supply the
   <relativeCALID> portion of the address.  A qualified calendar address
   is required when the <csid>
   rules defined in Section 5 of the target calendar address differs
   from that RFC 2396.

   Example of the a relative CAP server receiving the command.

   Examples of URL:

         abcd1234QWER

2.7 Calendar Addresses

   Calendar addresses can be described as absolute or relative CAP URIs:

       cap://calendar.example.com/user1
       ://calendar.example.com/user1
       user1
       cap://calendar.example.com/conferenceRoomA
       cap://calendar.example.com/89798-098-zytytasd URLs.

   Examples:

         cap://cal.example.com/abcd1234QWER
         abcd1234QWER

   For a user currently authenticated to a the CAP server on
   calendar.example.com, the first three
   cal.example.com, these two calendar addresses refer to the same
   calendar.

2.7

2.8 Extensions to iCalendar

   In mapping the calendar query feature, and access rights onto the
   iCalendar format, several extended iCalendar properties and
   components are defined by this memo.

   The search operation makes use of a new component, called VQUERY.
   The component consists of a set of new properties: QUERY, EXPAND EXPAND,
   NAME and
   QUERYNAME, QUERYID, that define a search filter.  VQUERY is used by the
   following CAP commands: "search", "move", "modify" "modify", "move" and "delete".

   Access rights are specified in the new iCalendar VCAR component.

   Calendar are specified by the new VAGENDA component.

2.8

2.9 Relationship of RFC 2446 (ITIP) to CAP

   [iTIP] describes scheduling methods which result in indirect
   manipulation of calendar components.  In CAP, the "schedule" "create" command is
   used to submit scheduling requests.  Other CAP commands such as
   "create", "delete", "modify" and "move" provide direct manipulation
   of calendar components.  In the CAP calendar store model, scheduling
   messages are conceptually kept separate from other calendar
   components.  This is modeled with the VSCHEDULE set.  Note that this
   is a conceptual model, the actual storage details are left to
   implementations.

   When scheduling is used, the METHOD is saved along with components.
   A scheduled component becomes a booked component when its METHOD
   property is removed. set to CREATE.  For example, a component whose METHOD is
   "REQUEST" is scheduled.  The component becomes booked when the METHOD
   is removed. set to "CREATE".

   Several scheduled entries can be in the CS for the same UID.  They
   are consolidated when booked, or they are removed from the CS.

   For example, if you were on vacation, you could have a REQUEST to
   attend a meeting and several updates to that meeting.  Your CUA would
   have to "search" them out of the CS using CAP, process them,
   determine what 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 entry or "modify" an
   existing entry.  Finally, the CUA can do a "delete" of all of these
   now old scheduling requests in the CS.  See [iTIP] for details on
   resolving multiple [iTIP] scheduling entries.

3. Protocol Framework

   CAP uses the BEEP application protocol kernel mapped onto TCP (refer
   to [BEEP] and [BEEPTCP] for more information).  The default port that
   the Calendar Service listens for connections on is port 5229. --TBD--.

3.1 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 containers, MUST use a one-
   to-many exchange, with a distinct answer associated with each target.
   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.

3.2 Use of XML, BEEP, MIME and iCalendar

   NOTE: This topic is under debate and all CAP commands might drop the
   XML wrapper and just send the text/calendar objects and it would
   contain the command.

   Each BEEP payload exchanged via CAP consists of an XML document and
   possibly an arbitrary is a iCalendar MIME content.  The XML document defines the
   action content that
   fully conforms to be performed.  When needed, the calendaring related data is
   included in a related MIME part containing an iCalendar object.

   If only an XML document is sent in the BEEP payload, then the mapping
   to a BEEP payload is straight-forward, e.g., [RFC2445].

   C: MSG 1 2 . 432 62
   C: Content-Type: application/beep+xml application/cap+xml
   C:
   C: <generate-uid num=10/> num="10"/>
   C: END

   Otherwise, arbitrary MIME content is included in the BEEP payload by
   using a "multipart/related" (see [RFC 3087]), identified
   using a
   "cid" URL (see [RFC 2392]), and the XML control document occurs as
   the starting body part, e.g., CDATA.

   C: MSG 1 3 . 1023 951
   C: Content-Type: multipart/related; boundary="boundary-asdf123";
   C:               start="<1@cal.example.com>";
   C:               type="application/beep+xml"
   C:
   C: --boundary-asdf123
   C: Content-Type: application/beep+xml
   C: Content-ID: <1@cal.example.com>
   C:
   C:
   C: <schedule id="abcd12346">
   C:   <target relcalid="john-relcalid"/>
   C:   <target relcalid="bob-relcalid"/> Content-type: application/cap+xml
   C:   <data content="cid:2@cal.example.com"/>
   C: </schedule> <create>
   C: --boundary-asdf123 <![CDATA[
   C: Content-Type: text/calendar
   C: Content-ID: 2@cal.example.com
   C:

   C: BEGIN:VCALENDAR
   C: METHOD:REQUEST
   C: CMDID:abcd12346
   C: BEGIN:VEVENT
   C: UID:abcd12345
   C: ORGAGNIZER:cap://cal.example.com/mary-relcalid
   C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/mary-relcalid
   C: ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.example.com/john-relcalid
   C: ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.example.com/bob-relcalid
   C: DTSTART:20010920T180000Z
   C: DTEND:20010920T190000Z
   C: SUMMARY:Mary invites John and Robert
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-asdf123-- ]]>
   C: </create>
   C: END

   The MIME content-type "application/beep+xml" is defined in Section
   6.4

   NOTE: From this point on many of [BEEP]. the 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 as the BEEP payload
   boundries are independant of CAP.

3.3 Bounded Latency

   A CUA can associate a maximum latency time to a CAP command with the
   "max-time" element.
   "latency" argument.  If the CS is unable to complete the request in
   the specified amount of time, then the server CS sends a "timeout"
   request MSG on
   the same channel to which the CUA MUST respond reply with a an "abort" or a
   "continue" reply.

   Upon receiving an "abort" reply, the CS MUST terminate the command in
   progress and return a request-status code 2.0.3.
   progress.

   When receiving a "continue" reply the server resumes its work in
   progress.  Note that a new latency time MAY be included in a
   "continue" reply.

   The timeout element takes two arguments "latency" argument and "action". the "action" MUST both be added to the CAP
   command, or nether can be added to a command.  The "latency" argument value
   MUST be BE set to the maximum latency time in seconds.  The "action"
   argument accepts the following values: "ask" and "abort".  If the
   maximum latency time is exceeded and the "action" argument is set to
   "ask", then CS MUST send a "timeout" message to inform the CUA,
   otherwise if the argument "action" is set to "abort" the CS can
   directly terminate the request and return a request-status code
   2.0.3.

   Example:

   In this example bill@cal.example.com attempts to read a calendar but
   the latency time he supplies is not sufficient for the server to
   complete the command.

   C: MSG 1 4 . 2043 680
   C: Content-Type: multipart/related; boundary="boundary-zxy123";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-zxy123
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com application/cap+xml
   C:
   C: <search id="xyz12346">
   C:   <max-time latency=3 action=ask/>
   C:   <select>
   C:     <source relcalid='opaqueid101'/>
   C:     <data content="cid:2@cal.example.com"/>
   C:   </select>
   C: </search> latency="3" action="ask">
   C: --boundary-zxy123 <![CDATA[
   C: Content-Type: text/calendar
   C: Content-ID: 2@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: METOD:SEARCH
   C: TARGET:relcalid-123
   C: CMDID:xyz12346
   C: BEGIN:VQUERY
   C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
   C:  WHERE DTEND >= '19990714T080000Z' AND
   C:  DTSTART <= '19990715T080000Z'
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-zxy123-- ]]>
   C: </search>
   C: END

   # After 3 seconds
   S: MSG 1 2 . 102 64
   S: Content-Type: application/beep+xml application/cap+xml
   S:
   S: <timeout id="xyz12346"/> cmdid="xyz12346"/>
   S: END

   If Bill wants to continue and give the server more time he would
   issue a "continue" reply:

   C: RPY 1 2 . 166 113
   C: Content-Type: application/beep+xml application/cap+xml
   C:
   C: <continue id="xyz12346">
   C:   <max-time latency=3 action=ask/>
   C: </continue> cmdid="xyz12346" latency="3" action="ask"/>
   C: END

   If instead, Bill wants wanted to abort the command and not wait any further
   he would issue an "abort" reply:

   C: RPY 1 2 . 166 62
   C: Content-Type: application/beep+xml application/cap+xml
   C:
   C: <abort id="xyz12346"/> cmdid="xyz12346"/>
   C: END

   S: RPY 1 4 . 2723 114
   S:
   S: <result>
   S: <request-status code="2.0.3">
   S: Request Aborted by the CUA.
   S: </request-status>
   S: </result>
   S: END

4. Formal Command Syntax New Value Types

4.1 Searching 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 Filtering contains query statements targeted at locating those values.

     This section describes CAP's selecting was based on [SQL92] and filtering entities within
   a calendar store.  It [SQLCOM].
     NOTE: This grammar is based on NOT SQL92.

     (1) For the Standard Query Language (SQL)
   defined purpose of a query, all components should be
         handled as tables, and the properties of those
         components, should be handled as columns.

     (2) All VAGENDAs and CS's look like tables for the purpose of a
         QUERY. And all of their properties look like columns in
         those tables.

     (3) You CAN NOT do any cross component-type joins. And that means
         you can ONLY have one component, OR one VAGENDA OR one CALSTORE
         in [SQL].

4.1.1 Grammar For Search Mechanism

    search     = "BEGIN:VQUERY" CRLF
                 [expand] querycomp
                 "END:VQUERY" CRLF

    expand     = "EXPAND" ":" ( "TRUE" / "FALSE") CRLF
               # the default is EXPAND:FALSE

    comp-name  = "VEVENT" / "VTODO" / "VJOURNAL"
   	    / "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VAGENDA"
               / "VCAR" / iana-name / x-name

    querycomp  = ( query ) / ( queryname query ) / queryname

    queryname  = "QUERYNAME:" text

    query      = "QUERY:" ( query-min / query-92 )
    #
    # NOTE: query-min the FROM clause.

     (4) Everything in the SELECT and WHERE clauses MUST be implemented BE from the
         component type, or VAGENDA OR CALSTORE in CSs.
    #
    #   query-92 the FROM clause.
         This includes the values from the USING_PROPERTIES and
         USING_COMPONENTS clauses.

     (5) The '.' is ONLY used if CAPABILITY returns SQL-92
    #   as to separate the QUERYLEVEL value or if QUERYLEVEL table name (component)
         and column name (property) when selecting a property that
         is not
    #    specified.
    #

    query-min      = capselect-min

    capselect-min  = "SELECT" capmin-cols "FROM" capmin-comps
                     "WHERE" capmin-cmp

    capmin-col     = # Any contained inside of a component that is targeted in
         the TARGET property.

         In this example the '.' is used to separate the
         TRIGGER property name found from its contained component (VALARM)
         which is contained in any of VEVENT in the
                     components.

    capmin-cols    = ( capmin-col / capmin-col ","
                     capmin-cols )
    capmin-comps   = ( comp-name / comp-name ","
                     compmin-comps )

    capmin-cmp     = ( colname capmin-cmp-rhs
                   / colname capmin-cmp-rhs
                     capmin-logical capmin-cmp )

    capmin-cmp-rhs = ( capmin-oper colvalue
                   /   "IS" ["NOT"] "NULL" )

    colname        = ( # Any valid component property name.
                   / "*" )

    cmpmin-oper    = ( " = "  / " != " / " < " / " > " / " <= "
                   / " >= " )

    capmin-logical = ( " AND " / " OR " )

    query-92       = capselect-92 capfrom-92 capwhere-92
                     caporderby-92

    capselect-92   = # Any valid [SQL] string that goes into
                     a selected TARGET
         (relcalid). All TRIGGER values in any VEVENT in relcalid
         would be returned.

             TARGET:relcalid
             QUERY: SELECT clause.

    capfrom-92     = # Like capmin-comps except embedded spaces
                     # are allowed between commas - per [SQL].

    capwhere-92    = # Any valid [SQL] string that goes into VALARM.TRIGGER FROM VEVENT

     (6) A contained component without a
                     # WHERE clause.

    caporderby-92  = # Any valid [SQL] string that goes into '.' it is the same as
         <component>.* with the result being a
                     # ORDERBY clause.

4.1.2 SQL-MIN notes

      (1) No inlined spaces are allowed if not properly formatted
         <component>(s) in the grammar above.

      (2) Note that cmpmin-oper data stream, and capmin-logical elements are
      surrounded by exactly one space.

     Use 'VEVENT,VTODO', not 'VEVENT, VTODO'
     Use 'DTSTART <= 20000605T131313Z', not
         'DTSTART <= 20000605T131313Z'.
     Use ' correctly formatted
         in the contained component(s) in iCalendar (RFC2445) format.

                 (a) SELECT VEVENT.<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'

           Note: (a) Selects all instances of <a-property-name>
                     from all VEVENT components.

                 (b) and ' OR ', not 'AND' (c) Select all VALARM components from all
                     VEVENT components.

                 (d) Selects every property and not 'OR'.

      (3) There every component
                     that is no ORDERBY.  Sorting will take place in any VEVENT component.

                 (e) Selects all properties and all contained
                     components in all VEVENT components that have a VALARM
                     with a TRIGGER property value between the order provided
                     dates and times.

           NOT VALID:

                 (f) SELECT VEVENET.VALARM.TRIGGER FROM VEVENT

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

           Note: (g) Is NOT valid because it contains
                     two '.' characters in the
      columns are supplied SELECT clause.

                 (h) Is NOT valid because it mixes VEVENT
                     and VTODO properties in the command.

      (4) The CS MUST sort at least same VQUERY.

      (7) When multiple QUERY properties are supplied in a single VQUERY
          component, the first column.  The CS MAY sort
      additional columns.

      (5) If EXPAND=FALSE and if colname is "*" sorting will be by results returned are the
      DTSTART  value ascending.  If EXPAND=TRUE and if colname is "*"
      sorting will be by same as the RECURRENCE-ID results
          returned for multipled VQUERY components having each a single
          QUERY property.

       Formal Definition: The value ascending.

      If colname is "*" and capmin-coms type is VALARM only then sorting will
      be by TRIGGER time in UTC ascending.

      (6) SQL-MIN MUST be implemented.

4.1.3 Querying Experminental Properties

4.1.4 Example, Query defined by UID

   The the following example would match
       notation:

       comp-name  = "VEVENT"    / "VTODO"   / "VJOURNAL"
                  / "VTIMEZONE" / "VALARM"  / "VFREEBUSY"
                  / "VAGENDA"   / "VCAR"    / "CALSTORE"
                  / "VQUERY"    / iana-name / x-comp

       querycomp  = queries / ( queryname queries) / queryname

       queryname  = "QUERYNAME" *(";" xparam) ":" text CRLF

       queries    = query
                  / queries query

       query      = "QUERY" *(";" xparam) ":" cal-query CRLF

                    ; NOTE: There is exactly one space separating
                    ; the entire content various parts of cal-query
                    ;
       cal-query  = "SELECT"   SP   cap-cols  SP
                    "FROM"     SP   comp-name SP
                    *(cauprops SP / capcprops SP)
                    "WHERE"    SP   cap-expr

                  / "SELECT" SP cap-cols SP
                    "FROM"   SP comp-name

       capuprops   = "USING_PROPERTIES" SP uprop-list

       uprop-list  = (cap-col SP cap-local)
                   / uprop-list SP cap-col SP cap-local

       capcprops   = "USING_COMPONENTS" SP cprop-list

       cprop-list  = (cap-comp cap-local)
                   / cprop-list SP cap-col SP cap-local

       cap-col     = ; Any property name found in the component
   with
                     ; named in the UID property equal to "uid123" and not expand any multiple
   instances comp-tbl used in the FROM clause.
                     ;
                     ;   SELECT ORGANIZER FROM VEVENT ...
                     ;
                     ; OR
                     ;
                     ; A component name of an existing component contained
                     ; inside of the component.  If cmp-tbl used in the CUA does not know if "uid123" was
   a VEVENT, VTODO, VJOURNAL, or any other component, then all
   components that FROM clause.
                     ;
                     ;   SELECT VALARM FROM VEVENT ...

                     ; NOTE: there is NO space around the CUA supports MUST be supplied "," on
                     ; the QUERY
   property.  This example assumes the CUA only supports VTODO and
   VEVENT.

   If the results were empty it could also mean next line
       cap-cols    = cap-col / ( cap-cols "," cap-col)
                     / "*"
                     /
       cap-param   = ; Any parameter that "uid123" was a
   property may be contained in a component other than a VTODO or VEVENT.

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

   The following example would match the entire content cap-col
                     ; in the supplied PARAM() function

       cap-local   = ; Any string that is composed of the component
   with characters
                     ; that could be a cap-col name, but is not any
                     ; cap-col name. It is suggested that the UID property equal
                     ; string start with "my-" to "uid123" and would expand ensure it does not
                     ; conflict with any
   instances existing or future cap-col name.
                     ; This name MUST BE defined in the cap-using and
                     ; can only be used in cap-expr of the component after applying any recurrence rules.  This same query.
                     ; And this name is only known and valid for the
                     ; provided query could select multiple instances and only for the lifetime of components each with
                     ; the query. If multiple QUERY properties exist
                     ; in the same UID.  Each instance would have a unique RECURRENCE-ID of component, it is only valid and usable
                     ; in the
   expanded component.

   BEGIN:VQUERY
   EXPAND:TRUE
   QUERY:SELECT * FROM VEVENT,VTODO WHERE UID same QUERY property where it was supplied.

       col-value   = 'uid123'
   END:VQUERY

4.1.5 Query col-literal
                   / "SELF()"
                   / "CAL-OWNERS(" cal-address ")"
                   / "CURRENT-CALID()"

       cal-address = ; A CALID as define by Date-Time range

   This query selects CAP

       col-literal = "'" literal-data "'"

      literal-data = ; Any data that matches the entire content value type of every booked VEVENT the
                     ; column that has
   an instance greater than or equal is being compared. That is you can
                     ; not compare PRIORITY to July 1st, 2000 00:00:00 UTC "some string" because
                     ; PRIORITY has a value type of integer. If it is
                     ; not preceded by the LIKE element, any '%' and
   less than or equal '_'
                     ; characters in the literal data are not treated as
                     ; wildcard characters and do not have to July 31st, 2000 23:59:59 UTC

   BEGIN:VQUERY
   EXPAND:TRUE
   QUERY:SELECT * FROM VEVENT
     WHERE RECURRENCE-ID >= '20000801T000000Z'
     AND RECURRENCE-ID <= '20000831T235959Z'
     AND METHOD = 'CREATE'
   END:VQUERY

4.1.6 Query for all Non-Booked Entries

   The following example selects be backslash
                     ; escaped.
                     ;
                     ; OR
                     ;
                     ; If the entire content of all scheduling
   VEVENTS in literal-data is preceded by the CS.  The default for EXPAND LIKE
                     ; element it may also contain the '%' and '_'
                     ; wildcard characters. And if the literal data
                     ; that is FALSE, so comparing contains any '%' or '_'
                     ; characters, they MUST BE backslash escaped as
                     ; described in the
   recurrence rules will notes below in order for them not
                     ; to be expanded.

   BEGIN:VQUERY
   QUERY:SELECT * FROM VEVENT,VTODO WHERE METHOD IS treated as wildcard characters.

       cap-ucol    = cap-col / cap-local

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

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

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

   The following example fetches NULL"
                   / col-value SP "NOT IN" cap-colval"
                   / col-value SP "IN" cap-colval"

       cap-colval     = cap-ucol
                   / "PARAM(" cap-ucol "," cap-param ")"

       cap-oper    = "="
                   / "!="
                   / "<"
                   / ">"
                   / "<="
                   / ">="

       cap-logical = "AND" / "OR"

       SP          = ; A single white space ascii character
                     ; (value in HEX %x20).

       CRLF        = ; As defined in RFC 2445.

       xparam      = ; As defined in RFC 2445.

       x-prop      = ; As defined in RFC 2445.

       x-comp      = ; As defined in RFC 2445.

4.1.1 CAP-QL notes

         (1) There is no ORDERBY.  Sorting will take place in the UIDs of all non-booked VEVENTs order the
         columns are supplied in the command.

         Float and
   VTODOs.

   BEGIN:VQUERY
   QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD IS NOT NULL
   END:VQUERY

4.1.7 Query with Subset of Properties integer values MUST BE sorted by Date/Time

   In this example only their numeric value.

         This means the named properties result of a sort on an integer value type will be selected be:

                   1, 2, 100, 1000

           and all
   booked not

                   1, 100, 1000, 2

         This means the result of a sort on an float value type will be:

                   1.1, 2.23, 100.332, 1000.12

           and non-booked components not

                   1.1, 100.332, 1000.12, 2.23

         Date and date time values will be selected that have a DTSTART
   from February 1st to February 10th 2000.

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

4.1.8 Components With Alarms In A Range

   This example fetches all components with an alarm that triggers
   within sorted by their equivalent
         value in UTC. No matter what the specified returned time range.  In this case only zone in the UID, SUMMARY,
   and DESCRIPTION will be selected for all booked VEVENTS result
         set returns. This is so that have an
   alarm between the two date-times.

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

5. Access Rights

   Access rights within CAP if multiple components are specified with returned
         each in a unique time zone, the "VCAR" calendar
   component, "RIGHTS" value type and results will be sorted in UTC.
         This does not mean the "GRANT", "DENY" and "CARID"
   component properties.

   Properties within a VCAR values must be evaluated converted to UTC in the order provided.

5.1 VCAR Inheritance

   Calendar access rights specified
         data returned to the CUA. It means the CS must do the sort in a calendar store UTC.

         All other values are inherited sorted according to the locale sorting order
         as
   default calendar access rights for any calendar specified in the parent calendar. Or the CS locale if the calendar store.  Likewise,
         does not have any calendar access rights specified in locale set, or the host operating system
         locale if the CS does not specify a
   root calendar are inherited as default calendar access rights for any
   sub-calendar locale. And the locale to
         use for the root calendar.  Furthermore, calendar access
   rights specified sort is determined in a sub-calendar are inherited as default calendar
   access rights for any calendars that are hierarchically below order.

         (2) The CS MUST sort at least the
   sub-calendar.

   Calendar access rights specified in a calendar override any default
   calendar access rights.  Calendar access rights specified within a
   sub-calendar override any default calendar access rights.

5.2 Access Control and NOCONFLICT

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

6. Commands and Responses

   CAP commands and responses are described in this section.

   As mentioned in Section 3.2, CAP commands are defined by XML
   documents. first column.
             The syntax of CS MAY sort additional columns.

         (3) If the commands cap-cols is defined in Section 9, this
   section describes their semantic.

   The attributes of a command are described in the "Attributes:"
   section in the command descriptions below.  Similarly the "Elements:"
   section describes the elements that compose the command.  The
   "Response:" section, identifies only "*" and nothing else, then:

               If EXPAND=FALSE sorting will be by the responses that may DTSTART value
               ascending.

               If EXPAND=TRUE sorting will be returned by the server.

   In RECURRENCE-ID value
               ascending.

             If one or more DTSTART or RECURRENCE-ID components have
             exactly the examples below, lines preceded with "S:" refer to same value, the server
   and lines preceded with "C:" refer to order for those matching
             components is unspecified.

             If the client.  Lines in which selected component(s) do not contain a DTSTART
             or a RECURRENCE-ID, then the
   first non-whitespace character order is a "#" unspecified.

         (4) All literal values are editorial comments surrounded by single quotes ('), not
             double quotes ("), and
   are not part of without any quotes. If the protocol.

6.1 Session Commands

6.1.1 "generate-uid" Command

   Attributes:

      num: Number of UIDs to generate (1 if omitted).

   Response:

      "uid-list"

   The "generate-uid" command returns one value
             contains quotes or more unique identifiers
   which MUST any other ESCAPED-CHAR, they must be unique on the server's calendar store.  It is
   recommended
             backslash escaped as described in section "4.3.11 Text"
             of RFC2445. Any LIKE wildcard characters that are part
             of any literal data that is preceded by a LIKE clause and
             is not intended to mean wildcard search, MUST BE escaped as
             described in note (7) below.

         (5) When comparing DATE-TIME to DATE value types and when
             comparing DATE to DATE-TIME value types, the return values result will
             be globally unique ids.

   Example:

   C: MSG 1 5 . 2837 60
   C: Content-Type: application/beep+xml
   C:
   C: <generateuid num=5/>
   C: END
   S: RPY 1 5 . 2897 328
   S: Content-Type: application/beep+xml
   S:
   S: <uid-list>
   S:   <uid>20011121T120000Z-12340@cal.example.com</uid>
   S:   <uid>20011121T120000Z-12341@cal.example.com</uid>
   S:   <uid>20011121T120000Z-12342@cal.example.com</uid>
   S:   <uid>20011121T120000Z-12343@cal.example.com</uid>
   S:   <uid>20011121T120000Z-12344@cal.example.com</uid>
   S: </uid-list>
   S: END

6.1.2 "get-capability" Command

   Attributes:

      None

   Elements:

      None

   Response:

      "capability"

   The "get-capability" command returns information about true if the Calendar
   Service given DATE value is on the current state of same day as the connection with DATE-TIME
             value. And they are compared in UTC no matter what time zone
             the client.
   The values returned data may differ depending on current user identify actual have been stored in.

               VALUE-1             VALUE-2            Compare Results

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

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

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

            When comparing DATE and DATE-TIME values with the security level of LIKE
            clause the connection.

   Client implementations SHOULD NOT require any capability element
   beyond those defined in this specification, and MAY ignore any non-
   standard, experimental capability elements.  Non-standard
   experimental capability elements MUST comparison will be prefixed with done as if the text "x-".
   The prefix SHOULD also include value is
            a vendor identifier.  For example, "x-
   foo-barcapability", for RFC2445 DATE or DATE-TIME string value.

                   LIKE '2002%' will match anything in the non-standard "barcapability" capability 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%').

            Again all comparisons will be done in UTC.

            Using a LIKE value of the vendor "foo".  It may "%00%, would return different results depending on any value that
            contained two consecutive zeros.

         (6) DTEND and DURATION.

             When a QUERY contains a DTEND value, then the UPN.

       Capability   Occurs     Description
       -------------------------------------------------------
       cap            1          Container for CAP related elements.
         version      1+         Version(s) of CAP, MUST include at
                                 least "1.0".

         query-level  1+         Indicates level of SQL support.
                                 SQL-MIN or SQL-92. MUST include at
                                 least SQL-MIN.
         car          1+         Indicates level of CAR support.
                                 CAR-MIN or CAR-FULL-1. CAR-MIN CS MUST
                                 be present.

         date         0 or 1
            max       0 or 1     The datetime also
             evaluate any existing DURATION property value in UTC beyond
                                 which the server cannot accept. If
                                 not specified and determine
             if it has an effective end time that matches the default is
                                 99991231T235959Z.
            min       0 or 1     The datetime QUERY
             supplied  DTEND value prior to which or any range of values supplied by
             the server cannot accept. If not
                                 specified QUERY.

             When a QUERY contains a DURATION value, then the default is
                                 00000101T000000Z.

       icalendar      1          Container for CAP related elements.
         version      1+         Version(s) of iCalendar that is (are) supported.
         max-component-size
                      0 or 1     A positive integer CS MUST
             also evaluate any existing DTEND property value and determine
             if it has an effective duration that specifies matches the size QUERY
             supplied DURATION value or any range of values supplied by
             the largest iCalendar object QUERY.

             As DTEND is the first time that is excluded from a components
             time range, any DURATION supplied by the server will accept in bytes. Objects
                                 larger QUERY that is
             exactly one second less than this will be rejected.
                                 The absence of this attribute indicates
                                 no limit.

       itip           1          Container for iTIP related elements.
         version      1+         Version(s) of ITIP, DTEND MUST include match the QUERY.
             And if the DURATION ends exactly at least
                                 "1.0".

   Example:

   C: MSG 1 6 . 3225 57
   C: Content-Type: application/beep+xml
   C:
   C: <get-capability/>
   C: END
   S: RPY 1 6 . 3282 423
   S: Content-Type: application/beep+xml
   S:
   S:
   S: <capability>
   S:  <icalendar>
   S:    <version>2.1</version>
   S:    <max-component-size>65536</max-component-size>
   S:  </icalendar>
   S:  <itip>
   S:    <version>1.0</version>
   S:  </itip>
   S:  <cap>
   S:    <version>1.0</version>
   S:    <car>CAR-MIN</car>
   S:    <query-level>SQL-MIN</query-level>
   S:    <date>
   S:        <min>00000101T000000Z</min>
   S:        <max>99991231T235959Z</max>
   S:    </date>
   S:  </cap>
   S: </capability>
   S: END

6.1.3 "identify" Command

   Attribute:

      upn: The UPN of the new identify to assume.

   Element:

      None

   Response:

      "result" with one of computed DTEND it
             MUST NOT match.

             Any DTEND supplied by the following request-status codes:

         2.0 Successful.

         6.4 Identity not permitted.

   The "identify" command allows QUERY that is exactly one second
             more than an end time computed from a DURATION MUST match the CUA to set
             QUERY. Any end time that is computed from a new identity to be
   used for calendar access.

   The CS determines through an internal mechanism if DURATION that
             exactly matches the credentials supplied at authentication permit the assumption of the selected
   identity.  If they do, the session assumes the new identity,
   otherwise DTEND MUST NOT match.

               (6.1) Given a security error meeting room reserved with a component
                     that contains:
                   DTSTART:20020127T000000Z
                   DTEND:20020127T010000Z

                   The reservation is returned.

6.1.4 "noop" Command

   Arguments:

      None

   Element:

      None

   Response:

      "result" really from:

                           January 27th, 2002 00:00:00
                   To:

                           January 27th, 2002,00:59:59

               (6.2) Given another meeting room reserved with the following request-status code:

         2.0 successful

   This command does nothing.  It can be sent to the server periodically
   to request a component
                     that contains:

                   DTSTART:20020127T000000Z
                   DURATION:P59M59S

                   The reservation is really from:

                           January 27th, 2002 00:00:00
                    To:

                           January 27th, 2002,00:59:59

               (6.3) A QUERY that contains:

                   ... VEVENT.DTSTART = '20020127T00000Z'
                   AND VEVENT.DTEND = '20020127T010000Z'

                   MUST match both (6.1) and (6.2).

               (6.4) A QUERY that contains:

                   ... VEVENT.DTSTART = '20020127T00000Z'
                   AND DURATION = 'P59M59S'

                   MUST match both (6.1) and (6.2).

         (7) [NOT] LIKE notes:

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

            LIKE pattern matches always cover the session.

   [EDITORS NOTE: should an unauthenticated and unidentified client be
   able 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.
            That is to issue this command?]

   [EDITORS NOTE: search for a '%' or '_' in view of the integration string:

                  LIKE '%\%%'    Matches any string with BEEP should "noop" be
   removed?]

   Example:

   C: MSG 1 7 . 3705 47
   C: Content-Type: application/beep+xml
   C:
   C: <noop/>
   C: END
   S: RPY 1 7 . 3752 91
   S: Content-Type: application/beep+xml
   S:
   S: <result>
   S:   <request-status code="2.0"/>
   S: </result>
   S: END

6.2 Calendaring and Scheduling Commands

6.2.1 Restriction Tables

   Calendaring data are sent encapsulated a '%' in iCalendar objects (see
   Section 6.2.3.1).  The restriction tables listed it.
                  LIKE '%\_%'    Matches any string with a '_' in it.

            Strings compared using the commands
   below describe LIKE clause MUST BE performed
            using case in-sensitive comparisons. ('a' = 'A').

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

            Some property values (such as the iCalendar data for these
   commands 'recur' value type), contain
            commas and replies. are not multi valued. The presence column uses CS must understand the following values
            objects being compared and understand how to assert whether a
   property is required, is optional determine how any
            multi valued or multi instances properties or parameter values
            are separated, quoted, and backslash escaped and perform the number of times it may
   appear
            comparisons as if each value existed by itself and not quoted
            or backslash escaped when comparing using the CONTAINS() element.

            And see the examples in the iCalendar object.  A comment may be provided next note (8).

         (8) 'col-value SP "NOT IN" cap-colval"

            This is similar to further
   clarify the presence criteria. LIKE element, except it does value
            matching and not string comparison matches.

            Some iCalendar objects can be multi instance and multi valued.
            The table below defines IN operator will return a match if the values for literal value supplied
            as part of the presence column.

   Presence
   Value       Description
   --------------------------------------------------------------
   1           One instance MUST be present
   1+          At least one instance MUST be present
   0           Instances 'IN' clause is contained in the value of this property MUST NOT be present
   0+          Multiple instances MAY be present
   0 or 1      Up to 1 any
            instance of this property MAY be present
   --------------------------------------------------------------

   While the tables list every component and property, their purpose named property or parameter, or is
   not to define the meaning in any of
            the component multiple values in the named property or property.

6.2.2 Common Attributes

6.2.2.1 "id" Attribute parameter. The "id" attribute is an optional identifier for
            '%' and '_' matching characters are not used with the command.  When
   specified, '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       FOO:parameter=1,2:x             One parameter, two values.
            d       FOO:parameter="1,2",3:y         One parameter, two value.
            e       FOO:parameter=","
                    END:A-COMPONENT

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

                    '2' IN parameter                would match (c) only.
                    '1,2' IN parameter              would match (d) only.
                    '%,%' IN parameter              would match (d) and (e).

                    LIKE(property, "value1%"        would match (a) and (b)
                    LIKE(property, 'value%')        would match (a) and (b)
                    LIKE(parameter, '1%')           would match (c) and (d)
                    LIKE(parameter, '%2%')          would match (c) and (d)
                    LIKE(parameter, ',')            would NOT match any.

            Some property values (such as the 'recur' value type), contain
            commas and are not multi valued. The CS will include this attribute in all must understand the related
   messages it returns
            objects being compared and understand how to determine how any
            multi valued or multi instances properties or parameter values
            are separated, quoted, and backslash escaped and perform the client.

   The "id" attribute is mainly useful for the "timeout" message (see
   Section 3.3).  The CAP server imposes no restriction on
            comparisons as if each value existed by itself and not quoted
            or backslash escaped when comparing using the value. CONTAINS() element.

            If uniqueness IN is required, preceded by 'NOT' then it there is a match when
            the responsibility of the CUA
   to generate unique values.

6.2.3 Common Elements

6.2.3.1 "data" Element

   The role of value does not exist in the "data" element is to join an iCalendar document to an
   XML document forming a CAP command property or response.  The "data" element
   is composed of parameter value.

           (9) DATE-TIME and TIME values in a single attribute ("content") that MUST be set to WHEN clause.

               All DATE-TIME and TIME literal values supplied as in
               a
   "cid" URL WHEN clause MUST BE terminated with 'Z'. That means
               that refers to an iCalendar document.  See Section 3.2 for
   more information.

   Depending of the context, CUA MUST supply the content of values in UTC.

               Valid:

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

               Not valid:

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

               It is a syntax error and the referred iCalendar
   object CS MUST reject the QUERY.

4.2 CAP-QL notes

         (1) There is subject to restrictions.  See Section 6.2.1 for more
   details.

6.2.3.2 "select" Element

   Many calendaring commands can target several components stored no ORDERBY.  Sorting will take place in the order the
             columns are supplied in the command.

         Float and integer values MUST BE sorted by their numeric value.

         This means the result of a sort on an integer value type will be:

                   1, 2, 100, 1000

           and not

                   1, 100, 1000, 2

         This means the
   CS (e.g., "search", "delete", "modify" result of a sort on an float value type will be:

                   1.1, 2.23, 100.332, 1000.12

           and "move").  The "select"
   element is used to identify not

                   1.1, 100.332, 1000.12, 2.23

         Date and date time values will be sorted by their equivalent
         value in UTC. No matter what the targeted components.

   The "select" element returned time zone is composed of in the following:

      A "data" element
         result set. This is so that MUST refer to if multiple components are returned
         each in a VQUERY component.

      One or more "source" elements that identify unique time zone, the containers results will be sorted in UTC.
         This does not mean the values must be converted to
      consider.

   Restriction Table for UTC in the "data" element:

          Component/Property   Presence Comment
          -------------------  -------- ---------------------------
          VCALENDAR            1
          . VERSION            1        MUST be 2.1
          . [IANA-PROP]        0+
         data returned to the CUA. It means the CS must do the sort in UTC.

         All other values are sorted according to the locale sorting order
         as specified in the calendar. Or the CS locale if the calendar
         does not have any IANA registered
                                        property

          . VQUERY             1
          . . EXPAND           0 or 1
          . . QUERYNAME        0 locale set, or 1   MUST be present the host operating system
         locale if QUERY the CS does not specify a locale. And the locale to
         use for the sort is absent.
          . . QUERY            0 or 1 determined in that order.

         (2) The CS MUST be present if QUERYNAME sort at least the first column.
             The CS MAY sort additional columns.

         (3) If the cap-cols is absent.
          . . [IANA-PROP]      0+       any IANA registered
                                        property

          . VTIMEZONE          0+       MUST only "*" and nothing else, then:

             If EXPAND=FALSE sorting will be present if any
                                        date/time refers
                                        to a timezone
          . . DAYLIGHT         0+       MUST by the DTSTART value
             ascending.

             If EXPAND=TRUE sorting will be by the RECURRENCE-ID value
             ascending.

             If one or more of
                                        either STANDARD DTSTART or DAYLIGHT
          . . . . COMMENT      0 RECURRENCE-ID components have
             exactly the same value, the order for those matching
             components is unspecified.

         (4) All literal values are surrounded by single quotes ('), not
          double quotes ("), and not without any quotes. If the value
          contains quotes or 1
          . . . . DTSTART      1
          . . . . RDATE        0+       if present RRULE MUST NOT any other ESCAPED-CHAR, they must be present
          . . . . RRULE        0+       if present RDATE
          backslash escaped as described in section "4.3.11 Text"
          of RFC2445. Any LIKE wildcard characters that are part
          of any literal data that is preceded by a LIKE clause and
          is not intended to mean wildcard search, MUST NOT

                                        be present
          . . . . TZNAME       0 or 1
          . . . . TZOFFSET     1
          . . . . TZOFFSETFROM 1
          . . . . TZOFFSETTO   1
          . . . . X-PROPERTY   0+
          . . . . [IANA-PROP]  0+       any IANA registered
                                        property
          . . LAST-MODIFIED    0 or 1
          . . STANDARD         0+
          . . . . COMMENT      0 or 1
          . . . . DTSTART      1
          . . . . RDATE        0+       if present RRULE MUST NOT
                                        be present
          . . . . RRULE        0+       if present RDATE MUST NOT
                                        be present
          . . . . TZNAME       0 or 1
          . . . . TZOFFSETFROM 1
          . . . . TZOFFSETTO   1
          . . . . X-PROPERTY   0+
          . . . . [IANA-PROP]  0+       any IANA registered
                                        property
          . . TZID             1
          . . TZURL            0 or 1
          . . X-PROPERTY       0+
          . . [IANA-PROP]      0+       any IANA registered

6.2.3.3 "source" Element

   The "source" element is used to specify container(s) that will be
   examined during the execution of a CAP command.  The "source" element
   is similar to the "target" element (see Section 6.2.3.4, but can
   refer BE escaped as
          described in note (7) below.

         (5) When comparing DATE-TIME to several containers (e.g., a calendar hierarchy or all the
   calendar owned by a given CU).

   Attributes:

      csid: DATE value types and when specified MUST point
         comparing DATE to a CSID.  When omitted DATE-TIME value types, the CSID
      of result will
         be true if the current server is assumed.

      relcalid: when specified MUST point to a RELCALID.  The DATE value is
      relative on the same day as the DATE-TIME
         value of (both compared in UTC). And they MUST BE compared in UTC no
         matter what time zone the "csid" attribute.

      depth: specifies object had been tagged with when the maximal depth of
         object was stored in the calendar hierarchy to
      explore. CS.

               VALUE-1             VALUE-2            Compare Results

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

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

               20020304T003456Z    20020205T003456    FALSE
               (in UTC-0)          (in UTC-7)
         When omitted comparing DATE and DATE-TIME values with the LIKE
         clause the comparison will be done as if the value "0" is assumed.  The accepted
      values are positives integers and "*".

      owner: if present MUST be set to
         a UPN.  When specified only the
      VAGENDA owned by RFC2445 DATE or DATE-TIME string value (again in UTC).

             LIKE '2002%' will match anything in the given UPN are considered.

6.2.3.4 "target" Element

   The "target" element year 2002 (UTC).

             LIKE '200201%' will match anything in January 2002 (UTC).

             LIKE '%T000000' will match anything at midnight (UTC).

             LIKE '____01__T%' will match anything for any year or
                               time that is used to specify a container targeted by in January (UTC).
                               (Four '_', '01', two '_' 'T%').

         Again all comparisons will be done in UTC.

         Using a CAP
   command (e.g., the destination LIKE value of "%00%, would return any value that
         contained two consecutive zeros.

         (6) DTEND and DURATION.

         When a "create" command).  A "target"
   element MAY refer to VQUERY contains a VAGENGA or DTEND value, then the top level container of a
   Calendar Store.

   Attributes:

      csid: when specified CS MUST point to a CSID.  When omitted also
         evaluate any existing DURATION property value and determine
         if it has an effective end time that matches the CSID VQUERY
         supplied  DTEND value or any range of values supplied by
         the current server is assumed.

      relcalid: when specified MUST point to VQUERY.

         When a RELCALID.  The VQUERY contains a DURATION value, then the CS MUST
         also evaluate any existing DTEND property value is
      relative and determine
         if it has an effective duration that matches the VQUERY
         supplied DURATION value or any range of values supplied by
         the "csid" attribute.

6.2.4 Calendaring Commands

   Calendaring commands allow a CUA to directly manipulate VQUERY.

         As DTEND is the first time that is excluded from a calendar.

   Calendar access rights can be granted for components
         time range, any DURATION supplied by the more generalized access
   provided VQUERY that is
         exactly one second less than DTEND MUST match the VQUERY.
         And if the DURATION ends exactly at the computed DTEND it
         MUST NOT match.

         Any DTEND supplied by the calendar commands.

6.2.4.1 "create" Command

   Attributes:

      "id" (see Section 6.2.2.1).

   Elements:

      "max-time": See Section 3.3.

      "target":  Each "target" element points to VQUERY that is exactly one second
         more than an end time computed from a container where the
      new component will be created.

      "data": DURATION MUST point to an iCalendar object defining the
      component(s) to create.  See match the restriction table given below.

   Response:

      One "result" message per "target" element MUST be returned (see
      Section 3.1).

      One of
         VQUERY. Any end time that is computed from a DURATION that
         exactly matches the following "request-status" codes supplied DTEND MUST be returned:

         2.0 - successfully created the NOT match.

            (6.1) Given a meeting room reserved with a component or calendar

         6.1 - Container not found

         6.3 - Bad args
                  that contains:

                   DTSTART:20020127T000000Z
                   DTEND:20020127T010000Z

                   The "data" element of each "result" message reservation is subject to the
      result restriction table defined below. really from:

                           January 27th, 2002 00:00:00
                   To:

                           January 27th, 2002,00:59:59

            (6.2) Given another meeting room reserved with a component
                  that contains:

                   DTSTART:20020127T000000Z
                   DURATION:P59M59S

                   The "create" command reservation is used to create one really from:

                           January 27th, 2002 00:00:00
                    To:

                           January 27th, 2002,00:59:59

             (6.3) A VQUERY that contains:

                   ... VEVENT.DTSTART = '20020127T00000Z'
                   AND VEVENT.DTEND = '20020127T010000Z'

                   MUST match both (6.1) and (6.2).

             (6.4) A VQUERY that contains:

                   ... VEVENT.DTSTART = '20020127T00000Z'
                   AND DURATION = 'P59M59S'

                   MUST match both (6.1) and (6.2).

         (7) [NOT] LIKE notes:

            The pattern matching characters is the '%' that matches
            zero or more iCalendar objects.
   The "target" elements specify characters, and '_' that matches exactly one
            character (where character does not always mean octet).

            LIKE pattern matches always cover the containers where entire string. To match
            a pattern anywhere within a string, the component(s)
   will 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 created.

   Restriction table backslash escaped as
            done in [RFC2445]. That is to search for a '%' or '_' in
            the "data" element of string:

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

            Strings compared using the "create" command:

       Component/Property     Presence Comment
       -------------------    -------- -----------------------------
       VCALENDAR              1
       . VERSION              1 LIKE clause MUST be 2.1
       . [IANA-PROP]          0+       any IANA registered
                                       property

       . VAGENDA              0+
       . . CALMASTER          0 or 1
       . . NAME               0 or 1
       . . OWNER              1+
       . . RELCALID           1
       . . TZID               0 or 1
       . . [IANA-PROP]        0+ BE performed
            using case in-sensitive comparisons. ('a' = 'A').

            The CS must understand the objects being compared and
            understand how to determine how any IANA registered multi valued property

       . VCAR                 0+
       . . CARID              0
            or 1
       . . DENY               0+       Note, there must be at
                                       least one GRANT parameter values are separated, quoted, and backslash
            escaped and perform the comparisons as if each value existed
            by itself and not quoted or DENY
                                       within backslash escaped when comparing
            using the VCAR.
       . . GRANT              0+       Note, LIKE element.

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

         (8) [NOT] "CONTAINS(" cap-lhs "," col-literal ")"

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

                 property:value1,value2

                 CONTAINS(property, 'value1')   would match
                 CONTAINS(property, 'value')    would NOT match

                 LIKE(property, 'value%')       would match

             The CS must be at
                                       least one GRANT or DENY
                                       within understand the VCAR.
       . . [IANA-PROP]        0+       any IANA registered
                                       property

       . VQUERY               0+
       . . EXPAND             0 or 1
       . . QUERYNAME          1
       . . QUERY              1
       . . [IANA-PROP]        0+ objects being compared and
             understand how to determine how any IANA registered multi valued property

       . VEVENT               0+
       . . ATTENDEE           0+
       . . SEQUENCE           0
             or 1   MUST be present parameter values are separated, quoted, and backslash
             escaped and perform the comparisons as if each value is
                                       greater than 0,
                                       MAY be present if 0
       . . SUMMARY            1        Can be null
       . . UID                1

       . . ATTACH             0+
       . . CATEGORIES         0 or 1
       . . CLASS              0 existed
             by itself and not quoted or 1
       . . COMMENT            0 or 1
       . . CONTACT            0+
       . . CREATED            0 or 1
       . . DESCRIPTION        0 or 1   Can be null
       . . DTEND              0 backslash escaped when comparing
             using the CONTAINS() element.

             If CONTAINS() is preceded by 'NOT' then there is a match when
             the value does not exist in the property or 1   if present DURATION parameter value.

           (9) DATE-TIME and TIME values in a WHEN clause.

               All DATE-TIME and TIME literal values supplied as in
               a WHEN clause MUST
                                       NOT be present
       . . DTSTAMP            1
       . . DTSTART            1
       . . DURATION           0 or 1   if present DTEND BE terminated with 'Z'. That means
               that the CUA MUST NOT
                                       be present
       . . EXDATE             0+
       . . EXRULE             0+
       . . GEO                0 or 1
       . . LAST-MODIFIED      0 or 1
       . . LOCATION           0 or 1
       . . ORGANIZER          1
       . . PRIORITY           0 or 1
       . . RDATE              0+
       . . RECURRENCE-ID      0 supply the values in UTC.

               Valid:

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

               Not valid:

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

               It is a syntax error and the CS MUST reject the VQUERY.

4.3 Example, Query by UID

      The following example would match the entire content of the VEVENT
      or 1   only if referring VTODO with the UID property equal to an
                                       instance "uid123" and not expand
      any multiple instances of a recurring
                                       calendar the component.
                                       Otherwise it  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 NOT be
                                       present.
       . . RELATED-TO         0+
       . . REQUEST-STATUS     0+
       . . RESOURCES          0 or 1   This property MAY contain supplied in a
      QUERY property.  This example assumes the CUA only supports VTODO and
      VEVENT.

      If the results were empty it could also mean that "uid123" was a
                                       list of values
       . . RRULE              0+
       . . STATUS             0 or 1
       . . TRANSP             0 or 1
       . . URL                0 or 1
       . . X-PROPERTY         0+
       . . [IANA-PROP]        0+       any IANA registered
                                       property

       . . VALARM             0+
       . . . ACTION           1
       . . . ALARMID          1
       . . . ATTACH           0+
       . . . DESCRIPTION      0 or 1
       . . . DURATION         0 or 1  if present REPEAT MUST be
                                      present
       . . . REPEAT           0 or 1  if present DURATION MUST be
                                      present
       . . . SUMMARY          0 or 1
       . . . TRIGGER          1
       . . . X-PROPERTY       0+
       . . . [IANA-PROP]      0+      any IANA registered
      property

       . in a component other than a VTODO                0+
       . . ATTENDEE           0+
       . . SEQUENCE           0 or 1  MUST be present if value is
                                      greater than 0, MAY be
                                      present if 0
       . . SUMMARY            1       Can be null.
       . . VEVENT.

      BEGIN:VQUERY
      QUERY:SELECT * FROM VTODO WHERE UID                1

       . . ATTACH             0+
       . . CATEGORIES         0 or 1 = 'uid123'
      QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123'
      END:VQUERY

4.4 Query by Date-Time range

   This property may contain a
                                      list query selects the entire content of values
       . . CLASS              0 or 1
       . . COMMENT            0 or 1
       . . CONTACT            0+
       . . CREATED            0 every booked VEVENT that has
   an instance greater than or 1
       . . DESCRIPTION        0 equal to July 1st, 2000 00:00:00 UTC and
   less than or 1  Can be null
       . . DTSTAMP            1
       . . DTSTART            1
       . . DUE                0 or 1  If present DURATION MUST NOT
                                      be present
       . . DURATION           0 or 1  If present DUE MUST NOT be
                                      present
       . . EXDATE             0+
       . . EXRULE             0+
       . . GEO                0 or 1
       . . LAST-MODIFIED      0 or 1
       . . LOCATION           0 or 1
       . . ORGANIZER          1
       . . PRIORITY           1
       . . PERCENT-COMPLETE   0 or 1
       . . RDATE              0+
       . . RECURRENCE-ID      0 or 1  MUST only if referring equal to an
                                      instance of a recurring
                                      calendar component.
                                      Otherwise it MUST NOT be
                                      present.
       . . RELATED-TO         0+
       . . REQUEST-STATUS     0
       . . RESOURCES          0 or 1  This property may contain a
                                      list July 31st, 2000 23:59:59 UTC

   BEGIN:VQUERY
   EXPAND:TRUE
   QUERY:SELECT * FROM VEVENT
    WHERE RECURRENCE-ID >= '20000801T000000Z'
    AND RECURRENCE-ID <= '20000831T235959Z'
    AND METHOD = 'CREATE'
   END:VQUERY

4.5 Query for all Non-Booked Entries

      The following example selects the entire contents of values
       . . RRULE              0+
       . . STATUS             0 or 1  MAY be all [ITIP]
      non-booked VTODOs and VEVENTs with their METHOD set to one of COMPLETED,
                                      NEEDS-ACTION,
                                      IN-PROCESS, CANCELLED
       . . URL                0 or 1

       . . X-PROPERTY         0+
       . . [IANA-PROP]        0+      any IANA registered property

       . . VALARM             0+
       . . . ACTION           1
       . . . ALARMID          1
       . . . ATTACH           0+
       . . . DESCRIPTION      0 or 1
       . . . DURATION         0 or 1  if present REPEAT MUST be
                                      present
       . . . REPEAT           0 or 1  if present DURATION MUST
      the [ITIP] METHODs. The default for EXPAND is FALSE, so the
      recurrence rules will not be
                                    present
       . . . SUMMARY          0 or 1
       . . . TRIGGER          1
       . . . X-PROPERTY       0+
       . . . [IANA-PROP]      0+      any IANA registered expanded.

      BEGIN:VQUERY
      QUERYID:Fetch VEVENT and VTODO iTIP components
      NAME;LANG=fr_ca: ...todo...
      QUERY:SELECT * FROM VEVENT WHERE
       METHOD = 'REQUEST' OR METHOD = 'ADD' OR METHOD = 'PUBLISH' OR
       METHOD = 'CANCEL' OR METHOD = 'REPLY' OR METHOD = 'COUNTER' OR
       METHOD = 'REFRESH' OR METHOD = 'DECLINECOUNTER'
      QUERY:SELECT * FROM VTODO WHERE
       METHOD = 'REQUEST' OR METHOD = 'ADD' OR METHOD = 'PUBLISH' OR
       METHOD = 'CANCEL' OR METHOD = 'REPLY' OR METHOD = 'COUNTER' OR
       METHOD = 'REFRESH' OR METHOD = 'DECLINECOUNTER'
      END:VQUERY

      In the above exampe, the QUERY property

       . VJOURNAL             0+
       . . ATTENDEE           0
       . . DESCRIPTION        1    Can be null.
       . . DTSTAMP            1
       . . DTSTART            1
       . . ORGANIZER          1
       . . could have been written as:

      QUERY:SELECT * FROM VEVENT WHERE METHOD != 'CREATE'
       AND METHOD != 'DELETE'

      The following example fetches all VEVENT and VTODO booked entries
      from the CS.

      BEGIN:VQUERY
      QUERYID:Fetch All Booked VEVENT and VTODO components
      QUERY:SELECT * FROM VEVENT WHERE METHOD = 'CREATE'
      QUERY:SELECT * FROM VTODO WHERE METHOD = 'CREATE'
      END:VQUERY

      The following fetches the UID                1

       . . ATTACH             0+
       . . CATEGORIES         0 or 1 This for all VEVENT and VTODO components
      that have been marked for delete (METHOD:DELETE).

      BEGIN:VQUERY
      QUERYID:Fetch UIDs of marked for delete VEVENTs and VTODOs
      QUERY:SELECT UID FROM VEVENT WHERE METHOD = 'DELETE'
      QUERY:SELECT UID FROM VTODO WHERE METHOD = 'DELETE'
      END:VQUERY

      In the examples above they were bunched into groups of similar
      queries. They could be performed all at once by having all of
      the QUERY property MAY contain a list in one BEGIN/END VQUERY component.

4.6 Query with Subset of values
       . . CLASS              0 or 1
       . . COMMENT            0 or 1
       . . CONTACT            0+
       . . CREATED            0 or 1
       . . EXDATE             0+
       . . EXRULE             0+
       . . LAST-MODIFIED      0 or 1
       . . RDATE              0+
       . . RECURRENCE-ID      0 or 1   MUST Properties by Date/Time

   In this example only if referring to
                                       an instance of a recurring
                                       calendar component.
                                       Otherwise it MUST NOT be
                                       present.
       . . RELATED-TO         0+
       . . REQUEST-STATUS     0+
       . . RRULE              0+
       . . SEQUENCE           0 or 1   MUST be present if
                                       non-zero. MAY be
                                       present if zero.
       . . STATUS             0 or 1
       . . SUMMARY            0 or 1   Can the named properties will be null
       . . URL                0 or 1
       . . X-PROPERTY         0+
       . . [IANA-PROP]        0+       any IANA registered
                                       property
       . VFREEBUSY            0

       . VTIMEZONE            0+     MUST selected and all
   booked and non-booked components will be present if any
                                     date/time refers to selected that have a
                                     timezone
       . . DAYLIGHT           0+     MUST be one or more of
                                     either STANDARD or
                                     DAYLIGHT
       . . . . COMMENT        0 or 1
       . . . . DTSTART        1
       . . . . RDATE          0+       if present RRULE MUST NOT
                                       be present
       . . . . RRULE          0+       if present RDATE MUST NOT
                                       be present
       . . . . TZNAME         0 or 1
       . . . . TZOFFSET       1
       . . . . TZOFFSETFROM   1
       . . . . TZOFFSETTO     1
       . . . . X-PROPERTY     0+
       . . . . [IANA-PROP]    0+       any IANA registered
                                     property
       . . LAST-MODIFIED      0 or 1
       . . STANDARD           0+
       . . . . COMMENT        0 or 1
       . . . .
   from February 1st to February 10th 2000.

   BEGIN:VQUERY
   QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT
    WHERE DTSTART        1
       . . . . RDATE          0+       if present RRULE MUST NOT
                                       be present
       . . . . RRULE          0+       if present RDATE MUST NOT
                                       be present
       . . . . TZNAME         0 or 1
       . . . . TZOFFSETFROM   1
       . . . . TZOFFSETTO     1
       . . . . X-PROPERTY     0+
       . . . . [IANA-PROP]    0+       any IANA registered property
       . . TZID               1
       . . TZURL              0 or 1
       . . X-PROPERTY         0+
       . . [IANA-PROP]        0+       any IANA registered property

   Restriction Table for >= '20000201T000000Z'
    AND DTSTART <= '20000210T235959Z'
   END:VQUERY

4.7 Components With Alarms In A Range

      This example fetches all VEVENTs with an alarm that triggers
      within the "data" element of specified time range.  In this case only the "result" response:

       Component/Property  Presence Comment
       ------------------- -------- -------------------------------

       VCALENDAR              1+
       . VERSION              1        MUST UID, SUMMARY,
      and DESCRIPTION will be 2.1

       . VAGENDA              0+
       . . RELCALID           1
       . . REQUEST-STATUS     1+

       . VCAR                 0+
       . . CARID              1
       . . REQUEST-STATUS     1+

       . selected for all booked VEVENTS that have an
      alarm between the two date-times.

      BEGIN:VQUERY
      EXPAND:TRUE
      QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT               0+
       . . UID                1
        USING_COMPONENT VALARM my-alarm
        WHERE my-alarm.TRIGGER >= '20000101T030405Z'
        AND my-alarm.TRIGGER <= '20001231T235959Z'
        AND METHOD = 'CREATE'
      END:VQUERY

5. Access Rights

   Access rights within CAP are specified with the "VCAR" calendar
   component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID"
   component properties.

5.1 Access Control and NOCONFLICT

   The UID for which this
                                       REQUEST-STATUS applies
       . . REQUEST-STATUS     1+
       . . RECURRENCE-ID      0 TRANSP property can take on values (TRANSPARENT-NOCONFLICT,
   OPAQUE-NOCONFLICT) that prohibit other events from overlapping it.
   This setting overrides access.  The ALLOW-CONFLICT Calendar or 1   MUST be specified only if instance of
                                       a recurring
   component was created.
       . . VALARM             0        if VEVENT was successfully
                                       saved
                              1+       if there were errors saving
                                       alarms
       . . . ALARMID          1
       . . . REQUEST-STATUS   1+

       . VFREEBUSY            0

       . VJOURNAL             0+
       . . UID                1        The UID for which setting may also prevent overlap, returning an error code
   "6.3"

6. Commands and Responses

   CAP commands and responses are described in this
                                       REQUEST-STATUS applies
       . . RECURRENCE-ID      0 or 1   MUST be specified only if instance of
                                       a recurring component was created.
       . . REQUEST-STATUS     1+

       . VQUERY               0+
       . . REQUEST-STATUS     1+

       . VTODO                0+
       . . UID                1 section.

   As mentioned in Section 3.2, CAP commands are defined by MIME
   objects.

   The UID for which this
                                       REQUEST-STATUS applies
       . . RECURRENCE-ID      0 or 1   MUST be specified only if instance attributes of a recurring component was created.
       . . REQUEST-STATUS     1+
       . . VALARM             0        if VTODO was successfully
                                       saved
                              1+       if there were errors saving
                                       alarms
       . . . ALARMID          1
       . . . REQUEST-STATUS   1+

   Example:

   In the following example, two new top level VAGENDAs command are created.

   Note described in the "Attributes:"
   section in the command descriptions below.  Similarly the "Elements:"
   section describes the elements that compose the CSID of command.  The
   "Response:" section, identifies the responses that may be returned by
   the server.

   In the examples below, lines preceded with "S:" refer to the server
   and lines preceded with "C:" refer to the client.  Lines in which the
   first non-whitespace character is cal.example.com.

   C: MSG 1 8 . 3843 778
   C: Content-Type: multipart/related; boundary="boundary-foo321";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-foo321
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <create id="creation01">
   C:   <target csid="cal.example.com"/>
   C:   <data content="cid:2@cal.example.com"/>
   C: </create> a "#" are editorial comments and
   are not part of the protocol.

6.1 Session Commands

6.1.1 "generate-uid" Command

      Attributes:

              num: Number of UIDs to generate (1 if omitted).

            cmdid: A unique id that identifies this command to
                   the CUA and CS.

          latency: How long before CS asks you to continue. (optional)

           action: How to handle latencty - MUST BE suppled but
                   only when the 'latency' command is supplied.

      Response:

            "uid-list"

      The "generate-uid" command returns one or more unique identifiers
      which MUST BE globaly unique.

      Example:

      C: --boundary-foo321 MSG 1 5 . 2837 60
      C: Content-Type: text/calendar
   C: Content-ID: 2@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: BEGIN:VAGENDA
   C: RELCALID:relcalz1
   C: NAME;LANGUAGE=EN-us:Bill's Soccer Team
   C: OWNER:bill
   C: CALMASTER:mailto:bill@example.com
   C: TZID:US_PST
   C: END:VAGENDA
   C: BEGIN:VAGENDA application/cap+xml
      C: RELCALID:relcalz2
   C: NAME;LANGUAGE=EN-us:Mary's personal calendar
   C: OWNER:mary
   C: CALMASTER:mailto:mary@example.com
   C: TZID:US_PST
   C: END:VAGENDA
      C: END:VCALENDAR
   C: --boundary-foo321-- <generateuid num=5/>
      C: END
      S: RPY 1 8 5 . 4621 647
   S: Content-Type: multipart/related; boundary="boundary-bar321";
   S:    start="1@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-bar321 2897 328
      S: Content-Type: application/beep+xml
   S: Content-ID: 1@cal.example.com
   S:
   S: <result id="creation01">
   S:    <target csid="cal-example.com"/>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-bar321
   S: Content-Type:text/calendar; application/cap+xml
      S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VAGENDA
      S: RELCALID:relcalz1
   S: REQUEST-STATUS:2.0
   S: END:VAGENDA <uid-list>
      S: BEGIN:VAGENDA   <uid>20011121T120000Z-12340@cal.example.com</uid>
      S: RELCALID:relcalz2   <uid>20011121T120000Z-12341@cal.example.com</uid>
      S: REQUEST-STATUS:2.0   <uid>20011121T120000Z-12342@cal.example.com</uid>
      S: END:VAGENDA   <uid>20011121T120000Z-12343@cal.example.com</uid>
      S: END:VCALENDAR   <uid>20011121T120000Z-12344@cal.example.com</uid>
      S: --boundary-bar321-- </uid-list>
      S: END

   Example to create a new component

6.1.2 "get-capability" Command

      Attributes:

            None

      Elements:

            None

      Response:

            "capability"

      The "get-capability" command returns information about the Calendar
      Server given the current state of the connection with the client.
      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 multiple containers.

   C: MSG 1 9 . 5268 622
   C: Content-Type: multipart/related; boundary="boundary-kshgd";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-kshgd
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <create id="creation02">
   C:   <target relcalid="relcalz1"/>
   C:   <target relcalid="relcalz2"/>
   C:   <data content="cid:2@cal.example.com"/>
   C: </create>
   C: --boundary-kshgd
   C: Content-Type: text/calendar
   C: Content-ID: 2@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: BEGIN:VEVENT
   C: DTSTART:99990307T180000Z
   C: UID:abcd12345
   C: DTEND:99990307T190000Z
   C: SUMMARY:Important Meeting
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-kshgd--
   C: END
   S: ANS 1 9 . 58901 563 0
   S: Content-Type: multipart/related; boundary="boundary-eqrga";
   S:    start="1@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-eqrga
   S: Content-Type: application/beep+xml
   S: Content-ID: 1@cal.example.com
   S:
   S: <result id="creation02">
   S:    <target relcalid="relcalz1"/>
   S:    <request-status code="2.0"/>
   S:    <data content="2@cal.example.com"/>
   S: </result>
   S: --boundary-eqrga
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VEVENT
   S: UID:abcd12345
   S: REQUEST-STATUS:2.9
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-eqrga--
   S: END
   S: ANS 1 9 . 6453 563 1
   S: Content-Type: multipart/related; boundary="boundary-982hf";
   S:    start="1@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-982hf
   S: Content-Type: application/beep+xml
   S: Content-ID: 1@cal.example.com
   S:
   S: <result id="creation02">
   S:    <target relcalid="relcalz2"/>
   S:    <request-status code="2.0"/>
   S:    <data content="2@cal.example.com"/>
   S: </result>
   S: --boundary-982hf
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VEVENT
   S: UID:abcd12345
   S: REQUEST-STATUS:6.0
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-982hf--
   S: END
   S: NUL 1 9 . 7016 0
   S: END

   As described in Section 3.1, the CS sends one response per "target"
   element present in the "create" command.

6.2.4.2 "delete" Command

   Attributes:

      "id" (see Section 6.2.2.1).

   Elements:

      "max-time": See Section 3.3.

      "select": specifies this specification, and MAY ignore any non-
      standard, experimental capability elements.  Non-standard
      experimental capability elements MUST be prefixed with the compoments to delete (see Section
      6.2.3.2).

   Response:

      One "result" message per "source" in text "x-".
      The prefix SHOULD also include a vendor identifier.  For example, "x-
      foo-barcapability", for the "select" element (see
      Section 3.1).

      One non-standard "barcapability" capability
      of the following "request-status" codes MUST be returned:

         2.0 - successfully created vendor "foo".  It may return different results depending on
      the component or calendar

         6.1 - UPN.

          Capability   Occurs     Description
          -------------------------------------------------------
          cap            1          Container not found

         6.3 - Bad args for CAP related elements.

          cap-version    1+         Version of CAP. MUST include at
                                    least "1.0" for this version of
                                    CAP.

            prodid       0 or 1     The "data" element product id of each "result" message the CS.

            query-level  1+         Indicates level of SQL support.
                                    CAP-QL or NONE. (NONE is subject for
                                    CS's that allow ITIP methods
                                    only to be deposited and nothing
                                    else). If set to NONE, then the
      result restriction table define below.

   The "delete" command
                                    'car' capability MUST BE set to NONE.

            car          1+         Indicates level of CAR support.
                                    CAR-NONE, CAR-MIN or CAR-FULL-1.
                                    If CAR-FUL-1 is supplied then
                                    CAR-MIN MUST BE supplied. CAR = NONE
                                    MUST BE used to delete a calendar when query-level of
                                    NONE is supplied. If

            date-max     0 or component. 1     The
   "select" element specifies datetime value in UTC beyond
                                    which the container(s) server cannot accept. If
                                    not specified the default is
                                    99991231T235959Z.

            date-min     0 or 1     The datetime value prior to delete.

   Restriction Table for which
                                    the "data" element of server cannot accept. If not
                                    specified the "result" response(s).

       Component/Property    Presence Comment
       -------------------   -------- -----------------------------

       VCALENDAR             1+

       . VERSION             1        MUST be 2.1

       . VAGENDA                      Only if VAGENDAS were
                                      deleted
       . RELCALID            1
       . REQUEST-STATUS      1

       . VCAR                0+       Only if VCAR components were
                                      deleted
       . . CARID             1
       . . REQUEST-STATUS    1

       . VEVENT              0+       Only if VEVENT components
                                      were deleted
       . . UID               1
       . . REQUEST-STATUS default is
                                    00000101T000000Z.

            max-component-size
                         0 or 1   Omitted if an embedded VALARM was     A positive integer value that specifies
                                    the target size of the deletion.
       . . VALARM             0+      Only if VALARM components
                                      were deleted
       . . . ALARMID          1
       . . . REQUEST-STATUS   1

       . VFREEBUSY           0
       . . UID               1
       . . DTSTAMP           1
       . . REQUEST-STATUS    1

       . VJOURNAL            0+       Only if VJOURNAL largest iCalendar
                                    object that the server will accept in
                                    octets. Objects larger than this will be
                                    rejected. The absence of this attribute
                                    indicates no limit. This is also the
                                    maximum value of any BEEP payload
                                    the CS will accept or send.

          components
                                    were deleted
       . . UID               1
       . . REQUEST-STATUS      1

       . VQUERY              0+       Only if VQUERY         A comma seperated list of the names of
                                    components
                                      were deleted
       . UID                 1
       . REQUEST-STATUS      1

       . VTIMEZONE           0+       Only if VTIMEZONE that this CS supports. This
                                    includes any components
       . . TZID                       were deleted
       . . REQUEST-STATUS    1
       . VTODO               0+       Only if VTODO inside of
                                    other components were
                                      deleted
       . . UID (VALARM and VEVENT
                                    for example). MUST include at least
                                    VCALSTORE, VCALENDAR, and VAGENDA
                                    and at least one of VEVENT, VTODO,
                                    or VJORNAL.

            version      1+         Version of iCalendar support.
                                    MUST BE at least "2.0".
                                    supported.

          itip-version      1+      Version(s) of ITIP, MUST include at
                                    least "1.0".

         recur-accepted  0 or 1
       . . REQUEST-STATUS     whether the CS accepts recurrence rules
         recur-expand    0 or 1   Omitted if an embedded VALARM was     whether or not the target CS supports the
                                    expansion of recurrence rules.
         recur-limit     0 or 1     the deletion.

       . . VALARM            0+       Only if VALARM components
                                      were deleted
       . . . ALARMID maximum number of occurrences or a recurrence
                                    rule that are expanded by the CS

      Example:

      C: MSG 1 6 . . . REQUEST-STATUS 3225 57
      C: Content-Type: application/beep+xml
      C:
      C: <get-capability/>
      C: END
      S: RPY 1

       ----------------------------------------------------------

   [EDITORS NOTE: Issues:

      - Can one use DELETE to remove all VALARMs and VTIMEZONEs that
      match a certain search criteria and that belong 6 . 3282 423
      S: Content-Type: application/beep+xml
      S:
      S:
      S: <capability>
      S:  <version>2.0</version>
      S:  <max-component-size>65536</max-component-size>
      S:  <itip-version>1.0</itip-version>
      S:  <cap-version>1.0</cap-version>
      S:  <car>CAR-FULL-1</car><car>CAR-MIN</car.
      S:  <query-level>CAP-QL</query-level>
      S:  <date-min>00000101T000000Z</date-min>
      S:  <date-max>99991231T235959Z</date-max>
      S:  <components>
      S:   VCALSTORE,VAGENDA,VCALENDAR,VEVENT,X-my-vcomp,VALARM
      S:  </components>
      S: </capability>
      S: END

6.1.3 "identify" Command

      Attribute:

            upn: The UPN of the new identify to all components,
      event though VALARMs and VTIMEZONEs never exist as independent
      components? Or should assume.

      Element:

            None

      Response:

            "result" with one use MODIFY? If they can be deleted, do
      we return the REQUEST-STATUS of their deletion in a VEVENT or
      separately?

   Example the following request-status codes:

                  2.0 Successful.

                  6.4 Identity not permitted.

      The "identify" command allows the CUA to delete set a VEVENT with UID 'abcd12345' from any new identity to be
      used for calendar access.

      The CS determines through an internal mechanism if the credentials
      supplied at authentication permit the assumption of the
   calendar owned by selected
      identity.  If they do, the CU with session assumes the UPN="user@cal.example.com": new identity,
      otherwise a security error is returned.

      If
      Example:

      C: MSG 1 10 7 . 7016 558 3705 47
      C: Content-Type: multipart/related; boundary="boundary-gsdmx3";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml" application/cap+xml
      C:
      C: --boundary-gsdmx3 <identify upn="my-alter-ego"/>
      C: END

      S: RPY 1 7 . 3752 91
      S: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <delete id="delete01">
   C:    <select>
   C:       <source depth=* owner="user@cal.example.com"/>
   C:       <data content="cid:2@cal.example.com"/>
   C:    </select>
   C: </delete> application/cap+xml
      S:
      S: <request-status code="2.0"/>
      S: END

6.1.4 "noop" Command

      Arguments:

            None

      Element:

            None

      Response:

                  2.0 successful

      This command does nothing.  It can be sent to the server periodically
      to request that the CS does not time out the session.

      Example:

      C: --boundary-gsdmx3 MSG 1 7 . 3705 47
      C: Content-Type: text/calendar
   C: Content-ID: 2@cal.example.com
   C:
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' application/cap+xml
      C: END:VQUERY
      C: --boundary-gsdmx3-- <noop/>
      C: END
      S: RPY 1 10 7 . 7574 587 3752 91
      S: Content-Type: multipart/related; boundary="boundary-oifc3j";
   S:    start="1@cal.example.com"; application/cap+xml
      S:    type="application/beep+xml"
   S:
   S: --boundary-oifc3j
   S: Content-Type: application/beep+xml
   S: Content-ID: 1@cal.example.com
   S:
   S: <result id="delete01">
   S:    <source depth=* owner="user@cal.example.com"/>
   S:    <data content="cid:2@cal.example.com"/>
      S: <request-status code="2.0"/>
      S: </result>
   S: --boundary-oifc3j
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VEVENT
   S: UID:abcd12345
   S: REQUEST-STATUS: 2.0
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-oifc3j--
   S: END

6.2.4.3 "modify" Command

   Attributes:

      "id" (see Section 6.2.2.1).

   Elements:

      "max-time": See Section 3.3.

      "select": identifies the component(s) to modify.

      "add": adds properties to the selected component(s).

      "remove": removes properties from

6.2 Calendaring and Scheduling Commands

6.2.1 Restriction Tables

   Calendaring data is sent encapsulated in iCalendar objects The
   restriction tables listed in the selected component(s).

      "update": updates commands below describe the content
   composition of the selected component(s).

   Response:

      One "result" message per "source" in iCalendar data for these commands and replies.

   The presence column uses the "select" following values to assert whether a
   property is returned (see
      Section 3.1).

      One required, is optional and the number of times it may
   appear in the following "request-status" codes MUST iCalendar object.  A comment may be returned:

         2.0 - successfully created provided to further
   clarify the component or calendar

         6.1 - Container not found

         6.3 - Bad args presence criteria.

   The "data" element table below defines the values for the presence column.

   Presence
   Value       Description
   --------------------------------------------------------------
   1           One instance MUST be present
   1+          At least one instance MUST be present
   0           Instances of each "result" message is subject this property MUST NOT be present
   0+          Multiple instances MAY be present
   0 or 1      Up to 1 instance of this property MAY be present
   --------------------------------------------------------------

   While the
      restriction table defined below.

   The "modify" command tables list every component and property, their purpose is used
   not to modify existing components.  The
   "select" element specifies define the components to modify.  The "add",
   "remove" and "update" elements define meaning of the operations to perform.

   The "add" element is used to add properties component or nested components property.

6.2.2 Calendaring Commands

   Calendaring commands allow a CUA to directly manipulate a calendar.

   Calendar access rights can be granted for the selected components.  The "add" element is composed more generalized access
   provided by the calendar commands.

   There are two kinds of a "data"
   element replies.  Those that contains a component with the properties to add.  For
   example to add contain an inline attachment to a VEVENT iCalendar
   object, and those that do not contain an iCalendar object.

   Any reply from the following CS that contains an iCalendar object could be:

           BEGIN:VCALENDAR
           BEGIN:VEVENT
           ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
            MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
            EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
              <...remainder of "BASE64" encoded binary data...>
           END:VEVENT
           END:VCALENDAR

   The "remove" element is used to remove properties wrappend
   in a <reply> and </reply> tags.

   Any reply from the selected
   components.  The "data" element contains CS that does not contain an iCalendar with the
   properties to delete.  When the "ignore-value" attribute object is set to
   true, all the properties specified
   returned in the "data" element are removed
   even a <request-status code="x.y"/&gt tag.  And if the values do not match the current state this reply
   includes any cap command replies.  Then they are returned wrapped
   between <request-status code="x.y"&gt and </request-status
   code="x.y"&gt tags.

6.2.2.1 "create" Command

      Attributes:

            "latency" with "action" (optional)

      Response:

            One "result" iCalendar object per "target" element MUST be
            returned (see Section 3.1)

            One of the component.
   This is useful to remove potentially large properties efficiently
   (e.g., "ATTACH"). following "request-status" codes MUST be returned:

                  2.0 - successfully created the component or calendar

                  6.1 - Target not found

                  6.3 - Bad args

      The "update" element "create" command is used to update create one or add more iCalendar objects.

      The TARGET property specify the properties referred
   to by containers where the "data" element.  If component(s)
      will be created.

      The CDATA portion of the "remove-missing" attribute is set
   to true, then all the elements not present in the "data" element
   document will command can be removed from the selected components.

   When more than one operations is specified, the modifications MUST
   must respect any valid [ITIP] object
      or any iCalendar object using the following order: "remove" followed by "update"
   followed by "add".  The modifications restriction table.
      There MUST only be applied if the
   resulting BE at least one component respects the restriction table inside of the "create"
   command. VCALENDAR
      object.

      Restriction Table table for "data" element of the "result" response: "create" command:

          Component/Property     Presence Comment
          -------------------    -------- ------------------------------- -----------------------------
          VCALENDAR              1+              1
          . VERSION              1        MUST be 2.1 BE at least 2.0
          . VAGENDA              0+ TARGET               1+
          . METHOD               1        MUST BE the METHOD of the newly
                                          created components.
          . RELCALID CMDID                0 or 1
          . [IANA-PROP]          0+       any IANA registered
                                          property

          . REQUEST-STATUS     1+ VAGENDA              0+
          . VCAR VAGENDA              0+
          . . CARID ALLOW-CONFLICT     0 or 1
          . . REQUEST-STATUS     1+

       . VEVENT               0+
       . . UID CALMASTER          0 or 1
          . . RECURRENCE-ID CALSCALE           0 or 1   MUST be specified only if instance of
                                       a recurring component was modified.
          . . REQUEST-STATUS     1+ CREATED            0 or 1
          . . VALARM DEFAULT-CHARSET    0        if VEVENT was successfully
                                       saved
                              1+       if there were errors saving
                                       alarms or 1
          . . DEFAULT-LOCALE     0 or 1
          . REQUEST-STATUS   1+ . VFREEBUSY DEFAULT-TZID       0

       . VJOURNAL             0+ or 1
          . . UID LAST-MODIFIED      0 or 1
          . . RECURRENCE-ID METHOD             0 or 1   MUST be specified   The only if instance of
                                       a recurring component was modified.
       . valid values are
                                          "CREATE" or "DELETE."
          . REQUEST-STATUS     1+ . VQUERY NAME               0+
          . . REQUEST-STATUS OWNER              1+
          . VTODO . RELATED-TO         0+
          . . UID RELCALID           1
          . . RECURRENCE-ID TZID               0 or 1   MUST be specified only if instance of
                                       a recurring component was modified.
          . . REQUEST-STATUS     1+ X-PROPERTY         0+
          . . VALARM             0        if VTODO was successfully
                                       saved
                              1+       if there were errors saving
                                       alarms [IANA-PROP]        0+       any IANA registered
                                          property
          . . X-COMPONENT        0+

          . REQUEST-STATUS   1+

   In the example below, the start and end time of the event with UID
   abcd12345 is changed VCAR                 0+
          . . . CARID            1
          . . . NAME             0+       Note, there MUST NOT be
                                          more than one NAME with
                                          no LANGUAGE parameter,
                                          and there MUST NOT be
                                          more than one NAME with
                                          the LOCATION same LANGUAGE value.
          . . . DECREED          0        This property is removed.

   C: MSG 1 11 outside
                                          the scope of the protocol.
          . 8161 1144
   C: Content-Type: multipart/related; boundary="boundary-324dav";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-324dav
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.cal.example.com
   C:
   C: <modify id="modify01"/>
   C:    <select>
   C:       <source owner="user@cal.example.com" depth=*/>
   C:       <data content="cid:query@cal.example.com"/>
   C:    </select>
   C:    <remove ignore-value=true>
   C:       <data content="remove@cal.example.com"/>
   C:    </remove>
   C:    <update remove-missing=false>
   C:       <data content="cid:update@cal.example.com"/>
   C:    </update>
   C: </modify>
   C: --boundary-324dav
   C: Content-Type: text/calendar
   C: Content-ID: query@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VQUERY
   C: QUERY: SELECT * FROM VEVENT WHERE UID='abcd12345'
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-324dav
   C: Content-Type: text/calendar
   C: Content-ID: remove@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VEVENT
   C: LOCATION:

   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-324dav
   C: Content-Type: text/calendar
   C: Content-ID: update@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VEVENT
   C: DTSTART:19990421T160000Z
   C: DTEND:19990421T163000Z
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-324dav--
   C: END
   S: RPY 1 11 . 9305 570
   S: Content-Type: multipart/related; boundary="boundary-tvx2";
   S:    start="command@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-tvx2
   S: Content-Type: application/beep+xml
   S: Content-ID: command@cal.example.com
   S:
   S: <result id="modify01">
   S:    <source owner="user@cal.example.com"/>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-tvx2
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: BEGIN:VEVENT
   S: UID:abcd12345
   S: REQUEST-STATUS: 2.0
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-tvx2--
   S: END

   In this example, all instances of "Building 6" are replaced by "New
   office lobby" in VEVENTs:

   C: MSG 1 12 . 9875 870
   C: Content-Type: multipart/related; boundary="boundary-trew2";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-trew2
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <modify id="modify02"/>
   C:    <select>
   C:       <source owner="user@cal.example.com" depth=*/>
   C:       <data content="cid:query@cal.example.com"/>
   C:    </select>
   C:    <update remove-missing=false>
   C:       <data content="cid:update@cal.example.com"/>
   C:    </update>
   C: </modify>
   C: --boundary-trew2
   C: Content-Type: text/calendar
   C: Content-ID: query@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VQUERY
   C: QUERY: SELECT * FROM VEVENT WHERE LOCATION='Building 6'
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-trew2
   C: Content-Type: text/calendar
   C: Content-ID: update@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VEVENT
   C: LOCATION:New office lobby
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-trew2--
   C: END
   S: RPY 1 12 X-PROPERTY       0+
          . 10745 578
   S: Content-Type: multipart/related; boundary="boundary-poiu51";
   S:    start="command@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-poiu51
   S: Content-Type: application/beep+xml
   S: Content-ID: command@cal.example.com
   S:
   S: <result id="modify02">
   S:    <source owner="user@cal.example.com"/>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-poiu51
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: BEGIN:VEVENT
   S: UID:abcd12345
   S: REQUEST-STATUS: 2.0
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-poiu51--
   S: END

6.2.4.4 "move" Command

   Attributes:

      "id" (see Section 6.2.2.1).

   Elements:

      "max-time": See Section 3.3.

      "target":  The "target" element points to the container where the
      components are to be relocated.

      "select": identifies the component(s) to move.

   Response:

      One "result" message for each "source" in the "select" element is
      returned (see Section 3.1).

      One of the following "request-status" codes MUST be returned:

         2.0 - successfully created the component or calendar

         6.1 - Container not found

         6.3 - Bad args

      The "data" element of each "result" message is subject to the
      result restriction table defined below.

   The "move" command is used to move components within the CS's
   hierarchy of calendars.  When moving VAGENDA, the CS MUST ensure that
   VCARs are still valid after the move, and the CS MUST update the
   PARENT and CHILDREN properties of the new and old parent containers.

   Restriction Table for "data" element of the "result" response:

       Component/Property  Presence Comment
       ------------------- -------- -------------------------------

       VCALENDAR              1+ . VERSION              1        MUST be 2.1 . VAGENDA [IANA-PROP]      0+       any IANA registered
                                          property
          . . RELCALID           1
       . . REQUEST-STATUS VRIGHT           1+
          . VCAR                 0+
       . . CARID              1 . . REQUEST-STATUS PERMISSION     1+
          . VEVENT               0+
       . . UID                1 . . REQUEST-STATUS     1+ DENY           0+       Note, there must be at
                                          least one GRANT or DENY
                                          within the VRIGHT.
          . . VALARM             0        if VEVENT was successfully
                                       saved
                              1+       if . . GRANT          0+       Note, there were errors saving
                                       alarms must be at
                                          least one GRANT or DENY
                                          within the VRIGHT.
          . . . ALARMID          1 . SCOPE          0+       Note, there must be at
                                          least one SCOPE if
                                          PERMISSION is set to
                                          "READ", "MODIFY",
                                          "DELETE", or "*".
          . . . REQUEST-STATUS   1+ . VFREEBUSY RESTRICTION    0 or 0+  Note, allowed only if
                                          PERMISSION is set to
                                          "WRITE", "MODIFY", or "*".
          . VJOURNAL . . . X-PROPERTY     0+
          . . UID                1 . . REQUEST-STATUS     1+ [IANA-PROP]    0+       any IANA registered
                                          property

          . VQUERY               0+
               (For VQUERY minimum values - see the VQUERY sections.
                Plus each each new VQUERY must have a QUERYID property)

          . x-component          0+

      Restriction Table for the CDATA section of a reply that contains
      an iCalendar object is any valid [ITIP] response plus any from
      this restriction table and the VQUERY responses can contain
      any iCalendar properties that are wrapped in BEGIN/END VCALENDAR.
      There MUST BE at least one component inside of the VCALENDAR
      object.

          Component/Property  Presence Comment
          ------------------- -------- -------------------------------

          VCALENDAR              1+
          . VERSION              1        MUST BE at least 2.0
          . REQUEST-STATUS TARGET               1+
          . VTODO CMDID                0 or 1

          . VAGENDA              0+
          . . UID RELCALID           1
          . . REQUEST-STATUS     1+

          . VCAR                 0+
          . . VALARM             0        if VTODO was successfully
                                       saved
                              1+       if there were errors saving
                                       alarms CARID              1
          . . REQUEST-STATUS     1+

          . ALARMID          1 VQUERY               0+
          . . QUERYID            0+      One for each QUERYID supplied in "create"
          . . REQUEST-STATUS     1+
             ---------------------------------------------------------

   [EDITORS NOTE: Issues:

      1) Should one be able to move a calendar owned by person X into a
      calendar owned by person Y.  (Can these such rights be specified
      in VCARs?)

   Example: moving
            (Plus the VAGENDA Nellis to Area-51

   C: MSG 1 12 query results)

          . 11323 613
   C: Content-Type: multipart/related; boundary="boundary-kljr";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C: x-component          0+

      In the following example, two new top level VAGENDAs are created.
      Note that the CSID of the server is cal.example.com.

      C: --boundary-kljr MSG 1 8 . 3843 480
      C: Content-Type: application/beep+xml application/cap+xml
      C: Content-ID: 1@cal.example.com
      C: <create>
      C: <move id="move01"/> <![CDATA[
      C:    <select> Content-Type: text/calendar
      C:       <source csid="cal@example.com" depth=*>
      C:       <data content="cid:query@cal.example.com"/> BEGIN:VCALENDAR
      C:    </select> VERSION:2.0
      C:    <target relcalid="area-51"/> CMDID:creation01
      C: </move> TARGET:cal.example.com
      C: --boundary-kljr BEGIN:VAGENDA                           <- data for 1st new calendar
      C: Content-Type: text/calendar RELCALID:relcalz1
      C: Content-ID: query@cal.example.com NAME;LANGUAGE=EN-us:Bill's Soccer Team
      C: OWNER:bill
      C: BEGIN:VCALENDAR CALMASTER:mailto:bill@example.com
      C: BEGIN:VQUERY TZID:US/Pacific
      C: QUERY: SELECT * FROM VAGENDA WHERE RELCALID='Nellis' END:VAGENDA
      C: END:VQUERY BEGIN:VAGENDA                           <- data for 2nd new calendar
      C: RELCALID: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
      C: --boundary-kljr-- />]]>
      C: END
   S: RPY 1 2 . 11936 571
   S: Content-Type: multipart/related; boundary="boundary-mnbvd";
   S:    start="reply@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-mnbvd

      When there are multiple TARGET'values in the original command object
      then the replies MUST BE in the exact same order as they were provided
      to the CS. The same is true for the objects created, their responses
      MUST BE in the exact same order as they were supplied to the CS.
      (With the BEEP header and footer removed)
      S: Content-Type: application/beep+xml
   S: Content-ID: reply@cal.example.com
   S: text/calendar
      S: <result id="move01">
      S:    <source csid=cal@example.com depth=*> BEGIN:VCALENDAR
      S:    <request-status code="2.0"/> VERSION:2.0
      S:    <data content="cid:2@cal.example.com"/> CMDID:creation01
      S: </result> TARGET:cal.example.com
      S: --boundary-mnbvd TARGET:cal.example.com
      S: Content-Type: text/calendar BEGIN:VAGENDA                     <- Reply for 1st calendar create
      S: Content-ID: 2@cal.example.com RELCALID:relcalz1
      S: REQUEST-STATUS:2.0
      S: BEGIN:VCALENDAR END:VAGENDA
      S: BEGIN:VAGENDA                     <- Reply for 2nd calendar create
      S: RELCALID:Nellis RELCALID:relcalz2
      S: REQUEST-STATUS: 2.0 REQUEST-STATUS:2.0
      S: END:VAGENDA
      S: END:VCALENDAR
   S: --boundary-mnbvd--
   S: END

6.2.4.5 "search" Command

   Attributes:

      "id" (see Section 6.2.2.1).

   Elements:

      "max-time": See Section 3.3.

      "select": identifies the components to return.

      "max-results": maximum number of components to return per source
      (if omited unlimited).

      "max-size": maximum size

      To create a new component in bytes, multiple containers simply name
      all of the iCalendar object to
      return.

   Response:

      A "result" message per "source" containers in the "select" element is
      returned (see Section 3.1).

      One of TARGET in the create command. Here
      a new VEVENT is created in two TARGETs. In this example, the
      VEVENT is one new iTIP REQUEST object in two calendars. The
      results would be iCalendar object that conform to the iTIP
      replys as defined in iTIP.

      C: Content-Type: text/calendar
      C:
      C: BEGIN:VCALENDAR
      C: VERSION:2.0
      C: CMDID:creation02
      C: METHOD:REQUEST
      C: TARGET:relcalz1
      C: TARGET:relcalz2
      C: BEGIN:VEVENT
      C: DTSTART:99990307T180000Z
      C: UID:abcd12345
      C: DTEND:99990307T190000Z
      C: SUMMARY:Important Meeting
      C: END:VEVENT
      C: END:VCALENDAR

      The CS reply can be combined when there is exactly one target.
      If a <create> command deposited two METHOD:REQUEST objects into
      the same target, this could be the reply.

      S: <result>
      S: <![CDATA[
      S: Content-Type: text/calendar
      S:

      S: BEGIN:VCALENDAR
      S: CMDID:deposit request
      S: TARGET:relcalz1
      S: VERSION:2.0
      S: BEGIN:VEVENT
      S: REQUEST-STATUS:2.0
      S: END:VEVENT
      S: BEGIN:VEVENT
      S: REQUEST-STATUS:2.0
      S: END:VEVENT
      S: END:VCALENDAR
      S: >]]>
      S: </result>

6.2.2.2 "move" Command

   Attributes:

         "cmdid"

   Elements:

         "max-time": See Section 3.3.

         "target":  The "target" element points to the container where
         the components are to be relocated.

         "select": identifies the component(s) to move.

   Response:

         One "result" message for each "source" in the "select" element
         is returned (see Section 3.1).

         One of the following "request-status" codes MUST be returned:

               2.0 - successfully created moved the component or calendar

               6.1 - Container not found

               6.3 - Bad args

         The "data" element of each "result" message points is subject to an iCalendar
      object composed of all the selected components.  Only "REQUEST-
      STATUS" and the properties mentioned in
         result restriction table defined below.

   The "move" command is used to move components within the "SELECT" clause CS's
   hierarchy of calendars.  The access control on the
      QUERY are included VAGENDA after it
   has been moved to its new location in the components.

   Searching for Events

   In calstore hierarchy MUST be
   at least as secure as it was prior to the example below events on March 10,1999 between 080000Z and
   190000Z are read.  In move.  One way to
   accomplish this case only 4 properties for each event are
   returned.  Two calendars are specified.  Only booked (vs scheduled)
   entries are is to be returned.  The first result returns two VEVENTs build a list of VCARs that match apply to the VAGENDA
   in that "source", its old hierarchy and and write them into the second result returns only one
   VEVENT VAGENDA before
   moving it to its new location.

   Restriction Table for "data" element of the second "source". "result" response:

       Component/Property  Presence Comment
       ------------------- -------- -------------------------------

       VCALENDAR              1+
       . VERSION              1        MUST be 2.0

       . VAGENDA              0+
       . . RELCALID           1
       . . REQUEST-STATUS     1+

       . VCAR                 0+
       . . CARID              1
       . . REQUEST-STATUS     1+

       . VEVENT               0+
       . . UID                1
       . . REQUEST-STATUS     1+

       . . VALARM             0        if VEVENT was successfully
                                       saved
                              1+       if there were errors saving
                                       alarms
       . . . ALARMID          1
       . . . REQUEST-STATUS   1+

       . VFREEBUSY            0

       . VJOURNAL             0+
       . . UID                1
       . . REQUEST-STATUS     1+

       . VQUERY               0+
       . . REQUEST-STATUS     1+

       . VTODO                0+
       . . UID                1
       . . REQUEST-STATUS     1+
       . . VALARM             0        if VTODO was successfully
                                       saved
                              1+       if there were errors saving
                                       alarms
       . . . ALARMID          1
       . . . REQUEST-STATUS   1+

             ---------------------------------------------------------

   Example: moving the VAGENDA Nellis to Area-51

   C: MSG 1 13 12 . 12507 704 11323 613
   C: Content-Type: multipart/related; boundary="boundary-5329"; boundary="boundary-kljr";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-5329 --boundary-kljr
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <search id="search01"/> <move id="move01"/>
   C:    <select>
   C:       <source relcalid="relcal2"/>
   C:       <source relcalid="relcal3"/> csid="cal@example.com" depth=*>
   C:       <data content="cid:query@cal.example.com"/>
   C:    </select>
   C: </search>    <target relcalid="area-51"/>
   C: </move>
   C: --boundary-5329 --boundary-kljr
   C: Content-Type: text/calendar
   C: Content-ID: query@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VQUERY
   C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
   C: QUERY: SELECT * FROM VEVENT
   C: VAGENDA WHERE DTEND >= '19990310T080000Z'
   C:  AND DTSTART <= '19990310T190000Z'
   C:  AND METHOD IS NULL RELCALID='Nellis'
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-5329-- --boundary-kljr--
   C: END
   S: ANS RPY 1 13 2 . 13211 803 0 11936 571
   S: Content-Type: multipart/related; boundary="boundary-f4fw2"; boundary="boundary-mnbvd";
   S:    start="answer@cal.example.com";    start="reply@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-f4fw2
   S: Content-Type: application/beep+xml
   S: Content-ID: answer@cal.example.com
   S:
   S: <result id="search01">
   S:    <source relcalid="relcal2"/>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-f4fw2
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VEVENT
   S: DTSTART:19990310T090000Z
   S: DTEND:19990310T100000Z
   S: UID:abcxyz12345
   S: SUMMARY:Meet with Sir Elton
   S: REQUEST-STATUS:2.0
   S: END:VEVENT
   S: BEGIN:VEVENT
   S: DTSTART:19990310T130000Z
   S: DTEND:19990310T133000Z
   S: UID:abcxyz8999
   S: SUMMARY:Meet with  brave Sir Robin
   S: REQUEST-STATUS:2.0
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-f4fw2--
   S: END
   S: ANS 1 13 . 14014 664 1
   S: Content-Type: multipart/related; boundary="boundary-r432";
   S:    start="answer@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-r432 --boundary-mnbvd
   S: Content-Type: application/beep+xml
   S: Content-ID: answer@cal.example.com reply@cal.example.com
   S:
   S: <result id="search01"> id="move01">
   S:    <source relcalid="relcal3"/> csid=cal@example.com depth=*>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-r432 --boundary-mnbvd
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VEVENT
   S: REQUEST-STATUS:2.0
   S: DTSTART:19990310T140000Z
   S: DTEND:19990310T150000Z
   S: UID:123456asdf BEGIN:VAGENDA
   S: SUMMARY:Summer Budget RELCALID:Nellis
   S: REQUEST-STATUS:2.0 REQUEST-STATUS: 2.0
   S: END:VEVENT END:VAGENDA
   S: END:VCALENDAR
   S: --boundary-r432--
   S: END
   S: NUL 1 13 . 14678 0 --boundary-mnbvd--
   S: END

6.2.2.3 "delete" Command

      Attributes:

            "latency" and "action" (optional see Section xxxx)

      Response:

            One of the following "request-status" codes MUST be returned
            for each target supplied and for each object deleted
            as in that target that is effected.

                  2.0 - successfully deleted the component or calendar

                  6.1 - Container not found

                  6.3 - Bad args

      The return values are subject "delete" command is used to VCAR filtering.  That is, if delete calendars or components.
      The "select" element specifies the
   request contains properties container(s) to which the UPN does not have access,
   those properties will not appear in delete.

      Restriction Table for the return values.  If "delete" command of the UPN
   has access to "reply"
      response.

          Component/Property    Presence Comment
          -------------------   -------- -----------------------------

          VCALENDAR             1+

          . VERSION             1        MUST be at least one property of 2.0
          . VAGENDA                      Only if VAGENDAS were
                                         deleted

          . CMDID               0+       MUST BE supplied if it was
                                         supplied in the component, but has been
   denied access to all properties called out in the request, the
   response will contain a single delete command.

          . METHOD              1        MUST BE DELETE

          . TARGET              1+

          . REQUEST-STATUS property indicating the
   error.  That is, the      1

          . VCAR                0+       Only if VCAR components were
                                         deleted
          . . CARID             1
          . . REQUEST-STATUS    1

          . VEVENT              0+       Only if VEVENT components will be the following:

   [EDITORS NOTE: Should the one(s) that the UPN has access to - be
   returned?]

   S: ANS
                                         were targets of deletion.
          . . UID               1 13
          . 14014 548 . REQUEST-STATUS    0
   S: Content-Type: multipart/related; boundary="boundary-fmei3";
   S:    start="command@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-fmei3
   S: Content-Type: application/beep+xml
   S: Content-ID: command@cal.example.com
   S:
   S: <result>
   S:    <source relcalid="relcalid"/>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-fmei3
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VEVENT
   S: REQUEST-STATUS:4.1
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-fmei3--
   S: END

   If the UPN has no access to any events at all, the response will
   simply be or 1   Omitted if an empty data set.  The response looks embedded VALARM was
                                         the same if there
   are particular events to which target of the CU has been denied access.

   S: ANS 1 13 deletion.
          . 14014 502 0
   S: Content-Type: multipart/related; boundary="boundary-ewrvc";
   S:    start="command@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-ewrvc
   S: Content-Type: application/beep+xml
   S: Content-ID: command@cal.example.com
   S:
   S: <result>
   S:    <source relcalid="relcalid"/>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-ewrvc
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: END:VCALENDAR
   S: --boundary-ewrvc--
   S: END

   Find alarms within a range . VALARM             0+      Only if VALARM components
                                         were targets of time for booked VEVENTs.

   C: MSG deletion.
          . . . SEQUENCE        1 15
          . 14678 747
   C: Content-Type: multipart/related; boundary="boundary-weoiu";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-weoiu
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <search id="search02"/>
   C:    <select>
   C:       <source relcalid="relcal2"/>
   C:       <source relcalid="relcal3"/>
   C:       <data content="cid:query@cal.example.com"/>
   C:    </select>
   C: </search>
   C: --boundary-weoiu . . REQUEST-STATUS  1

          . VFREEBUSY           0+       Only if VFREEBUSY was the target
                                         of deletion.
          . . UID               1
          . . DTSTAMP           1
          . . REQUEST-STATUS    1

          . VJOURNAL            0+       Only if VJOURNAL components
                                         were targets of deletion.
          . . UID               1
          . . REQUEST-STATUS    1

          . VQUERY              0+       Only if VQUERY components
                                         were targets of deletion.
          . UID                 1
          . REQUEST-STATUS      1

          . VTIMEZONE           0+       Only if VTIMEZONE components
          . . TZID                       were targets of deletion.
          . . REQUEST-STATUS    1

          . VTODO               0+       Only if VTODO components were
                                         targets of deletion.
          . . UID               1
          . . REQUEST-STATUS    0 or 1   Omitted if an embedded VALARM was
                                         the target of the deletion.

          . . VALARM            0+       Only if VALARM components
                                         were targets of deletion.
          . . . ALARMID         1
          . . . REQUEST-STATUS  1

          ----------------------------------------------------------

      Note: If a VAGENDA is deleted then NONE of its contained
      components will return any REQUEST-STATUS responses.

      Example to delete a VEVENT with VEVENT UID 'abcd12345' from
      the calendar "relcald-22" from the current CS:

      C: Content-Type: text/calendar
      C: Content-ID: query@cal.example.com
   C:
      C: BEGIN:VCALENDAR
      C: TARGET:relcalid-22
      C: METHOD:DELETE
      C: CMDID:random but unique per CAU
      C: BEGIN:VQUERY
      C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID,VALARM.*
   C: * FROM VEVENT,VTODO
   C: VEVENT WHERE VALARM.TRIGGER >= '19990310T080000Z'
   C:    AND VALARM.TRIGGER <= '19990310T190000Z'
   C:    AND METHOD IS NULL UID = 'abcd12345'
      C: END:VQUERY
      C: END:VCALENDAR
   C: --boundary-weoiu--
   C: END
   S: ANS 1 15 . 15426 511 0
   S: Content-Type: multipart/related; boundary="boundary-kjhs";
   S:    start="command@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-kjhs
   S: Content-Type: application/beep+xml
   S: Content-ID: command@cal.example.com
   S:
   S: <result id="search02">
   S:    <source relcalid="relcal2"/>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-kjhs
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: END:VCALENDAR
   S: --boundary-kjhs--
   S: END
   S: ANS 1 2 . 15937 734 1
   S: Content-Type: multipart/related; boundary="boundary-435fe";
   S:    start="command@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-435fe
   S: Content-Type: application/beep+xml
   S: Content-ID: command@cal.example.com
   S:
   S: <result id="search02">
   S:    <source relcalid="relcal3"/>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-435fe
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VEVENT
   S: DTSTART:19990310T130000Z
   S: DTEND:19990310T133000Z
   S: UID:abcxyz8999
   S: SUMMARY:Meet with brave Sir Robin
   S: BEGIN:VALARM
   S: TRIGGER:19990310T132500Z
   S: SUMMARY:Almost time...
   S: ACTION:DISPLAY
   S: END:VALARM
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-435fe--
   S: END
   S: NUL 1 15 . 16671 0
   S: END

   In this example bill@example.com reads

      One or more iCalendar object will be returned that contain
      a day's worth REQUEST-STATUS for the deleted components. There could have been
      more than one component deleted, Any booked and any
      number of events unprocessed iTIP scheduling components that
      matched the QUERY value in the above example. Each
      unique METHOD that was deleted from
   cap://cal.example.com/opaqueid99.

   C: MSG 1 16 . 16671 668
   C: Content-Type: multipart/related; boundary="boundary-vnj43";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-vnj43
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <search id="xyz12345"/>
   C:    <select>
   C:       <source relcalid="opaqueid99"/>
   C:       <data content="cid:query@cal.example.com"/>
   C:    </select>
   C: </search>
   C: --boundary-vnj43
   C: Content-Type: text/calendar
   C: Content-ID: query@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: BEGIN:VQUERY
   C: QUERY:SELECT DTSTART,DTEND,SUMMARY, UID FROM VEVENT
   C:   WHERE DTEND >= '19990714T080000Z'
   C:   AND DTSTART <= '19990715T080000Z'
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-vnj43--
   C: END
   S: RPY 1 16 . 17359 751
   S: Content-Type: multipart/related; boundary="boundary-rfew";
   S:    start="command@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-rfew
   S: Content-Type: application/beep+xml
   S: Content-ID: command@cal.example.com
   S:
   S: <result id="xyz12345">
   S:    <source relcalid="opaqueid99"/>
   S:    <request-status code="2.0"/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-rfew
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VEVENT
   S: DTSTART:19990714T200000Z
   S: DTEND:19990714T210000Z
   S: UID:000444888929922
   S: SUMMARY:Blah blah
   S: END:VEVENT
   S: BEGIN:VEVENT
   S: UID:0034848098038888989443
   S: SUMMARY:meeting
   S: DTEND:19990714T233000Z
   S: DTSTART:19990714T223000Z
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-rfew--
   S: END the store MUST BE in a
      seperate iCalendar object. This is because only one METHOD is allowed
      in an iCalendar object.

6.2.2.4 "modify" Command

      Attributes:

            "latency" and "action" (Optional - see xxx)

      Response:

            One of the following "request-status" codes MUST be returned:

                  2.0 - successfully modified the component or calendar

                  6.1 - Container not found

                  6.3 - Bad args

      The "modify" command is used to modify existing components.  The
      TARGET property specifies the calendars were the components
      exist that are going to be modified.

      The format of the request is three containers inside of VCALENDAR
      container object:

           BEGIN:VCALEDNAR
           <VQUERY>
           <OLD-VALUES>
           <NEW-VALUES>
           END:CALENDAR

     The VQUERY selects the components that are to be modified.

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

     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-VALULES is added to the component.

     In this example bill@example.com reads example the VEVENT with UID:unique-58 has; the LOCATION and
     LAST-MODIFIED  changed, the VALARM with SEQUENCE:3 has its
     TRIGGER disabled, the X-LOCAL property is removed from the VEVENT,
     and a COMMENT is added.

     Because SEQUENCE is used to locate the VALARM in this example,
     both the OLD-VALUES and the NEW-VALUES contains SEQUENCE:3 and
     if SEQUENCE was left out of NEW-VALUES - it would have been deleted.

     Example:

     C: Content-Type: text/calendar
     C: BEGIN:VCALENDAR
     C: VERSION:2.0
     C: TARGET:my-cal
     C: METHOD:MODIFY
     C: BEGIN:VQUERY
     C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58'
     C: END:VQUERY
     C: BEGIN:VEVENT
     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
     C: BEGIN:VEVENT
     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
     C: END:VEVENT
     C: />]]>
     C: </modify>
     C: END

     X-LOCAL was not supplied in the NEW-VALUES, so it was deleted.
     LOCATION was altered, as was LAST-MODIFIED. The VALARM with
     SEQUENCE:3 had its TRIGGER disabled, and SEQUENCE did not
     change so it was not effected. COMMENT was added.

     When it comes to inline ATTACHMENTs, the CUA only needs to uniquely
     identify the contents of the ATTACHE value in the OLD-VALUES in order
     to delete them. When the CS compares the attachment data it is compared
     in it binary form. The ATTACHMENT value supplied by the CUA MUST BE
     valid encoded information.

     For example, to delete a huge inline attachment from every
     VEVENT in 'my-cal' that has an ATTACH with the OLD-VALUES:

           BEGIN:VCALENDAR
           VERSION:2.0
           TARGET:my-cal
           METHOD:MODIFY
           BEGIN:VQUERY
           QUERY:SELECT ATTACH FROM VEVENT
           END:VQUERY
           BEGIN:VEVENT
           ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
            MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
            EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
            ...<remander of attachment data NOT supplied> ....
           END:VEVENT
           BEGIN:VEVENT
           END:VEVENT
           END:VCALENDAR

      Above the NEW-VALUES is empty, so everything in the OLD-VALUES
      is deleted.

      Furthermore, the following additional restrictions apply:

            One can not change the "UID" property of a component.

            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.

            As all contained components that matching OLD-VALUES will be
            modified. In the first modify example above, if SEQUENCE were
            to be deleted from both the OLD-VALUES and NEW-VALUES, then all
            TRIGGERs that matched the OLD-VALUES in all VALARM in the
            selected VEVENTs would be disabled.

            The result of the modify MUST BE a valid iCalendar object.

      If the REQUEST-STATUS is 2.0, then the entire modification was
      successful.

      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 for each error that occurred.

           There MUST BE at least one error reported.

      If multiple components are selected, then the UID for each selected
      component MUST BE returned if the component contains a UID:

      S: Content-Type: text/calendar
      S:

      S: BEGIN:VCALENDAR
      S: TARGET:relcalid
      S: BEGIN:VEVENT
      S: UID:123
      S: REQUEST-STATUS:2.0
      S: END:VEVENT
      S: END:VCALENDAR

6.2.2.5 "search" Command

      Attributes:

          "latency" and "action" (Optional - see xxx)

      Response:

            One iCalendar message per "target" in the "select" element is
            returned (see Section xxx).

            One of the following "request-status" codes MUST be returned:

                  2.0   - successfully executed the query

                  2.0.9 - success, but some data could not be returned

                  6.1   - Container not found

                  6.3   - Bad args

            The data in each result contains an iCalendar object composed
            of all the selected components.  Only "REQUEST-STATUS"
            and the properties mentioned in the "SELECT" clause of the
            QUERY  are included in the components. Each iCalendar object is
            tagged with the TARGET property and optional CMDID property.

      Searching for Events

      In the example below events on March 10,1999 between 080000Z and
      190000Z are read.  In this case only 4 properties for each event are
      returned.  Two calendars are specified.  Only booked (vs scheduled)
      entries are to be returned.

      NOTE: BEEP headers and footers not included in the examples below.

      C: Content-Type: text/calendar
      C:
      C: BEGIN:VCALENDAR
      C: VERSION:2.0
      C: METHOD:SEARCH
      C: CMDID:search01
      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 METHOD  IS 'CREATE'
      C: END:VQUERY
      C: END:VCALENDAR

      S: Content-Type: text/calendar
      S:
      S: BEGIN:VCALENDAR
      S: VERSION:2.0
      S: METHOD:REPLY
      S: TARGET:relacal2
      S: CMDID:search01
      S: REQUEST-STATUS:2.0
      S: BEGIN:VEVENT
      S: DTSTART:19990310T090000Z
      S: DTEND:19990310T100000Z
      S: UID:abcxyz12345
      S: SUMMARY:Meet with Sir Elton
      S: REQUEST-STATUS:2.0
      S: END:VEVENT
      S: BEGIN:VEVENT
      S: DTSTART:19990310T130000Z
      S: DTEND:19990310T133000Z
      S: UID:abcxyz8999
      S: SUMMARY:Meet with  brave Sir Robin
      S: REQUEST-STATUS:2.0
      S: END:VEVENT
      S: END:VCALENDAR

      S: Content-Type: text/calendar
      S:
      S: BEGIN:VCALENDAR
      S: VERSION:2.0
      S: METHOD:REPLY
      S: CMDID:search01
      S: TARGET:relcal3
      S: REQUEST-STATUS:2.0
      S: BEGIN:VEVENT
      S: REQUEST-STATUS:2.0
      S: DTSTART:19990310T140000Z
      S: DTEND:19990310T150000Z
      S: UID:123456asdf
      S: SUMMARY:Summer Budget
      S: REQUEST-STATUS:2.0
      S: END:VEVENT
      S: 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.  That is, the VEVENT components will be the following:

      Here the request was successful, but the VEVENT contents
      were not accessable (4.1).

      S: Content-Type: text/calendar
      S:
      S: BEGIN:VCALENDAR
      S: METHOD:REPLY
      S: TARGET:relcalid
      S: CMIDID=any-id
      S: VERSION:2.0
      S: BEGIN:VEVENT
      S: REQUEST-STATUS:4.1
      S: END:VEVENT
      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 looks the same if there
      the particular components did not exist.

      S: Content-Type: text/calendar
      S:
      S: BEGIN:VCALENDAR
      S: VERSION:2.0
      S: METHOD:REPLY
      S: CMDID:some-id
      S: TARGET:ralcalid
      S: REQUEST-STATUS:2.0
      S: END:VCALENDAR

      Find alarms within a range of time for booked VEVENTs.

      C: Content-Type: text/calendar
      C:
      C: BEGIN:VCALENDAR
      C: VERSION:2.0
      C: METHOD:SEARCH
      C: TARGET:"Doug:Baseball"
      C: TARGET:"Steve:Baseball"
      C: CMDID:search02
      C: BEGIN:VQUERY
      C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID,VALARM
      C: FROM VEVENT,VTODO
      C: USING_COMPONENT VALARM my-alarm
      C:  WHERE my-alarm.TRIGGER >= '19990310T080000Z'
      C:  AND my-alarm.TRIGGER <= '19990310T190000Z'
      C:  AND METHOD = 'CREATE'
      C: END:VQUERY
      C: END:VCALENDAR

      Here no data was returned for relcal2:

      S: Content-Type: text/calendar
      S:
      S: BEGIN:VCALENDAR
      S: VERSION:2.0
      S: TARGET:relcal2
      S: CMDID:search02
      S: METHOD:REPLY
      S: REQUEST-STATUS:X.Y                <- todo
      S: END:VCALENDAR

      And here relcal3 did return some resuls:

      S: Content-Type: text/calendar
      S:
      S: BEGIN:VCALENDAR
      S: VERSION:2.0
      S: METHOD:REPLY
      S: TARGET:relcal3
      S: CMDID:search02
      S: REQUEST-STATUS:2.0
      S: BEGIN:VEVENT
      S: DTSTART:19990310T130000Z
      S: DTEND:19990310T133000Z
      S: UID:abcxyz8999
      S: SUMMARY:Meet with brave Sir Robin
      S: BEGIN:VALARM
      S: TRIGGER:19990310T132500Z
      S: SUMMARY:Almost time...

      S: ACTION:DISPLAY
      S: END:VALARM
      S: END:VEVENT
      S: END:VCALENDAR

      In this example bill@example.com reads a day's worth of events from
      cap://cal.example.com/opaqueid99. And the optional cmdid is not
      supplied as the CUA will not issue another command until this
      one completes.

      C: BEGIN:VCALENDAR
      C: VERSION:2.0
      C: METHOD:SEARCH
      C: TARGET:opaqueid99
      C: BEGIN:VQUERY
      C: QUERY:SELECT DTSTART,DTEND,SUMMARY, UID FROM VEVENT
      C:  WHERE DTEND >= '19990714T080000Z'
      C:  AND DTSTART <= '19990715T080000Z'
      C: END:VQUERY
      C: END:VCALENDAR

      If there are multiple targets, each iCalendar reply is contained
      within its own <reply>.

      Stored VQUERY can be used by specifying the property QUERYID
      instead of QUERY.

      This matches all calendar store properties.  This MUST NOT return any
      VAGENDAs. IT would return all RELATED-TO properties.

           BEGIN:VCALENDAR
           VERSION:2.0
           METHOD:SEARCH
           TARGET:cap://bobo.ex.com
           BEGIN:VQUERY
           QUERY:SELECT * FROM VCALSTORE
           END:VQUERY
           END:VCALENDAR

      This will match all properties of the VAGENDA relcal4.  This MUST NOT
      return any components.

           BEGIN:VCALENDAR
           VERSION:2.0
           METHOD:SEARCH
           TARGET:cap://bobo.ex.com/relcal4
           BEGIN:VQUERY
           QUERY:SELECT * FROM VAGENDA
           END:VQUERY
           END:VCALENDAR

      This will fetch all stored VQUERYs. All stored queries MUST BE
      saved with a QUERYID.

           BEGIN:VCALENDAR
           VERSION:2.0
           METHOD:SEARCH
           TARGET:relcal4
           BEGIN:VQUERY
           QUERY:SELECT VQUERY.* FROM VQUERY.
           END:VQUERY
           END:VCALENDAR

6.2.2.6 Response Codes

   Numeric response codes are returned at both the transfer and
   application layer.  The same set of codes is used in both cases.

   The format of these codes is described in [RFC2445], and extend in
   [iTIP] and [iMIP].  The following describes new codes added to this
   set.

   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 [RFC2445], to make the accompanying
   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.

             2.0.9             Success of the read operation, but some
                               requested information could not be returned
                               due to access control.

             3.1.4             Capability not supported.

             4.1               Calendar store access denied.

             6.3               Attempt to create or modify an event
                               such that it would overlap another event
                               in either of the following two circum-
                               stances:

                               (a) One of the events has a TRANSP
                               property set to OPAQUE-NOCONFLICT or
                               TRANSPARENT-NOCONFLICT.

                               (b) The calendar's ALLOW-CONFLICT
                               property is set to NO.

             6.XXX             [EDITORS NOTE: More are in this memo -
                               add here TODO]

             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 Calendar Service
                               that prevents the operation from
                               succeeding.

             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
                               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 id specified is
                               already in use.

             9.0               An unrecognized command was received.

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

7. Initial Registrations

7.1 BEEP Profile Registration

         Profile Identification: http://iana.org/beep/transient/calsch/
         cap/1.0

         Messages exchanged during Channel Creation: none

         Messages starting one-to-one exchanges:

               "timeout", "generate-uid", "identify", "get-capability"

         Messages in positive replies:

               "uid-list", "abort", "continue", "result", "capability"

         Messages in negative replies:

               "error"

         Messages in one-to-many exchanges: "create", "search",
         "delete", "modify" or "schedule"

         Message Syntax: c.f., Section 8

         Message Semantics: c.f., Section 6

         Contact Information: c.f., the "Author's Address" section of
         this memo

7.2  Registration: The System (Well-Known) TCP port number for CAP

   A single well-known port (xxxx) is allocated to CAP.

         Protocol Number:

               TCP

         Message Formats, Types, Opcodes, and Sequences:

               Section 8

         Functions:

               Section 6
         Use of Broadcast/Multicast:

               none

         Proposed Name:

               Calendar Access Protocol

         Short name:

               cap

         Contact Information:

               cf., the "Authors' Addresses" section of this draft

8. CAP DTD

   To Be Done.

9. Properties

   [Once definitions are in iCalendar format and are agreed on, should
   be moved into section "Extension to iCalendar"]

9.1 Calendar Store Properties

   The following are properties of the calendar store.

             Name           Read  Value     Description
                            Only  Type
             --------------------------------------------------------------
             CALMASTER      N     URI       URL of contact address for person
                                            responsible. SHOULD BE
                                            mailto URL.

             CSID           Y     URI       The CSID of this calendar
                                            store. If not specified, it is
                                            the same as the hostname.

             DEFAULT_VCARS  N     TEXT      A multivalued property
                                            containing the default VCARs
                                            for newly created top level
                                            calendars. Each entry is a day's worth of events from
   cap://cal.example.com/opaqueid101
                                            CARID. It MUST include at a
                                            minimum
                                            READBUSYTIMEINFO,REQUESTONLY,
                                            UPDATEPARTSTATUS, and
   cap://cal.example.com/opaqueid103

   C: MSG 1 17 . 18110 694
   C: Content-Type: multipart/related; boundary="boundary=wtu";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary=wtu
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <search id="xyz12346"/>
   C:    <select>
   C:       <source relcalid="opaqueid101"/>
   C:       <source relcalid="opaqueid103"/>
   C:       <data content="cid:query@cal.example.com"/>
   C:    </select>
   C: </search>
   C: --boundary=wtu
   C: Content-Type: text/calendar
   C: Content-ID: query@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: BEGIN:VQUERY
   C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
   C: WHERE DTEND >= 19990714T080000Z AND
   C:   DTSTART <= 19990715T080000Z
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary=wtu--
   C: END

   S: ANS 1 17 . 18804 717 0
   S: Content-Type: multipart/related; boundary="boundary-09436";
   S:    start="command@cal.example.com";
   S:    type="application/beep+xml"
   S:
   S: --boundary-09436
   S: Content-Type: application/beep+xml
   S: Content-ID: command@cal.example.com
   S:
   S: <result id="xyz12346">
   S:    <source relcalid="opaqueid103"/>
   S:    <request-status code="2.0"/>
   # this response code means that
                                            DEFAULTOWNER.

             MAXDATE        Y     DATE-TIME The date/time in the transport successfully
   # delivered future
                                            beyond which the data.
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: --boundary-09436
   S: Content-Type: text/calendar
   S: Content-ID: 2@cal.example.com
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.1
   S: BEGIN:VEVENT
   S: UID:0034848098038888989443
   S: SUMMARY:meeting
   S: DTEND:19990714T233000Z
   S: DTSTART:19990714T223000Z
   S: END:VEVENT
   S: END:VCALENDAR
   S: --boundary-09436--
   S: END

   S: ANS 1 18 . 19521 216 1
   S: Content-Type: application/beep+xml
   S:
   S: <result id="xyz12346">
   S:    <source relcalid="opaqueid101"/>
   S:    <request-status code="4.1">Access Denied<request-status/>
   S:    <data content="cid:2@cal.example.com"/>
   S: </result>
   S: END

   S: NUL 1 18 . 19737 0
   S: END

   Stored VQUERY can server cannot
                                            represent. If not specified,
                                            then 99991231T235959 will be used by specifying
                                            assumed.

             MINDATE        Y     DATE-TIME The date/time in the property QUERYNAME
   instead of QUERY.

   Example:

              BEGIN:VQUERY
              QUERYNAME:StoredVQuery-1
              END:VQUERY
   This match all calendar store properties.  This MUST NOT return any
   VAGENDAs.

                BEGIN:VCALENDAR
                VERSION:2.1
                BEGIN:VQUERY
                QUERY:SELECT * FROM CALSTORE WHERE CSID='bobo.ex.com'
                END:VQUERY
                END:VCALENDAR

   This will match all properties of past prior
                                            to which the VAGENDA relcal4.  This MUST NOT
   return any components.

                BEGIN:VCALENDAR
                VERSION:2.1
                BEGIN:VQUERY
                QUERY:SELECT * FROM VAGENDA WHERE RELCALID='relcal4'
                END:VQUERY
                END:VCALENDAR

   This server cannot
                                            represent. If not specified,
                                            then 00000101T000000 will fetch all stored VQUERYs.

                BEGIN:VCALENDAR
                VERSION:2.1
                BEGIN:VQUERY
                QUERY:SELECT * FROM VQUERY WHERE QUERYNAME IS NOT NULL
                END:VQUERY
                END:VCALENDAR

6.3 Scheduling Commands

   Scheduling commands allow a CU to indirectly manipulate be
                                            assumed.

             CURRENT_DATETIME  Y  DATE-TIME Current server time. This is
                                            returned as a calendar by
   asking another CU local time and
                                            TZID.

             RECUR_ACCEPTED  Y    BOOLEAN   Boolean value will be set to perform an operation on their calendar.  For
   example, CU-A can request CU-B
                                            TRUE if the server will accept
                                            recurrence rules. It will be
                                            set to add FALSE if the server will
                                            not accept recurrence rules. If
                                            not specified a meeting to their calendar; in
   effect inviting CU-B CUA MUST assume
                                            TRUE.

             RECUR_EXPAND   Y     BOOLEAN   If set to TRUE, the meeting.

   Calendar access rights can be granted for scheduling commands without
   granting rights for more generalized access with CS supports
                                            the calendar
   commands.

   [EDITORS NOTE: This section needs expansion of recurrence
                                            rules in the returned set. If set
                                            to be completed by adding FALSE, the
   restriction tables for each CS is incapable
                                            of these iTIP methods. expanding recurrence rules.
                                            If not specified a CUA MUST assume
                                            TRUE.

             RECUR_LIMIT    Y   INTEGER     This numeric value describes
                                            how the server handles
                                            unbounded recurrences. The basis for
                                            value is only valid if
                                            RECURRENCE is TRUE. If the
   text
                                            value is to be taken from [iTIP].]

6.3.1 "schedule" Command

   Attributes:

      "id" (see Section 6.2.2.1).

   Elements:

      "max-time": See Section 3.3.

      "target":  Each "target" element points to a container where 0 it means that the
      sceduled element will be created.

      "data": MUST point to
                                            server supports unbounded
                                            recurrence rules. If it is non-
                                            zero, it is a valid iTip iCalendar object.  Refer to
      [iTIP] for positive integer
                                            indicating the definition number of the accepted METHOD and restriction
      tables.

   Response:

      One "result" message per "target" element MUST
                                            instances that will be returned (see
      Section 3.1).

      One of
                                            when the following "request-status" codes server expands an
                                            unbounded recurrence rule when
                                            fetched from the CS. A CUA MUST be returned:

         2.0 - Success

         6.1 - Container not found

         6.3 - Bad args

      Additionnal request-status code MAY be returned as described on
      [iTIP].
                                            query for date ranges when this
                                            value is zero.

             VERSION        Y   TEXT        The "data" element version of each "result" message the CS. The
                                            default and the only currently
                                            Supported version is subject "2.0" to
                                            match the
      result restriction table defined below.

   The "schedule" command insert a new scheduled component into [RFC2445] VERSION.

9.2 Calendar Properties

             Name           Read  Value     Description
                            Only  Type
             --------------------------------------------------------------
             ALLOW-CONFLICT  N    BOOLEAN   This boolean value indicates
                                            Whether or not the
   VSCHEDULE set calendar
                                            supports event conflicts. That
                                            is, whether or not any of the container(s) referred to by
                                            events in the calendar can
                                            overlap. If not specified the
                                            default value is TRUE meaning
                                            that conflicts are allowed.

             CALSCALE        N    TEXT      The CALSCALE for this calendar.
                                            If not specified the default is
                                            GREGORIAN.

             CHARSET         N    TEXT      The default charset for
                                            Localized strings in this
                                            calendar. If not specified, the "target"
   element(s).
                                            default is UTF-8.

             CHILD           Y    TEXT      A Calendar Service MUST accept iCalendar object with the following
   METHODs as described in [iTIP]:

        -----------------------------------------------------------
        Command        Description
        -----------------------------------------------------------
        PUBLISH        Publish a calendar entry sub-calendars belonging to one or more
                       calendars.
        REQUEST        Schedule a this
                                            calendar. A calendar entry with may have
                                            multiple sub-calendars, each one or more
                       calendars.
        REPLY          Response
                                            corresponding to a scheduling request.
        ADD            Add one or more instances to an existing
                       calendar entry.
        CANCEL         Cancel one or more instances to an existing
                       calendar entry.
        REFRESH        A request for the latest version CHILD property.

             CREATED         Y    DATE-TIME The timestamp of a
                       calendar entry.
        COUNTER        A request the calendar's
                                            create date.

             DEFAULT_VCARS   N    TEXT      The default VCARs for newly
                                            Created top level calendars.
                                            This is a change (a counter-proposal)
                       to a calendar entry.
        DECLINECOUNTER Decline a counter proposal.
        -----------------------------------------------------------

6.3.2 Processing Scheduling Components

   A CU might be invited to a meeting.  If the CU had been invited by
   CAP, CARID. The default
                                            value is the entry value of
                                            DEFAULT_VCARS in the CU calendar will be scheduled, but not booked.
   So a CUA will need to look VCALSTORE
                                            table.

             LANGUAGE        N    TEXT      The default language for scheduled entries
                                            localizable strings in the calendar and
   present them to the CU or automatically decide if the invitation this
                                            calendar. There is
   to no default.
                                            This value MUST NOT be accepted or processed.

   Example: empty.
                                            The possible values of this
                                            property are those specified in
                                            RFC-3066.

             LAST-MODIFIED   N    DATE-TIME The little league coach places timestamp when the teams entire schedule into your
                                            Properties of the calendar were
                                            last updated. Default is the
                                            same as CREATED.

             NAME            N    TEXT      The display name for this
                                            calendar.  Lets say that every game and practice It is on a Friday night
   and your localizable
                                            string. If not provided, an
                                            empty value will be returned.

             OWNER           N    URI       A multi-instanced property
                                            indicating the calendar now has this iTIP scheduling data:

               BEGIN:VCALENDAR
               VERSION:2.0
               METHOD:PUBLISH
               BEGIN:VEVENT
               DTSTAMP;TZID=US/Pacific:20000229T180000
               DTSTART;TZID=US/Pacific:20000303T180000
               ORGANIZER:coach@little.league.com
               SUMMARY:Schedule of games and practice
               UID:1-coach@little.league.com
               SEQUENCE:0
               DESCRIPTION:Please have your child owner.
                                            Each entry returned will be a
                                            UPN. There must be at the field
                and ready to play by 6pm.
               RRULE:FREQ=WEEKLY;COUNT=10
               END:VEVENT
               END:VCALENDAR

   At least one
                                            owner.

             PARENT          N    URI       The CALID of this point calendar's
                                            Parent maintained by a CAP
                                            server. An empty value means
                                            the above VEVENT calendar is not booked in your calendar; it the top level
                                            parent. The default value is
   simply scheduled. no
                                            parent.

             RELCALID        N    URI       A CUA would fetch unique identifier within this and all other scheduled
   VEVENTs from your calendar with:

   C: MSG 1 19 . 19737 582
   C: Content-Type: multipart/related; boundary="boundary-rtij41";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-rtij41
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <search id="xyz12345"/>
   C:    <select>
   C:       <source relcalid="relcal2"/>
   C:       <data content="cid:query@cal.example.com"/>
   C:    </select>
   C: </search>
   C: --boundary-rtij41
   C: Content-Type: text/calendar
   C: Content-ID: query@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VQUERY
   C: QUERY:SELECT * WHERE FROM VEVENT METHOD IS
                                            cal-store for the calendar.
                                            There is no default value.
                                            This value MUST NOT NULL
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-rtij41--
   C: END be empty.

             TOMBSTONE       N    BOOLEAN   TRUE indicator that this
                                            Calendar has been marked as
                                            deleted. The CUA and CU could determine which scheduling entries were to
   remain on default value is
                                            FALSE.

             TZID            N    TEXT      The id of the timezone
                                            Associated with this calendar.  Each scheduling component could
                                            See TZID in [RFC2445]. The default
                                            value is UTC.

10. Security Considerations

   Access rights should be deleted
   or updated with granted cautiously, consult Section 2.4.2 for
   a discussion of the "modify" subject.

   The "identify" command to remove the iTip METHOD. should be carefully implemented as discussed
   in Section 6.1.3.

   In some cases the CUA could automatically do addition, since CAP is a profile of the work and inform BEEP, consult [BEEP]'s
   Section 9 for a discussion of BEEP-specific security issues.

   Although service provisioning is a policy matter, at a minimum, all
   implementations must provide the
   CU.  An example following tuning profiles:

         for authentication: http://iana.org/beep/SASL/DIGEST-MD5

         for confidentiality: http://iana.org/beep/TLS (using the
         TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)

         for both: http://iana.org/beep/TLS (using the
         TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
         certificates)

11. Extensions To iCalendar

   The following section contains new components, properties,
   parameters, and values.

11.1 Property Value Data Types

11.1.1 UPN

   To: ietf-calendar@imc.org

   Subject: Registration of this text/calendar MIME value type UPN

   Value Name: UPN

   Purpose: This value type is CANCEL.  If configured to process
   METHOD:CANCEL it could execute the "delete" command used to delete the
   component and inform the CU identify values that the booked component had been
   canceled. contain user
   principal name of CU or group of CU.

   Formal Definition: The CUA MUST process the scheduled components in the order sent.
   Some optimization could be done value type is defined by the CUA.  One example following
   notation:

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

                     ; dot-atom-text is if defined in RFC 2822

   Description: This data type is an identifier that denotes a
   PUBLISH and later CU or a CANCEL for the same component
   group of CU.  A UPN is a RFC 2822 compliant e-mail address, with the same
   SEQUENCE number were scheduled, but not booked.  The CUA might never
   inform the CU
   exceptions listed below, and treat in most cases it as if is deliverable to the PUBLISH had never been received
   by doing a "delete" command on both entries.

   It
   CU.  In some cases it is important identical to note that scheduled components do not show up in
   busy time as BUSY.  Only when they are booked does the TRANSP:OPAQUE
   property take effect. CU's well known email
   address.  A CS implementation MAY mark the time as
   TENTATIVE.  This is CU's UPN MUST never be an implementation and administrative choice.

   The CS MAY automatically process some iTIP request.  For example a CS
   MAY automatically send out REFRESH replies via iMIP or CAP, then
   delete the REFRESH entry.  But only if there are no other pending
   scheduled entries for this calendar e-mail address that may affect what REFRESH
   would send back.  If  the CS is not able to reply
   deliverable to the REFRESH
   request then  it is left in the scheduling set until the CUA and CU
   processes the set.  At the point where a different person as there  are is no outstanding
   scheduled command requirement that  would effect a
   person's UPN must be his e-mail address.

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

6.3.3 iTIP Examples be used.

   Example:

   The following examples describe scenarios is a UPN for the handling of
   incoming iTIP data.  An appropriate sort-order a CU:

          jdoe@acme.com

   The following is a UPN for the handling a group of
   incoming iTIP CU:

          staff@acme.com

   The following is by UID, Recurrence-id, sequence, dtstamp.  This
   processing may be optimized, a UPN for instance, REFRESHs could be
   processed last.

   As an update anonymous CU belonging to [iTIP], data with the "COUNTER" method should be
   processed even if the Sequence number

          @acme.com

   The following is stale.

6.3.3.1 Sending and Receiving a UPN for an iTIP request

   In this example A invites B and C anonymous CU:

          @

11.1.2 UPN Filter

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME value type UPN-FILTER

   Value Name: UPN-FILTER

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

   Formal Definition: The value type is defined by the meeting
   and C rejects it. following
   notation:

        upn-filter    = "OWNER" /
                        "NONOWNER" /
                        "*" /
                        [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text )

                       ; dot-atom-text is defined in RFC 2822

   Description: The calendars for A, B and C are relcal1, relcal2
   and relcal3 respectively, and value is used to match user principal names (UPNs).

   Example: The following are examples of this value type:

       OWNER       Matches the UPNs equal to any instance
                   of the OWNER property of the VAGENDA in
                   which the encapsulating VCAR is stored.

       NONOWNER    Matches all on UPNs different from all
                   instances of the same server,
   "cal.example.com".  A lot OWNER property of these described actions are performed by the CUAs and not
                   VAGENDA in which the users themselves, encapsulating VCAR
                   is stored.

       *           Matches all UPNs.

       @           Matches the CUAs are called A-c, B-c
   and C-c respectively.

   A wishes UPN of anonymous CUs
                   belonging to create a meeting with B and C, so A-c uses CAP the null realm

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

       @realm      Matches the following iTIP request UPN of anonymous CUs
                   belonging to relcal2 and relcal3, while logged in the specified realm

       *@*         Matches the UPN of non-anonymous CUs
                   belonging to
   "cal.example.com".

   C: MSG 1 20 . 22254 874
   C: Content-Type: multipart/related; boundary="boundary-rewf4";
   C:    start="1@cal.example.com;
   C:    type="application/beep+xml"
   C:
   C: --boundary-rewf4
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <schedule id="xhj-dd"/>
   C:    <target relcalid="relcal3"/>
   C:    <target relcalid="relcal2"/>
   C:    <select>
   C:       <data content="cid:request@cal.example.com"/>
   C:    </select>
   C: </schedule>
   C: --boundary-rewf4
   C: Content-Type: text/calendar
   C: Content-ID: request@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: METHOD:REQUEST
   C: BEGIN:VEVENT
   C: UID:abcd12345
   C: DTSTART:19990307T180000Z
   C: DTEND:19990307T190000Z
   C: ORGANIZER:cap://cal.example.com/relcal1
   C: ATTENDEE;RSVP=TRUE;
   C:   PARTSTAT=NEEDS-ACTION:cap://cal.example.com/relcal2
   C: ATTENDEE;RSVP=TRUE;
   C:   PARTSTAT=NEEDS-ACTION:cap://cal.example.com/relcal3
   C: SUMMARY:Important Meeting
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-rewf4--
   C: END

   An incoming event (indicated by any non-null realm

       *@realm     Matches the value UPN of non-anonymous CUs
                   belonging to the "METHOD" property)
   then appears in relcal2 and relcal3, with specified realm

       user@realm  Matches the following data:

               BEGIN:VEVENT
               METHOD:REQUEST
               UID:abcd12345
               DTSTART:19990307T180000Z
               DTEND:19990307T190000Z
               ORGANIZER:cap://cal.example.com/relcal1
               ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.example.c
                om/relcal2
               ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.example.c
                om/relcal3
               SUMMARY:Important Meeting
               END:VEVENT

   B-c and C-c must search for such incoming events, they do so using UPN of the following CAP search:

   C: MSG 1 21 . 24655 631
   C: Content-Type: multipart/related; boundary="boundary-ytem";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-ytem
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com;
   C:
   C: <search id="xhr-de">
   C:   <max-time latency=60 action=ask/>
   C:   <select>
   C:     <source relcalid='relcal2'/>
   # or relcalid='relcal3'
   C:     <data content="cid:2@cal.example.com"/>
   C:   </select>
   C: </search>
   C: --boundary-ytem
   C: Content-Type: text/calendar
   C: Content-ID: 2@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST';
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-ytem--
   C: END

   In response specified CU
                   belonging to the specified realm

       user@*      Matches the UPN of the specified CU
                   belonging to this search they get any non-null realm

11.2 Calendar Components

11.2.1 Agenda Component

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME component VAGENDA

   Component Name: VAGENDA

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

   Formal Definition: A "VAGENDA" calendar component is defined by the above event.  B-c and C-c
   must then open
   following notation:

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

        agendaprop  = *(
                        ; the VEVENT, find following MUST occur exactly once

                        created / recalid / last-mod /

                        ; the UID following MUST occur at least once
                        owner /

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

                        allow-conflict / calscale / default-charset / default-locale /
                        method / default-tzid /

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

                        name / related / iana-token / x-prop / x-comp
                       )

   Example: The following is
   already an event on their calendar with that UID.  To do example of this they
   use component:

      BEGIN:VAGENDA
      CREATED:20020121T123149Z
      NAME:Work Calendar
      OWNER:john@example.calendar.com
      RECALID:lhdi98dey6
      LAST-MODIFIED:20020210T152301Z
      ALLOW-CONFLICT:FALSE
      METHOD:DELETE
      END:VAGENDA

11.2.2 Calendar Store Component

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME component VCALSTORE

   Component Name: VCALSTORE

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

   Formal Definition: A "VCALSTORE" calendar component is defined by the
   following search:

   C: MSG 1 22 . 26087 654
   C: Content-Type: multipart/related; boundary="boundary-rtylk";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-rtylk
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com;
   C:
   C: <search id="xhr-df">
   C:   <max-time latency=60 action=ask/>
   C:   <select>
   C:     <source relcalid='relcal2'/>
   # or relcalid='relcal3'
   C:     <data content="cid:2@cal.example.com"/>
   C:   </select>
   C: </search>
   C: --boundary-rtylk
   C: Content-Type: text/calendar
   C: Content-ID: 2@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE UID notation:

        calstorec     = 'abcd12345' AND
   C:  METHOD IS NULL
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-rtylk--
   C: END

   We assume that "BEGIN" ":" "VCALSTORE" CRLF
                        calstoreprop
                        "END" ":" "VCALSTORE" CRLF

        calstoreprop  = *(
                          ; the event is not already in their relcal2 or relcal3.

   B-c prompts B who decides to accept following MUST occur exactly once
                          calmaster / current-datetime /

                          ; the following must occur at least once

                          default-vcar /

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

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

                          ; the meeting request, following are optional,
                          ; and B-c
   creates a copy MAY occur more than once

                          iana-token / x-prop / x-comp / vcard
                         )

   Example: The following is an example of the event in relcal2, with the "PARTSTAT" parameter
   set to ACCEPTED.  B-c also sends this copy to the Organizer at
   relcal1 as an iTIP REPLY, preserving the CMDID:

   C: MSG 1 23 . 26741 697
   C: Content-Type: multipart/related; boundary="boundary-1943";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-1943
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com;
   C:
   C: <schedule id="xhj-dd">
   C:   <target relcalid="relcal1">
   C:   <data content="cid:2@cal.example.com"/>
   C: </schedule>
   C: --boundary-1943
   C: Content-Type: component:

      BEGIN:VCALSTORE
      CALMASTER:mailto:admin@example.calendar.com
      DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY
      DEFAULT-VCARS:UPDATEPARTSTATUS,DEFAULTOWNER
      CSID:example.calendar.com
      END:VCALSTORE

11.2.3 Calendar Access Right Component

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar
   C: Content-ID: 2@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: METHOD:REPLY
   C: BEGIN:VEVENT
   C: UID:abcd12345
   C: DTSTART:19990307T180000Z
   C: DTEND:19990307T190000Z
   C: ORGANIZER:cap://cal.example.com/relcal1
   C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/relcal2
   C: SUMMARY:Important Meeting
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-1943--
   C: END

   C, on MIME component VCAR

   Component Name: "VCAR"

   Purpose: Provide a grouping of calendar access rights.

   Format Definition: A "VCAR" calendar component is defined by the other hand, decides to decline
   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 meeting, following are OPTIONAL,
                ; and C-c sends MAY occur more than once

                name / x-prop / iana-prop
                )

   Description: A "VCAR" calendar component is a
   reply grouping of component
   properties, and "VRIGHT" calendar components, that represents access
   rights granted or denied to calendar users.

   The "CARID" property specifies the Organizer to that effect, as follows:

   C: MSG 1 24 . 27438 705
   C: Content-Type: multipart/related; boundary="boundary-oiudfc";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-oiudfc
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com;
   C:
   C: <schedule id="xhj-de">
   C:   <target relcalid="relcal1">
   C:   <data content="cid:2@cal.example.com"/>
   C: </schedule>
   C: --boundary-oiudfc
   C: Content-Type: text/calendar
   C: Content-ID: 2@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: METHOD:REPLY
   C: BEGIN:VEVENT
   C: UID:abcd12345
   C: DTSTART:19990307T180000Z
   C: DTEND:19990307T190000Z
   C: ORGANIZER:cap://cal.example.com/relcal1
   C: ATTENDEE;PARTSTAT=DECLINED:cap://cal.example.com/relcal3
   C: SUMMARY:Important Meeting
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-oiudfc--
   C: END

   It is preferable that C-c stores local identifier for the "VCAR"
   calendar component.  The "NAME" property specifies a localizable
   display name.

   Example: In the event in relcal3 even though it
   has been declined.  Storing following example, the event in relcal3 allows subsequent
   iTIP messages UPN "foo@host.com" is given
   read access to be interpreted correctly.  The "PARTSTAT" parameter
   indicates that the event was refused.

   After receiving the replies from relcal2 "DTSTART" and relcal3, A-c updates the
   version "DTEND" VEVENT properties.  No other
   access is specified:

        BEGIN:VCAR
        CARID:xyzzy-001
        NAME:View Start and End Times
        BEGIN:VRIGHT
        GRANT:foo@host.com
        PERMISSION:READ
        SCOPE:SELECT DTSTART,DTEND FROM VEVENT
        END:VRIGHT
        END:VCAR

   In this example, all UPNs are given read access to "DTSTART" and
   "DTEND" properties of VEVENT components.  "All CUs and UGs" are
   specified by the event UPN value "*".  Note that this enumerated UPN value
   is not in relcal1 quotes:

        BEGIN:VCAR
        CARID:xyzzy-002
        NAME:View Start and End Times 2
        BEGIN:VRIGHT
        GRANT:*
        PERMISSION:READ
        SCOPE:SELECT DTSTART,DTEND FROM VEVENT
        END:VRIGHT
        END:VCAR
   In this example, rights are specified for all UPNs to read VEVENT
   components classified as PUBLIC:

        BEGIN:VCAR
        CARID:xyzzy-003
        NAME:View PUBLIC Start and End Times
        BEGIN:VRIGHT
        GRANT:*
        PERMISSION:READ
        SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC'
        END:VRIGHT
        END:VCAR

   In this example, rights are specified for all UPNs to read or modify
   existing VEVENT components classified as PUBLIC:

        BEGIN:VCAR
        CARID:xyzzy-004
        NAME:Read and Modify PUBLIC Calendar Entries
        BEGIN:VRIGHT
        GRANT:*
        PERMISSION:READ
        PERMISSION:MODIFY
        SCOPE:SELECT * FROM VEVENT WHERE CLASS = 'PUBLIC'
        END:VRIGHT
        END:VCAR

   In these examples, full calendar access rights are given to indicate the new participation
   status:

   C: MSG 1 25 . 29450 934
   C: Content-Type: multipart/related; boundary="boundary-wer3";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-wer3
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.cal.example.com
   C:
   C: <modify id="modify01"/>
   C:    <select>
   C:       <source relcalid="relcal1"/>
   C:       <data content="cid:query@cal.example.com"/>
   C:    </select>
   C:    <update remove-missing=false>
   C:       <data content="cid:update@cal.example.com"/>
   C:    </update>
   C: </modify>
   C: --boundary-wer3
   C: Content-Type: text/calendar
   C: Content-ID: query@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VQUERY
   C: QUERY: SELECT
   OWNER, 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:xyzzy-005
        NAME:Only OWNER or ADMIN Settable CARs
        BEGIN:VRIGHT
        GRANT:OWNER
        PERMISSION:*
        SCOPE:SELECT * FROM VAGENDA
        END:VRIGHT
        BEGIN:VRIGHT
        GRANT:cal-admin@host.com
        PERMISSION:*
        SCOPE:SELECT * FROM VCAR
        RESTRICTION:SELECT * FROM VCAR
        END:VRIGHT
        END:VCAR
   In this example, rights to write, read, modify or delete calendar
   access rights are denied to all UPNs.  This example would disable
   providing different access rights to the calendar store or calendar.
   This calendar access right should be specified with great care, as it
   remove the ability to change calendar access; even for the owner or
   administrator:

        BEGIN:VCAR
        CARID:xyzzy-006
        NAME:No CAR At All
        BEGIN:VRIGHT
        DENY:*
        PERMISSION:*
        SCOPE:SELECT * FROM VEVENT WHERE UID='abcd12345'
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-wer3
   C: Content-Type: VCAR
        END:VRIGHT
        END:VCAR

11.2.4 VRIGHT Calendar Component

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar
   C: Content-ID: update@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VEVENT
   C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/relcal2
   C: ATTENDEE;PARTSTAT=DECLINED:cap://cal.example.com/relcal3
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-wer3--
   C: END

   A-c then sends MIME component VRIGHT

   Component Name: "VRIGHT"

   Purpose: Provide a new iTIP request to relcal2 only, indicating the
   updated information.

6.3.3.2 Handling grouping of component properties that describe an iTIP refresh
   access right.

   Format Definition: A little bit later, C "VRIGHT" calendar component is thinking about accepting the event in defined by the
   previous example, but first wants to check
   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 current state following are optional,
                  ; and MAY occur more than once

                  scope / restriction / x-prop / iana-prop

                  )

   Description: A "VRIGHT" calendar component is a grouping of calendar
   access right component properties.

   The "GRANT" property specifies the
   event.  To find CU or UG to whom a calendar access
   right is granted.  The "DENY" property specifies the current state C-c uses CU or UG to whom
   a calendar access right is denied.  The "PERMISSION" property
   specifies the iTIP "REFRESH" method,
   sending actual permission being set.  The "SCOPE" property
   identifies the following to relcal1:

   C: MSG 1 26 . 31005 649
   C: Content-Type: multipart/related; boundary="boundary-fsdk3";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-fsdk3
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <schedule id="xud-pn"/>
   C:    <target relcalid="relcal1"/>
   C:    <data content="cid:refresh@cal.example.com"/>
   C: </schedule>
   C: --boundary-fsdk3
   C: Content-Type: text/calendar
   C: Content-ID: refresh@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: METHOD:REFRESH
   C: BEGIN:VEVENT
   C: UID:abcd12345
   C: ORGANIZER:cap://cal.example.com/relcal1
   C: ATTENDEE:cap://cal.example.com/relcal3
   C: DTSTAMP:19990306T202333Z
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-fsdk3--
   C: END

   A-c finds calendar store properties, calendar properties,
   calendar components, component properties to which the refresh as an incoming iTIP, access right
   applies.  The "RESTRICTION" property specifies restriction on the
   value that may take calendar store properties, calendar properties,
   calendar components, and searches for component properties after a WRITE or MODIFY
   operation.  Values MUST match all the
   corresponding event.  Having found instances of the event (with no changes since RESTRICTION
   property to be valid.

11.3 Component Properties

   The following properties can appear within calendar components, as
   specified by each component property definition.

11.3.1 Allow-Conflict Component Property

   To: ietf-calendar@imc.org

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

   Property Name: ALLOW-CONFLICT

   Purpose: This property indicates whether or not the last example) A-c then verifies that relcal3 is in fact an
   attendee calendar supports
   component conflicts.  That is, whether or not any of the event and 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" calendar
   component.

   Description: In a "VAGENDA", this property is thus allowed used to request a refresh.  (In indicate
   whether components may conflict.  That is, if their expanded
   instances may share the case of same time or overlap the same time periods.
   If it has a published event things value of TRUE, then conflicts are more complicated.) A-c
   packages allowed.  If FALSE, the event as an iTIP request and sends it to relcal3:

   C: MSG 1 27 . 32541 856
   C: Content-Type: multipart/related; boundary="boundary-trekvg";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-trekvg
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <schedule id="xud-pn"/>
   C:    <target relcalid="relcal3"/>
   C:    <data content="cid:request@cal.example.com"/>
   C: </schedule>
   C: --boundary-trekvg
   C: Content-Type: text/calendar
   C: Content-ID: request@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: METHOD:REQUEST
   C: TARGET:cap://cal.example.com/relcal3
   C: BEGIN:VEVENT
   C: UID:abcd12345
   C: DTSTART:19990307T180000Z
   C: DTEND:19990307T190000Z
   C: ORGANIZER:cap://cal.example.com/relcal1
   C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/relcal2
   C: ATTENDEE;PARTSTAT=DECLINED:cap://cal.example.com/relcal3
   C: SUMMARY:Important Meeting
   C: SEQUENCE:0
   C: DTSTAMP:19990306T204333Z
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-trekvg--
   C: END

6.3.3.3 Sending and accepting an iTIP counter

   Having received
   no two components may conflict.

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

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

        allowconflictvalue  = *(";" xparam)

   Example: The following is an example of the event C wishes to propose this property for a
   venue "VAGENDA"
   calendar component:

        ALLOW-CONFLICT:FALSE

11.3.2 Charset Component Property

   To: ietf-calendar@imc.org

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

   Property Name: DEFAULT-CHARSET

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

   Value Type: TEXT

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

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

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

   Format Definition: The property is defined by the following to relcal1:

   C: MSG 1 28 . 34587 883
   C: Content-Type: multipart/related; boundary="boundary-werf";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-werf
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <schedule id="zzykjjk"/>
   C:    <target relcalid="relcal1"/>
   C:    <data content="cid:counter@cal.example.com"/>
   C: </schedule>
   C: --boundary-werf
   C: Content-Type: notation:

        default-charset     = "DEFAULT-CHARSET" default-charsetparam ":" text CRLF

        default-charsetparam  = *(";" xparam)
   Example: The following is an example of this property for a "VAGENDA"
   calendar component:

        DEFAULT-CHARSET:Shift_JIS

11.3.3 Default Locale Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar
   C: Content-ID: counter@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: METHOD:COUNTER
   C: BEGIN:VEVENT
   C: UID:abcd12345
   C: DTSTART:19990307T180000Z
   C: DTEND:19990307T190000Z
   C: SEQUENCE:0
   C: ORGANIZER:cap://cal.example.com/relcal1
   C: ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/relcal2
   C: ATTENDEE;PARTSTAT=DECLINED:cap://cal.example.com/relcal3
   C: SUMMARY:Important Meeting
   C: LOCATION:La Belle Province
   C: COMMENT:My favorite restaurant, I'll definitely go if it's
   C:   there.
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-werf--
   C: END

   Having sent MIME property DEFAULT-LOCALE

   Property Name: DEFAULT-LOCALE

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

   Value Type: TEXT

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

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

   Description: In a "VAGENDA", this property is used to relcal1, C-c shouldn't store indicate the new
   details
   default locale for values in relcal3.  If C-c updated the version in relcal3 components, e.g., "VEVENT", of the
   "VAGENDA." The full locale SHOULD be used.  The default and
   relcal1 did minimum
   locale is POSIX, if not reply to supplied in the counter, then relcal3 would have
   incorrect information.  Instead C-c preserves UTF-8 charset as defined in
   RFC 2277.

   Format Definition: The property is defined by the correct information
   and waits for following notation:

        default-locale     = "DEFAULT-LOCALE" default-localeparam ":" language CRLF

        default-localeparam  = *(";" xparam)

        default-locale = Text identifying a response from relcal1.  A CUA implementation may wish
   to preserve locale, as defined in [RFC 2277]

   Example: The following is an example of this information itself, externally to property:

        DEFAULT-LOCALE:en-US.iso-8859-1

11.3.4 Default Time Zone Property

   Property Name: DEFAULT-TZID
   Purpose: This property specifies the CS.

   In order to receive an iTIP counter A-c follows text value that specifies the same search as
   default time zone for other iTIP data, first find the incoming message, next find any
   matching events a calendar.

   Value Type: TEXT

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

   Conformance: This property may be specified once in the a "VAGENDA"
   calendar store.

   Having found component.

   Description: This is the matching event, A reviews label by which the proposed changes default time zone for a
   calendar is specified.  The default is used for all TIME and
   decides to accept DATE-
   TIME properties, in the COUNTER.  To calendar, that do this, A-c modifies the version not have a timezone nor are
   in relcal1 (bumping UTC.  The presence of the sequence number) to:

   C: MSG 1 29 . 37650 850
   C: Content-Type: multipart/related; boundary="boundary-kmcrf";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-kmcrf
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.cal.example.com
   C:
   C: <modify id="asdf123"/>
   C:    <select>
   C:       <source relcalid="relcal1"/>
   C:       <data content="cid:query@cal.example.com"/>
   C:    </select>
   C:    <update remove-missing=false>
   C:       <data content="cid:update@cal.example.com"/>
   C:    </update>
   C: </modify>
   C: --boundary-kmcrf
   C: Content-Type: text/calendar
   C: Content-ID: query@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VQUERY
   C: QUERY: SELECT * FROM VEVENT WHERE UID='abcd12345'
   C: END:VQUERY
   C: END:VCALENDAR
   C: --boundary-kmcrf
   C: Content-Type: text/calendar
   C: Content-ID: update@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: BEGIN:VEVENT
   C: LOCATION:La Belle Province
   C: SEQUENCE:1
   C: END:VCALENDAR
   C: --boundary-kmcrf--
   C: END

   A-c then sends SOLIDUS character (US-ASCII decimal 47)
   as a prefix, indicates that this TZID represents an unique ID in a
   globally defined time zone registry (when such registry is defined).

   Format Definition: This property is defined by the updated version as following
   notation:

        default-tzid       = "DEFAULT-TZID" default-tzidpropparam ":" [tzidprefix] text CRLF

        default-tzidpropparam      = *(";" xparam)

   Example: The following is an example of this property:

        DEFAULT-TZID:US-Eastern

11.3.5 Owner Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME property OWNER

   Property Name: OWNER

   Purpose: The property specifies an owner of a request to both relcal2 calendar.

   Value Type: UPN

   Property Parameters: Non-standard, alternate text representation and
   relcal3:

   C: MSG 1 30 . 39450 909
   C: Content-Type: multipart/related; boundary="boundary-plmng";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-plmng
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <schedule id="xup-po"/>
   C:    <target relcalid="relcal2"/>
   C:    <target relcalid="relcal3"/>
   C:    <data content="cid:request@cal.example.com"/>
   C: </schedule>
   C: --boundary-plmng
   C: Content-Type:
   language property parameters can be specified on this property.

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

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

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

        owner = "OWNER" ownerparam ":" upn CRLF

        ownerparam = *(";" xparam)

   Example: The following is an example of this property:

      OWNER:jsmith@acme.com
      OWNER:jdoe@acme.com

11.3.6 Relative Calendar Identifier Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar
   C: Content-ID: request@cal.example.com
   C:

   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: METHOD:REQUEST
   C: BEGIN:VEVENT
   C: UID:abcd12345
   C: DTSTART:19990307T180000Z
   C: DTEND:19990307T190000Z
   C: ORGANIZER:cap://cal.example.com/relcal1
   C: ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
   C:  ACTION:cap://cal.example.com/relcal2
   C: ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
   C:  ACTION:cap://cal.example.com/relcal3
   C: SUMMARY:Important Meeting
   C: LOCATION:La Belle Province
   C: SEQUENCE:1
   C: DTSTAMP:19990307T054339Z
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-plmng--
   C: END

6.3.3.4 Declining MIME property RELCALID

   Property Name: RELCALID

   Purpose: The property specifies an iTIP counter

   B does not like identifier for a "VAGENDA." It
   must be unique within the new location CS.

   Value Type: URI

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

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

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

   Format Definition: The property is defined by the event, B-c
   sends following notation:

        recalidprop = "RELCALID" recalidparam ":" relcalid CRLF

        [EDITORS NOTE: recalid is defined in Bernard's proposition for the definition of a CAP URL]

        recalidparam = *(";" xparam)

   Example: The following iTIP:

   C: MSG 1 31 . 41620 762
   C: Content-Type: multipart/related; boundary="boundary-cafe3";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-cafe3
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <schedule id="xim-ef"/>
   C:    <target relcalid="relcal1"/>
   C:    <data content="cid:counter@cal.example.com"/>
   C: </schedule>
   C: --boundary-cafe3
   C: Content-Type: is an example of this property:

      RELCALID:hjik123A001

11.3.7 Calendar Store Component Properties

11.3.7.1 Calmaster Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar
   C: Content-ID: counter@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: METHOD:COUNTER
   C: BEGIN:VEVENT
   C: UID:abcd12345
   C: DTSTART:19990307T180000Z
   C: DTEND:19990307T190000Z
   C: ORGANIZER:cap://cal.example.com/relcal1
   C: ATTENDEE:cap://cal.example.com/relcal2
   C: ATTENDEE:cap://cal.example.com/relcal3
   C: SUMMARY:Important Meeting
   C: LOCATION:Guy et Dodo
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-cafe3--
   C: END

   However, C does not accept MIME property CALMASTER

   Property Name: CALMASTER

   Purpose: The property specifies an e-mail address of a person
   responsible for the counter, and C-c replies with 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
   decline counter:

   C: MSG 1 32 . 42901 631
   C: Content-Type: multipart/related; boundary="boundary-meme34";
   C:    start="1@cal.example.com";
   C:    type="application/beep+xml"
   C:
   C: --boundary-meme34
   C: Content-Type: application/beep+xml
   C: Content-ID: 1@cal.example.com
   C:
   C: <schedule id="xim-ef"/>
   C:    <target relcalid="relcal2"/>
   C:    <data content="cid:decline-counter@cal.example.com"/>
   C: </schedule>
   C: --boundary-meme34
   C: Content-Type: "VCALSTORE"
   component.

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

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

        calmaster = "CALMASTER" calmasterparam ":" uri CRLF

        calmasterparam = *(";" xparam)

        uri = as defined by RFC 2445

   Example: The following is an example of this property:

      CALMASTER:mailto:administrator@acme.com

11.3.7.2 Calendar Store Identifier Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar
   C: Content-ID: decline-counter@cal.example.com
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.1
   C: METHOD:DECLINE-COUNTER
   C: BEGIN:VEVENT
   C: DTSTAMP:19990307T093245Z
   C: UID:abcd12345
   C: ORGANIZER:cap://cal.example.com/relcal1
   C: SEQUENCE:1
   C: END:VEVENT
   C: END:VCALENDAR
   C: --boundary-meme34--
   C: END

   CUA-b MIME property CSID

   Property Name: CSID

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

   Value Type: URI

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

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

   Description: The identifier MUST keep be globally unique.  If not
   specified, it is the original  information when sending same as the counter,
   and there hostname.

   Format Definition: The property is no problem when no information defined by the following notation:

        csid = "CSID" csidparam ":" capurl CRLF

        [EDITORS NOTE: capurl is returned defined in Bernard's proposition for the
   DECLINE-COUNTER.

7. Response Codes

   Numeric response codes are returned definition of a CAP URL]

        csidparam = *(";" xparam)

   Example: The following is an example of this property:

      CSID:cap://calendar.acme.com

11.3.7.3 Default Access Rights Component Property

   To: ietf-calendar@imc.org

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

   Property Name: DEFAULT-VCARS

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

   Value Type: TEXT

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

   Conformance: This property MUST be specified in "VCALSTORE" calendar
   component and MUST at both least specify the transfer following values:
   READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and
   application layer.  The same set of codes DEFAULTOWNER.

   Description: This property is used in both cases.

   [EDITORS NOTE: Do we want the "VCALSTORE" calendar
   component to use specify the same set CARID of the VCAR components that must be
   copied in VAGENDA at creation time.

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

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

        def-vcarsparam = *( ";" xparam )

   Example: The following is an example of this property:

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

11.3.7.4 Maximum Date Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of codes?] text/calendar MIME property MAXDATE

   Property Name: MAXDATE

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

   Value Type: DATE-TIME

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

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

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

   Format Definition: The format of these codes property is described in [iCAL], and extend in
   [iTIP] and [iMIP]. defined by the following notation:

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

        maxdateparam  = *(";" xparam)

   Example: The following describes new codes added to is an example of this
   set.

   At property:

        MAXDATE:20990101T000000Z

11.3.7.5 Minimum Date Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME property MINDATE

   Property Name: MINDATE

   Purpose: This property specifies the application layer response codes are returned as date/time in the value of
   a "REQUEST-STATUS" 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 value type of this property is
   modified from that defined can be specified once in [iCAL], to make the accompanying text
   optional.

             Code              Description
             --------------------------------------------------------------
             2.0               Success. "VCALSTORE".

   Description: The parameters vary with the
                               operation date and are specified.

             2.0.3             In response to time MUST be a UTC value.  If not
   specified, then 00000101T000000Z will be assumed.

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

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

        mindateparam  = *(";" xparam)

   Example: The following is an
                               "abort" reply, example of this reply code indicates
                               that any command currently underway was
                               successfully aborted.

             3.1.4             Capability not supported.

             4.1               Calendar store access denied.

             6.3               Attempt to create or modify an event
                               such that it would overlap another event
                               in either property:

        MINDATE:19710101T000000Z

11.3.8 Descriptive Component Properties

   The following properties specify descriptive information about
   calendar components.

11.3.8.1 REQUEST-STATUS property

   This description is a revision of the REQUEST-STATUS property for
   VCALENDAR version 2.1.

     rstatus  = "REQUEST-STATUS" rstatparam ":"
       statcode [";" statdesc [";" extdata]]

     rstatparam  = *(
      ; the following two circum-
                               stances:

                               (a) One of is optional,
      ; but MUST NOT occur more than once
        (";" languageparm) /

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

      (";" xparam)

      )

     statcode  = 1*DIGIT *("." 1*DIGIT)
      ;Hierarchical, numeric return status code

     statdesc  = text
      ;An optional textual status description, content is
      ;decided by the implementor. May be empty.

     extdata  = text
      ;Textual exception data. For example, the events has a TRANSP offending property set to OPAQUE-NOCONFLICT
      ;name and value or
                               TRANSPARENT-NOCONFLICT.

                               (b) The calendar's ALLOW-CONFLICT complete property is set to NO.

             6.XXX             [EDITORS NOTE: More line.

   Example: The following are in some possible examples of this memo -
                               add here TODO]

             7.0               A timeout has occurred. property.
   The server was
                               unable to complete the operation in the
                               requested time.

             8.0               A failure has occurred in the Calendar Service
                               that prevents the operation from
                               succeeding.

             8.2               Used to signal that an iCalendar object has
                               exceeded the server's size limit

             8.3               A DATETIME value was too far COMMA and SEMICOLON separator characters in the future
                               represented on this Calendar.

             8.4               A DATETIME property value was too far
   are BACKSLASH character escaped because they appear in the past
                               to be represented on this Calendar.

             8.5               An attempt was made to create a new
                               object but the unique id text value.

    REQUEST-STATUS:2.0;Success

    REQUEST-STATUS:2.0;Success despite braindead LDAP implementation

    REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01

    REQUEST-STATUS:2.8; Success, repeating event ignored. Scheduled
    as a single event.;RRULE:FREQ=WEEKLY;INTERVAL=2

    REQUEST-STATUS:4.1;Event conflict. Date/time is busy.

    REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
    MAILTO:jsmith@host.com

    REQUEST-STATUS:3.7;;ATTENDEE:MAILTO:jsmith@host.com

    REQUEST-STATUS:10.4;Help! That really shouldnt have happened.

11.3.8.2 CALID Property Parameter

   Property Name: CALID
   Property Parameters: none

   Conformance: This property can be specified is
                               already in use.

             9.0               An unrecognized command was received.

             10.4              The operation has not been performed
                               because it would cause the resources
                               (memory, disk, CPU, etc) "VCAP"

   Description: This property is used to exceed specify a fully qualified
   calid.

   Format Definition: The property is defined by the
                               allocated quota.
             --------------------------------------------------------------

8. BEEP Profile Registration

      Profile Identification:
      http://iana.org/beep/transient/calsch/cap/1.0

      Messages exchanged during Channel Creation: none

      Messages starting one-to-one exchanges:

         "timeout", "generate-uid", "identify", "get-capability"

      Messages in positive replies:

         "uid-list", "abort", "continue", "result", "capability"

      Messages in negative replies:

         "error"

      Messages in one-to-many exchanges: "create", "search", "delete",
      "modify" following notation:

     CALID   = "DENY" ":" calid CRLF

   Example:

     CALID:cap://cal.example.com/sdfifgty4321

11.3.8.3 Time Transparency

   Property Name: TRANSP

   Purpose: This property defines whether an event is transparent or "schedule"

      Message Syntax: c.f., Section 9

      Message Semantics: c.f., Section 6

      Contact Information: c.f., not
   to busy time searches.

   Value Type: TEXT

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

   Conformance: This property can be specified once in a "VEVENT"
   calendar component.

   Description: Time Transparency is the "Author's Address" section characteristic of this
      memo

9. CAP DTD

   <!--
     DTD an event that
   determines whether it appears to consume time on a calendar.  Events
   that consume actual time for CAP commands and responses.
   -->

   <!ENTITY % CAP PUBLIC "-//IETF/DTD CAP//EN" "">
   %CAP;

   <!--
     DTD data types:

         entity      syntax/reference        example
         ======      ================        =======
         UPN         c.f. UPN Section 1.3    mary@cal.example.com
         CMDID       string                  read_12321
         SECONDS     1..2147483647           60
         CODE        1*DIGIT *("." 1*DIGIT)  2.0
         COUNT       1..32768                1
         CSID        c.f. CSID Section 1.3   cap://cap.example.com:5229
         DEPTH       '*' | 1..2147483647     1
   -->

   <!ENTITY % UPN       "CDATA">
   <!ENTITY % CMDID     "CDATA">
   <!ENTITY % SECONDS   "CDATA">
   <!ENTITY % CODE      "CDATA">
   <!ENTITY % COUNT     "CDATA">
   <!ENTITY % RELCALID  "CDATA">
   <!ENTITY % CSID      "CDATA">
   <!ENTITY % DEPTH     "CDATA">

   <!ELEMENT create (max-time?,target+,data)>
   <!ATTLIST create id %CMDID; #IMPLIED>

   <!ELEMENT search (max-time?,select,max-results?)>
   <!ATTLIST search id %CMDID; #IMPLIED>

   <!ELEMENT max-size (#PCDATA)>
   <!ELEMENT max-results (#PCDATA)>

   <!ELEMENT delete (max-time?,select)>
   <!ATTLIST delete id %CMDID; #IMPLIED>

   <!ATTLIST modify (max-time?,select,add,delete,update)>
   <!ATTLIST modify id %CMDID; #IMPLIED>

   <!ELEMENT itip (max-time?,data)>
   <!ATTLIST itip id %CMDID; #IMPLIED>

   <!ELEMENT target EMPTY>
   <!ATTLIST target relcalid %RELCALID; #IMPLIED
                    csid     %RELCALID; #IMPLIED>

   <!ELEMENT max-time EMPTY>
   <!ATTLIST max-time latency %SECONDS; #REQUIRED>
                      action (ask|abort) "abort">

   <!ELEMENT data EMPTY>
   <!ATTLIST data content %URI; #REQUIRED>

   <!ELEMENT select (data,source+)>

   <!ELEMENT source EMPTY>
   <!ATTLIST source relcalid %RELCALID; #IMPLIED
                    csid     %CALID;    #IMPLIED
                    depth    %DEPTH;    "0">

   <!ELEMENT remove (data)>
   <!ATTLIST remove ignore-value (true|false) "false">

   <!ELEMENT update (data)>
   <!ATTLIST update remove-missing (true|false) "false">

   <!ELEMENT generate-uid EMPTY>
   <!ATTLIST generate-uid num %COUNT; '1'>

   <!ELEMENT uid-list (uid*)>
   <!ELEMENT uid (#PCDATA)>

   <!ELEMENT identify EMPTY>
   <!ATTLIST identify upn %UPN; #REQUIRED>

   <!ELEMENT timeout EMPTY>
   <!ATTLIST timeout id %CMDID; #IMPLIED>

   <!ELEMENT abort EMPTY>
   <!ELEMENT continue (timeout?)>

   <!ELEMENT get-capability EMPTY>

   <!ELEMENT capability (cap,itip,icalendar,date?)>
   <!ELEMENT version (#PCDATA)>

   <!ELEMENT icalendar (version,max-component-size?)>
   <!ELEMENT max-component-size (#PCDATA)>
   <!ELEMENT query-level (#PCDATA)>

   <!ELEMENT itip (version)>

   <!ELEMENT cap (version,query-level,car?)>

   <!ELEMENT car (#PCDATA)>
   <!ELEMENT query-level (#PCDATA)>

   <!ELEMENT date (max?,min?)>
   <!ELEMENT min (#PCDATA)>
   <!ELEMENT max (#PCDATA)>

   <!ELEMENT result (data?,target?,source?,request-status)>
   <!ATTLIST result id   %CMDID; #IMPLIED>

   <!ELEMENT request-status (#PCDATA)>
   <!ATTLIST request-status code %CODE; #REQUIRED>

   <!ELEMENT error (request-status)>

10. Implementation Issues

   1.  What are the minimum component properties set required individual or resource associated
   with the calendar SHOULD be recorded as OPAQUE, allowing them to create
   a new VEVENT, VTODO and VJOURNAL?.  PROPOSAL: DTSTART, SUMMARY and
   UID.

   [EDITORS NOTE (dr): They MUST be
   detected by free-busy time searches.  Other events, which do not take
   up the same individual's (or resource's) time SHOULD be recorded as
   TRANSPARENT, making them invisible to free-busy time searches.

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

     transp   = "TRANSP" tranparam ":" transvalue CRLF

     tranparam   = *(";" xparam)

     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 event
                  ; can overlap it.

                  / "OPAQUE-NOCONFLICT"  ; Opaque on busy time
                  ; searches and no other OPAQUE
                  ; or OPAQUE-NOCONFLICT event
                  ; can overlap it.
                  ;
                  ;Default value is OPAQUE

   Example: The following is an example of this property for iTIP]

   2.  What an event
   that is the state transparent or does not block on free/busy time searches:

      TRANSP:TRANSPARENT

   The following is an example of all undefined properties? PROPOSAL: Not
   defined.  So this property for an event that is
   opaque or blocks on free/busy time searches:

      TRANSP:OPAQUE

   The following is an example of this property for an event that is
   opaque or blocks on free/busy time searches plus no other event can
   overlap it:

      TRANSP:OPAQUE-NOCONFLICT

11.3.8.4 Name Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME property NAME

   Property Name: NAME

   Purpose: This property provides a query will not return them, if they are selected.

   [EDITORS NOTE (dr): Many have default values, localizable display name for a CS may return the
   default values?]

11. Properties

   [EDITORS NOTE: These extensions/changes to iCalendar need to
   calendar component.

   Value Type: TEXT

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

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

   Description: This property is used in the IANA registration process defined "VAGENDA" and in
   section 7 the "VCAR"
   calendar components to specify a localizable display name.

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

        name = "NAME" nameparam ":" text CRLF

        nameparam = *(
                       ; the following is optional,
                       ; but MUST NOT occur more than once

                       ( ";" languageparam ) /

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

                       ( ";" xparam )
                     )

   Example: The following is an example of [iCAL].]

11.1 this property:

        NAME:Restrict Guests From Creating ALARMs On Events

11.3.9 Calendar Store Access Right Component Properties

   The following are properties

11.3.9.1 VCAR Identifier Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME property CARID

   Property Name: CARID

   Purpose: This property specifies the identifier for an access right
   calendar store.

             Name           Read component.

   Value     Description
                            Only  Type
             --------------------------------------------------------------
             CALMASTER      N     URI       The e-mail address for a
                                            responsible person. Type: TEXT

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

   Conformance: This property MUST be specified once in a
                                            mailto URL.

             CSID           Y     URI       The CSID of this "VCAR"
   calendar
                                            store. If not specified, it is
                                            the same as the hostname.

             DEFAULT_VCARS  N     TEXT      A multivalued component.

   Description: This property
                                            containing the default VCARs
                                            for newly created top level
                                            calendars. Each entry is a
                                            CARID. It MUST include at a
                                            minimum
                                            READBUSYTIMEINFO,REQUESTONLY,
                                            UPDATEPARTSTATUS, and
                                            DEFAULTOWNER.

             MAXDATE        Y     DATE-TIME The date/time in the future
                                            beyond which the server cannot
                                            represent. If not specified,
                                            then 99991231T235959 will be
                                            assumed.

             MINDATE        Y     DATE-TIME The date/time used in the past prior "VCAR" calendar component
   to which specify an identifier.

   Format Definition: The property is defined by the server cannot
                                            represent. If not specified,
                                            then 00000101T000000 will be
                                            assumed.

             CURRENT_DATETIME  Y  DATE-TIME Current server time. following notation:

        carid      = "CARID" caridparam ":" text CRLF

        caridparam = *( ";" xparam )

   Example: The following is an example of this property:

        CARID:xyzzy-007

11.3.9.2 VCAR Decreed Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME property DECREED

   Property Name: DECREED

   Purpose: This property specifies if an access right calendar
   component is
                                            returned as a local time and
                                            TZID.

             RECUR_ACCEPTED  Y decreed or not.

   Value Type: BOOLEAN   Boolean value will be set to
                                            TRUE if the server will accept
                                            recurrence rules. It will

   Property Parameters: Non-standard property parameters can be
                                            set to FALSE if the server will
                                            not accept recurrence rules. If
                                            not
   specified a CUA MUST assume
                                            TRUE.

             RECUR_EXPAND   Y     BOOLEAN   If set to TRUE, the CS supports
                                            the expansion of recurrence
                                            rules. If set to FALSE, the CS
                                            is incapable of expanding
                                            recurrence rules. If not on this property.

   Conformance: This property MAY be specified a CUA MUST assume
                                            TRUE.

             RECUR_LIMIT    Y   INTEGER once in a "VCAR" calendar
   component.

   Description: This numeric value describes
                                            how the server handles
                                            unbounded recurrences. The
                                            value is only valid if
                                            RECURRENCE property is TRUE. If used in the
                                            value is 0 it means that "VCAR" calendar component
   to specify whether the
                                            server supports unbounded
                                            recurrence rules. If it component is non-
                                            zero, it decreed or not.

   Format Definition: The property is a positive integer
                                            indicating the number of
                                            instances that will be created
                                            when defined by the server expands following notation:

        decreed      = "DECREED" decreedparam ":" boolean CRLF

        decreedparam = *( ";" xparam )

   Example: The following is an
                                            unbounded recurrence rule when
                                            fetched from the CS. A CUA MUST
                                            query for date ranges when example of this
                                            value is zero.

             VERSION        Y   TEXT        The version property:

        DECREED:TRUE

11.3.10 Right Component Properties

11.3.10.1 Grant Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME property GRANT

   Property Name: GRANT

   Purpose: This property identifies the CS. The
                                            default and the only currently
                                            Supported version is "2.0" to
                                            match UPN(s) being granted access in
   the [iCAL] VERSION.

11.2 Calendar Properties

             Name           Read VRIGHT component.

   Value     Description Type: UPN-FILTER

   Property Parameters: Only  Type
             --------------------------------------------------------------
             ALLOW-CONFLICT  N    BOOLEAN non-standard property parameters can be
   specified on this property.

   Conformance: This boolean value indicates
                                            Whether or not property can be specified in "VRIGHT" calendar
   components.

   Description: This property is used in the "VRIGHT" calendar
                                            supports event conflicts. That
                                            is, whether component
   to specify the CU or not any UG being granted access.

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

        grant     = "GRANT" grantparam ":" upn-filter CRLF

        grantparam  = *( ";" xparam )

   Example: The following are examples of this property:

        GRANT:*

        GRANT:bob@example.com

11.3.10.2 Deny Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME property DENY

   Property Name: DENY

   Purpose: This property identifies the
                                            events UPN(s) being denied access in
   the calendar can
                                            overlap. If not VRIGHT component.

   Value Type: UPN-FILTER
   Property Parameters: Only non-standard property parameters can be
   specified the
                                            default value is TRUE meaning
                                            that conflicts are allowed.

             CALSCALE        N    TEXT      The CALSCALE for on this calendar.
                                            If not property.

   Conformance: This property can be specified the default in "VRIGHT" calendar
   components.

   Description: This property is
                                            GREGORIAN.

             CHARSET         N    TEXT      The default charset for
                                            Localized strings used in this
                                            calendar. If not specified, the
                                            default "VRIGHT" calendar component
   to define the CU or UG being denied access.

   Format Definition: The property is UTF-8.

             CHILDREN        Y    TEXT defined by the following notation:

        deny       = "DENY" denyparam ":" upn-filter CRLF

        denyparam  = *( ";" xparam )

   Example: The list following are examples of sub-calendars
                                            Belonging to this calendar. An
                                            empty list means no children.
                                            The results may be a comma
                                            separated list property:

        DENY:*

        DENY:bob@example.com

11.3.10.3 Permission Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of children.
                                            Each entry returned is text/calendar MIME property PERMISSION

   Property Name: PERMISSION

   Purpose: This property defines a CALID.
                                            The default permission that is an empty list.

             CREATED         Y    DATE-TIME The timestamp of the calendar's
                                            create date.

             DEFAULT_VCARS   N granted or denied
   in a VRIGHT component.

   Value Type: TEXT      The default VCARs for newly
                                            Created top level calendars.

   Property Parameters: Only 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" calendar component
   to define a CARID. permission that is granted or denied.

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

        perm      = "PERMISSION" permparam ":" permvalue CRLF
        permparam = *( ";" xparam )

        permvalue = ( "READ" / "WRITE" / "DELETE" / "MODIFY" / all )

        all         = "*"

   Example: The following is an example of
                                            DEFAULT_VCARS in this property:

        PERMISSION:READ

11.3.10.4 Scope Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME property SCOPE

   Property Name: SCOPE

   Purpose: This property identifies the CALSTORE
                                            table.

             LANGUAGE        N    TEXT      The default language for
                                            localizable strings objects in the CS to which the
   access rights applies.

   Value Type: CAL-QUERY

   Property Parameters: Only non-standard property parameters can be
   specified on this
                                            calendar. There is no default. property.

   Conformance: This value MUST NOT property can be empty.

             LAST-MODIFIED   N    DATE-TIME The timestamp when specified in "VRIGHT" calendar
   components.

   Description: This property is used in the
                                            Properties "VRIGHT" calendar component
   to define the set of objects subject to the calendar were
                                            last updated. Default access right being
   defined.

   Format Definition: The property is defined by the
                                            same as CREATED.

             NAME            N    TEXT following notation:

        scope      = "SCOPE" scopeparam ":" cal-query CRLF

        scopeparam = *( ";" xparam )

   Example: The display name for this
                                            calendar. It following is a localizable
                                            string. If not provided, an
                                            empty value will be returned.

             OWNER           N    URI       A multi-instanced example of this property:

        SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC'

11.3.10.5 Restriction Component Property

   To: ietf-calendar@imc.org

   Subject: Registration of text/calendar MIME property
                                            indicating RESTRICTION

   Property Name: RESTRICTION

   Purpose: This property defines restrictions on the value that may
   take new or existent calendar owner.

                                            Each entry returned will be a
                                            UPN. There must components.

   Value Type: CAL-QUERY

   Property Parameters: Only non-standard property parameters can be at least one
                                            owner.

             PARENT          N    URI       The CALID of
   specified on this calendar's
                                            Parent maintained by a CAP
                                            server. An empty value means
                                            the property.

   Conformance: This property can be specified in "VRIGHT" calendar is
   components, but only when the top level
                                            parent. The default value PERMISSION property is no
                                            parent.

             RELCALID        N    URI       A unique identifier for the calendar.
                                            There set to "WRITE",
   "MODIFY", or "*".

   Description: This property is no default value used in the "VRIGHT" calendar component
   to define restrictions on the calendar 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, calendar components, and
                                            This value component properties (i.e., by
   using the "modify" command).  Accepted values MUST NOT be empty.

             TOMBSTONE       N    BOOLEAN   TRUE indicator that this
                                            Calendar has been marked as
                                            deleted. match the
   specified RESTRICTION.

   Format Definition: The default value property is
                                            FALSE.

             TZID            N    TEXT defined by the following notation:

        restrict      = "RESTRICTION" restrictparam ":" cal-query CRLF

        restrictparam = *( ";" xparam )

   Example: The id following are examples of the timezone
                                            Associated with this calendar.
                                            See TZID in [iCAL]. The default
                                            value is UTC. property:

        RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST'

        RESTRICTION:SELECT * FROM VEVENT WHERE
         SELF() IN CAL-OWNERS(ORGANIZER)

        RESTRICTION:SELECT * FROM VEVENT WHERE 'BUSINESS' IN
         CATEGORIES

12. CAP Item Registration

   This section provides the process for registration of new or modified
   CAP entities.

12.1 Registration of New and Modified CAP Entities

   New CAP entities are registered by the publication of an IETF Request
   for Comment (RFC).  Changes to a CAP item are registered by the
   publication of a revision of the RFC defining the method.

12.2 Registration of New Entities

   This section defines procedures by which new entities (i.e.,
   components, properties, parameters, enumerated values or restriction
   tables) for a CAP item can be registered with the IANA.

   Non-standard, experimental entities can be used by bilateral
   agreement, provided the associated properties names follow the "X-"
   convention.  Such non-standard and experimental entities are non-IANA
   entities and need not be registered using this process.

   The procedures defined here are designed to allow public comment and
   review of new CAP entities, while posing only a small impediment to
   the definition of new properties.

   Registration of a new CAP item is accomplished by the following
   steps.

12.2.1 Define the Item

   A CAP item is defined by completing the following template.

               To: ietf-calendar@imc.org
               Subject: Registration of CAP item XXX
               Item name:
               Item purpose:
               Description:
               CAP terminology changes:
               CAP data model changes:
               CAP system model changes:
               Conformance considerations:
               Format definition:
               Examples:

   The meaning of each field in the template is as follows.

         Item name: The name of the item.

         Item purpose: The purpose of the item (e.g., Extends the CAP
         command set to poll for notifications, etc.).  Give a short but
         clear description.

         Description: Any special notes about the item, how it is to be
         used, etc.

         CAP terminology changes: Any change or additions to the
         existing CAP terminology needs to be specified.

         CAP data model changes: Any of the valid property parameters
         for the property needs to be specified.

         CAP system model changes:

         Conformance: A clear summary of how and where this CAP item
         extension MUST, MAY, SHOULD or can be used.  Any changes or
         impact to the existing conformance definition for CAP should be
         explained.  The impact to implementations conforming to the
         existing CAP specification should be clearly described.

         Format definition: The ABNF for each element of the CAP item
         needs to be specified.

         Examples: One or more examples of instances of the CAP item and
         each of its usage scenarios needs to be specified.

12.2.2 Post the item definition

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

12.2.3 Allow a comment period

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

12.2.4 Submit the proposal for approval

   Once the two-week comment period has elapsed, and the proposer is
   convinced consensus has been reached on the proposal, the
   registration application should be submitted to the Method Reviewer
   for approval.  The Method Reviewer is appointed by the Application
   Area Directors and can either accept or reject the proposal
   registration.  An accepted registration should be passed on by the
   Method Reviewer to the IANA for inclusion in the official IANA method
   registry.  The registration can be rejected for any of the following
   reasons.  1) Insufficient comment period; 2) Consensus not reached;
   3) Technical deficiencies raised on the list or elsewhere have not
   been addressed.  The Method Reviewers decision to reject a proposal
   can decisions may be appealed by the proposer to
   the IESG, or the objections raised
   can be addressed by the proposer and the proposal resubmitted.

   [EDITORS NOTE: John Stracke to review any updates] IESG.

12.3 Property Change Control

   Existing CAP entities can be changed using the same process by which
   they were registered.

         1.  Define the change

         2.  Post the change

         3.  Allow a comment period

         4.  Submit the proposal for approval

   Note that the original author or any other interested party can
   propose a change to an existing CAP object, but that such changes
   should only be proposed when there are serious omissions or errors in
   the published memo.  The Method Reviewer can object to a change if it
   is not backward compatible, but is not required to do so.

   CAP objects definitions can never be deleted from the IANA registry,
   but objects which are no longer believed to be useful can be declared
   OBSOLETE by adding this text to their "Item purpose" field.

13. IANA Considerations

   This memo defines IANA registered extensions to the attributes
   defined by iCalendar, as defined in [iCAL], [RFC2445], 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]. [RFC2445].

   If the IESG approves this memo for publication, then the IANA
   registers the profile specified in Section 7.1, and selects an IANA-
   specific URI, e.g., http://iana.org/beep/cap/1.0.

URIs

   [1]  <http://www.imc.org/html.charters/calsch-charter.html>

Authors' Addresses

   Steve Mansour
   AOL/Netscape
   466 Ellis Road
   Mountain View, CA  94043
   US

   Phone: +1-650-937-3351
   EMail: sman@netscape.com

   Doug Royer
   INET-Consulting LLC
   1795 W. Broadway #266
   Idaho Falls, ID  83402

   Phone: 208-520-4044
   EMail: Doug@royer.com Doug@Royer.com

   George Babics
   Steltor
   2000 Peel Street
   Montreal, Quebec  H3A 2W5
   CA

   Phone: +1-514-733-8500 x4201
   Fax:   +1-514-733-8878
   EMail: georgeb@steltor.com

   Paul Hill
   Massachusetts Institute of Technology
   W92-172
   77 Massachusetts Avenue
   Cambridge, MA  02139
   US

   Phone: +1-617-253-0124
   Fax:   +1-617-258-8736
   EMail: phb@mit.edu

Appendix A. Acknowledgments

   The following have individuals were major contributors in the
   drafting and discussion of this memo:

         Harald Alvestrand, Mario Bonin, Andre Courtemanche, Dave
         Crocker, Bernard Desruisseaux, Pat Egen, Gilles Fortin, Jeff
         Hodges, Alex Hoppman, Bruce Kahn, Lisa Lippert, David Madeo,
         Bob Mahoney, Bob Morgan, Patrice Lapierre, Pete O'Leary,
         Richard Shusterman, Tony Small, John Stracke, Alexander Taler,
         Mark Wahl.  Special thanks to Patrice Lapierre for transforming
         CAP into a BEEP profile.

Appendix B. Bibliography

      [BEEP] Rose, "The Block Extensible Exchange Protocol Core", RFC
      [BEEPTCP] Rose, "Mapping

   [RFC1521] Borenstein, N., Freed, N., "Specifying and Describing the BEEP Core onto TCP", Format of Internet Message
             Bodies", RFC 3081, March
      2001

      [MIME] N.  Borenstein 1521, September 1993
             ftp://ftp.isi.edu/in-notes/rfc1521.txt

   [RFC1738] Berners-Lee, T, Masinter, L. and McCahil, M., "Uniform Resource Locators (URL)", RFC
             1738, December 1994
             ftp://ftp.isi.edu/in-notes/rfc1738.txt

   [RFC2045] Borenstein, N. and Freed, "MIME (Multipurpose N., "Multipurpose Internet Mail Extensions) Extensions (MIME) Part
             One: Mechanisms for Internet Draft UTF-825
      [RFC 3087] Campbell, Sparks, "Control of Service Context using SIP
      [RFC 2392] Levinson, "Content-ID and Message-ID Uniform Resource
      Locators", RFC 2392, August 1998

      Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

      [TLS] 2045, November 1996
             ftp://ftp.isi.edu/in-notes/rfc2045.txt

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119,
             ftp://ftp.isi.edu/in-notes/rfc2119.txt

   [RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997
             ftp://ftp.isi.edu/in-notes/rfc2222.txt

   [RFC2246] Dierks, T. and Allen, C., "The TLS Protocol", Protocol Version 1.0", RFC 2246, January 1999

      [RFC2119] TODO...

      [SASL] RFC2222 TODO...

      [URL]
             ftp://ftp.isi.edu/in-notes/rfc2246.txt

   [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392,
             August 1998
             ftp://ftp.isi.edu/in-notes/rfc2392.txt

   [RFC2396] Berners-Lee, T, Fielding, R. and Masinter, L., "Uniform Resource Identifiers (URI):
             Generic Syntax", RFC 2396, August 1998.

      [iCAL] 1998
             ftp://ftp.isi.edu/in-notes/rfc2396.txt

   [RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object
             Specification (iCalendar)", RFC 2445, November 1998

      [iTIP]
             ftp://ftp.isi.edu/in-notes/rfc2245.txt

   [RFC2446] Silverberg, S., Mansour, S., Dawson, F. and Hopson, R., "iCalendar Transport-
      Independent Transport-Independent
             Interoperability Protocol (iTIP)", (iTIP) Events, BusyTime, To-dos and Journal Entries", RFC
             2446, November 1998

      [iMIP]
             ftp://ftp.isi.edu/in-notes/rfc2446.txt

   [RFC2447] Dawson, F., Mansour, S. and Silverberg, "iCalendar Message-Based Interoperability
             Protocol (iMIP)", RFC 2445, 2447, November 1998
             ftp://ftp.isi.edu/in-notes/rfc2447.txt
             ftp://ftp.isi.edu/in-notes/rfc3080.txt
             ftp://ftp.isi.edu/in-notes/rfc3081.txt

   [RFC3087] Campbell, B. and Sparks, R., "Control of Service Context using SIP Request-URI",
             ftp://ftp.isi.edu/in-notes/rfc3087.txt

   [SQL]     "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

   [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3.1"
             http://www.unicode.org/unicode/standard/standard.html

   [US-ASCII] Coded Character Set -- 7-bit American Standard -

      Worldwide Code for Information Interchange,
              ANSI X3.4-1986.

   [????]    "Worldwide Character Encoding -- Version 1.0", Addison-Wesley, Volume 1, 1991,
             Volume 2, 1992. UTF-8 is described in Unicode Technical Report #4.

      [US-ASCII] Coded Character Set--7-bit American Standard Code for
      Information Interchange, ANSI X3.4-1986.

Full Copyright Statement

   Copyright (C) The Internet Society (2001). (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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