draft-ietf-calsch-cap-01.txt   draft-ietf-calsch-cap-02.txt 
Network Working Group Steve Mansour/Netscape Network Working Group Steve Mansour/Netscape
Internet Draft Frank Dawson/Lotus Internet Draft Frank Dawson/Lotus
<draft-ietf-calsch-cap-01.txt> Doug Royer/Software.com <draft-ietf-calsch-cap-02.txt> Doug Royer/Software.com
Alexander Taler/CS&T Alexander Taler/CS&T
Paul Hill/MIT Paul Hill/MIT
Expires six months from: October 22, 1999 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 with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering Task
Task Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt . http://www.ietf.org/ietf/1id-abstracts.txt .
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 1999. 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 that
permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to
to access an [RFC2445] based Calendar Store (CS). This memo defines access an [RFC2445] based Calendar Store (CS). This memo defines the
the CAP specification. 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
Mansour/Dawson/Royer/Taler/Hill The CAP definition is based on requirements identified by the Internet
Expires: April 2000 1 Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH)
Working Group activities can be found on the IMC web site at Working Group. More information about the IETF CALSCH Working Group
activities can be found on the IMC web site at
http://www.imc.org/ietf-calendar, and at the IETF web site at http://www.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 http://www.ietf.org/html.charters/calsch-charter.html. Refer to the
references within this memo for further information on how to access references within this memo for further information on how to access
these various documents. these various documents.
Mansour/Dawson/Royer/Taler/Hill Mansour/Dawson/Royer/Taler/Hill 2 Expires September 2000
Expires: April 2000 2
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ................................................... 3
1.1 Formatting Conventions ..................................... 3 1.1. Formatting Conventions ....................................... 3
1.2 Related Documents .......................................... 4 1.2. Related Documents ............................................ 3
1.3 Definitions ................................................ 4 1.3. Definitions .................................................. 4
2. CAP Design .................................................. 8 2. CAP Design ..................................................... 10
2.1 System Model ............................................... 8 2.1. System Model ................................................. 10
2.2 Calendar Store Object Model ................................ 9 2.2. Calendar Store Object Model .................................. 11
2.3 Protocol Model ............................................. 10 2.3. Protocol Model ............................................... 11
2.4 Roles ...................................................... 11 2.4. Security Model ............................................... 13
2.5 Calendar User .............................................. 11 2.4.1. Authentication, Credentials, and Identity .................. 14
2.5.1 UPNs and Certificates .................................... 11 2.4.2. Calendar User and UPNs ..................................... 14
2.5.2 CAP session identity ..................................... 12 2.4.2.1. UPNs and Certificates .................................... 15
2.6 Calendar Addresses ......................................... 13 2.4.2.2. Anonymous Users and Authentication ....................... 16
2.7 Finding CAP Servers ........................................ 14 2.4.2.3. Required Security Mechanisms ............................. 16
2.7.1 Using DNS ................................................ 14 2.4.2.4. TLS Ciphersuites ......................................... 17
2.7.2 Using SLP ................................................ 14 2.4.3. User Groups ................................................ 17
2.8 Extensions to iCalendar .................................... 16 2.4.4. Access Rights .............................................. 18
2.9 Relationship of RFC 2446 (ITIP) to CAP ..................... 17 2.4.4.1. VCalendar Access Right (VCAR) ........................... 18
2.10 VCalendar Access Rights (VCARs) ........................... 17 2.4.4.2. Decreed VCARs ............................................ 19
2.11 Query Schema .............................................. 18 2.4.4.3. Inheritance .............................................. 19
3. State Diagram ............................................... 18 2.4.5. CAP session identity ....................................... 19
4. Protocol Framework .......................................... 19 2.5. Roles ........................................................ 20
4.1 CAP Application Layer ...................................... 19 2.6. Calendar Addresses ........................................... 21
4.2 CAP Transport Layer ........................................ 20 2.7. Extensions to iCalendar ...................................... 21
4.3 Response Format ............................................ 20 2.8. Relationship of RFC 2446 (ITIP) to CAP ....................... 22
4.4 Auto-logout Timer .......................................... 20 2.9. VCalendar Access Rights (VCARs) .............................. 23
4.5 Bounded Latency ............................................ 21 2.10. Query Schema ................................................ 23
4.6 Data Elements .............................................. 21 3. State Diagram .................................................. 23
5. Formal Command Syntax ....................................... 21 4. Protocol Framework ............................................. 25
5.1 Searching and Filtering .................................... 21 4.1. CAP Application Layer ........................................ 25
5.1.1 Grammar For Search Mechanism ............................. 22 4.2. CAP Transfer Protocol ........................................ 25
6. Access Rights ............................................... 22 4.3. Response Format .............................................. 25
6.1 VCAR Inheritance ........................................... 23 4.4. Auto-logout Timer ............................................ 26
6.2 Access Control and NOCONFLICT .............................. 23 4.5. Bounded Latency .............................................. 26
7. Commands and Responses ...................................... 23 4.6. Data Elements ................................................ 27
7.1 Transport Protocol Commands ................................ 24 5. Formal Command Syntax .......................................... 27
7.1.1 Initial Connection ....................................... 24 5.1. Searching and Filtering ...................................... 27
7.1.2 ABORT Command ............................................ 24 5.1.1. Grammar For Search Mechanism ............................... 27
7.1.3 AUTHENTICATE Command ..................................... 25 6. Access Rights .................................................. 28
7.1.6 DISCONNECT Command ....................................... 30 6.1. VCAR Inheritance ............................................. 28
7.1.7 IDENTIFY Command ......................................... 30 6.2. Access Control and NOCONFLICT ................................ 28
7.1.8 SENDDATA Command ......................................... 30 7. Commands and Responses ......................................... 29
7.1.9 STARTTLS Command ......................................... 31 7.1. Transfer Protocol Commands ................................... 29
7.2 Application Protocol Commands .............................. 32 7.1.1. Initial Connection ......................................... 29
7.2.1 Calendaring Commands ..................................... 32 7.1.2. ABORT Command .............................................. 30
7.2.1.1 CREATE Method .......................................... 32 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 Mansour/Dawson/Royer/Taler/Hill Expires September 2000
7.2.1.1.1 Creating New Calendars ............................... 32 7.1.9. SENDDATA Command ........................................... 38
7.2.1.2 DELETE Method .......................................... 34 7.1.10. STARTTLS Command .......................................... 38
7.2.1.3 GENERATEUID Method ..................................... 35 7.1.10.1. UPNEXPAND Method ........................................ 39
7.2.1.4 MODIFY Method .......................................... 35 7.2. Application Protocol Commands ................................ 40
7.2.1.5 MOVE Method ............................................ 36 7.2.1. Calendaring Commands ....................................... 40
7.2.1.6 READ Method ............................................ 37 7.2.1.1. CREATE Method ............................................ 40
7.2.2 Scheduling Commands ...................................... 41 7.2.1.1.1. Creating New Calendars ................................. 41
7.2.2.1 PUBLISH ................................................ 41 7.2.1.2. DELETE Method ............................................ 43
7.2.2.2 REQUEST ................................................ 41 7.2.1.3. GENERATEUID Method ....................................... 44
7.2.2.3 REPLY .................................................. 41 7.2.1.4. MODIFY Method ............................................ 44
7.2.2.4 ADD .................................................... 41 7.2.1.5. MOVE Method .............................................. 45
7.2.2.5 CANCEL ................................................. 41 7.2.1.6. NOOP Method .............................................. 46
7.2.2.6 REFRESH ................................................ 41 7.2.1.7. READ Method .............................................. 46
7.2.2.7 COUNTER ................................................ 41 7.2.2. Scheduling Commands ........................................ 50
7.2.2.8 DECLINECOUNTER ......................................... 41 7.2.2.1. Reading out scheduling components ........................ 50
7.2.3 iTIP Examples ............................................ 42 7.2.2.2. PUBLISH .................................................. 51
7.2.3.1 Sending and Receiving an iTIP request .................. 42 7.2.2.3. REQUEST .................................................. 52
7.2.3.2 Handling an iTIP refresh ............................... 45 7.2.2.4. REPLY .................................................... 52
7.2.3.3 Sending and accepting an iTIP counter .................. 46 7.2.2.5. ADD ...................................................... 52
7.2.3.4 Declining an iTIP counter .............................. 47 7.2.2.6. CANCEL ................................................... 52
8. Response Codes .............................................. 48 7.2.2.7. REFRESH .................................................. 52
9. Detailed SQL Schema ......................................... 50 7.2.2.8. COUNTER .................................................. 52
9.1 iCalendar Store Schema ..................................... 51 7.2.2.9. DECLINECOUNTER ........................................... 52
10. Examples ................................................... 57 7.2.3. iTIP Examples .............................................. 52
10.1 Authentication Examples ................................... 57 7.2.3.1. Sending and Receiving an iTIP request .................... 52
10.1.1 Login Using Kerberos V4 ................................. 57 7.2.3.2. Handling an iTIP refresh ................................. 55
10.1.2 Error Scenarios ......................................... 58 7.2.3.3. Sending and accepting an iTIP counter .................... 56
10.2 Read Examples ............................................. 58 7.2.3.4. Declining an iTIP counter ................................ 57
10.2.1 Read From A Single Calendar ............................. 58 8. Response Codes ................................................. 58
10.2.2 Read From Multiple Calendars ............................ 59 8.1. Minimum CS query implementation .............................. 60
10.2.3 Timeouts ................................................ 61 8.1.1. Query by UID ............................................... 60
10.2.4 Using the Calendar Parent, Children Properties .......... 62 8.1.2. Query by Date / Date-Time range ............................ 60
10.2.5 An example that depends on VEVENT.DTSTART and 8.1.2.1. Date/Date-Time query with subset of properties ........... 60
VALARM.DTSTART ............................................ 62 8.1.3. <TBD> ...................................................... 60
11. Implementation Issues ...................................... 62 9. Detailed SQL Schema ............................................ 60
12. Properties ................................................. 62 9.1. iCalendar Store Schema ....................................... 62
12.1 Calendar Store Properties ................................. 62 9.1.1. ACTION schema .............................................. 62
12.2 Calendar Properties ....................................... 63 9.1.2. ATTACH schema .............................................. 63
13. Security Considerations .................................... 64 9.1.3. ATTENDEE schema ............................................ 63
14. Changes to iCalendar ....................................... 64 9.1.4. CALSTORE schema ............................................ 63
14.1 Created ................................................... 64 9.1.5. CHILDREN schema ............................................ 64
14.2 Last Modified ............................................. 65 9.1.6. CLASS schema ............................................... 64
14.2.1.1 Time Transparency ..................................... 66 9.1.7. CN schema .................................................. 64
14.3 RIGHTS Value Type ......................................... 67 9.1.8. COMMENT schema ............................................. 64
14.4 VCAR Calendar Component ................................... 70 9.1.9. CONTACT schema ............................................. 64
14.5 GRANT Component Property .................................. 72 9.1.10. CREATED schema ............................................ 65
14.6 DENY Component Property ................................... 73 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 Mansour/Dawson/Royer/Taler/Hill Expires September 2000
14.7 VCAR Identifier Component Property ........................ 73 9.1.18. DURATION schema ........................................... 67
15. CAP Entities Registration .................................. 75 9.1.19. EXDATE schema ............................................. 67
15.2.1 Define the Entity ....................................... 76 9.1.20. EXRULE schema ............................................. 67
15.2.2 Post the entity definition .............................. 77 9.1.21. FBTYPE schema ............................................. 67
15.2.3 Allow a comment period .................................. 77 9.1.22. FMTTYPE schema ............................................ 67
15.2.4 Submit the entity for approval .......................... 77 9.1.23. FREEBUSY schema ........................................... 68
15.3 Property Change Control ................................... 77 9.1.24. GEO schema ................................................ 68
16. IANA Considerations ........................................ 78 9.1.25. LANGUAGE schema ........................................... 68
17. Acknowledgments ............................................ 78 9.1.26. LAST_MODIFIED schema ...................................... 68
18. Bibliography ............................................... 78 9.1.27. MEMBER schema ............................................. 68
19. Author's Address ........................................... 79 9.1.28. METHOD schema ............................................. 69
20. Full Copyright Statement ................................... 80 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 Mansour/Dawson/Royer/Taler/Hill Expires September 2000
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 1. Introduction
This document specifies how a Calendar User Agent (CUA) interacts This document specifies how a Calendar User Agent (CUA) interacts with a
with a Calendar Store (CS) to manage calendar information. In Calendar Store (CS) to manage calendar information. In particular, it
particular, it specifies how to query, create, modify, and delete specifies how to query, create, modify, and delete iCalendar components
iCalendar components (e.g., events, to-dos, or daily journal (e.g., events, to-dos, or daily journal entries). It further specifies
entries). It further specifies how to search for available busy time how to search for available busy time information.
information.
This protocol is based on request/response form of protocol data This protocol is based on request/response form of protocol data units,
units, sent from a client CUA to a calendar server. The protocol data sent from a client CUA to a calendar server. The protocol data units
units leverage the standard iCalendar format [RFC2445] for conveying leverage the standard iCalendar format [RFC2445] for conveying CS
CS related information. 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", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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-strings of
text with the first character of each word in upper case. For text with the first character of each word in upper case. For example,
example, "Organizer" refers to a role of a "Calendar User" (CU) "Organizer" refers to a role of a "Calendar User" (CU) within the
within the protocol defined by this memo. Calendar components defined protocol defined by this memo. Calendar components defined by [RFC2445]
by [RFC2445] are referred to with capitalized, quoted-strings of are referred to with capitalized, quoted-strings of text. All calendar
text. All calendar components start with the letter "V". For example, components start with the letter "V". For example, "VEVENT" refers to
"VEVENT" refers to the event calendar component, "VTODO" refers to the event calendar component, "VTODO" refers to the to-do calendar
the to-do calendar component and "VJOURNAL" refers to the daily component and "VJOURNAL" refers to the daily journal calendar component.
journal calendar component. Calendar access methods defined by this Calendar access methods defined by this memo, as well as scheduling
memo, as well as scheduling methods defined by [RFC2446], are methods defined by [RFC2446], are referred to with capitalized, quoted-
referred to with capitalized, quoted-strings of text. For example, strings of text. For example, "CREATE" refers to the method for creating
"CREATE" refers to the method for creating a calendar component on a a calendar component on a calendar, "READ" refers to the method for
calendar, "READ" refers to the method for reading calendar reading calendar components.
components.
Properties defined by this memo are referred to with capitalized, Properties defined by this memo are referred to with capitalized,
quoted-strings of text, followed by the word "property". For example, quoted-strings of text, followed by the word "property". For example,
"ATTENDEE" property refers to the iCalendar property used to convey "ATTENDEE" property refers to the iCalendar property used to convey the
the calendar address of a "Calendar User". Property parameters calendar address of a "Calendar User". Property parameters defined by
defined by this memo are referred to with lower case, quoted-strings this memo are referred to with lower case, quoted-strings of text,
of text, followed by the word "parameter". For example, "value" followed by the word "parameter". For example, "value" parameter refers
parameter refers to the iCalendar property parameter used to override to the iCalendar property parameter used to override the default data
the default data type for a property value. Enumerated values defined type for a property value. Enumerated values defined by this memo are
by this memo are referred to with capitalized text, either alone or referred to with capitalized text, either alone or followed by the word
followed by the word "value". "value".
In tables, the quoted-string text is specified without quotes in
Mansour/Dawson/Royer/Taler/Hill In tables, the quoted-string text is specified without quotes in order
Expires: April 2000 3 to minimize the table length.
order to minimize the table length.
1.2 Related Documents 1.2. Related Documents
Implementers will need to be familiar with several other memos that, Implementers will need to be familiar with several other memos that,
along with this one, describe the Internet calendaring and scheduling along with this one, describe the Internet calendaring and scheduling
Mansour/Dawson/Royer/Taler/Hill 3 Expires September 2000
standards. This document, standards. This document,
[RFC2445] specifies the objects, data types, properties and property [RFC2445] specifies the objects, data types, properties and property
parameters used in the protocols, along with the methods for parameters used in the protocols, along with the methods for
representing and encoding them; representing and encoding them;
[RFC2446] specifies an interoperability protocol for scheduling [RFC2446] specifies an interoperability protocol for scheduling between
between different implementations. The related documents are: different implementations. The related documents are:
[RFC2447] specifies an Internet email binding for [RFC2446]. [RFC2447] specifies an Internet email binding for [RFC2446].
[iRIP] specifies a real-time binding for [RFC2446]. [iRIP] specifies a real-time binding for [RFC2446].
This memo does not attempt to repeat the specification of concepts or This memo does not attempt to repeat the specification of concepts or
definitions from these other memos. Where possible, references are definitions from these other memos. Where possible, references are made
made to the memo that provides for the specification of these to the memo that provides for the specification of these concepts or
concepts or definitions. definitions.
1.3 Definitions 1.3. Definitions
Authentication ID (AuthID) A tuple of username, realm, and Authentication ID (AuthID)
authentication method, used by the Calendar Service internally to
identify a successfully authenticated CAP session.
Calendar A collection of logically related objects or entities each A tuple of username, realm, and authentication method, used by the
of which may be associated with a calendar date and possibly time of Calendar Service internally to identify a successfully authenticated
day. These entities can include other calendar properties or calendar CAP session.
components. In addition, a calendar might be hierarchically related
to other sub-calendars. A calendar is identified by its unique
calendar identifier. The [RFC2445] defines calendar properties,
calendar components and component properties that make up the content
of a calendar.
Calendar Access Protocol (CAP) The standard Internet protocol that Calendar
permits a Calendar User Agent to access and manipulate a calendar
residing on a Calendar Store.
Calendar Access Rights (CAR) The mechanism for specifying the CAP A collection of logically related objects or entities each of which
operations ("ACTIONS") that a particular calendar user ("UPN") are may be associated with a calendar date and possibly time of day. These
granted or denied permission to perform on a given calendar entity entities can include other calendar properties or calendar components.
("OBJECT"). The calendar access rights are specified with the "VCAR" In addition, a calendar might be hierarchically related to other sub-
calendars. A calendar is identified by its unique calendar identifier.
The [RFC2445] defines calendar properties, calendar components and
component properties that make up the content of a calendar.
Mansour/Dawson/Royer/Taler/Hill Calendar Access Protocol (CAP)
Expires: April 2000 4
calendar components within a CS and calendar.
Calendar Component An entity within a calendar. Some types of The standard Internet protocol that permits a Calendar User Agent to
calendar components include events, to-dos, journals, alarms, time access and manipulate a calendar residing on a Calendar Store.
zones and freebusy data. A calendar component consists of component
properties and possibly other sub-components. For example, an event
may contain an alarm component.
Calendar Component Properties An attribute of a particular calendar Calendar Access Rights (CAR)
component. Some calendar component properties are applicable to
different types of calendar components. For example, DTSTART is
applicable to VEVENT, VTODO, VJOURNAL calendar components. Other
calendar components are applicable only to an individual type of
calendar component. For example, TZURL is only applicable to
VTIMEZONE calendar components.
Calendar Identifier (CalID) A globally unique identifier associated The mechanism for specifying the CAP operations ("ACTIONS") that a
with a calendar. Calendars reside within a CS. See Qualified Calendar particular calendar user ("UPN") are granted or denied permission to
Identifier and Relative Calendar Identifier. perform on a given calendar entity ("OBJECT"). The calendar access
rights are specified with the "VCAR" calendar components within a CS
and calendar.
Calendar Policy A CAP operational restriction on the access or Mansour/Dawson/Royer/Taler/Hill 4 Expires September 2000
manipulation of a calendar. For example, "events MUST be scheduled in
unit intervals of one hour".
Calendar Properties An attribute of a calendar. The attribute applies Calendar Collection
to the calendar, as a whole. For example, CALSCALE specifies the
calendar scale (e.g., GREGORIAN) for the whole calendar.
Calendar Service An implementation of a Calendar Store that manages A collection of Calendars, Resource Calendars, and/or other Calendar
one or more calendars. Collections. These collections are expanded by the CS and may reside
either locally or in an external database or directory. The calendars
in the collection may be fixed or dynamic over time.
Calendar Store (CS) The data and service model definition for a Calendar Component
Calendar Service.
Calendar Store Identifier (CSID) The globally unique identifier for An entity within a calendar. Some types of calendar components include
an individual CS. A CSID consists of the host and port portions of a events, to-dos, journals, alarms, time zones and freebusy data. A
"Common Internet Scheme Syntax" part of a URL, as defined by calendar component consists of component properties and possibly other
[RFC2396]. sub-components. For example, an event may contain an alarm component.
Calendar Store Components Components maintained in a CS specify a Calendar Component Properties
grouping of calendar store-wide information. Calendar store
components can be accessed using CAP.
Calendar Store Properties Properties maintained in a Calendar Store An attribute of a particular calendar component. Some calendar
calendar store-wide information. Calendar store properties can be component properties are applicable to different types of calendar
accessed using CAP. components. For example, DTSTART is applicable to VEVENT, VTODO,
VJOURNAL calendar components. Other calendar components are applicable
only to an individual type of calendar component. For example, TZURL
is only applicable to VTIMEZONE calendar components.
Mansour/Dawson/Royer/Taler/Hill Calendar Identifier (CalID)
Expires: April 2000 5
Calendar User (CU) An entity (often biological) that uses a
calendaring system.
Calendar User Agent (CUA) The CUA is the client application that a CU A globally unique identifier associated with a calendar. Calendars
utilizes to access and manipulate a calendar. reside within a CS. See Qualified Calendar Identifier and Relative
Calendar Identifier.
Calendaring and Scheduling System The computer sub-system that Calendar Policy
provides the services for accessing, manipulating calendars and
scheduling calendar components.
CAP Session An open communication channel between a CAP CUA and a CAP A CAP operational restriction on the access or manipulation of a
CS. calendar. For example, "events MUST be scheduled in unit intervals of
one hour".
Connected Mode A mobile computing mode where the CUA is directly Calendar Properties
connected to the CS.
Delegate Is a calendar user (sometimes called the delegatee) who has An attribute of a calendar. The attribute applies to the calendar, as
been assigned participation in a scheduled calendar component (e.g., a whole. For example, CALSCALE specifies the calendar scale (e.g.,
GREGORIAN) for the whole calendar.
Calendar Service
An implementation of a Calendar Store that manages one or more
calendars.
Mansour/Dawson/Royer/Taler/Hill 5 Expires September 2000
Calendar Store (CS)
The data and service model definition for a Calendar Service.
Calendar Store Identifier (CSID)
The globally unique identifier for an individual CS. A CSID consists
of the host and port portions of a "Common Internet Scheme Syntax"
part of a URL, as defined by [RFC2396].
Calendar Store Components
Components maintained in a CS specify a grouping of calendar store-
wide information. Calendar store components can be accessed using CAP.
Calendar Store Properties
Properties maintained in a Calendar Store calendar store-wide
information. Calendar store properties can be accessed using CAP.
Calendar User (CU)
An entity (often biological) that uses a calendaring system.
Calendar User Agent (CUA)
The CUA is the client application that a CU or UG utilizes to access
and manipulate a calendar.
Calendaring and Scheduling System
The computer sub-system that provides the services for accessing,
manipulating calendars and scheduling calendar components.
CAP Session
An open communication channel between a CAP CUA and a CAP CS.
Connected Mode
A mobile computing mode where the CUA is directly connected to the CS.
Delegate
Mansour/Dawson/Royer/Taler/Hill 6 Expires September 2000
Is a calendar user (sometimes called the delegatee) who has been
assigned participation in a scheduled calendar component (e.g.,
VEVENT) by one of the attendees in the scheduled calendar component VEVENT) by one of the attendees in the scheduled calendar component
(sometimes called the delegator). An example of a delegate is a team (sometimes called the delegator). An example of a delegate is a team
member told to go to a particular meeting. member told to go to a particular meeting.
Designate Is a calendar user who is authorized to act on behalf of Designate
another calendar user. An example of a designate is an assistant.
Disconnected Mode A mobile computing mode where a CUA can be Is a calendar user who is authorized to act on behalf of another
disconnected from a CS. When the CUA is disconnected, it is in the calendar user. An example of a designate is an assistant.
disconnected mode.
Fan Out The calendaring and scheduling process by which a calendar Disconnected Mode
operation on one calendar is also performed on every other calendar
specified in the operation. This may include the calendar associated
with TARGET calendar property.
Hierarchical Calendars A CS feature where a calendar have a A mobile computing mode where a CUA can be disconnected from a CS.
hierarchical relationship with another calendar in the CS. The top- When the CUA is disconnected, it is in the disconnected mode.
most calendar in the hierarchical relationship has the CS as its
parent. There may be multiple top-most calendars in a given CS.
Within a given hierarchical relationship, all sub-calendars have a
calendar with a "parent" topographical relationship. In addition,
sub-calendars may have a relationship with another calendar that has
a "child" topographical relationship. In addition, a calendar may
have a relationship such that one or more calendars have a "sibling"
topographical relationship with the calendar. The hierarchical
calendar feature is not a storage relationship of the calendars
within the CS. Instead it is a feature that relates access control
rights to calendar content between different calendars in the CS.
Mansour/Dawson/Royer/Taler/Hill Fan Out
Expires: April 2000 6
The hierarchical relationship of a calendar is specified in the
"PARENT" and "CHILDREN" calendar properties.
High Bandwidth Connection A communications connection supporting high The calendaring and scheduling process by which a calendar operation
transfer rates; transfer rates commonly found within a LAN. on one calendar is also performed on every other calendar specified in
the operation. This may include the calendar associated with TARGET
calendar property.
Local Store A CS which is on the same platform as the CUA. Hierarchical Calendars
Low Bandwidth Connection A communications connection supporting slow A CS feature where a calendar have a hierarchical relationship with
transfer rates; transfer rates commonly found in remote access another calendar in the CS. The top-most calendar in the hierarchical
technology. relationship has the CS as its parent. There may be multiple top-most
calendars in a given CS. Within a given hierarchical relationship, all
sub-calendars have a calendar with a "parent" topographical
relationship. In addition, sub-calendars may have a relationship with
another calendar that has a "child" topographical relationship. In
addition, a calendar may have a relationship such that one or more
calendars have a "sibling" topographical relationship with the
calendar. The hierarchical calendar feature is not a storage
relationship of the calendars within the CS. Instead it is a feature
that relates access control rights to calendar content between
different calendars in the CS. The hierarchical relationship of a
calendar is specified in the "PARENT" and "CHILDREN" calendar
properties.
Overlapped Booking A policy which indicates whether or not OPAQUE High Bandwidth Connection
events can overlap one another. When the policy is applied to a
calendar it indicates whether or not any OPAQUE events in the
calendar can overlap. When applied to an individual event, it
indicates whether or not it can be overlapped by any other OPAQUE
event.
Owner A CU or CUs that have "OWNER" calendar access rights for a A communications connection supporting high transfer rates; transfer
rates commonly found within a LAN.
Mansour/Dawson/Royer/Taler/Hill 7 Expires September 2000
Local Store
A CS which is on the same platform as the CUA.
Low Bandwidth Connection
A communications connection supporting slow transfer rates; transfer
rates commonly found in remote access technology.
Overlapped Booking
A policy which indicates whether or not OPAQUE events can overlap one
another. When the policy is applied to a calendar it indicates whether
or not any OPAQUE events in the calendar can overlap. When applied to
an individual event, it indicates whether or not it can be overlapped
by any other OPAQUE event.
Owner
One or more CUs or UGs that have "OWNER" calendar access rights for a
calendar. The owner is specified in the "OWNER" calendar property. calendar. The owner is specified in the "OWNER" calendar property.
Qualified Calendar Identifier (Qualified CalID) A CalID where both Qualified Calendar Identifier (Qualified CalID)
the <scheme> and <csid> are present.
Realm A collection of calendar user accounts, identified by a string. A CalID where both the <scheme> and <csid> are present.
The name of the realm is only used in UPNs. In order to avoid
namespace conflict, the realm SHOULD be postfixed with an appropriate
DNS domain name. (eg: the foobar realm could be called
foobar.example.com).
Relative Calendar Identifier (Relative CalID) An identifier for an Realm
individual calendar in a calendar store. It is unique within a
calendar store. It is recommended to be globally unique. A Relative
CalID consists of the portion of the "scheme part" of a Qualified
CalID following the Calendar Store Identifier. This is the same as
the "URL path" of the "Common Internet Scheme Syntax" portion of a
URL, as defined by [RFC2396].
Remote Store A CS which is not on the same platform as the CUA. A collection of calendar user accounts, identified by a string. The
name of the realm is only used in UPNs. In order to avoid namespace
conflict, the realm SHOULD be postfixed with an appropriate DNS domain
name. (eg: the foobar realm could be called foobar.example.com).
Session Identity A UPN associated with a CAP session. A session gains Relative Calendar Identifier (Relative CalID)
an identity after successful authentication. The identity is used in
combination with CAR to determine access to data in the CS.
Sub-calendars Calendars that have a "child" hierarchical relationship An identifier for an individual calendar in a calendar store. It is
with another calendar, its "parent". unique within a calendar store. It is recommended to be globally
unique. A Relative CalID consists of the portion of the "scheme part"
of a Qualified CalID following the Calendar Store Identifier. This is
the same as the "URL path" of the "Common Internet Scheme Syntax"
portion of a URL, as defined by [RFC2396].
Mansour/Dawson/Royer/Taler/Hill Remote Store
Expires: April 2000 7
User Name A name which denotes a Calendar User within a realm. This
is part of a UPN.
User Principal Name (UPN) An identifier that denotes a unique CU. A A CS which is not on the same platform as the CUA.
UPN strongly resembles an RFC 822 style email address and in some
cases it may be identical to the email address for the CU. It Mansour/Dawson/Royer/Taler/Hill 8 Expires September 2000
consists of a realm in the form of a DNS domain name and a username.
It may also have an optional instance. In it's simplest form it looks Resource Calendar (RC)
like "user@example.com".
A non-human Calendar, associated with an organizational resource.
There is no syntactic difference between an RC and a Calendar.
Session Identity
A UPN associated with a CAP session. A session gains an identity after
successful authentication. The identity is used in combination with
CAR to determine access to data in the CS.
Sub-calendars
Calendars that have a "child" hierarchical relationship with another
calendar, its "parent".
User Group (UG)
A collection of Calendar Users and/or User Groups. These groups are
expanded by the CS and may reside either locally or in an external
database or directory. The group membership may be fixed or dynamic
over time.
User Name
A name which denotes a Calendar User within a realm. This is part of a
UPN.
User Principal Name (UPN)
An identifier that denotes a unique CU. A UPN is an RFC 822 compliant
email address, with exceptions listed below, and in most cases it is
deliverable to the CU. In some cases it is identical to the CU's well
known email address. A CU's UPN MUST never be deliverable to a
different person. It consists of a realm in the form of a valid, and
unique, DNS domain name and a unique username. In it's simplest form
it looks like "user@example.com".
In certain cases a UPN will not be RFC 822 compliant. When anonymous
authentication is used, or anonymous authorization is being defined,
the special UPN "@" will be used. When authentication must be used,
but unique identity must be obscured, a UPN of the form @DNS-domain-
name may be used. For example, "@example.com". Usage of these special
cases is further discussed in the authentication and authorization
sections of this document.
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 calendar
system and how they interact with each other. 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 commands to and
receive responses from a "Calendar Service" (CS). The CUA prepares an receive responses from a "Calendar Service" (CS). The CUA prepares an
MIME encapsulated iCalendar object containing a command, sends it to MIME encapsulated iCalendar object containing a command, sends it to the
the CS, and receives an iCalendar object as a response. There are two CS, and receives an iCalendar object as a response. There are two
distinct protocols in operation to accomplish this exchange. The distinct protocols in operation to accomplish this exchange. The
Transport Protocol is used to move iCalendar objects between a CUA Transfer Protocol is used to move iCalendar objects between a CUA and a
and a CS. The Application Protocol defines the content and semantics CS. The Application Protocol defines the content and semantics of the
of the iCalendar objects sent between the CUA and the CS. This iCalendar objects sent between the CUA and the CS. This document defines
document defines both the Transport Protocol and the Application both the Transfer Protocol and the Application Protocol.
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 CS1 using
CAP. The CUA must authenticate the Calendar User (CU) so that access CAP. The CUA must authenticate the Calendar User (CU) so that access to
to calendars on CS1 can be controlled. The CUA can then view, create, calendars on CS1 can be controlled. The CUA can then view, create, edit,
edit, and delete calendars, calendar properties, and calendar and delete calendars, calendar properties, and calendar components
components subject to the access rights. 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 communicate with a
single CS to perform scheduling operations with calendars on multiple single CS to perform scheduling operations with calendars on multiple
CSs. That is, a Calendar User (CU) can book events on or read events CSs. That is, a Calendar User (CU) can book events on or read events
from calendars on other calendar stores. To accomplish this, a CAP from calendars on other calendar stores. To accomplish this, a CAP
server has several options: server has several options:
? CS1 MAY play the role of a CUA and use CAP to access CS2; ? CS1 MAY CS1 MAY play the role of a CUA and use CAP to access CS2;
be able to play the role of a CUA and use [iRIP] to interoperate with
the possible iRIP support in CS2; ? CS1 MUST be able play the role of CS1 MAY be able to play the role of a CUA and use [iRIP] to
a CUA and use [RFC2447] to interoperate with other CUAs. ? Storage interoperate with the possible iRIP support in CS2;
Agent
CS1 MUST be able play the role of a CUA and use [RFC2447] to
interoperate with other CUAs.
Storage Agent
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 8
+-----+ +-----+ +-----+ +-----+
| | 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 CUA. It Note that the fanout feature in CAP is a convenience to the CUA. It
is perfectly valid for the CUA to assume the responsibility for is perfectly valid for the CUA to assume the responsibility for
fanout if it wishes. That is, [RFC2447] messages could also be sent fanout if it wishes. That is, [RFC2447] 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 The conceptual model for a calendar store is shown below. The calendar
calendar store contains calendars, VTIMEZONEs, VCARs, and calendar store contains calendars, VTIMEZONEs, VCARs, and calendar store
store properties. properties.
Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs, VCARs, and Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs, VCARs, and
calendar properties. Calendars may also contain other calendars. calendar properties. Calendars may also contain other calendars.
+---------Calendar Store-----------------------------+ +---------Calendar Store-----------------------------+
| | | |
| | | |
| VCARs | | VCARs |
| +--calendars-------------------------+ | | +--calendars-------------------------+ |
| Properties | | | | Properties | | |
skipping to change at line 516 skipping to change at line 678
| | | 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 Relative
CALID. CALID.
Mansour/Dawson/Royer/Taler/Hill In this model, VSCHEDULE is a queue of scheduling messages that have not
Expires: April 2000 9 yet been applied to the calendar. Items in VSCHEDULE are discussed in
In this model, VSCHEDULE is a queue of scheduling messages that have more detail below.
not yet been applied to the calendar. Items in VSCHEDULE are
discussed in more detail below.
2.3 Protocol Model 2.3. Protocol Model
A generic transport, Calendar Server Transport Protocol (CSTP), is A generic transfer-layer, Calendar Server Transfer Protocol (CSTP), is
used to move data objects between a CUA and the CS. CSTP commands are used to move data objects between a CUA and the CS. CSTP commands are
listed below and their usage and semantics are defined in section 7 listed below and their usage and semantics are defined in section 7 of
of this document. 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 whose latency time has been exceeded.
AUTHENTICATE Authenticate a UPN. AUTHENTICATE Authenticate a UPN.
CONTINUE Continue the execution of a command whose latency CONTINUE Continue the execution of a command whose 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. SENDDATA Send a data object MIME encapsulated iCalendar.
STARTTLS Negotiate transport level security using [TLS] STARTTLS Negotiate transport level security using [TLS]
-------------------------------------------------------------------------
Application-level commands are used to manipulate data on the Application-level commands are used to manipulate data on the calendar
calendar store. They are listed below and discussed in detail in store. They are listed below and discussed in detail in section 7.
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 GENERATEUID Generate one or more unique ids
MODIFY Change a calendar or component MODIFY Change a calendar or component
MOVE Move a calendar MOVE Move a calendar
READ Read a calendar properties or components READ Read a calendar properties or components
-------------------------------------------------------------------------
CAP Scheduling Commands CAP Scheduling Commands
----------------------------------------------------------------------- -------------------------------------------------------------------------
Command Description Command Description
------------ -------------------------------------------------------- -------------------------------------------------------------------------
PUBLISH publish a calendar entry to one or more calendars PUBLISH Publish a calendar entry to one
REQUEST schedule a calendar entry with one or more calendars or more calendars.
REPLY response to a scheduling request
ADD add one or more instances to an existing calendar entry
Mansour/Dawson/Royer/Taler/Hill Mansour/Dawson/Royer/Taler/Hill 12 Expires September 2000
Expires: April 2000 10 REQUEST Schedule a calendar entry with
CANCEL cancel one or more instances to an existing calendar one or more calendars.
entry
REFRESH a request for the latest version of a calendar entry
COUNTER a request for a change (a counter-proposal) to a
calendar entry
DECLINECOUNTER decline a counter proposal
2.4 Roles REPLY Response to a scheduling request.
CAP defines methods for managing [RFC2445] objects on a Calendar ADD Add one or more instances to an
Store and exchanging [RFC2445] objects for the purposes of group existing calendar entry.
calendaring and scheduling between "Calendar Users" (CUs). There are
two distinct roles taken on by CUs in CAP. The CU who creates an
initial event or to-do and invites other CUs as attendees takes on
the role of "Organizer". The CUs asked to participate in the group
event or to-do take on the role of "Attendee". Note that "role" is
also a descriptive parameter to the "ATTENDEE" property. Its use is
to convey descriptive context to an "Attendee" such as "chair", "REQ-
PARTICIPANT" or NON- PARTICIPANT" and has nothing to do with the
scheduling workflow.
2.5 Calendar User CANCEL Cancel one or more instances to
an existing calendar entry.
REFRESH A request for the latest version
of a calendar entry.
COUNTER A request for a change (a
counter-proposal) to a calendar
entry.
DECLINECOUNTER Decline a counter proposal.
-------------------------------------------------------------------------
2.4. Security Model
Authentication to the CS will be performed using SASL [RFC2222].
As noted in the CAP system model section, a variety of connectivity
scenarios are possible. This complicates the security model
considerably, and a thorough familiarity with the concepts is required
to ensure interoperability.
Basic threats to a Calendaring and Scheduling System include:
(1) Unauthorized access to data via data-fetching operations,
(2) Unauthorized access to reusable client authentication
information by monitoring others' access,
(3) Unauthorized access to data by monitoring others' access,
(4) Unauthorized modification of data,
(5) Unauthorized or excessive use of resources (denial of
service), and
(6) Spoofing of CS: Tricking a client into believing that
information came from the CS when in fact it did not, either by
modifying data in transit or misdirecting the client's
connection.
Threats (1), (4), (5) and (6) are due to hostile clients. Threats (2),
and (3) are due to hostile agents on the path between client and server,
or posing as a server.
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 [RFC2222] mechanism
set, possibly backed by the TLS credentials exchange mechanism,
(2) Client authorization by means of access control based on the
requestor's authenticated identity,
(3) Data integrity protection by means of the TLS protocol or
data-integrity SASL mechanisms,
(4) Protection against snooping by means of the TLS protocol or
data-encrypting SASL mechanisms,
(5) Resource limitation by means of administrative limits on service
controls, and
(6) Server authentication by means of the TLS protocol or SASL
mechanism.
Imposition of access controls (authorizations) is done by means of
VCARs, an overview is provided in section <fwd ref>, and a detailed
syntax is provided in section <fwd ref>. Authentication is explained in
detail in section <fwd ref>.
2.4.1. Authentication, Credentials, and Identity
Generically, authentication credentials are the evidence supplied by one
party to another, asserting the identity of the supplying party (e.g. a
user) who is attempting to establish an association with the other party
(typically a server). Authentication is the process of generating,
transmitting, and verifying these credentials and thus the identity they
assert. An authentication identity is the name presented in a
credential.
There are many forms of authentication credentials. The form used
depends upon the particular authentication mechanism negotiated by the
parties. For example: X.509 certificates, Kerberos tickets, simple
identity and password pairs. Note that an authentication mechanism may
constrain the form of authentication identities used with it.
SASL only provides a protocol to negotiate a mutually acceptable
authentication mechanism. SASL itself does not constrain or dictate the
form of the authentication identities used to perform the
authentication.
2.4.2. 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. It is
represented in CAP as a UPN. A UPN is the owner of a calendar and the represented in CAP as a UPN. A UPN is the owner of a calendar and the
subject of access rights. subject of access rights. The UPN representation is independent of the
authentication mechanism used during a particular CUA/CS interaction.
This is because UPNs are used within VCARs. If the UPN were dependant on
the authentication mechanism, a VCAR could not be consistently
evaluated. A CU may use one mechanism while using one CUA but the same
CU may use a different authentication mechanism when using a different
Examples: Mansour/Dawson/Royer/Taler/Hill 14 Expires September 2000
user@example.com CUA, or while connecting from a different location.
user/cap@example.com
The UPN representation is independent of the authentication mechanism The user may also have multiple UPNs for various purposes.
used during a particular CUA / CS interaction. A CU may use one
mechanism while using one CUA but the same user may use a different
authentication mechanism when using a different CUA, or while
connecting from a different location.
For Calendaring and Scheduling systems that are integrated with a Note that the immutability of the user's UPN may be achieved by using
directory system the UPN SHOULD be stored in the attribute [TBD] with SASL's authorization identity feature. (The transmitted authorization
OID [TBD]. This enables a clear mapping between a UPN and a identity may be different than the identity in the client's
Distinguished Name. [note: Microsoft's Active Directory is storing authentication credentials.) [RFC2222, section 3] This also permits a CU
UPNs as the userPrincipalName.] Within a directory service a UPN is a to authenticate using their own credentials, yet request the access
single valued property. privileges of the identity for which they are proxying [RFC2222]. Also,
the form of authentication identity supplied by a service like TLS may
not correspond to the UPNs used to express a server's access control
policy, requiring a server-specific mapping to be done. The method by
which a server composes and validates an authorization identity from the
authentication credentials supplied by a client is implementation-
specific.
2.5.1 UPNs and Certificates For Calendaring and Scheduling Systems that are integrated with a
directory system, the CS MUST support the ability to configure which
schema attribute stores the UPN. The CS MAY allow one or more attributes
to be searched for the UPN.
When using certificates for purposes of CAP authentication, the 2.4.2.1. UPNs and Certificates
Mansour/Dawson/Royer/Taler/Hill When using X.509 certificates for purposes of CAP authentication, the
Expires: April 2000 11 UPN should appear in the certificate. Unfortunately there is no single
SubjectName field of the user's certificate SHOULD contain the user's correct guideline for which field should contain the UPN.
UPN (for example, "juser@example.com") as the value of the "CN="
component, and the user's email address (often the same as the UPN)
as the value of the "E=" component . The altSubjectName will contain
the DN of the user's account object in the DS. The Issuer field must
be that of a root CA trusted to issue login certificates, or the DN
of a lower level CA whose certificate includes an
"AuthorizedNamingContext" field that authorizes it to issue
certificates for "example.com" (exact field name and validation
mechanism TBD).
Note: If a server is validating data received via iMIP, if the From RFC-2459, section 4.1.2.6 (Subject):
"ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe
Random User:juser@example.com" then the "juser@example.com" part If subject naming information is present only in the subjectAltName
should be checked against the altSubjectName field of the extension (e.g., a key bound only to an email address or URI), then
certificate, and the "Joe Random User" part should be checked against the subject name MUST be an empty sequence and the subjectAltName
the CN component of the altSubjectName DN. This is so the "ATTENDEE" extension MUST be critical.
Implementations of this specification MAY use these comparison rules
to process unfamiliar attribute types (i.e., for name chaining).
This allows implementations to process certificates with unfamiliar
attributes in the subject name.
In addition, legacy implementations exist where an RFC 822 name is
embedded in the subject distinguished name as an EmailAddress
attribute. The attribute value for EmailAddress is of type
IA5String to permit inclusion of the character '@', which is not
part of the PrintableString character set. EmailAddress attribute
values are not case sensitive (e.g., "fanfeedback@redsox.com" is the
same as "FANFEEDBACK@REDSOX.COM").
Conforming implementations generating new certificates with
electronic mail addresses MUST use the rfc822Name in the subject
alternative name field (see sec. 4.2.1.7 [of RFC 2459]) to describe
Mansour/Dawson/Royer/Taler/Hill 15 Expires September 2000
such identities. Simultaneous inclusion of the EmailAddress
attribute in the subject distinguished name to support legacy
implementations is deprecated but permitted.
Since no single method of including the UPN in the certificate will work
in all cases, CAP implementations MUST support the ability to configure
what the mapping will be by the CS administrator. Implementations MAY
support multiple mapping definitions, for example, the UPN may be found
in either the subject alternative name field, or the UPN may be embedded
in the subject distinguished name as an EmailAddress attribute.
Note: If a CS or CUA is validating data received via iMIP, if the
"ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe Random
User:juser@example.com" then the email address should be checked against
the UPN, and the CN should also be checked. This is so the "ATTENDEE"
property couldn't be munged to something misleading like property couldn't be munged to something misleading like
"ATTENDEE;CN=Joe Rictus User:juser@example.com" and have it pass "ATTENDEE;CN=Joe Rictus User:juser@example.com" and have it pass
validation. This validation will also defeat other attempts at validation. This validation will also defeat other attempts at
confusion. confusion.
2.5.2 CAP session identity 2.4.2.2. Anonymous Users and Authentication
A CAP session has an assocatied set of authentication credentials, Anonymous access is often desirable. For example an organization may
from which is derived a UPN. This UPN is the identity of the CAP publish calendar information that does not require any access control
session, and is used to determine access rights for the session. for viewing or login. Conversely, a user may wish to view unrestricted
calendar information without revealing their identity.
The CUA may change the identity of a CAP session by calling the CAP implementations MUST support anonymous authentication, as defined in
"IDENTIFY" command. The Calendar Service only permits the operation section <fwd ref 7.1.3>.
if the session's authentication credentials are good for the
requested identity. The method of checking this permission is
implementation dependant, but may be thought of as a mapping from
authentication credentials to UPNs. The "IDENTIFY" command allows a
single set of authentication credentials to choose from multiple
identities, and allows multiple sets of authentication credentials to
assume the same identity.
For anonymous access the identity of the session is "@", a UPN with a CAP implementations MAY support anonymous authentication with TLS, as
null username and null realm. A UPN with a null username, but non- defined in section <fwd ref 7.1.3.2>.
null realm, such as "@foo.com" may be used to mean any identity from
that realm, which is useful to grant access rights to all users in a
given realm. A UPN with a non-null username and null realm, such as
"bob@" could be a security risk and must not be used.
Since the UPN includes realm information it may be used to govern 2.4.2.3. Required Security Mechanisms
calendar store access rights across realms. However, governing access
Mansour/Dawson/Royer/Taler/Hill The following implementation conformance requirements are in place:
Expires: April 2000 12
rights across realms is only useful if login access is available.
This could be done through a trusted server relationship or a
temporary account.
The "IDENTIFY" command provides for a weak group implementation. By (1) For a read-only, public CS, anonymous authentication,
allowing multiple sets of authentication credentials belonging to described in section <fwd ref 7.1.3.1>, can be used.
different users to identify as the same UPN, that UPN essentially
identifies a group of people, and may be used for group calendar
ownership, or the granting of access rights to a group.
2.6 Calendar Addresses (2) Implementations providing password-based authenticated access
MUST support authentication using Digest, as described in
section <fwd ref>. This provides client authentication with
protection against passive eavesdropping attacks, but does
not provide protection against active intermediary attacks.
Calendar addresses are URIs that are modeled after [RFC2396]. CAP (3) For a CS needing session protection and authentication, the Start
uses the following forms of URI. TLS extended operation, and either the simple authentication choice
or the SASL EXTERNAL mechanism, are to be used together.
[[<scheme>]://<csid>[:<port>]/]<relativeCALID> Mansour/Dawson/Royer/Taler/Hill 16 Expires September 2000
Implementations SHOULD support authentication with a password as
described in section <fwd ref>, and SHOULD support authentication
with a certificate as described in section <fwd ref>. Together,
these can provide integrity and disclosure protection of
transmitted data, and authentication of client and server,
including protection against active intermediary attacks.
where: 2.4.2.4. TLS Ciphersuites
? <scheme> is "cap" ? <csid> is the Calendar Store ID. It is the The following ciphersuites defined in [RFC 2246] MUST NOT be used for
network address of the computer on which the CAP server is running ? confidentiality protection of passwords or data:
<port> is optional. Its default value is 5229. The port must be
present if the CAP server does not listen on the default port. ?
<relativeCALID> is an identifier that uniquely identifies the
calendar on a particular calendar store. There is no implied
structure in a Relative CALID. It is an arbitrary string of 7 bit
ASCII characters. It may refer to the calendar of a user or of a
resource such as a conference room. It MUST be unique within the
calendar store. It is recommended that the Relative CALID be globally
unique.
If the <scheme> and <csid> are present the calendar address is said TLS_NULL_WITH_NULL_NULL TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA
to be "qualified". Senders are required to supply the <relativeCALID>
portion of the address. A qualified calendar address is required when The following ciphersuites defined in [RFC 2246] can be cracked easily
the <csid> of the target calendar address differs from that of the (less than a week of CPU time on a standard CPU in 1997). The client
CAP server receiving the command. and server SHOULD carefully consider the value of the password or data
being protected before using these ciphersuites:
TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
The following ciphersuites are vulnerable to man-in-the-middle attacks,
and SHOULD NOT be used to protect passwords or sensitive data, unless
the network configuration is such that the danger of a man-in-the-middle
attack is tolerable:
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
A client or server that supports TLS MUST support at least
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
2.4.3. User Groups
User Group is used to represent a collection of CUs or other UGs that
can be referenced in VCARS. A UG is represented in CAP as a UPN. The
CUA cannot distinguish between a UPN that represents a CU or a UG.
UGs are expanded as necessary by the CS. The CS MUST accept a CUA
request for UG expansion, although the CS may be configured to restrict
some responses. The CS MAY expand a UG (including nested UGs) to obtain
a list of unique CUs. Duplicate UPNs are filtered during expansion.
Mansour/Dawson/Royer/Taler/Hill 17 Expires September 2000
Incomplete expansion should be treated as a failure.
[ Editor's Note: We need to explore the issue and impact of directory
permissions and precedence.]
The CS SHOULD not preserve UG expansions across operations. A UG may
reference a static list of members, or it may represent a dynamic list.
Each operation SHOULD generate its own expansion in order to recognize
changes to UG membership. 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
having a common directory. We think the above text resolves this]
CAP does not define commands or methods for managing UGs.
Examples: Examples:
cap://calendar.example.com/user1 Small UG - The Three Stooges. There is only and always three at any
://calendar.example.com/user1 one time.
user1 Large UG - The MIT graduating class of 1999. This is a static list.
cap://calendar.example.com/conferenceRoomA Dynamic UG - The IETF membership, which is a large and changing list
cap://calendar.example.com/89798-098-zytytasd of members.
Nested UG - The National Football League, made up of the AFC and
NFC, which are made up of 3 divisions each...
For a user currently authenticated to a CAP server on 2.4.4. Access Rights
calendar.example.com, the first three addresses refer to the same
Mansour/Dawson/Royer/Taler/Hill In simple terms, access rights are used to grant or deny access to a
Expires: April 2000 13 calendar for a CU. CAP defines a new component type called a VCalendar
calendar. Access Right (VCAR). Specifically, a VCAR grants, or denies, UPNs the
right to read and write components, properties, and parameters on
calendars within a CS.
2.7 Finding CAP Servers The VCAR model does not put any restriction on the sequence in which the
object and access rights are created. That is, an event associated with
a particular VCAR might be created before or after the actual VCAR is
defined. In addition, the VCAR and VEVENT definition might be created in
the same iCalendar object and passed together in a single command.
2.7.1 Using DNS All rights MUST be denied unless specifically granted; individual VCARs
MUST be specifically granted to an authenticated CU.
<TBD> 2.4.4.1. VCalendar Access Right (VCAR)
2.7.2 Using SLP Access rights within CAP are specified with the "VCAR" calendar
component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID"
component properties.
This section assumes that the reader is familiar with RFC2608 and Mansour/Dawson/Royer/Taler/Hill 18 Expires September 2000
RFC2609. The Service Location Protocol (SLP) as defined in [RFC2608]: Properties within an iCalendar object are unordered. This also is the
case for the "GRANT", "DENY" and "CARID" properties. Likewise,
there is no implied ordering required for components of a "RIGHTS" value
type other than that specified by the ABNF. [ editor's note, this
requires a lot of review. We think that this paragraph may be incorrect.
]
"The Service Location Protocol provides a scalable framework for For details on the VCAR syntax please see section <forward ref>
the discovery and selection of network services. Using this
protocol, computers using the Internet need little or no static
configuration of network services for network based
applications. This is especially important as computers become
more portable, and users less tolerant or able to fulfill the
demands of network system administration."
Each service defines itself so that client applications may locate 2.4.4.2. Decreed VCARs
the service using predefined parameters that apply to that specific
service. Below are the definitions for the CAP "Service Template" as
defined in [RFC2609].
Name of submitter: "Doug Royer" <Doug.Royer@Software.com> [editor's note: new concept. This will also require some syntax
Language of service template: en modification 14.4. This section is being actively discussed on the
Security Considerations: <TBD> working group list, 2/3/2000.]
Template Text: A CS MAY choose to implement and allow persistent immutable VCARs, that
------------------------template begins here------------------- are configured by the CS Administrator, which apply to all calendars on
template-type=Calendar-Access-Protocol the server.
# The version will be updated to 1.0 as CAP becomes an RFC. When a user attempts to modify a decreed VCAR and error will be
template-version=0.0 returned,indicating that the user has insufficient authorization to
perform the operation.
template-description= The CAP protocol does not define the semantics used to initially create
The Calendar-Access-Protocol service provides the location a decreed VCAR. This administrative task is out side the scope of the
of iCalendar services. CAP protocol.
# Services can be located or defined with one or more 2.4.4.3. Inheritance
# of the following parameters:
#
# <port> Port number CAP service is listening to.
#
# <calendar> Find calendar by calendar name.
Mansour/Dawson/Royer/Taler/Hill Calendars inherit VCARs from their parent.
Expires: April 2000 14
#
# <user> User name associated with the service.
# Aids in locating a calendar or calendars
# associated with a user name <string>.
#
# <scheme> CAP is the only SCHEME supported
#
# <email> Find calendars associated with an
# email address.
#
# <upn> Find calendars associated with a UPN.
#
template-url-syntax=
url-options = url-port / url-calendar /
url-user / url-scheme /
url-email / url-upn
# The port number(s) the CAP server listens on. VCARs specified in a calendar or a sub-calendar override all inherited
url-port = "ports=" ports-list VCARs.
ports-list = port / port "," ports-list
port = 1*DIGIT
# The CalID for the calendar. 2.4.5. CAP session identity
url-calendar = "CalID=" calid-list
calid-list = CalID / CalID "," CalID
# A user associated with a calendar user. A CAP session has an associated set of authentication credentials, from
url-user = "user=" user-list which is derived a UPN. This UPN is the identity of the CAP session, and
user-list = user / user "," user-list is used to determine access rights for the session.
user = # A CU as defined by
# the CS implementation,
# Which URL-scheme's are supported by the CS: The CUA may change the identity of a CAP session by calling the
url-scheme = "scheme=" scheme-list "IDENTIFY" command. The Calendar Service only permits the operation if
scheme-list = scheme / scheme "," scheme-list the session's authentication credentials are good for the requested
scheme = CAP # Only CAP supported at identity. The method of checking this permission is implementation
# this time. dependent, but may be thought of as a mapping from authentication
credentials to UPNs. The "IDENTIFY" command allows a single set of
authentication credentials to choose from multiple identities, and
allows multiple sets of authentication credentials to assume the same
identity.
# Names of calendars associated with an email address. Mansour/Dawson/Royer/Taler/Hill 19 Expires September 2000
url-email = "mailto=" email-list For anonymous access the identity of the session is "@", a UPN with a
email-list = email / email "," email-list null username and null realm. A UPN with a null username, but non-null
email = # An RFC822 email address realm, such as "@foo.com" may be used to mean any identity from that
realm, which is useful to grant access rights to all users in a given
realm. A UPN with a non-null username and null realm, such as "bob@"
could be a security risk and must not be used.
# Names of calendars associated with a UPN. Since the UPN includes realm information it may be used to govern
url-upn = "mailto=" upn-list calendar store access rights across realms. However, governing access
upn-list = upn / upn "," upn-list rights across realms is only useful if login access is available. This
upn = # An RFC822 upn address could be done through a trusted server relationship or a temporary
account.
Mansour/Dawson/Royer/Taler/Hill The "IDENTIFY" command provides for a weak group implementation. By
Expires: April 2000 15 allowing multiple sets of authentication credentials belonging to
-------------------------template ends here--------------------- different users to identify as the same UPN, that UPN essentially
identifies a group of people, and may be used for group calendar
ownership, or the granting of access rights to a group.
Example of SLP advertisement: Examples:
URL = Small UG - The Three Stooges. There will always be three, it will
service:Calendar-Access-Protocol://cal.example.com/ports=1234 not change.
Attributes = (location-description=Net iCal server1),
(CalID=Doug.Royer,Steve.Mansour,Conference-RM1),
(user="Doug Royer", "Steve Mansour", "Conference Room 1"),
(scheme=CAP),
(email="Doug.Royer@Software.com","Doug@Royer.com","droyer@software.com, Large UG - The MIT graduating class of 1999. This is a static list.
"sman@netscape.com","ConfRoom1@example.com"),
(upn=droyer@software.com,sman@netscape.com),
(template-url-syntax=\0D
url-options = url-port / url-calendar / url-user \0D
/ url-scheme / url-email / url-upn \0D
url-port = "ports=" ports-list \0D
ports-list = port / port "," ports-list \0D
port = 1*DIGIT \0D
url-calendar = "CalID=" calid-list \0D
calid-list = CalID / CalID "," CalID \0D
url-user = "user=" user-list \0D
user-list = user / user "," user-list \0D
url-scheme = "scheme=" scheme-list \0D
scheme-list = scheme / scheme "," scheme-list \0D
scheme = CAP \0D
url-email = "mailto=" email-list \0D
email-list = email / email "," email-list \0D
url-upn = "mailto=" upn-list \0D
upn-list = upn / upn "," upn-list\0D)
2.8 Extensions to iCalendar Dynamic UG - The IETF membership, which is a large and changing
list of members.
Nested UG - The National Football League, made up of the AFC and
NFC, which are made up of 3 divisions each...
2.5. Roles
CAP defines methods for managing [RFC2445] objects on a Calendar Store
and exchanging [RFC2445] objects for the purposes of group calendaring
and scheduling between "Calendar Users" (CUs) or "User Groups" (UGs).
There are two distinct roles taken on by CUs in CAP. The CU who creates
an initial event or to-do and invites other CUs or UGs as attendees
takes on the role of "Organizer". The CUs or UGs asked to participate in
the group event or to-do take on the role of "Attendee". Note that
"role" is also a descriptive parameter to the "ATTENDEE" property. Its
use is to convey descriptive context to an "Attendee" such as "chair",
"REQ-PARTICIPANT" or NON- PARTICIPANT" and has nothing to do with the
scheduling workflow.
Mansour/Dawson/Royer/Taler/Hill 20 Expires September 2000
2.6. Calendar Addresses
Calendar addresses are URIs that are modeled after [RFC2396]. CAP uses
the following forms of URI.
[[<scheme>]://<csid>[:<port>]/]<relativeCALID>
where:
<scheme> is "cap"
<csid> is the Calendar Store ID. It is the network address of the
computer on which the CAP server is running.
<port> is optional. Its default value is 5229. The port must be present
if the CAP server does not listen on the default port.
<relativeCALID> is an identifier that uniquely identifies the calendar
on a particular calendar store. There is no implied structure in a
Relative CALID. It is an arbitrary string of 7 bit ASCII characters. It
may refer to the calendar of a user or of a resource such as a
conference room. It MUST be unique within the calendar store. It is
recommended that the Relative CALID be globally unique.
If the <scheme> and <csid> are present the calendar address is said to
be "qualified". Senders are required to supply the <relativeCALID>
portion of the address. A qualified calendar address is required when
the <csid> of the target calendar address differs from that of the CAP
server receiving the command.
Examples:
cap://calendar.example.com/user1
://calendar.example.com/user1
user1
cap://calendar.example.com/conferenceRoomA
cap://calendar.example.com/89798-098-zytytasd
For a user currently authenticated to a CAP server on
calendar.example.com, the first three addresses refer to the same
calendar.
2.7. 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 rights onto
the iCalendar format, several extended iCalendar methods and the iCalendar format, several extended iCalendar methods and components
components are defined by this memo. are defined by this memo.
* The search function is specified with the new iCalendar QUERY * The search function is specified with the new iCalendar QUERY
method. The QUERY method makes use of a new component, called method. The QUERY method makes use of a new component, called
VQUERY, that contains the search filter. The component consists VQUERY, that contains the search filter. The component consists of
of 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 Mansour/Dawson/Royer/Taler/Hill 21 Expires September 2000
component. a set of new properties: SCOPE, MAXRESULTS, MAXRESULTSSIZE, QUERY
and QUERYNAME, that define the search filter.
* The iCalendar METHOD property format has been updated with new * Access control is specified the the new iCalendar VCAR component.
Mansour/Dawson/Royer/Taler/Hill * The iCalendar METHOD property format has been updated with new
Expires: April 2000 16
values. values.
* A new iCalendar component, VCOMMAND, has been added. VCOMMANDs * A new iCalendar component, VCOMMAND, has been added. VCOMMANDs
are needed to fully specify CAP commands. 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
2.9 Relationship of RFC 2446 (ITIP) to CAP 2.8. Relationship of RFC 2446 (ITIP) to CAP
[RFC2446] describes scheduling methods which result in indirect [RFC2446] describes scheduling methods which result in indirect
manipulation of calendar components. CAP methods provide direct manipulation of calendar components. CAP methods provide direct
manipuation of calendar components. In the CAP calendar store model, manipulation of calendar components. In the CAP calendar store model,
scheduling messages are kept separate from other calendar components. scheduling messages are kept separate from other calendar components.
This is modeled with the VSCHEDULE queue. Note that this is a This is modeled with the VSCHEDULE queue. Note that this is a conceptual
conceptual model, the actual storage details are left to model, the actual storage details are left to implementations. The model
implementations. The model is shown pictorially as follows: 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 The METHOD is saved along with components. Scheduled components become
become booked components when the METHOD changes from an ITIP method booked components when the METHOD changes from an ITIP method to the CAP
to the CAP storage method. For example, a component whose METHOD is storage method. For example, a component whose METHOD is "REQUEST" is
"REQUEST" is scheduled. The component becomes booked when the METHOD scheduled. The component becomes booked when the METHOD is changed to
is changed to "CREATED". "CREATED".
[ed note: need to clean up the terminology here. We havent discussed [ed note: need to clean up the terminology here. We havent discussed
"booked"] "booked"]
2.10 VCalendar Access Rights (VCARs) Mansour/Dawson/Royer/Taler/Hill 22 Expires September 2000
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 calendar
for a Calendar User. Specifically, they grant User Principal Names for a CU or UG. Specifically, they grant User Principal Names (UPNs) the
(UPNs) the rights to read and write components, properties, and rights to read and write components, properties, and parameters on
parameters on calendars within a calendar store. calendars within a calendar store.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 17
The model does not put any restriction on the sequence in which the The model does not put any restriction on the sequence in which the
object and access rights are created. That is, an event associated object and access rights are created. That is, an event associated with
with a particular VCAR might be created before or after the actual a particular VCAR might be created before or after the actual VCAR is
VCAR is defined. In addition, the VCAR and VEVENT definition might be defined. In addition, the VCAR and VEVENT definition might be created in
created in the same iCalendar object and passed together in a single the same iCalendar object and passed together in a single SENDDATA
SENDDATA command. command.
2.11 Query Schema VCAR principals can be CU or UG UPNs. Whenever VCARs are evaluated, all
referenced User Groups MUST be evaluated as an expanded list. UG
expansion SHOULD NOT persist across operations.
[Editor's Note: This is where we need to define precedence rules.]
2.10. Query Schema
<TBD> breif paragraph on summary of VQUERY.
3. State Diagram 3. State Diagram
This section describes the states of the transport connection between This section describes the states of the transport connection between a
a CUA and a CS. The state diagram is shown below. State names shown CUA and a CS. The state diagram is shown below. State names shown with
with first letter capitalized. The commands used to switch between first letter capitalized. The commands used to switch between states are
states are shown next to an arrow connecting the states. The commands shown next to an arrow connecting the states. The commands are listed in
are listed in all capital letters. A condition that causes a state to all capital letters. A condition that causes a state to change is shown
change is shown in lower case letters. in lower case letters.
Mansour/Dawson/Royer/Taler/Hill 23 Expires September 2000
STARTTLS / STARTTLS /
CAPABILITY CAPABILITY
+-------+ +-------+
| | +---------------+ | | +---------------+
| +-----------+ AUTHENTICATE | | | +-----------+ AUTHENTICATE | |
+-->| Connected |-------------->| Authenticated | +-->| Connected |-------------->| Authenticated |
+-----------+ | | +-----------+ | |
| +---------------+ | +---------------+
| | | |
| | | |
skipping to change at line 963 skipping to change at line 1308
| +--------| | | | +--------| | |
| | +---------------+ | command | | +---------------+ | command
| | | | completes | | | | completes
V |DISCONNECT | | V |DISCONNECT | |
+--------------+ | |SENDDATA | +--------------+ | |SENDDATA |
| Disconnected |<--+ | | | Disconnected |<--+ | |
+--------------+ | | ABORT +--------------+ | | ABORT
A | | A | |
| V | | V |
| DISCONNECT +---------------+ | | DISCONNECT +---------------+ |
+--------------------| Receive |--------+ +--------------------| Receive |--+
| |<--+ | |<--+
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 18
+---------------+ | +---------------+ |
| | CONTINUTE | | CONTINUTE
+----+ +----+
The connection begins the Connected state when a CUA connects to a CAP The connection begins the Connected state when a CUA connects to a CAP
server. The capabilities of the CS are reported in the response from server. The capabilities of the CS are reported in the response from the
the CS. From this state, the CUA can issue the DISCONNECT command to CS. From this state, the CUA can issue the DISCONNECT command to
terminate the connection, the CAPABILITY, STARTTLS, or AUTHENTICATE terminate the connection, the CAPABILITY, STARTTLS, or AUTHENTICATE
commands. One use of the CAPABILITY command at this stage is to commands. One use of the CAPABILITY command at this stage is to
determine the supported authentication mechanisms supported by the determine the supported authentication mechanisms supported by the
server. Once the STARTTLS command has been successfully executed from server. Once the STARTTLS command has been successfully executed from
either the Connected or Authenticated state, it must not be executed either the Connected or Authenticated state, it must not be executed
again. again.
If an AUTHENTICATE command is successful, the connection enters the If an AUTHENTICATE command is successful, the connection enters the
Authenticated state and then immediately goes to the IDENTIFIED state. Authenticated state and then immediately goes to the IDENTIFIED state.
From here the CUA can issue the CAPABILITY command. The capabilities While in the Identified state, allow CALIDEXPAND and UPNEXPAND commands.
the server offers in the Authenticated state may be different than From here the CUA can issue the CAPABILITY command. The capabilities the
those in the Connected state. The CUA can also use the IDENTIFY command server offers in the Authenticated state may be different than those in
to change the identity of the user subject to access control. The the Connected state. The CUA can also use the IDENTIFY command to change
connection remains in the Authenticated state after the CAPABILITY the identity of the user subject to access control. The connection
command completes. The CUA can issue the DISCONNECT command to remains in the Authenticated state after the CAPABILITY command
terminate the connection. The SENDDATA command can be used to send a
request to read, write, modify, or delete data on the server. Mansour/Dawson/Royer/Taler/Hill 24 Expires September 2000
completes. The CUA can issue the DISCONNECT command to terminate the
connection. The SENDDATA command can be used to send a request to read,
write, modify, or delete data on the server.
After the SENDDATA command has been issued the connection enters the After the SENDDATA command has been issued the connection enters the
Receive state while the CUA awaits and reads a server reply. Normally, Receive state while the CUA awaits and reads a server reply. Normally,
the server handles the command, sends a reply which is read by the CUA the server handles the command, sends a reply which is read by the CUA
and the connection returns to the Authenticated state. The CUA may have and the connection returns to the Authenticated state. The CUA may have
issued the SENDATA command with a maximum latency time. This informs issued the SENDATA command with a maximum latency time. This informs the
the server that the CUA expects a response within the maximum latency server that the CUA expects a response within the maximum latency time,
time, even if the command was not completed. When the server is unable even if the command was not completed. When the server is unable to
to complete the command in the maximum latency time, it issues an complete the command in the maximum latency time, it issues an
appropriate reply code and waits for the CUA to tell it how to proceed. appropriate reply code and waits for the CUA to tell it how to proceed.
If the CUA issues a CONTINUE command the server continues processing If the CUA issues a CONTINUE command the server continues processing the
the command and the connection remains in the Receive state. If the CUA command and the connection remains in the Receive state. If the CUA
issues the ABORT command the server need not process the command any issues the ABORT command the server need not process the command any
further and the connection returns to the Authenticated state. The further and the connection returns to the Authenticated state. The
DISCONNECT command can also be issued from the Receive state. 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 the calendar
store. Commands and responses are transmitted between the CUA and CS store. Commands and responses are transmitted between the CUA and CS
inside "VCALENDAR" component wrappers. Commands are specified as the inside "VCALENDAR" component wrappers. Commands are specified as the
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 19
value of a "METHOD" property, and responses are specified as the value value of a "METHOD" property, and responses are specified as the value
of a "REQUEST-STATUS" property. of a "REQUEST-STATUS" property.
4.2 CAP Transport Layer 4.2. CAP Transfer Protocol
The CAP transport layer handles the transmission of CAP application The CAP transfer protocol defines the format of data transmitted between
layer messages. a CUA and the CS.
CAP transport layer commands are transmitted across the underlying CAP transfer protocol commands are transmitted using the underlying
transport. The transport used is a TCP/IP socket connection between the transport. The transport used is a TCP/IP socket connection between the
CUA and the CS. The CS listens for connections on port <xyz>. CUA and the CS. The default port that the CS listens for connections on
is port 5229.
Messages sent between the CUA and CS are formatted as a command Messages sent between the CUA and CS are formatted as a command followed
followed by any associated data: 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:
<response code> [; debug text ; more text] <transfer-level response-code> [response args] [; debug text ; more
[<CRLF><application-data>]<CRLF>.CRLF>
Mansour/Dawson/Royer/Taler/Hill 25 Expires September 2000
text] <CRLF>.<CRLF> [<application-data>] <CRLF>.<CRLF>
The response codes are defined in Section 8. The debug text is human- The response codes are defined in Section 8. The debug text is human-
readable information for protocol debugging. readable information for protocol debugging and is optional.
The optional application-data begins on the next line. The optional application-data begins on the next line.
The response is terminated with a <CRLF> "." <CRLF> sequence. Any The response is terminated with the second <CRLF> "." <CRLF> sequence.
<CRLF> "." sequences which appear in the transmitted data must be Any <CRLF> "." sequences which appear in the transmitted data must be
quoted by placing an additional "." between the <CRLF> and the ".". For quoted by placing an additional "." between the <CRLF> and the ".". For
example, the following sequences of characters in the application data: example, the following sequences of characters in the application data:
.
..2
...3
are quoted as follows: are quoted as follows:
No other tagged command sequence can be sent until the special ..
...2
....3
No other tagged command sequence can be sent until the second special
terminating character sequence <CRLF>.<CRLF> has been sent. terminating character sequence <CRLF>.<CRLF> has been sent.
4.4 Auto-logout Timer 4.4. Auto-logout Timer
If a server has an inactivity auto-logout timer, that timer MUST be of If a server has an inactivity auto-logout timer, that timer MUST be of
at least 15 minutes duration. The receipt of ANY command from the at least 15 minutes duration. The receipt of ANY command from the client
client during that interval MUST suffice to reset the auto-logout during that interval MAY reset the auto-logout timer, subject to CS
timer. administrators policy. A CUA may be discouraged from attempts to do
usless things only to keep the connection alive.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 20
When a timeout occurs, the server drops the connection to the CUA. When a timeout occurs, the server drops the connection to the CUA.
4.5 Bounded Latency 4.5. Bounded Latency
[CAP] is designed so that the CUA can either obtain an immediate [CAP] is designed so that the CUA can either obtain an immediate
response from a request or discover within a specified amount of time response from a request or discover within a specified amount of time
that the request could not be completed in the requested amount of that the request could not be completed in the requested amount of time.
time. When the CUA initiates a command that the server cannot complete When the CUA initiates a command that the server cannot complete within
within the specified latency time, the server returns an appropriate the specified latency time, the server returns an appropriate response
response code. The CUA then issues either a CONTINUE or ABORT command. code. The CUA then issues either a CONTINUE or ABORT command. The ABORT
The ABORT command immediately terminates the command in progress and command immediately terminates the command in progress and the
the connection returns to the Authenticated state. The CONTINUE command connection returns to the Authenticated state. The CONTINUE command
instructs the server to continue processing the command. instructs the server to continue processing the command.
4.6 Data Elements Mansour/Dawson/Royer/Taler/Hill 26 Expires September 2000
4.6. Data Elements
The data elements for CAP are MIME encapsulated iCalendar objects. 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 searching and filtering entities within a
remote store. It is based on the Standard Query Language (SQL) defined remote store. It is based on the Standard Query Language (SQL) defined
by [SQL]. by [SQL].
The QUERY property value MUST be a valid QUERY value type. This new The QUERY property value MUST be a valid QUERY value type. This new
value type is defined to be a "name=value" value type grammar, similar 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 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., 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 SELECT, WHERE, etc.). Each "value" is valid string associated with one
of these SQL statement components. of these SQL statement components.
[Editor's note: We need to precisely define what part of SQL were [Editor's note: We need to precisely define what part of SQL were using
using and why we chose what we did.] and why we chose what we did.]
Examples needed: Examples needed:
Grant someone access to June events Grant someone access to June events
Grant someone access to events during the month of June. (i.e., based Grant someone access to events during the month of June. (i.e., based
on the current system date, if it's prior to June or after June you on the current system date, if it's prior to June or after June you
don't have access) don't have access)
Example for denying access to a specific property: Example for denying access to a specific property:
DENY:UPN=FOO;ACTION=*;OBJECT=CLASS DENY:UPN=FOO;ACTION=*;OBJECT=CLASS
*scope vcar to a component *scope vcar to a component *scope Grant, Deny of a VCAR
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 21
*scope Grant, Deny of a VCAR
5.1.1 Grammar For Search Mechanism 5.1.1. Grammar For Search Mechanism
SEARCH = "BEGIN:VQUERY" CRLF SEARCH = "BEGIN:VQUERY" CRLF
[scope] [maxresults] [maxsize] querycomp [scope] [maxresults] [maxsize] querycomp
"END:VQUERY" CRLF "END:VQUERY" CRLF
scope = "SCOPE:" comp-name ("," comp-name)* scope = "SCOPE:" comp-name ("," comp-name)*
comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE"
/ "VALARM" / "VFREEBUSY" / iana-name / x-name / "VALARM" / "VFREEBUSY" / "VCAR" / iana-name / x-name
maxresults = integer maxresults = integer
maxsize = integer maxsize = integer
Mansour/Dawson/Royer/Taler/Hill 27 Expires September 2000
querycomp = (query) / (queryname query) / queryname querycomp = (query) / (queryname query) / queryname
queryname = "QUERYNAME:" text queryname = "QUERYNAME:" text
query = "QUERY:" queryrule query = "QUERY:" queryrule
queryrule = select where orderby ... queryrule = capselect capwhere caporderby ...
select = <any valid SQL string that goes into a SELECT clause> capselect = <any valid SQL string that goes into a SELECT clause>
where = <any valid SQL string that goes into a WHERE clause> capwhere = <any valid SQL string that goes into a WHERE clause>
orderby = <any valid SQL string that goes into a ORDERBY caporderby = <any valid SQL string that goes into a ORDERBY
clause> clause>
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" calendar
component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID"
component properties. component properties.
Individual calendar access rights MUST be specifically granted to an Individual calendar access rights MUST be specifically granted to an
authenticated calendar user (i.e., UPN); all rights are denied unless authenticated calendar user (i.e., UPN); all rights are denied unless
specifically granted. specifically granted.
Properties within an iCalendar object are unordered. This also is the Properties within a VCAR must be evaluated in the order provided.
case for the "GRANT", "DENY" and "CARID" properties. Likewise, there
is no implied ordering required for components of a "RIGHTS" value
type other than that specified by the ABNF.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 22
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 inherited as
default calendar access rights for any calendar in the parent default calendar access rights for any calendar in the parent calendar
calendar store. Likewise, any calendar access rights specified in a store. Likewise, any calendar access rights specified in a root calendar
root calendar are inherited as default calendar access rights for any are inherited as default calendar access rights for any sub- calendar to
sub- calendar to the root calendar. By implication, calendar access the root calendar. By implication, calendar access rights specified in a
rights specified in a sub-calendar are inherited as default calendar sub-calendar are inherited as default calendar access rights for any
access rights for any calendars that are hierarchically below the calendars that are hierarchically below the sub- calendar.
sub- calendar.
Calendar access rights specified in a calendar override any default Calendar access rights specified in a calendar override any default
calendar access rights. Calendar access rights specified within a calendar access rights. Calendar access rights specified within a sub-
sub- calendar override any default calendar access rights. 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, The TRANSP property can take on values (TRANSPARENT-NOCONFLICT, OPAQUE-
OPAQUE- NOCONFLICT) that prohibit other events from overlapping it. NOCONFLICT) that prohibit other events from overlapping it. This setting
This setting overrides access While access control may allow a UPN to overrides access While access control may allow a UPN to store an event
store an event on a particular calendar. , the CONFLICTS Calendar or on a particular calendar. , the CONFLICTS Calendar or component setting
component setting may prevent it, returning an error code "6.3" 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 syntax. The
precise syntax of command arguments is described in the Formal Syntax precise syntax of command arguments is described in the Formal Syntax
section. section.
Some commands cause specific server data to be returned; these are Some commands cause specific server data to be returned; these are
identified by "Data:" in the command descriptions below. See the identified by "Data:" in the command descriptions below. See the
response descriptions in the Responses section for information on response descriptions in the Responses section for information on these
these responses, and the Formal Syntax section for the precise syntax responses, and the Formal Syntax section for the precise syntax of these
of these responses. responses.
The "Result:" in the command description refers to the possible The "Result:" in the command description refers to the possible status
status responses to a command, and any special interpretation of responses to a command, and any special interpretation of these status
these status responses. 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 command MAY
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 23
have arguments. Arguments are defined in the detailed command have arguments. Arguments are defined in the detailed command
definitions below. definitions below.
Responses to commands have the following general form: Responses to commands have the following general form:
responseCode [sep transportDescr sep [applicationDescr]] CRLF "." responseCode [sep transportDescr sep [applicationDescr]]
CRLF CRLF "." CRLF
In the examples below, lines preceded with "S:" refer to the sender In the examples below, lines preceded with "S:" refer to the sender and
and lines preceded with "R:" refer to the receiver. Lines in which lines preceded with "R:" refer to the receiver. Lines in which the first
the first non-whitespace character is a "#" are editorial comments non-whitespace character is a "#" are editorial comments and are not
and are not part of the protocol. part of the protocol.
7.1 Transport 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 indicate
that it is ready to receive commands. A response of 8.1 indicates that it is ready to receive commands. A response of 8.1 indicates that
that the server is too busy to accept the connection. In addition, the server is too busy to accept the connection. In addition, the
the general capabilities of the CS are reported in the response from
the CS. These capabilities may be different than those reported in Mansour/Dawson/Royer/Taler/Hill 29 Expires September 2000
the authenticated state. general capabilities of the CS are reported in the response from the CS.
These capabilities may be different than those reported in the
authenticated state.
The supported authentication mechanisms. There may be 1 or more. The supported authentication mechanisms. There may be 1 or more.
CAPVERSION CAPVERSION
IRIPVERSION IRIPVERSION
7.1.2 ABORT Command 7.1.2. ABORT Command
Arguments: none Arguments: none
Data: none Data: none
Result: 2.0 - success Result: 2.0 - success
2.2 - no command is in progres 2.2 - no command is in progress
The ABORT command is issued by the CUA to stop a command whose
Mansour/Dawson/Royer/Taler/Hill The ABORT command is issued by the CUA to stop a command whose latency
Expires: April 2000 24 time has been exceeded. When the latency time is specified on the
latency time has been exceeded. When the latency time is specified on SENDATA command, the CS must issue a reply to the CUA within the
the SENDATA command, the CS must issue a reply to the CUA within the
specified time. It may be a reply code indicating that the CS has not specified time. It may be a reply code indicating that the CS has not
yet processed the request. The CUA must then tell the server whether yet processed the request. The CUA must then tell the server whether to
to continue or abort. 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 SENDATA
command has been completed but before receiving a reply. command has been completed but before receiving a reply.
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: 2.0 - Authenticate completed, now in authenticated state Result:
6.0 - Failed authentication
2.0 - Authenticate completed, now in authenticated
state.
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
server down).
6.x - Authentication exchange cancelled.
6.x - Authentication mechanism too weak.
Mansour/Dawson/Royer/Taler/Hill 30 Expires September 2000
6.x - Encryption required.
6.x - Pass phrase expired. The pass phrase was
correct but expired. The user will have to
contact a pass phrase change server prior to
authenticating.
6.x - The user is valid but the server does not
have an entry in the authentication database
for the requested mechanism (e.g., DIGEST-
MD5). If the user successfully authenticates
using a plain text password, then the back
end back end entry will be updated. Note
that if the client chooses to fall back to
plain text password authentication it should
enable an encryption layer or get user-con-
firmation that a one-time transition is ac-
ceptable.
6.x - User account disabled. The user will have to
contact the system administrator to get the
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 reported in
the response from the CS. These may be different than the the response from the CS. These may be different than the capabilities
capabilities in the Connected, but unauthenticated state. in the Connected, but unauthenticated state.
The AUTHENTICATE command is used by the CUA to identify the user to
the CS. CAP uses the [SASL] specification for authentication. The
desired SASL mechanism is specified as the initial argument.
<SASL mechanism name> is a registered SASL authentication mechanism. The AUTHENTICATE command is used by the CUA to identify the user to the
(Refer to [SASL] for information on obtaining a list of currently CS. CAP supports a number of authentication methods, the [SASL]
registered mechanisms.) CS Supported authentication mechanisms can be specification for authentication is the preferred method.
discovered using the CAPABILITY command. All implementations MUST
support Digest-MD5 authentication using DES and 3DES, as well as
DES-56 for link level encryption. Implementations MUST support the
SASL Anonymous mechanism, although this may be disabled in
installations. Implementations SHOULD implement the External SASL
mechanism and the command STARTTLS.
<initial data> is an optional parameter which can be used for If STARTTLS is negotiated prior to the AUTHENTICATE command, the client
mechanisms which require an initial response from the CUA. MUST discard all information about the CS capabilities fetched prior to
the TLS negotiation. In particular, the value of supported SASL
Mechanisms MAY be different after TLS has been negotiated.
The AUTHENTICATE command is followed by an authentication protocol If a SASL security layer is negotiated, the client MUST discard all
exchange, in the form of a series of CS challenges and CUA responses. information about the CS capabilities fetched prior to SASL. In
These challenges and responses are encoded in Base64 and transmitted particular, if the client is configured to support multiple SASL
mechanisms, it SHOULD fetch supported SASL Mechanisms both before and
after the SASL security layer is negotiated and verify that the value
has not changed after the SASL security layer was negotiated. This
detects active attacks which remove supported SASL mechanisms from the
supported SASL Mechanisms list.
Mansour/Dawson/Royer/Taler/Hill <initial data> is an optional parameter which can be used for mechanisms
Expires: April 2000 25 which require an initial response from the CUA.
with a terminating CRLF. The CS terminates the exchange with a "."
<CRLF> sequence followed by a reply code. ("." is not a legal Base64
character.) Possible reply codes are listed above.
CAP does not provide support for SASL authorization identities. If a The AUTHENTICATE command is followed by an authentication protocol
CUA attempts to use an authorization identity the Calendar Service exchange, in the form of a series of CS challenges and CUA responses,
must return the reply code indicating that the authorization identity per the relevant RFC that describes the specific SASL mechanism being
was refused. used.
If the CUA wishes to cancel an authentication exchange it may do so Mansour/Dawson/Royer/Taler/Hill 31 Expires September 2000
by issuing a "." <CRLF> sequence. Upon receipt of such a sequence the Cancelling the authentication process during its negotiation is
CS MUST terminate the exchange and return the appropriate reply code. implementation specific and not within scope of the CAP 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 the CS
starting with the first octet transmitted after the CRLF which starting with the first octet transmitted after the CRLF which follows
follows the 2.0 reply code, and for the CUA starting with the first the 2.0 reply code, and for the CUA starting with the first octet after
octet after the CRLF of its last response in the authentication the CRLF of its last response in the authentication exchange. Encrypted
exchange. Encrypted data is transmitted as described in [SASL]. data is transmitted as described in [SASL].
The service name specified by this protocol's profile of SASL is The service name specified by this protocol's profile of SASL is "cap".
"cap". [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 indicating the
identity which has been assigned to the session, derived from the identity which has been assigned to the session, derived from the
supplied authentication credentials. supplied authentication credentials, and/or authorization identifier. A
CAP session does not have an identity until the CUA has issued the
A CAP session does not have an identity until the CUA has issued the "AUTHENTICATE" command.
"AUTHENTCATE" command.
The CUA may not issue the "AUTHENTCATE" command multiple times, even The CUA may not issue the "AUTHENTICATE" command multiple times, even if
if the first attempt was aborted. If a CUA attempts to do this the CS the first attempt was aborted. If a CUA attempts to do this the CS must
must terminate the session. terminate the session.
Data returned in response to a successful logon is: Data returned in response to a successful login is:
The following examples illustrate the various possiblities for an The following examples illustrate the various possibilities for an
authentication protocol exchange. authentication protocol exchange.
Here are examples of a successful authentication: 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: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 26
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
S: PRODID:-//ACME/CAPserver//EN
S: VERSION:2.1
S: IDENTITY=bill@example.com
S: CAPVERSION=1.0
S: ITIPVERSION=1.0
S: AUTH=KERBEROS_V4
S: AUTH=DIGEST_MD5
S: CAR=CAR1 appl
S: MINDATE=19700101T000000Z appl
S: MAXDATE=20370201T000000Z
S: END:VCALENDAR
S: . S: .
C: AUTHENTICATE ANONYMOUS
S: 2.0
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: 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=CAR1 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: .
7.1.4 CAPABILITY Command 7.1.3.1. AUTHENTICATE ANONYMOUS
RFC-2245 defines the Anonymous SASL mechanism. This RFC states that "the
mechanism consists of a single message from the client to the server.
The client sends optional trace information in the form of a human
readable string. The trace information should take one of three forms:
an Internet email address, an opaque string which does not contain the
'@' character and can be interpreted by the system administrator of the
client's domain, or nothing. For privacy reasons, an Internet email
address should only be used with permission from the user."
RFC-2245 goes on to state, "A client which uses the user's correct email
address as trace information without explicit permission may violate
that user's privacy." Information about who accesses an anonymous CS on
a sensitive subject (e.g., AA meeting times and locations) has strong
privacy needs. "Clients should not send the email address without
explicit permission of the user and should offer the option of supplying
no trace token -- thus only exposing the source IP address and time."
Example of CUA using the Capability command followed by an anonymous
authentication:
C: CAPABILITY
S: 2.0
S:CAPVERSION=1.0
S:AUTH=KERBEROS_V4
S:AUTH=DIGEST_MD5
S:AUTH=ANONYMOUS
S:.
C:AUTHENTICATE ANONYMOUS
S:+
C:c21yaGM=
S:2.0
Subsequent to the initial Anonymous Authentication with a CS, a CUA will
have to provide a UPN for some CAP operations. For anonymous access the
UPN that MUST be used by the CUA is "@", a UPN with a null username and
null realm. The user's normal UPN MUST not be used for the subsequent
CAP operations.
Mansour/Dawson/Royer/Taler/Hill 33 Expires September 2000
Note that the CS implementation may have internal audit logs that use
the user's asserted UPN as trace information. However, this UPN will not
appear on the wire after the initial SASL anonymous authentication.
Use of the "@" UPN and wild-carding of UPNs within VCARs are covered in
Section <forward ref>.
7.1.4. CALIDEXPAND Command
Arguments: CalID
Data: no specific data for this command
Result: 2.0 Successful, and requested data follows
2.1 Permission Denied
2.2 Requested CSID not found
2.3 Result exceeds MAXEXPANDLIST
2.4 Misc. EXPAND error
Return the members of the argument CalID. Successful result yields one
or more Calendars and/or Resource Calendars. More than one C or RC
returned implies that the CalID was a CC.
Example:
Example #1: Request lookup of CSID which is a Calendar Collection
C: CALIDEXPAND cap://cal.example.com/calid14
S: 2.0 cap://cal.example.com/calid14
S: cap://cal.example.com/calid2
S: cap://cal.example.com/calid5
S: cap://cal.example.com/calid66
S: .
Example #2: Request lookup of a CSID which is a Resource Calendar
C: CALIDEXPAND cap://cal.example.com/conf5
S: 2.0 cap://cal.example.com/conf5
S: cap://cal.example.com/conf5
S: .
Example #3: Request CSID which exceeds MAXCALIDEXPANDLIST
C: CALIDEXPAND cap://cal.example.com/calid76
S: 2.0 cap://cal.example.com/calid76
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid12
S: cap://cal.example.com/calid21
S: cap://cal.example.com/calid33
S: 2.3 Expansion resulted in too much data
S: .
Mansour/Dawson/Royer/Taler/Hill 34 Expires September 2000
Example #4: CS loses contact with directory server during CALIDEXPAND
C: CALIDEXPAND cap://cal.example.com/calid76
S: 2.0 cap://cal.example.com/calid76
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid5
S: 2.4 Lost contact with directory server
S: .
7.1.5. CAPABILITY Command
Arguments: none Arguments: none
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 27
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 CAPABILTY command returns information about the CAP server given the
the current state of the connection with the client. The values current state of the connection with the client. The values returned may
returned may differ depending on whether the connection is in the differ depending on whether the connection is in the Connected or the
Connected or the Authenticated state. The return values may also be Authenticated state. The return values may also be different for a
different for a secure versus a non-secure connection. secure versus a non-secure connection.
Client implementations SHOULD NOT require any capability name beyond Client implementations SHOULD NOT require any capability name beyond
those defined in this specification, and MAY ignore any non-standard, those defined in this specification, and MAY ignore any non-standard,
experimental capability names. Non-standard capability names are experimental capability names. Non-standard capability names are
prefixed with the text "X-". The prefix SHOULD also include a short prefixed with the text "X-". The prefix SHOULD also include a short
character vendor identifier For example, "X-FOO-BARCAPABILITY", for character vendor identifier For example, "X-FOO-BARCAPABILITY", for the
the non-standard "BARCAPABILITY" capability of the implementor "FOO". non-standard "BARCAPABILITY" capability of the implementor "FOO". This
This command may return different results in the Connected state command may return different results in the Connected state versus the
versus the Authenticated state. It may also return different results Authenticated state. It may also return different results depending on
depending on the UPN. the UPN.
Capability Occurs Description Capability Occurs Description
--------------------- ------- ---------------------------------- -----------------------------------------------------------------------
CAPrev1 1 Revision of CAP, must be CAPrev1 1 Revision of CAP, must be "CAPrev1"
"CAPrev1"
IRIPrev1 0 or 1 Revision of IRIP, MAY be present. IRIPrev1 0 or 1 Revision of IRIP, MAY be present. If
If present, it MUST be "IRIPrev1" present, it MUST be "IRIPrev1"
CAR 0 or 1 Indicates level of CAR support CAR0, CAR 0 or 1 Indicates level of CAR support CAR-MIN
CAR1, CAR2, CAR3 or CAR-FULL-1
MAXICALOBJECTSIZE 0 or 1 An integer value that specifies Mansour/Dawson/Royer/Taler/Hill 35 Expires September 2000
The largest ICAL object the server MAXICALOBJECTSIZE 0 or 1 An integer value that specifies The
will accept. Objects larger than largest ICAL object the server will ac-
this will be rejected. cept in bytes. Objects larger than this
will be rejected. A value of zero (0)
indicates unlimited.
MAXDATE 0 or 1 The datetime value beyond which MAXDATE 0 or 1 The datetime value beyond which the
the server cannot accept. server cannot accept.
MINDATE 0 or 1 The datetime value prior to which MAXCALIDEXPANDLIST 0 or 1 An integer value that specifies the max-
the server cannot accept. imum number of CalIDs that can be re-
turned by the CALIDEXPAND Command. A
value of zero (0) indicates unlimited.
MAXUPNEXPANDLIST 0 or 1 An integer value that specifies the max-
imum number of UPNs that can be returned
by the UPNEXPAND Command. A value of
zero (0) indicates unlimited.
MINDATE 0 or 1 The datetime value prior to which the
server cannot accept.
Example: Example:
C: CAPABILTIY C: CAPABILTIY
S: 2.0 S: 2.0
S: .
S: CAPVERSION=1.0 S: CAPVERSION=1.0
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 28
S: ITIPVERSION=1.0 S: ITIPVERSION=1.0
S: AUTH=KERBEROS_V4 S: AUTH=KERBEROS_V4
S: AUTH=DIGEST_MD5 S: AUTH=DIGEST_MD5
S: . S: .
7.1.5 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 a SENDATA
timeout. When a timeout value is specified on the SENDDATA command, timeout. When a timeout value is specified on the SENDDATA command, the
the server must issue a reply to the client within the specified server must issue a reply to the client within the specified time. If
time. If the latency time has elapsed prior to the server completing the latency time has elapsed prior to the server completing the command
the command it returns a timeout response code. If the client wants it returns a timeout response code. If the client wants the server to
the server to continue processing the command it responds with the continue processing the command it responds with the CONTINUE command.
CONTINUE command.
If latencyTime is present, it must be a positive integer that If latencyTime is present, it must be a positive integer that specifies
specifies the maximum number of seconds the client will wait for the
next response. If it is omitted, the receiver waits an indefinite
period of time for the response.
In this example, the client requests a response from the server every Mansour/Dawson/Royer/Taler/Hill 36 Expires September 2000
10 seconds. the maximum number of seconds the client will wait for the next
response. If it is omitted, the receiver waits an indefinite period of
time for the response.
In this example, the client requests a response from the 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: .
C: CONTINUE:10 C: CONTINUE:10
S: 2.0 S: 2.0
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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 29
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.6 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 connection.
It always succeeds. It always succeeds.
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 from the
server server
# before disconnecting? ] # before disconnecting? ]
S: 2.0 S: 2.0
S: .
S: .
Mansour/Dawson/Royer/Taler/Hill 37 Expires September 2000
C: <drops connection> C: <drops connection>
S: <drops connection> S: <drops connection>
7.1.7 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 6.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 identity to be
used for calendar access. This command may only be called in the used for calendar access. This command may only be called in the
Identified State. Identified State.
The CS determines through an internal mechanism if the credentials The CS determines through an internal mechanism if the credentials
supplied at authentication permit the assumption of the selected the supplied at authentication permit the assumption of the selected the
identity. If they do the session assumes the new identity, otherwise identity. If they do the session assumes the new identity, otherwise a
a security error is returned. security error is returned.
7.1.8 SENDDATA Command 7.1.9. SENDDATA Command
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 30
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 <CRLF>.<CRLF>
is encountered. is encountered.
The SENDDATA command is used to send calendar requests and commands The SENDDATA command is used to send calendar requests and commands to
to the server. After a response code of 2.0.1 is issued the CUA sends the server. After a response code of 2.0.1 is issued the CUA sends a
a MIME encapsulated iCalendar object to the server. The end of this MIME encapsulated iCalendar object to the server. The end of this MIME
MIME data is signaleled by the special sequence <CRLF>.<CRLF> . data is signaled by the special sequence <CRLF>.<CRLF> .
7.1.9 STARTTLS Command 7.1.10. STARTTLS Command
Arguments: None Arguments: None
Data: None Data: None
Result: 2.0 Result: 2.0
6.5 TLS not supported 6.5 TLS not supported
The "STARTTLS" command is issued by the CUA to indicate to the CS that The "STARTTLS" command is issued by the CUA to indicate to the CS that
it wishes to negotiate transport level security using [TLS]. If the CS it wishes to negotiate transport level security using [TLS]. If the CS
does not support TLS it returns status code 6.5. If the CS supports TLS does not support TLS it returns status code 6.5. If the CS supports TLS
it issues an initial response of 2.0.12 indicating that the CUA should it issues an initial response of 2.0.12 indicating that the CUA should
Mansour/Dawson/Royer/Taler/Hill 38 Expires September 2000
proceed with TLS negotiation. Once the TLS negotiation is complete the proceed with TLS negotiation. Once the TLS negotiation is complete the
server returns the response code 2.0. 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 "AUTHENTICATE"
command. The SASL external mechanism may be used if the CUA wishes to command. The SASL external mechanism may be used if the CUA wishes to
use the authentication id which was used in the TLS negotiation. If an use the authentication id which was used in the TLS negotiation.
authentication id was determined during TLS negotiations it MUST NOT be
used for the purpose of granting a CAP session identity unless the CUA
authenticates using the SASL external mechanism.
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 an
"AUTHENTICATE" or "STARTTLS" command in this session. If a CUA does "AUTHENTICATE" or "STARTTLS" command in this session. If a CUA does
this the CS must terminate the session. this the CS must terminate the session.
The following examples illustrate the use of the "STARTTLS" 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:
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 31
C: STARTTLS C: STARTTLS
S: 2.0.12 S: 2.0.12
<tls negotiation> <tls negotiation>
S: 2.0 S: 2.0
S: .
S: .
7.2 Application Protocol Commands 7.1.10.1. UPNEXPAND Method
7.2.1 Calendaring Commands Arguments: UPN
Data: no specific data for this command
Result: 2.0 - success
2.1 Permission Denied
2.2 Requested UPN not found
2.3 Result exceeds MAXUPNEXPANDLIST
2.4 Misc. UPNEXPAND error
Return the members of the argument UPN. Successful result yields one or
more CalIDs. More than one CalID returned implies that the UPN was a
UG.
Example #1: Request lookup of a UPN which is a CU
C: UPNEXPAND upn@example.com
S: 2.0 upn@example.com
S: cap://cal.example.com/calid3
S: .
Example #2: Request lookup of UPN which is a UG
Mansour/Dawson/Royer/Taler/Hill 39 Expires September 2000
C: UPNEXPAND group@example.com
S: 2.0 group@example.com
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid6
S: cap://cal.example.com/calid1342
S: .
Example #3: Request lookup exceeds MAXUPNEXPANDLIST
C: UPNEXPAND group@example.com
S: 2.0 group@example.com
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid12
S: cap://cal.example.com/calid21
S: cap://cal.example.com/calid33
S: 2.3 Lookup resulted in too much data
S: .
Example #4: CS loses contact with directory server during UPNEXPAND
C: UPNEXPAND group@example.com
S: 2.0 group@example.com
S: cap://cal.example.com/calid3
S: cap://cal.example.com/calid5
S: 2.4 Lost contact with directory server
S: .
7.2. Application Protocol 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 in CAP.
Calendaring commands (or methods) allow a CU to directly manipulate a Calendaring commands (or methods) allow a CU to directly manipulate a
calendar. calendar.
Calendar access rights can be granted for the more generalized access Calendar access rights can be granted for the more generalized access
provided by the calendar commands. provided by the calendar commands.
7.2.1.1 CREATE Method 7.2.1.1. CREATE Method
Arguments: objtype 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 of type The CREATE method is used to create a new iCalendar object of type
objtype. ContainerId1 through ContainerIdn specify the container(s) objtype. The property TARGET specifies the container(s) for the create.
for the create. When creating a new calendar at the top level, the The type of object wrapped inside of the VCALENDAR/CREATE object is the
CSID is specified. Otherwise the container will be a CalID. object type(s) being created. When creating a new calendar at the top
level, the CSID is specified. Otherwise the container will be a CalID.
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 Example to create a new calendar named "Bill's Soccer Team" in several
several different containers. In the following example, the client is different containers. In the following example, the client is in the
in the Authenticated state with CS cal.example.com. Authenticated 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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 32
C: METHOD:CREATE;VCALENDAR
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://bobo.ex.com/
C: TARGET:relcal5 C: TARGET:relcal5
C: TARGET:cap://cal.example.com/relcal8 C: TARGET:cap://cal.example.com/relcal8
C: TARGET:relcal9 C: TARGET:relcal9
C: BEGIN:VCALENDAR C: BEGIN:VCALENDAR
C: RELCALID:relcalz C: RELCALID:relcalz
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:capcar:bill C: OWNER:bill
C: OWNER:capcar:mary C: OWNER:mary
C: CALMASTER:mailto:bill@example.com C: CALMASTER:mailto:bill@example.com
C: PREFERRED-TZID:US_PST C: TZID:US_PST
C: BEGIN:VCAR C: BEGIN:VCAR
C: CARID:12345 C: CARID:12345
C: GRANT;CN="Bill Jones":UPN=capcar:bill;ACTION=ALL;OBJECT=all C: GRANT:UPN=bill;ACTION=*;OBJECT=*
C: GRANT;CN="Mary Jones":UPN=capcar:mary;ACTION=read;OBJECT=all C: GRANT:UPN=mary;ACTION=read;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: 6.0 cap://cal.example.com/
S: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/relcalz S: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/relcalz
S: 3.1.4 cap://bobo.ex.com/ S: 3.1.4 cap://bobo.ex.com/
S: 6.2 cap://cal.example.com/relcal5 S: 6.2 cap://cal.example.com/relcal5
S: 3.1.5 cap://cal.example.com/relcal8 S: 3.1.5 cap://cal.example.com/relcal8
S: 7.0 cap://cal.example.com/relcal9 S: 7.0 cap://cal.example.com/relcal9
If the example above, the Relative CALID is specified. The values for If the example above, the Relative CALID is specified. The values for
this property must be unique on a CS. That is the reason for the this property must be unique on a CS. That is the reason for the 3.1.5
3.1.5 error response. error response.
In the example below, the Relative CalID is not specified. So, the Mansour/Dawson/Royer/Taler/Hill 41 Expires September 2000
CAP server will generate one for each calendar successfully created. In the example below, the Relative CalID is not specified. So, the CAP
The value of the Relative CalID appears as the second parameter on server will generate one for each calendar successfully created. The
the response code. value of the Relative CalID appears as the second parameter on the
response code.
S: 6.0 cap://cal.example.com/ S: 6.0 cap://cal.example.com/
S: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/rand123 S: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/rand123
S: 3.1.4 cap://bobo.ex.com/ S: 3.1.4 cap://bobo.ex.com/
S: 6.2 cap://cal.example.com/relcal5 S: 6.2 cap://cal.example.com/relcal5
S: 3.1.4 cap://cal.example.com/relcal8 S: 3.1.4 cap://cal.example.com/relcal8
S: 2.0 cap://cal.example.com/relcal9 cap://cal.example.com/rand456 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.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 33
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.foo.com/relcal1
C: TARGET:relcal2 C: TARGET:relcal2
C: BEGIN:VEVENT C: BEGIN:VEVENT
C: DTSTART:19990307T180000Z C: DTSTART:19990307T180000Z
C: UID:abcd12345 C: UID:abcd12345
C: DTEND:19990307T190000Z C: DTEND:19990307T190000Z
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; S: Content-Type:text/calendar; method=RESPONSE; OPTINFO="CMDID:abcde"
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: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal1 abcd12345
S: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal2 abcd12345 S: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal2 abcd12345
S: END:VEVENT S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
[Editors Note: this returns the calendar and UID? Is this right? It The responce returns the calendar (CALID) and UID of the component so
could also be UID and RecurrenceID ? what about if the event has an that the CUA can match up the REQUEST-STATUS from multiple objects
RRULE?] created on multiple calendards (TARGETs).
7.2.1.2 DELETE Method Mansour/Dawson/Royer/Taler/Hill 42 Expires September 2000
Arguments: ContainerId1 [;...ContainerIdn] 7.2.1.2. DELETE Method
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
Mansour/Dawson/Royer/Taler/Hill The DELETE method is used to delete a calendar or component. The TARGET
Expires: April 2000 34 properties specify the container(s) for the delete. When deleting a
The DELETE method is used to delete a calendar or component. calendar at the top level, the CSID is specified. Otherwise the
ContainerId1 through ContainerIdn specify the container(s) for the container will be a CalID.
delete. When deleting a calendar at the top level, the CSID is
specified. Otherwise the container will be a CalID.
Example to delete a calendar at the top level: 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: SCOPE:VEVENT
C: QUERY SELECT="UID" C: QUERY SELECT="UID"
C: WHERE (UID EQ abcd12345) 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 cap://cal.foo.com/bill S: 2.0
S: .
7.2.1.3 GENERATEUID Method And an example to delete the 'MrBill' calendar:
Arguments: number of uids to generate C: SENDDATA
C: Content-Type:text/calendar; method=DELETE; component=VCOMMAND
C: Content-Transfer-Encoding:7bit
C:
C: BEGIN:VCALENDAR
C: BEGIN:VCOMMAND
C: METHOD:DELETE
C: TARGET:cap://cal.foo.com/MrBill
C: END:VCOMMAND
C: END:VCALENDAR
C: .
S: 2.0
S: .
Mansour/Dawson/Royer/Taler/Hill 43 Expires September 2000
C: SENDDATA C:
7.2.1.3. GENERATEUID Method
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 MUST be
unique on the servers calendar store. It is recommended that the unique on the server's calendar store. It is recommended that the return
return value be a globally unique id. 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
7.2.1.4 MODIFY Method [Editors note: this example needs work. It's not packaged right]
Arguments: ContainerId1 [...ContainerIdn] 7.2.1.4. MODIFY Method
Arguments: none
Data: no specific data for this command Data: no specific data for this command
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 35
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 The MODIFY method is used to change an existing calendar or component.
component. ContainerId1 through ContainerIdn specify the TARGET specify the container(s) of the modification. When modifying a
container(s) of the modification. When modifying a calendar at the calendar at the top level, the CSID is specified. Otherwise the
top level, the CSID is specified. Otherwise the container will be a container will be a CalID.
CalID.
The format of the request is two or three containers inside of a
VCOMMAND container:
BEGIN:VCOMMAND
[VQUERY]
OLD-VALUES
NEW-VALUES
END:VCOMMAND
If a VQUERY is present, then only objects matching the query results are
modified.
In the example below, the start and end time of the event with UID In the example below, the start and end time of the event with UID
abcd12345 is changed and the LOCATION property is removed. 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;VEVENT 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: SCOPE:VEVENT
C: QUERY SELECT="UID" C: QUERY:SELECT UID WHERE (UID EQ abcd12345)
C: WHERE (UID EQ abcd12345)
C: END:VQUERY C: END:VQUERY
C: BEGIN:VOLD C: BEGIN:VEVENT
C: DTSTART:19990421T160000Z C: DTSTART:19990421T160000Z
C: DTEND:19990421T163000Z C: DTEND:19990421T163000Z
C: LOCATION:Joes Diner C: LOCATION:Joe's Diner
C: END:VOLD C: END:VEVENT
C: BEGIN:VNEW C: BEGIN:VEVENT
C: DTSTART:19990421T160000Z C: DTSTART:19990421T160000Z
C: DTEND:19990421T163000Z C: DTEND:19990421T163000Z
C: END:VNEW 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 And in this example, all instances of "Building 6" are replaced by "New
office lobby" in VEVENTs:
C: SENDDATA
C: Content-type:text/calendar; Method=MODIFY; Component=VCOMMAND
C:
C: BEGIN:VCALENDAR
C: VERSION:2.1
C: METHOD:MODIFY
C: TARGET:relcal2
C: BEGIN:VCOMMAND
C: BEGIN:VEVENT
C: LOCATION:Building 6
C: END:VEVENT
C: BEGIN:VEVENT
C: LOCATION:New office lobby
C: END:VEVENT
C: END:VCOMMAND
C: END:VCALENDAR
C: .
S: 2.0 cap://cal.example.com/relcal2
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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 36
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 CSs hierarchy of This method is used to move a calendar within the CS's hierarchy of
calendars. calendars.
[Editors Note: there could be VCAR issues with this... if a VCARs [Editors Note: there could be VCAR issues with this... if a VCAR's scope
scope of influence is limited to a calendar, were probably OK. We of influence is limited to a calendar, we are probably OK. We should
should discuss this one] discuss this one]
7.2.1.6 READ Method 7.2.1.6. NOOP Method
Arguments: none
Data: none
Result: 2.0 - success
This method does nothing. It can be sent to the server periodically to
request that the CS not time out the session.
7.2.1.7. 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
Read Events Read Events
In the example below events on March 10,1999 between 080000Z and In the example below events on March 10,1999 between 080000Z and 190000Z
190000Z are read. In this case only 4 properties for each event are are read. In this case only 4 properties for each event are returned.
returned. Two calendars are specified. Two calendars are specified. Only booked (vs scheduled) entries are to
be returned.
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; C: FROM VEVENT
C: WHERE (DTEND >= 19990310T080000Z AND C: WHERE (DTEND >= 19990310T080000Z AND
C: DTSTART <= 19990310T190000Z); C: DTSTART <= 19990310T190000Z AND
METHOD EQ CREATE)
C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY) C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY)
C: END:VQUERY C: END:VQUERY
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 37
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 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
skipping to change at line 1954 skipping to change at line 2528
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: .
The return values are subject to VCAR filtering. That is, if the Mansour/Dawson/Royer/Taler/Hill 47 Expires September 2000
request contains properties to which the UPN does not have access, The return values are subject to VCAR filtering. That is, if the request
those properties will not appear in the return values. If the UPN has contains properties to which the UPN does not have access, those
access to at least one property of events, but has been denied access properties will not appear in the return values. If the UPN has access
to at least one property of events, but has been denied access to all
Mansour/Dawson/Royer/Taler/Hill properties called out in the request, the response will contain a single
Expires: April 2000 38 RESPONSE-CODE property indicating the error. That is, the VEVENT
to all properties called out in the request, the response will components will be the following:
contain a single RESPONSE-CODE property indicating the error. That
is, the VEVENT components will be the following:
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 If the UPN has no access to any events at all, the response will simply
simply be an empty data set. The response looks the same if there are be an empty data set. The response looks the same if there are
particular events to which the requester has been denied access. 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. Find alarms within a range of time for booked (METHOD EQ 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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 39
C: QUERY:SELECT (VEVENT.DTSTART, C: QUERY:SELECT (VEVENT.DTSTART,
Mansour/Dawson/Royer/Taler/Hill 48 Expires September 2000
VEVENT.DTEND,VEVENT.SUMMARY, VEVENT.UID, VEVENT.DTEND,VEVENT.SUMMARY, VEVENT.UID,
VALARM.*); VALARM.*)
C: FROM VEVENT,VTODO; C: FROM VEVENT,VTODO
C: WHERE (VALARM.TRIGGER >= 19990310T080000Z AND C: WHERE (VALARM.TRIGGER >= 19990310T080000Z AND
C: VALARM.TRIGGER <= 19990310T190000Z); C: VALARM.TRIGGER <= 19990310T190000Z AND
METHOD EQ CREATE)
C: ORDERBY (VALARM.TRIGGER ASC) 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
skipping to change at line 2058 skipping to change at line 2631
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 40
S: . S: .
7.2.2 Scheduling Commands Mansour/Dawson/Royer/Taler/Hill 49 Expires September 2000
The following provide a set of scheduling commands (or methods) in 7.2.2. Scheduling Commands
CAP. Scheduling commands allow a CU to indirectly manipulate a
calendar by asking another CU to perform an operation on their The following provide a set of scheduling commands (or methods) in CAP.
calendar. For example, CU-A can request CU-B to add a meeting to Scheduling commands allow a CU to indirectly manipulate a calendar by
their calendar; in effect inviting CU-B to the meeting. asking another CU to perform an operation on their calendar. For
example, CU-A can request CU-B to add a meeting to their calendar; in
effect inviting CU-B to the meeting.
Calendar access rights can be granted for scheduling commands without Calendar access rights can be granted for scheduling commands without
granting rights for more generalized access with the calendar granting rights for more generalized access with the calendar commands.
commands.
[Editors Note: This section needs to be completed by adding the [Editors Note: This section needs to be completed by adding the
restriction tables for each of these iTIP methods. The basis for the restriction tables for each of these iTIP methods. The basis for the
text is to be taken from [RFC2446].] text is to be taken from [RFC2446].]
7.2.2.1 PUBLISH 7.2.2.1. Reading out scheduling components
A CU might be invided to a meeting. If the CU had been invided by CAP,
the entry in the CU calendar will be scheduled, but not booked. So a
CUA will need to look for scheduled entries in the calendar and present
them to the CU or automaticly decide if the invitation is to be acceped
or processed.
Example: The little league coach places the teams entire schedule into
your calendar. Lets say that every game and practice is on a Firday
night and your calendar now has this iTIP scheduling data:
BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
DTSTAMP;TZID=US/Pacific:20000229T180000
DTSTART;TZID=US/Pacific:20000303T180000
ORGANIZER:coach@little.league.com
SUMMARY: Schedule of games and practice
UID:1-coarch@little.league.com
SEQUENCE:0
DESCRIPTION:Please have your child at the field
and ready to play by 6pm.
RRULE:FREQ=WEEKLY;COUNT=10
END:VEVENT
END:VCALENDAR
At this point the above VEVENT is not booked in your calendar, It is
simpley scheduled. A CUA would fetch this and all other scheduled
VEVENTs from your calendar with:
C: SENDDATA
C: Content-type:text/calendar; Method=READ; Component=VQUERY
C:
C: BEGIN:VCALENDAR
C: VERSION:2.1
Mansour/Dawson/Royer/Taler/Hill 50 Expires September 2000
C: METHOD:READ
C: CMDID:xyz12345
C: TARGET:relcal2
C: BEGIN:VQUERY
C: QUERY:SELECT (VEVENT.*)
C: FROM VEVENT
C: WHERE (METHOD != CREATE)
C: END:VQUERY
C: END:VCALENDAR
C: .
The the CUA and CU could determine which scheduling items were to remain
on the calendar. Each scheduling component could be deleted or updated
with METHOD:MODIFY to change the METHOD from PUBLISH, REQUEST, REPLY,
ADD, CANCEL, REFRESH, COUNTER, or DECLINE-COUNTER to what the CU and CUA
had decided.
In some cases the CUA could automaticly do the work and inform the CU.
An example of this is CANCEL. If configured to process METHOD:CANCEL it
could METHOD:DELETE the component an inform the CU that the booked
component had been canceled.
The CUA MUST process the scheduled components in the order sent. Some
optimization could be done by the CUA. One example is if a PUBLISH and
later a CANCEL for the same component with the same SEQUENCE number were
scheduled, but not booked. The CUA might never inform the CU and just
treat it as if the PUBLISH had never been received by doing a
METHOD:DELETE on both entries.
It is important to note that scheduled components do not show up in busy
time as BUSY. Only when they are booked does the TRANSP:OPAQUE property
take effect. A CS implementation could mark the time as TENTATIVE.
This is an implementation and administrative choice.
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 CSs hierarchy of This method is used to move a calendar within the CS's hierarchy of
calendars. calendars. If the CU wishes to keep the published entry. A
METHOD:MODIFY changing the entries METHOD from PUBLISH to CREATE would
be done, booking the entry. Or METHOD:DELETE if the CU did not wish
this scheduled item to exist in their calendar.
7.2.2.2 REQUEST Mansour/Dawson/Royer/Taler/Hill 51 Expires September 2000
7.2.2.3 REPLY 7.2.2.3. REQUEST
7.2.2.4 ADD 7.2.2.4. REPLY
7.2.2.5 CANCEL 7.2.2.5. ADD
7.2.2.6 REFRESH 7.2.2.6. CANCEL
7.2.2.7 COUNTER 7.2.2.7. REFRESH
7.2.2.8 DECLINECOUNTER 7.2.2.8. COUNTER
Mansour/Dawson/Royer/Taler/Hill 7.2.2.9. DECLINECOUNTER
Expires: April 2000 41
7.2.3 iTIP Examples 7.2.3. iTIP Examples
The following examples describe scenarios for the handling of The following examples describe scenarios for the handling of incoming
incoming iTIP data. An appropriate sort-order for the handling of iTIP data. An appropriate sort-order for the handling of incoming iTIP
icoming iTIP is by UID, Recurrence-id, sequence, dtstamp. This is by UID, Recurrence-id, sequence, dtstamp. This processing may be
processing may be optimized, for instance, REFRESHs could be optimized, for instance, REFRESHs could be processed last.
processed last.
As an update to [RFC2446], data with the "COUNTER" method should be As an update to [RFC2446], data with the "COUNTER" method should be
processed even if the Seqeunce number is stale. processed even if the Sequence number is stale.
7.2.3.1 Sending and Receiving an iTIP request 7.2.3.1. Sending and Receiving an iTIP request
In this example A invites B and C to a meeting, B accepts the meeting In this example A invites B and C to a meeting, B accepts the meeting
and C rejects it. The calendars for A, B and C are relcal1, relcal2 and C rejects it. The calendars for A, B and C are relcal1, relcal2 and
and relcal3 respectively, and are all on the same server, relcal3 respectively, and are all on the same server, "cal.foo.com". A
"cal.foo.com". A lot of these described actions are performed by the lot of these described actions are performed by the CUAs and not the
CUAs and not the users themselves, the CUAs are called A-c, B-c and users themselves, the CUAs are called A-c, B-c and C-c respectively.
C-c respectively.
A wishes to create a meeting with B and C, so A-c uses CAP to send A wishes to create a meeting with B and C, so A-c uses CAP to send the
the following iTIP request to relcal2 and relcal3, while logged in to following iTIP request to relcal2 and relcal3, while logged in to
"cal.foo.com". "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-ACTION:cap://cal.foo.com/relcal2
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 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) An incoming event (indicated by the value of the "METHOD" property) then
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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 42
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-ACTION:cap://cal.foo.com/relcal2
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 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 B-c and C-c must search for such incoming events, they do so using the
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 (ALL);
FROM VEVENT; FROM VEVENT;
skipping to change at line 2197 skipping to change at line 2840
then crack open the VEVENT, find the UID and determine if there is 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 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 (ALL); QUERY:SELECT (*)
FROM VEVENT; FROM VEVENT
WHERE (UID == abcd12345); WHERE (UID == abcd12345 AND METHOD == CREATE)
END:VQUERY END:VQUERY
END:VCALENDAR
We assume that the event is not already in their relcal2 or relcal3, Mansour/Dawson/Royer/Taler/Hill 53 Expires September 2000
so the read they only returns the original incoming iTIP (the UID END:VCALENDAR
matched), but this can be ignored since it is incoming.
B-c prompts B who decides to accept the meeting request, and B-c We assume that the event is not already in their relcal2 or relcal3.
creates a copy of the event in relcal2, with the "PARTSTAT" parameter
Mansour/Dawson/Royer/Taler/Hill B-c prompts B who decides to accept the meeting request, and B-c creates
Expires: April 2000 43 a copy of the event in relcal2, with the "PARTSTAT" parameter set to
set to ACCEPTED. B-c also sends this copy to the Organizer at relcal1 ACCEPTED. B-c also sends this copy to the Organizer at relcal1 as an
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
skipping to change at line 2248 skipping to change at line 2888
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 It is preferable that C-c store the event in relcal3 even though it has
has been declined. Storing the event in relcal3 allows subsequent been declined. Storing the event in relcal3 allows subsequent iTIP
iTIP messages to be interpreted correctly. The "PARTSTAT" parameter messages to be interpreted correctly. The "PARTSTAT" parameter indicates
indicates that the event was refused, and a tombstone property may be that the event was refused.
necessary if the user wishes to delete the event.
After receiving the replies from relcal2 and relcal3, A-c updates the After receiving the replies from relcal2 and relcal3, A-c updates the
version of the event in relcal1 to indicate the new participation version of the event in relcal1 to indicate the new participation
statii: statii:
BEGIN:VEVENT BEGIN:VEVENT
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 44
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 event in the
previous example, but first wants to check the current state of the 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, 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 for the
corresponding event. Having found the event (with no changes since corresponding event. Having found the event (with no changes since the
the last example) A-c then verifies that relcal3 is in fact an last example) A-c then verifies that relcal3 is in fact an Attendee of
Attendee of the event and is thus allowed to request a refresh. (In the event and is thus allowed to request a refresh. (In the case of a
the case of a published event things are more complicated.) A-c published event things are more complicated.) A-c packages the event up
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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 45
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?] [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 Having received the latest copy of the event C wishes to propose a venue
venue for the event, using an iTIP COUNTER. To do this C-c sends the for the event, using an iTIP COUNTER. To do this C-c sends the following
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 favourite restaurant, I'll definitely go if it's there.
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Having sent the information to relcal1, C-c shouldn't store the new Having sent the information to relcal1, C-c shouldn't store the new
details in relcal3. If C-c updated the version in relcal3 and relcal1 details in relcal3. If C-c updated the version in relcal3 and relcal1
did not reply to the counter, then relcal3 would have incorrect did not reply to the counter, then relcal3 would have incorrect
information. Instead C-c preserves the correct information and waits information. Instead C-c preserves the correct information and waits for
for a response from relcal1. A CUA implementation may wish to a response from relcal1. A CUA implementation may wish to preserve this
preserve this information itself, externally to the CS. information itself, externally to the CS.
In order to receive an iTIP counter A-c follows the same search as In order to receive an iTIP counter A-c follows the same search as for
for other iTIP data, first find the incoming message, next find any other iTIP data, first find the incoming message, next find any matching
matching events in the calendar store. events in the calendar store.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 46
Having found the matching event, A reviews the proposed changes and Having found the matching event, A reviews the proposed changes and
decides to accept the COUNTER. To do this, A-c modifies the version decides to accept the COUNTER. To do this, A-c modifies the version in
in relcal1 (bumping the sequence number) to: relcal1 (bumping the sequence number) to:
BEGIN:VEVENT METHOD:CREATE UID:abcd12345 DTSTART:19990307T180000Z BEGIN:VEVENT METHOD:CREATE UID:abcd12345 DTSTART:19990307T180000Z
DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 DTEND:19990307T190000Z 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
SUMMARY:Important Meeting LOCATION:La Belle Province SEQUENCE:1 Meeting LOCATION:La Belle Province SEQUENCE:1 END:VEVENT
END:VEVENT
A-c then sends the updated version as a request to both relcal2 and A-c then sends the updated version as a request to both relcal2 and
Mansour/Dawson/Royer/Taler/Hill 56 Expires September 2000
relcal3: relcal3:
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.1 VERSION:2.1
CMDID:xup-po CMDID:xup-po
METHOD:REQUEST METHOD:REQUEST
TARGET:cap://cal.foo.com/relcal2 TARGET:cap://cal.foo.com/relcal2
TARGET:cap://cal.foo.com/relcal3 TARGET:cap://cal.foo.com/relcal3
BEGIN:VEVENT BEGIN:VEVENT
UID:abcd12345 UID:abcd12345
skipping to change at line 2395 skipping to change at line 3031
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-ACTION:cap://cal.foo.com/relcal2
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3
SUMMARY:Important Meeting SUMMARY:Important Meeting
LOCATION:La Belle Province LOCATION:La Belle Province
SEQUENCE:1 SEQUENCE:1
DTSTAMP:19990307T054339Z DTSTAMP:19990307T054339Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
7.2.3.4 Declining an iTIP counter 7.2.3.4. Declining an iTIP counter
B does not like the new location and also counters the event, B-c B does not like the new location and also counters the event, B-c sends
sends the following iTIP: the following iTIP:
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.1 VERSION:2.1
CMDID:xim-ef CMDID:xim-ef
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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 47
DTEND:19990307T190000Z DTEND:19990307T190000Z
ORGANIZER:cap://cal.foo.com/relcal1 ORGANIZER:cap://cal.foo.com/relcal1
ATTENDEE:cap://cal.foo.com/relcal2 ATTENDEE:cap://cal.foo.com/relcal2
SUMMARY:Important Meeting SUMMARY:Important Meeting
LOCATION:Au Coin Dor=E9 LOCATION:Au Coin Dor=E9
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
However, C does not accept the counter, and C-c replies with a However, C does not accept the counter, and C-c replies with a decline
decline counter: counter:
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.1 VERSION:2.1
CMDID:xim-ef CMDID:xim-ef
METHOD:DECLINE-COUNTER METHOD:DECLINE-COUNTER
TARGET:cap://cal.foo.com/relcal2 TARGET:cap://cal.foo.com/relcal2
BEGIN:VEVENT BEGIN:VEVENT
Mansour/Dawson/Royer/Taler/Hill 57 Expires September 2000
DTSTAMP:19990307T093245Z DTSTAMP:19990307T093245Z
UID:abcd12345 UID:abcd12345
ORGANIZER:cap://cal.foo.com/relcal1 ORGANIZER:cap://cal.foo.com/relcal1
SEQUENCE:1 SEQUENCE:1
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Fortunately B-c kept the original information when sending the Fortunately B-c kept the original information when sending the counter,
counter, and there is no problem when no information is returned in and there is no problem when no information is returned in the DECLINE-
the DECLINE-COUNTER. COUNTER.
8. Response Codes Numeric response codes are returned at both the 8. Response Codes
transport and application layer. The same set of codes is used in Numeric response codes are returned at both the transfer and application
both cases. layer. The same set of codes is used in both cases.
[Editors Note: Do we want to use the same set of codes?] [Editors Note: Do we want to use the same set of codes?]
The format of these codes is described in [RFC2445], and extend in The format of these codes is described in [RFC2445], and extend in
[RFC2446] and [RFC2447]. The following describes new codes added to [RFC2446] and [RFC2447]. The following describes new codes added to this
this set. set.
At the application layer response codes are returned as the value of At the application layer response codes are returned as the value of a
a "REQUEST-STATUS" property. The value type of this property is "REQUEST-STATUS" property. The value type of this property is modified
modified from that defined in [RFC2445], to make the accompanying from that defined in [RFC2445], to make the accompanying text optional.
text optional.
Code Params Description Code Params Description
-------------------------------------------------------------------- ----------------------------------------------------------
2.0 varies Success. The parameters vary with the operation 2.0 varies Success, The parameters vary with the
operation and are specified.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 48
and are specified
2.0.1 none Success, send data, terminate with 2.0.1 none Success, send data, terminate with
<CRLF>.<CRLF> <CRLF>.<CRLF>
2.0.2 A reply is pending. It could not be completed in 2.0.2 A reply is pending. It could not be com-
the specified amount of time. The server awaits pleted in the specified amount of time.
a CONTINUE or ABORT command. The server awaits a CONTINUE or ABORT
command.
2.0.3 In response to the client issuing an ABORT 2.0.3 In response to the client issuing an
command, this reply code indicates that any ABORT command, this reply code indicates
command currently underway was successfully that any command currently underway was
aborted. successfully aborted.
2.0.6 An operation is being attempted on a remote Mansour/Dawson/Royer/Taler/Hill 58 Expires September 2000
server. This response indicates that the server 2.0.6 An operation is being attempted on a re-
has not yet been contacted but an attempt will mote server. This response indicates
be made to contact it after the command has been that the server has not yet been con-
tacted but an attempt will be made to
contact it after the command has been
sent. sent.
3.1.4 Capability not supported 3.1.4 Capability not supported.
4.1 Calendar store access denied 4.1 Calendar store access denied.
6.1 authenticate failure: unsupported authentication 6.1 Authenticate failure: unsupported au-
mechanism, credentials rejected thentication mechanism, credentials re-
jected.
6.2 Sender aborted authentication, authentication 6.2 Sender aborted authentication, authenti-
exchange cancelled cation exchange cancelled.
6.3 Attempt to create or modify an event such that it 6.3 Attempt to create or modify an event
would overlap another event in either of the such that it would overlap another event
following two circumstances: in either of the following two circum-
a) one of the events has a TRANSP property stances:
set to OPAQUE-NOCONFLICT or
TRANSPARENT-NOCONFLICT.
b) the calendar's ALLOW-CONFLICT property is
set to NO.
7.0 A timeout has occurred. The server was unable (a) One of the events has a TRANSP prop-
to complete the operation in the requested time. erty set to OPAQUE-NOCONFLICT or TRANS-
PARENT-NOCONFLICT.
8.0 A failure has occurred in the Receiver that (b) The calendar's ALLOW-CONFLICT prop-
prevents the operation from succeeding. erty is set to NO.
8.1 Sent when a session cannot be established because 7.0 A timeout has occurred. The server was
unable to complete the operation in the
requested time.
Mansour/Dawson/Royer/Taler/Hill 8.0 A failure has occurred in the Receiver
Expires: April 2000 49 that prevents the operation from suc-
the CAP Server is too busy. ceeding.
8.2 Used to signal that an ICAL object has exceeded 8.1 Sent when a session cannot be estab-
the server's size limit. lished because the CAP Server is too
busy.
8.3 A DATETIME value was too large to be represented 8.2 Used to signal that an ICAL object has
on this Calendar. exceeded the server's size limit
8.4 A DATETIME value was too far in the past to be 8.3 A DATETIME value was too large to be
represented on this Calendar. represented on this Calendar.
8.5 An attempt was made to create a new object but 8.4 A DATETIME value was too far in the past
the unique id specified is already in use. to be represented on this Calendar.
Mansour/Dawson/Royer/Taler/Hill 59 Expires September 2000
8.5 An attempt was made to create a new ob-
ject but the unique id specified is al-
ready in use.
8.6 ID clash 8.6 ID clash
9.0 An unrecongnized command was received. 9.0 An unrecognized command was received.
10.1 Accompanied by an alternate address. The 10.1 Accompanied by an alternate address. The
RECIPIENT specified should be contacted at the RECIPIENT specified should be contacted
given alternate address. The referral address at the given alternate address. The re-
MUST follow the reply code. ferral address MUST follow the reply
code.
10.2 The server is shutting down. 10.2 The server is shutting down.
10.4 The operation has not be performed because it 10.4 The operation has not be performed be-
would cause the resources (memory, disk,CPU, etc) cause it would cause the resources (mem-
to exceed the allocated quota. ory, disk,CPU, etc) to exceed the allo-
cated quota.
10.5 The ITIP message has been queued too too long. 10.5 The ITIP message has been queued too too
Delivery has been aborted. long. Delivery has been aborted.
----------------------------------------------------------
8.1. Minimum CS query implementation
The following is a MUST for a CS implementation.
8.1.1. Query by UID
<TBD>
8.1.2. Query by Date / Date-Time range
<TBD>
8.1.2.1. Date/Date-Time query with subset of properties
<TBD>
8.1.3. <TBD>
<TBD>
9. Detailed SQL Schema 9. Detailed SQL Schema
This section describes a conceptual schema for object model in CAP. This section describes a conceptual schema for object model in CAP. It
It is used as the basis for querying data managed by the CS. This is is used as the basis for querying data managed by the CS. This is only a
only a conceptual schema. Implementations can use any schema they conceptual schema. Implementations can use any schema they like so long
like so long as they are prepared to map CAP queries that are as they are prepared to map CAP queries that are expressed in this
expressed in this conceptual schema. Implementations are not required conceptual schema. Implementations are not required to use SQL database
to use SQL database technology. The protocol is designed such that a technology. The protocol is designed such that a CUA does not need to
CUA does not need to handle these queries.
Mansour/Dawson/Royer/Taler/Hill 60 Expires September 2000
understand SQL. The CUA just sends strings that happen to be valid SQL
queries.
This schema is based on SQL-92 [SQL] along with the [SQLCOM] This schema is based on SQL-92 [SQL] along with the [SQLCOM]
corrections. corrections.
Properties than can occur multiple times are intended to be put in Properties than can occur multiple times are intended to be put in
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 50
separate tables. For example separate tables. For example
BEGIN:VEVENT BEGIN:VEVENT
UID:1 UID:1
DTSTART:19990326T201400Z DTSTART:19990326T201400Z
ORGANIZER:mailto:sam@abc.COM ORGANIZER:mailto:sam@abc.COM
SUMMARY:I have 2 attachments SUMMARY:I have 2 attachments
ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell.au ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell.au
ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell2.au ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell2.au
END:VEVENT END:VEVENT
There are two ATTACHMENT properties each having a unique value. These There are two ATTACHMENT properties each having a unique value. These
are kept in separate tables. This is diagrammed below. The diagram is are kept in separate tables. This is diagrammed below. The diagram is
not a complete representation of the VEVENT table. It is an not a complete representation of the VEVENT table. It is an abbreviated
abbreviated table used to illustrate how properties that can occur table used to illustrate how properties that can occur multiple times
multiple times are intended to be represented. are intended to be represented.
ABBREVIATED VEVENT TABLE
UID DTSTART ORGANIZER SUMMARY ATTACH_LIST +----------------------------------------------------------------------+
+----+----------------+-------------------+------------+------------+ | ABBREVIATED VEVENT TABLE |
|1 |19990326T201400Z|mailto:sam@abc.com |I have 2 | 123 | +----+-----------------+---------------------+--------------+----------+
| | | |attachments | | | | | | | |
+----+----------------+-------------------+------------+------------+ |UID |DTSTART |ORGANIZER |SUMMARY |ATTACH_KEY|
|999 |19700101T000000Z|mailto:usr@host.com|I have no | | +----+-----------------+---------------------+--------------+----------+
|1 |19990326T201400Z |mailto:sam@abc.com |I have 2 at- |123 |
| | | |tachments | |
+----+-----------------+---------------------+--------------+----------+
|999 |19700101T000000Z |mailto:user@host.com |I have no | |
| | | |attachments | | | | | |attachments | |
+----+----------------+-------------------+------------+------------+ +----+-----------------+---------------------+--------------+----------+
ABBREVIATED ATTACH_LIST TABLE
ATTACH_LIST VALUE INLINE_BLOB Mansour/Dawson/Royer/Taler/Hill 61 Expires September 2000
+------------+------------------------------------+-----------------+ +-----------------------------------------------------------------------+
| ABBREVIATED ATTACH_KEY TABLE |
+------------+------------------------------------+---------------------+
| | | |
|ATTACH_KEY |VALUE | INLINE_BLOB |
+------------+------------------------------------+---------------------+
|123 | ftp://host.com/pub/sounds/bell.au | | |123 | ftp://host.com/pub/sounds/bell.au | |
+------------+------------------------------------+-----------------+ +------------+------------------------------------+---------------------+
|123 | ftp://host.com/pub/sounds/bell2.au| | |123 | ftp://host.com/pub/sounds/bell2.au| |
+------------+------------------------------------+-----------------+ +------------+------------------------------------+---------------------+
|234 | | MIICajCCAdO- | |234 | | MIICajCCAdO-gAw- |
| | | gAwIBAgICBEU | | | | IBAgICBEU <...re- |
| | | <...remainder | | | | mainder of "BASE64" |
| | | of "BASE64"| | | | encoded binary da- |
| | | encoded binary| | | | ta...> |
| | | data...> | +------------+------------------------------------+---------------------+
+------------+------------------------------------+-----------------+
9.1 iCalendar Store Schema 9.1. iCalendar Store Schema
The following defines the schema for an iCalendar object and the The following defines the schema for an iCalendar object and the
components, properties, and parameters defined and used in [RFC2445],
[RFC2446], [RFC2447], and [CAP].
Mansour/Dawson/Royer/Taler/Hill NOTES:
Expires: April 2000 51
components, properties, and parameters defined in [RFC2445].
Create table VCALENDAR { CURRENT_DATETIME would not be stored in the database. It
RELATIVECALID VARCHAR(256) PRIMARY KEY, is selectable and read only.
CALMASTER VARCHAR(256),
CHARSET VARCHAR(256),
CHILDREN VARCHAR(256)
LANGUAGE CHAR(5)
LAST_MODIFIED
NAME VARCHAR(256),
OWNERS
PARENT CHAR(16),
PATH
SCHEDULABLE_HOURS
TOMBSTONE
TZID
LAST_MODIFIED_BY
};
create table VEVENT { When supporting virtual hosts, there could be more than
ATTACH_LIST INTEGER, one row in the CALSTORE table. And then the CSID MUST
ATTENDEE_LIST INTEGER, not be empty.
/* CATEGORIES may contain a comma seperated list */
CATEGORIES VARCHAR(len?),
CLASS INTEGER,
CLASS_PARAMS INTEGER,
COMMENT VARCHA,
COMMENT_PARAMS INTEGER,
CONTACT_LIST INTEGER,
CREATED TIMESTAMP NOT NULL DEFAULT
CURRENT_DATE,
CREATED_PARAMS INTEGER,
DESCRIPTION VARCHAR(len?),
DESCRIPTION_PARAMS INTEGER,
DTEND TIMESTAMP,
DTEND_PARAMS INTEGER,
DTSTAMP TIMESTAMP NOT NULL,
DTSTAMP_PARAMS INTEGER,
DTSTART TIMESTAMP NOT NULL,
DTSTART_PARAMS INTEGER,
DURATION <?type?>,
DURATION_PARAMS INTEGER,
EXDATE_LIST INTEGER,
EXRULE_LIST INTEGER,
GEO_LAT NUMBER,
GEO_LON NUMBER,
GEO_PARAMS INTEGER,
Mansour/Dawson/Royer/Taler/Hill TIMESTAMP(14) is the SQL value equivelant of DATE-TIME.
Expires: April 2000 52
LAST_MODIFIED TIMESTAMP NOT NULL DEFAULT
CURRENT_DATE,
LAST_MODIFIED_PARAMS INTEGER,
LOCATION VARCHA,
LOCATION_PARAMS INTEGER,
METHOD VARCHAR(len20?),
ORGANIZER VARCHAR(len?) NOT NULL,
ORGANIZER_PARAMS INTEGER,
PRIORITY INTEGER,
PRIORITY_PARAMS CHAR(1),
RECURRENCE_ID VARCHAR(len?),
RECURRENCE_ID_PARAMS INTEGER,
RDATE_LIST INTEGER,
RELATED_TO_LIST INTEGER,
/* RESOURCES may contain a comma seperated list */
RESOURCES VARCHAR(len?),
RESOURCES_PARAMS INTEGER,
RRULE_LIST INTEGER,
SUMMARY VARCHAR(len?) NOT NULL DEFAULT "",
SUMMARY_PARAMS INTEGER,
SEQUENCE INTEGER NOT NULL DEFAULT 0,
SEQUENCE_PARAMS INTEGER,
STATUS INTEGER,
STATUS_PARAMS CHAR(1),
TRANSP CHAR(1),
TRANSP_PARAMS INTEGER,
UID VARCHAR(len?) NOT NULL,
UID_PARAMS INTEGER,
URL VARCHA,
URL_PARAMS INTEGER,
X_PROP_LIST INTEGER,
VALARM_LIST INTEGER,
};
create table VTODO { FLOAT(7,3) is an SQL 3x3 floating number (xxx.yyy).
ATTENDEE_LISTINTEGER,
ATTACH_LIST INTEGER,
/* CATEGORIES may contain a comma separated list */
CATEGORIES VARCHAR(len?),
CLASS INTEGER,
CLASS_PARAMS INTEGER,
COMMENT VARCHAR(len?),
COMMENT_PARAMS INTEGER,
CONTACT_LIST INTEGER,
CREATED TIMESTAMP NOT NULL DEFAULT
CURRENT_DATE,
CREATED_PARAMS INTEGER,
Mansour/Dawson/Royer/Taler/Hill 9.1.1. ACTION schema
Expires: April 2000 53
DESCRIPTION VARCHAR(len?),
DESCRIPTION_PARAMS INTEGER,
DTSTAMP TIMESTAMP NOT NULL,
DTSTAMP_PARAMS INTEGER,
DTSTART TIMESTAMP NOT NULL,
DTSTART_PARAMS INTEGER,
DUE TIMESTAMP,
DUE_PARAMS INTEGER,
DURATION <?type?>,
DURATION_PARAMS INTEGER,
EXDATE_LIST INTEGER,
EXRULE_LIST INTEGER,
GEO_LAT NUMBER,
GEO_LON NUMBER,
GEO_PARAMS INTEGER,
LAST_MODIFIED TIMESTAMP NOT NULL DEFAULT
CURRENT_DATE,
LAST_MODIFIED_PARAMS INTEGER,
LOCATION VARCHA,
LOCATION_PARAMS INTEGER,
METHOD VARCHAR(len20?),
ORGANIZER VARCHAR(len?) NOT NULL,
ORGANIZER_PARAMS INTEGER,
PERCENT_COMPLETE INTEGER,
PERCENT_COMPLETE_PARAMSLETE INTEGER
PRIORITY INTEGER NOT NULL,
PRIORITY_PARAMS INTEGER,
RDATE_LIST INTEGER,
RECURRENCE_ID VARCHAR(len?),
RECURRENCE_ID_PARAMS INTEGER,
/* RESOURCES may contain a comma seperated list */
RESOURCES VARCHAR(len?),
RESOURCES_PARAMS INTEGER,
RRULE_LIST INTEGER,
SEQUENCE INTEGER NOT NULL DEFAULT 0,
SEQUENCE_PARAMS INTEGER,
SUMMARY VARCHAR(len?) NOT NULL DEFAULT "",
SUMMARY_PARAMS INTEGER,
UID VARCHAR(len?) NOT NULL,
UID_PARAMS INTEGER,
URL VARCHAR(len?)
URL_PARAMS INTEGER,
X_PROP_LIST INTEGER
VALARM_LIST INTEGER,
};
create table VJOURNAL { /*
* If VALUE is NULL, then OTHER_VALUE contains non-rfc2445 value .
*/
CREATE TABLE ACTION (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE ENUM("AUDIO", "DISPLAY", "EMAIL",
"PROCEDURE") NOT NULL,
OTHER_VALU TEXT,
XPARAM INTEGER /* VALUE_KEY */
);
Mansour/Dawson/Royer/Taler/Hill Mansour/Dawson/Royer/Taler/Hill 62 Expires September 2000
Expires: April 2000 54
ATTACH_LIST INTEGER, 9.1.2. ATTACH schema
/* CATEGORIES may contain a comma seperated list */
CATEGORIES VARCHAR(len?), /*
CLASS INTEGER, * VALUE is a FILE uri. The data is decoded (per ENCODING) prior to being
CLASS_PARAMS INTEGER, * stored into the file
COMMENT VARCHAR(len?), */
COMMENT_PARAMS INTEGER, CREATE TABLE ATTACH (
CONTACT_LIST INTEGER, VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
CREATED TIMESTAMP NOT NULL DEFAULT VALUE VARCHAR(255) NOT NULL,
CURRENT_DATE, ISBINARY ENUM("T", "F") DEFAULT "F",
CREATED_PARAMS INTEGER, FMTTYPE INTEGER, /* VALUE_KEY */
DESCRIPTION VARCHAR(len?) NOT NULL DEFAUT "", XPARAM INTEGER /* VALUE_KEY */
DESCRIPTION_PARAMS INTEGER, );
DTSTAMP TIMESTAMP NOT NULL,
DTSTAMP_PARAMS INTEGER, 9.1.3. ATTENDEE schema
DTSTART TIMESTAMP NOT NULL,
DTSTART_PARAMS INTEGER, CREATE TABLE ATTENDEE (
EXDATE_LIST INTEGER, VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
EXRULE_LIST INTEGER, VALUE TEXT,
LAST_MODIFIED TIMESTAMP NOT NULL DEFAULT CUTYPE INTEGER, /* VALUE_KEY */
CURRENT_DATE, MEMBER INTEGER, /* VALUE_KEY */
METHOD VARCHAR(len20?), ROLE INTEGER, /* VALUE_KEY */
LAST_MODIFIED_PARAMS INTEGER, PARTSTAT INTEGER, /* VALUE_KEY */
ORGANIZER VARCHAR(len?) NOT NULL, RSVP ENUM("T", "F") DEFAULT "F",
ORGANIZER_PARAMS INTEGER, DELEGATED_TO INTEGER, /* VALUE_KEY */
RDATE_LIST INTEGER, DELEGATED_FROM INTEGER, /* VALUE_KEY */
RECURRENCE_ID VARCHAR(len?), CN INTEGER, /* VALUE_KEY */
RECURRENCE_ID_PARAMS INTEGER, DIR INTEGER, /* VALUE_KEY */
RELATED_TO_LIST INTEGER, LANGUAGE INTEGER, /* VALUE_KEY */
RRULE_LIST INTEGER, XPARAM INTEGER /* VALUE_KEY */
SEQUENCE INTEGER NOT NULL DEFAULT 0, );
SEQUENCE_PARAMS INTEGER,
STATUS INTEGER, 9.1.4. CALSTORE schema
STATUS_PARAMS CHAR(1),
SUMMARY VARCHAR(len?) NOT NULL DEFAULT "", CREATE TABLE CALSTORE (
SUMMARY_PARAMS INTEGER, VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
UID VARCHAR(len?) NOT NULL, CSID VARCHAR(255) NOT NULL,
UID_PARAMS INTEGER, CALMASTER TINYTEXT NOT NULL,
X_PROP_LIST INTEGER DEFAULT_VCAR INTEGER, /* VALUE_KEY */
}; MAXDATE TIMESTAMP(14) NOT NULL
DEFAULT "99991231235959",
MINDATE TIMESTAMP(14) NOT NULL
DEFAULT "00000101000000",
CURRENT_DATETIME TIMESTAMP(14) NOT NULL,
RECUR_ACCEPTED ENUM("T", "F") NOT NULL DEFAULT "T",
RECUR_EXPAND ENUM("T", "F") NOT NULL DEFAULT "T",
RECUR_LIMIT INTEGER DEFAULT 0,
VERSION VARCHAR(10) NOT NULL DEFAULT "2.0"
);
Mansour/Dawson/Royer/Taler/Hill 63 Expires September 2000
9.1.5. CHILDREN schema
CREATE TABLE CHILDREN (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY, /* KEY_VALUE */
CALID VARCHAR(255)
);
9.1.6. CLASS schema
CREATE TABLE CLASS (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE ENUM("PUBLIC", "PRIVATE",
"CONFIDENTIAL",
"<other>") NOT NULL,
OTHER_VALUE TEXT,
XPARAM INTEGER /* VALUE_KEY */
);
9.1.7. CN schema
CREATE TABLE CN (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE VARCHAR(255) NOT NULL
);
9.1.8. COMMENT schema
CREATE TABLE COMMENT (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT NOT NULL,
ALTREP INTEGER, /* VALUE_KEY */
LANGUAGE INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.9. CONTACT schema
CREATE TABLE CONTACT (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TINYTEXT NOT NULL,
ALTREP VARCHAR(255),
LANGUAGE INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
Mansour/Dawson/Royer/Taler/Hill 64 Expires September 2000
9.1.10. CREATED schema
CREATE TABLE CREATED (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TIMESTAMP(14) NOT NULL,
VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */
TZID INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.11. CUTYPE schema
CREATE TABLE CUTYPE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE ENUM("INDIVIDUAL",
"GROUP",
"RESOURCE",
"ROOM",
"UNKNOWN",
"<other>") NOT NULL,
OTHER_VALUE TINYTEXT
);
9.1.12. DAYLIGHT_STANDARD schema
CREATE TABLE DAYLIGHT_STANDARD (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
DTSTART INTEGER NOT NULL, /* VALUE_KEY */
TZOFFSETFROM INTEGER NOT NULL, /* SECONDS */
TZOFFSETTO INTEGER NOT NULL, /* SECONDS */
COMMENT INTEGER, /* VALUE_KEY */
RDATE INTEGER, /* VALUE_KEY */
RRULE INTEGER, /* VALUE_KEY */
TZNAME TINYTEXT,
XPROP INTEGER /* VALUE_KEY */
);
9.1.13. DESCRIPTION schema
CREATE TABLE DESCRIPTION (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT,
ALTREP INTEGER, /* VALUE_KEY */
Mansour/Dawson/Royer/Taler/Hill 65 Expires September 2000
LANGUAGE INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.14. DIR schema
CREATE TABLE DIR (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT
);
9.1.15. DTEND schema
CREATE TABLE DTEND (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TIMESTAMP(14) NOT NULL,
VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */
TZID INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.16. DTSTAMP schema
CREATE TABLE DTSTART (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TIMESTAMP(14) NOT NULL,
VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */
TZID INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.17. DUE schema
CREATE TABLE DUE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TIMESTAMP(14) NOT NULL,
VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */
TZID INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
Mansour/Dawson/Royer/Taler/Hill 66 Expires September 2000
9.1.18. DURATION schema
CREATE TABLE DURATION (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE INTEGER, /* SECONDS */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.19. EXDATE schema
CREATE TABLE EXDATE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TIMESTAMP(14) NOT NULL,
VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */
TZID INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.20. EXRULE schema
CREATE TABLE EXRULE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE INTEGER NOT NULL, /* VALUE_KEY (RECUR) */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.21. FBTYPE schema
CREATE TABLE FBTYPE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE ENUM("FREE", "BUSY",
"BUSY-UNAVALIBLE",
"BUSY-TENTATIVE",
"<other>") NOT NULL,
OTHER_VALUE TINYTEXT
);
9.1.22. FMTTYPE schema
CREATE TABLE FMTTYPE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TINYTEXT
);
Mansour/Dawson/Royer/Taler/Hill 67 Expires September 2000
9.1.23. FREEBUSY schema
CREATE TABLE FREEBUSY (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE_FROM TIMESTAMP(14) NOT NULL,
VALUE_TO TIMESTAMP(14),
DURATION INTEGER, /* SECONDS */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.24. GEO schema
CREATE TABLE GEO (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
LATITUDE FLOAT(7,3),
LONGITUDE FLOAT(7,3),
XPARAM INTEGER /* VALUE_KEY */
);
9.1.25. LANGUAGE schema
CREATE TABLE LANGUAGE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TINYTEXT
);
9.1.26. LAST_MODIFIED schema
CREATE TABLE LAST_MODIFIED (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TIMESTAMP(14) NOT NULL,
XPARAM INTEGER /* VALUE_KEY */
);
9.1.27. MEMBER schema
CREATE TABLE MEMBER (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT
);
Mansour/Dawson/Royer/Taler/Hill 68 Expires September 2000
9.1.28. METHOD schema
CREATE TABLE METHOD (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE ENUM("PUBLISH",
"REQUEST",
"REFRESH",
"CANCEL",
"ADD",
"REPLY",
"COUNTER",
"DECLINE-COUNTER",
"CREATE",
"DELETE",
"MODIFY",
"MOVE",
"READ",
"<other>") NOT NULL,
OTHER_VALUE TEXT
);
9.1.29. ORGANIZER schema
CREATE TABLE ORGANIZER (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT NOT NULL,
CN INTEGER, /* VALUE_KEY */
DIR INTEGER, /* VALUE_KEY */
SENT_BY INTEGER, /* VALUE_KEY */
LANGUAGE INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.30. OWNERS schema
CREATE TABLE OWNERS (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TINYTEXT NOT NULL
);
9.1.31. PARTSTAT schema
CREATE TABLE PARTSTAT (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE ENUM("NEEDS-ACTION",
"ACCEPTED",
"DECLINED",
Mansour/Dawson/Royer/Taler/Hill 69 Expires September 2000
"TENTATIVE",
"DELEGATED",
"COMPLETED",
"IN-PROCESS",
"<other>")
NOT NULL DEFAULT "NEEDS-ACTION",
OTHER_VALUE TINYTEXT
);
9.1.32. PERCENT_COMPLETE schema
CREATE TABLE PERCENT_COMPLETE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE INTEGER NOT NULL,
XPARAM INTEGER /* VALUE_KEY */
);
9.1.33. PRIORITY schema
CREATE TABLE PRIORITY (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE INTEGER NOT NULL,
XPARAM INTEGER /* VALUE_KEY */
);
9.1.34. RDATE schema
/* VALUETYPE (D) = DATE, (T) = DATE-TIME, (P) = PERIOD */
CREATE TABLE RDATE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TIMESTAMP(14) NOT NULL,
VALUETYPE ENUM("D", "T", "P") NOT NULL DEFAULT "T",
TZID INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.35. RECUR schema
CREATE TABLE RECUR (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
FREQ ENUM("SECONDLY", "MINUTELY", "HOURLY",
"DAILY", "WEEKLY", "MONTHLY", "YEARLY"),
UNTIL TIMESTAMP(14),
COUNT INTEGER,
INTERVAL_VAL INTEGER,
Mansour/Dawson/Royer/Taler/Hill 70 Expires September 2000
BYSECOND SET("1", "2", "3", "4", "5", "6", "7", "8",
"9", "10", "11", "12", "13", "14", "15",
"16", "17", "18", "19", "20", "21", "22",
"23", "24", "25", "26", "27", "28", "29",
"30", "31", "32", "33", "34", "35", "36",
"37", "38", "39", "40", "41", "42", "43",
"44", "45", "46", "47", "47", "48", "49",
"50", "51", "52", "53", "54", "55", "56",
"57", "58", "59"),
BYMINUTE SET("1", "2", "3", "4", "5", "6", "7", "8",
"9", "10", "11", "12", "13", "14", "15",
"16", "17", "18", "19", "20", "21", "22",
"23", "24", "25", "26", "27", "28", "29",
"30", "31", "32", "33", "34", "35", "36",
"37", "38", "39", "40", "41", "42", "43",
"44", "45", "46", "47", "47", "48", "49",
"50", "51", "52", "53", "54", "55", "56",
"57", "58", "59"),
BYHOUR SET("1", "2", "3", "4", "5", "6", "7", "8",
"9", "10", "11", "12", "13", "14", "15",
"16", "17", "18", "19", "20", "21", "22",
"23"),
BYDAY TINYTEXT,
BYMONTHDAY SET("1", "2", "3", "4", "5", "6", "7", "8",
"9", "10", "11", "12", "13", "14", "15",
"16", "17", "18", "19", "20", "21", "22",
"23", "24", "25", "26", "27", "28", "29",
"30", "31", "-1", "-2", "-3", "-4", "-5",
"-6", "-7", "-8", "-9", "-10", "-11",
"-12", "-13", "-14", "-15", "-16", "-17",
"-18", "-19", "-20", "-21", "-22", "-23",
"-24", "-25", "-26", "-27", "-28", "-29",
"-30", "-31"),
BYYEARDAY TINYTEXT,
BYWEEKNO TINYTEXT,
BYMONTH SET("1", "2", "3", "4", "5", "6", "7", "8",
"9", "10", "11", "12"),
BYSETPOS TINYTEXT,
WKST SET("SU", "MO", "TU", "WE", "TH", "FR", "SA"),
XPARAM INTEGER /* VALUE_KEY */
);
9.1.36. RECURRENCE_ID schema
CREATE TABLE RECURRENCE_ID (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TIMESTAMP(14) NOT NULL,
VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */
RANGE ENUM("THISANDPRIOR", "THISANDFUTURE"),
TZID INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
Mansour/Dawson/Royer/Taler/Hill 71 Expires September 2000
);
9.1.37. RELATED_TO schema
CREATE TABLE RELATED_TO (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT,
RELTYPE ENUM("PARENT", "CHILD", "SIBLING",
"<other>"),
OTHER_RELTYPE TINYTEXT,
XPARAM INTEGER /* VALUE_KEY */
);
9.1.38. REPEAT schema
CREATE TABLE REPEAT (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE INTEGER NOT NULL DEFAULT 0,
XPARAM INTEGER /* VALUE_KEY */
);
9.1.39. RESOURCES schema
CREATE TABLE RESOURCES (
VALUE_Y INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT NOT NULL,
ALTREP INTEGER, /* VALUE_KEY */
LANGUAE INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.40. ROLE schema
CREATE TABLE ROLE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE ENUM("CHAIR", "REQ-PARTICIPANT",
"OPT-PARTICIPANT",
"NON-PARTICIPANT",
"<other>")
NOT NULL DEFAULT "REQ-PARTICIPANT",
OTHER_VALUE TINYTEXT
);
Mansour/Dawson/Royer/Taler/Hill 72 Expires September 2000
9.1.41. RRULE schema
CREATE TABLE RRULE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE INTEGER NOT NULL, /* VALUE_KEY (RECUR) */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.42. SEQUENCE schema
CREATE TABLE SEQUENCE (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY DEFAULT 0,
VALUE INTEGER NOT NULL,
XPARAM INTEGER /* VALUE_KEY */
);
9.1.43. STATUS schema
CREATE TABLE STATUS (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE ENUM("TENTATIVE",
"CONFIRMED",
"CANCELLED",
"NEEDS-ACTION",
"COMPLETED",
"IN-PROCESS",
"DRAFT",
"FINAL") NOT NULL,
XPARAM INTEGER /* VALUE_KEY */
);
9.1.44. SUMMARY schema
CREATE TABLE SUMMARY (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TINYTEXT,
ALTREP INTEGER, /* VALUE_KEY */
LANGUAGE INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.45. TRANSP schema
CREATE TABLE TRANSP (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
Mansour/Dawson/Royer/Taler/Hill 73 Expires September 2000
VALUE ENUM("OPQQUE", "TRANSPARENT",
"OPAQUE-NOCONFLICTS",
"TRANSPARENT-NOCONFLICTS")
NOT NULL DEFAULT "TRANSPARENT",
XPARAM INTEGER /* VALUE_KEY */
);
9.1.46. TRIGGER schema
CREATE TABLE TRIGGER (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */
VALUE_DT TIMESTAMP(14),
VALUE_P INTEGER, /* SECONDS */
RELATED INTEGER, /* VALUE_KEY */
XPARAM INTEGER /* VALUE_KEY */
);
9.1.47. TZID schema
CREATE TABLE TZID (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT
);
9.1.48. UID schema
CREATE TABLE UID (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT,
XPARAM INTEGER /* VALUE_KEY */
);
9.1.49. URL schema
CREATE TABLE URL (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TEXT,
XPARAM INTEGER /* VALUE_KEY */
);
Mansour/Dawson/Royer/Taler/Hill 74 Expires September 2000
9.1.50. VALARM schema
CREATE TABLE VALARM (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
ACTION INTEGER NOT NULL, /* VALUE_KEY */
ATTACH INTEGER,
DESCRIPTION INTEGER, /* VALUE_KEY */
DURATION INTEGER, /* VALUE_KEY */
REPEAT INTEGER, /* VALUE_KEY */
SUMMARY INTEGER, /* VALUE_KEY */
TRIGGER INTEGER, /* VALUE_KEY */
X_PROP INTEGER /* VALUE_KEY */
);
9.1.51. VCALENDAR schema
CREATE TABLE VCALENDAR (
VALUE_KEY INTEGER NOT NULL,
ALLOW_CONFLICTS ENUM("T", "F") DEFAULT "T",
CALSCALE TINYTEXT NOT NULL,
CHARSET TINYTEXT NOT NULL,
CHILDREN INTEGER, /* VALUE_KEY */
CREATED INTEGER, /* VALUE_KEY */
DEFAULT_VCAR INTEGER NOT NULL, /* VALUE_KEY */
LANGUAGE INTEGER, /* VALUE_KEY */
LAST_MODIFIED INTEGER, /* VALUE_KEY */
NAME TINYTEXT,
OWNERS INTEGER, /* VALUE_KEY */
PARENT INTEGER, /* VALUE_KEY */
RELCALID VARCHAR(255) NOT NULL PRIMARY KEY,
TOMESTONE ENUM("T", "F") NOT NULL DEFAULT "T",
TZID INTEGER NOT NULL /* VALUE_KEY */
);
9.1.52. VCAR schema
CREATE TABLE VCAR (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TINYTEXT
/*<TODO>*/
);
9.1.53. VEVENT schema
The METHOD value will be CREATE for booked entries. Or it must be a
valid scheduling METHOD such as PUBLISH, REQUEST, REPLY, ADD, CANCEL,
REFRESH, COUNTER or DECLINE-COUNTER.
Mansour/Dawson/Royer/Taler/Hill 75 Expires September 2000
CREATE TABLE VEVENT (
ATTACH INTEGER, /* VALUE_KEY */
ATTENDEE INTEGER, /* VALUE_KEY */
CATEGORIES INTEGER, /* VALUE_KEY */
CLASS INTEGER, /* VALUE_KEY */
COMMENT INTEGER, /* VALUE_KEY */
CONTACT INTEGER, /* VALUE_KEY */
CREATED INTEGER, /* VALUE_KEY */
DESCRIPTION INTEGER, /* VALUE_KEY */
DTEND INTEGER, /* VALUE_KEY */
DTSTAMP INTEGER, /* VALUE_KEY */
DTSTART INTEGER, /* VALUE_KEY */
DURATION INTEGER, /* VALUE_KEY */
EXDATE INTEGER, /* VALUE_KEY */
EXRULE INTEGER, /* VALUE_KEY */
GEO INTEGER, /* VALUE_KEY */
LAST_MODIFIED INTEGER, /* VALUE_KEY */
LOCATION INTEGER, /* VALUE_KEY */
METHOD INTEGER, /* VALUE_KEY */
ORGANIZER INTEGER, /* VALUE_KEY */
PRIORITY INTEGER, /* VALUE_KEY */
RECURRENCE_ID INTEGER, /* VALUE_KEY */
RDATE_KEY INTEGER, /* VALUE_KEY */
RELATED_TO INTEGER, /* VALUE_KEY */
RESOURCES INTEGER, /* VALUE_KEY */
RRULE INTEGER, /* VALUE_KEY */
SUMMARY INTEGER, /* VALUE_KEY */
SEQUENCE INTEGER, /* VALUE_KEY */
STATUS INTEGER, /* VALUE_KEY */
TRANSP INTEGER, /* VALUE_KEY */
UID INTEGER, /* VALUE_KEY */
URL INTEGER, /* VALUE_KEY */
X_PROP_KEY INTEGER, /* VALUE_KEY */
VALARM_KEY INTEGER /* VALUE_KEY */
);
9.1.54. VFREEBUSY schema
An implementation may not actually have a VFREEBUSY table as the An implementation may not actually have a VFREEBUSY table as the
information may be produced dynamicly. However a CS MUST appear to information may be produced dynamicly. However a CS MUST appear to
provide this table as this may be how a CUA chooses to query for provide this table as this may be how a CUA chooses to query for
VFREEBUSY information while using [CAP]. Example, it probabily VFREEBUSY information while using [CAP]. Example, it probably would not
would not make any sense for ATTENDEE to exist in this table, yet make any sense for ATTENDEE to exist in this table, yet a CUA may wish
a CUA may wish to ask for the VFREEBUSY for an ATTENDEE. to ask for the VFREEBUSY for an ATTENDEE.
Mansour/Dawson/Royer/Taler/Hill CREATE TABLE VFREEBUSY (
Expires: April 2000 55 ATTENDEE INTEGER, /* VALUE_KEY */
create table VFREEBUSY { COMMENT INTEGER, /* VALUE_KEY */
ATTENDEE_LIST VARCHAR(len?), CONTACT INTEGER, /* VALUE_KEY */
COMMENT VARCHAR(len?), DTEND INTEGER, /* VALUE_KEY */
COMMENT_PARAMS INTEGER,
CONTACT_LIST INTEGER,
DTEND TIMESTAMP NOT NULL,
DTEND_PARAMS INTEGER,
DTSTAMP TIMESTAMP NOT NULL,
DTSTAMP_PARAMS INTEGER,
DTSTART TIMESTAMP NOT NULL,
DTSTART_PARAMS INTEGER,
FREEBUSY_LIST INTEGER NOT NULL,
METHOD VARCHAR(len20?),
ORGANIZER VARCHAR(len?) NOT NULL,
ORGANIZER_PARAMS INTEGER,
X_PROP_LIST INTEGER
URL VARCHAR(len?)
};
create table VTIMEZONE { Mansour/Dawson/Royer/Taler/Hill 76 Expires September 2000
DAYLIGHT_LIST INTEGER, /* In TZ_LIST table */ DTSTAMP INTEGER, /* VALUE_KEY */
STANDARD_LIST INTEGER, /* In TZ_LIST table */ DTSTART INTEGER, /* VALUE_KEY */
TZID VARCHAR(len?) NOT NULL, FREEBUSY INTEGER, /* VALUE_KEY */
TZID_PARAM INTEGER, METHOD INTEGER, /* VALUE_KEY */
TZURL VARCHAR(len?) NOT NULL, ORGANIZER INTEGER, /* VALUE_KEY */
TZURL_PARAM INTEGER, X_PROP_KEY INTEGER, /* VALUE_KEY */
X_PROP_LIST INTEGER URL INTEGER /* VALUE_KEY */
}; );
create table TZ_LIST { 9.1.55. VJOURNAL schema
/* Maps to DAYLIGHT_LIST or STANDARD_LIST in VTIMEZONE table */ The METHOD value will be CREATE for booked entries. Or it must be a
TZ_KEY INTEGER, valid scheduling METHOD such as PUBLISH, REQUEST, REPLY, ADD, CANCEL,
COMMENT VARCHAR(len?), REFRESH, COUNTER or DECLINE-COUNTER.
COMMENT_PARAMS INTEGER,
DTSTART TIMESTAMP NOT NULL,
DTSTART_PARAMS INTEGER,
LAST_MODIFIED TIMESTAMP NOT NULL DEFAULT
CURRENT_DATE,
LAST_MODIFIED_PARAMS INTEGER,
RDATE_LIST INTEGER,
RRULE_LIST INTEGER,
TZNAME VARCHAR(len?),
TZOFFSET <?type?> NOT NULL,
TZOFFSETFROM <?type?> NOT NULL,
TZOFFSETTO <?type?> NOT NULL,
};
Mansour/Dawson/Royer/Taler/Hill CREATE TABLE VJOURNAL (
Expires: April 2000 56 ATTACH_KEY INTEGER, /* VALUE_KEY */
create table VALARM_LIST { CATEGORIES INTEGER, /* VALUE_KEY */
/* Maps to VALARM_LIST in other tables */ CLASS INTEGER, /* VALUE_KEY */
VALARM_KEY INTEGER, COMMENT INTEGER, /* VALUE_KEY */
ACTION INTEGER NOT NULL, CONTACT INTEGER, /* VALUE_KEY */
ACTION_PARAMS INTEGER, CREATED INTEGER, /* VALUE_KEY */
ATTACH_LIST INTEGER, DESCRIPTION INTEGER, /* VALUE_KEY */
DESCRIPTION VARCHAR(len?) NOT NULL DEFAUT "", DTSTAMP INTEGER, /* VALUE_KEY */
DESCRIPTION_PARAMS INTEGER, DTSTART INTEGER, /* VALUE_KEY */
DURATION <?type?>, EXDATE INTEGER, /* VALUE_KEY */
DURATION_PARAMS INTEGER, EXRULE INTEGER, /* VALUE_KEY */
REPEAT INTEGER, LAST_MODIFIED INTEGER, /* VALUE_KEY */
REPEAT_PARAMS INTEGER, METHOD INTEGER, /* VALUE_KEY */
SUMMARY VARCHAR(len?) NOT NULL DEFAULT "", ORGANIZER INTEGER, /* VALUE_KEY */
SUMMARY_PARAMS INTEGER, RDATE INTEGER, /* VALUE_KEY */
TRIGGER_DT TIMESTAMP, RECURRENCE_ID INTEGER, /* VALUE_KEY */
TRIGGER_DURATION <?type?>, RELATED_TO INTEGER, /* VALUE_KEY */
X_PROP_LIST INTEGER RRULE INTEGER, /* VALUE_KEY */
}; SEQUENCE INTEGER, /* VALUE_KEY */
STATUS INTEGER, /* VALUE_KEY */
SUMMARY INTEGER, /* VALUE_KEY */
UID INTEGER, /* VALUE_KEY */
X_PROP INTEGER /* VALUE_KEY */
);
9.1.56. VQUERY schema
Stored VQUERYs will use the following schema.
CREATE TABLE VQUERY (
VALUE_KEY INTEGER NOT NULL PRIMARY KEY,
VALUE TINYTEXT, /* QUERYNAME */
SCOPE TINYTEXT,
MAXRESULTS INTEGER,
Mansour/Dawson/Royer/Taler/Hill 77 Expires September 2000
MAXSIZE INTEGER,
CARSELECT TEXT,
CARWHERE TEXT,
CARORDERBY TEXT,
X_PROP INTEGER /* VALUE_KEY */
);
9.1.57. VTIMEZONE schema
CREATE TABLE VTIMEZONE (
DAYLIGHT INTEGER NOT NULL, /* VALUE_KEY */
STANDARD INTEGER NOT NULL, /* VALUE_KEY */
TZID INTEGER NOT NULL, /* VALUE_KEY */
TZURL INTEGER, /* VALUE_KEY */
X_PROP_KEY INTEGER /* VALUE_KEY */
);
9.1.58. VTODO schema
The METHOD value will be CREATE for booked entries. Or it must be a
valid scheduling METHOD such as PUBLISH, REQUEST, REPLY, ADD, CANCEL,
REFRESH, COUNTER or DECLINE-COUNTER.
CREATE TABLE VTODO (
ATTENDEE INTEGER, /* VALUE_KEY */
ATTACH INTEGER, /* VALUE_KEY */
CATEGORIES INTEGER, /* VALUE_KEY */
CLASS INTEGER, /* VALUE_KEY */
COMMENT INTEGER, /* VALUE_KEY */
CONTACT INTEGER, /* VALUE_KEY */
CREATED INTEGER NOT NULL, /* VALUE_KEY */
DESCRIPTION INTEGER, /* VALUE_KEY */
DTSTAMP INTEGER NOT NULL, /* VALUE_KEY */
DTSTART INTEGER NOT NULL, /* VALUE_KEY */
DUE INTEGER, /* VALUE_KEY */