Network Working Group                   Steve Mansour/Netscape
          Internet Draft                                      Doug Royer
<draft-ietf-calsch-cap-03.txt>
          <draft-ietf-calsch-cap-04.txt>           George Babics/Steltor
                                                           Paul Hill/MIT
                         Calendar Access Protocol (CAP)

          Status of this Memo

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

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

          Distribution of this document is unlimited.

          Copyright Statement

          Copyright (C) The Internet Society 2000. 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] 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, and at the IETF
          web site at http://www.ietf.org/html.charters/calsch-
          charter.html. Refer to the references within this memo for
          further information on how to access these various documents.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          Table Of Contents

1.Introduction 7
1.1.Formatting Conventions    7
1.2.
          1 Introduction.............................................4
           1.1  Formatting Conventions...............................4
           1.2  Related Documents  8
1.3.  Definitions   8
2. Documents....................................5
           1.3  Definitions..........................................5
          2 CAP Design 16
2.1. Design..............................................12
           2.1  System Model  16
2.2. Model........................................12
           2.2  Calendar Store Object Model  17
2.3. Model.........................13
           2.3  Protocol Model     18
2.4. Model......................................15
           2.4  Security Model     20
2.4.1. Model......................................16
            2.4.1 Authentication, Credentials, and Identity  21
2.4.2. Identity........17
            2.4.2 Calendar User and UPNs 22
2.4.2.1.  UPNs and Certificates    23
2.4.2.2.  Anonymous Users and Authentication 24
2.4.2.3.  Required Security Mechanisms  25
2.4.2.4.  TLS Ciphersuites    25
2.4.3. UPNs...........................18
            2.4.3 User Groups  26
2.4.4. Groups......................................21
            2.4.4 Access Rights - Summary     27
2.4.4.1.  VCalendar  Access Right (VCAR)     28
2.4.4.2.  Decreed VCARs  28
2.4.4.3.  Inheritance    29
2.4.5. Summary..........................22
            2.4.5 Inheritance......................................23
            2.4.6 CAP Session Identity   29
2.5.  Roles    31
2.6. Identity.............................24
           2.5  Roles...............................................25
           2.6  Calendar Addresses 31
2.7. Addresses..................................25
           2.7  Extensions to iCalendar 32
2.8. iCalendar.............................26
           2.8  Relationship of RFC 2446 (ITIP) to CAP 33
2.9.  VCalendar Access Rights (VCARs)   35
3. CAP..............27
          3 State Diagram   35
4. Diagram...........................................29
          4 Protocol Framework   37
4.1. Framework......................................30
           4.1  CAP Application Layer   37
4.2. Layer...............................30
           4.2  CAP Transfer Protocol   38
4.3.  Response Format    38
4.4. Protocol...............................31
           4.3  Pipelining of Commands  39
4.5. Commands..............................32
           4.4  Auto-logout Timer  39
4.6. Timer...................................32
           4.5  Bounded Latency    39
4.7. Latency.....................................32
           4.6  Data Elements 40
5. Elements.......................................32
          5 Formal Command Syntax     40
5.1. Syntax...................................32
           5.1  Searching and Filtering 40
5.1.1. Filtering.............................32
            5.1.1 Grammar For Search Mechanism     40
5.1.2. Mechanism.....................33
            5.1.2 SQL-MIN notes     42
5.1.3. notes....................................34
            5.1.3 SQL-92 notes 43
5.1.4. notes.....................................35
            5.1.4 Example, Query by UID  43
5.1.5. UID............................35
            5.1.5 Query by Date-Time range    44
5.1.6. range.........................35
            5.1.6 Query for all Non-Booked Entries 44
5.1.7. Entries.................36
            5.1.7 Query with Subset of Properties by Date/Time    45
5.1.8. Find all Date/Time.....36
            5.1.8 Components with an Alarm Within the
Specified Range     45
6. With Alarms In A Range................36
          6 Access Rights   46
6.1. Rights...........................................37
           6.1  VCAR Inheritance   46
6.2. Inheritance....................................37
           6.2  Access Control and NOCONFLICT     46
7. NOCONFLICT.......................37
          7 Commands and Responses    47
7.1. Responses..................................38
           7.1  Transfer Protocol Commands   47
7.1.1. Commands..........................38
            7.1.1 Initial Connection     48
7.1.2. Connection...............................38
            7.1.2 ABORT Command     48
7.1.3. AUTHENTICATE Command   49
7.1.3.1. Command....................................39
            7.1.3 AUTHENTICATE ANONYMOUS   52
7.1.4. Command.............................39
            7.1.4 CALIDEXPAND Command    53
7.1.5. Command..............................43
            7.1.5 CAPABILITY Command     54
7.1.6. Command...............................45
            7.1.6 CONTINUE Command  57
7.1.7. Command.................................47

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            7.1.7 DISCONNECT Command     58
7.1.9. Command...............................48
            7.1.8 SENDDATA Command  60
7.1.10.1.  UPNEXPAND Method   61
7.2. Command.................................49
           7.2  Application Protocol Commands     62
7.2.1. Commands.......................52
            7.2.1 Calendaring Commands   62
Restriction Tables  63
7.2.1.1.  CREATE Method  63
7.2.1.1.1.  Creating New Calendars 71
7.2.1.2.  DELETE Method  74
7.2.1.3.  GENERATEUID Method  78
7.2.1.4.  MODIFY Method  79
7.2.1.5.  MOVE Method    88
7.2.1.6.  NOOP Method    90
7.2.1.7.  READ Method    90
7.2.2. Commands.............................52
            7.2.2 Scheduling Commands    95
7.2.2.1.  Reading out scheduling components  95
7.2.2.2.  PUBLISH   97
7.2.2.3.  REQUEST   98
7.2.2.4.  REPLY     98
7.2.2.5.  ADD  99
7.2.2.6.  CANCEL    99
7.2.2.7.  REFRESH   99
7.2.2.8.  COUNTER   100
7.2.2.9.  DECLINECOUNTER 100
7.2.3. Commands..............................84
            7.2.3 iTIP Examples     100
7.2.3.1.  Sending Examples....................................89
          8 Response Codes..........................................96
          9 Examples................................................98
           9.1  Authentication Examples.............................98
            9.1.1 Login Using Kerberos V4..........................98
            9.1.2 Error Scenarios..................................99
           9.2  Read Examples......................................100
            9.2.1 Read From Multiple Calendars....................101
            9.2.2 Timeouts........................................102
            9.2.3 Using Parent and Receiving an iTIP request   101
7.2.3.2.  Handling an iTIP refresh 105
7.2.3.3.  Sending Children Properties............103
            9.2.4 Query VEVENT.DTSTART and accepting an iTIP counter   106
7.2.3.4.  Declining an iTIP counter     108
9.  Detailed SQL Schema  112
9.1.  iCalendar VALARM.DTSTART.........103
          10  Implementation Issues................................103
          11  Properties...........................................104
           11.1  Calendar Store Schema  114
9.1.1.    ACTION schema  115
9.1.2. ATTACH schema     115
9.1.3. ATTENDEE schema   116
9.1.4. CALSTORE schema   116
9.1.5. CHILDREN schema   117
9.1.6.    CLASS schema   117
9.1.7.    CN schema 117
9.1.8. COMMENT schema    117
9.1.9. CONTACT schema    118
9.1.10.  CREATED schema  118
9.1.11.    CUTYPE schema 118
9.1.12.    DAYLIGHT_STANDARD schema     119
9.1.13.    DESCRIPTION schema 119
9.1.14.    DIR schema    120
9.1.15.    DTEND schema  120
9.1.16.    DTSTAMP schema     120
9.1.17.    DUE schema    120
9.1.18.    DURATION schema    121
9.1.19.    EXDATE schema 121
9.1.20.    EXRULE schema 121
9.1.21.    FBTYPE schema 122
9.1.22.    FMTTYPE schema     122
9.1.23.    FREEBUSY schema    122
9.1.24.    GEO schema    123
9.1.25.    LANGUAGE schema    123
9.1.26. LAST_MODIFIED schema  123
9.1.27.    MEMBER schema 123
9.1.28.    METHOD schema 123
9.1.29.    ORGANIZER schema   124
9.1.30.    OWNERS schema 124
9.1.31.    PARTSTAT schema    125
9.1.32.    PERCENT_COMPLETE schema 125
9.1.33.    PRIORITY schema    125
9.1.34.    RDATE schema  125
9.1.35.    RECUR schema  126
9.1.36.    RECURRENCE_ID schema    128
9.1.37.    RELATED_TO schema  128
9.1.38.    REPEAT schema 128
9.1.39.    RESOURCES schema   129
9.1.40.    ROLE schema   129
9.1.41.    RRULE schema  129
9.1.42.    SEQUENCE schema    130
9.1.43.    STATUS schema 130
9.1.44.    SUMMARY schema     130
9.1.45.    TRANSP schema 131
9.1.46.    TRIGGER schema     131
9.1.47.    TZID schema   131
9.1.48.    UID schema    131
9.1.49.    URL schema    132
9.1.50.    VALARM schema 132
9.1.51.    VCALENDAR schema   132
9.1.52.    VCAR schema   133
9.1.53.    VEVENT schema 133
9.1.54.    VFREEBUSY schema   135
9.1.55.    VJOURNAL schema    136
9.1.56.    VQUERY schema 137
9.1.57.    VTIMEZONE schema   137
9.1.58.    VTODO schema  138
9.1.59.    X_PROP schema 139
9.1.60.    XPARAM schema 140
10. Examples"  140
10.1.  Authentication Examples     140
10.1.1.  Login Using Kerberos V4   140
10.1.2.  Error Scenarios 141
10.2.  Read Examples     141
10.2.2.  Read From Multiple Calendars   143
10.2.3.  Timeouts   144
10.2.4.  Using the Calendar Parent, Children Properties
145
10.2.5.  An example that depends on VEVENT.DTSTART &
VALARM.DTSTART 145
11.  Implementation Issues    146
12.  Properties     146
12.1. Properties........................104
           11.2  Calendar Store Properties   146
12.2.  Calendar     Properties     149
13. Properties..............................105
          12  Security Considerations  151
14.  Changes to iCalendar     152
14.1.  Time Transparency 152
14.2.  RIGHTS Value Type 154
14.3.  VCAR Calendar Component     159
14.4.  GRANT Component Property    161
14.5.  DENY Component Property     162
14.7.  REQUEST-STATUS property     163
15. Considerations..............................107
          13  CAP Item Registration    165
15.1 Registration................................107
           13.1  Registration of New and Modified CAP Entities New CAP
entities are   165
15.2 Entities....107
           13.2  Registration of New Entities  165
15.1.1. Entities.....................107
            13.2.1  Define the Item 166
15.1.2. Item...............................108
            13.2.2  Post the item definition  167
15.1.3. definition......................109
            13.2.3  Allow a comment period    167
15.1.4. period........................109
            13.2.4  Submit the proposal for approval    168
15.2. approval..............109
           13.3  Property Change Control     168
16. Control..........................109
          14  IANA Considerations 169
17.  Acknowledgments     169
18.  Bibliography   170
19. Considerations..................................110
          15  Acknowledgments......................................110
          16  Bibliography.........................................111
          17  Author's Address    171
20. Address.....................................112
          18  Full Copyright Statement 172

1.Introduction Statement.............................112

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          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.

          This protocol is based on request/response form of protocol data units,
          sent from a client CUA to a calendar server. The protocol data
          units leverage the standard iCalendar format [iCAL] for
          conveying CS related information.

1.1.Formatting

          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. Calendar
          components defined by [iCAL] 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.
          Calendar access methods defined by this memo, as well as
          scheduling methods defined by [iTIP], are referred to with
          capitalized, quoted-strings of text. For example, "CREATE"
          refers to the method for creating a calendar component on a
          calendar, "READ" refers to the method 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 lower case, quoted-strings of text, followed
          by the word "parameter". For example, "value" parameter refers
          to the iCalendar property parameter used to override the
          default data type for a property value. Enumerated values
          defined by this memo are referred to with capitalized text,
          either alone or followed by the word "value".

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

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

1.2.

          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. This document, These documents are:

          [iCAL] (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].

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

1.3.

          1.3 Definitions

          Authentication ID (AuthID)

                  A tuple of username, realm, and authentication
                  method, used by the Calendar Service internally to
                  identify a successfully authenticated CAP session.

          Booked

                  A entry in a calendar has one of two conceptual
                  states. It is scheduled or it is booked.  A scheduled
                  entry has been stored in the calendar store but has
                  not been acted on by a calendar user or calendar user
                  agent. A booked appointment is an entry that has had
                  its state changed from one of the [iTIP] scheduling
                  methods to a CAP method of CREATE by a calendar user

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  or calendar user agent which resulted in decision to
                  keep the entry in the calendar store.

          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. A calendar is identified by
                  its unique calendar identifier. The [iCAL] 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 a
                  calendar residing on a Calendar Store.

          Calendar Access Rights (CAR)

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

          Calendar Collection

                  A collection of Calendars, Resource Calendars, and/or
                  other Calendar Collections.  These collections are
                  expanded by the CS and may reside either locally or
                  in an external database or directory.  The calendars
                  in the collection may be fixed or dynamic over time.

          Calendar Component

                  An item within a calendar. Some types of calendar
                  components include events, to-dos, journals, alarms,
                  time zones and freebusy data. A calendar component
                  consists of component properties and possibly other

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  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.

          Calendar Policy

                  A CAP operational restriction on the access or
                  manipulation of a calendar. For example, "events MUST
                  be scheduled in unit intervals of one hour".

          Calendar Properties

                  An attribute of a calendar. 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.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

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

          Calendar Store Components

                  Components maintained in a CS specify a grouping of
                  calendar store-wide information. Calendar store
                  components can be accessed using CAP.

          Calendar Store Properties

                  Properties maintained in a Calendar Store calendar store-
wide
                  store-wide information. Calendar store properties can
                  be accessed using CAP.

          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 or UG
                  utilizes to access and manipulate a calendar.

          Calendaring and Scheduling System

                  The computer sub-system that provides the services
                  for accessing, manipulating calendars and scheduling
                  calendar components.

          CAP Session

                  An open communication channel between a CAP CUA and a
                  CAP CS.

          Connected Mode

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  A mobile computing mode where the CUA is directly
                  connected to the CS.

          Delegate

                  Is 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

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

          Disconnected Mode

                  A mobile computing mode where a CUA can be
                  disconnected from a CS. When the CUA is disconnected,
                  it is in the disconnected mode.

          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.
                  This may include the calendar associated with TARGET
                  calendar property.

          Hierarchical Calendars

                  A CS feature where a calendar have a hierarchical
                  relationship with another calendar in the CS. The
                  top-most calendar in the hierarchical relationship
                  has the CS as its parent. There may be multiple top-most top-
                  most calendars in a given CS. Within a given
                  hierarchical relationship, all sub-
calendars sub-calendars have a
                  calendar with a "parent" topographical relationship.
                  In addition, sub-calendars may have a relationship

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  with another calendar that has a "child"
                  topographical relationship. In addition, a calendar
                  may have a relationship such that one or more
                  calendars have a "sibling" topographical relationship
                  with the calendar. 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.

          High Bandwidth Connection

                  A communications connection supporting high transfer
                  rates; transfer rates commonly found within a LAN.

          Local Store

                  A CS which is on the same platform as the CUA.

          Low Bandwidth Connection

                  A communications connection supporting slow transfer
                  rates; transfer rates commonly found in remote access
                  technology.

          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 any OPAQUE
                  events in the calendar can overlap. When applied to
                  an individual event, it indicates whether or not it
                  can be overlapped by any other OPAQUE event.

          Owner

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

          Qualified Calendar Identifier (Qualified CalID)

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  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. (eg: 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 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].

          Remote Store

                  A CS which is not on the same platform as the CUA.

          Resource Calendar (RC)

                  A non-human Calendar, associated with an
                  organizational resource. There is no syntactic
                  difference between an RC and a Calendar.

          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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  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.

          User Name

                  A name which denotes a Calendar User within a realm.
                  This is part of a UPN.

          User Principal Name (UPN)

                  An identifier that denotes a unique CU. A UPN is an
                  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
                  deliverable to a different person. 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.

          2  CAP Design

2.1.

          2.1 System Model

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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          CAP is used by a "Calendar User Agent" (CUA) to send commands
          to and receive responses from a "Calendar Service" (CS). The
          CUA prepares an a [MIME] encapsulated iCalendar object containing
          a command, sends it to the CS, and receives an a [MIME]
          encapsulated iCalendar object as a response. There are two
          distinct protocols in operation to accomplish this exchange.
          The Transfer Protocol is used to move iCalendar objects these encapsulations
          between a CUA and a CS. The Application Protocol defines the
          content and semantics of the iCalendar objects sent between
          the CUA and the CS. This document defines both the Transfer
          Protocol and the Application Protocol.

          In the diagram below, a user uses CUA1 to communicate with CS1
          using CAP. The CUA must authenticate the Calendar User (CU) so
          that access to calendars on CS1 can be controlled. The CUA can
          then view, create, edit, and delete calendars, calendar
          properties, and calendar components subject to the access
          rights.

          CAP servers support fanout. Fanout allows a CUA to communicate
          with a single CS to perform scheduling operations with
          calendars on multiple CSs. That is, a
Calendar User (CU) CU can book or schedule
          events (or to-dos) on or read events (or to-dos) from
          calendars on other calendar stores. To accomplish this, a CAP
          server has takes on these options: roles:

               * CS1 MAY play the role of a CUA and use CAP to access
                  CS2;
               * CS1 MUST be able play the role of a CUA and use [iMIP]
                  to interoperate with other CUAs.

Storage Agent

                    +-----+          +-----+
                    |     |   CAP    |     |   CAP
          CUA1------| CS1 |----------| CS2 |--------- CUA2
                    |     |          |     |           A
                    |     |          |     |           |
                    |     |          |     |           |
                    +-----+          +-----+           |
                      |        IMIP                    |
                      +--------------------------------+

          Note that the fanout feature in CAP is a convenience to the
          CUA. It is perfectly valid for the CUA to assume the
          responsibility for fanout if it wishes. That is, [iMIP]
          messages could also be sent from CUA1 to CUA2.

2.2.

          2.2 Calendar Store Object Model

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

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

          Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs, VCARs,
          and calendar properties. Calendars may also contain other
          calendars.

+---------Calendar Store---------------------------------+
|                                                        |
|                                                        |

          Calendar Store
            |
            +-- VCARs                                                  |
|              +--calendars-------------------------+    |
|
            +-- Properties   |                                    |    |
|              |  +--calendars--------+    VEVENTs  |    |
| VTIMEZONEs   |  |                   |     VTODOs  |    |
|              |  |          VEVENTs  |  VJOURNALs  |    |
|              |  |            VCARs  |    VALARMs  |    |
|              |  |  +---+    VTODOs  |
            +-- VCARs
            +-- VTIMEZONEs
            +-- VCALENDARs
                  |
                  +--VEVENTs
                       +--VALARMs
                  +--VTODOs
                       +--VALARMs
                  +--VJOURNALs
                  +--VCARs
                  +--Properties
                  +--VTIMEZONEs
                  +--VSCHEDULE
                  +--Calendar
                       |
                       +--VEVENTs
                            +--VALARMs
                       +--VTODOs
                            +--VALARMs
                       +--VJOURNALs
                       +--VALARMs
                       +--VCARs
                       +--Properties
                       +--VTIMEZONEs
                       +--VSCHEDULE
                       +--Calendar
                            |
|              |  |  |   |   VALARMs  |   Calendar  |    |
|              |  |  +---+ VJOURNALs  | Properties  |    |
|              |  |       VTIMEZONEs  | VTIMEZONEs  |    |
|              |  |         Calendar  |  VSCHEDULE  |    |
|              |  |       Properties  |             |    |
|              |  |        VSCHEDULE  |             |    |
|              |  +-------------------+             |    |
|              +------------------------------------+    |
+--------------------------------------------------------+
                           ...

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

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

2.3.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          2.3 Protocol Model

          A generic transfer-layer, Calendar Server Transfer Protocol
          (CSTP), is used to move data objects between a CUA and the CS.
          CSTP commands are listed below and their usage and semantics
          are defined in section 7 7.1 of this document.

          CSTP Commands
-------------------------------------------------------
          -----------------------------------------------------------
          Command         Description
          -----------------------------------------------------------
          ABORT           Stop a command. Perhaps because its latency
                          time has been exceeded.
          AUTHENTICATE    Authenticate a UPN.
          CONTINUE        Continue the execution of a command whose
latency
                          Latency time has been exceeded.
          IDENTIFY        Set a new identity for calendar access.
          DISCONNECT      Terminate a connection with the server.
          SENDDATA        Send a data object [MIME] encapsulated
                          iCalendar.
          STARTTLS        Negotiate transport level security using
                          [TLS].
          -----------------------------------------------------------

          Application-level commands are used to manipulate data on the
          calendar store. They are listed below and discussed in detail
          in section 7. 7.2.

          CAP Calendaring Commands
          -----------------------------------------------------------
          Command          Description
----------------------------------------------------------
          -----------------------------------------------------------
          CREATE           Create a new calendar or component.
          DELETE           Delete a calendar or component.
          GENERATEUID      Generate one or more unique ids.
          MODIFY           Change a calendar or component.
          MOVE             Move a calendar.
          READ             Read a calendar properties or components.
--------------------------------------------------------
          -----------------------------------------------------------

          CAP Scheduling Commands
          (As defined in [iTIP])
          -----------------------------------------------------------
          Command        Description
----------------------------------------------------------
          -----------------------------------------------------------

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          PUBLISH        Publish a calendar entry to one or more
                         calendars.
          REQUEST        Schedule a calendar entry with one or more
                         calendars.
          REPLY          Response 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 of a
                         calendar entry.
          COUNTER        A request for a change(a counter-proposal)to
                         a calendar entry.
          DECLINECOUNTER Decline a counter proposal.
          -----------------------------------------------------------

2.4.

          2.4 Security Model

          Authentication to the CS will be performed using [SASL].

          As noted in the CAP system model section, a variety of
          connectivity scenarios are possible. This complicates the
          security model considerably, and a thorough familiarity with
          the concepts is required to ensure interoperability.

          Basic threats to a Calendaring and Scheduling System include:

          (1) Unauthorized access to data via data-fetching operations,

          (2) Unauthorized access to reusable client authentication
              information by monitoring others' access,

          (3) Unauthorized access to data by monitoring others' access,

          (4) Unauthorized modification of data,

          (5) Unauthorized or excessive use of resources (denial of
              service), and

          (6) Spoofing of CS: Tricking a client into believing that
              information came     from the CS when in fact it did
              not, either by modifying data in transit or
              misdirecting the client's connection.

          Threats (1), (4), (5) and (6) are due to hostile clients.
          Threats (2), and (3) are due to hostile agents on the path
          between client and server, or posing as a server.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          CAP can be protected with the following security mechanisms:

          (1) Client authentication by means of the SASL mechanism
              set, possibly backed by the TLS credentials exchange
              mechanism,

          (2) Client authorization by means of access control based
              on the requestor's authenticated identity,

          (3) Data integrity protection by means of the TLS protocol
              or data integrity SASL mechanisms,

          (4) Protection against snooping by means of the TLS
              protocol or data encrypting SASL mechanisms,

          (5) Resource limitation by means of administrative limits
              on service controls, and

          (6) Server authentication by means of the TLS protocol or
              SASL mechanism.

          Imposition of access controls (authorizations) is done by
          means of VCARs, an overview is provided in section <fwd ref>,
          and a detailed syntax is provided in section <fwd ref>.
          Authentication is explained in detail in section <fwd ref>.

2.4.1.

          2.4.1  Authentication, Credentials, and Identity

          Generically, authentication credentials are the evidence
          supplied by one party to another, asserting the identity of
          the supplying party (e.g. a user) who is attempting to
          establish an association with the other party (typically a
          server). Authentication is the process of generating,
          transmitting, and verifying these credentials and thus the
          identity they assert. An authentication identity is the name
          presented in a credential.

          There are many forms of authentication credentials. The form
          used depends upon the particular authentication mechanism
          negotiated by the parties. For example: X.509 certificates,
          Kerberos tickets, simple identity and password pairs. Note
          that an authentication mechanism may constrain the form of
          authentication identities used with it.

          SASL only provides a protocol to negotiate a mutually
          acceptable authentication mechanism. SASL itself does not
          constrain or dictate the form of the authentication identities
          used to perform the authentication.

2.4.2.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          2.4.2  Calendar User and UPNs

          A Calendar User(CU) is an entity that can be authenticated. It
          is represented in CAP as a UPN. A UPN is the owner of a
          calendar and the subject 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
          control policy, requiring a server-specific mapping to be
          done. The method by which a server composes and validates an
          authorization identity from the authentication credentials
          supplied by a client is implementation-specific.

          For Calendaring and Scheduling Systems that are integrated
          with a directory system, the CS MUST support the ability to
          configure which schema attribute stores the UPN. The CS MAY
          allow one or more attributes to be searched for the UPN.

2.4.2.1.

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

          From RFC-2459, section 4.1.2.6 (Subject):

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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  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:juser@example.com" then the email
          address should be checked against the UPN, and the CN should
          also be checked. This is so the "ATTENDEE" property couldn't
          be munged to something misleading like "ATTENDEE;CN=Joe Rictus
          User:juser@example.com" and have it pass validation. This
          validation will also defeat other attempts at  confusion.

2.4.2.2.
          2.4.2.2   Anonymous Users and Authentication

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          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.

          CAP implementations MUST support anonymous authentication, as
          defined in section <fwd ref 7.1.3>.

          CAP implementations MAY support anonymous authentication with
          TLS, as defined in section <fwd ref 7.1.3.2>.

2.4.2.3.
          2.4.2.3   Required Security Mechanisms

          The following implementation conformance requirements are in
          place:

          (1) For a read-only, public CS, anonymous authentication,
          described in section <fwd ref 7.1.3.1>, can be used.

          (2) Implementations providing password-based authenticated
          access MUST support authentication using Digest, as described
          in section <fwd ref>.  This provides client authentication
          with protection against passive eavesdropping attacks, but
          does not provide protection against active intermediary
          attacks.

          (3) For a CS needing session protection and authentication,
          the Start TLS extended operation, and either the simple
          authentication choice or the SASL EXTERNAL mechanism, are to
          be used together.  Implementations SHOULD support
          authentication with a password as described in section <fwd
          ref>, and SHOULD support authentication with a certificate as
          described in section <fwd ref>.  Together, these can provide
          integrity and disclosure protection of transmitted data, and
          authentication of client and server, including protection
          against active intermediary attacks.

2.4.2.4.
          2.4.2.4   TLS Ciphersuites

          The following ciphersuites defined in [RFC 2246] MUST NOT be
          used for confidentiality protection of passwords or data:

                  TLS_NULL_WITH_NULL_NULL
                  TLS_RSA_WITH_NULL_MD5
                  TLS_RSA_WITH_NULL_SHA

          The following ciphersuites defined in [RFC 2246] can be
          cracked easily (less than a week of CPU time on a standard CPU
          in 1997).  The client and server SHOULD carefully consider the

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          value of the password or data being protected before using
          these ciphersuites:

                  TLS_RSA_EXPORT_WITH_RC4_40_MD5
                  TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
                  TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
                  TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
                  TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
                  TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
                  TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
                  TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
                  TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

          The following ciphersuites are vulnerable to man-in-the-
middle man-in-the-middle
          attacks, and SHOULD NOT be used to protect passwords or
          sensitive data, unless the network configuration is such that
          the danger of a man-in-the-middle attack is tolerable:

                  TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
                  TLS_DH_anon_WITH_RC4_128_MD5
                  TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
                  TLS_DH_anon_WITH_DES_CBC_SHA
                  TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

          A client or server that supports TLS MUST support at least:

                  TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

2.4.3.
          2.4.3  User Groups

          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 MUST accept a
          CUA request for UG expansion, although the CS may be
          configured to restrict some responses. The CS MAY expand a UG
          (including nested UGs) to obtain a list of unique CUs.
          Duplicate UPNs are filtered during expansion. Incomplete
          expansion should be treated as a failure.

          Groups may be in a directory with its own ACL model and CAP
          should use the directory service to expand a UPN subject to
          the directory service access control model for the
          authenticated entity.

          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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          expansion in order to recognize changes to UG membership.
          However, during fan out to other CSs, the originating CS
          SHOULD expand all UGs so that the target CS receives only a
          list of unique CUs. This is to prevent confusion when two CSs
          do not share the same UG database or directory.

          CAP does not define commands or methods for managing UGs.

          Small UG:
            The Three Stooges. There is only and always three at any
            one time.

          Large UG:
            The MIT graduating class of 1999. This is a static list.

          Dynamic UG:
            The IETF membership which is a large and changing list of
            members.

          Nested UG:
            The National Football League, made up of the AFC and NFC,
            which are   made up of 3 divisions each...

2.4.4.

          2.4.4  Access Rights - Summary

In simple terms, access

          Access rights are used to grant or deny access to a calendar
          for a CU. CAP defines a new component type called a Vcalendar
          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.

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

2.4.4.1.

          The access for a particular UPN is the union of all grants for
          that UPN minus the union of its denies.

          2.4.4.1   VCalendar Access Right (VCAR)

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

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

2.4.4.2.

          2.4.4.2   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 a decreed VCAR an error will be
          returned, indicating that the user has insufficient
          authorization to perform the operation.

          The CAP protocol does not define the semantics used to
          initially create a decreed VCAR. This administrative task is
          out side 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 Default Access
             GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=*
   DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;VALUE="Users
             DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;
              VALUE="Users Default Access"
              ;OBJECT=METHOD,VALUE=DELETE,MODIFY
             END:VCAR

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

2.4.4.3.

          2.4.5  Inheritance

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

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

          2.4.6  CAP Session Identity

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

          The CUA may change the identity of a CAP session by calling
          the "IDENTIFY" command. The 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 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.

          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.

          Examples:

          Small UG:

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  The Three Stooges.  There will always be three, it
                  will not change.

          Large UG:
                  The MIT graduating class of 1999.  This is a static
                  list.

          Dynamic UG:
                  The IETF membership, which is a large and changing
                  list of members.

          Nested UG:
                  The National Football League, made up of the AFC and
                  NFC, which are made up of 3 divisions each.

2.5.

          2.5 Roles

          CAP defines methods for managing [iCAL] objects on a Calendar
          Store and exchanging [iCAL] 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 or UGs as attendees takes on the role of
          "Organizer". The CUs or UGs asked to participate in the group
          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- "NON-
          PARTICIPANT" and has nothing to do with the scheduling
          workflow.

2.6.

          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> is "cap". That is this "cap", the protocol described in this
                  memo.

                  <csid> is the Calendar Store ID. It is the network
                  address of the computer on which the CAP server is
                  running.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  <port> is optional. Its default value is 5229. The
                  port must be present in the URL if the CAP server
                  does not listen on this default port of 5229.

                  <relativeCALID> is an identifier that uniquely
                  identifies the 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 Relative CALID be globally
                  unique.

          If the <scheme> and <csid> are present the calendar address is
          said to be "qualified". Senders are required to supply the
          <relativeCALID> portion of the address. A qualified calendar
          address is required when the <csid> of the target calendar
          address differs from that of the CAP server receiving the
          command.

          Examples of CAP URIs:

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

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

2.7.

          2.7 Extensions to iCalendar

          In mapping the CAP command set, query feature, and access
          rights onto the iCalendar format, several extended iCalendar
          methods and components are defined by this memo.

               * The search function is specified with the new
                  iCalendar QUERY method. The QUERY method makes use of
                  a new component, called VQUERY, that contains the
                  search filter. The component consists of a set of new
                  properties: EXPAND, MAXRESULTS, MAXRESULTSSIZE, QUERY
                  and QUERYNAME, that define the search filter. Note
                  that QUERY simply is the filter that is used by the CS
                  to select the data used in METHOD:READ, METHOD:CREATE, METHOD:UPDATE,

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  METHOD:MODIFY, METHOD:DELETE, any other METHOD that is
                  defined to use a QUERY filter.
               * Access control is specified the the new iCalendar VCAR
                  component.
               * The iCalendar METHOD property format has been updated
                  with new values.
               * A new iCalendar component, VCOMMAND, has been added.
                  VCOMMANDs are needed to fully specify CAP commands.
               * TARGET is a new property within the VCOMMAND
                  component. It indicates  the calendars to which the
                  command applies
               * CMDID is a Command ID that is used in a VCOMMAND to
                  uniquely identify  a command. Responses to a VCOMMAND
                  will contain the same CMDID.

2.8.

          2.8 Relationship of RFC 2446 (ITIP) to CAP

          [iTIP] describes scheduling methods which result in indirect
          manipulation of calendar components. CAP methods 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 queue. Note that this is a conceptual
          model, the actual storage details are left to implementations.
          The model is shown pictorially as follows:

               +-----------------VCALENDAR-------------------+
               |                                             |
               |  +-----------+  +-------VSCHEDULE---------+ |
               |  | VEVENTs   |  | PUBLISH messages        | |
               |  | VTODOs    |  | REQUEST messages        | |
               |  | VJOURNALs |  | REPLY messages          | |
               |  |           |  | ADD messages            | |
               |  |           |  | CANCEL messages         | |
               |  |           |  | REFRESH messages        | |
               |  |           |  | COUNTER messages        | |
               |  |           |  | DECLINECOUNTER messages | |
               |  +-----------+  +-------------------------+ |
               +---------------------------------------------+

          The METHOD is saved along with components. Scheduled
          components become booked components when the METHOD changes
          from an ITIP method to the CAP storage method CREATE.  For
          example, a component whose METHOD is "REQUEST" is scheduled.
          The component becomes booked when the METHOD is changed to
          "CREATED".

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          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 READ 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. Followed by a DELETE of all of these
          now old scheduling requests in the CS. See [iTIP] for details
          on resolving multiple [iTIP] scheduling entries.

2.9.  VCalendar Access Rights (VCARs)

In simple terms, VCARs

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          3  State Diagram

          This section describes the states of the transport connection
          between a CUA and a CS. The state diagram is shown below.
          State names are shown with first letter capitalized. Commands
          used to grant or deny access switch between states are shown next to a
calendar for a CU or UG. Specifically, they grant User
Principal Names (UPNs) an arrow
          connecting the rights to read and write
components, properties, and parameters on calendars within a
calendar store. states. The model does not put any restriction on the sequence in
which the object and access rights commands 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 SENDDATA
command.

VCAR principals can be CU or UG UPNs. Whenever VCARs are
evaluated, all referenced User Groups MUST be evaluated as
an expanded list.  UG expansion SHOULD NOT persist across
operations.

Your access is a  union of all your grants minus a union of
all your denies.

3.  State Diagram

This section describes the states of the transport
connection between a CUA and a CS. The state diagram is
shown below. State names shown with first letter
capitalized. The commands used to switch between states are
shown next to an arrow connecting the states. The commands
are listed in all capital letters. A condition that causes listed in all capital
          letters. A condition that causes a state to change is shown in
          lower case letters.

           STARTTLS /
           CAPABILITY
          +-------+
          |       |                       +---------------+
          |   +-----------+ AUTHENTICATE  |               |
          +-->| Connected |-------------->| Authenticated |
              +-----------+               |               |
                |                         +---------------+
                |                                |
                |                                |
      |                                |
      |                                |     +-----+
STARTTLS /
                |                                V     |     |
CAPABILITY     |STARTTLS /
                |                         +---------------+  |
IDENTIFY  |IDENTIFY
                |                         |               |<-+
                |                         |   Identified  |<----+  |<-----+
                |                +--------|               |      |
                |                |        +---------------+      |
command
      |
                |                |                |
completes       command|
                V                |DISCONNECT      |             |     completes|
              +--------------+   |                |SENDDATA                |              |
              | Disconnected |<--+                |              |
              +--------------+                    |                    |SENDDATA      | ABORT
                     A                            |              |
                     |                            V              |
                     |    DISCONNECT      +---------------+      |
                     +--------------------|    Receive    |-----+    |------+
                                          |               |<--+
                                          +---------------+   |
                                                         |    |
CONTINUTE
                                                         +----+
                                                        CONTINUE

          The connection begins the Connected state when a CUA connects
          to a CAP server. The capabilities of the CS are reported in
          the response from the CS. From this state, the CUA can issue
          the DISCONNECT command to terminate the connection, the
          CAPABILITY, STARTTLS, or AUTHENTICATE commands. One use of the
          CAPABILITY command at this stage is to determine the supported

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          authentication mechanisms supported by the server. Once the
          STARTTLS command has been successfully executed from either
          the Connected or Authenticated state, it must not be executed
          again.

          If an AUTHENTICATE command is successful, the connection
          enters the Authenticated state and then immediately goes to
          the IDENTIFIED state. While in the Identified state, allow
          CALIDEXPAND and UPNEXPAND commands. From here the CUA can
          issue the CAPABILITY command. The capabilities the server
          offers in the Authenticated state may be different than those
          in the Connected state to allow for the users realm to be used
          to grant or deny features. The CUA can also use the IDENTIFY
          command to change the identity of the user subject to access
          control. The connection remains in the Authenticated state
          after the CAPABILITY command completes. The CUA can issue the
          DISCONNECT command to terminate the connection. The SENDDATA
          command can be used to send a request to read, write, modify,
          or delete data on the server.

          After the SENDDATA command has been issued the connection
          enters the Receive state while the CUA awaits and reads a
          server reply. Normally, the server handles the command, sends
          a reply which is read by the CUA and the connection returns to
          the Authenticated state. The CUA may have issued the SENDATA
          command with a maximum latency time. This informs the server
          that the CUA expects a response within the maximum latency
          time, even if the command was not completed. When the server
          is unable to complete the command in the maximum latency time,
          it issues an appropriate reply code and waits for the CUA to
          tell it how to proceed. If the CUA issues a CONTINUE command
          the server continues processing the command and the connection
          remains in the Receive state. If the CUA issues the ABORT
          command the server need not process the command any further
          and the connection returns to the Authenticated state. The
          DISCONNECT command can also be issued from the Receive state.

4.

          4  Protocol Framework

4.1.

          4.1 CAP Application Layer

          The CAP application layer is used for the manipulation of the
          calendar store. Commands and responses are transmitted between
          the CUA and CS inside "VCALENDAR" component wrappers. Commands
          are specified as the value of a "METHOD" property, and
          responses are specified as the value of a "REQUEST-STATUS"
          property.

4.2.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          4.2 CAP Transfer Protocol

          The CAP transfer protocol defines the format of data
          transmitted between a CUA and the CS.

          CAP transfer protocol commands are transmitted using the
          underlying transport. The transport used is a TCP/IP socket
          connection between the CUA and the CS. The default port that
          the CS listens for connections on is port 5229.

          Messages sent between the CUA and CS are formatted as a
          command followed by any associated data:

          <command> [<command data>]

4.3.

          Response Format

          Server responses consist of a response code and any
          parameters:

          <transfer-level response-code> [response-args] [; debug-text ]
          <CRLF>.<CRLF>
          [<application-data>]
          <CRLF>.<CRLF>

          The response-args are defined in Section 8. The debug-text is
          human-readable information for protocol debugging and is
          optional and is only used to aid developers writing CSs and
          CUAs.  The debug-text MUST not be depended on by CUAs in
          normal interactions with a CS.

          The optional application-data begins on the next line.

          The response is terminated with the second <CRLF> "." <CRLF>
          sequence. Any <CRLF> "." sequences which appear in the
          transmitted data must be quoted by placing an additional "."
          between the <CRLF> and the ".". For example, the following
          sequences of characters in the application data:

          .
          ..2
          ...3

          are quoted as follows:

          ..
          ...2
          ....3

4.4.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          4.3 Pipelining of Commands

          If the CS returns a PIPELINE number greater then one (1) as a
          result of a CAPABILITY command the CUA can send up to PIPELINE
          VCOMMANDS without waiting for the CS to reply.

4.5.

          4.4 Auto-logout Timer

          If a server has an inactivity auto-logout timer, that timer
          MUST be of at least 15 minutes duration if there is no value
          of AUTOLOGOUTTIME returned in the CS CAPABILITY reply. The
          receipt of ANY command from the client during that interval
          MAY reset the auto-logout timer, subject to CS administrators
          policy. A CUA may be discouraged from attempts to do useless
          things only to keep the connection alive.

          A CS MAY have different AUTOLOGOUTTIME values depending on the
          UPN or the realm of the UPN.

          When a timeout occurs, the server drops the connection to the
          CUA.

4.6.

          4.5 Bounded Latency

          CAP is designed so that the CUA can either obtain an immediate
          response from a request or discover within a specified amount
          of time that the request could not be completed in the
          requested amount of time. When the CUA initiates a command
          that the server cannot complete within the specified latency
          time, the server returns an appropriate response code. The CUA
          then issues either a CONTINUE or ABORT command.  The ABORT
          command immediately terminates the command in progress
          identified by CMDID and the connection returns to the
          Authenticated state.  The CONTINUE command instructs the
          server to continue processing the command identified by the
          CMDID.

4.7.

          4.6 Data Elements

          The data elements for CAP are [MIME] encapsulated iCalendar
          objects.

5.

          5  Formal Command Syntax

5.1.
          5.1 Searching and Filtering

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          This section describes CAPs selecting and filtering entities
          within a calendar store. It is based on the Standard Query
          Language (SQL) defined in [SQL].

5.1.1.

          5.1.1  Grammar For Search Mechanism

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

             expand     = "EXPAND" ":" ( "TRUE" / "FALSE")
                        # If not specified, the default is EXPAND:FALSE .

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

             maxresults = integer

             maxsize    = integer

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

             queryname  = "QUERYNAME:" text

             query      = "QUERY:" ( query-min / query-92 )
             #
             # NOTE: query-min MUST be implemented in CSs.
             #
             #   query-92 is ONLY used if CAPABILITY returns SQL-92
             #   as the QUERYLEVEL value or if QUERYLEVEL is not
             #    specified.
             #

             query-min      = capselect-min capfrom-min capwhere-min

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

             capmin-col     = # Any property name found in any of the
                              components.

             capmin-cols    = ( capmin-col / capmin-col ","
                              capmin-cols )

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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

             capmin-cmp     = ( colname cmpmin-oper colvalue
                            / colname cmpmin-oper colvalue
                              capmin-logical capmin-cmp )

             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 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 a
                              # WHERE clause.

             caporderby-92  = # Any valid [SQL] string that goes into a
                              # ORDERBY clause.

5.1.2.

          5.1.2  SQL-MIN notes

          (1) No inlined spaces are allowed if not in the grammar above.

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

              Use 'VEVENT,VTODO', not 'VEVENT, VTODO'
              Use 'DTSTART <= 20000605T131313Z', not
                  'DTSTART<=  20000605T131313Z'.
              Use ' AND ' and ' OR ', not 'AND' and not 'OR'.

          (3) There is no ORDERBY.  Sorting will take place in the order
              the columns are supplied in the command.

          (4) The CS MUST sort at least the first column.
 The column.The CS MAY sort
              additional columns.

          (5) If EXPAND=FALSE and if colname is "*" sorting will be by
              the DTSTART  value ascending.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

              If EXPAND=TRUE and if colname is "*" sorting will be by
              the RECURRENCE-ID value ascending.

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

          (6) SQL-MIN MUST be implemented.

5.1.3.

          5.1.3  SQL-92 notes

          (1) Although this memo specifies that any [SQL] query can be used. Some
          used, some of the [SQL] grammar is optional and therefore
they are also is
          considered optional in CSs advertising an SQL-
92 SQL-92
          implementation with CAPABILITY.

          (2) A CS implementation MAY implement SQL-92. If a CS does not
          implement SQL-92 then it MUST advertise SQL-MIN in the
          capability reply.

5.1.4.

          5.1.4  Example, Query by UID

          This example would select the entire contents of uid123 and
          not expand any multiple instances of the component.  If the
          CUA does not know if 'uid123' was a VEVENT, VTODO, VJOURNAL,
          or other component, then all components that 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 that 'uid123' was
          a property in a component other than a VTODO or VEVENT.

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

          This example would select the entire contents of uid123 and
          would expand any instances of the component after applying any
          recurrence rules. This query could select multiple instances
          of components each with the same UID.  Each instance would
          have a unique RECURRENCE-ID of the expanded component.

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

5.1.5.

          5.1.5  Query by Date-Time range

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          This query selects the entire contents of every booked VEVENT
          that has an instance less than or equal to July 31st, 2000
          23:59:59 Z and greater than or equal to July 1st, 2000
          00:00:00 Z

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

5.1.6.

          5.1.6  Query for all Non-Booked Entries
          This example selects the entire contents of all scheduling
          (non-booked) VEVENTS in the CS. The default for EXPAND is
          FALSE, so the recurrence rules will not be expanded.

            BEGIN:VQUERY
            QUERY:SELECT * FROM VEVENT,VTODO WHERE METHOD != 'CREATE'
            END:VQUERY

   And this one only

          The following example fetches the UIDs of all non-booked
          VEVENTs and VTODOs.

            BEGIN:VQUERY
            QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD != 'CREATE'
            END:VQUERY

5.1.7.

          5.1.7  Query with Subset of Properties by Date/Time

          This MUST implement is similar to the one above, except only
          the named properties will be selected and all booked and non-
          booked components will be selected that have a DTSTART from
          Feb 1st to Feb 10th.

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

5.1.8. Find all

          5.1.8  Components With Alarms In A Range
          This example fetches all components with an Alarm Within alarm that
          triggers within the
Specified Range specified time range. In this case only
          the UID, SUMMARY, and DESCRIPTION will be selected for all
          booked VEVENTS that have an alarm between the two date-times.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

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

6.

          6  Access Rights

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

          Individual calendar access rights MUST be specifically granted
          to an authenticated calendar user (i.e., UPN); all rights are
          denied unless specifically granted.

          Properties within a VCAR must be evaluated in the order
          provided.

6.1.

          6.1 VCAR Inheritance

          Calendar access rights specified in a calendar store are
          inherited as default calendar access rights for any calendar
          in the parent calendar store. Likewise, any calendar access
          rights specified in a root calendar are inherited as default
          calendar access rights for any sub- calendar to the root
          calendar. By implication, calendar access rights specified in
          a sub-calendar are inherited as default calendar access rights
          for any calendars that are hierarchically below 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.

6.2.

          6.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 While access
          control may allow a UPN to store an event on a particular
          calendar. , the CONFLICTS Calendar or component setting may
          prevent it, returning an error code "6.3"

7.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          7  Commands and Responses

          CAP commands and responses are described in this section.

          Command arguments, identified by "Arguments:" in the command
          descriptions below, are described by function, not by syntax.
          The precise syntax of command arguments is described in the
          Formal Syntax section.

          Some commands cause specific server data to be returned; these
          are identified by "Data:" in the command descriptions below.
          See the response descriptions in the Responses section for
          information on these responses, and the Formal Syntax section
          for the precise syntax of these responses.

          The "Result:" in the command description refers to the
          possible status responses to a command, and any special
          interpretation of these status responses.

          Commands have the general form:

                  <command> [arguments...]

          where <command> is a command listed in the table above. A
          command MAY have arguments. Arguments are defined in the
          detailed command definitions below.

          Responses to commands have the following general form:

                  responseCode [sep transportDescr sep
                  [applicationDescr]]
                  CRLF "." CRLF

          In the examples below, lines preceded with "S:" refer to the
          sender and lines preceded with "R:" refer to the receiver.
          Lines in which the first non-whitespace character is a "#" are
          editorial comments and are not part of the protocol.

7.1.

          7.1 Transfer Protocol Commands

7.1.1.

          7.1.1  Initial Connection

          Arguments:  none

          Data:       none

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          Result:     2.0  - success.
                      8.1  - server too busy

          Upon session startup, the server sends a response of 2.0 to
          indicate that it is ready to receive commands. A response of
          8.1 indicates that the server is too busy to accept the
          connection. In addition, the general capabilities of the CS
          are reported in the response from the CS. These capabilities
          may be different than those reported in the authenticated
          state.

7.1.2.

          7.1.2  ABORT Command

          Arguments:  [CMDID]

          Data:       none

          Result:     2.0 - success
                      2.2 - no command is in progress

          The ABORT command is issued by the CUA to stop a command.  A
          common usage could be to ABORT a command whose latency time
          has been exceeded. When the latency time is specified on the
          SENDATA command, the CS must issue a reply to the CUA within
          the specified time. It may be a reply code indicating that the
          CS has not yet processed the request. The CUA must then tell
          the server whether to continue or abort.

          The CUA can issue the ABORT command at any time after the
          SENDATA command has been completed but before receiving a
          reply.

          If CMDID is supplied then the command identified by CMDID is
          aborted.

          If CMDID is not supplied then the fist command that is still
          pending is aborted.

7.1.3.

          7.1.3  AUTHENTICATE Command

          Arguments:  <SASL mechanism name> [<initial data>]

          Data:       continuation data may be requested

          Result:
            2.0 - Authenticate completed, now in authenticated

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                  state.
           6.0 -  Failed authentication.
           6.1 -  Authorization identity refused.
           6.2 -  Sender aborted authentication, authentication
                exchange cancelled.
           6.3 -  Unsupported Authentication Mechanism.
           6.4 -  Temporary failure (back end authentication
                  server down).
           6.5 -  Authentication exchange cancelled.
           6.6 -  Authentication mechanism too weak.
           6.7 -  Encryption required.
           6.8 -  Pass phrase expired.  The pass phrase was
                  correct but expired. The user will have to
                  contact a pass phrase change server prior to
                  authenticating.
           6.9 -  The user is valid but the server does not
                  have an entry in the authentication database
                  for the requested mechanism (e.g., DIGEST-
                  MD5). If the user successfully authenticates
                  using a plain text password, then the back
                  end back end entry will be updated.  Note
                  that if the client chooses to fall back to
                  plain text password authentication it should
                  enable an encryption layer or get user-con-
                  firmation that a one-time transition is ac-
                  ceptable.
           6.10 -  User account disabled. The user will have to
                   contact the system administrator to  get  the
                   account re-enabled.
            9.1 -  Unexpected command.

          The capabilities of the CS in the authenticated state are
          reported in the response from the CS. These may be different
          than the capabilities in the Connected, but unauthenticated
          state.

          The AUTHENTICATE command is used by the CUA to identify the
          user to the CS. CAP supports a number of authentication
          methods, the SASL specification for authentication is the
          preferred method.

          If STARTTLS is negotiated prior to the AUTHENTICATE command,
          the client MUST discard all information about the CS
          capabilities fetched prior to the TLS negotiation.  In
          particular, the value of supported SASL Mechanisms MAY be
          different after TLS has been negotiated.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          If a SASL security layer is negotiated, the client MUST
          discard all information about the CS capabilities fetched
          prior to SASL.  In particular, if the client is configured to
          support multiple SASL mechanisms, it SHOULD fetch supported
          SASL Mechanisms both before and after the SASL security layer
          is negotiated and verify that the value has not changed after
          the SASL security layer was negotiated.  This detects active
          attacks which remove supported SASL mechanisms from the
          supported SASL Mechanisms list.

          <initial data> is an optional parameter which can be used for
          mechanisms which require an initial response from the CUA.

          The AUTHENTICATE command is followed by an authentication
          protocol exchange, in the form of a series of CS challenges
          and CUA responses, per the relevant RFC that describes the
          specific SASL mechanism being used.

          Cancelling the authentication process during its negotiation
          is implementation specific and not within scope of the CAP
          specification.

          If a security layer was negotiated it comes into effect for
          the CS starting with the first octet transmitted after the
          CRLF which follows the 2.0 reply code, and for the CUA
          starting with the first octet after the CRLF of its last
          response in the authentication exchange. Encrypted data is
          transmitted as described in SASL.

          The service name specified by this protocol's profile of SASL
          is "cap". [EDITORS NOTE: this must be registered with IANA,
          has anyone done this yet?]

          The result of the AUTHENTICATE command includes data
          indicating the identity which has been assigned to the
          session, derived from the supplied authentication credentials,
          and/or authorization identifier.  A CAP session does not have
          an identity until the CUA has issued the "AUTHENTICATE"
          command.

          The CUA may not issue the "AUTHENTICATE" command multiple
          times, even if the first attempt was aborted. If a CUA
          attempts to do this the CS must terminate the session.

          Here is an example of a successful authentication:

             C: AUTHENTICATE KERBEROS_V4
             S: AmFYig==

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

             C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
             S: or//EoAADZI=
             C: DiAF5A4gA+oOIALuBkAAmw==
             S: 2.0
             S: .
             S: Content-Type:text/calendar; method=REQUEST; charset=US-
ASCII
             S:  charset=US-ASCII
             S: Content-Transfer-Encoding: 7bit
             S:
             S: BEGIN:VCALENDAR BEGIN:VCAP
             S: PRODID:-//ACME/CAPserver//EN
             S: VERSION:2.1
             S: IDENTITY=bill@example.com
             S: CAPVERSION=1.0
             S: ITIPVERSION=1.0
             S: AUTH=KERBEROS_V4
             S: AUTH=DIGEST_MD5
             S: CAR=CAR-FULL-1
             S: MINDATE=19700101T000000Z
             S: MAXDATE=20370201T000000Z
             S: END:VCALENDAR END:VCAP
             S: .

          This example shows a failed authentication:

             C: AUTHENTICATE KERBEROS_V4

             S: AmFYig==
             C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
             S: .
             S: 6.0
             S: .
             S: .

7.1.3.1.

          7.1.3.1   AUTHENTICATE ANONYMOUS

          RFC-2245 defines the Anonymous SASL mechanism. This RFC states
          that "the mechanism consists of a single message from the
          client to the server. The client sends optional trace
          information in the form of a human readable string. The trace
          information should take one of three forms: an Internet email
          address, an opaque string which does not contain the '@'
          character and can be interpreted by the system administrator
          of the client's domain, or nothing. For privacy reasons, an
          Internet email address should only be used with permission
          from the user."

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          RFC-2245 goes on to state, "A client which uses the user's
          correct email address as trace information without explicit
          permission may violate that user's privacy." Information about
          who accesses an anonymous CS on a sensitive subject (e.g., AA
          meeting times and locations) has strong privacy needs.
          "Clients should not send the email address without explicit
          permission of the user and should offer the option of
          supplying no trace token -- thus only exposing the source IP
          address and time."

          Example of CUA using the Capability command followed by an
          anonymous authentication:

             C: CAPABILITY
             S: 2.0
             S:CAPVERSION=1.0
             S:AUTH=KERBEROS_V4
             S:AUTH=DIGEST_MD5
             S:AUTH=ANONYMOUS
             S:.
             C:AUTHENTICATE ANONYMOUS
             S:+
             C:c21yaGM=
             S:2.0

          Subsequent to the initial Anonymous Authentication with a CS,
          a CUA will have to provide a UPN for some CAP operations. For
          anonymous access the UPN that MUST be used by the CUA is "@",
          a UPN with a null username and null realm. The user's normal
          UPN MUST not be used for the subsequent CAP operations.

          Note that the CS implementation may have internal audit logs
          that use the user's asserted UPN as trace information.
          However, this UPN will not appear on the wire after the
          initial SASL anonymous authentication.

          Use of the "@" UPN and wild-carding of UPNs within VCARs are
          covered in

          Section <forward ref>.

7.1.4.

          7.1.4  CALIDEXPAND Command

          Arguments:  CalID

          Data:       no specific data for this command

          Result:     2.0 Successful, and requested data follows

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

               2.1 Permission Denied
               2.2 Requested CSID not found
               2.3 Result exceeds MAXEXPANDLIST
               2.4 Misc. EXPAND error

          Return the members of the argument CalID.  Successful result
          yields one or more Calendars and/or Resource Calendars.  More
          than one C or RC returned implies that the CalID was a CC.

          Example:

          Example #1: Request lookup of CSID which is a Calendar
          Collection

             C: CALIDEXPAND cap://cal.example.com/calid14
             S: 2.0 cap://cal.example.com/calid14
             S: cap://cal.example.com/calid2
             S: cap://cal.example.com/calid5
             S: cap://cal.example.com/calid66
             S: .

          Example #2: Request lookup of a CSID which is a Resource Calendar

             C: CALIDEXPAND cap://cal.example.com/conf5
             S: 2.0 cap://cal.example.com/conf5
             S: cap://cal.example.com/conf5
             S: .

          Example #3: Request CSID which exceeds MAXCALIDEXPANDLIST

             C: CALIDEXPAND cap://cal.example.com/calid76
             S: 2.0 cap://cal.example.com/calid76
             S: cap://cal.example.com/calid3
             S: cap://cal.example.com/calid12
             S: cap://cal.example.com/calid21
             S: cap://cal.example.com/calid33
             S: 2.3 Expansion resulted in too much data
             S: .

          Example #4: CS loses contact with directory server during
          CALIDEXPAND

             C: CALIDEXPAND cap://cal.example.com/calid76
             S: 2.0 cap://cal.example.com/calid76
             S: cap://cal.example.com/calid3
             S: cap://cal.example.com/calid5
             S: 2.4 Lost contact with directory server
             S: .

7.1.5.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          7.1.5  CAPABILITY Command

          Arguments:  none

          Data:       none

          Result:     capabilities as described below

          The CAPABILITY command returns information about the CAP
          server given the current state of the connection with the
          client. The values returned may differ depending on whether
          the connection is in the Connected or the Authenticated state.
          The return values may also be different for a secure versus a
          non-secure connection.

          Client implementations SHOULD NOT require any capability name
          beyond those defined in this specification, and MAY ignore any
          non-standard, experimental capability names. Non-
standard Non-standard
          experimental capability names MUST be prefixed with the text
          "X-". The prefix SHOULD also include a short character vendor
          identifier For example, "X-FOO-
BARCAPABILITY", "X-FOO-BARCAPABILITY", for the non-standard non-
          standard "BARCAPABILITY" capability of the implementor "FOO".
          This command may return different results in the Connected
          state versus the Authenticated state. It may also return
          different results depending on the UPN.

          Capability   Occurs     Description
          -------------------------------------------------------
          AUTH         1+         The authentication mechanisms
                                  supported. Implementations MUST
                                  implement at least

          CAPVERSION   1          Revision of CAP, MUST include at
                                  least "1.0". Comma separated
                                  values.

          ITIPVERSION  0 or 1     Revision of ITIP, MAY be present.
                                  If present, it MUST include at
                                  least "1.0"
          CAR          0 or 1     Indicates level of CAR support.
                                  CAR-MIN or CAR-FULL-1. If not
                                  specified the default is
                                  CAR-FULL-1.  Implementations
                                  MUST implement CAR-MIN.
                                  Implementations MAY implement
                                  CAR-FULL-1.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          QUERYLEVEL   0 or 1     Indicates level of SQL support.
                                  SQL-MIN or SQL-92. If not
                                  specified the default is SQL-92.
                                  Implementations MUST implement
                                  SQL-MIN.  Implementations MAY
                                  implement SQL-92.

          MAXICALOBJECTSIZE
                       0 or 1     An integer value that specifies
                                  The largest ICAL object the server
                                  will accept in bytes. Objects
                                  larger than this will be rejected.
                                  A value of zero (0) indicates
                                  unlimited. The default is zero (0)
                                  if not specified.

          MAXDATE      0 or 1     The datetime value in GMT beyond
                                  which the server cannot accept. If
                                  not specified the default is
                                  99991231T235959Z.

          MAXCALIDEXPANDLIST
                       0 or 1     An integer value that specifies
                                  the maximum number of CalIDs that
                                  can be returned by the CALIDEXPAND
                                  Command. A value of zero (0)
                                  indicates unlimited which is the
                                  default if not specified.

          MAXUPNEXPANDLIST
                       0 or 1     An integer value that specifies
                                  the maximum number of UPNs that
                                  can be returned by the UPNEXPAND
                                  Command. A value of zero (0)
                                  indicates unlimited which is the
                                  default if not specified.

          MINDATE      0 or 1     The datetime value prior to which
                                  the server cannot accept. If not
                                  specified the default is
                                  00000101T000000Z.

          PIPELINE     0 or 1     An integer value that specifies
                                  the maximum number of commands a
                                  CUA may send without the CUA
                                  waiting for a reply from the CS.
                                  If not specified, the default
                                  value is one (1). A value of zero
                                  (0)indicates unlimited.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          AUTOLOGOUTTIME
                       0 or 1     An integer value that specifies
                                  the default idle time in seconds
                                  the CS will wait before
                                  disconnecting an idle CUA.If the
                                  CS is busy the CS may adjust down
                                  the auto-logout timer.  If not
                                  specified, the value is 15 minutes
                                  (900 seconds). A value of zero (0)
                                  indicates unlimited connect time
                                  is allowed.

            Example:

            C: CAPABILTIY
            S: 2.0
            S: .
            S: CAPVERSION=1.0
            S: ITIPVERSION=1.0
            S: AUTH=KERBEROS_V4
            S: AUTH=DIGEST_MD5
            S: .

7.1.6.

          7.1.6  CONTINUE Command

          Arguments: latency time in seconds (optional)

          Data:    none

          Result:   results from the command in progress
                    2.0.2 - reply pending.

          The CONTINUE command is issued by the client in response to a
          SENDATA timeout. When a timeout value is specified on the
          SENDDATA command, the server must issue a reply to the client
          within the specified time. If the latency time has elapsed
          prior to the server completing the command it returns a
          timeout response code. If the client wants the server to
          continue processing the command it responds with the CONTINUE
          command.

          If latencyTime is present, it must be a positive integer that
          specifies the maximum number of seconds the client will wait
          for the next response. If it is omitted, the receiver waits an
          indefinite period of time for the response.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          In this example, the client requests a response from the
          server every 10 seconds.

            C: SENDDATA:10
            C: Content-Type:text/calendar; method=READ; component=VEVENT
            C:
            C: BEGIN:VCALENDAR BEGIN:VCAP
            # etc
            C: END:VCALENDAR END:VCAP
            C: .
            # after 10 seconds...
            S: .
            S: 2.0.2
            S: .
            S: .
            C: CONTINUE:10
            S: 2.0
            S: .
            S: Content-type:text/calendar;
            S:   Method=RESPONSE;Component=VDATA;
            S: Optinfo=VERSION:2.1
            S:
            S: BEGIN:VCALENDAR BEGIN:VCAP

            S: VERSION:2.1
            S: CALID:cap://cal.example.com/relcal2
            # etc.
            S: END:VCALENDAR END:VCAP
            S: .

7.1.7.

          7.1.7  DISCONNECT Command

          Arguments: none

          Data:

          Result:   2.0

          The DISCONNECT command is used by a client to terminate a
          connection. It always succeeds.

          The CUA MUST wait for the CS 2.0 reply to ensure that TCP/IP
          (which knows nothing about CAP) can be sure the connection
          should go away. This avoids the CS connection being stuck in
          TCP-WAIT state.

          Example:

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            C: DISCONNECT
            # [ed. Note: should the client now wait for a response from
          the
            server
            #  before disconnecting? ]
            S: 2.0
            S: .
            S: .
            S: <drops connection>
            C: <drops connection>

          7.1.8. IDENTIFY Command

          Arguments: Identity to assume

          Data:      None

          Result:    2.0
                      .4 Identity not permitted

          The "IDENTIFY" command allows the CUA to select a new identity
          to be used for calendar access. This command may only be
          called in the Identified State.

          The CS determines through an internal mechanism if the
          credentials supplied at authentication permit the assumption
          of the selected the identity. If they do the session assumes
          the new identity, otherwise a security error is returned.

7.1.9.

          7.1.8  SENDDATA Command

          Arguments: [latencyTime]

          Data:      a [MIME] encapsulated iCalendar object

          Result:    2.0.1 - Server will now accept input until
                             <CRLF>.<CRLF> is encountered.

          The SENDDATA command is used to send calendar requests and
          commands to the server. After a response code of 2.0.1 is
          issued the CUA sends a [MIME] encapsulated iCalendar object to
          the server. The end of this [MIME] data is signaled by the
          special sequence <CRLF>.<CRLF> .

          7.1.10. STARTTLS Command

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          Arguments: None

          Data:      None

          Result:    2.0
                     5  TLS not supported

          The "STARTTLS" command is issued by the CUA to indicate to the
          CS that it wishes to negotiate transport level security using
          [TLS]. If the CS does not support TLS it returns status code
          6.5. If the CS supports TLS it issues an initial response of
          2.0.12 indicating that the CUA should proceed with TLS
          negotiation. Once the TLS negotiation is complete the server
          returns the response code 2.0.

          After issuing the "STARTTLS" command the CUA issues the
          "AUTHENTICATE" command. The SASL external mechanism may be
          used if the CUA wishes to use the authentication id which was
          used in the TLS negotiation.

          The CUA MUST NOT issue a "STARTTLS" if it has already issued
          an "AUTHENTICATE" or "STARTTLS" command in this session. If a
          CUA does this the CS must terminate the session.

          The following examples illustrate the use of the "STARTTLS"
          command:

          Unsupported TLS:

            C: STARTTLS
            S: 6.5

          Supported TLS:

            C: STARTTLS
            S: 2.0.12
             <tls negotiation>
            S: 2.0

            S: .
            S: .

7.1.10.1.

          7.1.8.1   UPNEXPAND Method

          Arguments: UPN

          Data:      no specific data for this command

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          Result:    2.0 - success
                     2.1 Permission Denied
                     2.2 Requested UPN not found
                     2.3 Result exceeds MAXUPNEXPANDLIST
                     2.4 Misc. UPNEXPAND error

          Return the members of the argument UPN. Successful result
          yields one or more CalIDs. More than one CalID returned
          implies that the UPN was a UG.

          Example #1: Request lookup of a UPN which is a CU

            C: UPNEXPAND upn@example.com
            S: 2.0 upn@example.com
            S: cap://cal.example.com/calid3
            S: .

          Example #2: Request lookup of UPN which is a UG

            C: UPNEXPAND group@example.com
            S: 2.0 group@example.com
            S: cap://cal.example.com/calid3
            S: cap://cal.example.com/calid6
            S: cap://cal.example.com/calid1342
            S: .

          Example #3: Request lookup exceeds MAXUPNEXPANDLIST

            C: UPNEXPAND group@example.com
            S: 2.0 group@example.com
            S: cap://cal.example.com/calid3
            S: cap://cal.example.com/calid12
            S: cap://cal.example.com/calid21
            S: cap://cal.example.com/calid33
            S: 2.3 Lookup resulted in too much data
            S: .

          Example #4: CS loses contact with directory server during
          UPNEXPAND

            C: UPNEXPAND group@example.com
            S: 2.0 group@example.com
            S: cap://cal.example.com/calid3
            S: cap://cal.example.com/calid5

            S: 2.4 Lost contact with directory server
            S: .

7.2.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          7.2 Application Protocol Commands

7.2.1.

          7.2.1  Calendaring Commands

          The following methods provide a set of calendaring commands in
          CAP. Calendaring commands (or methods) allow a CU to directly
          manipulate a calendar.

          Calendar access rights can be granted for the more generalized
          access provided by the calendar commands.

          7.2.1.1   Restriction Tables

          Commands are sent to CAP servers encapsulated in iCalendar
          objects. The reply to these commands are also encapsulated in
          iCalendar objects. The restriction tables listed in the
          commands below describe the composition of the iCalendar data
          for these commands and replies.

          The Presence column uses the following values to assert
          whether a property is required, is optional and the number of
          times it may appear in the iCalendar object. A Comment may be
          provided to further clarify the presence criteria.

          The 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 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 tables list every component and property, their
          purpose is not to define the meaning of the component or
          property.

          There will be a RESPONSE-STATUS REQUEST-STATUS for each VCALENDAR and
          component created, modified, deleted, or requested. The number
          of RESPONSE-STATUS REQUEST-STATUS values returned MUST be equal to the number
          of TARGETS times the number of objects in the command. The
          responses MUST be ordered first by TARGET then by the order of
          the objects as supplied in the command.

7.2.1.1.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          7.2.1.2   CREATE Method

          Arguments: none

          Data:    no specific data for this command

          Result:   2.0 - successfully created the component or calendar
                    6.0 - Permission denied
                    6.1 - Container(s) not found
                    6.2 - Calendar or component already exists
                    6.3 -
                    Bad args

          The CREATE method is used to create a new iCalendar object of
          type objtype. The property TARGET specifies the container(s)
          for the create. The type of object wrapped inside of the
          VCALENDAR/CREATE object is the object type(s) being created.
          When creating a new calendar at the top level, the CSID is
          specified. Otherwise the container will be a CalID.

          Restriction table

          Component/Property     Presence Comment
          -------------------    ---------------------------------    -------- -----------------------------
          VCAP                   1+       The CUA can send up
                                          PIPELINE commands
                                          without processing a
                                          response

          . CMDID                0 or 1   If CMDID is not supplied,
                                then there must not be
                                pending replies to previous
                                command.

. VERSION              1        MUST be 2.0
          . [IANA-PROP]          0+       any IANA registered
                                          property

          . VCOMMAND             1        MUST at least one container
                                          (VCALENDAR, VCAR, VQUERY,
                                          VEVENT, VTODO, VJOURNAL)
          . . CMDID              0 or 1   If CMDID is not supplied,
                                          then there must not be
                                          pending replies to previous
                                          command.

          . . [IANA-PROP]        0+       any IANA registered
                                          property
          . . METHOD             1        MUST be CREATE.
          . . TARGET             1+       MUST be the CSID or CALID

          . . VCALENDAR          0+

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          . . . CALMASTER        0 or 1
          . . . NAME             0 or 1
          . . . OWNER            1+
          . . . RELCALID         1
          . . . TZID             0 or 1
          . . . [IANA-PROP]      0+       any IANA registered
                                          property

          . . VCAR               0+
          . . . CARID            0 or 1
          . . . DENY             0+       Note, there must be at
                                          least one GRANT or DENY
                                          within the VCAR.
          . . . GRANT            0+       Note, there must be at
                                          least one GRANT or DENY
                                          within the VCAR.
          . . . [IANA-PROP]      0+       any IANA registered
                                          property

          . . VQUERY             0+
          . . . EXPAND           0 or 1
          . . . MAXRESULTS       0 or 1
          . . . MAXSIZE          0 or 1
          . . . QUERYNAME        1
          . . . QUERY            1
          . . . [IANA-PROP]      0+       any IANA registered
                                          property

          . . VEVENT             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
          . . . UID              1

          . . . ATTACH           0+
          . . . CATEGORIES       0 or 1
          . . . CLASS            0 or 1
          . . . COMMENT          0 or 1
          . . . CONTACT          0+
          . . . CREATED          0 or 1
          . . . DESCRIPTION      0 or 1   Can be null
          . . . DTEND            0 or 1   if present DURATION MUST
                                          NOT be present
          . . . DTSTAMP          1
          . . . DTSTART          1
          . . . DURATION         0 or 1   if present DTEND MUST NOT
                                          be present

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          . . . EXDATE           0+
          . . . EXRULE           0+
          . . . GEO              0 or 1
          . . . LAST-MODIFIED    0 or 1
          . . . LOCATION         0 or 1
          . . . METHOD           1        <<placeholder. it may move
                                          to meta-info>>
          . . . ORGANIZER        1
          . . . PRIORITY         0 or 1
          . . . RDATE            0+
          . . . RECURRENCE-ID    0 or 1   only if referring 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 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        0 or 1   MUST be 1 if multiple
                                          VALARMs are present in
                                          same component.
          . . . . 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

          . . VTODO              0+
          . . . ATTENDEE         0+
          . . . SEQUENCE         0 or 1  MUST be present if value is
                                         greater than 0, MAY be
                                         present if 0

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          . . . SUMMARY          1       Can be null.
          . . . UID              1

          . . . ATTACH           0+
          . . . CATEGORIES       0 or 1  This property may contain a
                                         list of values
          . . . CLASS            0 or 1
          . . . COMMENT          0 or 1
          . . . CONTACT          0+
          . . . CREATED          0 or 1
          . . . DESCRIPTION      0 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
          . . . METHOD           1       <<placeholder. it may move
                                         to meta-info>>
          . . . ORGANIZER        1
          . . . PRIORITY         1
          . . . PERCENT-COMPLETE 0 or 1
          . . . RDATE            0+
          . . . RECURRENCE-ID    0 or 1  MUST only if referring 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 of values
          . . . RRULE            0+
          . . . STATUS           0 or 1  MAY be 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        0 or 1  MUST be 1 if multiple

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                                         VALARMs are present in
                                         same component.
          . . . . 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

          . . VJOURNAL           0+
          . . . ATTENDEE         0
          . . . DESCRIPTION      1    Can be null.
          . . . DTSTAMP          1
          . . . DTSTART          1
          . . . ORGANIZER        1
          . . . UID              1

          . . . ATTACH           0+
          . . . CATEGORIES       0 or 1 This property MAY contain a list
          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
          . . . METHOD           1        <<placeholder. it may move
                                          to meta-info>>
          . . . RDATE            0+
          . . . RECURRENCE-ID    0 or 1   MUST only if referring to
                                          an instance of a recurring
                                          calendar component.
                                          Otherwise it MUST NOT be
                                          present.
          . . . RELATED-TO       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 be null
          . . . URL              0 or 1
          . . . X-PROPERTY       0+

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

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

          . . VFREEBUSY          0

          . . VTIMEZONE          0+       MUST be present if any
                                          date/time refers to 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
          . . . . . 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

          Server Restriction Table for the CREATE command

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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          VCAP                   1+
          . VCALENDAR            1+
          . . TARGET             1

          . . VERSION            1        MUST be 2.0

          . . CMDID              0 or 1   MUST be returned if the
                                          request contained
                                          a CMDID
          . . RESPONSE-STATUS REQUEST-STATUS     0        if not creating a calendar
                                 1+       if creating a calendar

          . . . VCAR             0+
          . . . . RESPONSE-STATUS REQUEST-STATUS   1+
          . . . . *              0        No other VCAR properties
                                          are present
          .
          . . . VCOMMAND         0

          . . . VEVENT           0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *              0        No other VEVENT properties
                                          are present
          . . . . VALARM         0        if VEVENT was successfully
                                          saved
                                 1+       if there were errors saving
                                          alarms
          . . . . . RESPONSE-STATUS REQUEST-STATUS  1+

          . . . VFREEBUSY        0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *              0        No other VFREEBUSY
                                          properties are present

          . . . VJOURNAL         0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *              0        No other VJOURNAL
                                          properties are present

          . . . VQUERY           0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *              0        No other VQUERY properties
                                          are present

          . . . VTODO            0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *              0        No other VTODO properties
                                          are present

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

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

7.2.1.1.1.

          7.2.1.2.1       Creating New Calendars

          Example to create two new calendars different containers. In
          the following example, the client is in the Authenticated
          state with CS cal.example.com.

            C: SENDDATA
            C: CONTENT-TYPE:
text/calendar;method=CREATE;component=VCOMMAND text/calendar; method=CREATE;
            C:   component=VCOMMAND
            C: Content-Transfer-Encoding:7bit
            C:
            C: BEGIN:VCALENDAR BEGIN:VCAP
            C: VERSION:2.1
            C: BEGIN:VCOMMAND
            C: METHOD:CREATE
            C: TARGET:cap://cal.example.com/
            C: TARGET:relcal4
            C: BEGIN:VCALENDAR
            C: RELCALID:relcalz1
            C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Bill's Soccer Team
            C: OWNER:bill
            C: CALMASTER:mailto:bill@example.com
            C: TZID:US_PST
            C: BEGIN:VCAR
            C: CARID:12345
            C: GRANT:UPN=bill;ACTION=*;OBJECT=*
            C: END:VCAR
            C: END:VCALENDAR
            C: BEGIN:VCALENDAR
            C: RELCALID:relcalz2
            C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Mary's personal
            C:   calendar
            C: OWNER:mary
            C: CALMASTER:mailto:mary@example.com
            C: TZID:US_PST
            C: BEGIN:VCAR
            C: CARID:12346
            C: GRANT:UPN=mary;ACTION=*;OBJECT=*
            C: END:VCAR
            C: END:VCALENDAR
            C: END:VCOMMAND
            C: END:VCALENDAR END:VCAP

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            C: .
            S: 2.0
            S: Content-Type:text/calendar; method=RESPONSE;
            S:   OPTINFO="CMDID:abcde"
            #  This 2.0 is the transport reply status and ends with a
            #  CRLF.CRLF (below)
            S: BEGIN:VCALENDAR BEGIN:VCAP
            S: METHOD:RESPONSE
            S: TARGET:cap://cal.example.com/
            S: REQUEST-STATUS:2.0
            S: END:VCALENDAR END:VCAP
            S: BEGIN:VCALENDAR BEGIN:VCAP
            S: METHOD:RESPONSE
            S: REQUEST-STATUS:2.0
            S: END:VCALENDAR END:VCAP
            S: .

          Example to create a new component.

            C: SENDDATA
            C: Content-Type:text/calendar; method=CREATE; charset=US-
ASCII
            C:   charset=US-ASCII
            C: Content-Transfer-Encoding:7bit
            C:
            C: BEGIN:VCALENDAR BEGIN:VCAP
            C: VERSION:2.1
            C: CMDID:abcde
            C: BEGIN:VCOMMAND
            C: METHOD:CREATE
            C: TARGET:cap://cal.example.com/relcal1
            C: TARGET:relcal2
            C: BEGIN:VEVENT

            C: DTSTART:99990307T180000Z
            C: UID:abcd12345
            C: DTEND:99990307T190000Z
            C: SUMMARY:Important Meeting
            C: END:VEVENT
            C: END:VCALENDAR END:VCOMMAND
            C: END:VCAP
            C: .
            S: 2.0
            S: Content-Type:text/calendar; method=RESPONSE;
            S:   OPTINFO="CMDID:abcde"
            S:
            S: BEGIN:VCALENDAR BEGIN:VCAP
            S: VERSION:2.1
            S: CMDID:abcde

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            S: METHOD:RESPONSE
            S: BEGIN:VEVENT
            S: TARGET::cap://cal.example.com/relcal1
            S: REQUEST-STATUS:2.9
            S: END:VEVENT
            S: BEGIN:VEVENT
            S: REQUEST-STATUS:2.9
            S: REQUEST-STATUS:2.10
            S: END:VEVENT
            S: END:VCALENDAR END:VCAP
            S: .

          The responce returns response contains the calendar (CALID) and UID of the
          component so that the CUA can match up the TARGET from
          multiple objects created on multiple calendards (TARGETs).

7.2.1.2.

          7.2.1.3   DELETE Method

          Arguments: none

          Data:    no specific data for this command

          Result:   2.0 - successfully deleted the component or calendar
                    Permission
                    Calendar or component not found
                    Bad args
                    Container(s) not found

          The DELETE method is used to delete a calendar or component.
          The TARGET properties specify the container(s) for the delete.
          When deleting a calendar at the top level, the CSID is
          specified. Otherwise the   container will be a CalID.

          Restriction Table

          Component/Property    Presence Comment
          -------------------   -------- ---------------------------
          VCAP                  1+       The CUA can send up
                                         PIPELINE commands
                                         without processing a
                                         response

           VERSION              1        MUST be 2.0

           VCOMMAND             1
            CMDID               0 or 1   If CMDID is not supplied,
                                         then there must
                                         not be pending replies to

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                                         previous command.

 VERSION              1        MUST be 2.0

 VCOMMAND             1
            METHOD              1        MUST be DELETE.
            TARGET              1+       MUST be a the CSID or CALID

            VQUERY              0+
             EXPAND             0    ?
             MAXRESULTS         0 or 1   Limit the solution set to
                                         no more than this many
                                         entries.
             MAXSIZE            0    ?
             QUERYNAME          1        Name by which this query is
                                         referenced
             QUERY              1        The query

          Server Restriction Table for the DELETE command

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

          VCAP                1+
          TARGET              1

          VERSION             1        MUST be 2.0

          CMDID               0 or 1   MUST be returned if the
                                       request contained a CMDID

          VCALENDAR                    Only if VCALENDARs were
                                       deleted
            REQUEST-STATUS    1
            *                 1+       No other VALARM properties
                                       are present

          VALARM              0+       Only if VALARM components
                                       were deleted
            REQUEST-STATUS    1
            *                 0        No other VALARM properties
                                       are present

          VCAR                0+       Only if VCAR components were
                                       deleted
            REQUEST-STATUS    1
            *                 0        No other VCAR properties are
                                       present

          VEVENT              0+       Only if VEVENT components
                                       were deleted
            REQUEST-STATUS    1+

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            *                 0        No other VEVENT properties
                                       are present

          VFREEBUSY           0
            REQUEST-STATUS    1+
            *                 0        No other VFREEBUSY properties
                                       are present

          VJOURNAL            0+       Only if VJOURNAL components
                                       were deleted
            REQUEST-STATUS    1+
            *                 0        No other VJOURNAL properties
                                       are present

          VQUERY              0+       Only if VQUERY components
                                       were deleted
            REQUEST-STATUS    1+
            *                 0        No other VQUERY properties
                                       are present

          VTIMEZONE           0+       Only if VTIMEZONE components
                                       were deleted
            REQUEST-STATUS    1+
            *                 0        No other VQUERY properties
                                       are present

          VTODO               0+       Only if VTODO components were
                                       deleted
            REQUEST-STATUS    1+
            *                 0        No other VTODO properties are
                                       present

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

          [Editors note: Issues:

          - Currently CAP requires that the server return a response
          status. However, if there are multiple components deleted,
          should the UID also be returned?

          - VQUERY EXPAND and MAXSIZE parameters do not seem to apply to
          deletion?

          - Can one use DELETE to remove all VALARMs and VTIMEZONEs that
          match a certain search criteria and that belong to all
          components, event though VALARMs and VTIMEZONEs never exist as
          independent components? Or should one use MODIFY? If they can

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          be deleted, do we return the REQUEST-STATUS of their deletion
          in a VEVENT or separately?

          - In the example in CAP where a calendar is deleted all the
          server returns is 2.0, nothing else?

           - We should not be able to delete any VFREEBUSY components?

           - Can we delete multiple calendars?

           - Currently one can not delete a VCALENDAR and some other
          component in the same DELETE command. This seems OK. Anyone
          see any need to be able to do this?

           - Should the MAXRESULTS property of VQUERY apply to deletion?
          We can use it to delete only the first n components that match.]
          match.
          ]

            Example to delete a VEVENT with UID 'abcd12345':

            C: SENDDATA
            C: Content-Type:text/calendar; method=DELETE;
          component=VCOMMAND
            C: Content-Transfer-Encoding:7bit
            C:

          C: BEGIN:VCALENDAR BEGIN:VCAP
            C: BEGIN:VCOMMAND
            C: METHOD:DELETE
            C: TARGET:cap://cal.foo.com/bill
            C: BEGIN:VQUERY
            C: QUERY:SELECT UID FROM VEVENT WHERE UID = 'abcd12345'
            C: END:VQUERY
            C: END:VCOMMAND
            C: END:VCALENDAR END:VCAP
            C: .
            S: 2.0
            S: Content-Type:text/calendar; method=DELETE;
            S:  component=VCOMMAND
            S:
            S: BEGIN:VCALENDAR BEGIN:VCAP
            S: METHOD:RESPONSE
            S: BEGIN:VEVENT
            S: REQUEST-STATUS:2.0
            S: END:VEVENT
            S: END:VCALENDAR END:VCAP
            S: .

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          And an example to delete the 'MrBill' calendar:

            C: SENDDATA
            C: Content-Type:text/calendar; method=DELETE;
            C:  component=VCOMMAND
            C: Content-Transfer-Encoding:7bit
            C:
            C: BEGIN:VCALENDAR BEGIN:VCAP
            C: BEGIN:VCOMMAND
            C: METHOD:DELETE
            C: TARGET:cap://cal.foo.com/MrBill
            C: END:VCOMMAND
            C: END:VCALENDAR END:VCAP
            C: .
            S: 2.0
            S: .

7.2.1.3.

          7.2.1.4   GENERATEUID Method

          Arguments: Number of UIDs to generate.

          Data:      new uids

          Result:    2.0

          GENERATEUID returns one or more new unique identifier which
          MUST be unique on the server's calendar store. It is
          recommended that the return value be a globally unique id.

          Example:

          C: GENERATEUID 2

          S: 2.0 abcde1234567-asdf-lkhh abcde1234567-asdf-3455

          [EDITORS NOTE: this example needs work. It's not packaged
          right]

7.2.1.4.

          7.2.1.5   MODIFY Method

          Arguments: none

          Data:     no specific data for this command

          Result:   2.0 - successfully modified the component or
                          calendar
                Permission

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                Calendar or component not found
                Bad args
                Container(s) not found

          The MODIFY method is used to change an existing calendar or
          component. TARGET specify the container(s) of the
          modification. When modifying a calendar at the top level, the
          CSID is specified. Otherwise the container will be a CalID.

          The format of the request is two or three containers inside of
          a VCOMMAND container:

            BEGIN:VCOMMAND
            [VQUERY]
            OLD-VALUES
            NEW-VALUES
            END:VCOMMAND

          If a VQUERY is present, then only objects matching the query
          results are modified.

          Restriction Table

          Component/Property     Presence Comment
          -------------------    -------- ---------------------------
          VCAP                   1+       The CUA can send up
                                          PIPELINE commands
                                          without processing a
                                          response

          . CMDID                0 or 1   If CMDID is not supplied,
                                then there must
                                not be pending replies to
                                previous command.

. VERSION              1        MUST be 2.0
          . [IANA-PROP]          0+       any IANA registered
                                          property

          . VCOMMAND             1        MUST have at least one
                                          container (VCALENDAR,
                                          VCAR, VQUERY, VEVENT,
                                          VTODO, VJOURNAL)
          . . CMDID                0 or 1 If CMDID is not supplied,
                                          then there must
                                          not be pending replies to
                                          previous command.
          . . [IANA-PROP]        0+       any IANA registered
                                          property
          . . METHOD             1        MUST be MODIFY
          . . TARGET             1+       MUST be the CALID

          . . VCALENDAR          0+

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          . . . CALMASTER        0 or 1
          . . . NAME             0 or 1
          . . . OWNER            1+
          . . . RELCALID         1
          . . . TZID             0 or 1
          . . . [IANA-PROP]      0+       any IANA registered
                                          property

          . . VCAR               0+
          . . . CARID            0 or 1
          . . . DENY             0+       Note, there must be at
                                          least one GRANT or DENY
                                          within the VCAR.
          . . . GRANT            0+       Note, there must be at
                                          least one GRANT or DENY
                                          within the VCAR.
          . . . [IANA-PROP]      0+       any IANA registered
                                          property

          . . VQUERY             0+
          . . . EXPAND           0 or 1
          . . . MAXRESULTS       0 or 1
          . . . MAXSIZE          0 or 1
          . . . QUERYNAME        1
          . . . QUERY            1
          . . . [IANA-PROP]      0+       any IANA registered
                                          property

          . . VEVENT             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
          . . . UID              1

          . . . ATTACH           0+
          . . . CATEGORIES       0 or 1
          . . . CLASS            0 or 1
          . . . COMMENT          0 or 1
          . . . CONTACT          0+
          . . . CREATED          0 or 1
          . . . DESCRIPTION      0 or 1   Can be null
          . . . DTEND            0 or 1   if present DURATION MUST
                                          NOT be present
          . . . DTSTAMP          1
          . . . DTSTART          1
          . . . DURATION         0 or 1   if present DTEND MUST NOT
                                          be present

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          . . . EXDATE           0+
          . . . EXRULE           0+
          . . . GEO              0 or 1
          . . . LAST-MODIFIED    0 or 1
          . . . LOCATION         0 or 1
          . . . METHOD           1         <<placeholder. it may move
                                             to meta-info>>
          . . . ORGANIZER        1
          . . . PRIORITY         0 or 1
          . . . RDATE            0+
          . . . RECURRENCE-ID    0 or 1   only if referring 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 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        0 or 1   MUST be 1 if multiple
                                          VALARMs are present in same
                                          component.
          . . . . 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

          . . VTODO              0+
          . . . ATTENDEE         0+
          . . . SEQUENCE         0 or 1   MUST be present if value is
                                          greater than 0, MAY be

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                                          present if 0
          . . . SUMMARY          1        Can be null.
          . . . UID              1

          . . . ATTACH           0+
          . . . CATEGORIES       0 or 1   This property may contain a
                                          list of values
          . . . CLASS            0 or 1
          . . . COMMENT          0 or 1
          . . . CONTACT          0+
          . . . CREATED          0 or 1
          . . . DESCRIPTION      0 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
          . . . METHOD           1        <<placeholder. it may move
                                          to meta-info>>
          . . . ORGANIZER        1
          . . . PRIORITY         1
          . . . PERCENT-COMPLETE 0 or 1
          . . . RDATE            0+
          . . . RECURRENCE-ID    0 or 1   MUST only if referring 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 of values
          . . . RRULE            0+
          . . . STATUS           0 or 1   MAY be one of COMPLETED,
                                          NEEDS-ACTION,
                                          IN-PROCESS, CANCELLED
          . . . URL              0 or 1

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

          . . . VALARM           0+

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          . . . . ACTION         1
          . . . . ALARMID        0 or 1   MUST be 1 if multiple
                                          VALARMs are present in
                                          same component.
          . . . . 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

          . . VJOURNAL           0+
          . . . ATTENDEE         0
          . . . DESCRIPTION      1        Can be null.
          . . . DTSTAMP          1
          . . . DTSTART          1
          . . . ORGANIZER        1
          . . . UID              1

          . . . ATTACH           0+
          . . . CATEGORIES       0 or 1   This property MAY contain a
                                          list 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
          . . . METHOD           1        <<placeholder. it may move
                                          to meta-info>>
          . . . RDATE            0+
          . . . RECURRENCE-ID    0 or 1   MUST only if referring to

                                          an instance of a recurring
                                          calendar component.
                                          Otherwise it MUST NOT be
                                          present.
          . . . RELATED-TO       0+
          . . . RRULE            0+
          . . . SEQUENCE         0 or 1   MUST be present if non-
                                          zero. MAY be
          . . . . .                       present if zero.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          . . . STATUS           0 or 1
          . . . SUMMARY          0 or 1   Can be null
          . . . URL              0 or 1
          . . . X-PROPERTY       0+
          . . . [IANA-PROP]      0+       any IANA registered
                                          property

          . . VFREEBUSY          0

          . . VTIMEZONE          0+       MUST be present if any
                                          date/time refers
                                          to 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
          . . . . . 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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          Server Restriction Table for the CREATE MODIFY command

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

          VCAP                  1+
          . VCALENDAR           1+
          . . TARGET            1

          . . VERSION           1        MUST be 2.0

          . . CMDID             0 or 1   MUST be returned if the
                                         request contained a CMDID
          . . RESPONSE-STATUS REQUEST-STATUS    0        if not creating a calendar
                                1+       if creating a calendar

          . . . VCAR            0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *             0        No other VCAR properties are
                                         present
          .
          . . . VCOMMAND        0

          . . . VEVENT         0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *            0         No other VEVENT properties
                                         are present
          . . . . VALARM       0         if VEVENT was successfully
                                         saved
                               1+        if there were errors saving
                                         alarms
          . . . . . RESPONSE-STATUS REQUEST-STATUS   1+

          . . . VFREEBUSY       0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *             0        No other VFREEBUSY
                                         properties are
                                         present

          . . . VJOURNAL        0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *             0        No other VJOURNAL properties
                                         are present

          . . . VQUERY          0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          . . . . *             0        No other VQUERY properties
                                         are present

          . . . VTODO           0+
          . . . . RESPONSE-STATUS REQUEST-STATUS    1+
          . . . . *             0        No other VTODO properties
                                         are present
          . . . . VALARM        0        if VTODO was successfully
                                         saved
                                1+       if there were errors saving
                                         alarms
          . . . . . RESPONSE-STATUS REQUEST-STATUS   1+

[Editor's

          [EditorĖs notes: Issues:
          freebusy - a cap server should dynamically calculate freebusy
          information - we recommend that you cannot create, modify, or
          delete  freebusy composers ]

          In the example below, the start and end time of the event with
          UID abcd12345 is changed and the LOCATION property is removed.

            C: SENDDATA
            C: Content-type:text/calendar; Method=MODIFY;
            C:  Component=VCOMMAND
            C:
            C: BEGIN:VCALENDAR BEGIN:VCAP
            C: VERSION:2.1
            C: BEGIN:VCOMMAND
            C: METHOD:MODIFY
            C: TARGET:relcal2
            C: BEGIN:VCOMMAND
            C: BEGIN:VQUERY
            C: QUERY:SELECT UID FROM VEVENT WHERE UID = 'abcd12345'
            C: END:VQUERY
            C: BEGIN:VEVENT
            C: DTSTART:19990421T160000Z
            C: DTEND:19990421T163000Z
            C: LOCATION:Joe's Diner
            C: END:VCOMMAND
            C: END:VEVENT

            C: BEGIN:VEVENT
            C: DTSTART:19990421T160000Z
            C: DTEND:19990421T163000Z
            C: END:VEVENT
            C: END:VCOMMAND
            C: END:VCALENDAR END:VCAP
            C: .

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            S: 2.0 cap://cal.example.com/relcal2

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

            C: SENDDATA
            C: Content-type:text/calendar; Method=MODIFY;
            C:  Component=VCOMMAND
            C:
            C: BEGIN:VCALENDAR BEGIN:VCAP
            C: VERSION:2.1
            C: BEGIN:VCOMMAND
            C: METHOD:MODIFY
            C: TARGET:relcal2
            C: BEGIN:VCOMMAND
            C: BEGIN:VEVENT
            C: LOCATION:Building 6
            C: END:VEVENT
            C: BEGIN:VEVENT
            C: LOCATION:New office lobby
            C: END:VEVENT
            C: END:VCOMMAND
            C: END:VCALENDAR END:VCOMMAND
            C: END:VCAP
            C: .
            S: 2.0 cap://cal.example.com/relcal2

7.2.1.5.

          7.2.1.6   MOVE Method

          Arguments: ContainerId

          Data:      data as described below

          Result:    2.0 - success
                     2.2 - will attempt operation on the remote cap CAP
                           server
                     Permission
                     Calendar already exists
                     Bad args
                     Parent Calendar(s) not found

          This method is used to move a calendar within the CS's
          hierarchy of calendars.

          Restriction Table
          Component/Property     Presence  Comment
          -------------------    -------- ---------------------
          VCAP                   1+       The CUA can send up

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                                          PIPELINE commands without
                                          processing a response

          . VERSION              1        MUST be 2.0

          . VCOMMAND             1        MUST have at least one
                                          VCALENDAR

          . . CMDID              0 or 1   If CMDID is not supplied,
                                          then there must not be
                                          pending replies to
                                          previous command.

          . VERSION              1        MUST be 2.0

. VCOMMAND             1        MUST have at least one
                                VCALENDAR

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

          . . METHOD             1        MUST be MOVE.
          . . TARGET             1        MUST be a the CSID or
                                          CALID

          . . VCALENDAR          1+
          . . . CALMASTER        0
          . . . NAME             0
          . . . OWNER            0
          . . . RELCALID         1
          . . . TZID             0
          . . . [IANA-PROP]      0+       any IANA registered
                                          property

          Server Restriction Table for the MOVE command

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

          VCAP                1+

          . VCALENDAR         1+

          . . TARGET          1
          . . VERSION         1        MUST be 2.0

          . . CMDID           0 or 1   MUST be returned if the
                                       request contained
                                       a CMDID
          . . RESPONSE-STATUS REQUEST-STATUS  1+

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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          [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?)
           2) Should we also be able to move components from one
          calendar to another? What if the calendars are owned by
          different users? (With components one can do a copy, then
          delete the original.)
           3) There was very little information about MOVE in CAP. Why
          was it added? Was there some major need for it?
           4) Can one move multiple calendars into one calendar?
          ]

7.2.1.6.

          7.2.1.7   NOOP Method

          Arguments: none

          Data:      none

          Result:    2.0 - success

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

7.2.1.7.

          7.2.1.8   READ Method

          Arguments: ContainerId

          Data:      data as described below

          Result:    2.0 -
                         - successful and the requested data follows
                     2.2 - will attempt read on the remote cap CAP server
                     Permission
                     Bad args

          Restriction Table

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

          Component/Property     Presence Comment
          -------------------    -------- ---------------------------
          VCAP                   1+       The first
returns two VEVENTS that match in that TARGET, the second
result returns only one VEVENT for the second TARGET.

  C: SENDDATA
  C: Content-type:text/calendar; Method=READ;
Component=VQUERY
  C:
  C: BEGIN:VCALENDAR
  C: VERSION:2.1
  C: METHOD:READ
  C: CMDID:xyz12345
  C: TARGET:relcal2
  C: TARGET:cap://bobo.ex.com/relcal3
  C: BEGIN:VQUERY
  C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
    FROM VEVENT
    WHERE DTEND >= '19990310T080000Z'
    AND DTSTART <= '19990310T190000Z'
    AND METHOD = 'CREATE'
  C: END:VQUERY
  C: END:VCALENDAR
  C: CUA can send
                                          PIPELINE commands
                                          without processing a
                                          response

          .
  S: VERSION              1        MUST be 2.0 cap://cal.example.com/relcal2
  S: Content-type:text/calendar; Method=RESPONSE;
Optinfo=VERSION:2.1
  S: Content-Transfer-Encoding: 7bit
  S:
  S: BEGIN:VCALENDAR
  S: VERSION:2.1
  S: METHOD:RESPONSE
  S: BEGIN:VEVENT

  S: DTSTART:19990310T090000Z
  S: DTEND:19990310T100000Z
  S: UID:abcxyz12345
  S: SUMMARY:Meet with   Sir Elton
  S: END:VEVENT
  S: BEGIN:VEVENT
  S: DTSTART:19990310T130000Z
  S: DTEND:19990310T133000Z
  S: UID:abcxyz8999
  S: SUMMARY:Meet with   brave brave Sir     Robin
  S: END:VEVENT
  S: END:VCALENDAR
  S:
          .
  S: 2.0 cap://bobo.ex.com/relcal3
  S: Content-type:text/calendar;
Method=RESPONSE;Component=VDATA;
  S: Optinfo=VERSION:2.1
  S: Content-Transfer-Encoding: 7bit
  S:
  S: BEGIN:VCALENDAR
  S: VERSION:2.1
  S: METHOD:RESPONSE
  S: BEGIN:VDATA
  S: BEGIN:VEVENT
  S: DTSTART:19990310T140000Z
  S: DTEND:19990310T150000Z
  S: UID:123456asdf
  S: SUMMARY:Summer Budget
  S: END:VEVENT
  S: END:VDATA
  S: END:VCALENDAR
  S: [IANA-PROP]          0+       any IANA registered
                                          property

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          .

The return values are subject to VCAR filtering. That is,
if the request contains properties to which the UPN does
not VCOMMAND             1        MUST have access, those properties will not appear in the
return values. If the UPN has access to at least one
property of events, but has been denied access to all
properties called out in the request, the response will
contain a single RESPONSE-CODE property indicating the
error. That is, the VEVENT components will be the
following:

[EDITORS NOTE:
Should the one(s) that the UPN has access to be returned?]
  S: 2.0 cap://bobo.ex.com/sally
  S: Content-type:text/calendar;
Method=RESPONSE;Component=VDATA;
  S: Optinfo=VERSION:2.1
  S: Content-Transfer-Encoding: 7bit
  S:
  S: BEGIN:VCALENDAR
  S: VERSION:2.1
  S: BEGIN:VDATA
  S: BEGIN:VEVENT
  S: RESPONSE-CODE:3.8
  S: END:VEVENT

  S: END:VDATA
  S: END:VCALENDAR
  S:
                                          container (VCALENDAR,
                                          VCAR, VQUERY, VEVENT,
                                          VTODO, VJOURNAL)
          . . CMDID              0 or 1   If the UPN has no access to any events at all, the
response will simply be an empty data set. The response
looks the same if CMDID is not supplied,
                                          then there are particular events must not be pending
                                          replies to which
the requester has been denied access.

  S: 2.0 cap://bobo.ex.com/sally
  S: Content-type:text/calendar;
Method=RESPONSE;Component=VDATA;
  S: Optinfo=VERSION:2.1
  S: Content-Transfer-Encoding: 7bit
  S:
  S: BEGIN:VCALENDAR
  S: VERSION:2.1
  S: BEGIN:VDATA
  S: END:VDATA
  S: END:VCALENDAR
  S: previous command.
          . . [IANA-PROP]        0+       any IANA registered
                                          property
          . .

  Find alarms within a range of time for booked (METHOD =
CREATE) VEVENTs.

  C: SENDDATA
  C: Content-type:text/calendar; Method=READ;
Component=VQUERY
  C:
  C: BEGIN:VCALENDAR
  C: VERSION:2.1
  C: METHOD:READ
  C: CMDID:xyz12345
  C: TARGET:relcal2
  C: TARGET:cap://bobo.ex.com/relcal3
  C: BEGIN:VQUERY
  C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID, VALARM.*
   FROM VEVENT,VTODO
   WHERE VALARM.TRIGGER >= '19990310T080000Z'
   AND VALARM.TRIGGER <= '19990310T190000Z'
   AND METHOD = 'CREATE'
  C: END:VQUERY
  C: END:VCALENDAR
  C:             1        MUST be READ
          .
  S: 2.0 cap://bobo.ex.com/relcal3
  S: Content-type:text/calendar; Method=RESPONSE;
  S: Optinfo=VERSION:2.1
  S: Content-Transfer-Encoding: 7bit
  S:
  S: BEGIN:VCALENDAR
  S: VERSION:2.1
  S: METHOD:RESPONSE
  S: CMDID:xyz12345
  S: TARGET:cap://bobo.ex.com/relcal3
  S: BEGIN:VEVENT
  S: DTSTART:19990310T130000Z
  S: DTEND:19990310T133000Z

  S: UID:abcxyz8999
  S: SUMMARY:Meet with brave 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: .
  S: 2.0 cap://bobo.ex.com/relcal2
  S: Content-type:text/calendar; Method=RESPONSE;
  S: Optinfo=VERSION:2.1
  S: Content-Transfer-Encoding: 7bit
  S:
  S: BEGIN:VCALENDAR
  S: VERSION:2.1
  S: METHOD:RESPONSE
  S: CMDID:xyz12345
  S: TARGET:cap://bobo.ex.com/relcal2
  S: BEGIN:VEVENT
  S: REQUEST-STATUS:2.0
  S: END:VEVENT
  S: END:VCALENDAR
  S: .

7.2.2. Scheduling Commands

The following provide a set of scheduling commands (or
methods) in CAP. Scheduling commands allow a CU to
indirectly manipulate a calendar by asking another CU to
perform an operation on their calendar. For example, CU-A
can request CU-B to add a meeting to their calendar; in
effect inviting CU-B to the meeting.

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

[EDITORS NOTE: This section needs to be completed by
adding the restriction tables for each of these iTIP
methods. The basis for the text is to be taken from
[iTIP].]

7.2.2.1. Reading out scheduling components

A CU might be invited to a meeting. If the CU had been
invited by CAP, the entry in the CU calendar will TARGET             1+       MUST be
scheduled, but not booked. So a CUA will need to look for
scheduled entries in the calender and present them to the
CU or automaticly decide if the invitation is to be
accepted CALID

          . . VCALENDAR          0+
          . . . CALMASTER        0 or processed.

Example:

The little league coach places the teams entire schedule
into your calendar. Lets say that every game and practice
is on a Friday night and your 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 at the field
   and ready to play by 6pm.
  RRULE:FREQ=WEEKLY;COUNT=10
  END:VEVENT
  END:VCALENDAR

At this point the above VEVENT is not booked in your
calendar, It is simply scheduled. A CUA would fetch this
and all other scheduled VEVENTs from your calendar with:

  C: SENDDATA
  C: Content-type:text/calendar; Method=READ;
Component=VQUERY
  C:
  C: BEGIN:VCALENDAR
  C: VERSION:2.1
  C: METHOD:READ
  C: CMDID:xyz12345
  C: TARGET:relcal2
  C: BEGIN:VQUERY
  C: QUERY:SELECT * WHERE FROM VEVENT METHOD != 'CREATE'
  C: END:VQUERY
  C: END:VCALENDAR
  C: 1
          .

The the CUA and CU could determine which scheduling items
were to remain on the calendar. Each scheduling component
could be deleted . . NAME             0 or updated with METHOD:MODIFY to change
the METHOD from PUBLISH, REQUEST, REPLY, ADD, CANCEL,
REFRESH, COUNTER, 1
          . . . OWNER            1+
          . . . RELCALID         1
          . . . TZID             0 or DECLINE-COUNTER to what the CU and
CUA had decided.

In some cases the CUA could automaticly do the work and
inform the CU.   An example of this is CANCEL. If
configured to process METHOD:CANCEL it could
METHOD:DELETE the component an inform the CU that the
booked component had been canceled.

The CUA MUST process the scheduled components in the order
sent. Some optimization could be done by the CUA. One
example is if a PUBLISH and later a CANCEL for the same
component with the same SEQUENCE number were  scheduled,
but not booked. The CUA might never inform the CU and just
treat it as if the PUBLISH had never been received by
doing a METHOD:DELETE on both entries.

It is important to note that scheduled components do not
show up in busy time as BUSY. Only when they are booked
does the TRANSP:OPAQUE 1
          . . . [IANA-PROP]      0+       any IANA registered
                                          property take effect. A CS
implementation MAY mark the time as TENTATIVE. This
is an implementation and administrative choice.

7.2.2.2. PUBLISH

  Arguments:

  Data:    data as described below

  Result:   2.0 - success
    2.2 - will attempt operation on the remote cap server
    Permission
    Calendar already exists
    Bad args
    Parent Calendar(s) not found

This method is used to move a calendar within the CS's
hierarchy of calendars. If the CU wishes to keep the
published entry. A METHOD:MODIFY changing the entries
METHOD from PUBLISH to CREATE would

          . . VCAR               0

          . . VQUERY             1
          . . . EXPAND           0 or 1
          . . . MAXRESULTS       0 or 1
          . . . MAXSIZE          0 or 1
          . . . QUERYNAME        1
          . . . QUERY            1
          . . . [IANA-PROP]      0+       any IANA registered
                                          property

          . . VEVENT             0
          . . VTODO              0
          . . VJOURNAL           0
          . . VFREEBUSY          0

          . . VTIMEZONE          0+       MUST be done, booking the
entry. Or METHOD:DELETE present if the CU did not wish this
scheduled item any
                                          date/time refers
                                          to exist in their calendar.

7.2.2.3. REQUEST

  Arguments:

  Data:    data as described below

  Result:   2.0 - success
    2.2 - will attempt operation on the remote cap server
    Permission
    Calendar already exists
    Bad args
    Parent Calendar(s) not found

  This as described in [iTIP] and would a timezone
          . . . DAYLIGHT         0+       MUST be modified just
like PUBLISH above.

7.2.2.4. REPLY

  Arguments:

  Data:    data as described below

  Result:   2.0 - success

    2.2 - will attempt operation on the remote cap server
    Permission
    Calendar already exists
    Bad args
    Parent Calendar(s) not found

7.2.2.5. ADD

  Arguments:

  Data:    data as described below

  Result:   2.0 - success
    2.2 - will attempt operation on the remote cap server
    Permission
    Calendar already exists
    Bad args
    Parent Calendar(s) not found

7.2.2.6. CANCEL

  Arguments:

  Data:    data as described below

  Result:   2.0 - success
    2.2 - will attempt operation on the remote cap server
    Permission
    Calendar already exists
    Bad args
    Parent Calendar(s) not found

7.2.2.7. REFRESH

  Arguments:

  Data:    data as described below

  Result:   2.0 - success
    2.2 - will attempt operation on the remote cap server
    Permission
    Calendar already exists
    Bad args
    Parent Calendar(s) not found

7.2.2.8. COUNTER

  Arguments:

  Data:    data as described below

  Result:   2.0 - success
    2.2 - will attempt operation on the remote cap server
    Permission
    Calendar already exists
    Bad args
    Parent Calendar(s) not found

7.2.2.9. DECLINECOUNTER

  Arguments:

  Data:    data as described below

  Result:   2.0 - success
    2.2 - will attempt operation on the remote cap server
    Permission
    Calendar already exists
    Bad args
    Parent Calendar(s) not found

7.2.3. iTIP Examples

The following examples describe scenarios for the handling one or more of incoming iTIP data. An appropriate sort-order for the
handling of incoming iTIP is by UID, Recurrence-id,
sequence, dtstamp. This processing may
                                          either STANDARD
                                          or DAYLIGHT
          . . . . . COMMENT      0 or 1
          . . . . . DTSTART      1
          . . . . . RDATE        0+       if present RRULE MUST NOT
                                          be optimized, for
instance, REFRESHs could present
          . . . . . RRULE        0+       if present RDATE MUST NOT

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                                          be processed last.

As an update to [iTIP], data with the "COUNTER" method
should 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 processed even present
          . . . . . RRULE        0+       if the Sequence number is stale.

7.2.3.1. Sending and Receiving an iTIP request

  In this example A invites B and C to a meeting, B
accepts the meeting and C rejects it. The calendars for A,
B and C are relcal1, relcal2 and relcal3 respectively, and
are all on the same server, "cal.foo.com". A lot of these
described actions are performed by the CUAs and not the
users themselves, the CUAs are called A-c, B-c and C-c
respectively.

  A wishes to create a meeting with B and C, so A-c uses
CAP to send the following iTIP request to relcal2 and
relcal3, while logged in to "cal.foo.com".

  BEGIN:VCALENDAR
  VERSION:2.1

  CMDID:xhj-dd
  METHOD:REQUEST
  TARGET:cap://cal.foo.com/relcal2
  TARGET:relcal3
  BEGIN:VEVENT
  UID:abcd12345
  DTSTART:19990307T180000Z
  DTEND:19990307T190000Z
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ACTION:cap://cal.foo.com/relcal2
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ACTION:cap://cal.foo.com/relcal3
  SUMMARY:Important Meeting
  END:VEVENT
  END:VCALENDAR

  An incoming event (indicated by the value of the "METHOD"
property) then
  appears in relcal2 and relcal3, with the following data:

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

  B-c and C-c must search 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

          Server Restriction Table for such incoming events, they do
so using the
  following CAP search:

  BEGIN:VCALENDAR
  VERSION:2.1
  METHOD:READ
  CMDID:xhr-de
  TARGET:relcal2
  # READ command

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

          VCAP                    1+
          . VCALENDAR             1+
          . . TARGET              1

          . . VERSION             1      MUST be 2.0

          . . CMDID               0 or TARGET:relcal3
  BEGIN:VQUERY
  QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST';
  END:VQUERY
  END:VCALENDAR

  In response to this search they get the above event. B-c
and C-c must
  then crack open the VEVENT, find 1 MUST be returned if the UID and determine
                                         request contained a CMDID
          . . REQUEST-STATUS      0      if
there is
  already an event on their not creating a calendar with that UID. To do
this they use
  the following search:

  BEGIN:VCALENDAR
  VERSION:2.1
  METHOD:READ
  CMDID:xhr-df
  TARGET:relcal2

  BEGIN:VQUERY
  QUERY:SELECT
                                  1+     if creating a calendar

          . . . VCAR              0+
          . . . . REQUEST-STATUS  1+
          . . . . * FROM               0      No other VCAR properties are

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                                         present
          .
          . . . VCOMMAND          0

          . . . VEVENT WHERE UID = 'abcd12345' AND
METHOD = 'CREATE'
  END:VQUERY
  END:VCALENDAR

  We assume that the event is not already in their relcal2
or relcal3.

  B-c prompts B who decides to accept the meeting request,
and B-c creates
  a copy 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:

  BEGIN:VCALENDAR
  VERSION:2.1
  CMDID:xhj-dd
  METHOD:REPLY
  TARGET:cap://cal.foo.com/relcal1
  BEGIN:VEVENT
  UID:abcd12345
  DTSTART:19990307T180000Z
  DTEND:19990307T190000Z
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2
  SUMMARY:Important Meeting
  END:VEVENT
  END:VCALENDAR

  C, on the            0+
          . . . . REQUEST-STATUS  1+
          . . . . *               0      No other hand, decides to decline the meeting, and
C-c sends a
  reply to the Organizer to that effect, as follows:

  BEGIN:VCALENDAR
  VERSION:2.1
  CMDID:xhj-dd
  METHOD:REPLY
  TARGET:cap://cal.foo.com/relcal1
  BEGIN:VEVENT
  UID:abcd12345
  DTSTART:19990307T180000Z
  DTEND:19990307T190000Z
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
  SUMMARY:Important Meeting
  END:VEVENT
  END:VCALENDAR

  It is preferable that C-c store the event in relcal3 even
though it has
  been declined. Storing the event in relcal3 allows
subsequent iTIP
  messages to be interpreted correctly. The "PARTSTAT"
parameter indicates
  that the event VEVENT properties
                                         are present
          . . . . VALARM          0      if VEVENT was refused.

  After receiving the replies from relcal2 and relcal3, A-c
updates the
  version of successfully
                                         saved
                                  1+     if there were errors saving
                                         alarms
          . . . . . REQUEST-STATUS 1+

          . . . VFREEBUSY         0+
          . . . . REQUEST-STATUS  1+
          . . . . *               0      No other VFREEBUSY
                                         properties are
                                         present

          . . . VJOURNAL          0+
          . . . . REQUEST-STATUS  1+
          . . . . *               0      No other VJOURNAL properties
                                         are present

          . . . VQUERY            0+
          . . . . REQUEST-STATUS  1+
          . . . . *               0      No other VQUERY properties
                                         are present

          . . . VTODO             0+
          . . . . REQUEST-STATUS  1+
          . . . . *               0      No other VTODO properties
                                         are present
          . . . . VALARM          0      if VTODO was successfully
                                         saved
                                  1+     if there were errors saving
                                         alarms
          . . . . . REQUEST-STATUS 1+

          Read 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 in relcal1 to indicate the new
participation
  status:

  BEGIN:VEVENT
  METHOD:REQUEST
  UID:abcd12345
  DTSTART:19990307T180000Z
  DTEND:19990307T190000Z
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2
  ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
  SUMMARY:Important Meeting
  END:VEVENT

  A-c then sends a new iTIP request are returned. Two calendars are specified. Only booked
          (vs scheduled) entries are to relcal2 only,
indicating the
  updated information.

7.2.3.2. Handling an iTIP refresh

  A little bit later, C is thinking about accepting the
event in the
  previous example, but be returned. The first wants to check the current
state of returns

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          two VEVENTS that match in that TARGET, the
  event. To find second result
          returns only one VEVENT for the current state C-c uses the iTIP
"REFRESH" method,
  sending the following to relcal1:

  BEGIN:VCALENDAR second TARGET.

            C: SENDDATA
            C: Content-type:text/calendar; Method=READ; Component=VQUERY
            C:
            C: BEGIN:VCAP
            C: VERSION:2.1
  CMDID:xud-pn
  METHOD:REFRESH
  TARGET:cap://cal.foo.com/relcal1
  BEGIN:VEVENT
  UID:abcd12345
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE:cap://cal.foo.com/relcal3
  DTSTAMP:19990306T202333Z
  END:VEVENT
  END:VCALENDAR

  A-c finds the refresh as an incoming iTIP, and searches
for the
  corresponding event. Having found the event (with no
changes since the
  last example) A-c then verifies that relcal3 is in fact an
Attendee of
  the event and is thus allowed to request a refresh. (In
the case of a
  published event things are more complicated.) A-c packages
the event up
  as an iTIP request and sends it to relcal3:

  BEGIN:VCALENDAR
            C: BEGIN:VCOMMAND
            C: METHOD:READ
            C: CMDID:xyz12345
            C: TARGET:relcal2
            C: TARGET:cap://bobo.ex.com/relcal3
            C: BEGIN:VQUERY
            C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
                FROM VEVENT
                WHERE DTEND >= '19990310T080000Z'
                AND DTSTART <= '19990310T190000Z'
                AND METHOD = 'CREATE'
            C: END:VQUERY
            C: END:VCOMMAND
            C: END:VCAP
            C: .
            S: 2.0 cap://cal.example.com/relcal2
            S: Content-type:text/calendar; Method=RESPONSE;
                Optinfo=VERSION:2.1
            S: Content-Transfer-Encoding: 7bit
            S:
            S: BEGIN:VCAP
            S: VERSION:2.1
  CMDID: xud-pn
  METHOD:REQUEST
  TARGET:cap://cal.foo.com/relcal3
            S: METHOD:RESPONSE
            S: BEGIN:VEVENT
  UID:abcd12345
  DTSTART:19990307T180000Z
  DTEND:19990307T190000Z
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2

  ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
  SUMMARY:Important Meeting
  SEQUENCE:0
  DTSTAMP:19990306T204333Z

            S: DTSTART:19990310T090000Z
            S: DTEND:19990310T100000Z
            S: UID:abcxyz12345
            S: SUMMARY:Meet with  Sir Elton
            S: END:VEVENT
  END:VCALENDAR

7.2.3.3. Sending and accepting an iTIP counter

  Having received the latest copy of the event C wishes to
propose a venue
  for the event, using an iTIP COUNTER. To do this C-c sends
the following
  to relcal1:

  BEGIN:VCALENDAR
  VERSION:2.1
  CMDID:zzykjjk
  METHOD:COUNTER
  TARGET:cap://cal.foo.com/relcal1
            S: BEGIN:VEVENT
  UID:abcd12345
  DTSTART:19990307T180000Z
  DTEND:19990307T190000Z
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
  SUMMARY:Important Meeting
  LOCATION:La Belle Province
  COMMENT:My favorite restaurant, I'll definitely go if it's
there.
  END:VEVENT
  END:VCALENDAR

  Having sent the information to relcal1, C-c shouldn't
store the new
  details in relcal3. If C-c updated the version in relcal3
and relcal1
  did not reply to the counter, then relcal3 would have
incorrect
  information. Instead C-c preserves the correct information
and waits for
  a response from relcal1. A CUA implementation may wish to
preserve this
  information itself, externally to the CS.

  In order to receive an iTIP counter A-c follows the same
search as for
  other iTIP data, first find the incoming message, next
find any matching
  events in the calendar store.

  Having found the matching event, A reviews the proposed
changes and
  decides to accept the COUNTER. To do this, A-c modifies
the version in
  relcal1 (bumping the sequence number) to:

  BEGIN:VEVENT
  METHOD:CREATE
  UID:abcd12345
  DTSTART:19990307T180000Z
  DTEND:19990307T190000Z
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2

  ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
  SUMMARY:Important Meeting
  LOCATION:La Belle Province
  SEQUENCE:1
  END:VEVENT

  A-c then sends the updated version as a request to both
relcal2 and
  relcal3:

  BEGIN:VCALENDAR
  VERSION:2.1
  CMDID:xup-po
  METHOD:REQUEST
  TARGET:cap://cal.foo.com/relcal2
  TARGET:cap://cal.foo.com/relcal3
  BEGIN:VEVENT
  UID:abcd12345
  DTSTART:19990307T180000Z
  DTEND:19990307T190000Z
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ACTION:cap://cal.foo.com/relcal2
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ACTION:cap://cal.foo.com/relcal3
  SUMMARY:Important Meeting
  LOCATION:La Belle Province
  SEQUENCE:1
  DTSTAMP:19990307T054339Z
  END:VEVENT
  END:VCALENDAR

7.2.3.4. Declining an iTIP counter

  B does not like the new location and also counters the
event, B-c sends
  the following iTIP:

  BEGIN:VCALENDAR
  VERSION:2.1
  CMDID:xim-ef
  METHOD:COUNTER
  TARGET:cap://cal.foo.com/relcal1
  BEGIN:VEVENT
  UID:abcd12345
  DTSTART:19990307T180000Z
  DTEND:19990307T190000Z
  ORGANIZER:cap://cal.foo.com/relcal1
  ATTENDEE:cap://cal.foo.com/relcal2
  SUMMARY:Important Meeting
  LOCATION:Au Coin Dor=E9
  END:VEVENT
  END:VCALENDAR

  However, C does not accept the counter, and C-c replies
            S: DTSTART:19990310T130000Z
            S: DTEND:19990310T133000Z
            S: UID:abcxyz8999
            S: SUMMARY:Meet with a decline
  counter:

  BEGIN:VCALENDAR
  VERSION:2.1
  CMDID:xim-ef
  METHOD:DECLINE-COUNTER
  TARGET:cap://cal.foo.com/relcal2
  BEGIN:VEVENT
  DTSTAMP:19990307T093245Z
  UID:abcd12345
  ORGANIZER:cap://cal.foo.com/relcal1
  SEQUENCE:1
  END:VEVENT
  END:VCALENDAR

  Fortunately B-c kept the original information when sending
the counter,
  and there is no problem when no information is returned in
the DECLINE-
  COUNTER.

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

  [EDITORS NOTE: Do we want to use the same set of codes?]

  The format of these codes is described in [iCAL], 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 [iCAL], to make the accompanying text
optional.

  Code  Params          Description
  ----------------------------------------------------------
-------------
  2.0  [CMDID] varies      Success, The parameters vary with
the
                  operation and are specified.

  2.0.1  [CMDID]         Success, send data, terminate  with
                  <CRLF>.<CRLF>

  2.0.2  [CMDID]         A reply is pending. It could not be
com-
                  pleted in the specified amount of time.
                  The server awaits a CONTINUE or ABORT
                  command. If can optionally be followed
                  by a CMDID. If the SENDDATA object con-
                  tained a CMDID, then the CS MUST append
                  the CMDID to the 2.0.2 reply for that
                  object.

  2.0.3  [CMDID]         In response to the client issuing
an
                  ABORT command, this reply code indicates
                  that any command currently underway was
                  successfully aborted. If can optionally
                  be followed by a CMDID. If the SENDDATA
                  object contained a CMDID, then the CS
                  MUST append the CMDID to the 2.0.2 reply
                  for that object.

  2.0.6  [CMDID]         An operation is being attempted on
a re-
                  mote server. This response indicates
                  that the server has not yet been con-
                  tacted but an attempt will be made to
                  contact it after the command has been
                  sent.

  3.1.4  [CMDID]         Capability not supported.

  4.1   [CMDID]         Calendar store access denied.

  6. 1  [CMDID]         Authenticate failure: unsupported au-
                  thentication mechanism, credentials re-
                  jected.

  6.2   [CMDID]         Sender aborted authentication,
authenti-
                  cation exchange cancelled.

  6.3   [CMDID]         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 prop-
                  erty set to OPAQUE-NOCONFLICT or TRANS-
                  PARENT-NOCONFLICT.

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

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

  7.0  [CMDID]          A timeout has occurred. The server
was
                  unable to complete the operation in the
                  requested time.

  8.0  [CMDID]          A failure has occurred in the
Receiver
                  that prevents the operation from suc-
                  ceeding.

  8.1  [CMDID]          Sent when a session cannot be estab-
                  lished because the CAP Server is too
                  busy.

  8.2  [CMDID]          Used to signal that an ICAL object
has
                  exceeded the server's size limit

  8.3  [CMDID]          A DATETIME value was too large to be
                  represented on this Calendar.

  8.4  [CMDID]          A DATETIME value was too far in the
past
                  to be represented on this Calendar.

  8.5  [CMDID]          An attempt was made to create a new
ob-
                  ject but the unique id specified is al-
                  ready in use.

  9.0  [CMDID]          An unrecognized command was
received.

  10.1  <old-address> <new-   Accompanied by an alternate
address. The
      address> [CMDID]     RECIPIENT specified should be
contacted at
                  the given alternate address. The re-
                  ferral address MUST follow the reply
                  code.

  10.2               The server is shutting down.

  10.4               The operation has not be performed be-
                  cause it would cause the resources (mem-
                  ory, disk,CPU, etc) to exceed the allo-
                  cated quota.

  10.5  [CMDID]         The ITIP message has been queued too
too
                  long. Delivery has been aborted.
  ----------------------------------------------------------
-------------

9. Detailed SQL Schema

  This section describes a conceptual schema for object
model in CAP. It
  is used as the basis for querying data managed by the CS.
This is only
  a conceptual schema. Implementations can use any schema
they like so
  long as they are prepared to map CAP queries that are
expressed in this
  conceptual schema. Implementations are not required to use
SQL database
  technology. The protocol is designed such that a CUA does
not need to
  understand SQL. The CUA just sends strings that happen to
be valid SQL
  queries.

  This schema is based on SQL-92 [SQL] along with the
[SQLCOM]
  corrections.

  Properties than can occur multiple times are intended to
be put in
  separate tables. For example:

  BEGIN:VEVENT
  UID:1
  DTSTART:19990326T201400Z
  ORGANIZER:mailto:sam@abc.COM
  SUMMARY:I have 2 attachments

ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bel
l.au

ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bel
l2.au
  END:VEVENT

  There are two ATTACHMENT properties each having a unique
value. These
  are kept in separate tables. This is diagrammed below. The
diagram is
  not a complete representation of the VEVENT table. It is
an abbreviated
  table used to illustrate how properties that can occur
multiple times
  are intended to be represented.

  +---------------------------------------------------------
-------------+
  |          ABBREVIATED VEVENT TABLE             |
  +----+-----------------+---------------------+------------
--+----------+
  |  |         |           |       |     |
  |UID |DTSTART     |ORGANIZER      |SUMMARY    |ATTACH_KEY|
  +----+-----------------+---------------------+------------
--+----------+
  |1  |19990326T201400Z |mailto:sam@abc.com  |I have 2 at-
|123    |
  |  |         |           |tachments   |     |
  +----+-----------------+---------------------+------------
--+----------+
  |999 |19700101T000000Z |mailto:user@host.com |I have  no |
|
  |  |         |           |attachments  |     |
  +----+-----------------+---------------------+------------
--+----------+

  +---------------------------------------------------------
--------------+
  |          ABBREVIATED ATTACH_KEY TABLE            |
  +------------+------------------------------------+-------
--------------+
  |      |                  |           |
  |ATTACH_KEY |VALUE                | INLINE_BLOB     |
  +------------+------------------------------------+-------
--------------+
  |123     |ftp://host.com/pub/sounds/bell.au  |           |
  +------------+------------------------------------+-------
--------------+
  |123     |ftp://host.com/pub/sounds/bell2.au |           |
  +------------+------------------------------------+-------
--------------+
  |234     |                  | MIICajCCAdO-gAw-  |
  |      |                  | IBAgICBEU  <...re |
  |      |                  | mainder of "BASE64" |
  |      |                  | encoded binary da- |
  |      |                  | ta...>       |
  +------------+------------------------------------+-------
--------------+

9.1. iCalendar Store Schema

  The following defines the schema for an iCalendar object
and the
  components, properties, and parameters defined and used in
[iCAL],
  [iTIP], [iMIP], and [CAP].

   NOTES:

  * CURRENT_DATETIME would not be stored in the database. It
is selectable
 and read only.

  * When supporting virtual hosts, there could be more than
one row in the
 CALSTORE table. And then the CSID MUST not be empty.

  * TIMESTAMP(14) is the SQL value equivalent of DATE-TIME.

  * FLOAT(7,3) is an SQL 3x3 floating number (xxx.yyy).

9.1.1.    ACTION schema

  /*
  * If VALUE is NULL,    then OTHER_VALUE contains non-
rfc2445 value .
  */
  CREATE TABLE ACTION (
       VALUE_KEY    INTEGER NOT    NULL PRIMARY KEY,
       VALUE        ENUM("AUDIO", "DISPLAY", "EMAIL",
               "PROCEDURE") NOT NULL,
       OTHER_VALUE  TEXT,
       XPARAM       INTEGER          /* VALUE_KEY */
  );

9.1.2. ATTACH schema

  /*
  * VALUE is a FILE uri. The data is decoded (per ENCODING)
prior to being
  * stored into the file
  */
  CREATE TABLE ATTACH (
       VALUE_KEY    INTEGER NOT NULL PRIMARY KEY,
       VALUE        VARCHAR(255)   NOT NULL,
       ISBINARY     ENUM("T", "F") DEFAULT "F",
       FMTTYPE INTEGER,    /* VALUE_KEY */
       XPARAM       INTEGER     /* VALUE_KEY */
  );

9.1.3. ATTENDEE schema

  CREATE TABLE ATTENDEE (
       VALUE_KEY     INTEGER NOT NULL PRIMARY KEY,
       VALUE         TEXT,
       CUTYPE        INTEGER,       /* VALUE_KEY */
       MEMBER        INTEGER,       /* VALUE_KEY */
       ROLE          INTEGER,       /* VALUE_KEY */
       PARTSTAT      INTEGER,       /* VALUE_KEY */
       RSVP          ENUM("T", "F") DEFAULT "F",
       DELEGATED_TO  INTEGER,       /* VALUE_KEY */
       DELEGATED_FROM     INTEGER,       /* VALUE_KEY */
       CN       INTEGER,       /* VALUE_KEY */
       DIR           INTEGER,       /* VALUE_KEY */
       LANGUAGE      INTEGER,       /* VALUE_KEY */
       XPARAM        INTEGER             /* VALUE_KEY */
  );

9.1.4. CALSTORE schema

  CREATE TABLE CALSTORE (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       CSID           VARCHAR(255) NOT NULL,
       CALMASTER      TINYTEXT NOT NULL,
       DEFAULT_VCAR   INTEGER,            /* VALUE_KEY */
       MAXDATE   TIMESTAMP(14) NOT NULL
                 DEFAULT "99991231235959",
       MINDATE   TIMESTAMP(14) NOT NULL
                 DEFAULT "00000101000000",
       CURRENT_DATETIME    TIMESTAMP(14) NOT NULL,
       RECUR_ACCEPTED      ENUM("T", "F") NOT NULL DEFAULT
"T",
       RECUR_EXPAND   ENUM("T", "F") NOT NULL DEFAULT "T",
       RECUR_LIMIT    INTEGER DEFAULT 0,
       VERSION   VARCHAR(10) NOT NULL   DEFAULT   "2.0"
  );

9.1.5. CHILDREN schema

  CREATE TABLE CHILDREN (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY, /*
KEY_VALUE */
       CALID          VARCHAR(255)
  );

9.1.6.    CLASS schema

  CREATE TABLE CLASS (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       VALUE          ENUM("PUBLIC", "PRIVATE",
                    "CONFIDENTIAL",
                    "<other>") NOT NULL,
       OTHER_VALUE    TEXT,
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.7.    CN schema

  CREATE TABLE CN (
       VALUE_KEY    INTEGER   NOT NULL PRIMARY KEY,
       VALUE        VARCHAR(255) NOT NULL
  );

9.1.8. COMMENT schema

  CREATE TABLE COMMENT   (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       VALUE          TEXT    NOT NULL,
       ALTREP         INTEGER,            /* VALUE_KEY */
       LANGUAGE       INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.9. CONTACT schema

  CREATE TABLE CONTACT   (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       VALUE          TINYTEXT NOT NULL,
       ALTREP         VARCHAR(255),
       LANGUAGE       INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.10. CREATED schema

  CREATE TABLE CREATED   (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TIMESTAMP(14) NOT NULL,
       VALUETYPE      INTEGER NOT  NULL,       /* VALUE_KEY
*/
       TZID           INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.11.    CUTYPE   schema

  CREATE TABLE CUTYPE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          ENUM("INDIVIDUAL",
                    "GROUP",
                    "RESOURCE",
                    "ROOM",
                    "UNKNOWN",
                    "<other>") NOT NULL,
     OTHER_VALUE      TINYTEXT
  );

9.1.12.    DAYLIGHT_STANDARD schema

  CREATE TABLE DAYLIGHT_STANDARD (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       DTSTART   INTEGER NOT  NULL,       /* VALUE_KEY */
       TZOFFSETFROM   INTEGER NOT  NULL,       /* SECONDS */
       TZOFFSETTO     INTEGER NOT  NULL,       /* SECONDS */
       COMMENT   INTEGER,            /* VALUE_KEY */
       RDATE          INTEGER,            /* VALUE_KEY */
       RRULE          INTEGER,            /* VALUE_KEY */
       TZNAME         TINYTEXT,
       XPROP          INTEGER        /* VALUE_KEY */
  );

9.1.13.    DESCRIPTION schema

  CREATE TABLE DESCRIPTION (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       VALUE          TEXT,
       ALTREP         INTEGER,            /* VALUE_KEY */
       LANGUAGE       INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.14.    DIR schema

  CREATE TABLE DIR (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TEXT
  );

9.1.15.    DTEND schema

  CREATE TABLE DTEND (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TIMESTAMP(14) NOT NULL,
       VALUETYPE      INTEGER NOT  NULL,       /* VALUE_KEY
*/
       TZID           INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.16.    DTSTAMP schema

  CREATE TABLE DTSTART   (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TIMESTAMP(14) NOT NULL,
       VALUETYPE      INTEGER NOT  NULL,       /* VALUE_KEY
*/
       TZID           INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.17.    DUE schema

  CREATE TABLE DUE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TIMESTAMP(14) NOT NULL,
       VALUETYPE      INTEGER NOT  NULL,       /* VALUE_KEY
*/
       TZID           INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.18.    DURATION schema

  CREATE TABLE DURATION (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          INTEGER,            /* SECONDS */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.19.    EXDATE   schema

  CREATE TABLE EXDATE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TIMESTAMP(14) NOT NULL,
       VALUETYPE      INTEGER NOT  NULL,       /* VALUE_KEY
*/
       TZID           INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.20.    EXRULE   schema

  CREATE TABLE EXRULE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          INTEGER NOT  NULL,       /*
VALUE_KEY(RECUR)*/
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.21.    FBTYPE   schema

  CREATE TABLE FBTYPE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          ENUM("FREE", "BUSY",
                    "BUSY-UNAVALIBLE",
                    "BUSY-TENTATIVE",
                    "<other>") NOT NULL,
       OTHER_VALUE    TINYTEXT
  );

9.1.22.    FMTTYPE schema

  CREATE TABLE FMTTYPE   (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TINYTEXT
  );

9.1.23.    FREEBUSY schema

  CREATE TABLE FREEBUSY (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       VALUE_FROM     TIMESTAMP(14) NOT NULL,
       VALUE_TO       TIMESTAMP(14),
       DURATION       INTEGER,            /* SECONDS */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.24.    GEO schema

  CREATE TABLE GEO (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       LATITUDE       FLOAT(7,3),
       LONGITUDE      FLOAT(7,3),
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.25.    LANGUAGE schema

  CREATE TABLE LANGUAGE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TINYTEXT
  );

9.1.26. LAST_MODIFIED schema

  CREATE TABLE LAST_MODIFIED (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
     VALUE            TIMESTAMP(14) NOT NULL,
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.27.    MEMBER   schema

  CREATE TABLE MEMBER (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TEXT
  );

9.1.28.    METHOD   schema

  CREATE TABLE METHOD (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          ENUM("PUBLISH",
                     "REQUEST",
                     "REFRESH",
                     "CANCEL",
                     "ADD",
                     "REPLY",
                     "COUNTER",
                     "DECLINE-COUNTER",
                     "CREATE",
                     "DELETE",
                     "MODIFY",
                     "MOVE",
                     "READ",
                     "<other>") NOT     NULL,
       OTHER_VALUE     TEXT
  );

9.1.29.    ORGANIZER schema

  CREATE TABLE ORGANIZER (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       VALUE          TEXT    NOT NULL,
       CN        INTEGER,            /* VALUE_KEY */
       DIR            INTEGER,            /* VALUE_KEY */
       SENT_BY   INTEGER,            /* VALUE_KEY */
       LANGUAGE       INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.30.    OWNERS   schema

  CREATE TABLE OWNERS (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TINYTEXT NOT NULL
);

9.1.31.    PARTSTAT schema

  CREATE TABLE PARTSTAT (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          ENUM("NEEDS-ACTION",
                     "ACCEPTED",
                     "DECLINED",
                     "TENTATIVE",
                     "DELEGATED",
                     "COMPLETED",
                     "IN-PROCESS",
                     "<other>")
                     NOT NULL DEFAULT "NEEDS-ACTION",
       OTHER_VALUE    TINYTEXT
  );

9.1.32.    PERCENT_COMPLETE schema

  CREATE TABLE PERCENT_COMPLETE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          INTEGER NOT  NULL,
       XPARAM         INTEGER         /* VALUE_KEY */
  );

9.1.33.    PRIORITY schema

  CREATE TABLE PRIORITY (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          INTEGER NOT  NULL,
       XPARAM         INTEGER         /*     VALUE_KEY */
  );

9.1.34.    RDATE schema

  /* VALUETYPE (D) = DATE, (T)     = DATE-TIME, (P) = PERIOD
*/
  CREATE TABLE RDATE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TIMESTAMP(14) NOT NULL,
       VALUETYPE      ENUM("D", "T", "P")    NOT NULL
DEFAULT "T",
       TZID           INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.35.    RECUR schema

  CREATE TABLE RECUR (
       VALUE_KEY     INTEGER NOT NULL PRIMARY KEY,
       FREQ          ENUM("SECONDLY", "MINUTELY", "HOURLY",
                  "DAILY", "WEEKLY", "MONTHLY", "YEARLY"),
       UNTIL         TIMESTAMP(14),
       COUNT         INTEGER,
       INTERVAL_VAL  INTEGER,
       BYSECOND      SET("1", "2", "3", "4", "5", "6",
"7","8",
                  "9", "10",  "11", "12", "13", "14","15",
                  "16", "17", "18", "19", "20", "21", "22",
                  "23", "24", "25", "26", "27", "28", "29",
                  "30", "31", "32", "33", "34", "35", "36",
                  "37", "38", "39", "40", "41", "42", "43",
                  "44", "45", "46", "47", "47", "48", "49",
                  "50", "51", "52", "53", "54", "55", "56",
                  "57", "58", "59"),
       BYMINUTE      SET("1", "2", "3", "4", "5", "6",
"7","8",
                  "9", "10",  "11", "12", "13", "14","15",
                  "16", "17", "18", "19", "20", "21", "22",
                  "23", "24", "25", "26", "27", "28", "29",
                  "30", "31", "32", "33", "34", "35", "36",
                  "37", "38", "39", "40", "41", "42", "43",
                  "44", "45", "46", "47", "47", "48", "49",
                  "50", "51", "52", "53", "54", "55", "56",
                  "57", "58", "59"),
       BYHOUR       SET("1", "2", "3", "4", "5", "6", "7",
"8",
                  "9", "10",  "11", "12", "13", "14","15",
                  "16", "17", "18", "19", "20", "21", "22",
                  "23"),
       BYDAY        TINYTEXT,
       BYMONTHDAY   SET("1", "2", "3", "4", "5", "6", "7",
"8",
                  "9", "10",  "11", "12", "13", "14","15",
                  "16", "17", "18", "19", "20", "21", "22",
                  "23", "24", "25", "26", "27", "28", "29",
                  "30", "31", "-1", "-2", "-3", "-4", "-5",
                  "-6", "-7", "-8", "-9", "-10", "-11",
             "-12", "-13", "-14", "-15", "-16","-17",
                  "-18", "-19", "-20", "-21", "-22","-23",
                  "-24", "-25", "-26", "-27", "-28","-29",
                  "-30", "-31"),
       BYYEARDAY     TINYTEXT,
       BYWEEKNO      TINYTEXT,
       BYMONTH  SET("1", "2", "3", "4", "5", "6", "7","8",
                  "9", "10",  "11", "12"),
       BYSETPOS      TINYTEXT,
       WKST          SET("SU", "MO", "TU", "WE", "TH", "FR",
"SA"),
       XPARAM        INTEGER        /* VALUE_KEY */
  );

9.1.36.    RECURRENCE_ID schema

  CREATE TABLE RECURRENCE_ID (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TIMESTAMP(14) NOT NULL,
       VALUETYPE      INTEGER NOT  NULL,        /*
VALUE_KEY */
       RANGE          ENUM("THISANDPRIOR", "THISANDFUTURE"),
       TZID           INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.37.    RELATED_TO schema

  CREATE TABLE RELATED_TO (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TEXT,
       RELTYPE   ENUM("PARENT", "CHILD", "SIBLING",
                    "<other>"),
       OTHER_RELTYPE       TINYTEXT,
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.38.    REPEAT   schema

  CREATE TABLE REPEAT (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          INTEGER NOT  NULL DEFAULT 0,
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.39.    RESOURCES schema

  CREATE TABLE RESOURCES (
       VALUE_Y  INTEGER NOT NULL PRIMARY KEY,
       VALUE         TEXT NOT NULL,
       ALTREP        INTEGER,       /* VALUE_KEY */
       LANGUAE  INTEGER,       /* VALUE_KEY */
       XPARAM        INTEGER        /* VALUE_KEY */
  );

9.1.40.    ROLE schema

  CREATE TABLE ROLE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          ENUM("CHAIR", "REQ-PARTICIPANT",
                     "OPT-PARTICIPANT",
                     "NON-PARTICIPANT",
                     "<other>")
                     NOT NULL DEFAULT "REQ-PARTICIPANT",
       OTHER_VALUE    TINYTEXT
  );

9.1.41.    RRULE schema

  CREATE TABLE RRULE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          INTEGER NOT  NULL,       /*
VALUE_KEY(RECUR)*/
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.42.    SEQUENCE schema

  CREATE TABLE SEQUENCE (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY DEFAULT
0,
       VALUE          INTEGER NOT  NULL,
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.43.    STATUS   schema

  CREATE TABLE STATUS (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          ENUM("TENTATIVE",
                     "CONFIRMED",
                     "CANCELLED",
                     "NEEDS-ACTION",
                     "COMPLETED",
                     "IN-PROCESS",
                     "DRAFT",
                     "FINAL") NOT NULL,
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.44.    SUMMARY schema

  CREATE TABLE SUMMARY   (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       VALUE          TINYTEXT,
       ALTREP         INTEGER,            /* VALUE_KEY */
       LANGUAGE       INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.45.    TRANSP   schema

  CREATE TABLE TRANSP (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          ENUM("OPQQUE", "TRANSPARENT",
                     "OPAQUE-NOCONFLICTS",
                     "TRANSPARENT-NOCONFLICTS")
                      NOT NULL DEFAULT "TRANSPARENT",
  XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.46.    TRIGGER schema

  CREATE TABLE TRIGGER   (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       VALUETYPE      INTEGER NOT NULL,   /* VALUE_KEY */
       VALUE_DT       TIMESTAMP(14),
       VALUE_P   INTEGER,            /* SECONDS */
       RELATED   INTEGER,            /* VALUE_KEY */
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.47.    TZID schema

  CREATE TABLE TZID (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TEXT
  );

9.1.48.    UID schema

  CREATE TABLE UID (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TEXT,
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.49.    URL schema

  CREATE TABLE URL (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TEXT,
       XPARAM         INTEGER        /* VALUE_KEY */
  );

9.1.50.    VALARM   schema

  CREATE TABLE VALARM (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       ACTION         INTEGER NOT NULL,   /* VALUE_KEY */
       ATTACH         INTEGER,
       DESCRIPTION    INTEGER,            /* VALUE_KEY */
     DURATION    INTEGER,            /* VALUE_KEY */
       REPEAT         INTEGER,            /* VALUE_KEY */
       SUMMARY   INTEGER,            /* VALUE_KEY */
       TRIGGER   INTEGER,            /* VALUE_KEY */
       X_PROP         INTEGER        /* VALUE_KEY */
  );

9.1.51.    VCALENDAR schema

  CREATE TABLE VCALENDAR (
       VALUE_KEY      INTEGER NOT NULL,
       ALLOW_CONFLICTS     ENUM("T", "F") DEFAULT "T",
       CALSCALE       TINYTEXT NOT NULL,
       CHARSET   TINYTEXT NOT NULL,
       CHILDREN       INTEGER,            /* VALUE_KEY */
       CREATED   INTEGER,            /* VALUE_KEY */
       DEFAULT_VCAR   INTEGER NOT NULL,   /* VALUE_KEY */
       LANGUAGE       INTEGER,            /* VALUE_KEY */
       LAST_MODIFIED       INTEGER,            /* VALUE_KEY
*/
       NAME           TINYTEXT,
       OWNERS         INTEGER,            /* VALUE_KEY */
       PARENT         INTEGER,            /* VALUE_KEY */
       RELCALID       VARCHAR(255) NOT NULL PRIMARY KEY,
       TOMESTONE      ENUM("T", "F") NOT NULL DEFAULT "T",
       TZID           INTEGER NOT NULL    /* VALUE_KEY */
  );

9.1.52.    VCAR schema

  CREATE TABLE  brave brave Sir Robin
            S: END:VEVENT
            S: END:VCAP
            S: .
            S: 2.0 cap://bobo.ex.com/relcal3
            S: Content-type:text/calendar; Method=RESPONSE;
            S:    Component=VDATA; Optinfo=VERSION:2.1

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            S: Content-Transfer-Encoding: 7bit
            S:
            S: BEGIN:VCAP
            S: VERSION:2.1
            S: METHOD:RESPONSE
            S: BEGIN:VDATA
            S: BEGIN:VEVENT
            S: DTSTART:19990310T140000Z
            S: DTEND:19990310T150000Z
            S: UID:123456asdf
            S: SUMMARY:Summer Budget
            S: END:VEVENT
            S: END:VDATA
            S: END:VCAP
            S: .

          The return values are subject to VCAR (
     VALUE_KEY      INTEGER NOT    NULL PRIMARY KEY,
     VALUE           TINYTEXT
  /*<TODO>*/

  );

9.1.53. 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 events, 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   schema
          components will be the following:

            [EDITORS NOTE: Should the one(s) that the UPN has access to
          - be
            returned?]
            S: 2.0 cap://bobo.ex.com/sally
            S: Content-type:text/calendar;
          Method=RESPONSE;Component=VDATA;
            S:    Optinfo=VERSION:2.1
            S: Content-Transfer-Encoding: 7bit
            S:
            S: BEGIN:VCAP
            S: VERSION:2.1
            S: BEGIN:VDATA
            S: BEGIN:VEVENT
            S: REQUEST-STATUS:3.8
            S: END:VEVENT

            S: END:VDATA
            S: END:VCAP
            S: .

          If the UPN has no access to any events at all, the response
          will simply be an empty data set. The response looks the same

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          if there are particular events to which the requester has been
          denied access.

            S: 2.0 cap://bobo.ex.com/sally
            S: Content-type:text/calendar; Method=RESPONSE;
            S:  Component=VDATA;
            S: Optinfo=VERSION:2.1
            S: Content-Transfer-Encoding: 7bit
            S:
            S: BEGIN:VCAP
            S: VERSION:2.1
            S: BEGIN:VDATA
            S: END:VDATA
            S: END:VCAP
            S: .

          Find alarms within a range of time for booked (METHOD =
          CREATE) VEVENTs.

            C: SENDDATA
            C: Content-type:text/calendar; Method=READ; Component=VQUERY
            C:
            C: BEGIN:VCAP
            C: VERSION:2.1
            C: BEGIN:VCOMMAND
            C: METHOD:READ
            C: CMDID:xyz12345
            C: TARGET:relcal2
            C: TARGET:cap://bobo.ex.com/relcal3
            C: BEGIN:VQUERY
            C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID, VALARM.*
                FROM VEVENT,VTODO
                WHERE VALARM.TRIGGER >= '19990310T080000Z'
                AND VALARM.TRIGGER <= '19990310T190000Z'
                AND METHOD value will be CREATE for booked entries. Or it
must be = 'CREATE'
            C: END:VQUERY
            C: END:VCOMMAND
            C: END:VCAP
            C: .
            S: 2.0 cap://bobo.ex.com/relcal3
            S: Content-type:text/calendar; Method=RESPONSE;
            S: Optinfo=VERSION:2.1
            S: Content-Transfer-Encoding: 7bit
            S:
            S: BEGIN:VCAP
            S: VERSION:2.1
            S: METHOD:RESPONSE
            S: CMDID:xyz12345
            S: TARGET:cap://bobo.ex.com/relcal3

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            S: BEGIN:VEVENT
            S: DTSTART:19990310T130000Z
            S: DTEND:19990310T133000Z

            S: UID:abcxyz8999
            S: SUMMARY:Meet with brave brave Sir Robin
            S: BEGIN:VALARM
            S: TRIGGER:19990310T132500Z
            S: SUMMARY:Almost time..
            S: ACTION:DISPLAY
            S: END:VALARM
            S: END:VEVENT
            S: END:VCAP
            S: .
            S: 2.0 cap://bobo.ex.com/relcal2
            S: Content-type:text/calendar; Method=RESPONSE;
            S: Optinfo=VERSION:2.1
            S: Content-Transfer-Encoding: 7bit
            S:
            S: BEGIN:VCAP
            S: VERSION:2.1
            S: METHOD:RESPONSE
            S: CMDID:xyz12345
            S: TARGET:cap://bobo.ex.com/relcal2
            S: BEGIN:VEVENT
            S: REQUEST-STATUS:2.0
            S: END:VEVENT
            S: END:VCAP
            S: .

          7.2.2  Scheduling Commands

          The following provide a
  valid set of scheduling METHOD such     as PUBLISH, REQUEST,
REPLY, ADD, CANCEL,
  REFRESH, COUNTER or DECLINE-COUNTER.

  CREATE TABLE VEVENT (
       ATTACH         INTEGER,            /* VALUE_KEY */
       ATTENDEE       INTEGER,            /* VALUE_KEY */
       CATEGORIES     INTEGER,            /* VALUE_KEY */
       CLASS          INTEGER,            /* VALUE_KEY */
       COMMENT   INTEGER,            /* VALUE_KEY */
       CONTACT   INTEGER,            /* VALUE_KEY */
       CREATED   INTEGER,            /* VALUE_KEY */
     DESCRIPTION      INTEGER,            /* VALUE_KEY */
       DTEND          INTEGER,            /* VALUE_KEY */
       DTSTAMP   INTEGER,            /* VALUE_KEY */
       DTSTART   INTEGER,            /* VALUE_KEY */
       DURATION       INTEGER,            /* VALUE_KEY */
       EXDATE         INTEGER,            /* VALUE_KEY */
       EXRULE         INTEGER,            /* VALUE_KEY */
       GEO            INTEGER,            /* VALUE_KEY */
       LAST_MODIFIED       INTEGER,            /* VALUE_KEY
*/
       LOCATION       INTEGER,            /* VALUE_KEY */
       METHOD         INTEGER,            /* VALUE_KEY */
       ORGANIZER      INTEGER,            /* VALUE_KEY */
       PRIORITY       INTEGER,            /* VALUE_KEY */
       RECURRENCE_ID       INTEGER,            /* VALUE_KEY
*/
       RDATE_KEY      INTEGER,            /* VALUE_KEY */
       RELATED_TO     INTEGER,            /* VALUE_KEY */
       RESOURCES      INTEGER,            /* VALUE_KEY */
       RRULE          INTEGER,            /* VALUE_KEY */
       SUMMARY   INTEGER,            /* VALUE_KEY */
       SEQUENCE       INTEGER,            /* VALUE_KEY */
       STATUS         INTEGER,            /* VALUE_KEY */
       TRANSP         INTEGER,            /* VALUE_KEY */
       UID            INTEGER,            /* VALUE_KEY */
       URL            INTEGER,            /* VALUE_KEY */
       X_PROP_KEY     INTEGER,            /* VALUE_KEY */
       VALARM_KEY     INTEGER        /* VALUE_KEY */
  );

9.1.54.    VFREEBUSY schema
  An implementation may not actually have a VFREEBUSY table
as   the
  information may be produced dynamicly. However commands (or
          methods) in CAP.  Scheduling commands allow a CS MUST
appear CU to
  provide this table as this may be how indirectly
          manipulate a CUA chooses calendar by asking another CU to
query     for
  VFREEBUSY information while using [CAP]. Example, it
probably would not
  make any sense for ATTENDEE perform an
          operation on their calendar. For example, CU-A can request CU-
          B to exist in this table, yet add a
CUA may wish meeting to their calendar; in effect inviting CU-B
          to ask for the VFREEBUSY for an ATTENDEE.

  CREATE TABLE VFREEBUSY (
       ATTENDEE       INTEGER,            /* VALUE_KEY */
       COMMENT   INTEGER,            /* VALUE_KEY */
       CONTACT   INTEGER,            /* VALUE_KEY */
       DTEND          INTEGER,            /* VALUE_KEY */
       DTSTAMP   INTEGER,            /* VALUE_KEY */
       DTSTART   INTEGER,            /* VALUE_KEY */
       FREEBUSY       INTEGER,            /* VALUE_KEY */
       METHOD         INTEGER,            /* VALUE_KEY */
       ORGANIZER      INTEGER,            /* VALUE_KEY */
       X_PROP_KEY     INTEGER,            /* VALUE_KEY */
       URL            INTEGER        /* VALUE_KEY */
  );

9.1.55.    VJOURNAL schema
  The METHOD value will meeting.

          Calendar access rights can be CREATE granted for booked entries. Or it
must be a
  valid scheduling METHOD such as PUBLISH, REQUEST, REPLY,
ADD, CANCEL,
  REFRESH, COUNTER or DECLINE-COUNTER.

  CREATE TABLE VJOURNAL (
       ATTACH_KEY     INTEGER,       /* VALUE_KEY */
       CATEGORIES     INTEGER,       /* VALUE_KEY */
       CLASS          INTEGER,       /* VALUE_KEY */
       COMMENT   INTEGER,       /* VALUE_KEY */
       CONTACT   INTEGER,       /* VALUE_KEY */
       CREATED   INTEGER,       /* VALUE_KEY */
       DESCRIPTION    INTEGER,       /* VALUE_KEY */
       DTSTAMP   INTEGER,       /* VALUE_KEY */
       DTSTART   INTEGER,       /* VALUE_KEY */
       EXDATE         INTEGER,       /* VALUE_KEY */
       EXRULE         INTEGER,       /* VALUE_KEY */
       LAST_MODIFIED       INTEGER,       /* VALUE_KEY */
       METHOD         INTEGER,       /* VALUE_KEY */
       ORGANIZER      INTEGER,       /* VALUE_KEY */
       RDATE          INTEGER,       /* VALUE_KEY */
       RECURRENCE_ID       INTEGER,       /* VALUE_KEY */
       RELATED_TO     INTEGER,       /* VALUE_KEY */
       RRULE          INTEGER,       /* VALUE_KEY */
       SEQUENCE       INTEGER,       /* VALUE_KEY */
       STATUS         INTEGER,       /* VALUE_KEY */
       SUMMARY   INTEGER,       /* VALUE_KEY */
       UID            INTEGER,       /* VALUE_KEY */
       X_PROP         INTEGER   /* VALUE_KEY */
  );

9.1.56.    VQUERY   schema
  Stored VQUERYs will use commands
          without granting rights for more generalized access with the following schema.

  CREATE TABLE VQUERY (
       VALUE_KEY      INTEGER NOT NULL PRIMARY KEY,
       VALUE          TINYTEXT,      /* QUERYNAME */
       SCOPE          TINYTEXT,
       MAXRESULTS     INTEGER,
       MAXSIZE   INTEGER,
       CARSELECT      TEXT,
       CARWHERE       TEXT,
       CARORDERBY     TEXT,
       X_PROP         INTEGER   /* VALUE_KEY */
  );

9.1.57.    VTIMEZONE schema

  CREATE TABLE VTIMEZONE (
       DAYLIGHT       INTEGER NOT NULL,   /* VALUE_KEY */
       STANDARD       INTEGER NOT NULL,   /* VALUE_KEY */
       TZID           INTEGER NOT NULL,   /* VALUE_KEY */
       TZURL          INTEGER,            /* VALUE_KEY */
       X_PROP_KEY     INTEGER        /* VALUE_KEY */
  );

9.1.58.    VTODO schema
  The METHOD value will
          calendar commands.

          [EDITORS NOTE: This section needs to be CREATE completed by adding
          the restriction tables for booked entries. Or it
must each of these iTIP methods. The
          basis for the text is to be taken from [iTIP].]

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          7.2.2.1   Reading Scheduling Components

          A CU might be invited to a
  valid scheduling METHOD such as PUBLISH, REQUEST, REPLY,
ADD, CANCEL,
  REFRESH, COUNTER or DECLINE-COUNTER.

  CREATE TABLE VTODO (
       ATTENDEE       INTEGER,            /* VALUE_KEY */
       ATTACH         INTEGER,            /* VALUE_KEY */
       CATEGORIES     INTEGER,            /* VALUE_KEY */
       CLASS          INTEGER,            /* VALUE_KEY */
       COMMENT   INTEGER,            /* VALUE_KEY */
       CONTACT   INTEGER,            /* VALUE_KEY */
       CREATED   INTEGER NOT NULL,   /* VALUE_KEY */
       DESCRIPTION    INTEGER,            /* VALUE_KEY */
       DTSTAMP   INTEGER NOT NULL,   /* VALUE_KEY */
       DTSTART   INTEGER NOT NULL,   /* VALUE_KEY */
       DUE            INTEGER,            /* VALUE_KEY */
       DURATION       INTEGER,            /* VALUE_KEY */
       EXDATE         INTEGER,            /* VALUE_KEY */
       EXRULE         INTEGER,            /* VALUE_KEY */
       GEO            INTEGER,            /* VALUE_KEY */
       LAST_MODIFIED       INTEGER NOT NULL,   /* VALUE_KEY
*/
       LOCATION       INTEGER,            /* VALUE_KEY */
       METHOD         INTEGER,            /* VALUE_KEY */
       ORGANIZER      INTEGER,            /* VALUE_KEY */
       PERCENT_COMPLETE    INTEGER,            /* VALUE_KEY
*/
       PRIORITY       INTEGER,            /* VALUE_KEY */
       RDATE          INTEGER,            /* VALUE_KEY */
       RECURRENCE_ID       INTEGER,            /* VALUE_KEY
*/
       RESOURCES      INTEGER,            /* VALUE_KEY */
       RRULE          INTEGER,            /* VALUE_KEY */
       SEQUENCE       INTEGER,            /* VALUE_KEY */
       SUMMARY   INTEGER NOT NULL,   /* VALUE_KEY */
       UID            INTEGER NOT NULL PRIMARY KEY, /*
VALUE_KEY */
       URL            INTEGER,            /* VALUE_KEY */
       X_PROP         INTEGER,            /* VALUE_KEY */
       VALARM         INTEGER        /* VALUE_KEY */
  );

9.1.59.    X_PROP   schema

  CREATE TABLE X_PROP (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TEXT NOT NULL,
       NAME           TEXT NOT NULL,
       PARAMS         INTEGER      /* VALUE_KEY (XPARAM)*/
  );

9.1.60.    XPARAM   schema

  CREATE TABLE XPARAM (
       VALUE_KEY      INTEGER NOT  NULL PRIMARY KEY,
       VALUE          TEXT NOT NULL,
       NAME           TEXT NOT NULL
  );

10. Examples"

For all meeting. If the CU had been invited
          by CAP, the examples entry in this section, the authenticated user
is  user@example.com.

10.1. Authentication Examples

10.1.1. Login Using Kerberos V4

  Use Kerberos V4 to authenticate as bill@example.com CU calendar will be scheduled, but
          not booked. So a CUA will need to look for scheduled entries
          in the
CAP server on
  cal.example.com.

  C: <connect calendar and present them to cal.example.com on port ...>
  S: 2.0
  S: .
  C: CAPABILTY
  S: CAPVERSION=1.0
  S: ITIPVERSION=1.0
  S: AUTH=KERBEROS_V4
  S: AUTH=DIGEST_MD5
  S: .
  C: AUTHENTICATE KERBEROS_V4
  S: AmFYig==
  C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
  S: or//EoAADZI=
  C: DiAF5A4gA+oOIALuBkAAmw==
  S: 2.0
  S: IDENTITY=bill@example.com
  S: CAPVERSION=1.0

  S: ITIPVERSION=1.0
  S: AUTH=KERBEROS_V4
  S: AUTH=DIGEST_MD5
  S: CAR=CAR-FULL-1
  S: MINDATE=19700101T000000Z
  S: MAXDATE=20380118T191407Z
  S: .

10.1.2. Error Scenarios

  Use of SASL Authorization Identity is not supported. Use the IDENTITY
  command instead. If you attempt to use CU or automaticly
          decide if the Authorization
Identity, an
  error status will invitation is to be returned.

  C: AUTHENTICATE KERBEROS_V4
  S: AmFYig==
  C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
  S: or//EoAADZI=
  C: DiAF5A4gA+oOIALuBkAAmw==
  S: 6.1
  S: .

  Sender aborted authentication:

  C: AUTHENTICATE KERBEROS_V4
  S: AmFYig==
  C: .
  S: 6.2
  S: .

  Unsupported mechanism:

  C: AUTHENTICATE Experimental_Auth
  S: 6.3
  S: .

10.2. Read Examples

10.2.1. Read From A Single Calendar

  In this example bill@example.com reads accepted or processed.

          Example:

          The little league coach places the teams entire schedule into
          your calendar. Lets say that every game and practice is on a day's worth of
events from
  cap://cal.example.com/opaqueid99.

  C: SENDDATA
  C: Content-type:text/calendar; Method=READ;
Component=VQUERY
  C:
  C: BEGIN:VCALENDAR
  C: VERSION:2.1
  C: METHOD:READ
  C: CMDID:xyz12345

  C: TARGET:cap://cal.example.com/opaqueid99
  C: BEGIN:VQUERY
  C: QUERY:SELECT DTSTART,DTEND,SUMMARY, UID FROM VEVENT
    WHERE DTEND >= '19990714T080000Z'
    AND DTSTART <= '19990715T080000Z'
  C: END:VQUERY
  C: END:VCALENDAR
  C: .
  #
          Friday night and your calendar now has this response code means that the transport successfully
  # delivered the data.
  S: 2.0 ; got the request OK ; really
  S: .
  S: Content-type:text/calendar; Method=RESPONSE;
Optinfo=VERSION:2.1
  S: Content-Transfer-Encoding: 7bit
  S:
  S: BEGIN:VCALENDAR
  S: VERSION:2.1
  S: METHOD:RESPONSE
  S: TARGET:cap://cal.example.com/opaqueid99
  S: CMDID:xyz12345
  S: RESPONSE-STATUS:2.0
  S: BEGIN:VEVENT
  S: DTSTART:19990714T200000Z
  S: DTEND:19990714T210000Z
  S: UID:000444888929922
  S: SUMMARY:Blah bla
  S: END:VEVENT
  S: iTIP scheduling
          data:

            BEGIN:VCAP
            VERSION:2.0
            METHOD:PUBLISH
            BEGIN:VEVENT
  S: UID:0034848098038888989443
  S: SUMMARY:meeting
  S: DTEND:19990714T233000Z
  S: DTSTART:19990714T223000Z
  S:
            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 at the field
             and ready to play by 6pm.
            RRULE:FREQ=WEEKLY;COUNT=10
            END:VEVENT
  S: END:VCALENDAR
  S: .

10.2.2. Read From Multiple Calendars

  In
            END:VCAP

          At this point the above VEVENT is not booked in your calendar,
          It is simply scheduled. A CUA would fetch this example bill@example.com reads a day's worth of
events from
  cap://cal.example.com/opaqueid101 and
cap://cal.example.com/opaqueid103 all other
          scheduled VEVENTs from your calendar with:

            C: SENDDATA
            C: Content-type:text/calendar; Method=READ; Component=VQUERY
            C:
            C: BEGIN:VCALENDAR BEGIN:VCAP
            C: VERSION:2.1
            C: METHOD:READ
  C: CMDID:xyz12346
  C: TARGET:cap://cal.example.com/opaqueid101
  C: TARGET:opaqueid103
  C: BEGIN:VQUERY
  C: VSCOPE:VEVENT

  C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
  C: WHERE DTEND >= 19990714T080000Z AND DTSTART <=
19990715T080000Z
  C: END:VQUERY BEGIN:VCOMMAND
            C: END:VCALENDAR METHOD:READ
            C: CMDID:xyz12345
            C: TARGET:relcal2
            C: BEGIN:VQUERY
            C: QUERY:SELECT * WHERE FROM VEVENT METHOD != 'CREATE'
            C: END:VQUERY
            C: END:VCOMMAND
            C: END:VCAP

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            C: .
  S: 2.0
  S: .
  S: Content-Type:multipart/mixed;boundary="--
FEE3790DC7E35189CA67"
  S:
  S: ----FEE3790DC7E35189CA67
  S: Content-type:text/calendar; Method=RESPONSE;
  S: Optinfo=VERSION:2.1
  S: Content-Transfer-Encoding: 7bit
  S:
  S: BEGIN:VCALENDAR
  S: VERSION:2.1
  S: METHOD:RESPONSE
  S: TARGET:cap://cal.example.com/opaqueid103
  S: CMDID:xyz12346
  S: RESPONSE-CODE:2.0
  S: BEGIN:VEVENT
  S: UID:0034848098038888989443
  S: SUMMARY:meeting
  S: DTEND:19990714T233000Z
  S: DTSTART:19990714T223000Z
  S: END:VEVENT
  S: END:VCALENDAR
  S:
  S: ----FEE3790DC7E35189CA67CE2C
  S: Content-type:text/calendar; Method=RESPONSE;
  S: Optinfo=VERSION:2.1
  S: Content-Transfer-Encoding: 7bit
  S:
  S: BEGIN:VCALENDAR
  S: VERSION:2.1
  S: METHOD:RESPONSE
  S: TARGET:cap://cal.example.com/opaqueid101
  S: CMDID:xyz12346
  S: RESPONSE-CODE:4.1 ; access denied
  S: END:VCALENDAR
  S:
  S: ----FEE3790DC7E35189CA67CE2C
  S: .

10.2.3. Timeouts

          The the CUA and CU could determine which scheduling items were
          to remain on the calendar. Each scheduling component could be
          deleted or updated with METHOD:MODIFY to change the METHOD
          from PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER,
          or DECLINE-COUNTER to what the CU and CUA had decided.

          In some cases the CUA could automaticly do the work and inform
          the CU. An example of this is CANCEL. If configured to process
          METHOD:CANCEL it could METHOD:DELETE the component an inform
          the CU that the booked component had been canceled.

          The CUA MUST process the scheduled components in the order
          sent. Some optimization could be done by the CUA. One example bill@example.com attempts
          is if a PUBLISH and later a CANCEL for the same component with
          the same SEQUENCE number were scheduled, but not booked. The
          CUA might never inform the CU and treat it as if the PUBLISH
          had never been received by doing a METHOD:DELETE on both
          entries.

          It is important 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. A CS implementation MAY
          mark the time as TENTATIVE. This is an implementation and
          administrative choice.

          7.2.2.2   PUBLISH

            Arguments:

            Data:      data as described below

            Result:    2.0 - success
                       2.2 - will attempt operation on the remote CAP
                             server
                       Permission
                       Calendar already exists
                       Bad args
                       Parent Calendar(s) not found

          This method is used to read move a calendar but within the
  latency time he supplies is not sufficient for CS's
          hierarchy of calendars. If the server CU wishes to complete keep the command.

  C: SENDDATA 3
  C: Content-type:text/calendar; Method=READ;
Component=VQUERY

  C:
  C: BEGIN:VCALENDAR
  C: VERSION:2.1
  C: METHOD:READ
  C: CMDID:xyz12346
  C: TARGET:cap://cal.example.com/opaqueid101
  C: TARGET:opaqueid103
  C: BEGIN:VQUERY
  C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
    WHERE DTEND >= '19990714T080000Z' AND DTSTART <=
'19990715T080000Z'
  C: END:VQUERY
  C: END:VCALENDAR
  C: .
  S: 7.0 ; xyz12346
  S: .
  S: .

  If Bill wants published
          entry. A METHOD:MODIFY changing the entries METHOD from
          PUBLISH to continue CREATE would be done, booking the entry. Or
          METHOD:DELETE if the CU did not wish this scheduled item to
          exist in their calendar.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          7.2.2.3   REQUEST

            Arguments:

            Data:      data as described below

            Result:    2.0 - success
                       2.2 - will attempt operation on the remote CAP
                             server
                       Permission
                       Calendar already exists
                       Bad args
                       Parent Calendar(s) not found

          This as described in [iTIP] and give would be modified just like
          PUBLISH above.

          7.2.2.4   REPLY

            Arguments:

            Data:      data as described below

            Result:     2.0 - success
                        2.2 - will attempt operation on the remote CAP
                              server
                        Permission
                        Calendar already exists
                        Bad args
                        Parent Calendar(s) not found

          7.2.2.5   ADD

            Arguments:

            Data:      data as described below

            Result:    2.0 - success
                       2.2 - will attempt operation on the remote CAP
                             server
                       Permission
                       Calendar already exists
                       Bad args
                       Parent Calendar(s) not found

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          7.2.2.6   CANCEL

            Arguments:

            Data:      data as described below

            Result:    2.0 - success
                       2.2 - will attempt operation on the remote CAP
                             server
                       Permission
                       Calendar already exists
                       Bad args
                       Parent Calendar(s) not found

          7.2.2.7   REFRESH

            Arguments:

            Data:      data as described below

            Result:    2.0 - success
                       2.2 - will attempt operation on the remote CAP
                             server more time he
would issue a
  CONTINUE command:

  C: CONTINUE 10 ; xyz12346

  If Bill wants to abort the command and
                       Permission
                       Calendar already exists
                       Bad args
                       Parent Calendar(s) not wait any
further he would
  issue an ABORT command:

  C: ABORT ; xyz12346
  S: found

          7.2.2.8   COUNTER

            Arguments:

            Data:      data as described below

            Result:    2.0
  S: .
  S: .

10.2.4. Using - success
                       2.2 - will attempt operation on the remote CAP
                             server
                       Permission
                       Calendar Parent, Children Properties

10.2.5. An example that depends already exists
                       Bad args
                       Parent Calendar(s) not found

          7.2.2.9   DECLINECOUNTER

            Arguments:

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            Data:      data as described below

            Result:    2.0 - success
                       2.2 - will attempt operation on VEVENT.DTSTART and
VALARM.DTSTART

11. Implementation Issues

  1. What are the minimum component properties set required
to create a
  new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART,
SUMMARY and UID.
  [EDITORS NOTE (dr): They MUST be remote CAP
                             server
                       Permission
                       Calendar already exists
                       Bad args
                       Parent Calendar(s) not found

          7.2.3  iTIP Examples

          The following examples describe scenarios for the same as handling of
          incoming iTIP data. An appropriate sort-order for iTIP]

  2. What is the state handling
          of all undefined properties?
PROPOSAL: Not defined.
  So a query will not return them, if they are selected.
  [EDITORS NOTE (dr): Many have default values, a CS incoming iTIP is by UID, Recurrence-id, sequence, dtstamp.
          This processing may
return the
  default values?]

12. Properties

  [EDITORS NOTE: These extensions/changes to iCalendar need
to be
  reformatted optimized, for instance, REFRESHs could
          be processed last.

          As an update to conform [iTIP], data with the "COUNTER" method should
          be processed even if the Sequence number is stale.

          7.2.3.1   Sending and Receiving an iTIP request

          In this example A invites B and C to a meeting, B accepts the IANA registration process
defined in
  section 7 of [iCAL].]

12.1. Calendar Store Properties
          meeting and C rejects it. The following calendars for A, B and C are properties of
          relcal1, relcal2 and relcal3 respectively, and are all on the calendar store.

  Name          Read  Value    Description
           Only  Type
  ----------------------------------------------------------
----------------
  CALMASTER      N  URI   The email address for a
responsible
                     person. MUST be a mailto URL.

  CSID      Y  URI    The CSID
          same server, "cal.foo.com". A lot of this calendar store.
                     If these described actions
          are performed by the CUAs and not   specified, it is the same as users themselves, the hostname or virtual host name.

  DEFAULT_VCARS  N  TEXT
          CUAs are called A-c, B-c and C-c respectively.

          A multivalued property containing
                     the default VCARs for newly created
                     top level calendars. Each entry is
                     a CARID It MUST include at wishes to create a mini-
                     mum READBUSYTIMEINFO,REQUESTONLY,
                     UPDATEPARTSTATUS, meeting with B and DEFAULTOWNER.

  MAXDATE  Y   DATE-TIME  The date/time C, so A-c uses CAP to
          send the following iTIP request to relcal2 and relcal3, while
          logged in to "cal.foo.com".

            BEGIN:VCAP
            VERSION:2.1

            CMDID:xhj-dd
            BEGIN:VCOMMAND
            METHOD:REQUEST
            TARGET:cap://cal.foo.com/relcal2
            TARGET:relcal3
            BEGIN:VEVENT
            UID:abcd12345
            DTSTART:19990307T180000Z
            DTEND:19990307T190000Z
            ORGANIZER:cap://cal.foo.com/relcal1

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
          ACTION:cap://cal.foo.com/relcal2
            ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
          ACTION:cap://cal.foo.com/relcal3
            SUMMARY:Important Meeting
            END:VEVENT
            END:VCOMMAND
            END:VCAP

          An incoming event (indicated by the future beyond
                     which value of the server cannot represent.
                     If not specified, "METHOD"
          property) then
                     99991231T235959 will be assumed.

  MINDATE  Y   DATE-TIME  The date/time appears in relcal2 and relcal3, with the
          following data:

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

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

            BEGIN:VCAP
            VERSION:2.1
            BEGIN:VCOMMAND
            METHOD:READ
            CMDID:xhr-de
            TARGET:relcal2
            # or TARGET:relcal3
            BEGIN:VCOMMAND
            BEGIN:VQUERY
            QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST';
            END:VQUERY
            END:VCOMMAND
            END:VCOMMAND
            END:VCAP

          In response to
                     which this search they get the server cannot represent.
                     If not specified, above event. B-c and
          C-c must then
                     00000101T000000 will be assumed.

  CURRENT_DATETIME  Y    DATE-TIME  Current server time.
This is re-
                     Turned as a local time crack open the VEVENT, find the UID and TZID.

  RECUR_ACCEPTED   Y     BOOLEAN    Boolean value will be
set to TRUE
          determine if there is already an event on their calendar with
          that UID. To do this they use the server will accept recur-
                     rence rules. It will be set to
                     FALSE if following search:

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            BEGIN:VCAP
            VERSION:2.1
            BEGIN:VCOMMAND
            METHOD:READ
            CMDID:xhr-df
            TARGET:relcal2

            BEGIN:VCOMMAND
            BEGIN:VQUERY
            QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' AND
             METHOD = 'CREATE'
            END:VQUERY
            END:VCOMMAND
            END:VCOMMAND
            END:VCAP

          We assume that the server will event is not already in their relcal2 or
          relcal3.

          B-c prompts B who decides to accept
                     recurrence rules. If not specified the meeting request, and
          B-c creates a CUA MUST assume TRUE.

  RECUR_EXPAND   Y   BOOLEAN   If set to TRUE, copy of the CS
supports event in relcal2, with the
                     expansion of recurrence rules. If
          "PARTSTAT" parameter set to FALSE, ACCEPTED. B-c also sends this copy
          to the CS is incapable
                     of expanding recurrence rules.  If
                     not specified a CUA MUST assume
                     TRUE.

  RECUR_LIMIT    Y   INTEGER   This numeric value describes
how Organizer at relcal1 as an iTIP REPLY, preserving the
          CMDID:

            BEGIN:VCAP
            VERSION:2.1
            CMDID:xhj-dd
            METHOD:REPLY
            TARGET:cap://cal.foo.com/relcal1
            BEGIN:VEVENT
            UID:abcd12345
            DTSTART:19990307T180000Z
            DTEND:19990307T190000Z
            ORGANIZER:cap://cal.foo.com/relcal1
            ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2
            SUMMARY:Important Meeting
            END:VEVENT
            END:VCAP

          C, on the other hand, decides to decline the server handles unbounded recur-
                     rences. The value is only valid if
                     RECURRENCE is TRUE. If meeting, and C-c
          sends a reply to the value Organizer to that effect, as follows:

            BEGIN:VCALENDAR
            VERSION:2.1
            CMDID:xhj-dd
            METHOD:REPLY
            TARGET:cap://cal.foo.com/relcal1
            BEGIN:VEVENT

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            UID:abcd12345
            DTSTART:19990307T180000Z
            DTEND:19990307T190000Z
            ORGANIZER:cap://cal.foo.com/relcal1
            ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
            SUMMARY:Important Meeting
            END:VEVENT
            END:VCALENDAR

          It is
                     0 it means preferable that C-c store the server supports
                     unbounded recurrence rules. If it
                     is non-zero, event in relcal3 even
          though it is a positive inte-
                     ger indicating has been declined. Storing the number of in-
                     stances that will event in relcal3
          allows subsequent iTIP messages to be created when interpreted correctly.
          The "PARTSTAT" parameter indicates that the server expands an unbounded re-
                     currence rule when fetched event was refused.

          After receiving the replies from relcal2 and relcal3, A-c
          updates the
                     CS.  A CUA MUST query for date
                     ranges when this value is zero.

  VERSION  Y   TEXT  The version of the CS. The default
                     and event in relcal1 to indicate the only currently supported
                     version is "2.0"
          new participation status:

            BEGIN:VEVENT
            METHOD:REQUEST
            UID:abcd12345
            DTSTART:19990307T180000Z
            DTEND:19990307T190000Z
            ORGANIZER:cap://cal.foo.com/relcal1
            ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2
            ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
            SUMMARY:Important Meeting
            END:VEVENT

          A-c then sends a new iTIP request to match relcal2 only, indicating
          the
                     [iCAL]   VERSION.

12.2. Calendar Properties

Name       Read  Value   Description
           Only  Type
------------------------------------------------------------
-------------
ALLOW-CONFLICTS  N BOOLEAN    This boolean value indicates
                    Whether or not updated information.

          7.2.3.2   Handling an iTIP refresh

          A little bit later, C is thinking about accepting the calendar sup-
                    ports event conflicts. That is,
                    whether or not any in
          the previous example, but first wants to check the current
          state of the events in event. To find the current state C-c uses the
          iTIP "REFRESH" method, sending the following to relcal1:

            BEGIN:VCALENDAR
            VERSION:2.1
            CMDID:xud-pn
            METHOD:REFRESH
            TARGET:cap://cal.foo.com/relcal1
            BEGIN:VEVENT
            UID:abcd12345
            ORGANIZER:cap://cal.foo.com/relcal1
            ATTENDEE:cap://cal.foo.com/relcal3

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            DTSTAMP:19990306T202333Z
            END:VEVENT
            END:VCALENDAR

          A-c finds the refresh as an incoming iTIP, and searches for
          the calendar can overlap. If not
                    specified corresponding event. Having found the default value is TRUE
                    meaning   that conflicts are allowed.

CALSCALE   N  TEXT       The CALSCALE for this calendar. If
                    not specified event (with no
          changes since the default last example) A-c then verifies that relcal3
          is GREGO-
                    RIAN.

CHARSET    N  TEXT  The default charset for localized
                    strings in this calendar. If not
                    specified, fact an Attendee of the default event and is UTF-8.

CHILDREN    Y   TEXT     The list of sub-calendars belonging thus allowed to this calendar. An empty list
                    means no children. The results may
                    be
          request a comma separated list refresh. (In the case of chil-
                    dren. Each entry returned is a
                    CALID. The default is published event things
          are more complicated.) A-c packages the event up as an empty
                    list.

CREATED    Y  DATE-TIME  The timestamp iTIP
          request and sends it to relcal3:

            BEGIN:VCALENDAR
            VERSION:2.1
            CMDID: xud-pn
            METHOD:REQUEST
            TARGET:cap://cal.foo.com/relcal3
            BEGIN:VEVENT
            UID:abcd12345
            DTSTART:19990307T180000Z
            DTEND:19990307T190000Z
            ORGANIZER:cap://cal.foo.com/relcal1
            ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2

            ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
            SUMMARY:Important Meeting
            SEQUENCE:0
            DTSTAMP:19990306T204333Z
            END:VEVENT
            END:VCALENDAR

          7.2.3.3   Sending and accepting an iTIP counter

          Having received the latest copy of the calendar's
                    create date.

DEFAULT_VCAR  N  TEXT         The default VCARs for newly
created
                    top level calendars. This is event C wishes to
          propose a
                    CARID. The default value is venue for the event, using an iTIP COUNTER. To do
          this C-c sends the following to relcal1:

            BEGIN:VCAP
            VERSION:2.1
            CMDID:zzykjjk
            METHOD:COUNTER
            TARGET:cap://cal.foo.com/relcal1
            BEGIN:VEVENT
            UID:abcd12345
            DTSTART:19990307T180000Z
            DTEND:19990307T190000Z
            ORGANIZER:cap://cal.foo.com/relcal1

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
            SUMMARY:Important Meeting
            LOCATION:La Belle Province
            COMMENT:My favorite restaurant, I'll definitely go if it's
          there.
            END:VEVENT
            END:VCAP

          Having sent the information to relcal1, C-c shouldn't store
          the new details in relcal3. If C-c updated the
                    value of DEFAULT_VCAR version in
          relcal3 and relcal1 did not reply to the CAL-
                    STORE table.

LANGUAGE    N  TEXT      The default language counter, then relcal3
          would have incorrect information. Instead C-c preserves the
          correct information and waits for localiz-
                    able strings in a response from relcal1. A
          CUA implementation may wish to preserve this  calendar.
                    There is no default. This value
                    MUST NOT be empty.

LAST-MODIFIED N  DATE-TIME    The timestamp when the
properties
                    of information
          itself, externally to the calendar were last updated.
                    Default is CS.

          In order to receive an iTIP counter A-c follows the same
          search as CREATED.

NAME      N  TEXT        The display name for this calendar.
                    It is a localizable string. If not
                    provided, an empty value will be
                    returned.

OWNERS     N  URI       A multiinstanced property indicat-
                    ing other iTIP data, first find the incoming
          message, next find any matching events in the calendar owner. Each entry
                    returned will be a UPN. There must
                    be at least one     owner.

PARENT     N  URI        The CALID of this calendars parent
                    maintained by store.

          Having found the matching event, A reviews the proposed
          changes and decides to accept the COUNTER. To do this, A-c
          modifies the version in relcal1 (bumping the sequence number)
          to:

            BEGIN:VEVENT
            METHOD:CREATE
            UID:abcd12345
            DTSTART:19990307T180000Z
            DTEND:19990307T190000Z
            ORGANIZER:cap://cal.foo.com/relcal1
            ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2

            ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
            SUMMARY:Important Meeting
            LOCATION:La Belle Province
            SEQUENCE:1
            END:VEVENT

          A-c then sends the updated version as a request to both
          relcal2 and relcal3:

            BEGIN:VCAP
            VERSION:2.1
            CMDID:xup-po
            METHOD:REQUEST
            TARGET:cap://cal.foo.com/relcal2
            TARGET:cap://cal.foo.com/relcal3
            BEGIN:VEVENT

          <draft-ietf-calsch-cap-04.txt>   CAP server. An
                    empty value means   Expires September 2001

            UID:abcd12345
            DTSTART:19990307T180000Z
            DTEND:19990307T190000Z
            ORGANIZER:cap://cal.foo.com/relcal1
            ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
          ACTION:cap://cal.foo.com/relcal2
            ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
          ACTION:cap://cal.foo.com/relcal3
            SUMMARY:Important Meeting
            LOCATION:La Belle Province
            SEQUENCE:1
            DTSTAMP:19990307T054339Z
            END:VEVENT
            END:VCAP

          7.2.3.4   Declining an iTIP counter

          B does not like the new location and also counters the calendar is event,
          B-c sends the top level parent. The default
                    value is no parent.

RELCALID    N  URI       A unique name for following iTIP:

            BEGIN:VCAP
            VERSION:2.1
            CMDID:xim-ef
            METHOD:COUNTER
            TARGET:cap://cal.foo.com/relcal1
            BEGIN:VEVENT
            UID:abcd12345
            DTSTART:19990307T180000Z
            DTEND:19990307T190000Z
            ORGANIZER:cap://cal.foo.com/relcal1
            ATTENDEE:cap://cal.foo.com/relcal2
            SUMMARY:Important Meeting
            LOCATION:Au Coin Dor=E9
            END:VEVENT
            END:VCAP

          However, C does not accept the calendar.
                    There is no default value counter, and this
                    value MUST NOT be empty.

TOMBSTONE   N  BOOLEAN   TRUE indicator that this calendar
                    has been marked as deleted. The
                    default value is FALSE.

TZID      N  TEXT        The id of the timezone associated C-c replies with this calendar. See TZID in
                    [iCAL]. The default value is GMT.

13. Security Considerations

  For the mandatory SASL mechanism that a
          decline counter:

            BEGIN:VCAP
            VERSION:2.1
            CMDID:xim-ef
            METHOD:DECLINE-COUNTER
            TARGET:cap://cal.foo.com/relcal2
            BEGIN:VEVENT
            DTSTAMP:19990307T093245Z
            UID:abcd12345
            ORGANIZER:cap://cal.foo.com/relcal1

          <draft-ietf-calsch-cap-04.txt>   CAP specifies,   Expires September 2001

            SEQUENCE:1
            END:VEVENT
            END:VCAP

          Fortunately B-c kept the
mechanism
  support is:

  ? MUST authentication
  ? MUST authorization
  ? MAY impersonation
  The security issue:

       +---------+           +----------+
 CUA1 ------ |  CS1  |--------CAP----------|  CS2  |-----
CUA2
       | calF  |           | calA  |
       +---------+           +----------+

14. Changes to iCalendar

  [EDITORS NOTE: These extensions/changes to iCalendar need
to be
  reformatted to conform to original information when sending the IANA registration process
defined in
  section 7 of [iCAL].]

14.1. Time Transparency

  Property Name: TRANSP

  Purpose: This property defines whether an event
          counter, and there is
transparent or 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 no problem when no information is
          returned in the characteristic of an
event that
  determines whether it appears to consume time on a
calendar. Events that
  consume actual time for the individual or resource
associated with DECLINE-COUNTER.

          8  Response Codes
          Numeric response codes are returned at both the
  calendar SHOULD be recorded as OPAQUE, allowing them transfer and
          application layer. The same set of codes is used in both
          cases.

          [EDITORS NOTE: Do we want to be
detected by
  free-busy time searches. Other events, which do not take
up use the
  individual's (or resource's) time SHOULD be recorded as
TRANSPARENT,
  making them invisible to free-busy time searches.

  Format Definition: same set of codes?]

          The property format of these codes 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 described in [iCAL], and no other OPAQUE
           ; or OPAQUE-NOCONFLICT event
           ; can overlap it.

     / "OPAQUE-NOCONFLICT"  ; Opaque on busy time
     ; searches extend
          in [iTIP] and no other OPAQUE
     ; or OPAQUE-NOCONFLICT event
     ; can overlap it.
     ;
     ;Default value is OPAQUE

  Example: [iMIP]. The following is an example 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 for
an event that is transparent or does not block on free/busy time
searches:

   TRANSP:TRANSPARENT modified from that defined in [iCAL], to make the
          accompanying text optional.

          Code  Params      Description
          --------------------------------------------------------------
          2.0  [CMDID] varies
                            Success, The following parameters vary with the
                            operation and are specified.

          2.0.1  [CMDID]    Success, send data, terminate  with
                            <CRLF>.<CRLF>

          2.0.2  [CMDID]    A reply is an example pending. It could not be com-
                            pleted in the specified amount of this property for an event time.
                            The server awaits a CONTINUE or ABORT
                            command. If can optionally be followed
                            by a CMDID. If the SENDDATA object con-
                            tained a CMDID, then the CS MUST append
                            the CMDID to the 2.0.2 reply for that is opaque
  or blocks on free/busy time searches:

   TRANSP:OPAQUE

  The following is
                            object.

          2.0.3  [CMDID]    In response to the client issuing an example of
                            ABORT command, this property reply code indicates
                            that any command currently underway was
                            successfully aborted. If can optionally
                            be followed by a CMDID. If the SENDDATA

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                            object contained a CMDID, then the CS
                            MUST append the CMDID to the 2.0.2 reply
                            for an event that object.

          2.0.6  [CMDID]    An operation is opaque
  or blocks being attempted on free/busy time searches plus no other event
can overlap it:

   TRANSP:OPAQUE-NOCONFLICT

14.2. RIGHTS Value Type

  Value Name: RIGHTS

  Purpose: a
                            re-mote server. This value type is used response indicates
                            that the server has not yet been con-
                            tacted but an attempt will be made to identify properties
whose value is a
  calendar access rights.

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

  carrights    = [princ] (carref / cardef) CRLF

  princ      = "UPN" "=" (text / all / "OWNER" / "NONOWNER"
/ "ANONYMOUS")

  carref      = ";" "CARREF" "=" text *("," text)

  cardef      = action object *("," action object)

  action      = ";" "ACTION" "=" act-type *("," act-type)

  act-type     = ("CREATE" / "MODIFY" / "DELETE" / "READ" /
all)

  object      = ";" "OBJECT" "=" (csprop *("," csprop)
[propvalue])
            / (calprop *("," calprop) [propvalue])
            / (component *("," component)) [compvalue]

   / (compprop *("," compprop) [propvalue])
   / (compparam *("," compparam) [paramvalue])

  csprop     = csprop2 / all / iana-name

  csprop2     = <any calendar command has been
                            sent.

          3.1.4  [CMDID]    Capability not supported.

          4.1   [CMDID]     Calendar store property defined in
[CAP]>

  propvalue    = propvalue2 / all / self / iana-name

  propvalue2   = <any value appropriate for the named
property>

  calprop     = calprop2 / all / iana-name

  calprop2    = <any calendar property name defined in
[iCAL] or [CAP]>

  component    = component2 / all / iana-name

  component2   = <any calendar component defined in [iCAL]
or [CAP]>

  compprop    = compprop2 / all / iana-name

  compprop2    = <any component property name defined in
[iCAL] access denied.

          6. 1  [CMDID]     Authenticate failure: unsupported au-
                            thentication mechanism, credentials re-
                            jected.

          6.2   [CMDID]     Sender aborted authentication, authenti-
                            cation exchange cancelled.

          6.3   [CMDID]     Attempt to create or [CAP]>

  compparam    = compparm2 / all / iana-name

  compparm2    = <any component parameter name defined modify an event
                            such that it would overlap another event
                            in
[iCAL] or [CAP]>

  compvalue    = ";" "VALUE" "=" ((component2 *(","
component2))
           / all / iana-name)

  paramvalue   = paramvalue2 / all / iana-name

  paramvalue2   = <any value appropriate for either of the named
parameter>

  all       = "*"

  self      = "SELF"  ; Only valid for ATTENDEE value.
           ; When OBJECT=ATTENDEE;VALUE=SELF.

  iana-name    = <A name registered with IANA>

  Description: following two circum-
                            stances:

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

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

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

          7.0  [CMDID]      A timeout has occurred. The server was
                            unable to complete the operation in the
                            requested time.

          8.0  [CMDID]      A failure has occurred in the Receiver
                            that prevents the operation from
                            succeeding.

          8.1  [CMDID]      Sent when a structured session cannot be
                            established because the CAP Server is too
                            busy.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          8.2  [CMDID]      Used to signal that an ICAL object has
                            exceeded the server's size limit

          8.3  [CMDID]      A DATETIME value
consisting of was too large to be
                            represented on this Calendar.

          8.4  [CMDID]      A DATETIME value was too far in the past
                            to be represented on this Calendar.

          8.5  [CMDID]      An attempt was made to create a list
  of one or more access control rights rule parts. Each rule
part new
                            object but the unique id specified is
  defined
                            already in use.

          9.0  [CMDID]      An unrecognized command was received.

          10.1  <old-address> <new- address> [CMDID]
                            Accompanied by a "NAME=VALUE" pair. an alternate address. The rule parts are
separated from each
  other by
                            RECIPIENT specified should be contacted at
                            the given alternate address. The
                            referral address MUST follow the SEMICOLON character (US-ASCII decimal 59). reply
                            code.

          10.2              The rule parts
  are server is shutting down.

          10.4              The operation has not ordered in any particular sequence, unless
otherwise specified
  by be performed
                            because it would cause the ABNF.

  Within one carrights resources
                            (memory, disk,CPU, etc) to exceed the
                            allocated quota.

          10.5  [CMDID]     The ITIP message has been queued too too
                            long. Delivery has been aborted.
          --------------------------------------------------------------

          9  Examples

          For all matches the examples in this section, the authenticated user
          is  user@example.com.

          9.1 Authentication Examples

          9.1.1  Login Using Kerberos V4

            Use Kerberos V4 to authenticate as bill@example.com to the
          CAP server on
            cal.example.com.

            C: <connect to cal.example.com on port ...>
            S: 2.0

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            S: .
            C: CAPABILTY
            S: CAPVERSION=1.0
            S: ITIPVERSION=1.0
            S: AUTH=KERBEROS_V4
            S: AUTH=DIGEST_MD5
            S: .
            C: AUTHENTICATE KERBEROS_V4
            S: AmFYig==
            C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
            S: or//EoAADZI=
            C: DiAF5A4gA+oOIALuBkAAmw==
            S: 2.0
            S: IDENTITY=bill@example.com
            S: CAPVERSION=1.0

            S: ITIPVERSION=1.0
            S: AUTH=KERBEROS_V4
            S: AUTH=DIGEST_MD5
            S: CAR=CAR-FULL-1
            S: MINDATE=19700101T000000Z
            S: MAXDATE=20380118T191407Z
            S: .

          9.1.2  Error Scenarios

          Use of multiple OBJECT and
VALUE pairs must SASL Authorization Identity is not supported. Use the
          IDENTITY command instead. If you attempt to use the
          Authorization Identity, an error status will be true for returned.

            C: AUTHENTICATE KERBEROS_V4
            S: AmFYig==
            C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
            S: or//EoAADZI=
            C: DiAF5A4gA+oOIALuBkAAmw==
            S: 6.1
            S: .

          Sender aborted authentication:

            C: AUTHENTICATE KERBEROS_V4
            S: AmFYig==
            C: .
            S: 6.2
            S: .

          Unsupported mechanism:

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            C: AUTHENTICATE Experimental_Auth
            S: 6.3
            S: .

          9.2 Read Examples

          10.2.1. Read From A Single Calendar

          In this example bill@example.com reads a day's worth of events
          from cap://cal.example.com/opaqueid99.

            C: SENDDATA
            C: Content-type:text/calendar; Method=READ; Component=VQUERY
            C:
            C: BEGIN:VCAP
            C: VERSION:2.1
            C: BEGIN:VCOMMAND
            C: METHOD:READ
            C: CMDID:xyz12345

            C: TARGET:cap://cal.example.com/opaqueid99
            C: BEGIN:VQUERY
            C: QUERY:SELECT DTSTART,DTEND,SUMMARY, UID FROM VEVENT
              WHERE DTEND >= '19990714T080000Z'
              AND DTSTART <= '19990715T080000Z'
            C: END:VQUERY
            C: END:VCOMMAND
            C: END:VCAP
            C: .
            # this response code means that the GRANT or DENY to apply.

  The UPN rule part specifies transport successfully
            # delivered the CU or UG to which data.
            S: 2.0 ; got the
VCARs applies.
  The value of request OK ; really
            S: .
            S: Content-type:text/calendar; Method=RESPONSE;
            S:  Optinfo=VERSION:2.1
            S: Content-Transfer-Encoding: 7bit
            S:
            S: BEGIN:VCAP
            S: VERSION:2.1
            S: METHOD:RESPONSE
            S: TARGET:cap://cal.example.com/opaqueid99
            S: CMDID:xyz12345
            S: REQUEST-STATUS:2.0
            S: BEGIN:VEVENT
            S: DTSTART:19990714T200000Z
            S: DTEND:19990714T210000Z

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            S: UID:000444888929922
            S: SUMMARY:Blah bla
            S: END:VEVENT
            S: BEGIN:VEVENT
            S: UID:0034848098038888989443
            S: SUMMARY:meeting
            S: DTEND:19990714T233000Z
            S: DTSTART:19990714T223000Z
            S: END:VEVENT
            S: END:VCAP
            S: .

          9.2.1  Read From Multiple Calendars

          In this rule part is either a quoted text
specifying a UPN or
  an unquoted text specifying a keyword enumerating example bill@example.com reads a
standard
  authenticated user type. If the value is the keyword is *,
then the rule
  applies to all authenticated calendar users (i.e., all
UPNs). If the
  value is the keyword OWNER, then the rule applies day's worth of events
          from cap://cal.example.com/opaqueid101 and
          cap://cal.example.com/opaqueid103

            C: SENDDATA
            C: Content-type:text/calendar; Method=READ; Component=VQUERY
            C:
            C: BEGIN:VCAP
            C: VERSION:2.1
            C: BEGIN:VCOMMAND
            C: METHOD:READ
            C: CMDID:xyz12346
            C: TARGET:cap://cal.example.com/opaqueid101
            C: TARGET:opaqueid103
            C: BEGIN:VQUERY
            C: VSCOPE:VEVENT

            C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
            C: WHERE DTEND >= 19990714T080000Z AND
            C:   DTSTART <= 19990715T080000Z
            C: END:VQUERY
            C: END:VCOMMAND
            C: END:VCAP
            C: .
            S: 2.0
            S: .
            S: Content-Type:multipart/mixed;
            S:  boundary="--FEE3790DC7E35189CA67"
            S:
            S: ----FEE3790DC7E35189CA67
            S: Content-type:text/calendar; Method=RESPONSE;
            S: Optinfo=VERSION:2.1
            S: Content-Transfer-Encoding: 7bit

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            S:
            S: BEGIN:VCAP
            S: VERSION:2.1
            S: METHOD:RESPONSE
            S: TARGET:cap://cal.example.com/opaqueid103
            S: CMDID:xyz12346
            S: REQUEST-STATUS:2.0
            S: BEGIN:VEVENT
            S: UID:0034848098038888989443
            S: SUMMARY:meeting
            S: DTEND:19990714T233000Z
            S: DTSTART:19990714T223000Z
            S: END:VEVENT
            S: END:VCAP
            S:
            S: ----FEE3790DC7E35189CA67CE2C
            S: Content-type:text/calendar; Method=RESPONSE;
            S: Optinfo=VERSION:2.1
            S: Content-Transfer-Encoding: 7bit
            S:
            S: BEGIN:VCAP
            S: VERSION:2.1
            S: METHOD:RESPONSE
            S: TARGET:cap://cal.example.com/opaqueid101
            S: CMDID:xyz12346
            S: REQUEST-STATUS:4.1 ; access denied
            S: END:VCAP
            S:
            S: ----FEE3790DC7E35189CA67CE2C
            S: .

          9.2.2  Timeouts

          In this example bill@example.com attempts to any
of the owners
  of the read a calendar store or calendar. If the value is the
keyword NONOWNER,
  then
          but the rule applies to a UPN that latency time he supplies is not sufficient for the owner of
          server to complete the calendar
  store or calendar. command.

            C: SENDDATA 3
            C: Content-type:text/calendar; Method=READ; Component=VQUERY

            C:
            C: BEGIN:VCAP
            C: VERSION:2.1
            C: BEGIN:VCOMMAND
            C: METHOD:READ
            C: CMDID:xyz12346
            C: TARGET:cap://cal.example.com/opaqueid101

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

            C: TARGET:opaqueid103
            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:VCOMMAND
            C: END:VCALENDAR
            C: .
            S: 7.0 ; xyz12346
            S: .
            S: .

          If this rule part is not specified in
the value, then
  the calendar access rights do not apply Bill wants to any UPN. In
this case, the
  calendar access rights can be defined for reference by
another instance
  of a calendar access rights. For example, a complex set of
calendar
  access rights can be defined once continue and referenced many
times in give the
  rights specified for individual calendar users.

  The CARREF rule part specifies a reference to a particular
"VCAR"
  calendar component. The text is matched to a CARID
property value within
  a "VCAR" calendar component. This allows for server more time he
          would issue a particular
set of
  calendar access rights to be defined once and referenced
multiple times.
  The "VCAR" identifier specified by this rule part is
unique CONTINUE command:

            C: CONTINUE 10 ; xyz12346

          If Bill wants to abort the
  calendar store.

  Predefined calendar access CARIDs that MUST be
implememnetd (CAR-MIN)
  are:
   CARID:READBUSYTIMEINFO - Specifies rights for reading
VFREEBUSY
   components by anonymous command and known users. Suggested VCAR
to allow all
   users to read VFREEBUSY components:

    BEGIN:VCAR
    CARID:READBUSYTIMEINFO
    GRANT:UPN=*;ACTION=READ;OBJECTS=VFREEBUSY;VALUE=*
    END:VCAR

   CARID:REQUESTONLY - Specifies rights for creating new
event
   invitations, to-do assignments not wait any further he
          would issue an ABORT command:

            C: ABORT ; xyz12346
            S: 2.0
            S: .
            S: .

          9.2.3  Using Parent and journal entries by
users other
   than the owner of Children Properties

          9.2.4  Query VEVENT.DTSTART and VALARM.DTSTART

          10 Implementation Issues

          1. What are the calendar. Suggested VCAR to allow
access by
   nonowners minimum component properties set required to deposit
          create a REQUEST in new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART,
          SUMMARY and UID.

          [EDITORS NOTE (dr): They MUST be the CS:

    BEGIN:VCAR
    CARID:REQUESTONLY
    GRANT:UPN=NONOWNER;ACTION=CREATE;OBJECT=*
    ;OBJECT=METHOD;VALUE=REQUEST
    END:VCAR

   CARID:UPDATEPARTSTATUS - Specifies rights same as for iTIP]

          2. What is the state of all undefined properties? PROPOSAL:
          Not defined. So a user to
modify their
   participation status in a calendar they do query will not own.
Suggested VCAR
   to allow users to update their own participation status:

    BEGIN:VCAR
    CARID:UPDATEPARTSTATUS
    GRANT:UPN=*;ACTION=MODIFY
    ;OBECT=PARTSTAT:VALUE=*
    ;OBJECT=ATTENDEE;VALUE=SELF
    END:VCAR

   CARID:DEFAULTOWNER - Specifies the return them, if they are
          selected.

          [EDITORS NOTE (dr): Many have default access for any
owner of values, a
   calendar. Suggested VCAR CS may return
          the default values?]

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          11 Properties

          [EDITORS NOTE: These extensions/changes to all owners access iCalendar need to their
own
   calendars:

    BEGIN:VCAR
    CARID:DEFAULTOWNER
    GRANT:UPN=OWNER;ACTION=*;OBJECT=*;VALUE=*;
    END:VCAR

  The ACTION rule part defines one or more CAP actions that
are allowed
  for the UPN. The valid values are CREATE, DELETE, MODIFY,
MOVE, READ,
  and all of the [iTIP] scheduling commands; PUBLISH,
REQUEST, REPLY, ADD,
  CANCEL, REFRESH, COUNTER, DECLINECOUNTER, corresponding
          be reformatted to conform to the
  scheduling commands; and '*', meaning all IANA registration process
          defined in section 7 of [iCAL].]

          11.1    Calendar Store Properties
          The following are properties of calendaring
commands and
  scheduling commands. Multiple ACTION enumerations can the calendar store.

          Name           Read  Value     Description
                         Only  Type
          --------------------------------------------------------------
          CALMASTER      N     URI       The email address for a
                                         Responsible person. MUST be
specified as a
  COMMA character (US-ASCII decimal 44) separated list of
ACTION
  enumerated values.
                                         mailto URL.

          CSID           Y     URI       The text '*' CSID of this calendar
                                         store. If not specified, it is
                                         the same as specifying
the enumerated
  values "CREATE,MODIFY,DELETE,READ,MOVE",.

  The OBJECT rule part defines the calendar store property,
calendar
  property, calendar component, component property, hostname or
parameter that
                                         virtual host name.

          DEFAULT_VCARS  N     TEXT      A multivalued property
                                         Containing the
  ACTION default VCARs
                                         for newly created top level
                                         calendars. Each entry is restricted to. Multiple OBJECT enumerations can
be specified
  as a COMMA character (US-ASCII decimal 44) separated list
of OBJECT
  enumerated values. The value '*; specifies any
                                         CARID It MUST include at a
                                         minimum
                                         READBUSYTIMEINFO,REQUESTONLY,
                                         UPDATEPARTSTATUS, and all
valid objects.
                                         DEFAULTOWNER.

          MAXDATE        Y     DATE-TIME The VALUE rule part specifies date/time in the restricted values for future
                                         beyond which the OBJECT rule
  part. Multiple VALUE strings can be specified as a COMMA
character (US-
  ASCII decimal 44) separated list of VALUE strings. The
text '*'
  specifies any and all valid values. server cannot
                                         represent. If an OBJECT rule part
is specified
  but no corresponding VALUE rule part is not specified,
                                         then
the rule applies
  to any and all valid values of the specified OBJECT(s).

  Example: The following is a rule which specifies access
rights for "foo"
  calendar user to read busy time values:

   UPN="foo@host.com";ACTION=READ;OBJECT=DTSTART,DTEND

14.3. VCAR Calendar Component

  Component Name: "VCAR"

  Purpose: Provide a grouping of calendar access rights.

  Format Definition: A "VCAR" calendar component is defined
by the
  following notation:

  aclc   =  "BEGIN" ":" "VCAR" CRLF
         carprop
         "END" ":" "VCAR" CRLF

  carprop =   carid 1*(grant / deny)

  Description: A "VCAR" calendar component is a grouping of
calendar
  access rights component properties. 99991231T235959 will be
                                         assumed.

          MINDATE        Y     DATE-TIME The "CARID" property specifies date/time in the past prior
                                         To which the server cannot
                                         represent. If not specified,
                                         then 00000101T000000 will be
                                         assumed.

          CURRENT_DATETIME  Y  DATE-TIME Current server time. This is
                                         returned as a local identifier for time and
                                         TZID.

          RECUR_ACCEPTED  Y    BOOLEAN   Boolean value will be set to

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                                         TRUE if the "VCAR"
  calendar component. The "GRANT" property specifies
calendar access
  rights granted server will accept
                                         recurrence rules. It will be
                                         set to an UPN. The "DENY" property specifies
calendar access
  rights denied from an UPN.

  Example: In FALSE if the following example, server will
                                         not accept recurrence rules. If
                                         not specified a CUA MUST assume
                                         TRUE.

          RECUR_EXPAND   Y     BOOLEAN   If set to TRUE, the UPN "foo@host.com"
has read
  access CS supports
                                         The expansion of recurrence
                                         rules. If set to FALSE, the "DTSTART" and "DTEND" calendar properties.
No other access CS
                                         is specified:

  BEGIN:VCAR
  CARID:"View Start and End Times"
  GRANT:UPN=foo@host.com;ACTION="READ";OBJECT=DTSTART,DTEND
  END:VEVENT

  In this example, all UPNs are given read access to
"DTSTART" and
  "DTEND". "All CUs and UGs" are incapable of expanding
                                         recurrence rules. If not
                                         specified by a CUA MUST assume
                                         TRUE.

          RECUR_LIMIT    Y   INTEGER     This numeric value describes
                                         How the UPN server handles
                                         unbounded recurrences. The
                                         value
"*". Note
  that this enumerated UPN is only valid if
                                         RECURRENCE is TRUE. If the
                                         value is not in quotes.:

  BEGIN:VCAR
  CARID:"View Start and End Times 2"
  GRANT:UPN=*;ACTION=READ;OBJECT=DTSTART,DTEND
  END:VCAR

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

  BEGIN:VCAR
  CARID:"View PUBLIC Start and End Times"
  GRANT:UPN=*;ACTION=READ;OBJECT=DTSTART,DTEND
  ;OBJECT=CLASS;VALUE=PUBLIC
  END:VCAR

  In this example, rights are specified 0 it means that the
                                         server supports unbounded
                                         recurrence rules. If it is non-
                                         zero, it is a positive integer
                                         indicating the number of
                                         instances that will be created
                                         when the server expands an
                                         unbounded recurrence rule when
                                         fetched from the CS. A CUA MUST
                                         query for all UPNs to read
or modify
  existing components classified as PUBLIC:

  BEGIN:VCAR
  CARID:"Read and Modify PUBLIC Calendar Entries"
  GRANT:UPN=*;ACTION=READ,MODIFY;OBJECT=*
  ;OBJECT=CLASS;VALUE=PRIVATE
  END:VCAR

  In date ranges when this example, full calendar access rights are given to
                                         value is zero.

          VERSION        Y   TEXT        The version of the OWNER CS. The
                                         Default and
  a hypothetical administrator is given access rights to
specify calendar
  access rights. If no other rights are specified, the only
these two UPNs can
  specify calendar access rights:

  BEGIN:VCAR
  CARID:"Only OWNER or ADMIN Settable CARs"
  GRANT:UPN=OWNER;ACTION=*;OBJECT=*
  GRANT:UPN=cal-admin@host.com;ACTION=*;OBJECT=VCAR;VALUE=*

  END:VCAR

  In this example, rights to create, read, modify or delete
calendar
  access rights are denied to all UPNs. This example would
disable
  providing different access rights currently
                                         Supported version is "2.0" to
                                         match the calendar store or
calendar. [iCAL] VERSION.

          11.2    Calendar Properties

          Name           Read  Value     Description
                         Only  Type
          --------------------------------------------------------------
          ALLOW-CONFLICTS N    BOOLEAN   This calendar access rights should boolean value indicates
                                         Whether or not be specified, as
they the ability
  to change calendar access; even for the owner
                                         supports event conflicts. That
                                         is, whether or
administrator:

  BEGIN:VCAR
  CARID:"No CAR At All"
  DENY:UPN=*;OBJECT=VCAR;VALUE=CARID,GRANT,DENY
  ENG:VCAR

14.4. GRANT Component Property

  Property Name: GRANT

  Purpose: This property specifies those access rights
granted to a UPN.

  Value Type: RIGHTS

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

  Conformance: This property can be specified not any of the
                                         events in "VCAR"
calendar
  component.

  Description: This property is used to grant calendar
access rights to a
  UPN.

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

  grant      = "GRANT" rightsparam ":" carrights CRLF
  rightsparam   = *(";" xparam)

14.5. DENY Component Property

  Property Name: DENY

  Purpose: This property specifies those access rights
denied from a UPN.

  Value Type: RIGHTS

  Property Parameters: Only non-standard property parameters calendar can be
                                         overlap. If not specified on the

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                                         default value is TRUE meaning
                                         that conflicts are allowed.

          CALSCALE        N    TEXT      The CALSCALE for this property.

  Conformance: This property can be calendar.
                                         If not specified the default is
                                         GREGORIAN.

          CHARSET         N    TEXT      The default charset for
                                         Localized strings in "VCAR"
calendar
  component.

  Description: This property this
                                         calendar. If not specified, the
                                         default is used to deny calendar access
rights UTF-8.

          CHILDREN        Y    TEXT      The list of sub-calendars
                                         Belonging to this calendar. An
                                         empty list means no children.
                                         The results may be a
  UPN.

  Format Definition: comma
                                         separated list of children.
                                         Each entry returned is a CALID.
                                         The property default is defined by the
following notation:

  DENY   = "DENY" rightsparam ":" carrights CRLF
  rightsparam   = *(";" xparam)

  Example: In an empty list.

          CREATED         Y    DATE-TIME The timestamp of the following example, any UPN who calendar's
                                         create date.

          DEFAULT_VCAR    N    TEXT      The default VCARs for newly
                                         Created top level calendars.
                                         This is not the
owner a CARID. The default
                                         value is
  denied rights to create, modify or delete entries:

  DENY:UPN=NONOWNER;ACTION=CREATE,MODIFY,DELETE;OBJECT=*

14.6. VCAR Identifier Component Property

  Property Name: CARID

  Purpose: This property specifies the identifier for a
"VCAR" calendar
  component.

  Value Type: value of
                                         DEFAULT_VCAR in the CALSTORE
                                         table.

          LANGUAGE        N    TEXT

  Property Parameters: Non-standard property parameters can
be specified
  on      The default language for
                                         localizable strings in this property.

  Conformance:
                                         calendar. There is no default.
                                         This property can value MUST NOT be specified in "VCAR"
calendar
  component.

  Description: This property permits previously defined sets empty.

          LAST-MODIFIED   N    DATE-TIME The timestamp when the
                                         Properties of the calendar
  access rights to be specified with a reference. This
capability
  facilitates repetitively specifying calendar access
rights.

  Format Definition: were
                                         last updated. Default is the
                                         same as CREATED.

          NAME            N    TEXT      The display name for this
                                         calendar. It is a localizable
                                         string. If not provided, an
                                         empty value will be returned.

          OWNERS          N    URI       A multi-instanced property is defined by
                                         indicating the
following notation:

  CARID = "CARID" textparam ":" text CRLF

  Example: calendar owner.
                                         Each entry returned will be a
                                         UPN. There must be at least one

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

                                         owner.

          PARENT          N    URI       The following is an example CALID of this property:

  CARID:"Restrict Guests From Creating ALARMs On Events"

14.7. REQUEST-STATUS property

  This description is calendars
                                         Parent maintained by a revision of CAP
                                         server. An empty value means
                                         the REQUEST-STATUS
property for
  VCALENDAR version 2.1.

  rstatus  = "REQUEST-STATUS" rstatparam ":"
    statcode [";" statdesc [";" extdata]]

  rstatparam  = *(
   ; calendar is the following top level
                                         parent. The default value is optional,
   ; but MUST NOT occur more than once

     (";" languageparm) /

   ; no
                                         parent.

          RELCALID        N    URI       A unique name for the following calendar.
                                         There is optional,
   ; no default value 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
                                         This value MUST NOT be empty.

  extdata  = text
   ;Textual exception data. For example, the offending
property
   ;name and

          TOMBSTONE       N    BOOLEAN   TRUE indicator that this
                                         Calendar has been marked as
                                         deleted. The default value or complete property line.

  Example: is
                                         FALSE.

          TZID            N    TEXT      The following are some possible examples id of the timezone
                                         Associated with this
property. The
  COMMA and SEMICOLON separator characters calendar.
                                         See TZID in the property [iCAL]. The default
                                         value are
  BACKSLASH character escaped because they appear in a 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.

15. GMT.

          12 Security Considerations

          For the mandatory SASL mechanism that CAP specifies, the
          mechanism support is:

            MUST authentication
            MUST authorization
            MAY impersonation

          13 CAP Item Registration

          This section provides the process for registration of new or
          modified CAP entities.

  15.1

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

  15.2

          13.2    Registration of New Entities

          This section defines procedures by which new entities (i.e.,
          components, properties, parameters, enumerated values or

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          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.

15.1.1.

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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          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.

15.1.2.

          13.2.2  Post the item definition

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

15.1.3.

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

15.1.4.

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

15.2.

          13.3    Property Change Control

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          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.

16.

          14 IANA Considerations

          This memo defines IANA registered extensions to the attributes
          defined by iCalendar, as defined in [iCAL], and [iTIP], as
          defined in [VCARD].

          [EDITORS NOTE (DR): RFC2426 - is vCard. This needs more
          explanation. What does vCARD have todo with this?]

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

17.

          15 Acknowledgments

          The following have individuals were major contributors in the
          drafting and discussion of this memo:

          Harald Alvestrand, Mario Bonin, Andre Courtemanche, Dave
          Crocker, Pat Egen, Gilles Fortin, Jeff Hodges, Alex Hoppman,
          Bruce Kahn, Lisa Lippert, David Madeo, Bob Mahoney, Bob
          Morgan, Pete O'Leary, Richard Shusterman, Tony Small, John
          Stracke, Mark Wahl.

18. Wahl, Alexander Taler.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          16 Bibliography

          [MIME] N. Borenstein and N. Freed, "MIME (Multipurpose
          Internet Mail Extensions) Part One: Mechanisms for Internet Draft UTF-
          Specifying and Describing the Format of Internet Message
          Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

          [TLS] Dierks, Allen, "The TLS Protocol", RFC 2246, January
          1999

          [RFC2119] TODO...

          [SASL] RFC2222 TODO...

          [URL] Berners-Lee, Fielding, Masinter, "Uniform Resource
          Identifiers

          (URI): Generic Syntax", RFC 2396, August 1998.

          [iCAL] Dawson, Stenerson, "Internet Calendaring and Scheduling
          Core Object Specification (iCalendar)", RFC 2445, November
          1998

          [iTIP] Silverberg, Mansour, Dawson, Hopson, "iCalendar
Transport-
  Independent
          Transport-Independent Interoperability Protocol (iTIP)", RFC
          2446, November 1998

          [iMIP] Dawson, Mansour, Silverberg, "iCalendar Message-
Based Message-Based
          Interoperability Protocol (iMIP)", RFC 2445, November 1998

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

          [VCARD] RFC.... TODO

19.

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          17 Author's Address
          The following address information is provided in a vCard v3.0,
          the [VCARD] electronic business card format.

          Steve Mansour
  Cheif Cook
          Judge, Jury, and Bottle Washer
  Netscape Executioner
          Netscape, iPlanet
          501 E Middlfield Road
          Mountain View, CA 94043 USA
          Phone:  +1-650-937-2378
  Fax: +1-650-937-2103  +1-408-276-4268
          mailto:sman@netscape.com

          Paul Hill
          Senior Programmer Analyst
          Massachusetts Institute of Technology
          W92-172
          77 Massachusetts Avenue
          Cambridge, MA, USA
          02139
          Phone:  +1-617-253-0124
          Fax: +1-617-258-8736
          mailto:pbh@mit.edu

          Doug Royer
  Architect - Messaging
  Software.com
  Suite 106
  530 E. Montecito St
  Santa Barbara, CA 93103 USA
  Phone:  +1-805-957-1790 x541

  Fax: +1-805-957-1544
          mailto:Doug@Royer.com

          George Babics
  Research & Development
  Corporate Software & Technologies
  3333 Graham Boulevard, 5th floor
          Steltor (formerly CS&T/Lexacom)
          2000 Peel Street
          Montreal, Quebec, Canada
  H3R 3L5
          H3A 2W5
          Tel: (514) 733-8500 x303 x4201
          Fax: (514) 733-8878
  mailto: georgeb@cst.ca

20.
          Mailto: georgeb@steltor.com

          18 Full Copyright Statement

          "Copyright (C) The Internet Society (2000). 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

          <draft-ietf-calsch-cap-04.txt>   CAP   Expires September 2001

          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.

Network Working Group         Steve Mansour/Netscape
Internet Draft      Doug Royer
<draft-ietf-calsch-cap-03.txt>          George
Babics/Steltor
          Paul Hill/MIT