draft-ietf-calsch-cap-04.txt   draft-ietf-calsch-cap-05.txt 
Network Working Group Steve Mansour/Netscape Network Working Group S. Mansour
Internet Draft Doug Royer Internet-Draft Netscape, iPlanet
<draft-ietf-calsch-cap-04.txt> George Babics/Steltor Expires: January 18, 2002 D. Royer
Paul Hill/MIT
G. Babics
Steltor
P. Hill
Massachusetts Institute of
Technology
July 20, 2001
Calendar Access Protocol (CAP) Calendar Access Protocol (CAP)
draft-ietf-calsch-cap-05
Status of this Memo Status of this Memo
This memo is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet Engineering
Engineering Task Force (IETF), its areas, and its working Task Force (IETF), its areas, and its working groups. Note that
groups. Note that other groups may also distribute working other groups may also distribute working documents as Internet-
documents as Internet-Drafts. Internet-Drafts are draft Drafts.
documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any 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 time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt . http://www.ietf.org/ietf/1id-abstracts.txt .
The list of Internet-Draft Shadow Directories can be accessed The list of Internet-Draft Shadow Directories can be accessed at
at http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. This Internet-Draft will expire on January 18, 2002.
Copyright Statement Copyright Notice
Copyright (C) The Internet Society 2000. All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The Calendar Access Protocol (CAP) is an Internet protocol The Calendar Access Protocol (CAP) is an Internet protocol that
that permits a Calendar User (CU) to utilize a Calendar User permits a Calendar User (CU) to utilize a Calendar User Agent (CUA)
Agent (CUA) to access an [iCAL] based Calendar Store (CS). to access an [iCAL] based Calendar Store (CS). This memo defines the
This memo defines the CAP specification. CAP specification.
The CAP definition is based on requirements identified by the The CAP definition is based on requirements identified by the
Internet Engineering Task Force (IETF) Calendaring and Internet Engineering Task Force (IETF) Calendaring and Scheduling
Scheduling (CALSCH) Working Group. More information about the (CALSCH) Working Group. More information about the IETF CALSCH
IETF CALSCH Working Group activities can be found on the IMC Working Group activities can be found on the IMC web site at
web site at http://www.imc.org/ietf-calendar, and at the IETF http://www.imc.org/ietf-calendarand at the IETF web site at
web site at http://www.ietf.org/html.charters/calsch- http://www.ietf.org/html.charters/calsch-charter.html[1]. Refer to
charter.html. Refer to the references within this memo for the references within this memo for further information on how to
further information on how to access these various documents. access these various documents.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
Table Of Contents
1 Introduction.............................................4
1.1 Formatting Conventions...............................4
1.2 Related Documents....................................5
1.3 Definitions..........................................5
2 CAP Design..............................................12
2.1 System Model........................................12
2.2 Calendar Store Object Model.........................13
2.3 Protocol Model......................................15
2.4 Security Model......................................16
2.4.1 Authentication, Credentials, and Identity........17
2.4.2 Calendar User and UPNs...........................18
2.4.3 User Groups......................................21
2.4.4 Access Rights - Summary..........................22
2.4.5 Inheritance......................................23
2.4.6 CAP Session Identity.............................24
2.5 Roles...............................................25
2.6 Calendar Addresses..................................25
2.7 Extensions to iCalendar.............................26
2.8 Relationship of RFC 2446 (ITIP) to CAP..............27
3 State Diagram...........................................29
4 Protocol Framework......................................30
4.1 CAP Application Layer...............................30
4.2 CAP Transfer Protocol...............................31
4.3 Pipelining of Commands..............................32
4.4 Auto-logout Timer...................................32
4.5 Bounded Latency.....................................32
4.6 Data Elements.......................................32
5 Formal Command Syntax...................................32
5.1 Searching and Filtering.............................32
5.1.1 Grammar For Search Mechanism.....................33
5.1.2 SQL-MIN notes....................................34
5.1.3 SQL-92 notes.....................................35
5.1.4 Example, Query by UID............................35
5.1.5 Query by Date-Time range.........................35
5.1.6 Query for all Non-Booked Entries.................36
5.1.7 Query with Subset of Properties by Date/Time.....36
5.1.8 Components With Alarms In A Range................36
6 Access Rights...........................................37
6.1 VCAR Inheritance....................................37
6.2 Access Control and NOCONFLICT.......................37
7 Commands and Responses..................................38
7.1 Transfer Protocol Commands..........................38
7.1.1 Initial Connection...............................38
7.1.2 ABORT Command....................................39
7.1.3 AUTHENTICATE Command.............................39
7.1.4 CALIDEXPAND Command..............................43
7.1.5 CAPABILITY Command...............................45
7.1.6 CONTINUE Command.................................47
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
7.1.7 DISCONNECT Command...............................48 Table of Contents
7.1.8 SENDDATA Command.................................49
7.2 Application Protocol Commands.......................52
7.2.1 Calendaring Commands.............................52
7.2.2 Scheduling Commands..............................84
7.2.3 iTIP 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 Children Properties............103
9.2.4 Query VEVENT.DTSTART and VALARM.DTSTART.........103
10 Implementation Issues................................103
11 Properties...........................................104
11.1 Calendar Store Properties........................104
11.2 Calendar Properties..............................105
12 Security Considerations..............................107
13 CAP Item Registration................................107
13.1 Registration of New and Modified CAP Entities....107
13.2 Registration of New Entities.....................107
13.2.1 Define the Item...............................108
13.2.2 Post the item definition......................109
13.2.3 Allow a comment period........................109
13.2.4 Submit the proposal for approval..............109
13.3 Property Change Control..........................109
14 IANA Considerations..................................110
15 Acknowledgments......................................110
16 Bibliography.........................................111
17 Author's Address.....................................112
18 Full Copyright Statement.............................112
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 1. Introduction . . . . . . . . . . . . . . . . . . . . . 5
1.1 Formatting Conventions . . . . . . . . . . . . . . . . 5
1.2 Related Documents . . . . . . . . . . . . . . . . . . 6
1.3 Definitions . . . . . . . . . . . . . . . . . . . . . 6
2. CAP Design . . . . . . . . . . . . . . . . . . . . . . 13
2.1 System Model . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Firewalls and Fanout . . . . . . . . . . . . . . . . . 14
2.2 Calendar Store Object Model . . . . . . . . . . . . . 15
2.3 Protocol Model . . . . . . . . . . . . . . . . . . . . 16
2.4 Security Model . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Authentication, Credentials, and Identity . . . . . . 18
2.4.2 Calendar User and UPNs . . . . . . . . . . . . . . . . 19
2.4.2.1 UPNs and Certificates . . . . . . . . . . . . . . . . 19
2.4.2.2 Anonymous Users and Authentication . . . . . . . . . . 20
2.4.2.3 Required Security Mechanisms . . . . . . . . . . . . . 21
2.4.2.4 TLS Ciphersuites . . . . . . . . . . . . . . . . . . . 21
2.4.3 User Groups . . . . . . . . . . . . . . . . . . . . . 22
2.4.4 Access Rights - Summary . . . . . . . . . . . . . . . 23
2.4.4.1 VCalendar Access Right (VCAR) . . . . . . . . . . . . 24
2.4.4.2 Decreed VCARs . . . . . . . . . . . . . . . . . . . . 24
2.4.5 Inheritance . . . . . . . . . . . . . . . . . . . . . 25
2.4.6 CAP Session Identity . . . . . . . . . . . . . . . . . 25
2.5 Roles . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Calendar Addresses . . . . . . . . . . . . . . . . . . 26
2.7 Extensions to iCalendar . . . . . . . . . . . . . . . 27
2.8 Relationship of RFC 2446 (ITIP) to CAP . . . . . . . . 28
3. State Diagram . . . . . . . . . . . . . . . . . . . . 30
4. Protocol Framework . . . . . . . . . . . . . . . . . . 32
4.1 CAP Application Layer . . . . . . . . . . . . . . . . 32
4.2 CAP Transfer Protocol . . . . . . . . . . . . . . . . 32
4.3 Pipelining Commands . . . . . . . . . . . . . . . . . 33
4.4 Auto-logout Timer . . . . . . . . . . . . . . . . . . 33
4.5 Bounded Latency . . . . . . . . . . . . . . . . . . . 33
4.6 Data Elements . . . . . . . . . . . . . . . . . . . . 34
5. Formal Command Syntax . . . . . . . . . . . . . . . . 35
5.1 Searching and Filtering . . . . . . . . . . . . . . . 35
5.1.1 Grammar For Search Mechanism . . . . . . . . . . . . . 35
5.1.2 SQL-MIN notes . . . . . . . . . . . . . . . . . . . . 36
5.1.3 SQL-92 notes . . . . . . . . . . . . . . . . . . . . . 37
5.1.4 Example, Query by UID . . . . . . . . . . . . . . . . 37
5.1.5 Query by Date-Time range . . . . . . . . . . . . . . . 38
5.1.6 Query for all Non-Booked Entries . . . . . . . . . . . 38
5.1.7 Query with Subset of Properties by Date/Time . . . . . 38
5.1.8 Components With Alarms In A Range . . . . . . . . . . 39
6. Access Rights . . . . . . . . . . . . . . . . . . . . 40
6.1 VCAR Inheritance . . . . . . . . . . . . . . . . . . . 40
6.2 Access Control and NOCONFLICT . . . . . . . . . . . . 40
7. Commands and Responses . . . . . . . . . . . . . . . . 41
7.1 Transfer Protocol Commands . . . . . . . . . . . . . . 41
7.1.1 Initial Connection . . . . . . . . . . . . . . . . . . 41
7.1.2 ABORT Command . . . . . . . . . . . . . . . . . . . . 42
7.1.3 AUTHENTICATE Command . . . . . . . . . . . . . . . . . 42
7.1.3.1 AUTHENTICATE ANONYMOUS . . . . . . . . . . . . . . . . 45
7.1.4 CALIDEXPAND Command . . . . . . . . . . . . . . . . . 46
7.1.5 CAPABILITY Command . . . . . . . . . . . . . . . . . . 48
7.1.6 CONTINUE Command . . . . . . . . . . . . . . . . . . . 50
7.1.7 DISCONNECT Command . . . . . . . . . . . . . . . . . . 51
7.1.8 IDENTIFY Command . . . . . . . . . . . . . . . . . . . 52
7.1.9 SENDDATA Command . . . . . . . . . . . . . . . . . . . 52
7.1.10 STARTTLS Command . . . . . . . . . . . . . . . . . . . 53
7.1.11 UPNEXPAND Method . . . . . . . . . . . . . . . . . . . 53
7.1.12 NOOP Command . . . . . . . . . . . . . . . . . . . . . 55
7.2 Application Protocol Commands . . . . . . . . . . . . 55
7.2.1 Calendaring Commands . . . . . . . . . . . . . . . . . 55
7.2.1.1 Restriction Tables . . . . . . . . . . . . . . . . . . 56
7.2.1.2 CREATE Method . . . . . . . . . . . . . . . . . . . . 56
7.2.1.2.1 Creating New Calendars . . . . . . . . . . . . . . . . 64
7.2.1.2.2 Creating a new VQUERY . . . . . . . . . . . . . . . . 66
7.2.1.3 DELETE Method . . . . . . . . . . . . . . . . . . . . 67
7.2.1.4 GENERATEUID Method . . . . . . . . . . . . . . . . . . 71
7.2.1.5 MODIFY Method . . . . . . . . . . . . . . . . . . . . 71
7.2.1.6 MOVE Method . . . . . . . . . . . . . . . . . . . . . 80
7.2.1.7 READ Method . . . . . . . . . . . . . . . . . . . . . 83
7.2.1.7.1 Query With A Stored Query . . . . . . . . . . . . . . 90
7.2.2 Scheduling Commands . . . . . . . . . . . . . . . . . 91
7.2.2.1 Reading Scheduling Components . . . . . . . . . . . . 92
7.2.2.2 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 93
7.2.2.3 REQUEST . . . . . . . . . . . . . . . . . . . . . . . 94
7.2.2.4 REPLY . . . . . . . . . . . . . . . . . . . . . . . . 94
7.2.2.5 ADD . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.2.2.6 CANCEL . . . . . . . . . . . . . . . . . . . . . . . . 95
7.2.2.7 REFRESH . . . . . . . . . . . . . . . . . . . . . . . 95
7.2.2.8 COUNTER . . . . . . . . . . . . . . . . . . . . . . . 96
7.2.2.9 DECLINECOUNTER . . . . . . . . . . . . . . . . . . . . 96
7.2.3 iTIP Examples . . . . . . . . . . . . . . . . . . . . 96
7.2.3.1 Sending and Receiving an iTIP request . . . . . . . . 96
7.2.3.2 Handling an iTIP refresh . . . . . . . . . . . . . . . 99
7.2.3.3 Sending and accepting an iTIP counter . . . . . . . . 100
7.2.3.4 Declining an iTIP counter . . . . . . . . . . . . . . 102
8. Response Codes . . . . . . . . . . . . . . . . . . . . 104
8.1 Examples . . . . . . . . . . . . . . . . . . . . . . . 106
8.1.1 Authentication Examples . . . . . . . . . . . . . . . 106
8.1.1.1 Login Using Kerberos V4 . . . . . . . . . . . . . . . 106
8.1.1.2 Error Scenarios . . . . . . . . . . . . . . . . . . . 106
8.2 Read Examples . . . . . . . . . . . . . . . . . . . . 106
8.2.1 Read From A Single Calendar . . . . . . . . . . . . . 106
8.2.2 Read From Multiple Calendars . . . . . . . . . . . . . 107
8.2.3 Timeouts . . . . . . . . . . . . . . . . . . . . . . . 109
8.2.4 Using Parent and Children Properties . . . . . . . . . 110
8.2.5 Query VEVENT.DTSTART and VALARM.DTSTART . . . . . . . 110
9. Implementation Issues . . . . . . . . . . . . . . . . 111
10. Properties . . . . . . . . . . . . . . . . . . . . . . 112
10.1 Calendar Store Properties . . . . . . . . . . . . . . 112
10.2 Calendar Properties . . . . . . . . . . . . . . . . . 113
11. Security Considerations . . . . . . . . . . . . . . . 116
12. CAP Item Registration . . . . . . . . . . . . . . . . 117
12.1 Registration of New and Modified CAP Entities . . . . 117
12.2 Registration of New Entities . . . . . . . . . . . . . 117
12.2.1 Define the Item . . . . . . . . . . . . . . . . . . . 117
12.2.2 Post the item definition . . . . . . . . . . . . . . . 118
12.2.3 Allow a comment period . . . . . . . . . . . . . . . . 118
12.2.4 Submit the proposal for approval . . . . . . . . . . . 118
12.3 Property Change Control . . . . . . . . . . . . . . . 119
13. IANA Considerations . . . . . . . . . . . . . . . . . 120
Authors' Addresses . . . . . . . . . . . . . . . . . . 120
A. Acknowledegements . . . . . . . . . . . . . . . . . . 122
B. Bibliography . . . . . . . . . . . . . . . . . . . . . 123
Full Copyright Statement . . . . . . . . . . . . . . . 124
1 Introduction 1. Introduction
This document specifies how a Calendar User Agent (CUA) This document specifies how a Calendar User Agent (CUA) interacts
interacts with a Calendar Store (CS) to manage calendar with a Calendar Store (CS) to manage calendar information. In
information. In particular, it specifies how to query, create, particular, it specifies how to query, create, modify, and delete
modify, and delete iCalendar components (e.g., events, to-dos, iCalendar components (e.g., events, to-dos, or daily journal
or daily journal entries). It further specifies how to search entries). It further specifies how to search for available busy time
for available busy time information. information.
This protocol is based on request/response form of data units, This protocol is based on request/response form of data units, sent
sent from a client CUA to a calendar server. The protocol data from a client CUA to a calendar server. The protocol data units
units leverage the standard iCalendar format [iCAL] for leverage the standard iCalendar format [iCAL] for conveying CS
conveying CS related information. related information.
1.1 Formatting Conventions 1.1 Formatting Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described document are to be interpreted as described in [RFC2119].
in [RFC2119].
Calendaring and scheduling roles are referred to in quoted- Calendaring and scheduling roles are referred to in quoted- strings
strings of text with the first character of each word in upper of text with the first character of each word in upper case. For
case. For example, "Organizer" refers to a role of a "Calendar example, "Organizer" refers to a role of a "Calendar User" (CU)
User" (CU) within the protocol defined by this memo. Calendar within the protocol defined by this memo. Calendar components
components defined by [iCAL] are referred to with capitalized, defined by [iCAL] are referred to with capitalized, quoted-strings of
quoted-strings of text. All calendar components start with the text. All calendar components start with the letter "V". For
letter "V". For example, "VEVENT" refers to the event calendar example, "VEVENT" refers to the event calendar component, "VTODO"
component, "VTODO" refers to the to-do calendar component and refers to the to-do calendar component and "VJOURNAL" refers to the
"VJOURNAL" refers to the daily journal calendar component. daily journal calendar component. Calendar access methods defined by
Calendar access methods defined by this memo, as well as this memo, as well as scheduling methods defined by [iTIP], are
scheduling methods defined by [iTIP], are referred to with referred to with capitalized, quoted-strings of text. For example,
capitalized, quoted-strings of text. For example, "CREATE" "CREATE" refers to the method for creating a calendar component on a
refers to the method for creating a calendar component on a
calendar, "READ" refers to the method for reading calendar calendar, "READ" refers to the method for reading calendar
components. components.
Properties defined by this memo are referred to with Properties defined by this memo are referred to with capitalized,
capitalized, quoted-strings of text, followed by the word quoted-strings of text, followed by the word "property". For
"property". For example, "ATTENDEE" property refers to the example, "ATTENDEE" property refers to the iCalendar property used to
iCalendar property used to convey the calendar address of a convey the calendar address of a "Calendar User". Property
"Calendar User". Property parameters defined by this memo are parameters defined by this memo are referred to with lower case,
referred to with lower case, quoted-strings of text, followed quoted-strings of text, followed by the word "parameter". For
by the word "parameter". For example, "value" parameter refers example, "value" parameter refers to the iCalendar property parameter
to the iCalendar property parameter used to override the used to override the default data type for a property value.
default data type for a property value. Enumerated values Enumerated values defined by this memo are referred to with
defined by this memo are referred to with capitalized text, capitalized text, either alone or followed by the word "value".
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 tables, the quoted-string text is specified without quotes in
in order to minimize the table length. order to minimize the table length.
1.2 Related Documents 1.2 Related Documents
Implementers will need to be familiar with several other memos Implementers will need to be familiar with several other memos that,
that, along with this one, describe the Internet calendaring along with this one, describe the Internet calendaring and scheduling
and scheduling standards. These documents are: standards. These documents are:
[iCAL] (RFC2445) which specifies the objects, data types, [iCAL] (RFC2445) which specifies the objects, data types, properties
properties and property parameters used in the protocols, and property parameters used in the protocols, along with the methods
along with the methods for representing and encoding them, for representing and encoding them,
[iTIP] (RFC2446) which specifies an interoperability protocol [iTIP] (RFC2446) which specifies an interoperability protocol for
for scheduling between different implementations. The related scheduling between different implementations. The related documents
documents are: are:
[iMIP] (RFC2447) which specifies an Internet email binding for [iMIP] (RFC2447) which specifies an Internet email binding for
[iTIP]. [iTIP].
[IMPL] (draft/rfc...) which is a guide to implementers and [IMPL] (draft/rfc...) which is a guide to implementers and describes
describes the elements of a calendaring system, how they the elements of a calendaring system, how they interact with each
interact with each other, how they interact with end users, other, how they interact with end users, and how the standards and
and how the standards and protocols are used. protocols are used.
This memo does not attempt to repeat the specification of This memo does not attempt to repeat the specification of concepts or
concepts or definitions from these other memos. Where definitions from these other memos. Where possible, references are
possible, references are made to the memo that provides for made to the memo that provides for the specification of these
the specification of these concepts or definitions. concepts or definitions.
1.3 Definitions 1.3 Definitions
Authentication ID (AuthID) Authentication ID (AuthID)
A tuple of username, realm, and authentication A tuple of username, realm, and authentication method, used by the
method, used by the Calendar Service internally to Calendar Service internally to identify a successfully
identify a successfully authenticated CAP session. authenticated CAP session.
Booked Booked
A entry in a calendar has one of two conceptual A entry in a calendar has one of two conceptual states. It is
states. It is scheduled or it is booked. A scheduled scheduled or it is booked. A scheduled entry has been stored in
entry has been stored in the calendar store but has the calendar store but has not been acted on by a calendar user or
not been acted on by a calendar user or calendar user calendar user agent. A booked appointment is an entry that has
agent. A booked appointment is an entry that has had had its state changed from one of the [iTIP] scheduling methods to
its state changed from one of the [iTIP] scheduling a CAP method of CREATE by a calendar user or calendar user agent
methods to a CAP method of CREATE by a calendar user which resulted in decision to keep the entry in the calendar
store.
<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 Calendar
A collection of logically related objects or entities each of
A collection of logically related objects or entities which may be associated with a calendar date and possibly time of
each of which may be associated with a calendar date day. These entities can include other calendar properties or
and possibly time of day. These entities can include calendar components.In addition, a calendar might be
other calendar properties or calendar components.In hierarchically related to other sub-calendars. A calendar is
addition, a calendar might be hierarchically related identified by its unique calendar identifier. The [iCAL] defines
to other sub-calendars. A calendar is identified by calendar properties, calendar components and component properties
its unique calendar identifier. The [iCAL] defines that make up the content of a calendar.
calendar properties, calendar components and
component properties that make up the content of a
calendar.
Calendar Access Protocol (CAP) Calendar Access Protocol (CAP)
The standard Internet protocol that permits a The standard Internet protocol that permits a Calendar User Agent
Calendar User Agent to access and manipulate a to access and manipulate a calendar residing on a Calendar Store.
calendar residing on a Calendar Store.
Calendar Access Rights (CAR) Calendar Access Rights (CAR)
The mechanism for specifying the CAP operations The mechanism for specifying the CAP operations ("ACTIONS") that a
("ACTIONS") that a particular calendar user ("UPN") particular calendar user ("UPN") are granted or denied permission
are granted or denied permission to perform on a to perform on a given calendar item ("OBJECT"). The calendar
given calendar item ("OBJECT"). The calendar access access rights are specified with the "VCAR" calendar components
rights are specified with the "VCAR" calendar within a CS and calendar.
components within a CS and calendar.
Calendar Collection Calendar Collection
A collection of Calendars, Resource Calendars, and/or A collection of Calendars, Resource Calendars, and/or other
other Calendar Collections. These collections are Calendar Collections. These collections are expanded by the CS
expanded by the CS and may reside either locally or and may reside either locally or in an external database or
in an external database or directory. The calendars directory. The calendars in the collection may be fixed or
in the collection may be fixed or dynamic over time. dynamic over time.
Calendar Component Calendar Component
An item within a calendar. Some types of calendar An item within a calendar. Some types of calendar components
components include events, to-dos, journals, alarms, include events, to-dos, journals, alarms, time zones and freebusy
time zones and freebusy data. A calendar component data. A calendar component consists of component properties and
consists of component properties and possibly other possibly other sub-components. For example, an event may contain
an alarm component.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
sub-components. For example, an event may contain an
alarm component.
Calendar Component Properties Calendar Component Properties
An attribute of a particular calendar component. Some An attribute of a particular calendar component. Some calendar
calendar component properties are applicable to component properties are applicable to different types of calendar
different types of calendar components. For example, components. For example, DTSTART is applicable to VEVENT, VTODO,
DTSTART is applicable to VEVENT, VTODO, VJOURNAL VJOURNAL calendar components. Other calendar components are
calendar components. Other calendar components are applicable only to an individual type of calendar component. For
applicable only to an individual type of calendar example, TZURL is only applicable to VTIMEZONE calendar
component. For example, TZURL is only applicable to components.
VTIMEZONE calendar components.
Calendar Identifier (CalID) Calendar Identifier (CalID)
A globally unique identifier associated with a A globally unique identifier associated with a calendar.
calendar. Calendars reside within a CS. See Qualified Calendars reside within a CS. See Qualified Calendar Identifier
Calendar Identifier and Relative Calendar Identifier. and Relative Calendar Identifier.
Calendar Policy Calendar Policy
A CAP operational restriction on the access or A CAP operational restriction on the access or manipulation of a
manipulation of a calendar. For example, "events MUST calendar. For example, "events MUST be scheduled in unit
be scheduled in unit intervals of one hour". intervals of one hour".
Calendar Properties Calendar Properties
An attribute of a calendar. The attribute applies to An attribute of a calendar. The attribute applies to the
the calendar, as a whole. For example, CALSCALE calendar, as a whole. For example, CALSCALE specifies the
specifies the calendar scale (e.g., GREGORIAN) for calendar scale (e.g., GREGORIAN) for the whole calendar.
the whole calendar.
Calendar Service Calendar Service
An implementation of a Calendar Store that manages An implementation of a Calendar Store that manages one or more
one or more calendars. calendars.
Calendar Store (CS) Calendar Store (CS)
The data and service model definition for a Calendar The data and service model definition for a Calendar Service.
Service.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
Calendar Store Identifier (CSID) Calendar Store Identifier (CSID)
The globally unique identifier for an individual CS. The globally unique identifier for an individual CS. A CSID
A CSID consists of the host and port portions of a consists of the host and port portions of a "Common Internet
"Common Internet Scheme Syntax" part of a URL, as Scheme Syntax" part of a URL, as defined by [URL].
defined by [URL].
Calendar Store Components Calendar Store Components
Components maintained in a CS specify a grouping of Components maintained in a CS specify a grouping of calendar
calendar store-wide information. Calendar store store-wide information. Calendar store components can be accessed
components can be accessed using CAP. using CAP.
Calendar Store Properties Calendar Store Properties
Properties maintained in a Calendar Store calendar Properties maintained in a Calendar Store calendar store-wide
store-wide information. Calendar store properties can information. Calendar store properties can be accessed using CAP.
be accessed using CAP.
Calendar User (CU) Calendar User (CU)
An entity (often biological) that uses a calendaring An entity (often biological) that uses a calendaring system.
system.
Calendar User Agent (CUA) Calendar User Agent (CUA)
The CUA is the client application that a CU or UG The CUA is the client application that a CU or UG utilizes to
utilizes to access and manipulate a calendar. access and manipulate a calendar.
Calendaring and Scheduling System Calendaring and Scheduling System
The computer sub-system that provides the services The computer sub-system that provides the services for accessing,
for accessing, manipulating calendars and scheduling manipulating calendars and scheduling calendar components.
calendar components.
CAP Session CAP Session
An open communication channel between a CAP CUA and a An open communication channel between a CAP CUA and a CAP CS.
CAP CS.
Connected Mode 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.
A mobile computing mode where the CUA is directly
connected to the CS.
Delegate Delegate
Is a calendar user (sometimes called the delegatee) Is a calendar user (sometimes called the delegatee) who has been
who has been assigned participation in a scheduled assigned participation in a scheduled calendar component (e.g.,
calendar component (e.g., VEVENT) by one of the VEVENT) by one of the attendees in the scheduled calendar
attendees in the scheduled calendar component component (sometimes called the delegator). An example of a
(sometimes called the delegator). An example of a delegate is a team member told to go to a particular meeting.
delegate is a team member told to go to a particular
meeting.
Designate Designate
Is a calendar user who is authorized to act on behalf Is a calendar user who is authorized to act on behalf of another
of another calendar user. An example of a designate calendar user. An example of a designate is an assistant.
is an assistant.
Disconnected Mode Disconnected Mode
A mobile computing mode where a CUA can be A mobile computing mode where a CUA can be disconnected from a CS.
disconnected from a CS. When the CUA is disconnected, When the CUA is disconnected, it is in the disconnected mode.
it is in the disconnected mode.
Fan Out Fan Out
The calendaring and scheduling process by which a The calendaring and scheduling process by which a calendar
calendar operation on one calendar is also performed operation on one calendar is also performed on every other
on every other calendar specified in the operation. calendar specified in the operation. This may include the
This may include the calendar associated with TARGET calendar associated with TARGET calendar property.
calendar property.
Hierarchical Calendars Hierarchical Calendars
A CS feature where a calendar have a hierarchical A CS feature where a calendar have a hierarchical relationship
relationship with another calendar in the CS. The with another calendar in the CS. The top-most calendar in the
top-most calendar in the hierarchical relationship hierarchical relationship has the CS as its parent. There may be
has the CS as its parent. There may be multiple top- multiple top- most calendars in a given CS. Within a given
most calendars in a given CS. Within a given hierarchical relationship, all sub-calendars have a calendar with
hierarchical relationship, all sub-calendars have a a "parent" topographical relationship. In addition, sub-calendars
calendar with a "parent" topographical relationship. may have a relationship with another calendar that has a "child"
In addition, sub-calendars may have a relationship topographical relationship. In addition, a calendar may have a
relationship such that one or more calendars have a "sibling"
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 topographical relationship with the calendar. The hierarchical
calendar feature is not a storage relationship of the calendars
with another calendar that has a "child" within the CS. Instead it is a feature that relates access
topographical relationship. In addition, a calendar control rights to calendar content between different calendars in
may have a relationship such that one or more the CS. The hierarchical relationship of a calendar is specified
calendars have a "sibling" topographical relationship in the "PARENT" and "CHILDREN" calendar properties.
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 High Bandwidth Connection
A communications connection supporting high transfer A communications connection supporting high transfer rates;
rates; transfer rates commonly found within a LAN. transfer rates commonly found within a LAN.
Local Store Local Store
A CS which is on the same platform as the CUA. A CS which is on the same platform as the CUA.
Low Bandwidth Connection Low Bandwidth Connection
A communications connection supporting slow transfer A communications connection supporting slow transfer rates;
rates; transfer rates commonly found in remote access transfer rates commonly found in remote access technology.
technology.
Overlapped Booking Overlapped Booking
A policy which indicates whether or not OPAQUE events A policy which indicates whether or not OPAQUE events can overlap
can overlap one another. When the policy is applied one another. When the policy is applied to a calendar it
to a calendar it indicates whether or not any OPAQUE indicates whether or not the time span of any entry (VEVENT,
events in the calendar can overlap. When applied to VTODO, ...) in the calendar can overlap the time span of any other
an individual event, it indicates whether or not it entry in the same calendar. When applied to an individual entry,
can be overlapped by any other OPAQUE event. it indicates whether or not any other entry's time span can
overlap that individual entry.
Owner Owner
One or more CUs or UGs that have "OWNER" calendar One or more CUs or UGs that have "OWNER" calendar access rights
access rights for a calendar. The owner is specified for a calendar. The owner is specified in the "OWNER" calendar
in the "OWNER" calendar property. property and in the "OWNER" calendar store property.
Qualified Calendar Identifier (Qualified CalID) 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.
A CalID where both the <scheme> and <csid> are
present.
Realm Realm
A collection of calendar user accounts, identified by A collection of calendar user accounts, identified by a string.
a string. The name of the realm is only used in The name of the realm is only used in UPNs. In order to avoid
UPNs. In order to avoid namespace conflict, the realm namespace conflict, the realm SHOULD be postfixed with an
SHOULD be postfixed with an appropriate DNS domain appropriate DNS domain name. (eg: the foobar realm could be
name. (eg: the foobar realm could be called called foobar.example.com).
foobar.example.com).
Relative Calendar Identifier (Relative CalID) Relative Calendar Identifier (Relative CalID)
An identifier for an individual calendar in a An identifier for an individual calendar in a calendar store. It
calendar store. It is unique within a calendar store. is unique within a calendar store. It is recommended to be
It is recommended to be globally unique. A Relative globally unique. A Relative CalID consists of the portion of the
CalID consists of the portion of the "scheme part" of "scheme part" of a Qualified CalID following the Calendar Store
a Qualified CalID following the Calendar Store Identifier. This is the same as the "URL path" of the "Common
Identifier. This is the same as the "URL path" of the Internet Scheme Syntax" portion of a URL, as defined by [URL].
"Common Internet Scheme Syntax" portion of a URL, as
defined by [URL].
Remote Store Remote Store
A CS which is not on the same platform as the CUA. A CS which is not on the same platform as the CUA.
Resource Calendar (RC) Resource Calendar (RC)
A non-human Calendar, associated with an A non-human Calendar, associated with an organizational resource.
organizational resource. There is no syntactic There is no syntactic difference between an RC and a Calendar.
difference between an RC and a Calendar.
Session Identity Session Identity
A UPN associated with a CAP session. A session gains A UPN associated with a CAP session. A session gains an identity
an identity after successful authentication. The after successful authentication. The identity is used in
identity is used in combination with CAR to determine combination with CAR to determine access to data in the CS.
access to data in the CS.
Sub-calendars Sub-calendars
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 Calendars that have a "child" hierarchical relationship with
another calendar, its "parent".
Calendars that have a "child" hierarchical
relationship with another calendar, its "parent".
User Group (UG) User Group (UG)
A collection of Calendar Users and/or User Groups. A collection of Calendar Users and/or User Groups. These groups
These groups are expanded by the CS and may reside are expanded by the CS and may reside either locally or in an
either locally or in an external database or external database or directory. The group membership may be fixed
directory. The group membership may be fixed or or dynamic over time.
dynamic over time.
User Name User Name
A name which denotes a Calendar User within a realm. A name which denotes a Calendar User within a realm. This is part
This is part of a UPN. of a UPN.
User Principal Name (UPN) User Principal Name (UPN)
An identifier that denotes a unique CU. A UPN is an An identifier that denotes a unique CU. A UPN is an RFC 822
RFC 822 compliant email address, with exceptions compliant email address, with exceptions listed below, and in most
listed below, and in most cases it is deliverable to cases it is deliverable to the CU. In some cases it is identical
the CU. In some cases it is identical to the CU's to the CU's well known email address. A CU's UPN to email address
well known email address. A CU's UPN MUST never be mapping MUST never be deliverable to a different person as there
deliverable to a different person. It consists of a is not requirement that they are the same. It consists of a
realm in the form of a valid, and unique, DNS domain realm in the form of a valid, and unique, DNS domain name and a
name and a unique username. In it's simplest form it unique username. In it's simplest form it looks like
looks like "user@example.com". "user@example.com".
In certain cases a UPN will not be RFC 822 compliant. In certain cases a UPN will not be RFC 822 compliant. When
When anonymous authentication is used, or anonymous anonymous authentication is used, or anonymous authorization is
authorization is being defined, the special UPN "@" being defined, the special UPN "@" will be used. When
will be used. When authentication must be used, but authentication must be used, but unique identity must be obscured,
unique identity must be obscured, a UPN of the form a UPN of the form @DNS-domain-name may be used. For example,
@DNS-domain-name may be used. For example, "@example.com". Usage of these special cases is further discussed
"@example.com". Usage of these special cases is in the authentication and authorization sections of this document.
further discussed in the authentication and
authorization sections of this document.
2 CAP Design 2. CAP Design
2.1 System Model 2.1 System Model
The system model describes the high level components of a The system model describes the high level components of a calendar
calendar system and how they interact with each other. 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 a
[MIME] encapsulated iCalendar object containing a command, sends it
to the CS, and receives 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
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.
CAP is used by a "Calendar User Agent" (CUA) to send commands In the diagram below, a user uses CUA1 to communicate with CS1 using
to and receive responses from a "Calendar Service" (CS). The CAP. The CUA must authenticate the Calendar User (CU) so that access
CUA prepares a [MIME] encapsulated iCalendar object containing to calendars on CS1 can be controlled. The CUA can then view,
a command, sends it to the CS, and receives a [MIME] create, edit, and delete calendars, calendar properties, and calendar
encapsulated iCalendar object as a response. There are two components subject to the access rights.
distinct protocols in operation to accomplish this exchange.
The Transfer Protocol is used to move 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 CAP servers support fanout. Fanout allows a CUA to communicate with
using CAP. The CUA must authenticate the Calendar User (CU) so a single CS to perform scheduling operations with calendars on
that access to calendars on CS1 can be controlled. The CUA can multiple CSs. That is, a CU can book or schedule events (or to-dos)
then view, create, edit, and delete calendars, calendar on or read events (or to-dos) from calendars on other calendar
properties, and calendar components subject to the access stores. To accomplish this, a CAP server takes on these roles:
rights.
CAP servers support fanout. Fanout allows a CUA to communicate * CS1 MAY play the role of a CUA and use CAP to access CS2;
with a single CS to perform scheduling operations with
calendars on multiple CSs. That is, a 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 takes on these roles:
* CS1 MAY play the role of a CUA and use CAP to access * CS1 MUST be able play the role of a CUA and use [iMIP] to
CS2; interoperate with other CUAs.
* CS1 MUST be able play the role of a CUA and use [iMIP]
to interoperate with other CUAs.
+-----+ +-----+ +-----+ +-----+
| | CAP | | CAP | | CAP | | CAP
CUA1------| CS1 |----------| CS2 |--------- CUA2 CUA1------| CS1 |----------| CS2 |--------- CUA2
| | | | A | | | | A
| | | | | | | | | |
| | | | | | | | | |
+-----+ +-----+ | +-----+ +-----+ |
| IMIP | | IMIP |
+--------------------------------+ +--------------------------------+
Note that the fanout feature in CAP is a convenience to the Note that the fanout feature in CAP is a convenience to the CUA. It
CUA. It is perfectly valid for the CUA to assume the is perfectly valid for the CUA to assume the responsibility for
responsibility for fanout if it wishes. That is, [iMIP] fanout if it wishes. That is, [iMIP] messages could also be sent
messages could also be sent from CUA1 to CUA2. from CUA1 to CUA2.
2.2 Calendar Store Object Model CAP does not specify any trust model between CS1 and CS2.
Implementations may require a trust model to exist in order to
accomplish scheduling between CS1 and CS2.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 2.1.1 Firewalls and Fanout
- - - ------INTERNET---------------------- - - -
| |
+----------------+ +----------------------+
| Site Public CS |<---->| Other Site Public CS |
| (CS-P) | | (CS-P2) |
+----------------+ +----------------------+
^ ^
| .
v .
+----------------+ .
| Site Firewall | - - - ---Other LAN---- -
+----------------+
|
- - ---------------LAN---------------------------- - - -
| | |
+--------------+ +--------------+ +- - - - - - - - +
| Department-1 | | Department-2 | | . . . |
| CS-1 | | CS-2 | | CS-n |
+--------------+ +--------------+ +- - - - - - - - +
One example of a site site policy could be that all entries in
department calendars that were marked PUBLIC, were visible on the
internet to any users that was granted access to CS-P.
With fanout in place, CS-P would authenticate the internet user and
decide in an implementation specific way, which user CS (CS-1, CS-
2, CS-n) the TARGET calendar physically existed. Then using
fanout, CS- P sends the request subject to VCARs or immutable
VCARS from CS-P to the users CS and back to the CUA through CS-P.
CS-P could be a smart proxy.
And there is no reason that the target calendar need to exist under
the firewall (CS-P2), only that the CSs can authenticate with each
other. In this way all users in a domain could appear to be at
calendar.site.com, hiding all CS-1 through CS-n from the internet.
And also hiding that fact that CS-P2 may be a separate domain
controlled by the same site administrators as CS-P (which in turn
could do fanout to its LAN).
2.2 Calendar Store Object Model
The conceptual model for a calendar store is shown below. The The conceptual model for a calendar store is shown below. The
calendar store contains calendars, VTIMEZONEs, VCARs, and calendar store contains calendars, VTIMEZONEs, VCARs, and calendar
calendar store properties. store properties.
Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs, VCARs, Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs, VCARs, and
and calendar properties. Calendars may also contain other calendar properties. Calendars may also contain other calendars.
calendars.
Calendar Store Calendar Store
| |
+-- VCARs +-- VCARs
+-- Properties +-- Properties
+-- VCARs
+-- VTIMEZONEs +-- VTIMEZONEs
+-- VCALENDARs +-- VCALENDARs
| |
+--VEVENTs +--VEVENTs
+--VALARMs +--VALARMs
+--VTODOs +--VTODOs
+--VALARMs +--VALARMs
+--VJOURNALs +--VJOURNALs
+--VCARs +--VCARs
+--Properties +--Properties
+--VTIMEZONEs +--VTIMEZONEs
+--VSCHEDULE +--VSCHEDULE
+--VQUERY
+--Calendar +--Calendar
| |
+--VEVENTs +--VEVENTs
+--VALARMs +--VALARMs
+--VTODOs +--VTODOs
+--VALARMs +--VALARMs
+--VJOURNALs +--VJOURNALs
+--VALARMs
+--VCARs +--VCARs
+--Properties +--Properties
+--VTIMEZONEs +--VTIMEZONEs
+--VSCHEDULE +--VSCHEDULE
+--VQUERY
+--Calendar +--Calendar
| |
... ...
Calendars within a Calendar Store are identified by their Calendars within a Calendar Store are identified by their Relative
Relative CALID. CALID.
In this 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.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 In this 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 Protocol Model 2.3 Protocol Model
A generic transfer-layer, Calendar Server Transfer Protocol A generic transfer-layer, Calendar Server Transfer Protocol (CSTP),
(CSTP), is used to move data objects between a CUA and the CS. is used to move data objects between a CUA and the CS. CSTP commands
CSTP commands are listed below and their usage and semantics are listed below and their usage and semantics are defined in section
are defined in section 7.1 of this document. 7.1 of this document.
CSTP Commands CSTP Commands
----------------------------------------------------------- -----------------------------------------------------------
Command Description Command Description
----------------------------------------------------------- -----------------------------------------------------------
ABORT Stop a command. Perhaps because its latency ABORT Stop a command. Perhaps because its latency
time has been exceeded. time has been exceeded.
AUTHENTICATE Authenticate a UPN. AUTHENTICATE Authenticate a UPN.
CONTINUE Continue the execution of a command whose CONTINUE Continue the execution of a command whose
Latency time has been exceeded. Latency time has been exceeded.
IDENTIFY Set a new identity for calendar access. IDENTIFY Set a new identity for calendar access.
DISCONNECT Terminate a connection with the server. DISCONNECT Terminate a connection with the server.
SENDDATA Send a data object [MIME] encapsulated SENDDATA Send a data object [MIME] encapsulated
iCalendar. iCalendar.
STARTTLS Negotiate transport level security using STARTTLS Negotiate transport level security using
[TLS]. [TLS].
NOOP Do nothing operation.
----------------------------------------------------------- -----------------------------------------------------------
Application-level commands are used to manipulate data on the Application-level commands are used to manipulate data on the
calendar store. They are listed below and discussed in detail calendar store. They are listed below and discussed in detail in
in section 7.2. section 7.2.
CAP Calendaring Commands CAP Calendaring Commands
----------------------------------------------------------- ----------------------------------------------------------
Command Description Command Description
----------------------------------------------------------- ----------------------------------------------------------
CREATE Create a new calendar or component. CREATE Create a new calendar or component.
DELETE Delete a calendar or component. DELETE Delete a calendar or component.
GENERATEUID Generate one or more unique ids. GENERATEUID Generate one or more unique ids.
MODIFY Change a calendar or component. MODIFY Change a calendar or component.
MOVE Move a calendar. MOVE Move a calendar.
READ Read a calendar properties or components. READ Read a calendar properties or components.
----------------------------------------------------------- ----------------------------------------------------------
CAP Scheduling Commands CAP Scheduling Commands
(As defined in [iTIP]) (As defined in [iTIP])
----------------------------------------------------------- -----------------------------------------------------------
Command Description Command Description
----------------------------------------------------------- -----------------------------------------------------------
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
PUBLISH Publish a calendar entry to one or more PUBLISH Publish a calendar entry to one or more
calendars. calendars.
REQUEST Schedule a calendar entry with one or more REQUEST Schedule a calendar entry with one or more
calendars. calendars.
REPLY Response to a scheduling request. REPLY Response to a scheduling request.
ADD Add one or more instances to an existing ADD Add one or more instances to an existing
calendar entry. calendar entry.
CANCEL Cancel one or more instances to an existing CANCEL Cancel one or more instances to an existing
calendar entry. calendar entry.
REFRESH A request for the latest version of a REFRESH A request for the latest version of a
calendar entry. calendar entry.
COUNTER A request for a change(a counter-proposal)to COUNTER A request for a change (a counter-proposal)
a calendar entry. to a calendar entry.
DECLINECOUNTER Decline a counter proposal. DECLINECOUNTER Decline a counter proposal.
----------------------------------------------------------- -----------------------------------------------------------
2.4 Security Model 2.4 Security Model
Authentication to the CS will be performed using [SASL]. Authentication to the CS will be performed using [SASL].
As noted in the CAP system model section, a variety of As noted in the CAP system model section, a variety of connectivity
connectivity scenarios are possible. This complicates the scenarios are possible. This complicates the security model
security model considerably, and a thorough familiarity with considerably, and a thorough familiarity with the concepts is
the concepts is required to ensure interoperability. required to ensure interoperability.
Basic threats to a Calendaring and Scheduling System include: Basic threats to a Calendaring and Scheduling System include:
(1) Unauthorized access to data via data-fetching operations, (1) Unauthorized access to data via data-fetching operations,
(2) Unauthorized access to reusable client authentication (2) Unauthorized access to reusable client authentication
information by monitoring others' access, information by monitoring others' access,
(3) Unauthorized access to data by monitoring others' access, (3) Unauthorized access to data by monitoring others' access,
(4) Unauthorized modification of data, (4) Unauthorized modification of data,
(5) Unauthorized or excessive use of resources (denial of (5) Unauthorized or excessive use of resources (denial of
service), and service), and
(6) Spoofing of CS: Tricking a client into believing that (6) Spoofing of CS: Tricking a client into believing that
information came from the CS when in fact it did information came from the CS when in fact it did not, either
not, either by modifying data in transit or by modifying data in transit or misdirecting the client's
misdirecting the client's connection. 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 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.
CAP can be protected with the following security mechanisms: CAP can be protected with the following security mechanisms:
(1) Client authentication by means of the SASL mechanism (1) Client authentication by means of the SASL mechanism set,
set, possibly backed by the TLS credentials exchange possibly backed by the TLS credentials exchange mechanism,
mechanism,
(2) Client authorization by means of access control based (2) Client authorization by means of access control based on the
on the requestor's authenticated identity, requestor's authenticated identity,
(3) Data integrity protection by means of the TLS protocol (3) Data integrity protection by means of the TLS protocol or data
or data integrity SASL mechanisms, integrity SASL mechanisms,
(4) Protection against snooping by means of the TLS (4) Protection against snooping by means of the TLS protocol or
protocol or data encrypting SASL mechanisms, data encrypting SASL mechanisms,
(5) Resource limitation by means of administrative limits (5) Resource limitation by means of administrative limits on
on service controls, and service controls, and
(6) Server authentication by means of the TLS protocol or (6) Server authentication by means of the TLS protocol or SASL
SASL mechanism. mechanism.
Imposition of access controls (authorizations) is done by Imposition of access controls (authorizations) is done by means of
means of VCARs, an overview is provided in section <fwd ref>, VCARs, an overview is provided in the section 2.4.4 <fwd ref> and a
and a detailed syntax is provided in section <fwd ref>. detailed syntax is provided in section 6 <fwd ref> Authentication is
Authentication is explained in detail in section <fwd ref>. explained in detail in section 2.4.1 <fwd ref>
2.4.1 Authentication, Credentials, and Identity 2.4.1 Authentication, Credentials, and Identity
Generically, authentication credentials are the evidence Generically, authentication credentials are the evidence supplied by
supplied by one party to another, asserting the identity of one party to another, asserting the identity of the supplying party
the supplying party (e.g. a user) who is attempting to (e.g. a user) who is attempting to establish an association with the
establish an association with the other party (typically a other party (typically a server). Authentication is the process of
server). Authentication is the process of generating, generating, transmitting, and verifying these credentials and thus
transmitting, and verifying these credentials and thus the the identity they assert. An authentication identity is the name
identity they assert. An authentication identity is the name
presented in a credential. presented in a credential.
There are many forms of authentication credentials. The form There are many forms of authentication credentials. The form used
used depends upon the particular authentication mechanism depends upon the particular authentication mechanism negotiated by
negotiated by the parties. For example: X.509 certificates, the parties. For example: X.509 certificates, Kerberos tickets,
Kerberos tickets, simple identity and password pairs. Note simple identity and password pairs. Note that an authentication
that an authentication mechanism may constrain the form of mechanism may constrain the form of authentication identities used
authentication identities used with it. 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.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 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 Calendar User and UPNs 2.4.2 Calendar User and UPNs
A Calendar User(CU) is an entity that can be authenticated. It A Calendar User(CU) is an entity that can be authenticated. It is
is represented in CAP as a UPN. A UPN is the owner of a represented in CAP as a UPN. A UPN is the owner of a calendar and
calendar and the subject of access rights. The UPN the subject of access rights. The UPN representation is independent
representation is independent of the authentication mechanism of the authentication mechanism used during a particular CUA/CS
used during a particular CUA/CS interaction. This is because interaction. This is because UPNs are used within VCARs. If the UPN
UPNs are used within VCARs. If the UPN were dependent on the were dependent on the authentication mechanism, a VCAR could not be
authentication mechanism, a VCAR could not be consistently consistently evaluated. A CU may use one mechanism while using one
evaluated. A CU may use one mechanism while using one CUA but CUA but the same CU may use a different authentication mechanism when
the same CU may use a different authentication mechanism when using a different CUA, or while connecting from a different location.
using a different CUA, or while connecting from a different
location.
The user may also have multiple UPNs for various purposes. The user may also have multiple UPNs for various purposes.
Note that the immutability of the user's UPN may be achieved Note that the immutability of the user's UPN may be achieved by using
by using SASL's authorization identity feature. (The SASL's authorization identity feature. (The transmitted
transmitted authorization identity may be different than the authorization identity may be different than the identity in the
identity in the client's authentication credentials.) [SASL, client's authentication credentials.) [SASL, section 3] This also
section 3] This also permits a CU to authenticate using their permits a CU to authenticate using their own credentials, yet request
own credentials, yet request the access privileges of the the access privileges of the identity for which they are proxying
identity for which they are proxying SASL. Also, the form of SASL. Also, the form of authentication identity supplied by a
authentication identity supplied by a service like TLS may not service like TLS may not correspond to the UPNs used to express a
correspond to the UPNs used to express a server's access server's access control policy, requiring a server-specific mapping
control policy, requiring a server-specific mapping to be to be done. The method by which a server composes and validates an
done. The method by which a server composes and validates an authorization identity from the authentication credentials supplied
authorization identity from the authentication credentials by a client is implementation-specific.
supplied by a client is implementation-specific.
For Calendaring and Scheduling Systems that are integrated For Calendaring and Scheduling Systems that are integrated with a
with a directory system, the CS MUST support the ability to directory system, the CS MUST support the ability to configure which
configure which schema attribute stores the UPN. The CS MAY schema attribute stores the UPN. The CS MAY allow one or more
allow one or more attributes to be searched for the UPN. attributes to be searched for the UPN.
2.4.2.1 UPNs and Certificates 2.4.2.1 UPNs and Certificates
When using X.509 certificates for purposes of CAP When using X.509 certificates for purposes of CAP authentication, the
authentication, the UPN should appear in the certificate. UPN should appear in the certificate. Unfortunately there is no
Unfortunately there is no single correct guideline for which single correct guideline for which field should contain the UPN.
field should contain the UPN.
From RFC-2459, section 4.1.2.6 (Subject): From RFC-2459, section 4.1.2.6 (Subject):
If subject naming information is present only in the If subject naming information is present only in the subjectAlt-
subjectAlt-Name extension (e.g., a key bound only to Name extension (e.g., a key bound only to an email address or
an email address or URI), then the subject name MUST URI), then the subject name MUST be an empty sequence and the
subjectAltName extension MUST be critical.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
be an empty sequence and the subjectAltName extension Implementations of this specification MAY use these comparison
MUST be critical. rules to process unfamiliar attribute types (i.e., for name
chaining). This allows implementations to process certificates
with unfamiliar attributes in the subject name.
Implementations of this specification MAY use these In addition, legacy implementations exist where an RFC 822 name is
comparison rules to process unfamiliar attribute embedded in the subject distinguished name as an EmailAddress
types (i.e., for name chaining). This allows attribute. The attribute value for EmailAddress is of type
implementations to process certificates with IA5String to permit inclusion of the character '@', which is not
unfamiliar attributes in the subject name. 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").
In addition, legacy implementations exist where an Conforming implementations generating new certificates with
RFC 822 name is embedded in the subject distinguished electronic mail addresses MUST use the rfc822Name in the subject
name as an EmailAddress attribute. The attribute alternative name field (see sec. 4.2.1.7 [of RFC 2459]) to
value for EmailAddress is of type IA5String to permit describe such identities. Simultaneous inclusion of the
inclusion of the character '@', which is not part of EmailAddress attribute in the subject distinguished name to
the PrintableString character set. EmailAddress support legacy implementations is deprecated but permitted.
attribute values are not case sensitive (e.g.,
"fanfeedback@redsox.com" is the same as
"FANFEEDBACK@REDSOX.COM").
Conforming implementations generating new Since no single method of including the UPN in the certificate will
certificates with electronic mail addresses MUST use work in all cases, CAP implementations MUST support the ability to
the rfc822Name in the subject alternative name field configure what the mapping will be by the CS administrator.
(see sec. 4.2.1.7 [of RFC 2459]) to describe such Implementations MAY support multiple mapping definitions, for
identities. Simultaneous inclusion of the example, the UPN may be found in either the subject alternative name
EmailAddress attribute in the subject distinguished field, or the UPN may be embedded in the subject distinguished name
name to support legacy implementations is deprecated as an EmailAddress attribute.
but permitted.
Since no single method of including the UPN in the certificate Note: If a CS or CUA is validating data received via iMIP, if the
will work in all cases, CAP implementations MUST support the "ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe
ability to configure what the mapping will be by the CS Random User:juser@example.com" then the email address should be
administrator. Implementations MAY support multiple mapping checked against the UPN, and the CN should also be checked. This is
definitions, for example, the UPN may be found in either the so the "ATTENDEE" property couldn't be munged to something misleading
subject alternative name field, or the UPN may be embedded in like "ATTENDEE;CN=Joe Rictus User:juser@example.com" and have it pass
the subject distinguished name as an EmailAddress attribute. validation. This validation will also defeat other attempts at
confusion.
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 Anonymous Users and Authentication 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.
Anonymous access is often desirable. For example an CAP implementations MUST support anonymous authentication, as defined
organization may publish calendar information that does not in section <fwd ref 7.1.3>
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 CAP implementations MAY support anonymous authentication with TLS, as
defined in section <fwd ref 7.1.3>. defined in section <fwd ref 7.1.3.2>
CAP implementations MAY support anonymous authentication with
TLS, as defined in section <fwd ref 7.1.3.2>.
2.4.2.3 Required Security Mechanisms 2.4.2.3 Required Security Mechanisms
The following implementation conformance requirements are in The following implementation conformance requirements are in place:
place:
(1) For a read-only, public CS, anonymous authentication, (1) For a read-only, public CS, anonymous authentication,
described in section <fwd ref 7.1.3.1>, can be used. described in section <fwd ref 7.1.3.1> can be used.
(2) Implementations providing password-based authenticated (2) Implementations providing password-based authenticated access
access MUST support authentication using Digest, as described MUST support authentication using Digest, as described in section
in section <fwd ref>. This provides client authentication <fwd ref&gt [ed note: this section has not yet been defined.
with protection against passive eavesdropping attacks, but Paul can you please look into it?]; This provides client
does not provide protection against active intermediary authentication with protection against passive eavesdropping
attacks. 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.
(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 TLS Ciphersuites 2.4.2.4 TLS Ciphersuites
The following ciphersuites defined in [RFC 2246] MUST NOT be The following ciphersuites defined in [RFC 2246] MUST NOT be used for
used for confidentiality protection of passwords or data: confidentiality protection of passwords or data:
TLS_NULL_WITH_NULL_NULL TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
The following ciphersuites defined in [RFC 2246] can be TLS_RSA_WITH_NULL_MD5
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 TLS_RSA_WITH_NULL_SHA
value of the password or data being protected before using The following ciphersuites defined in [RFC 2246] can be cracked
these ciphersuites: easily (less than a week of CPU time on a standard CPU in 1997). The
client and server SHOULD carefully consider the value of the password
or data being protected before using these ciphersuites:
TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_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_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
The following ciphersuites are vulnerable to man-in-the-middle The following ciphersuites are vulnerable to man-in-the-middle
attacks, and SHOULD NOT be used to protect passwords or attacks, and SHOULD NOT be used to protect passwords or sensitive
sensitive data, unless the network configuration is such that data, unless the network configuration is such that the danger of a
the danger of a man-in-the-middle attack is tolerable: man-in-the-middle attack is tolerable:
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
A client or server that supports TLS MUST support at least: A client or server that supports TLS MUST support at least:
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
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 2.4.3 User Groups
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 A User Group is used to represent a collection of CUs or other UGs
should use the directory service to expand a UPN subject to that can be referenced in VCARS. A UG is represented in CAP as a
the directory service access control model for the UPN. The CUA cannot distinguish between a UPN that represents a CU
authenticated entity. or a UG.
The CS SHOULD not preserve UG expansions across operations. A UGs are expanded as necessary by the CS. The CS MUST accept a CUA
UG may reference a static list of members, or it may represent request for UG expansion, although the CS may be configured to
a dynamic list. Each operation SHOULD generate its own 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.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 Groups may be in a directory service 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.
expansion in order to recognize changes to UG membership. The CS should not preserve UG expansions across operations. A UG may
However, during fan out to other CSs, the originating CS reference a static list of members, or it may represent a dynamic
SHOULD expand all UGs so that the target CS receives only a list. Each operation SHOULD generate its own expansion in order to
list of unique CUs. This is to prevent confusion when two CSs recognize changes to UG membership. However, during fan out to other
do not share the same UG database or directory. 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. CAP does not define commands or methods for managing UGs.
Small UG: Small UG:
The Three Stooges. There is only and always three at any
one time. The Three Stooges. There is only and always three at any one
time.
Large UG: Large UG:
The MIT graduating class of 1999. This is a static list. The MIT graduating class of 1999. This is a static list.
Dynamic UG: Dynamic UG:
The IETF membership which is a large and changing list of
members. The IETF membership which is a large and changing list of members.
Nested UG: Nested UG:
The National Football League, made up of the AFC and NFC,
which are made up of 3 divisions each... The National Football League, made up of the AFC and NFC, which
are made up of 3 divisions each...
2.4.4 Access Rights - Summary 2.4.4 Access Rights - Summary
Access rights are used to grant or deny access to a calendar Access rights are used to grant or deny access to a calendar for a
for a CU. CAP defines a new component type called a Vcalendar CU. CAP defines a new component type called a Vcalendar Access Right
Access Right (VCAR). Specifically, a VCAR grants, or denies, (VCAR). Specifically, a VCAR grants, or denies, UPNs the right to
UPNs the right to read and write components, properties, and read and write components, properties, and parameters on calendars
parameters on calendars within a CS. within a CS.
The VCAR model does not put any restriction on the sequence in The VCAR model does not put any restriction on the sequence in which
which the object and access rights are created. That is, an the object and access rights are created. That is, an event
event associated with a particular VCAR might be created associated with a particular VCAR might be created before or after
before or after the actual VCAR is defined. In addition, the the actual VCAR is defined. In addition, the VCAR and VEVENT
VCAR and VEVENT definition might be created in the same definition might be created in the same iCalendar object and passed
iCalendar object and passed together in a single command. together in a single command.
All rights MUST be denied unless specifically granted; All rights MUST be denied unless specifically granted; individual
individual VCARs MUST be specifically granted to an VCARs MUST be specifically granted to an authenticated CU.
authenticated CU.
The access for a particular UPN is the union of all grants for The access for a particular UPN is the union of all grants for that
that UPN minus the union of its denies. UPN minus the union of its denies.
2.4.4.1 VCalendar Access Right (VCAR) 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"
Access rights within CAP are specified with the "VCAR" component properties.
calendar component, "RIGHTS" value type and the "GRANT",
"DENY" and "CARID" component properties.
Properties within an iCalendar object are unordered. This also Properties within an iCalendar object are unordered. This also is
is the case for the "GRANT", "DENY" and "CARID" properties. the case for the "GRANT", "DENY" and "CARID" properties. Likewise,
Likewise, there is no implied ordering required for components there is no implied ordering required for components of a "RIGHTS"
of a "RIGHTS" value type other than that specified by the value type other than that specified by the ABNF. [EDITOR'S NOTE,
ABNF. [EDITOR'S NOTE, this requires a lot of review. We think this requires a lot of review. We think that this paragraph may be
that this paragraph may be incorrect. ] incorrect. ]
For details on the VCAR syntax please see section <forward For details on the VCAR syntax please see section <forward ref>
ref>
2.4.4.2 Decreed VCARs 2.4.4.2 Decreed VCARs
A CS MAY choose to implement and allow persistent immutable A CS MAY choose to implement and allow persistent immutable VCARs,
VCARs, that are configured by the CS Administrator, which that are configured by the CS Administrator, which apply to all
apply to all calendars on the server. calendars on the server.
When a user attempts to modify a decreed VCAR an error will be When a user attempts to modify a decreed VCAR an error will be
returned, indicating that the user has insufficient returned, indicating that the user has insufficient authorization to
authorization to perform the operation. perform the operation.
The CAP protocol does not define the semantics used to The CAP protocol does not define the semantics used to initially
initially create a decreed VCAR. This administrative task is create a decreed VCAR. This administrative task is out side the
out side the scope of the CAP protocol. scope of the CAP protocol.
For example an implementation or a CS administrator may wish For example an implementation or a CS administrator may wish to
to define a VCAR that will always allow the calendar owners to define a VCAR that will always allow the calendar owners to have full
have full access to their own calendars. The GRANT property access to their own calendars. The GRANT property allows the OWNERs
allows the OWNERs all (OBJECT=*) access to their own calendar all (OBJECT=*) access to their own calendar objects. The DENY
objects. The DENY property disallows anyone (UPN=*) from property disallows anyone (UPN=*) from being able to delete or modify
being able to delete or modify this VCAR. this VCAR.
BEGIN:VCAR BEGIN:VCAR
CARID:Users Default Access CARID:Users Default Access
GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=* GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=*
DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID; DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;
VALUE="Users Default Access" VALUE="Users Default Access"
;OBJECT=METHOD,VALUE=DELETE,MODIFY ;OBJECT=METHOD,VALUE=DELETE,MODIFY
END:VCAR END:VCAR
Decreed VCARs MUST be readable by the calendar owner in Decreed VCARs MUST be readable by the calendar owner in standard VCAR
standard VCAR format. format.
2.4.5 Inheritance 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.
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 VCARs specified in a calendar or a sub-calendar override all
inherited VCARs. inherited VCARs.
2.4.6 CAP Session Identity 2.4.6 CAP Session Identity
A CAP session has an associated set of authentication A CAP session has an associated set of authentication credentials,
credentials, from which is derived a UPN. This UPN is the from which is derived a UPN. This UPN is the identity of the CAP
identity of the CAP session, and is used to determine access session, and is used to determine access rights for the session.
rights for the session.
The CUA may change the identity of a CAP session by calling The CUA may change the identity of a CAP session by calling the
the "IDENTIFY" command. The Calendar Service only permits the "IDENTIFY" command. The Calendar Service only permits the operation
operation if the session's authentication credentials are good if the session's authentication credentials are good for the
for the requested identity. The method of checking this requested identity. The method of checking this permission is
permission is implementation dependent, but may be thought of implementation dependent, but may be thought of as a mapping from
as a mapping from authentication credentials to UPNs. The authentication credentials to UPNs. The "IDENTIFY" command allows a
"IDENTIFY" command allows a single set of authentication single set of authentication credentials to choose from multiple
credentials to choose from multiple identities, and allows identities, and allows multiple sets of authentication credentials to
multiple sets of authentication credentials to assume the same assume the same identity.
identity.
For anonymous access the identity of the session is "@", a UPN For anonymous access the identity of the session is "@", a UPN with a
with a null username and null realm. A UPN with a null null username and null realm. A UPN with a null username, but non-
username, but non-null realm, such as "@foo.com" may be used null realm, such as "@foo.com" may be used to mean any identity from
to mean any identity from that realm, which is useful to grant that realm, which is useful to grant access rights to all users in a
access rights to all users in a given realm. A UPN with a non- given realm. A UPN with a non-null username and null realm, such as
null username and null realm, such as "bob@" could be a "bob@" could be a security risk and MUST NOT be used.
security risk and MUST NOT be used.
Since the UPN includes realm information it may be used to Since the UPN includes realm information it may be used to govern
govern calendar store access rights across realms. However, calendar store access rights across realms. However, governing
governing access rights across realms is only useful if login access rights across realms is only useful if login access is
access is available. This could be done through a trusted available. This could be done through a trusted server relationship
server relationship or a temporary account. or a temporary account.
The "IDENTIFY" command provides for a weak group The "IDENTIFY" command provides for a weak group implementation. By
implementation. By allowing multiple sets of authentication allowing multiple sets of authentication credentials belonging to
credentials belonging to different users to identify as the different users to identify as the same UPN, that UPN essentially
same UPN, that UPN essentially identifies a group of people, identifies a group of people, and may be used for group calendar
and may be used for group calendar ownership, or the granting ownership, or the granting of access rights to a group.
of access rights to a group.
Examples: Examples:
Small UG: Small UG:
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 The Three Stooges. There will always be three, it will not
change.
The Three Stooges. There will always be three, it
will not change.
Large UG: Large UG:
The MIT graduating class of 1999. This is a static
list. The MIT graduating class of 1999. This is a static list.
Dynamic UG: Dynamic UG:
The IETF membership, which is a large and changing
list of members. The IETF membership, which is a large and changing list of
members.
Nested UG: Nested UG:
The National Football League, made up of the AFC and
NFC, which are made up of 3 divisions each. The National Football League, made up of the AFC and NFC, which
are made up of 3 divisions each.
2.5 Roles 2.5 Roles
CAP defines methods for managing [iCAL] objects on a Calendar CAP defines methods for managing [iCAL] objects on a Calendar Store
Store and exchanging [iCAL] objects for the purposes of group and exchanging [iCAL] objects for the purposes of group calendaring
calendaring and scheduling between "Calendar Users" (CUs) or and scheduling between "Calendar Users" (CUs) or "User Groups" (UGs).
"User Groups" (UGs). There are two distinct roles taken on by There are two distinct roles taken on by CUs in CAP. The CU who
CUs in CAP. The CU who creates an initial event or to-do and creates an initial event or to-do and invites other CUs or UGs as
invites other CUs or UGs as attendees takes on the role of attendees takes on the role of "Organizer". The CUs or UGs asked to
"Organizer". The CUs or UGs asked to participate in the group participate in the group event or to-do take on the role of
event or to-do take on the role of "Attendee". Note that "Attendee". Note that "role" is also a descriptive parameter to the
"role" is also a descriptive parameter to the "ATTENDEE" "ATTENDEE" property. Its use is to convey descriptive context to an
property. Its use is to convey descriptive context to an "Attendee" such as "chair", "REQ-PARTICIPANT" or "NON- PARTICIPANT"
"Attendee" such as "chair", "REQ-PARTICIPANT" or "NON- and has nothing to do with the scheduling workflow.
PARTICIPANT" and has nothing to do with the scheduling
workflow.
2.6 Calendar Addresses 2.6 Calendar Addresses
Calendar addresses are URIs that are modeled after URLs [URL]. Calendar addresses are URIs that are modeled after URLs [URL]. CAP
CAP uses the following forms of URI. uses the following forms of URI.
[[<scheme>]://<csid>[:<port>]/]<relativeCALID> [[<scheme>]://<csid>[:<port>]/]<relativeCALID>
where: where:
<scheme> is "cap", the protocol described in this <scheme> is "cap", the protocol described in this memo.
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 <csid> is the Calendar Store ID. It is the network address of the
computer on which the CAP server is running.
<port> is optional. Its default value is 5229. The <port> is optional. Its default value is 5229. The port must be
port must be present in the URL if the CAP server present in the URL if the CAP server does not listen on this
does not listen on this default port of 5229. default port of 5229.
<relativeCALID> is an identifier that uniquely <relativeCALID> is an identifier that uniquely identifies the
identifies the calendar on a particular calendar calendar on a particular calendar store. There is no implied
store. There is no implied structure in a Relative structure in a Relative CALID. It is an arbitrary string of
CALID. It is an arbitrary string of printable 7 bit printable 7 bit ASCII characters. It may refer to the calendar of
ASCII characters. It may refer to the calendar of a a user or of a resource such as a conference room. It MUST be
user or of a resource such as a conference room. It unique within the calendar store. It is recommended that the
MUST be unique within the calendar store. It is Relative CALID be globally unique.
recommended that the Relative CALID be globally
unique.
If the <scheme> and <csid> are present the calendar address is If the <scheme> and <csid> are present the calendar address is said
said to be "qualified". Senders are required to supply the to be "qualified". Senders are required to supply the
<relativeCALID> portion of the address. A qualified calendar <relativeCALID> portion of the address. A qualified calendar address
address is required when the <csid> of the target calendar is required when the <csid> of the target calendar address differs
address differs from that of the CAP server receiving the from that of the CAP server receiving the command.
command.
Examples of CAP URIs: Examples of CAP URIs:
cap://calendar.example.com/user1 cap://calendar.example.com/user1
://calendar.example.com/user1 ://calendar.example.com/user1
user1 user1
cap://calendar.example.com/conferenceRoomA cap://calendar.example.com/conferenceRoomA
cap://calendar.example.com/89798-098-zytytasd cap://calendar.example.com/89798-098-zytytasd
For a user currently authenticated to a CAP server on For a user currently authenticated to a CAP server on
calendar.example.com, the first three addresses refer to the calendar.example.com, the first three addresses refer to the same
same calendar. calendar.
2.7 Extensions to iCalendar 2.7 Extensions to iCalendar
In mapping the CAP command set, query feature, and access In mapping the CAP command set, query feature, and access rights onto
rights onto the iCalendar format, several extended iCalendar the iCalendar format, several extended iCalendar methods and
methods and components are defined by this memo. components are defined by this memo.
* The search function is specified with the new The search function is specified with the new iCalendar QUERY
iCalendar QUERY method. The QUERY method makes use of method. The QUERY method makes use of a new component, called
a new component, called VQUERY, that contains the VQUERY, that contains the search filter. The component consists
search filter. The component consists of a set of new of a set of new properties: EXPAND, MAXSIZE, MAXRESULTS, QUERY and
properties: EXPAND, MAXRESULTS, MAXRESULTSSIZE, QUERY QUERYNAME, that define the search filter. Note that QUERY simply
and QUERYNAME, that define the search filter. Note is the filter that is used by the CS to select the data used in
that QUERY simply is the filter that is used by the CS METHOD:READ, METHOD:CREATE, METHOD:MODIFY, METHOD:DELETE, any
to select the data used in METHOD:READ, METHOD:CREATE, other METHOD that is defined to use a QUERY filter.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 Access control is specified the the new iCalendar VCAR component.
METHOD:MODIFY, METHOD:DELETE, any other METHOD that is The iCalendar METHOD property format has been updated with new
defined to use a QUERY filter. values.
* Access control is specified the the new iCalendar VCAR
component. A new iCalendar component, VCOMMAND, has been added. VCOMMANDs
* The iCalendar METHOD property format has been updated are needed to specify CAP commands.
with new values.
* A new iCalendar component, VCOMMAND, has been added. VCAP is a new container for data that is transmitted as part of a
VCOMMANDs are needed to specify CAP commands. VCOMMAND
* TARGET is a new property within the VCOMMAND
component. It indicates the calendars to which the TARGET is a new property within the VCOMMAND component. It
command applies 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 CMDID is a Command ID that is used in a VCOMMAND to uniquely
will contain the same CMDID. identify a command. Responses to a VCOMMAND will contain the
same CMDID.
2.8 Relationship of RFC 2446 (ITIP) to CAP 2.8 Relationship of RFC 2446 (ITIP) to CAP
[iTIP] describes scheduling methods which result in indirect [iTIP] describes scheduling methods which result in indirect
manipulation of calendar components. CAP methods provide manipulation of calendar components. CAP methods provide direct
direct manipulation of calendar components. In the CAP manipulation of calendar components. In the CAP calendar store
calendar store model, scheduling messages are conceptually model, scheduling messages are conceptually kept separate from other
kept separate from other calendar components. This is modeled calendar components. This is modeled with the VSCHEDULE queue. Note
with the VSCHEDULE queue. Note that this is a conceptual that this is a conceptual model, the actual storage details are left
model, the actual storage details are left to implementations. to implementations. The model is shown pictorially as follows:
The model is shown pictorially as follows:
+-----------------VCALENDAR-------------------+ +-----------------VCALENDAR-------------------+
| | | |
| +-----------+ +-------VSCHEDULE---------+ | | +-----------+ +-------VSCHEDULE---------+ |
| | VEVENTs | | PUBLISH messages | | | | VEVENTs | | PUBLISH messages | |
| | VTODOs | | REQUEST messages | | | | VTODOs | | REQUEST messages | |
| | VJOURNALs | | REPLY messages | | | | VJOURNALs | | REPLY messages | |
| | | | ADD messages | | | | | | ADD messages | |
| | | | CANCEL messages | | | | | | CANCEL messages | |
| | | | REFRESH messages | | | | | | REFRESH messages | |
| | | | COUNTER messages | | | | | | COUNTER messages | |
| | | | DECLINECOUNTER messages | | | | | | DECLINECOUNTER messages | |
| +-----------+ +-------------------------+ | | +-----------+ +-------------------------+ |
+---------------------------------------------+ +---------------------------------------------+
The METHOD is saved along with components. Scheduled The METHOD is saved along with components. Scheduled components
components become booked components when the METHOD changes become booked components when the METHOD changes from an ITIP method
from an ITIP method to the CAP storage method CREATE. For to the CAP storage method CREATE. For example, a component whose
example, a component whose METHOD is "REQUEST" is scheduled. METHOD is "REQUEST" is scheduled. The component becomes booked when
The component becomes booked when the METHOD is changed to the METHOD is changed to "CREATED".
"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 Several scheduled entries can be in the CS for the same UID. They
to attend a meeting and several updates to that meeting. Your are consolidated when booked. Or they are removed from the CS.
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.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 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.
3 State Diagram 3. State Diagram
This section describes the states of the transport connection This section describes the states of the transport connection between
between a CUA and a CS. The state diagram is shown below. a CUA and a CS. The state diagram is shown below. State names are
State names are shown with first letter capitalized. Commands shown with first letter capitalized. Commands used to switch between
used to switch between states are shown next to an arrow states are shown next to an arrow connecting the states. The
connecting the states. The commands are listed in all capital commands are listed in all capital letters. A condition that causes
letters. A condition that causes a state to change is shown in a state to change is shown in lower case letters.
lower case letters.
STARTTLS / STARTTLS /
CAPABILITY CAPABILITY
+-------+ +-------+
| | +---------------+ | | +---------------+
| +-----------+ AUTHENTICATE | | | +-----------+ AUTHENTICATE | |
+-->| Connected |-------------->| Authenticated | +-->| Connected |-------------->| Authenticated |
+-----------+ | | +-----------+ | |
| +---------------+ | +---------------+
| | | |
skipping to change at page 29, line 48 skipping to change at page 30, line 45
A | | A | |
| V | | V |
| DISCONNECT +---------------+ | | DISCONNECT +---------------+ |
+--------------------| Receive |------+ +--------------------| Receive |------+
| |<--+ | |<--+
+---------------+ | +---------------+ |
| | | |
+----+ +----+
CONTINUE CONTINUE
The connection begins the Connected state when a CUA connects The connection begins the Connected state when a CUA connects to a
to a CAP server. The capabilities of the CS are reported in CAP server. The capabilities of the CS are reported in the response
the response from the CS. From this state, the CUA can issue from the CS. From this state, the CUA can issue the DISCONNECT
the DISCONNECT command to terminate the connection, the command to terminate the connection, the CAPABILITY, STARTTLS, or
CAPABILITY, STARTTLS, or AUTHENTICATE commands. One use of the AUTHENTICATE commands. One use of the CAPABILITY command at this
CAPABILITY command at this stage is to determine the supported stage is to determine the supported authentication mechanisms
supported by the server. Once the STARTTLS command has been
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 successfully executed from either the Connected or Authenticated
state, it must not be executed again.
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 If an AUTHENTICATE command is successful, the connection enters the
enters the Authenticated state and then immediately goes to Authenticated state and then immediately goes to the IDENTIFIED
the IDENTIFIED state. While in the Identified state, allow state. While in the Identified state, the CALIDEXPAND and UPNEXPAND
CALIDEXPAND and UPNEXPAND commands. From here the CUA can commands can be executed. From here the CUA can issue the CAPABILITY
issue the CAPABILITY command. The capabilities the server command. The capabilities offered by the server in the Authenticated
offers in the Authenticated state may be different than those state may be different than those in the Connected state to allow for
in the Connected state to allow for the users realm to be used the user's realm to be used to grant or deny features. The CUA can
to grant or deny features. The CUA can also use the IDENTIFY also use the IDENTIFY command to change the identity of the user
command to change the identity of the user subject to access subject to access control. The connection remains in the Identified
control. The connection remains in the Authenticated state state after the CAPABILITY command completes. The CUA can issue the
after the CAPABILITY command completes. The CUA can issue the DISCONNECT command to terminate the connection. The SENDDATA command
DISCONNECT command to terminate the connection. The SENDDATA can be used to send a request to read, write, modify, or delete data
command can be used to send a request to read, write, modify, on the server.
or delete data on the server.
After the SENDDATA command has been issued the connection After the SENDDATA command has been issued the connection enters the
enters the Receive state while the CUA awaits and reads a Receive state while the CUA awaits and reads a server reply.
server reply. Normally, the server handles the command, sends Normally, the server handles the command, sends a reply which is read
a reply which is read by the CUA and the connection returns to by the CUA and the connection returns to the Authenticated state.
the Authenticated state. The CUA may have issued the SENDATA The CUA may have issued the SENDATA command with a maximum latency
command with a maximum latency time. This informs the server time. This informs the server that the CUA expects a response within
that the CUA expects a response within the maximum latency the maximum latency time, even if the command was not completed.
time, even if the command was not completed. When the server When the server is unable to complete the command in the maximum
is unable to complete the command in the maximum latency time, latency time, it issues an appropriate reply code and waits for the
it issues an appropriate reply code and waits for the CUA to CUA to tell it how to proceed. If the CUA issues a CONTINUE command
tell it how to proceed. If the CUA issues a CONTINUE command
the server continues processing the command and the connection the server continues processing the command and the connection
remains in the Receive state. If the CUA issues the ABORT remains in the Receive state. If the CUA issues the ABORT command
command the server need not process the command any further the server need not process the command any further and the
and the connection returns to the Authenticated state. The connection returns to the Identified state. The DISCONNECT command
DISCONNECT command can also be issued from the Receive state. can also be issued from the Receive state.
4 Protocol Framework 4. Protocol Framework
4.1 CAP Application Layer 4.1 CAP Application Layer
The CAP application layer is used for the manipulation of the The CAP application layer is used for the manipulation of the
calendar store. Commands and responses are transmitted between calendar store. Commands and responses are transmitted between the
the CUA and CS inside "VCALENDAR" component wrappers. Commands CUA and CS inside "VCAP" wrappers. Commands are specified as the
are specified as the value of a "METHOD" property, and value of a "METHOD" property, and responses are specified as the
responses are specified as the value of a "REQUEST-STATUS" value of a "REQUEST-STATUS" property. An optional "CMDID" may be
property. used to uniquely identify commands.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
4.2 CAP Transfer Protocol 4.2 CAP Transfer Protocol
The CAP transfer protocol defines the format of data The CAP transfer protocol defines the format of data transmitted
transmitted between a CUA and the CS. between a CUA and the CS.
CAP transfer protocol commands are transmitted using the CAP transfer protocol commands are transmitted using the underlying
underlying transport. The transport used is a TCP/IP socket transport. The transport used is a TCP/IP socket connection between
connection between the CUA and the CS. The default port that the CUA and the CS. The default port that the CS listens for
the CS listens for connections on is port 5229. connections on is port 5229.
Messages sent between the CUA and CS are formatted as a Messages sent between the CUA and CS are formatted as a command
command followed by any associated data: followed by any associated data:
<command> [<command data>] <command> [<command data>]
Response Format Server responses consist of a response code and any parameters:
Server responses consist of a response code and any
parameters:
<transfer-level response-code> [response-args] [; debug-text ] <transfer-level response-code> [response-args] [; debug-text ]
<CRLF>.<CRLF> <CRLF>.<CRLF>
[<application-data>] [<application-data>]
<CRLF>.<CRLF> <CRLF>.<CRLF>
The response-args are defined in Section 8. The debug-text is The response-args are defined in Section 8. The debug-text is human-
human-readable information for protocol debugging and is readable information for protocol debugging and is optional and is
optional and is only used to aid developers writing CSs and only used to aid developers writing CSs and CUAs. The debug-text
CUAs. The debug-text MUST not be depended on by CUAs in MUST not be depended on by CUAs in normal interactions with a CS.
normal interactions with a CS.
The optional application-data begins on the next line. The optional application-data begins on the next line.
The response is terminated with the second <CRLF> "." <CRLF> The response is terminated with the second <CRLF> "." <CRLF>
sequence. Any <CRLF> "." sequences which appear in the sequence. Any <CRLF> "." sequences which appear in the transmitted
transmitted data must be quoted by placing an additional "." data must be quoted by placing an additional "." between the <CRLF>
between the <CRLF> and the ".". For example, the following and the ".". For example, the following sequences of characters in
sequences of characters in the application data: the application data:
. .
..2 ..2
...3 ...3
are quoted as follows: are quoted as follows:
.. ..
...2 ...2
....3 ....3
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 4.3 Pipelining Commands
4.3 Pipelining of Commands
If the CS returns a PIPELINE number greater then one (1) as a 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 result of a CAPABILITY command then the CUA can send up to PIPELINE
VCOMMANDS without waiting for the CS to reply. VCAP (each with a unique CMDID/VCOMMAND) without waiting for the CS
to reply.
It is unspecified what happens of the CUA exceedes the CS limit.
4.4 Auto-logout Timer 4.4 Auto-logout Timer
If a server has an inactivity auto-logout timer, that timer If a server has an inactivity auto-logout timer, that timer MUST be
MUST be of at least 15 minutes duration if there is no value of at least 15 minutes duration if there is no value of
of AUTOLOGOUTTIME returned in the CS CAPABILITY reply. The AUTOLOGOUTTIME returned in the CS CAPABILITY reply. The receipt of
receipt of ANY command from the client during that interval ANY command from the client during that interval MAY reset the auto-
MAY reset the auto-logout timer, subject to CS administrators logout timer, subject to CS administrators policy. A CUA may be
policy. A CUA may be discouraged from attempts to do useless discouraged from attempts to do useless things only to keep the
things only to keep the connection alive. connection alive.
A CS MAY have different AUTOLOGOUTTIME values depending on the A CS MAY have different AUTOLOGOUTTIME values depending on the UPN or
UPN or the realm of the UPN. the realm of the UPN.
When a timeout occurs, the server drops the connection to the When a timeout occurs, the server drops the connection to the CUA.
CUA.
4.5 Bounded Latency 4.5 Bounded Latency
CAP is designed so that the CUA can either obtain an immediate CAP is designed so that the CUA can either obtain an immediate
response from a request or discover within a specified amount response from a request or discover within a specified amount of time
of time that the request could not be completed in the that the request could not be completed in the requested amount of
requested amount of time. When the CUA initiates a command time. When the CUA initiates a command that the server cannot
that the server cannot complete within the specified latency complete within the specified latency time, the server returns an
time, the server returns an appropriate response code. The CUA appropriate response code. The CUA then issues either a CONTINUE or
then issues either a CONTINUE or ABORT command. The ABORT ABORT command. The ABORT command immediately terminates the command
command immediately terminates the command in progress in progress identified by CMDID and the connection returns to the
identified by CMDID and the connection returns to the Authenticated state. The CONTINUE command instructs the server to
Authenticated state. The CONTINUE command instructs the continue processing the command identified by the CMDID.
server to continue processing the command identified by the
CMDID.
4.6 Data Elements 4.6 Data Elements
The data elements for CAP are [MIME] encapsulated iCalendar The data elements for CAP are [MIME] encapsulated iCalendar objects.
objects.
5 Formal Command Syntax 5. Formal Command Syntax
5.1 Searching and Filtering
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 5.1 Searching and Filtering
This section describes CAPs selecting and filtering entities This section describes CAP's selecting and filtering entities within
within a calendar store. It is based on the Standard Query a calendar store. It is based on the Standard Query Language (SQL)
Language (SQL) defined in [SQL]. defined in [SQL].
5.1.1 Grammar For Search Mechanism 5.1.1 Grammar For Search Mechanism
search = "BEGIN:VQUERY" CRLF search = "BEGIN:VQUERY" CRLF
[expand] [maxresults] [maxsize] querycomp [expand] [maxresults] [maxsize] querycomp
"END:VQUERY" CRLF "END:VQUERY" CRLF
expand = "EXPAND" ":" ( "TRUE" / "FALSE") expand = "EXPAND" ":" ( "TRUE" / "FALSE")
# the default is EXPAND:FALSE # the default is EXPAND:FALSE
comp-name = "VEVENT" / "VTODO" / "VJOURNAL" comp-name = "VEVENT" / "VTODO" / "VJOURNAL"
/ "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VTIMEZONE" / "VALARM" / "VFREEBUSY"
/ "VCAR" / iana-name / x-name / "VCAR" / iana-name / x-name
maxresults = integer maxresults = "MAXRESULTS" ":" integer
maxsize = integer maxsize = "MAXSIZE" ":" integer
querycomp = ( query ) / ( queryname query ) / queryname querycomp = ( query ) / ( queryname query ) / queryname
queryname = "QUERYNAME:" text queryname = "QUERYNAME:" text
query = "QUERY:" ( query-min / query-92 ) query = "QUERY:" ( query-min / query-92 )
# #
# NOTE: query-min MUST be implemented in CSs. # NOTE: query-min MUST be implemented in CSs.
# #
# query-92 is ONLY used if CAPABILITY returns SQL-92 # query-92 is ONLY used if CAPABILITY returns SQL-92
skipping to change at page 33, line 51 skipping to change at page 36, line 4
query-min = capselect-min capfrom-min capwhere-min query-min = capselect-min capfrom-min capwhere-min
capselect-min = "SELECT" capmin-cols "FROM" capmin-comps capselect-min = "SELECT" capmin-cols "FROM" capmin-comps
"WHERE" capmin-cmp "WHERE" capmin-cmp
capmin-col = # Any property name found in any of the capmin-col = # Any property name found in any of the
components. components.
capmin-cols = ( capmin-col / capmin-col "," capmin-cols = ( capmin-col / capmin-col ","
capmin-cols ) capmin-cols )
capmin-comps = ( comp-name / comp-name "," capmin-comps = ( comp-name / comp-name ","
compmin-comps ) compmin-comps )
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
capmin-cmp = ( colname cmpmin-oper colvalue capmin-cmp = ( colname cmpmin-oper colvalue
/ colname cmpmin-oper colvalue / colname cmpmin-oper colvalue
capmin-logical capmin-cmp ) capmin-logical capmin-cmp )
colname = ( # Any valid component property name. colname = ( # Any valid component property name.
/ "*" ) / "*" )
cmpmin-oper = ( " = " / " != " / " < " / " > " / " <= " cmpmin-oper = ( " = " / " != " / " < " / " > " / " <= "
/ " >= " ) / " >= " )
skipping to change at page 34, line 46 skipping to change at page 36, line 46
(1) No inlined spaces are allowed if not in the grammar above. (1) No inlined spaces are allowed if not in the grammar above.
(2) Note that cmpmin-oper and capmin-logical elements are (2) Note that cmpmin-oper and capmin-logical elements are
surrounded by exactly one space. surrounded by exactly one space.
Use 'VEVENT,VTODO', not 'VEVENT, VTODO' Use 'VEVENT,VTODO', not 'VEVENT, VTODO'
Use 'DTSTART <= 20000605T131313Z', not Use 'DTSTART <= 20000605T131313Z', not
'DTSTART<= 20000605T131313Z'. 'DTSTART<= 20000605T131313Z'.
Use ' AND ' and ' OR ', not 'AND' and not 'OR'. Use ' AND ' and ' OR ', not 'AND' and not 'OR'.
(3) There is no ORDERBY. Sorting will take place in the order (3) There is no ORDERBY. Sorting will take place in the order the
the columns are supplied in the command. columns are supplied in the command.
(4) The CS MUST sort at least the first column.The CS MAY sort (4) The CS MUST sort at least the first column.The CS MAY sort
additional columns. additional columns.
(5) If EXPAND=FALSE and if colname is "*" sorting will be by (5) If EXPAND=FALSE and if colname is "*" sorting will be by the
the DTSTART value ascending. DTSTART value ascending. If EXPAND=TRUE and if colname is "*"
sorting will be by the RECURRENCE-ID 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 If colname is "*" and capmin-coms is VALARM only then sorting will
sorting will be by TRIGGER time in GMT ascending. be by TRIGGER time in GMT ascending.
(6) SQL-MIN MUST be implemented. (6) SQL-MIN MUST be implemented.
5.1.3 SQL-92 notes 5.1.3 SQL-92 notes
(1) Although this memo specifies that any [SQL] query can be (1) Although this memo specifies that any [SQL] query can be used,
used, some of the [SQL] grammar is optional and therefore is some of the [SQL] grammar is optional and therefore is considered
considered optional in CSs advertising an SQL-92 optional in CSs advertising an SQL-92 implementation with CAPABILITY.
implementation with CAPABILITY.
(2) A CS implementation MAY implement SQL-92. If a CS does not (2) A CS implementation MAY implement SQL-92. If a CS does not
implement SQL-92 then it MUST advertise SQL-MIN in the implement SQL-92 then it MUST advertise SQL-MIN in the capability
capability reply. reply.
5.1.4 Example, Query by UID 5.1.4 Example, Query by UID
This example would select the entire contents of uid123 and This example would select the entire contents of uid123 and not
not expand any multiple instances of the component. If the expand any multiple instances of the component. If the CUA does not
CUA does not know if 'uid123' was a VEVENT, VTODO, VJOURNAL, know if 'uid123' was a VEVENT, VTODO, VJOURNAL, or other component,
or other component, then all components that the CUA supports then all components that the CUA supports MUST be supplied on the
MUST be supplied on the QUERY property. This example assumes QUERY property. This example assumes the CUA only supports VTODO and
the CUA only supports VTODO and VEVENT. VEVENT.
If the results were empty it could also mean that 'uid123' was If the results were empty it could also mean that 'uid123' was a
a property in a component other than a VTODO or VEVENT. property in a component other than a VTODO or VEVENT.
BEGIN:VQUERY BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123' QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123'
END:VQUERY END:VQUERY
This example would select the entire contents of uid123 and This example would select the entire contents of uid123 and would
would expand any instances of the component after applying any expand any instances of the component after applying any recurrence
recurrence rules. This query could select multiple instances rules. This query could select multiple instances of components each
of components each with the same UID. Each instance would with the same UID. Each instance would have a unique RECURRENCE-ID
have a unique RECURRENCE-ID of the expanded component. of the expanded component.
BEGIN:VQUERY BEGIN:VQUERY
EXPAND:TRUE EXPAND:TRUE
QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123' QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123'
END:VQUERY END:VQUERY
5.1.5 Query by Date-Time range 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
This query selects the entire contents of every booked VEVENT greater than or equal to July 1st, 2000 00:00:00 Z
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 BEGIN:VQUERY
EXPAND:TRUE EXPAND:TRUE
QUERY:SELECT * FROM VEVENT QUERY:SELECT * FROM VEVENT
WHERE RECURRENCE-ID >= '20000801T000000Z' WHERE RECURRENCE-ID >= '20000801T000000Z'
AND RECURRENCE-ID <= '20000831T235959Z' AND RECURRENCE-ID <= '20000831T235959Z'
AND METHOD = 'CREATE' AND METHOD = 'CREATE'
END:VQUERY END:VQUERY
5.1.6 Query for all Non-Booked Entries 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 This example selects the entire contents of all scheduling (non-
FALSE, so the recurrence rules will not be expanded. booked) VEVENTS in the CS. The default for EXPAND is FALSE, so the
recurrence rules will not be expanded.
BEGIN:VQUERY BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT,VTODO WHERE METHOD != 'CREATE' QUERY:SELECT * FROM VEVENT,VTODO WHERE METHOD != 'CREATE'
END:VQUERY END:VQUERY
The following example fetches the UIDs of all non-booked The following example fetches the UIDs of all non-booked VEVENTs and
VEVENTs and VTODOs. VTODOs.
BEGIN:VQUERY BEGIN:VQUERY
QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD != 'CREATE' QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD != 'CREATE'
END:VQUERY END:VQUERY
5.1.7 Query with Subset of Properties by Date/Time 5.1.7 Query with Subset of Properties by Date/Time
This MUST implement is similar to the one above, except only This MUST implement is similar to the one above, except only the
the named properties will be selected and all booked and non- named properties will be selected and all booked and non- booked
booked components will be selected that have a DTSTART from components will be selected that have a DTSTART from Feb 1st to Feb
Feb 1st to Feb 10th. 10th.
BEGIN:VQUERY BEGIN:VQUERY
QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT
WHERE DTSTART >= '20000201T000000Z' WHERE DTSTART >= '20000201T000000Z'
AND DTSTART <= '20000210T235959Z' AND DTSTART <= '20000210T235959Z'
END:VQUERY END:VQUERY
5.1.8 Components With Alarms In A Range 5.1.8 Components With Alarms In A Range
This example fetches all components with an alarm that
triggers within the 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 This example fetches all components with an alarm that triggers
within the 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.
BEGIN:VQUERY BEGIN:VQUERY
EXPAND:TRUE EXPAND:TRUE
QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
WHERE VALARM.TRIGGER >= '20000101T030405Z' WHERE VALARM.TRIGGER >= '20000101T030405Z'
AND VALARM.TRIGGER <= '20001231T235959Z' AND VALARM.TRIGGER <= '20001231T235959Z'
AND METHOD = 'CREATE' AND METHOD = 'CREATE'
END:VQUERY END:VQUERY
6 Access Rights 6. Access Rights
Access rights within CAP are specified with the "VCAR" Access rights within CAP are specified with the "VCAR" calendar
calendar component, "RIGHTS" value type and the "GRANT", component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID"
"DENY" and "CARID" component properties. component properties.
Individual calendar access rights MUST be specifically granted Individual calendar access rights MUST be specifically granted to an
to an authenticated calendar user (i.e., UPN); all rights are authenticated calendar user (i.e., UPN); all rights are denied unless
denied unless specifically granted. specifically granted.
Properties within a VCAR must be evaluated in the order Properties within a VCAR must be evaluated in the order provided.
provided.
6.1 VCAR Inheritance 6.1 VCAR Inheritance
Calendar access rights specified in a calendar store are Calendar access rights specified in a calendar store are inherited as
inherited as default calendar access rights for any calendar default calendar access rights for any calendar in the parent
in the parent calendar store. Likewise, any calendar access calendar store. Likewise, any calendar access rights specified in a
rights specified in a root calendar are inherited as default root calendar are inherited as default calendar access rights for any
calendar access rights for any sub- calendar to the root sub- calendar to the root calendar. By implication, calendar access
calendar. By implication, calendar access rights specified in rights specified in a sub-calendar are inherited as default calendar
a sub-calendar are inherited as default calendar access rights access rights for any calendars that are hierarchically below the
for any calendars that are hierarchically below the sub- sub- calendar.
calendar.
Calendar access rights specified in a calendar override any Calendar access rights specified in a calendar override any default
default calendar access rights. Calendar access rights calendar access rights. Calendar access rights specified within a
specified within a sub-calendar override any default calendar sub-calendar override any default calendar access rights.
access rights.
6.2 Access Control and NOCONFLICT 6.2 Access Control and NOCONFLICT
The TRANSP property can take on values (TRANSPARENT- The TRANSP property can take on values (TRANSPARENT- NOCONFLICT,
NOCONFLICT, OPAQUE-NOCONFLICT) that prohibit other events from OPAQUE-NOCONFLICT) that prohibit other events from overlapping it.
overlapping it. This setting overrides access While access This setting overrides access While access control may allow a UPN to
control may allow a UPN to store an event on a particular store an event on a particular calendar. , the CONFLICTS Calendar or
calendar. , the CONFLICTS Calendar or component setting may component setting may prevent it, returning an error code "6.3"
prevent it, returning an error code "6.3"
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
7 Commands and Responses 7. Commands and Responses
CAP commands and responses are described in this section. CAP commands and responses are described in this section.
Command arguments, identified by "Arguments:" in the command Command arguments, identified by "Arguments:" in the command
descriptions below, are described by function, not by syntax. descriptions below, are described by function, not by syntax. The
The precise syntax of command arguments is described in the precise syntax of command arguments is described in the Formal Syntax
Formal Syntax section. section.
Some commands cause specific server data to be returned; these Some commands cause specific server data to be returned; these are
are identified by "Data:" in the command descriptions below. identified by "Data:" in the command descriptions below. See the
See the response descriptions in the Responses section for response descriptions in the Responses section for information on
information on these responses, and the Formal Syntax section these responses, and the Formal Syntax section for the precise syntax
for the precise syntax of these responses. of these responses.
The "Result:" in the command description refers to the The "Result:" in the command description refers to the possible
possible status responses to a command, and any special status responses to a command, and any special interpretation of
interpretation of these status responses. these status responses.
Commands have the general form: Commands have the general form:
<command> [arguments...] <command> [arguments...]
where <command> is a command listed in the table above. A where <command> is a command listed in the table above. A command
command MAY have arguments. Arguments are defined in the MAY have arguments. Arguments are defined in the detailed command
detailed command definitions below. definitions below.
Responses to commands have the following general form: Responses to commands have the following general form:
responseCode [sep transportDescr sep responseCode [sep transportDescr sep
[applicationDescr]] [applicationDescr]]
CRLF "." CRLF CRLF "." CRLF
In the examples below, lines preceded with "S:" refer to the In the examples below, lines preceded with "S:" refer to the sender
sender and lines preceded with "R:" refer to the receiver. and lines preceded with "R:" refer to the receiver. Lines in which
Lines in which the first non-whitespace character is a "#" are the first non-whitespace character is a "#" are editorial comments
editorial comments and are not part of the protocol. and are not part of the protocol.
7.1 Transfer Protocol Commands 7.1 Transfer Protocol Commands
7.1.1 Initial Connection 7.1.1 Initial Connection
Arguments: none Arguments: none
Data: 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
Result: 2.0 - success. that it is ready to receive commands. A response of 8.1 indicates
8.1 - server too busy that the server is too busy to accept the connection. In addition,
the general capabilities of the CS are reported in the response from
Upon session startup, the server sends a response of 2.0 to the CS. These capabilities may be different than those reported in
indicate that it is ready to receive commands. A response of the authenticated state.
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 ABORT Command 7.1.2 ABORT Command
Arguments: [CMDID] Arguments: [CMDID]
Data: none Data: none
Result: 2.0 - success Result: 2.0 - success 2.2 - no command is in progress
2.2 - no command is in progress
The ABORT command is issued by the CUA to stop a command. A The ABORT command is issued by the CUA to stop a command. A common
common usage could be to ABORT a command whose latency time usage could be to ABORT a command whose latency time has been
has been exceeded. When the latency time is specified on the exceeded. When the latency time is specified on the SENDATA command,
SENDATA command, the CS must issue a reply to the CUA within the CS must issue a reply to the CUA within the specified time. It
the specified time. It may be a reply code indicating that the may be a reply code indicating that the CS has not yet processed the
CS has not yet processed the request. The CUA must then tell request. The CUA must then tell the server whether to continue or
the server whether to continue or abort. abort.
The CUA can issue the ABORT command at any time after the The CUA can issue the ABORT command at any time after the SENDATA
SENDATA command has been completed but before receiving a command has been completed but before receiving a reply.
reply.
If CMDID is supplied then the command identified by CMDID is If CMDID is supplied then the command identified by CMDID is aborted.
aborted.
If CMDID is not supplied then the fist command that is still If CMDID is not supplied then the fist command that is still pending
pending is aborted. is aborted.
7.1.3 AUTHENTICATE Command 7.1.3 AUTHENTICATE Command
Arguments: <SASL mechanism name> [<initial data>] Arguments: <SASL mechanism name> [<initial data>]
Data: continuation data may be requested Data: continuation data may be requested
Result: Result:
2.0 - Authenticate completed, now in authenticated
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 2.0 - Authenticate completed, now in authenticated state.
6.0 - Failed authentication. 6.1 - Authorization identity
refused.
6.2 - Sender aborted authentication, authentication exchange
cancelled.
state.
6.0 - Failed authentication.
6.1 - Authorization identity refused.
6.2 - Sender aborted authentication, authentication
exchange cancelled.
6.3 - Unsupported Authentication Mechanism. 6.3 - Unsupported Authentication Mechanism.
6.4 - Temporary failure (back end authentication
server down). 6.4 - Temporary failure (back end authentication server down).
6.5 - Authentication exchange cancelled. 6.5 - Authentication exchange cancelled.
6.6 - Authentication mechanism too weak. 6.6 - Authentication mechanism too weak.
6.7 - Encryption required. 6.7 - Encryption required.
6.8 - Pass phrase expired. The pass phrase was
correct but expired. The user will have to 6.8 - Pass phrase expired. The pass phrase was correct but
contact a pass phrase change server prior to expired. The user will have to contact a pass phrase change
authenticating. server prior to authenticating.
6.9 - The user is valid but the server does not
have an entry in the authentication database 6.9 - The user is valid but the server does not have an entry in
for the requested mechanism (e.g., DIGEST- the authentication database for the requested mechanism (e.g.,
MD5). If the user successfully authenticates DIGEST- MD5). If the user successfully authenticates using a
using a plain text password, then the back plain text password, then the back end back end entry will be
end back end entry will be updated. Note updated. Note that if the client chooses to fall back to plain
that if the client chooses to fall back to text password authentication it should enable an encryption layer
plain text password authentication it should or get user-con- firmation that a one-time transition is ac-
enable an encryption layer or get user-con-
firmation that a one-time transition is ac-
ceptable. 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 6.10 - User account disabled. The user will have to contact the
reported in the response from the CS. These may be different system administrator to get the account re-enabled.
than the capabilities in the Connected, but unauthenticated
state.
The AUTHENTICATE command is used by the CUA to identify the 9.1 - Unexpected command.
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 capabilities of the CS in the authenticated state are reported in
the client MUST discard all information about the CS the response from the CS. These may be different than the
capabilities fetched prior to the TLS negotiation. In capabilities in the Connected, but unauthenticated state.
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 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 a SASL security layer is negotiated, the client MUST If STARTTLS is negotiated prior to the AUTHENTICATE command, the
discard all information about the CS capabilities fetched client MUST discard all information about the CS capabilities fetched
prior to SASL. In particular, if the client is configured to prior to the TLS negotiation. In particular, the value of supported
support multiple SASL mechanisms, it SHOULD fetch supported SASL Mechanisms MAY be different after TLS has been negotiated.
SASL Mechanisms both before and after the SASL security layer
is negotiated and verify that the value has not changed after If a SASL security layer is negotiated, the client MUST discard all
the SASL security layer was negotiated. This detects active information about the CS capabilities fetched prior to SASL. In
attacks which remove supported SASL mechanisms from the particular, if the client is configured to support multiple SASL
supported SASL Mechanisms list. 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 <initial data> is an optional parameter which can be used for
mechanisms which require an initial response from the CUA. mechanisms which require an initial response from the CUA.
The AUTHENTICATE command is followed by an authentication The AUTHENTICATE command is followed by an authentication protocol
protocol exchange, in the form of a series of CS challenges exchange, in the form of a series of CS challenges and CUA responses,
and CUA responses, per the relevant RFC that describes the per the relevant RFC that describes the specific SASL mechanism being
specific SASL mechanism being used. used.
Cancelling the authentication process during its negotiation Cancelling the authentication process during its negotiation is
is implementation specific and not within scope of the CAP implementation specific and not within scope of the CAP
specification. specification.
If a security layer was negotiated it comes into effect for If a security layer was negotiated it comes into effect for the CS
the CS starting with the first octet transmitted after the starting with the first octet transmitted after the CRLF which
CRLF which follows the 2.0 reply code, and for the CUA follows the 2.0 reply code, and for the CUA starting with the first
starting with the first octet after the CRLF of its last octet after the CRLF of its last response in the authentication
response in the authentication exchange. Encrypted data is exchange. Encrypted data is transmitted as described in SASL.
transmitted as described in SASL.
The service name specified by this protocol's profile of SASL The service name specified by this protocol's profile of SASL is
is "cap". [EDITORS NOTE: this must be registered with IANA, "cap". [EDITORS NOTE: this must be registered with IANA, has anyone
has anyone done this yet?] done this yet?]
The result of the AUTHENTICATE command includes data The result of the AUTHENTICATE command includes data indicating the
indicating the identity which has been assigned to the identity which has been assigned to the session, derived from the
session, derived from the supplied authentication credentials, supplied authentication credentials, and/or authorization identifier.
and/or authorization identifier. A CAP session does not have A CAP session does not have an identity until the CUA has issued the
an identity until the CUA has issued the "AUTHENTICATE" "AUTHENTICATE" command.
command.
The CUA may not issue the "AUTHENTICATE" command multiple The CUA may not issue the "AUTHENTICATE" command multiple times, even
times, even if the first attempt was aborted. If a CUA if the first attempt was aborted. If a CUA attempts to do this the
attempts to do this the CS must terminate the session. CS must terminate the session.
Here is an example of a successful authentication: Here is an example of a successful authentication:
C: AUTHENTICATE KERBEROS_V4 C: AUTHENTICATE KERBEROS_V4
S: AmFYig== S: AmFYig==
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
S: or//EoAADZI= S: or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw== C: DiAF5A4gA+oOIALuBkAAmw==
S: 2.0 S: 2.0
S: . S: .
S: Content-Type:text/calendar; method=REQUEST; S: Content-Type:text/calendar; method=REQUEST;
S: charset=US-ASCII S: charset=US-ASCII
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCAP S: BEGIN:VCAP
skipping to change at page 42, line 43 skipping to change at page 45, line 28
S: AmFYig== S: AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
S: . S: .
S: 6.0 S: 6.0
S: . S: .
S: . S: .
7.1.3.1 AUTHENTICATE ANONYMOUS 7.1.3.1 AUTHENTICATE ANONYMOUS
RFC-2245 defines the Anonymous SASL mechanism. This RFC states RFC-2245 defines the Anonymous SASL mechanism. This RFC states that
that "the mechanism consists of a single message from the "the mechanism consists of a single message from the client to the
client to the server. The client sends optional trace server. The client sends optional trace information in the form of a
information in the form of a human readable string. The trace human readable string. The trace information should take one of
information should take one of three forms: an Internet email three forms: an Internet email address, an opaque string which does
address, an opaque string which does not contain the '@' not contain the '@' character and can be interpreted by the system
character and can be interpreted by the system administrator administrator of the client's domain, or nothing. For privacy
of the client's domain, or nothing. For privacy reasons, an reasons, an Internet email address should only be used with
Internet email address should only be used with permission permission from the user."
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 RFC-2245 goes on to state, "A client which uses the user's correct
correct email address as trace information without explicit email address as trace information without explicit permission may
permission may violate that user's privacy." Information about violate that user's privacy." Information about who accesses an
who accesses an anonymous CS on a sensitive subject (e.g., AA anonymous CS on a sensitive subject (e.g., AA meeting times and
meeting times and locations) has strong privacy needs. locations) has strong privacy needs. "Clients should not send the
"Clients should not send the email address without explicit email address without explicit permission of the user and should
permission of the user and should offer the option of offer the option of supplying no trace token -- thus only exposing
supplying no trace token -- thus only exposing the source IP the source IP address and time."
address and time."
Example of CUA using the Capability command followed by an Example of CUA using the Capability command followed by an anonymous
anonymous authentication: authentication:
C: CAPABILITY C: CAPABILITY
S: 2.0 S: 2.0
S:CAPVERSION=1.0 S:CAPVERSION=1.0
S:AUTH=KERBEROS_V4 S:AUTH=KERBEROS_V4
S:AUTH=DIGEST_MD5 S:AUTH=DIGEST_MD5
S:AUTH=ANONYMOUS S:AUTH=ANONYMOUS
S:. S:.
C:AUTHENTICATE ANONYMOUS C:AUTHENTICATE ANONYMOUS
S:+ S:+
C:c21yaGM= C:c21yaGM=
S:2.0 S:2.0
Subsequent to the initial Anonymous Authentication with a CS, Subsequent to the initial Anonymous Authentication with a CS, a CUA
a CUA will have to provide a UPN for some CAP operations. For will have to provide a UPN for some CAP operations. For anonymous
anonymous access the UPN that MUST be used by the CUA is "@", access the UPN that MUST be used by the CUA is "@", a UPN with a null
a UPN with a null username and null realm. The user's normal username and null realm. The user's normal UPN MUST not be used for
UPN MUST not be used for the subsequent CAP operations. the subsequent CAP operations.
Note that the CS implementation may have internal audit logs Note that the CS implementation may have internal audit logs that use
that use the user's asserted UPN as trace information. the user's asserted UPN as trace information. However, this UPN will
However, this UPN will not appear on the wire after the not appear on the wire after the initial SASL anonymous
initial SASL anonymous authentication. authentication.
Use of the "@" UPN and wild-carding of UPNs within VCARs are Use of the "@" UPN and wild-carding of UPNs within VCARs are covered
covered in in
Section <forward ref>. Section <forward ref>.
7.1.4 CALIDEXPAND Command 7.1.4 CALIDEXPAND Command
Arguments: CalID Arguments: CalID
Data: no specific data for this command Data: no specific data for this command
Result: 2.0 Successful, and requested data follows Result: 2.0 Successful, and requested data follows
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
2.1 Permission Denied 2.1 Permission Denied
2.2 Requested CSID not found 2.2 Requested CSID not found
2.3 Result exceeds MAXEXPANDLIST 2.3 Result exceeds MAXEXPANDLIST
2.4 Misc. EXPAND error 2.4 Misc. EXPAND error
Return the members of the argument CalID. Successful result Return the members of the argument CalID. Successful result yields
yields one or more Calendars and/or Resource Calendars. More one or more Calendars and/or Resource Calendars. More than one C or
than one C or RC returned implies that the CalID was a CC. RC returned implies that the CalID was a CC.
Example: If the number of items exceeds MAXCALIDEXPAND, then up to
MAXCALIDEXPAND items are returned along with result 2.3.
Example #1: Request lookup of CSID which is a Calendar If the result is 2.4, then as many of the items as possible will be
Collection returned. It is possible that no items will be returned. The 2.4
response may have optional text describing the problem. Any such
text MUST be in the language and charset that is defined by the
calendar store properties LANGUAGE and CHARSET. If calendar store
CHARSET is not set, but the LANGUAGE property is set, then the
error message will be in LANGUAGE in the UTF-8 charset. If calendar
store LANGUAGE property is not set, then the CS MUST NOT return any
text with the results.
Examples:
Example #1: Request lookup of CSID which is a Calendar Collection
C: CALIDEXPAND cap://cal.example.com/calid14 C: CALIDEXPAND cap://cal.example.com/calid14
S: 2.0 cap://cal.example.com/calid14 S: 2.0
S: cap://cal.example.com/calid14
S: cap://cal.example.com/calid2 S: cap://cal.example.com/calid2
S: cap://cal.example.com/calid5 S: cap://cal.example.com/calid5
S: cap://cal.example.com/calid66 S: cap://cal.example.com/calid66
S: . S: .
Example #2: Request lookup a CSID which is a Resource Calendar Example #2: Request lookup a CSID which is a Resource Calendar
C: CALIDEXPAND cap://cal.example.com/conf5 C: CALIDEXPAND cap://cal.example.com/conf5
S: 2.0 cap://cal.example.com/conf5 S: 2.0
S: cap://cal.example.com/conf5
S: cap://cal.example.com/conf5 S: cap://cal.example.com/conf5
S: . S: .
Example #3: Request CSID which exceeds MAXCALIDEXPANDLIST Example #3: Request CSID which exceeds MAXCALIDEXPANDLIST
C: CALIDEXPAND cap://cal.example.com/calid76 C: CALIDEXPAND cap://cal.example.com/calid76
S: 2.0 cap://cal.example.com/calid76 S: 2.3 Expansion resulted in too much data
S: cap://cal.example.com/calid76
S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid12 S: cap://cal.example.com/calid12
S: cap://cal.example.com/calid21 S: cap://cal.example.com/calid21
S: cap://cal.example.com/calid33 S: cap://cal.example.com/calid33
S: 2.3 Expansion resulted in too much data
S: . S: .
Example #4: CS loses contact with directory server during Example #4: CS loses contact with directory server during CALIDEXPAND
CALIDEXPAND
C: CALIDEXPAND cap://cal.example.com/calid76 C: CALIDEXPAND cap://cal.example.com/calid76
S: 2.0 cap://cal.example.com/calid76 S: 2.4 Lost contact with directory server
S: cap://cal.example.com/calid76
S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid5 S: cap://cal.example.com/calid5
S: 2.4 Lost contact with directory server
S: . S: .
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
7.1.5 CAPABILITY Command 7.1.5 CAPABILITY Command
Arguments: none Arguments: none
Data: none Data: none
Result: capabilities as described below Result: capabilities as described below
The CAPABILITY command returns information about the CAP The CAPABILITY command returns information about the CAP server given
server given the current state of the connection with the the current state of the connection with the client. The values
client. The values returned may differ depending on whether returned may differ depending on whether the connection is in the
the connection is in the Connected or the Authenticated state. Connected or the Authenticated state. The return values may also be
The return values may also be different for a secure versus a different for a secure versus a non-secure connection.
non-secure connection.
Client implementations SHOULD NOT require any capability name Client implementations SHOULD NOT require any capability name beyond
beyond those defined in this specification, and MAY ignore any those defined in this specification, and MAY ignore any non-standard,
non-standard, experimental capability names. Non-standard experimental capability names. Non-standard experimental capability
experimental capability names MUST be prefixed with the text names MUST be prefixed with the text "X-". The prefix SHOULD also
"X-". The prefix SHOULD also include a short character vendor include a short character vendor identifier For example, "X-FOO-
identifier For example, "X-FOO-BARCAPABILITY", for the non- BARCAPABILITY", for the non- standard "BARCAPABILITY" capability of
standard "BARCAPABILITY" capability of the implementor "FOO". the implementor "FOO". This command may return different results in
This command may return different results in the Connected the Connected state versus the Authenticated state. It may also
state versus the Authenticated state. It may also return return different results depending on the UPN.
different results depending on the UPN.
Capability Occurs Description Capability Occurs Description
------------------------------------------------------- -------------------------------------------------------
AUTH 1+ The authentication mechanisms AUTH 1+ The authentication mechanisms
supported. Implementations MUST supported. Implementations MUST
implement at least implement at least
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.
CAPVERSION 1 Revision of CAP, MUST include at CAPVERSION 1 Revision of CAP, MUST include at
least "1.0". Comma separated least "1.0". Comma separated
values. values.
ITIPVERSION 0 or 1 Revision of ITIP, MAY be present. ITIPVERSION 0 or 1 Revision of ITIP, MAY be present.
If present, it MUST include at If present, it MUST include at
least "1.0" least "1.0"
CAR 0 or 1 Indicates level of CAR support. CAR 0 or 1 Indicates level of CAR support.
CAR-MIN or CAR-FULL-1. If not CAR-MIN or CAR-FULL-1. If not
specified the default is specified the default is
CAR-FULL-1. Implementations CAR-FULL-1. Implementations
MUST implement CAR-MIN. MUST implement CAR-MIN.
Implementations MAY implement Implementations MAY implement
CAR-FULL-1. CAR-FULL-1.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
QUERYLEVEL 0 or 1 Indicates level of SQL support. QUERYLEVEL 0 or 1 Indicates level of SQL support.
SQL-MIN or SQL-92. If not SQL-MIN or SQL-92. If not
specified the default is SQL-92. specified the default is SQL-92.
Implementations MUST implement Implementations MUST implement
SQL-MIN. Implementations MAY SQL-MIN. Implementations MAY
implement SQL-92. implement SQL-92.
MAXICALOBJECTSIZE MAXICALOBJECTSIZE
0 or 1 An integer value that specifies 0 or 1 An integer value that specifies
The largest ICAL object the server The largest ICAL object the server
skipping to change at page 47, line 5 skipping to change at page 50, line 20
00000101T000000Z. 00000101T000000Z.
PIPELINE 0 or 1 An integer value that specifies PIPELINE 0 or 1 An integer value that specifies
the maximum number of commands a the maximum number of commands a
CUA may send without the CUA CUA may send without the CUA
waiting for a reply from the CS. waiting for a reply from the CS.
If not specified, the default If not specified, the default
value is one (1). A value of zero value is one (1). A value of zero
(0)indicates unlimited. (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: Example:
C: CAPABILTIY C: CAPABILTIY
S: 2.0 S: 2.0
S: . S: .
S: CAPVERSION=1.0 S: CAPVERSION=1.0
S: ITIPVERSION=1.0 S: ITIPVERSION=1.0
S: AUTH=KERBEROS_V4 S: AUTH=KERBEROS_V4
S: AUTH=DIGEST_MD5 S: AUTH=DIGEST_MD5
S: . S: .
7.1.6 CONTINUE Command 7.1.6 CONTINUE Command
Arguments: latency time in seconds (optional) Arguments: latency time in seconds (optional)
Data: none Data: none
Result: results from the command in progress Result: results from the command in progress 2.0.2 - reply pending.
2.0.2 - reply pending.
The CONTINUE command is issued by the client in response to a The CONTINUE command is issued by the client in response to a SENDATA
SENDATA timeout. When a timeout value is specified on the timeout. When a timeout value is specified on the SENDDATA command,
SENDDATA command, the server must issue a reply to the client the server must issue a reply to the client within the specified
within the specified time. If the latency time has elapsed time. If the latency time has elapsed prior to the server completing
prior to the server completing the command it returns a the command it returns a timeout response code. If the client wants
timeout response code. If the client wants the server to the server to continue processing the command it responds with the
continue processing the command it responds with the CONTINUE CONTINUE command.
command.
If latencyTime is present, it must be a positive integer that If latencyTime is present, it must be a positive integer that
specifies the maximum number of seconds the client will wait specifies the maximum number of seconds the client will wait for the
for the next response. If it is omitted, the receiver waits an next response. If it is omitted, the receiver waits an indefinite
indefinite period of time for the response. 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 In this example, the client requests a response from the server every
server every 10 seconds. 10 seconds.
C: SENDDATA:10 C: SENDDATA:10
C: Content-Type:text/calendar; method=READ; component=VEVENT C: Content-Type:text/calendar; method=READ; component=VEVENT
C: C:
C: BEGIN:VCAP C: BEGIN:VCAP
# etc # etc
C: END:VCAP C: END:VCAP
C: . C: .
# after 10 seconds... # after 10 seconds...
S: . S: .
S: 2.0.2 S: 2.0.2
S: . S: .
S: . S: .
C: CONTINUE:10 C: CONTINUE:10
S: 2.0 S: 2.0
S: . S: .
S: Content-type:text/calendar; S: Content-type:text/calendar;
S: Method=RESPONSE;Component=VDATA; S: Method=RESPONSE;Component=VCAP;
S: Optinfo=VERSION:2.1 S: Optinfo=VERSION:2.1
S: S:
S: BEGIN:VCAP S: BEGIN:VCAP
S: VERSION:2.1 S: VERSION:2.1
S: CALID:cap://cal.example.com/relcal2 S: CALID:cap://cal.example.com/relcal2
# etc. # etc.
S: END:VCAP S: END:VCAP
S: . S: .
7.1.7 DISCONNECT Command 7.1.7 DISCONNECT Command
Arguments: none Arguments: none
Data: Data:
Result: 2.0 Result: 2.0
The DISCONNECT command is used by a client to terminate a The DISCONNECT command is used by a client to terminate a connection.
connection. It always succeeds. It always succeeds.
The CUA MUST wait for the CS 2.0 reply to ensure that TCP/IP The CUA MUST wait for the CS 2.0 reply to ensure that TCP/IP (which
(which knows nothing about CAP) can be sure the connection knows nothing about CAP) can be sure the connection should go away.
should go away. This avoids the CS connection being stuck in This avoids the CS connection being stuck in TCP-WAIT state.
TCP-WAIT state.
Example: Example:
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
C: DISCONNECT C: DISCONNECT
# [ed. Note: should the client now wait for a response from # [EDITORS NOTE: Note: should the client now wait for a response from
the the
server server
# before disconnecting? ] # before disconnecting? ]
S: 2.0 S: 2.0
S: . S: .
S: . S: .
S: <drops connection> S: <drops connection>
C: <drops connection> C: <drops connection>
7.1.8. IDENTIFY Command 7.1.8 IDENTIFY Command
Arguments: Identity to assume Arguments: Identity to assume
Data: None Data: None
Result: 2.0 Result: 2.0 .4 Identity not permitted
.4 Identity not permitted
The "IDENTIFY" command allows the CUA to select a new identity The "IDENTIFY" command allows the CUA to select a new identity to be
to be used for calendar access. This command may only be used for calendar access. This command may only be called in the
called in the Identified State. Identified State.
The CS determines through an internal mechanism if the The CS determines through an internal mechanism if the credentials
credentials supplied at authentication permit the assumption supplied at authentication permit the assumption of the selected the
of the selected the identity. If they do the session assumes identity. If they do the session assumes the new identity, otherwise
the new identity, otherwise a security error is returned. a security error is returned.
7.1.8 SENDDATA Command 7.1.9 SENDDATA Command
Arguments: [latencyTime] Arguments: [latencyTime]
Data: a [MIME] encapsulated iCalendar object Data: a [MIME] encapsulated iCalendar object
Result: 2.0.1 - Server will now accept input until Result: 2.0.1 - Server will now accept input until <CRLF>.<CRLF>
<CRLF>.<CRLF> is encountered. 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 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>
.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 7.1.10 STARTTLS Command
Arguments: None Arguments: None
Data: None Data: None
Result: 2.0 Result: 2.0 5 TLS not supported
5 TLS not supported
The "STARTTLS" command is issued by the CUA to indicate to the The "STARTTLS" command is issued by the CUA to indicate to the CS
CS that it wishes to negotiate transport level security using that it wishes to negotiate transport level security using [TLS]. If
[TLS]. If the CS does not support TLS it returns status code the CS does not support TLS it returns status code 6.5. If the CS
6.5. If the CS supports TLS it issues an initial response of supports TLS it issues an initial response of 2.0.12 indicating that
2.0.12 indicating that the CUA should proceed with TLS the CUA should proceed with TLS negotiation. Once the TLS
negotiation. Once the TLS negotiation is complete the server negotiation is complete the server returns the response code 2.0.
returns the response code 2.0.
After issuing the "STARTTLS" command the CUA issues the After issuing the "STARTTLS" command the CUA issues the
"AUTHENTICATE" command. The SASL external mechanism may be "AUTHENTICATE" command. The SASL external mechanism may be used if
used if the CUA wishes to use the authentication id which was the CUA wishes to use the authentication id which was used in the TLS
used in the TLS negotiation. negotiation.
The CUA MUST NOT issue a "STARTTLS" if it has already issued The CUA MUST NOT issue a "STARTTLS" if it has already issued an
an "AUTHENTICATE" or "STARTTLS" command in this session. If a "AUTHENTICATE" or "STARTTLS" command in this session. If a CUA does
CUA does this the CS must terminate the session. this the CS must terminate the session.
The following examples illustrate the use of the "STARTTLS" The following examples illustrate the use of the "STARTTLS" command:
command:
Unsupported TLS: Unsupported TLS:
C: STARTTLS C: STARTTLS
S: 6.5 S: 6.5
Supported TLS: Supported TLS:
C: STARTTLS C: STARTTLS
S: 2.0.12 S: 2.0.12
<tls negotiation> <tls negotiation>
S: 2.0 S: 2.0
S: . S: .
S: . S: .
7.1.8.1 UPNEXPAND Method 7.1.11 UPNEXPAND Method
Arguments: UPN Arguments: UPN
Data: no specific data for this command Data: no specific data for this command
Result: 2.0 - success 2.1 Permission Denied 2.2 Requested UPN not
found 2.3 Result exceeds MAXUPNEXPANDLIST 2.4 Misc. UPNEXPAND error
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 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.
Result: 2.0 - success If the number of items exceeds MAXUPNEXPANDLIST, then up to
2.1 Permission Denied MAXUPNEXPANDLIST items are returned along with result 2.3.
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 If the result is 2.4, then as many of the items as possible will be
yields one or more CalIDs. More than one CalID returned returned. It is possible that no items will be returned. The 2.4
implies that the UPN was a UG. response may have optional text describing the problem. Any such
text MUST be in the language and charset that is defined by the
calendar store properties LANGUAGE and CHARSET.
If calendar store CHARSET is not set, but the LANGUAGE property is
set, then the error message will be in LANGUAGE in the UTF-8
charset. If calendar store LANGUAGE property is not set, then the
CS MUST NOT return any text with the results.
Example #1: Request lookup of a UPN which is a CU Example #1: Request lookup of a UPN which is a CU
C: UPNEXPAND upn@example.com C: UPNEXPAND upn@example.com
S: 2.0 upn@example.com S: 2.0
S: upn@example.com
S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid3
S: . S: .
Example #2: Request lookup of UPN which is a UG Example #2: Request lookup of UPN which is a UG
C: UPNEXPAND group@example.com C: UPNEXPAND group@example.com
S: 2.0 group@example.com S: 2.0
S: group@example.com
S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid6 S: cap://cal.example.com/calid6
S: cap://cal.example.com/calid1342 S: cap://cal.example.com/calid1342
S: . S: .
Example #3: Request lookup exceeds MAXUPNEXPANDLIST Example #3: Request lookup exceeds MAXUPNEXPANDLIST
C: UPNEXPAND group@example.com C: UPNEXPAND group@example.com
S: 2.0 group@example.com S: 2.3 Lookup resulted in too much data
S: group@example.com
S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid12 S: cap://cal.example.com/calid12
S: cap://cal.example.com/calid21 S: cap://cal.example.com/calid21
S: cap://cal.example.com/calid33 S: cap://cal.example.com/calid33
S: 2.3 Lookup resulted in too much data
S: . S: .
Example #4: CS loses contact with directory server during Example #4: CS loses contact with directory server during UPNEXPAND
UPNEXPAND
C: UPNEXPAND group@example.com C: UPNEXPAND group@example.com
S: 2.0 group@example.com S: group@example.com
S: 2.4 Lost contact with directory server
S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid5 S: cap://cal.example.com/calid5
S: 2.4 Lost contact with directory server
S: . S: .
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 7.1.12 NOOP Command
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.
[EDITORS NOTE: should an unauthenticated and unidentified client be
able to issue this command?]
[EDITORS NOTE: need to add NOOP in the state diagram?]
Example:
C: NOOP
S: 2.0
S: .
7.2 Application Protocol Commands 7.2 Application Protocol Commands
7.2.1 Calendaring Commands 7.2.1 Calendaring Commands
The following methods provide a set of calendaring commands in The following methods provide a set of calendaring commands in CAP.
CAP. Calendaring commands (or methods) allow a CU to directly Calendaring commands (or methods) allow a CU to directly manipulate a
manipulate a calendar. calendar.
Calendar access rights can be granted for the more generalized Calendar access rights can be granted for the more generalized access
access provided by the calendar commands. provided by the calendar commands.
7.2.1.1 Restriction Tables 7.2.1.1 Restriction Tables
Commands are sent to CAP servers encapsulated in iCalendar Commands are sent to CAP servers encapsulated in iCalendar objects.
objects. The reply to these commands are also encapsulated in The reply to these commands are also encapsulated in iCalendar
iCalendar objects. The restriction tables listed in the objects. The restriction tables listed in the commands below
commands below describe the composition of the iCalendar data describe the composition of the iCalendar data for these commands and
for these commands and replies. replies.
The Presence column uses the following values to assert The Presence column uses the following values to assert whether a
whether a property is required, is optional and the number of property is required, is optional and the number of times it may
times it may appear in the iCalendar object. A Comment may be appear in the iCalendar object. A Comment may be provided to further
provided to further clarify the presence criteria. clarify the presence criteria.
The table below defines the values for the Presence column. The table below defines the values for the Presence column.
Presence Value Description Presence Value Description
-------------------------------------------------------------- --------------------------------------------------------------
1 One instance MUST be present 1 One instance MUST be present
1+ At least one instance MUST be present 1+ At least one instance MUST be present
0 Instances of this property Must NOT be present 0 Instances of this property Must NOT be present
0+ Multiple instances MAY be present 0+ Multiple instances MAY be present
0 or 1 Up to 1 instance of this property 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 While the tables list every component and property, their purpose is
purpose is not to define the meaning of the component or not to define the meaning of the component or property.
property.
There will be a REQUEST-STATUS for each VCALENDAR and
component created, modified, deleted, or requested. The number
of 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.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 There will be a REQUEST-STATUS for each VCALENDAR and component
created, modified, deleted, or requested. The number of 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.2 CREATE Method 7.2.1.2 CREATE Method
Arguments: none Arguments: none
Data: no specific data for this command Data: no specific data for this command
Result: 2.0 - successfully created the component or calendar Result:
2.0 - successfully created the component or calendar
6.0 - Permission denied 6.0 - Permission denied
6.1 - Container(s) not found 6.1 - Container(s) not found
6.2 - Calendar or component already exists 6.2 - Calendar or component already exists
6.3 -
Bad args
The CREATE method is used to create a new iCalendar object of 6.3 - Bad args
type objtype. The property TARGET specifies the container(s)
for the create. The type of object wrapped inside of the The CREATE method is used to create a new iCalendar object of type
VCALENDAR/CREATE object is the object type(s) being created. objtype. The property TARGET specifies the container(s) for the
When creating a new calendar at the top level, the CSID is create. The type of object wrapped inside of the VCALENDAR/CREATE
specified. Otherwise the container will be a CalID. 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 Restriction table
Component/Property Presence Comment Component/Property Presence Comment
------------------- -------- ----------------------------- ------------------- -------- -----------------------------
VCAP 1+ The CUA can send up VCAP 1+ The CUA can send up
PIPELINE commands PIPELINE commands
without processing a without processing a
response response
skipping to change at page 54, line 4 skipping to change at page 57, line 42
then there must not be then there must not be
pending replies to previous pending replies to previous
command. command.
. . [IANA-PROP] 0+ any IANA registered . . [IANA-PROP] 0+ any IANA registered
property property
. . METHOD 1 MUST be CREATE. . . METHOD 1 MUST be CREATE.
. . TARGET 1+ MUST be the CSID or CALID . . TARGET 1+ MUST be the CSID or CALID
. . VCALENDAR 0+ . . VCALENDAR 0+
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . CALMASTER 0 or 1 . . . CALMASTER 0 or 1
. . . NAME 0 or 1 . . . NAME 0 or 1
. . . OWNER 1+ . . . OWNER 1+
. . . RELCALID 1 . . . RELCALID 1
. . . TZID 0 or 1 . . . TZID 0 or 1
. . . [IANA-PROP] 0+ any IANA registered . . . [IANA-PROP] 0+ any IANA registered
property property
. . VCAR 0+ . . VCAR 0+
. . . CARID 0 or 1 . . . CARID 0 or 1
skipping to change at page 55, line 4 skipping to change at page 58, line 43
. . . COMMENT 0 or 1 . . . COMMENT 0 or 1
. . . CONTACT 0+ . . . CONTACT 0+
. . . CREATED 0 or 1 . . . CREATED 0 or 1
. . . DESCRIPTION 0 or 1 Can be null . . . DESCRIPTION 0 or 1 Can be null
. . . DTEND 0 or 1 if present DURATION MUST . . . DTEND 0 or 1 if present DURATION MUST
NOT be present NOT be present
. . . DTSTAMP 1 . . . DTSTAMP 1
. . . DTSTART 1 . . . DTSTART 1
. . . DURATION 0 or 1 if present DTEND MUST NOT . . . DURATION 0 or 1 if present DTEND MUST NOT
be present be present
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . EXDATE 0+ . . . EXDATE 0+
. . . EXRULE 0+ . . . EXRULE 0+
. . . GEO 0 or 1 . . . GEO 0 or 1
. . . LAST-MODIFIED 0 or 1 . . . LAST-MODIFIED 0 or 1
. . . LOCATION 0 or 1 . . . LOCATION 0 or 1
. . . METHOD 1 <<placeholder. it may move . . . METHOD 1 <<placeholder. it may move
to meta-info>> to meta-info>>
. . . ORGANIZER 1 . . . ORGANIZER 1
. . . PRIORITY 0 or 1 . . . PRIORITY 0 or 1
. . . RDATE 0+ . . . RDATE 0+
skipping to change at page 56, line 4 skipping to change at page 59, line 43
. . . . SUMMARY 0 or 1 . . . . SUMMARY 0 or 1
. . . . TRIGGER 1 . . . . TRIGGER 1
. . . . X-PROPERTY 0+ . . . . X-PROPERTY 0+
. . . . [IANA-PROP] 0+ any IANA registered property . . . . [IANA-PROP] 0+ any IANA registered property
. . VTODO 0+ . . VTODO 0+
. . . ATTENDEE 0+ . . . ATTENDEE 0+
. . . SEQUENCE 0 or 1 MUST be present if value is . . . SEQUENCE 0 or 1 MUST be present if value is
greater than 0, MAY be greater than 0, MAY be
present if 0 present if 0
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . SUMMARY 1 Can be null. . . . SUMMARY 1 Can be null.
. . . UID 1 . . . UID 1
. . . ATTACH 0+ . . . ATTACH 0+
. . . CATEGORIES 0 or 1 This property may contain a . . . CATEGORIES 0 or 1 This property may contain a
list of values list of values
. . . CLASS 0 or 1 . . . CLASS 0 or 1
. . . COMMENT 0 or 1 . . . COMMENT 0 or 1
. . . CONTACT 0+ . . . CONTACT 0+
. . . CREATED 0 or 1 . . . CREATED 0 or 1
skipping to change at page 57, line 4 skipping to change at page 60, line 45
NEEDS-ACTION, NEEDS-ACTION,
IN-PROCESS, CANCELLED IN-PROCESS, CANCELLED
. . . URL 0 or 1 . . . URL 0 or 1
. . . X-PROPERTY 0+ . . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered property . . . [IANA-PROP] 0+ any IANA registered property
. . . VALARM 0+ . . . VALARM 0+
. . . . ACTION 1 . . . . ACTION 1
. . . . ALARMID 0 or 1 MUST be 1 if multiple . . . . ALARMID 0 or 1 MUST be 1 if multiple
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
VALARMs are present in VALARMs are present in
same component. same component.
. . . . ATTACH 0+ . . . . ATTACH 0+
. . . . DESCRIPTION 0 or 1 . . . . DESCRIPTION 0 or 1
. . . . DURATION 0 or 1 if present REPEAT MUST be . . . . DURATION 0 or 1 if present REPEAT MUST be
present present
. . . . REPEAT 0 or 1 if present DURATION MUST be . . . . REPEAT 0 or 1 if present DURATION MUST be
present present
. . . . SUMMARY 0 or 1 . . . . SUMMARY 0 or 1
. . . . TRIGGER 1 . . . . TRIGGER 1
skipping to change at page 58, line 4 skipping to change at page 61, line 45
present. present.
. . . RELATED-TO 0+ . . . RELATED-TO 0+
. . . RRULE 0+ . . . RRULE 0+
. . . SEQUENCE 0 or 1 MUST be present if . . . SEQUENCE 0 or 1 MUST be present if
non-zero. MAY be non-zero. MAY be
present if zero. present if zero.
. . . STATUS 0 or 1 . . . STATUS 0 or 1
. . . SUMMARY 0 or 1 Can be null . . . SUMMARY 0 or 1 Can be null
. . . URL 0 or 1 . . . URL 0 or 1
. . . X-PROPERTY 0+ . . . X-PROPERTY 0+
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . [IANA-PROP] 0+ any IANA registered . . . [IANA-PROP] 0+ any IANA registered
property property
. . VFREEBUSY 0 . . VFREEBUSY 0
. . VTIMEZONE 0+ MUST be present if any . . VTIMEZONE 0+ MUST be present if any
date/time refers to a date/time refers to a
timezone timezone
. . . DAYLIGHT 0+ MUST be one or more of . . . DAYLIGHT 0+ MUST be one or more of
either STANDARD or either STANDARD or
DAYLIGHT DAYLIGHT
. . . . . COMMENT 0 or 1 . . . . . COMMENT 0 or 1
. . . . . DTSTART 1 . . . . . DTSTART 1
. . . . . RDATE 0+ if present RRULE MUST NOT . . . . . RDATE 0+ if present RRULE MUST NOT
be present be present
skipping to change at page 59, line 5 skipping to change at page 62, line 46
. . . TZID 1 . . . TZID 1
. . . TZURL 0 or 1 . . . TZURL 0 or 1
. . . X-PROPERTY 0+ . . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered property . . . [IANA-PROP] 0+ any IANA registered property
Server Restriction Table for the CREATE command Server Restriction Table for the CREATE command
Component/Property Presence Comment Component/Property Presence Comment
------------------- -------- ------------------------------- ------------------- -------- -------------------------------
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
VCAP 1+ VCAP 1+
. VCALENDAR 1+ . VCALENDAR 1+
. . TARGET 1 . . TARGET 1
. . VERSION 1 MUST be 2.0 . . VERSION 1 MUST be 2.0
. . CMDID 0 or 1 MUST be returned if the . . CMDID 0 or 1 MUST be returned if the
request contained request contained
a CMDID a CMDID
. . REQUEST-STATUS 0 if not creating a calendar . . REQUEST-STATUS 0 if not creating a calendar
1+ if creating a calendar 1+ if creating a calendar
. . . VCAR 0+ . . . VCAR 0+
. . . . REQUEST-STATUS 1+ . . . . REQUEST-STATUS 1+
. . . . * 0 No other VCAR properties . . . . * 0 No other VCAR properties
are present are present
skipping to change at page 60, line 5 skipping to change at page 63, line 47
. . . VQUERY 0+ . . . VQUERY 0+
. . . . REQUEST-STATUS 1+ . . . . REQUEST-STATUS 1+
. . . . * 0 No other VQUERY properties . . . . * 0 No other VQUERY properties
are present are present
. . . VTODO 0+ . . . VTODO 0+
. . . . REQUEST-STATUS 1+ . . . . REQUEST-STATUS 1+
. . . . * 0 No other VTODO properties . . . . * 0 No other VTODO properties
are present are present
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . . VALARM 0 if VTODO was successfully . . . . VALARM 0 if VTODO was successfully
saved saved
1+ if there were errors saving 1+ if there were errors saving
alarms alarms
. . . . . REQUEST-STATUS 1+ . . . . . REQUEST-STATUS 1+
7.2.1.2.1 Creating New Calendars 7.2.1.2.1 Creating New Calendars
Example to create two new calendars different containers. In Example to create two new calendars different containers. In the
the following example, the client is in the Authenticated following example, the client is in the Authenticated state with CS
state with CS cal.example.com. cal.example.com.
C: SENDDATA C: SENDDATA
C: CONTENT-TYPE: text/calendar; method=CREATE; C: CONTENT-TYPE: text/calendar; method=CREATE;
C: component=VCOMMAND C: component=VCOMMAND
C: Content-Transfer-Encoding:7bit C: Content-Transfer-Encoding:7bit
C: C:
C: BEGIN:VCAP C: BEGIN:VCAP
C: VERSION:2.1 C: VERSION:2.1
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: METHOD:CREATE C: METHOD:CREATE
skipping to change at page 61, line 4 skipping to change at page 64, line 47
C: OWNER:mary C: OWNER:mary
C: CALMASTER:mailto:mary@example.com C: CALMASTER:mailto:mary@example.com
C: TZID:US_PST C: TZID:US_PST
C: BEGIN:VCAR C: BEGIN:VCAR
C: CARID:12346 C: CARID:12346
C: GRANT:UPN=mary;ACTION=*;OBJECT=* C: GRANT:UPN=mary;ACTION=*;OBJECT=*
C: END:VCAR C: END:VCAR
C: END:VCALENDAR C: END:VCALENDAR
C: END:VCOMMAND C: END:VCOMMAND
C: END:VCAP C: END:VCAP
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
C: . C: .
S: 2.0 S: 2.0
S: Content-Type:text/calendar; method=RESPONSE; S: Content-Type:text/calendar; method=RESPONSE;
S: OPTINFO="CMDID:abcde" S: OPTINFO="CMDID:abcde"
# This 2.0 is the transport reply status and ends with a # This 2.0 is the transport reply status and ends with a
# CRLF.CRLF (below) # CRLF.CRLF (below)
S: BEGIN:VCAP S: BEGIN:VCAP
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: TARGET:cap://cal.example.com/ S: TARGET:cap://cal.example.com/
S: REQUEST-STATUS:2.0 S: REQUEST-STATUS:2.0
skipping to change at page 62, line 4 skipping to change at page 65, line 46
C: END:VCOMMAND C: END:VCOMMAND
C: END:VCAP C: END:VCAP
C: . C: .
S: 2.0 S: 2.0
S: Content-Type:text/calendar; method=RESPONSE; S: Content-Type:text/calendar; method=RESPONSE;
S: OPTINFO="CMDID:abcde" S: OPTINFO="CMDID:abcde"
S: S:
S: BEGIN:VCAP S: BEGIN:VCAP
S: VERSION:2.1 S: VERSION:2.1
S: CMDID:abcde S: CMDID:abcde
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: TARGET::cap://cal.example.com/relcal1 S: TARGET::cap://cal.example.com/relcal1
S: REQUEST-STATUS:2.9 S: REQUEST-STATUS:2.9
S: END:VEVENT S: END:VEVENT
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: REQUEST-STATUS:2.9 S: REQUEST-STATUS:2.9
S: REQUEST-STATUS:2.10 S: REQUEST-STATUS:2.10
S: END:VEVENT S: END:VEVENT
S: END:VCAP S: END:VCAP
S: . S: .
The response contains the calendar (CALID) and UID of the The response contains the calendar (CALID) and UID of the component
component so that the CUA can match up the TARGET from so that the CUA can match up the TARGET from multiple objects created
multiple objects created on multiple calendards (TARGETs). on multiple calendards (TARGETs).
7.2.1.2.2 Creating a new VQUERY
This example creates a stored VQUERY that selects all unprocessed
scheduling entries. QUERYNAME must not exist in the TARGET
calendar.
C: SENDDATA
C: Content-Type:text/calendar; method=CREATE; charset=US-ASCII
C: Content-Transfer-Encoding:7bit
C:
C: BEGIN:VCAP
C: VERSION:2.1
C: CMDID:abcde-2
C: METHOD:CREATE
C: TARGET:cap://cal.example.com/relcal1
C: BEGIN:VQUERY
C: BEGIN:VQUERY
C: QUERYNAME:GetAlliTIPinQueue
C: QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD != 'CREATE'
C: END:VQUERY
C: END:VEVENT
C: END:VCAP
C: .
S: 2.0
S: Content-Type:text/calendar; method=RESPONSE; OPTINFO="CMDID:abcde"
S:
S: BEGIN:VCAP
S: CMDID:abcde-2
S: METHOD:RESPONSE
S: TARGET::cap://cal.example.com/relcal1
S: BEGIN:VQUERY
S: REQUEST-STATUS:2.0;
S: END:VQUERY
S: END:VCAP
S: .
[EDITORS NOTE - can return QUERYNAME already exists error]
7.2.1.3 DELETE Method 7.2.1.3 DELETE Method
Arguments: none Arguments: none
Data: no specific data for this command Data: no specific data for this command
Result: 2.0 - successfully deleted the component or calendar Result:
2.0 - successfully deleted the component or calendar
Permission Permission
Calendar or component not found Calendar or component not found
Bad args Bad args
Container(s) not found Container(s) not found
The DELETE method is used to delete a calendar or component. The DELETE method is used to delete a calendar or component. The
The TARGET properties specify the container(s) for the delete. TARGET properties specify the container(s) for the delete. When
When deleting a calendar at the top level, the CSID is deleting a calendar at the top level, the CSID is specified.
specified. Otherwise the container will be a CalID. Otherwise the container will be a CalID.
Restriction Table Restriction Table
Component/Property Presence Comment Component/Property Presence Comment
------------------- -------- --------------------------- ------------------- -------- ---------------------------
VCAP 1+ The CUA can send up VCAP 1+ The CUA can send up
PIPELINE commands PIPELINE commands
without processing a without processing a
response response
VERSION 1 MUST be 2.0 VERSION 1 MUST be 2.0
VCOMMAND 1 VCOMMAND 1
CMDID 0 or 1 If CMDID is not supplied, CMDID 0 or 1 If CMDID is not supplied,
then there must then there must
not be pending replies to not be pending replies to
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
previous command. previous command.
METHOD 1 MUST be DELETE. METHOD 1 MUST be DELETE.
TARGET 1+ MUST be a the CSID or CALID TARGET 1+ MUST be a the CSID or CALID
VQUERY 0+ VQUERY 0+
EXPAND 0 ? EXPAND 0 ?
MAXRESULTS 0 or 1 Limit the solution set to MAXRESULTS 0 or 1 Limit the solution set to
no more than this many no more than this many
entries. entries.
MAXSIZE 0 ? MAXSIZE 0 ?
QUERYNAME 1 Name by which this query is QUERYNAME 1 Name by which this query is
referenced referenced
QUERY 1 The query QUERY 1 The query
Server Restriction Table for the DELETE command Server Restriction Table for the DELETE command
Component/Property Presence Comment Component/Property Presence Comment
------------------- -------- ----------------------------- ------------------- -------- -----------------------------
skipping to change at page 64, line 5 skipping to change at page 68, line 45
VCAR 0+ Only if VCAR components were VCAR 0+ Only if VCAR components were
deleted deleted
REQUEST-STATUS 1 REQUEST-STATUS 1
* 0 No other VCAR properties are * 0 No other VCAR properties are
present present
VEVENT 0+ Only if VEVENT components VEVENT 0+ Only if VEVENT components
were deleted were deleted
REQUEST-STATUS 1+ REQUEST-STATUS 1+
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
* 0 No other VEVENT properties * 0 No other VEVENT properties
are present are present
VFREEBUSY 0 VFREEBUSY 0
REQUEST-STATUS 1+ REQUEST-STATUS 1+
* 0 No other VFREEBUSY properties * 0 No other VFREEBUSY properties
are present are present
VJOURNAL 0+ Only if VJOURNAL components VJOURNAL 0+ Only if VJOURNAL components
were deleted were deleted
REQUEST-STATUS 1+ REQUEST-STATUS 1+
* 0 No other VJOURNAL properties * 0 No other VJOURNAL properties
are present are present
VQUERY 0+ Only if VQUERY components VQUERY 0+ Only if VQUERY components
were deleted were deleted
REQUEST-STATUS 1+ REQUEST-STATUS 1+
* 0 No other VQUERY properties * 0 No other VQUERY properties
skipping to change at page 64, line 41 skipping to change at page 69, line 30
are present are present
VTODO 0+ Only if VTODO components were VTODO 0+ Only if VTODO components were
deleted deleted
REQUEST-STATUS 1+ REQUEST-STATUS 1+
* 0 No other VTODO properties are * 0 No other VTODO properties are
present present
---------------------------------------------------------- ----------------------------------------------------------
[Editors note: Issues: [EDITORS NOTE: Issues:
- Currently CAP requires that the server return a response - Currently CAP requires that the server return a response status.
status. However, if there are multiple components deleted, However, if there are multiple components deleted, should the UID
should the UID also be returned? also be returned?
- VQUERY EXPAND and MAXSIZE parameters do not seem to apply to - VQUERY EXPAND and MAXSIZE parameters do not seem to apply to
deletion? deletion?
- Can one use DELETE to remove all VALARMs and VTIMEZONEs that - Can one use DELETE to remove all VALARMs and VTIMEZONEs that
match a certain search criteria and that belong to all match a certain search criteria and that belong to all components,
components, event though VALARMs and VTIMEZONEs never exist as event though VALARMs and VTIMEZONEs never exist as independent
independent components? Or should one use MODIFY? If they can components? Or should one use MODIFY? If they can be deleted, do
we return the REQUEST-STATUS of their deletion in a VEVENT or
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 separately?
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 - In the example in CAP where a calendar is deleted all the server
server returns is 2.0, nothing else? returns is 2.0, nothing else?
- We should not be able to delete any VFREEBUSY components? - We should not be able to delete any VFREEBUSY components?
- Can we delete multiple calendars? - Can we delete multiple calendars?
- Currently one can not delete a VCALENDAR and some other - Currently one can not delete a VCALENDAR and some other
component in the same DELETE command. This seems OK. Anyone component in the same DELETE command. This seems OK. Anyone see
see any need to be able to do this? any need to be able to do this?
- Should the MAXRESULTS property of VQUERY apply to deletion? - Should the MAXRESULTS property of VQUERY apply to deletion? We
We can use it to delete only the first n components that can use it to delete only the first n components that match. ]
match.
]
Example to delete a VEVENT with UID 'abcd12345': Example to delete a VEVENT with UID 'abcd12345':
C: SENDDATA C: SENDDATA
C: Content-Type:text/calendar; method=DELETE; C: Content-Type:text/calendar; method=DELETE;
component=VCOMMAND component=VCOMMAND
C: Content-Transfer-Encoding:7bit C: Content-Transfer-Encoding:7bit
C: C:
C: BEGIN:VCAP C: BEGIN:VCAP
skipping to change at page 66, line 4 skipping to change at page 70, line 42
S: Content-Type:text/calendar; method=DELETE; S: Content-Type:text/calendar; method=DELETE;
S: component=VCOMMAND S: component=VCOMMAND
S: S:
S: BEGIN:VCAP S: BEGIN:VCAP
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: REQUEST-STATUS:2.0 S: REQUEST-STATUS:2.0
S: END:VEVENT S: END:VEVENT
S: END:VCAP S: END:VCAP
S: . S: .
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
And an example to delete the 'MrBill' calendar:
C: SENDDATA C: SENDDATA
C: Content-Type:text/calendar; method=DELETE; C: Content-Type:text/calendar; method=DELETE;
C: component=VCOMMAND C: component=VCOMMAND
C: Content-Transfer-Encoding:7bit C: Content-Transfer-Encoding:7bit
C: C:
C: BEGIN:VCAP C: BEGIN:VCAP
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: METHOD:DELETE C: METHOD:DELETE
C: TARGET:cap://cal.foo.com/MrBill C: TARGET:cap://cal.foo.com/MrBill
C: END:VCOMMAND C: END:VCOMMAND
skipping to change at page 66, line 32 skipping to change at page 71, line 17
S: . S: .
7.2.1.4 GENERATEUID Method 7.2.1.4 GENERATEUID Method
Arguments: Number of UIDs to generate. Arguments: Number of UIDs to generate.
Data: new uids Data: new uids
Result: 2.0 Result: 2.0
GENERATEUID returns one or more new unique identifier which GENERATEUID returns one or more new unique identifier which MUST be
MUST be unique on the server's calendar store. It is unique on the server's calendar store. It is recommended that the
recommended that the return value be a globally unique id. return value be a globally unique id.
Example: Example:
C: GENERATEUID 2 C: GENERATEUID 2
S: 2.0
S: abcde1234567-asdf-lkhh
S: abcde1234567-asdf-3455
S: .
S: 2.0 abcde1234567-asdf-lkhh abcde1234567-asdf-3455 [EDITORS NOTE: this example needs work. It's not packaged right]
[EDITORS NOTE: this example needs work. It's not packaged
right]
7.2.1.5 MODIFY Method 7.2.1.5 MODIFY Method
Arguments: none Arguments: none
Data: no specific data for this command Data: no specific data for this command
Result: 2.0 - successfully modified the component or Result:
calendar
Permission
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 2.0 - successfully modified the component or calendar
Permission
Calendar or component not found Calendar or component not found
Bad args Bad args
Container(s) not found Container(s) not found
The MODIFY method is used to change an existing calendar or The MODIFY method is used to change an existing calendar or
component. TARGET specify the container(s) of the component. TARGET specify the container(s) of the modification.
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 When modifying a calendar at the top level, the CSID is specified.
a VCOMMAND container: Otherwise the container will be a CalID.
The format of the request is two or three containers inside of a
VCOMMAND container:
BEGIN:VCOMMAND BEGIN:VCOMMAND
[VQUERY] [VQUERY]
OLD-VALUES OLD-VALUES
NEW-VALUES NEW-VALUES
END:VCOMMAND END:VCOMMAND
If a VQUERY is present, then only objects matching the query If a VQUERY is present, then only objects matching the query results
results are modified. are modified.
Restriction Table Restriction Table
Component/Property Presence Comment Component/Property Presence Comment
------------------- -------- --------------------------- ------------------- -------- ---------------------------
VCAP 1+ The CUA can send up VCAP 1+ The CUA can send up
PIPELINE commands PIPELINE commands
without processing a without processing a
response response
skipping to change at page 68, line 4 skipping to change at page 72, line 47
. . CMDID 0 or 1 If CMDID is not supplied, . . CMDID 0 or 1 If CMDID is not supplied,
then there must then there must
not be pending replies to not be pending replies to
previous command. previous command.
. . [IANA-PROP] 0+ any IANA registered . . [IANA-PROP] 0+ any IANA registered
property property
. . METHOD 1 MUST be MODIFY . . METHOD 1 MUST be MODIFY
. . TARGET 1+ MUST be the CALID . . TARGET 1+ MUST be the CALID
. . VCALENDAR 0+ . . VCALENDAR 0+
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . CALMASTER 0 or 1 . . . CALMASTER 0 or 1
. . . NAME 0 or 1 . . . NAME 0 or 1
. . . OWNER 1+ . . . OWNER 1+
. . . RELCALID 1 . . . RELCALID 1
. . . TZID 0 or 1 . . . TZID 0 or 1
. . . [IANA-PROP] 0+ any IANA registered . . . [IANA-PROP] 0+ any IANA registered
property property
. . VCAR 0+ . . VCAR 0+
. . . CARID 0 or 1 . . . CARID 0 or 1
skipping to change at page 69, line 4 skipping to change at page 73, line 48
. . . COMMENT 0 or 1 . . . COMMENT 0 or 1
. . . CONTACT 0+ . . . CONTACT 0+
. . . CREATED 0 or 1 . . . CREATED 0 or 1
. . . DESCRIPTION 0 or 1 Can be null . . . DESCRIPTION 0 or 1 Can be null
. . . DTEND 0 or 1 if present DURATION MUST . . . DTEND 0 or 1 if present DURATION MUST
NOT be present NOT be present
. . . DTSTAMP 1 . . . DTSTAMP 1
. . . DTSTART 1 . . . DTSTART 1
. . . DURATION 0 or 1 if present DTEND MUST NOT . . . DURATION 0 or 1 if present DTEND MUST NOT
be present be present
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . EXDATE 0+ . . . EXDATE 0+
. . . EXRULE 0+ . . . EXRULE 0+
. . . GEO 0 or 1 . . . GEO 0 or 1
. . . LAST-MODIFIED 0 or 1 . . . LAST-MODIFIED 0 or 1
. . . LOCATION 0 or 1 . . . LOCATION 0 or 1
. . . METHOD 1 <<placeholder. it may move . . . METHOD 1 <<placeholder. it may move
to meta-info>> to meta-info>>
. . . ORGANIZER 1 . . . ORGANIZER 1
. . . PRIORITY 0 or 1 . . . PRIORITY 0 or 1
. . . RDATE 0+ . . . RDATE 0+
skipping to change at page 70, line 4 skipping to change at page 74, line 48
. . . . SUMMARY 0 or 1 . . . . SUMMARY 0 or 1
. . . . TRIGGER 1 . . . . TRIGGER 1
. . . . X-PROPERTY 0+ . . . . X-PROPERTY 0+
. . . . [IANA-PROP] 0+ any IANA registered . . . . [IANA-PROP] 0+ any IANA registered
property property
. . VTODO 0+ . . VTODO 0+
. . . ATTENDEE 0+ . . . ATTENDEE 0+
. . . SEQUENCE 0 or 1 MUST be present if value is . . . SEQUENCE 0 or 1 MUST be present if value is
greater than 0, MAY be greater than 0, MAY be
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
present if 0 present if 0
. . . SUMMARY 1 Can be null. . . . SUMMARY 1 Can be null.
. . . UID 1 . . . UID 1
. . . ATTACH 0+ . . . ATTACH 0+
. . . CATEGORIES 0 or 1 This property may contain a . . . CATEGORIES 0 or 1 This property may contain a
list of values list of values
. . . CLASS 0 or 1 . . . CLASS 0 or 1
. . . COMMENT 0 or 1 . . . COMMENT 0 or 1
. . . CONTACT 0+ . . . CONTACT 0+
. . . CREATED 0 or 1 . . . CREATED 0 or 1
. . . DESCRIPTION 0 or 1 Can be null . . . DESCRIPTION 0 or 1 Can be null
. . . DTSTAMP 1 . . . DTSTAMP 1
. . . DTSTART 1 . . . DTSTART 1
skipping to change at page 71, line 4 skipping to change at page 75, line 49
. . . STATUS 0 or 1 MAY be one of COMPLETED, . . . STATUS 0 or 1 MAY be one of COMPLETED,
NEEDS-ACTION, NEEDS-ACTION,
IN-PROCESS, CANCELLED IN-PROCESS, CANCELLED
. . . URL 0 or 1 . . . URL 0 or 1
. . . X-PROPERTY 0+ . . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered . . . [IANA-PROP] 0+ any IANA registered
property property
. . . VALARM 0+ . . . VALARM 0+
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . . ACTION 1 . . . . ACTION 1
. . . . ALARMID 0 or 1 MUST be 1 if multiple . . . . ALARMID 0 or 1 MUST be 1 if multiple
VALARMs are present in VALARMs are present in
same component. same component.
. . . . ATTACH 0+ . . . . ATTACH 0+
. . . . DESCRIPTION 0 or 1 . . . . DESCRIPTION 0 or 1
. . . . DURATION 0 or 1 if present REPEAT MUST be . . . . DURATION 0 or 1 if present REPEAT MUST be
present present
. . . . REPEAT 0 or 1 if present DURATION MUST be . . . . REPEAT 0 or 1 if present DURATION MUST be
present present
skipping to change at page 72, line 5 skipping to change at page 76, line 50
an instance of a recurring an instance of a recurring
calendar component. calendar component.
Otherwise it MUST NOT be Otherwise it MUST NOT be
present. present.
. . . RELATED-TO 0+ . . . RELATED-TO 0+
. . . RRULE 0+ . . . RRULE 0+
. . . SEQUENCE 0 or 1 MUST be present if non- . . . SEQUENCE 0 or 1 MUST be present if non-
zero. MAY be zero. MAY be
. . . . . present if zero. . . . . . present if zero.
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . STATUS 0 or 1 . . . STATUS 0 or 1
. . . SUMMARY 0 or 1 Can be null . . . SUMMARY 0 or 1 Can be null
. . . URL 0 or 1 . . . URL 0 or 1
. . . X-PROPERTY 0+ . . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered . . . [IANA-PROP] 0+ any IANA registered
property property
. . VFREEBUSY 0 . . VFREEBUSY 0
. . VTIMEZONE 0+ MUST be present if any . . VTIMEZONE 0+ MUST be present if any
skipping to change at page 73, line 4 skipping to change at page 78, line 4
. . . . . TZOFFSETFROM 1 . . . . . TZOFFSETFROM 1
. . . . . TZOFFSETTO 1 . . . . . TZOFFSETTO 1
. . . . . X-PROPERTY 0+ . . . . . X-PROPERTY 0+
. . . . . [IANA-PROP] 0+ any IANA registered . . . . . [IANA-PROP] 0+ any IANA registered
property property
. . . TZID 1 . . . TZID 1
. . . TZURL 0 or 1 . . . TZURL 0 or 1
. . . X-PROPERTY 0+ . . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered . . . [IANA-PROP] 0+ any IANA registered
property property
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
Server Restriction Table for the MODIFY command Server Restriction Table for the MODIFY command
Component/Property Presence Comment Component/Property Presence Comment
--------------------- -------- -------------------------- --------------------- -------- --------------------------
VCAP 1+ VCAP 1+
. VCALENDAR 1+ . VCALENDAR 1+
. . TARGET 1 . . TARGET 1
. . VERSION 1 MUST be 2.0 . . VERSION 1 MUST be 2.0
skipping to change at page 74, line 4 skipping to change at page 79, line 4
properties are properties are
present present
. . . VJOURNAL 0+ . . . VJOURNAL 0+
. . . . REQUEST-STATUS 1+ . . . . REQUEST-STATUS 1+
. . . . * 0 No other VJOURNAL properties . . . . * 0 No other VJOURNAL properties
are present are present
. . . VQUERY 0+ . . . VQUERY 0+
. . . . REQUEST-STATUS 1+ . . . . REQUEST-STATUS 1+
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. . . . * 0 No other VQUERY properties . . . . * 0 No other VQUERY properties
are present are present
. . . VTODO 0+ . . . VTODO 0+
. . . . REQUEST-STATUS 1+ . . . . REQUEST-STATUS 1+
. . . . * 0 No other VTODO properties . . . . * 0 No other VTODO properties
are present are present
. . . . VALARM 0 if VTODO was successfully . . . . VALARM 0 if VTODO was successfully
saved saved
1+ if there were errors saving 1+ if there were errors saving
alarms alarms
. . . . . REQUEST-STATUS 1+ . . . . . REQUEST-STATUS 1+
[EditorĖs notes: Issues: [EDITORS NOTES: Issues: freebusy - a cap server should dynamically
freebusy - a cap server should dynamically calculate freebusy calculate freebusy information we recommend that you cannot create,
information we recommend that you cannot create, modify, or modify, or delete freebusy composers ]
delete freebusy composers ]
In the example below, the start and end time of the event with In the example below, the start and end time of the event with UID
UID abcd12345 is changed and the LOCATION property is removed. abcd12345 is changed and the LOCATION property is removed.
C: SENDDATA C: SENDDATA
C: Content-type:text/calendar; Method=MODIFY; C: Content-type:text/calendar; Method=MODIFY;
C: Component=VCOMMAND C: Component=VCOMMAND
C: C:
C: BEGIN:VCAP C: BEGIN:VCAP
C: VERSION:2.1 C: VERSION:2.1
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: METHOD:MODIFY C: METHOD:MODIFY
C: TARGET:relcal2 C: TARGET:relcal2
skipping to change at page 75, line 5 skipping to change at page 80, line 5
C: END:VEVENT C: END:VEVENT
C: BEGIN:VEVENT C: BEGIN:VEVENT
C: DTSTART:19990421T160000Z C: DTSTART:19990421T160000Z
C: DTEND:19990421T163000Z C: DTEND:19990421T163000Z
C: END:VEVENT C: END:VEVENT
C: END:VCOMMAND C: END:VCOMMAND
C: END:VCAP C: END:VCAP
C: . C: .
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
S: 2.0 cap://cal.example.com/relcal2 S: 2.0 cap://cal.example.com/relcal2
And in this example, all instances of "Building 6" are And in this example, all instances of "Building 6" are replaced by
replaced by "New office lobby" in VEVENTs: "New office lobby" in VEVENTs:
C: SENDDATA C: SENDDATA
C: Content-type:text/calendar; Method=MODIFY; C: Content-type:text/calendar; Method=MODIFY;
C: Component=VCOMMAND C: Component=VCOMMAND
C: C:
C: BEGIN:VCAP C: BEGIN:VCAP
C: VERSION:2.1 C: VERSION:2.1
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: METHOD:MODIFY C: METHOD:MODIFY
C: TARGET:relcal2 C: TARGET:relcal2
skipping to change at page 75, line 40 skipping to change at page 80, line 38
C: END:VCAP C: END:VCAP
C: . C: .
S: 2.0 cap://cal.example.com/relcal2 S: 2.0 cap://cal.example.com/relcal2
7.2.1.6 MOVE Method 7.2.1.6 MOVE Method
Arguments: ContainerId Arguments: ContainerId
Data: data as described below Data: data as described below
Result: 2.0 - success Result:
2.2 - will attempt operation on the remote CAP
server 2.0 - success
2.2 - will attempt operation on the remote CAP server
Permission Permission
Calendar already exists Calendar already exists
Bad args Bad args
Parent Calendar(s) not found Parent Calendar(s) not found
The format of the command is:
This method is used to move a calendar within the CS's BEGIN:VCALENDAR
hierarchy of calendars. METHOD:MOVE
...
TARGET:target-name
BEGIN:VCOMMAND
BEGIN:VCALENDAR
PARENT:<old-parent>
END:VCALENDAR
BEGIN:VCALENDAR
PARENT:<new-parent>
END:VCALENDAR
END:VCOMMAND
END:VCALENDAR
This looks similar to a MODIFY command. Except the CS MUST ensure
that VCARs are still valid after the move. And the CS MUST update
the CHILDREN list in the new and old parent containers.
This method is used to move a calendar within the CS's hierarchy of
calendars.
Restriction Table Restriction Table
Component/Property Presence Comment Component/Property Presence Comment
------------------- -------- --------------------- ------------------- -------- ---------------------
VCAP 1+ The CUA can send up VCAP 1+ The CUA can send up
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
PIPELINE commands without PIPELINE commands without
processing a response processing a response
. VERSION 1 MUST be 2.0 . VERSION 1 MUST be 2.0
. VCOMMAND 1 MUST have at least one . VCOMMAND 1 MUST have at least one
VCALENDAR VCALENDAR
. . CMDID 0 or 1 If CMDID is not supplied, . . CMDID 0 or 1 If CMDID is not supplied,
then there must not be then there must not be
skipping to change at page 77, line 5 skipping to change at page 82, line 32
. . TARGET 1 . . TARGET 1
. . VERSION 1 MUST be 2.0 . . VERSION 1 MUST be 2.0
. . CMDID 0 or 1 MUST be returned if the . . CMDID 0 or 1 MUST be returned if the
request contained request contained
a CMDID a CMDID
. . REQUEST-STATUS 1+ . . REQUEST-STATUS 1+
--------------------------------------------------------- ---------------------------------------------------------
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 [EDITORS NOTE: Issues:
[Editors note: Issues: 1) Should one be able to move a calendar owned by person X into a
1) Should one be able to move a calendar owned by person X calendar owned by person Y. (Can these such rights be specified
into a calendar owned by person Y. (Can these such rights be in VCARs?)
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.7 NOOP Method 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.)
Arguments: none 3) There was very little information about MOVE in CAP. Why was
it added? Was there some major need for it?
Data: none 4) Can one move multiple calendars into one calendar?]
Result: 2.0 - success An example of moving a calendar from Nellis to Area-51
This method does nothing. It can be sent to the server C: SENDDATA
periodically to request that the CS not time out the session. C: Content-type:text/calendar; Method=MODIFY; Component=VCOMMAND
C:
C: BEGIN:VCAP
C: VERSION:2.1
C: METHOD:MOVE
C: TARGET:Nellis
C: BEGIN:VCOMMAND
C: BEGIN:VCALENDAR
C: PARENT:Department-33
C: END:VCALENDAR
C: BEGIN:CALENDAR
C: PARENT:Area-51
C: END:VCALENDAR
C: END:VCOMMAND
C: END:VCAP
C: .
S: 2.0
S: Content-Type:text/calendar; method=RESPONSE
S:
S: BEGIN:VCAP
S: METHOD:RESPONSE
S: TARGET:relcal2
S: BEGIN:VCALENDAR
S: REQUEST-STATUS:2.0;
S: END:VCALENDAR
S: END:VCAP
S: .
7.2.1.8 READ Method 7.2.1.7 READ Method
Arguments: ContainerId Arguments: ContainerId
Data: data as described below Data: data as described below
Result: 2.0 - Result:
- successful and the requested data follows
2.0 - - successful and the requested data follows
2.2 - will attempt read on the remote CAP server 2.2 - will attempt read on the remote CAP server
Permission Permission
Bad args Bad args
Restriction Table Restriction Table
Component/Property Presence Comment Component/Property Presence Comment
------------------- -------- --------------------------- ------------------- -------- ---------------------------
VCAP 1+ The CUA can send VCAP 1+ The CUA can send
PIPELINE commands PIPELINE commands
without processing a without processing a
response response
skipping to change at page 78, line 5 skipping to change at page 84, line 13
------------------- -------- --------------------------- ------------------- -------- ---------------------------
VCAP 1+ The CUA can send VCAP 1+ The CUA can send
PIPELINE commands PIPELINE commands
without processing a without processing a
response response
. VERSION 1 MUST be 2.0 . VERSION 1 MUST be 2.0
. [IANA-PROP] 0+ any IANA registered . [IANA-PROP] 0+ any IANA registered
property property
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
. VCOMMAND 1 MUST have at least one . VCOMMAND 1 MUST have at least one
container (VCALENDAR, container (VCALENDAR,
VCAR, VQUERY, VEVENT, VCAR, VQUERY, VEVENT,
VTODO, VJOURNAL) VTODO, VJOURNAL)
. . CMDID 0 or 1 If CMDID is not supplied, . . CMDID 0 or 1 If CMDID is not supplied,
then there must not be pending then there must not be pending
replies to previous command. replies to previous command.
. . [IANA-PROP] 0+ any IANA registered . . [IANA-PROP] 0+ any IANA registered
property property
. . METHOD 1 MUST be READ . . METHOD 1 MUST be READ
skipping to change at page 79, line 5 skipping to change at page 85, line 15
to a timezone to a timezone
. . . DAYLIGHT 0+ MUST be one or more of . . . DAYLIGHT 0+ MUST be one or more of
either STANDARD either STANDARD
or DAYLIGHT or DAYLIGHT
. . . . . COMMENT 0 or 1 . . . . . COMMENT 0 or 1
. . . . . DTSTART 1 . . . . . DTSTART 1
. . . . . RDATE 0+ if present RRULE MUST NOT . . . . . RDATE 0+ if present RRULE MUST NOT
be present be present
. . . . . RRULE 0+ if present RDATE MUST NOT . . . . . RRULE 0+ if present RDATE MUST NOT
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
be present be present
. . . . . TZNAME 0 or 1 . . . . . TZNAME 0 or 1
. . . . . TZOFFSET 1 . . . . . TZOFFSET 1
. . . . . TZOFFSETFROM 1 . . . . . TZOFFSETFROM 1
. . . . . TZOFFSETTO 1 . . . . . TZOFFSETTO 1
. . . . . X-PROPERTY 0+ . . . . . X-PROPERTY 0+
. . . . . [IANA-PROP] 0+ any IANA registered . . . . . [IANA-PROP] 0+ any IANA registered
property property
. . . LAST-MODIFIED 0 or 1 . . . LAST-MODIFIED 0 or 1
. . . STANDARD 0+ . . . STANDARD 0+
skipping to change at page 80, line 5 skipping to change at page 86, line 15
. . CMDID 0 or 1 MUST be returned if the . . CMDID 0 or 1 MUST be returned if the
request contained a CMDID request contained a CMDID
. . REQUEST-STATUS 0 if not creating a calendar . . REQUEST-STATUS 0 if not creating a calendar
1+ if creating a calendar 1+ if creating a calendar
. . . VCAR 0+ . . . VCAR 0+
. . . . REQUEST-STATUS 1+ . . . . REQUEST-STATUS 1+
. . . . * 0 No other VCAR properties are . . . . * 0 No other VCAR properties are
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
present present
. .
. . . VCOMMAND 0 . . . VCOMMAND 0
. . . VEVENT 0+ . . . VEVENT 0+
. . . . REQUEST-STATUS 1+ . . . . REQUEST-STATUS 1+
. . . . * 0 No other VEVENT properties . . . . * 0 No other VEVENT properties
are present are present
. . . . VALARM 0 if VEVENT was successfully . . . . VALARM 0 if VEVENT was successfully
saved saved
skipping to change at page 80, line 49 skipping to change at page 87, line 10
. . . . * 0 No other VTODO properties . . . . * 0 No other VTODO properties
are present are present
. . . . VALARM 0 if VTODO was successfully . . . . VALARM 0 if VTODO was successfully
saved saved
1+ if there were errors saving 1+ if there were errors saving
alarms alarms
. . . . . REQUEST-STATUS 1+ . . . . . REQUEST-STATUS 1+
Read Events Read Events
In the example below events on March 10,1999 between 080000Z In the example below events on March 10,1999 between 080000Z and
and 190000Z are read. In this case only 4 properties for each 190000Z are read. In this case only 4 properties for each event are
event are returned. Two calendars are specified. Only booked returned. Two calendars are specified. Only booked (vs scheduled)
(vs scheduled) entries are to be returned. The first returns entries are to be returned. The first returns two VEVENTS that match
in that TARGET, the second result returns only one VEVENT for the
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 second TARGET.
two VEVENTS that match in that TARGET, the second result
returns only one VEVENT for the second TARGET.
C: SENDDATA C: SENDDATA
C: Content-type:text/calendar; Method=READ; Component=VQUERY C: Content-type:text/calendar; Method=READ; Component=VQUERY
C: C:
C: BEGIN:VCAP C: BEGIN:VCAP
C: VERSION:2.1 C: VERSION:2.1
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: METHOD:READ C: METHOD:READ
C: CMDID:xyz12345 C: CMDID:xyz12345
C: TARGET:relcal2 C: TARGET:relcal2
skipping to change at page 81, line 55 skipping to change at page 88, line 14
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: DTSTART:19990310T130000Z S: DTSTART:19990310T130000Z
S: DTEND:19990310T133000Z S: DTEND:19990310T133000Z
S: UID:abcxyz8999 S: UID:abcxyz8999
S: SUMMARY:Meet with brave brave Sir Robin S: SUMMARY:Meet with brave brave Sir Robin
S: END:VEVENT S: END:VEVENT
S: END:VCAP S: END:VCAP
S: . S: .
S: 2.0 cap://bobo.ex.com/relcal3 S: 2.0 cap://bobo.ex.com/relcal3
S: Content-type:text/calendar; Method=RESPONSE; S: Content-type:text/calendar; Method=RESPONSE;
S: Component=VDATA; Optinfo=VERSION:2.1 S: Optinfo=VERSION:2.1
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCAP S: BEGIN:VCAP
S: VERSION:2.1 S: VERSION:2.1
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: BEGIN:VDATA
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: DTSTART:19990310T140000Z S: DTSTART:19990310T140000Z
S: DTEND:19990310T150000Z S: DTEND:19990310T150000Z
S: UID:123456asdf S: UID:123456asdf
S: SUMMARY:Summer Budget S: SUMMARY:Summer Budget
S: END:VEVENT S: END:VEVENT
S: END:VDATA
S: END:VCAP S: END:VCAP
S: . S: .
The return values are subject to VCAR filtering. That is, if The return values are subject to VCAR filtering. That is, if the
the request contains properties to which the UPN does not have request contains properties to which the UPN does not have access,
access, those properties will not appear in the return values. those properties will not appear in the return values. If the UPN
If the UPN has access to at least one property of events, but has access to at least one property of events, but has been denied
has been denied access to all properties called out in the access to all properties called out in the request, the response will
request, the response will contain a single REQUEST-STATUS contain a single REQUEST-STATUS property indicating the error. That
property indicating the error. That is, the VEVENT is, the VEVENT components will be the following:
components will be the following:
[EDITORS NOTE: Should the one(s) that the UPN has access to [EDITORS NOTE: Should the one(s) that the UPN has access to - be
- be
returned?] returned?]
S: 2.0 cap://bobo.ex.com/sally S: 2.0 cap://bobo.ex.com/sally
S: Content-type:text/calendar; S: Content-type:text/calendar;
Method=RESPONSE;Component=VDATA; Method=RESPONSE;
S: Optinfo=VERSION:2.1 S: Optinfo=VERSION:2.1
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCAP S: BEGIN:VCAP
S: VERSION:2.1 S: VERSION:2.1
S: BEGIN:VDATA
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: REQUEST-STATUS:3.8 S: REQUEST-STATUS:3.8
S: END:VEVENT S: END:VEVENT
S: END:VDATA
S: END:VCAP S: END:VCAP
S: . S: .
If the UPN has no access to any events at all, the response If the UPN has no access to any events at all, the response will
will simply be an empty data set. The response looks the same simply be an empty data set. The response looks the same if there
are particular events to which the requester has been denied access.
<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: 2.0 cap://bobo.ex.com/sally
S: Content-type:text/calendar; Method=RESPONSE; S: Content-type:text/calendar; Method=RESPONSE;
S: Component=VDATA;
S: Optinfo=VERSION:2.1 S: Optinfo=VERSION:2.1
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCAP S: BEGIN:VCAP
S: VERSION:2.1 S: VERSION:2.1
S: BEGIN:VDATA
S: END:VDATA
S: END:VCAP S: END:VCAP
S: . S: .
Find alarms within a range of time for booked (METHOD = Find alarms within a range of time for booked (METHOD = CREATE)
CREATE) VEVENTs. VEVENTs.
C: SENDDATA C: SENDDATA
C: Content-type:text/calendar; Method=READ; Component=VQUERY C: Content-type:text/calendar; Method=READ; Component=VQUERY
C: C:
C: BEGIN:VCAP C: BEGIN:VCAP
C: VERSION:2.1 C: VERSION:2.1
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: METHOD:READ C: METHOD:READ
C: CMDID:xyz12345 C: CMDID:xyz12345
C: TARGET:relcal2 C: TARGET:relcal2
skipping to change at page 84, line 4 skipping to change at page 90, line 5
S: 2.0 cap://bobo.ex.com/relcal3 S: 2.0 cap://bobo.ex.com/relcal3
S: Content-type:text/calendar; Method=RESPONSE; S: Content-type:text/calendar; Method=RESPONSE;
S: Optinfo=VERSION:2.1 S: Optinfo=VERSION:2.1
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCAP S: BEGIN:VCAP
S: VERSION:2.1 S: VERSION:2.1
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: CMDID:xyz12345 S: CMDID:xyz12345
S: TARGET:cap://bobo.ex.com/relcal3 S: TARGET:cap://bobo.ex.com/relcal3
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: DTSTART:19990310T130000Z S: DTSTART:19990310T130000Z
S: DTEND:19990310T133000Z S: DTEND:19990310T133000Z
S: UID:abcxyz8999 S: UID:abcxyz8999
S: SUMMARY:Meet with brave brave Sir Robin S: SUMMARY:Meet with brave brave Sir Robin
S: BEGIN:VALARM S: BEGIN:VALARM
S: TRIGGER:19990310T132500Z S: TRIGGER:19990310T132500Z
S: SUMMARY:Almost time.. S: SUMMARY:Almost time..
S: ACTION:DISPLAY S: ACTION:DISPLAY
skipping to change at page 84, line 37 skipping to change at page 90, line 35
S: VERSION:2.1 S: VERSION:2.1
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: CMDID:xyz12345 S: CMDID:xyz12345
S: TARGET:cap://bobo.ex.com/relcal2 S: TARGET:cap://bobo.ex.com/relcal2
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: REQUEST-STATUS:2.0 S: REQUEST-STATUS:2.0
S: END:VEVENT S: END:VEVENT
S: END:VCAP S: END:VCAP
S: . S: .
7.2.2 Scheduling Commands 7.2.1.7.1 Query With A Stored Query
The following provide a set of scheduling commands (or This will run a stored VQUERY and return the results of the
methods) in CAP. Scheduling commands allow a CU to indirectly VQUERY.
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 BEGIN:VQUERY
without granting rights for more generalized access with the QUERYNAME:StoredVQuery-1
calendar commands. END:VQUERY
[EDITORS NOTE: This section needs to be completed by adding This will fetch all calendar store properties. This MUST NOT
the restriction tables for each of these iTIP methods. The return any VCALENDARs.
basis for the text is to be taken from [iTIP].]
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 BEGIN:VCAP
VERSION:2.1
METHOD:READ
CMDID:-2ir-
TARGET:cap://bobo.ex.com
BEGIN:VQUERY
QUERY:SELECT * FROM CALSTORE
END:VQUERY
END:VCAP
This will fetch all calendar properties. This MUST NOT return any
components.
BEGIN:VCAP
VERSION:2.1
METHOD:READ
CMDID:-2ir-
TARGET:cap://bobo.ex.com/relcal4
BEGIN:VQUERY
QUERY:SELECT * FROM VCALENDAR
END:VQUERY
END:VCAP
This will fetch all stored VQUERYs.
BEGIN:VCAP
VERSION:2.1
METHOD:READ
CMDID:didmc
TARGET:cap://bobo.ex.com/relcal4
BEGIN:VQUERY
QUERY:SELECT * FROM VQUERY
END:VQUERY
END:VCAP
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 Scheduling Components 7.2.2.1 Reading Scheduling Components
A CU might be invited to a meeting. If the CU had been invited A CU might be invited to a meeting. If the CU had been invited by
by CAP, the entry in the CU calendar will be scheduled, but CAP, the entry in the CU calendar will be scheduled, but not booked.
not booked. So a CUA will need to look for scheduled entries So a CUA will need to look for scheduled entries in the calendar and
in the calendar and present them to the CU or automaticly present them to the CU or automaticly decide if the invitation is to
decide if the invitation is to be accepted or processed. be accepted or processed.
Example: Example:
The little league coach places the teams entire schedule into The little league coach places the teams entire schedule into your
your calendar. Lets say that every game and practice is on a calendar. Lets say that every game and practice is on a Friday night
Friday night and your calendar now has this iTIP scheduling and your calendar now has this iTIP scheduling data:
data:
BEGIN:VCAP BEGIN:VCAP
VERSION:2.0 VERSION:2.0
METHOD:PUBLISH METHOD:PUBLISH
BEGIN:VEVENT BEGIN:VEVENT
DTSTAMP;TZID=US/Pacific:20000229T180000 DTSTAMP;TZID=US/Pacific:20000229T180000
DTSTART;TZID=US/Pacific:20000303T180000 DTSTART;TZID=US/Pacific:20000303T180000
ORGANIZER:coach@little.league.com ORGANIZER:coach@little.league.com
SUMMARY: Schedule of games and practice SUMMARY: Schedule of games and practice
UID:1-coach@little.league.com UID:1-coach@little.league.com
SEQUENCE:0 SEQUENCE:0
DESCRIPTION:Please have your child at the field DESCRIPTION:Please have your child at the field
and ready to play by 6pm. and ready to play by 6pm.
RRULE:FREQ=WEEKLY;COUNT=10 RRULE:FREQ=WEEKLY;COUNT=10
END:VEVENT END:VEVENT
END:VCAP END:VCAP
At this point the above VEVENT is not booked in your calendar, At this point the above VEVENT is not booked in your calendar, It is
It is simply scheduled. A CUA would fetch this and all other simply scheduled. A CUA would fetch this and all other scheduled
scheduled VEVENTs from your calendar with: VEVENTs from your calendar with:
C: SENDDATA C: SENDDATA
C: Content-type:text/calendar; Method=READ; Component=VQUERY C: Content-type:text/calendar; Method=READ; Component=VQUERY
C: C:
C: BEGIN:VCAP C: BEGIN:VCAP
C: VERSION:2.1 C: VERSION:2.1
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: METHOD:READ C: METHOD:READ
C: CMDID:xyz12345 C: CMDID:xyz12345
C: TARGET:relcal2 C: TARGET:relcal2
C: BEGIN:VQUERY C: BEGIN:VQUERY
C: QUERY:SELECT * WHERE FROM VEVENT METHOD != 'CREATE' C: QUERY:SELECT * WHERE FROM VEVENT METHOD != 'CREATE'
C: END:VQUERY C: END:VQUERY
C: END:VCOMMAND C: END:VCOMMAND
C: END:VCAP C: END:VCAP
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
C: . C: .
The the CUA and CU could determine which scheduling items were The the CUA and CU could determine which scheduling items were to
to remain on the calendar. Each scheduling component could be remain on the calendar. Each scheduling component could be deleted
deleted or updated with METHOD:MODIFY to change the METHOD or updated with METHOD:MODIFY to change the METHOD from PUBLISH,
from PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINE-COUNTER to
or DECLINE-COUNTER to what the CU and CUA had decided. what the CU and CUA had decided.
In some cases the CUA could automaticly do the work and inform In some cases the CUA could automaticly do the work and inform the
the CU. An example of this is CANCEL. If configured to process CU. An example of this is CANCEL. If configured to process
METHOD:CANCEL it could METHOD:DELETE the component an inform METHOD:CANCEL it could METHOD:DELETE the component an inform the CU
the CU that the booked component had been canceled. that the booked component had been canceled.
The CUA MUST process the scheduled components in the order The CUA MUST process the scheduled components in the order sent.
sent. Some optimization could be done by the CUA. One example Some optimization could be done by the CUA. One example is if a
is if a PUBLISH and later a CANCEL for the same component with PUBLISH and later a CANCEL for the same component with the same
the same SEQUENCE number were scheduled, but not booked. The SEQUENCE number were scheduled, but not booked. The CUA might never
CUA might never inform the CU and treat it as if the PUBLISH inform the CU and treat it as if the PUBLISH had never been received
had never been received by doing a METHOD:DELETE on both by doing a METHOD:DELETE on both entries.
entries.
It is important to note that scheduled components do not show It is important to note that scheduled components do not show up in
up in busy time as BUSY. Only when they are booked does the busy time as BUSY. Only when they are booked does the TRANSP:OPAQUE
TRANSP:OPAQUE property take effect. A CS implementation MAY property take effect. A CS implementation MAY mark the time as
mark the time as TENTATIVE. This is an implementation and TENTATIVE. This is an implementation and administrative choice.
administrative choice.
7.2.2.2 PUBLISH 7.2.2.2 PUBLISH
Arguments: Arguments:
Data: data as described below Data: data as described below
Result: 2.0 - success Result:
2.2 - will attempt operation on the remote CAP
server 2.0 - success
2.2 - will attempt operation on the remote CAP server
Permission Permission
Calendar already exists Calendar already exists
Bad args Bad args
Parent Calendar(s) not found
This method is used to move a calendar within the CS's Parent Calendar(s) not found
hierarchy of calendars. If the CU wishes to keep the published
entry. A METHOD:MODIFY changing the entries METHOD from
PUBLISH to 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 If the CU wishes to keep the published entry. A METHOD:MODIFY
changing the entries METHOD from PUBLISH to CREATE would be done,
booking the entry. Or METHOD:DELETE if the CU did not wish this
scheduled item to exist in their calendar.
7.2.2.3 REQUEST 7.2.2.3 REQUEST
Arguments: Arguments:
Data: data as described below Data: data as described below
Result: 2.0 - success Result:
2.2 - will attempt operation on the remote CAP
server 2.0 - success
2.2 - will attempt operation on the remote CAP server
Permission Permission
Calendar already exists Calendar already exists
Bad args Bad args
Parent Calendar(s) not found Parent Calendar(s) not found
This as described in [iTIP] and would be modified just like This as described in [iTIP] and would be modified just like PUBLISH
PUBLISH above. above.
7.2.2.4 REPLY 7.2.2.4 REPLY
Arguments: Arguments:
Data: data as described below Data: data as described below
Result: 2.0 - success Result:
2.2 - will attempt operation on the remote CAP
server 2.0 - success
2.2 - will attempt operation on the remote CAP server
Permission Permission
Calendar already exists Calendar already exists
Bad args Bad args
Parent Calendar(s) not found Parent Calendar(s) not found
7.2.2.5 ADD 7.2.2.5 ADD
Arguments: Arguments:
Data: data as described below Data: data as described below
Result: 2.0 - success Result:
2.2 - will attempt operation on the remote CAP
server 2.0 - success
2.2 - will attempt operation on the remote CAP server
Permission Permission
Calendar already exists Calendar already exists
Bad args Bad args
Parent Calendar(s) not found
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001 Parent Calendar(s) not found
7.2.2.6 CANCEL 7.2.2.6 CANCEL
Arguments: Arguments:
Data: data as described below Data: data as described below
Result: 2.0 - success Result:
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 7.2.2.7 REFRESH
Arguments: Arguments:
Data: data as described below Data: data as described below
Result: 2.0 - success Result:
2.2 - will attempt operation on the remote CAP
server This as described in [iTIP] and would be modified just like PUBLISH
Permission above. The CS MAY automaticly send out REFRESH replies via iMIP or
Calendar already exists CAP if able, then METHOD:DELETE the REFRESH. But only if there are
Bad args no other pending scheduled entries for this calendar that may effect
Parent Calendar(s) not found what REFRESH would send back. If the CS is not able to reply to the
REFRESH request then it is left in the scheduling queue until the
CUA and CU processes the queue. At the point where there are no
outstanding scheduled command that would effect the reply results,
the CS may then automaticly send the reply to the REFRESH request.
7.2.2.8 COUNTER 7.2.2.8 COUNTER
Arguments: Arguments:
Data: data as described below Data: data as described below
Result: 2.0 - success Result:
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 7.2.2.9 DECLINECOUNTER
Arguments: Arguments:
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
Data: data as described below Data: data as described below
Result: 2.0 - success Result:
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 7.2.3 iTIP Examples
The following examples describe scenarios for the handling of The following examples describe scenarios for the handling of
incoming iTIP data. An appropriate sort-order for the handling incoming iTIP data. An appropriate sort-order for the handling of
of incoming iTIP is by UID, Recurrence-id, sequence, dtstamp. incoming iTIP is by UID, Recurrence-id, sequence, dtstamp. This
This processing may be optimized, for instance, REFRESHs could processing may be optimized, for instance, REFRESHs could be
be processed last. processed last.
As an update to [iTIP], data with the "COUNTER" method should As an update to [iTIP], data with the "COUNTER" method should be
be processed even if the Sequence number is stale. processed even if the Sequence number is stale.
7.2.3.1 Sending and Receiving an iTIP request 7.2.3.1 Sending and Receiving an iTIP request
In this example A invites B and C to a meeting, B accepts the In this example A invites B and C to a meeting, B accepts the meeting
meeting and C rejects it. The calendars for A, B and C are and C rejects it. The calendars for A, B and C are relcal1, relcal2
relcal1, relcal2 and relcal3 respectively, and are all on the and relcal3 respectively, and are all on the same server,
same server, "cal.foo.com". A lot of these described actions "cal.foo.com". A lot of these described actions are performed by the
are performed by the CUAs and not the users themselves, the CUAs and not the users themselves, the CUAs are called A-c, B-c and
CUAs are called A-c, B-c and C-c respectively. C-c respectively.
A wishes to create a meeting with B and C, so A-c uses CAP to A wishes to create a meeting with B and C, so A-c uses CAP to send
send the following iTIP request to relcal2 and relcal3, while the following iTIP request to relcal2 and relcal3, while logged in to
logged in to "cal.foo.com". "cal.foo.com".
BEGIN:VCAP BEGIN:VCAP
VERSION:2.1 VERSION:2.1
CMDID:xhj-dd CMDID:xhj-dd
BEGIN:VCOMMAND BEGIN:VCOMMAND
METHOD:REQUEST METHOD:REQUEST
TARGET:cap://cal.foo.com/relcal2 TARGET:cap://cal.foo.com/relcal2
TARGET:relcal3 TARGET:relcal3
BEGIN:VEVENT BEGIN:VEVENT
UID:abcd12345 UID:abcd12345
DTSTART:19990307T180000Z DTSTART:19990307T180000Z
DTEND:19990307T190000Z DTEND:19990307T190000Z
ORGANIZER:cap://cal.foo.com/relcal1 ORGANIZER:cap://cal.foo.com/relcal1
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ACTION:cap://cal.foo.com/relcal2 ACTION:cap://cal.foo.com/relcal2
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS- ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ACTION:cap://cal.foo.com/relcal3 ACTION:cap://cal.foo.com/relcal3
SUMMARY:Important Meeting SUMMARY:Important Meeting
END:VEVENT END:VEVENT
END:VCOMMAND END:VCOMMAND
END:VCAP END:VCAP
An incoming event (indicated by the value of the "METHOD" An incoming event (indicated by the value of the "METHOD" property)
property) then appears in relcal2 and relcal3, with the then appears in relcal2 and relcal3, with the following data:
following data:
BEGIN:VEVENT BEGIN:VEVENT
METHOD:REQUEST METHOD:REQUEST
UID:abcd12345 UID:abcd12345
DTSTART:19990307T180000Z DTSTART:19990307T180000Z
DTEND:19990307T190000Z DTEND:19990307T190000Z
ORGANIZER:cap://cal.foo.com/relcal1 ORGANIZER:cap://cal.foo.com/relcal1
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c
om/relcal2 om/relcal2
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.c
om/relcal3 om/relcal3
SUMMARY:Important Meeting SUMMARY:Important Meeting
END:VEVENT END:VEVENT
B-c and C-c must search for such incoming events, they do so B-c and C-c must search for such incoming events, they do so using
using the following CAP search: the following CAP search:
BEGIN:VCAP BEGIN:VCAP
VERSION:2.1 VERSION:2.1
BEGIN:VCOMMAND BEGIN:VCOMMAND
METHOD:READ METHOD:READ
CMDID:xhr-de CMDID:xhr-de
TARGET:relcal2 TARGET:relcal2
# or TARGET:relcal3 # or TARGET:relcal3
BEGIN:VCOMMAND BEGIN:VCOMMAND
BEGIN:VQUERY BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST'; QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST';
END:VQUERY END:VQUERY
END:VCOMMAND END:VCOMMAND
END:VCOMMAND END:VCOMMAND
END:VCAP END:VCAP
In response to this search they get the above event. B-c and In response to this search they get the above event. B-c and C-c
C-c must then crack open the VEVENT, find the UID and must then crack open the VEVENT, find the UID and determine if there
determine if there is already an event on their calendar with is already an event on their calendar with that UID. To do this they
that UID. To do this they use the following search: use the following search:
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
BEGIN:VCAP BEGIN:VCAP
VERSION:2.1 VERSION:2.1
BEGIN:VCOMMAND BEGIN:VCOMMAND
METHOD:READ METHOD:READ
CMDID:xhr-df CMDID:xhr-df
TARGET:relcal2 TARGET:relcal2
BEGIN:VCOMMAND BEGIN:VCOMMAND
BEGIN:VQUERY BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' AND QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' AND
METHOD = 'CREATE' METHOD = 'CREATE'
END:VQUERY END:VQUERY
END:VCOMMAND END:VCOMMAND
END:VCOMMAND END:VCOMMAND
END:VCAP END:VCAP
We assume that the event is not already in their relcal2 or We assume that the event is not already in their relcal2 or relcal3.
relcal3.
B-c prompts B who decides to accept the meeting request, and B-c prompts B who decides to accept the meeting request, and B-c
B-c creates a copy of the event in relcal2, with the creates a copy of the event in relcal2, with the "PARTSTAT" parameter
"PARTSTAT" parameter set to ACCEPTED. B-c also sends this copy set to ACCEPTED. B-c also sends this copy to the Organizer at
to the Organizer at relcal1 as an iTIP REPLY, preserving the relcal1 as an iTIP REPLY, preserving the CMDID:
CMDID:
BEGIN:VCAP BEGIN:VCAP
VERSION:2.1 VERSION:2.1
CMDID:xhj-dd CMDID:xhj-dd
METHOD:REPLY METHOD:REPLY
TARGET:cap://cal.foo.com/relcal1 TARGET:cap://cal.foo.com/relcal1
BEGIN:VEVENT BEGIN:VEVENT
UID:abcd12345 UID:abcd12345
DTSTART:19990307T180000Z DTSTART:19990307T180000Z
DTEND:19990307T190000Z DTEND:19990307T190000Z
ORGANIZER:cap://cal.foo.com/relcal1 ORGANIZER:cap://cal.foo.com/relcal1
ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2
SUMMARY:Important Meeting SUMMARY:Important Meeting
END:VEVENT END:VEVENT
END:VCAP END:VCAP
C, on the other hand, decides to decline the meeting, and C-c C, on the other hand, decides to decline the meeting, and C-c sends a
sends a reply to the Organizer to that effect, as follows: reply to the Organizer to that effect, as follows:
BEGIN:VCALENDAR BEGIN:VCAP
VERSION:2.1 VERSION:2.1
CMDID:xhj-dd CMDID:xhj-dd
METHOD:REPLY METHOD:REPLY
TARGET:cap://cal.foo.com/relcal1 TARGET:cap://cal.foo.com/relcal1
BEGIN:VEVENT BEGIN:VEVENT
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
UID:abcd12345 UID:abcd12345
DTSTART:19990307T180000Z DTSTART:19990307T180000Z
DTEND:19990307T190000Z DTEND:19990307T190000Z
ORGANIZER:cap://cal.foo.com/relcal1 ORGANIZER:cap://cal.foo.com/relcal1
ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
SUMMARY:Important Meeting SUMMARY:Important Meeting
END:VEVENT END:VEVENT
END:VCALENDAR END:VCAP
It is preferable that C-c store the event in relcal3 even It is preferable that C-c store the event in relcal3 even though it
though it has been declined. Storing the event in relcal3 has been declined. Storing the event in relcal3 allows subsequent
allows subsequent iTIP messages to be interpreted correctly. iTIP messages to be interpreted correctly. The "PARTSTAT" parameter
The "PARTSTAT" parameter indicates that the event was refused. indicates that the event was refused.
After receiving the replies from relcal2 and relcal3, A-c After receiving the replies from relcal2 and relcal3, A-c updates the
updates the version of the event in relcal1 to indicate the version of the event in relcal1 to indicate the new participation
new participation status: status:
BEGIN:VEVENT BEGIN:VEVENT
METHOD:REQUEST METHOD:REQUEST
UID:abcd12345 UID:abcd12345
DTSTART:19990307T180000Z DTSTART:19990307T180000Z
DTEND:19990307T190000Z DTEND:19990307T190000Z
ORGANIZER:cap://cal.foo.com/relcal1 ORGANIZER:cap://cal.foo.com/relcal1
ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2
ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
SUMMARY:Important Meeting SUMMARY:Important Meeting
END:VEVENT END:VEVENT
A-c then sends a new iTIP request to relcal2 only, indicating A-c then sends a new iTIP request to relcal2 only, indicating the
the updated information. updated information.
7.2.3.2 Handling an iTIP refresh 7.2.3.2 Handling an iTIP refresh
A little bit later, C is thinking about accepting the event in A little bit later, C is thinking about accepting the event in the
the previous example, but first wants to check the current previous example, but first wants to check the current state of the
state of the event. To find the current state C-c uses the event. To find the current state C-c uses the iTIP "REFRESH" method,
iTIP "REFRESH" method, sending the following to relcal1: sending the following to relcal1:
BEGIN:VCALENDAR BEGIN:VCAP
VERSION:2.1 VERSION:2.1
CMDID:xud-pn CMDID:xud-pn
METHOD:REFRESH METHOD:REFRESH
TARGET:cap://cal.foo.com/relcal1 TARGET:cap://cal.foo.com/relcal1
BEGIN:VEVENT BEGIN:VEVENT
UID:abcd12345 UID:abcd12345
ORGANIZER:cap://cal.foo.com/relcal1 ORGANIZER:cap://cal.foo.com/relcal1
ATTENDEE:cap://cal.foo.com/relcal3 ATTENDEE:cap://cal.foo.com/relcal3
<draft-ietf-calsch-cap-04.txt> CAP Expires September 2001
DTSTAMP:19990306T202333Z DTSTAMP:19990306T202333Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCAP
A-c finds the refresh as an incoming iTIP, and searches for A-c finds the refresh as an incoming iTIP, and searches for the
the corresponding event. Having found the event (with no corresponding event. Having found the event (with no changes since
changes since the last example) A-c then verifies that relcal3 the last example) A-c then verifies that relcal3 is in fact an
is in fact an Attendee of the event and is thus allowed to Attendee of the event and is thus allowed to request a refresh. (In
request a refresh. (In the case of a published event things the case of a published event things are more complicated.) A-c
are more complicated.) A-c pa