draft-ietf-calsch-cap-00.txt   draft-ietf-calsch-cap-01.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-00.txt> Doug Royer/Sun Microsystems <draft-ietf-calsch-cap-01.txt> Doug Royer/Software.com
Alexander Taler/CS&T Alexander Taler/CS&T
Paul Hill/MIT Paul Hill/MIT
Expires six months from: August 5, 1999 Expires six months from: October 22, 1999
Calendar Access Protocol (CAP) Calendar Access Protocol (CAP)
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 Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that other
may also distribute working documents as Internet-Drafts. Internet- groups may also distribute working documents as Internet-Drafts.
Drafts are draft documents valid for a maximum of six months and may be Internet-Drafts are draft documents valid for a maximum of six months
updated, replaced, or obsoleted by other documents at any time. It is and may be updated, replaced, or obsoleted by other documents at any
inappropriate to use Internet- Drafts as reference material or to cite time. It is inappropriate to use Internet- Drafts as reference
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 1999. All Rights Reserved.
Abstract Abstract
The Calendar Access Protocol (CAP) is an Internet protocol that permits The Calendar Access Protocol (CAP) is an Internet protocol that
a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an permits a Calendar User (CU) to utilize a Calendar User Agent (CUA)
[RFC2445] based Calendar Store (CS). This memo defines the CAP to access an [RFC2445] based Calendar Store (CS). This memo defines
specification.The CAP definition is based on requirements identified by the CAP specification.
the Internet Engineering Task Force (IETF) Calendaring and Scheduling
(CALSCH) Working Group. More information about the IETF CALSCH Working The CAP definition is based on requirements identified by the
Group activities can be found on the IMC web site at Internet Engineering Task Force (IETF) Calendaring and Scheduling
(CALSCH) Working Group. More information about the IETF CALSCH
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 1
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
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 1 Expires February 2000 Mansour/Dawson/Royer/Taler/Hill
Taler/Hill Expires: April 2000 2
Table of Contents Table of Contents
1. Introduction ................................................ 3
1.1 Formatting Conventions ..................................... 3
1.2 Related Documents .......................................... 4
1.3 Definitions ................................................ 4
2. CAP Design .................................................. 8
2.1 System Model ............................................... 8
2.2 Calendar Store Object Model ................................ 9
2.3 Protocol Model ............................................. 10
2.4 Roles ...................................................... 11
2.5 Calendar User .............................................. 11
2.5.1 UPNs and Certificates .................................... 11
2.5.2 CAP session identity ..................................... 12
2.6 Calendar Addresses ......................................... 13
2.7 Finding CAP Servers ........................................ 14
2.7.1 Using DNS ................................................ 14
2.7.2 Using SLP ................................................ 14
2.8 Extensions to iCalendar .................................... 16
2.9 Relationship of RFC 2446 (ITIP) to CAP ..................... 17
2.10 VCalendar Access Rights (VCARs) ........................... 17
2.11 Query Schema .............................................. 18
3. State Diagram ............................................... 18
4. Protocol Framework .......................................... 19
4.1 CAP Application Layer ...................................... 19
4.2 CAP Transport Layer ........................................ 20
4.3 Response Format ............................................ 20
4.4 Auto-logout Timer .......................................... 20
4.5 Bounded Latency ............................................ 21
4.6 Data Elements .............................................. 21
5. Formal Command Syntax ....................................... 21
5.1 Searching and Filtering .................................... 21
5.1.1 Grammar For Search Mechanism ............................. 22
6. Access Rights ............................................... 22
6.1 VCAR Inheritance ........................................... 23
6.2 Access Control and NOCONFLICT .............................. 23
7. Commands and Responses ...................................... 23
7.1 Transport Protocol Commands ................................ 24
7.1.1 Initial Connection ....................................... 24
7.1.2 ABORT Command ............................................ 24
7.1.3 AUTHENTICATE Command ..................................... 25
7.1.6 DISCONNECT Command ....................................... 30
7.1.7 IDENTIFY Command ......................................... 30
7.1.8 SENDDATA Command ......................................... 30
7.1.9 STARTTLS Command ......................................... 31
7.2 Application Protocol Commands .............................. 32
7.2.1 Calendaring Commands ..................................... 32
7.2.1.1 CREATE Method .......................................... 32
1. Introduction........................................................6 Mansour/Dawson/Royer/Taler/Hill
7.2.1.1.1 Creating New Calendars ............................... 32
1.1 Formatting Conventions ...........................................6 7.2.1.2 DELETE Method .......................................... 34
7.2.1.3 GENERATEUID Method ..................................... 35
1.2 Related Documents ................................................6 7.2.1.4 MODIFY Method .......................................... 35
7.2.1.5 MOVE Method ............................................ 36
1.3 Definitions ......................................................7 7.2.1.6 READ Method ............................................ 37
7.2.2 Scheduling Commands ...................................... 41
2. CAP Design.........................................................10 7.2.2.1 PUBLISH ................................................ 41
7.2.2.2 REQUEST ................................................ 41
2.1 System Model ....................................................10 7.2.2.3 REPLY .................................................. 41
7.2.2.4 ADD .................................................... 41
2.2 Calendar Store Object Model .....................................11 7.2.2.5 CANCEL ................................................. 41
7.2.2.6 REFRESH ................................................ 41
2.3 Protocol Model ..................................................12 7.2.2.7 COUNTER ................................................ 41
7.2.2.8 DECLINECOUNTER ......................................... 41
2.4 Roles ...........................................................13 7.2.3 iTIP Examples ............................................ 42
7.2.3.1 Sending and Receiving an iTIP request .................. 42
2.5 Calendar User ...................................................13 7.2.3.2 Handling an iTIP refresh ............................... 45
2.5.1 UPNs and Certificates ........................................14 7.2.3.3 Sending and accepting an iTIP counter .................. 46
2.5.2 CAP session identity .........................................14 7.2.3.4 Declining an iTIP counter .............................. 47
8. Response Codes .............................................. 48
2.6 Calendar Addresses ..............................................15 9. Detailed SQL Schema ......................................... 50
9.1 iCalendar Store Schema ..................................... 51
2.7 Finding CAP Servers .............................................15 10. Examples ................................................... 57
10.1 Authentication Examples ................................... 57
2.8 Extensions to iCalendar .........................................16 10.1.1 Login Using Kerberos V4 ................................. 57
10.1.2 Error Scenarios ......................................... 58
2.9 Relationship of RFC 2446 (ITIP) to CAP ..........................16 10.2 Read Examples ............................................. 58
10.2.1 Read From A Single Calendar ............................. 58
2.10 VCalendar Access Rights (VCARs) ................................16 10.2.2 Read From Multiple Calendars ............................ 59
10.2.3 Timeouts ................................................ 61
2.11 Query Schema ...................................................17 10.2.4 Using the Calendar Parent, Children Properties .......... 62
10.2.5 An example that depends on VEVENT.DTSTART and
3. State Diagram......................................................17 VALARM.DTSTART ............................................ 62
11. Implementation Issues ...................................... 62
4. Protocol Framework.................................................18 12. Properties ................................................. 62
12.1 Calendar Store Properties ................................. 62
4.1 CAP Application Layer ...........................................18 12.2 Calendar Properties ....................................... 63
13. Security Considerations .................................... 64
4.2 CAP Transport Layer .............................................18 14. Changes to iCalendar ....................................... 64
14.1 Created ................................................... 64
4.3 Response Format .................................................18 14.2 Last Modified ............................................. 65
14.2.1.1 Time Transparency ..................................... 66
4.4 Auto-logout Timer ...............................................19 14.3 RIGHTS Value Type ......................................... 67
14.4 VCAR Calendar Component ................................... 70
4.5 Bounded Latency .................................................19 14.5 GRANT Component Property .................................. 72
14.6 DENY Component Property ................................... 73
Mansour/Dawson/Royer 2 Expires February 2000
Taler/Hill
4.6 Data Elements ...................................................19
5. Formal Command Syntax..............................................20
5.1 Searching and Filtering .........................................20
5.1.1 Grammar For Search Mechanism .................................20
6. Access Rights......................................................21
6.1 VCAR Inheritance ................................................21
7. Commands and Responses.............................................21
7.1 Transport Protocol Commands .....................................22
7.1.1 Initial Connection ...........................................22
7.1.2 ABORT Command ................................................22
7.1.3 AUTHENTICATE Command .........................................23
7.1.4 CONTINUE Command .............................................26
7.1.5 DISCONNECT Command ...........................................27
7.1.6 IDENTIFY Command .............................................27
7.1.7 SENDDATA Command .............................................27
7.1.8 STARTTLS Command .............................................27
7.2 Application Protocol Commands ...................................28
7.2.1 Calendaring Commands .........................................28
7.2.1.1 CREATE Method ............................................28
7.2.1.1.1 Creating New Calendars ................................29
7.2.1.2 DELETE Method ............................................30
7.2.1.3 GENERATEUID Method .......................................31
7.2.1.4 MODIFY Method ............................................31
7.2.1.5 MOVE Method ..............................................32
7.2.1.6 READ Method ..............................................32
7.2.2 Scheduling Commands ..........................................36
7.2.2.1 PUBLISH ..................................................36
7.2.2.2 REQUEST ..................................................36
7.2.2.3 REPLY ....................................................36
7.2.2.4 ADD ......................................................36
7.2.2.5 CANCEL ...................................................36
7.2.2.6 REFRESH ..................................................36
7.2.2.7 COUNTER ..................................................36
7.2.2.8 DECLINECOUNTER ...........................................36
7.2.3 iTIP Examples ................................................36
7.2.3.1 Sending and Receiving an iTIP request ....................36
7.2.3.2 Handling an iTIP refresh .................................39
7.2.3.3 Sending and accepting an iTIP counter ....................40
7.2.3.4 Declining an iTIP counter ................................41
8. Response Codes.....................................................42
9. Detailed SQL Schema................................................44
Mansour/Dawson/Royer 3 Expires February 2000
Taler/Hill
9.1 iCalendar Store Schema ..........................................45
10. Examples..........................................................50
10.1 Authentication Examples ........................................50
10.1.1 Login Using Kerberos V4 .....................................50
10.1.2 Error Scenarios .............................................50
10.2 Read Examples ..................................................51
10.2.1 Read From A Single Calendar .................................51
10.2.2 Read From Multiple Calendars ................................52
10.2.3 Timeouts ....................................................53
10.2.4 Using the Calendar Parent, Children Properties ..............54
10.2.5 An example that depends on VEVENT.DTSTART and VALARM.DTSTART 54
11. Implementation Issues.............................................54
12. Properties........................................................54
12.1 Calendar Store Properties ......................................54
12.2 Calendar Properties ............................................54
13. Security Considerations...........................................55
14. Changes to iCalendar..............................................56
14.1 RIGHTS Value Type ..............................................56
14.2 VCAR Calendar Component ........................................59
14.3 GRANT Component Property .......................................60
14.4 DENY Component Property ........................................61
14.5 VCAR Identifier Component Property .............................61
14.6 REQUEST-STATUS property ........................................62
15. CAP Entities Registration.........................................63
15.1 Registration of New and Modified CAP Entities ..................63
15.2 Registration of New Entities ...................................63
15.2.1 Define the Entity ...........................................63
15.2.2 Post the entity definition ..................................64
15.2.3 Allow a comment period ......................................64
15.2.4 Submit the entity for approval ..............................64
Mansour/Dawson/Royer 4 Expires February 2000
Taler/Hill
15.3 Property Change Control ........................................65
16. IANA Considerations...............................................65
17. Acknowledgments...................................................65
18. Bibliography......................................................66
19. Author's Address..................................................66
20. Full Copyright Statement..........................................67 Mansour/Dawson/Royer/Taler/Hill
14.7 VCAR Identifier Component Property ........................ 73
15. CAP Entities Registration .................................. 75
15.2.1 Define the Entity ....................................... 76
15.2.2 Post the entity definition .............................. 77
15.2.3 Allow a comment period .................................. 77
15.2.4 Submit the entity for approval .......................... 77
15.3 Property Change Control ................................... 77
16. IANA Considerations ........................................ 78
17. Acknowledgments ............................................ 78
18. Bibliography ............................................... 78
19. Author's Address ........................................... 79
20. Full Copyright Statement ................................... 80
Mansour/Dawson/Royer 5 Expires February 2000 Mansour/Dawson/Royer/Taler/Hill
Taler/Hill
1. Introduction 1. Introduction
This document specifies how a Calendar User Agent (CUA) interacts with a
Calendar Store (CS) to manage calendar information. In particular, it
specifies how to query, create, modify, and delete iCalendar components
(e.g., events, to-dos, or daily journal entries). It further specifies
how to search for available busy time information.
This protocol is based on request/response form of protocol data units, This document specifies how a Calendar User Agent (CUA) interacts
sent from a client CUA to a calendar server. The protocol data units with a Calendar Store (CS) to manage calendar information. In
leverage the standard iCalendar format [RFC2445] for conveying CS particular, it specifies how to query, create, modify, and delete
related information. iCalendar components (e.g., events, to-dos, or daily journal
entries). It further specifies how to search for available busy time
information.
This protocol is based on request/response form of protocol data
units, sent from a client CUA to a calendar server. The protocol data
units leverage the standard iCalendar format [RFC2445] for conveying
CS related information.
1.1 Formatting Conventions 1.1 Formatting Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "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 example, text with the first character of each word in upper case. For
"Organizer" refers to a role of a "Calendar User" (CU) within the example, "Organizer" refers to a role of a "Calendar User" (CU)
protocol defined by this memo. Calendar components defined by [RFC2445] within the protocol defined by this memo. Calendar components defined
are referred to with capitalized, quoted-strings of text. All calendar by [RFC2445] are referred to with capitalized, quoted-strings of
components start with the letter "V". For example, "VEVENT" refers to text. All calendar components start with the letter "V". For example,
the event calendar component, "VTODO" refers to the to-do calendar "VEVENT" refers to the event calendar component, "VTODO" refers to
component and "VJOURNAL" refers to the daily journal calendar component. the to-do calendar component and "VJOURNAL" refers to the daily
Calendar access methods defined by this memo, as well as scheduling journal calendar component. Calendar access methods defined by this
methods defined by [RFC2446], are referred to with capitalized, quoted- memo, as well as scheduling methods defined by [RFC2446], are
strings of text. For example, "CREATE" refers to the method for creating referred to with capitalized, quoted-strings of text. For example,
a calendar component on a calendar, "READ" refers to the method for "CREATE" refers to the method for creating a calendar component on a
reading calendar components. calendar, "READ" refers to the method for reading calendar
components.
Properties defined by this memo are referred to with capitalized, Properties defined by this memo are referred to with 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 the "ATTENDEE" property refers to the iCalendar property used to convey
calendar address of a "Calendar User". Property parameters defined by the calendar address of a "Calendar User". Property parameters
this memo are referred to with lower case, quoted-strings of text, defined by this memo are referred to with lower case, quoted-strings
followed by the word "parameter". For example, "value" parameter refers of text, followed by the word "parameter". For example, "value"
to the iCalendar property parameter used to override the default data parameter refers to the iCalendar property parameter used to override
type for a property value. Enumerated values defined by this memo are the default data type for a property value. Enumerated values defined
referred to with capitalized text, either alone or followed by the word by this memo are referred to with capitalized text, either alone or
"value". followed by the word "value".
In tables, the quoted-string text is specified without quotes in order In tables, the quoted-string text is specified without quotes in
to minimize the table length.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 3
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
standards. This document, standards. This document,
Mansour/Dawson/Royer 6 Expires February 2000
Taler/Hill
[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 between [RFC2446] specifies an interoperability protocol for scheduling
different implementations. The related documents are: between 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 [to be published]. [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 made definitions from these other memos. Where possible, references are
to the memo that provides for the specification of these concepts or made to the memo that provides for the specification of these
definitions. concepts or definitions.
1.3 Definitions 1.3 Definitions
Authentication ID (AuthID)
A tuple of username, realm, and authentication method, used by the
Calendar Service internally to identify a successfully
authenticated CAP session.
Calendar Authentication ID (AuthID) A tuple of username, realm, and
A collection of logically related objects or entities each of which authentication method, used by the Calendar Service internally to
may be associated with a calendar date and possibly time of day. identify a successfully authenticated CAP session.
These entities can include other calendar properties or calendar
Calendar A collection of logically related objects or entities each
of which may be associated with a calendar date and possibly time of
day. These entities can include other calendar properties or calendar
components. In addition, a calendar might be hierarchically related components. In addition, a calendar might be hierarchically related
to other sub-calendars. A calendar is identified by its unique to other sub-calendars. A calendar is identified by its unique
calendar identifier. The [RFC2445] defines calendar properties, calendar identifier. The [RFC2445] defines calendar properties,
calendar components and component properties that make up the calendar components and component properties that make up the content
content of a calendar. of a calendar.
Calendar Access Protocol (CAP) Calendar Access Protocol (CAP) The standard Internet protocol that
The standard Internet protocol that permits a Calendar User Agent permits a Calendar User Agent to access and manipulate a calendar
to access and manipulate a calendar residing on a Calendar Store. residing on a Calendar Store.
Calendar Access Rights (CAR) Calendar Access Rights (CAR) The mechanism for specifying the CAP
The mechanism for specifying the CAP operations ("ACTIONS") that a operations ("ACTIONS") that a particular calendar user ("UPN") are
particular calendar user ("UPN") are granted or denied permission granted or denied permission to perform on a given calendar entity
to perform on a given calendar entity ("OBJECT"). The calendar ("OBJECT"). The calendar access rights are specified with the "VCAR"
access rights are specified with the "VCAR" calendar components
within a CS and calendar.
Calendar Component Mansour/Dawson/Royer/Taler/Hill
An entity within a calendar. Some types of calendar components Expires: April 2000 4
include events, to-dos, journals, alarms, time zones and freebusy calendar components within a CS and calendar.
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 Calendar Component An entity within a calendar. Some types of
An attribute of a particular calendar component. Some calendar calendar components include events, to-dos, journals, alarms, time
component properties are applicable to different types of calendar zones and freebusy data. A calendar component consists of component
components. For example, DTSTART is applicable to VEVENT, VTODO, properties and possibly other sub-components. For example, an event
may contain an alarm component.
Mansour/Dawson/Royer 7 Expires February 2000 Calendar Component Properties An attribute of a particular calendar
Taler/Hill component. Some calendar component properties are applicable to
VJOURNAL calendar components. Other calendar components are different types of calendar components. For example, DTSTART is
applicable only to an individual type of calendar component. For applicable to VEVENT, VTODO, VJOURNAL calendar components. Other
example, TZURL is only applicable to VTIMEZONE calendar components. 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) Calendar Identifier (CalID) A globally unique identifier associated
A globally unique identifier associated with a calendar. Calendars with a calendar. Calendars reside within a CS. See Qualified Calendar
reside within a CS. See Qualified Calendar Identifier and Relative Identifier and Relative Calendar Identifier.
Calendar Identifier.
Calendar Policy
A CAP operational restriction on the access or manipulation of a
calendar. For example, "events MUST be scheduled in unit intervals
of one hour".
Calendar Properties
An attribute of a calendar. The attribute applies to the calendar,
as a whole. For example, CALSCALE specifies the calendar scale
(e.g., GREGORIAN) for the whole calendar.
Calendar Service Calendar Policy A CAP operational restriction on the access or
An implementation of a Calendar Store that manages one or more manipulation of a calendar. For example, "events MUST be scheduled in
calendars. unit intervals of one hour".
Calendar Store (CS) Calendar Properties An attribute of a calendar. The attribute applies
The data and service model definition for a Calendar Service. to the calendar, as a whole. For example, CALSCALE specifies the
calendar scale (e.g., GREGORIAN) for the whole calendar.
Calendar Store Identifier (CSID) Calendar Service An implementation of a Calendar Store that manages
The globally unique identifier for an individual CS. A CSID one or more calendars.
consists of the host and port portions of a "Common Internet Scheme
Syntax" part of a URL, as defined by [RFC2396].
Calendar Store Components Calendar Store (CS) The data and service model definition for a
Components maintained in a CS specify a grouping of calendar store- Calendar Service.
wide information. Calendar store components can be accessed using
CAP.
Calendar Store Properties Calendar Store Identifier (CSID) The globally unique identifier for
Properties maintained in a Calendar Store calendar store-wide an individual CS. A CSID consists of the host and port portions of a
information. Calendar store properties can be accessed using CAP. "Common Internet Scheme Syntax" part of a URL, as defined by
[RFC2396].
Calendar User (CU) Calendar Store Components Components maintained in a CS specify a
An entity (often biological) that uses a calendaring system. grouping of calendar store-wide information. Calendar store
components can be accessed using CAP.
Calendar User Agent (CUA) Calendar Store Properties Properties maintained in a Calendar Store
The CUA is the client application that a CU utilizes to access and calendar store-wide information. Calendar store properties can be
manipulate a calendar. accessed using CAP.
Calendaring and Scheduling System Mansour/Dawson/Royer/Taler/Hill
The computer sub-system that provides the services for accessing, Expires: April 2000 5
manipulating calendars and scheduling calendar components. Calendar User (CU) An entity (often biological) that uses a
calendaring system.
CAP Session Calendar User Agent (CUA) The CUA is the client application that a CU
An open communication channel between a CAP CUA and a CAP CS. utilizes to access and manipulate a calendar.
Connected Mode Calendaring and Scheduling System The computer sub-system that
provides the services for accessing, manipulating calendars and
scheduling calendar components.
Mansour/Dawson/Royer 8 Expires February 2000 CAP Session An open communication channel between a CAP CUA and a CAP
Taler/Hill
A mobile computing mode where the CUA is directly connected to the
CS. CS.
Delegate Connected Mode A mobile computing mode where the CUA is directly
Is a calendar user (sometimes called the delegatee) who has been connected to the CS.
assigned participation in a scheduled calendar component (e.g.,
VEVENT) by one of the attendees in the scheduled calendar
component (sometimes called the delegator). An example of a
delegate is a team member told to go to a particular meeting.
Designate Delegate Is a calendar user (sometimes called the delegatee) who has
Is a calendar user who is authorized to act on behalf of another been assigned participation in a scheduled calendar component (e.g.,
calendar user. An example of a designate is an assistant. VEVENT) by one of the attendees in the scheduled calendar component
(sometimes called the delegator). An example of a delegate is a team
member told to go to a particular meeting.
Disconnected Mode Designate Is a calendar user who is authorized to act on behalf of
A mobile computing mode where a CUA can be disconnected from a CS. another calendar user. An example of a designate is an assistant.
When the CUA is disconnected, it is in the disconnected mode.
Fan Out Disconnected Mode A mobile computing mode where a CUA can be
The calendaring and scheduling process by which a calendar disconnected from a CS. When the CUA is disconnected, it is in the
disconnected mode.
Fan Out The calendaring and scheduling process by which a calendar
operation on one calendar is also performed on every other calendar operation on one calendar is also performed on every other calendar
specified in the operation. This may include the calendar specified in the operation. This may include the calendar associated
associated with TARGET calendar property. with TARGET calendar property.
Hierarchical Calendars Hierarchical Calendars A CS feature where a calendar have a
A CS feature where a calendar have a hierarchical relationship with hierarchical relationship with another calendar in the CS. The top-
another calendar in the CS. The top-most calendar in the most calendar in the hierarchical relationship has the CS as its
hierarchical relationship has the CS as its parent. There may be parent. There may be multiple top-most calendars in a given CS.
multiple top-most calendars in a given CS. Within a given Within a given hierarchical relationship, all sub-calendars have a
hierarchical relationship, all sub-calendars have a calendar with a calendar with a "parent" topographical relationship. In addition,
"parent" topographical relationship. In addition, sub-calendars may sub-calendars may have a relationship with another calendar that has
have a relationship with another calendar that has a "child" a "child" topographical relationship. In addition, a calendar may
topographical relationship. In addition, a calendar may have a have a relationship such that one or more calendars have a "sibling"
relationship such that one or more calendars have a "sibling"
topographical relationship with the calendar. The hierarchical topographical relationship with the calendar. The hierarchical
calendar feature is not a storage relationship of the calendars calendar feature is not a storage relationship of the calendars
within the CS. Instead it is a feature that relates access control within the CS. Instead it is a feature that relates access control
rights to calendar content between different calendars in the CS. rights to calendar content between different calendars in the CS.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 6
The hierarchical relationship of a calendar is specified in the The hierarchical relationship of a calendar is specified in the
"PARENT" and "CHILDREN" calendar properties. "PARENT" and "CHILDREN" calendar properties.
High Bandwidth Connection High Bandwidth Connection A communications connection supporting high
A communications connection supporting high transfer rates; transfer rates; transfer rates commonly found within a LAN.
transfer rates commonly found within a LAN.
Local Store Local Store A CS which is on the same platform as the CUA.
A CS which is on the same platform as the CUA.
Low Bandwidth Connection Low Bandwidth Connection A communications connection supporting slow
A communications connection supporting slow transfer rates; transfer rates; transfer rates commonly found in remote access
transfer rates commonly found in remote access technology. technology.
Owner 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.
Mansour/Dawson/Royer 9 Expires February 2000 Owner A CU or CUs that have "OWNER" calendar access rights for a
Taler/Hill
A CU or CUs 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) Qualified Calendar Identifier (Qualified CalID) A CalID where both
A CalID where both the <scheme> and <csid> are present. the <scheme> and <csid> are present.
Realm Realm A collection of calendar user accounts, identified by a string.
A collection of calendar user accounts, identified by a string. The The name of the realm is only used in UPNs. In order to avoid
name of the realm is only used in UPNs. In order to avoid namespace namespace conflict, the realm SHOULD be postfixed with an appropriate
conflict, the realm SHOULD be postfixed with an appropriate DNS DNS domain name. (eg: the foobar realm could be called
domain name. (eg: the foobar realm could be called
foobar.example.com). foobar.example.com).
Relative Calendar Identifier (Relative CalID) Relative Calendar Identifier (Relative CalID) An identifier for an
An identifier for an individual calendar in a calendar store. It is individual calendar in a calendar store. It is unique within a
unique within a calendar store. It is recommended to be globally calendar store. It is recommended to be globally unique. A Relative
unique. A Relative CalID consists of the portion of the "scheme CalID consists of the portion of the "scheme part" of a Qualified
part" of a Qualified CalID following the Calendar Store Identifier. CalID following the Calendar Store Identifier. This is the same as
This is the same as the "URL path" of the "Common Internet Scheme the "URL path" of the "Common Internet Scheme Syntax" portion of a
Syntax" portion of a URL, as defined by [RFC2396]. URL, as defined by [RFC2396].
Remote Store Remote Store A CS which is not on the same platform as the CUA.
A CS which is not on the same platform as the CUA.
Session Identity Session Identity A UPN associated with a CAP session. A session gains
A UPN associated with a CAP session. A session gains an identity an identity after successful authentication. The identity is used in
after successful authentication. The identity is used in
combination with CAR to determine access to data in the CS. combination with CAR to determine access to data in the CS.
Sub-calendars Sub-calendars Calendars that have a "child" hierarchical relationship
Calendars that have a "child" hierarchical relationship with with another calendar, its "parent".
another calendar, its "parent".
User Name Mansour/Dawson/Royer/Taler/Hill
A name which denotes a Calendar User within a realm. This is part Expires: April 2000 7
of a UPN. User Name A name which denotes a Calendar User within a realm. This
is part of a UPN.
User Principal Name (UPN) User Principal Name (UPN) An identifier that denotes a unique CU. A
An identifier that denotes a unique CU. A UPN strongly resembles an UPN strongly resembles an RFC 822 style email address and in some
RFC 822 style email address and in some cases it may be identical cases it may be identical to the email address for the CU. It
to the email address for the CU. It consists of a realm in the form consists of a realm in the form of a DNS domain name and a username.
of a DNS domain name and a username. It may also have an optional It may also have an optional instance. In it's simplest form it looks
instance. In it's simplest form it looks like "user@example.com". like "user@example.com".
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
Mansour/Dawson/Royer 10 Expires February 2000 the CS, and receives an iCalendar object as a response. There are two
Taler/Hill
MIME encapsulated iCalendar object containing a command, sends it to the
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 and a Transport Protocol is used to move iCalendar objects between a CUA
CS. The Application Protocol defines the content and semantics of the and a CS. The Application Protocol defines the content and semantics
iCalendar objects sent between the CUA and the CS. This document defines of the iCalendar objects sent between the CUA and the CS. This
both the Transport Protocol and the Application Protocol. document defines both the Transport Protocol and the Application
Protocol.
In the diagram below, a user uses CUA1 to communicate with CS1 using In the diagram below, a user uses CUA1 to communicate with CS1 using
CAP. The CUA must authenticate the Calendar User (CU) so that access to CAP. The CUA must authenticate the Calendar User (CU) so that access
calendars on CS1 can be controlled. The CUA can then view, create, edit, to calendars on CS1 can be controlled. The CUA can then view, create,
and delete calendars, calendar properties, and calendar components edit, and delete calendars, calendar properties, and calendar
subject to the access rights. components subject to the access rights.
CAP servers support fanout. Fanout allows a CUA to communicate with a CAP servers support fanout. Fanout allows a CUA to 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 play the role of a CUA and use CAP to access CS2; ? CS1 MAY
CS1 MAY be able to play the role of a CUA and use [iRIP] to be able to play the role of a CUA and use [iRIP] to interoperate with
interoperate with the possible iRIP support in CS2; the possible iRIP support in CS2; ? CS1 MUST be able play the role of
CS1 MUST be able play the role of a CUA and use [RFC2447] to a CUA and use [RFC2447] to interoperate with other CUAs. ? Storage
interoperate with other CUAs. Agent
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 |
+---------------------------------+ +---------------------------------+
Note that the fanout feature in CAP is a convenience to the CUA. It is Note that the fanout feature in CAP is a convenience to the CUA. It
perfectly valid for the CUA to assume the responsibility for fanout if is perfectly valid for the CUA to assume the responsibility for
it wishes. That is, [RFC2447] messages could also be sent from CUA1 to fanout if it wishes. That is, [RFC2447] messages could also be sent
CUA2. from CUA1 to CUA2.
2.2 Calendar Store Object Model 2.2 Calendar Store Object Model
The conceptual model for a calendar store is shown below. The calendar
store contains calendars, VTIMEZONEs, VCARs, and calendar store The conceptual model for a calendar store is shown below. The
properties. calendar store contains calendars, VTIMEZONEs, VCARs, and calendar
store 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-----------------------------+
| | | |
| | | |
Mansour/Dawson/Royer 11 Expires February 2000
Taler/Hill
| VCARs | | VCARs |
| +--calendars-------------------------+ | | +--calendars-------------------------+ |
| Properties | | | | Properties | | |
| | +--calendars--------+ VEVENTs | | | | +--calendars--------+ VEVENTs | |
| VTIMEZONEs | | | VTODOs | | | VTIMEZONEs | | | VTODOs | |
| | | VEVENTs | VJOURNALs | | | | | VEVENTs | VJOURNALs | |
| | | VCARs | VALARMs | | | | | VCARs | VALARMs | |
| | | +---+ VTODOs | VCARs | | | | | +---+ VTODOs | VCARs | |
| | | | | VALARMs | Calendar | | | | | | | VALARMs | Calendar | |
| | | +---+ VJOURNALs | Properties | | | | | +---+ VJOURNALs | Properties | |
skipping to change at line 577 skipping to change at line 516
| | | 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.
In this model, VSCHEDULE is a queue of scheduling messages that have not Mansour/Dawson/Royer/Taler/Hill
yet been applied to the calendar. Items in VSCHEDULE are discussed in Expires: April 2000 9
more detail below. In this model, VSCHEDULE is a queue of scheduling messages that have
not yet been applied to the calendar. Items in VSCHEDULE are
discussed in more detail below.
2.3 Protocol Model 2.3 Protocol Model
A generic transport, Calendar Server Transport Protocol (CSTP), is used
to move data objects between a CUA and the CS. CSTP commands are listed A generic transport, Calendar Server Transport Protocol (CSTP), is
below and their usage and semantics are defined in section 7 of this used to move data objects between a CUA and the CS. CSTP commands are
document. listed below and their usage and semantics are defined in section 7
of this document.
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 calendar Application-level commands are used to manipulate data on the
store. They are listed below and discussed in detail in section 7. calendar store. They are listed below and discussed in detail in
section 7.
CAP Calendaring Commands CAP Calendaring Commands
----------------------------------------------------------------------- -----------------------------------------------------------------------
Command Description Command Description
------------ -------------------------------------------------------- ------------ --------------------------------------------------------
CREATE Create a new calendar or component CREATE Create a new calendar or component
Mansour/Dawson/Royer 12 Expires February 2000
Taler/Hill
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 or more calendars
REQUEST schedule a calendar entry with one or more calendars REQUEST schedule a calendar entry with one or more calendars
REPLY response to a scheduling request REPLY response to a scheduling request
ADD add one or more instances to an existing calendar entry ADD add one or more instances to an existing calendar entry
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 10
CANCEL cancel one or more instances to an existing calendar CANCEL cancel one or more instances to an existing calendar
entry entry
REFRESH a request for the latest version of a calendar entry REFRESH a request for the latest version of a calendar entry
COUNTER a request for a change (a counter-proposal) to a COUNTER a request for a change (a counter-proposal) to a
calendar entry calendar entry
DECLINECOUNTER decline a counter proposal DECLINECOUNTER decline a counter proposal
2.4 Roles 2.4 Roles
CAP defines methods for managing [RFC2445] objects on a Calendar Store
and exchanging [RFC2445] objects for the purposes of group calendaring CAP defines methods for managing [RFC2445] objects on a Calendar
and scheduling between "Calendar Users" (CUs). There are two distinct Store and exchanging [RFC2445] objects for the purposes of group
roles taken on by CUs in CAP. The CU who creates an initial event or to- calendaring and scheduling between "Calendar Users" (CUs). There are
do and invites other CUs as attendees takes on the role of "Organizer". two distinct roles taken on by CUs in CAP. The CU who creates an
The CUs asked to participate in the group event or to-do take on the initial event or to-do and invites other CUs as attendees takes on
role of "Attendee". Note that "role" is also a descriptive parameter to the role of "Organizer". The CUs asked to participate in the group
the "ATTENDEE" property. Its use is to convey descriptive context to an event or to-do take on the role of "Attendee". Note that "role" is
"Attendee" such as "chair", "REQ-PARTICIPANT" or NON-PARTICIPANT" and also a descriptive parameter to the "ATTENDEE" property. Its use is
has nothing to do with the scheduling workflow. 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 2.5 Calendar User
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.
Examples: Examples:
user@example.com user@example.com
user/cap@example.com user/cap@example.com
The UPN representation is independent of the authentication mechanism The UPN representation is independent of the authentication mechanism
used during a particular CUA / CS interaction. A CU may use one used during a particular CUA / CS interaction. A CU may use one
skipping to change at line 656 skipping to change at line 602
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.
Examples: Examples:
user@example.com user@example.com
user/cap@example.com user/cap@example.com
The UPN representation is independent of the authentication mechanism The UPN representation is independent of the authentication mechanism
used during a particular CUA / CS interaction. A CU may use one 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 mechanism while using one CUA but the same user may use a different
authentication mechanism when using a different CUA, or while connecting authentication mechanism when using a different CUA, or while
from a different location. connecting from a different location.
For Calendaring and Scheduling systems that are integrated with a For Calendaring and Scheduling systems that are integrated with a
directory system the UPN SHOULD be stored in the attribute [TBD] with directory system the UPN SHOULD be stored in the attribute [TBD] with
OID [TBD]. This enables a clear mapping between a UPN and a OID [TBD]. This enables a clear mapping between a UPN and a
Distinguished Name. [note: Microsoft's Active Directory is storing UPNs Distinguished Name. [note: Microsoft's Active Directory is storing
UPNs as the userPrincipalName.] Within a directory service a UPN is a
Mansour/Dawson/Royer 13 Expires February 2000 single valued property.
Taler/Hill
as the userPrincipalName.] Within a directory service a UPN is a single
valued property.
2.5.1 UPNs and Certificates 2.5.1 UPNs and Certificates
When using certificates for purposes of CAP authentication, the When using certificates for purposes of CAP authentication, the
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 11
SubjectName field of the user's certificate SHOULD contain the user's SubjectName field of the user's certificate SHOULD contain the user's
UPN (for example, "juser@example.com") as the value of the "CN=" 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 component, and the user's email address (often the same as the UPN)
the value of the "E=" component . The altSubjectName will contain the DN as the value of the "E=" component . The altSubjectName will contain
of the user's account object in the DS. The Issuer field must be that of the DN of the user's account object in the DS. The Issuer field must
a root CA trusted to issue login certificates, or the DN of a lower be that of a root CA trusted to issue login certificates, or the DN
level CA whose certificate includes an "AuthorizedNamingContext" field of a lower level CA whose certificate includes an
that authorizes it to issue certificates for "example.com" (exact field "AuthorizedNamingContext" field that authorizes it to issue
name and validation mechanism TBD). certificates for "example.com" (exact field name and validation
mechanism TBD).
Note: If a server is validating data received via iMIP, if the Note: If a server is validating data received via iMIP, if the
"ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe Random "ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe
User:juser@example.com" then the "juser@example.com" part should be Random User:juser@example.com" then the "juser@example.com" part
checked against the altSubjectName field of the certificate, and the should be checked against the altSubjectName field of the
"Joe Random User" part should be checked against the CN component of the certificate, and the "Joe Random User" part should be checked against
altSubjectName DN. This is so the "ATTENDEE" property couldn't be munged the CN component of the altSubjectName DN. This is so the "ATTENDEE"
to something misleading like "ATTENDEE;CN=Joe Rictus property couldn't be munged to something misleading like
User:juser@example.com" and have it pass validation. This validation "ATTENDEE;CN=Joe Rictus User:juser@example.com" and have it pass
will also defeat other attempts at confusion. validation. This validation will also defeat other attempts at
confusion.
2.5.2 CAP session identity 2.5.2 CAP session identity
A CAP session has an assocatied set of authentication credentials, from A CAP session has an assocatied set of authentication credentials,
which is derived a UPN. This UPN is the identity of the CAP session, and from which is derived a UPN. This UPN is the identity of the CAP
is used to determine access rights for the session. session, and is used to determine access rights for the session.
The CUA may change the identity of a CAP session by calling the The CUA may change the identity of a CAP session by calling the
"IDENTIFY" command. The Calendar Service only permits the operation if "IDENTIFY" command. The Calendar Service only permits the operation
the session's authentication credentials are good for the requested if the session's authentication credentials are good for the
identity. The method of checking this permission is implementation requested identity. The method of checking this permission is
dependant, but may be thought of as a mapping from authentication implementation dependant, but may be thought of as a mapping from
credentials to UPNs. The "IDENTIFY" command allows a single set of authentication credentials to UPNs. The "IDENTIFY" command allows a
authentication credentials to choose from multiple identities, and single set of authentication credentials to choose from multiple
allows multiple sets of authentication credentials to assume the same identities, and allows multiple sets of authentication credentials to
identity. assume the same identity.
For anonymous access the identity of the session is "@", a UPN with a For anonymous access the identity of the session is "@", a UPN with a
null username and null realm. A UPN with a null username, but non-null null username and null realm. A UPN with a null username, but non-
realm, such as "@foo.com" may be used to mean any identity from that null realm, such as "@foo.com" may be used to mean any identity from
realm, which is useful to grant access rights to all users in a given that realm, which is useful to grant access rights to all users in a
realm. A UPN with a non-null username and null realm, such as "bob@" given realm. A UPN with a non-null username and null realm, such as
could be a security risk and must not be used. "bob@" could be a security risk and must not be used.
Since the UPN includes realm information it may be used to govern Since the UPN includes realm information it may be used to govern
calendar store access rights across realms. However, governing access calendar store access rights across realms. However, governing access
rights across realms is only useful if login access is available. This
Mansour/Dawson/Royer 14 Expires February 2000 Mansour/Dawson/Royer/Taler/Hill
Taler/Hill Expires: April 2000 12
rights across realms is only useful if login access is available.
could be done through a trusted server relationship or a temporary This could be done through a trusted server relationship or a
account. temporary account.
The "IDENTIFY" command provides for a weak group implementation. By The "IDENTIFY" command provides for a weak group implementation. By
allowing multiple sets of authentication credentials belonging to allowing multiple sets of authentication credentials belonging to
different users to identify as the same UPN, that UPN essentially different users to identify as the same UPN, that UPN essentially
identifies a group of people, and may be used for group calendar identifies a group of people, and may be used for group calendar
ownership, or the granting of access rights to a group. ownership, or the granting of access rights to a group.
2.6 Calendar Addresses 2.6 Calendar Addresses
Calendar addresses are URIs that are modeled after [RFC2396]. CAP uses Calendar addresses are URIs that are modeled after [RFC2396]. CAP
the following forms of URI. uses the following forms of URI.
[[<scheme>]://<csid>[:<port>]/]<relativeCALID> [[<scheme>]://<csid>[:<port>]/]<relativeCALID>
where: where:
<scheme> is "cap" ? <scheme> is "cap" ? <csid> is the Calendar Store ID. It is the
<csid> is the Calendar Store ID. It is the network address of the network address of the computer on which the CAP server is running ?
computer on which the CAP server is running
<port> is optional. Its default value is 5229. The port must be <port> is optional. Its default value is 5229. The port must be
present if the CAP server does not listen on the default port. present if the CAP server does not listen on the default port. ?
<relativeCALID> is an identifier that uniquely identifies the <relativeCALID> is an identifier that uniquely identifies the
calendar on a particular calendar store. There is no implied calendar on a particular calendar store. There is no implied
structure in a Relative CALID. It is an arbitrary string of 7 bit 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 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 resource such as a conference room. It MUST be unique within the
calendar store. It is recommended that the Relative CALID be calendar store. It is recommended that the Relative CALID be globally
globally unique. unique.
If the <scheme> and <csid> are present the calendar address is said to If the <scheme> and <csid> are present the calendar address is said
be "qualified". Senders are required to supply the <relativeCALID> to be "qualified". Senders are required to supply the <relativeCALID>
portion of the address. A qualified calendar address is required when portion of the address. A qualified calendar address is required when
the <csid> of the target calendar address differs from that of the CAP the <csid> of the target calendar address differs from that of the
server receiving the command. CAP server receiving the command.
Examples: Examples:
cap://calendar.example.com/user1 cap://calendar.example.com/user1
://calendar.example.com/user1 ://calendar.example.com/user1
user1 user1
cap://calendar.example.com/conferenceRoomA cap://calendar.example.com/conferenceRoomA
cap://calendar.example.com/89798-098-zytytasd cap://calendar.example.com/89798-098-zytytasd
For a user currently authenticated to a CAP server on For a user currently authenticated to a CAP server on
calendar.example.com, the first three addresses refer to the same calendar.example.com, the first three addresses refer to the same
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 13
calendar. calendar.
2.7 Finding CAP Servers 2.7 Finding CAP Servers
Using DNS
Using SLP
Request-Status _ optional text (second field)
Mansour/Dawson/Royer 15 Expires February 2000 2.7.1 Using DNS
Taler/Hill
<TBD>
2.7.2 Using SLP
This section assumes that the reader is familiar with RFC2608 and
RFC2609. The Service Location Protocol (SLP) as defined in [RFC2608]:
"The Service Location Protocol provides a scalable framework for
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
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>
Language of service template: en
Security Considerations: <TBD>
Template Text:
------------------------template begins here-------------------
template-type=Calendar-Access-Protocol
# The version will be updated to 1.0 as CAP becomes an RFC.
template-version=0.0
template-description=
The Calendar-Access-Protocol service provides the location
of iCalendar services.
# Services can be located or defined with one or more
# of the following parameters:
#
# <port> Port number CAP service is listening to.
#
# <calendar> Find calendar by calendar name.
Mansour/Dawson/Royer/Taler/Hill
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.
url-port = "ports=" ports-list
ports-list = port / port "," ports-list
port = 1*DIGIT
# The CalID for the calendar.
url-calendar = "CalID=" calid-list
calid-list = CalID / CalID "," CalID
# A user associated with a calendar user.
url-user = "user=" user-list
user-list = user / user "," user-list
user = # A CU as defined by
# the CS implementation,
# Which URL-scheme's are supported by the CS:
url-scheme = "scheme=" scheme-list
scheme-list = scheme / scheme "," scheme-list
scheme = CAP # Only CAP supported at
# this time.
# Names of calendars associated with an email address.
url-email = "mailto=" email-list
email-list = email / email "," email-list
email = # An RFC822 email address
# Names of calendars associated with a UPN.
url-upn = "mailto=" upn-list
upn-list = upn / upn "," upn-list
upn = # An RFC822 upn address
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 15
-------------------------template ends here---------------------
Example of SLP advertisement:
URL =
service:Calendar-Access-Protocol://cal.example.com/ports=1234
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,
"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 2.8 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 components the iCalendar format, several extended iCalendar methods and
are defined by this memo. components 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 of VQUERY, that contains the search filter. The component consists
a set of new properties: SCOPE, MAXRESULTS, MAXRESULTSSIZE, QUERY of a set of new properties: SCOPE, MAXRESULTS, MAXRESULTSSIZE,
and QUERYNAME, that define the search filter. QUERY and QUERYNAME, that define the search filter.
Access control is specified the the new iCalendar VCAR component.
The iCalendar METHOD property format has been updated with new * Access control is specified the the new iCalendar VCAR
component.
* The iCalendar METHOD property format has been updated with new
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 16
values. values.
A new iCalendar component, VCOMMAND, has been added. VCOMMANDs are
needed to fully specify CAP commands. * A new iCalendar component, VCOMMAND, has been added. VCOMMANDs
TARGET is a new property within the VCOMMAND component. It are needed to fully specify CAP commands.
indicates a
* TARGET is a new property within the VCOMMAND component. It
indicates the calendars to which the command applies
2.9 Relationship of RFC 2446 (ITIP) to CAP 2.9 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, manipuation 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 conceptual This is modeled with the VSCHEDULE queue. Note that this is a
model, the actual storage details are left to implementations. The model conceptual model, the actual storage details are left to
is shown pictorially as follows: implementations. The model is shown pictorially as follows:
+-----------------VCALENDAR-------------------+ +-----------------VCALENDAR-------------------+
| | | |
| +-----------+ +-------VSCHEDULE---------+ | | +-----------+ +-------VSCHEDULE---------+ |
| | VEVENTs | | PUBLISH messages | | | | VEVENTs | | PUBLISH messages | |
| | VTODOs | | REQUEST messages | | | | VTODOs | | REQUEST messages | |
| | VJOURNALs | | REPLY messages | | | | VJOURNALs | | REPLY messages | |
| | | | ADD messages | | | | | | ADD messages | |
| | | | CANCEL messages | | | | | | CANCEL messages | |
| | | | REFRESH messages | | | | | | REFRESH messages | |
| | | | COUNTER messages | | | | | | COUNTER messages | |
| | | | DECLINECOUNTER messages | | | | | | DECLINECOUNTER messages | |
| +-----------+ +-------------------------+ | | +-----------+ +-------------------------+ |
+---------------------------------------------+ +---------------------------------------------+
The METHOD is saved along with components. Scheduled components become The METHOD is saved along with components. Scheduled components
booked components when the METHOD changes from an ITIP method to the CAP become booked components when the METHOD changes from an ITIP method
storage method. For example, a component whose METHOD is "REQUEST" is to the CAP storage method. For example, a component whose METHOD is
scheduled. The component becomes booked when the METHOD is changed to "REQUEST" is scheduled. The component becomes booked when the METHOD
"CREATED". is changed to "CREATED".
[ed note: need to clean up the terminology here. We haven't discussed [ed note: need to clean up the terminology here. We havent discussed
"booked"] "booked"]
2.10 VCalendar Access Rights (VCARs) 2.10 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 Calendar User. Specifically, they grant User Principal Names
Mansour/Dawson/Royer 16 Expires February 2000
Taler/Hill
(UPNs) the rights to read and write components, properties, and (UPNs) the rights to read and write components, properties, and
parameters on calendars within a calendar store. parameters on 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 with object and access rights are created. That is, an event associated
a particular VCAR might be created before or after the actual VCAR is with a particular VCAR might be created before or after the actual
defined. In addition, the VCAR and VEVENT definition might be created in VCAR is defined. In addition, the VCAR and VEVENT definition might be
the same iCalendar object and passed together in a single SENDDATA created in the same iCalendar object and passed together in a single
command. SENDDATA command.
2.11 Query Schema 2.11 Query Schema
3. State Diagram 3. State Diagram
This section describes the states of the transport connection between a
CUA and a CS. The state diagram is shown below. State names shown with
first letter capitalized. The commands used to switch between states are
shown next to an arrow connecting the states. The commands are listed in
all capital letters. A condition that causes a state to change is shown
in lower case letters.
CAPABILITY +-----+ This section describes the states of the transport connection between
+-------+ | | CAPABILITY a CUA and a CS. The state diagram is shown below. State names shown
| | +---------------+ | with first letter capitalized. The commands used to switch between
| +-----------+ AUTHENTICATE | |<-+ states are shown next to an arrow connecting the states. The commands
+-->| Connected |-------------->| Authenticated |<----+ are listed in all capital letters. A condition that causes a state to
+-----------+ +--------| | | change is shown in lower case letters.
STARTTLS /
CAPABILITY
+-------+
| | +---------------+
| +-----------+ AUTHENTICATE | |
+-->| Connected |-------------->| Authenticated |
+-----------+ | |
| +---------------+
| |
| |
| |
| | +-----+ STARTTLS /
| V | | CAPABILITY /
| +---------------+ | IDENTIFY
| | |<-+
| | Identified |<----+
| +--------| | |
| | +---------------+ | command | | +---------------+ | command
|DISCONNECT | | | 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 the server. The capabilities of the CS are reported in the response from
CS. From this state, the CUA can issue the DISCONNECT command to the CS. From this state, the CUA can issue the DISCONNECT command to
terminate the connection, the CAPABILITY command, or the AUTHENTICATE terminate the connection, the CAPABILITY, STARTTLS, or AUTHENTICATE
command to authenticate a Calendar User. The capabilities of the CS in commands. One use of the CAPABILITY command at this stage is to
the authenticated state are returned in the response from the CS. One determine the supported authentication mechanisms supported by the
use of the CAPABILITY command at this stage is to determine the server. Once the STARTTLS command has been successfully executed from
supported authentication mechanisms supported by the server. either the Connected or Authenticated state, it must not be executed
again.
If an AUTHENTICATE command is successful, the connection enters the If an AUTHENTICATE command is successful, the connection enters the
Authenticated state. From here the CUA can issue the CAPABILITY command. Authenticated state and then immediately goes to the IDENTIFIED state.
From here the CUA can issue the CAPABILITY command. The capabilities
Mansour/Dawson/Royer 17 Expires February 2000 the server offers in the Authenticated state may be different than
Taler/Hill those in the Connected state. The CUA can also use the IDENTIFY command
to change the identity of the user subject to access control. The
The capabilities the server offers in the Authenticated state may be connection remains in the Authenticated state after the CAPABILITY
different than those in the Connected state. The connection remains in command completes. The CUA can issue the DISCONNECT command to
the Authenticated state after the CAPABILITY command completes. The CUA terminate the connection. The SENDDATA command can be used to send a
can issue the DISCONNECT command to terminate the connection. The request to read, write, modify, or delete data on the server.
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 the issued the SENDATA command with a maximum latency time. This informs
server that the CUA expects a response within the maximum latency time, the server that the CUA expects a response within the maximum latency
even if the command was not completed. When the server is unable to time, even if the command was not completed. When the server is unable
complete the command in the maximum latency time, it issues an to complete the command in the maximum latency time, it issues an
appropriate reply code and waits for the CUA to tell it how to proceed. appropriate reply code and waits for the CUA to tell it how to proceed.
If the CUA issues a CONTINUE command the server continues processing the If the CUA issues a CONTINUE command the server continues processing
command and the connection remains in the Receive state. If the CUA the command and the connection remains in the Receive state. If the CUA
issues the ABORT command the server need not process the command any 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 Transport Layer
The CAP transport layer handles the transmission of CAP application The CAP transport layer handles the transmission of CAP application
layer messages. layer messages.
CAP transport layer commands are transmitted across the underlying CAP transport layer commands are transmitted across 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 CS listens for connections on port <xyz>.
Messages sent between the CUA and CS are formatted as a command followed Messages sent between the CUA and CS are formatted as a command
by any associated data: followed by any associated data:
<command> [<command data>] <command> [<command data>]
4.3 Response Format 4.3 Response Format
Server responses consist of a response code and any parameters: Server responses consist of a response code and any parameters:
<response code> [; debug text ; more text] <response code> [; debug text ; more text]
[<CRLF><application-data>]<CRLF>.CRLF> [<CRLF><application-data>]<CRLF>.CRLF>
Mansour/Dawson/Royer 18 Expires February 2000
Taler/Hill
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.
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 <CRLF> The response is terminated with a <CRLF> "." <CRLF> sequence. Any
"." sequences which appear in the transmitted data must be quoted by <CRLF> "." sequences which appear in the transmitted data must be
placing an additional "." between the <CRLF> and the ".". For example, quoted by placing an additional "." between the <CRLF> and the ".". For
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:
..
...2
....3
No other tagged command sequence can be sent until the special No other tagged command sequence can be sent until the 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 <pick a number: 30> minutes duration. The receipt of ANY at least 15 minutes duration. The receipt of ANY command from the
command from the client during that interval MUST suffice to reset the client during that interval MUST suffice to reset the auto-logout
auto-logout timer. timer.
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 time. that the request could not be completed in the requested amount of
When the CUA initiates a command that the server cannot complete within time. When the CUA initiates a command that the server cannot complete
the specified latency time, the server returns an appropriate response within the specified latency time, the server returns an appropriate
code. The CUA then issues either a CONTINUE or ABORT command. The ABORT response code. The CUA then issues either a CONTINUE or ABORT command.
command immediately terminates the command in progress and the The ABORT command immediately terminates the command in progress and
connection returns to the Authenticated state. The CONTINUE command the 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 4.6 Data Elements
The data elements for CAP are MIME encapsulated iCalendar objects.
Mansour/Dawson/Royer 19 Expires February 2000 The data elements for CAP are MIME encapsulated iCalendar objects.
Taler/Hill
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.
skipping to change at line 1012 skipping to change at line 1099
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 we're using [Editor's note: We need to precisely define what part of SQL were
and why we chose what we did.] using 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 on Grant someone access to events during the month of June. (i.e., based
the current system date, if it's prior to June or after June you don't on the current system date, if it's prior to June or after June you
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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 21
*scope Grant, Deny of a VCAR *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)*
skipping to change at line 1053 skipping to change at line 1143
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 = select where orderby ...
select = <any valid SQL string that goes into a SELECT clause> select = <any valid SQL string that goes into a SELECT clause>
Mansour/Dawson/Royer 20 Expires February 2000
Taler/Hill
where = <any valid SQL string that goes into a WHERE clause> where = <any valid SQL string that goes into a WHERE clause>
orderby = <any valid SQL string that goes into a ORDERBY orderby = <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 an iCalendar object are unordered. This also is the
case for the "GRANT", "DENY" and "CARID" properties. Likewise, there is case for the "GRANT", "DENY" and "CARID" properties. Likewise, there
no implied ordering required for components of a "RIGHTS" value type is no implied ordering required for components of a "RIGHTS" value
other than that specified by the ABNF. 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 calendar default calendar access rights for any calendar in the parent
store. Likewise, any calendar access rights specified in a root calendar calendar store. Likewise, any calendar access rights specified in a
are inherited as default calendar access rights for any sub-calendar to root calendar are inherited as default calendar access rights for any
the root calendar. By implication, calendar access rights specified in a sub- calendar to the root calendar. By implication, calendar access
sub-calendar are inherited as default calendar access rights for any rights specified in a sub-calendar are inherited as default calendar
calendars that are hierarchically below the sub-calendar. access rights for any calendars that are hierarchically below the
sub- calendar.
Calendar access rights specified in a calendar override any default Calendar access rights specified in a calendar override any default
calendar access rights. Calendar access rights specified within a sub- calendar access rights. Calendar access rights specified within a
calendar override any default calendar access rights. sub- calendar override any default calendar access rights.
6.2 Access Control and NOCONFLICT
The TRANSP property can take on values (TRANSPARENT-NOCONFLICT,
OPAQUE- NOCONFLICT) that prohibit other events from overlapping it.
This setting overrides access While access control may allow a UPN to
store an event on a particular calendar. , the CONFLICTS Calendar or
component setting may prevent it, returning an error code "6.3"
7. 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 these response descriptions in the Responses section for information on
responses, and the Formal Syntax section for the precise syntax of these these responses, and the Formal Syntax section for the precise syntax
responses. of these responses.
The "Result:" in the command description refers to the possible status
responses to a command, and any special interpretation of these status
responses.
Mansour/Dawson/Royer 21 Expires February 2000 The "Result:" in the command description refers to the possible
Taler/Hill status responses to a command, and any special interpretation of
these status responses.
Commands have the general form: Commands have the general form:
<command> [arguments...] <command> [arguments...]
where <command> is a command listed in the table above. A command MAY where <command> is a command listed in the table above. A 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]] responseCode [sep transportDescr sep [applicationDescr]] CRLF "."
CRLF "." CRLF CRLF
In the examples below, lines preceded with "S:" refer to the sender and In the examples below, lines preceded with "S:" refer to the sender
lines preceded with "R:" refer to the receiver. Lines in which the first and lines preceded with "R:" refer to the receiver. Lines in which
non-whitespace character is a "#" are editorial comments and are not the first non-whitespace character is a "#" are editorial comments
part of the protocol. and are not part of the protocol.
7.1 Transport Protocol Commands 7.1 Transport Protocol Commands
7.1.1 Initial Connection 7.1.1 Initial Connection
Arguments: none Arguments: none
Data: noneResult: 2.0 _ success.
8.1 _ server too busy Data: none
Result: 2.0 - success.
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 that it is ready to receive commands. A response of 8.1 indicates
the server is too busy to accept the connection. In addition, the that the server is too busy to accept the connection. In addition,
general capabilities of the CS are reported in the response from the CS. the general capabilities of the CS are reported in the response from
These capabilities may be different than those reported in the the CS. These capabilities may be different than those reported in
authenticated state. 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 progres
The ABORT command is issued by the CUA to stop a command whoselatency The ABORT command is issued by the CUA to stop a command whose
time has been exceeded. When the latency time is specified onthe SENDATA
command, the CS must issue a reply to the CUA
within the specified time. It may be a reply code indicating
that the CS has not yet processed the request. The CUA must
then tell the server whether to continue or abort.
Mansour/Dawson/Royer 22 Expires February 2000 Mansour/Dawson/Royer/Taler/Hill
Taler/Hill Expires: April 2000 24
latency time has been exceeded. When the latency time is specified on
the SENDATA command, the CS must issue a reply to the CUA within the
specified time. It may be a reply code indicating that the CS has not
yet processed the request. The CUA must then tell the server whether
to continue or abort.
The CUA can issue the ABORT command at any time after the SENDATA 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: 2.0 - Authenticate completed, now in authenticated state
6.0 - Failed authentication 6.0 - Failed authentication
6.1 - Authorization identity refused. 6.1 - Authorization identity refused.
6.2 - Sender aborted authentication, authentication 6.2 - Sender aborted authentication, authentication
exchange cancelled exchange cancelled
6.3 - Unsupported Authentication Mechanism 6.3 - Unsupported Authentication Mechanism
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 capabilities the response from the CS. These may be different than the
in the Connected, but unauthenticated state. capabilities in the Connected, but unauthenticated state.
The AUTHENTICATE command is used by the CUA to identify the user to the The AUTHENTICATE command is used by the CUA to identify the user to
CS. CAP uses the [SASL] specification for authentication. The desired the CS. CAP uses the [SASL] specification for authentication. The
SASL mechanism is specified as the initial argument. desired SASL mechanism is specified as the initial argument.
<SASL mechanism name> is a registered SASL authentication mechanism. <SASL mechanism name> is a registered SASL authentication mechanism.
(Refer to [SASL] for information on obtaining a list of currently (Refer to [SASL] for information on obtaining a list of currently
registered mechanisms.) CS Supported authentication mechanisms can be registered mechanisms.) CS Supported authentication mechanisms can be
discovered using the CAPABILITY command. All implementations MUST discovered using the CAPABILITY command. All implementations MUST
support Digest-MD5 authentication using DES and 3DES, as well as DES-56 support Digest-MD5 authentication using DES and 3DES, as well as
for link level encryption. Implementations MUST support the SASL DES-56 for link level encryption. Implementations MUST support the
Anonymous mechanism, although this may be disabled in installations. SASL Anonymous mechanism, although this may be disabled in
Implementations SHOULD implement the External SASL mechanism and the installations. Implementations SHOULD implement the External SASL
command STARTTLS. mechanism and the command STARTTLS.
<initial data> is an optional parameter which can be used for mechanisms <initial data> is an optional parameter which can be used for
which require an initial response from the CUA. mechanisms which require an initial response from the CUA.
The AUTHENTICATE command is followed by an authentication protocol The AUTHENTICATE command is followed by an authentication protocol
exchange, in the form of a series of CS challenges and CUA responses. exchange, in the form of a series of CS challenges and CUA responses.
These challenges and responses are encoded in Base64 and transmitted These challenges and responses are encoded in Base64 and transmitted
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 25
with a terminating CRLF. The CS terminates the exchange with a "." with a terminating CRLF. The CS terminates the exchange with a "."
<CRLF> sequence followed by a reply code. ("." is not a legal Base64 <CRLF> sequence followed by a reply code. ("." is not a legal Base64
character.) Possible reply codes are listed above. character.) Possible reply codes are listed above.
CAP does not provide support for SASL authorization identities. If a CUA CAP does not provide support for SASL authorization identities. If a
attempts to use an authorization identity the Calendar Service must CUA attempts to use an authorization identity the Calendar Service
return the reply code indicating that the authorization identity was must return the reply code indicating that the authorization identity
refused. was refused.
Mansour/Dawson/Royer 23 Expires February 2000
Taler/Hill
If the CUA wishes to cancel an authentication exchange it may do so by If the CUA wishes to cancel an authentication exchange it may do so
issuing a "." <CRLF> sequence. Upon receipt of such a sequence the CS by issuing a "." <CRLF> sequence. Upon receipt of such a sequence the
MUST terminate the exchange and return the appropriate reply code. CS MUST terminate the exchange and return the appropriate reply code.
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 follows starting with the first octet transmitted after the CRLF which
the 2.0 reply code, and for the CUA starting with the first octet after follows the 2.0 reply code, and for the CUA starting with the first
the CRLF of its last response in the authentication exchange. Encrypted octet after the CRLF of its last response in the authentication
data is transmitted as described in [SASL]. exchange. Encrypted 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".
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.
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
"AUTHENTCATE" command. "AUTHENTCATE" command.
The CUA may not issue the "AUTHENTCATE" command multiple times, even if The CUA may not issue the "AUTHENTCATE" command multiple times, even
the first attempt was aborted. If a CUA attempts to do this the CS must if the first attempt was aborted. If a CUA attempts to do this the CS
terminate the session. must terminate the session.
Data returned in response to a successful logon is: Data returned in response to a successful logon is:
Client implementations SHOULD NOT require any capability name beyond
those defined in this specification, and MAY ignore any non-standard,
experimental capability names. Non-standard capability names are
prefixed with the text "X-". The prefix SHOULD also include a short
character vendor identifier For example, "X-FOO-BARCAPABILITY", for the
non-standard "BARCAPABILITY" capability of the implementor "FOO". This
command may return different results in the Connected state versus the
Authenticated state. It may also return different results depending on
the UPN.
Capability Occurs Description
--------------------- ------- ----------------------------------
CAPrev1 1 Revision of CAP, must be
"CAPrev1"
IRIPrev1 0 or 1 Revision of IRIP, MAY be present.
If present, it MUST be "IRIPrev1"
CAR 0 or 1 Indicates level of CAR support CAR0,
CAR1, CAR2, CAR3
MAXICALOBJECTSIZE 0 or 1 An integer value that specifies
The largest ICAL object the server
will accept. Objects larger than
this will be rejected.
MAXDATE 0 or 1 The datetime value beyond which
Mansour/Dawson/Royer 24 Expires February 2000
Taler/Hill
the server cannot accept.
MINDATE 0 or 1 The datetime value prior to which
the server cannot accept.
The following examples illustrate the various possiblities for an The following examples illustrate the various possiblities 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 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: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: PRODID:-//ACME/CAPserver//EN S: PRODID:-//ACME/CAPserver//EN
S: VERSION:2.1 S: VERSION:2.1
S: IDENTITY=bill@example.com S: IDENTITY=bill@example.com
S: CAPVERSION=1.0 S: CAPVERSION=1.0
S: ITIPVERSION=1.0 S: ITIPVERSION=1.0
S: AUTH=KERBEROS_V4 S: AUTH=KERBEROS_V4
S: AUTH=DIGEST_MD5 S: AUTH=DIGEST_MD5
skipping to change at line 1326 skipping to change at line 1401
S: AUTH=KERBEROS_V4 S: AUTH=KERBEROS_V4
S: AUTH=DIGEST_MD5 S: AUTH=DIGEST_MD5
S: CAR=CAR1 S: CAR=CAR1
S: MINDATE=19700101T000000Z S: MINDATE=19700101T000000Z
S: MAXDATE=20370201T000000Z S: MAXDATE=20370201T000000Z
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
This example shows a failed authentication: This example shows a failed authentication:
Mansour/Dawson/Royer 25 Expires February 2000
Taler/Hill
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
7.1.4 CONTINUE Command 7.1.4 CAPABILITY Command
Arguments: none
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 27
Data: none
Result: capabilities as described below
The CAPABILTY command returns information about the CAP server given
the current state of the connection with the client. The values
returned may differ depending on whether the connection is in the
Connected or the Authenticated state. The return values may also be
different for a secure versus a non-secure connection.
Client implementations SHOULD NOT require any capability name beyond
those defined in this specification, and MAY ignore any non-standard,
experimental capability names. Non-standard capability names are
prefixed with the text "X-". The prefix SHOULD also include a short
character vendor identifier For example, "X-FOO-BARCAPABILITY", for
the non-standard "BARCAPABILITY" capability of the implementor "FOO".
This command may return different results in the Connected state
versus the Authenticated state. It may also return different results
depending on the UPN.
Capability Occurs Description
--------------------- ------- ----------------------------------
CAPrev1 1 Revision of CAP, must be
"CAPrev1"
IRIPrev1 0 or 1 Revision of IRIP, MAY be present.
If present, it MUST be "IRIPrev1"
CAR 0 or 1 Indicates level of CAR support CAR0,
CAR1, CAR2, CAR3
MAXICALOBJECTSIZE 0 or 1 An integer value that specifies
The largest ICAL object the server
will accept. Objects larger than
this will be rejected.
MAXDATE 0 or 1 The datetime value beyond which
the server cannot accept.
MINDATE 0 or 1 The datetime value prior to which
the server cannot accept.
Example:
C: CAPABILTIY
S: 2.0
S: CAPVERSION=1.0
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 28
S: ITIPVERSION=1.0
S: AUTH=KERBEROS_V4
S: AUTH=DIGEST_MD5
S: .
7.1.5 CONTINUE Command
Arguments: latency time in seconds (optional) Arguments: latency time in seconds (optional)
Data: noneResult: results from the command in progress
2.0.2 _ reply pending. Data: none
Result: results from the command in progress
2.0.2 - reply pending.
The CONTINUE command is issued by the client in response to a SENDATA The CONTINUE command is issued by the client in response to a SENDATA
timeout. When a timeout value is specified on the SENDDATA command, the timeout. When a timeout value is specified on the SENDDATA command,
server must issue a reply to the client within the specified time. If the server must issue a reply to the client within the specified
the latency time has elapsed prior to the server completing the command time. If the latency time has elapsed prior to the server completing
it returns a timeout response code. If the client wants the server to the command it returns a timeout response code. If the client wants
continue processing the command it responds with the CONTINUE command. the server to continue processing the command it responds with the
CONTINUE command.
If latencyTime is present, it must be a positive integer that specifies If latencyTime is present, it must be a positive integer that
the maximum number of seconds the client will wait for the next specifies the maximum number of seconds the client will wait for the
response. If it is omitted, the receiver waits an indefinite period of next response. If it is omitted, the receiver waits an indefinite
time for the response. period of time for the response.
In this example, the client requests a response from the server every 10 In this example, the client requests a response from the server every
seconds. 10 seconds.
...
C: SENDDATA:10 C: SENDDATA:10
C: Content-Type:text/calendar; method=READ; component=VEVENT C: Content-Type:text/calendar; method=READ; component=VEVENT
C: C:
C: BEGIN: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
C: CONTINUE:10 C: CONTINUE:10
S: 2.0 S: 2.0
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: .
Mansour/Dawson/Royer 26 Expires February 2000 7.1.6 DISCONNECT Command
Taler/Hill
7.1.5 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. It
always succeeds. The DISCONNECT command is used by a client to terminate a connection.
It always succeeds.
Example: Example:
C: DISCONNECT C: DISCONNECT
# [ed. Note: should the client now wait for a response from the server # [ed. Note: should the client now wait for a response from the
# before disconnecting? ]S: 2.0 server
# before disconnecting? ]
S: 2.0
C: <drops connection> C: <drops connection>
S: <drops connection> S: <drops connection>
7.1.6 IDENTIFY Command 7.1.7 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
Authenticated 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 a identity. If they do the session assumes the new identity, otherwise
security error is returned. a security error is returned.
7.1.7 SENDDATA Command 7.1.8 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 to The SENDDATA command is used to send calendar requests and commands
the server. After a response code of 2.0.1 is issued the CUA sends a to the server. After a response code of 2.0.1 is issued the CUA sends
MIME encapsulated iCalendar object to the server. The end of this MIME a MIME encapsulated iCalendar object to the server. The end of this
data is signaleled by the special sequence <CRLF>.<CRLF> . MIME data is signaleled by the special sequence <CRLF>.<CRLF> .
7.1.9 STARTTLS Command
7.1.8 STARTTLS Command
Arguments: None Arguments: None
Data: None Data: None
Result: 2.0 Result: 2.0
Mansour/Dawson/Royer 27 Expires February 2000
Taler/Hill
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
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. If an
authentication id was determined during TLS negotiations it MUST NOT be authentication id was determined during TLS negotiations it MUST NOT be
used for the purpose of granting a CAP session identity unless the CUA used for the purpose of granting a CAP session identity unless the CUA
authenticates using the SASL external mechanism. 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 this "AUTHENTICATE" or "STARTTLS" command in this session. If a CUA does
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
7.2 Application Protocol Commands 7.2 Application Protocol Commands
7.2.1 Calendaring Commands 7.2.1 Calendaring Commands
The following methods provide a set of calendaring commands in CAP. The following methods provide a set of calendaring commands 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: objtype
skipping to change at line 1484 skipping to change at line 1630
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: objtype
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.2 - Calendar or 6.1 - Container(s) not found
component already exists 6.2 - Calendar or component already exists
6.3 -
Bad args Bad args
Mansour/Dawson/Royer 28 Expires February 2000
Taler/Hill
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) for objtype. ContainerId1 through ContainerIdn specify the container(s)
the create. When creating a new calendar at the top level, the CSID is for the create. When creating a new calendar at the top level, the
specified. Otherwise the container will be a CalID. 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 several
different containers. In the following example, the client is in the Example to create a new calendar named "Bill's Soccer Team" in
Authenticated state with CS cal.example.com. several different containers. In the following example, the client is
in the 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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 32
C: METHOD:CREATE;VCALENDAR 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
skipping to change at line 1542 skipping to change at line 1692
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 3.1.5 this property must be unique on a CS. That is the reason for the
error response. 3.1.5 error response.
In the example below, the Relative CalID is not specified. So, the CAP
server will generate one for each calendar successfully created. The
Mansour/Dawson/Royer 29 Expires February 2000
Taler/Hill
value of the Relative CalID appears as the second parameter on the In the example below, the Relative CalID is not specified. So, the
response code. CAP server will generate one for each calendar successfully created.
The 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; OPTINFO="CMDID:abcde" S: Content-Type:text/calendar; method=RESPONSE;
OPTINFO="CMDID:abcde"
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
S: CMDID:abcde S: CMDID:abcde
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal1 abcd12345 S: 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
skipping to change at line 1601 skipping to change at line 1750
S: END:VEVENT S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
[Editors Note: this returns the calendar and UID? Is this right? It [Editors Note: this returns the calendar and UID? Is this right? It
could also be UID and RecurrenceID ? what about if the event has an could also be UID and RecurrenceID ? what about if the event has an
RRULE?] RRULE?]
7.2.1.2 DELETE Method 7.2.1.2 DELETE Method
Arguments: ContainerId1 [;...ContainerIdn] Arguments: ContainerId1 [;...ContainerIdn]
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
Mansour/Dawson/Royer 30 Expires February 2000
Taler/Hill
Bad args Bad args
Container(s) not found Container(s) not found
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 34
The DELETE method is used to delete a calendar or component. The DELETE method is used to delete a calendar or component.
ContainerId1 through ContainerIdn specify the container(s) for the ContainerId1 through ContainerIdn specify the container(s) for the
delete. When deleting a calendar at the top level, the CSID is delete. When deleting a calendar at the top level, the CSID is
specified. Otherwise the container will be a CalID. specified. Otherwise the container will be a CalID.
Example to delete a calendar at the top level: Example to delete a calendar at the top level:
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
skipping to change at line 1638 skipping to change at line 1789
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 cap://cal.foo.com/bill
7.2.1.3 GENERATEUID Method 7.2.1.3 GENERATEUID Method
Arguments: number of uids to generate Arguments: number of uids to generate
Data: new uids Data: new uids
Result: 2.0 Result: 2.0
GENERATEUID returns one or more new unique identifier which MUST be GENERATEUID returns one or more new unique identifier which MUST be
unique on the server's calendar store. It is recommended that the return unique on the servers calendar store. It is recommended that the
value be a globally unique id. return value be a globally unique id.
Example: Example:
C: GENERATEUID 2 C: GENERATEUID 2
S: 2.0 abcde1234567-asdf-lkhh abcde1234567-asdf-3455 S: 2.0 abcde1234567-asdf-lkhh abcde1234567-asdf-3455
7.2.1.4 MODIFY Method 7.2.1.4 MODIFY Method
Arguments: ContainerId1 [...ContainerIdn] Arguments: ContainerId1 [...ContainerIdn]
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 component.
ContainerId1 through ContainerIdn specify the container(s) of the
modification. When modifying a calendar at the top level, the CSID is
specified. Otherwise the container will be a CalID.
Mansour/Dawson/Royer 31 Expires February 2000 The MODIFY method is used to change an existing calendar or
Taler/Hill component. ContainerId1 through ContainerIdn specify the
container(s) of the modification. When modifying a calendar at the
top level, the CSID is specified. Otherwise the container will be a
CalID.
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.
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;VEVENT
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"
C: WHERE (UID EQ abcd12345) C: WHERE (UID EQ abcd12345)
C: END:VQUERY C: END:VQUERY
C: BEGIN:VOLD C: BEGIN:VOLD
C: DTSTART:19990421T160000Z C: DTSTART:19990421T160000Z
C: DTEND:19990421T163000Z C: DTEND:19990421T163000Z
C: LOCATION:Joe's Diner C: LOCATION:Joes Diner
C: END:VOLD C: END:VOLD
C: BEGIN:VNEW C: BEGIN:VNEW
C: DTSTART:19990421T160000Z C: DTSTART:19990421T160000Z
C: DTEND:19990421T163000Z C: DTEND:19990421T163000Z
C: END:VNEW C: END:VNEW
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
skipping to change at line 1698 skipping to change at line 1856
C: DTEND:19990421T163000Z C: DTEND:19990421T163000Z
C: END:VNEW C: END:VNEW
C: END:VCOMMAND C: END:VCOMMAND
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
S: 2.0 cap://cal.example.com/relcal2 S: 2.0 cap://cal.example.com/relcal2
7.2.1.5 MOVE Method 7.2.1.5 MOVE Method
Arguments: ContainerId Arguments: ContainerId
Data: data as described below Data: data as described below
Result: 2.0 _ success Mansour/Dawson/Royer/Taler/Hill
2.2 _ will attempt operation on the remote cap server Expires: April 2000 36
Result: 2.0 - success
2.2 - will attempt operation on the remote cap server
Permission Permission
Calendar already exists Calendar already exists
Bad args Bad args
Parent Calendar(s) not found Parent Calendar(s) not found
This method is used to move a calendar within the CS's hierarchy of
This method is used to move a calendar within the CSs hierarchy of
calendars. calendars.
[Editors Note: there could be VCAR issues with this... if a VCAR's scope [Editors Note: there could be VCAR issues with this... if a VCARs
of influence is limited to a calendar, we're probably OK. We should scope of influence is limited to a calendar, were probably OK. We
discuss this one] should discuss this one]
7.2.1.6 READ Method 7.2.1.6 READ Method
Arguments: ContainerId Arguments: ContainerId
Data: data as described below
Result: 2.0 _ successful and the requested data follows Data: data as described below
Mansour/Dawson/Royer 32 Expires February 2000 Result: 2.0 - successful and the requested data follows
Taler/Hill 2.2 - will attempt read on the remote cap server
2.2 _ will attempt read on the remote cap server
Permission Permission
Calendar already exists
Bad args Bad args
Parent Calendar(s) not found
Read Events Read Events
In the example below events on March 10,1999 between 080000Z and 190000Z
are read. In this case only 4 properties for each event are returned. In the example below events on March 10,1999 between 080000Z and
Two calendars are specified. In the example, the CAP server is capable 190000Z are read. In this case only 4 properties for each event are
of returned. Two calendars are specified.
C: SENDDATA C: SENDDATA
C: Content-type:text/calendar; Method=READ; Component=VQUERY C: Content-type:text/calendar; Method=READ; Component=VQUERY
C: C:
C: BEGIN:VCALENDAR C: BEGIN:VCALENDAR
C: VERSION:2.1 C: VERSION:2.1
C: METHOD:READ C: METHOD:READ
C: CMDID:xyz12345 C: CMDID:xyz12345
C: TARGET:relcal2 C: TARGET:relcal2
C: TARGET:cap://bobo.ex.com/relcal3 C: TARGET:cap://bobo.ex.com/relcal3
C: BEGIN:VQUERY C: BEGIN:VQUERY
C: QUERY:SELECT (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);
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 1776 skipping to change at line 1937
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: DTSTART:19990310T130000Z S: DTSTART:19990310T130000Z
S: DTEND:19990310T133000Z S: DTEND:19990310T133000Z
S: UID:abcxyz8999 S: UID:abcxyz8999
S: SUMMARY:Meet with brave brave Sir Robin S: SUMMARY:Meet with brave brave Sir Robin
S: END:VEVENT S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
S: 2.0 cap://bobo.ex.com/relcal3 S: 2.0 cap://bobo.ex.com/relcal3
S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA;
Mansour/Dawson/Royer 33 Expires February 2000
Taler/Hill
S: Optinfo=VERSION:2.1 S: Optinfo=VERSION:2.1
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: BEGIN:VDATA S: BEGIN:VDATA
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: DTSTART:19990310T140000Z S: DTSTART:19990310T140000Z
S: DTEND:19990310T150000Z S: DTEND:19990310T150000Z
S: UID:123456asdf S: UID:123456asdf
S: SUMMARY:Summer Budget S: SUMMARY:Summer Budget
S: END:VEVENT S: END:VEVENT
S: END:VDATA S: END:VDATA
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
The return values are subject to VCAR filtering. That is, if the request The return values are subject to VCAR filtering. That is, if the
contains properties to which the UPN does not have access, those request contains properties to which the UPN does not have access,
properties will not appear in the return values. If the UPN has access those properties will not appear in the return values. If the UPN has
to at least one property of events, but has been denied access to all access to at least one property of events, but has been denied access
properties called out in the request, the response will contain a single
RESPONSE-CODE property indicating the error. That is, the VEVENT Mansour/Dawson/Royer/Taler/Hill
components will be the following: Expires: April 2000 38
to all properties called out in the request, the response will
contain a single RESPONSE-CODE property indicating the error. That
is, the VEVENT components will be the following:
S: 2.0 cap://bobo.ex.com/sally S: 2.0 cap://bobo.ex.com/sally
S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA;
S: Optinfo=VERSION:2.1 S: Optinfo=VERSION:2.1
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
S: BEGIN:VDATA S: BEGIN:VDATA
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: RESPONSE-CODE:3.8 S: RESPONSE-CODE:3.8
S: END:VEVENT S: END:VEVENT
S: END:VDATA S: END:VDATA
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
If the UPN has no access to any events at all, the response will simply If the UPN has no access to any events at all, the response will
be an empty data set. The response looks the same if there are simply 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
Mansour/Dawson/Royer 34 Expires February 2000
Taler/Hill
S: . S: .
Find alarms within a range of time. Find alarms within a range of time.
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
skipping to change at line 1849 skipping to change at line 2008
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,
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);
C: ORDERBY (VALARM.TRIGGER ASC) C: ORDERBY (VALARM.TRIGGER ASC)
C: END:VQUERY C: END:VQUERY
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
skipping to change at line 1890 skipping to change at line 2052
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
S: 2.0 cap://bobo.ex.com/relcal2 S: 2.0 cap://bobo.ex.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
Mansour/Dawson/Royer 35 Expires February 2000
Taler/Hill
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 7.2.2 Scheduling Commands
The following provide a set of scheduling commands (or methods) in CAP.
Scheduling commands allow a CU to indirectly manipulate a calendar by The following provide a set of scheduling commands (or methods) in
asking another CU to perform an operation on their calendar. For CAP. Scheduling commands allow a CU to indirectly manipulate a
example, CU-A can request CU-B to add a meeting to their calendar; in calendar by asking another CU to perform an operation on their
effect inviting CU-B to the meeting. 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 commands. granting rights for more generalized access with the calendar
commands.
[Editors Note: This section needs to be completed by adding the [Editors Note: This section needs to be completed by 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 PUBLISH
Arguments:
Data: data as described below
Result: 2.0 - success
2.2 - will attempt operation on the remote cap server
Permission
Calendar already exists
Bad args
Parent Calendar(s) not found
This method is used to move a calendar within the CSs hierarchy of
calendars.
7.2.2.2 REQUEST 7.2.2.2 REQUEST
7.2.2.3 REPLY 7.2.2.3 REPLY
7.2.2.4 ADD 7.2.2.4 ADD
7.2.2.5 CANCEL 7.2.2.5 CANCEL
7.2.2.6 REFRESH 7.2.2.6 REFRESH
7.2.2.7 COUNTER 7.2.2.7 COUNTER
7.2.2.8 DECLINECOUNTER 7.2.2.8 DECLINECOUNTER
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 41
7.2.3 iTIP Examples 7.2.3 iTIP Examples
The following examples describe scenarios for the handling of incoming
iTIP data. An appropriate sort-order for the handling of icoming iTIP is The following examples describe scenarios for the handling of
by UID, Recurrence-id, sequence, dtstamp. This processing may be incoming iTIP data. An appropriate sort-order for the handling of
optimized, for instance, REFRESHs could be processed last. icoming iTIP is by UID, Recurrence-id, sequence, dtstamp. This
processing may be optimized, for instance, REFRESHs could be
processed last.
As an update to [RFC2446], data with the "COUNTER" method should be As an update to [RFC2446], data with the "COUNTER" method should be
processed even if the Seqeunce number is stale. processed even if the Seqeunce 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 relcal3 respectively, and are all on the same server,
"cal.foo.com". A lot of these described actions are performed by the
CUAs and not the users themselves, the CUAs are called A-c, B-c and
C-c respectively.
Mansour/Dawson/Royer 36 Expires February 2000 A wishes to create a meeting with B and C, so A-c uses CAP to send
Taler/Hill the following iTIP request to relcal2 and relcal3, while logged in to
and relcal3 respectively, and are all on the same server, "cal.foo.com".
A lot of these described actions are performed by the CUAs and not the
users themselves, the CUAs are called A-c, B-c and C-c respectively.
A wishes to create a meeting with B and C, so A-c uses CAP to send the
following iTIP request to relcal2 and relcal3, while logged in to
"cal.foo.com". "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
skipping to change at line 1979 skipping to change at line 2159
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 appears in relcal2 and relcal3, with the following data: then 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 the B-c and C-c must search for such incoming events, they do so using
following CAP search: the 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;
WHERE (METHOD == REQUEST); WHERE (METHOD == REQUEST);
END:VQUERY END:VQUERY
END:VCALENDAR END:VCALENDAR
Mansour/Dawson/Royer 37 Expires February 2000
Taler/Hill
In response to this search they get the above event. B-c and C-c must In response to this search they get the above event. B-c and C-c must
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 (ALL);
FROM VEVENT; FROM VEVENT;
WHERE (UID == abcd12345); WHERE (UID == abcd12345);
END:VQUERY END:VQUERY
END:VCALENDAR END:VCALENDAR
We assume that the event is not already in their relcal2 or relcal3, so We assume that the event is not already in their relcal2 or relcal3,
the read they only returns the original incoming iTIP (the UID matched), so the read they only returns the original incoming iTIP (the UID
but this can be ignored since it is incoming. matched), but this can be ignored since it is incoming.
B-c prompts B who decides to accept the meeting request, and B-c creates B-c prompts B who decides to accept the meeting request, and B-c
a copy of the event in relcal2, with the "PARTSTAT" parameter set to creates a copy of the event in relcal2, with the "PARTSTAT" parameter
ACCEPTED. B-c also sends this copy to the Organizer at relcal1 as an
iTIP REPLY, preserving the CMDID: Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 43
set to ACCEPTED. B-c also sends this copy to the Organizer at relcal1
as an 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 2059 skipping to change at line 2242
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
Mansour/Dawson/Royer 38 Expires February 2000
Taler/Hill
ORGANIZER:cap://cal.foo.com/relcal1 ORGANIZER:cap://cal.foo.com/relcal1
ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3
SUMMARY:Important Meeting SUMMARY:Important Meeting
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
It is preferable that C-c store the event in relcal3 even though it has It is preferable that C-c store the event in relcal3 even though it
been declined. Storing the event in relcal3 allows subsequent iTIP has been declined. Storing the event in relcal3 allows subsequent
messages to be interpreted correctly. The "PARTSTAT" parameter iTIP messages to be interpreted correctly. The "PARTSTAT" parameter
indicates that the event was refused, and a tombstone property may be indicates that the event was refused, and a tombstone property may be
necessary if the user wishes to delete the event. 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
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
skipping to change at line 2113 skipping to change at line 2296
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 the corresponding event. Having found the event (with no changes since
last example) A-c then verifies that relcal3 is in fact an Attendee of the last example) A-c then verifies that relcal3 is in fact an
the event and is thus allowed to request a refresh. (In the case of a Attendee of the event and is thus allowed to request a refresh. (In
the case of a published event things are more complicated.) A-c
Mansour/Dawson/Royer 39 Expires February 2000 packages the event up as an iTIP request and sends it to relcal3:
Taler/Hill
published event things are more complicated.) A-c packages the event up
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
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19990306T204333Z DTSTAMP:19990306T204333Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
skipping to change at line 2162 skipping to change at line 2344
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 a response from relcal1. A CUA implementation may wish to for a response from relcal1. A CUA implementation may wish to
preserve this information itself, externally to the CS. preserve this information itself, externally to the CS.
Mansour/Dawson/Royer 40 Expires February 2000 In order to receive an iTIP counter A-c follows the same search as
Taler/Hill for other iTIP data, first find the incoming message, next find any
In order to receive an iTIP counter A-c follows the same search as for
other iTIP data, first find the incoming message, next find any
matching events in the calendar store. matching 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 relcal1 (bumping the sequence number) to: in relcal1 (bumping the sequence number) to:
BEGIN:VEVENT BEGIN:VEVENT METHOD:CREATE UID:abcd12345 DTSTART:19990307T180000Z
METHOD:CREATE DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1
UID:abcd12345
DTSTART:19990307T180000Z
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 Meeting SUMMARY:Important Meeting LOCATION:La Belle Province SEQUENCE:1
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
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
skipping to change at line 2229 skipping to change at line 2404
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 the following iTIP: sends the following iTIP:
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.1 VERSION:2.1
CMDID:xim-ef CMDID:xim-ef
METHOD:COUNTER METHOD:COUNTER
Mansour/Dawson/Royer 41 Expires February 2000
Taler/Hill
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 decline However, C does not accept the counter, and C-c replies with a
counter: decline 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
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, and there is no problem when no information is returned in counter, and there is no problem when no information is returned in
the DECLINE-COUNTER. the DECLINE-COUNTER.
8. Response Codes 8. Response Codes Numeric response codes are returned at both the
Numeric response codes are returned at both the transport and transport and application layer. The same set of codes is used in
application layer. The same set of codes is used in both cases. 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 this [RFC2446] and [RFC2447]. The following describes new codes added to
set. this set.
At the application layer response codes are returned as the value of a At the application layer response codes are returned as the value of
"REQUEST-STATUS" property. The value type of this property is modified a "REQUEST-STATUS" property. The value type of this property is
from that defined in [RFC2445], to make the accompanying text optional. modified from that defined in [RFC2445], to make the accompanying
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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 48
and are specified and are specified
2.0.1 none Success, send data, terminate with 2.0.1 none Success, send data, terminate with
Mansour/Dawson/Royer 42 Expires February 2000
Taler/Hill
<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 completed in
the specified amount of time. The server awaits the specified amount of time. The server awaits
a CONTINUE or ABORT command. 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 ABORT
command, this reply code indicates that any command, this reply code indicates that any
command currently underway was successfully command currently underway was successfully
aborted. aborted.
skipping to change at line 2314 skipping to change at line 2490
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 authentication
mechanism, credentials rejected mechanism, credentials rejected
6.2 Sender aborted authentication, authentication 6.2 Sender aborted authentication, authentication
exchange cancelled exchange cancelled
6.3 Attempt to create or modify an event such that it
would overlap another event in either of the
following two circumstances:
a) one of the events has a TRANSP property
set to OPAQUE-NOCONFLICT or
TRANSPARENT-NOCONFLICT.
b) the calendar's ALLOW-CONFLICT property is
set to NO.
7.0 A timeout has occurred. The server was unable 7.0 A timeout has occurred. The server was unable
to complete the operation in the requested time. to complete the operation in the requested time.
8.0 A failure has occurred in the Receiver that 8.0 A failure has occurred in the Receiver that
prevents the operation from succeeding. prevents the operation from succeeding.
8.1 Sent when a session cannot be established because 8.1 Sent when a session cannot be established because
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 49
the CAP Server is too busy. the CAP Server is too busy.
8.2 Used to signal that an ICAL object has exceeded 8.2 Used to signal that an ICAL object has exceeded
the server's size limit. the server's size limit.
8.3 A DATETIME value was too large to be represented 8.3 A DATETIME value was too large to be represented
on this Calendar. on this Calendar.
8.4 A DATETIME value was too far in the past to be 8.4 A DATETIME value was too far in the past to be
represented on this Calendar. represented on this Calendar.
8.5 An attempt was made to create a new object but 8.5 An attempt was made to create a new object but
the unique id specified is already in use. the unique id specified is already in use.
8.6 ID clash 8.6 ID clash
9.0 An unrecongnized command was received. 9.0 An unrecongnized command was received.
10.1 Accompanied by an alternate address. The 10.1 Accompanied by an alternate address. The
Mansour/Dawson/Royer 43 Expires February 2000
Taler/Hill
RECIPIENT specified should be contacted at the RECIPIENT specified should be contacted at the
given alternate address. The referral address given alternate address. The referral address
MUST follow the reply code. 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 because it
would cause the resources (memory, disk,CPU, etc) would cause the resources (memory, disk,CPU, etc)
to exceed the allocated quota. to exceed the allocated quota.
10.5 The ITIP message has been queued too too long. 10.5 The ITIP message has been queued too too long.
Delivery has been aborted. Delivery has been aborted.
9. Detailed SQL Schema 9. Detailed SQL Schema
This section describes a conceptual schema for object model in CAP. It
is used as the basis for querying data managed by the CS. This is only a This section describes a conceptual schema for object model in CAP.
conceptual schema. Implementations can use any schema they like so long It is used as the basis for querying data managed by the CS. This is
as they are prepared to map CAP queries that are expressed in this only a conceptual schema. Implementations can use any schema they
conceptual schema. Implementations are not required to use SQL database like so long as they are prepared to map CAP queries that are
technology. The protocol is designed such that a CUA does not need to expressed in this conceptual schema. Implementations are not required
handle these queries. to use SQL database technology. The protocol is designed such that a
CUA does not need to handle these 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 abbreviated not a complete representation of the VEVENT table. It is an
table used to illustrate how properties that can occur multiple times abbreviated table used to illustrate how properties that can occur
are intended to be represented. multiple times are intended to be represented.
ABBREVIATED VEVENT TABLE ABBREVIATED VEVENT TABLE
UID DTSTART ORGANIZER SUMMARY ATTACH_LIST UID DTSTART ORGANIZER SUMMARY ATTACH_LIST
+----+----------------+-------------------+------------+------------+ +----+----------------+-------------------+------------+------------+
|1 |19990326T201400Z|mailto:sam@abc.com |I have 2 | 123 | |1 |19990326T201400Z|mailto:sam@abc.com |I have 2 | 123 |
| | | |attachments | | | | | |attachments | |
+----+----------------+-------------------+------------+------------+ +----+----------------+-------------------+------------+------------+
|999 |19700101T000000Z|mailto:usr@host.com|I have no | | |999 |19700101T000000Z|mailto:usr@host.com|I have no | |
| | | |attachments | | | | | |attachments | |
Mansour/Dawson/Royer 44 Expires February 2000
Taler/Hill
+----+----------------+-------------------+------------+------------+ +----+----------------+-------------------+------------+------------+
ABBREVIATED ATTACH_LIST TABLE ABBREVIATED ATTACH_LIST TABLE
ATTACH_LIST VALUE INLINE_BLOB ATTACH_LIST 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| |
+------------+------------------------------------+-----------------+ +------------+------------------------------------+-----------------+
skipping to change at line 2418 skipping to change at line 2603
+------------+------------------------------------+-----------------+ +------------+------------------------------------+-----------------+
|234 | | MIICajCCAdO- | |234 | | MIICajCCAdO- |
| | | gAwIBAgICBEU | | | | gAwIBAgICBEU |
| | | <...remainder | | | | <...remainder |
| | | of "BASE64"| | | | of "BASE64"|
| | | encoded binary| | | | encoded binary|
| | | data...> | | | | 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
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 51
components, properties, and parameters defined in [RFC2445]. components, properties, and parameters defined in [RFC2445].
Create table VCALENDAR { Create table VCALENDAR {
RELATIVECALID VARCHAR(256) PRIMARY KEY, RELATIVECALID VARCHAR(256) PRIMARY KEY,
CALMASTER VARCHAR(256), CALMASTER VARCHAR(256),
CHARSET VARCHAR(256), CHARSET VARCHAR(256),
CHILDREN VARCHAR(256) CHILDREN VARCHAR(256)
LANGUAGE CHAR(5) LANGUAGE CHAR(5)
LAST_MODIFIED LAST_MODIFIED
NAME VARCHAR(256), NAME VARCHAR(256),
skipping to change at line 2452 skipping to change at line 2641
CATEGORIES VARCHAR(len?), CATEGORIES VARCHAR(len?),
CLASS INTEGER, CLASS INTEGER,
CLASS_PARAMS INTEGER, CLASS_PARAMS INTEGER,
COMMENT VARCHA, COMMENT VARCHA,
COMMENT_PARAMS INTEGER, COMMENT_PARAMS INTEGER,
CONTACT_LIST INTEGER, CONTACT_LIST INTEGER,
CREATED TIMESTAMP NOT NULL DEFAULT CREATED TIMESTAMP NOT NULL DEFAULT
CURRENT_DATE, CURRENT_DATE,
CREATED_PARAMS INTEGER, CREATED_PARAMS INTEGER,
DESCRIPTION VARCHAR(len?), DESCRIPTION VARCHAR(len?),
Mansour/Dawson/Royer 45 Expires February 2000
Taler/Hill
DESCRIPTION_PARAMS INTEGER, DESCRIPTION_PARAMS INTEGER,
DTEND TIMESTAMP, DTEND TIMESTAMP,
DTEND_PARAMS INTEGER, DTEND_PARAMS INTEGER,
DTSTAMP TIMESTAMP NOT NULL, DTSTAMP TIMESTAMP NOT NULL,
DTSTAMP_PARAMS INTEGER, DTSTAMP_PARAMS INTEGER,
DTSTART TIMESTAMP NOT NULL, DTSTART TIMESTAMP NOT NULL,
DTSTART_PARAMS INTEGER, DTSTART_PARAMS INTEGER,
DURATION <?type?>, DURATION <?type?>,
DURATION_PARAMS INTEGER, DURATION_PARAMS INTEGER,
EXDATE_LIST INTEGER, EXDATE_LIST INTEGER,
EXRULE_LIST INTEGER, EXRULE_LIST INTEGER,
GEO_LAT NUMBER, GEO_LAT NUMBER,
GEO_LON NUMBER, GEO_LON NUMBER,
GEO_PARAMS INTEGER, GEO_PARAMS INTEGER,
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 52
LAST_MODIFIED TIMESTAMP NOT NULL DEFAULT LAST_MODIFIED TIMESTAMP NOT NULL DEFAULT
CURRENT_DATE, CURRENT_DATE,
LAST_MODIFIED_PARAMS INTEGER, LAST_MODIFIED_PARAMS INTEGER,
LOCATION VARCHA, LOCATION VARCHA,
LOCATION_PARAMS INTEGER, LOCATION_PARAMS INTEGER,
METHOD VARCHAR(len20?), METHOD VARCHAR(len20?),
ORGANIZER VARCHAR(len?) NOT NULL, ORGANIZER VARCHAR(len?) NOT NULL,
ORGANIZER_PARAMS INTEGER, ORGANIZER_PARAMS INTEGER,
PRIORITY INTEGER, PRIORITY INTEGER,
PRIORITY_PARAMS CHAR(1), PRIORITY_PARAMS CHAR(1),
skipping to change at line 2509 skipping to change at line 2698
X_PROP_LIST INTEGER, X_PROP_LIST INTEGER,
VALARM_LIST INTEGER, VALARM_LIST INTEGER,
}; };
create table VTODO { create table VTODO {
ATTENDEE_LISTINTEGER, ATTENDEE_LISTINTEGER,
ATTACH_LIST INTEGER, ATTACH_LIST INTEGER,
/* CATEGORIES may contain a comma separated list */ /* CATEGORIES may contain a comma separated list */
CATEGORIES VARCHAR(len?), CATEGORIES VARCHAR(len?),
CLASS INTEGER, CLASS INTEGER,
Mansour/Dawson/Royer 46 Expires February 2000
Taler/Hill
CLASS_PARAMS INTEGER, CLASS_PARAMS INTEGER,
COMMENT VARCHAR(len?), COMMENT VARCHAR(len?),
COMMENT_PARAMS INTEGER, COMMENT_PARAMS INTEGER,
CONTACT_LIST INTEGER, CONTACT_LIST INTEGER,
CREATED TIMESTAMP NOT NULL DEFAULT CREATED TIMESTAMP NOT NULL DEFAULT
CURRENT_DATE, CURRENT_DATE,
CREATED_PARAMS INTEGER, CREATED_PARAMS INTEGER,
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 53
DESCRIPTION VARCHAR(len?), DESCRIPTION VARCHAR(len?),
DESCRIPTION_PARAMS INTEGER, DESCRIPTION_PARAMS INTEGER,
DTSTAMP TIMESTAMP NOT NULL, DTSTAMP TIMESTAMP NOT NULL,
DTSTAMP_PARAMS INTEGER, DTSTAMP_PARAMS INTEGER,
DTSTART TIMESTAMP NOT NULL, DTSTART TIMESTAMP NOT NULL,
DTSTART_PARAMS INTEGER, DTSTART_PARAMS INTEGER,
DUE TIMESTAMP, DUE TIMESTAMP,
DUE_PARAMS INTEGER, DUE_PARAMS INTEGER,
DURATION <?type?>, DURATION <?type?>,
DURATION_PARAMS INTEGER, DURATION_PARAMS INTEGER,
skipping to change at line 2567 skipping to change at line 2756
UID VARCHAR(len?) NOT NULL, UID VARCHAR(len?) NOT NULL,
UID_PARAMS INTEGER, UID_PARAMS INTEGER,
URL VARCHAR(len?) URL VARCHAR(len?)
URL_PARAMS INTEGER, URL_PARAMS INTEGER,
X_PROP_LIST INTEGER X_PROP_LIST INTEGER
VALARM_LIST INTEGER, VALARM_LIST INTEGER,
}; };
create table VJOURNAL { create table VJOURNAL {
Mansour/Dawson/Royer 47 Expires February 2000 Mansour/Dawson/Royer/Taler/Hill
Taler/Hill Expires: April 2000 54
ATTACH_LIST INTEGER, ATTACH_LIST INTEGER,
/* CATEGORIES may contain a comma seperated list */ /* CATEGORIES may contain a comma seperated list */
CATEGORIES VARCHAR(len?), CATEGORIES VARCHAR(len?),
CLASS INTEGER, CLASS INTEGER,
CLASS_PARAMS INTEGER, CLASS_PARAMS INTEGER,
COMMENT VARCHAR(len?), COMMENT VARCHAR(len?),
COMMENT_PARAMS INTEGER, COMMENT_PARAMS INTEGER,
CONTACT_LIST INTEGER, CONTACT_LIST INTEGER,
CREATED TIMESTAMP NOT NULL DEFAULT CREATED TIMESTAMP NOT NULL DEFAULT
CURRENT_DATE, CURRENT_DATE,
skipping to change at line 2610 skipping to change at line 2799
SEQUENCE_PARAMS INTEGER, SEQUENCE_PARAMS INTEGER,
STATUS INTEGER, STATUS INTEGER,
STATUS_PARAMS CHAR(1), STATUS_PARAMS CHAR(1),
SUMMARY VARCHAR(len?) NOT NULL DEFAULT "", SUMMARY VARCHAR(len?) NOT NULL DEFAULT "",
SUMMARY_PARAMS INTEGER, SUMMARY_PARAMS INTEGER,
UID VARCHAR(len?) NOT NULL, UID VARCHAR(len?) NOT NULL,
UID_PARAMS INTEGER, UID_PARAMS INTEGER,
X_PROP_LIST INTEGER X_PROP_LIST INTEGER
}; };
An implementation may not actually have a VFREEBUSY table as An implementation may not actually have a VFREEBUSY table as the
the information may be produced dynamicly. However a CS information may be produced dynamicly. However a CS MUST appear to
MUST appear to provide this table as this may be how a CUA provide this table as this may be how a CUA chooses to query for
chooses to query for VFREEBUSY information while using VFREEBUSY information while using [CAP]. Example, it probabily
[CAP]. Example, it probabily would not make any sense for would not make any sense for ATTENDEE to exist in this table, yet
ATTENDEE to exist in this table, yet a CUA may wish to ask a CUA may wish to ask for the VFREEBUSY for an ATTENDEE.
for the VFREEBUSY for an ATTENDEE.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 55
create table VFREEBUSY { create table VFREEBUSY {
ATTENDEE_LIST VARCHAR(len?), ATTENDEE_LIST VARCHAR(len?),
COMMENT VARCHAR(len?), COMMENT VARCHAR(len?),
COMMENT_PARAMS INTEGER, COMMENT_PARAMS INTEGER,
CONTACT_LIST INTEGER, CONTACT_LIST INTEGER,
Mansour/Dawson/Royer 48 Expires February 2000
Taler/Hill
DTEND TIMESTAMP NOT NULL, DTEND TIMESTAMP NOT NULL,
DTEND_PARAMS INTEGER, DTEND_PARAMS INTEGER,
DTSTAMP TIMESTAMP NOT NULL, DTSTAMP TIMESTAMP NOT NULL,
DTSTAMP_PARAMS INTEGER, DTSTAMP_PARAMS INTEGER,
DTSTART TIMESTAMP NOT NULL, DTSTART TIMESTAMP NOT NULL,
DTSTART_PARAMS INTEGER, DTSTART_PARAMS INTEGER,
FREEBUSY_LIST INTEGER NOT NULL, FREEBUSY_LIST INTEGER NOT NULL,
METHOD VARCHAR(len20?), METHOD VARCHAR(len20?),
ORGANIZER VARCHAR(len?) NOT NULL, ORGANIZER VARCHAR(len?) NOT NULL,
ORGANIZER_PARAMS INTEGER, ORGANIZER_PARAMS INTEGER,
skipping to change at line 2668 skipping to change at line 2855
CURRENT_DATE, CURRENT_DATE,
LAST_MODIFIED_PARAMS INTEGER, LAST_MODIFIED_PARAMS INTEGER,
RDATE_LIST INTEGER, RDATE_LIST INTEGER,
RRULE_LIST INTEGER, RRULE_LIST INTEGER,
TZNAME VARCHAR(len?), TZNAME VARCHAR(len?),
TZOFFSET <?type?> NOT NULL, TZOFFSET <?type?> NOT NULL,
TZOFFSETFROM <?type?> NOT NULL, TZOFFSETFROM <?type?> NOT NULL,
TZOFFSETTO <?type?> NOT NULL, TZOFFSETTO <?type?> NOT NULL,
}; };
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 56
create table VALARM_LIST { create table VALARM_LIST {
/* Maps to VALARM_LIST in other tables */ /* Maps to VALARM_LIST in other tables */
VALARM_KEY INTEGER, VALARM_KEY INTEGER,
ACTION INTEGER NOT NULL, ACTION INTEGER NOT NULL,
ACTION_PARAMS INTEGER, ACTION_PARAMS INTEGER,
ATTACH_LIST INTEGER, ATTACH_LIST INTEGER,
DESCRIPTION VARCHAR(len?) NOT NULL DEFAUT "", DESCRIPTION VARCHAR(len?) NOT NULL DEFAUT "",
DESCRIPTION_PARAMS INTEGER, DESCRIPTION_PARAMS INTEGER,
DURATION <?type?>, DURATION <?type?>,
DURATION_PARAMS INTEGER, DURATION_PARAMS INTEGER,
REPEAT INTEGER, REPEAT INTEGER,
REPEAT_PARAMS INTEGER, REPEAT_PARAMS INTEGER,
Mansour/Dawson/Royer 49 Expires February 2000
Taler/Hill
SUMMARY VARCHAR(len?) NOT NULL DEFAULT "", SUMMARY VARCHAR(len?) NOT NULL DEFAULT "",
SUMMARY_PARAMS INTEGER, SUMMARY_PARAMS INTEGER,
TRIGGER_DT TIMESTAMP, TRIGGER_DT TIMESTAMP,
TRIGGER_DURATION <?type?>, TRIGGER_DURATION <?type?>,
X_PROP_LIST INTEGER X_PROP_LIST INTEGER
}; };
10. Examples 10. Examples
For all the examples in this section, the authenticated user is For all the examples in this section, the authenticated user is
user@example.com. user@example.com.
10.1 Authentication Examples 10.1 Authentication Examples
10.1.1 Login Using Kerberos V4 10.1.1 Login Using Kerberos V4
Use Kerberos V4 to authenticate as bill@example.com to the CAP server on
cal.example.com. Use Kerberos V4 to authenticate as bill@example.com to the CAP server
on cal.example.com.
C: <connect to cal.example.com on port ...> C: <connect to cal.example.com on port ...>
S: 2.0 S: 2.0
S: .
C: CAPABILTY
S: CAPVERSION=1.0 S: CAPVERSION=1.0
S: ITIPVERSION=1.0 S: ITIPVERSION=1.0
S: AUTH=KERBEROS_V4 S: AUTH=KERBEROS_V4
S: AUTH=DIGEST_MD5 S: AUTH=DIGEST_MD5
S: . S: .
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: IDENTITY=bill@example.com S: IDENTITY=bill@example.com
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 57
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 appl S: CAR=CAR1 appl
S: MINDATE=19700101T000000Z appl S: MINDATE=19700101T000000Z appl
# who knows this date (end of the 32 bit number)? # who knows this date (end of the 32 bit number)?
S: MAXDATE=20370201T000000Z S: MAXDATE=20370201T000000Z
S: . S: .
skipping to change at line 2735 skipping to change at line 2929
Use of SASL Authorization Identity is not supported. Use the IDENTITY Use of SASL Authorization Identity is not supported. Use the IDENTITY
command instead. If you attempt to use the Authorization Identity, an command instead. If you attempt to use the Authorization Identity, an
error status will be returned. error status will be returned.
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: 6.1 S: 6.1
Mansour/Dawson/Royer 50 Expires February 2000
Taler/Hill
S: . S: .
Sender aborted authentication: Sender aborted authentication:
C: AUTHENTICATE KERBEROS_V4 C: AUTHENTICATE KERBEROS_V4
S: AmFYig== S: AmFYig==
C: . C: .
S: 6.2 S: 6.2
S: . S: .
skipping to change at line 2757 skipping to change at line 2948
Unsupported mechanism: Unsupported mechanism:
C: AUTHENTICATE Experimental_Auth C: AUTHENTICATE Experimental_Auth
S: 6.3 S: 6.3
S: . S: .
10.2 Read Examples 10.2 Read Examples
10.2.1 Read From A Single Calendar 10.2.1 Read From A Single Calendar
In this example bill@example.com reads a day's worth of events from In this example bill@example.com reads a day's worth of events from
cap://cal.example.com/opaqueid99. cap://cal.example.com/opaqueid99.
C: SENDDATA C: SENDDATA
C: Content-type:text/calendar; Method=READ; Component=VQUERY C: Content-type:text/calendar; Method=READ; Component=VQUERY
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 58
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:cap://cal.example.com/opaqueid99 C: TARGET:cap://cal.example.com/opaqueid99
C: BEGIN:VQUERY C: BEGIN:VQUERY
C: QUERY:SELECT (VEVENT.DTSTART,VEVENT.DTEND,SUMMARY,UID); C: QUERY:SELECT (VEVENT.DTSTART,VEVENT.DTEND,SUMMARY,UID);
C: FROM VEVENTTABLE; C: FROM VEVENTTABLE;
C: WHERE (VEVENT.DTEND >= 19990714T080000Z AND C: WHERE (VEVENT.DTEND >= 19990714T080000Z AND
skipping to change at line 2777 skipping to change at line 2972
C: TARGET:cap://cal.example.com/opaqueid99 C: TARGET:cap://cal.example.com/opaqueid99
C: BEGIN:VQUERY C: BEGIN:VQUERY
C: QUERY:SELECT (VEVENT.DTSTART,VEVENT.DTEND,SUMMARY,UID); C: QUERY:SELECT (VEVENT.DTSTART,VEVENT.DTEND,SUMMARY,UID);
C: FROM VEVENTTABLE; C: FROM VEVENTTABLE;
C: WHERE (VEVENT.DTEND >= 19990714T080000Z AND C: WHERE (VEVENT.DTEND >= 19990714T080000Z AND
C: VEVENT.DTSTART <= 19990715T080000Z); C: VEVENT.DTSTART <= 19990715T080000Z);
C: ORDERBY (VEVENT.DTSTART ASC, VEVENT.DTEND, UID, SUMMARY) C: ORDERBY (VEVENT.DTSTART ASC, VEVENT.DTEND, UID, SUMMARY)
C: END:VQUERY C: END:VQUERY
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
# this response code means that the transport successfully # this response code means that the transport successfully
# delivered the data. # delivered the data.
S: 2.0 ; got the request OK ; I swear S: 2.0 ; got the request OK ; really
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
S: TARGET:cap://cal.example.com/opaqueid99 S: TARGET:cap://cal.example.com/opaqueid99
S: CMDID:xyz12345 S: CMDID:xyz12345
Mansour/Dawson/Royer 51 Expires February 2000
Taler/Hill
# we have not yet discussed response-status # we have not yet discussed response-status
S: RESPONSE-STATUS:2.0 S: RESPONSE-STATUS:2.0
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: DTSTART:19990714T200000Z S: DTSTART:19990714T200000Z
S: DTEND:19990714T210000Z S: DTEND:19990714T210000Z
S: UID:000444888929922 S: UID:000444888929922
S: SUMMARY:Blah bla S: SUMMARY:Blah bla
S: END:VEVENT S: END:VEVENT
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: UID:0034848098038888989443 S: UID:0034848098038888989443
S: SUMMARY:meeting S: SUMMARY:meeting
S: DTEND:19990714T233000Z S: DTEND:19990714T233000Z
S: DTSTART:19990714T223000Z S: DTSTART:19990714T223000Z
S: END:VEVENT S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
10.2.2 Read From Multiple Calendars 10.2.2 Read From Multiple Calendars
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 59
In this example bill@example.com reads a day's worth of events from In this example bill@example.com reads a day's worth of events from
cap://cal.example.com/opaqueid101 and cap://cal.example.com/opaqueid103 cap://cal.example.com/opaqueid101 and
cap://cal.example.com/opaqueid103
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:xyz12346 C: CMDID:xyz12346
C: TARGET:cap://cal.example.com/opaqueid101 C: TARGET:cap://cal.example.com/opaqueid101
C: TARGET:opaqueid103 C: TARGET:opaqueid103
skipping to change at line 2847 skipping to change at line 3043
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
S: TARGET:cap://cal.example.com/opaqueid103 S: TARGET:cap://cal.example.com/opaqueid103
S: CMDID:xyz12346 S: CMDID:xyz12346
S: RESPONSE-CODE:2.0 S: RESPONSE-CODE:2.0
Mansour/Dawson/Royer 52 Expires February 2000
Taler/Hill
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: UID:0034848098038888989443 S: UID:0034848098038888989443
S: SUMMARY:meeting S: SUMMARY:meeting
S: DTEND:19990714T233000Z S: DTEND:19990714T233000Z
S: DTSTART:19990714T223000Z S: DTSTART:19990714T223000Z
S: END:VEVENT S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
S: S:
S: ----FEE3790DC7E35189CA67CE2C S: ----FEE3790DC7E35189CA67CE2C
S: Content-type:text/calendar; Method=RESPONSE; S: Content-type:text/calendar; Method=RESPONSE;
S: Optinfo=VERSION:2.1 S: Optinfo=VERSION:2.1
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 60
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: VERSION:2.1 S: VERSION:2.1
S: METHOD:RESPONSE S: METHOD:RESPONSE
S: TARGET:cap://cal.example.com/opaqueid101 S: TARGET:cap://cal.example.com/opaqueid101
S: CMDID:xyz12346 S: CMDID:xyz12346
S: RESPONSE-CODE:4.1 ; access denied S: RESPONSE-CODE:4.1 ; access denied
S: END:VCALENDAR S: END:VCALENDAR
S: S:
skipping to change at line 2900 skipping to change at line 3097
C: FROM VEVENT; C: FROM VEVENT;
C: WHERE (DTEND >= 19990714T080000Z AND C: WHERE (DTEND >= 19990714T080000Z AND
C: DTSTART <= 19990715T080000Z); C: DTSTART <= 19990715T080000Z);
C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY) C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY)
C: END:VQUERY C: END:VQUERY
C: END:VCALENDAR C: END:VCALENDAR
C: . C: .
S: 7.0 ; timeout S: 7.0 ; timeout
S: . S: .
If Bill wants to continue and give the server more time he would issue a If Bill wants to continue and give the server more time he would
CONTINUE command: issue a CONTINUE command:
C: CONTINUE 10 C: CONTINUE 10
Mansour/Dawson/Royer 53 Expires February 2000
Taler/Hill
If Bill wants to abort the command and not wait any further he would If Bill wants to abort the command and not wait any further he would
issue an ABORT command: issue an ABORT command:
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 61
C: ABORT C: ABORT
S: 2.0 S: 2.0
S: . S: .
10.2.4 Using the Calendar Parent, Children Properties 10.2.4 Using the Calendar Parent, Children Properties
10.2.5 An example that depends on VEVENT.DTSTART and VALARM.DTSTART 10.2.5 An example that depends on VEVENT.DTSTART and VALARM.DTSTART
11. Implementation Issues 11. Implementation Issues
1. What are the minimum component properties set required to create a 1. What are the minimum component properties set required to create a
new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, SUMMARY and UID. new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, SUMMARY and UID.
2. What is the state of all undefined properties? PROPOSAL: Not defined. 2. What is the state of all undefined properties? PROPOSAL: Not
So a query will not return them, if they are selected. defined. So a query will not return them, if they are selected.
12. Properties 12. Properties
[Editors Note: These extensions/changes to iCalendar need to be [Editors Note: These extensions/changes to iCalendar need to be
reformatted to conform to the IANA registration process defined in reformatted to conform to the IANA registration process defined in
section 7 of [RFC2445].] section 7 of [RFC2445].]
12.1 Calendar Store Properties 12.1 Calendar Store Properties
Read Read
Name Only Description Name Only Description
------------- ---- --------------------------------------------------- ------------- ---- ---------------------------------------------------
DEFAULT-VCARS N The default VCARs for newly created toplevel DEFAULT-VCARS N The default VCARs for newly created toplevel
calendars calendars
skipping to change at line 2947 skipping to change at line 3145
MAXDATE Y The date/time in the future beyond which MAXDATE Y The date/time in the future beyond which
the server cannot represent. the server cannot represent.
MINDATE Y The date/time in the past prior to which MINDATE Y The date/time in the past prior to which
the server cannot represent. the server cannot represent.
TIME Y Current server time. This is returned as a TIME Y Current server time. This is returned as a
localtime and TZID localtime and TZID
[Editors Note: Should there be something here about how the server RECURRENCE Y Boolean value set to TRUE if the server supports
handles RRULES and EXRULES? For example, can/MUST the server unzip recurrence rules, or FALSE if it does not.
RRULES/EXRULES? Does it even support RRULES? Can it deal with unbounded
RRULES?] RECUR-LIMIT Y This numeric value describes how the server handles
unbounded recurrences. The value is only valid if
RECURRENCE is TRUE. If the value is 0 it means that
the server supports unbounded recurrence rules. If
it is non-zero, it is a positive integer indicating
the number of instances that will be created when
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 62
the server expands an unbounded recurrence rule.
[Editors Note: Can/MUST the server unzip RRULES/EXRULES?]
12.2 Calendar Properties 12.2 Calendar Properties
Read Read
Name Only Description Name Only Description
------------- ---- -------------------------------------------------
ALLOW-CONFLICTS N This boolean value indicates whether or not the
calendar supports event conflicts. That is,
whether or not any of the events in the calendar
can overlap. The default value is YES meaning
that conflicts are allowed.
CHARSET N the default charset for localized strings in this CHARSET N the default charset for localized strings in this
calendar calendar
CHILDREN Y the sub-calendars belonging to this calendar. CHILDREN Y the sub-calendars belonging to this calendar.
Mansour/Dawson/Royer 54 Expires February 2000 CREATED Y the timestamp of the calendars create date
Taler/Hill
CREATED Y the timestamp of the calendar's create date
LANGUAGE N the default language for localizable strings in LANGUAGE N the default language for localizable strings in
this calendar this calendar
LAST-MODIFIED N the timestamp when the properties of the calendar LAST-MODIFIED N the timestamp when the properties of the calendar
were last updated. were last updated. Note that the UPN parameter
may be present to indicate the person or process
that last modified the calendar properties.
NAME N the display name for this calendar. It is NAME N the display name for this calendar. It is
a localizable string. a localizable string.
OWNERS N a multi instanced property indicating the OWNERS N a multi instanced property indicating the
calendar owner. calendar owner.
PARENT N maintained by a CAP server. PARENT N maintained by a CAP server.
PATH Y ?? human readable path of name. ?? PATH Y ?? human readable path of name. ??
[editors note: I think this is going to be [editors note: I think this is going to be
really problematic. Can we do away with really problematic. Can we do away with
this? Or perhaps make it optional? ] this? Or perhaps make it optional? ]
RELATIVECALID N a unique name for the calendar. It is made RELATIVECALID N a unique name for the calendar. It is made
up of 7 bit ASCII characters. up of 7 bit ASCII characters.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 63
SCHEDULABLE- N the preferred time range for scheduling SCHEDULABLE- N the preferred time range for scheduling
HOURS events on this calendar. HOURS events on this calendar. This value is a
collection of RRULEs and EXRULEs
TOMBSTONE N a marker indicating that this calendar has been TOMBSTONE N a marker indicating that this calendar has been
Deleted. Deleted.
TZID N the id of the timezone associated with this TZID N the id of the timezone associated with this
calendar calendar
LAST-MODIFIED-BY Y UPN of the person or process that
last modified the calendar properties.
13. Security Considerations 13. Security Considerations
For the mandatory SASL mechanism that CAP specifies, the mechanism For the mandatory SASL mechanism that CAP specifies, the mechanism
support is: support is:
MUST authentication ? MUST authentication ? MUST authorization ? MAY impersonation
MUST authorization
MAY impersonation
The security issue: The security issue:
+---------+ +----------+ +---------+ +----------+
CUA1 ------ | CS1 |--------CAP----------| CS2 |-----CUA2 CUA1 ------ | CS1 |--------CAP----------| CS2 |-----CUA2
| calF | | calA | | calF | | calA |
+---------+ +----------+ +---------+ +----------+
UserListX is not an owner of calF ? UserListX is not an owner of calF ? UserListX has been given
ACTONBEHALF of rights to calF by an owner of calF, UserY ? UserX
Mansour/Dawson/Royer 55 Expires February 2000 authenticates to CS1 as UserX ? UserX wants to update the attendee
Taler/Hill status of an event on calA ? An owner of calA has granted access to
UserListX has been given ACTONBEHALF of rights to calF by an owner UserY to update an event they have been invited to ? How do we grant
of calF, UserY UserX access to do this?
UserX authenticates to CS1 as UserX
UserX wants to update the attendee status of an event on calA
An owner of calA has granted access to UserY to update an event
they have been invited to
How do we grant UserX access to do this?
[Editors Note: This needs further work and examples.] [Editors Note: This needs further work and examples.]
14. Changes to iCalendar 14. Changes to iCalendar
[Editors Note: These extensions/changes to iCalendar need to be [Editors Note: These extensions/changes to iCalendar need to be
reformatted to conform to the IANA registration process defined in reformatted to conform to the IANA registration process defined in
section 7 of [RFC2445].] section 7 of [RFC2445].]
14.1 RIGHTS Value Type 14.1 Created
Property Name: CREATED
Purpose: This property specifies the date and time that the calendar
information was created by the calendar user agent in the calendar
store.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 64
Note: This is analogous to the creation date and time for a file in
the file system.
Value Type: DATE-TIME
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: The property can be specified once in "VEVENT", "VTODO"
or "VJOURNAL" calendar components.
Description: The date and time is a UTC value.
Format Definition: The property is defined by the following notation:
created = "CREATED" creaparam ":" date-time CRLF creaparam = (";"
upnparam) *(";" xparam) upnparam = "UPN" "=" DQUOTE upn-value DQUOTE
Example: The following is an example of this property:
CREATED:19960329T133000Z
CREATED;UPN=sman@netscape.com:19991018T203000Z
14.2 Last Modified
Property Name: LAST-MODIFIED
Purpose: The property specifies the date and time that the
information associated with the calendar component was last revised
in the calendar store. Note: This is analogous to the modification
date and time for a file in the file system.
Value Type: DATE-TIME
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in the "EVENT", "VTODO",
"VJOURNAL" or "VTIMEZONE" calendar components.
Description: The property value MUST be specified in the UTC time
format.
Format Definition: The property is defined by the following notation:
last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF lstparam =
(";" upnparam) *(";" xparam) upnparam = "UPN" "=" DQUOTE upn-value
DQUOTE
Example: The following is are examples of this property: LAST-
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 65
MODIFIED:19960817T133000Z LAST-
MODIFIED;UPN=sman@netscape.com:19991018T200000Z
14.2.1.1 Time Transparency
Property Name: TRANSP
Purpose: This property defines whether an event is transparent or not
to busy time searches.
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified once in a "VEVENT"
calendar component.
Description: Time Transparency is the characteristic of an event that
determines whether it appears to consume time on a calendar. Events
that consume actual time for the individual or resource associated
with the calendar SHOULD be recorded as OPAQUE, allowing them to be
detected by free-busy time searches. Other events, which do not take
up the individual's (or resource's) time SHOULD be recorded as
TRANSPARENT, making them invisible to free-busy time searches.
Format Definition: The property is specified by the following
notation:
transp = "TRANSP" tranparam ":" transvalue CRLF tranparam = *(";"
xparam) transvalue = "OPAQUE" ;Blocks or opaque on busy time
searches.
/ "TRANSPARENT" ;Transparent on busy time
searches.
/ "TRANSPARENT-NOCONFLICT" ; Transparent on busy time
; searches and no other OPAQUE
; or OPAQUE-NOCONFLICT event can
; overlap it.
/ "OPAQUE-NOCONFLICT" ; Opaque on busy time
; searches and no other OPAQUE
; or OPAQUE-NOCONFLICT event can
; overlap it.
;Default value is OPAQUE
Example: The following is an example of this property for an event
that is transparent or does not block on free/busy time searches:
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 66
TRANSP:TRANSPARENT
The following is an example of this property for an event that is
opaque or blocks on free/busy time searches:
TRANSP:OPAQUE
The following is an example of this property for an event that is
opaque or blocks on free/busy time searches plus no other event can
overlap it:
TRANSP:OPAQUE-NOCONFLICT
14.3 RIGHTS Value Type
Value Name: RIGHTS Value Name: RIGHTS
Purpose: This value type is used to identify properties whose value is a Purpose: This value type is used to identify properties whose value
calendar access rights. is a calendar access rights.
Formal Definition: The value type is defined by the following notation: Formal Definition: The value type is defined by the following
notation:
rights = [princ] (policy / carref / cardef) CRLF rights = [princ] (policy / carref / cardef) CRLF
princ = "UPN" "=" (text / all / "OWNER" / "NONOWNER") princ = "UPN" "=" (text / all / "OWNER" / "NONOWNER")
policy = ";" "POLICY" "=" policyname policy = ";" "POLICY" "=" policyname
policyname = "READBUSYTIMEINFO" / "ACTONBEHALFOF" / policyname = "READBUSYTIMEINFO" / "ACTONBEHALFOF" /
"REQUESTONLY" "REQUESTONLY"
/ "UPDATEPARTSTATUS" / "OWNER" / iana-name / "UPDATEPARTSTATUS" / "OWNER" / iana-name
skipping to change at line 3068 skipping to change at line 3400
action = ";" "ACTION" "=" act-type *("," act-type) action = ";" "ACTION" "=" act-type *("," act-type)
act-type = ("CREATE" / "MODIFY" / "DELETE" / "READ" / all) act-type = ("CREATE" / "MODIFY" / "DELETE" / "READ" / all)
object = ";" "OBJECT" "=" (csprop *("," csprop) [propvalue]) object = ";" "OBJECT" "=" (csprop *("," csprop) [propvalue])
/ (calprop *("," calprop) [propvalue]) / (calprop *("," calprop) [propvalue])
/ (component *("," component)) [compvalue] / (component *("," component)) [compvalue]
/ (compprop *("," compprop) [propvalue]) / (compprop *("," compprop) [propvalue])
/ (compparam *("," compparam) [paramvalue]) / (compparam *("," compparam) [paramvalue])
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 67
csprop = csprop2 / all / iana-name csprop = csprop2 / all / iana-name
csprop2 = <any calendar store property defined in [CAP]> csprop2 = <any calendar store property defined in [CAP]>
propvalue = propvalue2 / all / iana-name propvalue = propvalue2 / all / iana-name
Mansour/Dawson/Royer 56 Expires February 2000
Taler/Hill
propvalue2 = <any value appropriate for the named property> propvalue2 = <any value appropriate for the named property>
calprop = calprop2 / all / iana-name calprop = calprop2 / all / iana-name
calprop2 = <any calendar property name defined in [RFC2445] or calprop2 = <any calendar property name defined in [RFC2445] or
[CAP]> [CAP]>
component = component2 / all / iana-name component = component2 / all / iana-name
component2 = <any calendar component defined in [RFC2445] or component2 = <any calendar component defined in [RFC2445] or
skipping to change at line 3110 skipping to change at line 3441
/ all / iana-name) / all / iana-name)
paramvalue = paramvalue2 / all / iana-name paramvalue = paramvalue2 / all / iana-name
paramvalue2 = <any value appropriate for the named parameter> paramvalue2 = <any value appropriate for the named parameter>
all = "ALL" all = "ALL"
iana-name = <A name registered with IANA> iana-name = <A name registered with IANA>
Description: The value type is a structured value consisting of a list Description: The value type is a structured value consisting of a
of one or more access control rights rule parts. Each rule part is list of one or more access control rights rule parts. Each rule part
defined by a "NAME=VALUE" pair. The rule parts are separated from each is defined by a "NAME=VALUE" pair. The rule parts are separated from
other by the SEMICOLON character (US-ASCII decimal 59). The rule parts each other by the SEMICOLON character (US-ASCII decimal 59). The rule
are not ordered in any particular sequence, unless otherwise specified parts are not ordered in any particular sequence, unless otherwise
by the ABNF. Individual rule parts MUST only be specified once. specified by the ABNF. Individual rule parts MUST only be specified
once.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 68
The UPN rule part specifies the authenticated calendar user that the The UPN rule part specifies the authenticated calendar user that the
calendar access rights applies to. The value of this rule part is either calendar access rights applies to. The value of this rule part is
a quoted text specifying a UPN or an unquoted text specifying a keyword either a quoted text specifying a UPN or an unquoted text specifying
enumerating a standard authenticated user type. If the value is the a keyword enumerating a standard authenticated user type. If the
keyword is ALL, then the rule applies to all authenticated calendar value is the keyword is ALL, then the rule applies to all
users (i.e., all UPNs). If the value is the keyword OWNER, then the rule authenticated calendar users (i.e., all UPNs). If the value is the
applies to any of the owners of the calendar store or calendar. If the keyword OWNER, then the rule applies to any of the owners of the
value is the keyword NONOWNER, then the rule applies to a UPN that is calendar store or calendar. If the value is the keyword NONOWNER,
not the owner of the calendar store or calendar. If this rule part is then the rule applies to a UPN that is not the owner of the calendar
not specified in the value, then the calendar access rights do not apply store or calendar. If this rule part is not specified in the value,
to any UPN. In this case, the calendar access rights can be defined for then the calendar access rights do not apply to any UPN. In this
reference by another instance of a calendar access rights. For example, case, the calendar access rights can be defined for reference by
a complex set of calendar access rights can be defined once and another instance of a calendar access rights. For example, a complex
set of calendar access rights can be defined once and referenced many
Mansour/Dawson/Royer 57 Expires February 2000 times in the rights specified for individual calendar users.
Taler/Hill
referenced many times in the rights specified for individual calendar
users.
The POLICY rule part specifies a standard calendar access policy. The POLICY rule part specifies a standard calendar access policy.
Calendar access policies are individual sets of well-defined calendar Calendar access policies are individual sets of well-defined calendar
access rights that can be referenced by their policy name. access rights that can be referenced by their policy name.
NOTE: Possible calendar access policy that may be standardized by CAP NOTE: Possible calendar access policy that may be standardized by CAP
include: include:
READBUSYTIMEINFO - Specifies rights for reading busy time data. ? READBUSYTIMEINFO - Specifies rights for reading busy time data.
ACTONBEHALFOF - Specifies rights for any CAP function taken on ? ACTONBEHALFOF - Specifies rights for any CAP function taken on
PUBLIC or PRIVATE calendar components. However, no CAP function PUBLIC or PRIVATE calendar components. However, no CAP function can
can be taken on CONFIDENTIAL classified calendar components. be taken on CONFIDENTIAL classified calendar components.
REQUESTONLY - Specifies rights for creating new event invitations, ? REQUESTONLY - Specifies rights for creating new event invitations,
to-do assignments and journal entries. to-do assignments and journal entries.
UPDATEPARTSTATUS - Specifies rights for modifying ones own ? UPDATEPARTSTATUS - Specifies rights for modifying ones own
participation status. participation status.
OWNER - Specifies the same rights given to the owner of the ? OWNER - Specifies the same rights given to the owner of the
calendar store or calendar. calendar store or calendar.
The CARREF rule part specifies a reference to a particular "VCAR" The CARREF rule part specifies a reference to a particular "VCAR"
calendar component. The text is matched to a CARID property value within calendar component. The text is matched to a CARID property value
a "VCAR" calendar component. This allows for a particular set of within a "VCAR" calendar component. This allows for a particular set
calendar access rights to be defined once and referenced multiple times. of calendar access rights to be defined once and referenced multiple
The "VCAR" identifier specified by this rule part is unique to the times. The "VCAR" identifier specified by this rule part is unique to
calendar store. the calendar store.
The ACTION rule part defines one or more CAP actions that are allowed The ACTION rule part defines one or more CAP actions that are allowed
for the UPN. The valid values are CREATE, COPY, DELETE, MODIFY, MOVE, for the UPN. The valid values are CREATE, COPY, DELETE, MODIFY, MOVE,
READ, corresponding to the calendar commands; PUBLISH, REQUEST, REPLY,
ADD, CANCEL, REFRESH, COUNTER, DECLINECOUNTER, corresponding to the
scheduling commands; and ALL, meaning all of calendaring commands and
scheduling commands. Multiple ACTION enumerations can be specified as a
COMMA character (US-ASCII decimal 44) separated list of ACTION
enumerated values. The text ALL is the same as specifying the enumerated
values "CREATE, MODIFY, DELETE, READ".
The OBJECT rule part defines the calendar store property, calendar Mansour/Dawson/Royer/Taler/Hill
property, calendar component, component property, or parameter that the Expires: April 2000 69
ACTION is restricted to. Multiple OBJECT enumerations can be specified READ, corresponding to the calendar commands; PUBLISH, REQUEST,
as a COMMA character (US-ASCII decimal 44) separated list of OBJECT REPLY, ADD, CANCEL, REFRESH, COUNTER, DECLINECOUNTER, corresponding
enumerated values. The value ALL specifies any and all valid objects. to the scheduling commands; and ALL, meaning all of calendaring
commands and scheduling commands. Multiple ACTION enumerations can be
specified as a COMMA character (US-ASCII decimal 44) separated list
of ACTION enumerated values. The text ALL is the same as specifying
the enumerated values "CREATE, MODIFY, DELETE, READ".
The VALUE rule part specifies the restricted values for the OBJECT rule The OBJECT rule part defines the calendar store property, calendar
part. Multiple VALUE strings can be specified as a COMMA character (US- property, calendar component, component property, or parameter that
ASCII decimal 44) separated list of VALUE strings. The text ALL the ACTION is restricted to. Multiple OBJECT enumerations can be
specifies any and all valid values. If an OBJECT rule part is specified specified as a COMMA character (US-ASCII decimal 44) separated list
but no corresponding VALUE rule part is specified, then the rule applies of OBJECT enumerated values. The value ALL specifies any and all
to any and all valid values of the specified OBJECT(s). valid objects.
Mansour/Dawson/Royer 58 Expires February 2000 The VALUE rule part specifies the restricted values for the OBJECT
Taler/Hill rule part. Multiple VALUE strings can be specified as a COMMA
character (US- ASCII decimal 44) separated list of VALUE strings. The
text ALL specifies any and all valid values. If an OBJECT rule part
is specified but no corresponding VALUE rule part is specified, then
the rule applies to any and all valid values of the specified
OBJECT(s).
Example: The following is a rule which specifies access rights for "foo" Example: The following is a rule which specifies access rights for
calendar user to read busy time values: "foo" calendar user to read busy time values:
UPN="foo@host.com";ACTION=READ;OBJECT=DTSTART,DTEND UPN="foo@host.com";ACTION=READ;OBJECT=DTSTART,DTEND
14.2 VCAR Calendar Component 14.4 VCAR Calendar Component
Component Name: "VCAR" Component Name: "VCAR"
Purpose: Provide a grouping of calendar access rights. Purpose: Provide a grouping of calendar access rights.
Format Definition: A "VCAR" calendar component is defined by the Format Definition: A "VCAR" calendar component is defined by the
following notation: following notation:
aclc = "BEGIN" ":" "VCAR" CRLF aclc = "BEGIN" ":" "VCAR" CRLF
carprop carprop
"END" ":" "VCAR" CRLF "END" ":" "VCAR" CRLF
carprop = carid 1*(grant / deny) carprop = carid 1*(grant / deny)
Description: A "VCAR" calendar component is a grouping of calendar Description: A "VCAR" calendar component is a grouping of calendar
access rights component properties. access rights component properties.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 70
The "CARID" property specifies the local identifier for the "VCAR" The "CARID" property specifies the local identifier for the "VCAR"
calendar component. The "GRANT" property specifies calendar access calendar component. The "GRANT" property specifies calendar access
rights granted to an UPN. The "DENY" property specifies calendar access rights granted to an UPN. The "DENY" property specifies calendar
rights denied from an UPN. access rights denied from an UPN.
Example: In the following example, the UPN "foo@host.com" has read Example: In the following example, the UPN "foo@host.com" has read
access to the "DTSTART" and "DTEND" calendar properties. No other access access to the "DTSTART" and "DTEND" calendar properties. No other
is specified: access is specified:
BEGIN:VCAR BEGIN:VCAR
CARID:"View Start and End Times" CARID:"View Start and End Times"
GRANT:UPN="foo@host.com";ACTION="READ";OBJECT=DTSTART,DTEND GRANT:UPN="foo@host.com";ACTION="READ";OBJECT=DTSTART,DTEND
END:VEVENT END:VEVENT
In this example, all UPNs are given read access to "DTSTART" and In this example, all UPNs are given read access to "DTSTART" and
"DTEND". "All CUs" is specified by the UPN value "ALL". Note that this "DTEND". "All CUs" is specified by the UPN value "ALL". Note that
enumerated UPN value is not in quotes.: this enumerated UPN value is not in quotes.:
BEGIN:VCAR BEGIN:VCAR
CARID:"View Start and End Times 2" CARID:"View Start and End Times 2"
GRANT:UPN=ALL;ACTION=READ;OBJECT=DTSTART,DTEND GRANT:UPN=ALL;ACTION=READ;OBJECT=DTSTART,DTEND
END:VCAR END:VCAR
In this example, rights are specified for all UPNs to read components In this example, rights are specified for all UPNs to read components
classified as PUBLIC: classified as PUBLIC:
BEGIN:VCAR BEGIN:VCAR
CARID:"View PUBLIC Start and End Times" CARID:"View PUBLIC Start and End Times"
Mansour/Dawson/Royer 59 Expires February 2000
Taler/Hill
GRANT:UPN=ALL;ACTION=READ;OBJECT=DTSTART;DTEND GRANT:UPN=ALL;ACTION=READ;OBJECT=DTSTART;DTEND
DENY:UPN=ALL;ACTION=READ;OBJECT=CLASS;VALUE=PUBLIC, DENY:UPN=ALL;ACTION=READ;OBJECT=CLASS;VALUE=PUBLIC,
CONFIDENTIAL CONFIDENTIAL
END:VCAR END:VCAR
In this example, rights are specified for all UPNs to read or modify In this example, rights are specified for all UPNs to read or modify
existing components classified as PUBLIC: existing components classified as PUBLIC:
BEGIN:VCAR BEGIN:VCAR
CARID:"Read and Modify PUBLIC Calendar Entries" CARID:"Read and Modify PUBLIC Calendar Entries"
GRANT:UPN=ALL;ACTION=READ,MODIFY;OBJECT=ALL GRANT:UPN=ALL;ACTION=READ,MODIFY;OBJECT=ALL
DENY:UPN=ALL;ACTION=READ,MODIFY;OBJECT=CLASS;VALUE=PRIVATE, DENY:UPN=ALL;ACTION=READ,MODIFY;OBJECT=CLASS;VALUE=PRIVATE,
CONFIDENTIAL CONFIDENTIAL
END:VCAR END:VCAR
In this example, rights are given to a standard calendar access right In this example, rights are given to a standard calendar access right
policy of "viewing" (i.e., READ) busy time information: policy of "viewing" (i.e., READ) busy time information:
BEGIN:VCAR BEGIN:VCAR
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 71
CARID:"View Busy Time Information" CARID:"View Busy Time Information"
GRANT:UPN=ALL;POLICY=READBUSYTIMEINFO GRANT:UPN=ALL;POLICY=READBUSYTIMEINFO
END:VCAR END:VCAR
In this example, full calendar access rights are given to the OWNER and In this example, full calendar access rights are given to the OWNER
a hypothetical administrator is given access rights to specify calendar and a hypothetical administrator is given access rights to specify
access rights. If no other rights are specified, only these two UPNs can calendar access rights. If no other rights are specified, only these
specify calendar access rights: two UPNs can specify calendar access rights:
BEGIN:VCAR BEGIN:VCAR
CARID:"Only OWNER or ADMIN Settable CARs" CARID:"Only OWNER or ADMIN Settable CARs"
GRANT:UPN=OWNER;ACTION=ALL;OBJECT=ALL GRANT:UPN=OWNER;ACTION=ALL;OBJECT=ALL
GRANT:UPN="cal-admin@host.com";ACTION=ALL; GRANT:UPN="cal-admin@host.com";ACTION=ALL;
OBJECT=VCAR,CARID,GRANT,DENY OBJECT=VCAR,CARID,GRANT,DENY
END:VCAR END:VCAR
In this example, rights to create, read, modify or delete calendar In this example, rights to create, read, modify or delete calendar
access rights are denied to all UPNs. This example would disable access rights are denied to all UPNs. This example would disable
providing different access rights to the calendar store or calendar. providing different access rights to the calendar store or calendar.
This calendar access rights should not be specified, as they the ability This calendar access rights should not be specified, as they the
to change calendar access; even for the owner or administrator: ability to change calendar access; even for the owner or
administrator:
BEGIN:VCAR BEGIN:VCAR
CARID:"No CAR At All" CARID:"No CAR At All"
DENY:UPN=ALL;OBJECT=VCAR,CARID,GRANT,DENY DENY:UPN=ALL;OBJECT=VCAR,CARID,GRANT,DENY
14.3 GRANT Component Property 14.5 GRANT Component Property
Property Name: GRANT Property Name: GRANT
Purpose: This property specifies those access rights granted to a UPN. Purpose: This property specifies those access rights granted to a
UPN.
Value Type: RIGHTS Value Type: RIGHTS
Mansour/Dawson/Royer 60 Expires February 2000
Taler/Hill
Property Parameters: Only non-standard property parameters can be Property Parameters: Only non-standard property parameters can be
specified on this property. specified on this property.
Conformance: This property can only be specified in "VCAR" calendar Conformance: This property can only be specified in "VCAR" calendar
component. component.
Description: This property is used to grant calendar access rights to a Description: This property is used to grant calendar access rights to
UPN. a UPN.
Format Definition: The property is defined by the following notation: Format Definition: The property is defined by the following notation:
grant = "GRANT" rightsparam ":" rights CRLF Mansour/Dawson/Royer/Taler/Hill
rightparam = *(";" xparam) Expires: April 2000 72
grant = "GRANT" rightsparam ":" rights CRLF rightparam = *(";"
xparam)
Example: In the following example, a hypothetical "guest@host.com" UPN Example: In the following example, a hypothetical "guest@host.com"
is granted rights to view busy time information. These rights are UPN is granted rights to view busy time information. These rights are
specified by referencing a standard calendar access rights policy, by specified by referencing a standard calendar access rights policy, by
name: name:
GRANT:UPN="guest@host.com";POLICY="READBUSYTIMEINFO" GRANT:UPN="guest@host.com";POLICY="READBUSYTIMEINFO"
14.4 DENY Component Property 14.6 DENY Component Property
Property Name: DENY Property Name: DENY
Purpose: This property specifies those access rights denied from a UPN. Purpose: This property specifies those access rights denied from a
UPN.
Value Type: RIGHTS Value Type: RIGHTS
Property Parameters: Only non-standard property parameters can be Property Parameters: Only non-standard property parameters can be
specified on this property. specified on this property.
Conformance: This property can only be specified in "VCAR" calendar Conformance: This property can only be specified in "VCAR" calendar
component. component.
Description: This property is used to deny calendar access rights to a Description: This property is used to deny calendar access rights to
UPN. a UPN.
Format Definition: The property is defined by the following notation: Format Definition: The property is defined by the following notation:
DENY = "DENY" rightsparam ":" rights CRLF DENY = "DENY" rightsparam ":" rights CRLF rightsparam = *(";"
rightsparam = *(";" xparam) xparam)
Example: In the following example, any UPN who is not the owner is Example: In the following example, any UPN who is not the owner is
denied rights to create, modify or delete entries: denied rights to create, modify or delete entries:
DENY:UPN=NONOWNER;ACTION=CREATE,MODIFY,DELETE;OBJECT=ALL DENY:UPN=NONOWNER;ACTION=CREATE,MODIFY,DELETE;OBJECT=ALL
14.5 VCAR Identifier Component Property 14.7 VCAR Identifier Component Property
Property Name: CARID Property Name: CARID
Mansour/Dawson/Royer 61 Expires February 2000
Taler/Hill
Purpose: This property specifies the identifier for a "VCAR" calendar Purpose: This property specifies the identifier for a "VCAR" calendar
component. component.
Value Type: TEXT Value Type: TEXT
Property Parameters: Non-standard property parameters can be specified Mansour/Dawson/Royer/Taler/Hill
on this property. Expires: April 2000 73
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: This property can be specified in "VCAR" calendar Conformance: This property can be specified in "VCAR" calendar
component. component.
Description: This property permits previously defined sets of calendar Description: This property permits previously defined sets of
access rights to be specified with a reference. This capability calendar access rights to be specified with a reference. This
facilitates repetitively specifying calendar access rights. capability facilitates repetitively specifying calendar access
rights.
Format Definition: The property is defined by the following notation: Format Definition: The property is defined by the following notation:
CARID = "CARID" textparam ":" text CRLF CARID = "CARID" textparam ":" text CRLF
Example: The following is an example of this property: Example: The following is an example of this property:
CARID:"Restrict Guests From Creating ALARMs On Events" CARID:"Restrict Guests From Creating ALARMs On Events"
14.6 REQUEST-STATUS property 14.8 REQUEST-STATUS property
This description is a revision of the REQUEST-STATUS property for This description is a revision of the REQUEST-STATUS property for
VCALENDAR version 2.1. VCALENDAR version 2.1.
rstatus = "REQUEST-STATUS" rstatparam ":" rstatus = "REQUEST-STATUS" rstatparam ":"
statcode [";" statdesc [";" extdata]] statcode [";" statdesc [";" extdata]]
rstatparam = *( rstatparam = *(
; the following is optional, ; the following is optional,
; but MUST NOT occur more than once ; but MUST NOT occur more than once
skipping to change at line 3407 skipping to change at line 3743
) )
statcode = 1*DIGIT *("." 1*DIGIT) statcode = 1*DIGIT *("." 1*DIGIT)
;Hierarchical, numeric return status code ;Hierarchical, numeric return status code
statdesc = text statdesc = text
;An optional textual status description, content is ;An optional textual status description, content is
;decided by the implementor. May be empty. ;decided by the implementor. May be empty.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 74
extdata = text extdata = text
;Textual exception data. For example, the offending property ;Textual exception data. For example, the offending property
Mansour/Dawson/Royer 62 Expires February 2000
Taler/Hill
;name and value or complete property line. ;name and value or complete property line.
Example: The following are some possible examples of this property. The Example: The following are some possible examples of this property.
COMMA and SEMICOLON separator characters in the property value are The COMMA and SEMICOLON separator characters in the property value
BACKSLASH character escaped because they appear in a text value. are BACKSLASH character escaped because they appear in a text value.
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
REQUEST-STATUS:2.0;Success despite braindead LDAP implementation REQUEST-STATUS:2.0;Success despite braindead LDAP implementation
REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01
REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled REQUEST-STATUS:2.8; Success repeating event ignored. Scheduled
as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 as a single event.;RRULE:FREQ=WEEKLY;INTERVAL=2
REQUEST-STATUS:4.1;Event conflict. Date/time is busy. REQUEST-STATUS:4.1;Event conflict. Date/time is busy.
REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
MAILTO:jsmith@host.com MAILTO:jsmith@host.com
REQUEST-STATUS:3.7;;ATTENDEE:MAILTO:jsmith@host.com REQUEST-STATUS:3.7;;ATTENDEE:MAILTO:jsmith@host.com
REQUEST-STATUS:10.4;Help! That really shouldn't have happened. REQUEST-STATUS:10.4;Help! That really shouldnt have happened.
15. CAP Entities Registration 15. CAP Entities Registration
This section provides the process for registration of new or modified This section provides the process for registration of new or modified
CAP entities. CAP entities.
15.1 Registration of New and Modified CAP Entities 15.1 Registration of New and Modified CAP Entities New CAP entities
New CAP entities are registered by the publication of an IETF Request are registered by the publication of an IETF Request for Comment
for Comment (RFC). Changes to a CAP entity are registered by the (RFC). Changes to a CAP entity are registered by the publication of a
publication of a revision of the RFC defining the method. revision of the RFC defining the method.
15.2 Registration of New Entities 15.2 Registration of New Entities
This section defines procedures by which new entities (i.e., components,
properties, parameters, enumerated values or restriction tables) for a
CAP entity can be registered with the IANA.
Non-standard, experimental entities can be used by bilateral agreement, This section defines procedures by which new entities (i.e.,
provided the associated properties names follow the "X-" convention. components, properties, parameters, enumerated values or restriction
Such non-standard entities are non-IANA entities and need not be tables) for a CAP entity can be registered with the IANA.
registered using this process.
Non-standard, experimental entities can be used by bilateral
agreement, provided the associated properties names follow the "X-"
convention. Such non-standard entities are non-IANA entities and
need not be registered using this process.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 75
The procedures defined here are designed to allow public comment and The procedures defined here are designed to allow public comment and
review of new CAP entities, while posing only a small impediment to the review of new CAP entities, while posing only a small impediment to
definition of new properties. the definition of new properties.
Registration of a new CAP entity is accomplished by the following steps. Registration of a new CAP entity is accomplished by the following
steps.
15.2.1 Define the Entity 15.2.1 Define the Entity A CAP entity is defined by completing the
A CAP entity is defined by completing the following template. following template.
To: ietf-calendar@imc.org To: ietf-calendar@imc.org
Mansour/Dawson/Royer 63 Expires February 2000
Taler/Hill
Subject: Registration of CAP entity XXX Subject: Registration of CAP entity XXX
Entity name: Entity name:
Entity purpose: Entity purpose:
Description: Description:
CAP terminology changes: CAP terminology changes:
CAP data model changes: CAP data model changes:
CAP system model changes: CAP system model changes:
Conformance considerations: Conformance considerations:
Format definition: Format definition:
Examples: Examples:
The meaning of each field in the template is as follows. The meaning of each field in the template is as follows.
Entity name: The name of the entity. Entity name: The name of the entity.
Entity purpose: The purpose of the entity (e.g., Extends the CAP command Entity purpose: The purpose of the entity (e.g., Extends the CAP
set to poll for notifications, etc.). Give a short but clear command set to poll for notifications, etc.). Give a short but clear
description. description.
Description: Any special notes about the entity, how it is to be used, Description: Any special notes about the entity, how it is to be
etc. used, etc.
CAP terminology changes: Any change or additions to the existing CAP CAP terminology changes: Any change or additions to the existing CAP
terminology needs to be specified. terminology needs to be specified.
CAP data model changes: Any of the valid property parameters for the CAP data model changes: Any of the valid property parameters for the
property needs to be specified. property needs to be specified.
CAP system model changes: CAP system model changes:
Conformance: A clear summary of how and where this CAP entity extension Conformance: A clear summary of how and where this CAP entity
MUST, MAY, SHOULD or can be used. Any changes or impact to the existing extension MUST, MAY, SHOULD or can be used. Any changes or impact to
conformance definition for CAP should be explained. The impact to the existing conformance definition for CAP should be explained. The
implmentations conforming to the existing CAP specification should be impact to implmentations conforming to the existing CAP specification
clearly described. should be clearly described.
Format definition: The ABNF for each element of the CAP entity needs to Mansour/Dawson/Royer/Taler/Hill
be specified. Expires: April 2000 76
Format definition: The ABNF for each element of the CAP entity needs
to be specified.
Examples: One or more examples of instances of the CAP entity and each Examples: One or more examples of instances of the CAP entity and
of its usage scenarios needs to be specified. each of its usage scenarios needs to be specified.
15.2.2 Post the entity definition 15.2.2 Post the entity definition
The entity description MUST be posted to the new entity discussion list,
ietf-calendar@imc.org. The entity description MUST be posted to the new entity discussion
list, ietf-calendar@imc.org.
15.2.3 Allow a comment period 15.2.3 Allow a comment period
Discussion on the new entity MUST be allowed to take place on the list
for a minimum of two weeks. Consensus MUST be reached on the property Discussion on the new entity MUST be allowed to take place on the
before proceeding to the next step. list for a minimum of two weeks. Consensus MUST be reached on the
property before proceeding to the next step.
15.2.4 Submit the entity for approval 15.2.4 Submit the entity for approval
Once the two-week comment period has elapsed, and the proposer is Once the two-week comment period has elapsed, and the proposer is
convinced consensus has been reached on the entity, the registration convinced consensus has been reached on the entity, the registration
application should be submitted to the Method Reviewer for approval.
Mansour/Dawson/Royer 64 Expires February 2000 The Method Reviewer is appointed by the Application Area Directors
Taler/Hill and can either accept or reject the entity registration. An accepted
registration should be passed on by the Method Reviewer to the IANA
application should be submitted to the Method Reviewer for approval. The for inclusion in the official IANA method registry. The registration
Method Reviewer is appointed by the Application Area Directors and can can be rejected for any of the following reasons. 1) Insufficient
either accept or reject the entity registration. An accepted comment period; 2) Consensus not reached; 3) Technical deficiencies
registration should be passed on by the Method Reviewer to the IANA for raised on the list or elsewhere have not been addressed. The Method
inclusion in the official IANA method registry. The registration can be Reviewer's decision to reject an entity can be appealed by the
rejected for any of the following reasons. 1) Insufficient comment proposer to the IESG, or the objections raised can be addressed by
period; 2) Consensus not reached; 3) Technical deficiencies raised on the proposer and the entity resubmitted.
the list or elsewhere have not been addressed. The Method Reviewer's
decision to reject an entity can be appealed by the proposer to the
IESG, or the objections raised can be addressed by the proposer and the
entity resubmitted.
[Ed note: John Stracke to review any updates] [Ed note: John Stracke to review any updates]
15.3 Property Change Control 15.3 Property Change Control
Existing CAP entities can be changed using the same process by which Existing CAP entities can be changed using the same process by which
they were registered. they were registered.
1. 1. Define the change 2. Post the change 3. Allow a comment period 4.
Define the change
2.
Post the change
3.
Allow a comment period
4.
Submit the entity for approval Submit the entity for approval
Note that the original author or any other interested party can propose Note that the original author or any other interested party can
a change to an existing CAP entity, but that such changes should only be propose a change to an existing CAP entity, but that such changes
proposed when there are serious omissions or errors in the published should only be proposed when there are serious omissions or errors in
memo. The Method Reviewer can object to a change if it is not backward
compatible, but is not required to do so.
CAP entity definitions can never be deleted from the IANA registry, but Mansour/Dawson/Royer/Taler/Hill
entities which are no longer believed to be useful can be declared Expires: April 2000 77
OBSOLETE by adding this text to their "Entity purpose" field. the published memo. The Method Reviewer can object to a change if it
is not backward compatible, but is not required to do so.
CAP entity definitions can never be deleted from the IANA registry,
but entities which are no longer believed to be useful can be
declared OBSOLETE by adding this text to their "Entity purpose"
field.
16. IANA Considerations 16. IANA Considerations
This memo defines IANA registered extensions to the attributes defined This memo defines IANA registered extensions to the attributes
by iCalendar, as defined in [RFC2445], and iTIP, as defined in defined by iCalendar, as defined in [RFC2445], and iTIP, as defined
[RFC2426]. in [RFC2426].
IANA registration proposals for iCalendar and iTIP are to be emailed to IANA registration proposals for iCalendar and iTIP are to be emailed
the registration agent for the "text/calendar" MIME content-type, to the registration agent for the "text/calendar" MIME content-type,
<MAILTO: ietf-calendar@imc.org> using the format defined in section 7 of <MAILTO: ietf-calendar@imc.org> using the format defined in section 7
[RFC2445]. of [RFC2445].
17. Acknowledgments 17. Acknowledgments
The following have individuals were major contributors in the drafting
and discussion of this memo:
Mario Bonin, Andre Courtemanche, Dave Crocker, Pat Egen, Gilles Fortin, The following have individuals were major contributors in the
Alex Hoppman, Bruce Kahn, Lisa Lippert, David Madeo, Bob Mahoney, Pete drafting and discussion of this memo:
O'Leary, Richard Shusterman, Tony Small, John Stracke.
Mansour/Dawson/Royer 65 Expires February 2000 Mario Bonin, Andre Courtemanche, Dave Crocker, Pat Egen, Gilles
Taler/Hill Fortin, Alex Hoppman, Bruce Kahn, Lisa Lippert, David Madeo, Bob
Mahoney, Pete O'Leary, Richard Shusterman, Tony Small, John Stracke.
18. Bibliography 18. Bibliography
[RFC1521] N. Borenstein and N. Freed, "MIME (Multipurpose Internet Mail
Specifying and Describing the Format of Internet Message Bodies", RFC [RFC1521] N. Borenstein and N. Freed, "MIME (Multipurpose Internet
1521, Bellcore, Innosoft, September 1993. Mail Extensions) Part One: Mechanisms for Internet Draft UTF-825
July 1996 Specifying and Describing the Format of Internet Message
Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
[TLS] Dierks, Allen, "The TLS Protocol", RFC 2246, January 1999 [TLS] Dierks, Allen, "The TLS Protocol", RFC 2246, January 1999
[RFC2396] Berners-Lee, Fielding, Masinter, "Uniform Resource Identifiers [RFC2608] Guttman, Perkins, Veizades, Day, "Service Location
(URI): Generic Syntax", RFC 2396, August 1998. protocol, Version 2", RFC2608, June 1999.
[RFC2445] Dawson, Stenerson, "Internet Calendaring and Scheduling Core [RFC2609] Guttman, Perkins, Kempf, "Service Templates and Service:
Object Specification (iCalendar)", RFC 2445, November 1998 Schemes", RFC2609, June 1999.
[RFC2396] Berners-Lee, Fielding, Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2445] Dawson, Stenerson, "Internet Calendaring and Scheduling
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 78
Core Object Specification (iCalendar)", RFC 2445, November 1998
[RFC2446] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport- [RFC2446] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport-
Independent Interoperability Protocol (iTIP)", RFC 2446, November 1998 Independent Interoperability Protocol (iTIP)", RFC 2446, November
1998
[RFC2447] Dawson, Mansour, Silverberg, "iCalendar Message-Based [RFC2447] Dawson, Mansour, Silverberg, "iCalendar Message-Based
Interoperability Protocol (iMIP)", RFC 2445, November 1998 Interoperability Protocol (iMIP)", RFC 2445, November 1998
[SQL] "Database Language _ SQL", ANSI/ISO/IEC 9075: 1992, aka ANSI [SQL] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka ANSI
X3.135-1992, aka FiPS PUB 127-2 X3.135-1992, aka FiPS PUB 127-2
[SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 to [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 to
ISO/IEC 9075: 1992, also adopted as Amendment 1 to ANSI X3.135.1992 ISO/IEC 9075: 1992, also adopted as Amendment 1 to ANSI X3.135.1992
[UNICODE] The Unicode Consortium, "The Unicode Standard --Worldwide [UNICODE] The Unicode Consortium, "The Unicode Standard --Worldwide
Character Encoding -- Version 1.0", Addison-Wesley, Volume 1, 1991, Character Encoding -- Version 1.0", Addison-Wesley, Volume 1, 1991,
Volume 2, 1992. UTF-8 is described in Unicode Technical Report #4. Volume 2, 1992. UTF-8 is described in Unicode Technical Report #4.
[US-ASCII] Coded Character Set--7-bit American Standard Code for [US-ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986. Information Interchange, ANSI X3.4-1986.
19. Author's Address 19. Author's Address The following address information is provided in a
The following address information is provided in a vCard v3.0, the RFC vCard v3.0, the RFC 2426 electronic business card format.
2426 electronic business card format.
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0 VERSION:3.0
N:Dawson;Frank N:Dawson;Frank
FN:Frank Dawson FN:Frank Dawson
ORG:Lotus Development Corporation ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;Raleigh;NC; ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;Raleigh;NC;
27613-3502;US 27613-3502;US
TEL;TYPE=PREF,WORK,MSG:+1-617-693-8728 TEL;TYPE=PREF,WORK,MSG:+1-617-693-8728
TEL;TYPE=WORK,MSG:+1-919-676-9515 TEL;TYPE=WORK,MSG:+1-919-676-9515
TEL;TYPE=WORK,FAX:+1-919-676-9515 TEL;TYPE=WORK,FAX:+1-919-676-9515
EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL;TYPE=X-HOME:http://home.earthlink.net/~fdawson URL;TYPE=X-HOME:http://home.earthlink.net/~fdawson
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0 VERSION:3.0
Mansour/Dawson/Royer 66 Expires February 2000
Taler/Hill
N:Mansour;Steve N:Mansour;Steve
FN:Steve Mansour FN:Steve Mansour
ORG:Netscape ORG:Netscape
ADR;TYPE=WORK,POSTAL,PARCEL:;;501 E Middlfield Road;Mountain ADR;TYPE=WORK,POSTAL,PARCEL:;;501 E Middlfield Road;Mountain
View;CA;94043;US View;CA;94043;US
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 79
TEL;WORK;MSG:+1-650-937-2378 TEL;WORK;MSG:+1-650-937-2378
TEL;WORK;FAX:+1-650-937-2103 TEL;WORK;FAX:+1-650-937-2103
EMAIL;INTERNET:sman@netscape.com EMAIL;INTERNET:sman@netscape.com
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0 VERSION:3.0
FN:Doug Royer FN:Doug Royer
N:Royer;Doug N:Royer,Doug
ORG:Sun Microsystems ORG:Software.com
ADR;TYPE=WORK,POSTAL,PARCEL:MS MPK17-105;;901 San Antonio Road; ADR;TYPE=WORK,POSTAL,PARCEL:Suite 106;;530 E. Montecito St;
Palo Alto;CA;94303-4900 Santa Barbara;CA;93103
TEL;TYPE=WORK,VOICE:650-786-7599 TEL;TYPE=WORK,VOICE:805-957-1790 x541
TEL;TYPE=FAX:650-786-7994 TEL;TYPE=FAX:805-957-1544
EMAIL;TYPE=INTERNET:doug.royer@sun.com EMAIL;TYPE=INTERNET:Doug.Royer@Software.com
URL;TYPE=X-HOME:http://Royer.com/People/Doug
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0 VERSION:3.0
FN:Alexander Taler FN:Alexander Taler
N:Taler;Alexander N:Taler;Alexander
ORG:CS&T ORG:CS&T
ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC; ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC;
H3R 3L5;Canada H3R 3L5;Canada
TEL;TYPE=WORK,VOICE:514-733-8500 TEL;TYPE=WORK,VOICE:514-733-8500
skipping to change at line 3677 skipping to change at line 4023
N:Taler;Alexander N:Taler;Alexander
ORG:CS&T ORG:CS&T
ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC; ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC;
H3R 3L5;Canada H3R 3L5;Canada
TEL;TYPE=WORK,VOICE:514-733-8500 TEL;TYPE=WORK,VOICE:514-733-8500
TEL;TYPE=FAX:514-733-8878 TEL;TYPE=FAX:514-733-8878
EMAIL;TYPE=INTERNET:alext@cst.ca EMAIL;TYPE=INTERNET:alext@cst.ca
END:VCARD END:VCARD
20. Full Copyright Statement 20. Full Copyright Statement
"Copyright (C) The Internet Society (1999). All Rights Reserved. "Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it
assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are
on all such copies and derivative works. However, this document itself included on all such copies and derivative works. However, this
may not be modified in any way, such as by removing the copyright notice document itself may not be modified in any way, such as by removing
or references to the Internet Society or other Internet organizations, the copyright notice or references to the Internet Society or other
except as needed for the purpose of developing Internet standards in Internet organizations, except as needed for the purpose of
which case the procedures for copyrights defined in the Internet developing Internet standards in which case the procedures for
Standards process MUST be followed, or as required to translate it into copyrights defined in the Internet Standards process MUST be
languages other than English. followed, or as required to translate it into languages other than
English.
Mansour/Dawson/Royer/Taler/Hill
Expires: April 2000 80
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns. This
This document and the information contained herein is provided on an "AS document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
Mansour/Dawson/Royer 67 Expires February 2000
Taler/Hill
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
FITNESS FOR A PARTICULAR PURPOSE. OR FITNESS FOR A PARTICULAR PURPOSE.
Mansour/Dawson/Royer 68 Expires February 2000 Mansour/Dawson/Royer/Taler/Hill
Taler/Hill Expires: April 2000 81
 End of changes. 400 change blocks. 
1207 lines changed or deleted 1552 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/