draft-ietf-calsch-cap-02.txt   draft-ietf-calsch-cap-03.txt 
Network Working Group Steve Mansour/Netscape Network Working Group Steve Mansour/Netscape
Internet Draft Frank Dawson/Lotus Internet Draft Doug Royer
<draft-ietf-calsch-cap-02.txt> Doug Royer/Software.com <draft-ietf-calsch-cap-03.txt> George Babics/Steltor
Alexander Taler/CS&T
Paul Hill/MIT Paul Hill/MIT
Expires six months from: March 10, 2000
Calendar Access Protocol (CAP) Calendar Access Protocol (CAP)
Status of this Memo Status of this Memo
This memo is an Internet-Draft and is in full conformance with all This memo is an Internet-Draft and is in full conformance
provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet
Force (IETF), its areas, and its working groups. Note that other Engineering Task Force (IETF), its areas, and its working
groups may also distribute working documents as Internet-Drafts. groups. Note that other groups may also distribute working
Internet-Drafts are draft documents valid for a maximum of six months documents as Internet-Drafts. Internet-Drafts are draft
and may be updated, replaced, or obsoleted by other documents at any documents valid for a maximum of six months and may be
time. It is inappropriate to use Internet- Drafts as reference updated, replaced, or obsoleted by other documents at any
material or to cite them other than as "work in progress." time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt . http://www.ietf.org/ietf/1id-abstracts.txt .
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be
http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Distribution of this document is unlimited.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society 2000. All Rights Reserved. Copyright (C) The Internet Society 2000. All Rights
Reserved.
Abstract Abstract
The Calendar Access Protocol (CAP) is an Internet protocol that The Calendar Access Protocol (CAP) is an Internet protocol
permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to that permits a Calendar User (CU) to utilize a Calendar User
access an [RFC2445] based Calendar Store (CS). This memo defines the Agent (CUA) to access an [iCAL] based Calendar Store (CS).
CAP specification. This memo defines the CAP specification.
The CAP definition is based on requirements identified by the Internet
Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH)
Working Group. More information about the IETF CALSCH Working Group
activities can be found on the IMC web site at
http://www.imc.org/ietf-calendar, and at the IETF web site at
Mansour/Dawson/Royer/Taler/Hill 1 Expires September 2000
http://www.ietf.org/html.charters/calsch-charter.html. Refer to the
references within this memo for further information on how to access
these various documents.
Mansour/Dawson/Royer/Taler/Hill 2 Expires September 2000
Table of Contents
1. Introduction ................................................... 3
1.1. Formatting Conventions ....................................... 3
1.2. Related Documents ............................................ 3
1.3. Definitions .................................................. 4
2. CAP Design ..................................................... 10
2.1. System Model ................................................. 10
2.2. Calendar Store Object Model .................................. 11
2.3. Protocol Model ............................................... 11
2.4. Security Model ............................................... 13
2.4.1. Authentication, Credentials, and Identity .................. 14
2.4.2. Calendar User and UPNs ..................................... 14
2.4.2.1. UPNs and Certificates .................................... 15
2.4.2.2. Anonymous Users and Authentication ....................... 16
2.4.2.3. Required Security Mechanisms ............................. 16
2.4.2.4. TLS Ciphersuites ......................................... 17
2.4.3. User Groups ................................................ 17
2.4.4. Access Rights .............................................. 18
2.4.4.1. VCalendar Access Right (VCAR) ........................... 18
2.4.4.2. Decreed VCARs ............................................ 19
2.4.4.3. Inheritance .............................................. 19
2.4.5. CAP session identity ....................................... 19
2.5. Roles ........................................................ 20
2.6. Calendar Addresses ........................................... 21
2.7. Extensions to iCalendar ...................................... 21
2.8. Relationship of RFC 2446 (ITIP) to CAP ....................... 22
2.9. VCalendar Access Rights (VCARs) .............................. 23
2.10. Query Schema ................................................ 23
3. State Diagram .................................................. 23
4. Protocol Framework ............................................. 25
4.1. CAP Application Layer ........................................ 25
4.2. CAP Transfer Protocol ........................................ 25
4.3. Response Format .............................................. 25
4.4. Auto-logout Timer ............................................ 26
4.5. Bounded Latency .............................................. 26
4.6. Data Elements ................................................ 27
5. Formal Command Syntax .......................................... 27
5.1. Searching and Filtering ...................................... 27
5.1.1. Grammar For Search Mechanism ............................... 27
6. Access Rights .................................................. 28
6.1. VCAR Inheritance ............................................. 28
6.2. Access Control and NOCONFLICT ................................ 28
7. Commands and Responses ......................................... 29
7.1. Transfer Protocol Commands ................................... 29
7.1.1. Initial Connection ......................................... 29
7.1.2. ABORT Command .............................................. 30
7.1.3. AUTHENTICATE Command ....................................... 30
7.1.3.1. AUTHENTICATE ANONYMOUS ................................... 33
7.1.4. CALIDEXPAND Command ........................................ 34
7.1.5. CAPABILITY Command ......................................... 35
7.1.6. CONTINUE Command ........................................... 36
7.1.7. DISCONNECT Command ......................................... 37
7.1.8. IDENTIFY Command ........................................... 38
Mansour/Dawson/Royer/Taler/Hill Expires September 2000
7.1.9. SENDDATA Command ........................................... 38
7.1.10. STARTTLS Command .......................................... 38
7.1.10.1. UPNEXPAND Method ........................................ 39
7.2. Application Protocol Commands ................................ 40
7.2.1. Calendaring Commands ....................................... 40
7.2.1.1. CREATE Method ............................................ 40
7.2.1.1.1. Creating New Calendars ................................. 41
7.2.1.2. DELETE Method ............................................ 43
7.2.1.3. GENERATEUID Method ....................................... 44
7.2.1.4. MODIFY Method ............................................ 44
7.2.1.5. MOVE Method .............................................. 45
7.2.1.6. NOOP Method .............................................. 46
7.2.1.7. READ Method .............................................. 46
7.2.2. Scheduling Commands ........................................ 50
7.2.2.1. Reading out scheduling components ........................ 50
7.2.2.2. PUBLISH .................................................. 51
7.2.2.3. REQUEST .................................................. 52
7.2.2.4. REPLY .................................................... 52
7.2.2.5. ADD ...................................................... 52
7.2.2.6. CANCEL ................................................... 52
7.2.2.7. REFRESH .................................................. 52
7.2.2.8. COUNTER .................................................. 52
7.2.2.9. DECLINECOUNTER ........................................... 52
7.2.3. iTIP Examples .............................................. 52
7.2.3.1. Sending and Receiving an iTIP request .................... 52
7.2.3.2. Handling an iTIP refresh ................................. 55
7.2.3.3. Sending and accepting an iTIP counter .................... 56
7.2.3.4. Declining an iTIP counter ................................ 57
8. Response Codes ................................................. 58
8.1. Minimum CS query implementation .............................. 60
8.1.1. Query by UID ............................................... 60
8.1.2. Query by Date / Date-Time range ............................ 60
8.1.2.1. Date/Date-Time query with subset of properties ........... 60
8.1.3. <TBD> ...................................................... 60
9. Detailed SQL Schema ............................................ 60
9.1. iCalendar Store Schema ....................................... 62
9.1.1. ACTION schema .............................................. 62
9.1.2. ATTACH schema .............................................. 63
9.1.3. ATTENDEE schema ............................................ 63
9.1.4. CALSTORE schema ............................................ 63
9.1.5. CHILDREN schema ............................................ 64
9.1.6. CLASS schema ............................................... 64
9.1.7. CN schema .................................................. 64
9.1.8. COMMENT schema ............................................. 64
9.1.9. CONTACT schema ............................................. 64
9.1.10. CREATED schema ............................................ 65
9.1.11. CUTYPE schema ............................................. 65
9.1.12. DAYLIGHT_STANDARD schema .................................. 65
9.1.13. DESCRIPTION schema ........................................ 65
9.1.14. DIR schema ................................................ 66
9.1.15. DTEND schema .............................................. 66
9.1.16. DTSTAMP schema ............................................ 66
9.1.17. DUE schema ................................................ 66
Mansour/Dawson/Royer/Taler/Hill Expires September 2000 The CAP definition is based on requirements identified by
9.1.18. DURATION schema ........................................... 67 the Internet Engineering Task Force (IETF) Calendaring and
9.1.19. EXDATE schema ............................................. 67 Scheduling (CALSCH) Working Group. More information about
9.1.20. EXRULE schema ............................................. 67 the IETF CALSCH Working Group activities can be found on the
9.1.21. FBTYPE schema ............................................. 67 IMC web site at http://www.imc.org/ietf-calendar, and at the
9.1.22. FMTTYPE schema ............................................ 67 IETF web site at http://www.ietf.org/html.charters/calsch-
9.1.23. FREEBUSY schema ........................................... 68 charter.html. Refer to the references within this memo for
9.1.24. GEO schema ................................................ 68 further information on how to access these various
9.1.25. LANGUAGE schema ........................................... 68 documents.
9.1.26. LAST_MODIFIED schema ...................................... 68
9.1.27. MEMBER schema ............................................. 68
9.1.28. METHOD schema ............................................. 69
9.1.29. ORGANIZER schema .......................................... 69
9.1.30. OWNERS schema ............................................. 69
9.1.31. PARTSTAT schema ........................................... 69
9.1.32. PERCENT_COMPLETE schema ................................... 70
9.1.33. PRIORITY schema ........................................... 70
9.1.34. RDATE schema .............................................. 70
9.1.35. RECUR schema .............................................. 70
9.1.36. RECURRENCE_ID schema ...................................... 71
9.1.37. RELATED_TO schema ......................................... 72
9.1.38. REPEAT schema ............................................. 72
9.1.39. RESOURCES schema .......................................... 72
9.1.40. ROLE schema ............................................... 72
9.1.41. RRULE schema .............................................. 73
9.1.42. SEQUENCE schema ........................................... 73
9.1.43. STATUS schema ............................................. 73
9.1.44. SUMMARY schema ............................................ 73
9.1.45. TRANSP schema ............................................. 73
9.1.46. TRIGGER schema ............................................ 74
9.1.47. TZID schema ............................................... 74
9.1.48. UID schema ................................................ 74
9.1.49. URL schema ................................................ 74
9.1.50. VALARM schema ............................................. 75
9.1.51. VCALENDAR schema .......................................... 75
9.1.52. VCAR schema ............................................... 75
9.1.53. VEVENT schema ............................................. 75
9.1.54. VFREEBUSY schema .......................................... 76
9.1.55. VJOURNAL schema ........................................... 77
9.1.56. VQUERY schema ............................................. 77
9.1.57. VTIMEZONE schema .......................................... 78
9.1.58. VTODO schema .............................................. 78
9.1.59. X_PROP schema ............................................. 79
9.1.60. XPARAM schema ............................................. 79
9.2. Query example ................................................ 79
10. Examples ...................................................... 79
10.1. Authentication Examples ..................................... 79
10.1.1. Login Using Kerberos V4 ................................... 79
10.1.2. Error Scenarios ........................................... 80
10.2. Read Examples ............................................... 81
10.2.1. Read From A Single Calendar ............................... 81
10.2.2. Read From Multiple Calendars .............................. 82
10.2.3. Timeouts .................................................. 83
10.2.4. Using the Calendar Parent, Children Properties ............ 84
Mansour/Dawson/Royer/Taler/Hill Expires September 2000 Table Of Contents
10.2.5. An example that depends on VEVENT.DTSTART and VALARM.DT-
START ........................................................ 84
11. Implementation Issues ......................................... 84
12. Properties .................................................... 84
12.1. Calendar Store Properties ................................... 84
12.2. Calendar Properties ......................................... 85
13. Security Considerations ....................................... 87
14. Changes to iCalendar .......................................... 87
14.1. Time Transparency ........................................... 88
14.2. RIGHTS Value Type ........................................... 89
14.3. VCAR Calendar Component ..................................... 92
14.4. GRANT Component Property .................................... 94
14.5. DENY Component Property ..................................... 94
14.6. VCAR Identifier Component Property .......................... 95
15. CAP Entities Registration ..................................... 96
15.1.1. Define the Entity ......................................... 97
15.1.2. Post the entity definition ................................ 98
15.1.3. Allow a comment period .................................... 98
15.1.4. Submit the entity for approval ............................ 98
15.2. Property Change Control ..................................... 98
16. IANA Considerations ........................................... 99
17. Acknowledgments ............................................... 99
18. Bibliography .................................................. 99
19. Author's Address .............................................. 100
20. Full Copyright Statement ...................................... 101
Mansour/Dawson/Royer/Taler/Hill Expires September 2000 1.Introduction 7
1.1.Formatting Conventions 7
1.2. Related Documents 8
1.3. Definitions 8
2. CAP Design 16
2.1. System Model 16
2.2. Calendar Store Object Model 17
2.3. Protocol Model 18
2.4. Security Model 20
2.4.1. Authentication, Credentials, and Identity 21
2.4.2. Calendar User and UPNs 22
2.4.2.1. UPNs and Certificates 23
2.4.2.2. Anonymous Users and Authentication 24
2.4.2.3. Required Security Mechanisms 25
2.4.2.4. TLS Ciphersuites 25
2.4.3. User Groups 26
2.4.4. Access Rights - Summary 27
2.4.4.1. VCalendar Access Right (VCAR) 28
2.4.4.2. Decreed VCARs 28
2.4.4.3. Inheritance 29
2.4.5. CAP Session Identity 29
2.5. Roles 31
2.6. Calendar Addresses 31
2.7. Extensions to iCalendar 32
2.8. Relationship of RFC 2446 (ITIP) to CAP 33
2.9. VCalendar Access Rights (VCARs) 35
3. State Diagram 35
4. Protocol Framework 37
4.1. CAP Application Layer 37
4.2. CAP Transfer Protocol 38
4.3. Response Format 38
4.4. Pipelining of Commands 39
4.5. Auto-logout Timer 39
4.6. Bounded Latency 39
4.7. Data Elements 40
5. Formal Command Syntax 40
5.1. Searching and Filtering 40
5.1.1. Grammar For Search Mechanism 40
5.1.2. SQL-MIN notes 42
5.1.3. SQL-92 notes 43
5.1.4. Example, Query by UID 43
5.1.5. Query by Date-Time range 44
5.1.6. Query for all Non-Booked Entries 44
5.1.7. Query with Subset of Properties by Date/Time 45
5.1.8. Find all Components with an Alarm Within the
Specified Range 45
6. Access Rights 46
6.1. VCAR Inheritance 46
6.2. Access Control and NOCONFLICT 46
7. Commands and Responses 47
7.1. Transfer Protocol Commands 47
7.1.1. Initial Connection 48
7.1.2. ABORT Command 48
7.1.3. AUTHENTICATE Command 49
7.1.3.1. AUTHENTICATE ANONYMOUS 52
7.1.4. CALIDEXPAND Command 53
7.1.5. CAPABILITY Command 54
7.1.6. CONTINUE Command 57
7.1.7. DISCONNECT Command 58
7.1.9. SENDDATA Command 60
7.1.10.1. UPNEXPAND Method 61
7.2. Application Protocol Commands 62
7.2.1. Calendaring Commands 62
Restriction Tables 63
7.2.1.1. CREATE Method 63
7.2.1.1.1. Creating New Calendars 71
7.2.1.2. DELETE Method 74
7.2.1.3. GENERATEUID Method 78
7.2.1.4. MODIFY Method 79
7.2.1.5. MOVE Method 88
7.2.1.6. NOOP Method 90
7.2.1.7. READ Method 90
7.2.2. Scheduling Commands 95
7.2.2.1. Reading out scheduling components 95
7.2.2.2. PUBLISH 97
7.2.2.3. REQUEST 98
7.2.2.4. REPLY 98
7.2.2.5. ADD 99
7.2.2.6. CANCEL 99
7.2.2.7. REFRESH 99
7.2.2.8. COUNTER 100
7.2.2.9. DECLINECOUNTER 100
7.2.3. iTIP Examples 100
7.2.3.1. Sending and Receiving an iTIP request 101
7.2.3.2. Handling an iTIP refresh 105
7.2.3.3. Sending and accepting an iTIP counter 106
7.2.3.4. Declining an iTIP counter 108
9. Detailed SQL Schema 112
9.1. iCalendar Store Schema 114
9.1.1. ACTION schema 115
9.1.2. ATTACH schema 115
9.1.3. ATTENDEE schema 116
9.1.4. CALSTORE schema 116
9.1.5. CHILDREN schema 117
9.1.6. CLASS schema 117
9.1.7. CN schema 117
9.1.8. COMMENT schema 117
9.1.9. CONTACT schema 118
9.1.10. CREATED schema 118
9.1.11. CUTYPE schema 118
9.1.12. DAYLIGHT_STANDARD schema 119
9.1.13. DESCRIPTION schema 119
9.1.14. DIR schema 120
9.1.15. DTEND schema 120
9.1.16. DTSTAMP schema 120
9.1.17. DUE schema 120
9.1.18. DURATION schema 121
9.1.19. EXDATE schema 121
9.1.20. EXRULE schema 121
9.1.21. FBTYPE schema 122
9.1.22. FMTTYPE schema 122
9.1.23. FREEBUSY schema 122
9.1.24. GEO schema 123
9.1.25. LANGUAGE schema 123
9.1.26. LAST_MODIFIED schema 123
9.1.27. MEMBER schema 123
9.1.28. METHOD schema 123
9.1.29. ORGANIZER schema 124
9.1.30. OWNERS schema 124
9.1.31. PARTSTAT schema 125
9.1.32. PERCENT_COMPLETE schema 125
9.1.33. PRIORITY schema 125
9.1.34. RDATE schema 125
9.1.35. RECUR schema 126
9.1.36. RECURRENCE_ID schema 128
9.1.37. RELATED_TO schema 128
9.1.38. REPEAT schema 128
9.1.39. RESOURCES schema 129
9.1.40. ROLE schema 129
9.1.41. RRULE schema 129
9.1.42. SEQUENCE schema 130
9.1.43. STATUS schema 130
9.1.44. SUMMARY schema 130
9.1.45. TRANSP schema 131
9.1.46. TRIGGER schema 131
9.1.47. TZID schema 131
9.1.48. UID schema 131
9.1.49. URL schema 132
9.1.50. VALARM schema 132
9.1.51. VCALENDAR schema 132
9.1.52. VCAR schema 133
9.1.53. VEVENT schema 133
9.1.54. VFREEBUSY schema 135
9.1.55. VJOURNAL schema 136
9.1.56. VQUERY schema 137
9.1.57. VTIMEZONE schema 137
9.1.58. VTODO schema 138
9.1.59. X_PROP schema 139
9.1.60. XPARAM schema 140
10. Examples" 140
10.1. Authentication Examples 140
10.1.1. Login Using Kerberos V4 140
10.1.2. Error Scenarios 141
10.2. Read Examples 141
10.2.2. Read From Multiple Calendars 143
10.2.3. Timeouts 144
10.2.4. Using the Calendar Parent, Children Properties
145
10.2.5. An example that depends on VEVENT.DTSTART &
VALARM.DTSTART 145
11. Implementation Issues 146
12. Properties 146
12.1. Calendar Store Properties 146
12.2. Calendar Properties 149
13. Security Considerations 151
14. Changes to iCalendar 152
14.1. Time Transparency 152
14.2. RIGHTS Value Type 154
14.3. VCAR Calendar Component 159
14.4. GRANT Component Property 161
14.5. DENY Component Property 162
14.7. REQUEST-STATUS property 163
15. CAP Item Registration 165
15.1 Registration of New and Modified CAP Entities New CAP
entities are 165
15.2 Registration of New Entities 165
15.1.1. Define the Item 166
15.1.2. Post the item definition 167
15.1.3. Allow a comment period 167
15.1.4. Submit the proposal for approval 168
15.2. Property Change Control 168
16. IANA Considerations 169
17. Acknowledgments 169
18. Bibliography 170
19. Author's Address 171
20. Full Copyright Statement 172
1. Introduction 1. Introduction
This document specifies how a Calendar User Agent (CUA) interacts with a This document specifies how a Calendar User Agent (CUA)
Calendar Store (CS) to manage calendar information. In particular, it interacts with a Calendar Store (CS) to manage calendar
specifies how to query, create, modify, and delete iCalendar components information. In particular, it specifies how to query,
(e.g., events, to-dos, or daily journal entries). It further specifies create, modify, and delete iCalendar components (e.g.,
how to search for available busy time information. events, to-dos, or daily journal entries). It further
specifies how to search for available busy time information.
This protocol is based on request/response form of protocol data units, This protocol is based on request/response form of protocol
sent from a client CUA to a calendar server. The protocol data units data units, sent from a client CUA to a calendar server. The
leverage the standard iCalendar format [RFC2445] for conveying CS protocol data units leverage the standard iCalendar format
related information. [iCAL] for conveying CS related information.
1.1. Formatting Conventions 1.1. Formatting Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"
document are to be interpreted as described in [RFC2119]. and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119].
Calendaring and scheduling roles are referred to in quoted-strings of Calendaring and scheduling roles are referred to in quoted-
text with the first character of each word in upper case. For example, strings of text with the first character of each word in
"Organizer" refers to a role of a "Calendar User" (CU) within the upper case. For example, "Organizer" refers to a role of a
protocol defined by this memo. Calendar components defined by [RFC2445] "Calendar User" (CU) within the protocol defined by this
are referred to with capitalized, quoted-strings of text. All calendar memo. Calendar components defined by [iCAL] are referred to
components start with the letter "V". For example, "VEVENT" refers to with capitalized, quoted-strings of text. All calendar
the event calendar component, "VTODO" refers to the to-do calendar components start with the letter "V". For example, "VEVENT"
component and "VJOURNAL" refers to the daily journal calendar component. refers to the event calendar component, "VTODO" refers to
Calendar access methods defined by this memo, as well as scheduling the to-do calendar component and "VJOURNAL" refers to the
methods defined by [RFC2446], are referred to with capitalized, quoted- daily journal calendar component. Calendar access methods
strings of text. For example, "CREATE" refers to the method for creating defined by this memo, as well as scheduling methods defined
a calendar component on a calendar, "READ" refers to the method for by [iTIP], are referred to with capitalized, quoted-strings
reading calendar components. of text. For example, "CREATE" refers to the method for
creating a calendar component on a calendar, "READ" refers
to the method for reading calendar components.
Properties defined by this memo are referred to with capitalized, Properties defined by this memo are referred to with
quoted-strings of text, followed by the word "property". For example, capitalized, quoted-strings of text, followed by the word
"ATTENDEE" property refers to the iCalendar property used to convey the "property". For example, "ATTENDEE" property refers to the
calendar address of a "Calendar User". Property parameters defined by iCalendar property used to convey the calendar address of a
this memo are referred to with lower case, quoted-strings of text, "Calendar User". Property parameters defined by this memo
followed by the word "parameter". For example, "value" parameter refers are referred to with lower case, quoted-strings of text,
to the iCalendar property parameter used to override the default data followed by the word "parameter". For example, "value"
type for a property value. Enumerated values defined by this memo are parameter refers to the iCalendar property parameter used to
referred to with capitalized text, either alone or followed by the word override the default data type for a property value.
Enumerated values defined by this memo are referred to with
capitalized text, either alone or followed by the word
"value". "value".
In tables, the quoted-string text is specified without quotes in order In tables, the quoted-string text is specified without
to minimize the table length. quotes in order to minimize the table length.
1.2. Related Documents 1.2. Related Documents
Implementers will need to be familiar with several other memos that, Implementers will need to be familiar with several other
along with this one, describe the Internet calendaring and scheduling memos that, along with this one, describe the Internet
calendaring and scheduling standards. This document,
Mansour/Dawson/Royer/Taler/Hill 3 Expires September 2000
standards. This document,
[RFC2445] specifies the objects, data types, properties and property [iCAL] (RFC2445) specifies the objects, data types,
parameters used in the protocols, along with the methods for properties and property parameters used in the protocols,
representing and encoding them; along with the methods for representing and encoding them,
[RFC2446] specifies an interoperability protocol for scheduling between [iTIP] (RFC2446) specifies an interoperability protocol for
different implementations. The related documents are: scheduling between different implementations. The related
documents are:
[RFC2447] specifies an Internet email binding for [RFC2446]. [iMIP] (RFC2447) specifies an Internet email binding for
[iTIP].
[iRIP] specifies a real-time binding for [RFC2446]. [IMPL] (draft/rfc...) is a guide to implementors...
This memo does not attempt to repeat the specification of concepts or This memo does not attempt to repeat the specification of
definitions from these other memos. Where possible, references are made concepts or definitions from these other memos. Where
to the memo that provides for the specification of these concepts or possible, references are made to the memo that provides for
definitions. the specification of these concepts or definitions.
1.3. Definitions 1.3. Definitions
Authentication ID (AuthID) Authentication ID (AuthID)
A tuple of username, realm, and authentication method, used by the A tuple of username, realm, and authentication method, used
Calendar Service internally to identify a successfully authenticated by the Calendar Service internally to identify a
CAP session. successfully authenticated CAP session.
Booked
A entry in a calendar has one of two conceptual states. It
is scheduled or it is booked. A scheduled entry has been
stored in the calendar store but has not been acted on by a
calendar user or calendar user agent. A booked appointment
is an entry that has had its state changed from one of the
[iTIP] scheduling methods to a CAP method of CREATE by a
calendar user 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 which A collection of logically related objects or entities each
may be associated with a calendar date and possibly time of day. These of which may be associated with a calendar date and possibly
entities can include other calendar properties or calendar components. time of day. These entities can include other calendar
In addition, a calendar might be hierarchically related to other sub- properties or calendar components.In addition, a calendar
calendars. A calendar is identified by its unique calendar identifier. might be hierarchically related to other sub-calendars. A
The [RFC2445] defines calendar properties, calendar components and calendar is identified by its unique calendar identifier.
component properties that make up the content of a calendar. The [iCAL] defines 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 Calendar User Agent to The standard Internet protocol that permits a Calendar User
access and manipulate a calendar residing on a Calendar Store. Agent to access and manipulate a calendar residing on a
Calendar Store.
Calendar Access Rights (CAR) Calendar Access Rights (CAR)
The mechanism for specifying the CAP operations ("ACTIONS") that a The mechanism for specifying the CAP operations ("ACTIONS")
particular calendar user ("UPN") are granted or denied permission to that a particular calendar user ("UPN") are granted or
perform on a given calendar entity ("OBJECT"). The calendar access denied permission to perform on a given calendar item
rights are specified with the "VCAR" calendar components within a CS ("OBJECT"). The calendar access rights are specified with
and calendar. the "VCAR" calendar components within a CS and calendar.
Mansour/Dawson/Royer/Taler/Hill 4 Expires September 2000
Calendar Collection Calendar Collection
A collection of Calendars, Resource Calendars, and/or other Calendar A collection of Calendars, Resource Calendars, and/or other
Collections. These collections are expanded by the CS and may reside Calendar Collections. These collections are expanded by the
either locally or in an external database or directory. The calendars CS and may reside either locally or in an external database
in the collection may be fixed or dynamic over time. or directory. The calendars in the collection may be fixed
or dynamic over time.
Calendar Component Calendar Component
An entity within a calendar. Some types of calendar components include An item within a calendar. Some types of calendar components
events, to-dos, journals, alarms, time zones and freebusy data. A include events, to-dos, journals, alarms, time zones and
calendar component consists of component properties and possibly other freebusy data. A calendar component consists of component
sub-components. For example, an event may contain an alarm component. properties and possibly other 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 calendar An attribute of a particular calendar component. Some
component properties are applicable to different types of calendar calendar component properties are applicable to different
components. For example, DTSTART is applicable to VEVENT, VTODO, types of calendar components. For example, DTSTART is
VJOURNAL calendar components. Other calendar components are applicable applicable to VEVENT, VTODO, VJOURNAL calendar components.
only to an individual type of calendar component. For example, TZURL Other calendar components are applicable only to an
is only applicable to VTIMEZONE calendar components. individual type of calendar component. For example, TZURL is
only applicable to VTIMEZONE calendar components.
Calendar Identifier (CalID) Calendar Identifier (CalID)
A globally unique identifier associated with a calendar. Calendars A globally unique identifier associated with a calendar.
reside within a CS. See Qualified Calendar Identifier and Relative Calendars reside within a CS. See Qualified Calendar
Calendar Identifier. Identifier and Relative Calendar Identifier.
Calendar Policy Calendar Policy
A CAP operational restriction on the access or manipulation of a A CAP operational restriction on the access or manipulation
calendar. For example, "events MUST be scheduled in unit intervals of of a calendar. For example, "events MUST be scheduled in
one hour". unit intervals of one hour".
Calendar Properties Calendar Properties
An attribute of a calendar. The attribute applies to the calendar, as An attribute of a calendar. The attribute applies to the
a whole. For example, CALSCALE specifies the calendar scale (e.g., calendar, as a whole. For example, CALSCALE specifies the
GREGORIAN) for the whole calendar. calendar scale (e.g., GREGORIAN) for the whole calendar.
Calendar Service Calendar Service
An implementation of a Calendar Store that manages one or more An implementation of a Calendar Store that manages one or
calendars. more calendars.
Mansour/Dawson/Royer/Taler/Hill 5 Expires September 2000
Calendar Store (CS) Calendar Store (CS)
The data and service model definition for a Calendar Service. The data and service model definition for a Calendar
Service.
Calendar Store Identifier (CSID) Calendar Store Identifier (CSID)
The globally unique identifier for an individual CS. A CSID consists The globally unique identifier for an individual CS. A CSID
of the host and port portions of a "Common Internet Scheme Syntax" consists of the host and port portions of a "Common Internet
part of a URL, as defined by [RFC2396]. Scheme Syntax" part of a URL, as defined by [URL].
Calendar Store Components Calendar Store Components
Components maintained in a CS specify a grouping of calendar store- Components maintained in a CS specify a grouping of calendar
wide information. Calendar store components can be accessed using CAP. store-wide information. Calendar store components can be
accessed using CAP.
Calendar Store Properties Calendar Store Properties
Properties maintained in a Calendar Store calendar store-wide Properties maintained in a Calendar Store calendar store-
information. Calendar store properties can be accessed using CAP. wide information. Calendar store properties can be accessed
using CAP.
Calendar User (CU) Calendar User (CU)
An entity (often biological) that uses a calendaring system. An entity (often biological) that uses a calendaring system.
Calendar User Agent (CUA) Calendar User Agent (CUA)
The CUA is the client application that a CU or UG utilizes to access The CUA is the client application that a CU or UG utilizes
and manipulate a calendar. to access and manipulate a calendar.
Calendaring and Scheduling System Calendaring and Scheduling System
The computer sub-system that provides the services for accessing, The computer sub-system that provides the services for
manipulating calendars and scheduling calendar components. accessing, manipulating calendars and scheduling calendar
components.
CAP Session CAP Session
An open communication channel between a CAP CUA and a CAP CS. An open communication channel between a CAP CUA and a CAP
CS.
Connected Mode Connected Mode
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
Mansour/Dawson/Royer/Taler/Hill 6 Expires September 2000 Is a calendar user (sometimes called the delegatee) who has
Is a calendar user (sometimes called the delegatee) who has been been assigned participation in a scheduled calendar
assigned participation in a scheduled calendar component (e.g., component (e.g., VEVENT) by one of the attendees in the
VEVENT) by one of the attendees in the scheduled calendar component scheduled calendar component (sometimes called the
(sometimes called the delegator). An example of a delegate is a team delegator). An example of a delegate is a team member told
member told to go to a particular meeting. to go to a particular meeting.
Designate Designate
Is a calendar user who is authorized to act on behalf of another Is a calendar user who is authorized to act on behalf of
calendar user. An example of a designate is an assistant. another calendar user. An example of a designate is an
assistant.
Disconnected Mode Disconnected Mode
A mobile computing mode where a CUA can be disconnected from a CS. A mobile computing mode where a CUA can be disconnected from
When the CUA is disconnected, it is in the disconnected mode. a CS. When the CUA is disconnected, it is in the
disconnected mode.
Fan Out Fan Out
The calendaring and scheduling process by which a calendar operation The calendaring and scheduling process by which a calendar
on one calendar is also performed on every other calendar specified in operation on one calendar is also performed on every other
the operation. This may include the calendar associated with TARGET calendar specified in the operation. This may include the
calendar property. calendar associated with TARGET calendar property.
Hierarchical Calendars Hierarchical Calendars
A CS feature where a calendar have a hierarchical relationship with A CS feature where a calendar have a hierarchical
another calendar in the CS. The top-most calendar in the hierarchical relationship with another calendar in the CS. The top-most
relationship has the CS as its parent. There may be multiple top-most calendar in the hierarchical relationship has the CS as its
calendars in a given CS. Within a given hierarchical relationship, all parent. There may be multiple top-most calendars in a given
sub-calendars have a calendar with a "parent" topographical CS. Within a given hierarchical relationship, all sub-
relationship. In addition, sub-calendars may have a relationship with calendars have a calendar with a "parent" topographical
another calendar that has a "child" topographical relationship. In relationship. In addition, sub-calendars may have a
addition, a calendar may have a relationship such that one or more relationship with another calendar that has a "child"
calendars have a "sibling" topographical relationship with the topographical relationship. In addition, a calendar may have
calendar. The hierarchical calendar feature is not a storage a relationship such that one or more calendars have a
relationship of the calendars within the CS. Instead it is a feature "sibling" topographical relationship with the calendar. The
that relates access control rights to calendar content between hierarchical calendar feature is not a storage relationship
different calendars in the CS. The hierarchical relationship of a of the calendars within the CS. Instead it is a feature that
calendar is specified in the "PARENT" and "CHILDREN" calendar relates access control rights to calendar content between
properties. 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 rates; transfer A communications connection supporting high transfer rates;
rates commonly found within a LAN. transfer rates commonly found within a LAN.
Mansour/Dawson/Royer/Taler/Hill 7 Expires September 2000
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 rates; transfer A communications connection supporting slow transfer rates;
rates commonly found in remote access technology. transfer rates commonly found in remote access technology.
Overlapped Booking Overlapped Booking
A policy which indicates whether or not OPAQUE events can overlap one A policy which indicates whether or not OPAQUE events can
another. When the policy is applied to a calendar it indicates whether overlap one another. When the policy is applied to a
or not any OPAQUE events in the calendar can overlap. When applied to calendar it indicates whether or not any OPAQUE events in
an individual event, it indicates whether or not it can be overlapped the calendar can overlap. When applied to an individual
by any other OPAQUE event. event, it indicates whether or not it can be overlapped by
any other OPAQUE event.
Owner Owner
One or more CUs or UGs that have "OWNER" calendar access rights for a One or more CUs or UGs that have "OWNER" calendar access
calendar. The owner is specified in the "OWNER" calendar property. rights for a calendar. The owner is specified in the "OWNER"
calendar property.
Qualified Calendar Identifier (Qualified CalID) Qualified Calendar Identifier (Qualified CalID)
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 string. The A collection of calendar user accounts, identified by a
name of the realm is only used in UPNs. In order to avoid namespace string. The name of the realm is only used in UPNs. In
conflict, the realm SHOULD be postfixed with an appropriate DNS domain order to avoid namespace conflict, the realm SHOULD be
name. (eg: the foobar realm could be called foobar.example.com). postfixed with an appropriate DNS domain name. (eg: the
foobar realm could be called foobar.example.com).
Relative Calendar Identifier (Relative CalID) Relative Calendar Identifier (Relative CalID)
An identifier for an individual calendar in a calendar store. It is An identifier for an individual calendar in a calendar
unique within a calendar store. It is recommended to be globally store. It is unique within a calendar store. It is
unique. A Relative CalID consists of the portion of the "scheme part" recommended to be globally unique. A Relative CalID consists
of a Qualified CalID following the Calendar Store Identifier. This is of the portion of the "scheme part" of a Qualified CalID
the same as the "URL path" of the "Common Internet Scheme Syntax" following the Calendar Store Identifier. This is the same as
portion of a URL, as defined by [RFC2396]. the "URL path" of the "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.
Mansour/Dawson/Royer/Taler/Hill 8 Expires September 2000
Resource Calendar (RC) Resource Calendar (RC)
A non-human Calendar, associated with an organizational resource. A non-human Calendar, associated with an organizational
There is no syntactic difference between an RC and a Calendar. resource. There is no syntactic difference between an RC and
a Calendar.
Session Identity Session Identity
A UPN associated with a CAP session. A session gains an identity after A UPN associated with a CAP session. A session gains an
successful authentication. The identity is used in combination with identity after successful authentication. The identity is
CAR to determine access to data in the CS. used in combination with CAR to determine access to data in
the CS.
Sub-calendars Sub-calendars
Calendars that have a "child" hierarchical relationship with another Calendars that have a "child" hierarchical relationship with
calendar, its "parent". another calendar, its "parent".
User Group (UG) User Group (UG)
A collection of Calendar Users and/or User Groups. These groups are A collection of Calendar Users and/or User Groups. These
expanded by the CS and may reside either locally or in an external groups are expanded by the CS and may reside either locally
database or directory. The group membership may be fixed or dynamic or in an external database or directory. The group
over time. membership may be fixed or dynamic over time.
User Name User Name
A name which denotes a Calendar User within a realm. This is part of a A name which denotes a Calendar User within a realm. This is
UPN. part of a UPN.
User Principal Name (UPN) User Principal Name (UPN)
An identifier that denotes a unique CU. A UPN is an RFC 822 compliant An identifier that denotes a unique CU. A UPN is an RFC 822
email address, with exceptions listed below, and in most cases it is compliant email address, with exceptions listed below, and
deliverable to the CU. In some cases it is identical to the CU's well in most cases it is deliverable to the CU. In some cases it
known email address. A CU's UPN MUST never be deliverable to a is identical to the CU's well known email address. A CU's
different person. It consists of a realm in the form of a valid, and UPN MUST never be deliverable to a different person. It
unique, DNS domain name and a unique username. In it's simplest form consists of a realm in the form of a valid, and unique, DNS
it looks like "user@example.com". domain name and a unique username. In it's simplest form it
looks like "user@example.com".
In certain cases a UPN will not be RFC 822 compliant. When anonymous In certain cases a UPN will not be RFC 822 compliant. When
authentication is used, or anonymous authorization is being defined, anonymous authentication is used, or anonymous authorization
the special UPN "@" will be used. When authentication must be used, is being defined, the special UPN "@" will be used. When
but unique identity must be obscured, a UPN of the form @DNS-domain- authentication must be used, but unique identity must be
name may be used. For example, "@example.com". Usage of these special obscured, a UPN of the form @DNS-domain-name may be used.
cases is further discussed in the authentication and authorization For example, "@example.com". Usage of these special cases is
further discussed in the authentication and authorization
sections of this document. sections of this document.
Mansour/Dawson/Royer/Taler/Hill 9 Expires September 2000
2. CAP Design 2. CAP Design
2.1. System Model 2.1. System Model
The system model describes the high level components of a calendar The system model describes the high level components of a
system and how they interact with each other. calendar system and how they interact with each other.
CAP is used by a "Calendar User Agent" (CUA) to send commands to and CAP is used by a "Calendar User Agent" (CUA) to send
receive responses from a "Calendar Service" (CS). The CUA prepares an commands to and receive responses from a "Calendar Service"
MIME encapsulated iCalendar object containing a command, sends it to the (CS). The CUA prepares an [MIME] encapsulated iCalendar
CS, and receives an iCalendar object as a response. There are two object containing a command, sends it to the CS, and
distinct protocols in operation to accomplish this exchange. The receives an iCalendar object as a response. There are two
Transfer Protocol is used to move iCalendar objects between a CUA and a distinct protocols in operation to accomplish this exchange.
CS. The Application Protocol defines the content and semantics of the The Transfer Protocol is used to move iCalendar objects
iCalendar objects sent between the CUA and the CS. This document defines between a CUA and a CS. The Application Protocol defines the
both the Transfer Protocol and the Application Protocol. content and semantics of the iCalendar objects sent between
the CUA and the CS. This document defines both the Transfer
Protocol and the Application Protocol.
In the diagram below, a user uses CUA1 to communicate with CS1 using In the diagram below, a user uses CUA1 to communicate with
CAP. The CUA must authenticate the Calendar User (CU) so that access to CS1 using CAP. The CUA must authenticate the Calendar User
calendars on CS1 can be controlled. The CUA can then view, create, edit, (CU) so that access to calendars on CS1 can be controlled.
and delete calendars, calendar properties, and calendar components The CUA can then view, create, edit, and delete calendars,
subject to the access rights. calendar properties, and calendar components subject to the
access rights.
CAP servers support fanout. Fanout allows a CUA to communicate with a CAP servers support fanout. Fanout allows a CUA to
single CS to perform scheduling operations with calendars on multiple communicate with a single CS to perform scheduling
CSs. That is, a Calendar User (CU) can book events on or read events operations with calendars on multiple CSs. That is, a
from calendars on other calendar stores. To accomplish this, a CAP Calendar User (CU) can book events on or read events from
server has several options: calendars on other calendar stores. To accomplish this, a
CAP server has these options:
CS1 MAY play the role of a CUA and use CAP to access CS2; CS1 MAY play the role of a CUA and use CAP to access CS2;
CS1 MAY be able to play the role of a CUA and use [iRIP] to CS1 MUST be able play the role of a CUA and use [iMIP] to
interoperate with the possible iRIP support in CS2;
CS1 MUST be able play the role of a CUA and use [RFC2447] to
interoperate with other CUAs. interoperate with other CUAs.
Storage Agent Storage Agent
+-----+ +-----+ +-----+ +-----+
| | CAP | | CAP | | CAP | | CAP
CUA1 ------| CS1 |-----------| CS2 |--------- CUA2 CUA1------| CS1 |----------| CS2 |--------- CUA2
| | | | A | | | | A
| | | | | | | | | |
| | | | | | | | | |
+-----+ +-----+ | +-----+ +-----+ |
| IMIP | | IMIP |
+---------------------------------+ +--------------------------------+
Mansour/Dawson/Royer/Taler/Hill 10 Expires September 2000 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, [RFC2447] messages could also be sent messages could also be sent from CUA1 to CUA2.
from CUA1 to CUA2.
2.2. Calendar Store Object Model 2.2. Calendar Store Object Model
The conceptual model for a calendar store is shown below. The calendar The conceptual model for a calendar store is shown below.
store contains calendars, VTIMEZONEs, VCARs, and calendar store The calendar store contains calendars, VTIMEZONEs, VCARs,
properties. and calendar store properties.
Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs, VCARs, and Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs,
calendar properties. Calendars may also contain other calendars. VCARs, and calendar properties. Calendars may also contain
other calendars.
+---------Calendar Store-----------------------------+ +---------Calendar Store---------------------------------+
| | | |
| | | |
| VCARs | | VCARs |
| +--calendars-------------------------+ | | +--calendars-------------------------+ |
| Properties | | | | Properties | | |
| | +--calendars--------+ VEVENTs | | | | +--calendars--------+ VEVENTs | |
| VTIMEZONEs | | | VTODOs | | | VTIMEZONEs | | | VTODOs | |
| | | VEVENTs | VJOURNALs | | | | | VEVENTs | VJOURNALs | |
| | | VCARs | VALARMs | | | | | VCARs | VALARMs | |
| | | +---+ VTODOs | VCARs | | | | | +---+ VTODOs | VCARs | |
| | | | | VALARMs | Calendar | | | | | | | VALARMs | Calendar | |
| | | +---+ VJOURNALs | Properties | | | | | +---+ VJOURNALs | Properties | |
| | | VTIMEZONEs | VTIMEZONEs | | | | | VTIMEZONEs | VTIMEZONEs | |
| | | Calendar | VSCHEDULE | | | | | Calendar | VSCHEDULE | |
| | | Properties | | | | | | Properties | | |
| | | VSCHEDULE | | | | | | VSCHEDULE | | |
| | +-------------------+ | | | | +-------------------+ | |
| +------------------------------------+ | | +------------------------------------+ |
+----------------------------------------------------+ +--------------------------------------------------------+
Calendars within a Calendar Store are identified by their Relative Calendars within a Calendar Store are identified by their
CALID. Relative CALID.
In this model, VSCHEDULE is a queue of scheduling messages that have not In this mo del, VSCHEDULE is a queue of scheduling messages
yet been applied to the calendar. Items in VSCHEDULE are discussed in that have not yet been applied to the calendar. Items in
more detail below. VSCHEDULE are discussed in more detail below.
2.3. Protocol Model 2.3. Protocol Model
A generic transfer-layer, Calendar Server Transfer Protocol (CSTP), is A generic transfer-layer, Calendar Server Transfer Protocol
used to move data objects between a CUA and the CS. CSTP commands are (CSTP), is used to move data objects between a CUA and the
listed below and their usage and semantics are defined in section 7 of CS. CSTP commands are listed below and their usage and
this document. semantics are defined in section 7 of this document.
Mansour/Dawson/Royer/Taler/Hill 11 Expires September 2000
CSTP Commands CSTP Commands
------------------------------------------------------------------------- -------------------------------------------------------
Command Description Command Description
------------------------------------------------------------------------- -----------------------------------------------------------
ABORT Stop a command whose latency time has been exceeded. ABORT Stop a command. Perhaps because its latency
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 latency
time has been exceeded. 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
iCalendar.
STARTTLS Negotiate transport level security using
[TLS].
-----------------------------------------------------------
SENDDATA Send a data object MIME encapsulated iCalendar. Application-level commands are used to manipulate data on
the calendar store. They are listed below and discussed in
STARTTLS Negotiate transport level security using [TLS] detail in section 7.
-------------------------------------------------------------------------
Application-level commands are used to manipulate data on the calendar
store. They are listed below and discussed in detail in section 7.
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.
MODIFY Change a calendar or component.
GENERATEUID Generate one or more unique ids MOVE Move a calendar.
READ Read a calendar properties or components.
MODIFY Change a calendar or component --------------------------------------------------------
MOVE Move a calendar
READ Read a calendar properties or components
-------------------------------------------------------------------------
CAP Scheduling Commands CAP Scheduling Commands
------------------------------------------------------------------------- (As defined in [iTIP])
-----------------------------------------------------------
Command Description Command Description
------------------------------------------------------------------------- ----------------------------------------------------------
PUBLISH Publish a calendar entry to one PUBLISH Publish a calendar entry to one or more
or more calendars. calendars.
REQUEST Schedule a calendar entry with one or more
Mansour/Dawson/Royer/Taler/Hill 12 Expires September 2000 calendars.
REQUEST Schedule a calendar entry with
one or more 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 calendar entry.
existing calendar entry. CANCEL Cancel one or more instances to an existing
calendar entry.
CANCEL Cancel one or more instances to REFRESH A request for the latest version of a
an existing calendar entry. calendar entry.
COUNTER A request for a change(a counter-proposal)to
REFRESH A request for the latest version a calendar entry.
of a calendar entry.
COUNTER A request for a change (a
counter-proposal) 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 [RFC2222]. Authentication to the CS will be performed using [SASL].
As noted in the CAP system model section, a variety of connectivity As noted in the CAP system model section, a variety of
scenarios are possible. This complicates the security model connectivity scenarios are possible. This complicates the
considerably, and a thorough familiarity with the concepts is required security model considerably, and a thorough familiarity with
to ensure interoperability. the concepts is 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 not, either by information came from the CS when in fact it did
modifying data in transit or misdirecting the client's not, either by modifying data in transit or
connection. misdirecting the client's connection.
Threats (1), (4), (5) and (6) are due to hostile clients. Threats (2), Threats (1), (4), (5) and (6) are due to hostile clients.
and (3) are due to hostile agents on the path between client and server, Threats (2), and (3) are due to hostile agents on the path
or posing as a server. 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:
Mansour/Dawson/Royer/Taler/Hill 13 Expires September 2000 (1) Client authentication by means of the SASL mechanism
(1) Client authentication by means of the SASL [RFC2222] mechanism set, possibly backed by the TLS credentials exchange
set, possibly backed by the TLS credentials exchange mechanism, mechanism,
(2) Client authorization by means of access control based on the
requestor's authenticated identity,
(3) Data integrity protection by means of the TLS protocol or
data-integrity SASL mechanisms,
(4) Protection against snooping by means of the TLS protocol or
data-encrypting SASL mechanisms,
(5) Resource limitation by means of administrative limits on service
controls, and
(6) Server authentication by means of the TLS protocol or SASL
mechanism.
Imposition of access controls (authorizations) is done by means of (2) Client authorization by means of access control based
VCARs, an overview is provided in section <fwd ref>, and a detailed on the requestor's authenticated identity,
syntax is provided in section <fwd ref>. Authentication is explained in
detail in section <fwd ref>. (3) Data integrity protection by means of the TLS protocol
or data integrity SASL mechanisms,
(4) Protection against snooping by means of the TLS
protocol or data encrypting SASL mechanisms,
(5) Resource limitation by means of administrative limits
on service controls, and
(6) Server authentication by means of the TLS protocol or
SASL mechanism.
Imposition of access controls (authorizations) is done
by means of VCARs, an overview is provided in section
<fwd ref>, and a detailed syntax is provided in section
<fwd ref>. Authentication is explained in detail in
section <fwd ref>.
2.4.1. Authentication, Credentials, and Identity 2.4.1. Authentication, Credentials, and Identity
Generically, authentication credentials are the evidence supplied by one Generically, authentication credentials are the evidence
party to another, asserting the identity of the supplying party (e.g. a supplied by one party to another, asserting the identity of
user) who is attempting to establish an association with the other party the supplying party (e.g. a user) who is attempting to
(typically a server). Authentication is the process of generating, establish an association with the other party (typically a
transmitting, and verifying these credentials and thus the identity they server). Authentication is the process of generating,
assert. An authentication identity is the name presented in a transmitting, and verifying these credentials and thus the
credential. identity they assert. An authentication identity is the name
presented in a credential.
There are many forms of authentication credentials. The form used There are many forms of authentication credentials. The form
depends upon the particular authentication mechanism negotiated by the used depends upon the particular authentication mechanism
parties. For example: X.509 certificates, Kerberos tickets, simple negotiated by the parties. For example: X.509 certificates,
identity and password pairs. Note that an authentication mechanism may Kerberos tickets, simple identity and password pairs. Note
constrain the form of authentication identities used with it. that an authentication mechanism may constrain the form of
authentication identities used with it.
SASL only provides a protocol to negotiate a mutually acceptable SASL only provides a protocol to negotiate a mutually
authentication mechanism. SASL itself does not constrain or dictate the acceptable authentication mechanism. SASL itself does not
form of the authentication identities used to perform the constrain or dictate the form of the authentication
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 is A Calendar User(CU) is an entity that can be authenticated.
represented in CAP as a UPN. A UPN is the owner of a calendar and the It is represented in CAP as a UPN. A UPN is the owner of a
subject of access rights. The UPN representation is independent of the calendar and the subject of access rights. The UPN
authentication mechanism used during a particular CUA/CS interaction. representation is independent of the authentication
This is because UPNs are used within VCARs. If the UPN were dependant on mechanism used during a particular CUA/CS interaction. This
the authentication mechanism, a VCAR could not be consistently is because UPNs are used within VCARs. If the UPN were
evaluated. A CU may use one mechanism while using one CUA but the same dependent on the authentication mechanism, a VCAR could not
CU may use a different authentication mechanism when using a different be consistently evaluated. A CU may use one mechanism while
using one CUA but the same CU may use a different
Mansour/Dawson/Royer/Taler/Hill 14 Expires September 2000 authentication mechanism when using a different CUA, or
CUA, or while connecting from a different location. 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 by using Note that the immutability of the user's UPN may be achieved
SASL's authorization identity feature. (The transmitted authorization by using SASL's authorization identity feature. (The
identity may be different than the identity in the client's transmitted authorization identity may be different than the
authentication credentials.) [RFC2222, section 3] This also permits a CU identity in the client's authentication credentials.) [SASL,
to authenticate using their own credentials, yet request the access section 3] This also permits a CU to authenticate using
privileges of the identity for which they are proxying [RFC2222]. Also, their own credentials, yet request the access privileges of
the form of authentication identity supplied by a service like TLS may the identity for which they are proxying SASL. Also, the
not correspond to the UPNs used to express a server's access control form of authentication identity supplied by a service like
policy, requiring a server-specific mapping to be done. The method by TLS may not correspond to the UPNs used to express a
which a server composes and validates an authorization identity from the server's access control policy, requiring a server-specific
authentication credentials supplied by a client is implementation- mapping to be done. The method by which a server composes
specific. and validates an authorization identity from the
authentication credentials supplied by a client is
implementation-specific.
For Calendaring and Scheduling Systems that are integrated with a For Calendaring and Scheduling Systems that are integrated
directory system, the CS MUST support the ability to configure which with a directory system, the CS MUST support the ability to
schema attribute stores the UPN. The CS MAY allow one or more attributes configure which schema attribute stores the UPN. The CS MAY
to be searched for the UPN. allow one or more 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 authentication, the When using X.509 certificates for purposes of CAP
UPN should appear in the certificate. Unfortunately there is no single authentication, the UPN should appear in the certificate.
correct guideline for which field should contain the UPN. Unfortunately there is no single correct guideline for which
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 subjectAltName If subject naming information is present only in the
extension (e.g., a key bound only to an email address or URI), then subjectAlt-Name extension (e.g., a key bound only to an
the subject name MUST be an empty sequence and the subjectAltName email address or URI), then the subject name MUST be an
extension MUST be critical. empty sequence and the subjectAltName extension MUST be
critical.
Implementations of this specification MAY use these comparison rules Implementations of this specification MAY use these
to process unfamiliar attribute types (i.e., for name chaining). comparison rules to process unfamiliar attribute types
This allows implementations to process certificates with unfamiliar (i.e., for name chaining). This allows implementations to
attributes in the subject name. process certificates with unfamiliar attributes in the
subject name.
In addition, legacy implementations exist where an RFC 822 name is In addition, legacy implementations exist where an RFC 822
embedded in the subject distinguished name as an EmailAddress name is embedded in the subject distinguished name as an
attribute. The attribute value for EmailAddress is of type EmailAddress attribute. The attribute value for
IA5String to permit inclusion of the character '@', which is not EmailAddress is of type IA5String to permit inclusion of the
part of the PrintableString character set. EmailAddress attribute character '@', which is not part of the PrintableString
values are not case sensitive (e.g., "fanfeedback@redsox.com" is the character set. EmailAddress attribute values are not case
same as "FANFEEDBACK@REDSOX.COM"). sensitive (e.g., "fanfeedback@redsox.com" is the same as
"FANFEEDBACK@REDSOX.COM").
Conforming implementations generating new certificates with Conforming implementations generating new certificates with
electronic mail addresses MUST use the rfc822Name in the subject electronic mail addresses MUST use the rfc822Name in the
alternative name field (see sec. 4.2.1.7 [of RFC 2459]) to describe subject alternative name field (see sec. 4.2.1.7 [of RFC
2459]) to describe such identities. Simultaneous inclusion
Mansour/Dawson/Royer/Taler/Hill 15 Expires September 2000 of the EmailAddress attribute in the subject distinguished
such identities. Simultaneous inclusion of the EmailAddress name to support legacy implementations is deprecated but
attribute in the subject distinguished name to support legacy permitted.
implementations is deprecated but permitted.
Since no single method of including the UPN in the certificate will work Since no single method of including the UPN in the
in all cases, CAP implementations MUST support the ability to configure certificate will work in all cases, CAP implementations MUST
what the mapping will be by the CS administrator. Implementations MAY support the ability to configure what the mapping will be by
support multiple mapping definitions, for example, the UPN may be found the CS administrator. Implementations MAY support multiple
in either the subject alternative name field, or the UPN may be embedded mapping definitions, for example, the UPN may be found in
in the subject distinguished name as an EmailAddress attribute. either the subject alternative name field, or the UPN may be
embedded in the subject distinguished name as an
EmailAddress attribute.
Note: If a CS or CUA is validating data received via iMIP, if the Note: If a CS or CUA is validating data received via iMIP,
"ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe Random if the "ORGANIZER" or "ATTENDEE" property said (e.g.)
User:juser@example.com" then the email address should be checked against "ATTENDEE;CN=Joe Random User:juser@example.com" then the
the UPN, and the CN should also be checked. This is so the "ATTENDEE" email address should be checked against the UPN, and the CN
property couldn't be munged to something misleading like should also be checked. This is so the "ATTENDEE" property
"ATTENDEE;CN=Joe Rictus User:juser@example.com" and have it pass couldn't be munged to something misleading like
validation. This validation will also defeat other attempts at "ATTENDEE;CN=Joe Rictus User:juser@example.com" and have it
confusion. 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
Anonymous access is often desirable. For example an organization may Anonymous access is often desirable. For example an
publish calendar information that does not require any access control organization may publish calendar information that does not
for viewing or login. Conversely, a user may wish to view unrestricted require any access control for viewing or login. Conversely,
calendar information without revealing their identity. a user may wish to view unrestricted calendar information
without revealing their identity.
CAP implementations MUST support anonymous authentication, as defined in CAP implementations MUST support anonymous authentication,
section <fwd ref 7.1.3>. as defined in section <fwd ref 7.1.3>.
CAP implementations MAY support anonymous authentication with TLS, as CAP implementations MAY support anonymous authentication
defined in section <fwd ref 7.1.3.2>. 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 place: The following implementation conformance requirements are in
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 access (2) Implementations providing password-based authenticated
MUST support authentication using Digest, as described in access MUST support authentication using Digest, as
section <fwd ref>. This provides client authentication with described in section <fwd ref>. This provides client
protection against passive eavesdropping attacks, but does authentication with protection against passive eavesdropping
not provide protection against active intermediary 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.
Mansour/Dawson/Royer/Taler/Hill 16 Expires September 2000 (3) For a CS needing session protection and authentication,
Implementations SHOULD support authentication with a password as the Start TLS extended operation, and either the simple
described in section <fwd ref>, and SHOULD support authentication authentication choice or the SASL EXTERNAL mechanism, are to
with a certificate as described in section <fwd ref>. Together, be used together. Implementations SHOULD support
these can provide integrity and disclosure protection of authentication with a password as described in section <fwd
transmitted data, and authentication of client and server, ref>, and SHOULD support authentication with a certificate
including protection against active intermediary attacks. 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 used for The following ciphersuites defined in [RFC 2246] MUST NOT be
confidentiality protection of passwords or data: used for confidentiality protection of passwords or data:
TLS_NULL_WITH_NULL_NULL TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
The following ciphersuites defined in [RFC 2246] can be cracked easily The following ciphersuites defined in [RFC 2246] can be
(less than a week of CPU time on a standard CPU in 1997). The client cracked easily (less than a week of CPU time on a standard
and server SHOULD carefully consider the value of the password or data CPU in 1997). The client and server SHOULD carefully
being protected before using these ciphersuites: 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_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_RC4_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 attacks, The following ciphersuites are vulnerable to man-in-the-
and SHOULD NOT be used to protect passwords or sensitive data, unless middle attacks, and SHOULD NOT be used to protect passwords
the network configuration is such that the danger of a man-in-the-middle or sensitive data, unless the network configuration is such
attack is tolerable: that the danger of a man-in-the-middle attack is tolerable:
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA 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 2.4.3. User Groups
User Group is used to represent a collection of CUs or other UGs that User Group is used to represent a collection of CUs or other
can be referenced in VCARS. A UG is represented in CAP as a UPN. The UGs that can be referenced in VCARS. A UG is represented in
CUA cannot distinguish between a UPN that represents a CU or a UG. CAP as a UPN. The CUA cannot distinguish between a UPN
that represents a CU or a UG.
UGs are expanded as necessary by the CS. The CS MUST accept a CUA UGs are expanded as necessary by the CS. The CS MUST accept
request for UG expansion, although the CS may be configured to restrict a CUA request for UG expansion, although the CS may be
some responses. The CS MAY expand a UG (including nested UGs) to obtain configured to restrict some responses. The CS MAY expand a
a list of unique CUs. Duplicate UPNs are filtered during expansion. 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.
Mansour/Dawson/Royer/Taler/Hill 17 Expires September 2000 Groups may be in a directory with its own ACL model and CAP
Incomplete expansion should be treated as a failure. should use the directory service to expand a UPN subject to
the directory service access control model for the
authenticated entity.
[ Editor's Note: We need to explore the issue and impact of directory The CS SHOULD not preserve UG expansions across operations.
permissions and precedence.] A UG may reference a static list of members, or it may
represent a dynamic list. Each operation SHOULD generate its
own expansion in order to recognize changes to UG
membership. However, during fan out to other CSs, the
originating CS SHOULD expand all UGs so that the target CS
receives only a list of unique CUs. This is to prevent
confusion when two CSs do not share the same UG database or
directory.
The CS SHOULD not preserve UG expansions across operations. A UG may CAP does not define commands or methods for managing UGs.
reference a static list of members, or it may represent a dynamic list.
Each operation SHOULD generate its own expansion in order to recognize
changes to UG membership. However, during fan out to other CSs, the
originating CS SHOULD expand all UGs so that the target CS receives only
a list of unique CUs. This is to prevent confusion when two CSs do not
share the same UG database or directory.
[Editor's Note: Doug had an issue here relating to multiple CUs not Small UG:
having a common directory. We think the above text resolves this] The Three Stooges. There is only and always three at any
one time.
CAP does not define commands or methods for managing UGs. Large UG:
The MIT graduating class of 1999. This is a static list.
Examples: Dynamic UG:
The IETF membership which is a large and changing list of
members.
Small UG - The Three Stooges. There is only and always three at any Nested UG:
one time. The National Football League, made up of the AFC and NFC,
Large UG - The MIT graduating class of 1999. This is a static list. which are made up of 3 divisions each...
Dynamic UG - The IETF membership, which is a large and changing list
of members.
Nested UG - The National Football League, made up of the AFC and
NFC, which are made up of 3 divisions each...
2.4.4. Access Rights 2.4.4. Access Rights - Summary
In simple terms, access rights are used to grant or deny access to a In simple terms, access rights are used to grant or deny
calendar for a CU. CAP defines a new component type called a VCalendar access to a calendar for a CU. CAP defines a new component
Access Right (VCAR). Specifically, a VCAR grants, or denies, UPNs the type called a Vcalendar Access Right (VCAR). Specifically, a
right to read and write components, properties, and parameters on VCAR grants, or denies, UPNs the right to read and write
calendars within a CS. components, properties, and parameters on calendars within a
CS.
The VCAR model does not put any restriction on the sequence in which the The VCAR model does not put any restriction on the sequence
object and access rights are created. That is, an event associated with in which the object and access rights are created. That is,
a particular VCAR might be created before or after the actual VCAR is an event associated with a particular VCAR might be created
defined. In addition, the VCAR and VEVENT definition might be created in before or after the actual VCAR is defined. In addition, the
the same iCalendar object and passed together in a single command. VCAR and VEVENT definition might be created in the same
iCalendar object and passed together in a single command.
All rights MUST be denied unless specifically granted; individual VCARs All rights MUST be denied unless specifically granted;
MUST be specifically granted to an authenticated CU. individual VCARs MUST be specifically granted to an
authenticated CU.
2.4.4.1. VCalendar Access Right (VCAR) 2.4.4.1. VCalendar Access Right (VCAR)
Access rights within CAP are specified with the "VCAR" calendar Access rights within CAP are specified with the "VCAR"
component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" calendar component, "RIGHTS" value type and the "GRANT",
component properties. "DENY" and "CARID" component properties.
Mansour/Dawson/Royer/Taler/Hill 18 Expires September 2000 Properties within an iCalendar object are unordered. This
Properties within an iCalendar object are unordered. This also is the also is the case for the "GRANT", "DENY" and "CARID"
case for the "GRANT", "DENY" and "CARID" properties. Likewise, properties. Likewise, there is no implied ordering required
there is no implied ordering required for components of a "RIGHTS" value for components of a "RIGHTS" value type other than that
type other than that specified by the ABNF. [ editor's note, this specified by the ABNF. [EDITOR'S NOTE, this requires a lot
requires a lot of review. We think that this paragraph may be incorrect. of review. We think that this paragraph may be incorrect. ]
]
For details on the VCAR syntax please see section <forward ref> For details on the VCAR syntax please see section <forward
ref>
2.4.4.2. Decreed VCARs 2.4.4.2. Decreed VCARs
[editor's note: new concept. This will also require some syntax A CS MAY choose to implement and allow persistent immutable
modification 14.4. This section is being actively discussed on the VCARs, that are configured by the CS Administrator, which
working group list, 2/3/2000.] apply to all calendars on the server.
A CS MAY choose to implement and allow persistent immutable VCARs, that When a user attempts to modify a decreed VCAR an error will
are configured by the CS Administrator, which apply to all calendars on be returned, indicating that the user has insufficient
the server. authorization to perform the operation.
When a user attempts to modify a decreed VCAR and error will be The CAP protocol does not define the semantics used to
returned,indicating that the user has insufficient authorization to initially create a decreed VCAR. This administrative task is
perform the operation. out side the scope of the CAP protocol.
The CAP protocol does not define the semantics used to initially create For example an implementation or a CS administrator may wish
a decreed VCAR. This administrative task is out side the scope of the to define a VCAR that will always allow the calendar owners
CAP protocol. to have full access to their own calendars. The GRANT
property allows the OWNERs all (OBJECT=*) access to their
own calendar objects. The DENY property disallows anyone
(UPN=*) from being able to delete or modify this VCAR.
BEGIN:VCAR
CARID:Users Default Access
GRANT:UPN=OWNER;OBJECT=*;OBJECT=OBJECT=METHOD;VALUE=*
DENY:UPN=*;OBJECT=VCAR;OBJECT=CARID;VALUE="Users Default
Access"
;OBJECT=METHOD,VALUE=DELETE,MODIFY
END:VCAR
Decreed VCARs MUST be readable by the calendar owner in
standard VCAR format.
2.4.4.3. Inheritance 2.4.4.3. Inheritance
Calendars inherit VCARs from their parent. Calendars inherit VCARs from their parent calendar.
VCARs specified in a calendar or a sub-calendar override all inherited VCARs specified in a calendar or a sub-calendar override all
VCARs. inherited VCARs.
2.4.5. CAP session identity 2.4.5. CAP Session Identity
A CAP session has an associated set of authentication credentials, from A CAP session has an associated set of authentication
which is derived a UPN. This UPN is the identity of the CAP session, and credentials, from which is derived a UPN. This UPN is the
is used to determine access rights for the session. identity of the CAP session, and is used to determine access
rights for the session.
The CUA may change the identity of a CAP session by calling the The CUA may change the identity of a CAP session by calling
"IDENTIFY" command. The Calendar Service only permits the operation if the "IDENTIFY" command. The Calendar Service only permits
the session's authentication credentials are good for the requested the operation if the session's authentication credentials
identity. The method of checking this permission is implementation are good for the requested identity. The method of checking
dependent, but may be thought of as a mapping from authentication this permission is implementation dependent, but may be
credentials to UPNs. The "IDENTIFY" command allows a single set of thought of as a mapping from authentication credentials to
authentication credentials to choose from multiple identities, and UPNs. The "IDENTIFY" command allows a single set of
allows multiple sets of authentication credentials to assume the same authentication credentials to choose from multiple
identity. identities, and allows multiple sets of authentication
credentials to assume the same identity.
Mansour/Dawson/Royer/Taler/Hill 19 Expires September 2000 For anonymous access the identity of the session is "@", a
For anonymous access the identity of the session is "@", a UPN with a UPN 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-null username, but non-null realm, such as "@foo.com" may be used
realm, such as "@foo.com" may be used to mean any identity from that to mean any identity from that realm, which is useful to
realm, which is useful to grant access rights to all users in a given grant access rights to all users in a given realm. A UPN
realm. A UPN with a non-null username and null realm, such as "bob@" with a non-null username and null realm, such as "bob@"
could be a security risk and must not be used. could be a security risk and MUST NOT be used.
Since the UPN includes realm information it may be used to govern Since the UPN includes realm information it may be used to
calendar store access rights across realms. However, governing access govern calendar store access rights across realms. However,
rights across realms is only useful if login access is available. This governing access rights across realms is only useful if
could be done through a trusted server relationship or a temporary login access is available. This could be done through a
account. trusted server relationship or a temporary account.
The "IDENTIFY" command provides for a weak group implementation. By The "IDENTIFY" command provides for a weak group
allowing multiple sets of authentication credentials belonging to implementation. By allowing multiple sets of authentication
different users to identify as the same UPN, that UPN essentially credentials belonging to different users to identify as the
identifies a group of people, and may be used for group calendar same UPN, that UPN essentially identifies a group of people,
ownership, or the granting of access rights to a group. and may be used for group calendar ownership, or the
granting of access rights to a group.
Examples: Examples:
Small UG - The Three Stooges. There will always be three, it will Small UG:
not change. The Three Stooges. There will always be three, it will not
change.
Large UG - The MIT graduating class of 1999. This is a static list. Large UG:
The MIT graduating class of 1999. This is a static list.
Dynamic UG - The IETF membership, which is a large and changing Dynamic UG:
list of members. The IETF membership, which is a large and changing list of
members.
Nested UG - The National Football League, made up of the AFC and Nested UG:
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 [RFC2445] objects on a Calendar Store CAP defines methods for managing [iCAL] objects on a
and exchanging [RFC2445] objects for the purposes of group calendaring Calendar Store and exchanging [iCAL] objects for the
and scheduling between "Calendar Users" (CUs) or "User Groups" (UGs). purposes of group calendaring and scheduling between
There are two distinct roles taken on by CUs in CAP. The CU who creates "Calendar Users" (CUs) or "User Groups" (UGs). There
an initial event or to-do and invites other CUs or UGs as attendees are two distinct roles taken on by CUs in CAP. The CU who
takes on the role of "Organizer". The CUs or UGs asked to participate in creates an initial event or to-do and invites other CUs or
the group event or to-do take on the role of "Attendee". Note that UGs as attendees takes on the role of "Organizer". The CUs
"role" is also a descriptive parameter to the "ATTENDEE" property. Its or UGs asked to participate in the group event or to-do take
use is to convey descriptive context to an "Attendee" such as "chair", on the role of "Attendee". Note that "role" is also a
"REQ-PARTICIPANT" or NON- PARTICIPANT" and has nothing to do with the descriptive parameter to the "ATTENDEE" property. Its use is
scheduling workflow. to convey descriptive context to an "Attendee" such as
"chair", "REQ-PARTICIPANT" or NON- PARTICIPANT" and has
Mansour/Dawson/Royer/Taler/Hill 20 Expires September 2000 nothing to do with the scheduling workflow.
2.6. Calendar Addresses 2.6. Calendar Addresses
Calendar addresses are URIs that are modeled after [RFC2396]. CAP uses Calendar addresses are URIs that are modeled after URLs
the following forms of URI. [URL]. CAP uses the following forms of URI.
[[<scheme>]://<csid>[:<port>]/]<relativeCALID> [[<scheme>]://<csid>[:<port>]/]<relativeCALID>
where: where:
<scheme> is "cap" <scheme> is "cap". That is this protocol described in this
memo.
<csid> is the Calendar Store ID. It is the network address of the <csid> is the Calendar Store ID. It is the network address
computer on which the CAP server is running. of the computer on which the CAP server is running.
<port> is optional. Its default value is 5229. The port must be present <port> is optional. Its default value is 5229. The port must
if the CAP server does not listen on the default port. be present in the URL if the CAP server does not listen on
this default port of 5229.
<relativeCALID> is an identifier that uniquely identifies the calendar <relativeCALID> is an identifier that uniquely identifies
on a particular calendar store. There is no implied structure in a the calendar on a particular calendar store. There is no
Relative CALID. It is an arbitrary string of 7 bit ASCII characters. It implied structure in a Relative CALID. It is an arbitrary
may refer to the calendar of a user or of a resource such as a string of 7 bit ASCII characters. It may refer to the
conference room. It MUST be unique within the calendar store. It is calendar of a user or of a resource such as a conference
room. It MUST be unique within the calendar store. It is
recommended that the Relative CALID be globally unique. recommended that the Relative CALID be globally unique.
If the <scheme> and <csid> are present the calendar address is said to If the <scheme> and <csid> are present the calendar address
be "qualified". Senders are required to supply the <relativeCALID> is said to be "qualified". Senders are required to supply
portion of the address. A qualified calendar address is required when the <relativeCALID> portion of the address. A qualified
the <csid> of the target calendar address differs from that of the CAP calendar address is required when the <csid> of the target
server receiving the command. calendar address differs from that of the CAP server
receiving the command.
Examples: 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 same calendar.example.com, the first three addresses refer to the
calendar. same calendar.
2.7. Extensions to iCalendar 2.7. Extensions to iCalendar
In mapping the CAP command set, query feature, and access rights onto In mapping the CAP command set, query feature, and access
the iCalendar format, several extended iCalendar methods and components rights onto the iCalendar format, several extended iCalendar
are defined by this memo. methods and components are defined by this memo.
* The search function is specified with the new iCalendar QUERY
method. The QUERY method makes use of a new component, called
VQUERY, that contains the search filter. The component consists of
Mansour/Dawson/Royer/Taler/Hill 21 Expires September 2000
a set of new properties: SCOPE, MAXRESULTS, MAXRESULTSSIZE, QUERY
and QUERYNAME, that define the search filter.
* Access control is specified the the new iCalendar VCAR component.
* The iCalendar METHOD property format has been updated with new
values.
* A new iCalendar component, VCOMMAND, has been added. VCOMMANDs
are needed to fully specify CAP commands.
* The search function is specified with the new iCalendar
QUERY method. The QUERY method makes use of a new component,
called VQUERY, that contains the search filter. The
component consists of a set of new properties: EXPAND,
MAXRESULTS, MAXRESULTSSIZE, QUERY and QUERYNAME, that define
the search filter. Note that QUERY simply is the filter that
is used by the CS to select the data used in METHOD:READ,
METHOD:CREATE, METHOD:UPDATE, METHOD:DELETE, any other
METHOD that is defined to use a QUERY filter.
* Access control is specified the the new iCalendar VCAR
component.
* The iCalendar METHOD property format has been updated with
new values.
* A new iCalendar component, VCOMMAND, has been added.
VCOMMANDs are needed to fully specify CAP commands.
* TARGET is a new property within the VCOMMAND component. It * TARGET is a new property within the VCOMMAND component. It
indicates the calendars to which the 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 will
contain the same CMDID.
2.8. Relationship of RFC 2446 (ITIP) to CAP 2.8. Relationship of RFC 2446 (ITIP) to CAP
[RFC2446] describes scheduling methods which result in indirect [iTIP] describes scheduling methods which result in indirect
manipulation of calendar components. CAP methods provide direct manipulation of calendar components. CAP methods provide
manipulation of calendar components. In the CAP calendar store model, direct manipulation of calendar components. In the CAP
scheduling messages are kept separate from other calendar components. calendar store model, scheduling messages are conceptually
This is modeled with the VSCHEDULE queue. Note that this is a conceptual kept separate from other calendar components. This is
model, the actual storage details are left to implementations. The model modeled with the VSCHEDULE queue. Note that this is a
is shown pictorially as follows: conceptual model, the actual storage details are left to
implementations. 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 components become The METHOD is saved along with components. Scheduled
booked components when the METHOD changes from an ITIP method to the CAP components become booked components when the METHOD changes
storage method. For example, a component whose METHOD is "REQUEST" is from an ITIP method to the CAP storage method CREATE. For
scheduled. The component becomes booked when the METHOD is changed to example, a component whose METHOD is "REQUEST" is scheduled.
The component becomes booked when the METHOD is changed to
"CREATED". "CREATED".
[ed note: need to clean up the terminology here. We havent discussed Several scheduled entries can be in the CS for the same UID.
"booked"] They are consolidated when booked. Or they are removed from
the CS.
Mansour/Dawson/Royer/Taler/Hill 22 Expires September 2000 For example, if you were on vacation, you could have a
REQUEST to attend a meeting and several updates to that
meeting. Your CUA would have to READ them out of the CS
using CAP, process them, determine what the final state of
the object from a possible combination of user input and
programmed logic. Then the CUA would instruct the CS to
CREATE a new booked entry or MODIFY an existing entry.
Followed by a DELETE of all of these now old scheduling
requests in the CS. See [iTIP] for details on resolving
multiple [iTIP] scheduling entries.
2.9. VCalendar Access Rights (VCARs) 2.9. VCalendar Access Rights (VCARs)
In simple terms, VCARs are used to grant or deny access to a calendar In simple terms, VCARs are used to grant or deny access to a
for a CU or UG. Specifically, they grant User Principal Names (UPNs) the calendar for a CU or UG. Specifically, they grant User
rights to read and write components, properties, and parameters on Principal Names (UPNs) the rights to read and write
calendars within a calendar store. components, properties, and parameters on calendars within a
calendar store.
The model does not put any restriction on the sequence in which the The model does not put any restriction on the sequence in
object and access rights are created. That is, an event associated with which the object and access rights are created. That is, an
a particular VCAR might be created before or after the actual VCAR is event associated with a particular VCAR might be created
defined. In addition, the VCAR and VEVENT definition might be created in before or after the actual VCAR is defined. In addition, the
the same iCalendar object and passed together in a single SENDDATA VCAR and VEVENT definition might be created in the same
iCalendar object and passed together in a single SENDDATA
command. command.
VCAR principals can be CU or UG UPNs. Whenever VCARs are evaluated, all VCAR principals can be CU or UG UPNs. Whenever VCARs are
referenced User Groups MUST be evaluated as an expanded list. UG evaluated, all referenced User Groups MUST be evaluated as
expansion SHOULD NOT persist across operations. an expanded list. UG expansion SHOULD NOT persist across
operations.
[Editor's Note: This is where we need to define precedence rules.]
2.10. Query Schema Your access is a union of all your grants minus a union of
<TBD> breif paragraph on summary of VQUERY. all your denies.
3. State Diagram 3. State Diagram
This section describes the states of the transport connection between a This section describes the states of the transport
CUA and a CS. The state diagram is shown below. State names shown with connection between a CUA and a CS. The state diagram is
first letter capitalized. The commands used to switch between states are shown below. State names shown with first letter
shown next to an arrow connecting the states. The commands are listed in capitalized. The commands used to switch between states are
all capital letters. A condition that causes a state to change is shown shown next to an arrow connecting the states. The commands
in lower case letters. are listed in all capital letters. A condition that causes a
state to change is shown in lower case letters.
Mansour/Dawson/Royer/Taler/Hill 23 Expires September 2000
STARTTLS / STARTTLS /
CAPABILITY CAPABILITY
+-------+ +-------+
| | +---------------+ | | +---------------+
| +-----------+ AUTHENTICATE | | | +-----------+ AUTHENTICATE | |
+-->| Connected |-------------->| Authenticated | +-->| Connected |-------------->| Authenticated |
+-----------+ | | +-----------+ | |
| +---------------+ | +---------------+
| | | |
| | | |
| | | |
| | +-----+ STARTTLS / | | +-----+
| V | | CAPABILITY / STARTTLS /
| +---------------+ | IDENTIFY | V | |
CAPABILITY /
| +---------------+ |
IDENTIFY
| | |<-+ | | |<-+
| | Identified |<----+ | | Identified |<----+
| +--------| | | | +--------| | |
| | +---------------+ | command | | +---------------+ |
| | | | completes command
| | | |
completes
V |DISCONNECT | | V |DISCONNECT | |
+--------------+ | |SENDDATA | +--------------+ | |SENDDATA |
| Disconnected |<--+ | | | Disconnected |<--+ | |
+--------------+ | | ABORT +--------------+ | |
ABORT
A | | A | |
| V | | V |
| DISCONNECT +---------------+ | | DISCONNECT +---------------+ |
+--------------------| Receive |--+ +--------------------| Receive |-----+
| |<--+ | |<--+
+---------------+ | +---------------+ |
| | CONTINUTE | |
CONTINUTE
+----+ +----+
The connection begins the Connected state when a CUA connects to a CAP The connection begins the Connected state when a CUA
server. The capabilities of the CS are reported in the response from the connects to a CAP server. The capabilities of the CS are
CS. From this state, the CUA can issue the DISCONNECT command to reported in the response from the CS. From this state, the
terminate the connection, the CAPABILITY, STARTTLS, or AUTHENTICATE CUA can issue the DISCONNECT command to terminate the
commands. One use of the CAPABILITY command at this stage is to connection, the CAPABILITY, STARTTLS, or AUTHENTICATE
determine the supported authentication mechanisms supported by the commands. One use of the CAPABILITY command at this stage is
server. Once the STARTTLS command has been successfully executed from to determine the supported authentication mechanisms
either the Connected or Authenticated state, it must not be executed supported by the server. Once the STARTTLS command has been
again. successfully executed from either the Connected or
Authenticated state, it must not be executed again.
If an AUTHENTICATE command is successful, the connection enters the If an AUTHENTICATE command is successful, the connection
Authenticated state and then immediately goes to the IDENTIFIED state. enters the Authenticated state and then immediately goes to
While in the Identified state, allow CALIDEXPAND and UPNEXPAND commands. the IDENTIFIED state. While in the Identified state, allow
From here the CUA can issue the CAPABILITY command. The capabilities the CALIDEXPAND and UPNEXPAND commands. From here the CUA can
server offers in the Authenticated state may be different than those in issue the CAPABILITY command. The capabilities the server
the Connected state. The CUA can also use the IDENTIFY command to change offers in the Authenticated state may be different than
the identity of the user subject to access control. The connection those in the Connected state to allow for the users realm to
remains in the Authenticated state after the CAPABILITY command be used to grant or deny features. The CUA can also use the
IDENTIFY command to change the identity of the user subject
to access control. The connection remains
Mansour/Dawson/Royer/Taler/Hill 24 Expires September 2000 in the Authenticated state after the CAPABILITY command
completes. The CUA can issue the DISCONNECT command to terminate the completes. The CUA can issue the DISCONNECT command to
connection. The SENDDATA command can be used to send a request to read, terminate the connection. The SENDDATA command can be used
write, modify, or delete data on the server. to send a request to read, write, modify, or delete data on
the server.
After the SENDDATA command has been issued the connection enters the After the SENDDATA command has been issued the connection
Receive state while the CUA awaits and reads a server reply. Normally, enters the Receive state while the CUA awaits and reads a
the server handles the command, sends a reply which is read by the CUA server reply. Normally, the server handles the command,
and the connection returns to the Authenticated state. The CUA may have sends a reply which is read by the CUA and the connection
issued the SENDATA command with a maximum latency time. This informs the returns to the Authenticated state. The CUA may have issued
server that the CUA expects a response within the maximum latency time, the SENDATA command with a maximum latency time. This
even if the command was not completed. When the server is unable to informs the server that the CUA expects a response within
complete the command in the maximum latency time, it issues an the maximum latency time, even if the command was not
appropriate reply code and waits for the CUA to tell it how to proceed. completed. When the server is unable to complete the command
If the CUA issues a CONTINUE command the server continues processing the in the maximum latency time, it issues an appropriate reply
command and the connection remains in the Receive state. If the CUA code and waits for the CUA to tell it how to proceed. If the
issues the ABORT command the server need not process the command any CUA issues a CONTINUE command the server continues
further and the connection returns to the Authenticated state. The processing the command and the connection remains in the
DISCONNECT command can also be issued from the Receive state. Receive state. If the CUA issues the ABORT command the
server need not process the command any further and the
connection returns to the Authenticated state. The
DISCONNECT command can also be issued from the Receive
state.
4. 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 calendar The CAP application layer is used for the manipulation of
store. Commands and responses are transmitted between the CUA and CS the calendar store. Commands and responses are transmitted
inside "VCALENDAR" component wrappers. Commands are specified as the between the CUA and CS inside "VCALENDAR" component
value of a "METHOD" property, and responses are specified as the value wrappers. Commands are specified as the value of a "METHOD"
of a "REQUEST-STATUS" property. property, and responses are specified as the value of a
"REQUEST-STATUS" property.
4.2. CAP Transfer Protocol 4.2. CAP Transfer Protocol
The CAP transfer protocol defines the format of data transmitted between The CAP transfer protocol defines the format of data
a CUA and the CS. transmitted between a CUA and the CS.
CAP transfer protocol commands are transmitted using the underlying CAP transfer protocol commands are transmitted using the
transport. The transport used is a TCP/IP socket connection between the underlying transport. The transport used is a TCP/IP socket
CUA and the CS. The default port that the CS listens for connections on connection between the CUA and the CS. The default port that
is port 5229. the CS listens for connections on is port 5229.
Messages sent between the CUA and CS are formatted as a command followed Messages sent between the CUA and CS are formatted as a
by any associated data: command followed by any associated data:
<command> [<command data>] <command> [<command data>]
4.3. Response Format 4.3. 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 ; more
Mansour/Dawson/Royer/Taler/Hill 25 Expires September 2000 <transfer-level response-code> [response-args] [; debug-text
text] <CRLF>.<CRLF> [<application-data>] <CRLF>.<CRLF> ]
<CRLF>.<CRLF>
[<application-data>]
<CRLF>.<CRLF>
The response codes are defined in Section 8. The debug text is human- The response-args are defined in Section 8. The debug-text
readable information for protocol debugging and is optional. is human-readable information for protocol debugging and is
optional and is only used to aid developers writing CSs and
CUAs. The debug-text MUST not be depended on by CUAs in
normal interactions with a CS.
The optional application-data begins on the next line. The optional application-data begins on the next line.
The response is terminated with the second <CRLF> "." <CRLF> sequence. The response is terminated with the second <CRLF> "." <CRLF>
Any <CRLF> "." sequences which appear in the transmitted data must be sequence. Any <CRLF> "." sequences which appear in the
quoted by placing an additional "." between the <CRLF> and the ".". For transmitted data must be quoted by placing an additional "."
example, the following sequences of characters in the application data: between the <CRLF> and the ".". For example, the following
sequences of characters in the application data:
. .
..2 ..2
...3 ...3
are quoted as follows: are quoted as follows:
.. ..
...2 ...2
....3 ....3
No other tagged command sequence can be sent until the second special 4.4. Pipelining of Commands
terminating character sequence <CRLF>.<CRLF> has been sent.
4.4. Auto-logout Timer If the CS returns a PIPELINE number greater then one (1) as
a result of a CAPABILITY command the CUA can send up to
PIPELINE VCOMMANDS without waiting for the CS to reply.
If a server has an inactivity auto-logout timer, that timer MUST be of 4.5. Auto-logout Timer
at least 15 minutes duration. The receipt of ANY command from the client
during that interval MAY reset the auto-logout timer, subject to CS
administrators policy. A CUA may be discouraged from attempts to do
usless things only to keep the connection alive.
When a timeout occurs, the server drops the connection to the CUA. If a server has an inactivity auto-logout timer, that timer
MUST be of at least 15 minutes duration if there is no value
of AUTOLOGOUTTIME returned in the CS CAPABILITY reply. The
receipt of ANY command from the client during that interval
MAY reset the auto-logout timer, subject to CS
administrators policy. A CUA may be discouraged from
attempts to do useless things only to keep the connection
alive.
4.5. Bounded Latency A CS MAY have different AUTOLOGOUTTIME values depending on
the UPN or the realm of the UPN.
[CAP] is designed so that the CUA can either obtain an immediate When a timeout occurs, the server drops the connection to
response from a request or discover within a specified amount of time the CUA.
that the request could not be completed in the requested amount of time.
When the CUA initiates a command that the server cannot complete within
the specified latency time, the server returns an appropriate response
code. The CUA then issues either a CONTINUE or ABORT command. The ABORT
command immediately terminates the command in progress and the
connection returns to the Authenticated state. The CONTINUE command
instructs the server to continue processing the command.
Mansour/Dawson/Royer/Taler/Hill 26 Expires September 2000 4.6. Bounded Latency
4.6. Data Elements CAP is designed so that the CUA can either obtain an
immediate response from a request or discover within a
specified amount of time that the request could not be
completed in the requested amount of time. When the CUA
initiates a command that the server cannot complete within
the specified latency time, the server returns an
appropriate response code. The CUA then issues either a
CONTINUE or ABORT command. The ABORT command immediately
terminates the command in progress identified by CMDID and
the connection returns to the Authenticated state. The
CONTINUE command instructs the server to continue processing
the command identified by the CMDID.
The data elements for CAP are MIME encapsulated iCalendar objects. 4.7. Data Elements
The data elements for CAP are [MIME] encapsulated iCalendar
objects.
5. Formal Command Syntax 5. Formal Command Syntax
5.1. Searching and Filtering 5.1. Searching and Filtering
This section describes CAPs searching and filtering entities within a This section describes CAPs selecting and filtering entities
remote store. It is based on the Standard Query Language (SQL) defined within a calendar store. It is based on the Standard Query
by [SQL]. Language (SQL) defined in [SQL].
The QUERY property value MUST be a valid QUERY value type. This new 5.1.1. Grammar For Search Mechanism
value type is defined to be a "name=value" value type grammar, similar
in syntax to the format already in use for the iCalendar RECUR value
type. Each "name" is the name of a valid SQL statement component (e.g.,
SELECT, WHERE, etc.). Each "value" is valid string associated with one
of these SQL statement components.
[Editor's note: We need to precisely define what part of SQL were using search = "BEGIN:VQUERY" CRLF
and why we chose what we did.] [expand] [maxresults] [maxsize] querycomp
"END:VQUERY" CRLF
Examples needed: expand = "EXPAND" ":" ( "TRUE" / "FALSE")
# If not specified, the default is EXPAND:FALSE .
Grant someone access to June events comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / VTIMEZONE"
Grant someone access to events during the month of June. (i.e., based / "VALARM" / "VFREEBUSY" / "VCAR" / iana-name
on the current system date, if it's prior to June or after June you / x-name
don't have access)
Example for denying access to a specific property: maxresults = integer
DENY:UPN=FOO;ACTION=*;OBJECT=CLASS maxsize = integer
*scope vcar to a component *scope Grant, Deny of a VCAR querycomp = ( query ) / ( queryname query ) / queryname
5.1.1. Grammar For Search Mechanism queryname = "QUERYNAME:" text
SEARCH = "BEGIN:VQUERY" CRLF query = "QUERY:" ( query-min / query-92 )
[scope] [maxresults] [maxsize] querycomp #
"END:VQUERY" CRLF # NOTE: query-min MUST be implemented in CSs.
#
# query-92 is ONLY used if CAPABILITY returns SQL-92
# as the QUERYLEVEL value or if QUERYLEVEL is not
specified.
scope = "SCOPE:" comp-name ("," comp-name)* query-min = capselect-min capfrom-min capwhere-min
comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" capselect-min = "SELECT" capmin-cols "FROM" capmin-comps
/ "VALARM" / "VFREEBUSY" / "VCAR" / iana-name / x-name "WHERE" capmin-cmp
maxresults = integer capmin-col = # Any property name found in any of the
components.
maxsize = integer capmin-cols = ( capmin-col / capmin-col "," capmin-cols )
capmin-comps = ( comp-name / comp-name ","
compmin-comps )
Mansour/Dawson/Royer/Taler/Hill 27 Expires September 2000 capmin-cmp = ( colname cmpmin-oper colvalue
querycomp = (query) / (queryname query) / queryname / colname cmpmin-oper colvalue capmin-logical capmin-cmp )
queryname = "QUERYNAME:" text colname = ( # Any valid component property name.
/ "*" )
query = "QUERY:" queryrule cmpmin-oper = ( " = " / " != " / " < " / " > " / "
<= " / " >= " )
queryrule = capselect capwhere caporderby ... capmin-logical = ( " AND " / " OR " )
capselect = <any valid SQL string that goes into a SELECT clause> query-92 = capselect-92 capfrom-92 capwhere-92
caporderby-92
capwhere = <any valid SQL string that goes into a WHERE clause> capselect-92 = # Any valid [SQL] string that goes
into a SELECT clause.
caporderby = <any valid SQL string that goes into a ORDERBY capfrom-92 = # Like capmin-comps except embedded
clause> spaces are allowed
# between commas - per [SQL].
capwhere-92 = # Any valid [SQL] string that goes
into a WHERE clause.
caporderby-92 = # Any valid [SQL] string that goes
into a ORDERBY clause.
5.1.2. SQL-MIN notes
(1) No inlined spaces are allowed if not in the grammar
above.
(2) Note that cmpmin-oper and capmin-logical elements are
surrounded by exactly one space.
Use 'VEVENT,VTODO', not 'VEVENT, VTODO'
Use 'DTSTART <= 20000605T131313Z', not 'DTSTART<=
20000605T131313Z'.
Use ' AND ' and ' OR ', not 'AND' and not 'OR'.
(3) There is no ORDERBY. Sorting will take place in the
order the columns are supplied in the command.
(4) The CS MUST sort at least the first column.
The CS MAY sort additional columns.
(5) If EXPAND=FALSE and if colname is "*" sorting will be
by the DTSTART value ascending.
If EXPAND=TRUE and if colname is "*" sorting will be by the
RECURRENCE-ID value ascending.
If colname is "*" and capmin-coms is VALARM only then
sorting will be by TRIGGER time in GMT ascending.
(6) SQL-MIN MUST be implemented.
5.1.3. SQL-92 notes
(1) Although this memo specifies that any [SQL] query can
be used. Some of the [SQL] grammar is optional and therefore
they are also considered optional in CSs advertising an SQL-
92 implementation with CAPABILITY.
(2) A CS implementation MAY implement SQL-92. If a CS
does not implement SQL-92 then it MUST advertise SQL-MIN in
the capability reply.
5.1.4. Example, Query by UID
This example would select the entire contents of uid123 and
not expand any multiple instances of the component. If the
CUA does not know if 'uid123' was a VEVENT, VTODO, VJOURNAL,
or other component, then all components that the CUA
supports MUST be supplied on the QUERY property. This
example assumes the CUA only supports VTODO and VEVENT.
If the results were empty it could also mean that 'uid123'
was a property in a component other than a VTODO or VEVENT.
BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123'
END:VQUERY
This example would select the entire contents of uid123 and
would expand any instances of the component after applying
any recurrence rules. This query could select multiple
instances of components each with the same UID. Each
instance would have a unique RECURRENCE-ID of the expanded
component.
BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT * FROM VEVENT,VTODO WHERE UID = 'uid123'
END:VQUERY
5.1.5. Query by Date-Time range
This query selects the entire contents of every booked
VEVENT that has an instance less than or equal to July 31st,
2000 23:59:59 Z and greater than or equal to July 1st, 2000
00:00:00 Z
BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT *
FROM VEVENT
WHERE RECURRENCE-ID >= '20000801T000000Z'
AND RECURRENCE-ID <= '20000831T235959Z'
AND METHOD = 'CREATE'
END:VQUERY
5.1.6. Query for all Non-Booked Entries
This example selects the entire contents of all scheduling
(non-booked) VEVENTS in the CS. The default for EXPAND is
FALSE, so the recurrence rules will not be expanded.
BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT,VTODO WHERE METHOD != 'CREATE'
END:VQUERY
And this one only fetches the UIDs of all non-booked
VEVENTs and VTODOs.
BEGIN:VQUERY
QUERY:SELECT UID FROM VEVENT,VTODO WHERE METHOD != 'CREATE'
END:VQUERY
5.1.7. Query with Subset of Properties by Date/Time
This MUST implement is similar to the one above, except only
the named properties will be selected and all booked and non-
booked components will be selected that have a DTSTART from
Feb 1st to Feb 10th.
BEGIN:VQUERY
QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT
WHERE DTSTART >= '20000201T000000Z'
AND DTSTART <= '20000210T235959Z'
END:VQUERY
5.1.8. Find all Components with an Alarm Within the
Specified 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
EXPAND:TRUE
QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
WHERE VALARM.TRIGGER >= '20000101T030405Z'
AND VALARM.TRIGGER <= '20001231T235959Z'
AND METHOD = 'CREATE'
END:VQUERY
6. Access Rights 6. Access Rights
Access rights within CAP are specified with the "VCAR" calendar Access rights within CAP are specified with the "VCAR"
component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" calendar component, "RIGHTS" value type and the "GRANT",
component properties. "DENY" and "CARID" component properties.
Individual calendar access rights MUST be specifically granted to an Individual calendar access rights MUST be specifically
authenticated calendar user (i.e., UPN); all rights are denied unless granted to an authenticated calendar user (i.e., UPN); all
specifically granted. rights are denied unless specifically granted.
Properties within a VCAR must be evaluated in the order provided. Properties within a VCAR must be evaluated in the order
provided.
6.1. VCAR Inheritance 6.1. VCAR Inheritance
Calendar access rights specified in a calendar store are inherited as Calendar access rights specified in a calendar store are
default calendar access rights for any calendar in the parent calendar inherited as default calendar access rights for any calendar
store. Likewise, any calendar access rights specified in a root calendar in the parent calendar store. Likewise, any calendar access
are inherited as default calendar access rights for any sub- calendar to rights specified in a root calendar are inherited as default
the root calendar. By implication, calendar access rights specified in a calendar access rights for any sub- calendar to the root
sub-calendar are inherited as default calendar access rights for any calendar. By implication, calendar access rights specified
calendars that are hierarchically below the sub- calendar. in a sub-calendar are inherited as default calendar access
rights for any calendars that are hierarchically below the
sub- calendar.
Calendar access rights specified in a calendar override any default Calendar access rights specified in a calendar override any
calendar access rights. Calendar access rights specified within a sub- default calendar access rights. Calendar access rights
calendar override any default calendar access rights. specified within a sub-calendar override any default
calendar access rights.
6.2. Access Control and NOCONFLICT 6.2. Access Control and NOCONFLICT
The TRANSP property can take on values (TRANSPARENT-NOCONFLICT, OPAQUE- The TRANSP property can take on values (TRANSPARENT-
NOCONFLICT) that prohibit other events from overlapping it. This setting NOCONFLICT, OPAQUE-NOCONFLICT) that prohibit other events
overrides access While access control may allow a UPN to store an event from overlapping it. This setting overrides access While
on a particular calendar. , the CONFLICTS Calendar or component setting access control may allow a UPN to store an event on a
may prevent it, returning an error code "6.3" particular calendar. , the CONFLICTS Calendar or component
setting may prevent it, returning an error code "6.3"
Mansour/Dawson/Royer/Taler/Hill 28 Expires September 2000
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. The descriptions below, are described by function, not by
precise syntax of command arguments is described in the Formal Syntax syntax. The precise syntax of command arguments is described
section. in the Formal Syntax section.
Some commands cause specific server data to be returned; these are Some commands cause specific server data to be returned;
identified by "Data:" in the command descriptions below. See the these are identified by "Data:" in the command descriptions
response descriptions in the Responses section for information on these below. See the response descriptions in the Responses
responses, and the Formal Syntax section for the precise syntax of these section for information on these responses, and the Formal
responses. Syntax section for the precise syntax of these responses.
The "Result:" in the command description refers to the possible status The "Result:" in the command description refers to the
responses to a command, and any special interpretation of these status possible status responses to a command, and any special
responses. interpretation of 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 command MAY where <command> is a command listed in the table above. A
have arguments. Arguments are defined in the detailed command command MAY have arguments. Arguments are defined in the
definitions below. detailed command definitions below.
Responses to commands have the following general form: Responses to commands have the following general form:
responseCode [sep transportDescr sep [applicationDescr]] responseCode [sep transportDescr sep [applicationDescr]]
CRLF "." CRLF CRLF "." CRLF
In the examples below, lines preceded with "S:" refer to the sender and In the examples below, lines preceded with "S:" refer to the
lines preceded with "R:" refer to the receiver. Lines in which the first sender and lines preceded with "R:" refer to the receiver.
non-whitespace character is a "#" are editorial comments and are not Lines in which the first non-whitespace character is a "#"
part of the protocol. are editorial comments 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
Result: 2.0 - success. Result: 2.0 - success.
8.1 - server too busy 8.1 - server too busy
Upon session startup, the server sends a response of 2.0 to indicate Upon session startup, the server sends a response of 2.0 to
that it is ready to receive commands. A response of 8.1 indicates that indicate that it is ready to receive commands. A response of
the server is too busy to accept the connection. In addition, the 8.1 indicates that the server is too busy to accept the
connection. In addition, the general capabilities of the CS
Mansour/Dawson/Royer/Taler/Hill 29 Expires September 2000 are reported in the response from the CS. These capabilities
general capabilities of the CS are reported in the response from the CS. may be different than those reported in the authenticated
These capabilities may be different than those reported in the state.
authenticated state.
The supported authentication mechanisms. There may be 1 or more.
CAPVERSION
IRIPVERSION
7.1.2. ABORT Command 7.1.2. ABORT Command
Arguments: none 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 whose latency The ABORT command is issued by the CUA to stop a command. A
time has been exceeded. When the latency time is specified on the common usage could be to ABORT a command whose latency time
SENDATA command, the CS must issue a reply to the CUA within the has been exceeded. When the latency time is specified on the
specified time. It may be a reply code indicating that the CS has not SENDATA command, the CS must issue a reply to the CUA within
yet processed the request. The CUA must then tell the server whether to the specified time. It may be a reply code indicating that
continue or abort. the CS has not yet processed the request. The CUA must then
tell the server whether to continue or abort.
The CUA can issue the ABORT command at any time after the SENDATA The CUA can issue the ABORT command at any time after the
command has been completed but before receiving a reply. SENDATA command has been completed but before receiving a
reply.
If CMDID is supplied then the command identified by CMDID is
aborted.
If CMDID is not supplied then the fist command that is still
pending is aborted.
7.1.3. 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 2.0 - Authenticate completed, now in authenticated
state. state.
6.0 - Failed authentication. 6.0 - Failed authentication.
6.1 - Authorization identity refused. 6.1 - Authorization identity refused.
6.2 - Sender aborted authentication, authentication 6.2 - Sender aborted authentication, authentication
exchange cancelled. exchange cancelled.
6.3 - Unsupported Authentication Mechanism. 6.3 - Unsupported Authentication Mechanism.
6.x - Temporary failure (back end authentication 6.4 - Temporary failure (back end authentication
server down). server down).
6.x - Authentication exchange cancelled. 6.5 - Authentication exchange cancelled.
6.x - Authentication mechanism too weak. 6.6 - Authentication mechanism too weak.
6.7 - Encryption required.
Mansour/Dawson/Royer/Taler/Hill 30 Expires September 2000 6.8 - Pass phrase expired. The pass phrase was
6.x - Encryption required.
6.x - Pass phrase expired. The pass phrase was
correct but expired. The user will have to correct but expired. The user will have to
contact a pass phrase change server prior to contact a pass phrase change server prior to
authenticating. authenticating.
6.x - The user is valid but the server does not 6.9 - The user is valid but the server does not
have an entry in the authentication database have an entry in the authentication database
for the requested mechanism (e.g., DIGEST- for the requested mechanism (e.g., DIGEST-
MD5). If the user successfully authenticates MD5). If the user successfully authenticates
using a plain text password, then the back using a plain text password, then the back
end back end entry will be updated. Note end back end entry will be updated. Note
that if the client chooses to fall back to that if the client chooses to fall back to
plain text password authentication it should plain text password authentication it should
enable an encryption layer or get user-con- enable an encryption layer or get user-con-
firmation that a one-time transition is ac- firmation that a one-time transition is ac-
ceptable. ceptable.
6.x - User account disabled. The user will have to 6.10 - User account disabled. The user will have to
contact the system administrator to get the contact the system administrator to get the
account re-enabled. account re-enabled.
9.1 - Unexpected command. 9.1 - Unexpected command.
The capabilities of the CS in the authenticated state are reported in The capabilities of the CS in the authenticated state are
the response from the CS. These may be different than the capabilities reported in the response from the CS. These may be different
in the Connected, but unauthenticated state. than the capabilities in the Connected, but unauthenticated
state.
The AUTHENTICATE command is used by the CUA to identify the user to the The AUTHENTICATE command is used by the CUA to identify the
CS. CAP supports a number of authentication methods, the [SASL] user to the CS. CAP supports a number of authentication
specification for authentication is the preferred method. methods, the SASL specification for authentication is the
preferred method.
If STARTTLS is negotiated prior to the AUTHENTICATE command, the client If STARTTLS is negotiated prior to the AUTHENTICATE command,
MUST discard all information about the CS capabilities fetched prior to the client MUST discard all information about the CS
the TLS negotiation. In particular, the value of supported SASL capabilities fetched prior to the TLS negotiation. In
Mechanisms MAY be different after TLS has been negotiated. particular, the value of supported SASL Mechanisms MAY be
different after TLS has been negotiated.
If a SASL security layer is negotiated, the client MUST discard all If a SASL security layer is negotiated, the client MUST
information about the CS capabilities fetched prior to SASL. In discard all information about the CS capabilities fetched
particular, if the client is configured to support multiple SASL prior to SASL. In particular, if the client is configured
mechanisms, it SHOULD fetch supported SASL Mechanisms both before and to support multiple SASL mechanisms, it SHOULD fetch
after the SASL security layer is negotiated and verify that the value supported SASL Mechanisms both before and after the SASL
has not changed after the SASL security layer was negotiated. This security layer is negotiated and verify that the value has
detects active attacks which remove supported SASL mechanisms from the not changed after the SASL security layer was negotiated.
supported SASL Mechanisms list. This detects active attacks which remove supported SASL
mechanisms from the supported SASL Mechanisms list.
<initial data> is an optional parameter which can be used for mechanisms <initial data> is an optional parameter which can be used
which require an initial response from the CUA. for mechanisms which require an initial response from the
CUA.
The AUTHENTICATE command is followed by an authentication protocol The AUTHENTICATE command is followed by an authentication
exchange, in the form of a series of CS challenges and CUA responses, protocol exchange, in the form of a series of CS challenges
per the relevant RFC that describes the specific SASL mechanism being and CUA responses, per the relevant RFC that describes the
used. specific SASL mechanism being used.
Mansour/Dawson/Royer/Taler/Hill 31 Expires September 2000 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 the CS If a security layer was negotiated it comes into effect for
starting with the first octet transmitted after the CRLF which follows the CS starting with the first octet transmitted after the
the 2.0 reply code, and for the CUA starting with the first octet after CRLF which follows the 2.0 reply code, and for the CUA
the CRLF of its last response in the authentication exchange. Encrypted starting with the first octet after the CRLF of its last
data is transmitted as described in [SASL]. response in the authentication exchange. Encrypted data is
transmitted as described in SASL.
The service name specified by this protocol's profile of SASL is "cap". The service name specified by this protocol's profile of
[Note: this must be registered with IANA, has anyone done this yet?] SASL is "cap". [EDITORS NOTE: this must be registered with
IANA, has anyone done this yet?]
The result of the AUTHENTICATE command includes data indicating the The result of the AUTHENTICATE command includes data
identity which has been assigned to the session, derived from the indicating the identity which has been assigned to the
supplied authentication credentials, and/or authorization identifier. A session, derived from the supplied authentication
CAP session does not have an identity until the CUA has issued the credentials, and/or authorization identifier. A CAP session
does not have an identity until the CUA has issued the
"AUTHENTICATE" command. "AUTHENTICATE" command.
The CUA may not issue the "AUTHENTICATE" command multiple times, even if The CUA may not issue the "AUTHENTICATE" command multiple
the first attempt was aborted. If a CUA attempts to do this the CS must times, even if the first attempt was aborted. If a CUA
terminate the session. attempts to do this the CS must terminate the session.
Data returned in response to a successful login is:
The following examples illustrate the various possibilities for an Here is an example of a successful authentication:
authentication protocol exchange.
Here are examples of a successful authentication:
C: AUTHENTICATE KERBEROS_V4 C: AUTHENTICATE KERBEROS_V4
S: AmFYig== S: AmFYig==
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; charset=US-ASCII S: Content-Type:text/calendar; method=REQUEST; charset=US-
ASCII
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: PRODID:-//ACME/CAPserver//EN S: PRODID:-//ACME/CAPserver//EN
S: VERSION:2.1 S: VERSION:2.1
S: IDENTITY=bill@example.com S: IDENTITY=bill@example.com
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: CAR=CAR-FULL-1 S: CAR=CAR-FULL-1
skipping to change at line 1743 skipping to change at page 1, line 2020
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: CAR=CAR-FULL-1 S: CAR=CAR-FULL-1
S: MINDATE=19700101T000000Z S: MINDATE=19700101T000000Z
S: MAXDATE=20370201T000000Z S: MAXDATE=20370201T000000Z
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
Mansour/Dawson/Royer/Taler/Hill 32 Expires September 2000
This example shows a failed authentication: This example shows a failed authentication:
C: AUTHENTICATE KERBEROS_V4 C: AUTHENTICATE KERBEROS_V4
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 that "the RFC-2245 defines the Anonymous SASL mechanism. This RFC
mechanism consists of a single message from the client to the server. states that "the mechanism consists of a single message from
The client sends optional trace information in the form of a human the client to the server. The client sends optional trace
readable string. The trace information should take one of three forms: information in the form of a human readable string. The
an Internet email address, an opaque string which does not contain the trace information should take one of three forms: an
'@' character and can be interpreted by the system administrator of the Internet email address, an opaque string which does not
client's domain, or nothing. For privacy reasons, an Internet email contain the '@' character and can be interpreted by the
address should only be used with permission from the user." system administrator of the client's domain, or nothing. For
privacy reasons, an Internet email address should only be
used with permission from the user."
RFC-2245 goes on to state, "A client which uses the user's correct email RFC-2245 goes on to state, "A client which uses the user's
address as trace information without explicit permission may violate correct email address as trace information without explicit
that user's privacy." Information about who accesses an anonymous CS on permission may violate that user's privacy." Information
a sensitive subject (e.g., AA meeting times and locations) has strong about who accesses an anonymous CS on a sensitive subject
privacy needs. "Clients should not send the email address without (e.g., AA meeting times and locations) has strong privacy
explicit permission of the user and should offer the option of supplying needs. "Clients should not send the email address without
no trace token -- thus only exposing the source IP address and time." explicit permission of the user and should offer the option
of supplying no trace token -- thus only exposing the source
IP address and time."
Example of CUA using the Capability command followed by an anonymous Example of CUA using the Capability command followed by an
authentication: anonymous 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, a CUA will Subsequent to the initial Anonymous Authentication with a
have to provide a UPN for some CAP operations. For anonymous access the CS, a CUA will have to provide a UPN for some CAP
UPN that MUST be used by the CUA is "@", a UPN with a null username and operations. For anonymous access the UPN that MUST be used
null realm. The user's normal UPN MUST not be used for the subsequent by the CUA is "@", a UPN with a null username and null
CAP operations. realm. The user's normal UPN MUST not be used for the
subsequent CAP operations.
Mansour/Dawson/Royer/Taler/Hill 33 Expires September 2000 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 not However, this UPN will not appear on the wire after the
appear on the wire after the initial SASL anonymous authentication. initial SASL anonymous authentication.
Use of the "@" UPN and wild-carding of UPNs within VCARs are
covered in
Use of the "@" UPN and wild-carding of UPNs within VCARs are covered 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
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 yields one Return the members of the argument CalID. Successful result
or more Calendars and/or Resource Calendars. More than one C or RC yields one or more Calendars and/or Resource Calendars.
returned implies that the CalID was a CC. More than one C or RC returned implies that the CalID was a
CC.
Example: Example:
Example #1: Request lookup of CSID which is a Calendar Collection 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 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 of a CSID which is a Resource Calendar Example #2: Request lookup of 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 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.0 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: 2.3 Expansion resulted in too much data
S: . S: .
Mansour/Dawson/Royer/Taler/Hill 34 Expires September 2000 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.0 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: 2.4 Lost contact with directory server
S: . S: .
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 CAPABILTY command returns information about the CAP server given the The CAPABILITY command returns information about the CAP
current state of the connection with the client. The values returned may server given the current state of the connection with the
differ depending on whether the connection is in the Connected or the client. The values returned may differ depending on whether
Authenticated state. The return values may also be different for a the connection is in the Connected or the Authenticated
secure versus a non-secure connection. state. The return values may also be different for a secure
versus a non-secure connection.
Client implementations SHOULD NOT require any capability name beyond Client implementations SHOULD NOT require any capability
those defined in this specification, and MAY ignore any non-standard, name beyond those defined in this specification, and MAY
experimental capability names. Non-standard capability names are ignore any non-standard, experimental capability names. Non-
prefixed with the text "X-". The prefix SHOULD also include a short standard experimental capability names MUST be prefixed with
character vendor identifier For example, "X-FOO-BARCAPABILITY", for the the text "X-". The prefix SHOULD also include a short
non-standard "BARCAPABILITY" capability of the implementor "FOO". This character vendor identifier For example, "X-FOO-
command may return different results in the Connected state versus the BARCAPABILITY", for the non-standard "BARCAPABILITY"
Authenticated state. It may also return different results depending on capability of the implementor "FOO". This command may return
the UPN. different results in the Connected state versus the
Authenticated state. It may also return different results
depending on the UPN.
Capability Occurs Description Capability Occurs Description
----------------------------------------------------------------------- -------------------------------------------------------
CAPrev1 1 Revision of CAP, must be "CAPrev1" AUTH 1+ The authentication mechanisms
supported. Implementations MUST
implement at least
IRIPrev1 0 or 1 Revision of IRIP, MAY be present. If CAPVERSION 1 Revision of CAP, MUST include at
present, it MUST be "IRIPrev1" least "1.0". Comma separated
values.
CAR 0 or 1 Indicates level of CAR support CAR-MIN ITIPVERSION 0 or 1 Revision of ITIP, MAY be present.
or CAR-FULL-1 If present, it MUST include at
least "1.0"
CAR 0 or 1 Indicates level of CAR support.
CAR-MIN or CAR-FULL-1. If not
specified the default is
CAR-FULL-1. Implementations
MUST implement CAR-MIN.
Implementations MAY implement
CAR-FULL-1.
Mansour/Dawson/Royer/Taler/Hill 35 Expires September 2000 QUERYLEVEL 0 or 1 Indicates level of SQL support.
MAXICALOBJECTSIZE 0 or 1 An integer value that specifies The SQL-MIN or SQL-92. If not
largest ICAL object the server will ac- specified the default is SQL-92.
cept in bytes. Objects larger than this Implementations MUST implement
will be rejected. A value of zero (0) SQL-MIN. Implementations MAY
indicates unlimited. implement SQL-92.
MAXDATE 0 or 1 The datetime value beyond which the MAXICALOBJECTSIZE
server cannot accept. 0 or 1 An integer value that specifies
The largest ICAL object the server
will accept in bytes. Objects
larger than this will be rejected.
A value of zero (0) indicates
unlimited. The default is zero (0)
if not specified.
MAXCALIDEXPANDLIST 0 or 1 An integer value that specifies the max- MAXDATE 0 or 1 The datetime value in GMT beyond
imum number of CalIDs that can be re- which the server cannot accept. If
turned by the CALIDEXPAND Command. A not specified the default is
value of zero (0) indicates unlimited. 99991231T235959Z.
MAXUPNEXPANDLIST 0 or 1 An integer value that specifies the max- MAXCALIDEXPANDLIST
imum number of UPNs that can be returned 0 or 1 An integer value that specifies
by the UPNEXPAND Command. A value of the maximum number of CalIDs that
zero (0) indicates unlimited. can be returned by the CALIDEXPAND
Command. A value of zero (0)
indicates unlimited which is the
default if not specified.
MINDATE 0 or 1 The datetime value prior to which the MAXUPNEXPANDLIST
server cannot accept. 0 or 1 An integer value that specifies
the maximum number of UPNs that
can be returned by the UPNEXPAND
Command. A value of zero (0)
indicates unlimited which is the
default if not specified.
MINDATE 0 or 1 The datetime value prior to which
the server cannot accept. If not
specified the default is
00000101T000000Z.
PIPELINE 0 or 1 An integer value that specifies
the maximum number of commands a
CUA may send without the CUA
waiting for a reply from the CS.
If not specified, the default
value is one (1). A value of zero
(0)indicates unlimited.
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
skipping to change at line 1934 skipping to change at page 1, line 2274
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 SENDATA The CONTINUE command is issued by the client in response to
timeout. When a timeout value is specified on the SENDDATA command, the a SENDATA timeout. When a timeout value is specified on the
server must issue a reply to the client within the specified time. If SENDDATA command, the server must issue a reply to the
the latency time has elapsed prior to the server completing the command client within the specified time. If the latency time has
it returns a timeout response code. If the client wants the server to elapsed prior to the server completing the command it
continue processing the command it responds with the CONTINUE command. returns a timeout response code. If the client wants the
server to continue processing the command it responds with
If latencyTime is present, it must be a positive integer that specifies the CONTINUE command.
Mansour/Dawson/Royer/Taler/Hill 36 Expires September 2000 If latencyTime is present, it must be a positive integer
the maximum number of seconds the client will wait for the next that specifies the maximum number of seconds the client will
response. If it is omitted, the receiver waits an indefinite period of wait for the next response. If it is omitted, the receiver
time for the response. waits an indefinite period of time for the response.
In this example, the client requests a response from the server every 10 In this example, the client requests a response from the
seconds. server every 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:VCALENDAR C: BEGIN:VCALENDAR
# etc # etc
C: END:VCALENDAR C: END:VCALENDAR
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; Method=RESPONSE;Component=VDATA; S: Content-type:text/calendar;
Method=RESPONSE;Component=VDATA;
S: Optinfo=VERSION:2.1 S: Optinfo=VERSION:2.1
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
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:VCALENDAR S: END:VCALENDAR
S: . S: .
7.1.7. DISCONNECT Command 7.1.7. DISCONNECT Command
Arguments: none Arguments: none
skipping to change at line 1984 skipping to change at page 1, line 2327
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 connection. The DISCONNECT command is used by a client to terminate a
It always succeeds. connection. It always succeeds.
The CUA MUST wait for the CS 2.0 reply to ensure that TCP/IP
(which knows nothing about CAP) can be sure the connection
should go away. This avoids the CS connection being stuck in
TCP-WAIT state.
Example: Example:
C: DISCONNECT C: DISCONNECT
# [ed. Note: should the client now wait for a response from the # [ed. Note: should the client now wait for a response
server from the server before disconnecting? ]
# before disconnecting? ]
S: 2.0 S: 2.0
S: . S: .
S: . S: .
Mansour/Dawson/Royer/Taler/Hill 37 Expires September 2000
C: <drops connection>
S: <drops connection> S: <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
6.4 Identity not permitted .4 Identity not permitted
The "IDENTIFY" command allows the CUA to select a new identity to be The "IDENTIFY" command allows the CUA to select a new
used for calendar access. This command may only be called in the identity to be used for calendar access. This command may
Identified State. only be called in the Identified State.
The CS determines through an internal mechanism if the credentials The CS determines through an internal mechanism if the
supplied at authentication permit the assumption of the selected the credentials supplied at authentication permit the assumption
identity. If they do the session assumes the new identity, otherwise a of the selected the identity. If they do the session assumes
security error is returned. the new identity, otherwise a security error is returned.
7.1.9. 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 <CRLF>.<CRLF> Result: 2.0.1 - Server will now accept input until
is encountered. <CRLF>.<CRLF> is encountered.
The SENDDATA command is used to send calendar requests and commands to The SENDDATA command is used to send calendar requests and
the server. After a response code of 2.0.1 is issued the CUA sends a commands to the server. After a response code of 2.0.1 is
MIME encapsulated iCalendar object to the server. The end of this MIME issued the CUA sends a [MIME] encapsulated iCalendar object
data is signaled by the special sequence <CRLF>.<CRLF> . to the server. The end of this [MIME] data is signaled by
the special sequence <CRLF>.<CRLF> .
7.1.10. STARTTLS Command 7.1.10. STARTTLS Command
Arguments: None Arguments: None
Data: None Data: None
Result: 2.0 Result: 2.0
5 TLS not supported
6.5 TLS not supported The "STARTTLS" command is issued by the CUA to indicate to
the CS that it wishes to negotiate transport level security
The "STARTTLS" command is issued by the CUA to indicate to the CS that using [TLS]. If the CS does not support TLS it returns
it wishes to negotiate transport level security using [TLS]. If the CS status code 6.5. If the CS supports TLS it issues an initial
does not support TLS it returns status code 6.5. If the CS supports TLS response of 2.0.12 indicating that the CUA should proceed
it issues an initial response of 2.0.12 indicating that the CUA should with TLS negotiation. Once the TLS negotiation is complete
the server returns the response code 2.0.
Mansour/Dawson/Royer/Taler/Hill 38 Expires September 2000
proceed with TLS negotiation. Once the TLS negotiation is complete the
server returns the response code 2.0.
After issuing the "STARTTLS" command the CUA issues the "AUTHENTICATE" After issuing the "STARTTLS" command the CUA issues the
command. The SASL external mechanism may be used if the CUA wishes to "AUTHENTICATE" command. The SASL external mechanism may be
use the authentication id which was used in the TLS negotiation. used if the CUA wishes to use the authentication id which
was used in the TLS negotiation.
The CUA MUST NOT issue a "STARTTLS" if it has already issued an The CUA MUST NOT issue a "STARTTLS" if it has already issued
"AUTHENTICATE" or "STARTTLS" command in this session. If a CUA does an "AUTHENTICATE" or "STARTTLS" command in this session. If
this the CS must terminate the session. a CUA does this the CS must terminate the session.
The following examples illustrate the use of the "STARTTLS" command: The following examples illustrate the use of the "STARTTLS"
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
skipping to change at line 2088 skipping to change at page 1, line 2435
Arguments: UPN Arguments: UPN
Data: no specific data for this command Data: no specific data for this command
Result: 2.0 - success Result: 2.0 - success
2.1 Permission Denied 2.1 Permission Denied
2.2 Requested UPN not found 2.2 Requested UPN not found
2.3 Result exceeds MAXUPNEXPANDLIST 2.3 Result exceeds MAXUPNEXPANDLIST
2.4 Misc. UPNEXPAND error 2.4 Misc. UPNEXPAND error
Return the members of the argument UPN. Successful result yields one or Return the members of the argument UPN. Successful result
more CalIDs. More than one CalID returned implies that the UPN was a yields one or more CalIDs. More than one CalID returned
UG. implies that the UPN was a UG.
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 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
Mansour/Dawson/Royer/Taler/Hill 39 Expires September 2000
C: UPNEXPAND group@example.com C: UPNEXPAND group@example.com
S: 2.0 group@example.com S: 2.0 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.0 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: 2.3 Lookup resulted in too much data
S: . S: .
Example #4: CS loses contact with directory server during UPNEXPAND Example #4: CS loses contact with directory server during
UPNEXPAND
C: UPNEXPAND group@example.com C: UPNEXPAND group@example.com
S: 2.0 group@example.com S: 2.0 group@example.com
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: 2.4 Lost contact with directory server
S: . 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 CAP. The following methods provide a set of calendaring commands
Calendaring commands (or methods) allow a CU to directly manipulate a in CAP. Calendaring commands (or methods) allow a CU to
calendar. directly manipulate a calendar.
Calendar access rights can be granted for the more generalized access Calendar access rights can be granted for the more
provided by the calendar commands. generalized access provided by the calendar commands.
Restriction Tables
Commands are sent to CAP servers encapsulated in iCalendar
objects. The reply to these commands are also encapsulated
in iCalendar objects. The restriction tables listed in the
commands below describe the composition of the iCalendar
data for these commands and replies.
The Presence column uses the following values to assert
whether a property is required, is optional and the number
of times it may appear in the iCalendar object. A Comment
may be provided to further clarify the presence criteria.
The table below defines the values for the Presence column.
Presence Value Description
-----------------------------------------------------------
1 One instance MUST be present
1+ At least one instance MUST be present
0 Instances of this property Must NOT be present
0+ Multiple instances MAY be present
0 or 1 Up to 1 instance of this property MAY be present
----------------------------------------------------------
While the tables list every component and property, their
purpose is not to define the meaning of the component or
property.
There will be a RESPONSE-STATUS for each VCALENDAR and
component created, modified, deleted, or requested. The
number of RESPONSE-STATUS values returned MUST be equal to
the number of TARGETS times the number of objects in the
command. The responses MUST be ordered first by TARGET then
by the order of the objects as supplied in the command.
7.2.1.1. CREATE Method 7.2.1.1. 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 - 6.3 -
Bad args Bad args
Mansour/Dawson/Royer/Taler/Hill 40 Expires September 2000 The CREATE method is used to create a new iCalendar object
The CREATE method is used to create a new iCalendar object of type of type objtype. The property TARGET specifies the
objtype. The property TARGET specifies the container(s) for the create. container(s) for the create. The type of object wrapped
The type of object wrapped inside of the VCALENDAR/CREATE object is the inside of the VCALENDAR/CREATE object is the object type(s)
object type(s) being created. When creating a new calendar at the top being created. When creating a new calendar at the top
level, the CSID is specified. Otherwise the container will be a CalID. level, the CSID is specified. Otherwise the container will
be a CalID.
Restriction table
Component/Property Presence Comment
------------------- ---------------------------------
VCAP 1+ The CUA can send up
PIPELINE commands
without processing a
response
. CMDID 0 or 1 If CMDID is not supplied,
then there must not be
pending replies to previous
command.
. VERSION 1 MUST be 2.0
. [IANA-PROP] 0+ any IANA registered
property
. VCOMMAND 1 MUST at least one container
(VCALENDAR, VCAR, VQUERY,
VEVENT, VTODO, VJOURNAL)
. . [IANA-PROP] 0+ any IANA registered
property
. . METHOD 1 MUST be CREATE.
. . TARGET 1+ MUST be the CSID or CALID
. . VCALENDAR 0+
. . . CALMASTER 0 or 1
. . . NAME 0 or 1
. . . OWNER 1+
. . . RELCALID 1
. . . TZID 0 or 1
. . . [IANA-PROP] 0+ any IANA registered
property
. . VCAR 0+
. . . CARID 0 or 1
. . . DENY 0+ Note, there must be at
least one GRANT or DENY
within the VCAR.
. . . GRANT 0+ Note, there must be at
least one GRANT or DENY
within the VCAR.
. . . [IANA-PROP] 0+ any IANA registered
property
. . VQUERY 0+
. . . EXPAND 0 or 1
. . . MAXRESULTS 0 or 1
. . . MAXSIZE 0 or 1
. . . QUERYNAME 1
. . . QUERY 1
. . . [IANA-PROP] 0+ any IANA registered
property
. . VEVENT 0+
. . . ATTENDEE 0+
. . . SEQUENCE 0 or 1 MUST be present if value is
greater than 0,
MAY be present if 0
. . . SUMMARY 1 Can be null
. . . UID 1
. . . ATTACH 0+
. . . CATEGORIES 0 or 1
. . . CLASS 0 or 1
. . . COMMENT 0 or 1
. . . CONTACT 0+
. . . CREATED 0 or 1
. . . DESCRIPTION 0 or 1 Can be null
. . . DTEND 0 or 1 if present DURATION MUST
NOT be present
. . . DTSTAMP 1
. . . DTSTART 1
. . . DURATION 0 or 1 if present DTEND MUST NOT
be present
. . . EXDATE 0+
. . . EXRULE 0+
. . . GEO 0 or 1
. . . LAST-MODIFIED 0 or 1
. . . LOCATION 0 or 1
. . . METHOD 1 <<placeholder. it may move
to meta-info>>
. . . ORGANIZER 1
. . . PRIORITY 0 or 1
. . . RDATE 0+
. . . RECURRENCE-ID 0 or 1 only if referring to an
instance of a recurring
calendar component.
Otherwise it MUST NOT be
present.
. . . RELATED-TO 0+
. . . REQUEST-STATUS 0+
. . . RESOURCES 0 or 1 This property MAY contain a
list of values
. . . RRULE 0+
. . . STATUS 0 or 1
. . . TRANSP 0 or 1
. . . URL 0 or 1
. . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered
property
. . . VALARM 0+
. . . . ACTION 1
. . . . ALARMID 0 or 1 MUST be 1 if multiple
VALARMs are present in
same component.
. . . . ATTACH 0+
. . . . DESCRIPTION 0 or 1
. . . . DURATION 0 or 1 if present REPEAT MUST be
present
. . . . REPEAT 0 or 1 if present DURATION MUST be
present
. . . . SUMMARY 0 or 1
. . . . TRIGGER 1
. . . . X-PROPERTY 0+
. . . . [IANA-PROP] 0+ any IANA registered property
. . VTODO 0+
. . . ATTENDEE 0+
. . . SEQUENCE 0 or 1 MUST be present if value is
greater than 0, MAY be
present if 0
. . . SUMMARY 1 Can be null.
. . . UID 1
. . . ATTACH 0+
. . . CATEGORIES 0 or 1 This property may contain a
list of values
. . . CLASS 0 or 1
. . . COMMENT 0 or 1
. . . CONTACT 0+
. . . CREATED 0 or 1
. . . DESCRIPTION 0 or 1 Can be null
. . . DTSTAMP 1
. . . DTSTART 1
. . . DUE 0 or 1 If present DURATION MUST NOT
be present
. . . DURATION 0 or 1 If present DUE MUST NOT be
present
. . . EXDATE 0+
. . . EXRULE 0+
. . . GEO 0 or 1
. . . LAST-MODIFIED 0 or 1
. . . LOCATION 0 or 1
. . . METHOD 1 <<placeholder. it may move
to meta-info>>
. . . ORGANIZER 1
. . . PRIORITY 1
. . . PERCENT-COMPLETE 0 or 1
. . . RDATE 0+
. . . RECURRENCE-ID 0 or 1 MUST only if referring to an
instance of a recurring
calendar component.
Otherwise it MUST NOT be
present.
. . . RELATED-TO 0+
. . . REQUEST-STATUS 0
. . . RESOURCES 0 or 1 This property may contain a
list of values
. . . RRULE 0+
. . . STATUS 0 or 1 MAY be one of COMPLETED,
NEEDS-ACTION,
IN-PROCESS, CANCELLED
. . . URL 0 or 1
. . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered property
. . . VALARM 0+
. . . . ACTION 1
. . . . ALARMID 0 or 1 MUST be 1 if multiple
VALARMs are present in
same component.
. . . . ATTACH 0+
. . . . DESCRIPTION 0 or 1
. . . . DURATION 0 or 1 if present REPEAT MUST be
present
. . . . REPEAT 0 or 1 if present DURATION MUST be
present
. . . . SUMMARY 0 or 1
. . . . TRIGGER 1
. . . . X-PROPERTY 0+
. . . . [IANA-PROP] 0+ any IANA registered property
. . VJOURNAL 0+
. . . ATTENDEE 0
. . . DESCRIPTION 1 Can be null.
. . . DTSTAMP 1
. . . DTSTART 1
. . . ORGANIZER 1
. . . UID 1
. . . ATTACH 0+
. . . CATEGORIES 0 or 1 This property MAY contain a
list of values
. . . CLASS 0 or 1
. . . COMMENT 0 or 1
. . . CONTACT 0+
. . . CREATED 0 or 1
. . . EXDATE 0+
. . . EXRULE 0+
. . . LAST-MODIFIED 0 or 1
. . . METHOD 1 <<placeholder. it may move
to meta-info>>
. . . RDATE 0+
. . . RECURRENCE-ID 0 or 1 MUST only if referring to
an instance of a recurring
calendar component.
Otherwise it MUST NOT be
present.
. . . RELATED-TO 0+
. . . RRULE 0+
. . . SEQUENCE 0 or 1 MUST be present if
non-zero. MAY be
present if zero.
. . . STATUS 0 or 1
. . . SUMMARY 0 or 1 Can be null
. . . URL 0 or 1
. . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered
property
. . VFREEBUSY 0
. . VTIMEZONE 0+ MUST be present if any
date/time refers to a
timezone
. . . DAYLIGHT 0+ MUST be one or more of
either STANDARD or
DAYLIGHT
. . . . . COMMENT 0 or 1
. . . . . DTSTART 1
. . . . . RDATE 0+ if present RRULE MUST NOT
be present
. . . . . RRULE 0+ if present RDATE MUST NOT
be present
. . . . . TZNAME 0 or 1
. . . . . TZOFFSET 1
. . . . . TZOFFSETFROM 1
. . . . . TZOFFSETTO 1
. . . . . X-PROPERTY 0+
. . . . . [IANA-PROP] 0+ any IANA registered
property
. . . LAST-MODIFIED 0 or 1
. . . STANDARD 0+
. . . . . COMMENT 0 or 1
. . . . . DTSTART 1
. . . . . RDATE 0+ if present RRULE MUST NOT
be present
. . . . . RRULE 0+ if present RDATE MUST NOT
be present
. . . . . TZNAME 0 or 1
. . . . . TZOFFSETFROM 1
. . . . . TZOFFSETTO 1
. . . . . X-PROPERTY 0+
. . . . . [IANA-PROP] 0+ any IANA registered property
. . . TZID 1
. . . TZURL 0 or 1
. . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered property
Server Restriction Table for the CREATE command
Component/Property Presence Comment
------------------- -------- ---------------------------
VCAP 1+
. VCALENDAR 1+
. . TARGET 1
. . VERSION 1 MUST be 2.0
. . CMDID 0 or 1 MUST be returned if the
request contained
a CMDID
. . RESPONSE-STATUS 0 if not creating a calendar
1+ if creating a calendar
. . . VCAR 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VCAR properties
are present
.
. . . VCOMMAND 0
. . . VEVENT 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VEVENT properties
are present
. . . . VALARM 0 if VEVENT was successfully
saved
1+ if there were errors saving
alarms
. . . . . RESPONSE-STATUS 1+
. . . VFREEBUSY 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VFREEBUSY
properties are present
. . . VJOURNAL 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VJOURNAL
properties are present
. . . VQUERY 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VQUERY properties
are present
. . . VTODO 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VTODO properties
are present
. . . . VALARM 0 if VTODO was successfully
saved
1+ if there were errors saving
alarms
. . . . . RESPONSE-STATUS 1+
7.2.1.1.1. Creating New Calendars 7.2.1.1.1. Creating New Calendars
Example to create a new calendar named "Bill's Soccer Team" in several Example to create two new calendars different containers. In
different containers. In the following example, the client is in the the following example, the client is in the Authenticated
Authenticated state with CS cal.example.com. state with CS cal.example.com.
C: SENDDATA C: SENDDATA
C: CONTENT-TYPE: text/calendar;method=CREATE;component=VCOMMAND C: CONTENT-TYPE:
text/calendar;method=CREATE;component=VCOMMAND
C: Content-Transfer-Encoding:7bit C: Content-Transfer-Encoding:7bit
C: C:
C: BEGIN:VCALENDAR C: BEGIN:VCALENDAR
C: VERSION:2.1 C: VERSION:2.1
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: METHOD:CREATE C: METHOD:CREATE
C: TARGET:cap://cal.example.com/ C: TARGET:cap://cal.example.com/
C: TARGET:relcal4 C: TARGET:relcal4
C: TARGET://bobo.ex.com/
C: TARGET:relcal5
C: TARGET:cap://cal.example.com/relcal8
C: TARGET:relcal9
C: BEGIN:VCALENDAR C: BEGIN:VCALENDAR
C: RELCALID:relcalz C: RELCALID:relcalz1
C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Bill's Soccer Team C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Bill's Soccer Team
C: OWNER:bill C: OWNER:bill
C: OWNER:mary
C: CALMASTER:mailto:bill@example.com C: CALMASTER:mailto:bill@example.com
C: TZID:US_PST C: TZID:US_PST
C: BEGIN:VCAR C: BEGIN:VCAR
C: CARID:12345 C: CARID:12345
C: GRANT:UPN=bill;ACTION=*;OBJECT=* C: GRANT:UPN=bill;ACTION=*;OBJECT=*
C: GRANT:UPN=mary;ACTION=read;OBJECT=* C: END:VCAR
C: END:VCALENDAR
C: BEGIN:VCALENDAR
C: RELCALID:relcalz2
C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Mary's personal
calendar
C: OWNER:mary
C: CALMASTER:mailto:mary@example.com
C: TZID:US_PST
C: BEGIN:VCAR
C: CARID:12346
C: GRANT:UPN=mary;ACTION=*;OBJECT=*
C: END:VCAR C: END:VCAR
C: END:VCALENDAR C: END:VCALENDAR
C: END:VCOMMAND C: END:VCOMMAND
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
S: 6.0 cap://cal.example.com/ S: 2.0
S: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/relcalz S: Content-Type:text/calendar; method=RESPONSE;
S: 3.1.4 cap://bobo.ex.com/ OPTINFO="CMDID:abcde"
S: 6.2 cap://cal.example.com/relcal5 # This 2.0 is the transport reply status and ends with a
S: 3.1.5 cap://cal.example.com/relcal8 CRLF.CRLF (below)
S: 7.0 cap://cal.example.com/relcal9 S: BEGIN:VCALENDAR
S: METHOD:RESPONSE
If the example above, the Relative CALID is specified. The values for S: TARGET:cap://cal.example.com/
this property must be unique on a CS. That is the reason for the 3.1.5 S: REQUEST-STATUS:2.0
error response. S: END:VCALENDAR
S: BEGIN:VCALENDAR
Mansour/Dawson/Royer/Taler/Hill 41 Expires September 2000 S: METHOD:RESPONSE
In the example below, the Relative CalID is not specified. So, the CAP S: REQUEST-STATUS:2.0
server will generate one for each calendar successfully created. The S: END:VCALENDAR
value of the Relative CalID appears as the second parameter on the S: .
response code.
S: 6.0 cap://cal.example.com/
S: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/rand123
S: 3.1.4 cap://bobo.ex.com/
S: 6.2 cap://cal.example.com/relcal5
S: 3.1.4 cap://cal.example.com/relcal8
S: 2.0 cap://cal.example.com/relcal9 cap://cal.example.com/rand456
Example to create a new component. Example to create a new component.
C: SENDDATA C: SENDDATA
C: Content-Type:text/calendar; method=CREATE; charset=US-ASCII C: Content-Type:text/calendar; method=CREATE; charset=US-
ASCII
C: Content-Transfer-Encoding:7bit C: Content-Transfer-Encoding:7bit
C: C:
C: BEGIN:VCALENDAR C: BEGIN:VCALENDAR
C: VERSION:2.1 C: VERSION:2.1
C: CMDID:abcde C: CMDID:abcde
C: METHOD:CREATE C: METHOD:CREATE
C: TARGET:cap://cal.foo.com/relcal1 C: TARGET:cap://cal.example.com/relcal1
C: TARGET:relcal2 C: TARGET:relcal2
C: BEGIN:VEVENT C: BEGIN:VEVENT
C: DTSTART:19990307T180000Z
C: DTSTART:99990307T180000Z
C: UID:abcd12345 C: UID:abcd12345
C: DTEND:19990307T190000Z C: DTEND:99990307T190000Z
C: SUMMARY:Important Meeting C: SUMMARY:Important Meeting
C: END:VEVENT C: END:VEVENT
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
S: 2.0 S: 2.0
S: Content-Type:text/calendar; method=RESPONSE; OPTINFO="CMDID:abcde" S: Content-Type:text/calendar; method=RESPONSE;
OPTINFO="CMDID:abcde"
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
S: CMDID:abcde S: CMDID:abcde
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal1 abcd12345 S: TARGET::cap://cal.example.com/relcal1
S: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal2 abcd12345 S: REQUEST-STATUS:2.9
S: END:VEVENT
S: BEGIN:VEVENT
S: REQUEST-STATUS:2.9
S: REQUEST-STATUS:2.10
S: END:VEVENT S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
S: .
The responce returns the calendar (CALID) and UID of the component so The responce returns the calendar (CALID) and UID of the
that the CUA can match up the REQUEST-STATUS from multiple objects component so
created on multiple calendards (TARGETs). that the CUA can match up the TARGET from multiple objects
created on
Mansour/Dawson/Royer/Taler/Hill 42 Expires September 2000 multiple calendards (TARGETs).
7.2.1.2. DELETE Method 7.2.1.2. 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 TARGET The DELETE method is used to delete a calendar or
properties specify the container(s) for the delete. When deleting a component. The TARGET properties specify the
calendar at the top level, the CSID is specified. Otherwise the container(s) for the delete. When deleting a calendar at
the top level, the CSID is specified. Otherwise the
container will be a CalID. container will be a CalID.
Restriction Table
Component/Property Presence Comment
------------------- -------- ---------------------------
VCAP 1+ The CUA can send up
PIPELINE commands
without processing a
response
CMDID 0 or 1 If CMDID is not supplied,
then there must
not be pending replies to
previous command.
VERSION 1 MUST be 2.0
VCOMMAND 1
METHOD 1 MUST be DELETE.
TARGET 1+ MUST be a the CSID or CALID
VQUERY 0+
EXPAND 0 ?
MAXRESULTS 0 or 1 Limit the solution set to
no more than this many
entries.
MAXSIZE 0 ?
QUERYNAME 1 Name by which this query is
referenced
QUERY 1 The query
Server Restriction Table for the DELETE command
Component/Property Presence Comment
------------------- -------- -----------------------------
VCAP 1+
TARGET 1
VERSION 1 MUST be 2.0
CMDID 0 or 1 MUST be returned if the
request contained a CMDID
VCALENDAR Only if VCALENDARs were
deleted
REQUEST-STATUS 1
* 1+ No other VALARM properties
are present
VALARM 0+ Only if VALARM components
were deleted
REQUEST-STATUS 1
* 0 No other VALARM properties
are present
VCAR 0+ Only if VCAR components were
deleted
REQUEST-STATUS 1
* 0 No other VCAR properties are
present
VEVENT 0+ Only if VEVENT components
were deleted
REQUEST-STATUS 1+
* 0 No other VEVENT properties
are present
VFREEBUSY 0
REQUEST-STATUS 1+
* 0 No other VFREEBUSY properties
are present
VJOURNAL 0+ Only if VJOURNAL components
were deleted
REQUEST-STATUS 1+
* 0 No other VJOURNAL properties
are present
VQUERY 0+ Only if VQUERY components
were deleted
REQUEST-STATUS 1+
* 0 No other VQUERY properties
are present
VTIMEZONE 0+ Only if VTIMEZONE components
were deleted
REQUEST-STATUS 1+
* 0 No other VQUERY properties
are present
VTODO 0+ Only if VTODO components were
deleted
REQUEST-STATUS 1+
* 0 No other VTODO properties are
present
----------------------------------------------------------
[Editors note: Issues:
- Currently CAP requires that the server return a response
status. However, if there are multiple components deleted,
should the UID also be returned?
- VQUERY EXPAND and MAXSIZE parameters do not seem to apply
to deletion?
- Can one use DELETE to remove all VALARMs and VTIMEZONEs
that match a certain search criteria and that belong to all
components, event though VALARMs and VTIMEZONEs never exist
as independent components? Or should one use MODIFY? If
they can be deleted, do we return the REQUEST-STATUS of
their deletion in a VEVENT or separately?
- In the example in CAP where a calendar is deleted all the
server returns is 2.0, nothing else?
- We should not be able to delete any VFREEBUSY components?
- Can we delete multiple calendars?
- Currently one can not delete a VCALENDAR and some other
component in the same DELETE command. This seems OK. Anyone
see any need to be able to do this?
- Should the MAXRESULTS property of VQUERY apply to
deletion? We can use it to delete only the first n
components that match.]
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; component=VCOMMAND C: Content-Type:text/calendar; method=DELETE;
component=VCOMMAND
C: Content-Transfer-Encoding:7bit C: Content-Transfer-Encoding:7bit
C: C:
C: BEGIN:VCALENDAR C: BEGIN:VCALENDAR
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: METHOD:DELETE C: METHOD:DELETE
C: TARGET:cap://cal.foo.com/bill C: TARGET:cap://cal.foo.com/bill
C: BEGIN:VQUERY C: BEGIN:VQUERY
C: SCOPE:VEVENT C: QUERY:SELECT UID FROM VEVENT WHERE UID = 'abcd12345'
C: QUERY SELECT="UID"
C: WHERE (UID EQ abcd12345)
C: END:VQUERY C: END:VQUERY
C: END:VCOMMAND C: END:VCOMMAND
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
S: 2.0 S: 2.0
S: Content-Type:text/calendar; method=DELETE;
component=VCOMMAND
S:
S: BEGIN:VCALENDAR
S: METHOD:RESPONSE
S: BEGIN:VEVENT
S: REQUEST-STATUS:2.0
S: END:VEVENT
S: END:VCALENDAR
S: . S: .
And an example to delete the 'MrBill' calendar: And an example to delete the 'MrBill' calendar:
C: SENDDATA C: SENDDATA
C: Content-Type:text/calendar; method=DELETE; component=VCOMMAND C: Content-Type:text/calendar; method=DELETE;
component=VCOMMAND
C: Content-Transfer-Encoding:7bit C: Content-Transfer-Encoding:7bit
C: C:
C: BEGIN:VCALENDAR C: BEGIN:VCALENDAR
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
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
S: 2.0 S: 2.0
S: . S: .
Mansour/Dawson/Royer/Taler/Hill 43 Expires September 2000
C: SENDDATA C:
7.2.1.3. GENERATEUID Method 7.2.1.3. 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 MUST be GENERATEUID returns one or more new unique identifier which
unique on the server's calendar store. It is recommended that the return MUST be unique on the server's calendar store. It is
value be a globally unique id. recommended that the return value be a globally unique id.
Example: Example:
C: GENERATEUID 2 C: GENERATEUID 2
S: 2.0 abcde1234567-asdf-lkhh abcde1234567-asdf-3455 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.4. MODIFY Method 7.2.1.4. 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 calendar Result: 2.0 - successfully modified 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 MODIFY method is used to change an existing calendar or component. The MODIFY method is used to change an existing calendar or
TARGET specify the container(s) of the modification. When modifying a component. TARGET specify the container(s) of the
calendar at the top level, the CSID is specified. Otherwise the modification. When modifying a calendar at the top level,
container will be a CalID. the CSID is specified. Otherwise the container will be a
CalID.
The format of the request is two or three containers inside of a The format of the request is two or three containers inside
VCOMMAND container: 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 results are If a VQUERY is present, then only objects matching the query
modified. results are modified.
In the example below, the start and end time of the event with UID Restriction Table
abcd12345 is changed and the LOCATION property is removed.
Component/Property Presence Comment
------------------- -------- ---------------------------
VCAP 1+ The CUA can send up
PIPELINE commands
without processing a
response
. CMDID 0 or 1 If CMDID is not supplied,
then there must
not be pending replies to
previous command.
. VERSION 1 MUST be 2.0
. [IANA-PROP] 0+ any IANA registered
property
. VCOMMAND 1 MUST have at least one
container (VCALENDAR,
VCAR, VQUERY, VEVENT,
VTODO, VJOURNAL)
. . [IANA-PROP] 0+ any IANA registered
property
. . METHOD 1 MUST be MODIFY
. . TARGET 1+ MUST be the CALID
. . VCALENDAR 0+
. . . CALMASTER 0 or 1
. . . NAME 0 or 1
. . . OWNER 1+
. . . RELCALID 1
. . . TZID 0 or 1
. . . [IANA-PROP] 0+ any IANA registered
property
. . VCAR 0+
. . . CARID 0 or 1
. . . DENY 0+ Note, there must be at
least one GRANT or DENY
within the VCAR.
. . . GRANT 0+ Note, there must be at
least one GRANT or DENY
within the VCAR.
. . . [IANA-PROP] 0+ any IANA registered
property
. . VQUERY 0+
. . . EXPAND 0 or 1
. . . MAXRESULTS 0 or 1
. . . MAXSIZE 0 or 1
. . . QUERYNAME 1
. . . QUERY 1
. . . [IANA-PROP] 0+ any IANA registered
property
. . VEVENT 0+
. . . ATTENDEE 0+
. . . SEQUENCE 0 or 1 MUST be present if value is
greater than 0,
MAY be present if 0
. . . SUMMARY 1 Can be null
. . . UID 1
. . . ATTACH 0+
. . . CATEGORIES 0 or 1
. . . CLASS 0 or 1
. . . COMMENT 0 or 1
. . . CONTACT 0+
. . . CREATED 0 or 1
. . . DESCRIPTION 0 or 1 Can be null
. . . DTEND 0 or 1 if present DURATION MUST
NOT be present
. . . DTSTAMP 1
. . . DTSTART 1
. . . DURATION 0 or 1 if present DTEND MUST NOT
be present
. . . EXDATE 0+
. . . EXRULE 0+
. . . GEO 0 or 1
. . . LAST-MODIFIED 0 or 1
. . . LOCATION 0 or 1
. . . METHOD 1 <<placeholder. it may move
to meta-info>>
. . . ORGANIZER 1
. . . PRIORITY 0 or 1
. . . RDATE 0+
. . . RECURRENCE-ID 0 or 1 only if referring to an
instance of a recurring
calendar component.
Otherwise it MUST NOT be
present.
. . . RELATED-TO 0+
. . . REQUEST-STATUS 0+
. . . RESOURCES 0 or 1 This property MAY contain a
list of values
. . . RRULE 0+
. . . STATUS 0 or 1
. . . TRANSP 0 or 1
. . . URL 0 or 1
. . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered
property
. . . VALARM 0+
. . . . ACTION 1
. . . . ALARMID 0 or 1 MUST be 1 if multiple
VALARMs are present in same
component.
. . . . ATTACH 0+
. . . . DESCRIPTION 0 or 1
. . . . DURATION 0 or 1 if present REPEAT MUST be
present
. . . . REPEAT 0 or 1 if present DURATION MUST be
present
. . . . SUMMARY 0 or 1
. . . . TRIGGER 1
. . . . X-PROPERTY 0+
. . . . [IANA-PROP] 0+ any IANA registered
property
. . VTODO 0+
. . . ATTENDEE 0+
. . . SEQUENCE 0 or 1 MUST be present if value is
greater than 0, MAY be
present if 0
. . . SUMMARY 1 Can be null.
. . . UID 1
. . . ATTACH 0+
. . . CATEGORIES 0 or 1 This property may contain a
list of values
. . . CLASS 0 or 1
. . . COMMENT 0 or 1
. . . CONTACT 0+
. . . CREATED 0 or 1
. . . DESCRIPTION 0 or 1 Can be null
. . . DTSTAMP 1
. . . DTSTART 1
. . . DUE 0 or 1 If present DURATION MUST
NOT be present
. . . DURATION 0 or 1 If present DUE MUST NOT be
present
. . . EXDATE 0+
. . . EXRULE 0+
. . . GEO 0 or 1
. . . LAST-MODIFIED 0 or 1
. . . LOCATION 0 or 1
. . . METHOD 1 <<placeholder. it may move
to meta-info>>
. . . ORGANIZER 1
. . . PRIORITY 1
. . . PERCENT-COMPLETE 0 or 1
. . . RDATE 0+
. . . RECURRENCE-ID 0 or 1 MUST only if referring to
an instance of a recurring
calendar component.
Otherwise it MUST NOT
be present.
. . . RELATED-TO 0+
. . . REQUEST-STATUS 0
. . . RESOURCES 0 or 1 This property may contain a
list of values
. . . RRULE 0+
. . . STATUS 0 or 1 MAY be one of COMPLETED,
NEEDS-ACTION,
IN-PROCESS, CANCELLED
. . . URL 0 or 1
. . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered
property
. . . VALARM 0+
. . . . ACTION 1
. . . . ALARMID 0 or 1 MUST be 1 if multiple
VALARMs are present in
same component.
. . . . ATTACH 0+
. . . . DESCRIPTION 0 or 1
. . . . DURATION 0 or 1 if present REPEAT MUST be
present
. . . . REPEAT 0 or 1 if present DURATION MUST be
present
. . . . SUMMARY 0 or 1
. . . . TRIGGER 1
. . . . X-PROPERTY 0+
. . . . [IANA-PROP] 0+ any IANA registered
property
. . VJOURNAL 0+
. . . ATTENDEE 0
. . . DESCRIPTION 1 Can be null.
. . . DTSTAMP 1
. . . DTSTART 1
. . . ORGANIZER 1
. . . UID 1
. . . ATTACH 0+
. . . CATEGORIES 0 or 1 This property MAY contain a
list of values
. . . CLASS 0 or 1
. . . COMMENT 0 or 1
. . . CONTACT 0+
. . . CREATED 0 or 1
. . . EXDATE 0+
. . . EXRULE 0+
. . . LAST-MODIFIED 0 or 1
. . . METHOD 1 <<placeholder. it may move
to meta-info>>
. . . RDATE 0+
. . . RECURRENCE-ID 0 or 1 MUST only if referring to
an instance of a recurring
calendar component.
Otherwise it MUST NOT be
present.
. . . RELATED-TO 0+
. . . RRULE 0+
. . . SEQUENCE 0 or 1 MUST be present if non-
zero. MAY be
. . . . . present if zero.
. . . STATUS 0 or 1
. . . SUMMARY 0 or 1 Can be null
. . . URL 0 or 1
. . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered
property
. . VFREEBUSY 0
. . VTIMEZONE 0+ MUST be present if any
date/time refers
to a timezone
. . . DAYLIGHT 0+ MUST be one or more of
either STANDARD
or DAYLIGHT
. . . . . COMMENT 0 or 1
. . . . . DTSTART 1
. . . . . RDATE 0+ if present RRULE MUST NOT
be present
. . . . . RRULE 0+ if present RDATE MUST NOT
be present
. . . . . TZNAME 0 or 1
. . . . . TZOFFSET 1
. . . . . TZOFFSETFROM 1
. . . . . TZOFFSETTO 1
. . . . . X-PROPERTY 0+
. . . . . [IANA-PROP] 0+ any IANA registered
property
. . . LAST-MODIFIED 0 or 1
. . . STANDARD 0+
. . . . . COMMENT 0 or 1
. . . . . DTSTART 1
. . . . . RDATE 0+ if present RRULE MUST NOT
be present
. . . . . RRULE 0+ if present RDATE MUST NOT
be present
. . . . . TZNAME 0 or 1
. . . . . TZOFFSETFROM 1
. . . . . TZOFFSETTO 1
. . . . . X-PROPERTY 0+
. . . . . [IANA-PROP] 0+ any IANA registered
property
. . . TZID 1
. . . TZURL 0 or 1
. . . X-PROPERTY 0+
. . . [IANA-PROP] 0+ any IANA registered
property
Server Restriction Table for the CREATE command
Component/Property Presence Comment
--------------------- -------- --------------------------
VCAP 1+
. VCALENDAR 1+
. . TARGET 1
. . VERSION 1 MUST be 2.0
. . CMDID 0 or 1 MUST be returned if the
request contained a CMDID
. . RESPONSE-STATUS 0 if not creating a calendar
1+ if creating a calendar
. . . VCAR 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VCAR properties are
present
.
. . . VCOMMAND 0
. . . VEVENT 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VEVENT properties
are present
. . . . VALARM 0 if VEVENT was successfully
saved
1+ if there were errors saving
alarms
. . . . . RESPONSE-STATUS 1+
. . . VFREEBUSY 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VFREEBUSY
properties are
present
. . . VJOURNAL 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VJOURNAL properties
are present
. . . VQUERY 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VQUERY properties
are present
. . . VTODO 0+
. . . . RESPONSE-STATUS 1+
. . . . * 0 No other VTODO properties
are present
. . . . VALARM 0 if VTODO was successfully
saved
1+ if there were errors saving
alarms
. . . . . RESPONSE-STATUS 1+
[Editor's notes: Issues:
freebusy - a cap server should dynamically calculate
freebusy information - we recommend that you cannot create,
modify, or delete freebusy composers ]
In the example below, the start and end time of the event
with UID abcd12345 is changed and the LOCATION property is
removed.
Mansour/Dawson/Royer/Taler/Hill 44 Expires September 2000
C: SENDDATA C: SENDDATA
C: Content-type:text/calendar; Method=MODIFY; Component=VCOMMAND C: Content-type:text/calendar; Method=MODIFY;
Component=VCOMMAND
C: C:
C: BEGIN:VCALENDAR C: BEGIN:VCALENDAR
C: VERSION:2.1 C: VERSION:2.1
C: METHOD:MODIFY C: METHOD:MODIFY
C: TARGET:relcal2 C: TARGET:relcal2
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: BEGIN:VQUERY C: BEGIN:VQUERY
C: SCOPE:VEVENT C: QUERY:SELECT UID FROM VEVENT WHERE UID = 'abcd12345'
C: QUERY:SELECT UID WHERE (UID EQ abcd12345)
C: END:VQUERY C: END:VQUERY
C: BEGIN:VEVENT C: BEGIN:VEVENT
C: DTSTART:19990421T160000Z C: DTSTART:19990421T160000Z
C: DTEND:19990421T163000Z C: DTEND:19990421T163000Z
C: LOCATION:Joe's Diner C: LOCATION:Joe's Diner
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:VCALENDAR C: END:VCALENDAR
C: . C: .
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 replaced by "New And in this example, all instances of "Building 6" are
office lobby" in VEVENTs: replaced by "New office lobby" in VEVENTs:
C: SENDDATA C: SENDDATA
C: Content-type:text/calendar; Method=MODIFY; Component=VCOMMAND C: Content-type:text/calendar; Method=MODIFY;
Component=VCOMMAND
C: C:
C: BEGIN:VCALENDAR C: BEGIN:VCALENDAR
C: VERSION:2.1 C: VERSION:2.1
C: METHOD:MODIFY C: METHOD:MODIFY
C: TARGET:relcal2 C: TARGET:relcal2
C: BEGIN:VCOMMAND C: BEGIN:VCOMMAND
C: BEGIN:VEVENT C: BEGIN:VEVENT
C: LOCATION:Building 6 C: LOCATION:Building 6
C: END:VEVENT C: END:VEVENT
C: BEGIN:VEVENT C: BEGIN:VEVENT
skipping to change at line 2420 skipping to change at page 1, line 3604
C: END:VEVENT C: END:VEVENT
C: END:VCOMMAND C: END:VCOMMAND
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
S: 2.0 cap://cal.example.com/relcal2 S: 2.0 cap://cal.example.com/relcal2
7.2.1.5. MOVE Method 7.2.1.5. MOVE Method
Arguments: ContainerId Arguments: ContainerId
Mansour/Dawson/Royer/Taler/Hill 45 Expires September 2000
Data: data as described below Data: data as described below
Result: 2.0 - success Result: 2.0 - success
2.2 - will attempt operation on the remote cap server 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 method is used to move a calendar within the CS's hierarchy of This method is used to move a calendar within the CS's
calendars. hierarchy of calendars.
[Editors Note: there could be VCAR issues with this... if a VCAR's scope Restriction Table
of influence is limited to a calendar, we are probably OK. We should Component/Property Presence Comment
discuss this one] ------------------- -------- ---------------------
VCAP 1+ The CUA can send up
PIPELINE commands without
processing a response
. CMDID 0 or 1 If CMDID is not supplied,
then there must not be
pending replies to
previous command.
. VERSION 1 MUST be 2.0
. VCOMMAND 1 MUST have at least one
VCALENDAR
. . [IANA-PROP] 0+ any IANA registered
property
. . METHOD 1 MUST be MOVE.
. . TARGET 1 MUST be a the CSID or
CALID
. . VCALENDAR 1+
. . . CALMASTER 0
. . . NAME 0
. . . OWNER 0
. . . RELCALID 1
. . . TZID 0
. . . [IANA-PROP] 0+ any IANA registered
property
Server Restriction Table for the MOVE command
Component/Property Presence Comment
------------------- -------- -----------------------------
VCAP 1+
. VCALENDAR 1+
. . TARGET 1
. . VERSION 1 MUST be 2.0
. . CMDID 0 or 1 MUST be returned if the
request contained
a CMDID
. . RESPONSE-STATUS 1+
---------------------------------------------------------
[Editors note: Issues:
1) Should one be able to move a calendar owned by person X
into a calendar owned by person Y. (Can these such rights be
specified in VCARs?)
2) Should we also be able to move components from one
calendar to another? What if the calendars are owned by
different users? (With components one can do a copy, then
delete the original.)
3) There was very little information about MOVE in CAP. Why
was it added? Was there some major need for it?
4) Can one move multiple calendars into one calendar?
]
7.2.1.6. NOOP Method 7.2.1.6. NOOP Method
Arguments: none Arguments: none
Data: none Data: none
Result: 2.0 - success Result: 2.0 - success
This method does nothing. It can be sent to the server periodically to This method does nothing. It can be sent to the server
request that the CS not time out the session. periodically to request that the CS not time out the
session.
7.2.1.7. 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 - successful and the requested data follows Result: 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
Read Events Read Events
In the example below events on March 10,1999 between 080000Z and 190000Z In the example below events on March 10,1999 between 080000Z
are read. In this case only 4 properties for each event are returned. and 190000Z are read. In this case only 4 properties for
Two calendars are specified. Only booked (vs scheduled) entries are to each event are returned. Two calendars are specified. Only
be returned. booked (vs scheduled) entries are to be returned. The first
returns 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:VCALENDAR C: BEGIN:VCALENDAR
C: VERSION:2.1 C: VERSION:2.1
C: METHOD:READ C: METHOD:READ
Mansour/Dawson/Royer/Taler/Hill 46 Expires September 2000
C: CMDID:xyz12345 C: CMDID:xyz12345
C: TARGET:relcal2 C: TARGET:relcal2
C: TARGET:cap://bobo.ex.com/relcal3 C: TARGET:cap://bobo.ex.com/relcal3
C: BEGIN:VQUERY C: BEGIN:VQUERY
C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID) C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
C: FROM VEVENT FROM VEVENT
C: WHERE (DTEND >= 19990310T080000Z AND WHERE DTEND >= '19990310T080000Z'
C: DTSTART <= 19990310T190000Z AND AND DTSTART <= '19990310T190000Z'
METHOD EQ CREATE) AND METHOD = 'CREATE'
C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY)
C: END:VQUERY C: END:VQUERY
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
S: 2.0 cap://cal.example.com/relcal2 S: 2.0 cap://cal.example.com/relcal2
S: Content-type:text/calendar; Method=RESPONSE; S: Content-type:text/calendar; Method=RESPONSE;
S: Optinfo=VERSION:2.1 Optinfo=VERSION:2.1
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: DTSTART:19990310T090000Z S: DTSTART:19990310T090000Z
S: DTEND:19990310T100000Z S: DTEND:19990310T100000Z
S: UID:abcxyz12345 S: UID:abcxyz12345
S: SUMMARY:Meet with Sir Elton S: SUMMARY:Meet with Sir Elton
S: END:VEVENT S: END:VEVENT
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
skipping to change at line 2510 skipping to change at page 1, line 3759
S: END:VEVENT S: END:VEVENT
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:VCALENDAR S: END:VCALENDAR
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;Component=VDATA; S: Content-type:text/calendar;
Method=RESPONSE;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:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: BEGIN:VDATA 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:VDATA
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
Mansour/Dawson/Royer/Taler/Hill 47 Expires September 2000 The return values are subject to VCAR filtering. That is,
The return values are subject to VCAR filtering. That is, if the request if the request contains properties to which the UPN does
contains properties to which the UPN does not have access, those not have access, those properties will not appear in the
properties will not appear in the return values. If the UPN has access return values. If the UPN has access to at least one
to at least one property of events, but has been denied access to all property of events, but has been denied access to all
properties called out in the request, the response will contain a single properties called out in the request, the response will
RESPONSE-CODE property indicating the error. That is, the VEVENT contain a single RESPONSE-CODE property indicating the
components will be the following: error. That is, the VEVENT components will be the
following:
[EDITORS NOTE:
Should the one(s) that the UPN has access to be returned?]
S: 2.0 cap://bobo.ex.com/sally S: 2.0 cap://bobo.ex.com/sally
S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; S: Content-type:text/calendar;
Method=RESPONSE;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:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
S: BEGIN:VDATA S: BEGIN:VDATA
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: RESPONSE-CODE:3.8 S: RESPONSE-CODE:3.8
S: END:VEVENT S: END:VEVENT
S: END:VDATA S: END:VDATA
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
If the UPN has no access to any events at all, the response will simply If the UPN has no access to any events at all, the
be an empty data set. The response looks the same if there are response will simply be an empty data set. The response
particular events to which the requester has been denied access. looks the same 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;Component=VDATA; S: Content-type:text/calendar;
Method=RESPONSE;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:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
S: BEGIN:VDATA S: BEGIN:VDATA
S: END:VDATA S: END:VDATA
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
Find alarms within a range of time for booked (METHOD EQ CREATE) Find alarms within a range of time for booked (METHOD =
VEVENTs. CREATE) 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:VCALENDAR C: BEGIN:VCALENDAR
C: VERSION:2.1 C: VERSION:2.1
C: METHOD:READ C: METHOD:READ
C: CMDID:xyz12345 C: CMDID:xyz12345
C: TARGET:relcal2 C: TARGET:relcal2
C: TARGET:cap://bobo.ex.com/relcal3 C: TARGET:cap://bobo.ex.com/relcal3
C: BEGIN:VQUERY C: BEGIN:VQUERY
C: QUERY:SELECT (VEVENT.DTSTART, C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID, VALARM.*
FROM VEVENT,VTODO
Mansour/Dawson/Royer/Taler/Hill 48 Expires September 2000 WHERE VALARM.TRIGGER >= '19990310T080000Z'
VEVENT.DTEND,VEVENT.SUMMARY, VEVENT.UID, AND VALARM.TRIGGER <= '19990310T190000Z'
VALARM.*) AND METHOD = 'CREATE'
C: FROM VEVENT,VTODO
C: WHERE (VALARM.TRIGGER >= 19990310T080000Z AND
C: VALARM.TRIGGER <= 19990310T190000Z AND
METHOD EQ CREATE)
C: ORDERBY (VALARM.TRIGGER ASC)
C: END:VQUERY C: END:VQUERY
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
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:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
skipping to change at line 2633 skipping to change at page 1, line 3887
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:VCALENDAR S: END:VCALENDAR
S: . S: .
Mansour/Dawson/Royer/Taler/Hill 49 Expires September 2000
7.2.2. Scheduling Commands 7.2.2. Scheduling Commands
The following provide a set of scheduling commands (or methods) in CAP. The following provide a set of scheduling commands (or
Scheduling commands allow a CU to indirectly manipulate a calendar by methods) in CAP. Scheduling commands allow a CU to
asking another CU to perform an operation on their calendar. For indirectly manipulate a calendar by asking another CU to
example, CU-A can request CU-B to add a meeting to their calendar; in 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. effect inviting CU-B to the meeting.
Calendar access rights can be granted for scheduling commands without Calendar access rights can be granted for scheduling
granting rights for more generalized access with the calendar commands. commands without granting rights for more generalized
access with the calendar commands.
[Editors Note: This section needs to be completed by adding the [EDITORS NOTE: This section needs to be completed by
restriction tables for each of these iTIP methods. The basis for the adding the restriction tables for each of these iTIP
text is to be taken from [RFC2446].] methods. The basis for the text is to be taken from
[iTIP].]
7.2.2.1. Reading out scheduling components 7.2.2.1. Reading out scheduling components
A CU might be invided to a meeting. If the CU had been invided by CAP, A CU might be invited to a meeting. If the CU had been
the entry in the CU calendar will be scheduled, but not booked. So a invited by CAP, the entry in the CU calendar will be
CUA will need to look for scheduled entries in the calendar and present scheduled, but not booked. So a CUA will need to look for
them to the CU or automaticly decide if the invitation is to be acceped scheduled entries in the calender and present them to the
or processed. CU or automaticly decide if the invitation is to be
accepted or processed.
Example: The little league coach places the teams entire schedule into Example:
your calendar. Lets say that every game and practice is on a Firday
night and your calendar now has this iTIP scheduling data: The little league coach places the teams entire schedule
into your calendar. Lets say that every game and practice
is on a Friday night and your calendar now has this iTIP
scheduling data:
BEGIN:VCALENDAR BEGIN:VCALENDAR
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-coarch@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:VCALENDAR END:VCALENDAR
At this point the above VEVENT is not booked in your calendar, It is At this point the above VEVENT is not booked in your
simpley scheduled. A CUA would fetch this and all other scheduled calendar, It is simply scheduled. A CUA would fetch this
VEVENTs from your calendar with: and all other scheduled 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:VCALENDAR C: BEGIN:VCALENDAR
C: VERSION:2.1 C: VERSION:2.1
Mansour/Dawson/Royer/Taler/Hill 50 Expires September 2000
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 (VEVENT.*) C: QUERY:SELECT * WHERE FROM VEVENT METHOD != 'CREATE'
C: FROM VEVENT
C: WHERE (METHOD != CREATE)
C: END:VQUERY C: END:VQUERY
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
The the CUA and CU could determine which scheduling items were to remain The the CUA and CU could determine which scheduling items
on the calendar. Each scheduling component could be deleted or updated were to remain on the calendar. Each scheduling component
with METHOD:MODIFY to change the METHOD from PUBLISH, REQUEST, REPLY, could be deleted or updated with METHOD:MODIFY to change
ADD, CANCEL, REFRESH, COUNTER, or DECLINE-COUNTER to what the CU and CUA the METHOD from PUBLISH, REQUEST, REPLY, ADD, CANCEL,
had decided. REFRESH, COUNTER, or DECLINE-COUNTER to what the CU and
CUA had decided.
In some cases the CUA could automaticly do the work and inform the CU. In some cases the CUA could automaticly do the work and
An example of this is CANCEL. If configured to process METHOD:CANCEL it inform the CU. An example of this is CANCEL. If
could METHOD:DELETE the component an inform the CU that the booked configured to process METHOD:CANCEL it could
component had been canceled. METHOD:DELETE the component an inform the CU that the
booked component had been canceled.
The CUA MUST process the scheduled components in the order sent. Some The CUA MUST process the scheduled components in the order
optimization could be done by the CUA. One example is if a PUBLISH and sent. Some optimization could be done by the CUA. One
later a CANCEL for the same component with the same SEQUENCE number were example is if a PUBLISH and later a CANCEL for the same
scheduled, but not booked. The CUA might never inform the CU and just component with the same SEQUENCE number were scheduled,
treat it as if the PUBLISH had never been received by doing a but not booked. The CUA might never inform the CU and just
METHOD:DELETE on both entries. treat it as if the PUBLISH had never been received by
doing a METHOD:DELETE on both entries.
It is important to note that scheduled components do not show up in busy It is important to note that scheduled components do not
time as BUSY. Only when they are booked does the TRANSP:OPAQUE property show up in busy time as BUSY. Only when they are booked
take effect. A CS implementation could mark the time as TENTATIVE. does the TRANSP:OPAQUE property take effect. A CS
This is an implementation and administrative choice. implementation MAY mark the time as TENTATIVE. This
is an implementation and 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.0 - success
2.2 - will attempt operation on the remote cap server 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 method is used to move a calendar within the CS's hierarchy of This method is used to move a calendar within the CS's
calendars. If the CU wishes to keep the published entry. A hierarchy of calendars. If the CU wishes to keep the
METHOD:MODIFY changing the entries METHOD from PUBLISH to CREATE would published entry. A METHOD:MODIFY changing the entries
be done, booking the entry. Or METHOD:DELETE if the CU did not wish METHOD from PUBLISH to CREATE would be done, booking the
this scheduled item to exist in their calendar. entry. Or METHOD:DELETE if the CU did not wish this
scheduled item to exist in their calendar.
Mansour/Dawson/Royer/Taler/Hill 51 Expires September 2000
7.2.2.3. REQUEST 7.2.2.3. REQUEST
Arguments:
Data: data as described below
Result: 2.0 - success
2.2 - will attempt operation on the remote cap server
Permission
Calendar already exists
Bad args
Parent Calendar(s) not found
This as described in [iTIP] and would be modified just
like PUBLISH above.
7.2.2.4. REPLY 7.2.2.4. REPLY
Arguments:
Data: data as described below
Result: 2.0 - success
2.2 - will attempt operation on the remote cap server
Permission
Calendar already exists
Bad args
Parent Calendar(s) not found
7.2.2.5. ADD 7.2.2.5. ADD
Arguments:
Data: data as described below
Result: 2.0 - success
2.2 - will attempt operation on the remote cap server
Permission
Calendar already exists
Bad args
Parent Calendar(s) not found
7.2.2.6. CANCEL 7.2.2.6. CANCEL
Arguments:
Data: data as described below
Result: 2.0 - success
2.2 - will attempt operation on the remote cap server
Permission
Calendar already exists
Bad args
Parent Calendar(s) not found
7.2.2.7. REFRESH 7.2.2.7. REFRESH
Arguments:
Data: data as described below
Result: 2.0 - success
2.2 - will attempt operation on the remote cap server
Permission
Calendar already exists
Bad args
Parent Calendar(s) not found
7.2.2.8. COUNTER 7.2.2.8. COUNTER
Arguments:
Data: data as described below
Result: 2.0 - success
2.2 - will attempt operation on the remote cap server
Permission
Calendar already exists
Bad args
Parent Calendar(s) not found
7.2.2.9. DECLINECOUNTER 7.2.2.9. DECLINECOUNTER
Arguments:
Data: data as described below
Result: 2.0 - success
2.2 - will attempt operation on the remote cap server
Permission
Calendar already exists
Bad args
Parent Calendar(s) not found
7.2.3. iTIP Examples 7.2.3. iTIP Examples
The following examples describe scenarios for the handling of incoming The following examples describe scenarios for the handling
iTIP data. An appropriate sort-order for the handling of incoming iTIP of incoming iTIP data. An appropriate sort-order for the
is by UID, Recurrence-id, sequence, dtstamp. This processing may be handling of incoming iTIP is by UID, Recurrence-id,
optimized, for instance, REFRESHs could be processed last. sequence, dtstamp. This processing may be optimized, for
instance, REFRESHs could be processed last.
As an update to [RFC2446], data with the "COUNTER" method should be As an update to [iTIP], data with the "COUNTER" method
processed even if the Sequence number is stale. should be 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 meeting In this example A invites B and C to a meeting, B
and C rejects it. The calendars for A, B and C are relcal1, relcal2 and accepts the meeting and C rejects it. The calendars for A,
relcal3 respectively, and are all on the same server, "cal.foo.com". A B and C are relcal1, relcal2 and relcal3 respectively, and
lot of these described actions are performed by the CUAs and not the are all on the same server, "cal.foo.com". A lot of these
users themselves, the CUAs are called A-c, B-c and C-c respectively. described actions are performed by the CUAs and not the
users themselves, the CUAs are called A-c, B-c and C-c
respectively.
A wishes to create a meeting with B and C, so A-c uses CAP to send the A wishes to create a meeting with B and C, so A-c uses
following iTIP request to relcal2 and relcal3, while logged in to CAP to send the following iTIP request to relcal2 and
"cal.foo.com". relcal3, while logged in to "cal.foo.com".
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.1 VERSION:2.1
CMDID:xhj-dd CMDID:xhj-dd
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
Mansour/Dawson/Royer/Taler/Hill 52 Expires September 2000
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.com/relcal2 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 ACTION:cap://cal.foo.com/relcal2
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ACTION:cap://cal.foo.com/relcal3
SUMMARY:Important Meeting SUMMARY:Important Meeting
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
An incoming event (indicated by the value of the "METHOD" property) then An incoming event (indicated by the value of the "METHOD"
property) then
appears in relcal2 and relcal3, with the following data: appears in relcal2 and relcal3, with the 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.com/relcal2 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 ACTION:cap://cal.foo.com/relcal2
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-
ACTION:cap://cal.foo.com/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 using the B-c and C-c must search for such incoming events, they do
so using the
following CAP search: following CAP search:
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.1 VERSION:2.1
METHOD:READ METHOD:READ
CMDID:xhr-de CMDID:xhr-de
TARGET:relcal2 TARGET:relcal2
# or TARGET:relcal3 # or TARGET:relcal3
BEGIN:VQUERY BEGIN:VQUERY
QUERY:SELECT (ALL); QUERY:SELECT * FROM VEVENT WHERE METHOD = 'REQUEST';
FROM VEVENT;
WHERE (METHOD == REQUEST);
END:VQUERY END:VQUERY
END:VCALENDAR END:VCALENDAR
In response to this search they get the above event. B-c and C-c must In response to this search they get the above event. B-c
then crack open the VEVENT, find the UID and determine if there is and C-c must
already an event on their calendar with that UID. To do this they use then crack open the VEVENT, find the UID and determine if
there is
already an event on their calendar with that UID. To do
this they use
the following search: the following search:
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.1 VERSION:2.1
METHOD:READ METHOD:READ
CMDID:xhr-df CMDID:xhr-df
TARGET:relcal2 TARGET:relcal2
BEGIN:VQUERY BEGIN:VQUERY
QUERY:SELECT (*) QUERY:SELECT * FROM VEVENT WHERE UID = 'abcd12345' AND
FROM VEVENT METHOD = 'CREATE'
WHERE (UID == abcd12345 AND METHOD == CREATE)
END:VQUERY END:VQUERY
Mansour/Dawson/Royer/Taler/Hill 53 Expires September 2000
END:VCALENDAR END:VCALENDAR
We assume that the event is not already in their relcal2 or relcal3. We assume that the event is not already in their relcal2
or relcal3.
B-c prompts B who decides to accept the meeting request, and B-c creates B-c prompts B who decides to accept the meeting request,
a copy of the event in relcal2, with the "PARTSTAT" parameter set to and B-c creates
ACCEPTED. B-c also sends this copy to the Organizer at relcal1 as an a copy of the event in relcal2, with the "PARTSTAT"
parameter set to
ACCEPTED. B-c also sends this copy to the Organizer at
relcal1 as an
iTIP REPLY, preserving the CMDID: iTIP REPLY, preserving the CMDID:
BEGIN:VCALENDAR BEGIN:VCALENDAR
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:VCALENDAR END:VCALENDAR
C, on the other hand, decides to decline the meeting, and C-c sends a C, on the other hand, decides to decline the meeting, and
C-c sends a
reply to the Organizer to that effect, as follows: reply to the Organizer to that effect, as follows:
BEGIN:VCALENDAR BEGIN:VCALENDAR
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=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:VCALENDAR
It is preferable that C-c store the event in relcal3 even though it has It is preferable that C-c store the event in relcal3 even
been declined. Storing the event in relcal3 allows subsequent iTIP though it has
messages to be interpreted correctly. The "PARTSTAT" parameter indicates been declined. Storing the event in relcal3 allows
subsequent iTIP
messages to be interpreted correctly. The "PARTSTAT"
parameter indicates
that the event was refused. that the event was refused.
After receiving the replies from relcal2 and relcal3, A-c updates the After receiving the replies from relcal2 and relcal3, A-c
version of the event in relcal1 to indicate the new participation updates the
statii: version of the event in relcal1 to indicate the new
participation
status:
BEGIN:VEVENT BEGIN:VEVENT
METHOD:REQUEST METHOD:REQUEST
Mansour/Dawson/Royer/Taler/Hill 54 Expires September 2000
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 the A-c then sends a new iTIP request to relcal2 only,
indicating 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 the A little bit later, C is thinking about accepting the
previous example, but first wants to check the current state of the event in the
event. To find the current state C-c uses the iTIP "REFRESH" method, previous example, but first wants to check the current
state of the
event. To find the current state C-c uses the iTIP
"REFRESH" method,
sending the following to relcal1: sending the following to relcal1:
BEGIN:VCALENDAR BEGIN:VCALENDAR
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
DTSTAMP:19990306T202333Z DTSTAMP:19990306T202333Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
A-c finds the refresh as an incoming iTIP, and searches for the A-c finds the refresh as an incoming iTIP, and searches
corresponding event. Having found the event (with no changes since the for the
last example) A-c then verifies that relcal3 is in fact an Attendee of corresponding event. Having found the event (with no
the event and is thus allowed to request a refresh. (In the case of a changes since the
published event things are more complicated.) A-c packages the event up last example) A-c then verifies that relcal3 is in fact an
Attendee of
the event and is thus allowed to request a refresh. (In
the case of a
published event things are more complicated.) A-c packages
the event up
as an iTIP request and sends it to relcal3: as an iTIP request and sends it to relcal3:
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.1 VERSION:2.1
CMDID: xud-pn CMDID: xud-pn
METHOD:REQUEST METHOD:REQUEST
TARGET:cap://cal.foo.com/relcal3 TARGET:cap://cal.foo.com/relcal3
BEGIN:VEVENT BEGIN:VEVENT
UID:abcd12345 UID:abcd12345
DTSTART:19990307T180000Z DTSTART:19990307T180000Z
skipping to change at line 2951 skipping to change at page 1, line 4315
VERSION:2.1 VERSION:2.1
CMDID: xud-pn CMDID: xud-pn
METHOD:REQUEST METHOD:REQUEST
TARGET:cap://cal.foo.com/relcal3 TARGET:cap://cal.foo.com/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
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
Mansour/Dawson/Royer/Taler/Hill 55 Expires September 2000
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19990306T204333Z DTSTAMP:19990306T204333Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
[Ed. - should the CMDID match that of the REFRESH?]
7.2.3.3. Sending and accepting an iTIP counter 7.2.3.3. Sending and accepting an iTIP counter
Having received the latest copy of the event C wishes to propose a venue Having received the latest copy of the event C wishes to
for the event, using an iTIP COUNTER. To do this C-c sends the following propose a venue
for the event, using an iTIP COUNTER. To do this C-c sends
the following
to relcal1: to relcal1:
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.1 VERSION:2.1
CMDID:zzykjjk CMDID:zzykjjk
METHOD:COUNTER METHOD:COUNTER
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=DECLINED:cap://cal.foo.com/relcal3 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
SUMMARY:Important Meeting SUMMARY:Important Meeting
LOCATION:La Belle Province LOCATION:La Belle Province
COMMENT:My favourite restaurant, I'll definitely go if it's there. COMMENT:My favorite restaurant, I'll definitely go if it's
there.
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Having