| < draft-royer-calsch-cap-02.txt | draft-royer-calsch-cap-03.txt > | |||
|---|---|---|---|---|
| Calendaring and Scheduling D. Royer | Calendaring and Scheduling D. Royer | |||
| Internet-Draft IntelliCal, LLC | Internet-Draft IntelliCal, LLC | |||
| Expires: August 10, 2005 G. Babics | Expires: February 9, 2006 G. Babics | |||
| Oracle | Oracle | |||
| P. Hill | P. Hill | |||
| Massachusetts Institute of | Massachusetts Institute of | |||
| Technology | Technology | |||
| S. Mansour | S. Mansour | |||
| AOL/Netscape | AOL/Netscape | |||
| Feb 9, 2005 | August 8, 2005 | |||
| Calendar Access Protocol (CAP) | Calendar Access Protocol (CAP) | |||
| draft-royer-calsch-cap-02 | draft-royer-calsch-cap-03 | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is subject to all provisions | By submitting this Internet-Draft, each author represents that any | |||
| of section 3 of RFC 3667. By submitting this Internet-Draft, each | applicable patent or other IPR claims of which he or she is aware | |||
| author represents that any applicable patent or other IPR claims of | have been or will be disclosed, and any of which he or she becomes | |||
| which he or she is aware have been or will be disclosed, and any of | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| which he or she become aware will be disclosed, in accordance with | ||||
| RFC 3668. | ||||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as | other groups may also distribute working documents as Internet- | |||
| Internet-Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on August 10, 2005. | This Internet-Draft will expire on February 9, 2006. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
| Abstract | Abstract | |||
| The Calendar Access Protocol (CAP) is an Internet protocol described | The Calendar Access Protocol (CAP) is an Internet protocol described | |||
| in this memo that permits a Calendar User (CU) to utilize a Calendar | in this memo that permits a Calendar User (CU) to utilize a Calendar | |||
| User Agent (CUA) to access an [iCAL] based Calendar Store (CS). | User Agent (CUA) to access an [iCAL] based Calendar Store (CS). | |||
| skipping to change at page 2, line 20 ¶ | skipping to change at page 2, line 19 ¶ | |||
| needed to be released so that many years of work could be preserved. | needed to be released so that many years of work could be preserved. | |||
| Many properties in CAP can be used by other iCalendar protocols and | Many properties in CAP can be used by other iCalendar protocols and | |||
| have had many years of debate. | have had many years of debate. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 1.1 Formatting Conventions . . . . . . . . . . . . . . . . . 5 | 1.1 Formatting Conventions . . . . . . . . . . . . . . . . . 5 | |||
| 1.2 Related Documents . . . . . . . . . . . . . . . . . . . 6 | 1.2 Related Documents . . . . . . . . . . . . . . . . . . . 6 | |||
| 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . 7 | 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 2. Additions to iCalendar . . . . . . . . . . . . . . . . . . . 11 | 2. Additions to iCalendar . . . . . . . . . . . . . . . . . . . 12 | |||
| 2.1 New Value Types (summary) . . . . . . . . . . . . . . . 14 | 2.1 New Value Types (summary) . . . . . . . . . . . . . . . 15 | |||
| 2.1.1 New Parameters (summary) . . . . . . . . . . . . . . 14 | 2.1.1 New Parameters (summary) . . . . . . . . . . . . . . 15 | |||
| 2.1.2 New or Updated Properties (summary) . . . . . . . . 14 | 2.1.2 New or Updated Properties (summary) . . . . . . . . 16 | |||
| 2.1.3 New Components (summary) . . . . . . . . . . . . . . 16 | 2.1.3 New Components (summary) . . . . . . . . . . . . . . 18 | |||
| 2.2 Relationship of RFC-2446 (ITIP) and CAP . . . . . . . . 17 | 2.2 Relationship of RFC-2446 (ITIP) and CAP . . . . . . . . 19 | |||
| 3. CAP Design . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 3. CAP Design . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 3.1 System Model . . . . . . . . . . . . . . . . . . . . . . 19 | 3.1 System Model . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 3.2 Calendar Store Object Model . . . . . . . . . . . . . . 19 | 3.2 Calendar Store Object Model . . . . . . . . . . . . . . 22 | |||
| 3.3 Protocol Model . . . . . . . . . . . . . . . . . . . . . 20 | 3.3 Protocol Model . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 3.3.1 Use of BEEP, MIME and iCalendar . . . . . . . . . . 21 | 3.3.1 Use of BEEP, MIME and iCalendar . . . . . . . . . . 24 | |||
| 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . 23 | 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
| 4.1 Calendar User and UPNs . . . . . . . . . . . . . . . . . 23 | 4.1 Calendar User and UPNs . . . . . . . . . . . . . . . . . 26 | |||
| 4.1.1 UPNs and Certificates . . . . . . . . . . . . . . . 23 | 4.1.1 UPNs and Certificates . . . . . . . . . . . . . . . 26 | |||
| 4.1.2 Anonymous Users and Authentication . . . . . . . . . 24 | 4.1.2 Anonymous Users and Authentication . . . . . . . . . 27 | |||
| 4.1.3 User Groups . . . . . . . . . . . . . . . . . . . . 24 | 4.1.3 User Groups . . . . . . . . . . . . . . . . . . . . 27 | |||
| 4.2 Access Rights . . . . . . . . . . . . . . . . . . . . . 25 | 4.2 Access Rights . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 4.2.1 Access Control and NOCONFLICT . . . . . . . . . . . 25 | 4.2.1 Access Control and NOCONFLICT . . . . . . . . . . . 28 | |||
| 4.2.2 Predefined VCARs . . . . . . . . . . . . . . . . . . 25 | 4.2.2 Predefined VCARs . . . . . . . . . . . . . . . . . . 28 | |||
| 4.2.3 Decreed VCARs . . . . . . . . . . . . . . . . . . . 27 | 4.2.3 Decreed VCARs . . . . . . . . . . . . . . . . . . . 30 | |||
| 4.3 CAP Session Identity . . . . . . . . . . . . . . . . . . 28 | 4.3 CAP Session Identity . . . . . . . . . . . . . . . . . . 31 | |||
| 5. CAP URL and Calendar Address . . . . . . . . . . . . . . . . 30 | 5. CAP URL and Calendar Address . . . . . . . . . . . . . . . . 33 | |||
| 6. New Value Types . . . . . . . . . . . . . . . . . . . . . . 32 | 6. New Value Types . . . . . . . . . . . . . . . . . . . . . . 35 | |||
| 6.1 Property Value Data Types . . . . . . . . . . . . . . . 32 | 6.1 Property Value Data Types . . . . . . . . . . . . . . . 35 | |||
| 6.1.1 CAL-QUERY Value Type . . . . . . . . . . . . . . . . 32 | 6.1.1 CAL-QUERY Value Type . . . . . . . . . . . . . . . . 35 | |||
| 6.1.2 UPN Value Type . . . . . . . . . . . . . . . . . . . 47 | 6.1.2 UPN Value Type . . . . . . . . . . . . . . . . . . . 51 | |||
| 6.1.3 UPN-FILTER Value . . . . . . . . . . . . . . . . . . 48 | 6.1.3 UPN-FILTER Value . . . . . . . . . . . . . . . . . . 52 | |||
| 7. New Parameters . . . . . . . . . . . . . . . . . . . . . . . 51 | 7. New Parameters . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
| 7.1 ACTION Parameter . . . . . . . . . . . . . . . . . . . . 51 | 7.1 ACTION Parameter . . . . . . . . . . . . . . . . . . . . 55 | |||
| 7.2 ENABLE Parameter . . . . . . . . . . . . . . . . . . . . 51 | 7.2 ENABLE Parameter . . . . . . . . . . . . . . . . . . . . 55 | |||
| 7.3 ID Parameter . . . . . . . . . . . . . . . . . . . . . . 52 | 7.3 ID Parameter . . . . . . . . . . . . . . . . . . . . . . 56 | |||
| 7.4 LATENCY Parameter . . . . . . . . . . . . . . . . . . . 53 | 7.4 LATENCY Parameter . . . . . . . . . . . . . . . . . . . 57 | |||
| 7.5 LOCAL Parameter . . . . . . . . . . . . . . . . . . . . 54 | 7.5 LOCAL Parameter . . . . . . . . . . . . . . . . . . . . 58 | |||
| 7.6 LOCALIZE Parameter . . . . . . . . . . . . . . . . . . . 54 | 7.6 LOCALIZE Parameter . . . . . . . . . . . . . . . . . . . 58 | |||
| 7.7 OPTIONS Parameter . . . . . . . . . . . . . . . . . . . 55 | 7.7 OPTIONS Parameter . . . . . . . . . . . . . . . . . . . 59 | |||
| 8. New Properties . . . . . . . . . . . . . . . . . . . . . . . 57 | 8. New Properties . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
| 8.1 ALLOW-CONFLICT Property . . . . . . . . . . . . . . . . 57 | 8.1 ALLOW-CONFLICT Property . . . . . . . . . . . . . . . . 61 | |||
| 8.2 ATT-COUNTER Property . . . . . . . . . . . . . . . . . . 57 | 8.2 ATT-COUNTER Property . . . . . . . . . . . . . . . . . . 61 | |||
| 8.3 CALID Property . . . . . . . . . . . . . . . . . . . . . 58 | 8.3 CALID Property . . . . . . . . . . . . . . . . . . . . . 62 | |||
| 8.4 CALMASTER Property . . . . . . . . . . . . . . . . . . . 59 | 8.4 CALMASTER Property . . . . . . . . . . . . . . . . . . . 63 | |||
| 8.5 CAP-VERSION Property . . . . . . . . . . . . . . . . . . 59 | 8.5 CAP-VERSION Property . . . . . . . . . . . . . . . . . . 63 | |||
| 8.6 CARID Property . . . . . . . . . . . . . . . . . . . . . 60 | 8.6 CARID Property . . . . . . . . . . . . . . . . . . . . . 64 | |||
| 8.7 CAR-LEVEL Property . . . . . . . . . . . . . . . . . . . 61 | 8.7 CAR-LEVEL Property . . . . . . . . . . . . . . . . . . . 65 | |||
| 8.8 COMPONENTS Property . . . . . . . . . . . . . . . . . . 61 | 8.8 COMPONENTS Property . . . . . . . . . . . . . . . . . . 65 | |||
| 8.9 CSID Property . . . . . . . . . . . . . . . . . . . . . 63 | 8.9 CSID Property . . . . . . . . . . . . . . . . . . . . . 67 | |||
| 8.10 DECREED Property . . . . . . . . . . . . . . . . . . . . 63 | 8.10 DECREED Property . . . . . . . . . . . . . . . . . . . . 67 | |||
| 8.11 DEFAULT-CHARSET Property . . . . . . . . . . . . . . . . 64 | 8.11 DEFAULT-CHARSET Property . . . . . . . . . . . . . . . . 68 | |||
| 8.12 DEFAULT-LOCALE Property . . . . . . . . . . . . . . . . 65 | 8.12 DEFAULT-LOCALE Property . . . . . . . . . . . . . . . . 69 | |||
| 8.13 DEFAULT-TZID Property . . . . . . . . . . . . . . . . . 66 | 8.13 DEFAULT-TZID Property . . . . . . . . . . . . . . . . . 70 | |||
| 8.14 DEFAULT-VCARS Property . . . . . . . . . . . . . . . . . 67 | 8.14 DEFAULT-VCARS Property . . . . . . . . . . . . . . . . . 71 | |||
| 8.15 DENY Property . . . . . . . . . . . . . . . . . . . . . 68 | 8.15 DENY Property . . . . . . . . . . . . . . . . . . . . . 72 | |||
| 8.16 EXPAND property . . . . . . . . . . . . . . . . . . . . 68 | 8.16 EXPAND property . . . . . . . . . . . . . . . . . . . . 72 | |||
| 8.17 GRANT Property . . . . . . . . . . . . . . . . . . . . . 69 | 8.17 GRANT Property . . . . . . . . . . . . . . . . . . . . . 73 | |||
| 8.18 ITIP-VERSION Property . . . . . . . . . . . . . . . . . 70 | 8.18 ITIP-VERSION Property . . . . . . . . . . . . . . . . . 74 | |||
| 8.19 MAX-COMP-SIZE Property . . . . . . . . . . . . . . . . . 70 | 8.19 MAX-COMP-SIZE Property . . . . . . . . . . . . . . . . . 74 | |||
| 8.20 MAXDATE Property . . . . . . . . . . . . . . . . . . . . 71 | 8.20 MAXDATE Property . . . . . . . . . . . . . . . . . . . . 75 | |||
| 8.21 MINDATE Property . . . . . . . . . . . . . . . . . . . . 72 | 8.21 MINDATE Property . . . . . . . . . . . . . . . . . . . . 76 | |||
| 8.22 MULTIPART Property . . . . . . . . . . . . . . . . . . . 72 | 8.22 MULTIPART Property . . . . . . . . . . . . . . . . . . . 76 | |||
| 8.23 NAME Property . . . . . . . . . . . . . . . . . . . . . 73 | 8.23 NAME Property . . . . . . . . . . . . . . . . . . . . . 77 | |||
| 8.24 OWNER Property . . . . . . . . . . . . . . . . . . . . . 74 | 8.24 OWNER Property . . . . . . . . . . . . . . . . . . . . . 78 | |||
| 8.25 PERMISSION Property . . . . . . . . . . . . . . . . . . 75 | 8.25 PERMISSION Property . . . . . . . . . . . . . . . . . . 79 | |||
| 8.26 QUERY property . . . . . . . . . . . . . . . . . . . . . 75 | 8.26 QUERY property . . . . . . . . . . . . . . . . . . . . . 79 | |||
| 8.27 QUERYID property . . . . . . . . . . . . . . . . . . . . 76 | 8.27 QUERYID property . . . . . . . . . . . . . . . . . . . . 80 | |||
| 8.28 QUERY-LEVEL Property . . . . . . . . . . . . . . . . . . 77 | 8.28 QUERY-LEVEL Property . . . . . . . . . . . . . . . . . . 81 | |||
| 8.29 RECUR-ACCEPTED Property . . . . . . . . . . . . . . . . 77 | 8.29 RECUR-ACCEPTED Property . . . . . . . . . . . . . . . . 81 | |||
| 8.30 RECUR-LIMIT Property . . . . . . . . . . . . . . . . . . 78 | 8.30 RECUR-LIMIT Property . . . . . . . . . . . . . . . . . . 82 | |||
| 8.31 RECUR-EXPAND Property . . . . . . . . . . . . . . . . . 79 | 8.31 RECUR-EXPAND Property . . . . . . . . . . . . . . . . . 83 | |||
| 8.32 RESTRICTION Property . . . . . . . . . . . . . . . . . . 79 | 8.32 RESTRICTION Property . . . . . . . . . . . . . . . . . . 83 | |||
| 8.33 SCOPE Property . . . . . . . . . . . . . . . . . . . . . 80 | 8.33 SCOPE Property . . . . . . . . . . . . . . . . . . . . . 84 | |||
| 8.34 STORES-EXPANDED Property . . . . . . . . . . . . . . . . 81 | 8.34 STORES-EXPANDED Property . . . . . . . . . . . . . . . . 85 | |||
| 8.35 TARGET Property . . . . . . . . . . . . . . . . . . . . 82 | 8.35 TARGET Property . . . . . . . . . . . . . . . . . . . . 86 | |||
| 8.36 TRANSP Property . . . . . . . . . . . . . . . . . . . . 82 | 8.36 TRANSP Property . . . . . . . . . . . . . . . . . . . . 86 | |||
| 9. New Components . . . . . . . . . . . . . . . . . . . . . . . 84 | 9. New Components . . . . . . . . . . . . . . . . . . . . . . . 88 | |||
| 9.1 VAGENDA Component . . . . . . . . . . . . . . . . . . . 84 | 9.1 VAGENDA Component . . . . . . . . . . . . . . . . . . . 88 | |||
| 9.2 VCALSTORE Component . . . . . . . . . . . . . . . . . . 86 | 9.2 VCALSTORE Component . . . . . . . . . . . . . . . . . . 90 | |||
| 9.3 VCAR Component . . . . . . . . . . . . . . . . . . . . . 88 | 9.3 VCAR Component . . . . . . . . . . . . . . . . . . . . . 92 | |||
| 9.4 VRIGHT Component . . . . . . . . . . . . . . . . . . . . 90 | 9.4 VRIGHT Component . . . . . . . . . . . . . . . . . . . . 95 | |||
| 9.5 VREPLY Component . . . . . . . . . . . . . . . . . . . . 91 | 9.5 VREPLY Component . . . . . . . . . . . . . . . . . . . . 96 | |||
| 9.6 VQUERY Component . . . . . . . . . . . . . . . . . . . . 92 | 9.6 VQUERY Component . . . . . . . . . . . . . . . . . . . . 96 | |||
| 10. Commands and Responses . . . . . . . . . . . . . . . . . . 94 | 10. Commands and Responses . . . . . . . . . . . . . . . . . . 98 | |||
| 10.1 CAP Commands (CMD) . . . . . . . . . . . . . . . . . . . 94 | 10.1 CAP Commands (CMD) . . . . . . . . . . . . . . . . . . . 98 | |||
| 10.1.1 Bounded Latency . . . . . . . . . . . . . . . . . . 95 | 10.1.1 Bounded Latency . . . . . . . . . . . . . . . . . . 99 | |||
| 10.2 ABORT Command . . . . . . . . . . . . . . . . . . . . . 97 | 10.2 ABORT Command . . . . . . . . . . . . . . . . . . . . . 101 | |||
| 10.3 CONTINUE Command . . . . . . . . . . . . . . . . . . . . 98 | 10.3 CONTINUE Command . . . . . . . . . . . . . . . . . . . . 102 | |||
| 10.4 CREATE Command . . . . . . . . . . . . . . . . . . . . . 99 | 10.4 CREATE Command . . . . . . . . . . . . . . . . . . . . . 103 | |||
| 10.5 DELETE Command . . . . . . . . . . . . . . . . . . . . . 105 | 10.5 DELETE Command . . . . . . . . . . . . . . . . . . . . . 109 | |||
| 10.6 GENERATE-UID Command . . . . . . . . . . . . . . . . . . 108 | 10.6 GENERATE-UID Command . . . . . . . . . . . . . . . . . . 112 | |||
| 10.7 GET-CAPABILITY Command . . . . . . . . . . . . . . . . . 110 | 10.7 GET-CAPABILITY Command . . . . . . . . . . . . . . . . . 114 | |||
| 10.8 IDENTIFY Command . . . . . . . . . . . . . . . . . . . . 113 | 10.8 IDENTIFY Command . . . . . . . . . . . . . . . . . . . . 117 | |||
| 10.9 MODIFY Command . . . . . . . . . . . . . . . . . . . . . 116 | 10.9 MODIFY Command . . . . . . . . . . . . . . . . . . . . . 120 | |||
| 10.10 MOVE Command . . . . . . . . . . . . . . . . . . . . . 120 | 10.10 MOVE Command . . . . . . . . . . . . . . . . . . . . . 124 | |||
| 10.11 REPLY Response to a Command . . . . . . . . . . . . . 123 | 10.11 REPLY Response to a Command . . . . . . . . . . . . . 127 | |||
| 10.12 SEARCH Command . . . . . . . . . . . . . . . . . . . . 124 | 10.12 SEARCH Command . . . . . . . . . . . . . . . . . . . . 128 | |||
| 10.12.1 Searching for VFREEBUSY . . . . . . . . . . . . . 127 | 10.12.1 Searching for VFREEBUSY . . . . . . . . . . . . . 131 | |||
| 10.13 SET-LOCALE Command . . . . . . . . . . . . . . . . . . 128 | 10.13 SET-LOCALE Command . . . . . . . . . . . . . . . . . . 132 | |||
| 10.14 TIMEOUT Command . . . . . . . . . . . . . . . . . . . 130 | 10.14 TIMEOUT Command . . . . . . . . . . . . . . . . . . . 134 | |||
| 10.15 Response Codes . . . . . . . . . . . . . . . . . . . . 130 | 10.15 Response Codes . . . . . . . . . . . . . . . . . . . . 134 | |||
| 11. Object Registration . . . . . . . . . . . . . . . . . . . 133 | 11. Object Registration . . . . . . . . . . . . . . . . . . . 137 | |||
| 11.1 Registration of New and Modified Entities . . . . . . . 133 | 11.1 Registration of New and Modified Entities . . . . . . . 137 | |||
| 11.2 Post the item definition . . . . . . . . . . . . . . . . 133 | 11.2 Post the item definition . . . . . . . . . . . . . . . . 137 | |||
| 11.3 Allow a comment period . . . . . . . . . . . . . . . . . 133 | 11.3 Allow a comment period . . . . . . . . . . . . . . . . . 137 | |||
| 11.4 Release a new RFC . . . . . . . . . . . . . . . . . . . 133 | 11.4 Release a new RFC . . . . . . . . . . . . . . . . . . . 137 | |||
| 12. BEEP and CAP . . . . . . . . . . . . . . . . . . . . . . . 134 | 12. BEEP and CAP . . . . . . . . . . . . . . . . . . . . . . . 138 | |||
| 12.1 BEEP Profile Registration . . . . . . . . . . . . . . . 134 | 12.1 BEEP Profile Registration . . . . . . . . . . . . . . . 138 | |||
| 12.2 BEEP Exchange Styles . . . . . . . . . . . . . . . . . . 136 | 12.2 BEEP Exchange Styles . . . . . . . . . . . . . . . . . . 140 | |||
| 12.3 BEEP connection details . . . . . . . . . . . . . . . . 136 | 12.3 BEEP connection details . . . . . . . . . . . . . . . . 140 | |||
| 13. IANA Considerations . . . . . . . . . . . . . . . . . . . 139 | 13. IANA Considerations . . . . . . . . . . . . . . . . . . . 143 | |||
| 14. Security Considerations . . . . . . . . . . . . . . . . . 140 | 14. Security Considerations . . . . . . . . . . . . . . . . . 144 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 141 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 145 | |||
| A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 142 | A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 146 | |||
| B. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 143 | B. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 147 | |||
| Intellectual Property and Copyright Statements . . . . . . . 145 | Intellectual Property and Copyright Statements . . . . . . . 149 | |||
| 1. Introduction | 1. Introduction | |||
| This document specifies how a Calendar CUA interacts with a CS to | This document specifies how a Calendar CUA interacts with a CS to | |||
| manage calendar information. In particular, it specifies how to | manage calendar information. In particular, it specifies how to | |||
| query, create, modify, and delete iCalendar components (e.g., events, | query, create, modify, and delete iCalendar components (e.g., events, | |||
| to-dos, or daily journal entries). It further specifies how to | to-dos, or daily journal entries). It further specifies how to | |||
| search for available busy time information. Synchronization with | search for available busy time information. Synchronization with | |||
| CUAs is not covered and believed to be possible using CAP. | CUAs is not covered and believed to be possible using CAP. | |||
| skipping to change at page 7, line 30 ¶ | skipping to change at page 7, line 33 ¶ | |||
| implementation stores the state of any object is not a protocol | implementation stores the state of any object is not a protocol | |||
| issues and is not discussed. An object can be said to be booked, | issues and is not discussed. An object can be said to be booked, | |||
| unprocessed, or marked for delete. | unprocessed, or marked for delete. | |||
| 1. An "UNPROCESSED" state scheduling object has been stored in | 1. An "UNPROCESSED" state scheduling object has been stored in | |||
| the calendar store but has not been acted on by a CU or CUA. | the calendar store but has not been acted on by a CU or CUA. | |||
| All scheduled entries are [iTIP] objects. All [iTIP] objects | All scheduled entries are [iTIP] objects. All [iTIP] objects | |||
| in the store are not in the "BOOKED" state. To retrieve any | in the store are not in the "BOOKED" state. To retrieve any | |||
| [iTIP] object, simply do a query asking for any objects that | [iTIP] object, simply do a query asking for any objects that | |||
| are stored in the "UNPROCESSED" state. | are stored in the "UNPROCESSED" state. | |||
| 2. A "BOOKED" state entry is stored with the "CREATE" command. | 2. A "BOOKED" state entry is stored with the "CREATE" command. | |||
| It is an object that has been acted on by a CU or CUA and | It is an object that has been acted on by a CU or CUA and | |||
| there has been a decision to store an object. To retrieve any | there has been a decision to store an object. To retrieve any | |||
| booked object, simply do a query asking for any objects that | booked object, simply do a query asking for any objects that | |||
| were stored in the "BOOKED" state. | were stored in the "BOOKED" state. | |||
| 3. A "DELETED" state entry is created by sending a "DELETE" | 3. A "DELETED" state entry is created by sending a "DELETE" | |||
| command with the "OPTION" parameter value set to "MARK". To | command with the "OPTION" parameter value set to "MARK". To | |||
| retrieve any deleted object, simply do a query asking for any | retrieve any deleted object, simply do a query asking for any | |||
| objects that were stored in the "DELETED" state. By default | objects that were stored in the "DELETED" state. By default | |||
| objects marked for delete are not returned. The CUA must | objects marked for delete are not returned. The CUA must | |||
| specifically ask for marked for delete objects. You can not | specifically ask for marked for delete objects. You can not | |||
| ask for components in the "DELETED" state and in other states | ask for components in the "DELETED" state and in other states | |||
| in the same "VQUERY" component, as there would be no way to | in the same "VQUERY" component, as there would be no way to | |||
| distinguish between them in the reply. | distinguish between them in the reply. | |||
| Calendar - A collection of logically related objects or entities | Calendar - A collection of logically related objects or entities | |||
| each of which may be associated with a calendar date and possibly | each of which may be associated with a calendar date and possibly | |||
| time of day. These entities can include calendar properties or | time of day. These entities can include calendar properties or | |||
| components. In addition, a calendar might be related to other | components. In addition, a calendar might be related to other | |||
| calendars with the "RELATED-TO" property. A calendar is | calendars with the "RELATED-TO" property. A calendar is | |||
| identified by its unique calendar identifier. The [iCAL] defines | identified by its unique calendar identifier. The [iCAL] defines | |||
| the initial calendar properties, calendar components and | the initial calendar properties, calendar components and | |||
| properties that make up the contents of a calendar. | properties that make up the contents of a calendar. | |||
| Calendar Access Protocol (CAP) - The standard Internet protocol that | Calendar Access Protocol (CAP) - The standard Internet protocol that | |||
| permits a CUA to access and manipulate calendars residing on a | permits a CUA to access and manipulate calendars residing on a | |||
| Calendar Store. (this memo) | Calendar Store. (this memo) | |||
| Calendar Access Rights (VCAR) - The mechanism for specifying the CAP | Calendar Access Rights (VCAR) - The mechanism for specifying the CAP | |||
| operations ("PERMISSION") that a particular calendar user ("UPN") | operations ("PERMISSION") that a particular calendar user ("UPN") | |||
| is granted or denied permission to perform on a given calendar | is granted or denied permission to perform on a given calendar | |||
| object ("SCOPE"). The calendar access rights are specified with a | object ("SCOPE"). The calendar access rights are specified with a | |||
| "VCAR" component. (Section 9.3.) | "VCAR" component. (Section 9.3.) | |||
| Calendar Address - Also See Calendar URL - they are one in the same | Calendar Address - Also See Calendar URL - they are one in the same | |||
| for CAP addresses. The calendar address can also be the value to | for CAP addresses. The calendar address can also be the value to | |||
| the "ATTENDEE" and "ORGANIZER" properties as defined in [iCAL]. | the "ATTENDEE" and "ORGANIZER" properties as defined in [iCAL]. | |||
| Calendar URL - A calendar URL is a URL defined in this memo that | Calendar URL - A calendar URL is a URL defined in this memo that | |||
| specifies the address of a CS or Calendar. | specifies the address of a CS or Calendar. | |||
| Component- Any object that conforms to the iCalendar object format | Component- Any object that conforms to the iCalendar object format | |||
| and that is either defined in an internet draft, registered with | and that is either defined in an internet draft, registered with | |||
| IANA, or is an experimental object that is prefixed with "x-". | IANA, or is an experimental object that is prefixed with "x-". | |||
| Some types of components include calendars, events, to-dos, | Some types of components include calendars, events, to-dos, | |||
| journals, alarms, and time zones. A component consists of | journals, alarms, and time zones. A component consists of | |||
| properties and possibly other contained components. For example, | properties and possibly other contained components. For example, | |||
| an event may contain an alarm component. | an event may contain an alarm component. | |||
| Container - This is a generic name for VCALSTORE or VAGENDA. | Container - This is a generic name for VCALSTORE or VAGENDA. | |||
| Properties - An attribute of a particular component. Some | Properties - An attribute of a particular component. Some | |||
| properties are applicable to different types of components. For | properties are applicable to different types of components. For | |||
| example, the "DTSTART" property is applicable to the "VEVENT", | example, the "DTSTART" property is applicable to the "VEVENT", | |||
| "VTODO", and "VJOURNAL" components. Other components are | "VTODO", and "VJOURNAL" components. Other components are | |||
| applicable only to an individual type of calendar component. For | applicable only to an individual type of calendar component. For | |||
| example, the "TZURL" property may only be applicable to the | example, the "TZURL" property may only be applicable to the | |||
| "VTIMEZONE" components. | "VTIMEZONE" components. | |||
| Calendar Identifier (CALID) - A globally unique identifier | Calendar Identifier (CALID) - A globally unique identifier | |||
| associated with a calendar. Calendars reside within a CS. See | associated with a calendar. Calendars reside within a CS. See | |||
| Qualified Calendar Identifier and Relative Calendar Identifier. | Qualified Calendar Identifier and Relative Calendar Identifier. | |||
| All CALIDs start with "cap:". | All CALIDs start with "cap:". | |||
| Calendar Policy - A CAP operational restriction on the access or | Calendar Policy - A CAP operational restriction on the access or | |||
| manipulation of a calendar. These may be outside of the scope of | manipulation of a calendar. These may be outside of the scope of | |||
| the CAP protocol. An example of an implementation or site policy | the CAP protocol. An example of an implementation or site policy | |||
| is, "events MUST BE scheduled in unit intervals of one hour". | is, "events MUST BE scheduled in unit intervals of one hour". | |||
| Calendar Property - An attribute of a calendar ("VAGENDA"). The | Calendar Property - An attribute of a calendar ("VAGENDA"). The | |||
| attribute applies to the calendar, as a whole. For example, the | attribute applies to the calendar, as a whole. For example, the | |||
| "CALSCALE" property specifies the calendar scale (e.g., the | "CALSCALE" property specifies the calendar scale (e.g., the | |||
| "GREGORIAN" value) for the all entries within the calendar. | "GREGORIAN" value) for the all entries within the calendar. | |||
| Calendar Store (CS) - The data and service model definition for a | Calendar Store (CS) - The data and service model definition for a | |||
| Calendar Store as defined in this memo. This memo does not | Calendar Store as defined in this memo. This memo does not | |||
| specify how the CS is implemented. | specify how the CS is implemented. | |||
| Calendar Server - An implementation of a Calendar Store (CS) that | Calendar Server - An implementation of a Calendar Store (CS) that | |||
| manages one or more calendars. | manages one or more calendars. | |||
| Calendar Store Identifier (CSID) - The globally unique identifier | Calendar Store Identifier (CSID) - The globally unique identifier | |||
| for an individual CS. A CSID consists of the host and port | for an individual CS. A CSID consists of the host and port | |||
| portions of a "Common Internet Scheme Syntax" part of a URL, as | portions of a "Common Internet Scheme Syntax" part of a URL, as | |||
| defined by [URL]. The CSID excludes any reference to a specific | defined by [URL]. The CSID excludes any reference to a specific | |||
| calendar. (Section 8.9) | calendar. (Section 8.9) | |||
| Calendar Store Components - Components maintained in a CS specify a | Calendar Store Components - Components maintained in a CS specify a | |||
| grouping of calendar store-wide information. | grouping of calendar store-wide information. | |||
| Calendar Store Properties - Properties maintained in a Calendar | Calendar Store Properties - Properties maintained in a Calendar | |||
| Store calendar store-wide information. | Store calendar store-wide information. | |||
| Calendar User (CU) - An entity (often biological) that uses a | Calendar User (CU) - An entity (often biological) that uses a | |||
| calendaring system. | calendaring system. | |||
| Calendar User Agent (CUA) - The client application that a CU | Calendar User Agent (CUA) - The client application that a CU | |||
| utilizes to access and manipulate a calendar. | utilizes to access and manipulate a calendar. | |||
| CAP Session - An open communication channel between a CUA and a CS. | CAP Session - An open communication channel between a CUA and a CS. | |||
| If the CAP session is authenticated, the CU is "authenticated" and | If the CAP session is authenticated, the CU is "authenticated" and | |||
| it is an "authenticated CAP session". | it is an "authenticated CAP session". | |||
| Contained Component / Contained Properties - A component or property | Contained Component / Contained Properties - A component or property | |||
| that is contained inside of another component. A "VALARM" | that is contained inside of another component. A "VALARM" | |||
| component for example may be contained inside of a "VEVENT" | component for example may be contained inside of a "VEVENT" | |||
| component. And a "TRIGGER" property could be a contained property | component. And a "TRIGGER" property could be a contained property | |||
| of a "VALARM" component. | of a "VALARM" component. | |||
| Delegate - A CU (sometimes called the delegatee) who has been | Delegate - A CU (sometimes called the delegatee) who has been | |||
| assigned participation in a scheduled component (e.g., VEVENT) by | assigned participation in a scheduled component (e.g., VEVENT) by | |||
| one of the attendees in the scheduled component (sometimes called | one of the attendees in the scheduled component (sometimes called | |||
| the delegator). An example of a delegate is a team member told to | the delegator). An example of a delegate is a team member told to | |||
| go to a particular meeting in place of another Attendee who is | go to a particular meeting in place of another Attendee who is | |||
| unable to attend. | unable to attend. | |||
| Designate - A CU who is authorized to act on behalf of another CU. | Designate - A CU who is authorized to act on behalf of another CU. | |||
| An example of a designate is an assistant. | An example of a designate is an assistant. | |||
| Experimental - The CUA and CS may implement experimental extensions | Experimental - The CUA and CS may implement experimental extensions | |||
| to the protocol. They also might have experimental components, | to the protocol. They also might have experimental components, | |||
| properties, and parameters. These extensions MUST start with "x-" | properties, and parameters. These extensions MUST start with "x-" | |||
| (or "X-") and should include a vendor prefix (such as | (or "X-") and should include a vendor prefix (such as | |||
| "x-myvendor-"). There is no guarantee that these experimental | "x-myvendor-"). There is no guarantee that these experimental | |||
| extensions will interoperate with other implementations. There is | extensions will interoperate with other implementations. There is | |||
| no guarantee that they will not interact in unpredictable ways | no guarantee that they will not interact in unpredictable ways | |||
| with other vendor experimental extensions. There is no guarantee | with other vendor experimental extensions. There is no guarantee | |||
| that the same specific experimental extension is not used my | that the same specific experimental extension is not used my | |||
| multiple vendors in incompatible ways. Implementations should | multiple vendors in incompatible ways. Implementations should | |||
| skipping to change at page 9, line 45 ¶ | skipping to change at page 10, line 26 ¶ | |||
| to the protocol. They also might have experimental components, | to the protocol. They also might have experimental components, | |||
| properties, and parameters. These extensions MUST start with "x-" | properties, and parameters. These extensions MUST start with "x-" | |||
| (or "X-") and should include a vendor prefix (such as | (or "X-") and should include a vendor prefix (such as | |||
| "x-myvendor-"). There is no guarantee that these experimental | "x-myvendor-"). There is no guarantee that these experimental | |||
| extensions will interoperate with other implementations. There is | extensions will interoperate with other implementations. There is | |||
| no guarantee that they will not interact in unpredictable ways | no guarantee that they will not interact in unpredictable ways | |||
| with other vendor experimental extensions. There is no guarantee | with other vendor experimental extensions. There is no guarantee | |||
| that the same specific experimental extension is not used my | that the same specific experimental extension is not used my | |||
| multiple vendors in incompatible ways. Implementations should | multiple vendors in incompatible ways. Implementations should | |||
| limit sending those extensions to other implementations. | limit sending those extensions to other implementations. | |||
| Object - A generic name for any component, property, parameter, or | Object - A generic name for any component, property, parameter, or | |||
| value type to be used in iCalendar. | value type to be used in iCalendar. | |||
| Overlapped Booking - A policy which indicates whether or not | Overlapped Booking - A policy which indicates whether or not | |||
| components with a "TRANSP" property not set to | components with a "TRANSP" property not set to "TRANSPARENT- | |||
| "TRANSPARENT-NOCONFLICT" or "OPAQUE-NOCONFLICT" value can overlap | NOCONFLICT" or "OPAQUE-NOCONFLICT" value can overlap one another. | |||
| one another. When the policy is applied to a calendar it | When the policy is applied to a calendar it indicates whether or | |||
| indicates whether or not the time span of any component (VEVENT, | not the time span of any component (VEVENT, VTODO, ...) in the | |||
| VTODO, ...) in the calendar can overlap the time span of any other | calendar can overlap the time span of any other component in the | |||
| component in the same calendar. When applied to an individual | same calendar. When applied to an individual object, it indicates | |||
| object, it indicates whether or not any other component's time | whether or not any other component's time span can overlap that | |||
| span can overlap that individual component. If the CS does not | individual component. If the CS does not allow overlapped | |||
| allow overlapped booking, then the CS is unwilling to allow any | booking, then the CS is unwilling to allow any overlapped bookings | |||
| overlapped bookings within any calendar or entry in the CS. | within any calendar or entry in the CS. | |||
| Owner - One or more CUs or UGs that are listed in the "OWNER" | Owner - One or more CUs or UGs that are listed in the "OWNER" | |||
| property in a calendar. There can be more than one owner. | property in a calendar. There can be more than one owner. | |||
| Qualified Calendar Identifier (Qualified CALID) - A CALID in which | Qualified Calendar Identifier (Qualified CALID) - A CALID in which | |||
| both the scheme and CSID of the CAP URI are present. | both the scheme and CSID of the CAP URI are present. | |||
| Realm - A collection of calendar user accounts, identified by a | Realm - A collection of calendar user accounts, identified by a | |||
| string. The name of the Realm is only used in UPNs. In order to | string. The name of the Realm is only used in UPNs. In order to | |||
| avoid namespace conflict, the Realm SHOULD be postfixed with an | avoid namespace conflict, the Realm SHOULD be postfixed with an | |||
| appropriate DNS domain name. (e.g., the foobar Realm could be | appropriate DNS domain name. (e.g., the foobar Realm could be | |||
| called foobar.example.com). | called foobar.example.com). | |||
| Relative Calendar Identifier (Relative CALID) - An identifier for an | Relative Calendar Identifier (Relative CALID) - An identifier for an | |||
| individual calendar in a calendar store. It MUST BE unique within | individual calendar in a calendar store. It MUST BE unique within | |||
| a calendar store. A Relative CALID consists of the "URL path" of | a calendar store. A Relative CALID consists of the "URL path" of | |||
| the "Common Internet Scheme Syntax" portion of a URL, as defined | the "Common Internet Scheme Syntax" portion of a URL, as defined | |||
| by [URI] and [URLGUIDE]. | by [URI] and [URLGUIDE]. | |||
| Session Identity - A UPN associated with a CAP session. A session | Session Identity - A UPN associated with a CAP session. A session | |||
| gains an identity after successful authentication. The identity | gains an identity after successful authentication. The identity | |||
| is used in combination with VCAR to determine access to data in | is used in combination with VCAR to determine access to data in | |||
| the CS. | the CS. | |||
| User Group (UG) - A collection of Calendar Users and/or User Groups. | User Group (UG) - A collection of Calendar Users and/or User Groups. | |||
| These groups are expanded by the CS and may reside either locally | These groups are expanded by the CS and may reside either locally | |||
| or in an external database or directory. The group membership may | or in an external database or directory. The group membership may | |||
| be fixed or dynamic over time. | be fixed or dynamic over time. | |||
| Username - A name which denotes a Calendar User within a Realm. | Username - A name which denotes a Calendar User within a Realm. | |||
| This is part of a UPN. | This is part of a UPN. | |||
| User Principal Name (UPN) - A unique identifier that denotes a CU or | User Principal Name (UPN) - A unique identifier that denotes a CU or | |||
| a group of CU. (Section 6.1.2) | a group of CU. (Section 6.1.2) | |||
| 2. Additions to iCalendar | 2. Additions to iCalendar | |||
| Several new components, properties, parameters, and value types are | Several new components, properties, parameters, and value types are | |||
| added in CAP. This section summarizes those new objects. | added in CAP. This section summarizes those new objects. | |||
| This memo extends the properties that can go into 'calprops' as | This memo extends the properties that can go into 'calprops' as | |||
| defined in [iCAL] section 4.6 page 51 to allow [iTIP] objects | defined in [iCAL] section 4.6 page 51 to allow [iTIP] objects | |||
| skipping to change at page 11, line 24 ¶ | skipping to change at page 12, line 24 ¶ | |||
| ABNF to allow IANA and experimental extensions. This memo does not | ABNF to allow IANA and experimental extensions. This memo does not | |||
| address how a CUA transmits [iTIP] or [iMIP] objects to non CAP | address how a CUA transmits [iTIP] or [iMIP] objects to non CAP | |||
| programs. (What follows is ABNF as described in [ABNF]) | programs. (What follows is ABNF as described in [ABNF]) | |||
| calprops = 2*( | calprops = 2*( | |||
| ; 'prodid' and 'version' are both REQUIRED, | ; 'prodid' and 'version' are both REQUIRED, | |||
| ; but MUST NOT occur more than once. | ; but MUST NOT occur more than once. | |||
| ; | ; | |||
| prodid /version / | prodid /version / | |||
| ; | ; | |||
| ; These are optional, but MUST NOT occur | ; These are optional, but MUST NOT occur | |||
| ; more than once. | ; more than once. | |||
| ; | ; | |||
| calscale / | calscale / | |||
| method / | method / | |||
| cmd / | cmd / | |||
| ; | ; | |||
| ; Target is optional, and may occur more | ; Target is optional, and may occur more | |||
| ; than once. | ; than once. | |||
| ; | ; | |||
| target / other-props ) | target / other-props ) | |||
| ; | ; | |||
| other-props = *(x-prop) *(iana-prop) *(other-props) | other-props = *(x-prop) *(iana-prop) *(other-props) | |||
| ; | ; | |||
| iana-prop = ; Any property registered by IANA directly or | iana-prop = ; Any property registered by IANA directly or | |||
| ; included in an RFC that may be applied to | ; included in an RFC that may be applied to | |||
| ; the component and within the rules published. | ; the component and within the rules published. | |||
| ; | ; | |||
| x-prop = ; As defined in [iCAL] | x-prop = ; As defined in [iCAL] | |||
| ; | ; | |||
| methodp = ; As defined in [iCAL] | methodp = ; As defined in [iCAL] | |||
| ; | ; | |||
| prodid = ; As defined in [iCAL] | prodid = ; As defined in [iCAL] | |||
| ; | ; | |||
| calscale = ; As defined in [iCAL] | calscale = ; As defined in [iCAL] | |||
| ; | ; | |||
| Another change is that the 'component' part of the 'icalbody' ABNF as | Another change is that the 'component' part of the 'icalbody' ABNF as | |||
| described in [iCAL] section 4.6 is optional when sending a command as | described in [iCAL] section 4.6 is optional when sending a command as | |||
| shown in the following updated ABNF: | shown in the following updated ABNF: | |||
| skipping to change at page 13, line 6 ¶ | skipping to change at page 14, line 6 ¶ | |||
| In addition a problem exists with the control of "VALARM" components | In addition a problem exists with the control of "VALARM" components | |||
| and their "TRIGGER" properties. A CU may wish to set their own alarm | and their "TRIGGER" properties. A CU may wish to set their own alarm | |||
| (local alarms) on components. These local alarms are not to be | (local alarms) on components. These local alarms are not to be | |||
| forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property | forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property | |||
| and the "ENABLE" parameter. So for the protocol between a CUA and a | and the "ENABLE" parameter. So for the protocol between a CUA and a | |||
| CS, the following changes apply to the CAP protocol from [iCAL] | CS, the following changes apply to the CAP protocol from [iCAL] | |||
| section 4.6.6 page 67: | section 4.6.6 page 67: | |||
| alarmc = "BEGIN" ":" "VALARM" CRLF | alarmc = "BEGIN" ":" "VALARM" CRLF | |||
| alarm-seq | alarm-seq | |||
| other-props | other-props | |||
| (audioprop / dispprop / emailprop / procprop) | (audioprop / dispprop / emailprop / procprop) | |||
| "END" ":" "VALARM" CRLF | "END" ":" "VALARM" CRLF | |||
| ; | ; | |||
| emailprop = ; As definded in [iCAL] | emailprop = ; As definded in [iCAL] | |||
| ; | ; | |||
| procprop = ; As definded in [iCAL] | procprop = ; As definded in [iCAL] | |||
| ; | ; | |||
| dispprop = ; As definded in [iCAL] | dispprop = ; As definded in [iCAL] | |||
| ; | ; | |||
| audioprop = ; As definded in [iCAL] | audioprop = ; As definded in [iCAL] | |||
| ; | ; | |||
| alarm-seq = "SEQUENCE" alarmseqparams ":" posint0 CRLF | alarm-seq = "SEQUENCE" alarmseqparams ":" posint0 CRLF | |||
| skipping to change at page 14, line 17 ¶ | skipping to change at page 15, line 17 ¶ | |||
| trigrel = ; As defined in [iCAL] | trigrel = ; As defined in [iCAL] | |||
| ; | ; | |||
| trigabs = ; As defined in [iCAL] | trigabs = ; As defined in [iCAL] | |||
| Section 7.2 and Section 7.5. | Section 7.2 and Section 7.5. | |||
| 2.1 New Value Types (summary) | 2.1 New Value Types (summary) | |||
| UPN The UPN value type is text value type restricted to only UPN | UPN The UPN value type is text value type restricted to only UPN | |||
| values. (Section 6.1.2) | values. (Section 6.1.2) | |||
| UPN-FILTER Like the UPN value type, but also includes filter rules | UPN-FILTER Like the UPN value type, but also includes filter rules | |||
| that allow wildcards. (Section 6.1.3) | that allow wildcards. (Section 6.1.3) | |||
| CALQUERY The "CAL-QUERY" value type is a query syntax that is used by | CALQUERY The "CAL-QUERY" value type is a query syntax that is used by | |||
| the CUA to specify the rules that apply to a CAP command. | the CUA to specify the rules that apply to a CAP command. | |||
| (Section 6.1.1) | (Section 6.1.1) | |||
| 2.1.1 New Parameters (summary) | 2.1.1 New Parameters (summary) | |||
| ACTION - The "ACTION" parameter informs the endpoint if it should | ACTION - The "ACTION" parameter informs the endpoint if it should | |||
| abort or ask to continue on timeout. (Section 7.1). | abort or ask to continue on timeout. (Section 7.1). | |||
| ENABLE - The "ENABLE" parameter in CAP is used to tag a property in | ENABLE - The "ENABLE" parameter in CAP is used to tag a property in | |||
| a component as disabled or enabled. (Section 7.2). | a component as disabled or enabled. (Section 7.2). | |||
| ID - The "ID" parameter specifies a unique identifier to be used for | ID - The "ID" parameter specifies a unique identifier to be used for | |||
| any outstanding commands. | any outstanding commands. | |||
| LATENCY - The "LATENCY" parameter supplies the timeout value for | LATENCY - The "LATENCY" parameter supplies the timeout value for | |||
| command completion to the other endpoint. (Section 7.4). | command completion to the other endpoint. (Section 7.4). | |||
| LOCAL - The "LOCAL" parameter in CAP is used to tag a property in a | LOCAL - The "LOCAL" parameter in CAP is used to tag a property in a | |||
| component to signify that the component is local or to be | component to signify that the component is local or to be | |||
| distributed. (Section 7.5). | distributed. (Section 7.5). | |||
| LOCALIZE - The "LOCALIZE" parameter specifies the locale to be used | LOCALIZE - The "LOCALIZE" parameter specifies the locale to be used | |||
| in error and warning messages. | in error and warning messages. | |||
| OPTIONS - The "OPTIONS" parameter passes optional information for | OPTIONS - The "OPTIONS" parameter passes optional information for | |||
| the command being sent. | the command being sent. | |||
| 2.1.2 New or Updated Properties (summary) | 2.1.2 New or Updated Properties (summary) | |||
| ALLOW-CONFLICT - Some entries in a calendar might not be valid if | ALLOW-CONFLICT - Some entries in a calendar might not be valid if | |||
| other entries were allowed to overlap the same time span. | other entries were allowed to overlap the same time span. | |||
| (Section 8.1) | (Section 8.1) | |||
| ATT-COUNTER - When storing a "METHOD" property with the "COUNTER" | ATT-COUNTER - When storing a "METHOD" property with the "COUNTER" | |||
| method, there needs to be a way to remember the "ATTENDEE" value | method, there needs to be a way to remember the "ATTENDEE" value | |||
| that sent the COUNTER. (Section 8.2) | that sent the COUNTER. (Section 8.2) | |||
| CAP-VERSION - The version of CAP the implementation supports. | CAP-VERSION - The version of CAP the implementation supports. | |||
| (Section 8.5) | (Section 8.5) | |||
| CAR-LEVEL - The level of calendar access level supported. (Section | ||||
| 8.7) | CAR-LEVEL - The level of calendar access level supported. | |||
| (Section 8.7) | ||||
| COMPONENTS - The list of components supported. (Section 8.8) | COMPONENTS - The list of components supported. (Section 8.8) | |||
| CSID - The Calendar Store IDentifier (CSID) uniquely identifies a | CSID - The Calendar Store IDentifier (CSID) uniquely identifies a | |||
| CAP server. (Section 8.9) | CAP server. (Section 8.9) | |||
| CALID - Each calendar within a CS needs to be uniquely identifiable. | CALID - Each calendar within a CS needs to be uniquely identifiable. | |||
| The "CALID" property identifies a unique calendar within a CS. It | The "CALID" property identifies a unique calendar within a CS. It | |||
| can be a full CALID or a relative CALID. (Section 8.3) | can be a full CALID or a relative CALID. (Section 8.3) | |||
| CALMASTER - The "CALMASTER" property specifies the contact | CALMASTER - The "CALMASTER" property specifies the contact | |||
| information for the CS. (Section 8.4) | information for the CS. (Section 8.4) | |||
| CARID - Access rights can be saved and fetched by unique ID - the | CARID - Access rights can be saved and fetched by unique ID - the | |||
| "CARID" property. (Section 8.6) | "CARID" property. (Section 8.6) | |||
| CMD - The CAP commands, as well as replies are transmitted using the | CMD - The CAP commands, as well as replies are transmitted using the | |||
| "CMD" property. (Section 10.1) | "CMD" property. (Section 10.1) | |||
| DECREED - Some access rights are not changeable by the CUA. When | DECREED - Some access rights are not changeable by the CUA. When | |||
| that is the case, the "DECREED" property value in the "VCAR" | that is the case, the "DECREED" property value in the "VCAR" | |||
| component will be "TRUE". (Section 8.10) | component will be "TRUE". (Section 8.10) | |||
| DEFAULT-CHARSET - The list of charsets supported by the CS. The | DEFAULT-CHARSET - The list of charsets supported by the CS. The | |||
| first entry is the default for the CS. (Section 8.11) | first entry is the default for the CS. (Section 8.11) | |||
| DEFAULT-LOCALE - The list of locales supported by the CS. The first | DEFAULT-LOCALE - The list of locales supported by the CS. The first | |||
| entry in the list is the default locale. (Section 8.12) | entry in the list is the default locale. (Section 8.12) | |||
| DEFAULT-TZID - This is the list of known timezones supported. The | DEFAULT-TZID - This is the list of known timezones supported. The | |||
| first entry is the default. (Section 8.13) | first entry is the default. (Section 8.13) | |||
| DEFAULT-VCARS - A list of the "CARID" properties that will be used | DEFAULT-VCARS - A list of the "CARID" properties that will be used | |||
| to create new calendars. (Section 8.14) | to create new calendars. (Section 8.14) | |||
| DENY - The UPNs listed in the "DENY" property of a "VCAR" component | DENY - The UPNs listed in the "DENY" property of a "VCAR" component | |||
| will denied access as described in the "VRIGHT" component. | will denied access as described in the "VRIGHT" component. | |||
| (Section 8.15) | (Section 8.15) | |||
| EXPAND - This property tells the CS if the query reply should expand | EXPAND - This property tells the CS if the query reply should expand | |||
| components into multiple instances. The default is "FALSE" and is | components into multiple instances. The default is "FALSE" and is | |||
| ignored for CSs that can not expand recurrence rules. (Section | ignored for CSs that can not expand recurrence rules. | |||
| 8.16) | (Section 8.16) | |||
| GRANT - The UPNs listed in the "GRANT" property of a "VCAR" | GRANT - The UPNs listed in the "GRANT" property of a "VCAR" | |||
| component will allowed access as described in the "VRIGHT" | component will allowed access as described in the "VRIGHT" | |||
| component. (Section 8.17) | component. (Section 8.17) | |||
| ITIP-VERSION - The version of [iTIP] supported. (Section 8.18) | ITIP-VERSION - The version of [iTIP] supported. (Section 8.18) | |||
| MAXDATE - The maximum date supported by the CS. (Section 8.20) | MAXDATE - The maximum date supported by the CS. (Section 8.20) | |||
| MAX-COMP-SIZE - The largest component size allowed in the | MAX-COMP-SIZE - The largest component size allowed in the | |||
| implementation including attachments in octets. (Section 8.19) | implementation including attachments in octets. (Section 8.19) | |||
| MINDATE - The minimum date supported by the CS. (Section 8.21) | MINDATE - The minimum date supported by the CS. (Section 8.21) | |||
| MULTIPART - Passed in the capability messages to indicate which MIME | MULTIPART - Passed in the capability messages to indicate which MIME | |||
| multipart types the sender supports. (Section 8.22) | multipart types the sender supports. (Section 8.22) | |||
| NAME - The "NAME" property is used to add locale specific | NAME - The "NAME" property is used to add locale specific | |||
| descriptions into components. (Section 8.23) | descriptions into components. (Section 8.23) | |||
| OWNER - Each calendar has at least one "OWNER" property. (xref | OWNER - Each calendar has at least one "OWNER" property. (xref | |||
| target="OWNER"/>) Related to the "CAL-OWNERS()" (Section 6.1.1.1) | target="OWNER"/>) Related to the "CAL-OWNERS()" (Section 6.1.1.1) | |||
| query clause. | query clause. | |||
| PERMISSION - This property specifies the permission being granted or | PERMISSION - This property specifies the permission being granted or | |||
| denied. Examples are the "SEARCH" and "MODIFY" values. (Section | denied. Examples are the "SEARCH" and "MODIFY" values. | |||
| 8.25) | (Section 8.25) | |||
| QUERY - Used to hold the CAL-QUERY (Section 8.26) for the component. | QUERY - Used to hold the CAL-QUERY (Section 8.26) for the component. | |||
| QUERYID - A unique id for a stored query. (Section 8.27) | QUERYID - A unique id for a stored query. (Section 8.27) | |||
| QUERY-LEVEL - The level of the query language supported. (Section | ||||
| 8.28) | QUERY-LEVEL - The level of the query language supported. | |||
| (Section 8.28) | ||||
| RECUR-ACCEPTED - If the implementation support recurrence rules. | RECUR-ACCEPTED - If the implementation support recurrence rules. | |||
| (Section 8.29) | (Section 8.29) | |||
| RECUR-EXPAND - If the implementation support expanding recurrence | RECUR-EXPAND - If the implementation support expanding recurrence | |||
| rules. (Section 8.31) | rules. (Section 8.31) | |||
| RECUR-LIMIT - Any maximum limit on the number of instances the | RECUR-LIMIT - Any maximum limit on the number of instances the | |||
| implementation will expand recurring objects. (Section 8.30) | implementation will expand recurring objects. (Section 8.30) | |||
| REQUEST-STATUS - The [iCAL] "REQUEST-STATUS" property is extended to | REQUEST-STATUS - The [iCAL] "REQUEST-STATUS" property is extended to | |||
| include new error numbers. | include new error numbers. | |||
| RESTRICTION - In the final check when granting calendar access | RESTRICTION - In the final check when granting calendar access | |||
| requests, the CS test the results to the value of the | requests, the CS test the results to the value of the | |||
| "RESTRICTION" property in the corresponding "VRIGHT" component to | "RESTRICTION" property in the corresponding "VRIGHT" component to | |||
| determine if the access meets that restriction. (Section 8.32) | determine if the access meets that restriction. (Section 8.32) | |||
| SCOPE - The "SCOPE" property is used in "VRIGHT"s component to | SCOPE - The "SCOPE" property is used in "VRIGHT"s component to | |||
| select the subset of data that may be acted upon when checking | select the subset of data that may be acted upon when checking | |||
| access rights. (Section 8.33) | access rights. (Section 8.33) | |||
| SEQUENCE - When the "SEQUENCE" property is used in a "VALARM" | SEQUENCE - When the "SEQUENCE" property is used in a "VALARM" | |||
| component it uniquely identifies the instances of the "VALARM" | component it uniquely identifies the instances of the "VALARM" | |||
| within that component. | within that component. | |||
| STORES-EXPANDED - Specifies if the implementation stores recurring | STORES-EXPANDED - Specifies if the implementation stores recurring | |||
| object expanded or not. (Section 8.34) | object expanded or not. (Section 8.34) | |||
| TARGET - The new "VCALENDAR" component property "TARGET" (Section | ||||
| 8.35) is used to specify which calendar(s) will be the subject of | TARGET - The new "VCALENDAR" component property "TARGET" | |||
| the CAP command. | (Section 8.35) is used to specify which calendar(s) will be the | |||
| subject of the CAP command. | ||||
| TRANSP - This is a modification the [iCAL] "TRANSP" property and it | TRANSP - This is a modification the [iCAL] "TRANSP" property and it | |||
| allows more values. The new values are related to conflict | allows more values. The new values are related to conflict | |||
| control. (Section 8.36) | control. (Section 8.36) | |||
| 2.1.3 New Components (summary) | 2.1.3 New Components (summary) | |||
| VAGENDA - CAP allows the fetching and storing of the entire contents | VAGENDA - CAP allows the fetching and storing of the entire contents | |||
| of a calendar. The "VCALENDAR" component is not sufficient to | of a calendar. The "VCALENDAR" component is not sufficient to | |||
| encapsulate all of the needed data that describes a calendar. The | encapsulate all of the needed data that describes a calendar. The | |||
| "VAGENDA" component is the encapsulating object for an entire | "VAGENDA" component is the encapsulating object for an entire | |||
| skipping to change at page 16, line 49 ¶ | skipping to change at page 19, line 4 ¶ | |||
| allows more values. The new values are related to conflict | allows more values. The new values are related to conflict | |||
| control. (Section 8.36) | control. (Section 8.36) | |||
| 2.1.3 New Components (summary) | 2.1.3 New Components (summary) | |||
| VAGENDA - CAP allows the fetching and storing of the entire contents | VAGENDA - CAP allows the fetching and storing of the entire contents | |||
| of a calendar. The "VCALENDAR" component is not sufficient to | of a calendar. The "VCALENDAR" component is not sufficient to | |||
| encapsulate all of the needed data that describes a calendar. The | encapsulate all of the needed data that describes a calendar. The | |||
| "VAGENDA" component is the encapsulating object for an entire | "VAGENDA" component is the encapsulating object for an entire | |||
| calendar. (Section 9.1) | calendar. (Section 9.1) | |||
| VCALSTORE - Each CS contains one or more calendars (VAGENDAs), the | VCALSTORE - Each CS contains one or more calendars (VAGENDAs), the | |||
| "VCALSTORE" component is the encapsulating object that can hold | "VCALSTORE" component is the encapsulating object that can hold | |||
| all of the "VAGENDA" components along with any components and | all of the "VAGENDA" components along with any components and | |||
| properties that are unique to the store level. (Section 9.2) | properties that are unique to the store level. (Section 9.2) | |||
| VCAR - Calendar Access Rights are specified and encapsulated in the | VCAR - Calendar Access Rights are specified and encapsulated in the | |||
| new iCalendar "VCAR" component. The "VCAR" component holds some | new iCalendar "VCAR" component. The "VCAR" component holds some | |||
| new properties and at least one "VRIGHT" component. (Section 9.3) | new properties and at least one "VRIGHT" component. (Section 9.3) | |||
| VRIGHT - This component encapsulates a set of instructions to the CS | VRIGHT - This component encapsulates a set of instructions to the CS | |||
| that define the rights or restrictions needed. (Section 9.4) | that define the rights or restrictions needed. (Section 9.4) | |||
| VREPLY - This component encapsulates a set of data that can consist | VREPLY - This component encapsulates a set of data that can consist | |||
| of an arbitrary amounts of properties and components. Its | of an arbitrary amounts of properties and components. Its | |||
| contents is dependent on the command that was issued. (Section | contents is dependent on the command that was issued. | |||
| 9.5) | (Section 9.5) | |||
| VQUERY - The search operation makes use of a new component, called | VQUERY - The search operation makes use of a new component, called | |||
| "VQUERY" and a new value type "CAL-QUERY" (Section 6.1.1). The | "VQUERY" and a new value type "CAL-QUERY" (Section 6.1.1). The | |||
| "VQUERY" component is used to fetch objects from the CS. (Section | "VQUERY" component is used to fetch objects from the CS. | |||
| 9.6) | (Section 9.6) | |||
| 2.2 Relationship of RFC-2446 (ITIP) and CAP | 2.2 Relationship of RFC-2446 (ITIP) and CAP | |||
| [iTIP] describes scheduling methods which result in indirect | [iTIP] describes scheduling methods which result in indirect | |||
| manipulation of components. In CAP, the "CREATE" command is used to | manipulation of components. In CAP, the "CREATE" command is used to | |||
| deposit entities into the store. Other CAP commands such as | deposit entities into the store. Other CAP commands such as | |||
| "DELETE", "MODIFY" and "MOVE" command values provide direct | "DELETE", "MODIFY" and "MOVE" command values provide direct | |||
| manipulation of components. In the CAP calendar store model, | manipulation of components. In the CAP calendar store model, | |||
| scheduling messages are conceptually kept separate from other | scheduling messages are conceptually kept separate from other | |||
| components by their state. | components by their state. | |||
| skipping to change at page 21, line 18 ¶ | skipping to change at page 24, line 18 ¶ | |||
| charsets for the session, the CUA issues the "SET-LOCALE" command. | charsets for the session, the CUA issues the "SET-LOCALE" command. | |||
| The CUA would have to first perform a "GET-CAPABILITY" command on the | The CUA would have to first perform a "GET-CAPABILITY" command on the | |||
| CS to get the list of charsets supported by the CS. The charset is | CS to get the list of charsets supported by the CS. The charset is | |||
| switched only after a successful reply. | switched only after a successful reply. | |||
| The CUA may switch locales and charsets as needed. There is no | The CUA may switch locales and charsets as needed. There is no | |||
| requirement that a CS support multiple locales or charsets. | requirement that a CS support multiple locales or charsets. | |||
| 3.3.1 Use of BEEP, MIME and iCalendar | 3.3.1 Use of BEEP, MIME and iCalendar | |||
| CAP uses the [BEEP] application protocol over TCP. (refer to [BEEP] | CAP uses the [BEEP] application protocol over TCP. (refer to [BEEP] | |||
| and [BEEPTCP] for more information). The default port that the CS | and [BEEPTCP] for more information). The default port that the CS | |||
| listens for connections is on user port 1026. | listens for connections is on user port 1026. | |||
| The [BEEP] data exchanged in CAP is a iCalendar MIME content that | The [BEEP] data exchanged in CAP is a iCalendar MIME content that | |||
| fully conforms to [iCAL] iCalendar format. | fully conforms to [iCAL] iCalendar format. | |||
| This example tells the CS to generate and return 10 UIDs to be used | This example tells the CS to generate and return 10 UIDs to be used | |||
| by the CUA. Note throughout this memo, 'C:' refers to what the CUA | by the CUA. Note throughout this memo, 'C:' refers to what the CUA | |||
| sends, 'S:' refers to what the CS sends, 'I:' refers to what the | sends, 'S:' refers to what the CS sends, 'I:' refers to what the | |||
| initiator sends, and 'L:' refers to what the listener sends. Where | initiator sends, and 'L:' refers to what the listener sends. Where | |||
| skipping to change at page 22, line 7 ¶ | skipping to change at page 25, line 7 ¶ | |||
| NOTE: The following examples will not include the [BEEP] header and | NOTE: The following examples will not include the [BEEP] header and | |||
| footer information. Only the iCalendar objects that are sent between | footer information. Only the iCalendar objects that are sent between | |||
| the CUA and CS will be shown as the [BEEP] payload boundaries are | the CUA and CS will be shown as the [BEEP] payload boundaries are | |||
| independent of CAP. | independent of CAP. | |||
| The commands listed below are used to manipulate or access the data | The commands listed below are used to manipulate or access the data | |||
| on the calendar store: | on the calendar store: | |||
| ABORT - Sent to halt the processing of some of the commands. | ABORT - Sent to halt the processing of some of the commands. | |||
| (Section 10.2) | (Section 10.2) | |||
| CONTINUE - Sent to continue processing a command that has had its | CONTINUE - Sent to continue processing a command that has had its | |||
| specified timeout time reached. (Section 10.3) | specified timeout time reached. (Section 10.3) | |||
| CREATE - Create a new object on the CS. Initiated by the CUA only. | CREATE - Create a new object on the CS. Initiated by the CUA only. | |||
| (Section 10.4) | (Section 10.4) | |||
| SET-LOCALE - Tell the CS to use any named locale and charset | SET-LOCALE - Tell the CS to use any named locale and charset | |||
| supplied. Initiated by the CUA only. (Section 10.13) | supplied. Initiated by the CUA only. (Section 10.13) | |||
| DELETE - Delete objects from the CS. Initiated by the CUA only. | DELETE - Delete objects from the CS. Initiated by the CUA only. | |||
| Can also be used to mark an object for deletion. (Section 10.5) | Can also be used to mark an object for deletion. (Section 10.5) | |||
| GENERATE-UID - Generate one or more unique ids. Initiated by the | GENERATE-UID - Generate one or more unique ids. Initiated by the | |||
| CUA only. (Section 10.6) | CUA only. (Section 10.6) | |||
| GET-CAPABILITY - Query the capabilities the other end point of the | GET-CAPABILITY - Query the capabilities the other end point of the | |||
| session. (Section 10.7) | session. (Section 10.7) | |||
| IDENTIFY - Set a new identity for the session. Initiated by the CUA | IDENTIFY - Set a new identity for the session. Initiated by the CUA | |||
| only. (Section 10.8) | only. (Section 10.8) | |||
| MODIFY - Modify components. Initiated by the CUA only. (Section | ||||
| 10.9) | MODIFY - Modify components. Initiated by the CUA only. | |||
| (Section 10.9) | ||||
| MOVE - Move components to another container. Initiated by the CUA | MOVE - Move components to another container. Initiated by the CUA | |||
| only. (Section 10.10) | only. (Section 10.10) | |||
| REPLY - When replying to a command, the "CMD" value will be set to | REPLY - When replying to a command, the "CMD" value will be set to | |||
| "REPLY" so that it will not be confused with a new command. | "REPLY" so that it will not be confused with a new command. | |||
| (Section 10.11) | (Section 10.11) | |||
| SEARCH - Search for components. Initiated by the CUA only. | SEARCH - Search for components. Initiated by the CUA only. | |||
| (Section 10.12) | (Section 10.12) | |||
| TIMEOUT - Sent when a specified amount of time has lapsed and a | TIMEOUT - Sent when a specified amount of time has lapsed and a | |||
| command has not finished. (Section 10.14) | command has not finished. (Section 10.14) | |||
| 4. Security Model | 4. Security Model | |||
| The [BEEP] transport performs all session authentication. | The [BEEP] transport performs all session authentication. | |||
| 4.1 Calendar User and UPNs | 4.1 Calendar User and UPNs | |||
| A CU is an entity that can be authenticated. It is represented in | A CU is an entity that can be authenticated. It is represented in | |||
| skipping to change at page 23, line 26 ¶ | skipping to change at page 26, line 26 ¶ | |||
| mechanism, a VCAR could not be consistently evaluated. A CU may use | 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 | one mechanism while using one CUA but the same CU may use a different | |||
| authentication mechanism when using a different CUA, or while | authentication mechanism when using a different CUA, or while | |||
| connecting from a different location. | connecting from a different location. | |||
| The user may also have multiple UPNs for various purposes. | The user may also have multiple UPNs for various purposes. | |||
| Note that the immutability of the user's UPN may be achieved by using | Note that the immutability of the user's UPN may be achieved by using | |||
| SASL's authorization identity feature. (The transmitted | SASL's authorization identity feature. (The transmitted | |||
| authorization identity may be different than the identity in the | authorization identity may be different than the identity in the | |||
| client's authentication credentials.) [SASL, section 3]. This also | client's authentication credentials.) [SASL, section 3]. This also | |||
| permits a CU to authenticate using their own credentials, yet request | permits a CU to authenticate using their own credentials, yet request | |||
| the access privileges of the identity for which they are proxying | the access privileges of the identity for which they are proxying | |||
| SASL. Also, the form of authentication identity supplied by a | SASL. Also, the form of authentication identity supplied by a | |||
| service like TLS may not correspond to the UPNs used to express a | service like TLS may not correspond to the UPNs used to express a | |||
| server's access rights, requiring a server specific mapping to be | server's access rights, requiring a server specific mapping to be | |||
| done. The method by which a server determines a UPN, based on the | done. The method by which a server determines a UPN, based on the | |||
| authentication credentials supplied by a client, is implementation | authentication credentials supplied by a client, is implementation | |||
| specific. See [BEEP] for authentication details; [BEEP] relies on | specific. See [BEEP] for authentication details; [BEEP] relies on | |||
| SASL. | SASL. | |||
| 4.1.1 UPNs and Certificates | 4.1.1 UPNs and Certificates | |||
| When using X.509 certificates for purposes of CAP authentication, the | When using X.509 certificates for purposes of CAP authentication, the | |||
| UPN should appear in the certificate. Unfortunately there is no | UPN should appear in the certificate. Unfortunately there is no | |||
| single correct guideline for which field should contain the UPN. | single correct guideline for which field should contain the UPN. | |||
| From RFC-2459, section 4.1.2.6 (Subject): | From RFC-2459, section 4.1.2.6 (Subject): | |||
| If subject naming information is present only in the | ||||
| subjectAlt-Name extension (e.g., a key bound only to an email | If subject naming information is present only in the subjectAlt- | |||
| address or URI), then the subject name MUST be an empty sequence | Name extension (e.g., a key bound only to an email address or | |||
| and the subjectAltName extension MUST BE critical. | 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 | Implementations of this specification MAY use these comparison | |||
| rules to process unfamiliar attribute types (i.e., for name | rules to process unfamiliar attribute types (i.e., for name | |||
| chaining). This allows implementations to process certificates | chaining). This allows implementations to process certificates | |||
| with unfamiliar attributes in the subject name. | with unfamiliar attributes in the subject name. | |||
| In addition, legacy implementations exist where an RFC 2822 name | In addition, legacy implementations exist where an RFC 2822 name | |||
| is embedded in the subject distinguished name as an EmailAddress | is embedded in the subject distinguished name as an EmailAddress | |||
| attribute. The attribute value for EmailAddress is of type | attribute. The attribute value for EmailAddress is of type | |||
| IA5String to permit inclusion of the character '@', which is not | IA5String to permit inclusion of the character '@', which is not | |||
| part of the PrintableString character set. EmailAddress attribute | part of the PrintableString character set. EmailAddress attribute | |||
| values are not case sensitive (e.g., | values are not case sensitive (e.g., | |||
| "fanfeedback@redsox.example.com" is the same as | "fanfeedback@redsox.example.com" is the same as "FANFEEDBACK@ | |||
| "FANFEEDBACK@REDSOX.EXAMPLE.COM"). | REDSOX.EXAMPLE.COM"). | |||
| Conforming implementations generating new certificates with | Conforming implementations generating new certificates with | |||
| electronic mail addresses MUST use the rfc822Name in the subject | electronic mail addresses MUST use the rfc822Name in the subject | |||
| alternative name field (see sec. 4.2.1.7 of [X509CRL]) to | alternative name field (see sec. 4.2.1.7 of [X509CRL]) to describe | |||
| describe such identities. Simultaneous inclusion of the | such identities. Simultaneous inclusion of the EmailAddress | |||
| EmailAddress attribute in the subject distinguished name to | attribute in the subject distinguished name to support legacy | |||
| support legacy implementations is deprecated but permitted. | implementations is deprecated but permitted. | |||
| Since no single method of including the UPN in the certificate will | Since no single method of including the UPN in the certificate will | |||
| work in all cases, CAP implementations MUST support the ability to | work in all cases, CAP implementations MUST support the ability to | |||
| configure what the mapping will be by the CS administrator. | configure what the mapping will be by the CS administrator. | |||
| Implementations MAY support multiple mapping definitions, for | Implementations MAY support multiple mapping definitions, for | |||
| example, the UPN may be found in either the subject alternative name | example, the UPN may be found in either the subject alternative name | |||
| field, or the UPN may be embedded in the subject distinguished name | field, or the UPN may be embedded in the subject distinguished name | |||
| as an EmailAddress attribute. | as an EmailAddress attribute. | |||
| Note: If a CS or CUA is validating data received via [iMIP], if the | Note: If a CS or CUA is validating data received via [iMIP], if the | |||
| "ORGANIZER" or "ATTENDEE" properties said (e.g.) "ATTENDEE;CN=Joe | "ORGANIZER" or "ATTENDEE" properties said (e.g.) "ATTENDEE;CN=Joe | |||
| Random User:MAILTO:juser@example.com" then the email address should | Random User:MAILTO:juser@example.com" then the email address should | |||
| be checked against the UPN. This is so the "ATTENDEE" property | be checked against the UPN. This is so the "ATTENDEE" property | |||
| cannot be changed to something misleading like "ATTENDEE;CN=Joe | cannot be changed to something misleading like "ATTENDEE;CN=Joe | |||
| Rictus User:MAILTO:jrictus@example.com" and have it pass validation. | Rictus User:MAILTO:jrictus@example.com" and have it pass validation. | |||
| Note that it is the email addresses that miscompare, the CN | Note that it is the email addresses that miscompare, the CN | |||
| miscompare is irrelevant. | miscompare is irrelevant. | |||
| 4.1.2 Anonymous Users and Authentication | 4.1.2 Anonymous Users and Authentication | |||
| Anonymous access is often desirable. For example an organization may | Anonymous access is often desirable. For example an organization may | |||
| skipping to change at page 34, line 4 ¶ | skipping to change at page 37, line 16 ¶ | |||
| Will return all of the properties in each "VALARM" component | Will return all of the properties in each "VALARM" component | |||
| in the matching "VEVENT" component: | in the matching "VEVENT" component: | |||
| TRIGGER;RELATED=END:PT5M | TRIGGER;RELATED=END:PT5M | |||
| REPEAT:4 | REPEAT:4 | |||
| ... | ... | |||
| TRIGGER;RELATED=START:PT5M | TRIGGER;RELATED=START:PT5M | |||
| DURATION:PT10M | DURATION:PT10M | |||
| ... | ... | |||
| ... | ... | |||
| (a) SELECT <a-property-name> FROM VEVENT | (a) SELECT <a-property-name> FROM VEVENT | |||
| (b) SELECT VALARM FROM VEVENT | (b) SELECT VALARM FROM VEVENT | |||
| (c) SELECT VALARM.* FROM VEVENT | (c) SELECT VALARM.* FROM VEVENT | |||
| (d) SELECT * FROM VEVENT | (d) SELECT * FROM VEVENT | |||
| (e) SELECT * FROM VEVENT WHERE | (e) SELECT * FROM VEVENT WHERE | |||
| VALARM.TRIGGER < '20020201T000000Z' | VALARM.TRIGGER < '20020201T000000Z' | |||
| AND VALARM.TRIGGER > '20020101T000000Z' | AND VALARM.TRIGGER > '20020101T000000Z' | |||
| Note: | Note: | |||
| (a) Selects all instances of <a-property-name> | (a) Selects all instances of <a-property-name> | |||
| from all "VEVENT" components. | from all "VEVENT" components. | |||
| (b) and (c) Select all "VALARM" components from all | (b) and (c) Select all "VALARM" components from all | |||
| "VEVENT" components. (b) would return then in | "VEVENT" components. (b) would return then in | |||
| BEGIN/END VALARM tags. (c) would return all | BEGIN/END VALARM tags. (c) would return all | |||
| of the properties without BEGIN/END VALARM tags. | of the properties without BEGIN/END VALARM tags. | |||
| (d) Selects every property and every component | (d) Selects every property and every component | |||
| that is in any "VEVENT" component, with each "VEVENT" | that is in any "VEVENT" component, with each "VEVENT" | |||
| component wrapped in a BEGIN/END VEVENT tags. | component wrapped in a BEGIN/END VEVENT tags. | |||
| (e) Selects all properties and all contained | (e) Selects all properties and all contained | |||
| components in all "VEVENT" components that have a "VALARM" | components in all "VEVENT" components that have a "VALARM" | |||
| component with a "TRIGGER" property value between | component with a "TRIGGER" property value between | |||
| the provided dates and times, with each "VEVENT" | the provided dates and times, with each "VEVENT" | |||
| component wrapped in a BEGIN/END VEVENT tags. | component wrapped in a BEGIN/END VEVENT tags. | |||
| NOT VALID: | NOT VALID: | |||
| (f) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT | (f) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT | |||
| (g) SELECT DTSTART,UID FROM VEVENT WHERE | (g) SELECT DTSTART,UID FROM VEVENT WHERE | |||
| VTODO.SUMMERY = "Fix typo in CAP" | VTODO.SUMMERY = "Fix typo in CAP" | |||
| Note: (f) Is NOT valid because it contains | Note: (f) Is NOT valid because it contains | |||
| two '.' characters in the "SELECT" clause. | two '.' characters in the "SELECT" clause. | |||
| (g) Is NOT valid because it mixes VEVENT | (g) Is NOT valid because it mixes VEVENT | |||
| and VTODO properties in the same VQUERY. | and VTODO properties in the same VQUERY. | |||
| Formal Definition: The value type is defined by the following | Formal Definition: The value type is defined by the following | |||
| notation: | notation: | |||
| cal-query = "SELECT" SP cap-val SP | cal-query = "SELECT" SP cap-val SP | |||
| "FROM" SP comp-name SP | "FROM" SP comp-name SP | |||
| "WHERE" SP cap-expr | "WHERE" SP cap-expr | |||
| / "SELECT" SP cap-cols SP | / "SELECT" SP cap-cols SP | |||
| "FROM" SP comp-name | "FROM" SP comp-name | |||
| ; | ; | |||
| cap-val = cap-cols / param | cap-val = cap-cols / param | |||
| / ( cap-val "," cap-val ) | / ( cap-val "," cap-val ) | |||
| ; | ; | |||
| ; NOTE: there is NO space around the "," on | ; NOTE: there is NO space around the "," on | |||
| ; the next line | ; the next line | |||
| cap-cols = cap-col / ( cap-cols "," cap-col) | cap-cols = cap-col / ( cap-cols "," cap-col) | |||
| / "*" | / "*" | |||
| / "*.*" ; only valid when the target is a "VAGENDA" | / "*.*" ; only valid when the target is a "VAGENDA" | |||
| ; | ; | |||
| ; A 'cap-col' is: | ; A 'cap-col' is: | |||
| ; | ; | |||
| ; Any property name ('cap-prop') found in the component | ; Any property name ('cap-prop') found in the component | |||
| ; named in the 'comp-name' used in the "FROM" clause. | ; named in the 'comp-name' used in the "FROM" clause. | |||
| ; | ; | |||
| ; SELECT ORGANIZER FROM VEVENT ... | ; SELECT ORGANIZER FROM VEVENT ... | |||
| ; | ; | |||
| ; OR | ; OR | |||
| ; | ; | |||
| ; A component name ('comp-name') of an existing component | ; A component name ('comp-name') of an existing component | |||
| ; contained inside of the 'comp-name' used in the "FROM" | ; contained inside of the 'comp-name' used in the "FROM" | |||
| ; clause. | ; clause. | |||
| ; | ; | |||
| ; SELECT VALARM FROM VEVENT ... | ; SELECT VALARM FROM VEVENT ... | |||
| ; | ; | |||
| ; OR | ; OR | |||
| ; | ; | |||
| ; A component name ('comp-name') of an existing | ; A component name ('comp-name') of an existing | |||
| ; component contained inside of the 'comp-name' used | ; component contained inside of the 'comp-name' used | |||
| ; in the "FROM" clause followed by a property | ; in the "FROM" clause followed by a property | |||
| ; name ('cap-prop') to be selected from that component. | ; name ('cap-prop') to be selected from that component. | |||
| ; (comp-name "." cap-prop) | ; (comp-name "." cap-prop) | |||
| ; | ; | |||
| ; SELECT VALARM.TRIGGER FROM VEVENT ... | ; SELECT VALARM.TRIGGER FROM VEVENT ... | |||
| ; | ; | |||
| cap-col = comp-name | cap-col = comp-name | |||
| / comp-name "." cap-prop | / comp-name "." cap-prop | |||
| / cap-prop | / cap-prop | |||
| ; | ; | |||
| comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" | comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" | |||
| / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" | / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" | |||
| / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" | / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" | |||
| / "VRIGHT" / x-comp / iana-comp | / "VRIGHT" / x-comp / iana-comp | |||
| ; | ; | |||
| cap-prop = ; A property that may be in the 'cap-comp' named | cap-prop = ; A property that may be in the 'cap-comp' named | |||
| ; in the "SELECT" clause. | ; in the "SELECT" clause. | |||
| ; | ; | |||
| cap-expr = "(" cap-expr ")" | cap-expr = "(" cap-expr ")" | |||
| / cap-term | / cap-term | |||
| ; | ; | |||
| cap-term = cap-expr SP cap-logical SP cap-expr | cap-term = cap-expr SP cap-logical SP cap-expr | |||
| / cap-factor | / cap-factor | |||
| ; | ; | |||
| cap-logical= "AND" / "OR" | cap-logical= "AND" / "OR" | |||
| ; | ; | |||
| cap-factor = cap-colval SP cap-oper SP col-value | cap-factor = cap-colval SP cap-oper SP col-value | |||
| / cap-colval SP "LIKE" SP col-value | / cap-colval SP "LIKE" SP col-value | |||
| / cap-colval SP "NOT LIKE" SP col-value | / cap-colval SP "NOT LIKE" SP col-value | |||
| / cap-colval SP "IS NULL" | / cap-colval SP "IS NULL" | |||
| / cap-colval SP "IS NOT NULL" | / cap-colval SP "IS NOT NULL" | |||
| / col-value SP "IN" cap-colval | / col-value SP "IN" cap-colval | |||
| / col-value SP "NOT IN" cap-colval | / col-value SP "NOT IN" cap-colval | |||
| / "STATE()" "=" ( "BOOKED" | / "STATE()" "=" ( "BOOKED" | |||
| / "UNPROCESSED" | / "UNPROCESSED" | |||
| / "DELETED" | / "DELETED" | |||
| / iana-state | / iana-state | |||
| / x-state ) | / x-state ) | |||
| ; | ; | |||
| iana-state = ; Any state registered by IANA directly or | iana-state = ; Any state registered by IANA directly or | |||
| ; included in an RFC that may be applied to | ; included in an RFC that may be applied to | |||
| ; the component and within the rules published. | ; the component and within the rules published. | |||
| ; | ; | |||
| x-state = ; Any experimental state that starts with | x-state = ; Any experimental state that starts with | |||
| ; "x-" or "X-". | ; "x-" or "X-". | |||
| ; | ; | |||
| cap-colval = cap-col / param | cap-colval = cap-col / param | |||
| ; | ; | |||
| param = "PARAM(" cap-col "," cap-param ")" | param = "PARAM(" cap-col "," cap-param ")" | |||
| ; | ; | |||
| cap-param = ; Any parameter that may be contained in the cap-col | cap-param = ; Any parameter that may be contained in the cap-col | |||
| ; in the supplied PARAM() function | ; in the supplied PARAM() function | |||
| ; | ; | |||
| col-value = col-literal | col-value = col-literal | |||
| / "SELF()" | / "SELF()" | |||
| / "CAL-OWNERS()" | / "CAL-OWNERS()" | |||
| / "CAL-OWNERS(" cal-address ")" | / "CAL-OWNERS(" cal-address ")" | |||
| / "CURRENT-TARGET()" | / "CURRENT-TARGET()" | |||
| ; | ; | |||
| cal-address = ; A CALID as define by CAP | cal-address = ; A CALID as define by CAP | |||
| ; | ; | |||
| col-literal = "'" literal-data "'" | col-literal = "'" literal-data "'" | |||
| ; | ; | |||
| literal-data = ; Any data that matches the value type of the | literal-data = ; Any data that matches the value type of the | |||
| ; column that is being compared. That is you can | ; column that is being compared. That is you can | |||
| ; not compare PRIORITY to "some string" because | ; not compare PRIORITY to "some string" because | |||
| ; PRIORITY has a value type of integer. If it is | ; PRIORITY has a value type of integer. If it is | |||
| ; not preceded by the LIKE element, any '%' and '_' | ; not preceded by the LIKE element, any '%' and '_' | |||
| ; characters in the literal data are not treated as | ; characters in the literal data are not treated as | |||
| ; wildcard characters and do not have to be backslash | ; wildcard characters and do not have to be backslash | |||
| ; escaped. | ; escaped. | |||
| ; | ; | |||
| ; OR | ; OR | |||
| ; | ; | |||
| ; If the literal-data is preceded by the LIKE | ; If the literal-data is preceded by the LIKE | |||
| ; element it may also contain the '%' and '_' | ; element it may also contain the '%' and '_' | |||
| ; wildcard characters. And if the literal data | ; wildcard characters. And if the literal data | |||
| ; that is comparing contains any '%' or '_' | ; that is comparing contains any '%' or '_' | |||
| ; characters, they MUST BE backslash escaped as | ; characters, they MUST BE backslash escaped as | |||
| ; described in the notes below in order for them not | ; described in the notes below in order for them not | |||
| ; to be treated as wildcard characters. | ; to be treated as wildcard characters. | |||
| ; | ; | |||
| ; And if the literal data contains any characters | ; And if the literal data contains any characters | |||
| ; that would have to be backslash escaped if | ; that would have to be backslash escaped if | |||
| ; a property or parameter value then they must | ; a property or parameter value then they must | |||
| ; be backslash escaped in the literal-data. | ; be backslash escaped in the literal-data. | |||
| ; PLUS the quote character (') must be backslash | ; PLUS the quote character (') must be backslash | |||
| ; escaped. Example: | ; escaped. Example: | |||
| ; | ; | |||
| ; ... WHERE SUBJECT = 'It\'s time to ski' | ; ... WHERE SUBJECT = 'It\'s time to ski' | |||
| ; | ; | |||
| cap-oper = "=" | cap-oper = "=" | |||
| / "!=" | / "!=" | |||
| / "<" | / "<" | |||
| / ">" | / ">" | |||
| / "<=" | / "<=" | |||
| / ">=" | / ">=" | |||
| ; | ; | |||
| SP = ; A single white space ASCII character | SP = ; A single white space ASCII character | |||
| ; (value in HEX %x20). | ; (value in HEX %x20). | |||
| ; | ; | |||
| x-comp = ; As defined in [iCAL] section 4.6 | x-comp = ; As defined in [iCAL] section 4.6 | |||
| ; | ; | |||
| iana-comp = ; As defined in [iCAL] section 4.6 | iana-comp = ; As defined in [iCAL] section 4.6 | |||
| 6.1.1.1 [NOT] CAL-OWNERS() | 6.1.1.1 [NOT] CAL-OWNERS() | |||
| This function returns the list of "OWNER" properties for the named | This function returns the list of "OWNER" properties for the named | |||
| calendar when used in the "SELECT" clause. | calendar when used in the "SELECT" clause. | |||
| skipping to change at page 38, line 40 ¶ | skipping to change at page 42, line 40 ¶ | |||
| Used in a CAL-QUERY. Returns or tests for the value of the named | Used in a CAL-QUERY. Returns or tests for the value of the named | |||
| parameter from the named property. | parameter from the named property. | |||
| 6.1.1.3.1 PARAM() in SELECT | 6.1.1.3.1 PARAM() in SELECT | |||
| When used in a "SELECT" clause, it returns the entire property and | When used in a "SELECT" clause, it returns the entire property and | |||
| all of that properties parameters (the result is not limited to the | all of that properties parameters (the result is not limited to the | |||
| supplied parameter). If the property does not contain the named | supplied parameter). If the property does not contain the named | |||
| parameter, then the property is not returned (It could however be | parameter, then the property is not returned (It could however be | |||
| returned as a result of another "SELECT" clause value.) If multiple | returned as a result of another "SELECT" clause value.) If multiple | |||
| properties of the supplied name have the named parameter, all | properties of the supplied name have the named parameter, all | |||
| properties with that named parameter are returned. If multiple | properties with that named parameter are returned. If multiple | |||
| PARAM() clauses in a single "SELECT" CLAUSE match the same property, | PARAM() clauses in a single "SELECT" CLAUSE match the same property, | |||
| then the single matching property is returned only once. | then the single matching property is returned only once. | |||
| Also note that many parameters have default values defined in [iCAL] | Also note that many parameters have default values defined in [iCAL] | |||
| that must be treated as existing with their default value in the | that must be treated as existing with their default value in the | |||
| properties as defined in [iCAL} even when not explicitly present. So | properties as defined in [iCAL} even when not explicitly present. So | |||
| for example if a query were performed with PARAM(ATTENDEE,ROLE) then | for example if a query were performed with PARAM(ATTENDEE,ROLE) then | |||
| ALL "ATTENDEE" properties would match because even when they do not | ALL "ATTENDEE" properties would match because even when they do not | |||
| skipping to change at page 41, line 14 ¶ | skipping to change at page 45, line 14 ¶ | |||
| clause the comparison will be done as if the value is a [iCAL] DATE | clause the comparison will be done as if the value is a [iCAL] DATE | |||
| or DATE-TIME string value. | or DATE-TIME string value. | |||
| LIKE '2002%' will match anything in the year 2002. | LIKE '2002%' will match anything in the year 2002. | |||
| LIKE '200201%' will match anything in January 2002. | LIKE '200201%' will match anything in January 2002. | |||
| LIKE '%T000000' will match anything at midnight. | LIKE '%T000000' will match anything at midnight. | |||
| LIKE '____01__T%' will match anything for any year or | LIKE '____01__T%' will match anything for any year or | |||
| time that is in January. | time that is in January. | |||
| (Four '_', '01', two '_' 'T%'). | (Four '_', '01', two '_' 'T%'). | |||
| Using a "LIKE" clause value of "%00%, would return any value that | Using a "LIKE" clause value of "%00%, would return any value that | |||
| contained two consecutive zeros. | contained two consecutive zeros. | |||
| All comparisons will be done in UTC. | All comparisons will be done in UTC. | |||
| 6.1.1.8 DTEND and DURATION | 6.1.1.8 DTEND and DURATION | |||
| The "DTEND" property value is not included in the time occupied by | The "DTEND" property value is not included in the time occupied by | |||
| the component. That is a "DTEND" property value of 20030614T12000 | the component. That is a "DTEND" property value of 20030614T12000 | |||
| skipping to change at page 42, line 17 ¶ | skipping to change at page 46, line 17 ¶ | |||
| end with a percent sign. | end with a percent sign. | |||
| To match a '%' or '_' in the data and not have it interpreted as a | To match a '%' or '_' in the data and not have it interpreted as a | |||
| wildcard character, they MUST BE backslash escaped. That is to | wildcard character, they MUST BE backslash escaped. That is to | |||
| search for a '%' or '_' in the string: | search for a '%' or '_' in the string: | |||
| LIKE '%\%%' Matches any string with a '%' in it. | LIKE '%\%%' Matches any string with a '%' in it. | |||
| LIKE '%\_%' Matches any string with a '_' in it. | LIKE '%\_%' Matches any string with a '_' in it. | |||
| Strings compared using the "LIKE" clause MUST BE performed using case | Strings compared using the "LIKE" clause MUST BE performed using case | |||
| in-sensitive comparisons when the locale allows. (Example: in | in-sensitive comparisons when the locale allows. (Example: in US- | |||
| US-ASCII the compare assumes 'a' = 'A'). | ASCII the compare assumes 'a' = 'A'). | |||
| If the "LIKE" clause is preceded by 'NOT' then there is a match when | If the "LIKE" clause is preceded by 'NOT' then there is a match when | |||
| the string compare fails. | the string compare fails. | |||
| Some property values (such as the 'recur' value type), contain commas | Some property values (such as the 'recur' value type), contain commas | |||
| and are not multi valued. The CS must understand the objects being | and are not multi valued. The CS must understand the objects being | |||
| compared and understand how to determine how any multi valued or | compared and understand how to determine how any multi valued or | |||
| multi instances properties or parameter values are separated, quoted, | multi instances properties or parameter values are separated, quoted, | |||
| and backslash escaped and perform the comparisons as if each value | and backslash escaped and perform the comparisons as if each value | |||
| existed by itself and not quoted or backslash escaped when comparing | existed by itself and not quoted or backslash escaped when comparing | |||
| skipping to change at page 47, line 29 ¶ | skipping to change at page 51, line 29 ¶ | |||
| Value Name: UPN | Value Name: UPN | |||
| Purpose: This value type is used to identify values that contain user | Purpose: This value type is used to identify values that contain user | |||
| principal name of CU or group of CU. | principal name of CU or group of CU. | |||
| Formal Definition: The value type is defined by the following | Formal Definition: The value type is defined by the following | |||
| notation: | notation: | |||
| ; | ; | |||
| upn = "@" | upn = "@" | |||
| / [ dot-atom-text ] "@" dot-atom-text | / [ dot-atom-text ] "@" dot-atom-text | |||
| ; | ; | |||
| ; dot-atom-text is defined in RFC 2822 | ; dot-atom-text is defined in RFC 2822 | |||
| ; | ; | |||
| ; | ; | |||
| dot-atom-text = ; As defined in [iCAL] | dot-atom-text = ; As defined in [iCAL] | |||
| Description: This data type is an identifier that denotes a CU or a | Description: This data type is an identifier that denotes a CU or a | |||
| group of CU. A UPN is a RFC 2822 compliant email address, with | group of CU. A UPN is a RFC 2822 compliant email address, with | |||
| exceptions listed below, and in most cases it is deliverable to the | 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 | CU. In some cases it is identical to the CU's well known email | |||
| address. A CU's UPN MUST never be an e-mail address that is | address. A CU's UPN MUST never be an e-mail address that is | |||
| deliverable to a different person. And there is no requirement that | deliverable to a different person. And there is no requirement that | |||
| skipping to change at page 49, line 6 ¶ | skipping to change at page 53, line 6 ¶ | |||
| Value Name: UPN-FILTER | Value Name: UPN-FILTER | |||
| Purpose: This value type is used to identify values that contain a | Purpose: This value type is used to identify values that contain a | |||
| user principal name filter. | user principal name filter. | |||
| Formal Definition: The value type is defined by the following | Formal Definition: The value type is defined by the following | |||
| notation: | notation: | |||
| ; | ; | |||
| ; NOTE: "CAL-OWNERS(cal-address)" | ; NOTE: "CAL-OWNERS(cal-address)" | |||
| ; and "NOT CAL-OWNERS(cal-address)" | ; and "NOT CAL-OWNERS(cal-address)" | |||
| ; are both NOT allowed below. | ; are both NOT allowed below. | |||
| ; | ; | |||
| upn-filter = "CAL-OWNERS()" / | upn-filter = "CAL-OWNERS()" / | |||
| "NOT CAL-OWNERS()" / | "NOT CAL-OWNERS()" / | |||
| "*" / | "*" / | |||
| [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text ) | [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text ) | |||
| ; | ; | |||
| ; dot-atom-text is defined in RFC 2822 | ; dot-atom-text is defined in RFC 2822 | |||
| Description: The value is used to match user principal names (UPNs). | Description: The value is used to match user principal names (UPNs). | |||
| For "CAL-OWNERS()" and "NOT CAL-OWNERS()", see Section 8.24. | For "CAL-OWNERS()" and "NOT CAL-OWNERS()", see Section 8.24. | |||
| * Matches all UPNs. | * Matches all UPNs. | |||
| @ Matches the UPN of anonymous CUs | @ Matches the UPN of anonymous CUs | |||
| belonging to the null realm | belonging to the null realm | |||
| @* Matches the UPN of anonymous CUs | @* Matches the UPN of anonymous CUs | |||
| skipping to change at page 53, line 14 ¶ | skipping to change at page 57, line 14 ¶ | |||
| id-param = ";" "ID" "=" unique-id | id-param = ";" "ID" "=" unique-id | |||
| ; The text value supplied is a unique value | ; The text value supplied is a unique value | |||
| ; shared between the CUA and CS to uniquely | ; shared between the CUA and CS to uniquely | |||
| ; identify the instance of command in the | ; identify the instance of command in the | |||
| ; the current CUA session. The value has | ; the current CUA session. The value has | |||
| ; no meaning to other CUAs or other sessions. | ; no meaning to other CUAs or other sessions. | |||
| ; | ; | |||
| unique-id = ; text | unique-id = ; text | |||
| ; | ; | |||
| text = ; As defined in [iCAL]. | text = ; As defined in [iCAL]. | |||
| Example: The following is an example of this parameter component: | Example: The following is an example of this parameter component: | |||
| CMD;UD=some-unique-value:CREATE | CMD;UD=some-unique-value:CREATE | |||
| 7.4 LATENCY Parameter | 7.4 LATENCY Parameter | |||
| Parameter Name: LATENCY | Parameter Name: LATENCY | |||
| Purpose: This parameter indicates time in seconds for when a timeout | Purpose: This parameter indicates time in seconds for when a timeout | |||
| skipping to change at page 61, line 21 ¶ | skipping to change at page 65, line 21 ¶ | |||
| Value Type: TEXT | Value Type: TEXT | |||
| Property Parameters: Non-standard property parameters can be | Property Parameters: Non-standard property parameters can be | |||
| specified on this property. | specified on this property. | |||
| Conformance: The property can be specified in a "VREPLY" component | Conformance: The property can be specified in a "VREPLY" component | |||
| that is sent in response to a "GET-CAPABILITY" command. | that is sent in response to a "GET-CAPABILITY" command. | |||
| Description: The value is one from a list of "CAR-NONE", "CAR-MIN", | Description: The value is one from a list of "CAR-NONE", "CAR-MIN", | |||
| or "CAR-FULL-1". If "CAR-FULL-1" is supplied then "CAR-MIN" is also | or "CAR-FULL-1". If "CAR-FULL-1" is supplied then "CAR-MIN" is also | |||
| available. A "CAR-MIN" implementation only supported the | available. A "CAR-MIN" implementation only supported the "DEFAULT- | |||
| "DEFAULT-VCARS" property values listed in the "VCALSTORE" component | VCARS" property values listed in the "VCALSTORE" component and a | |||
| and a "CAR-MIN" implementation does not support the creation or | "CAR-MIN" implementation does not support the creation or | |||
| modification of "VCAR" components from the CUA. | modification of "VCAR" components from the CUA. | |||
| Formal Definition: The property is defined by the following notation: | Formal Definition: The property is defined by the following notation: | |||
| car-level = "CAR-LEVEL" ":" other-params ":" car-level-values | car-level = "CAR-LEVEL" ":" other-params ":" car-level-values | |||
| ; | ; | |||
| car-level-values = ( "CAR-NONE" / "CAR-MIN" / "CAR-FULL-1" | car-level-values = ( "CAR-NONE" / "CAR-MIN" / "CAR-FULL-1" | |||
| / other-levels ) | / other-levels ) | |||
| ; | ; | |||
| other-levels = ; Any name published in an RFC for a "CAR-LEVEL" | other-levels = ; Any name published in an RFC for a "CAR-LEVEL" | |||
| skipping to change at page 76, line 12 ¶ | skipping to change at page 80, line 12 ¶ | |||
| Purpose: Specifies the query for the component. | Purpose: Specifies the query for the component. | |||
| Value Type: CAL-QUERY | Value Type: CAL-QUERY | |||
| Property Parameters: Non-standard property parameters can be | Property Parameters: Non-standard property parameters can be | |||
| specified on this property. | specified on this property. | |||
| Conformance: This property can be specified in "VQUERY" components. | Conformance: This property can be specified in "VQUERY" components. | |||
| Description: A "QUERY" is used to specify the "CAL-QUERY" (Section | Description: A "QUERY" is used to specify the "CAL-QUERY" | |||
| 6.1.1 for the query. | (Section 6.1.1 for the query. | |||
| Formal Definition: The property is defined by the following notation: | Formal Definition: The property is defined by the following notation: | |||
| query = "QUERY" other-params ":" cal-query CRLF | query = "QUERY" other-params ":" cal-query CRLF | |||
| Example: The following is an example of this property: | Example: The following is an example of this property: | |||
| QUERY:SELECT * FROM VEVENT | QUERY:SELECT * FROM VEVENT | |||
| 8.27 QUERYID property | 8.27 QUERYID property | |||
| skipping to change at page 81, line 36 ¶ | skipping to change at page 85, line 36 ¶ | |||
| Property Parameters: Non-standard property parameters can be | Property Parameters: Non-standard property parameters can be | |||
| specified on this property. | specified on this property. | |||
| Conformance: This property can be specified in a "VREPLY" component | Conformance: This property can be specified in a "VREPLY" component | |||
| in response to a "GET-CAPABILITY" command. | in response to a "GET-CAPABILITY" command. | |||
| Description: If the value is "TRUE" then the endpoint expands | Description: If the value is "TRUE" then the endpoint expands | |||
| recurrence rules and then stores the results into the CS. If this is | recurrence rules and then stores the results into the CS. If this is | |||
| "TRUE" then the "RECUR-LIMIT" property is significant because an | "TRUE" then the "RECUR-LIMIT" property is significant because an | |||
| infinitely recurring appointment will be stored no more than | infinitely recurring appointment will be stored no more than "RECUR- | |||
| "RECUR-LIMIT" property values into the CS and all other instances | LIMIT" property values into the CS and all other instances will be | |||
| will be lost. | lost. | |||
| Formal Definition: The property is specified by the following | Formal Definition: The property is specified by the following | |||
| notation: | notation: | |||
| stores-expanded = "STORES-EXPANDED" other-params ":" boolean CRLF | stores-expanded = "STORES-EXPANDED" other-params ":" boolean CRLF | |||
| The following is an example of this property: | The following is an example of this property: | |||
| STORES-EXPANDED:TRUE | STORES-EXPANDED:TRUE | |||
| STORES-EXPANDED:FALSE | STORES-EXPANDED:FALSE | |||
| skipping to change at page 87, line 16 ¶ | skipping to change at page 91, line 16 ¶ | |||
| following table and ABNF notation. The creation of a "VCALSTORE" | following table and ABNF notation. The creation of a "VCALSTORE" | |||
| component is an administrative task and not part of the CAP protocol. | component is an administrative task and not part of the CAP protocol. | |||
| The following are notes to some of the properties in the "VCALSTORE" | The following are notes to some of the properties in the "VCALSTORE" | |||
| component. | component. | |||
| CALSCALE - A comma separated list of CALSCALEs supported by this CS. | CALSCALE - A comma separated list of CALSCALEs supported by this CS. | |||
| All "VAGENDA" component calendar CALSCALE properties MUST BE from | All "VAGENDA" component calendar CALSCALE properties MUST BE from | |||
| this list. This list MUST contain at least "GREGORIAN". The | this list. This list MUST contain at least "GREGORIAN". The | |||
| default for newly created "VAGENDA" components is the first entry. | default for newly created "VAGENDA" components is the first entry. | |||
| RELATED-TO - This is a multiple instance property. There must be a | RELATED-TO - This is a multiple instance property. There must be a | |||
| "RELATED-TO" property MUST for each of the "VAGENDA" components | "RELATED-TO" property MUST for each of the "VAGENDA" components | |||
| contained in the "VCALSTORE" component each with the "RELTYPE" | contained in the "VCALSTORE" component each with the "RELTYPE" | |||
| parameter value set to "CHILD". Other "RELATED-TO" properties may | parameter value set to "CHILD". Other "RELATED-TO" properties may | |||
| be included. | be included. | |||
| CREATED - The timestamp of the CS creation time. This is a READ | CREATED - The timestamp of the CS creation time. This is a READ | |||
| ONLY property. | ONLY property. | |||
| CSID - The CSID of this calendar store. MUST NOT be empty. How | CSID - The CSID of this calendar store. MUST NOT be empty. How | |||
| this property is set in the VCALSTORE is an administrative or | this property is set in the VCALSTORE is an administrative or | |||
| implementation specific issue and is not covered in CAP. This is | implementation specific issue and is not covered in CAP. This is | |||
| a READ ONLY property. A suggested value is the fully qualified | a READ ONLY property. A suggested value is the fully qualified | |||
| host name or a fully qualified virtual host name supported by the | host name or a fully qualified virtual host name supported by the | |||
| system. | system. | |||
| LAST-MODIFIED - The timestamp when the Properties of the "VCALSTORE" | LAST-MODIFIED - The timestamp when the Properties of the "VCALSTORE" | |||
| component were last updated or calendars were created or deleted. | component were last updated or calendars were created or deleted. | |||
| This is a READ ONLY PROPERTY. | This is a READ ONLY PROPERTY. | |||
| calstorec = "BEGIN" ":" "VCALSTORE" CRLF | calstorec = "BEGIN" ":" "VCALSTORE" CRLF | |||
| calstoreprop | calstoreprop | |||
| *(vagendac) | *(vagendac) | |||
| "END" ":" "VCALSTORE" CRLF | "END" ":" "VCALSTORE" CRLF | |||
| ; | ; | |||
| calstoreprop = *( | calstoreprop = *( | |||
| ; the following MUST occur exactly once | ; the following MUST occur exactly once | |||
| ; | ; | |||
| allow-conflict / calscale / calmaster | allow-conflict / calscale / calmaster | |||
| / created / csid / default-charset | / created / csid / default-charset | |||
| / default-locale / default-vcars | / default-locale / default-vcars | |||
| / default-tzid / last-mod / maxdate / mindate | / default-tzid / last-mod / maxdate / mindate | |||
| ; | ; | |||
| ; the following are optional, | ; the following are optional, | |||
| skipping to change at page 89, line 43 ¶ | skipping to change at page 94, line 16 ¶ | |||
| BEGIN:VCAR | BEGIN:VCAR | |||
| CARID:ViewStartEnd2 | CARID:ViewStartEnd2 | |||
| NAME:View Start and End Times 2 | NAME:View Start and End Times 2 | |||
| BEGIN:VRIGHT | BEGIN:VRIGHT | |||
| GRANT:* | GRANT:* | |||
| PERMISSION:SEARCH | PERMISSION:SEARCH | |||
| SCOPE:SELECT DTSTART,DTEND FROM VEVENT | SCOPE:SELECT DTSTART,DTEND FROM VEVENT | |||
| END:VRIGHT | END:VRIGHT | |||
| END:VCAR | END:VCAR | |||
| In these examples, full calendar access rights are given to the | In these examples, full calendar access rights are given to the CAL- | |||
| CAL-OWNERS(), and a hypothetical administrator is given access rights | OWNERS(), and a hypothetical administrator is given access rights to | |||
| to specify calendar access rights. If no other rights are specified, | specify calendar access rights. If no other rights are specified, | |||
| only these two UPNs can specify calendar access rights: | only these two UPNs can specify calendar access rights: | |||
| BEGIN:VCAR | BEGIN:VCAR | |||
| CARID:some-id-3 | CARID:some-id-3 | |||
| NAME:Only OWNER or ADMIN Settable VCARs | NAME:Only OWNER or ADMIN Settable VCARs | |||
| BEGIN:VRIGHT | BEGIN:VRIGHT | |||
| GRANT:CAL-OWNERS() | GRANT:CAL-OWNERS() | |||
| PERMISSION:* | PERMISSION:* | |||
| SCOPE:SELECT * FROM VAGENDA | SCOPE:SELECT * FROM VAGENDA | |||
| END:VRIGHT | END:VRIGHT | |||
| skipping to change at page 94, line 50 ¶ | skipping to change at page 98, line 50 ¶ | |||
| / move-cmd | / move-cmd | |||
| / reply-cmd | / reply-cmd | |||
| / search-cmd | / search-cmd | |||
| / set-locale-cmd | / set-locale-cmd | |||
| / iana-cmd | / iana-cmd | |||
| / x-cmd | / x-cmd | |||
| ) CRLF | ) CRLF | |||
| ; | ; | |||
| option-value = "OPTION" "=" paramtext | option-value = "OPTION" "=" paramtext | |||
| ; | ; | |||
| paramtext ; As defined in [iCAL] | paramtext ; As defined in [iCAL] | |||
| Calendaring commands allow a CUA to directly manipulate a calendar. | Calendaring commands allow a CUA to directly manipulate a calendar. | |||
| Calendar access rights can be granted or denied for any commands. | Calendar access rights can be granted or denied for any commands. | |||
| 10.1.1 Bounded Latency | 10.1.1 Bounded Latency | |||
| A CAP command can have an associated maximum latency time by | A CAP command can have an associated maximum latency time by | |||
| specifying the "LATENCY" parameter. If the command is unable to be | specifying the "LATENCY" parameter. If the command is unable to be | |||
| completed in the specified amount of time (as specified by the | completed in the specified amount of time (as specified by the | |||
| "LATENCY" parameter value with an "ACTION" parameter set to the "ASK" | "LATENCY" parameter value with an "ACTION" parameter set to the "ASK" | |||
| skipping to change at page 98, line 9 ¶ | skipping to change at page 102, line 9 ¶ | |||
| only in process command be aborted. Latency MUST not be supplied | only in process command be aborted. Latency MUST not be supplied | |||
| with the "ABORT" command. | with the "ABORT" command. | |||
| Formal Definition: An "ABORT" command is defined by the following | Formal Definition: An "ABORT" command is defined by the following | |||
| notation: | notation: | |||
| abort-cmd = abortparam ":" "ABORT" | abort-cmd = abortparam ":" "ABORT" | |||
| ; | ; | |||
| abortparam = *( | abortparam = *( | |||
| ; | ; | |||
| ; the following are optional, | ; the following are optional, | |||
| ; but MUST NOT occur more than once | ; but MUST NOT occur more than once | |||
| ; | ; | |||
| id-param | id-param | |||
| / localize-param | / localize-param | |||
| ; | ; | |||
| ; the following is optional, | ; the following is optional, | |||
| ; and MAY occur more than once | ; and MAY occur more than once | |||
| ; | ; | |||
| / other-params | / other-params | |||
| ) | ) | |||
| The REPLY of any "ABORT" command is: | The REPLY of any "ABORT" command is: | |||
| abort-reply = "BEGIN" ":" "VCALENDAR" CRLF | abort-reply = "BEGIN" ":" "VCALENDAR" CRLF | |||
| calprops | calprops | |||
| abort-vreply | abort-vreply | |||
| "END" ":" "VCALENDAR" CRLF | "END" ":" "VCALENDAR" CRLF | |||
| ; | ; | |||
| abort-vreply = "BEGIN" ":" "VREPLY" CRLF | abort-vreply = "BEGIN" ":" "VREPLY" CRLF | |||
| rstatus | rstatus | |||
| other-props | other-props | |||
| "END" ":" "VREPLY" CRLF | "END" ":" "VREPLY" CRLF | |||
| 10.3 CONTINUE Command | 10.3 CONTINUE Command | |||
| CMD: CONTINUE | CMD: CONTINUE | |||
| Purpose: The "CONTINUE" command is only sent after a "TIMEOUT" | Purpose: The "CONTINUE" command is only sent after a "TIMEOUT" | |||
| command has been received to inform the other end of the session to | command has been received to inform the other end of the session to | |||
| resume working on a command. | resume working on a command. | |||
| Formal Definition: A "CONTINUE" command is defined by the following | Formal Definition: A "CONTINUE" command is defined by the following | |||
| skipping to change at page 106, line 37 ¶ | skipping to change at page 110, line 43 ¶ | |||
| / other-params | / other-params | |||
| ) | ) | |||
| The "DELETE" command is used to delete calendars or components. The | The "DELETE" command is used to delete calendars or components. The | |||
| included "VQUERY" component(s) specifies the container(s) to delete. | included "VQUERY" component(s) specifies the container(s) to delete. | |||
| If a component is to be marked for delete and not physically removed, | If a component is to be marked for delete and not physically removed, | |||
| then include the "OPTIONS" parameter with its value set to the "MARK" | then include the "OPTIONS" parameter with its value set to the "MARK" | |||
| value in order to alter its state to "DELETED". | value in order to alter its state to "DELETED". | |||
| When components are deleted, only the top most component | When components are deleted, only the top most component "REQUEST- | |||
| "REQUEST-STATUS" properties are returned. No "REQUEST-STATUS" | STATUS" properties are returned. No "REQUEST-STATUS" properties are | |||
| properties are returned for components inside of the selected | returned for components inside of the selected components. There | |||
| components. There MUST BE one "VREPLY" component returned for each | MUST BE one "VREPLY" component returned for each object that is | |||
| object that is deleted or marked for delete. Note that if no | deleted or marked for delete. Note that if no "VREPLY" components | |||
| "VREPLY" components are returned then nothing matched and nothing was | are returned then nothing matched and nothing was deleted. | |||
| deleted. | ||||
| Restriction Table for the "REPLY" command for any "DELETE" command. | Restriction Table for the "REPLY" command for any "DELETE" command. | |||
| delete-reply = "BEGIN" ":" "VCALENDAR" CRLF | delete-reply = "BEGIN" ":" "VCALENDAR" CRLF | |||
| calprops ; MUST include 'reply-cmd' | calprops ; MUST include 'reply-cmd' | |||
| *(delete-vreply) | *(delete-vreply) | |||
| "END" ":" "VCALENDAR" CRLF | "END" ":" "VCALENDAR" CRLF | |||
| ; | ; | |||
| delete-vreply = "BEGIN" ":" "VREPLY" CRLF | delete-vreply = "BEGIN" ":" "VREPLY" CRLF | |||
| deleted-id | deleted-id | |||
| rstatus | rstatus | |||
| "END" ":" "VREPLY" CRLF | "END" ":" "VREPLY" CRLF | |||
| ; | ; | |||
| ; Where the id is appropriate for the | ; Where the id is appropriate for the | |||
| ; type of object deleted: | ; type of object deleted: | |||
| ; | ; | |||
| ; VAGENDA = relcalid | ; VAGENDA = relcalid | |||
| ; VCAR = carid | ; VCAR = carid | |||
| skipping to change at page 117, line 30 ¶ | skipping to change at page 121, line 30 ¶ | |||
| Where "XXX" above is a named component type (VEVENT, VTODO, ...). | Where "XXX" above is a named component type (VEVENT, VTODO, ...). | |||
| Both the old and new components MUST BE of the same type. | Both the old and new components MUST BE of the same type. | |||
| The old-values is a component and the contents of that component are | The old-values is a component and the contents of that component are | |||
| going to change and may contain information that helps uniquely | going to change and may contain information that helps uniquely | |||
| identify the original component (SEQUENCE in the example below). If | identify the original component (SEQUENCE in the example below). If | |||
| the CS can not find a component that matches the QUERY and does not | the CS can not find a component that matches the QUERY and does not | |||
| have at least all of the OLD-VALUES, then a 6.1 error is returned. | have at least all of the OLD-VALUES, then a 6.1 error is returned. | |||
| The new-values is a component of the same type as old-values and | The new-values is a component of the same type as old-values and new- | |||
| new-values contains the new data for each selected component. Any | values contains the new data for each selected component. Any data | |||
| data that is in old-values and not in new-values is deleted from the | that is in old-values and not in new-values is deleted from the | |||
| selected component. Any values in new-values that was not in | selected component. Any values in new-values that was not in old- | |||
| old-values is added to the component. | values is added to the component. | |||
| In this example the "VEVENT" component with a "UID" property value of | In this example the "VEVENT" component with a "UID" property value of | |||
| 'unique-58' has; the "LOCATION" property and "LAST-MODIFIED" property | 'unique-58' has; the "LOCATION" property and "LAST-MODIFIED" property | |||
| changed, the "VALARM" component with the "SEQUENCE" property with a | changed, the "VALARM" component with the "SEQUENCE" property with a | |||
| value of "3" has its "TRIGGER" property disabled, the "X-LOCAL" | value of "3" has its "TRIGGER" property disabled, the "X-LOCAL" | |||
| property is removed from the "VEVENT" component, and a "COMMENT" | property is removed from the "VEVENT" component, and a "COMMENT" | |||
| property is added. | property is added. | |||
| Because "SEQUENCE" property is used to locate the "VALARM" component | Because "SEQUENCE" property is used to locate the "VALARM" component | |||
| in this example, both the old-values and the new-values contain the | in this example, both the old-values and the new-values contain the | |||
| skipping to change at page 118, line 51 ¶ | skipping to change at page 122, line 51 ¶ | |||
| "SEQUENCE" property value did not change so it was not effected. The | "SEQUENCE" property value did not change so it was not effected. The | |||
| "COMMENT" property was added. | "COMMENT" property was added. | |||
| When it comes to inline ATTACHMENTs, the CUA only needs to uniquely | When it comes to inline ATTACHMENTs, the CUA only needs to uniquely | |||
| identify the contents of the ATTACHMENT value in the old-values in | identify the contents of the ATTACHMENT value in the old-values in | |||
| order to delete them. When the CS compares the attachment data it is | order to delete them. When the CS compares the attachment data it is | |||
| compared in its binary form. The ATTACHMENT value supplied by the | compared in its binary form. The ATTACHMENT value supplied by the | |||
| CUA MUST BE valid encoded information. | CUA MUST BE valid encoded information. | |||
| For example, to delete the same huge inline attachment from every | For example, to delete the same huge inline attachment from every | |||
| VEVENT in 'my-cal' that has an "ATTACH" property value with the | VEVENT in 'my-cal' that has an "ATTACH" property value with the old- | |||
| old-values: | values: | |||
| BEGIN:VCALENDAR | BEGIN:VCALENDAR | |||
| VERSION:2.0 | VERSION:2.0 | |||
| PRODID:-//someone's prodid | PRODID:-//someone's prodid | |||
| TARGET:my-cal | TARGET:my-cal | |||
| CMD:MODIFY | CMD:MODIFY | |||
| BEGIN:VQUERY | BEGIN:VQUERY | |||
| QUERY:SELECT ATTACH FROM VEVENT | QUERY:SELECT ATTACH FROM VEVENT | |||
| END:VQUERY | END:VQUERY | |||
| BEGIN:VEVENT | BEGIN:VEVENT | |||
| skipping to change at page 119, line 30 ¶ | skipping to change at page 123, line 30 ¶ | |||
| BEGIN:VEVENT | BEGIN:VEVENT | |||
| END:VEVENT | END:VEVENT | |||
| END:VCALENDAR | END:VCALENDAR | |||
| Above the new-values is empty, so everything in the old-values is | Above the new-values is empty, so everything in the old-values is | |||
| deleted. | deleted. | |||
| Furthermore, the following additional restrictions apply: | Furthermore, the following additional restrictions apply: | |||
| 1. One can not change the "UID" property of a component. | 1. One can not change the "UID" property of a component. | |||
| 2. If a contained component is changed inside of a selected | 2. If a contained component is changed inside of a selected | |||
| component, and that contained component has multiple instances, | component, and that contained component has multiple instances, | |||
| then old-values MUST contain information that uniquely identifies | then old-values MUST contain information that uniquely identifies | |||
| the instance or instances that are changing. It is valid to | the instance or instances that are changing. It is valid to | |||
| change more than one. As all contained components that match | change more than one. As all contained components that match | |||
| old-values will be modified. In the first modify example above, | old-values will be modified. In the first modify example above, | |||
| if "SEQUENCE" properties were to be deleted from both the | if "SEQUENCE" properties were to be deleted from both the old- | |||
| old-values and new-values, then all "TRIGGER" properties that | values and new-values, then all "TRIGGER" properties that matched | |||
| matched the old-values in all "VALARM" components in the selected | the old-values in all "VALARM" components in the selected | |||
| "VEVENT" components would be disabled. | "VEVENT" components would be disabled. | |||
| 3. The result of the modify MUST BE a valid iCalendar object. | 3. The result of the modify MUST BE a valid iCalendar object. | |||
| Response: | Response: | |||
| A "VCALENDAR" component is returned with one ore more | A "VCALENDAR" component is returned with one ore more "REQUEST- | |||
| "REQUEST-STATUS" property values. | STATUS" property values. | |||
| If any error occurred: | If any error occurred: | |||
| No component will be changed at all. That is, it will appear just | No component will be changed at all. That is, it will appear just | |||
| as it was prior to the modify and the CAP server SHOULD return a | as it was prior to the modify and the CAP server SHOULD return a | |||
| "REQUEST-STATUS" property for each error that occurred. | "REQUEST-STATUS" property for each error that occurred. | |||
| There MUST BE at least one error reported. | There MUST BE at least one error reported. | |||
| If multiple components are selected, then what uniquely identified | If multiple components are selected, then what uniquely identified | |||
| the component MUST BE returned (UID, QUERYID, ...) if the component | the component MUST BE returned (UID, QUERYID, ...) if the component | |||
| contains a unique identifier. If not, sufficient information to | contains a unique identifier. If not, sufficient information to | |||
| uniquely identify the modified components MUST BE returned in the | uniquely identify the modified components MUST BE returned in the | |||
| reply. | reply. | |||
| S: Content-Type: text/calendar | S: Content-Type: text/calendar | |||
| S: | S: | |||
| skipping to change at page 124, line 9 ¶ | skipping to change at page 128, line 9 ¶ | |||
| A CS MUST send a "REPLY" command to a CUA for any command a CUA MAY | A CS MUST send a "REPLY" command to a CUA for any command a CUA MAY | |||
| send to the CS. The "REPLY" command MUST BE implemented by all CSs. | send to the CS. The "REPLY" command MUST BE implemented by all CSs. | |||
| Formal Definition: A "REPLY" command is defined by the following | Formal Definition: A "REPLY" command is defined by the following | |||
| notation: | notation: | |||
| reply-cmd = replyparam ":" "REPLY" | reply-cmd = replyparam ":" "REPLY" | |||
| ; | ; | |||
| replyparam = *( | replyparam = *( | |||
| ; | ; | |||
| ; The 'id' parameter value MUST BE exactly the | ; The 'id' parameter value MUST BE exactly the | |||
| ; same as the value sent in the original | ; same as the value sent in the original | |||
| ; CMD property. If the original CMD did | ; CMD property. If the original CMD did | |||
| ; not have an 'id' parameter, then the 'id' | ; not have an 'id' parameter, then the 'id' | |||
| ; MUST NOT be supplied in the REPLY. | ; MUST NOT be supplied in the REPLY. | |||
| ; | ; | |||
| id-param | id-param | |||
| ; | ; | |||
| ; the following is optional, | ; the following is optional, | |||
| ; and MAY occur more than once | ; and MAY occur more than once | |||
| ; | ; | |||
| skipping to change at page 135, line 27 ¶ | skipping to change at page 139, line 27 ¶ | |||
| In either case, all iCal objects transmitted together must have the | In either case, all iCal objects transmitted together must have the | |||
| same TARGET property. | same TARGET property. | |||
| The sending of multipart MIME entities over BEEP is not permitted for | The sending of multipart MIME entities over BEEP is not permitted for | |||
| CAP unless the other endpoint has indicated its ability to accept | CAP unless the other endpoint has indicated its ability to accept | |||
| them via the appropriate CAPABILITY. | them via the appropriate CAPABILITY. | |||
| Messages in negative replies: | Messages in negative replies: | |||
| Any valid "text/calendar" MIME object that contains CAP | Any valid "text/calendar" MIME object that contains CAP "REQUEST- | |||
| "REQUEST-STATUS" property and a CAP "CMD" property with a property | STATUS" property and a CAP "CMD" property with a property value of | |||
| value of "REPLY". And where the CS has determined the requested | "REPLY". And where the CS has determined the requested operation to | |||
| operation to be a fatal error. And when the CS has performed NO | be a fatal error. And when the CS has performed NO operation that | |||
| operation that effected the contents of any part of the CS or any | effected the contents of any part of the CS or any calendar | |||
| calendar controlled by the CS. | controlled by the CS. | |||
| Messages in one-to-many exchanges: | Messages in one-to-many exchanges: | |||
| After the initial message then a BEEP "MSG" may contain one or more | After the initial message then a BEEP "MSG" may contain one or more | |||
| MIME objects at least one of which MUST be "text/calendar" and each | MIME objects at least one of which MUST be "text/calendar" and each | |||
| "text/calendar" MIME object MUST contain a CAP "CMD" property. | "text/calendar" MIME object MUST contain a CAP "CMD" property. | |||
| The BEEP "MSG" messages can only contain MIME "multipart" MIME | The BEEP "MSG" messages can only contain MIME "multipart" MIME | |||
| objects if the other endpoint has received a CAP "CAPABILITY" | objects if the other endpoint has received a CAP "CAPABILITY" | |||
| indicating the other endpoint supports multipart MIME objects. This | indicating the other endpoint supports multipart MIME objects. This | |||
| skipping to change at page 139, line 11 ¶ | skipping to change at page 143, line 11 ¶ | |||
| included during channel start (see RFC3080, section 2.3.1.2) as BEEP | included during channel start (see RFC3080, section 2.3.1.2) as BEEP | |||
| allows for the start command to include the initial data transfer. | allows for the start command to include the initial data transfer. | |||
| This reduces the number of round trips to initiate a CAP session. | This reduces the number of round trips to initiate a CAP session. | |||
| 13. IANA Considerations | 13. IANA Considerations | |||
| This memo defines IANA registered extensions to the attributes | This memo defines IANA registered extensions to the attributes | |||
| defined by iCalendar, as defined in [iCAL], and [iTIP]. | defined by iCalendar, as defined in [iCAL], and [iTIP]. | |||
| IANA registration proposals for iCalendar and [iTIP] are to be mailed | IANA registration proposals for iCalendar and [iTIP] are to be mailed | |||
| to the registration agent for the "text/calendar" [MIME] | to the registration agent for the "text/calendar" [MIME] content- | |||
| content-type, <MAILTO: ietf-calendar@imc.org> using the format | type, <MAILTO: ietf-calendar@imc.org> using the format defined in | |||
| defined in section 7 of [iCAL]. | section 7 of [iCAL]. | |||
| If the IESG approves this memo for publication, then the IANA | If the IESG approves this memo for publication, then the IANA | |||
| registers the profile specified in Section 12.1, and selects an | registers the profile specified in Section 12.1, and selects an IANA- | |||
| IANA-specific URI, e.g., http://iana.org/beep/cap/1.0. | specific URI, e.g., http://iana.org/beep/cap/1.0. | |||
| 14. Security Considerations | 14. Security Considerations | |||
| Access rights should be granted cautiously. Without careful planning | Access rights should be granted cautiously. Without careful planning | |||
| it is possible to open up access to a greater degree than desired. | it is possible to open up access to a greater degree than desired. | |||
| The "IDENTIFY" command should be carefully implemented. If done | The "IDENTIFY" command should be carefully implemented. If done | |||
| incorrectly UPNs may gain access as other unintended UPSs. The | incorrectly UPNs may gain access as other unintended UPSs. The | |||
| "IDENTIFY" command may not chain, that is the identity is always | "IDENTIFY" command may not chain, that is the identity is always | |||
| validated against the original UPN and not the new UPN. | validated against the original UPN and not the new UPN. | |||
| In addition, since CAP is a profile of [BEEP], consult [BEEP]'s | In addition, since CAP is a profile of [BEEP], consult [BEEP]'s | |||
| Section 9 for a discussion of BEEP-specific security issues. | Section 9 for a discussion of BEEP-specific security issues. | |||
| There are risks of allowing anonymous UPNs to deposit REQUEST and | There are risks of allowing anonymous UPNs to deposit REQUEST and | |||
| REFRESH objects. (calendar spam and deninal of service for example) | REFRESH objects. (calendar spam and deninal of service for example) | |||
| So implementations should consider methods to restrict anonymous | So implementations should consider methods to restrict anonymous | |||
| requests to within acceptable usages. | requests to within acceptable usages. | |||
| CS implementations might consider automatically creating VCARs that | CS implementations might consider automatically creating VCARs that | |||
| allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY | allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY | |||
| objects for those UIDs if they otherwise do not have access rather | objects for those UIDs if they otherwise do not have access rather | |||
| then opening up world access. And they may consider also allowing | then opening up world access. And they may consider also allowing | |||
| COUNTER objects for those ATTENDEEs. | COUNTER objects for those ATTENDEEs. | |||
| When an object is booked by a CUA the CS reply may wish to include | When an object is booked by a CUA the CS reply may wish to include | |||
| skipping to change at page 140, line 38 ¶ | skipping to change at page 144, line 38 ¶ | |||
| When an object is booked by a CUA the CS reply may wish to include | When an object is booked by a CUA the CS reply may wish to include | |||
| warning messages to the CUA for ATTENDEEs that have CAP urls that do | warning messages to the CUA for ATTENDEEs that have CAP urls that do | |||
| not have local UPNs as those ATTENDEES may be unable to REPLY or | not have local UPNs as those ATTENDEES may be unable to REPLY or | |||
| REFRESH. Some CSs may wish this to be an error. | REFRESH. Some CSs may wish this to be an error. | |||
| Although service provisioning is a policy matter, at a minimum, all | Although service provisioning is a policy matter, at a minimum, all | |||
| implementations must provide the following tuning profiles: | implementations must provide the following tuning profiles: | |||
| for authentication: http://iana.org/beep/SASL/DIGEST-MD5 | for authentication: http://iana.org/beep/SASL/DIGEST-MD5 | |||
| for confidentiality: http://iana.org/beep/TLS (using the | for confidentiality: http://iana.org/beep/TLS (using the | |||
| TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) | TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) | |||
| for both: http://iana.org/beep/TLS (using the | for both: http://iana.org/beep/TLS (using the | |||
| TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side | TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side | |||
| certificates) | certificates) | |||
| Authors' Addresses | Authors' Addresses | |||
| Doug Royer | Doug Royer | |||
| IntelliCal, LLC | IntelliCal, LLC | |||
| 267 Kentlands Blvd. #3041 | 267 Kentlands Blvd. #3041 | |||
| Gaithersburg, MD 20878 | Gaithersburg, MD 20878 | |||
| US | US | |||
| Phone: +1-866-594-8574 | Phone: +1-866-594-8574 | |||
| Fax: +1-866-594-8574 | Fax: +1-866-594-8574 | |||
| EMail: Doug@IntelliCal.com | Email: Doug@IntelliCal.com | |||
| URI: http://Royer.com/People/Doug | URI: http://Royer.com/People/Doug | |||
| George Babics | George Babics | |||
| Oracle | Oracle | |||
| 2000 Peel Street | 2000 Peel Street | |||
| Montreal, Quebec H3A 2W5 | Montreal, Quebec H3A 2W5 | |||
| CA | CA | |||
| Phone: +1-514-733-8500 x4201 | Phone: +1-514-733-8500 x4201 | |||
| Fax: +1-514-733-8878 | Fax: +1-514-733-8878 | |||
| EMail: George.Babics@Oracle.com | Email: George.Babics@Oracle.com | |||
| Paul Hill | Paul Hill | |||
| Massachusetts Institute of Technology | Massachusetts Institute of Technology | |||
| W92-172 | W92-172 | |||
| 77 Massachusetts Avenue | 77 Massachusetts Avenue | |||
| Cambridge, MA 02139 | Cambridge, MA 02139 | |||
| US | US | |||
| Phone: +1-617-253-0124 | Phone: +1-617-253-0124 | |||
| Fax: +1-617-258-8736 | Fax: +1-617-258-8736 | |||
| EMail: phb@mit.edu | Email: phb@mit.edu | |||
| Steve Mansour | Steve Mansour | |||
| AOL/Netscape | AOL/Netscape | |||
| 466 Ellis Road | 466 Ellis Road | |||
| Mountain View, CA 94043 | Mountain View, CA 94043 | |||
| US | US | |||
| Phone: +1-650-937-3351 | Phone: +1-650-937-3351 | |||
| EMail: sman@netscape.com | Email: sman@netscape.com | |||
| Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
| The following have individuals were major contributors in the | The following have individuals were major contributors in the | |||
| drafting and discussion of this memo and are greatly appreciated: | drafting and discussion of this memo and are greatly appreciated: | |||
| Alan Davies, Andrea Campi, Andre Courtemanche, Andrew Davison, Anil | Alan Davies, Andrea Campi, Andre Courtemanche, Andrew Davison, Anil | |||
| Srivastava, ArentJan Banck, Arnaud Quillaud, Benjamin Sonntag, | Srivastava, ArentJan Banck, Arnaud Quillaud, Benjamin Sonntag, | |||
| Bernard Desruisseaux, Bertrand Guiheneuf, Bob Mahoney, Bob Morgan, | Bernard Desruisseaux, Bertrand Guiheneuf, Bob Mahoney, Bob Morgan, | |||
| Bruce Kahn, Chris Dudding, Chris Olds, Christopher Apple, Cortlandt | Bruce Kahn, Chris Dudding, Chris Olds, Christopher Apple, Cortlandt | |||
| Winters, Craig Johnson, Cyrus Daboo, Damon Chaplin, Dan Hickman, Dan | Winters, Craig Johnson, Cyrus Daboo, Damon Chaplin, Dan Hickman, Dan | |||
| Kohn, Dan Winship, Darryl Champagne, David C. Thewlis, David Nicol, | Kohn, Dan Winship, Darryl Champagne, David C. Thewlis, David Nicol, | |||
| David Nusbaum, David West, Derik Stenerson, Eric R. Plamondon, Frank | David Nusbaum, David West, Derik Stenerson, Eric R. Plamondon, Frank | |||
| Dawson, Frank Nitsch, Gary Frederick, Gary McGath, Gilles Fortin, | Dawson, Frank Nitsch, Gary Frederick, Gary McGath, Gilles Fortin, | |||
| Graham Gilmore, Greg Barnes, Greg FitzPatrick, Harald Alvestrand, | Graham Gilmore, Greg Barnes, Greg FitzPatrick, Harald Alvestrand, | |||
| Harrie Hazewinkel, Helge Hess, Jagan Garimella, Jay Parker, Jim Ray, | Harrie Hazewinkel, Helge Hess, Jagan Garimella, Jay Parker, Jim Ray, | |||
| Jim Smith, Joerg Reichelt, John Berthels, John Smith, John Stracke, | Jim Smith, Joerg Reichelt, John Berthels, John Smith, John Stracke, | |||
| Jonathan Lennox, JP Rosevear, Karen Chu, Katie Capps Parlante, Kees | Jonathan Lennox, JP Rosevear, Karen Chu, Katie Capps Parlante, Kees | |||
| Cook, Ken Crawford, Ki Wong, Lars Eggert, Lata Kannan, Lawrence | Cook, Ken Crawford, Ki Wong, Lars Eggert, Lata Kannan, Lawrence | |||
| Greenfield, Libby Miller, Lisa Dusseault, Lyndon Nerenberg, Mark | Greenfield, Libby Miller, Lisa Dusseault, Lyndon Nerenberg, Mark | |||
| Davidson, Mark Paterson, Mark Smith, Mark Swanson, Mark Tearle, | Davidson, Mark Paterson, Mark Smith, Mark Swanson, Mark Tearle, | |||
| Marshall Rose, Martijn van Beers, Martin Jackson, Matthias Laabs, Max | Marshall Rose, Martijn van Beers, Martin Jackson, Matthias Laabs, Max | |||
| Froumentin, Micah Gorrell, Michael Fair, Mike Higginbottom, Mike | Froumentin, Micah Gorrell, Michael Fair, Mike Higginbottom, Mike | |||
| skipping to change at page 143, line 8 ¶ | skipping to change at page 147, line 8 ¶ | |||
| Preston Stephenson, Prometeo Sandino Roman Corral, Ralph Patterson, | Preston Stephenson, Prometeo Sandino Roman Corral, Ralph Patterson, | |||
| Robert Lusardi, Robert Ransdell, Rob Siemborski, Satyanarayana | Robert Lusardi, Robert Ransdell, Rob Siemborski, Satyanarayana | |||
| Vempati, Satya Vempati, Scott Hollenbeck, Seamus Garvey, Shannon | Vempati, Satya Vempati, Scott Hollenbeck, Seamus Garvey, Shannon | |||
| Clark, Shriram Vishwanathan, Steve Coya, Steve Mansour, Steve Miller, | Clark, Shriram Vishwanathan, Steve Coya, Steve Mansour, Steve Miller, | |||
| Steve Vinter, Stuart Guthrie, Suchet Singh Khalsa, Ted Hardie, Tim | Steve Vinter, Stuart Guthrie, Suchet Singh Khalsa, Ted Hardie, Tim | |||
| Hare, Timo Sirainen, Vicky Oliver, Yael Shaham-Gafni | Hare, Timo Sirainen, Vicky Oliver, Yael Shaham-Gafni | |||
| Appendix B. Bibliography | Appendix B. Bibliography | |||
| [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifications: ABNF" | [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifications: ABNF" | |||
| RFC 2234, November 1997 | RFC 2234, November 1997 | |||
| ftp://ftp.isi.edu/in-notes/rfc2234.txt | ftp://ftp.isi.edu/in-notes/rfc2234.txt | |||
| [BEEP] Rose, M., "The Block Extensible Exchange Protocol Core", | [BEEP] Rose, M., "The Block Extensible Exchange Protocol Core", | |||
| RFC 3080, March 2001 | RFC 3080, March 2001 | |||
| ftp://ftp.isi.edu/in-notes/rfc3080.txt | ftp://ftp.isi.edu/in-notes/rfc3080.txt | |||
| [BEEPTCP] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001 | [BEEPTCP] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001 | |||
| ftp://ftp.isi.edu/in-notes/rfc3081.txt | ftp://ftp.isi.edu/in-notes/rfc3081.txt | |||
| [BEEPGUIDE] Rose, M., "BEEP, The Definitive Guide", ISBN 0-596-00244-0, | [BEEPGUIDE] Rose, M., "BEEP, The Definitive Guide", ISBN 0-596-00244-0, | |||
| O'Reilly & Associates, Inc. | O'Reilly & Associates, Inc. | |||
| [CHARREG] Freed, N., Postel, J., "IANA Charset Registration Procedures", | [CHARREG] Freed, N., Postel, J., "IANA Charset Registration Procedures", | |||
| RFC 2278, January 1998, | RFC 2278, January 1998, | |||
| ftp://ftp.isi.edu/in-notes/rfc2278.txt | ftp://ftp.isi.edu/in-notes/rfc2278.txt | |||
| [CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and Languages", | [CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and Languages", | |||
| RFC 2277, January 1998, | RFC 2277, January 1998, | |||
| ftp://ftp.isi.edu/in-notes/rfc2277.txt | ftp://ftp.isi.edu/in-notes/rfc2277.txt | |||
| [GUIDE] Mahoney, B., Babics, G., Taler, A. "Guide to Internet | [GUIDE] Mahoney, B., Babics, G., Taler, A. "Guide to Internet | |||
| Calendaring", RFC 3283, June 2002, | Calendaring", RFC 3283, June 2002, | |||
| ftp://ftp.isi.edu/in-notes/rfc3283.txt | ftp://ftp.isi.edu/in-notes/rfc3283.txt | |||
| [iCAL] Dawson, F. and Stenerson, D., "Internet Calendaring and | [iCAL] Dawson, F. and Stenerson, D., "Internet Calendaring and | |||
| Scheduling Core Object Specification (iCalendar)", RFC 2445, | Scheduling Core Object Specification (iCalendar)", RFC 2445, | |||
| November 1998 ftp://ftp.isi.edu/in-notes/rfc2445.txt | November 1998 ftp://ftp.isi.edu/in-notes/rfc2445.txt | |||
| [iTIP] Silverberg, S., Mansour, S., Dawson, F. and Hopson, R., | [iTIP] Silverberg, S., Mansour, S., Dawson, F. and Hopson, R., | |||
| "iCalendar Transport-Independent Interoperability Protocol | "iCalendar Transport-Independent Interoperability Protocol | |||
| (iTIP) Events, BusyTime, To-dos and Journal Entries", | (iTIP) Events, BusyTime, To-dos and Journal Entries", | |||
| RFC 2446, November 1998 ftp://ftp.isi.edu/in-notes/rfc2446.txt | RFC 2446, November 1998 ftp://ftp.isi.edu/in-notes/rfc2446.txt | |||
| [iMIP] Dawson, F., Mansour, S. and Silverberg, "iCalendar | [iMIP] Dawson, F., Mansour, S. and Silverberg, "iCalendar | |||
| Message-Based Interoperability Protocol (iMIP)", RFC 2447, | Message-Based Interoperability Protocol (iMIP)", RFC 2447, | |||
| November 1998 ftp://ftp.isi.edu/in-notes/rfc2447.txt | November 1998 ftp://ftp.isi.edu/in-notes/rfc2447.txt | |||
| [MIME] Borenstein, N. and Freed, N., "Multipurpose Internet Mail | [MIME] Borenstein, N. and Freed, N., "Multipurpose Internet Mail | |||
| Extensions (MIME) Part One: Format of Internet Message Bodies", | Extensions (MIME) Part One: Format of Internet Message Bodies", | |||
| RFC 2045, November 1996 | RFC 2045, November 1996 | |||
| ftp://ftp.isi.edu/in-notes/rfc2045.txt | ftp://ftp.isi.edu/in-notes/rfc2045.txt | |||
| [RFCWORDS] Bradner, S., "Key words for use in RFCs to Indicate | [RFCWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", RFC 2119, BCP 14, March 1997 | Requirement Levels", RFC 2119, BCP 14, March 1997 | |||
| ftp://ftp.isi.edu/in-notes/rfc2119.txt | ftp://ftp.isi.edu/in-notes/rfc2119.txt | |||
| [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", | [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", | |||
| RFC 2222, October 1997 | RFC 2222, October 1997 | |||
| ftp://ftp.isi.edu/in-notes/rfc2222.txt | ftp://ftp.isi.edu/in-notes/rfc2222.txt | |||
| [SQL92] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, | [SQL92] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, | |||
| aka ANSI X3.135-1992, aka FiPS PUB 127-2 | aka ANSI X3.135-1992, aka FiPS PUB 127-2 | |||
| [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 | [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 | |||
| to ISO/IEC 9075: 1992, also adopted as Amendment 1 to | to ISO/IEC 9075: 1992, also adopted as Amendment 1 to | |||
| ANSI X3.135.1992 | ANSI X3.135.1992 | |||
| [URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., | [URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., Petke, R., | |||
| "Guidelines for new URL Schemes", RFC 2718, November 1999, | "Guidelines for new URL Schemes", RFC 2718, November 1999, | |||
| ftp://ftp.isi.edu/in-notes/rfc2718.txt | ftp://ftp.isi.edu/in-notes/rfc2718.txt | |||
| [URI] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform Resource | [URI] Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform Resource | |||
| Identifiers (URI): Generic Syntax", RFC 2396, August 1998 | Identifiers (URI): Generic Syntax", RFC 2396, August 1998 | |||
| ftp://ftp.isi.edu/in-notes/rfc2396.txt | ftp://ftp.isi.edu/in-notes/rfc2396.txt | |||
| [URL] Berners-Lee, T, Masinter, L. and McCahil, M., "Uniform | [URL] Berners-Lee, T, Masinter, L. and McCahil, M., "Uniform | |||
| Resource Locators (URL)", RFC 1738, December 1994 | Resource Locators (URL)", RFC 1738, December 1994 | |||
| ftp://ftp.isi.edu/in-notes/rfc1738.txt | ftp://ftp.isi.edu/in-notes/rfc1738.txt | |||
| [X509CRL] Housley, R., Ford, W., Polk, W., Solo, D. "Internet X.509 | [X509CRL] Housley, R., Ford, W., Polk, W., Solo, D. "Internet X.509 | |||
| Public Key Infrastructure, Certificate and CRL Profile", | Public Key Infrastructure, Certificate and CRL Profile", | |||
| RFC 2459, January 1999, | RFC 2459, January 1999, | |||
| ftp://ftp.isi.edu/in-notes/rfc2459.txt | ftp://ftp.isi.edu/in-notes/rfc2459.txt | |||
| Intellectual Property Statement | Intellectual Property Statement | |||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
| might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
| made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
| on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
| End of changes. 204 change blocks. | ||||
| 388 lines changed or deleted | 491 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||