Internet Draft CAP March 10, 2000 Network Working Group Steve Mansour/Netscape Internet Draft Frank Dawson/Lotus <draft-ietf-calsch-cap-02.txt> Doug Royer/Software.com Alexander Taler/CS&T Paul Hill/MIT Expires six months from: March 10, 2000 Calendar Access Protocol (CAP) Status of this Memo This memo is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt . The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Copyright Statement Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract The Calendar Access Protocol (CAP) is an Internet protocol that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [RFC2445] based Calendar Store (CS). This memo defines the CAP specification. The CAP definition is based on requirements identified by the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) Working Group. More information about the IETF CALSCH Working Group activities can be found on the IMC web site at http://www.imc.org/ietf-calendar, and at the IETF web site at Mansour/Dawson/Royer/Taler/Hill 1 Expires September 2000 Internet Draft CAP March 10, 2000 http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this memo for further information on how to access these various documents. Mansour/Dawson/Royer/Taler/Hill 2 Expires September 2000 Internet Draft CAP March 10, 2000 Table of Contents 1. Introduction ................................................... 3 1.1. Formatting Conventions ....................................... 3 1.2. Related Documents ............................................ 3 1.3. Definitions .................................................. 4 2. CAP Design ..................................................... 10 2.1. System Model ................................................. 10 2.2. Calendar Store Object Model .................................. 11 2.3. Protocol Model ............................................... 11 2.4. Security Model ............................................... 13 2.4.1. Authentication, Credentials, and Identity .................. 14 2.4.2. Calendar User and UPNs ..................................... 14 2.4.2.1. UPNs and Certificates .................................... 15 2.4.2.2. Anonymous Users and Authentication ....................... 16 2.4.2.3. Required Security Mechanisms ............................. 16 2.4.2.4. TLS Ciphersuites ......................................... 17 2.4.3. User Groups ................................................ 17 2.4.4. Access Rights .............................................. 18 2.4.4.1. VCalendar Access Right (VCAR) ........................... 18 2.4.4.2. Decreed VCARs ............................................ 19 2.4.4.3. Inheritance .............................................. 19 2.4.5. CAP session identity ....................................... 19 2.5. Roles ........................................................ 20 2.6. Calendar Addresses ........................................... 21 2.7. Extensions to iCalendar ...................................... 21 2.8. Relationship of RFC 2446 (ITIP) to CAP ....................... 22 2.9. VCalendar Access Rights (VCARs) .............................. 23 2.10. Query Schema ................................................ 23 3. State Diagram .................................................. 23 4. Protocol Framework ............................................. 25 4.1. CAP Application Layer ........................................ 25 4.2. CAP Transfer Protocol ........................................ 25 4.3. Response Format .............................................. 25 4.4. Auto-logout Timer ............................................ 26 4.5. Bounded Latency .............................................. 26 4.6. Data Elements ................................................ 27 5. Formal Command Syntax .......................................... 27 5.1. Searching and Filtering ...................................... 27 5.1.1. Grammar For Search Mechanism ............................... 27 6. Access Rights .................................................. 28 6.1. VCAR Inheritance ............................................. 28 6.2. Access Control and NOCONFLICT ................................ 28 7. Commands and Responses ......................................... 29 7.1. Transfer Protocol Commands ................................... 29 7.1.1. Initial Connection ......................................... 29 7.1.2. ABORT Command .............................................. 30 7.1.3. AUTHENTICATE Command ....................................... 30 7.1.3.1. AUTHENTICATE ANONYMOUS ................................... 33 7.1.4. CALIDEXPAND Command ........................................ 34 7.1.5. CAPABILITY Command ......................................... 35 7.1.6. CONTINUE Command ........................................... 36 7.1.7. DISCONNECT Command ......................................... 37 7.1.8. IDENTIFY Command ........................................... 38 Mansour/Dawson/Royer/Taler/Hill Expires September 2000 Internet Draft CAP March 10, 2000 7.1.9. SENDDATA Command ........................................... 38 7.1.10. STARTTLS Command .......................................... 38 7.1.10.1. UPNEXPAND Method ........................................ 39 7.2. Application Protocol Commands ................................ 40 7.2.1. Calendaring Commands ....................................... 40 7.2.1.1. CREATE Method ............................................ 40 7.2.1.1.1. Creating New Calendars ................................. 41 7.2.1.2. DELETE Method ............................................ 43 7.2.1.3. GENERATEUID Method ....................................... 44 7.2.1.4. MODIFY Method ............................................ 44 7.2.1.5. MOVE Method .............................................. 45 7.2.1.6. NOOP Method .............................................. 46 7.2.1.7. READ Method .............................................. 46 7.2.2. Scheduling Commands ........................................ 50 7.2.2.1. Reading out scheduling components ........................ 50 7.2.2.2. PUBLISH .................................................. 51 7.2.2.3. REQUEST .................................................. 52 7.2.2.4. REPLY .................................................... 52 7.2.2.5. ADD ...................................................... 52 7.2.2.6. CANCEL ................................................... 52 7.2.2.7. REFRESH .................................................. 52 7.2.2.8. COUNTER .................................................. 52 7.2.2.9. DECLINECOUNTER ........................................... 52 7.2.3. iTIP Examples .............................................. 52 7.2.3.1. Sending and Receiving an iTIP request .................... 52 7.2.3.2. Handling an iTIP refresh ................................. 55 7.2.3.3. Sending and accepting an iTIP counter .................... 56 7.2.3.4. Declining an iTIP counter ................................ 57 8. Response Codes ................................................. 58 8.1. Minimum CS query implementation .............................. 60 8.1.1. Query by UID ............................................... 60 8.1.2. Query by Date / Date-Time range ............................ 60 8.1.2.1. Date/Date-Time query with subset of properties ........... 60 8.1.3. <TBD> ...................................................... 60 9. Detailed SQL Schema ............................................ 60 9.1. iCalendar Store Schema ....................................... 62 9.1.1. ACTION schema .............................................. 62 9.1.2. ATTACH schema .............................................. 63 9.1.3. ATTENDEE schema ............................................ 63 9.1.4. CALSTORE schema ............................................ 63 9.1.5. CHILDREN schema ............................................ 64 9.1.6. CLASS schema ............................................... 64 9.1.7. CN schema .................................................. 64 9.1.8. COMMENT schema ............................................. 64 9.1.9. CONTACT schema ............................................. 64 9.1.10. CREATED schema ............................................ 65 9.1.11. CUTYPE schema ............................................. 65 9.1.12. DAYLIGHT_STANDARD schema .................................. 65 9.1.13. DESCRIPTION schema ........................................ 65 9.1.14. DIR schema ................................................ 66 9.1.15. DTEND schema .............................................. 66 9.1.16. DTSTAMP schema ............................................ 66 9.1.17. DUE schema ................................................ 66 Mansour/Dawson/Royer/Taler/Hill Expires September 2000 Internet Draft CAP March 10, 2000 9.1.18. DURATION schema ........................................... 67 9.1.19. EXDATE schema ............................................. 67 9.1.20. EXRULE schema ............................................. 67 9.1.21. FBTYPE schema ............................................. 67 9.1.22. FMTTYPE schema ............................................ 67 9.1.23. FREEBUSY schema ........................................... 68 9.1.24. GEO schema ................................................ 68 9.1.25. LANGUAGE schema ........................................... 68 9.1.26. LAST_MODIFIED schema ...................................... 68 9.1.27. MEMBER schema ............................................. 68 9.1.28. METHOD schema ............................................. 69 9.1.29. ORGANIZER schema .......................................... 69 9.1.30. OWNERS schema ............................................. 69 9.1.31. PARTSTAT schema ........................................... 69 9.1.32. PERCENT_COMPLETE schema ................................... 70 9.1.33. PRIORITY schema ........................................... 70 9.1.34. RDATE schema .............................................. 70 9.1.35. RECUR schema .............................................. 70 9.1.36. RECURRENCE_ID schema ...................................... 71 9.1.37. RELATED_TO schema ......................................... 72 9.1.38. REPEAT schema ............................................. 72 9.1.39. RESOURCES schema .......................................... 72 9.1.40. ROLE schema ............................................... 72 9.1.41. RRULE schema .............................................. 73 9.1.42. SEQUENCE schema ........................................... 73 9.1.43. STATUS schema ............................................. 73 9.1.44. SUMMARY schema ............................................ 73 9.1.45. TRANSP schema ............................................. 73 9.1.46. TRIGGER schema ............................................ 74 9.1.47. TZID schema ............................................... 74 9.1.48. UID schema ................................................ 74 9.1.49. URL schema ................................................ 74 9.1.50. VALARM schema ............................................. 75 9.1.51. VCALENDAR schema .......................................... 75 9.1.52. VCAR schema ............................................... 75 9.1.53. VEVENT schema ............................................. 75 9.1.54. VFREEBUSY schema .......................................... 76 9.1.55. VJOURNAL schema ........................................... 77 9.1.56. VQUERY schema ............................................. 77 9.1.57. VTIMEZONE schema .......................................... 78 9.1.58. VTODO schema .............................................. 78 9.1.59. X_PROP schema ............................................. 79 9.1.60. XPARAM schema ............................................. 79 9.2. Query example ................................................ 79 10. Examples ...................................................... 79 10.1. Authentication Examples ..................................... 79 10.1.1. Login Using Kerberos V4 ................................... 79 10.1.2. Error Scenarios ........................................... 80 10.2. Read Examples ............................................... 81 10.2.1. Read From A Single Calendar ............................... 81 10.2.2. Read From Multiple Calendars .............................. 82 10.2.3. Timeouts .................................................. 83 10.2.4. Using the Calendar Parent, Children Properties ............ 84 Mansour/Dawson/Royer/Taler/Hill Expires September 2000 Internet Draft CAP March 10, 2000 10.2.5. An example that depends on VEVENT.DTSTART and VALARM.DT- START ........................................................ 84 11. Implementation Issues ......................................... 84 12. Properties .................................................... 84 12.1. Calendar Store Properties ................................... 84 12.2. Calendar Properties ......................................... 85 13. Security Considerations ....................................... 87 14. Changes to iCalendar .......................................... 87 14.1. Time Transparency ........................................... 88 14.2. RIGHTS Value Type ........................................... 89 14.3. VCAR Calendar Component ..................................... 92 14.4. GRANT Component Property .................................... 94 14.5. DENY Component Property ..................................... 94 14.6. VCAR Identifier Component Property .......................... 95 15. CAP Entities Registration ..................................... 96 15.1.1. Define the Entity ......................................... 97 15.1.2. Post the entity definition ................................ 98 15.1.3. Allow a comment period .................................... 98 15.1.4. Submit the entity for approval ............................ 98 15.2. Property Change Control ..................................... 98 16. IANA Considerations ........................................... 99 17. Acknowledgments ............................................... 99 18. Bibliography .................................................. 99 19. Author's Address .............................................. 100 20. Full Copyright Statement ...................................... 101 Mansour/Dawson/Royer/Taler/Hill Expires September 2000 Internet Draft CAP March 10, 2000 1. Introduction This document specifies how a Calendar User Agent (CUA) interacts with a Calendar Store (CS) to manage calendar information. In particular, it specifies how to query, create, modify, and delete iCalendar components (e.g., events, to-dos, or daily journal entries). It further specifies how to search for available busy time information. This protocol is based on request/response form of protocol data units, sent from a client CUA to a calendar server. The protocol data units leverage the standard iCalendar format [RFC2445] for conveying CS related information. 1.1. Formatting Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in upper case. For example, "Organizer" refers to a role of a "Calendar User" (CU) within the protocol defined by this memo. Calendar components defined by [RFC2445] are referred to with capitalized, quoted-strings of text. All calendar components start with the letter "V". For example, "VEVENT" refers to the event calendar component, "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to the daily journal calendar component. Calendar access methods defined by this memo, as well as scheduling methods defined by [RFC2446], are referred to with capitalized, quoted- strings of text. For example, "CREATE" refers to the method for creating a calendar component on a calendar, "READ" refers to the method for reading calendar components. Properties defined by this memo are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User". Property parameters defined by this memo are referred to with lower case, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Enumerated values defined by this memo are referred to with capitalized text, either alone or followed by the word "value". In tables, the quoted-string text is specified without quotes in order to minimize the table length. 1.2. Related Documents Implementers will need to be familiar with several other memos that, along with this one, describe the Internet calendaring and scheduling Mansour/Dawson/Royer/Taler/Hill 3 Expires September 2000 Internet Draft CAP March 10, 2000 standards. This document, [RFC2445] specifies the objects, data types, properties and property parameters used in the protocols, along with the methods for representing and encoding them; [RFC2446] specifies an interoperability protocol for scheduling between different implementations. The related documents are: [RFC2447] specifies an Internet email binding for [RFC2446]. [iRIP] specifies a real-time binding for [RFC2446]. This memo does not attempt to repeat the specification of concepts or definitions from these other memos. Where possible, references are made to the memo that provides for the specification of these concepts or definitions. 1.3. 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 A collection of logically related objects or entities each of which may be associated with a calendar date and possibly time of day. These entities can include other calendar properties or calendar components. In addition, a calendar might be hierarchically related to other sub- calendars. A calendar is identified by its unique calendar identifier. The [RFC2445] defines calendar properties, calendar components and component properties that make up the content of a calendar. Calendar Access Protocol (CAP) The standard Internet protocol that permits a Calendar User Agent to access and manipulate a calendar residing on a Calendar Store. Calendar Access Rights (CAR) The mechanism for specifying the CAP operations ("ACTIONS") that a particular calendar user ("UPN") are granted or denied permission to perform on a given calendar entity ("OBJECT"). The calendar access rights are specified with the "VCAR" calendar components within a CS and calendar. Mansour/Dawson/Royer/Taler/Hill 4 Expires September 2000 Internet Draft CAP March 10, 2000 Calendar Collection A collection of Calendars, Resource Calendars, and/or other Calendar Collections. These collections are expanded by the CS and may reside either locally or in an external database or directory. The calendars in the collection may be fixed or dynamic over time. Calendar Component An entity within a calendar. Some types of calendar components include events, to-dos, journals, alarms, time zones and freebusy data. A calendar component consists of component properties and possibly other sub-components. For example, an event may contain an alarm component. Calendar Component Properties An attribute of a particular calendar component. Some calendar component properties are applicable to different types of calendar components. For example, DTSTART is applicable to VEVENT, VTODO, VJOURNAL calendar components. Other calendar components are applicable only to an individual type of calendar component. For example, TZURL is only applicable to VTIMEZONE calendar components. Calendar Identifier (CalID) A globally unique identifier associated with a calendar. Calendars reside within a CS. See Qualified Calendar Identifier and Relative Calendar Identifier. Calendar Policy A CAP operational restriction on the access or manipulation of a calendar. For example, "events MUST be scheduled in unit intervals of one hour". Calendar Properties An attribute of a calendar. The attribute applies to the calendar, as a whole. For example, CALSCALE specifies the calendar scale (e.g., GREGORIAN) for the whole calendar. Calendar Service An implementation of a Calendar Store that manages one or more calendars. Mansour/Dawson/Royer/Taler/Hill 5 Expires September 2000 Internet Draft CAP March 10, 2000 Calendar Store (CS) The data and service model definition for a Calendar Service. Calendar Store Identifier (CSID) The globally unique identifier for an individual CS. A CSID consists of the host and port portions of a "Common Internet Scheme Syntax" part of a URL, as defined by [RFC2396]. Calendar Store Components Components maintained in a CS specify a grouping of calendar store- wide information. Calendar store components can be accessed using CAP. Calendar Store Properties Properties maintained in a Calendar Store calendar store-wide information. Calendar store properties can be accessed using CAP. Calendar User (CU) An entity (often biological) that uses a calendaring system. Calendar User Agent (CUA) The CUA is the client application that a CU or UG utilizes to access and manipulate a calendar. Calendaring and Scheduling System The computer sub-system that provides the services for accessing, manipulating calendars and scheduling calendar components. CAP Session An open communication channel between a CAP CUA and a CAP CS. Connected Mode A mobile computing mode where the CUA is directly connected to the CS. Delegate Mansour/Dawson/Royer/Taler/Hill 6 Expires September 2000 Internet Draft CAP March 10, 2000 Is a calendar user (sometimes called the delegatee) who has been assigned participation in a scheduled calendar component (e.g., VEVENT) by one of the attendees in the scheduled calendar component (sometimes called the delegator). An example of a delegate is a team member told to go to a particular meeting. Designate Is a calendar user who is authorized to act on behalf of another calendar user. An example of a designate is an assistant. Disconnected Mode A mobile computing mode where a CUA can be disconnected from a CS. When the CUA is disconnected, it is in the disconnected mode. Fan Out The calendaring and scheduling process by which a calendar operation on one calendar is also performed on every other calendar specified in the operation. This may include the calendar associated with TARGET calendar property. Hierarchical Calendars A CS feature where a calendar have a hierarchical relationship with another calendar in the CS. The top-most calendar in the hierarchical relationship has the CS as its parent. There may be multiple top-most calendars in a given CS. Within a given hierarchical relationship, all sub-calendars have a calendar with a "parent" topographical relationship. In addition, sub-calendars may have a relationship with another calendar that has a "child" topographical relationship. In addition, a calendar may have a relationship such that one or more calendars have a "sibling" topographical relationship with the calendar. The hierarchical calendar feature is not a storage relationship of the calendars within the CS. Instead it is a feature that relates access control rights to calendar content between different calendars in the CS. The hierarchical relationship of a calendar is specified in the "PARENT" and "CHILDREN" calendar properties. High Bandwidth Connection A communications connection supporting high transfer rates; transfer rates commonly found within a LAN. Mansour/Dawson/Royer/Taler/Hill 7 Expires September 2000 Internet Draft CAP March 10, 2000 Local Store A CS which is on the same platform as the CUA. Low Bandwidth Connection A communications connection supporting slow transfer rates; transfer rates commonly found in remote access technology. Overlapped Booking A policy which indicates whether or not OPAQUE events can overlap one another. When the policy is applied to a calendar it indicates whether or not any OPAQUE events in the calendar can overlap. When applied to an individual event, it indicates whether or not it can be overlapped by any other OPAQUE event. Owner One or more CUs or UGs that have "OWNER" calendar access rights for a calendar. The owner is specified in the "OWNER" calendar property. Qualified Calendar Identifier (Qualified CalID) A CalID where both the <scheme> and <csid> are present. Realm A collection of calendar user accounts, identified by a string. The name of the realm is only used in UPNs. In order to avoid namespace conflict, the realm SHOULD be postfixed with an appropriate DNS domain name. (eg: the foobar realm could be called foobar.example.com). Relative Calendar Identifier (Relative CalID) An identifier for an individual calendar in a calendar store. It is unique within a calendar store. It is recommended to be globally unique. A Relative CalID consists of the portion of the "scheme part" of a Qualified CalID following the Calendar Store Identifier. This is the same as the "URL path" of the "Common Internet Scheme Syntax" portion of a URL, as defined by [RFC2396]. Remote Store A CS which is not on the same platform as the CUA. Mansour/Dawson/Royer/Taler/Hill 8 Expires September 2000 Internet Draft CAP March 10, 2000 Resource Calendar (RC) A non-human Calendar, associated with an organizational resource. There is no syntactic difference between an RC and a Calendar. Session Identity A UPN associated with a CAP session. A session gains an identity after successful authentication. The identity is used in combination with CAR to determine access to data in the CS. Sub-calendars Calendars that have a "child" hierarchical relationship with another calendar, its "parent". User Group (UG) A collection of Calendar Users and/or User Groups. These groups are expanded by the CS and may reside either locally or in an external database or directory. The group membership may be fixed or dynamic over time. User Name A name which denotes a Calendar User within a realm. This is part of a UPN. User Principal Name (UPN) An identifier that denotes a unique CU. A UPN is an RFC 822 compliant email address, with exceptions listed below, and in most cases it is deliverable to the CU. In some cases it is identical to the CU's well known email address. A CU's UPN MUST never be deliverable to a different person. It consists of a realm in the form of a valid, and unique, DNS domain name and a unique username. In it's simplest form it looks like "user@example.com". In certain cases a UPN will not be RFC 822 compliant. When anonymous authentication is used, or anonymous authorization is being defined, the special UPN "@" will be used. When authentication must be used, but unique identity must be obscured, a UPN of the form @DNS-domain- name may be used. For example, "@example.com". Usage of these special cases is further discussed in the authentication and authorization sections of this document. Mansour/Dawson/Royer/Taler/Hill 9 Expires September 2000 Internet Draft CAP March 10, 2000 2. CAP Design 2.1. System Model The system model describes the high level components of a calendar system and how they interact with each other. 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 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 Transfer Protocol is used to move iCalendar objects between a CUA and a CS. The Application Protocol defines the content and semantics of the iCalendar objects sent between the CUA and the CS. This document defines both the Transfer Protocol and the Application Protocol. In the diagram below, a user uses CUA1 to communicate with CS1 using CAP. The CUA must authenticate the Calendar User (CU) so that access to calendars on CS1 can be controlled. The CUA can then view, create, edit, and delete calendars, calendar properties, and calendar components subject to the access rights. CAP servers support fanout. Fanout allows a CUA to communicate with a single CS to perform scheduling operations with calendars on multiple CSs. That is, a Calendar User (CU) can book events on or read events from calendars on other calendar stores. To accomplish this, a CAP server has several options: CS1 MAY play the role of a CUA and use CAP to access CS2; CS1 MAY be able to play the role of a CUA and use [iRIP] to interoperate with the possible iRIP support in CS2; CS1 MUST be able play the role of a CUA and use [RFC2447] to interoperate with other CUAs. Storage Agent +-----+ +-----+ | | CAP | | CAP CUA1 ------| CS1 |-----------| CS2 |--------- CUA2 | | | | A | | | | | | | | | | +-----+ +-----+ | | IMIP | +---------------------------------+ Mansour/Dawson/Royer/Taler/Hill 10 Expires September 2000 Internet Draft CAP March 10, 2000 Note that the fanout feature in CAP is a convenience to the CUA. It is perfectly valid for the CUA to assume the responsibility for fanout if it wishes. That is, [RFC2447] messages could also be sent from CUA1 to CUA2. 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 properties. Calendars contain VEVENTs, VTODOs, VJOURNALs, VALARMs, VCARs, and calendar properties. Calendars may also contain other calendars. +---------Calendar Store-----------------------------+ | | | | | VCARs | | +--calendars-------------------------+ | | Properties | | | | | +--calendars--------+ VEVENTs | | | VTIMEZONEs | | | VTODOs | | | | | VEVENTs | VJOURNALs | | | | | VCARs | VALARMs | | | | | +---+ VTODOs | VCARs | | | | | | | VALARMs | Calendar | | | | | +---+ VJOURNALs | Properties | | | | | VTIMEZONEs | VTIMEZONEs | | | | | Calendar | VSCHEDULE | | | | | Properties | | | | | | VSCHEDULE | | | | | +-------------------+ | | | +------------------------------------+ | +----------------------------------------------------+ Calendars within a Calendar Store are identified by their Relative CALID. In this model, VSCHEDULE is a queue of scheduling messages that have not yet been applied to the calendar. Items in VSCHEDULE are discussed in more detail below. 2.3. Protocol Model A generic transfer-layer, Calendar Server Transfer Protocol (CSTP), is used to move data objects between a CUA and the CS. CSTP commands are listed below and their usage and semantics are defined in section 7 of this document. Mansour/Dawson/Royer/Taler/Hill 11 Expires September 2000 Internet Draft CAP March 10, 2000 CSTP Commands ------------------------------------------------------------------------- Command Description ------------------------------------------------------------------------- ABORT Stop a command whose latency time has been exceeded. AUTHENTICATE Authenticate a UPN. CONTINUE Continue the execution of a command whose latency time has been exceeded. IDENTIFY Set a new identity for calendar access. DISCONNECT Terminate a connection with the server. SENDDATA Send a data object MIME encapsulated iCalendar. STARTTLS Negotiate transport level security using [TLS] ------------------------------------------------------------------------- Application-level commands are used to manipulate data on the calendar store. They are listed below and discussed in detail in section 7. CAP Calendaring Commands ------------------------------------------------------------------------- Command Description ------------------------------------------------------------------------- CREATE Create a new calendar or component DELETE Delete a calendar or component GENERATEUID Generate one or more unique ids MODIFY Change a calendar or component MOVE Move a calendar READ Read a calendar properties or components ------------------------------------------------------------------------- CAP Scheduling Commands ------------------------------------------------------------------------- Command Description ------------------------------------------------------------------------- PUBLISH Publish a calendar entry to one or more calendars. Mansour/Dawson/Royer/Taler/Hill 12 Expires September 2000 Internet Draft CAP March 10, 2000 REQUEST Schedule a calendar entry with one or more calendars. REPLY Response to a scheduling request. ADD Add one or more instances to an existing calendar entry. CANCEL Cancel one or more instances to an existing calendar entry. REFRESH A request for the latest version of a calendar entry. COUNTER A request for a change (a counter-proposal) to a calendar entry. DECLINECOUNTER Decline a counter proposal. ------------------------------------------------------------------------- 2.4. Security Model Authentication to the CS will be performed using SASL [RFC2222]. As noted in the CAP system model section, a variety of connectivity scenarios are possible. This complicates the security model considerably, and a thorough familiarity with the concepts is required to ensure interoperability. Basic threats to a Calendaring and Scheduling System include: (1) Unauthorized access to data via data-fetching operations, (2) Unauthorized access to reusable client authentication information by monitoring others' access, (3) Unauthorized access to data by monitoring others' access, (4) Unauthorized modification of data, (5) Unauthorized or excessive use of resources (denial of service), and (6) Spoofing of CS: Tricking a client into believing that information came from the CS when in fact it did not, either by modifying data in transit or misdirecting the client's connection. Threats (1), (4), (5) and (6) are due to hostile clients. Threats (2), and (3) are due to hostile agents on the path between client and server, or posing as a server. CAP can be protected with the following security mechanisms: Mansour/Dawson/Royer/Taler/Hill 13 Expires September 2000 Internet Draft CAP March 10, 2000 (1) Client authentication by means of the SASL [RFC2222] mechanism set, possibly backed by the TLS credentials exchange mechanism, (2) Client authorization by means of access control based on the requestor's authenticated identity, (3) Data integrity protection by means of the TLS protocol or data-integrity SASL mechanisms, (4) Protection against snooping by means of the TLS protocol or data-encrypting SASL mechanisms, (5) Resource limitation by means of administrative limits on service controls, and (6) Server authentication by means of the TLS protocol or SASL mechanism. Imposition of access controls (authorizations) is done by means of VCARs, an overview is provided in section <fwd ref>, and a detailed syntax is provided in section <fwd ref>. Authentication is explained in detail in section <fwd ref>. 2.4.1. Authentication, Credentials, and Identity Generically, authentication credentials are the evidence supplied by one party to another, asserting the identity of the supplying party (e.g. a user) who is attempting to establish an association with the other party (typically a server). Authentication is the process of generating, transmitting, and verifying these credentials and thus the identity they assert. An authentication identity is the name presented in a credential. There are many forms of authentication credentials. The form used depends upon the particular authentication mechanism negotiated by the parties. For example: X.509 certificates, Kerberos tickets, simple identity and password pairs. Note that an authentication mechanism may constrain the form of authentication identities used with it. SASL only provides a protocol to negotiate a mutually acceptable authentication mechanism. SASL itself does not constrain or dictate the form of the authentication identities used to perform the authentication. 2.4.2. Calendar User and UPNs A Calendar User(CU) is an entity that can be authenticated. It is represented in CAP as a UPN. A UPN is the owner of a calendar and the subject of access rights. The UPN representation is independent of the authentication mechanism used during a particular CUA/CS interaction. This is because UPNs are used within VCARs. If the UPN were dependant on the authentication mechanism, a VCAR could not be consistently evaluated. A CU may use one mechanism while using one CUA but the same CU may use a different authentication mechanism when using a different Mansour/Dawson/Royer/Taler/Hill 14 Expires September 2000 Internet Draft CAP March 10, 2000 CUA, or while connecting from a different location. The user may also have multiple UPNs for various purposes. Note that the immutability of the user's UPN may be achieved by using SASL's authorization identity feature. (The transmitted authorization identity may be different than the identity in the client's authentication credentials.) [RFC2222, section 3] This also permits a CU to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying [RFC2222]. Also, the form of authentication identity supplied by a service like TLS may not correspond to the UPNs used to express a server's access control policy, requiring a server-specific mapping to be done. The method by which a server composes and validates an authorization identity from the authentication credentials supplied by a client is implementation- specific. For Calendaring and Scheduling Systems that are integrated with a directory system, the CS MUST support the ability to configure which schema attribute stores the UPN. The CS MAY allow one or more attributes to be searched for the UPN. 2.4.2.1. UPNs and Certificates When using X.509 certificates for purposes of CAP authentication, the UPN should appear in the certificate. Unfortunately there is no single correct guideline for which field should contain the UPN. From RFC-2459, section 4.1.2.6 (Subject): If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. Implementations of this specification MAY use these comparison rules to process unfamiliar attribute types (i.e., for name chaining). This allows implementations to process certificates with unfamiliar attributes in the subject name. In addition, legacy implementations exist where an RFC 822 name is embedded in the subject distinguished name as an EmailAddress attribute. The attribute value for EmailAddress is of type IA5String to permit inclusion of the character '@', which is not part of the PrintableString character set. EmailAddress attribute values are not case sensitive (e.g., "fanfeedback@redsox.com" is the same as "FANFEEDBACK@REDSOX.COM"). Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (see sec. 4.2.1.7 [of RFC 2459]) to describe Mansour/Dawson/Royer/Taler/Hill 15 Expires September 2000 Internet Draft CAP March 10, 2000 such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted. Since no single method of including the UPN in the certificate will work in all cases, CAP implementations MUST support the ability to configure what the mapping will be by the CS administrator. Implementations MAY support multiple mapping definitions, for example, the UPN may be found in either the subject alternative name field, or the UPN may be embedded in the subject distinguished name as an EmailAddress attribute. Note: If a CS or CUA is validating data received via iMIP, if the "ORGANIZER" or "ATTENDEE" property said (e.g.) "ATTENDEE;CN=Joe Random User:juser@example.com" then the email address should be checked against the UPN, and the CN should also be checked. This is so the "ATTENDEE" property couldn't be munged to something misleading like "ATTENDEE;CN=Joe Rictus User:juser@example.com" and have it pass validation. This validation will also defeat other attempts at confusion. 2.4.2.2. Anonymous Users and Authentication Anonymous access is often desirable. For example an organization may publish calendar information that does not require any access control for viewing or login. Conversely, a user may wish to view unrestricted calendar information without revealing their identity. CAP implementations MUST support anonymous authentication, as defined in section <fwd ref 7.1.3>. CAP implementations MAY support anonymous authentication with TLS, as defined in section <fwd ref 7.1.3.2>. 2.4.2.3. Required Security Mechanisms The following implementation conformance requirements are in place: (1) For a read-only, public CS, anonymous authentication, described in section <fwd ref 7.1.3.1>, can be used. (2) Implementations providing password-based authenticated access MUST support authentication using Digest, as described in section <fwd ref>. This provides client authentication with protection against passive eavesdropping attacks, but does not provide protection against active intermediary attacks. (3) For a CS needing session protection and authentication, the Start TLS extended operation, and either the simple authentication choice or the SASL EXTERNAL mechanism, are to be used together. Mansour/Dawson/Royer/Taler/Hill 16 Expires September 2000 Internet Draft CAP March 10, 2000 Implementations SHOULD support authentication with a password as described in section <fwd ref>, and SHOULD support authentication with a certificate as described in section <fwd ref>. Together, these can provide integrity and disclosure protection of transmitted data, and authentication of client and server, including protection against active intermediary attacks. 2.4.2.4. TLS Ciphersuites The following ciphersuites defined in [RFC 2246] MUST NOT be used for confidentiality protection of passwords or data: TLS_NULL_WITH_NULL_NULL TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA The following ciphersuites defined in [RFC 2246] can be cracked easily (less than a week of CPU time on a standard CPU in 1997). The client and server SHOULD carefully consider the value of the password or data being protected before using these ciphersuites: TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA The following ciphersuites are vulnerable to man-in-the-middle attacks, and SHOULD NOT be used to protect passwords or sensitive data, unless the network configuration is such that the danger of a man-in-the-middle attack is tolerable: TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA A client or server that supports TLS MUST support at least TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. 2.4.3. User Groups User Group is used to represent a collection of CUs or other UGs that can be referenced in VCARS. A UG is represented in CAP as a UPN. The CUA cannot distinguish between a UPN that represents a CU or a UG. UGs are expanded as necessary by the CS. The CS MUST accept a CUA request for UG expansion, although the CS may be configured to restrict some responses. The CS MAY expand a UG (including nested UGs) to obtain a list of unique CUs. Duplicate UPNs are filtered during expansion. Mansour/Dawson/Royer/Taler/Hill 17 Expires September 2000 Internet Draft CAP March 10, 2000 Incomplete expansion should be treated as a failure. [ Editor's Note: We need to explore the issue and impact of directory permissions and precedence.] The CS SHOULD not preserve UG expansions across operations. A UG may reference a static list of members, or it may represent a dynamic list. Each operation SHOULD generate its own expansion in order to recognize changes to UG membership. However, during fan out to other CSs, the originating CS SHOULD expand all UGs so that the target CS receives only a list of unique CUs. This is to prevent confusion when two CSs do not share the same UG database or directory. [Editor's Note: Doug had an issue here relating to multiple CUs not having a common directory. We think the above text resolves this] CAP does not define commands or methods for managing UGs. Examples: Small UG - The Three Stooges. There is only and always three at any one time. Large UG - The MIT graduating class of 1999. This is a static list. Dynamic UG - The IETF membership, which is a large and changing list of members. Nested UG - The National Football League, made up of the AFC and NFC, which are made up of 3 divisions each... 2.4.4. Access Rights In simple terms, access rights are used to grant or deny access to a calendar for a CU. CAP defines a new component type called a VCalendar Access Right (VCAR). Specifically, a VCAR grants, or denies, UPNs the right to read and write components, properties, and parameters on calendars within a CS. The VCAR model does not put any restriction on the sequence in which the object and access rights are created. That is, an event associated with a particular VCAR might be created before or after the actual VCAR is defined. In addition, the VCAR and VEVENT definition might be created in the same iCalendar object and passed together in a single command. All rights MUST be denied unless specifically granted; individual VCARs MUST be specifically granted to an authenticated CU. 2.4.4.1. VCalendar Access Right (VCAR) Access rights within CAP are specified with the "VCAR" calendar component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" component properties. Mansour/Dawson/Royer/Taler/Hill 18 Expires September 2000 Internet Draft CAP March 10, 2000 Properties within an iCalendar object are unordered. This also is the case for the "GRANT", "DENY" and "CARID" properties. Likewise, there is no implied ordering required for components of a "RIGHTS" value type other than that specified by the ABNF. [ editor's note, this requires a lot of review. We think that this paragraph may be incorrect. ] For details on the VCAR syntax please see section <forward ref> 2.4.4.2. Decreed VCARs [editor's note: new concept. This will also require some syntax modification 14.4. This section is being actively discussed on the working group list, 2/3/2000.] A CS MAY choose to implement and allow persistent immutable VCARs, that are configured by the CS Administrator, which apply to all calendars on the server. When a user attempts to modify a decreed VCAR and error will be returned,indicating that the user has insufficient authorization to perform the operation. The CAP protocol does not define the semantics used to initially create a decreed VCAR. This administrative task is out side the scope of the CAP protocol. 2.4.4.3. Inheritance Calendars inherit VCARs from their parent. VCARs specified in a calendar or a sub-calendar override all inherited VCARs. 2.4.5. CAP session identity A CAP session has an associated set of authentication credentials, from which is derived a UPN. This UPN is the identity of the CAP session, and is used to determine access rights for the session. The CUA may change the identity of a CAP session by calling the "IDENTIFY" command. The Calendar Service only permits the operation if the session's authentication credentials are good for the requested identity. The method of checking this permission is implementation dependent, but may be thought of as a mapping from authentication credentials to UPNs. The "IDENTIFY" command allows a single set of authentication credentials to choose from multiple identities, and allows multiple sets of authentication credentials to assume the same identity. Mansour/Dawson/Royer/Taler/Hill 19 Expires September 2000 Internet Draft CAP March 10, 2000 For anonymous access the identity of the session is "@", a UPN with a null username and null realm. A UPN with a null username, but non-null realm, such as "@foo.com" may be used to mean any identity from that realm, which is useful to grant access rights to all users in a given realm. A UPN with a non-null username and null realm, such as "bob@" could be a security risk and must not be used. Since the UPN includes realm information it may be used to govern calendar store access rights across realms. However, governing access rights across realms is only useful if login access is available. This could be done through a trusted server relationship or a temporary account. The "IDENTIFY" command provides for a weak group implementation. By allowing multiple sets of authentication credentials belonging to different users to identify as the same UPN, that UPN essentially identifies a group of people, and may be used for group calendar ownership, or the granting of access rights to a group. Examples: Small UG - The Three Stooges. There will always be three, it will not change. Large UG - The MIT graduating class of 1999. This is a static list. Dynamic UG - The IETF membership, which is a large and changing list of members. Nested UG - The National Football League, made up of the AFC and NFC, which are made up of 3 divisions each... 2.5. Roles CAP defines methods for managing [RFC2445] objects on a Calendar Store and exchanging [RFC2445] objects for the purposes of group calendaring and scheduling between "Calendar Users" (CUs) or "User Groups" (UGs). There are two distinct roles taken on by CUs in CAP. The CU who creates an initial event or to-do and invites other CUs or UGs as attendees takes on the role of "Organizer". The CUs or UGs asked to participate in the group event or to-do take on the role of "Attendee". Note that "role" is also a descriptive parameter to the "ATTENDEE" property. Its use is to convey descriptive context to an "Attendee" such as "chair", "REQ-PARTICIPANT" or NON- PARTICIPANT" and has nothing to do with the scheduling workflow. Mansour/Dawson/Royer/Taler/Hill 20 Expires September 2000 Internet Draft CAP March 10, 2000 2.6. Calendar Addresses Calendar addresses are URIs that are modeled after [RFC2396]. CAP uses the following forms of URI. [[<scheme>]://<csid>[:<port>]/]<relativeCALID> where: <scheme> is "cap" <csid> is the Calendar Store ID. It is the network address of the computer on which the CAP server is running. <port> is optional. Its default value is 5229. The port must be present if the CAP server does not listen on the default port. <relativeCALID> is an identifier that uniquely identifies the calendar on a particular calendar store. There is no implied structure in a Relative CALID. It is an arbitrary string of 7 bit ASCII characters. It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store. It is recommended that the Relative CALID be globally unique. If the <scheme> and <csid> are present the calendar address is said to be "qualified". Senders are required to supply the <relativeCALID> portion of the address. A qualified calendar address is required when the <csid> of the target calendar address differs from that of the CAP server receiving the command. Examples: cap://calendar.example.com/user1 ://calendar.example.com/user1 user1 cap://calendar.example.com/conferenceRoomA cap://calendar.example.com/89798-098-zytytasd For a user currently authenticated to a CAP server on calendar.example.com, the first three addresses refer to the same calendar. 2.7. Extensions to iCalendar In mapping the CAP command set, query feature, and access rights onto the iCalendar format, several extended iCalendar methods and components are defined by this memo. * The search function is specified with the new iCalendar QUERY method. The QUERY method makes use of a new component, called VQUERY, that contains the search filter. The component consists of Mansour/Dawson/Royer/Taler/Hill 21 Expires September 2000 Internet Draft CAP March 10, 2000 a set of new properties: SCOPE, MAXRESULTS, MAXRESULTSSIZE, QUERY and QUERYNAME, that define the search filter. * Access control is specified the the new iCalendar VCAR component. * The iCalendar METHOD property format has been updated with new values. * A new iCalendar component, VCOMMAND, has been added. VCOMMANDs are needed to fully specify CAP commands. * TARGET is a new property within the VCOMMAND component. It indicates the calendars to which the command applies 2.8. Relationship of RFC 2446 (ITIP) to CAP [RFC2446] describes scheduling methods which result in indirect manipulation of calendar components. CAP methods provide direct manipulation of calendar components. In the CAP calendar store model, scheduling messages are kept separate from other calendar components. This is modeled with the VSCHEDULE queue. Note that this is a conceptual model, the actual storage details are left to implementations. The model is shown pictorially as follows: +-----------------VCALENDAR-------------------+ | | | +-----------+ +-------VSCHEDULE---------+ | | | VEVENTs | | PUBLISH messages | | | | VTODOs | | REQUEST messages | | | | VJOURNALs | | REPLY messages | | | | | | ADD messages | | | | | | CANCEL messages | | | | | | REFRESH messages | | | | | | COUNTER messages | | | | | | DECLINECOUNTER messages | | | +-----------+ +-------------------------+ | +---------------------------------------------+ The METHOD is saved along with components. Scheduled components become booked components when the METHOD changes from an ITIP method to the CAP storage method. For example, a component whose METHOD is "REQUEST" is scheduled. The component becomes booked when the METHOD is changed to "CREATED". [ed note: need to clean up the terminology here. We havent discussed "booked"] Mansour/Dawson/Royer/Taler/Hill 22 Expires September 2000 Internet Draft CAP March 10, 2000 2.9. VCalendar Access Rights (VCARs) In simple terms, VCARs are used to grant or deny access to a calendar for a CU or UG. Specifically, they grant User Principal Names (UPNs) the rights to read and write components, properties, and parameters on calendars within a calendar store. 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 a particular VCAR might be created before or after the actual VCAR is defined. In addition, the VCAR and VEVENT definition might be created in the same iCalendar object and passed together in a single SENDDATA command. VCAR principals can be CU or UG UPNs. Whenever VCARs are evaluated, all referenced User Groups MUST be evaluated as an expanded list. UG expansion SHOULD NOT persist across operations. [Editor's Note: This is where we need to define precedence rules.] 2.10. Query Schema <TBD> breif paragraph on summary of VQUERY. 3. State Diagram 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. Mansour/Dawson/Royer/Taler/Hill 23 Expires September 2000 Internet Draft CAP March 10, 2000 STARTTLS / CAPABILITY +-------+ | | +---------------+ | +-----------+ AUTHENTICATE | | +-->| Connected |-------------->| Authenticated | +-----------+ | | | +---------------+ | | | | | | | | +-----+ STARTTLS / | V | | CAPABILITY / | +---------------+ | IDENTIFY | | |<-+ | | Identified |<----+ | +--------| | | | | +---------------+ | command | | | | completes V |DISCONNECT | | +--------------+ | |SENDDATA | | Disconnected |<--+ | | +--------------+ | | ABORT A | | | V | | DISCONNECT +---------------+ | +--------------------| Receive |--+ | |<--+ +---------------+ | | | CONTINUTE +----+ The connection begins the Connected state when a CUA connects to a CAP server. The capabilities of the CS are reported in the response from the CS. From this state, the CUA can issue the DISCONNECT command to terminate the connection, the CAPABILITY, STARTTLS, or AUTHENTICATE commands. One use of the CAPABILITY command at this stage is to determine the supported authentication mechanisms supported by the server. Once the STARTTLS command has been successfully executed from either the Connected or Authenticated state, it must not be executed again. If an AUTHENTICATE command is successful, the connection enters the Authenticated state and then immediately goes to the IDENTIFIED state. While in the Identified state, allow CALIDEXPAND and UPNEXPAND commands. From here the CUA can issue the CAPABILITY command. The capabilities the server offers in the Authenticated state may be different than those in the Connected state. The CUA can also use the IDENTIFY command to change the identity of the user subject to access control. The connection remains in the Authenticated state after the CAPABILITY command Mansour/Dawson/Royer/Taler/Hill 24 Expires September 2000 Internet Draft CAP March 10, 2000 completes. The CUA can issue the DISCONNECT command to terminate the connection. The SENDDATA command can be used to send a request to read, write, modify, or delete data on the server. After the SENDDATA command has been issued the connection enters the Receive state while the CUA awaits and reads a server reply. Normally, the server handles the command, sends a reply which is read by the CUA and the connection returns to the Authenticated state. The CUA may have issued the SENDATA command with a maximum latency time. This informs the server that the CUA expects a response within the maximum latency time, even if the command was not completed. When the server is unable to complete the command in the maximum latency time, it issues an appropriate reply code and waits for the CUA to tell it how to proceed. If the CUA issues a CONTINUE command the server continues processing the command and the connection remains in the Receive state. If the CUA issues the ABORT command the server need not process the command any further and the connection returns to the Authenticated state. The DISCONNECT command can also be issued from the Receive state. 4. Protocol Framework 4.1. CAP Application Layer The CAP application layer is used for the manipulation of the calendar store. Commands and responses are transmitted between the CUA and CS inside "VCALENDAR" component wrappers. Commands are specified as the value of a "METHOD" property, and responses are specified as the value of a "REQUEST-STATUS" property. 4.2. CAP Transfer Protocol The CAP transfer protocol defines the format of data transmitted between a CUA and the CS. CAP transfer protocol commands are transmitted using the underlying transport. The transport used is a TCP/IP socket connection between the CUA and the CS. The default port that the CS listens for connections on is port 5229. Messages sent between the CUA and CS are formatted as a command followed by any associated data: <command> [<command data>] 4.3. Response Format Server responses consist of a response code and any parameters: <transfer-level response-code> [response args] [; debug text ; more Mansour/Dawson/Royer/Taler/Hill 25 Expires September 2000 Internet Draft CAP March 10, 2000 text] <CRLF>.<CRLF> [<application-data>] <CRLF>.<CRLF> The response codes are defined in Section 8. The debug text is human- readable information for protocol debugging and is optional. The optional application-data begins on the next line. The response is terminated with the second <CRLF> "." <CRLF> sequence. Any <CRLF> "." sequences which appear in the transmitted data must be quoted by placing an additional "." between the <CRLF> and the ".". For example, the following sequences of characters in the application data: . ..2 ...3 are quoted as follows: .. ...2 ....3 No other tagged command sequence can be sent until the second special terminating character sequence <CRLF>.<CRLF> has been sent. 4.4. Auto-logout Timer If a server has an inactivity auto-logout timer, that timer MUST be of at least 15 minutes duration. The receipt of ANY command from the client during that interval MAY reset the auto-logout timer, subject to CS administrators policy. A CUA may be discouraged from attempts to do usless things only to keep the connection alive. When a timeout occurs, the server drops the connection to the CUA. 4.5. Bounded Latency [CAP] is designed so that the CUA can either obtain an immediate response from a request or discover within a specified amount of time that the request could not be completed in the requested amount of time. When the CUA initiates a command that the server cannot complete within the specified latency time, the server returns an appropriate response code. The CUA then issues either a CONTINUE or ABORT command. The ABORT command immediately terminates the command in progress and the connection returns to the Authenticated state. The CONTINUE command instructs the server to continue processing the command. Mansour/Dawson/Royer/Taler/Hill 26 Expires September 2000 Internet Draft CAP March 10, 2000 4.6. Data Elements The data elements for CAP are MIME encapsulated iCalendar objects. 5. Formal Command Syntax 5.1. Searching and Filtering This section describes CAPs searching and filtering entities within a remote store. It is based on the Standard Query Language (SQL) defined by [SQL]. 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 in syntax to the format already in use for the iCalendar RECUR value type. Each "name" is the name of a valid SQL statement component (e.g., SELECT, WHERE, etc.). Each "value" is valid string associated with one of these SQL statement components. [Editor's note: We need to precisely define what part of SQL were using and why we chose what we did.] Examples needed: Grant someone access to June events Grant someone access to events during the month of June. (i.e., based on the current system date, if it's prior to June or after June you don't have access) Example for denying access to a specific property: DENY:UPN=FOO;ACTION=*;OBJECT=CLASS *scope vcar to a component *scope Grant, Deny of a VCAR 5.1.1. Grammar For Search Mechanism SEARCH = "BEGIN:VQUERY" CRLF [scope] [maxresults] [maxsize] querycomp "END:VQUERY" CRLF scope = "SCOPE:" comp-name ("," comp-name)* comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VTIMEZONE" / "VALARM" / "VFREEBUSY" / "VCAR" / iana-name / x-name maxresults = integer maxsize = integer Mansour/Dawson/Royer/Taler/Hill 27 Expires September 2000 Internet Draft CAP March 10, 2000 querycomp = (query) / (queryname query) / queryname queryname = "QUERYNAME:" text query = "QUERY:" queryrule queryrule = capselect capwhere caporderby ... capselect = <any valid SQL string that goes into a SELECT clause> capwhere = <any valid SQL string that goes into a WHERE clause> caporderby = <any valid SQL string that goes into a ORDERBY clause> 6. Access Rights Access rights within CAP are specified with the "VCAR" calendar component, "RIGHTS" value type and the "GRANT", "DENY" and "CARID" component properties. Individual calendar access rights MUST be specifically granted to an authenticated calendar user (i.e., UPN); all rights are denied unless specifically granted. Properties within a VCAR must be evaluated in the order provided. 6.1. VCAR Inheritance Calendar access rights specified in a calendar store are inherited as default calendar access rights for any calendar in the parent calendar store. Likewise, any calendar access rights specified in a root calendar are inherited as default calendar access rights for any sub- calendar to the root calendar. By implication, calendar access rights specified in a sub-calendar are inherited as default calendar access rights for any calendars that are hierarchically below the sub- calendar. Calendar access rights specified in a calendar override any default calendar access rights. Calendar access rights specified within a sub- calendar override any default calendar access rights. 6.2. 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" Mansour/Dawson/Royer/Taler/Hill 28 Expires September 2000 Internet Draft CAP March 10, 2000 7. Commands and Responses CAP commands and responses are described in this section. Command arguments, identified by "Arguments:" in the command descriptions below, are described by function, not by syntax. The precise syntax of command arguments is described in the Formal Syntax section. Some commands cause specific server data to be returned; these are identified by "Data:" in the command descriptions below. See the response descriptions in the Responses section for information on these responses, and the Formal Syntax section for the precise syntax of these responses. The "Result:" in the command description refers to the possible status responses to a command, and any special interpretation of these status responses. Commands have the general form: <command> [arguments...] where <command> is a command listed in the table above. A command MAY have arguments. Arguments are defined in the detailed command definitions below. Responses to commands have the following general form: responseCode [sep transportDescr sep [applicationDescr]] CRLF "." CRLF In the examples below, lines preceded with "S:" refer to the sender and lines preceded with "R:" refer to the receiver. Lines in which the first non-whitespace character is a "#" are editorial comments and are not part of the protocol. 7.1. Transfer Protocol Commands 7.1.1. Initial Connection Arguments: none Data: none Result: 2.0 - success. 8.1 - server too busy Upon session startup, the server sends a response of 2.0 to indicate that it is ready to receive commands. A response of 8.1 indicates that the server is too busy to accept the connection. In addition, the Mansour/Dawson/Royer/Taler/Hill 29 Expires September 2000 Internet Draft CAP March 10, 2000 general capabilities of the CS are reported in the response from the CS. These capabilities may be different than those reported in the authenticated state. The supported authentication mechanisms. There may be 1 or more. CAPVERSION IRIPVERSION 7.1.2. ABORT Command Arguments: none Data: none Result: 2.0 - success 2.2 - no command is in progress The ABORT command is issued by the CUA to stop a command whose latency time has been exceeded. When the latency time is specified on the SENDATA command, the CS must issue a reply to the CUA within the specified time. It may be a reply code indicating that the CS has not yet processed the request. The CUA must then tell the server whether to continue or abort. The CUA can issue the ABORT command at any time after the SENDATA command has been completed but before receiving a reply. 7.1.3. AUTHENTICATE Command Arguments: <SASL mechanism name> [<initial data>] Data: continuation data may be requested Result: 2.0 - Authenticate completed, now in authenticated state. 6.0 - Failed authentication. 6.1 - Authorization identity refused. 6.2 - Sender aborted authentication, authentication exchange cancelled. 6.3 - Unsupported Authentication Mechanism. 6.x - Temporary failure (back end authentication server down). 6.x - Authentication exchange cancelled. 6.x - Authentication mechanism too weak. Mansour/Dawson/Royer/Taler/Hill 30 Expires September 2000 Internet Draft CAP March 10, 2000 6.x - Encryption required. 6.x - Pass phrase expired. The pass phrase was correct but expired. The user will have to contact a pass phrase change server prior to authenticating. 6.x - The user is valid but the server does not have an entry in the authentication database for the requested mechanism (e.g., DIGEST- MD5). If the user successfully authenticates using a plain text password, then the back end back end entry will be updated. Note that if the client chooses to fall back to plain text password authentication it should enable an encryption layer or get user-con- firmation that a one-time transition is ac- ceptable. 6.x - User account disabled. The user will have to contact the system administrator to get the account re-enabled. 9.1 - Unexpected command. The capabilities of the CS in the authenticated state are reported in the response from the CS. These may be different than the capabilities in the Connected, but unauthenticated state. The AUTHENTICATE command is used by the CUA to identify the user to the CS. CAP supports a number of authentication methods, the [SASL] specification for authentication is the preferred method. If STARTTLS is negotiated prior to the AUTHENTICATE command, the client MUST discard all information about the CS capabilities fetched prior to the TLS negotiation. In particular, the value of supported SASL Mechanisms MAY be different after TLS has been negotiated. If a SASL security layer is negotiated, the client MUST discard all information about the CS capabilities fetched prior to SASL. In particular, if the client is configured to support multiple SASL mechanisms, it SHOULD fetch supported SASL Mechanisms both before and after the SASL security layer is negotiated and verify that the value has not changed after the SASL security layer was negotiated. This detects active attacks which remove supported SASL mechanisms from the supported SASL Mechanisms list. <initial data> is an optional parameter which can be used for mechanisms which require an initial response from the CUA. The AUTHENTICATE command is followed by an authentication protocol exchange, in the form of a series of CS challenges and CUA responses, per the relevant RFC that describes the specific SASL mechanism being used. Mansour/Dawson/Royer/Taler/Hill 31 Expires September 2000 Internet Draft CAP March 10, 2000 Cancelling the authentication process during its negotiation is implementation specific and not within scope of the CAP specification. If a security layer was negotiated it comes into effect for the CS starting with the first octet transmitted after the CRLF which follows the 2.0 reply code, and for the CUA starting with the first octet after the CRLF of its last response in the authentication exchange. Encrypted data is transmitted as described in [SASL]. The service name specified by this protocol's profile of SASL is "cap". [Note: this must be registered with IANA, has anyone done this yet?] The result of the AUTHENTICATE command includes data indicating the identity which has been assigned to the session, derived from the supplied authentication credentials, and/or authorization identifier. A CAP session does not have an identity until the CUA has issued the "AUTHENTICATE" command. The CUA may not issue the "AUTHENTICATE" command multiple times, even if the first attempt was aborted. If a CUA attempts to do this the CS must terminate the session. Data returned in response to a successful login is: The following examples illustrate the various possibilities for an authentication protocol exchange. Here are examples of a successful authentication: C: AUTHENTICATE KERBEROS_V4 S: AmFYig== C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT S: or//EoAADZI= C: DiAF5A4gA+oOIALuBkAAmw== S: 2.0 S: . S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: PRODID:-//ACME/CAPserver//EN S: VERSION:2.1 S: IDENTITY=bill@example.com S: CAPVERSION=1.0 S: ITIPVERSION=1.0 S: AUTH=KERBEROS_V4 S: AUTH=DIGEST_MD5 S: CAR=CAR-FULL-1 S: MINDATE=19700101T000000Z S: MAXDATE=20370201T000000Z S: END:VCALENDAR S: . Mansour/Dawson/Royer/Taler/Hill 32 Expires September 2000 Internet Draft CAP March 10, 2000 This example shows a failed authentication: C: AUTHENTICATE KERBEROS_V4 S: AmFYig== C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT S: . S: 6.0 S: . S: . 7.1.3.1. AUTHENTICATE ANONYMOUS RFC-2245 defines the Anonymous SASL mechanism. This RFC states that "the mechanism consists of a single message from the client to the server. The client sends optional trace information in the form of a human readable string. The trace information should take one of three forms: an Internet email address, an opaque string which does not contain the '@' character and can be interpreted by the system administrator of the client's domain, or nothing. For privacy reasons, an Internet email address should only be used with permission from the user." RFC-2245 goes on to state, "A client which uses the user's correct email address as trace information without explicit permission may violate that user's privacy." Information about who accesses an anonymous CS on a sensitive subject (e.g., AA meeting times and locations) has strong privacy needs. "Clients should not send the email address without explicit permission of the user and should offer the option of supplying no trace token -- thus only exposing the source IP address and time." Example of CUA using the Capability command followed by an anonymous authentication: C: CAPABILITY S: 2.0 S:CAPVERSION=1.0 S:AUTH=KERBEROS_V4 S:AUTH=DIGEST_MD5 S:AUTH=ANONYMOUS S:. C:AUTHENTICATE ANONYMOUS S:+ C:c21yaGM= S:2.0 Subsequent to the initial Anonymous Authentication with a CS, a CUA will have to provide a UPN for some CAP operations. For anonymous access the UPN that MUST be used by the CUA is "@", a UPN with a null username and null realm. The user's normal UPN MUST not be used for the subsequent CAP operations. Mansour/Dawson/Royer/Taler/Hill 33 Expires September 2000 Internet Draft CAP March 10, 2000 Note that the CS implementation may have internal audit logs that use the user's asserted UPN as trace information. However, this UPN will not appear on the wire after the initial SASL anonymous authentication. Use of the "@" UPN and wild-carding of UPNs within VCARs are covered in Section <forward ref>. 7.1.4. CALIDEXPAND Command Arguments: CalID Data: no specific data for this command Result: 2.0 Successful, and requested data follows 2.1 Permission Denied 2.2 Requested CSID not found 2.3 Result exceeds MAXEXPANDLIST 2.4 Misc. EXPAND error Return the members of the argument CalID. Successful result yields one or more Calendars and/or Resource Calendars. More than one C or RC returned implies that the CalID was a CC. Example: Example #1: Request lookup of CSID which is a Calendar Collection C: CALIDEXPAND cap://cal.example.com/calid14 S: 2.0 cap://cal.example.com/calid14 S: cap://cal.example.com/calid2 S: cap://cal.example.com/calid5 S: cap://cal.example.com/calid66 S: . Example #2: Request lookup of a CSID which is a Resource Calendar C: CALIDEXPAND cap://cal.example.com/conf5 S: 2.0 cap://cal.example.com/conf5 S: cap://cal.example.com/conf5 S: . Example #3: Request CSID which exceeds MAXCALIDEXPANDLIST C: CALIDEXPAND cap://cal.example.com/calid76 S: 2.0 cap://cal.example.com/calid76 S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid12 S: cap://cal.example.com/calid21 S: cap://cal.example.com/calid33 S: 2.3 Expansion resulted in too much data S: . Mansour/Dawson/Royer/Taler/Hill 34 Expires September 2000 Internet Draft CAP March 10, 2000 Example #4: CS loses contact with directory server during CALIDEXPAND C: CALIDEXPAND cap://cal.example.com/calid76 S: 2.0 cap://cal.example.com/calid76 S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid5 S: 2.4 Lost contact with directory server S: . 7.1.5. CAPABILITY Command Arguments: none 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 CAR-MIN or CAR-FULL-1 Mansour/Dawson/Royer/Taler/Hill 35 Expires September 2000 Internet Draft CAP March 10, 2000 MAXICALOBJECTSIZE 0 or 1 An integer value that specifies The largest ICAL object the server will ac- cept in bytes. Objects larger than this will be rejected. A value of zero (0) indicates unlimited. MAXDATE 0 or 1 The datetime value beyond which the server cannot accept. MAXCALIDEXPANDLIST 0 or 1 An integer value that specifies the max- imum number of CalIDs that can be re- turned by the CALIDEXPAND Command. A value of zero (0) indicates unlimited. MAXUPNEXPANDLIST 0 or 1 An integer value that specifies the max- imum number of UPNs that can be returned by the UPNEXPAND Command. A value of zero (0) indicates unlimited. MINDATE 0 or 1 The datetime value prior to which the server cannot accept. Example: C: CAPABILTIY S: 2.0 S: . S: CAPVERSION=1.0 S: ITIPVERSION=1.0 S: AUTH=KERBEROS_V4 S: AUTH=DIGEST_MD5 S: . 7.1.6. CONTINUE Command Arguments: latency time in seconds (optional) Data: none Result: results from the command in progress 2.0.2 - reply pending. The CONTINUE command is issued by the client in response to a SENDATA timeout. When a timeout value is specified on the SENDDATA command, the server must issue a reply to the client within the specified time. If the latency time has elapsed prior to the server completing the command it returns a timeout response code. If the client wants the server to continue processing the command it responds with the CONTINUE command. If latencyTime is present, it must be a positive integer that specifies Mansour/Dawson/Royer/Taler/Hill 36 Expires September 2000 Internet Draft CAP March 10, 2000 the maximum number of seconds the client will wait for the next response. If it is omitted, the receiver waits an indefinite period of time for the response. In this example, the client requests a response from the server every 10 seconds. C: SENDDATA:10 C: Content-Type:text/calendar; method=READ; component=VEVENT C: C: BEGIN:VCALENDAR # etc C: END:VCALENDAR C: . # after 10 seconds... S: . S: 2.0.2 S: . S: . C: CONTINUE:10 S: 2.0 S: . S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; S: Optinfo=VERSION:2.1 S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: CALID:cap://cal.example.com/relcal2 # etc. S: END:VCALENDAR S: . 7.1.7. DISCONNECT Command Arguments: none Data: Result: 2.0 The DISCONNECT command is used by a client to terminate a connection. It always succeeds. Example: C: DISCONNECT # [ed. Note: should the client now wait for a response from the server # before disconnecting? ] S: 2.0 S: . S: . Mansour/Dawson/Royer/Taler/Hill 37 Expires September 2000 Internet Draft CAP March 10, 2000 C: <drops connection> S: <drops connection> 7.1.8. IDENTIFY Command Arguments: Identity to assume Data: None Result: 2.0 6.4 Identity not permitted The "IDENTIFY" command allows the CUA to select a new identity to be used for calendar access. This command may only be called in the Identified State. The CS determines through an internal mechanism if the credentials supplied at authentication permit the assumption of the selected the identity. If they do the session assumes the new identity, otherwise a security error is returned. 7.1.9. SENDDATA Command Arguments: [latencyTime] Data: a MIME encapsulated iCalendar object Result: 2.0.1 - Server will now accept input until <CRLF>.<CRLF> is encountered. The SENDDATA command is used to send calendar requests and commands to the server. After a response code of 2.0.1 is issued the CUA sends a MIME encapsulated iCalendar object to the server. The end of this MIME data is signaled by the special sequence <CRLF>.<CRLF> . 7.1.10. STARTTLS Command Arguments: None Data: None Result: 2.0 6.5 TLS not supported The "STARTTLS" command is issued by the CUA to indicate to the CS that it wishes to negotiate transport level security using [TLS]. If the CS does not support TLS it returns status code 6.5. If the CS supports TLS it issues an initial response of 2.0.12 indicating that the CUA should Mansour/Dawson/Royer/Taler/Hill 38 Expires September 2000 Internet Draft CAP March 10, 2000 proceed with TLS negotiation. Once the TLS negotiation is complete the server returns the response code 2.0. After issuing the "STARTTLS" command the CUA issues the "AUTHENTICATE" command. The SASL external mechanism may be used if the CUA wishes to use the authentication id which was used in the TLS negotiation. The CUA MUST NOT issue a "STARTTLS" if it has already issued an "AUTHENTICATE" or "STARTTLS" command in this session. If a CUA does this the CS must terminate the session. The following examples illustrate the use of the "STARTTLS" command: Unsupported TLS: C: STARTTLS S: 6.5 Supported TLS: C: STARTTLS S: 2.0.12 <tls negotiation> S: 2.0 S: . S: . 7.1.10.1. UPNEXPAND Method Arguments: UPN Data: no specific data for this command Result: 2.0 - success 2.1 Permission Denied 2.2 Requested UPN not found 2.3 Result exceeds MAXUPNEXPANDLIST 2.4 Misc. UPNEXPAND error Return the members of the argument UPN. Successful result yields one or more CalIDs. More than one CalID returned implies that the UPN was a UG. Example #1: Request lookup of a UPN which is a CU C: UPNEXPAND upn@example.com S: 2.0 upn@example.com S: cap://cal.example.com/calid3 S: . Example #2: Request lookup of UPN which is a UG Mansour/Dawson/Royer/Taler/Hill 39 Expires September 2000 Internet Draft CAP March 10, 2000 C: UPNEXPAND group@example.com S: 2.0 group@example.com S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid6 S: cap://cal.example.com/calid1342 S: . Example #3: Request lookup exceeds MAXUPNEXPANDLIST C: UPNEXPAND group@example.com S: 2.0 group@example.com S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid12 S: cap://cal.example.com/calid21 S: cap://cal.example.com/calid33 S: 2.3 Lookup resulted in too much data S: . Example #4: CS loses contact with directory server during UPNEXPAND C: UPNEXPAND group@example.com S: 2.0 group@example.com S: cap://cal.example.com/calid3 S: cap://cal.example.com/calid5 S: 2.4 Lost contact with directory server S: . 7.2. Application Protocol Commands 7.2.1. Calendaring Commands The following methods provide a set of calendaring commands in CAP. Calendaring commands (or methods) allow a CU to directly manipulate a calendar. Calendar access rights can be granted for the more generalized access provided by the calendar commands. 7.2.1.1. CREATE Method Arguments: none Data: no specific data for this command Result: 2.0 - successfully created the component or calendar 6.0 - Permission denied 6.1 - Container(s) not found 6.2 - Calendar or component already exists 6.3 - Bad args Mansour/Dawson/Royer/Taler/Hill 40 Expires September 2000 Internet Draft CAP March 10, 2000 The CREATE method is used to create a new iCalendar object of type objtype. The property TARGET specifies the container(s) for the create. The type of object wrapped inside of the VCALENDAR/CREATE object is the object type(s) being created. When creating a new calendar at the top level, the CSID is specified. Otherwise the container will be a CalID. 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 Authenticated state with CS cal.example.com. C: SENDDATA C: CONTENT-TYPE: text/calendar;method=CREATE;component=VCOMMAND C: Content-Transfer-Encoding:7bit C: C: BEGIN:VCALENDAR C: VERSION:2.1 C: BEGIN:VCOMMAND C: METHOD:CREATE C: TARGET:cap://cal.example.com/ C: TARGET:relcal4 C: TARGET://bobo.ex.com/ C: TARGET:relcal5 C: TARGET:cap://cal.example.com/relcal8 C: TARGET:relcal9 C: BEGIN:VCALENDAR C: RELCALID:relcalz C: NAME:CHARSET=us-ascii;LANGUAGE=EN-us:Bill's Soccer Team C: OWNER:bill C: OWNER:mary C: CALMASTER:mailto:bill@example.com C: TZID:US_PST C: BEGIN:VCAR C: CARID:12345 C: GRANT:UPN=bill;ACTION=*;OBJECT=* C: GRANT:UPN=mary;ACTION=read;OBJECT=* C: END:VCAR C: END:VCALENDAR C: END:VCOMMAND C: END:VCALENDAR C: . S: 6.0 cap://cal.example.com/ S: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/relcalz S: 3.1.4 cap://bobo.ex.com/ S: 6.2 cap://cal.example.com/relcal5 S: 3.1.5 cap://cal.example.com/relcal8 S: 7.0 cap://cal.example.com/relcal9 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 error response. Mansour/Dawson/Royer/Taler/Hill 41 Expires September 2000 Internet Draft CAP March 10, 2000 In the example below, the Relative CalID is not specified. So, the 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: 2.0 cap://cal.example.com/relcal4 cap://cal.example.com/rand123 S: 3.1.4 cap://bobo.ex.com/ S: 6.2 cap://cal.example.com/relcal5 S: 3.1.4 cap://cal.example.com/relcal8 S: 2.0 cap://cal.example.com/relcal9 cap://cal.example.com/rand456 Example to create a new component. C: SENDDATA C: Content-Type:text/calendar; method=CREATE; charset=US-ASCII C: Content-Transfer-Encoding:7bit C: C: BEGIN:VCALENDAR C: VERSION:2.1 C: CMDID:abcde C: METHOD:CREATE C: TARGET:cap://cal.foo.com/relcal1 C: TARGET:relcal2 C: BEGIN:VEVENT C: DTSTART:19990307T180000Z C: UID:abcd12345 C: DTEND:19990307T190000Z C: SUMMARY:Important Meeting C: END:VEVENT C: END:VCALENDAR C: . S: 2.0 S: Content-Type:text/calendar; method=RESPONSE; OPTINFO="CMDID:abcde" S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: CMDID:abcde S: METHOD:RESPONSE S: BEGIN:VEVENT S: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal1 abcd12345 S: REQUEST-STATUS:2.0;cap://cal.foo.com/relcal2 abcd12345 S: END:VEVENT S: END:VCALENDAR The responce returns the calendar (CALID) and UID of the component so that the CUA can match up the REQUEST-STATUS from multiple objects created on multiple calendards (TARGETs). Mansour/Dawson/Royer/Taler/Hill 42 Expires September 2000 Internet Draft CAP March 10, 2000 7.2.1.2. DELETE Method Arguments: none Data: no specific data for this command Result: 2.0 - successfully deleted the component or calendar Permission Calendar or component not found Bad args Container(s) not found The DELETE method is used to delete a calendar or component. The TARGET properties specify the container(s) for the delete. When deleting a calendar at the top level, the CSID is specified. Otherwise the container will be a CalID. Example to delete a VEVENT with UID 'abcd12345': C: SENDDATA C: Content-Type:text/calendar; method=DELETE; component=VCOMMAND C: Content-Transfer-Encoding:7bit C: C: BEGIN:VCALENDAR C: BEGIN:VCOMMAND C: METHOD:DELETE C: TARGET:cap://cal.foo.com/bill C: BEGIN:VQUERY C: SCOPE:VEVENT C: QUERY SELECT="UID" C: WHERE (UID EQ abcd12345) C: END:VQUERY C: END:VCOMMAND C: END:VCALENDAR C: . S: 2.0 S: . And an example to delete the 'MrBill' calendar: C: SENDDATA C: Content-Type:text/calendar; method=DELETE; component=VCOMMAND C: Content-Transfer-Encoding:7bit C: C: BEGIN:VCALENDAR C: BEGIN:VCOMMAND C: METHOD:DELETE C: TARGET:cap://cal.foo.com/MrBill C: END:VCOMMAND C: END:VCALENDAR C: . S: 2.0 S: . Mansour/Dawson/Royer/Taler/Hill 43 Expires September 2000 Internet Draft CAP March 10, 2000 C: SENDDATA C: 7.2.1.3. GENERATEUID Method Arguments: Number of UIDs to generate. Data: new uids Result: 2.0 GENERATEUID returns one or more new unique identifier which MUST be unique on the server's calendar store. It is recommended that the return value be a globally unique id. Example: C: GENERATEUID 2 S: 2.0 abcde1234567-asdf-lkhh abcde1234567-asdf-3455 [Editors note: this example needs work. It's not packaged right] 7.2.1.4. MODIFY Method Arguments: none Data: no specific data for this command Result: 2.0 - successfully modified the component or calendar Permission Calendar or component not found Bad args Container(s) not found The MODIFY method is used to change an existing calendar or component. TARGET specify the container(s) of the modification. When modifying a calendar at the top level, the CSID is specified. Otherwise the container will be a CalID. The format of the request is two or three containers inside of a VCOMMAND container: BEGIN:VCOMMAND [VQUERY] OLD-VALUES NEW-VALUES END:VCOMMAND If a VQUERY is present, then only objects matching the query results are modified. In the example below, the start and end time of the event with UID abcd12345 is changed and the LOCATION property is removed. Mansour/Dawson/Royer/Taler/Hill 44 Expires September 2000 Internet Draft CAP March 10, 2000 C: SENDDATA C: Content-type:text/calendar; Method=MODIFY; Component=VCOMMAND C: C: BEGIN:VCALENDAR C: VERSION:2.1 C: METHOD:MODIFY C: TARGET:relcal2 C: BEGIN:VCOMMAND C: BEGIN:VQUERY C: SCOPE:VEVENT C: QUERY:SELECT UID WHERE (UID EQ abcd12345) C: END:VQUERY C: BEGIN:VEVENT C: DTSTART:19990421T160000Z C: DTEND:19990421T163000Z C: LOCATION:Joe's Diner C: END:VEVENT C: BEGIN:VEVENT C: DTSTART:19990421T160000Z C: DTEND:19990421T163000Z C: END:VEVENT C: END:VCOMMAND C: END:VCALENDAR C: . S: 2.0 cap://cal.example.com/relcal2 And in this example, all instances of "Building 6" are replaced by "New office lobby" in VEVENTs: C: SENDDATA C: Content-type:text/calendar; Method=MODIFY; Component=VCOMMAND C: C: BEGIN:VCALENDAR C: VERSION:2.1 C: METHOD:MODIFY C: TARGET:relcal2 C: BEGIN:VCOMMAND C: BEGIN:VEVENT C: LOCATION:Building 6 C: END:VEVENT C: BEGIN:VEVENT C: LOCATION:New office lobby C: END:VEVENT C: END:VCOMMAND C: END:VCALENDAR C: . S: 2.0 cap://cal.example.com/relcal2 7.2.1.5. MOVE Method Arguments: ContainerId Mansour/Dawson/Royer/Taler/Hill 45 Expires September 2000 Internet Draft CAP March 10, 2000 Data: data as described below Result: 2.0 - success 2.2 - will attempt operation on the remote cap server Permission Calendar already exists Bad args Parent Calendar(s) not found This method is used to move a calendar within the CS's hierarchy of calendars. [Editors Note: there could be VCAR issues with this... if a VCAR's scope of influence is limited to a calendar, we are probably OK. We should discuss this one] 7.2.1.6. NOOP Method Arguments: none Data: none Result: 2.0 - success This method does nothing. It can be sent to the server periodically to request that the CS not time out the session. 7.2.1.7. READ Method Arguments: ContainerId Data: data as described below Result: 2.0 - successful and the requested data follows 2.2 - will attempt read on the remote cap server Permission Bad args Read Events In the example below events on March 10,1999 between 080000Z and 190000Z are read. In this case only 4 properties for each event are returned. Two calendars are specified. Only booked (vs scheduled) entries are to be returned. C: SENDDATA C: Content-type:text/calendar; Method=READ; Component=VQUERY C: C: BEGIN:VCALENDAR C: VERSION:2.1 C: METHOD:READ Mansour/Dawson/Royer/Taler/Hill 46 Expires September 2000 Internet Draft CAP March 10, 2000 C: CMDID:xyz12345 C: TARGET:relcal2 C: TARGET:cap://bobo.ex.com/relcal3 C: BEGIN:VQUERY C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID) C: FROM VEVENT C: WHERE (DTEND >= 19990310T080000Z AND C: DTSTART <= 19990310T190000Z AND METHOD EQ CREATE) C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY) C: END:VQUERY C: END:VCALENDAR C: . S: 2.0 cap://cal.example.com/relcal2 S: Content-type:text/calendar; Method=RESPONSE; S: Optinfo=VERSION:2.1 S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: METHOD:RESPONSE S: BEGIN:VEVENT S: DTSTART:19990310T090000Z S: DTEND:19990310T100000Z S: UID:abcxyz12345 S: SUMMARY:Meet with Sir Elton S: END:VEVENT S: BEGIN:VEVENT S: DTSTART:19990310T130000Z S: DTEND:19990310T133000Z S: UID:abcxyz8999 S: SUMMARY:Meet with brave brave Sir Robin S: END:VEVENT S: END:VCALENDAR S: . S: 2.0 cap://bobo.ex.com/relcal3 S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; S: Optinfo=VERSION:2.1 S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: METHOD:RESPONSE S: BEGIN:VDATA S: BEGIN:VEVENT S: DTSTART:19990310T140000Z S: DTEND:19990310T150000Z S: UID:123456asdf S: SUMMARY:Summer Budget S: END:VEVENT S: END:VDATA S: END:VCALENDAR S: . Mansour/Dawson/Royer/Taler/Hill 47 Expires September 2000 Internet Draft CAP March 10, 2000 The return values are subject to VCAR filtering. That is, if the request contains properties to which the UPN does not have access, those properties will not appear in the return values. If the UPN has access to at least one property of events, but has been denied access to all properties called out in the request, the response will contain a single RESPONSE-CODE property indicating the error. That is, the VEVENT components will be the following: S: 2.0 cap://bobo.ex.com/sally S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; S: Optinfo=VERSION:2.1 S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: BEGIN:VDATA S: BEGIN:VEVENT S: RESPONSE-CODE:3.8 S: END:VEVENT S: END:VDATA S: END:VCALENDAR S: . If the UPN has no access to any events at all, the response will simply be an empty data set. The response looks the same if there are particular events to which the requester has been denied access. S: 2.0 cap://bobo.ex.com/sally S: Content-type:text/calendar; Method=RESPONSE;Component=VDATA; S: Optinfo=VERSION:2.1 S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: BEGIN:VDATA S: END:VDATA S: END:VCALENDAR S: . Find alarms within a range of time for booked (METHOD EQ CREATE) VEVENTs. C: SENDDATA C: Content-type:text/calendar; Method=READ; Component=VQUERY C: C: BEGIN:VCALENDAR C: VERSION:2.1 C: METHOD:READ C: CMDID:xyz12345 C: TARGET:relcal2 C: TARGET:cap://bobo.ex.com/relcal3 C: BEGIN:VQUERY C: QUERY:SELECT (VEVENT.DTSTART, Mansour/Dawson/Royer/Taler/Hill 48 Expires September 2000 Internet Draft CAP March 10, 2000 VEVENT.DTEND,VEVENT.SUMMARY, VEVENT.UID, VALARM.*) C: FROM VEVENT,VTODO C: WHERE (VALARM.TRIGGER >= 19990310T080000Z AND C: VALARM.TRIGGER <= 19990310T190000Z AND METHOD EQ CREATE) C: ORDERBY (VALARM.TRIGGER ASC) C: END:VQUERY C: END:VCALENDAR C: . S: 2.0 cap://bobo.ex.com/relcal3 S: Content-type:text/calendar; Method=RESPONSE; S: Optinfo=VERSION:2.1 S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: METHOD:RESPONSE S: CMDID:xyz12345 S: TARGET:cap://bobo.ex.com/relcal3 S: BEGIN:VEVENT S: DTSTART:19990310T130000Z S: DTEND:19990310T133000Z S: UID:abcxyz8999 S: SUMMARY:Meet with brave brave Sir Robin S: BEGIN:VALARM S: TRIGGER:19990310T132500Z S: SUMMARY:Almost time.. S: ACTION:DISPLAY S: END:VALARM S: END:VEVENT S: END:VCALENDAR S: . S: 2.0 cap://bobo.ex.com/relcal2 S: Content-type:text/calendar; Method=RESPONSE; S: Optinfo=VERSION:2.1 S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: METHOD:RESPONSE S: CMDID:xyz12345 S: TARGET:cap://bobo.ex.com/relcal2 S: BEGIN:VEVENT S: REQUEST-STATUS:2.0 S: END:VEVENT S: END:VCALENDAR S: . Mansour/Dawson/Royer/Taler/Hill 49 Expires September 2000 Internet Draft CAP March 10, 2000 7.2.2. Scheduling Commands The following provide a set of scheduling commands (or methods) in CAP. Scheduling commands allow a CU to indirectly manipulate a calendar by asking another CU to perform an operation on their calendar. For example, CU-A can request CU-B to add a meeting to their calendar; in effect inviting CU-B to the meeting. Calendar access rights can be granted for scheduling commands without granting rights for more generalized access with the calendar commands. [Editors Note: This section needs to be completed by adding the restriction tables for each of these iTIP methods. The basis for the text is to be taken from [RFC2446].] 7.2.2.1. Reading out scheduling components A CU might be invided to a meeting. If the CU had been invided by CAP, the entry in the CU calendar will be scheduled, but not booked. So a CUA will need to look for scheduled entries in the calendar and present them to the CU or automaticly decide if the invitation is to be acceped or processed. Example: The little league coach places the teams entire schedule into your calendar. Lets say that every game and practice is on a Firday night and your calendar now has this iTIP scheduling data: BEGIN:VCALENDAR VERSION:2.0 METHOD:PUBLISH BEGIN:VEVENT DTSTAMP;TZID=US/Pacific:20000229T180000 DTSTART;TZID=US/Pacific:20000303T180000 ORGANIZER:coach@little.league.com SUMMARY: Schedule of games and practice UID:1-coarch@little.league.com SEQUENCE:0 DESCRIPTION:Please have your child at the field and ready to play by 6pm. RRULE:FREQ=WEEKLY;COUNT=10 END:VEVENT END:VCALENDAR At this point the above VEVENT is not booked in your calendar, It is simpley scheduled. A CUA would fetch this and all other scheduled VEVENTs from your calendar with: C: SENDDATA C: Content-type:text/calendar; Method=READ; Component=VQUERY C: C: BEGIN:VCALENDAR C: VERSION:2.1 Mansour/Dawson/Royer/Taler/Hill 50 Expires September 2000 Internet Draft CAP March 10, 2000 C: METHOD:READ C: CMDID:xyz12345 C: TARGET:relcal2 C: BEGIN:VQUERY C: QUERY:SELECT (VEVENT.*) C: FROM VEVENT C: WHERE (METHOD != CREATE) C: END:VQUERY C: END:VCALENDAR C: . The the CUA and CU could determine which scheduling items were to remain on the calendar. Each scheduling component could be deleted or updated with METHOD:MODIFY to change the METHOD from PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINE-COUNTER to what the CU and CUA had decided. In some cases the CUA could automaticly do the work and inform the CU. An example of this is CANCEL. If configured to process METHOD:CANCEL it could METHOD:DELETE the component an inform the CU that the booked component had been canceled. The CUA MUST process the scheduled components in the order sent. Some optimization could be done by the CUA. One example is if a PUBLISH and later a CANCEL for the same component with the same SEQUENCE number were scheduled, but not booked. The CUA might never inform the CU and just treat it as if the PUBLISH had never been received by doing a METHOD:DELETE on both entries. It is important to note that scheduled components do not show up in busy time as BUSY. Only when they are booked does the TRANSP:OPAQUE property take effect. A CS implementation could mark the time as TENTATIVE. This is an implementation and administrative choice. 7.2.2.2. PUBLISH Arguments: Data: data as described below Result: 2.0 - success 2.2 - will attempt operation on the remote cap server Permission Calendar already exists Bad args Parent Calendar(s) not found This method is used to move a calendar within the CS's hierarchy of calendars. If the CU wishes to keep the published entry. A METHOD:MODIFY changing the entries METHOD from PUBLISH to CREATE would be done, booking the entry. Or METHOD:DELETE if the CU did not wish this scheduled item to exist in their calendar. Mansour/Dawson/Royer/Taler/Hill 51 Expires September 2000 Internet Draft CAP March 10, 2000 7.2.2.3. REQUEST 7.2.2.4. REPLY 7.2.2.5. ADD 7.2.2.6. CANCEL 7.2.2.7. REFRESH 7.2.2.8. COUNTER 7.2.2.9. DECLINECOUNTER 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 incoming 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 processed even if the Sequence number is stale. 7.2.3.1. Sending and Receiving an iTIP request In this example A invites B and C to a meeting, B accepts the meeting and C rejects it. The calendars for A, B and C are relcal1, relcal2 and relcal3 respectively, and are all on the same server, "cal.foo.com". A lot of these described actions are performed by the CUAs and not the users themselves, the CUAs are called A-c, B-c and C-c respectively. A wishes to create a meeting with B and C, so A-c uses CAP to send the following iTIP request to relcal2 and relcal3, while logged in to "cal.foo.com". BEGIN:VCALENDAR VERSION:2.1 CMDID:xhj-dd METHOD:REQUEST TARGET:cap://cal.foo.com/relcal2 TARGET:relcal3 BEGIN:VEVENT UID:abcd12345 DTSTART:19990307T180000Z Mansour/Dawson/Royer/Taler/Hill 52 Expires September 2000 Internet Draft CAP March 10, 2000 DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal2 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 SUMMARY:Important Meeting END:VEVENT END:VCALENDAR An incoming event (indicated by the value of the "METHOD" property) then appears in relcal2 and relcal3, with the following data: BEGIN:VEVENT METHOD:REQUEST UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal2 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 SUMMARY:Important Meeting END:VEVENT B-c and C-c must search for such incoming events, they do so using the following CAP search: BEGIN:VCALENDAR VERSION:2.1 METHOD:READ CMDID:xhr-de TARGET:relcal2 # or TARGET:relcal3 BEGIN:VQUERY QUERY:SELECT (ALL); FROM VEVENT; WHERE (METHOD == REQUEST); END:VQUERY END:VCALENDAR In response to this search they get the above event. B-c and C-c must then crack open the VEVENT, find the UID and determine if there is already an event on their calendar with that UID. To do this they use the following search: BEGIN:VCALENDAR VERSION:2.1 METHOD:READ CMDID:xhr-df TARGET:relcal2 BEGIN:VQUERY QUERY:SELECT (*) FROM VEVENT WHERE (UID == abcd12345 AND METHOD == CREATE) END:VQUERY Mansour/Dawson/Royer/Taler/Hill 53 Expires September 2000 Internet Draft CAP March 10, 2000 END:VCALENDAR We assume that the event is not already in their relcal2 or relcal3. B-c prompts B who decides to accept the meeting request, and B-c creates a copy of the event in relcal2, with the "PARTSTAT" parameter set to ACCEPTED. B-c also sends this copy to the Organizer at relcal1 as an iTIP REPLY, preserving the CMDID: BEGIN:VCALENDAR VERSION:2.1 CMDID:xhj-dd METHOD:REPLY TARGET:cap://cal.foo.com/relcal1 BEGIN:VEVENT UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 SUMMARY:Important Meeting END:VEVENT END:VCALENDAR C, on the other hand, decides to decline the meeting, and C-c sends a reply to the Organizer to that effect, as follows: BEGIN:VCALENDAR VERSION:2.1 CMDID:xhj-dd METHOD:REPLY TARGET:cap://cal.foo.com/relcal1 BEGIN:VEVENT UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 SUMMARY:Important Meeting END:VEVENT END:VCALENDAR It is preferable that C-c store the event in relcal3 even though it has been declined. Storing the event in relcal3 allows subsequent iTIP messages to be interpreted correctly. The "PARTSTAT" parameter indicates that the event was refused. After receiving the replies from relcal2 and relcal3, A-c updates the version of the event in relcal1 to indicate the new participation statii: BEGIN:VEVENT METHOD:REQUEST Mansour/Dawson/Royer/Taler/Hill 54 Expires September 2000 Internet Draft CAP March 10, 2000 UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 SUMMARY:Important Meeting END:VEVENT A-c then sends a new iTIP request to relcal2 only, indicating the updated information. 7.2.3.2. Handling an iTIP refresh A little bit later, C is thinking about accepting the event in the previous example, but first wants to check the current state of the event. To find the current state C-c uses the iTIP "REFRESH" method, sending the following to relcal1: BEGIN:VCALENDAR VERSION:2.1 CMDID:xud-pn METHOD:REFRESH TARGET:cap://cal.foo.com/relcal1 BEGIN:VEVENT UID:abcd12345 ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE:cap://cal.foo.com/relcal3 DTSTAMP:19990306T202333Z END:VEVENT END:VCALENDAR A-c finds the refresh as an incoming iTIP, and searches for the corresponding event. Having found the event (with no changes since the last example) A-c then verifies that relcal3 is in fact an Attendee of the event and is thus allowed to request a refresh. (In the case of a published event things are more complicated.) A-c packages the event up as an iTIP request and sends it to relcal3: BEGIN:VCALENDAR VERSION:2.1 CMDID: xud-pn METHOD:REQUEST TARGET:cap://cal.foo.com/relcal3 BEGIN:VEVENT UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 SUMMARY:Important Meeting Mansour/Dawson/Royer/Taler/Hill 55 Expires September 2000 Internet Draft CAP March 10, 2000 SEQUENCE:0 DTSTAMP:19990306T204333Z END:VEVENT END:VCALENDAR [Ed. - should the CMDID match that of the REFRESH?] 7.2.3.3. Sending and accepting an iTIP counter Having received the latest copy of the event C wishes to propose a venue for the event, using an iTIP COUNTER. To do this C-c sends the following to relcal1: BEGIN:VCALENDAR VERSION:2.1 CMDID:zzykjjk METHOD:COUNTER TARGET:cap://cal.foo.com/relcal1 BEGIN:VEVENT UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 SUMMARY:Important Meeting LOCATION:La Belle Province COMMENT:My favourite restaurant, I'll definitely go if it's there. END:VEVENT END:VCALENDAR Having sent the information to relcal1, C-c shouldn't store the new details in relcal3. If C-c updated the version in relcal3 and relcal1 did not reply to the counter, then relcal3 would have incorrect information. Instead C-c preserves the correct information and waits for a response from relcal1. A CUA implementation may wish to preserve this information itself, externally to the CS. In order to receive an iTIP counter A-c follows the same search as for other iTIP data, first find the incoming message, next find any matching events in the calendar store. Having found the matching event, A reviews the proposed changes and decides to accept the COUNTER. To do this, A-c modifies the version in relcal1 (bumping the sequence number) to: BEGIN:VEVENT METHOD:CREATE UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal2 ATTENDEE;PARTSTAT=DECLINED:cap://cal.foo.com/relcal3 SUMMARY:Important Meeting LOCATION:La Belle Province SEQUENCE:1 END:VEVENT A-c then sends the updated version as a request to both relcal2 and Mansour/Dawson/Royer/Taler/Hill 56 Expires September 2000 Internet Draft CAP March 10, 2000 relcal3: BEGIN:VCALENDAR VERSION:2.1 CMDID:xup-po METHOD:REQUEST TARGET:cap://cal.foo.com/relcal2 TARGET:cap://cal.foo.com/relcal3 BEGIN:VEVENT UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal2 ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION:cap://cal.foo.com/relcal3 SUMMARY:Important Meeting LOCATION:La Belle Province SEQUENCE:1 DTSTAMP:19990307T054339Z END:VEVENT END:VCALENDAR 7.2.3.4. Declining an iTIP counter B does not like the new location and also counters the event, B-c sends the following iTIP: BEGIN:VCALENDAR VERSION:2.1 CMDID:xim-ef METHOD:COUNTER TARGET:cap://cal.foo.com/relcal1 BEGIN:VEVENT UID:abcd12345 DTSTART:19990307T180000Z DTEND:19990307T190000Z ORGANIZER:cap://cal.foo.com/relcal1 ATTENDEE:cap://cal.foo.com/relcal2 SUMMARY:Important Meeting LOCATION:Au Coin Dor=E9 END:VEVENT END:VCALENDAR However, C does not accept the counter, and C-c replies with a decline counter: BEGIN:VCALENDAR VERSION:2.1 CMDID:xim-ef METHOD:DECLINE-COUNTER TARGET:cap://cal.foo.com/relcal2 BEGIN:VEVENT Mansour/Dawson/Royer/Taler/Hill 57 Expires September 2000 Internet Draft CAP March 10, 2000 DTSTAMP:19990307T093245Z UID:abcd12345 ORGANIZER:cap://cal.foo.com/relcal1 SEQUENCE:1 END:VEVENT END:VCALENDAR Fortunately B-c kept the original information when sending the counter, and there is no problem when no information is returned in the DECLINE- COUNTER. 8. Response Codes Numeric response codes are returned at both the transfer and application layer. The same set of codes is used in both cases. [Editors Note: Do we want to use the same set of codes?] The format of these codes is described in [RFC2445], and extend in [RFC2446] and [RFC2447]. The following describes new codes added to this set. At the application layer response codes are returned as the value of a "REQUEST-STATUS" property. The value type of this property is modified from that defined in [RFC2445], to make the accompanying text optional. Code Params Description ---------------------------------------------------------- 2.0 varies Success, The parameters vary with the operation and are specified. 2.0.1 none Success, send data, terminate with <CRLF>.<CRLF> 2.0.2 A reply is pending. It could not be com- pleted in the specified amount of time. The server awaits a CONTINUE or ABORT command. 2.0.3 In response to the client issuing an ABORT command, this reply code indicates that any command currently underway was successfully aborted. Mansour/Dawson/Royer/Taler/Hill 58 Expires September 2000 Internet Draft CAP March 10, 2000 2.0.6 An operation is being attempted on a re- mote server. This response indicates that the server has not yet been con- tacted but an attempt will be made to contact it after the command has been sent. 3.1.4 Capability not supported. 4.1 Calendar store access denied. 6.1 Authenticate failure: unsupported au- thentication mechanism, credentials re- jected. 6.2 Sender aborted authentication, authenti- cation exchange cancelled. 6.3 Attempt to create or modify an event such that it would overlap another event in either of the following two circum- stances: (a) One of the events has a TRANSP prop- erty set to OPAQUE-NOCONFLICT or TRANS- PARENT-NOCONFLICT. (b) The calendar's ALLOW-CONFLICT prop- erty is set to NO. 7.0 A timeout has occurred. The server was unable to complete the operation in the requested time. 8.0 A failure has occurred in the Receiver that prevents the operation from suc- ceeding. 8.1 Sent when a session cannot be estab- lished because the CAP Server is too busy. 8.2 Used to signal that an ICAL object has exceeded the server's size limit 8.3 A DATETIME value was too large to be represented on this Calendar. 8.4 A DATETIME value was too far in the past to be represented on this Calendar. Mansour/Dawson/Royer/Taler/Hill 59 Expires September 2000 Internet Draft CAP March 10, 2000 8.5 An attempt was made to create a new ob- ject but the unique id specified is al- ready in use. 8.6 ID clash 9.0 An unrecognized command was received. 10.1 Accompanied by an alternate address. The RECIPIENT specified should be contacted at the given alternate address. The re- ferral address MUST follow the reply code. 10.2 The server is shutting down. 10.4 The operation has not be performed be- cause it would cause the resources (mem- ory, disk,CPU, etc) to exceed the allo- cated quota. 10.5 The ITIP message has been queued too too long. Delivery has been aborted. ---------------------------------------------------------- 8.1. Minimum CS query implementation The following is a MUST for a CS implementation. 8.1.1. Query by UID <TBD> 8.1.2. Query by Date / Date-Time range <TBD> 8.1.2.1. Date/Date-Time query with subset of properties <TBD> 8.1.3. <TBD> <TBD> 9. Detailed SQL Schema This section describes a conceptual schema for object model in CAP. It is used as the basis for querying data managed by the CS. This is only a conceptual schema. Implementations can use any schema they like so long as they are prepared to map CAP queries that are expressed in this conceptual schema. Implementations are not required to use SQL database technology. The protocol is designed such that a CUA does not need to Mansour/Dawson/Royer/Taler/Hill 60 Expires September 2000 Internet Draft CAP March 10, 2000 understand SQL. The CUA just sends strings that happen to be valid SQL queries. This schema is based on SQL-92 [SQL] along with the [SQLCOM] corrections. Properties than can occur multiple times are intended to be put in separate tables. For example BEGIN:VEVENT UID:1 DTSTART:19990326T201400Z ORGANIZER:mailto:sam@abc.COM SUMMARY:I have 2 attachments ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell.au ATTACHMENT;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell2.au END:VEVENT There are two ATTACHMENT properties each having a unique value. These are kept in separate tables. This is diagrammed below. The diagram is not a complete representation of the VEVENT table. It is an abbreviated table used to illustrate how properties that can occur multiple times are intended to be represented. +----------------------------------------------------------------------+ | ABBREVIATED VEVENT TABLE | +----+-----------------+---------------------+--------------+----------+ | | | | | | |UID |DTSTART |ORGANIZER |SUMMARY |ATTACH_KEY| +----+-----------------+---------------------+--------------+----------+ |1 |19990326T201400Z |mailto:sam@abc.com |I have 2 at- |123 | | | | |tachments | | +----+-----------------+---------------------+--------------+----------+ |999 |19700101T000000Z |mailto:user@host.com |I have no | | | | | |attachments | | +----+-----------------+---------------------+--------------+----------+ Mansour/Dawson/Royer/Taler/Hill 61 Expires September 2000 Internet Draft CAP March 10, 2000 +-----------------------------------------------------------------------+ | ABBREVIATED ATTACH_KEY TABLE | +------------+------------------------------------+---------------------+ | | | | |ATTACH_KEY |VALUE | INLINE_BLOB | +------------+------------------------------------+---------------------+ |123 |ftp://host.com/pub/sounds/bell.au | | +------------+------------------------------------+---------------------+ |123 |ftp://host.com/pub/sounds/bell2.au | | +------------+------------------------------------+---------------------+ |234 | | MIICajCCAdO-gAw- | | | | IBAgICBEU <...re- | | | | mainder of "BASE64" | | | | encoded binary da- | | | | ta...> | +------------+------------------------------------+---------------------+ 9.1. iCalendar Store Schema The following defines the schema for an iCalendar object and the components, properties, and parameters defined and used in [RFC2445], [RFC2446], [RFC2447], and [CAP]. NOTES: CURRENT_DATETIME would not be stored in the database. It is selectable and read only. When supporting virtual hosts, there could be more than one row in the CALSTORE table. And then the CSID MUST not be empty. TIMESTAMP(14) is the SQL value equivelant of DATE-TIME. FLOAT(7,3) is an SQL 3x3 floating number (xxx.yyy). 9.1.1. ACTION schema /* * If VALUE is NULL, then OTHER_VALUE contains non-rfc2445 value . */ CREATE TABLE ACTION ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE ENUM("AUDIO", "DISPLAY", "EMAIL", "PROCEDURE") NOT NULL, OTHER_VALU TEXT, XPARAM INTEGER /* VALUE_KEY */ ); Mansour/Dawson/Royer/Taler/Hill 62 Expires September 2000 Internet Draft CAP March 10, 2000 9.1.2. ATTACH schema /* * VALUE is a FILE uri. The data is decoded (per ENCODING) prior to being * stored into the file */ CREATE TABLE ATTACH ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE VARCHAR(255) NOT NULL, ISBINARY ENUM("T", "F") DEFAULT "F", FMTTYPE INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.3. ATTENDEE schema CREATE TABLE ATTENDEE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT, CUTYPE INTEGER, /* VALUE_KEY */ MEMBER INTEGER, /* VALUE_KEY */ ROLE INTEGER, /* VALUE_KEY */ PARTSTAT INTEGER, /* VALUE_KEY */ RSVP ENUM("T", "F") DEFAULT "F", DELEGATED_TO INTEGER, /* VALUE_KEY */ DELEGATED_FROM INTEGER, /* VALUE_KEY */ CN INTEGER, /* VALUE_KEY */ DIR INTEGER, /* VALUE_KEY */ LANGUAGE INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.4. CALSTORE schema CREATE TABLE CALSTORE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, CSID VARCHAR(255) NOT NULL, CALMASTER TINYTEXT NOT NULL, DEFAULT_VCAR INTEGER, /* VALUE_KEY */ MAXDATE TIMESTAMP(14) NOT NULL DEFAULT "99991231235959", MINDATE TIMESTAMP(14) NOT NULL DEFAULT "00000101000000", CURRENT_DATETIME TIMESTAMP(14) NOT NULL, RECUR_ACCEPTED ENUM("T", "F") NOT NULL DEFAULT "T", RECUR_EXPAND ENUM("T", "F") NOT NULL DEFAULT "T", RECUR_LIMIT INTEGER DEFAULT 0, VERSION VARCHAR(10) NOT NULL DEFAULT "2.0" ); Mansour/Dawson/Royer/Taler/Hill 63 Expires September 2000 Internet Draft CAP March 10, 2000 9.1.5. CHILDREN schema CREATE TABLE CHILDREN ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, /* KEY_VALUE */ CALID VARCHAR(255) ); 9.1.6. CLASS schema CREATE TABLE CLASS ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE ENUM("PUBLIC", "PRIVATE", "CONFIDENTIAL", "<other>") NOT NULL, OTHER_VALUE TEXT, XPARAM INTEGER /* VALUE_KEY */ ); 9.1.7. CN schema CREATE TABLE CN ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE VARCHAR(255) NOT NULL ); 9.1.8. COMMENT schema CREATE TABLE COMMENT ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT NOT NULL, ALTREP INTEGER, /* VALUE_KEY */ LANGUAGE INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.9. CONTACT schema CREATE TABLE CONTACT ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TINYTEXT NOT NULL, ALTREP VARCHAR(255), LANGUAGE INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); Mansour/Dawson/Royer/Taler/Hill 64 Expires September 2000 Internet Draft CAP March 10, 2000 9.1.10. CREATED schema CREATE TABLE CREATED ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TIMESTAMP(14) NOT NULL, VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ TZID INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.11. CUTYPE schema CREATE TABLE CUTYPE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE ENUM("INDIVIDUAL", "GROUP", "RESOURCE", "ROOM", "UNKNOWN", "<other>") NOT NULL, OTHER_VALUE TINYTEXT ); 9.1.12. DAYLIGHT_STANDARD schema CREATE TABLE DAYLIGHT_STANDARD ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, DTSTART INTEGER NOT NULL, /* VALUE_KEY */ TZOFFSETFROM INTEGER NOT NULL, /* SECONDS */ TZOFFSETTO INTEGER NOT NULL, /* SECONDS */ COMMENT INTEGER, /* VALUE_KEY */ RDATE INTEGER, /* VALUE_KEY */ RRULE INTEGER, /* VALUE_KEY */ TZNAME TINYTEXT, XPROP INTEGER /* VALUE_KEY */ ); 9.1.13. DESCRIPTION schema CREATE TABLE DESCRIPTION ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT, ALTREP INTEGER, /* VALUE_KEY */ Mansour/Dawson/Royer/Taler/Hill 65 Expires September 2000 Internet Draft CAP March 10, 2000 LANGUAGE INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.14. DIR schema CREATE TABLE DIR ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT ); 9.1.15. DTEND schema CREATE TABLE DTEND ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TIMESTAMP(14) NOT NULL, VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ TZID INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.16. DTSTAMP schema CREATE TABLE DTSTART ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TIMESTAMP(14) NOT NULL, VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ TZID INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.17. DUE schema CREATE TABLE DUE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TIMESTAMP(14) NOT NULL, VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ TZID INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); Mansour/Dawson/Royer/Taler/Hill 66 Expires September 2000 Internet Draft CAP March 10, 2000 9.1.18. DURATION schema CREATE TABLE DURATION ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE INTEGER, /* SECONDS */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.19. EXDATE schema CREATE TABLE EXDATE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TIMESTAMP(14) NOT NULL, VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ TZID INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.20. EXRULE schema CREATE TABLE EXRULE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE INTEGER NOT NULL, /* VALUE_KEY (RECUR) */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.21. FBTYPE schema CREATE TABLE FBTYPE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE ENUM("FREE", "BUSY", "BUSY-UNAVALIBLE", "BUSY-TENTATIVE", "<other>") NOT NULL, OTHER_VALUE TINYTEXT ); 9.1.22. FMTTYPE schema CREATE TABLE FMTTYPE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TINYTEXT ); Mansour/Dawson/Royer/Taler/Hill 67 Expires September 2000 Internet Draft CAP March 10, 2000 9.1.23. FREEBUSY schema CREATE TABLE FREEBUSY ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE_FROM TIMESTAMP(14) NOT NULL, VALUE_TO TIMESTAMP(14), DURATION INTEGER, /* SECONDS */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.24. GEO schema CREATE TABLE GEO ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, LATITUDE FLOAT(7,3), LONGITUDE FLOAT(7,3), XPARAM INTEGER /* VALUE_KEY */ ); 9.1.25. LANGUAGE schema CREATE TABLE LANGUAGE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TINYTEXT ); 9.1.26. LAST_MODIFIED schema CREATE TABLE LAST_MODIFIED ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TIMESTAMP(14) NOT NULL, XPARAM INTEGER /* VALUE_KEY */ ); 9.1.27. MEMBER schema CREATE TABLE MEMBER ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT ); Mansour/Dawson/Royer/Taler/Hill 68 Expires September 2000 Internet Draft CAP March 10, 2000 9.1.28. METHOD schema CREATE TABLE METHOD ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE ENUM("PUBLISH", "REQUEST", "REFRESH", "CANCEL", "ADD", "REPLY", "COUNTER", "DECLINE-COUNTER", "CREATE", "DELETE", "MODIFY", "MOVE", "READ", "<other>") NOT NULL, OTHER_VALUE TEXT ); 9.1.29. ORGANIZER schema CREATE TABLE ORGANIZER ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT NOT NULL, CN INTEGER, /* VALUE_KEY */ DIR INTEGER, /* VALUE_KEY */ SENT_BY INTEGER, /* VALUE_KEY */ LANGUAGE INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.30. OWNERS schema CREATE TABLE OWNERS ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TINYTEXT NOT NULL ); 9.1.31. PARTSTAT schema CREATE TABLE PARTSTAT ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE ENUM("NEEDS-ACTION", "ACCEPTED", "DECLINED", Mansour/Dawson/Royer/Taler/Hill 69 Expires September 2000 Internet Draft CAP March 10, 2000 "TENTATIVE", "DELEGATED", "COMPLETED", "IN-PROCESS", "<other>") NOT NULL DEFAULT "NEEDS-ACTION", OTHER_VALUE TINYTEXT ); 9.1.32. PERCENT_COMPLETE schema CREATE TABLE PERCENT_COMPLETE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE INTEGER NOT NULL, XPARAM INTEGER /* VALUE_KEY */ ); 9.1.33. PRIORITY schema CREATE TABLE PRIORITY ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE INTEGER NOT NULL, XPARAM INTEGER /* VALUE_KEY */ ); 9.1.34. RDATE schema /* VALUETYPE (D) = DATE, (T) = DATE-TIME, (P) = PERIOD */ CREATE TABLE RDATE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TIMESTAMP(14) NOT NULL, VALUETYPE ENUM("D", "T", "P") NOT NULL DEFAULT "T", TZID INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.35. RECUR schema CREATE TABLE RECUR ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, FREQ ENUM("SECONDLY", "MINUTELY", "HOURLY", "DAILY", "WEEKLY", "MONTHLY", "YEARLY"), UNTIL TIMESTAMP(14), COUNT INTEGER, INTERVAL_VAL INTEGER, Mansour/Dawson/Royer/Taler/Hill 70 Expires September 2000 Internet Draft CAP March 10, 2000 BYSECOND SET("1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23", "24", "25", "26", "27", "28", "29", "30", "31", "32", "33", "34", "35", "36", "37", "38", "39", "40", "41", "42", "43", "44", "45", "46", "47", "47", "48", "49", "50", "51", "52", "53", "54", "55", "56", "57", "58", "59"), BYMINUTE SET("1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23", "24", "25", "26", "27", "28", "29", "30", "31", "32", "33", "34", "35", "36", "37", "38", "39", "40", "41", "42", "43", "44", "45", "46", "47", "47", "48", "49", "50", "51", "52", "53", "54", "55", "56", "57", "58", "59"), BYHOUR SET("1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23"), BYDAY TINYTEXT, BYMONTHDAY SET("1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23", "24", "25", "26", "27", "28", "29", "30", "31", "-1", "-2", "-3", "-4", "-5", "-6", "-7", "-8", "-9", "-10", "-11", "-12", "-13", "-14", "-15", "-16", "-17", "-18", "-19", "-20", "-21", "-22", "-23", "-24", "-25", "-26", "-27", "-28", "-29", "-30", "-31"), BYYEARDAY TINYTEXT, BYWEEKNO TINYTEXT, BYMONTH SET("1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12"), BYSETPOS TINYTEXT, WKST SET("SU", "MO", "TU", "WE", "TH", "FR", "SA"), XPARAM INTEGER /* VALUE_KEY */ ); 9.1.36. RECURRENCE_ID schema CREATE TABLE RECURRENCE_ID ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TIMESTAMP(14) NOT NULL, VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ RANGE ENUM("THISANDPRIOR", "THISANDFUTURE"), TZID INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ Mansour/Dawson/Royer/Taler/Hill 71 Expires September 2000 Internet Draft CAP March 10, 2000 ); 9.1.37. RELATED_TO schema CREATE TABLE RELATED_TO ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT, RELTYPE ENUM("PARENT", "CHILD", "SIBLING", "<other>"), OTHER_RELTYPE TINYTEXT, XPARAM INTEGER /* VALUE_KEY */ ); 9.1.38. REPEAT schema CREATE TABLE REPEAT ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE INTEGER NOT NULL DEFAULT 0, XPARAM INTEGER /* VALUE_KEY */ ); 9.1.39. RESOURCES schema CREATE TABLE RESOURCES ( VALUE_Y INTEGER NOT NULL PRIMARY KEY, VALUE TEXT NOT NULL, ALTREP INTEGER, /* VALUE_KEY */ LANGUAE INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.40. ROLE schema CREATE TABLE ROLE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE ENUM("CHAIR", "REQ-PARTICIPANT", "OPT-PARTICIPANT", "NON-PARTICIPANT", "<other>") NOT NULL DEFAULT "REQ-PARTICIPANT", OTHER_VALUE TINYTEXT ); Mansour/Dawson/Royer/Taler/Hill 72 Expires September 2000 Internet Draft CAP March 10, 2000 9.1.41. RRULE schema CREATE TABLE RRULE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE INTEGER NOT NULL, /* VALUE_KEY (RECUR) */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.42. SEQUENCE schema CREATE TABLE SEQUENCE ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY DEFAULT 0, VALUE INTEGER NOT NULL, XPARAM INTEGER /* VALUE_KEY */ ); 9.1.43. STATUS schema CREATE TABLE STATUS ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE ENUM("TENTATIVE", "CONFIRMED", "CANCELLED", "NEEDS-ACTION", "COMPLETED", "IN-PROCESS", "DRAFT", "FINAL") NOT NULL, XPARAM INTEGER /* VALUE_KEY */ ); 9.1.44. SUMMARY schema CREATE TABLE SUMMARY ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TINYTEXT, ALTREP INTEGER, /* VALUE_KEY */ LANGUAGE INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.45. TRANSP schema CREATE TABLE TRANSP ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, Mansour/Dawson/Royer/Taler/Hill 73 Expires September 2000 Internet Draft CAP March 10, 2000 VALUE ENUM("OPQQUE", "TRANSPARENT", "OPAQUE-NOCONFLICTS", "TRANSPARENT-NOCONFLICTS") NOT NULL DEFAULT "TRANSPARENT", XPARAM INTEGER /* VALUE_KEY */ ); 9.1.46. TRIGGER schema CREATE TABLE TRIGGER ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUETYPE INTEGER NOT NULL, /* VALUE_KEY */ VALUE_DT TIMESTAMP(14), VALUE_P INTEGER, /* SECONDS */ RELATED INTEGER, /* VALUE_KEY */ XPARAM INTEGER /* VALUE_KEY */ ); 9.1.47. TZID schema CREATE TABLE TZID ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT ); 9.1.48. UID schema CREATE TABLE UID ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT, XPARAM INTEGER /* VALUE_KEY */ ); 9.1.49. URL schema CREATE TABLE URL ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT, XPARAM INTEGER /* VALUE_KEY */ ); Mansour/Dawson/Royer/Taler/Hill 74 Expires September 2000 Internet Draft CAP March 10, 2000 9.1.50. VALARM schema CREATE TABLE VALARM ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, ACTION INTEGER NOT NULL, /* VALUE_KEY */ ATTACH INTEGER, DESCRIPTION INTEGER, /* VALUE_KEY */ DURATION INTEGER, /* VALUE_KEY */ REPEAT INTEGER, /* VALUE_KEY */ SUMMARY INTEGER, /* VALUE_KEY */ TRIGGER INTEGER, /* VALUE_KEY */ X_PROP INTEGER /* VALUE_KEY */ ); 9.1.51. VCALENDAR schema CREATE TABLE VCALENDAR ( VALUE_KEY INTEGER NOT NULL, ALLOW_CONFLICTS ENUM("T", "F") DEFAULT "T", CALSCALE TINYTEXT NOT NULL, CHARSET TINYTEXT NOT NULL, CHILDREN INTEGER, /* VALUE_KEY */ CREATED INTEGER, /* VALUE_KEY */ DEFAULT_VCAR INTEGER NOT NULL, /* VALUE_KEY */ LANGUAGE INTEGER, /* VALUE_KEY */ LAST_MODIFIED INTEGER, /* VALUE_KEY */ NAME TINYTEXT, OWNERS INTEGER, /* VALUE_KEY */ PARENT INTEGER, /* VALUE_KEY */ RELCALID VARCHAR(255) NOT NULL PRIMARY KEY, TOMESTONE ENUM("T", "F") NOT NULL DEFAULT "T", TZID INTEGER NOT NULL /* VALUE_KEY */ ); 9.1.52. VCAR schema CREATE TABLE VCAR ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TINYTEXT /*<TODO>*/ ); 9.1.53. VEVENT schema The METHOD value will be CREATE for booked entries. Or it must be a valid scheduling METHOD such as PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER or DECLINE-COUNTER. Mansour/Dawson/Royer/Taler/Hill 75 Expires September 2000 Internet Draft CAP March 10, 2000 CREATE TABLE VEVENT ( ATTACH INTEGER, /* VALUE_KEY */ ATTENDEE INTEGER, /* VALUE_KEY */ CATEGORIES INTEGER, /* VALUE_KEY */ CLASS INTEGER, /* VALUE_KEY */ COMMENT INTEGER, /* VALUE_KEY */ CONTACT INTEGER, /* VALUE_KEY */ CREATED INTEGER, /* VALUE_KEY */ DESCRIPTION INTEGER, /* VALUE_KEY */ DTEND INTEGER, /* VALUE_KEY */ DTSTAMP INTEGER, /* VALUE_KEY */ DTSTART INTEGER, /* VALUE_KEY */ DURATION INTEGER, /* VALUE_KEY */ EXDATE INTEGER, /* VALUE_KEY */ EXRULE INTEGER, /* VALUE_KEY */ GEO INTEGER, /* VALUE_KEY */ LAST_MODIFIED INTEGER, /* VALUE_KEY */ LOCATION INTEGER, /* VALUE_KEY */ METHOD INTEGER, /* VALUE_KEY */ ORGANIZER INTEGER, /* VALUE_KEY */ PRIORITY INTEGER, /* VALUE_KEY */ RECURRENCE_ID INTEGER, /* VALUE_KEY */ RDATE_KEY INTEGER, /* VALUE_KEY */ RELATED_TO INTEGER, /* VALUE_KEY */ RESOURCES INTEGER, /* VALUE_KEY */ RRULE INTEGER, /* VALUE_KEY */ SUMMARY INTEGER, /* VALUE_KEY */ SEQUENCE INTEGER, /* VALUE_KEY */ STATUS INTEGER, /* VALUE_KEY */ TRANSP INTEGER, /* VALUE_KEY */ UID INTEGER, /* VALUE_KEY */ URL INTEGER, /* VALUE_KEY */ X_PROP_KEY INTEGER, /* VALUE_KEY */ VALARM_KEY INTEGER /* VALUE_KEY */ ); 9.1.54. VFREEBUSY schema An implementation may not actually have a VFREEBUSY table as the information may be produced dynamicly. However a CS MUST appear to provide this table as this may be how a CUA chooses to query for VFREEBUSY information while using [CAP]. Example, it probably would not make any sense for ATTENDEE to exist in this table, yet a CUA may wish to ask for the VFREEBUSY for an ATTENDEE. CREATE TABLE VFREEBUSY ( ATTENDEE INTEGER, /* VALUE_KEY */ COMMENT INTEGER, /* VALUE_KEY */ CONTACT INTEGER, /* VALUE_KEY */ DTEND INTEGER, /* VALUE_KEY */ Mansour/Dawson/Royer/Taler/Hill 76 Expires September 2000 Internet Draft CAP March 10, 2000 DTSTAMP INTEGER, /* VALUE_KEY */ DTSTART INTEGER, /* VALUE_KEY */ FREEBUSY INTEGER, /* VALUE_KEY */ METHOD INTEGER, /* VALUE_KEY */ ORGANIZER INTEGER, /* VALUE_KEY */ X_PROP_KEY INTEGER, /* VALUE_KEY */ URL INTEGER /* VALUE_KEY */ ); 9.1.55. VJOURNAL schema The METHOD value will be CREATE for booked entries. Or it must be a valid scheduling METHOD such as PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER or DECLINE-COUNTER. CREATE TABLE VJOURNAL ( ATTACH_KEY INTEGER, /* VALUE_KEY */ CATEGORIES INTEGER, /* VALUE_KEY */ CLASS INTEGER, /* VALUE_KEY */ COMMENT INTEGER, /* VALUE_KEY */ CONTACT INTEGER, /* VALUE_KEY */ CREATED INTEGER, /* VALUE_KEY */ DESCRIPTION INTEGER, /* VALUE_KEY */ DTSTAMP INTEGER, /* VALUE_KEY */ DTSTART INTEGER, /* VALUE_KEY */ EXDATE INTEGER, /* VALUE_KEY */ EXRULE INTEGER, /* VALUE_KEY */ LAST_MODIFIED INTEGER, /* VALUE_KEY */ METHOD INTEGER, /* VALUE_KEY */ ORGANIZER INTEGER, /* VALUE_KEY */ RDATE INTEGER, /* VALUE_KEY */ RECURRENCE_ID INTEGER, /* VALUE_KEY */ RELATED_TO INTEGER, /* VALUE_KEY */ RRULE INTEGER, /* VALUE_KEY */ SEQUENCE INTEGER, /* VALUE_KEY */ STATUS INTEGER, /* VALUE_KEY */ SUMMARY INTEGER, /* VALUE_KEY */ UID INTEGER, /* VALUE_KEY */ X_PROP INTEGER /* VALUE_KEY */ ); 9.1.56. VQUERY schema Stored VQUERYs will use the following schema. CREATE TABLE VQUERY ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TINYTEXT, /* QUERYNAME */ SCOPE TINYTEXT, MAXRESULTS INTEGER, Mansour/Dawson/Royer/Taler/Hill 77 Expires September 2000 Internet Draft CAP March 10, 2000 MAXSIZE INTEGER, CARSELECT TEXT, CARWHERE TEXT, CARORDERBY TEXT, X_PROP INTEGER /* VALUE_KEY */ ); 9.1.57. VTIMEZONE schema CREATE TABLE VTIMEZONE ( DAYLIGHT INTEGER NOT NULL, /* VALUE_KEY */ STANDARD INTEGER NOT NULL, /* VALUE_KEY */ TZID INTEGER NOT NULL, /* VALUE_KEY */ TZURL INTEGER, /* VALUE_KEY */ X_PROP_KEY INTEGER /* VALUE_KEY */ ); 9.1.58. VTODO schema The METHOD value will be CREATE for booked entries. Or it must be a valid scheduling METHOD such as PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER or DECLINE-COUNTER. CREATE TABLE VTODO ( ATTENDEE INTEGER, /* VALUE_KEY */ ATTACH INTEGER, /* VALUE_KEY */ CATEGORIES INTEGER, /* VALUE_KEY */ CLASS INTEGER, /* VALUE_KEY */ COMMENT INTEGER, /* VALUE_KEY */ CONTACT INTEGER, /* VALUE_KEY */ CREATED INTEGER NOT NULL, /* VALUE_KEY */ DESCRIPTION INTEGER, /* VALUE_KEY */ DTSTAMP INTEGER NOT NULL, /* VALUE_KEY */ DTSTART INTEGER NOT NULL, /* VALUE_KEY */ DUE INTEGER, /* VALUE_KEY */ DURATION INTEGER, /* VALUE_KEY */ EXDATE INTEGER, /* VALUE_KEY */ EXRULE INTEGER, /* VALUE_KEY */ GEO INTEGER, /* VALUE_KEY */ LAST_MODIFIED INTEGER NOT NULL, /* VALUE_KEY */ LOCATION INTEGER, /* VALUE_KEY */ METHOD INTEGER, /* VALUE_KEY */ ORGANIZER INTEGER, /* VALUE_KEY */ PERCENT_COMPLETE INTEGER, /* VALUE_KEY */ PRIORITY INTEGER, /* VALUE_KEY */ RDATE INTEGER, /* VALUE_KEY */ RECURRENCE_ID INTEGER, /* VALUE_KEY */ RESOURCES INTEGER, /* VALUE_KEY */ RRULE INTEGER, /* VALUE_KEY */ SEQUENCE INTEGER, /* VALUE_KEY */ Mansour/Dawson/Royer/Taler/Hill 78 Expires September 2000 Internet Draft CAP March 10, 2000 SUMMARY INTEGER NOT NULL, /* VALUE_KEY */ UID INTEGER NOT NULL PRIMARY KEY, /* VALUE_KEY */ URL INTEGER, /* VALUE_KEY */ X_PROP INTEGER, /* VALUE_KEY */ VALARM INTEGER /* VALUE_KEY */ ); 9.1.59. X_PROP schema CREATE TABLE X_PROP ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT NOT NULL, NAME TEXT NOT NULL, PARAMS INTEGER /* VALUE_KEY (XPARAM)*/ ); 9.1.60. XPARAM schema CREATE TABLE XPARAM ( VALUE_KEY INTEGER NOT NULL PRIMARY KEY, VALUE TEXT NOT NULL, NAME TEXT NOT NULL ); 9.2. Query example <TBD> 10. Examples For all the examples in this section, the authenticated user is user@example.com. 10.1. Authentication Examples 10.1.1. Login Using Kerberos V4 Use Kerberos V4 to authenticate as bill@example.com to the CAP server on cal.example.com. C: <connect to cal.example.com on port ...> S: 2.0 S: . C: CAPABILTY S: CAPVERSION=1.0 Mansour/Dawson/Royer/Taler/Hill 79 Expires September 2000 Internet Draft CAP March 10, 2000 S: ITIPVERSION=1.0 S: AUTH=KERBEROS_V4 S: AUTH=DIGEST_MD5 S: . C: AUTHENTICATE KERBEROS_V4 S: AmFYig== C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT S: or//EoAADZI= C: DiAF5A4gA+oOIALuBkAAmw== S: 2.0 S: IDENTITY=bill@example.com S: CAPVERSION=1.0 S: ITIPVERSION=1.0 S: AUTH=KERBEROS_V4 S: AUTH=DIGEST_MD5 S: CAR=CAR-FULL-1 S: MINDATE=19700101T000000Z # who knows this date (end of the 32 bit number)? S: MAXDATE=20370201T000000Z S: . 10.1.2. Error Scenarios Use of SASL Authorization Identity is not supported. Use the IDENTITY command instead. If you attempt to use the Authorization Identity, an error status will be returned. C: AUTHENTICATE KERBEROS_V4 S: AmFYig== C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT S: or//EoAADZI= C: DiAF5A4gA+oOIALuBkAAmw== S: 6.1 S: . Sender aborted authentication: C: AUTHENTICATE KERBEROS_V4 S: AmFYig== C: . S: 6.2 S: . Unsupported mechanism: C: AUTHENTICATE Experimental_Auth S: 6.3 S: . Mansour/Dawson/Royer/Taler/Hill 80 Expires September 2000 Internet Draft CAP March 10, 2000 10.2. Read Examples 10.2.1. Read From A Single Calendar In this example bill@example.com reads a day's worth of events from cap://cal.example.com/opaqueid99. C: SENDDATA C: Content-type:text/calendar; Method=READ; Component=VQUERY C: C: BEGIN:VCALENDAR C: VERSION:2.1 C: METHOD:READ C: CMDID:xyz12345 C: TARGET:cap://cal.example.com/opaqueid99 C: BEGIN:VQUERY C: QUERY:SELECT (VEVENT.DTSTART,VEVENT.DTEND,SUMMARY,UID); C: FROM VEVENTTABLE; C: WHERE (VEVENT.DTEND >= 19990714T080000Z AND C: VEVENT.DTSTART <= 19990715T080000Z); C: ORDERBY (VEVENT.DTSTART ASC, VEVENT.DTEND, UID, SUMMARY) C: END:VQUERY C: END:VCALENDAR C: . # this response code means that the transport successfully # delivered the data. S: 2.0 ; got the request OK ; really S: . S: Content-type:text/calendar; Method=RESPONSE; S: Optinfo=VERSION:2.1 S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: METHOD:RESPONSE S: TARGET:cap://cal.example.com/opaqueid99 S: CMDID:xyz12345 S: RESPONSE-STATUS:2.0 S: BEGIN:VEVENT S: DTSTART:19990714T200000Z S: DTEND:19990714T210000Z S: UID:000444888929922 S: SUMMARY:Blah bla S: END:VEVENT S: BEGIN:VEVENT S: UID:0034848098038888989443 S: SUMMARY:meeting S: DTEND:19990714T233000Z S: DTSTART:19990714T223000Z S: END:VEVENT S: END:VCALENDAR S: . Mansour/Dawson/Royer/Taler/Hill 81 Expires September 2000 Internet Draft CAP March 10, 2000 10.2.2. Read From Multiple Calendars 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 C: SENDDATA C: Content-type:text/calendar; Method=READ; Component=VQUERY C: C: BEGIN:VCALENDAR C: VERSION:2.1 C: METHOD:READ C: CMDID:xyz12346 C: TARGET:cap://cal.example.com/opaqueid101 C: TARGET:opaqueid103 C: BEGIN:VQUERY C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID); C: FROM VEVENT; C: WHERE (DTEND >= 19990714T080000Z AND C: DTSTART <= 19990715T080000Z); C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY) C: END:VQUERY C: END:VCALENDAR C: . S: 2.0 S: . S: Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67" S: S: ----FEE3790DC7E35189CA67 S: Content-type:text/calendar; Method=RESPONSE; S: Optinfo=VERSION:2.1 S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: VERSION:2.1 S: METHOD:RESPONSE S: TARGET:cap://cal.example.com/opaqueid103 S: CMDID:xyz12346 S: RESPONSE-CODE:2.0 S: BEGIN:VEVENT S: UID:0034848098038888989443 S: SUMMARY:meeting S: DTEND:19990714T233000Z S: DTSTART:19990714T223000Z S: END:VEVENT S: END:VCALENDAR S: S: ----FEE3790DC7E35189CA67CE2C S: Content-type:text/calendar; Method=RESPONSE; S: Optinfo=VERSION:2.1 S: Content-Transfer-Encoding: 7bit S: S: BEGIN:VCALENDAR S: VERSION:2.1 Mansour/Dawson/Royer/Taler/Hill 82 Expires September 2000 Internet Draft CAP March 10, 2000 S: METHOD:RESPONSE S: TARGET:cap://cal.example.com/opaqueid101 S: CMDID:xyz12346 S: RESPONSE-CODE:4.1 ; access denied S: END:VCALENDAR S: S: ----FEE3790DC7E35189CA67CE2C S: . 10.2.3. Timeouts In this example bill@example.com attempts to read a calendar but the latency time he supplies is not sufficient for the server to complete the command. C: SENDDATA 3 C: Content-type:text/calendar; Method=READ; Component=VQUERY C: C: BEGIN:VCALENDAR C: VERSION:2.1 C: METHOD:READ C: CMDID:xyz12346 C: TARGET:cap://cal.example.com/opaqueid101 C: TARGET:opaqueid103 C: BEGIN:VQUERY C: QUERY:SELECT (DTSTART,DTEND,SUMMARY,UID); C: FROM VEVENT; C: WHERE (DTEND >= 19990714T080000Z AND C: DTSTART <= 19990715T080000Z); C: ORDERBY (DTSTART ASC, DTEND, UID, SUMMARY) C: END:VQUERY C: END:VCALENDAR C: . S: 7.0 ; timeout S: . S: . If Bill wants to continue and give the server more time he would issue a CONTINUE command: C: CONTINUE 10 If Bill wants to abort the command and not wait any further he would issue an ABORT command: C: ABORT S: 2.0 S: . S: . Mansour/Dawson/Royer/Taler/Hill 83 Expires September 2000 Internet Draft CAP March 10, 2000 10.2.4. Using the Calendar Parent, Children Properties 10.2.5. An example that depends on VEVENT.DTSTART and VALARM.DTSTART 11. Implementation Issues 1. What are the minimum component properties set required to create a new VEVENT, VTODO and VJOURNAL?. PROPOSAL: DTSTART, SUMMARY and UID. 2. What is the state of all undefined properties? PROPOSAL: Not defined. So a query will not return them, if they are selected. 12. Properties [Editors Note: These extensions/changes to iCalendar need to be reformatted to conform to the IANA registration process defined in section 7 of [RFC2445].] 12.1. Calendar Store Properties The following are properties of the calendar store. Name Read Value Description Only Type -------------------------------------------------------------------------- CALMASTER N URI The email address for a responsable person. MUST be a mailto URL. CSID Y URI The CSID of this calendar store. If not specified, it is the same as the hostname or virtual host name. DEFAULT_VCARS N TEXT A multivalued property containing the default VCARs for newly created top level calendars. Each entry is a CARID It MUST include at a mini- mum READBUSYTIMEINFO, REQUESTONLY, UPDATEPARTSTATUS, and DEFAULTOWNER. MAXDATE Y DATE-TIME The date/time in the future beyond which the server cannot represent. If not specified, then 99991231T235959 will be assumed. Mansour/Dawson/Royer/Taler/Hill 84 Expires September 2000 Internet Draft CAP March 10, 2000 MINDATE Y DATE-TIME The date/time in the past prior to which the server cannot represent. If not specified, then 00000101T000000 will be assumed. CURRENT_DATETIME Y DATE-TIME Current server time. This is re- turned as a local time and TZID. RECUR_ACCEPTED Y BOOLEAN Boolean value will be set to TRUE if the server will accept recur- rence rules. It will be set to FALSE if the server will not accept recurrence rules. If not specified a CUA MUST assume TRUE. RECUR_EXPAND Y BOOLEAN If set to TRUE, the CS supports the expansion of recurrence rules. If set to FALSE, the CS is incapabale of expanding recurrence rules. If not specified a CUA MUST assume TRUE. RECUR_LIMIT Y INTEGER This numeric value describes how the server handles unbounded recur- rences. 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 inte- ger indicating the number of in- stances that will be created when the server expands an unbounded re- currence rule when fetched from the CS. A CUA MUST query for date ranges when this value is zero. VERSION Y TEXT The version of the CS. The default and the only currently supported version is "2.0" to match the [RFC2445] VERSION. [Editors Note: Can/MUST the server unzip RRULES/EXRULES?] 12.2. Calendar Properties Mansour/Dawson/Royer/Taler/Hill 85 Expires September 2000 Internet Draft CAP March 10, 2000 Name Read Value Description Only Type ------------------------------------------------------------------------- ALLOW-CONFLICTS N BOOLEAN This boolean value indicates whether or not the calendar sup- ports event conflicts. That is, whether or not any of the events in the calendar can overlap. If not specified the default value is TRUE meaning that conflicts are allowed. CALSCALE N TEXT The CALSCALE for thie calendar. If not specified the default is GREGO- RIAN. CHARSET N TEXT The default charset for localized strings in this calendar. If not specified, the default is UTF-8. CHILDREN Y TEXT The list of sub-calendars belonging to this calendar. An empty list means no children. The results may be a comma seperated list of chil- dren. Each entry returned is a CALID. The default is an empty list. CREATED Y DATE-TIME The timestamp of the calendar's create date. DEFAULT_VCAR N TEXT The default VCARs for newly created top level calendars. This is a CARID. The defalut value is the value of DEFAULT_VCAR in the CAL- STORE table. T} LANGUAGE N TEXT The default language for localiz- able strings in this calendar. There is no default. LAST-MODIFIED N DATE-TIME The timestamp when the properties of the calendar were last updated. NAME N TEXT The display name for this calendar. It is a localizable string. If not provided, an empty value will be returned. Mansour/Dawson/Royer/Taler/Hill 86 Expires September 2000 Internet Draft CAP March 10, 2000 OWNERS N URI A multi instanced property indicat- ing the calendar owner. Each entry returned will be a UPN. There must be at least one owner. PARENT N URI The CALID of this calendars parent maintained by a CAP server. An empty value means the calendar is the top level parent. The default value is no parent. RELCALID N URI A unique name for the calendar. There is no default value and this value MUST NOT be empty. TOMBSTONE N BOOLEAN TRUE indicator that this calendar has been marked as deleted. The default value is FALSE. TZID N TEXT The id of the timezone associated with this calendar. See TZID in [RFC2445]. The default value is GMT. 13. Security Considerations For the mandatory SASL mechanism that CAP specifies, the mechanism support is: ? MUST authentication ? MUST authorization ? MAY impersonation The security issue: +---------+ +----------+ CUA1 ------ | CS1 |--------CAP----------| CS2 |-----CUA2 | calF | | calA | +---------+ +----------+ 14. Changes to iCalendar [Editors Note: These extensions/changes to iCalendar need to be reformatted to conform to the IANA registration process defined in section 7 of [RFC2445].] Mansour/Dawson/Royer/Taler/Hill 87 Expires September 2000 Internet Draft CAP March 10, 2000 14.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: TRANSP:TRANSPARENT The following is an example of this property for an event that is opaque or blocks on free/busy time searches: Mansour/Dawson/Royer/Taler/Hill 88 Expires September 2000 Internet Draft CAP March 10, 2000 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.2. RIGHTS Value Type Value Name: RIGHTS Purpose: This value type is used to identify properties whose value is a calendar access rights. Formal Definition: The value type is defined by the following notation: carrights = [princ] (carref / cardef) CRLF princ = "UPN" "=" (text / all / "OWNER" / "NONOWNER" / "ANONYMOUS") carref = ";" "CARREF" "=" text *("," text) cardef = action object *("," action object) action = ";" "ACTION" "=" act-type *("," act-type) act-type = ("CREATE" / "MODIFY" / "DELETE" / "READ" / all) object = ";" "OBJECT" "=" (csprop *("," csprop) [propvalue]) / (calprop *("," calprop) [propvalue]) / (component *("," component)) [compvalue] / (compprop *("," compprop) [propvalue]) / (compparam *("," compparam) [paramvalue]) csprop = csprop2 / all / iana-name csprop2 = <any calendar store property defined in [CAP]> propvalue = propvalue2 / all / self / iana-name propvalue2 = <any value appropriate for the named property> calprop = calprop2 / all / iana-name calprop2 = <any calendar property name defined in [RFC2445] or [CAP]> component = component2 / all / iana-name component2 = <any calendar component defined in [RFC2445] or [CAP]> Mansour/Dawson/Royer/Taler/Hill 89 Expires September 2000 Internet Draft CAP March 10, 2000 compprop = compprop2 / all / iana-name compprop2 = <any component property name defined in [RFC2445] or [CAP]> compparam = compparm2 / all / iana-name compparm2 = <any component parameter name defined in [RFC2445] or [CAP]> compvalue = ";" "VALUE" "=" ((component2 *("," component2)) / all / iana-name) paramvalue = paramvalue2 / all / iana-name paramvalue2 = <any value appropriate for the named parameter> all = "*" self = "SELF" ; Only valid for ATTENDEE value. ; When OBJECT=ATTENDEE;VALUE=SELF. iana-name = <A name registered with IANA> Description: The value type is a structured value consisting of a list of one or more access control rights rule parts. Each rule part is defined by a "NAME=VALUE" pair. The rule parts are separated from each other by the SEMICOLON character (US-ASCII decimal 59). The rule parts are not ordered in any particular sequence, unless otherwise specified by the ABNF. Within one carrights all matches of multiple OBJECT and VALUE pairs must be true for the GRANT or DENY to apply. The UPN rule part specifies the CU or UG to which the VCARs applies. The value of this rule part is either a quoted text specifying a UPN or an unquoted text specifying a keyword enumerating a standard authenticated user type. If the value is the keyword is *, then the rule applies to all authenticated calendar users (i.e., all UPNs). If the value is the keyword OWNER, then the rule applies to any of the owners of the calendar store or calendar. If the value is the keyword NONOWNER, then the rule applies to a UPN that is not the owner of the calendar store or calendar. If this rule part is not specified in the value, then the calendar access rights do not apply to any UPN. In this case, the calendar access rights can be defined for reference by another instance of a calendar access rights. For example, a complex set of calendar access rights can be defined once and referenced many times in the rights specified for individual calendar users. The CARREF rule part specifies a reference to a particular "VCAR" calendar component. The text is matched to a CARID property value within a "VCAR" calendar component. This allows for a particular set of calendar access rights to be defined once and referenced multiple times. Mansour/Dawson/Royer/Taler/Hill 90 Expires September 2000 Internet Draft CAP March 10, 2000 The "VCAR" identifier specified by this rule part is unique to the calendar store. Predefined calendar access CARIDs that MUST be implememnetd (CAR-MIN) are: CARID:READBUSYTIMEINFO - Specifies rights for reading VFREEBUSY components by anonymous and known users. Suggested VCAR to allow all users to read VFREEBUSY components: BEGIN:VCAR CARID:READBUSYTIMEINFO GRANT:UPN=*;ACTION=READ;OBJECTS=VFREEBUSY;VALUE=* END:VCAR CARID:REQUESTONLY - Specifies rights for creating new event invitations, to-do assignments and journal entries by users other than the owner of the calendar. Suggested VCAR to allow access by nonowners to submit REQUESTs: BEGIN:VCAR CARID:REQUESTONLY GRANT:UPN=NONOWNER;ACTION=CREATE;OBJECT=* ;OBJECT=METHOD;VALUE=REQUEST END:VCAR CARID:UPDATEPARTSTATUS - Specifies rights for a user to modify their participation status in a calendar they do not own. Suggested VCAR to allow users to update their own participation status: BEGIN:VCAR CARID:UPDATEPARTSTATUS GRANT:UPN=*;ACTION=MODIFY ;OBECT=PARTSTAT:VALUE=* ;OBJECT=ATTENDEE;VALUE=SELF END:VCAR CARID:DEFAULTOWNER - Specifies the default access for any owner of a calendar. Suggested VCAR to all owners access to their own calendars: BEGIN:VCAR CARID:DEFAULTOWNER GRANT:UPN=OWNER;ACTION=*;OBJECT=*;VALUE=*; END:VCAR The ACTION rule part defines one or more CAP actions that are allowed for the UPN. The valid values are CREATE, 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 Mansour/Dawson/Royer/Taler/Hill 91 Expires September 2000 Internet Draft CAP March 10, 2000 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 property, calendar component, component property, or parameter that the ACTION is restricted to. Multiple OBJECT enumerations can be specified as a COMMA character (US-ASCII decimal 44) separated list of OBJECT enumerated values. The value ALL specifies any and all valid objects. The VALUE rule part specifies the restricted values for the OBJECT rule part. Multiple VALUE strings can be specified as a COMMA character (US- ASCII decimal 44) separated list of VALUE strings. The text 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" calendar user to read busy time values: UPN="foo@host.com";ACTION=READ;OBJECT=DTSTART,DTEND 14.3. VCAR Calendar Component Component Name: "VCAR" Purpose: Provide a grouping of calendar access rights. Format Definition: A "VCAR" calendar component is defined by the following notation: aclc = "BEGIN" ":" "VCAR" CRLF carprop "END" ":" "VCAR" CRLF carprop = carid 1*(grant / deny) Description: A "VCAR" calendar component is a grouping of calendar access rights component properties. The "CARID" property specifies the local identifier for the "VCAR" calendar component. The "GRANT" property specifies calendar access rights granted to an UPN. The "DENY" property specifies calendar access rights denied from an UPN. Example: In the following example, the UPN "foo@host.com" has read access to the "DTSTART" and "DTEND" calendar properties. No other access is specified: BEGIN:VCAR CARID:"View Start and End Times" GRANT:UPN=foo@host.com;ACTION="READ";OBJECT=DTSTART,DTEND END:VEVENT Mansour/Dawson/Royer/Taler/Hill 92 Expires September 2000 Internet Draft CAP March 10, 2000 In this example, all UPNs are given read access to "DTSTART" and "DTEND". "All CUs and UGs" are specified by the UPN value "*". Note that this enumerated UPN value is not in quotes.: BEGIN:VCAR CARID:"View Start and End Times 2" GRANT:UPN=*;ACTION=READ;OBJECT=DTSTART,DTEND END:VCAR In this example, rights are specified for all UPNs to read components classified as PUBLIC: BEGIN:VCAR CARID:"View PUBLIC Start and End Times" GRANT:UPN=*;ACTION=READ;OBJECT=DTSTART;DTEND DENY:UPN=*;ACTION=READ;OBJECT=CLASS;VALUE=PUBLIC, CONFIDENTIAL END:VCAR In this example, rights are specified for all UPNs to read or modify existing components classified as PUBLIC: BEGIN:VCAR CARID:"Read and Modify PUBLIC Calendar Entries" GRANT:UPN=*;ACTION=READ,MODIFY;OBJECT=* DENY:UPN=*;ACTION=READ,MODIFY;OBJECT=CLASS;VALUE=PRIVATE, CONFIDENTIAL END:VCAR In this example, full calendar access rights are given to the OWNER and a hypothetical administrator is given access rights to specify calendar access rights. If no other rights are specified, only these two UPNs can specify calendar access rights: BEGIN:VCAR CARID:"Only OWNER or ADMIN Settable CARs" GRANT:UPN=OWNER;ACTION=*;OBJECT=* GRANT:UPN=cal-admin@host.com;ACTION=*; OBJECT=VCAR,CARID,GRANT,DENY END:VCAR In this example, rights to create, read, modify or delete calendar access rights are denied to all UPNs. This example would disable providing different access rights to the calendar store or calendar. This calendar access rights should not be specified, as they the ability to change calendar access; even for the owner or administrator: BEGIN:VCAR CARID:"No CAR At All" DENY:UPN=*;OBJECT=VCAR,CARID,GRANT,DENY ENG:VCAR Mansour/Dawson/Royer/Taler/Hill 93 Expires September 2000 Internet Draft CAP March 10, 2000 14.4. GRANT Component Property Property Name: GRANT Purpose: This property specifies those access rights granted to a UPN. Value Type: RIGHTS Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can only be specified in "VCAR" calendar component. Description: This property is used to grant calendar access rights to a UPN. Format Definition: The property is defined by the following notation: grant = "GRANT" rightsparam ":" carrights CRLF rightsparam = *(";" xparam) 14.5. DENY Component Property Property Name: DENY Purpose: This property specifies those access rights denied from a UPN. Value Type: RIGHTS Property Parameters: Only non-standard property parameters can be specified on this property. Conformance: This property can only be specified in "VCAR" calendar component. Description: This property is used to deny calendar access rights to a UPN. Format Definition: The property is defined by the following notation: DENY = "DENY" rightsparam ":" carrights CRLF rightsparam = *(";" xparam) Example: In the following example, any UPN who is not the owner is denied rights to create, modify or delete entries: DENY:UPN=NONOWNER;ACTION=CREATE,MODIFY,DELETE;OBJECT=* Mansour/Dawson/Royer/Taler/Hill 94 Expires September 2000 Internet Draft CAP March 10, 2000 14.6. VCAR Identifier Component Property Property Name: CARID Purpose: This property specifies the identifier for a "VCAR" calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VCAR" calendar component. Description: This property permits previously defined sets of calendar access rights to be specified with a reference. This capability facilitates repetitively specifying calendar access rights. Format Definition: The property is defined by the following notation: CARID = "CARID" textparam ":" text CRLF Example: The following is an example of this property: CARID:"Restrict Guests From Creating ALARMs On Events" 14.8 REQUEST-STATUS property This description is a revision of the REQUEST-STATUS property for VCALENDAR version 2.1. rstatus = "REQUEST-STATUS" rstatparam ":" statcode [";" statdesc [";" extdata]] rstatparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparm) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) statcode = 1*DIGIT *("." 1*DIGIT) ;Hierarchical, numeric return status code statdesc = text Mansour/Dawson/Royer/Taler/Hill 95 Expires September 2000 Internet Draft CAP March 10, 2000 ;An optional textual status description, content is ;decided by the implementor. May be empty. extdata = text ;Textual exception data. For example, the offending property ;name and value or complete property line. Example: The following are some possible examples of this property. The COMMA and SEMICOLON separator characters in the property value are BACKSLASH character escaped because they appear in a text value. REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success despite braindead LDAP implementation REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 REQUEST-STATUS:2.8; Success, repeating event ignored. Scheduled as a single event.;RRULE:FREQ=WEEKLY;INTERVAL=2 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: MAILTO:jsmith@host.com REQUEST-STATUS:3.7;;ATTENDEE:MAILTO:jsmith@host.com REQUEST-STATUS:10.4;Help! That really shouldnt have happened. 15. CAP Entities Registration This section provides the process for registration of new or modified CAP entities. 15.1 Registration of New and Modified CAP Entities New CAP entities are registered by the publication of an IETF Request for Comment (RFC). Changes to a CAP entity are registered by the publication of a revision of the RFC defining the method. 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, 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. The procedures defined here are designed to allow public comment and Mansour/Dawson/Royer/Taler/Hill 96 Expires September 2000 Internet Draft CAP March 10, 2000 review of new CAP entities, while posing only a small impediment to the definition of new properties. Registration of a new CAP entity is accomplished by the following steps. 15.1.1. Define the Entity A CAP entity is defined by completing the following template. To: ietf-calendar@imc.org Subject: Registration of CAP entity XXX Entity name: Entity purpose: Description: CAP terminology changes: CAP data model changes: CAP system model changes: Conformance considerations: Format definition: Examples: The meaning of each field in the template is as follows. Entity name: The name of the entity. Entity purpose: The purpose of the entity (e.g., Extends the CAP command set to poll for notifications, etc.). Give a short but clear description. Description: Any special notes about the entity, how it is to be used, etc. CAP terminology changes: Any change or additions to the existing CAP terminology needs to be specified. CAP data model changes: Any of the valid property parameters for the property needs to be specified. CAP system model changes: Conformance: A clear summary of how and where this CAP entity extension MUST, MAY, SHOULD or can be used. Any changes or impact to the existing conformance definition for CAP should be explained. The impact to implementations conforming to the existing CAP specification should be clearly described. Format definition: The ABNF for each element of the CAP entity needs to be specified. Examples: One or more examples of instances of the CAP entity and each of its usage scenarios needs to be specified. Mansour/Dawson/Royer/Taler/Hill 97 Expires September 2000 Internet Draft CAP March 10, 2000 15.1.2. Post the entity definition The entity description MUST be posted to the new entity discussion list, ietf-calendar@imc.org. 15.1.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 before proceeding to the next step. 15.1.4. Submit the entity for approval Once the two-week comment period has elapsed, and the proposer is convinced consensus has been reached on the entity, the registration application should be submitted to the Method Reviewer for approval. The Method Reviewer is appointed by the Application Area Directors and can either accept or reject the entity registration. An accepted registration should be passed on by the Method Reviewer to the IANA for inclusion in the official IANA method registry. The registration can be rejected for any of the following reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) Technical deficiencies raised on the list or elsewhere have not been addressed. The Method Reviewers decision to reject 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] 15.2. Property Change Control Existing CAP entities can be changed using the same process by which they were registered. 1. Define the change 2. Post the change 3. Allow a comment period 4. Submit the entity for approval Note that the original author or any other interested party can propose a change to an existing CAP entity, but that such changes should only be proposed when there are serious omissions or errors in the published memo. The Method Reviewer can object to a change if it is not backward compatible, but is not required to do so. CAP 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. Mansour/Dawson/Royer/Taler/Hill 98 Expires September 2000 Internet Draft CAP March 10, 2000 16. IANA Considerations This memo defines IANA registered extensions to the attributes defined by iCalendar, as defined in [RFC2445], and iTIP, as defined in [RFC2426]. IANA registration proposals for iCalendar and iTIP are to be mailed to the registration agent for the "text/calendar" MIME content-type, <MAILTO: ietf-calendar@imc.org> using the format defined in section 7 of [RFC2445]. 17. Acknowledgments The following have individuals were major contributors in the drafting and discussion of this memo: Harald Alvestrand, Mario Bonin, Andre Courtemanche, Dave Crocker, Pat Egen, Gilles Fortin, Jeff Hodges, Alex Hoppman, Bruce Kahn, Lisa Lippert, David Madeo, Bob Mahoney, Bob Morgan, Pete O'Leary, Richard Shusterman, Tony Small, John Stracke, Mark Wahl. 18. Bibliography [RFC1521] N. Borenstein and N. Freed, "MIME (Multipurpose Internet 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 [RFC2608] Guttman, Perkins, Veizades, Day, "Service Location protocol, Version 2", RFC2608, June 1999. [RFC2609] Guttman, Perkins, Kempf, "Service Templates and Service: 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 Core Object Specification (iCalendar)", RFC 2445, November 1998 [RFC2446] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport- Independent Interoperability Protocol (iTIP)", RFC 2446, November 1998 [RFC2447] Dawson, Mansour, Silverberg, "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 2445, November 1998 [SQL] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka ANSI X3.135-1992, aka FiPS PUB 127-2 Mansour/Dawson/Royer/Taler/Hill 99 Expires September 2000 Internet Draft CAP March 10, 2000 [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 to ISO/IEC 9075: 1992, also adopted as Amendment 1 to ANSI X3.135.1992 [UNICODE] The Unicode Consortium, "The Unicode Standard --Worldwide Character Encoding -- Version 1.0", Addison-Wesley, Volume 1, 1991, Volume 2, 1992. UTF-8 is described in Unicode Technical Report #4. [US-ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. 19. Author's Address The following address information is provided in a vCard v3.0, the RFC 2426 electronic business card format. BEGIN:VCARD VERSION:3.0 N:Dawson;Frank FN:Frank Dawson ORG:Lotus Development Corporation ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;Raleigh;NC; 27613-3502;US TEL;TYPE=PREF,WORK,MSG:+1-617-693-8728 TEL;TYPE=WORK,MSG:+1-919-676-9515 TEL;TYPE=WORK,FAX:+1-919-676-9515 EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com EMAIL;TYPE=INTERNET:fdawson@earthlink.net URL;TYPE=X-HOME:http://home.earthlink.net/~fdawson END:VCARD BEGIN:VCARD VERSION:3.0 N:Mansour;Steve FN:Steve Mansour ORG:Netscape ADR;TYPE=WORK,POSTAL,PARCEL:;;501 E Middlfield Road;Mountain View;CA;94043;US TEL;WORK;MSG:+1-650-937-2378 TEL;WORK;FAX:+1-650-937-2103 EMAIL;INTERNET:sman@netscape.com END:VCARD BEGIN:VCARD VERSION: 3.0 FN:Doug Royer N:Royer,Doug ORG:Software.com ADR;TYPE=WORK,POSTAL,PARCEL:Suite 106;;530 E. Montecito St; Santa Barbara;CA;93103;US TEL;TYPE=PREF,WORK,MSG:805-957-1790 x541 TEL;TYPE=WORK,MSG:650-364-6538 TEL;TYPE=WORK,FAX:805-957-1544 EMAIL;TYPE=INTERNET,PREF:Doug.Royer@Software.com Mansour/Dawson/Royer/Taler/Hill 100 Expires September 2000 Internet Draft CAP March 10, 2000 EMAIL;TYPE=INTERNET:Doug@Royer.com URL;TYPE=X-HOME:http://Royer.com/People/Doug END:VCARD BEGIN:VCARD VERSION:3.0 FN:Alexander Taler N:Taler;Alexander ORG:CS&T ADR;TYPE=WORK,POSTAL,PARCEL:;;3333 Graham Boulevard;Montreal;QC; H3R 3L5;Canada TEL;TYPE=WORK,VOICE:514-733-8500 TEL;TYPE=FAX:514-733-8878 EMAIL;TYPE=INTERNET:alext@cst.ca END:VCARD 20. Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Mansour/Dawson/Royer/Taler/Hill 101 Expires September 2000
Datatracker
Report a datatracker bug
draft-ietf-calsch-cap-02
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |