draft-ietf-calsify-2446bis-07.txt   draft-ietf-calsify-2446bis-08.txt 
Network Working Group C. Daboo, Ed. Network Working Group C. Daboo, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Obsoletes: 2446 (if approved) July 14, 2008 Obsoletes: 2446 (if approved) November 3, 2008
Intended status: Standards Track Intended status: Standards Track
Expires: January 15, 2009 Expires: May 7, 2009
iCalendar Transport-Independent Interoperability Protocol (iTIP) iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-07 draft-ietf-calsify-2446bis-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 January 15, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
This document specifies a protocol using the iCalendar object This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between specification to provide scheduling interoperability between
different calendar systems. This is done without reference to a different calendaring systems. This is done without reference to a
specific transport protocol so as to allow multiple methods of specific transport protocol so as to allow multiple methods of
communication between systems. Subsequent documents will define communication between systems. Subsequent documents will define
profiles of this protocol using specific interoperable methods of profiles of this protocol using specific interoperable methods of
communications between systems. communications between systems.
iTIP complements the iCalendar object specification by adding iTIP complements the iCalendar object specification by adding
semantics for group scheduling methods commonly available in current semantics for group scheduling methods commonly available in current
calendar systems. These scheduling methods permit two or more calendaring systems. These scheduling methods permit two or more
calendar systems to perform transactions such as publish, schedule, calendaring systems to perform transactions such as publish,
reschedule, respond to scheduling requests, negotiation of changes or schedule, reschedule, respond to scheduling requests, negotiation of
cancel. changes or cancel.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5
1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 5 1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 5
1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 6 1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 6
1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Interoperability Models . . . . . . . . . . . . . . . . . . . 8 2. Interoperability Models . . . . . . . . . . . . . . . . . . . 8
2.1. Application Protocol . . . . . . . . . . . . . . . . . . 9 2.1. Application Protocol . . . . . . . . . . . . . . . . . . 9
2.1.1. Calendar Entry State . . . . . . . . . . . . . . . . 9 2.1.1. Scheduling State . . . . . . . . . . . . . . . . . . 9
2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 10 2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Acting on Behalf of other Calendar Users . . . . . . 10 2.1.3. Acting on Behalf of other Calendar Users . . . . . . 10
2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 10 2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 10
2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 11 2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 12
3. Application Protocol Elements . . . . . . . . . . . . . . . . 12 3. Application Protocol Elements . . . . . . . . . . . . . . . . 13
3.1. Common Component Restriction Tables . . . . . . . . . . . 13 3.1. Common Component Restriction Tables . . . . . . . . . . . 14
3.1.1. VCALENDAR . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. VCALENDAR . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2. VTIMEZONE . . . . . . . . . . . . . . . . . . . . . . 13 3.1.2. VTIMEZONE . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3. VALARM . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.3. VALARM . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Methods for VEVENT Calendar Components . . . . . . . . . 15 3.2. Methods for VEVENT Calendar Components . . . . . . . . . 16
3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 31 3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 33
3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 32 3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 34
3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4. Methods For VTODO Components . . . . . . . . . . . . . . 37 3.4. Methods For VTODO Components . . . . . . . . . . . . . . 39
3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 38 3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 39 3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 50 3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 53 3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 56
3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 56 3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 58
3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 56 3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 58
3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 60 3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 62
3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 62 3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 64
3.7. Implementation Considerations . . . . . . . . . . . . . . 65 3.7. Implementation Considerations . . . . . . . . . . . . . . 67
3.7.1. Working With Recurrence Instances . . . . . . . . . . 65 3.7.1. Working With Recurrence Instances . . . . . . . . . . 67
3.7.2. Attendee Property Considerations . . . . . . . . . . 66 3.7.2. Attendee Property Considerations . . . . . . . . . . 68
3.7.3. X-Tokens . . . . . . . . . . . . . . . . . . . . . . 67 3.7.3. Extension Tokens . . . . . . . . . . . . . . . . . . 69
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1. Published Event Examples . . . . . . . . . . . . . . . . 67 4.1. Published Event Examples . . . . . . . . . . . . . . . . 69
4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 67 4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 70
4.1.2. Changing A Published Event . . . . . . . . . . . . . 68 4.1.2. Changing A Published Event . . . . . . . . . . . . . 70
4.1.3. Canceling A Published Event . . . . . . . . . . . . . 69 4.1.3. Canceling A Published Event . . . . . . . . . . . . . 71
4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 69 4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 71
4.1.5. Anniversaries or Events attached to entire days . . . 70 4.1.5. Anniversaries or Events attached to entire days . . . 73
4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 71 4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 73
4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 72 4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 74
4.2.2. Reply To A Group Event Request . . . . . . . . . . . 72 4.2.2. Reply To A Group Event Request . . . . . . . . . . . 75
4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 73 4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 75
4.2.4. Countering an Event Proposal . . . . . . . . . . . . 74 4.2.4. Countering an Event Proposal . . . . . . . . . . . . 76
4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 76 4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 79
4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 78 4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 81
4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 79 4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 82
4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 80 4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 83
4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 80 4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 83
4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 82 4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 84
4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 83 4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 86
4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 84 4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 87
4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 85 4.3.1. Publish Busy Time . . . . . . . . . . . . . . . . . . 87
4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 86 4.3.2. Request Busy Time . . . . . . . . . . . . . . . . . . 88
4.4. Recurring Event and Time Zone Examples . . . . . . . . . 86 4.3.3. Reply To A Busy Time Request . . . . . . . . . . . . 89
4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 86 4.4. Recurring Event and Time Zone Examples . . . . . . . . . 89
4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 88 4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 89
4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 90 4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 91
4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 91 4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 93
4.4.5. Change All Future Instances . . . . . . . . . . . . . 91 4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 94
4.4.6. Add A New Instance To A Recurring Event . . . . . . . 92 4.4.5. Change All Future Instances . . . . . . . . . . . . . 94
4.4.7. Add A New Series of Instances To A Recurring Event . 93 4.4.6. Add A New Instance To A Recurring Event . . . . . . . 95
4.4.8. Counter An Instance Of A Recurring Event . . . . . . 98 4.4.7. Add A New Series of Instances To A Recurring Event . 96
4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 99 4.4.8. Counter An Instance Of A Recurring Event . . . . . . 101
4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 101 4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 102
4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 102 4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 104
4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 102 4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 105
4.5.3. A VTODO Request for Updated Status . . . . . . . . . 103 4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 105
4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 103 4.5.3. A VTODO Request for Updated Status . . . . . . . . . 106
4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 104 4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 106
4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 104 4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 107
4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 105 4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 107
4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 106 4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 108
4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 107 4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 109
4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 107 4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 109
4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 107 4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 109
5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 110 4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 110
5.1. Partial Implementation . . . . . . . . . . . . . . . . . 110 5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 113
5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 110 5.1. Partial Implementation . . . . . . . . . . . . . . . . . 113
5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 112 5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 113
5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 113 5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 115
5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 115 5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 116
5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 116 5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 118
5.2.1. Cancellation of an Unknown Calendar Component. . . . 116 5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 119
5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 117 5.2.1. Cancellation of an Unknown Calendar Component. . . . 119
5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 117 5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 120
6. Security Considerations . . . . . . . . . . . . . . . . . . . 117 5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 120
6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 117 6. Security Considerations . . . . . . . . . . . . . . . . . . . 120
6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 117 6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 120
6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 117 6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 120
6.1.3. Unauthorized Replacement of the Organizer . . . . . . 118 6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 120
6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 118 6.1.3. Unauthorized Replacement of the Organizer . . . . . . 121
6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 118 6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 121
6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 118 6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 121
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 118 6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 121
6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 118 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 121
6.2.2. Implementation Controls . . . . . . . . . . . . . . . 119 6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 121
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 119 6.2.2. Implementation Controls . . . . . . . . . . . . . . . 122
7.1. METHOD:PUBLISH . . . . . . . . . . . . . . . . . . . . . 120 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 122
7.2. METHOD:REQUEST . . . . . . . . . . . . . . . . . . . . . 120 7.1. METHOD:PUBLISH . . . . . . . . . . . . . . . . . . . . . 123
7.3. METHOD:REPLY . . . . . . . . . . . . . . . . . . . . . . 120 7.2. METHOD:REQUEST . . . . . . . . . . . . . . . . . . . . . 123
7.4. METHOD:ADD . . . . . . . . . . . . . . . . . . . . . . . 120 7.3. METHOD:REPLY . . . . . . . . . . . . . . . . . . . . . . 123
7.5. METHOD:CANCEL . . . . . . . . . . . . . . . . . . . . . . 121 7.4. METHOD:ADD . . . . . . . . . . . . . . . . . . . . . . . 123
7.6. METHOD:REFRESH . . . . . . . . . . . . . . . . . . . . . 121 7.5. METHOD:CANCEL . . . . . . . . . . . . . . . . . . . . . . 124
7.7. METHOD:COUNTER . . . . . . . . . . . . . . . . . . . . . 121 7.6. METHOD:REFRESH . . . . . . . . . . . . . . . . . . . . . 124
7.8. METHOD:DECLINE-COUNTER . . . . . . . . . . . . . . . . . 121 7.7. METHOD:COUNTER . . . . . . . . . . . . . . . . . . . . . 124
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 121 7.8. METHOD:DECLINE-COUNTER . . . . . . . . . . . . . . . . . 124
9. Normative References . . . . . . . . . . . . . . . . . . . . 122 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 124
Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 122 9. Normative References . . . . . . . . . . . . . . . . . . . . 125
A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 122 Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 125
A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 123 A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 125
A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 126
Appendix B. Change History (to be removed prior to Appendix B. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . 123 publication as an RFC) . . . . . . . . . . . . . . . 126
Appendix C. Change History (to be removed prior to Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 129
publication as an RFC) . . . . . . . . . . . . . . . 124 Intellectual Property and Copyright Statements . . . . . . . . . 130
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 125
Intellectual Property and Copyright Statements . . . . . . . . . 126
1. Introduction and Overview 1. Introduction and Overview
This document specifies how calendaring systems use iCalendar This document specifies how calendaring systems use iCalendar
[I-D.ietf-calsify-rfc2445bis] objects to interoperate with other [I-D.ietf-calsify-rfc2445bis] objects to interoperate with other
calendar systems. In particular, it specifies how to schedule calendaring systems. In particular, it specifies how to schedule
events, to-dos, or daily journal entries. It further specifies how events, to-dos, or daily journal entries. It further specifies how
to search for available busy time information. It does so in a to search for available busy time information. It does so in a
general way without specifying how communication between different general way without specifying how communication between different
systems actually takes place. Subsequent documents specify transport systems actually takes place. Subsequent documents specify transport
bindings between systems that use this protocol. bindings between systems that use this protocol.
This protocol is based on messages sent from an originator to one or This protocol is based on messages sent from an originator to one or
more recipients. For certain types of messages, a recipient may more recipients. For certain types of messages, a recipient may
reply, in order to update their status and may also return reply, in order to update their status and may also return
transaction/request status information. The protocol supports the transaction/request status information. The protocol supports the
skipping to change at page 6, line 40 skipping to change at page 6, line 40
[I-D.ietf-calsify-rfc2447bis] specifies an Internet email binding [I-D.ietf-calsify-rfc2447bis] specifies an Internet email binding
for iTIP. for iTIP.
This specification does not attempt to repeat the concepts or This specification does not attempt to repeat the concepts or
definitions from these other specifications. Where possible, definitions from these other specifications. Where possible,
explicit references are made to the other specifications. explicit references are made to the other specifications.
1.3. Roles 1.3. Roles
Exchanges of iCalendar objects for the purposes of group calendaring Exchanges of iCalendar objects for the purposes of group calendaring
and scheduling occur between "Calendar Users" (CUs). CUs take on one and scheduling occur between "Calendar Users" (CUs). CUs take on
of two roles in iTIP: several roles in iTIP:
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Role | Description | | Role | Description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Organizer | The CU who initiates an exchange takes on the role of | | Organizer | The CU who initiates an exchange takes on the role of |
| | "Organizer". For example, the CU who proposes a | | | "Organizer". For example, the CU who proposes a |
| | group meeting is the "Organizer". | | | group meeting is the "Organizer". |
| | | | | |
| Attendee | The CUs asked to participate in the group meeting by | | Attendee | CUs who are included in the scheduling message as |
| | the "Organizer" take on the role of "Attendee". | | | possible recipients of that scheduling message. For |
| | example, the CUs asked to participate in a group |
| | meeting by the "Organizer" take on the role of |
| | "Attendee". |
| | |
| Other CU | A CU that is not explicitly included in a scheduling |
| | message, i.e., not the "Organizer" or an "Attendee". |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Note that "ROLE" is also a descriptive parameter to the iCalendar Note that "ROLE" is also a descriptive parameter to the iCalendar
"ATTENDEE" property. Its use is to convey descriptive context about "ATTENDEE" property. Its use is to convey descriptive context about
an "Attendee" such as "chair", "required participant" or "non- an "Attendee" such as "chair", "required participant" or "non-
required participant" and has nothing to do with the calendaring required participant" and has nothing to do with the calendaring
workflow. workflow.
1.4. Methods 1.4. Methods
The ITIP methods are listed below and their usage and semantics are The ITIP methods are listed below and their usage and semantics are
defined in section 3 of this document. defined in section 3 of this document.
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Method | Description | | Method | Description |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| PUBLISH | Used to publish a calendar entry to one or more | | PUBLISH | Used to publish an iCalendar object to one or |
| | Calendar Users. There is no interactivity | | | more Calendar Users. There is no interactivity |
| | between the publisher and any other calendar | | | between the publisher and any other calendar |
| | user. An example might include a baseball team | | | user. An example might include a baseball team |
| | publishing its schedule to the public. | | | publishing its schedule to the public. |
| | | | | |
| REQUEST | Used to schedule a calendar entry with other | | REQUEST | Used to schedule an iCalendar object with other |
| | Calendar Users. Requests are interactive in | | | Calendar Users. Requests are interactive in |
| | that they require the receiver to respond using | | | that they require the receiver to respond using |
| | the Reply methods. Meeting Requests, Busy Time | | | the reply methods. Meeting requests, busy time |
| | requests and the assignment of VTODOs to other | | | requests and the assignment of tasks to other |
| | Calendar Users are all examples. Requests are | | | Calendar Users are all examples. Requests are |
| | also used by the "Organizer" to update the | | | also used by the "Organizer" to update the |
| | status of a calendar entry. | | | status of an iCalendar object. |
| | | | | |
| REPLY | A Reply is used in response to a Request to | | REPLY | A reply is used in response to a request to |
| | convey "Attendee" status to the "Organizer". | | | convey "Attendee" status to the "Organizer". |
| | Replies are commonly used to respond to meeting | | | Replies are commonly used to respond to meeting |
| | and task requests. | | | and task requests. |
| | | | | |
| ADD | Add one or more new instances to an existing | | ADD | Add one or more new instances to an existing |
| | VEVENT, VTODO, or VJOURNAL. | | | recurring iCalendar object. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | VEVENT, VTODO, or VJOURNAL. | | | iCalendar object. |
| | | | | |
| REFRESH | The Refresh method is used by an "Attendee" to | | REFRESH | The Refresh method is used by an "Attendee" to |
| | request the latest version of a calendar entry. | | | request the latest version of an iCalendar |
| | object. |
| | | | | |
| COUNTER | The Counter method is used by an "Attendee" to | | COUNTER | The Counter method is used by an "Attendee" to |
| | negotiate a change in the calendar entry. | | | negotiate a change in an iCalendar objecy. |
| | Examples include the request to change a | | | Examples include the request to change a |
| | proposed Event time or change the due date for a | | | proposed event time or change the due date for a |
| | VTODO. | | | task. |
| | | | | |
| DECLINECOUNTER | Used by the "Organizer" to decline the proposed | | DECLINECOUNTER | Used by the "Organizer" to decline the proposed |
| | counter-proposal. | | | counter-proposal. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Group scheduling in iTIP is accomplished using the set of "request" Group scheduling in iTIP is accomplished using the set of "request"
and "response" methods described above. The following table shows and "response" methods described above. The following table shows
the methods broken down by who can send them. the methods broken down by who can send them.
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Originator | Methods | | Originator | Methods |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER |
| | | | | |
| Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when | | Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when |
| | delegating) | | | delegating) |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
Note that for some calendar component types, the allowable methods Note that for some calendar component types, the allowable methods
are a subset of the above set. are a subset of the above set. In addition, apart from "VTIMEZONE"
iCalendar components, only one component type is allowed in a single
iTIP message.
2. Interoperability Models 2. Interoperability Models
There are two distinct protocols relevant to interoperability: an There are two distinct protocols relevant to interoperability: an
"Application Protocol" and a "Transport Protocol". The Application "Application Protocol" and a "Transport Protocol". The Application
Protocol defines the content of the iCalendar objects sent between Protocol defines the content of the iCalendar objects sent between
sender and receiver to accomplish the scheduling transactions listed sender and receiver to accomplish the scheduling transactions listed
above. The Transport Protocol defines how the iCalendar objects are above. The Transport Protocol defines how the iCalendar objects are
sent between the sender and receiver. This document focuses on the sent between the sender and receiver. This document focuses on the
Application Protocol. Binding documents such as Application Protocol. Binding documents such as
skipping to change at page 9, line 25 skipping to change at page 9, line 33
+--------------------------------------------------------+ +--------------------------------------------------------+
| iTIP Protocol | | iTIP Protocol |
+--------------------------------------------------------+ +--------------------------------------------------------+
| Transport | | Transport |
+ - - - - - + - - - - - - + - - - - - + + - - - - - + - - - - - - + - - - - - +
| Real-time | Store-and-Forward | Others | | Real-time | Store-and-Forward | Others |
+-----------------+--------------------+-----------------+ +-----------------+--------------------+-----------------+
2.1. Application Protocol 2.1. Application Protocol
In the iTIP model, a calendar entry is created and managed by an In the iTIP model, an iCalendar object is created and managed by an
"Organizer". The "Organizer" interacts with other CUs by sending one "Organizer". The "Organizer" interacts with other CUs by sending one
or more of the iTIP messages listed above. "Attendees" use the or more of the iTIP messages listed above. "Attendees" use the
"REPLY" method to communicate their status. "Attendees" do not make "REPLY" method to communicate their status. "Attendees" do not make
direct changes to the master calendar entry. They can, however, use direct changes to the master iCalendar object. They can, however,
the "COUNTER" method to suggest changes to the "Organizer". In any use the "COUNTER" method to suggest changes to the "Organizer". In
case, the "Organizer" has complete control over the master calendar any case, the "Organizer" has complete control over the master
entry. iCalendar object.
2.1.1. Calendar Entry State 2.1.1. Scheduling State
There are two distinct states relevant to calendar entries: the There are two distinct states relevant to iCalendar objects used in
overall state of the entry and the state associated with an scheduling: the overall state of the iCalendar object and the state
"Attendee" to that entry. associated with an "Attendee" in that iCalendar object.
The state of an entry is defined by the "STATUS" property and is The state of an iCalendar object is defined by the "STATUS" property
controlled by the "Organizer." There is no default value for the and is controlled by the "Organizer." There is no default value for
"STATUS" property. The "Organizer" sets the "STATUS" property to the the "STATUS" property. The "Organizer" sets the "STATUS" property to
appropriate value for each calendar entry. the appropriate value for each iCalendar object.
The state of a particular "Attendee" relative to an entry is defined The state of a particular "Attendee" relative to a iCalendar object
by the "PARTSTAT" parameter in the "ATTENDEE" property for each used for scheduling is defined by the "PARTSTAT" parameter in the
"Attendee". When an "Organizer" issues the initial entry, "Attendee" "ATTENDEE" property for each "Attendee". When an "Organizer" issues
status is unknown. The "Organizer" specifies this by setting the the initial iCalendar object, "Attendee" status is typically unknown.
"PARTSTAT" parameter to "NEEDS-ACTION". Each "Attendee" modifies The "Organizer" specifies this by setting the "PARTSTAT" parameter to
their "ATTENDEE" property "PARTSTAT" parameter to an appropriate "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property
value as part of a "REPLY" message sent back to the "Organizer". "PARTSTAT" parameter to an appropriate value as part of a "REPLY"
message sent back to the "Organizer".
2.1.2. Delegation 2.1.2. Delegation
Delegation is defined as the process by which an "Attendee" grants Delegation is defined as the process by which an "Attendee" grants
another CU (or several CUs) the right to attend on their behalf. The another CU (or several CUs) the right to attend on their behalf. The
"Organizer" is made aware of this change because the delegating "Organizer" is made aware of this change because the delegating
"Attendee" informs the "Organizer". These steps are detailed in the "Attendee" informs the "Organizer". These steps are detailed in the
REQUEST method section. REQUEST method section.
2.1.3. Acting on Behalf of other Calendar Users 2.1.3. Acting on Behalf of other Calendar Users
skipping to change at page 10, line 40 skipping to change at page 10, line 51
logistics for another individual who chairs a meeting. logistics for another individual who chairs a meeting.
Second, a "SENT-BY" parameter may be specified in either the Second, a "SENT-BY" parameter may be specified in either the
"Organizer" or "Attendee" properties. When specified, the "SENT-BY" "Organizer" or "Attendee" properties. When specified, the "SENT-BY"
parameter indicates that the responding CU acted on behalf of the parameter indicates that the responding CU acted on behalf of the
specified "Attendee" or "Organizer". specified "Attendee" or "Organizer".
2.1.4. Component Revisions 2.1.4. Component Revisions
The "SEQUENCE" property is used by the "Organizer" to indicate The "SEQUENCE" property is used by the "Organizer" to indicate
revisions to the calendar component. The rules for incrementing the revisions to the calendar component. When the "Organizer" makes
"SEQUENCE" number are defined in [I-D.ietf-calsify-rfc2445bis]. For changes to one of the following properties, the sequence number MUST
clarity, these rules are paraphrased here in terms of how they are be incremented:
applied in iTIP. For a given "UID" in a calendar component:
o "DTSTART"
o "DTEND"
o "DURATION"
o "DUE"
o "RRULE"
o "RDATE"
o "EXDATE"
o "STATUS"
In addition, changes made by the "Organizer" to other properties MAY
also require the sequence number to be incremented. The "Organizer"
CUA MUST increment the sequence number whenever it makes changes to
properties in the calendar component that the "Organizer" deems will
jeopardize the validity of the participation status of the
"Attendees". For example, changing the location of a meeting from
one location to another distant location could effectively impact the
participation status of the "Attendees".
Depending on the "METHOD", the "SEQUENCE" property MUST follow these
rules in the context of iTIP:
o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
value is incremented according to the rules defined in value is incremented according to the rules stated above.
[I-D.ietf-calsify-rfc2445bis].
o The "SEQUENCE" property value MUST be incremented each time the o The "SEQUENCE" property value MUST be incremented each time the
"Organizer" uses the "ADD" or "CANCEL" methods. "Organizer" uses the "ADD" or "CANCEL" methods.
o The "SEQUENCE" property value MUST NOT be incremented when using o The "SEQUENCE" property value MUST NOT be incremented when using
"REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
delegation "REQUEST". delegation "REQUEST".
In some circumstances the "Organizer" may not have received responses In some circumstances the "Organizer" may not have received responses
to the final revision sent out. In this situation, the "Organizer" to the final revision sent out. In this situation, the "Organizer"
may wish to send an update "REQUEST", and set "RSVP=TRUE" for all may wish to send an update "REQUEST", and set "RSVP=TRUE" for all
"Attendees", so that current responses can be collected. "Attendees", so that current responses can be collected.
The value of the "SEQUENCE" property contained in a response from an The value of the "SEQUENCE" property contained in a response from an
"Attendee" may not always match the "Organizer's" revision. "Attendee" may not always match the "Organizer's" revision.
Implementations may choose to have the CUA indicate to the CU that Implementations may choose to have the CUA indicate to the CU that
the response is to an entry that has been revised and allow the CU to the response is to an iCalendar object that has been revised and
decide whether or not to accept the response. allow the CU to decide whether or not to accept the response.
Whilst a change in SEQUENCE number is indicative of a significant Whilst a change in sequence number is indicative of a significant
change to a previously scheduled item, ATTENDEE CUAs SHOULD NOT rely change to a previously scheduled item, "Attendee" CUAs SHOULD NOT
solely on a change in SEQUENCE as a means of detecting a significant rely solely on a change in sequence number as a means of detecting a
change. Instead CUAs SHOULD compare the old and new versions of the significant change. Instead CUAs SHOULD compare the old and new
calendar components and determine the exact nature of the changes and versions of the calendar components and determine the exact nature of
make decisions, possibly based on calendar user preferences, as to the changes and make decisions, possibly based on calendar user
whether the user needs to be explicitly informed of the change. preferences, as to whether the user needs to be explicitly informed
of the change.
2.1.5. Message Sequencing 2.1.5. Message Sequencing
CUAs that handle the iTIP application protocol must often correlate a CUAs that handle the iTIP application protocol must often correlate a
component in a calendar store with a component received in the iTIP component in a calendar store with a component received in the iTIP
message. For example, an event may be updated with a later revision message. For example, an event may be updated with a later revision
of the same event. To accomplish this, a CUA must correlate the of the same event. To accomplish this, a CUA must correlate the
version of the event already in its calendar store with the version version of the event already in its calendar store with the version
sent in the iTIP message. In addition to this correlation, there are sent in the iTIP message. In addition to this correlation, there are
several factors that can cause iTIP messages to arrive in an several factors that can cause iTIP messages to arrive in an
skipping to change at page 11, line 48 skipping to change at page 12, line 29
an earlier revision of a component AFTER receiving a reply to a later an earlier revision of a component AFTER receiving a reply to a later
revision. revision.
To maximize interoperability and to handle messages that arrive in an To maximize interoperability and to handle messages that arrive in an
unexpected order, use the following rules: unexpected order, use the following rules:
1. The primary key for referencing a particular iCalendar component 1. The primary key for referencing a particular iCalendar component
is the "UID" property value. To reference an instance of a is the "UID" property value. To reference an instance of a
recurring component, the primary key is composed of the "UID" and recurring component, the primary key is composed of the "UID" and
the "RECURRENCE-ID" properties. the "RECURRENCE-ID" properties.
2. The secondary key for referencing a component is the "SEQUENCE" 2. The secondary key for referencing a component is the "SEQUENCE"
property value. For components where the "UID" is the same, the property value. For components where the "UID" and
component with the highest numeric value for the "SEQUENCE" "RECURRENCE-ID" property values are the same, the component with
property obsoletes all other revisions of the component with the highest numeric value for the "SEQUENCE" property obsoletes
lower values. all other revisions of the component with lower values.
3. "Attendees" send "REPLY" messages to the "Organizer". For 3. "Attendees" send "REPLY" messages to the "Organizer". For
replies where the "UID" property value is the same, the value of replies where the "UID" and "RECURRENCE-ID" property values are
the "SEQUENCE" property indicates the revision of the component the same, the value of the "SEQUENCE" property indicates the
to which the "Attendee" is replying. The reply with the highest revision of the component to which the "Attendee" is replying.
numeric value for the "SEQUENCE" property obsoletes all other The reply with the highest numeric value for the "SEQUENCE"
replies with lower values. property obsoletes all other replies with lower values.
4. In situations where the "UID" and "SEQUENCE" properties match,
the "DTSTAMP" property is used as the tie-breaker. The component
with the latest "DTSTAMP" overrides all others. Similarly, for
"Attendee" responses where the "UID" property values match and
the "SEQUENCE" property values match, the response with the
latest "DTSTAMP" overrides all others.
Hence, CUAs must persist the following component properties: "UID", 4. In situations where the "UID", "RECURRENCE-ID", and "SEQUENCE"
"RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each property values match, the "DTSTAMP" property is used as the tie-
"ATTENDEE" property of a component CUAs must persist the "SEQUENCE" breaker. The component with the latest "DTSTAMP" overrides all
and "DTSTAMP" property values associated with the "Attendee's" others. Similarly, for "Attendee" responses where the "UID",
response. "RECURRENCE-ID", and "SEQUENCE" property values match, the
response with the latest "DTSTAMP" overrides all others.
Hence, CUAs will need to persist the following component properties
in order to correctly process iTIP messages: "UID", "RECURRENCE-ID",
"SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property
of a component, "Organizer" CUAs will need to persist the "SEQUENCE"
and "DTSTAMP" property values associated with the "Attendee's" last
response, so that any earlier responses from an "Attendee" that are
received out of order (e.g., due to a delay in the transport) can be
correctly discarded.
3. Application Protocol Elements 3. Application Protocol Elements
ITIP messages are "text/calendar" MIME entities that contain ITIP messages are "text/calendar" MIME entities that contain
calendaring and scheduling information. The particular type of calendaring and scheduling information. The particular type of
iCalendar message is referred to as the "method type". Each method iCalendar message is referred to as the "method type". Each method
type is identified by a "METHOD" property specified as part of the type is identified by a "METHOD" property specified as part of the
"text/calendar" content type. The table below shows various "text/calendar" content type. The table below shows various
combinations of calendar components and the method types that this combinations of calendar components and the method types that this
specification supports. specification supports.
skipping to change at page 13, line 24 skipping to change at page 14, line 15
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Presence Value | Description | | Presence Value | Description |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| 1 | One instance MUST be present | | 1 | One instance MUST be present |
| 1+ | At least one instance MUST be present | | 1+ | At least one instance MUST be present |
| 0 | Instances of this property MUST NOT be present | | 0 | Instances of this property MUST NOT be present |
| 0+ | Multiple instances MAY be present | | 0+ | Multiple instances MAY be present |
| 0 or 1 | Up to 1 instance of this property MAY be present | | 0 or 1 | Up to 1 instance of this property MAY be present |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
The tables also call out "X-PROPERTY" and "X-COMPONENT" to show where The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA-
vendor-specific properties and components can appear. The tables do COMPONENT" and "X-COMPONENT" to show where registered and vendor-
specific property and component extensions can appear. The tables do
not lay out the restrictions of property parameters. Those not lay out the restrictions of property parameters. Those
restrictions are defined in [I-D.ietf-calsify-rfc2445bis]. restrictions are defined in [I-D.ietf-calsify-rfc2445bis].
3.1. Common Component Restriction Tables 3.1. Common Component Restriction Tables
3.1.1. VCALENDAR 3.1.1. VCALENDAR
The restriction table below applies to properties of the iCalendar The restriction table below applies to properties of the iCalendar
object. That is, the properties at the outermost scope. object. That is, the properties at the outermost scope.
+-----------------------------------------------------+
| Constraints for properties in a VCALENDAR Component |
+-----------------------------------------------------+
+--------------------+----------+---------------------+ +--------------------+----------+---------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+---------------------+ +--------------------+----------+---------------------+
| CALSCALE | 0 or 1 | | | CALSCALE | 0 or 1 | |
| PRODID | 1 | | | PRODID | 1 | |
| VERSION | 1 | Value MUST be "2.0" | | VERSION | 1 | Value MUST be "2.0" |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
+--------------------+----------+---------------------+ +--------------------+----------+---------------------+
3.1.2. VTIMEZONE 3.1.2. VTIMEZONE
"VTIMEZONE" components may be referred to by other components via a "VTIMEZONE" components may be referred to by other components via a
"TZID" parameter on a "DATETIME" value type. The property "TZID" parameter on a "DATETIME" value type. The property
restrictions in the table below apply to any "VTIMEZONE" component in restrictions in the table below apply to any "VTIMEZONE" component in
an ITIP message. an ITIP message.
+--------------------------------------+
| Constraints for VTIMEZONE Components |
+--------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to timezone | | | | refers to timezone |
| DAYLIGHT | 0+ | MUST be one or more of either | | DAYLIGHT | 0+ | MUST be one or more of either |
| | | STANDARD or DAYLIGHT | | | | STANDARD or DAYLIGHT |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| DTSTART | 1 | MUST be local time format | | DTSTART | 1 | MUST be local time format |
| RDATE | 0+ | if present RRULE MUST NOT be | | RDATE | 0+ | if present RRULE MUST NOT be |
| | | present | | | | present |
| RRULE | 0+ | if present RDATE MUST NOT be | | RRULE | 0 or 1 | if present RDATE MUST NOT be |
| | | present | | | | present |
| TZNAME | 0+ | | | TZNAME | 0+ | |
| TZOFFSETFROM | 1 | | | TZOFFSETFROM | 1 | |
| TZOFFSETTO | 1 | | | TZOFFSETTO | 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| STANDARD | 0+ | MUST be one or more of either | | STANDARD | 0+ | MUST be one or more of either |
| | | STANDARD or DAYLIGHT | | | | STANDARD or DAYLIGHT |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| DTSTART | 1 | MUST be local time format | | DTSTART | 1 | MUST be local time format |
| RDATE | 0+ | if present RRULE MUST NOT be | | RDATE | 0+ | if present RRULE MUST NOT be |
| | | present | | | | present |
| RRULE | 0+ | if present RDATE MUST NOT be | | RRULE | 0 or 1 | if present RDATE MUST NOT be |
| | | present | | | | present |
| TZNAME | 0+ | | | TZNAME | 0+ | |
| TZOFFSETFROM | 1 | | | TZOFFSETFROM | 1 | |
| TZOFFSETTO | 1 | | | TZOFFSETTO | 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| TZID | 1 | | | TZID | 1 | |
| TZURL | 0 or 1 | | | TZURL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.1.3. VALARM 3.1.3. VALARM
The property restrictions in the table below apply to any "VALARM" The property restrictions in the table below apply to any "VALARM"
component in an ITIP message. component in an ITIP message.
+-----------------------------------+
| Constraints for VALARM Components |
+-----------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| VALARM | 0+ | | | VALARM | 0+ | |
| ACTION | 1 | | | ACTION | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| ATTENDEE | 0+ | | | ATTENDEE | 0+ | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DURATION | 0 or 1 | if present REPEAT MUST be present | | DURATION | 0 or 1 | if present REPEAT MUST be present |
| REPEAT | 0 or 1 | if present DURATION MUST be | | REPEAT | 0 or 1 | if present DURATION MUST be |
| | | present | | | | present |
| SUMMARY | 0 or 1 | | | SUMMARY | 0 or 1 | |
| TRIGGER | 1 | | | TRIGGER | 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2. Methods for VEVENT Calendar Components 3.2. Methods for VEVENT Calendar Components
This section defines the property set restrictions for the method This section defines the property set restrictions for the method
types that are applicable to the "VEVENT" calendar component. Each types that are applicable to the "VEVENT" calendar component. Each
method is defined using a table that clarifies the property method is defined using a table that clarifies the property
constraints that define the particular method. constraints that define the particular method.
skipping to change at page 15, line 40 skipping to change at page 16, line 40
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Method | Description | | Method | Description |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| PUBLISH | Post notification of an event. Used primarily | | PUBLISH | Post notification of an event. Used primarily |
| | as a method of advertising the existence of an | | | as a method of advertising the existence of an |
| | event. | | | event. |
| | | | | |
| REQUEST | Make a request for an event. This is an | | REQUEST | Make a request for an event. This is an |
| | explicit invitation to one or more "Attendees". | | | explicit invitation to one or more "Attendees". |
| | Event Requests are also used to update or change | | | Event requests are also used to update or change |
| | an existing event. Clients that cannot handle | | | an existing event. Clients that cannot handle |
| | REQUEST may degrade the event to view it as an | | | REQUEST MAY degrade the event to view it as an |
| | PUBLISH. | | | PUBLISH. |
| | | | | |
| REPLY | Reply to an event request. Clients may set | | REPLY | Reply to an event request. Clients may set |
| | their status ("PARTSTAT") to ACCEPTED, DECLINED, | | | their status ("PARTSTAT") to ACCEPTED, DECLINED, |
| | TENTATIVE, or DELEGATED. | | | TENTATIVE, or DELEGATED. |
| | | | | |
| ADD | Add one or more instances to an existing event. | | ADD | Add one or more instances to an existing event. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | event. | | | event. |
skipping to change at page 16, line 31 skipping to change at page 17, line 33
published iCalendar component. "Attendees" MUST NOT be present. Its published iCalendar component. "Attendees" MUST NOT be present. Its
expected usage is for encapsulating an arbitrary event as an expected usage is for encapsulating an arbitrary event as an
iCalendar object. The "Organizer" may subsequently update (with iCalendar object. The "Organizer" may subsequently update (with
another "PUBLISH" method), add instances to (with an "ADD" method), another "PUBLISH" method), add instances to (with an "ADD" method),
or cancel (with a "CANCEL" method) a previously published "VEVENT" or cancel (with a "CANCEL" method) a previously published "VEVENT"
calendar component. calendar component.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VEVENT |
+----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST equal "PUBLISH" | | METHOD | 1 | MUST equal "PUBLISH" |
| | | | | | | |
| VEVENT | 1+ | | | VEVENT | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SUMMARY | 1 | Can be null. | | SUMMARY | 1 | Can be null. |
skipping to change at page 17, line 20 skipping to change at page 18, line 26
| DURATION | 0 or 1 | If present DTEND MUST NOT be | | DURATION | 0 or 1 | If present DTEND MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | TENTATIVE/CONFIRMED/CANCELLED | | | | TENTATIVE/CONFIRMED/CANCELLED |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2.2. REQUEST 3.2.2. REQUEST
The "REQUEST" method in a "VEVENT" component provides the following The "REQUEST" method in a "VEVENT" component provides the following
scheduling functions: scheduling functions:
o Invite "Attendees" to an event o Invite "Attendees" to an event
o Reschedule an existing event o Reschedule an existing event
skipping to change at page 18, line 37 skipping to change at page 19, line 45
For the "REQUEST" method, multiple "VEVENT" components in a single For the "REQUEST" method, multiple "VEVENT" components in a single
iCalendar object are only permitted when for components with the same iCalendar object are only permitted when for components with the same
"UID" property. That is, a series of recurring events may have "UID" property. That is, a series of recurring events may have
instance-specific information. In this case, multiple "VEVENT" instance-specific information. In this case, multiple "VEVENT"
components are needed to express the entire series. components are needed to express the entire series.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------+
| Constraints for a METHOD:REQUEST of a VEVENT |
+----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REQUEST" | | METHOD | 1 | MUST be "REQUEST" |
| | | | | | | |
| VEVENT | 1+ | All components MUST have the same | | VEVENT | 1+ | All components MUST have the same |
| | | UID | | | | UID |
| ATTENDEE | 1+ | | | ATTENDEE | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
skipping to change at page 19, line 22 skipping to change at page 20, line 33
| DTEND | 0 or 1 | if present DURATION MUST NOT be | | DTEND | 0 or 1 | if present DURATION MUST NOT be |
| | | present | | | | present |
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | | STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2.2.1. Rescheduling an Event 3.2.2.1. Rescheduling an Event
skipping to change at page 21, line 7 skipping to change at page 22, line 17
outlined below. Implementations may support or restrict delegation outlined below. Implementations may support or restrict delegation
as they see fit. For instance, some implementations may restrict a as they see fit. For instance, some implementations may restrict a
delegate from delegating a "REQUEST" to another CU. delegate from delegating a "REQUEST" to another CU.
The "Delegator" of an event forwards the existing "REQUEST" to the The "Delegator" of an event forwards the existing "REQUEST" to the
"Delegate". The "REQUEST" method MUST include an "ATTENDEE" property "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
with the calendar address of the "Delegate". The "Delegator" MUST with the calendar address of the "Delegate". The "Delegator" MUST
also send a "REPLY" method to the "Organizer" with the "Delegator's" also send a "REPLY" method to the "Organizer" with the "Delegator's"
"ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED". "ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED".
In addition, the "DELEGATED-TO" parameter MUST be included with the In addition, the "DELEGATED-TO" parameter MUST be included with the
calendar address of the "Delegate". calendar address of the "Delegate". Also, a new "ATTENDEE" property
for the "Delegate" MUST be included and must specify the calendar
user address set in the "DELEGATED-TO" parameter, as above.
In response to the request, the "Delegate" MUST send a "REPLY" method In response to the request, the "Delegate" MUST send a "REPLY" method
to the "Organizer" and optionally, to the "Delegator". The "REPLY" to the "Organizer" and optionally, to the "Delegator". The "REPLY"
method " SHOULD include the "ATTENDEE" property with the "DELEGATED- method SHOULD include the "ATTENDEE" property with the "DELEGATED-
FROM" parameter value of the "Delegator's" calendar address. FROM" parameter value of the "Delegator's" calendar address.
The "Delegator" may continue to receive updates to the event even The "Delegator" may continue to receive updates to the event even
though they will not be attending. This is accomplished by the though they will not be attending. This is accomplished by the
"Delegator" setting their "role" attribute to " NON-PARTICIPANT" in "Delegator" setting their "role" attribute to " NON-PARTICIPANT" in
the "REPLY" to the "Organizer" the "REPLY" to the "Organizer"
3.2.2.4. Changing the Organizer 3.2.2.4. Changing the Organizer
The situation may arise where the "Organizer" of a VEVENT is no The situation may arise where the "Organizer" of a VEVENT is no
longer able to perform the "Organizer" role and abdicates without longer able to perform the "Organizer" role and abdicates without
passing on the "Organizer" role to someone else. When this occurs passing on the "Organizer" role to someone else. When this occurs
the "Attendees" of the VEVENT may use out-of-band mechanisms to the "Attendees" of the VEVENT may use out-of-band mechanisms to
communicate the situation and agree upon a new "Organizer". The new communicate the situation and agree upon a new "Organizer". The new
"Organizer" should then send out a new "REQUEST" with a modified "Organizer" should then send out a new "REQUEST" with a modified
version of the VEVENT in which the "SEQUENCE" number has been version of the VEVENT in which the "SEQUENCE" number has been
incremented and value of the "ORGANIZER" property has been changed to incremented and the "ORGANIZER" property has been changed to the new
the calendar address of the new "Organizer". "Organizer".
3.2.2.5. Sending on Behalf of the Organizer 3.2.2.5. Sending on Behalf of the Organizer
There are a number of scenarios that support the need for a calendar There are a number of scenarios that support the need for a calendar
user to act on behalf of the "Organizer" without explicit role user to act on behalf of the "Organizer" without explicit role
changing. This might be the case if the CU designated as "Organizer" changing. This might be the case if the CU designated as "Organizer"
was sick or unable to perform duties associated with that function. was sick or unable to perform duties associated with that function.
In these cases iTIP supports the notion of one CU acting on behalf of In these cases iTIP supports the notion of one CU acting on behalf of
another. Using the "SENT-BY" parameter, a calendar user could send another. Using the "SENT-BY" parameter, a calendar user could send
an updated "VEVENT" REQUEST. In the case where one CU sends on an updated "VEVENT" REQUEST. In the case where one CU sends on
behalf of another CU, the "Attendee" responses are still directed behalf of another CU, the "Attendee" responses are still directed
back towards the CU designated as "Organizer". back towards the CU designated as "Organizer".
3.2.2.6. Forwarding to An Uninvited CU 3.2.2.6. Forwarding to An Uninvited CU
An "Attendee" invited to an event may invite another uninvited CU to An "Attendee" invited to an event may invite another uninvited CU to
the event. The invited "Attendee" accomplishes this by forwarding the event. The invited "Attendee" accomplishes this by forwarding
the original "REQUEST" method to the uninvited CU. The "Organizer" the original "REQUEST" method to the uninvited CU. The uninvited CU
decides whether or not the uninvited CU is added to the attendee then replies to the "Organizer". The "Organizer" decides whether or
list. If the "Organizer" decides not to add the uninvited CU no not the uninvited CU is added to the attendee list. If the
further action is required, however the "Organizer" MAY send the "Organizer" decides not to add the uninvited CU no further action is
uninvited CU a "CANCEL" message. If the "Organizer" decides to add required, however the "Organizer" MAY send the uninvited CU a
an uninvited CU, a new "ATTENDEE" property is added for the uninvited "CANCEL" message. If the "Organizer" decides to add an uninvited CU,
CU with its property parameters set as the "Organizer" deems a new "ATTENDEE" property is added for the uninvited CU with its
appropriate. When forwarding a "REQUEST" to another CU, the property parameters set as the "Organizer" deems appropriate. When
forwarding "Attendee" MUST NOT make changes to the VEVENT property forwarding a "REQUEST" to another CU, the forwarding "Attendee" MUST
set. NOT make changes to the original message.
3.2.2.7. Updating Attendee Status 3.2.2.7. Updating Attendee Status
The "Organizer" of an event may also request updated status from one The "Organizer" of an event may also request updated status from one
or more "Attendees. The "Organizer" sends a "REQUEST" method to the or more "Attendees. The "Organizer" sends a "REQUEST" method to the
"Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
"SEQUENCE" property for the event is not changed from its previous "SEQUENCE" property for the event is not changed from its previous
value. A recipient will determine that the only change in the value. A recipient will determine that the only change in the
"REQUEST" is that their "RSVP" property parameter indicates a request "REQUEST" is that their "RSVP" property parameter indicates a request
for updated status. The recipient SHOULD respond with a "REPLY" for updated status. The recipient SHOULD respond with a "REPLY"
skipping to change at page 22, line 32 skipping to change at page 23, line 44
The "REPLY" method in a "VEVENT" calendar component is used to The "REPLY" method in a "VEVENT" calendar component is used to
respond (e.g., accept or decline) to a "REQUEST" or to reply to a respond (e.g., accept or decline) to a "REQUEST" or to reply to a
delegation "REQUEST". When used to provide a delegation response, delegation "REQUEST". When used to provide a delegation response,
the "Delegator" SHOULD include the calendar address of the "Delegate" the "Delegator" SHOULD include the calendar address of the "Delegate"
on the "DELEGATED-TO" property parameter of the "Delegator's" on the "DELEGATED-TO" property parameter of the "Delegator's"
"ATTENDEE" property. The "Delegate" SHOULD include the calendar "ATTENDEE" property. The "Delegate" SHOULD include the calendar
address of the "Delegator" on the "DELEGATED-FROM" property parameter address of the "Delegator" on the "DELEGATED-FROM" property parameter
of the "Delegate's" "ATTENDEE" property. of the "Delegate's" "ATTENDEE" property.
The "REPLY" method may also be used to respond to an unsuccessful The "REPLY" method is also used when processing of a "REQUEST" fails.
"REQUEST" method. Depending on the value of the "REQUEST-STATUS" Depending on the value of the "REQUEST-STATUS" property no scheduling
property no scheduling action may have been performed. action may have been performed.
The "Organizer" of an event may receive the "REPLY" method from a CU The "Organizer" of an event may receive the "REPLY" method from a CU
not in the original "REQUEST". For example, a "REPLY" may be not in the original "REQUEST". For example, a "REPLY" may be
received from a "Delegate" to an event. In addition, the "REPLY" received from a "Delegate" to an event. In addition, the "REPLY"
method may be received from an unknown CU (a "Party Crasher"). This method may be received from an unknown CU (a "Party Crasher"). This
uninvited "Attendee" may be accepted, or the "Organizer" may cancel uninvited "Attendee" may be accepted, or the "Organizer" may cancel
the event for the uninvited "Attendee" by sending a "CANCEL" method the event for the uninvited "Attendee" by sending a "CANCEL" method
to the uninvited "Attendee". to the uninvited "Attendee".
An "Attendee" can include a message to the "Organizer" using the An "Attendee" MAY include a message to the "Organizer" using the
"COMMENT" property. For example, if the user indicates tentative "COMMENT" property. For example, if the user indicates tentative
acceptance and wants to let the "Organizer" know why, the reason can acceptance and wants to let the "Organizer" know why, the reason can
be expressed in the "COMMENT" property value. be expressed in the "COMMENT" property value.
The "Organizer" may also receive a "REPLY" from one CU on behalf of The "Organizer" may also receive a "REPLY" from one CU on behalf of
another. Like the scenario enumerated above for the "Organizer", another. Like the scenario enumerated above for the "Organizer",
"Attendees" may have another CU respond on their behalf. This is "Attendees" may have another CU respond on their behalf. This is
done using the "SENT-BY" parameter. done using the "SENT-BY" parameter.
The optional properties listed in the table below (those listed as The optional properties listed in the table below (those listed as
"0+" or "0 or 1") MUST NOT be changed from those of the original "0+" or "0 or 1") MUST NOT be changed from those of the original
request. If property changes are desired the COUNTER message must be request. If property changes are desired the COUNTER message must be
used. used.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+--------------------------------------------+
| Constraints for a METHOD:REPLY of a VEVENT |
+--------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" | | METHOD | 1 | MUST be "REPLY" |
| | | | | | | |
| VEVENT | 1+ | All components MUST have the same | | VEVENT | 1+ | All components MUST have the same |
| | | UID | | | | UID |
| ATTENDEE | 1 | MUST be the address of the | | ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. | | | | Attendee replying. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| RECURRENCE-ID | 0 or 1 | only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it must NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | REQUEST |
| SEQUENCE | 0 or 1 | MUST if non-zero, MUST be the | | SEQUENCE | 0 or 1 | MUST if non-zero, MUST be the |
| | | sequence number of the original | | | | sequence number of the original |
| | | REQUEST. MAY be present if 0. | | | | REQUEST. MAY be present if 0. |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
skipping to change at page 24, line 7 skipping to change at page 25, line 23
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | | | STATUS | 0 or 1 | |
| SUMMARY | 0 or 1 | | | SUMMARY | 0 or 1 | |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2.4. ADD 3.2.4. ADD
The "ADD" method allows the "Organizer" to add one or more new The "ADD" method allows the "Organizer" to add one or more new
skipping to change at page 24, line 45 skipping to change at page 26, line 15
The "UID" must be that of the existing event. If the "UID" property The "UID" must be that of the existing event. If the "UID" property
value in the "ADD" is not found on the recipient's calendar, then the value in the "ADD" is not found on the recipient's calendar, then the
recipient SHOULD send a "REFRESH" to the "Organizer" in order to be recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
updated with the latest version of the "VEVENT". If an "Attendee" updated with the latest version of the "VEVENT". If an "Attendee"
implementation does not support the "ADD" method it should respond implementation does not support the "ADD" method it should respond
with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+------------------------------------------+
| Constraints for a METHOD:ADD of a VEVENT |
+------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "ADD" | | METHOD | 1 | MUST be "ADD" |
| | | | | | | |
| VEVENT | 1 | | | VEVENT | 1 | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | MUST be greater than 0 | | SEQUENCE | 1 | MUST be greater than 0 |
skipping to change at page 25, line 30 skipping to change at page 26, line 52
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | | STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| RECURRENCE-ID | 0 | | | RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2.5. CANCEL 3.2.5. CANCEL
The "CANCEL" method in a "VEVENT" calendar component is used to send The "CANCEL" method in a "VEVENT" calendar component is used to send
a cancellation notice of an existing event request to the a cancellation notice of an existing event request to the affected
"Attendees". The message is sent by the "Organizer" of the event. "Attendees". The message is sent by the "Organizer" of the event.
For a recurring event, either the whole event or instances of an For a recurring event, either the whole event or instances of an
event may be cancelled. To cancel the complete range of recurring event may be cancelled. To cancel the complete range of recurring
event, the "UID" property value for the event MUST be specified and a event, the "UID" property value for the event MUST be specified and a
"RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In
order to cancel an individual instance of the event, the order to cancel an individual instance of the event, the
"RECURRENCE-ID" property value for the event MUST be specified in the "RECURRENCE-ID" property value for the event MUST be specified in the
"CANCEL" method. "CANCEL" method.
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
skipping to change at page 26, line 35 skipping to change at page 28, line 9
b. individual recurrence instances may be cancelled by specifying b. individual recurrence instances may be cancelled by specifying
multiple "VEVENT" components each with a "RECURRENCE-ID" property multiple "VEVENT" components each with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled. corresponding to one of the instances to be cancelled.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+
| Constraints for a METHOD:CANCEL of a VEVENT |
+---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "CANCEL" | | METHOD | 1 | MUST be "CANCEL" |
| | | | | | | |
| VEVENT | 1+ | All must have the same UID | | VEVENT | 1+ | All must have the same UID |
| ATTENDEE | 0+ | MUST include all "Attendees" | | ATTENDEE | 0+ | MUST include all "Attendees" |
| | | being removed the event. MUST | | | | being removed from the event. |
| | | include all "Attendees" if the | | | | MUST include all "Attendees" if |
| | | entire event is cancelled. | | | | the entire event is cancelled. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | | | SEQUENCE | 1 | |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | REQUEST |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
skipping to change at page 27, line 19 skipping to change at page 28, line 46
| | | present | | | | present |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST be present if referring to | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | one or more or more recurring | | | | of a recurring calendar |
| | | instances. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MUST be set to CANCELLED. If | | STATUS | 0 or 1 | MUST be set to CANCELLED to |
| | | cancel the entire event. If |
| | | uninviting specific "Attendees" | | | | uninviting specific "Attendees" |
| | | then MUST NOT be included. | | | | then MUST NOT be included. |
| SUMMARY | 0 or 1 | | | SUMMARY | 0 or 1 | |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | |
| VALARM | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2.6. REFRESH 3.2.6. REFRESH
The "REFRESH" method in a "VEVENT" calendar component is used by The "REFRESH" method in a "VEVENT" calendar component is used by
"Attendees" of an existing event to request an updated description "Attendees" of an existing event to request an updated description
from the event "Organizer". The "REFRESH" method must specify the from the event "Organizer". The "REFRESH" method must specify the
"UID" property of the event to update. A recurrence instance of an "UID" property of the event to update. A recurrence instance of an
event may be requested by specifying the "RECURRENCE-ID" property event may be requested by specifying the "RECURRENCE-ID" property
corresponding to the associated event. The "Organizer" responds with corresponding to the associated event. The "Organizer" responds with
the latest description and version of the event. the latest description and version of the event.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------+
| Constraints for a METHOD:REFRESH of a VEVENT |
+----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REFRESH" | | METHOD | 1 | MUST be "REFRESH" |
| | | | | | | |
| VEVENT | 1 | | | VEVENT | 1 | |
| ATTENDEE | 1 | MUST be the address of requester | | ATTENDEE | 1 | MUST be the address of requester |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| UID | 1 | MUST be the UID associated with | | UID | 1 | MUST be the UID associated with |
| | | original REQUEST | | | | original REQUEST |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it must NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTACH | 0 | | | ATTACH | 0 | |
| CATEGORIES | 0 | | | CATEGORIES | 0 | |
| CLASS | 0 | | | CLASS | 0 | |
| CONTACT | 0 | | | CONTACT | 0 | |
| CREATED | 0 | | | CREATED | 0 | |
| DESCRIPTION | 0 | | | DESCRIPTION | 0 | |
| DTEND | 0 | | | DTEND | 0 | |
| DTSTART | 0 | | | DTSTART | 0 | |
| DURATION | 0 | | | DURATION | 0 | |
skipping to change at page 29, line 11 skipping to change at page 30, line 43
| RELATED-TO | 0 | | | RELATED-TO | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| RESOURCES | 0 | | | RESOURCES | 0 | |
| RRULE | 0 | | | RRULE | 0 | |
| SEQUENCE | 0 | | | SEQUENCE | 0 | |
| STATUS | 0 | | | STATUS | 0 | |
| SUMMARY | 0 | | | SUMMARY | 0 | |
| TRANSP | 0 | | | TRANSP | 0 | |
| URL | 0 | | | URL | 0 | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0+ | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | |
| VTIMEZONE | 0 | |
| | | |
| VALARM | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2.7. COUNTER 3.2.7. COUNTER
The "COUNTER" method for a "VEVENT" calendar component is used by an The "COUNTER" method for a "VEVENT" calendar component is used by an
"Attendee" of an existing event to submit to the "Organizer" a "Attendee" of an existing event to submit to the "Organizer" a
counter proposal to the event description. The "Attendee" sends this counter proposal to the event. The "Attendee" sends this message to
message to the "Organizer" of the event. the "Organizer" of the event.
The counter proposal is an iCalendar object consisting of a VEVENT The counter proposal is an iCalendar object consisting of a VEVENT
calendar component describing the complete description of the calendar component describing the complete description of the
alternate event. alternate event.
The "Organizer" rejects the counter proposal by sending the The "Organizer" rejects the counter proposal by sending the
"Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts
the counter proposal by rescheduling the event as described in the counter proposal by rescheduling the event as described in
section 3.2.2.1 Rescheduling an Event. section 3.2.2.1 Rescheduling an Event.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------+
| Constraints for a METHOD:COUNTER of a VEVENT |
+----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "COUNTER" | | METHOD | 1 | MUST be "COUNTER" |
| | | | | | | |
| VEVENT | 1 | | | VEVENT | 1 | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | MUST be the "Organizer" of the | | ORGANIZER | 1 | MUST be the "Organizer" of the |
| | | original event | | | | original event |
| SEQUENCE | 1 | MUST be present if value is | | SEQUENCE | 1 | MUST echo the original SEQUENCE |
| | | greater than 0, MAY be present if | | | | number. MUST be present if |
| | | 0 | | | | non-zero. MAY be present if |
| | | zero. |
| SUMMARY | 1 | Can be null | | SUMMARY | 1 | Can be null |
| UID | 1 | MUST be the UID associated with | | UID | 1 | MUST be the UID associated with |
| | | the REQUEST being countered | | | | the REQUEST being countered |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| ATTENDEE | 0+ | Can also be used to propose other | | ATTENDEE | 0+ | Can also be used to propose other |
| | | "Attendees" | | | | "Attendees" |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
skipping to change at page 30, line 31 skipping to change at page 32, line 20
| DTEND | 0 or 1 | if present DURATION MUST NOT be | | DTEND | 0 or 1 | if present DURATION MUST NOT be |
| | | present | | | | present |
| DURATION | 0 or 1 | if present DTEND MUST NOT be | | DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | Value must be one of | | STATUS | 0 or 1 | Value must be one of |
| | | CONFIRMED/TENATIVE/ CANCELLED | | | | CONFIRMED/TENATIVE/ CANCELLED |
| TRANSP | 0 or 1 | | | TRANSP | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2.8. DECLINECOUNTER 3.2.8. DECLINECOUNTER
The "DECLINECOUNTER" method in a "VEVENT" calendar component is used The "DECLINECOUNTER" method in a "VEVENT" calendar component is used
by the "Organizer" of an event to reject a counter proposal submitted by the "Organizer" of an event to reject a counter proposal submitted
by an "Attendee". The "Organizer" must send the "DECLINECOUNTER" by an "Attendee". The "Organizer" must send the "DECLINECOUNTER"
message to the "Attendee" that sent the "COUNTER" method to the message to the "Attendee" that sent the "COUNTER" method to the
"Organizer". "Organizer".
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-----------------------------------------------------+
| Constraints for a METHOD:DECLINECOUNTER of a VEVENT |
+-----------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "DECLINECOUNTER" | | METHOD | 1 | MUST be "DECLINECOUNTER" |
| | | | | | | |
| VEVENT | 1 | | | VEVENT | 1 | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| UID | 1 | MUST, same UID specified in | | UID | 1 | MUST, same UID specified in |
| | | original REQUEST and subsequent | | | | original REQUEST and subsequent |
| | | COUNTER | | | | COUNTER |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| SEQUENCE | 0 or 1 | MUST be present if value is | | SEQUENCE | 0 or 1 | MUST be present if value is |
| | | greater than 0, MAY be present if | | | | greater than 0, MAY be present if |
| | | 0 | | | | 0 |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTACH | 0 | | | ATTACH | 0 | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| CATEGORIES | 0 | | | CATEGORIES | 0 | |
| CLASS | 0 | | | CLASS | 0 | |
| CONTACT | 0 | | | CONTACT | 0 | |
| CREATED | 0 | | | CREATED | 0 | |
| DESCRIPTION | 0 | | | DESCRIPTION | 0 | |
| DTEND | 0 | | | DTEND | 0 | |
| DTSTART | 0 | | | DTSTART | 0 | |
skipping to change at page 32, line 19 skipping to change at page 34, line 17
| PRIORITY | 0 | | | PRIORITY | 0 | |
| RDATE | 0 | | | RDATE | 0 | |
| RELATED-TO | 0 | | | RELATED-TO | 0 | |
| RESOURCES | 0 | | | RESOURCES | 0 | |
| RRULE | 0 | | | RRULE | 0 | |
| STATUS | 0 | | | STATUS | 0 | |
| SUMMARY | 0 | | | SUMMARY | 0 | |
| TRANSP | 0 | | | TRANSP | 0 | |
| URL | 0 | | | URL | 0 | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0+ | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | |
| VTIMEZONE | 0 | |
| | | |
| VALARM | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.3. Methods For VFREEBUSY Components 3.3. Methods For VFREEBUSY Components
This section defines the property set for the methods that are This section defines the property set for the methods that are
applicable to the "VFREEBUSY" calendar component. Each of the applicable to the "VFREEBUSY" calendar component. Each of the
methods is defined using a restriction table. methods is defined using a restriction table.
This document only addresses the transfer of busy time information. This document only addresses the transfer of busy time information.
Applications desiring free time information MUST infer this from Applications desiring free time information MUST infer this from
available busy time information. available busy time information.
The busy time information within the iCalendar object MAY be grouped
into more than one "VFREEBUSY" calendar component. This capability
allows busy time periods to be grouped according to some common
periodicity, such as a calendar week, month, or year. In this case,
each "VFREEBUSY" calendar component MUST include the "ATTENDEE",
"DTSTART" and "DTEND" properties in order to specify the source of
the busy time information and the date and time interval over which
the busy time information covers.
The "FREEBUSY" property value MAY include a list of values, separated The "FREEBUSY" property value MAY include a list of values, separated
by the COMMA character (US-ASCII decimal 44). Alternately, multiple by the COMMA character (US-ASCII decimal 44). Alternately, multiple
busy time periods MAY be specified with multiple instances of the busy time periods MAY be specified with multiple instances of the
"FREEBUSY" property. Both forms MUST be supported by implementations "FREEBUSY" property. Both forms MUST be supported by implementations
conforming to this document. Duplicate busy time periods SHOULD NOT conforming to this document. Duplicate busy time periods SHOULD NOT
be specified in an iCalendar object. However, two different busy be specified in an iCalendar object. However, two different busy
time periods MAY overlap. time periods MAY overlap.
"FREEBUSY" properties should be sorted such that their values are in "FREEBUSY" properties SHOULD be sorted such that their values are in
ascending order, based on the start time, and then the end time, with ascending order, based on the start time, and then the end time, with
the earliest periods first. For example, today's busy time the earliest periods first. For example, today's busy time
information should appear after yesterday's busy time information. information should appear after yesterday's busy time information.
And the busy time for this half-hour should appear after the busy And the busy time for this half-hour should appear after the busy
time for earlier today. time for earlier today. Busy time periods may also span a day
boundary.
Since events may span a day boundary, free busy time period may also
span a day boundary. Individual "A" requests busy time from
individuals "B", "C" and "D". Individual "B" and "C" replies with
busy time data to individual "A". Individual "D" does not support
busy time requests and does not reply with any data. If the
transport binding supports exception messages, then individual "D"
returns an "unsupported capability" message to individual "A".
The following summarizes the methods that are defined for the The following summarizes the methods that are defined for the
"VFREEBUSY" calendar component. "VFREEBUSY" calendar component.
+---------+-------------------------------------+ +---------+-------------------------------------+
| Method | Description | | Method | Description |
+---------+-------------------------------------+ +---------+-------------------------------------+
| PUBLISH | Publish unsolicited busy time data. | | PUBLISH | Publish unsolicited busy time data. |
| | | | | |
| REQUEST | Request busy time data. | | REQUEST | Request busy time data. |
| | | | | |
| REPLY | Reply to a busy time request. | | REPLY | Reply to a busy time request. |
+---------+-------------------------------------+ +---------+-------------------------------------+
3.3.1. PUBLISH 3.3.1. PUBLISH
The "PUBLISH" method in a "VFREEBUSY" calendar component is used to The "PUBLISH" method in a "VFREEBUSY" calendar component is used to
publish busy time data. The method may be sent from one CU to any publish busy time data. The method may be sent from one CU to any
other. The purpose of the method is to provide a message for sending other. The purpose of the method is to provide a way to send
unsolicited busy time data. That is, the busy time data is not being unsolicited busy time data. That is, the busy time data is not being
sent as a "REPLY" to the receipt of a "REQUEST" method. sent as a "REPLY" to the receipt of a "REQUEST" method.
The "ORGANIZER" property must be specified in the busy time The "ORGANIZER" property MUST be specified in the busy time
information. The value is the CU address of the originator of the information. The value is the CU address of the originator of the
busy time information. busy time information.
The busy time information within the iCalendar object MAY be grouped
into more than one "VFREEBUSY" calendar component. This capability
allows busy time periods to be grouped according to some common
periodicity, such as a calendar week, month, or year. In this case,
each "VFREEBUSY" calendar component MUST include the "ORGANIZER",
"DTSTART" and "DTEND" properties in order to specify the source of
the busy time information and the date and time interval over which
the busy time information covers.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-------------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VFREEBUSY |
+-------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "PUBLISH" | | METHOD | 1 | MUST be "PUBLISH" |
| | | | | | | |
| VFREEBUSY | 1+ | | | VFREEBUSY | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | DateTime values must be in UTC | | DTSTART | 1 | DateTime values must be in UTC |
| DTEND | 1 | DateTime values must be in UTC | | DTEND | 1 | DateTime values must be in UTC |
| FREEBUSY | 0+ | MUST be BUSYTIME. Multiple | | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
| | | instances are allowed. Multiple | | | | instances are allowed. Multiple |
| | | instances must be sorted in | | | | instances SHOULD be sorted in |
| | | ascending order | | | | ascending order |
| ORGANIZER | 1 | MUST contain the address of | | ORGANIZER | 1 | MUST contain the address of |
| | | originator of busy time data. | | | | originator of busy time data. |
| UID | 1 | | | UID | 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0 or 1 | | | CONTACT | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| URL | 0 or 1 | Specifies busy time URL | | URL | 0 or 1 | Specifies busy time URL |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| DURATION | 0 | | | DURATION | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTIMEZONE | 0 | | | VTIMEZONE | 0 | |
| | | |
| VALARM | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.3.2. REQUEST 3.3.2. REQUEST
The "REQUEST" method in a "VFREEBUSY" calendar component is used to The "REQUEST" method in a "VFREEBUSY" calendar component is used to
ask a "Calendar User" for their busy time information. The request ask a "Calendar User" for their busy time information. The request
may be for a busy time information bounded by a specific date and may be for a busy time information bounded by a specific date and
time interval. time interval.
This message only permits requests for busy time information. The This message only permits requests for busy time information. The
skipping to change at page 35, line 14 skipping to change at page 37, line 14
information to one or more intended recipients. information to one or more intended recipients.
If the originator of the "REQUEST" method is not authorized to make a If the originator of the "REQUEST" method is not authorized to make a
busy time request on the recipient's calendar system, then an busy time request on the recipient's calendar system, then an
exception message SHOULD be returned in a "REPLY" method, but no busy exception message SHOULD be returned in a "REPLY" method, but no busy
time data need be returned. time data need be returned.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-------------------------------------------------+
| Constraints for a METHOD:REQUEST of a VFREEBUSY |
+-------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REQUEST" | | METHOD | 1 | MUST be "REQUEST" |
| | | | | | | |
| VFREEBUSY | 1 | | | VFREEBUSY | 1 | |
| ATTENDEE | 1+ | contain the address of the | | ATTENDEE | 1+ | contains the calendar user |
| | | calendar store | | | | addresses of the calendar users |
| | | whose freebusy is being requested |
| DTEND | 1 | DateTime values must be in UTC | | DTEND | 1 | DateTime values must be in UTC |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | DateTime values must be in UTC | | DTSTART | 1 | DateTime values must be in UTC |
| ORGANIZER | 1 | MUST be the request originator's | | ORGANIZER | 1 | MUST be the request originator's |
| | | address | | | | address |
| UID | 1 | | | UID | 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0 or 1 | | | CONTACT | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| FREEBUSY | 0 | | | FREEBUSY | 0 | |
| DURATION | 0 | | | DURATION | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| URL | 0 | | | URL | 0 | |
| | | | | | | |
| X-COMPONENT | 0+ | |
| | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTIMEZONE | 0 | | | VTIMEZONE | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.3.3. REPLY 3.3.3. REPLY
skipping to change at page 36, line 18 skipping to change at page 38, line 21
respond to a busy time request. The method is sent by the recipient respond to a busy time request. The method is sent by the recipient
of a busy time request to the originator of the request. of a busy time request to the originator of the request.
The "REPLY" method may also be used to respond to an unsuccessful The "REPLY" method may also be used to respond to an unsuccessful
"REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy
time information may be returned. time information may be returned.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-----------------------------------------------+
| Constraints for a METHOD:REPLY of a VFREEBUSY |
+-----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" | | METHOD | 1 | MUST be "REPLY" |
| | | | | | | |
| VFREEBUSY | 1 | | | VFREEBUSY | 1 | |
| ATTENDEE | 1 | (address of recipient replying) | | ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTEND | 1 | DateTime values must be in UTC | | DTEND | 1 | DateTime values must be in UTC |
| DTSTART | 1 | DateTime values must be in UTC | | DTSTART | 1 | DateTime values must be in UTC |
| FREEBUSY | 0+ | (values MUST all be of the same | | FREEBUSY | 0+ | values MUST all be of the same |
| | | data type. Multiple instances | | | | data type. Multiple instances |
| | | are allowed. Multiple instances | | | | SHOULD be sorted in ascending |
| | | MUST be sorted in ascending | | | | order. Values MUST NOT overlap |
| | | order. Values MUST NOT overlap) |
| ORGANIZER | 1 | MUST be the request originator's | | ORGANIZER | 1 | MUST be the request originator's |
| | | address | | | | address |
| UID | 1 | | | UID | 1 | MUST be the UID of the original |
| | | REQUEST |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0 or 1 | | | CONTACT | 0 or 1 | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| URL | 0 or 1 | (specifies busy time URL) | | URL | 0 or 1 | specifies busy time URL |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| DURATION | 0 | | | DURATION | 0 | |
| SEQUENCE | 0 | | | SEQUENCE | 0 | |
| | | | | | | |
| X-COMPONENT | 0+ | |
| | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTIMEZONE | 0 | | | VTIMEZONE | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4. Methods For VTODO Components 3.4. Methods For VTODO Components
skipping to change at page 38, line 19 skipping to change at page 41, line 5
that maybe added to a calendar. It MUST have an "Organizer". It that maybe added to a calendar. It MUST have an "Organizer". It
MUST NOT have "Attendees". Its expected usage is for encapsulating MUST NOT have "Attendees". Its expected usage is for encapsulating
an arbitrary "VTODO" calendar component as an iCalendar object. The an arbitrary "VTODO" calendar component as an iCalendar object. The
"Organizer" MAY subsequently update (with another "PUBLISH" method), "Organizer" MAY subsequently update (with another "PUBLISH" method),
add instances to (with an "ADD" method), or cancel (with a "CANCEL" add instances to (with an "ADD" method), or cancel (with a "CANCEL"
method) a previously published "VTODO" calendar component. method) a previously published "VTODO" calendar component.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VTODO |
+---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | | | METHOD | 1 | MUST be "PUBLISH" |
| | | MUST be "PUBLISH" | | | | |
| VTODO | 1+ | | | VTODO | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| PRIORITY | 1 | | | PRIORITY | 1 | |
| SEQUENCE | 0 or 1 | MUST be present if value is | | SEQUENCE | 0 or 1 | MUST be present if value is |
| | | greater than 0, MAY be present if | | | | greater than 0, MAY be present if |
| | | 0 | | | | 0 |
| SUMMARY | 1 | Can be null. | | SUMMARY | 1 | Can be null. |
| UID | 1 | | | UID | 1 | |
skipping to change at page 39, line 4 skipping to change at page 41, line 42
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present DURATION MUST NOT be |
| | | present | | | | present |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | | STATUS | 0 or 1 | MAY be one of |
| | | ACTION/IN- PROCESS/CANCELLED | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS/CANCELLED |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| VALARM | 0+ | | | IANA-COMPONENT | 0+ | |
| | | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.2. REQUEST 3.4.2. REQUEST
skipping to change at page 39, line 49 skipping to change at page 42, line 41
o Update the details of an existing to-do, without rescheduling it o Update the details of an existing to-do, without rescheduling it
o Update the completion status of "Attendees" of an existing to-do, o Update the completion status of "Attendees" of an existing to-do,
without rescheduling it without rescheduling it
o Reconfirm an existing to-do, without rescheduling it o Reconfirm an existing to-do, without rescheduling it
o Delegate/reassign an existing to-do to another "Calendar User" o Delegate/reassign an existing to-do to another "Calendar User"
The assigned "Calendar Users" are identified in the "VTODO" calendar The assigned "Calendar Users" are identified in the "VTODO" calendar
component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property
value sequences. value sequences.
The originator of a "REQUEST" is the "Organizer" of the to-do. The Typically the originator of a "REQUEST" is the "Organizer" of the
recipient of a "REQUEST" is the "Calendar User" assigned the to-do. to-do, and the recipient of a "REQUEST" is the "Calendar User"
The "Attendee" uses the "REPLY" method to convey their acceptance and assigned the to-do. The "Attendee" uses the "REPLY" method to convey
completion status to the "Organizer" of the "REQUEST". their acceptance and completion status to the "Organizer" of the
"REQUEST".
The "UID", "SEQUENCE", and "DTSTAMP" properties are used to The "UID", "SEQUENCE", and "DTSTAMP" properties are used to
distinguish the various uses of the "REQUEST" method. If the "UID" distinguish the various uses of the "REQUEST" method. If the "UID"
property value in the "REQUEST" is not found on the recipient's property value in the "REQUEST" is not found on the recipient's
calendar, then the "REQUEST" is for a new to-do. If the "UID" calendar, then the "REQUEST" is for a new to-do. If the "UID"
property value is found on the recipient's calendar, then the property value is found on the recipient's calendar, then the
"REQUEST" is a rescheduling, an update, or a reconfirm of the "VTODO" "REQUEST" is a rescheduling, an update, or a reconfirm of the "VTODO"
calendar object. calendar object.
If the "Organizer" of the "REQUEST" method is not authorized to make If the "Organizer" of the "REQUEST" method is not authorized to make
skipping to change at page 40, line 28 skipping to change at page 43, line 21
For the "REQUEST" method, multiple "VTODO" components in a single For the "REQUEST" method, multiple "VTODO" components in a single
iCalendar object are only permitted when for components with the same iCalendar object are only permitted when for components with the same
"UID" property. That is, a series of recurring events may have "UID" property. That is, a series of recurring events may have
instance-specific information. In this case, multiple "VTODO" instance-specific information. In this case, multiple "VTODO"
components are needed to express the entire series. components are needed to express the entire series.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+
| Constraints for a METHOD:REQUEST of a VTODO |
+---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REQUEST" | | METHOD | 1 | MUST be "REQUEST" |
| | | | | | | |
| VTODO | 1+ | All components must have the same | | VTODO | 1+ | All components must have the same |
| | | UID | | | | UID |
| ATTENDEE | 1+ | | | ATTENDEE | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
skipping to change at page 41, line 15 skipping to change at page 44, line 12
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present DURATION MUST NOT be |
| | | present | | | | present |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | present if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | | STATUS | 0 or 1 | MAY be one of |
| | | ACTION/IN- PROCESS | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.2.1. REQUEST for Rescheduling a VTODO 3.4.2.1. REQUEST for Rescheduling a VTODO
skipping to change at page 42, line 41 skipping to change at page 45, line 41
updating the completion status of "Attendees") or the "VTODO" updating the completion status of "Attendees") or the "VTODO"
calendar component itself (i.e., reconfirm the "VTODO"). calendar component itself (i.e., reconfirm the "VTODO").
3.4.2.3. REQUEST for Delegating a VTODO 3.4.2.3. REQUEST for Delegating a VTODO
The "REQUEST" method is also used to delegate or reassign ownership The "REQUEST" method is also used to delegate or reassign ownership
of a "VTODO" calendar component to another "Calendar User". For of a "VTODO" calendar component to another "Calendar User". For
example, it may be used to delegate an "Attendee's" role (i.e. example, it may be used to delegate an "Attendee's" role (i.e.
"chair", or "participant") for a "VTODO" calendar component. The "chair", or "participant") for a "VTODO" calendar component. The
"REQUEST" method is sent by one of the "Attendees" of an existing "REQUEST" method is sent by one of the "Attendees" of an existing
"VTODO" calendar component to some other individual. An "Attendee" "VTODO" calendar component to some other individual.
of a "VTODO" calendar component MUST NOT delegate to the "Organizer"
of the event.
For the purposes of this description, the "Attendee" delegating the For the purposes of this description, the "Attendee" delegating the
"VTODO" calendar component is referred to as the "Delegator". The "VTODO" calendar component is referred to as the "Delegator". The
"Attendee" receiving the delegation request is referred to as the "Attendee" receiving the delegation request is referred to as the
"Delegate". "Delegate".
The "Delegator" of a "VTODO" calendar component MUST forward the The "Delegator" of a "VTODO" calendar component MUST forward the
existing "REQUEST" method for a "VTODO" calendar component to the existing "REQUEST" method for a "VTODO" calendar component to the
"Delegate". The "VTODO" calendar component description MUST include "Delegate". The "VTODO" calendar component description MUST include
the "Delegator's" up-to-date "VTODO" calendar component definition. the "Delegator's" up-to-date "VTODO" calendar component definition.
skipping to change at page 44, line 39 skipping to change at page 47, line 37
"VTODO" calendar component. In addition, the "REPLY" method MAY be "VTODO" calendar component. In addition, the "REPLY" method MAY be
received from an unknown "Calendar User", having been forwarded the received from an unknown "Calendar User", having been forwarded the
"REQUEST" by an original "Attendee" of the "VTODO" calendar "REQUEST" by an original "Attendee" of the "VTODO" calendar
component. This uninvited "Attendee" MAY be accepted, or the component. This uninvited "Attendee" MAY be accepted, or the
"Organizer" MAY cancel the "VTODO" calendar component for the "Organizer" MAY cancel the "VTODO" calendar component for the
uninvited "Attendee" by sending them a "CANCEL" method. uninvited "Attendee" by sending them a "CANCEL" method.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-------------------------------------------+
| Constraints for a METHOD:REPLY of a VTODO |
+-------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" | | METHOD | 1 | MUST be "REPLY" |
| | | | | | | |
| VTODO | 1+ | All component MUST have the same | | VTODO | 1+ | All component MUST have the same |
| | | UID | | | | UID |
| ATTENDEE | 1+ | | | ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| REQUEST-STATUS | 1+ | | | REQUEST-STATUS | 1+ | |
| UID | 1 | MUST must be the address of the | | UID | 1 | MUST be the UID of the original |
| | | replying attendee | | | | REQUEST |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| COMPLETED | 0 or 1 | | | COMPLETED | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present DURATION MUST NOT be |
skipping to change at page 45, line 26 skipping to change at page 48, line 29
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a Recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present | | | | be present. |
| SEQUENCE | 0 or 1 | MUST be the sequence number of | | SEQUENCE | 0 or 1 | MUST be the sequence number of |
| | | the original REQUEST if greater | | | | the original REQUEST if greater |
| | | than 0. MAY be present if 0. | | | | than 0. MAY be present if 0. |
| STATUS | 0 or 1 | | | STATUS | 0 or 1 | |
| SUMMARY | 0 or 1 | Can be null | | SUMMARY | 0 or 1 | Can be null |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.4. ADD 3.4.4. ADD
The "ADD" method in a "VTODO" calendar component is used to add one The "ADD" method in a "VTODO" calendar component is used to add one
or more instances to an existing to-do. or more instances to an existing to-do.
If the "UID" property value in the "ADD" is not found on the If the "UID" property value in the "ADD" is not found on the
recipient's calendar, then the recipient SHOULD send a "REFRESH" to recipient's calendar, then the recipient SHOULD send a "REFRESH" to
the "Organizer" in order to be updated with the latest version of the the "Organizer" in order to be updated with the latest version of the
"VTODO". If an "Attendee" implementation does not support the "ADD" "VTODO". If an "Attendee" implementation does not support the "ADD"
method it should respond with a "REQUEST-STATUS" value of 5.3 and ask method it should respond with a "REQUEST-STATUS" value of 3.14 and
for a "REFRESH". ask for a "REFRESH".
The "SEQUENCE" property value is incremented as the sequence of to- The "SEQUENCE" property value is incremented as the sequence of to-
dos has changed. dos has changed.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-----------------------------------------+
| Constraints for a METHOD:ADD of a VTODO |
+-----------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "ADD" | | METHOD | 1 | MUST be "ADD" |
| | | | | | | |
| VTODO | 1 | | | VTODO | 1 | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| PRIORITY | 1 | | | PRIORITY | 1 | |
| SEQUENCE | 1 | MUST be greater than 0 | | SEQUENCE | 1 | MUST be greater than 0 |
skipping to change at page 47, line 9 skipping to change at page 50, line 17
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | | STATUS | 0 or 1 | MAY be one of |
| | | ACTION/IN- PROCESS | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| RECURRENCE-ID | 0 | | | RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.5. CANCEL 3.4.5. CANCEL
The "CANCEL" method in a "VTODO" calendar component is used to send a The "CANCEL" method in a "VTODO" calendar component is used to send a
cancellation notice of an existing "VTODO" calendar request to the cancellation notice of an existing "VTODO" calendar request to the
"Attendees". The message is sent by the "Organizer" of a "VTODO" affected "Attendees". The message is sent by the "Organizer" of a
calendar component to the "Attendees" of the "VTODO" calendar "VTODO" calendar component to the "Attendees" of the "VTODO" calendar
component. For a recurring "VTODO" calendar component, either the component. For a recurring "VTODO" calendar component, either the
whole "VTODO" calendar component or instances of a "VTODO" calendar whole "VTODO" calendar component or instances of a "VTODO" calendar
component may be cancelled. To cancel the complete range of a component may be cancelled. To cancel the complete range of a
recurring "VTODO" calendar component, the "UID" property value for recurring "VTODO" calendar component, the "UID" property value for
the "VTODO" calendar component MUST be specified and a "RECURRENCE- the "VTODO" calendar component MUST be specified and a "RECURRENCE-
ID" MUST NOT be specified in the "CANCEL" method. In order to cancel ID" MUST NOT be specified in the "CANCEL" method. In order to cancel
an individual instance of a recurring "VTODO" calendar component, the an individual instance of a recurring "VTODO" calendar component, the
"RECURRENCE-ID" property value for the "VTODO" calendar component "RECURRENCE-ID" property value for the "VTODO" calendar component
MUST be specified in the "CANCEL" method. MUST be specified in the "CANCEL" method.
skipping to change at page 49, line 5 skipping to change at page 51, line 27
b. individual recurrence instances may be cancelled by specifying b. individual recurrence instances may be cancelled by specifying
multiple "VTODO" components with a "RECURRENCE-ID" property multiple "VTODO" components with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled corresponding to one of the instances to be cancelled
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+--------------------------------------------+
| Constraints for a METHOD:CANCEL of a VTODO |
+--------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "CANCEL" | | METHOD | 1 | MUST be "CANCEL" |
| | | | | | | |
| VTODO | 1 | | | VTODO | 1+ | |
| ATTENDEE | 0+ | include all "Attendees" being | | ATTENDEE | 0+ | include all "Attendees" being |
| | | removed from the todo. MUST | | | | removed from the todo. MUST |
| | | include all "Attendees" if the | | | | include all "Attendees" if the |
| | | entire todo is cancelled. | | | | entire todo is cancelled. |
| UID | 1 | MUST echo original UID | | UID | 1 | MUST echo original UID |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | | | SEQUENCE | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
skipping to change at page 49, line 38 skipping to change at page 52, line 16
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present DURATION MUST NOT be |
| | | present | | | | present |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to one or | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | more instances of a recurring | | | | of a recurring calendar |
| | | calendar component. Otherwise it | | | | component. Otherwise it MUST NOT |
| | | MUST NOT be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| STATUS | 0 or 1 | If present it MUST be set to | | STATUS | 0 or 1 | MUST be set to CANCELLED to |
| | | "CANCELLED". MUST NOT be used if | | | | cancel the entire VTODO. If |
| | | purpose is to remove "ATTENDEES" | | | | removing specific "Attendees" |
| | | rather than cancel the entire | | | | then MUST NOT be included. |
| | | VTODO. |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.6. REFRESH 3.4.6. REFRESH
The "REFRESH" method in a "VTODO" calendar component is used by The "REFRESH" method in a "VTODO" calendar component is used by
"Attendees" of an existing "VTODO" calendar component to request an "Attendees" of an existing "VTODO" calendar component to request an
updated description from the "Organizer" of the "VTODO" calendar updated description from the "Organizer" of the "VTODO" calendar
skipping to change at page 51, line 5 skipping to change at page 53, line 20
corresponding to the associated "VTODO" calendar component. The corresponding to the associated "VTODO" calendar component. The
"Organizer" responds with the latest description and rendition of the "Organizer" responds with the latest description and rendition of the
"VTODO" calendar component. In most cases this will be a REQUEST "VTODO" calendar component. In most cases this will be a REQUEST
unless the "VTODO" has been cancelled, in which case the ORGANIZER unless the "VTODO" has been cancelled, in which case the ORGANIZER
MUST send a "CANCEL". This method is intended to facilitate machine MUST send a "CANCEL". This method is intended to facilitate machine
processing of requests for updates to a "VTODO" calendar component. processing of requests for updates to a "VTODO" calendar component.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+
| Constraints for a METHOD:REFRESH of a VTODO |
+---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REFRESH" | | METHOD | 1 | MUST be "REFRESH" |
| | | | | | | |
| VTODO | 1 | | | VTODO | 1 | |
| ATTENDEE | 1 | | | ATTENDEE | 1 | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| UID | 1 | MUST echo original UID | | UID | 1 | MUST echo original UID |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a Recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present | | | | be present. |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTACH | 0 | | | ATTACH | 0 | |
| CATEGORIES | 0 | | | CATEGORIES | 0 | |
| CLASS | 0 | | | CLASS | 0 | |
| COMMENT | 0 | | | COMMENT | 0 | |
| COMPLETED | 0 | | | COMPLETED | 0 | |
| CONTACT | 0 | | | CONTACT | 0 | |
| CREATED | 0 | | | CREATED | 0 | |
| DESCRIPTION | 0 | | | DESCRIPTION | 0 | |
| DTSTART | 0 | | | DTSTART | 0 | |
skipping to change at page 51, line 46 skipping to change at page 54, line 18
| PRIORITY | 0 | | | PRIORITY | 0 | |
| RDATE | 0 | | | RDATE | 0 | |
| RELATED-TO | 0 | | | RELATED-TO | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| RESOURCES | 0 | | | RESOURCES | 0 | |
| RRULE | 0 | | | RRULE | 0 | |
| SEQUENCE | 0 | | | SEQUENCE | 0 | |
| STATUS | 0 | | | STATUS | 0 | |
| URL | 0 | | | URL | 0 | |
| | | | | | | |
| X-COMPONENT | 0+ | |
| | | |
| VALARM | 0 | | | VALARM | 0 | |
| | | | | | | |
| VTIMEZONE | 0+ | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | |
| VTIMEZONE | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.7. COUNTER 3.4.7. COUNTER
The "COUNTER" method in a "VTODO" calendar component is used by an The "COUNTER" method in a "VTODO" calendar component is used by an
"Attendee" of an existing "VTODO" calendar component to submit to the "Attendee" of an existing "VTODO" calendar component to submit to the
"Organizer" a counter proposal for the "VTODO" calendar component. "Organizer" a counter proposal for the "VTODO" calendar component.
The "Attendee" sends the message to the "Organizer" of the "VTODO"
calendar component.
The counter proposal is an iCalendar object consisting of a "VTODO" The counter proposal is an iCalendar object consisting of a "VTODO"
calendar component describing the complete description of the calendar component describing the complete description of the
alternate "VTODO" calendar component. alternate "VTODO" calendar component.
The "Organizer" rejects the counter proposal by sending the The "Organizer" rejects the counter proposal by sending the
"Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
counter proposal by sending all of the "Attendees" of the "VTODO" counter proposal by sending all of the "Attendees" of the "VTODO"
calendar component a "REQUEST" method rescheduling the "VTODO" calendar component a "REQUEST" method rescheduling the "VTODO"
calendar component. In the latter case, the "Organizer" SHOULD reset calendar component. In the latter case, the "Organizer" SHOULD reset
the individual "RSVP" property parameter values to TRUE on each the individual "RSVP" property parameter values to TRUE on each
"ATTENDEE" property; in order to force a response by the "Attendees". "ATTENDEE" property in order to force a response by the "Attendees".
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+---------------------------------------------+
| Constraints for a METHOD:COUNTER of a VTODO |
+---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "COUNTER" | | METHOD | 1 | MUST be "COUNTER" |
| | | | | | | |
| VTODO | 1 | | | VTODO | 1 | |
| ATTENDEE | 1+ | | | ATTENDEE | 1+ | |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| PRIORITY | 1 | | | PRIORITY | 1 | |
skipping to change at page 53, line 14 skipping to change at page 55, line 40
| DUE | 0 or 1 | If present DURATION MUST NOT be | | DUE | 0 or 1 | If present DURATION MUST NOT be |
| | | present | | | | present |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST only 3.5if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE | | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE |
| | | number. MUST be present if | | | | number. MUST be present if |
| | | non-zero. MAY be present if | | | | non-zero. MAY be present if |
| | | zero. | | | | zero. |
| STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | | STATUS | 0 or 1 | MAY be one of |
| | | ACTION/IN- PROCESS/CANCELLED | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS/CANCELLED |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.4.8. DECLINECOUNTER 3.4.8. DECLINECOUNTER
The "DECLINECOUNTER" method in a "VTODO" calendar component is used The "DECLINECOUNTER" method in a "VTODO" calendar component is used
by an "Organizer" of "VTODO" calendar component to reject a counter by an "Organizer" of "VTODO" calendar component to reject a counter
proposal offered by one of the "Attendees". The "Organizer" sends proposal offered by one of the "Attendees". The "Organizer" sends
the message to the "Attendee" that sent the "COUNTER" method to the the message to the "Attendee" that sent the "COUNTER" method to the
"Organizer". "Organizer".
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+----------------------------------------------------+
| Constraints for a METHOD:DECLINECOUNTER of a VTODO |
+----------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "DECLINECOUNTER" | | METHOD | 1 | MUST be "DECLINECOUNTER" |
| | | | | | | |
| VTODO | 1 | | | VTODO | 1 | |
| ATTENDEE | 1+ | MUST for all attendees | | ATTENDEE | 1+ | MUST for all attendees |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | MUST echo the original SEQUENCE | | SEQUENCE | 1 | MUST echo the original SEQUENCE |
skipping to change at page 55, line 37 skipping to change at page 57, line 23
| | | present | | | | present |
| DURATION | 0 or 1 | If present DUE MUST NOT be | | DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present | | | | present |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| GEO | 0 or 1 | | | GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | | | LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | |
| PRIORITY | 0 or 1 | | | PRIORITY | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | | STATUS | 0 or 1 | MAY be one of |
| | | ACTION/IN- PROCESS | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.5. Methods For VJOURNAL Components 3.5. Methods For VJOURNAL Components
This section defines the property set for the methods that are This section defines the property set for the methods that are
applicable to the "VJOURNAL" calendar component. applicable to the "VJOURNAL" calendar component.
skipping to change at page 57, line 5 skipping to change at page 58, line 38
associated response. It is simply a posting of an iCalendar object associated response. It is simply a posting of an iCalendar object
that may be added to a calendar. It MUST have an "Organizer". It that may be added to a calendar. It MUST have an "Organizer". It
MUST NOT have "Attendees". The expected usage is for encapsulating MUST NOT have "Attendees". The expected usage is for encapsulating
an arbitrary journal entry as an iCalendar object. The "Organizer" an arbitrary journal entry as an iCalendar object. The "Organizer"
MAY subsequently update (with another "PUBLISH" method) or cancel MAY subsequently update (with another "PUBLISH" method) or cancel
(with a "CANCEL" method) a previously published journal entry. (with a "CANCEL" method) a previously published journal entry.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+------------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VJOURNAL |
+------------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "PUBLISH" | | METHOD | 1 | MUST be "PUBLISH" |
| | | | | | | |
| VJOURNAL | 1+ | | | VJOURNAL | 1+ | |
| DESCRIPTION | 1 | Can be null. | | DESCRIPTION | 1 | Can be null. |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| UID | 1 | | | UID | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to an | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | instance of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE | | SEQUENCE | 0 or 1 | MUST be present if non-zero. MAY |
| | | number. MUST be present if | | | | be present if zero. |
| | | non-zero. MAY be present if |
| | | zero. |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | DRAFT/FINAL/CANCELLED | | | | DRAFT/FINAL/CANCELLED |
| SUMMARY | 0 or 1 | Can be null | | SUMMARY | 0 or 1 | Can be null |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.5.2. ADD 3.5.2. ADD
skipping to change at page 59, line 5 skipping to change at page 60, line 21
one or more instances to an existing "VJOURNAL" entry. There is no one or more instances to an existing "VJOURNAL" entry. There is no
response to the "Organizer". response to the "Organizer".
If the "UID" property value in the "ADD" is not found on the If the "UID" property value in the "ADD" is not found on the
recipient's calendar, then the recipient MAY treat the "ADD" as a recipient's calendar, then the recipient MAY treat the "ADD" as a
"PUBLISH". "PUBLISH".
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+--------------------------------------------+
| Constraints for a METHOD:ADD of a VJOURNAL |
+--------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "ADD" | | METHOD | 1 | MUST be "ADD" |
| | | | | | | |
| VJOURNAL | 1 | | | VJOURNAL | 1 | |
| DESCRIPTION | 1 | Can be null | | DESCRIPTION | 1 | Can be null |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTSTART | 1 | | | DTSTART | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
skipping to change at page 59, line 28 skipping to change at page 61, line 27
| ATTACH | 0+ | | | ATTACH | 0+ | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | DRAFT/FINAL/CANCELLED | | | | DRAFT/FINAL/CANCELLED |
| SUMMARY | 0 or 1 | Can be null | | SUMMARY | 0 or 1 | Can be null |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| RECURRENCE-ID | 0 | | | RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.5.3. CANCEL 3.5.3. CANCEL
skipping to change at page 61, line 5 skipping to change at page 62, line 35
b. individual recurrence instances may be cancelled by specifying b. individual recurrence instances may be cancelled by specifying
multiple "VJOURNAL" components with a "RECURRENCE-ID" property multiple "VJOURNAL" components with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled corresponding to one of the instances to be cancelled
When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+-----------------------------------------------+
| Constraints for a METHOD:CANCEL of a VJOURNAL |
+-----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "CANCEL" | | METHOD | 1 | MUST be "CANCEL" |
| | | | | | | |
| VJOURNAL | 1+ | All MUST have the same UID | | VJOURNAL | 1+ | All MUST have the same UID |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | | | SEQUENCE | 1 | |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | REQUEST |
| ATTACH | 0+ | | | ATTACH | 0+ | |
| ATTENDEE | 0+ | | | ATTENDEE | 0 | |
| CATEGORIES | 0+ | | | CATEGORIES | 0+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| CREATED | 0 or 1 | | | CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | | | DESCRIPTION | 0 or 1 | |
| DTSTART | 0 or 1 | | | DTSTART | 0 or 1 | |
| EXDATE | 0+ | | | EXDATE | 0+ | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | only if referring to an instance | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar | | | | of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RRULE | 0+ | | | RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be present, must be | | STATUS | 0 or 1 | MAY be present, must be |
| | | "CANCELLED" if present | | | | "CANCELLED" if present |
| SUMMARY | 0 or 1 | | | SUMMARY | 0 or 1 | |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VALARM | 0 | |
| | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.6. Status Replies 3.6. Status Replies
The "REQUEST-STATUS" property is used to convey status information The "REQUEST-STATUS" property is used to convey status information
skipping to change at page 62, line 25 skipping to change at page 64, line 26
This specification allows for multiple "REQUEST-STATUS" properties to This specification allows for multiple "REQUEST-STATUS" properties to
be returned in iCalendar components in the appropriate iTIP messages. be returned in iCalendar components in the appropriate iTIP messages.
When multiple "REQUEST-STATUS" properties are present, the following When multiple "REQUEST-STATUS" properties are present, the following
restrictions apply: restrictions apply:
1. Within any one component, the "top-level" numeric value of the 1. Within any one component, the "top-level" numeric value of the
"short return status code" MUST be the same for all REQUEST- "short return status code" MUST be the same for all REQUEST-
STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx
and 5.xx codes within a single component. and 5.xx codes within a single component.
2. Across all components in the iTIP message, the following applies: 2. Across all components in the iTIP message, the following applies:
A. If any one component would have a 3.xx code, then all A. If any one component would have a 5.xx code, then all
components MUST have a code in that range or "REQUEST-STATUS"
MUST NOT be present in the other components if a 3.xx code is
not appropriate for those components.
B. If any one component would have a 5.xx code, then all
components MUST have a code in that range or "REQUEST-STATUS" components MUST have a code in that range or "REQUEST-STATUS"
MUST NOT be present in the other components if a 5.xx code is MUST NOT be present in the other components if a 5.xx code is
not appropriate for those components. This rule overrides not appropriate for those components.
(a) above. B. Otherwise, if any one component would have a 3.xx code, then
all components MUST have a code in that range or "REQUEST-
STATUS" MUST NOT be present in the other components if a 3.xx
code is not appropriate for those components.
C. 2.xx and 4.xx codes can be used in different components C. 2.xx and 4.xx codes can be used in different components
provided that each component follows the restriction in (1) provided that each component follows the restriction in (1)
above. above.
The following "REQUEST-STATUS" codes are defined: The following "REQUEST-STATUS" codes are defined (any "Offending
Data" MAY be specified in the "REQUEST-STATUS" value as the extdata
field):
+----------+------------------------+-------------------------------+ +----------+------------------------+-------------------------------+
| Short | Longer Return Status | Offending Data | | Short | Longer Return Status | Offending Data |
| Return | Description | | | Return | Description | |
| Status | | | | Status | | |
| Code | | | | Code | | |
+----------+------------------------+-------------------------------+ +----------+------------------------+-------------------------------+
| 2.0 | Success. | None. | | 2.0 | Success. | None. |
| | | | | | | |
| 2.1 | Success but fallback | Property name and value MAY | | 2.1 | Success but fallback | Property name and value MAY |
skipping to change at page 64, line 40 skipping to change at page 66, line 44
| | | | | | | |
| 3.11 | Required component or | Component or property name | | 3.11 | Required component or | Component or property name |
| | property missing. | MAY be specified. | | | property missing. | MAY be specified. |
| | | | | | | |
| 3.12 | Unknown component or | Component or property name | | 3.12 | Unknown component or | Component or property name |
| | property found | MAY be specified | | | property found | MAY be specified |
| | | | | | | |
| 3.13 | Unsupported component | Component or property name | | 3.13 | Unsupported component | Component or property name |
| | or property found | MAY be specified | | | or property found | MAY be specified |
| | | | | | | |
| 3.14 | Unsupported capability | Method or action MAY be | | 3.14 | Unsupported capability | METHOD or action MAY be |
| | | specified | | | | specified |
| | | | | | | |
| 4.0 | Event conflict. | DTSTART and DTEND property | | 4.0 | Event conflict. | DTSTART and DTEND property |
| | Date/time is busy. | name and values MAY be | | | Date/time is busy. | name and values MAY be |
| | | specified. | | | | specified. |
| | | | | | | |
| 5.0 | Request MAY supported. | Method property value MAY be | | 5.0 | Request not supported. | METHOD property value MAY be |
| | | specified. | | | | specified. |
| | | | | | | |
| 5.1 | Service unavailable. | ATTENDEE property value MAY | | 5.1 | Service unavailable. | ATTENDEE property value MAY |
| | | be specified. | | | | be specified. |
| | | | | | | |
| 5.2 | Invalid calendar | ATTENDEE property value MAY | | 5.2 | Invalid calendar | ATTENDEE property value MAY |
| | service. | be specified. | | | service. | be specified. |
| | | | | | | |
| 5.3 | No scheduling support | ATTENDEE property value MAY | | 5.3 | No scheduling support | ATTENDEE property value MAY |
| | for user. | be specified. | | | for user. | be specified. |
skipping to change at page 65, line 26 skipping to change at page 67, line 31
iCalendar includes a recurrence grammar to represent recurring iCalendar includes a recurrence grammar to represent recurring
events. The benefit of such a grammar is the ability to represent a events. The benefit of such a grammar is the ability to represent a
number of events in a single object. However, while this simplifies number of events in a single object. However, while this simplifies
creation of a recurring event, meeting instances still need to be creation of a recurring event, meeting instances still need to be
referenced. For instance, an "Attendee" may decline the third referenced. For instance, an "Attendee" may decline the third
instance of a recurring Friday event. Similarly, the "Organizer" may instance of a recurring Friday event. Similarly, the "Organizer" may
change the time or location to a single instance of the recurring change the time or location to a single instance of the recurring
event. event.
Since implementations may elect to store recurring events as either a Since implementations may elect to store recurring events as either a
single event object or a collection of discreet, related event single event object or a collection of discrete, related event
objects, the protocol is designed so that each recurring instance may objects, the protocol is designed so that each recurring instance may
be both referenced and versioned. Hence, implementations that choose be both referenced and versioned. Hence, implementations that choose
to maintain per-instance properties (such as "ATTENDEE" property to maintain per-instance properties (such as "ATTENDEE" property
"PARTSTAT" parameter) may do so. However, the protocol does not "PARTSTAT" parameter) may do so. However, the protocol does not
require per-instance recognition unless the instance itself must be require per-instance recognition unless the instance itself must be
renegotiated. renegotiated.
The scenarios for recurrence instance referencing are listed below. The scenarios for recurrence instance referencing are listed below.
For purposes of simplification a change to an event refers to a For purposes of simplification a change to an event refers to a
"trigger property." That is, a property that has a substantive "trigger property." That is, a property that has a substantive
skipping to change at page 66, line 6 skipping to change at page 68, line 10
o "Organizer" deletes or changes a single instance of a recurring o "Organizer" deletes or changes a single instance of a recurring
event event
o "Organizer" makes changes that affect all future instances o "Organizer" makes changes that affect all future instances
o "Organizer" makes changes that affect all previous instances o "Organizer" makes changes that affect all previous instances
o "Organizer" deletes or modifies a previously changed instance o "Organizer" deletes or modifies a previously changed instance
"Attendee" initiated actions: "Attendee" initiated actions:
o "Attendee" changes status for a particular recurrence instance o "Attendee" changes status for a particular recurrence instance
o "Attendee" sends Event-Counter for a particular recurrence o "Attendee" sends event-Counter for a particular recurrence
instance instance
An instance of a recurring event is assigned a unique identification, An instance of a recurring event is assigned a unique identification,
"RECURRENCE-ID" property, when that instance is renegotiated. "RECURRENCE-ID" property, when that instance is renegotiated.
Negotiation may be necessary when a substantive change to the event Negotiation may be necessary when a substantive change to the event
or to-do has be made (such as changing the start time, end time, due or to-do has been made (such as changing the start time, end time,
date or location). The "Organizer" can identify a specific due date or location). The "Organizer" can identify a specific
recurrence instance using the "RECURRENCE-ID" property. The property recurrence instance using the "RECURRENCE-ID" property. The property
value is equal to the date/time of the instance. If the "Organizer" value is equal to the date/time of the instance. If the "Organizer"
wishes to change the "DTSTART", the original "DTSTART" value is used wishes to change the "DTSTART", the original unmodified "DTSTART"
for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values value of the instance is used as the value "RECURRENCE-ID" property
reflect the change. Note that after the change has occurred, the and the new "DTSTART" and "DTEND" values reflect the change.
"RECURRENCE-ID" has changed to the new "DTSTART" value.
3.7.2. Attendee Property Considerations 3.7.2. Attendee Property Considerations
The "ORGANIZER" property is required on published events, to-dos, and The "ORGANIZER" property is required on published events, to-dos, and
journal entries for two reasons. First, only the "Organizer" is journal entries for two reasons. First, only the "Organizer" is
allowed to update and redistribute an event or to-do component. It allowed to update and redistribute an event or to-do component. It
follows that the "ORGANIZER" property MUST be present in the event, follows that the "ORGANIZER" property MUST be present in the event,
to-do, or journal entry component so that the CUA has a basis for to-do, or journal entry component so that the CUA has a basis for
authorizing an update. Second, it is prudent to provide a point of authorizing an update. Second, it is prudent to provide a point of
contact for anyone who receives a published component in case of contact for anyone who receives a published component in case of
skipping to change at page 66, line 48 skipping to change at page 69, line 4
It is recommended that the general approach to finding a "Calendar It is recommended that the general approach to finding a "Calendar
User" in an attendee list be as follows: User" in an attendee list be as follows:
1. Search for the "Calendar User" in the attendee list where 1. Search for the "Calendar User" in the attendee list where
"CUTYPE=INDIVIDUAL" "CUTYPE=INDIVIDUAL"
2. Failing (1) look for attendees where "CUTYPE=GROUP" or 2. Failing (1) look for attendees where "CUTYPE=GROUP" or
'CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User" 'CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User"
is a member of one of these groups. If so, the "REPLY" method is a member of one of these groups. If so, the "REPLY" method
sent to the "Organizer" MUST contain a new "ATTENDEE" property in sent to the "Organizer" MUST contain a new "ATTENDEE" property in
which: which:
3. 3.
* the "TYPE" property parameter is set to INDIVIDUAL * the "TYPE" property parameter is set to INDIVIDUAL
* the "MEMBER" property parameter is set to the name of the * the "MEMBER" property parameter is set to the name of the
group group
4. Failing (2) the CUA MAY ignore or accept the request as the 4. Failing (2) the CUA MAY ignore or accept the request as the
"Calendar User" wishes. "Calendar User" wishes.
3.7.3. X-Tokens 3.7.3. Extension Tokens
To make iCalendar objects extensible, new property types MAY be To make iCalendar objects extensible, new component, property or
inserted into components. These properties are called X-Tokens as property parameters can be used. Two types of extension exist: IANA
they are prefixed with "X-". A client is not required to make sense registered tokens and X- vendor-specific tokens. A client SHOULD
of X-Tokens. Clients are not required to save X-Tokens or use them save IANA tokens and MAY use them in replies. A client MAY save X-
in replies. Tokens and MAY use them in replies. When delegating or forwarding
messages to other CUs, a client SHOULD include IANA and X- tokens.
4. Examples 4. Examples
4.1. Published Event Examples 4.1. Published Event Examples
In the calendaring and scheduling context, publication refers to the In the calendaring and scheduling context, publication refers to the
one way transfer of event information. Consumers of published events one way transfer of event information. Consumers of published events
simply incorporate the event into a calendar. No reply is expected. simply incorporate the event into a calendar. No reply is expected.
Individual "A" publishes an event. Individual "B" reads the event Individual "A" publishes an event. Individual "B" reads the event
and incorporates it into their calendar. Events are published in and incorporates it into their calendar. Events are published in
several ways including: embedding the event as an object in a web several ways including: embedding the event as an object in a web
page, e- mailing the event to a distribution list, and posting the page, e-mailing the event to a distribution list, or posting the
event to a newsgroup. event to a newsgroup.
The table below illustrates the sequence of events between the The table below illustrates the sequence of events between the
publisher and the consumers of a published event. publisher and the consumers of a published event.
+-----------------+-----------------------+-------------------------+ +-----------------+-----------------------+-------------------------+
| Action | Organizer | Receiver | | Action | Organizer | Receiver |
+-----------------+-----------------------+-------------------------+ +-----------------+-----------------------+-------------------------+
| Publish an | "A" sends or posts a | "B" reads a published | | Publish an | "A" sends or posts a | "B" reads a published |
| event | PUBLISH message | event | | event | PUBLISH message | event |
skipping to change at page 71, line 51 skipping to change at page 74, line 12
| | | to "ACCEPTED" | | | | to "ACCEPTED" |
| | | | | | | |
| Decline the | | "C" sends a REPLY message | | Decline the | | "C" sends a REPLY message |
| meeting | | to "A" with its ATTENDEE | | meeting | | to "A" with its ATTENDEE |
| request | | "PARTSTAT" parameter set | | request | | "PARTSTAT" parameter set |
| | | to "DECLINED" | | | | to "DECLINED" |
| | | | | | | |
| Tentatively | | "D" sends a REPLY message | | Tentatively | | "D" sends a REPLY message |
| accept the | | to "A" with its ATTENDEE | | accept the | | to "A" with its ATTENDEE |
| meeting | | "PARTSTAT" parameter set | | meeting | | "PARTSTAT" parameter set |
| request | | to "tentative" | | request | | to "TENTATIVE" |
| | | | | | | |
| Confirm | "A" sends a REQUEST | | | Confirm | "A" sends a REQUEST | |
| meeting | message to "B" and | | | meeting | message to "B" and | |
| status with | "D" with updated | | | status with | "D" with updated | |
| attendees | information. | | | attendees | information. | |
+--------------+-----------------------+----------------------------+ +--------------+-----------------------+----------------------------+
4.2.1. A Group Event Request 4.2.1. A Group Event Request
A sample meeting request is sent from "A" to "B", "C", and "D". "E" A sample meeting request is sent from "A" to "B", "C", and "D". "E"
skipping to change at page 72, line 36 skipping to change at page 74, line 45
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com
ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T200000Z DTSTART:19970701T200000Z
DTEND:19970701T2000000Z DTEND:19970701T2100000Z
SUMMARY:Conference SUMMARY:Conference
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.2. Reply To A Group Event Request 4.2.2. Reply To A Group Event Request
Attendee "B" accepts the meeting. Attendee "B" accepts the meeting.
skipping to change at page 75, line 15 skipping to change at page 77, line 40
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:COUNTER METHOD:COUNTER
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
DTSTART:19970701T160000Z DTSTART:19970701T160000Z
DTEND:19970701T190000Z DTEND:19970701T170000Z
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
SUMMARY:Discuss the Merits of the election results SUMMARY:Discuss the Merits of the election results
LOCATION:Green Conference Room LOCATION:Blue Conference Room
COMMENT:This time works much better and I think the big conference COMMENT:This time works much better and I think the big conference
room is too big room is too big
UID:calsrv.example.com-873970198738777a@example.com UID:calsrv.example.com-873970198738777a@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970611T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"A" accepts the changes from "B". To accept a counter-proposal, the "A" accepts the changes from "B". To accept a counter-proposal, the
"Organizer" sends a new event "REQUEST" with an incremented sequence "Organizer" sends a new event "REQUEST" with an incremented sequence
number. number.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
skipping to change at page 75, line 42 skipping to change at page 78, line 19
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
DTSTART:19970701T160000Z DTSTART:19970701T160000Z
DTEND:19970701T190000Z DTEND:19970701T170000Z
SUMMARY:Discuss the Merits of the election results - changed to SUMMARY:Discuss the Merits of the election results - changed to
meet B's schedule meet B's schedule
LOCATION:Green Conference Room LOCATION:Blue Conference Room
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1 SEQUENCE:1
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Instead, "A" rejects "B's" counter proposal Instead, "A" rejects "B's" counter proposal
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:DECLINECOUNTER METHOD:DECLINECOUNTER
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
COMMENT:Sorry, I cannot change this meeting time COMMENT:Sorry, I cannot change this meeting time
skipping to change at page 76, line 31 skipping to change at page 79, line 16
When delegating an event request to another "Calendar User", the When delegating an event request to another "Calendar User", the
"Delegator" must both update the "Organizer" with a "REPLY" and send "Delegator" must both update the "Organizer" with a "REPLY" and send
a request to the "Delegate". There is currently no protocol a request to the "Delegate". There is currently no protocol
limitation to delegation depth. It is possible for the original limitation to delegation depth. It is possible for the original
delegate to delegate the meeting to someone else, and so on. When a delegate to delegate the meeting to someone else, and so on. When a
request is delegated from one CUA to another there are a number of request is delegated from one CUA to another there are a number of
responsibilities required of the "Delegator". The "Delegator" MUST: responsibilities required of the "Delegator". The "Delegator" MUST:
o Send a "REPLY" to the "Organizer" with the following updates: o Send a "REPLY" to the "Organizer" with the following updates:
o The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter set to A. The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter set
"DELEGATED" and the "DELEGATED-TO" parameter is set to the address to "DELEGATED" and the "DELEGATED-TO" parameter is set to the
of the "Delegate" address of the "Delegate"
o Add an additional "ATTENDEE" property for the "Delegate" with the B. Add an additional "ATTENDEE" property for the "Delegate" with
"DELEGATED-FROM" property parameter set to the "Delegator" the "DELEGATED-FROM" property parameter set to the "Delegator"
o Indicate whether they want to continue to receive updates when the C. Indicate whether they want to continue to receive updates when
"Organizer" sends out updated versions of the event. Setting the the "Organizer" sends out updated versions of the event.
"RSVP" property parameter to "TRUE" will cause the updates to be Setting the "RSVP" property parameter to "TRUE" will cause the
sent, setting it to "FALSE" causes no further updates to be sent. updates to be sent, setting it to "FALSE" causes no further
Note that in either case, if the "Delegate" declines the updates to be sent. Note that in either case, if the
invitation the "Delegator" will be notified. "Delegate" declines the invitation the "Delegator" will be
notified.
o The "Delegator" MUST also send a copy of the original "REQUEST" o The "Delegator" MUST also send a copy of the original "REQUEST"
method to the "Delegate". method to the "Delegate", with changes (A) and (B) as detailed
above applied.
It is not required that the "Delegate" include the "Delegator" in If the "Delegate" declines the meeting, the "Organizer" MUST send an
their "REPLY" method. However, it is strongly advised since this update "REQUEST" to the "Delegator" so that the "Delegator" may elect
will inform the "Delegator" whether the "Delegate" plans to attend to delegate the "REQUEST" to another CUA.
the meeting. [Editors note: How so?] If the "Delegate" declines the
meeting, the "Delegator" may elect to delegate the "REQUEST" to
another CUA. The process is the same.
+-----------------+----------------+--------------------------------+ +-----------------+----------------+--------------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+-----------------+----------------+--------------------------------+ +-----------------+----------------+--------------------------------+
| Initiate a | "A" sends a | | | Initiate a | "A" sends a | |
| meeting request | REQUEST | | | meeting request | REQUEST | |
| | message to "B" | | | | message to "B" | |
| | and "C" | | | | and "C" | |
| | | | | | | |
| Delegate: "C" | | "C" sends a REPLY to "A" with | | Delegate: "C" | | "C" sends a REPLY to "A" with |
skipping to change at page 80, line 38 skipping to change at page 83, line 33
END:VCALENDAR END:VCALENDAR
4.2.8. Forwarding an Event Request 4.2.8. Forwarding an Event Request
The protocol does not prevent an "Attendee" from "forwarding" an The protocol does not prevent an "Attendee" from "forwarding" an
"VEVENT" calendar component to other "Calendar Users". Forwarding "VEVENT" calendar component to other "Calendar Users". Forwarding
differs from delegation in that the forwarded "Calendar User" (often differs from delegation in that the forwarded "Calendar User" (often
referred to as a "Party Crasher") does not replace the forwarding referred to as a "Party Crasher") does not replace the forwarding
"Calendar User". Implementations are not required to add the "Party "Calendar User". Implementations are not required to add the "Party
Crasher" to the "Attendee" list and hence there is no guarantee that Crasher" to the "Attendee" list and hence there is no guarantee that
a "Party Crasher" will receive additional updates to the Event. The a "Party Crasher" will receive additional updates to the event. The
forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the
attendee list. The "Organizer" MAY add the forwarded "Calendar User" attendee list. The "Organizer" MAY add the forwarded "Calendar User"
to the attendee list. to the attendee list.
4.2.9. Cancel A Group Event 4.2.9. Cancel A Group Event
Individual "A" requests a meeting between individuals "A", "B", "C", Individual "A" requests a meeting between individuals "A", "B", "C",
and "D". Individual "B" declines attendance to the meeting. and "D". Individual "B" declines attendance to the meeting.
Individual "A" decides to cancel the meeting. The following table Individual "A" decides to cancel the meeting. The following table
illustrates the sequence of messages that would be exchanged between illustrates the sequence of messages that would be exchanged between
skipping to change at page 82, line 11 skipping to change at page 85, line 5
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.10. Removing Attendees 4.2.10. Removing Attendees
"A" wants to remove "B" from a meeting. This is done by sending a "A" wants to remove "B" from a meeting. This is done by sending a
"CANCEL" to "B" and removing "B" from the attendee list in the master "CANCEL" to "B" and removing "B" from the attendee list in the master
copy of the event. copy of the event.
+---------------------+--------------------------------+------------+ +-------------------+----------------------------------+------------+
| Action | "Organizer" | "Attendee" | | Action | "Organizer" | "Attendee" |
+---------------------+--------------------------------+------------+ +-------------------+----------------------------------+------------+
| Remove an "B" as an | "A" sends a CANCEL message to | | | Remove "B" as an | "A" sends a CANCEL message to | |
| "Attendee" | "B" | | | "Attendee" | "B" | |
| | | | | | | |
| Update the master | "A" sends the updated event to | | | Update the master | "A" optionally sends the updated | |
| copy of the event | the remaining "Attendees" | | | copy of the event | event to the remaining | |
+---------------------+--------------------------------+------------+ | | "Attendees" | |
+-------------------+----------------------------------+------------+
The original meeting includes "A", "B", "C", and "D". The example The original meeting includes "A", "B", "C", and "D". The example
below shows the "CANCEL" that "A" sends to "B". Note that in the below shows the "CANCEL" that "A" sends to "B". Note that in the
example below the "STATUS" property is omitted. This is used when example below the "STATUS" property is omitted. This is used when
the meeting itself is cancelled and not when the intent is to remove the meeting itself is cancelled and not when the intent is to remove
an "Attendee" from the Event. an "Attendee" from the event.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:CANCEL METHOD:CANCEL
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
COMMENT:You're off the hook for this meeting COMMENT:You're off the hook for this meeting
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
skipping to change at page 84, line 33 skipping to change at page 87, line 33
4.3. Busy Time Examples 4.3. Busy Time Examples
Busy time objects can be used in several ways. First, a CU may Busy time objects can be used in several ways. First, a CU may
request busy time from another CU for a specific range of time. That request busy time from another CU for a specific range of time. That
request can be answered with a busy time Reply. Additionally, a CU request can be answered with a busy time Reply. Additionally, a CU
may simply publish their busy time for a given interval and point may simply publish their busy time for a given interval and point
other CUs to the published location. The following examples outline other CUs to the published location. The following examples outline
both scenarios. both scenarios.
4.3.1. Publish Busy Time
Individual "A" publishes busy time for one week. Individual "A" publishes busy time for one week.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
METHOD:PUBLISH METHOD:PUBLISH
BEGIN:VFREEBUSY BEGIN:VFREEBUSY
DTSTAMP:19980101T124100Z DTSTAMP:19980101T124100Z
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
DTSTART:19980101T124200Z DTSTART:19980101T124200Z
DTEND:19980107T124200Z DTEND:19980108T124200Z
FREEBUSY:19980101T180000Z/19980101T190000Z FREEBUSY:19980101T180000Z/19980101T190000Z
FREEBUSY:19980103T020000Z/19980103T050000Z FREEBUSY:19980103T020000Z/19980103T050000Z
FREEBUSY:19980107T020000Z/19980107T050000Z FREEBUSY:19980107T020000Z/19980107T050000Z
FREEBUSY:19980113T000000Z/19980113T010000Z FREEBUSY:19980113T000000Z/19980113T010000Z
FREEBUSY:19980115T190000Z/19980115T200000Z FREEBUSY:19980115T190000Z/19980115T200000Z
FREEBUSY:19980115T220000Z/19980115T230000Z FREEBUSY:19980115T220000Z/19980115T230000Z
FREEBUSY:19980116T013000Z/19980116T043000Z FREEBUSY:19980116T013000Z/19980116T043000Z
END:VFREEBUSY END:VFREEBUSY
END:VCALENDAR END:VCALENDAR
4.3.2. Request Busy Time
Individual "A" requests busy time from individuals "B", "C". Individual "A" requests busy time from individuals "B", "C".
Individual "B" and "C" replies with busy time data to individual "A". Individual "B" and "C" replies with busy time data to individual "A".
The following table illustrates the sequence of messages that would The following table illustrates the sequence of messages that would
be exchanged between these individuals. be exchanged between these individuals.
+----------------------+--------------------+-----------------------+ +----------------------+--------------------+-----------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+----------------------+--------------------+-----------------------+ +----------------------+--------------------+-----------------------+
| Initiate a busy time | "A" sends | | | Initiate a busy time | "A" sends | |
| request | "REQUEST" message | | | request | "REQUEST" message | |
| | to "B" and "C" | | | | to "B" and "C" | |
| | | | | | | |
| Reply to the "BUSY" | | "B" sends a "REPLY" | | Reply to the "BUSY" | | "B" sends a "REPLY" |
| request with "BUSY" | | message to "A" with | | request with "BUSY" | | message to "A" with |
| time data | | busy time data | | time data | | busy time data |
+----------------------+--------------------+-----------------------+ +----------------------+--------------------+-----------------------+
4.3.1. Request Busy Time
"A" sends a "BUSY-REQUEST" to "B" and "C" for busy time "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VFREEBUSY BEGIN:VFREEBUSY
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
ATTENDEE:mailto:c@example.com ATTENDEE:mailto:c@example.com
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
DTSTART:19970701T080000Z DTSTART:19970701T080000Z
DTEND:19970701T200000 DTEND:19970701T200000
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
END:VFREEBUSY END:VFREEBUSY
END:VCALENDAR END:VCALENDAR
4.3.2. Reply To A Busy Time Request 4.3.3. Reply To A Busy Time Request
"B" sends a "REPLY" method type of a "VFREEBUSY" calendar component "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component
to "A" to "A"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VFREEBUSY BEGIN:VFREEBUSY
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
skipping to change at page 87, line 36 skipping to change at page 90, line 36
END:VTIMEZONE END:VTIMEZONE
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED; ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;
CUTYPE=INDIVIDUAL:a@example.com CUTYPE=INDIVIDUAL:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:b@example.fr ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:b@example.fr
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:c@example.jp ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:c@example.jp
DTSTAMP:19970613T190030Z DTSTAMP:19970613T190030Z
DTSTART;TZID=America-SanJose:19970701T140000 DTSTART;TZID=America-SanJose:19970701T140000
DTEND;TZID=America-SanJose:19970701T150000 DTEND;TZID=America-SanJose:19970701T150000
RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU
RDATE;TZID=America-SanJose:19970910T140000 RDATE;TZID=America-SanJose:19970910T140000
EXDATE;TZID=America-SanJose:19970909T140000 EXDATE;TZID=America-SanJose:19970909T140000
EXDATE;TZID=America-SanJose:19971028T140000 EXDATE;TZID=America-SanJose:19971028T140000
SUMMARY:Weekly Phone Conference SUMMARY:Weekly Phone Conference
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The first two components of this iCalendar object are the time zone The first component of this iCalendar object is the time zone
components. The "DTSTART" date coincides with the first instance of component. The "DTSTART" date coincides with the first instance of
the RRULE property. the RRULE property.
The recurring meeting is defined in a particular time zone, The recurring meeting is defined in a particular time zone,
presumably that of the originator. The client for each "Attendee" presumably that of the originator. The client for each "Attendee"
has the responsibility of determining the recurrence time in the has the responsibility of determining the recurrence time in the
"Attendee's" time zone. "Attendee's" time zone.
The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT. The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT
"Attendee" b@example.fr is in France where the local time on this (UTC-7). "Attendee" B@example.fr is in France where the local time
date is 9 hours ahead of PDT or 23:00. "Attendee" c@example.jp is in on this date is 9 hours ahead of PDT or 23:00 CEST (UTC+2).
Japan where local time is 8 hours ahead of UTC or Wednesday, July 2 "Attendee" C@example.jp is in Japan where local time is 16 hours
at 06:00. The event repeats weekly on Tuesdays (in PST/PDT). The ahead of PDT or Wednesday, July 2 at 06:00 JST (UTC+9). The event
"RRULE" property results in 20 instances. The last instance falls on repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property
Tuesday, November 11, 1997 2:00pm PDT. The "RDATE" property adds results in 20 instances. The last instance falls on Tuesday,
another instance: WED, 10-SEP-1997 2:00 PM PST. November 11, 1997 2:00pm PST. The "RDATE" property adds another
instance: WED, 10-SEP-1997 2:00 PM PDT.
There are two exceptions to this recurring appointment. The first There are also two exception dates to the recurrence rule. The first
one is: one is:
o TUE, 09-SEP-1997 23:00 GMT o TUE, 09-SEP-1997 14:00 PDT (UTC-7)
o TUE, 09-SEP-1997 14:00 PDT o TUE, 09-SEP-1997 23:00 CEST (UTC+2)
o WED, 10-SEP-1997 06:00 JST o WED, 10-SEP-1997 06:00 JST (UTC+9)
and the second is: and the second is:
o TUE, 28-OCT-1997 23:00 GMT o TUE, 28-OCT-1997 14:00 PST (UTC-8)
o TUE, 28-OCT-1997 14:00 PST o TUE, 28-OCT-1997 23:00 CET (UTC+1)
o WED, 29-OCT-1997 06:00 JST o WED, 29-OCT-1997 07:00 JST (UTC+9)
4.4.2. Modify A Recurring Instance 4.4.2. Modify A Recurring Instance
In this example the "Organizer" issues a recurring meeting. Later In this example the "Organizer" issues a recurring meeting. Later
the "Organizer" changes an instance of the event by changing the the "Organizer" changes an instance of the event by changing the
"DTSTART" property. Note the use of "RECURRENCE-ID" property and "DTSTART" property. Note the use of "RECURRENCE-ID" property and
"SEQUENCE" property in the second request. "SEQUENCE" property in the second request.
Original Request: Original Request:
skipping to change at page 100, line 39 skipping to change at page 103, line 39
Response from "B" to indicate that RRULE is not supported and an Response from "B" to indicate that RRULE is not supported and an
unrecognized property was encountered unrecognized property was encountered
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single
event;RRULE
REQUEST-STATUS:3.0;Invalid Property Name;FOO REQUEST-STATUS:3.0;Invalid Property Name;FOO
UID:guid-1@example.com UID:guid-1@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970603T094000Z DTSTAMP:19970603T094000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.5. Group To-do Examples 4.5. Group To-do Examples
Individual "A" creates a group task in which individuals "A", "B", Individual "A" creates a group task in which individuals "A", "B",
skipping to change at page 102, line 27 skipping to change at page 105, line 27
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com
ATTENDEE;RSVP=TRUE:mailto:d@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com
DTSTART:19970701T170000Z DTSTART:19970701T170000Z
DUE:19970722T170000Z DUE:19970722T170000Z
PRIORITY:1 PRIORITY:1
SUMMARY:Create the requirements document SUMMARY:Create the requirements document
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970717T200000Z DTSTAMP:19970717T200000Z
STATUS:Needs Action STATUS:NEEDS-ACTION
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
4.5.2. A VTODO Reply 4.5.2. A VTODO Reply
"B" accepts the to-do. "B" accepts the to-do.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
skipping to change at page 104, line 35 skipping to change at page 107, line 35
overall completion for the to-do at 40%. overall completion for the to-do at 40%.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;PARTSTAT=IN-PROCESS;CUTYPE=INDIVIDUAL:mailto:d@example.com ATTENDEE;PARTSTAT=COMPLETED;CUTYPE=INDIVIDUAL:mailto:d@example.com
DTSTART:19970701T170000Z DTSTART:19970701T170000Z
DUE:19970722T170000Z DUE:19970722T170000Z
PRIORITY:1 PRIORITY:1
SUMMARY:Create the requirements document SUMMARY:Create the requirements document
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
SEQUENCE:1 SEQUENCE:1
DTSTAMP:19970718T100000Z DTSTAMP:19970718T100000Z
STATUS:IN-PROGRESS STATUS:IN-PROCESS
PERCENT-COMPLETE:40 PERCENT-COMPLETE:40
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
4.5.7. Recurring VTODOs 4.5.7. Recurring VTODOs
The following examples relate to recurring "VTODO" calendar The following examples relate to recurring "VTODO" calendar
components. components.
4.5.7.1. Request for a Recurring VTODO 4.5.7.1. Request for a Recurring VTODO
skipping to change at page 105, line 25 skipping to change at page 108, line 25
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com
RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
DTSTART:19980101T100000-0700 DTSTART:19980101T100000Z
DUE:19980103T100000-0700 DUE:19980103T100000Z
SUMMARY:Send Status Reports to Area Managers SUMMARY:Send Status Reports to Area Managers
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970717T200000Z DTSTAMP:19970717T200000Z
STATUS:NEEDS ACTION STATUS:NEEDS-ACTION
PRIORITY:1 PRIORITY:1
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
4.5.7.2. Calculating due dates in recurring VTODOs 4.5.7.2. Replying to an instance of a recurring VTODO
The due date in a recurring "VTODO" calendar component is either a
fixed interval specified in the "REQUEST" method or specified using
the "RECURRENCE-ID" property. The former is calculated by applying
the difference between "DTSTART" and "DUE" properties and applying it
to each of the start of each recurring instance. Hence, if the
initial "VTODO" calendar component specifies a "DTSTART" property
value of "19970701T190000Z" and a "DUE" property value of
"19970801T190000Z" the interval of one day which is applied to each
recurring instance of the "VTODO" calendar component to determine the
"DUE" date of the instance.
4.5.7.3. Replying to an instance of a recurring VTODO
In this example "B" updates "A" on a single instance of the "VTODO" In this example "B" updates "A" on a single instance of the "VTODO"
calendar component. calendar component.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com
skipping to change at page 106, line 36 skipping to change at page 109, line 31
The iCalendar object below describes a single journal entry for The iCalendar object below describes a single journal entry for
October 2, 1997. The "RELATED-TO" property references the phone October 2, 1997. The "RELATED-TO" property references the phone
conference event for which minutes were taken. conference event for which minutes were taken.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:PUBLISH METHOD:PUBLISH
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VJOURNAL BEGIN:VJOURNAL
DTSTART:19971002T200000Z DTSTART:19971002T200000Z
DTSTAMP:19970717T233100Z
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
SUMMARY:Phone conference minutes SUMMARY:Phone conference minutes
DESCRIPTION:The editors meeting was held on October 1, 1997. DESCRIPTION:The editors meeting was held on October 1, 1997.
Details are in the attached document. Details are in the attached document.
UID:0981234-1234234-2410@example.com UID:0981234-1234234-2410@example.com
RELATED-TO:0981234-1234234-2402-35@example.com RELATED-TO:0981234-1234234-2402-35@example.com
ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt
END:VJOURNAL END:VJOURNAL
END:VCALENDAR END:VCALENDAR
4.7. Other Examples 4.7. Other Examples
4.7.1. Event Refresh 4.7.1. Event Refresh
Refresh the event with "UID" property value of "guid-1- Refresh the event with "UID" property value of
12345@example.com": "guid-1-12345@example.com":
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REFRESH METHOD:REFRESH
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
ATTENDEE:mailto:c@example.com ATTENDEE:mailto:c@example.com
ATTENDEE:mailto:d@example.com ATTENDEE:mailto:d@example.com
UID: guid-1-12345@example.com UID: guid-1-12345@example.com
DTSTAMP:19970603T094000 DTSTAMP:19970603T094000
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.7.2. Bad RECURRENCE-ID 4.7.2. Bad RECURRENCE-ID
Component instances are identified by the combination of "UID", Component instances are identified by the combination of "UID",
"RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends an iTIP
to an "Attendee", there are three cases in which an instance cannot message to an "Attendee", there are three cases in which an instance
be found. They are: cannot be found. They are:
1. The component with the referenced "UID" and "RECURRENCE-ID" has 1. The component with the referenced "UID" and "RECURRENCE-ID" has
been found but the "SEQUENCE" number in the calendar store does been found but the "SEQUENCE" number in the calendar store does
not match that of the ITIP message. not match that of the ITIP message.
2. The component with the referenced "UID" has been found, the 2. The component with the referenced "UID" has been found, the
"SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
found. found.
3. The "UID" and "SEQUENCE" numbers are found but the CUA does not 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not
support recurrences. support recurrences.
skipping to change at page 108, line 33 skipping to change at page 111, line 26
| Update an instance | "A" sends | | | Update an instance | "A" sends | |
| request | "REQUEST" message | | | request | "REQUEST" message | |
| | to "B" | | | | to "B" | |
| | | | | | | |
| Attendee requests | | "B" sends a | | Attendee requests | | "B" sends a |
| refresh because | | "REFRESH" message | | refresh because | | "REFRESH" message |
| "RECURRENCE-ID" was not | | to "A" | | "RECURRENCE-ID" was not | | to "A" |
| found | | | | found | | |
| | | | | | | |
| Refresh the entire | "A" sends the | | | Refresh the entire | "A" sends the | |
| Event | latest copy of the | | | event | latest copy of the | |
| | Event to "B" | | | | event to "B" | |
| | | | | | | |
| Attendee handles the | | "B" updates to the | | Attendee handles the | | "B" updates to the |
| request and updates the | | latest copy of the | | request and updates the | | latest copy of the |
| instance | | meeting. | | instance | | meeting. |
+-------------------------+--------------------+--------------------+ +-------------------------+--------------------+--------------------+
Request from "A": Request from "A":
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
skipping to change at page 110, line 26 skipping to change at page 113, line 26
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Method | Fallback | | Method | Fallback |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| PUBLISH | Required | | PUBLISH | Required |
| REQUEST | PUBLISH | | REQUEST | PUBLISH |
| REPLY | Required | | REPLY | Required |
| ADD | Required | | ADD | Required |
| CANCEL | Required | | CANCEL | Required |
| REFRESH | Required | | REFRESH | Required |
| COUNTER | Reply with Not Supported | | COUNTER | Reply with "Not Supported" |
| DECLINECOUNTER | Required if EVENT-COUNTER is implemented; | | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs, |
| | otherwise reply with Not Supported | | | otherwise reply with "Not Supported" |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| iCalendar | Fallback | | iCalendar | Fallback |
| Property | | | Property | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| CALSCALE | Ignore; assume GREGORIAN | | CALSCALE | Ignore - assume GREGORIAN |
| PRODID | Ignore | | PRODID | Ignore |
| METHOD | Required as described in the Method list above | | METHOD | Required as described in the Method list above |
| VERSION | Ignore | | VERSION | Ignore |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Event-Related | Fallback | | Event-Related | Fallback |
| Components | | | Components | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| VALARM | Reply with Not Supported | | VALARM | Reply with "Not Supported" |
| VTIMEZONE | Required if any DateTime value refers to a time | | VTIMEZONE | Required if any DateTime value refers to a time |
| | zone. | | | zone. |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Component | Fallback | | Component | Fallback |
| Property | | | Property | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| ATTACH | Ignore | | ATTACH | Ignore |
| ATTENDEE | Required if EVENT-REQUEST is not implemented; | | ATTENDEE | Required if METHOD is REQUEST, otherwise ignore |
| | otherwise reply with Not Supported |
| CATEGORIES | Ignore | | CATEGORIES | Ignore |
| CLASS | Ignore | | CLASS | Ignore |
| COMMENT | Ignore | | COMMENT | Ignore |
| COMPLETED | Ignore | | COMPLETED | Ignore |
| CONTACT | Ignore | | CONTACT | Ignore |
| CREATED | Ignore | | CREATED | Ignore |
| DESCRIPTION | Required | | DESCRIPTION | Ignore |
| DURATION | Reply with Not Supported | | DURATION | Reply with "Not Supported" |
| DTSTAMP | Required | | DTSTAMP | Required |
| DTSTART | Required | | DTSTART | Required |
| DTEND | Required | | DTEND | Required |
| EXDATE | Ignore | | EXDATE | Ignore |
| GEO | Ignore | | GEO | Ignore |
| LAST-MODIFIED | Ignore | | LAST-MODIFIED | Ignore |
| LOCATION | Required | | LOCATION | Required |
| ORGANIZER | Ignore | | ORGANIZER | Required if METHOD is REQUEST, otherwise ignore |
| PRIORITY | Ignore | | PRIORITY | Ignore |
| RELATED-TO | Ignore | | RELATED-TO | Ignore |
| RDATE | Ignore | | RDATE | Ignore |
| RRULE | Ignore. The first instance occurs on the | | RRULE | Ignore - assume the first instance occurs on |
| | DTStart property. If implemented, VTIMEZONE | | | the DTSTART property. If implemented, |
| | MUST also be implemented. | | | VTIMEZONE MUST also be implemented. |
| RECURRENCE-ID | Required if RRULE is implemented; otherwise | | RECURRENCE-ID | Required if RRULE is implemented, otherwise |
| | Ignore | | | Ignore |
| REQUEST-STATUS | Required | | REQUEST-STATUS | Required |
| RESOURCES | Ignore | | RESOURCES | Ignore |
| SEQUENCE | Required | | SEQUENCE | Required |
| STATUS | Ignore | | STATUS | Ignore |
| SUMMARY | Ignore | | SUMMARY | Ignore |
| TRANSP | Required if FREEBUSY is implemented; otherwise | | TRANSP | Required if FREEBUSY is implemented, otherwise |
| | Ignore | | | Ignore |
| URL | Ignore | | URL | Ignore |
| UID | Required | | UID | Required |
| X- | Ignore | | X- | Ignore |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
5.1.2. Free/Busy-Related Fallbacks 5.1.2. Free/Busy-Related Fallbacks
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| Method | Fallback | | Method | Fallback |
skipping to change at page 112, line 25 skipping to change at page 115, line 25
| | returned. | | | returned. |
| REPLY | Implementations MAY ignore the METHOD type. The | | REPLY | Implementations MAY ignore the METHOD type. The |
| | REQUEST-STATUS "3.14;Unsupported capability" MUST be | | | REQUEST-STATUS "3.14;Unsupported capability" MUST be |
| | returned. | | | returned. |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| iCalendar | Fallback | | iCalendar | Fallback |
| Property | | | Property | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| CALSCALE | Ignore; assume GREGORIAN. | | CALSCALE | Ignore - assume GREGORIAN. |
| PRODID | Ignore | | PRODID | Ignore |
| METHOD | Required as described in the Method list above. | | METHOD | Required as described in the Method list above. |
| VERSION | Ignore | | VERSION | Ignore |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Component | Fallback | | Component | Fallback |
| Property | | | Property | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| ATTENDEE | Required if METHOD is REQUEST, otherwise ignore |
| COMMENT | Ignore | | COMMENT | Ignore |
| CONTACT | Ignore | | CONTACT | Ignore |
| DTEND | Required | | DTEND | Required |
| DTSTAMP | Required | | DTSTAMP | Required |
| DTSTART | Required | | DTSTART | Required |
| DURATION | Required | | DURATION | Ignore |
| FREEBUSY | Required | | FREEBUSY | Required |
| ORGANIZER | Ignore | | ORGANIZER | Required if METHOD is REQUEST, otherwise ignore |
| REQUEST-STATUS | Ignore | | REQUEST-STATUS | Ignore |
| UID | Required | | UID | Required |
| URL | Ignore | | URL | Ignore |
| X- | Ignore | | X- | Ignore |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
5.1.3. To-Do-Related Fallbacks 5.1.3. To-Do-Related Fallbacks
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Method | Fallback | | Method | Fallback |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| PUBLISH | Required | | PUBLISH | Required |
| REQUEST | PUBLISH | | REQUEST | PUBLISH |
| REPLY | Required | | REPLY | Required |
| ADD | Required | | ADD | Required |
| CANCEL | Required | | CANCEL | Required |
| REFRESH | Required | | REFRESH | Required |
| COUNTER | Reply with Not Supported | | COUNTER | Reply with "Not Supported" |
| DECLINECOUNTER | Required if VTODO - COUNTER is implemented; | | DECLINECOUNTER | Required if COUNTER for VTODOs is implemented, |
| | otherwise reply with Not Supported | | | otherwise reply with "Not Supported" |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| iCalendar | Fallback | | iCalendar | Fallback |
| Property | | | Property | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| CALSCALE | Ignore; assume GREGORIAN. | | CALSCALE | Ignore - assume GREGORIAN. |
| PRODID | Ignore | | PRODID | Ignore |
| METHOD | Required as described in the Method list above. | | METHOD | Required as described in the Method list above. |
| VERSION | Ignore | | VERSION | Ignore |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| To-Do-Related | Fallback | | To-Do-Related | Fallback |
| Components | | | Components | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| VALARM | Reply with Not Supported | | VALARM | Reply with "Not Supported" |
| VTIMEZONE | Required if any DateTime value refers to a time | | VTIMEZONE | Required if any DateTime value refers to a time |
| | zone. | | | zone. |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| Component | Fallback | | Component | Fallback |
| Property | | | Property | |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| ATTACH | Ignore | | ATTACH | Ignore |
| ATTENDEE | Required if REQUEST is not implemented; | | ATTENDEE | Required if METHOD is REQUEST, otherwise |
| | otherwise ignore | | | ignore |
| CATEGORIES | Ignore | | CATEGORIES | Ignore |
| CLASS | Ignore | | CLASS | Ignore |
| COMMENT | Ignore | | COMMENT | Ignore |
| COMPLETED | Required | | COMPLETED | Required |
| CONTACT | Ignore | | CONTACT | Ignore |
| CREATED | Ignore | | CREATED | Ignore |
| DESCRIPTION | Required | | DESCRIPTION | Required if METHOD is REQUEST, otherwise |
| | ignore |
| DUE | Required | | DUE | Required |
| DURATION | Ignore Reply with Not Supported | | DURATION | Ignore - reply with "Not Supported" |
| DTSTAMP | Required | | DTSTAMP | Required |
| DTSTART | Required | | DTSTART | Required |
| EXDATE | Ignore Reply with Not Supported | | EXDATE | Ignore - reply with "Not Supported" |
| LAST-MODIFIED | Ignore | | LAST-MODIFIED | Ignore |
| LOCATION | Ignore | | LOCATION | Ignore |
| ORGANIZER | Ignore | | ORGANIZER | Required if METHOD is REQUEST, otherwise |
| | ignore |
| PERCENT-COMPLETE | Ignore | | PERCENT-COMPLETE | Ignore |
| PRIORITY | Required | | PRIORITY | Required |
| RECURRENCE-ID | Ignore | | RECURRENCE-ID | Required if RRULE is implemented, otherwise |
| | Ignore |
| RELATED-TO | Ignore | | RELATED-TO | Ignore |
| REQUEST-STATUS | Ignore | | REQUEST-STATUS | Ignore |
| RDATE | Ignore | | RDATE | Ignore |
| RRULE | Ignore. The first instance occurs on the | | RRULE | Ignore - assume the first instance occurs on |
| | DTSTART property. If implemented, VTIMEZONE | | | the DTSTART property. If implemented, |
| | MUST also be implemented. | | | VTIMEZONE MUST also be implemented. |
| RESOURCES | Ignore | | RESOURCES | Ignore |
| SEQUENCE | Required | | SEQUENCE | Required |
| STATUS | Required | | STATUS | Required |
| SUMMARY | Ignore | | SUMMARY | Ignore |
| URL | Ignore | | URL | Ignore |
| UID | Required | | UID | Required |
| X- | Ignore | | X- | Ignore |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
5.1.4. Journal-Related Fallbacks 5.1.4. Journal-Related Fallbacks
skipping to change at page 115, line 25 skipping to change at page 118, line 25
| | returned. | | | returned. |
| CANCEL | Implementations MAY ignore the METHOD type. The | | CANCEL | Implementations MAY ignore the METHOD type. The |
| | REQUEST-STATUS "3.14;Unsupported capability" MUST be | | | REQUEST-STATUS "3.14;Unsupported capability" MUST be |
| | returned. | | | returned. |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| iCalendar | Fallback | | iCalendar | Fallback |
| Property | | | Property | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| CALSCALE | Ignore; assume GREGORIAN. | | CALSCALE | Ignore - assume GREGORIAN. |
| PRODID | Ignore | | PRODID | Ignore |
| METHOD | Required as described in the Method list above. | | METHOD | Required as described in the Method list above. |
| VERSION | Ignore | | VERSION | Ignore |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Journal-Related | Fallback | | Journal-Related | Fallback |
| Components | | | Components | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| VTIMEZONE | Required if any DateTime value refers to a time | | VTIMEZONE | Required if any DateTime value refers to a time |
| | zone | | | zone |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Component | Fallback | | Component | Fallback |
| Property | | | Property | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| ATTACH | Ignore | | ATTACH | Ignore |
| ATTENDEE | Required if JOURNAL-REQUEST is implemented; | | ATTENDEE | Ignore |
| | otherwise ignore |
| CATEGORIES | Ignore | | CATEGORIES | Ignore |
| CLASS | Ignore | | CLASS | Ignore |
| COMMENT | Ignore | | COMMENT | Ignore |
| CONTACT | Ignore | | CONTACT | Ignore |
| CREATED | Ignore | | CREATED | Ignore |
| DESCRIPTION | Required | | DESCRIPTION | Ignore |
| DTSTAMP | Required | | DTSTAMP | Required |
| DTSTART | Required | | DTSTART | Required |
| EXDATE | Ignore | | EXDATE | Ignore |
| LAST-MODIFIED | Ignore | | LAST-MODIFIED | Ignore |
| ORGANIZER | Ignore | | ORGANIZER | Ignore |
| RECURRENCE-ID | Ignore | | RECURRENCE-ID | Required if RRULE is implemented, otherwise |
| | Ignore |
| RELATED-TO | Ignore | | RELATED-TO | Ignore |
| RDATE | Ignore. | | RDATE | Ignore. |
| RRULE | Ignore. The first instance occurs on the | | RRULE | Ignore - assume the first instance occurs on |
| | DTSTART property. If implemented, VTIMEZONE | | | the DTSTART property. If implemented, |
| | MUST also be implemented. | | | VTIMEZONE MUST also be implemented. |
| SEQUENCE | Required | | SEQUENCE | Required |
| STATUS | Ignore | | STATUS | Ignore |
| SUMMARY | Required | | SUMMARY | Required |
| URL | Ignore | | URL | Ignore |
| UID | Required | | UID | Required |
| X- | Ignore | | X- | Ignore |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
5.2. Latency Issues 5.2. Latency Issues
skipping to change at page 117, line 17 skipping to change at page 120, line 17
When an "Attendee" delegates an item to another CU they MUST send a When an "Attendee" delegates an item to another CU they MUST send a
"REPLY" method to the "Organizer" using the "ATTENDEE" properties to "REPLY" method to the "Organizer" using the "ATTENDEE" properties to
indicate that the request was delegated and to whom. Hence, it is indicate that the request was delegated and to whom. Hence, it is
possible for an "Organizer" to receive an "REPLY" from a CU not possible for an "Organizer" to receive an "REPLY" from a CU not
listed as one of the original "Attendees". The resolution is left to listed as one of the original "Attendees". The resolution is left to
the implementation but it is expected that the calendaring software the implementation but it is expected that the calendaring software
will either accept the reply or hold it until the related "REPLY" will either accept the reply or hold it until the related "REPLY"
method is received from the "Delegator". If the version of the method is received from the "Delegator". If the version of the
"REPLY" method is out of date the "Organizer" SHOULD treat the "REPLY" method is out of date the "Organizer" SHOULD treat the
message as a "REFRESH" message and update the delegate with the message as a "REFRESH" message and update the delegate with the
correct version. correct version provided that delegation to that delegate is
acceptable.
5.3. Sequence Number 5.3. Sequence Number
Under some conditions, a CUA may receive requests and replies with Under some conditions, a CUA may receive requests and replies with
the same "SEQUENCE" property value. The "DTSTAMP" property is the same "SEQUENCE" property value. The "DTSTAMP" property is
utilized as a tie-breaker when two items with the same "SEQUENCE" utilized as a tie-breaker when two items with the same "SEQUENCE"
property value are evaluated. property value are evaluated.
6. Security Considerations 6. Security Considerations
skipping to change at page 118, line 25 skipping to change at page 121, line 26
was mutually agreed upon. was mutually agreed upon.
6.1.4. Eavesdropping 6.1.4. Eavesdropping
The iCalendar object is constructed with human-readable clear text. The iCalendar object is constructed with human-readable clear text.
Any information contained in an iCalendar object may be read and/or Any information contained in an iCalendar object may be read and/or
changed by unauthorized persons while the object is in transit. changed by unauthorized persons while the object is in transit.
6.1.5. Flooding a Calendar 6.1.5. Flooding a Calendar
Implementations MAY provide a means to automatically incorporate Implementations could provide a means to automatically incorporate
"REQUEST" methods into a calendar. This presents the opportunity for "REQUEST" methods into a calendar. This presents the opportunity for
a calendar to be flooded with requests, which effectively block all a calendar to be flooded with requests, which effectively block all
the calendar's free time. the calendar's free time.
6.1.6. Unauthorized REFRESH Requests 6.1.6. Unauthorized REFRESH Requests
It is possible for an "Organizer" to receive a "REFRESH" request from It is possible for an "Organizer" to receive a "REFRESH" request from
someone who is not an "Attendee" of an event or to-do. Only someone who is not an "Attendee" of an event or to-do. Only
"Attendee's" of an event or to-do are authorized to receive replies "Attendee's" of an event or to-do are authorized to receive replies
to "REFRESH" requests. Replying to such requests to anyone who is to "REFRESH" requests. Replying to such requests to anyone who is
not an "Attendee" may be a security problem. not an "Attendee" may be a security problem.
6.2. Recommendations 6.2. Recommendations
For an application where the information is sensitive or critical and For an application where the information is sensitive or critical and
the network is subject is subject to a high probability of attack, the network is subject to a high probability of attack, iTIP
iTIP transactions SHOULD be encrypted. This may be accomplished transactions SHOULD be encrypted. This may be accomplished using
using public key technology, specifically Security Multiparts for public key technology, specifically Security Multiparts for MIME
MIME [RFC1847] in the iTIP transport binding. This helps mitigate [RFC1847] in the iTIP transport binding. This helps mitigate the
the threats of spoofing, eavesdropping and malicious changes in threats of spoofing, eavesdropping and malicious changes in transit.
transit.
6.2.1. Use of [RFC1847] to secure iTIP transactions 6.2.1. Use of [RFC1847] to secure iTIP transactions
iTIP transport bindings MUST provide a mechanism based on Security iTIP transport bindings MUST provide a mechanism based on Security
Multiparts for MIME [RFC1847] to enable authentication of the Multiparts for MIME [RFC1847] to enable authentication of the
sender's identity, and privacy and integrity of the data being sender's identity, and privacy and integrity of the data being
transmitted. This allows the receiver of a signed iCalendar object transmitted. This allows the receiver of a signed iCalendar object
to verify the identity of the sender. This sender may then be to verify the identity of the sender. This sender may then be
correlated to an "ATTENDEE" property in the iCalendar object. If the correlated to an "ATTENDEE" property in the iCalendar object. If the
correlation is made and the sender is authorized to make the correlation is made and the sender is authorized to make the
skipping to change at page 119, line 30 skipping to change at page 122, line 30
mitigated by a calendar system that uses this protocol by providing mitigated by a calendar system that uses this protocol by providing
controls or alerts that make "Calendar Users" aware of such controls or alerts that make "Calendar Users" aware of such
"Organizer" changes and allowing them to decide whether or not the "Organizer" changes and allowing them to decide whether or not the
request should be honored. request should be honored.
The threat of flooding a calendar SHOULD be mitigated by a calendar The threat of flooding a calendar SHOULD be mitigated by a calendar
system that uses this protocol by providing controls that may be used system that uses this protocol by providing controls that may be used
to limit the acceptable sources for iTIP transactions, and perhaps to limit the acceptable sources for iTIP transactions, and perhaps
the size of messages and volume of traffic, by source. the size of messages and volume of traffic, by source.
The threat of malicious procedural alarms SHOULD be mitigated by a
calendar system that uses this protocol by providing controls that
may be used to disallow procedural alarms in iTIP transactions and/or
remove all alarms from the object before delivery to the recipient.
The threat of unauthorized "REFRESH" requests SHOULD be mitigated by The threat of unauthorized "REFRESH" requests SHOULD be mitigated by
a calendar system that uses this protocol by providing controls or a calendar system that uses this protocol by providing controls or
alerts that allow "Calendar User" to decide whether or not the alerts that allow "Calendar User" to decide whether or not the
request should be honored. An implementation MAY decide to maintain, request should be honored. An implementation MAY decide to maintain,
for audit or historical purposes, "Calendar Users" who were part of for audit or historical purposes, "Calendar Users" who were part of
an attendee list and who were subsequently uninvited. Similar an attendee list and who were subsequently uninvited. Similar
controls or alerts should be provided when a "REFRESH" request is controls or alerts should be provided when a "REFRESH" request is
received from these "Calendar Users" as well. received from these "Calendar Users" as well.
7. IANA Consideration 7. IANA Consideration
This documents defines the following values for the iCalendar This documents defines the following values for the iCalendar
"METHOD" property: "METHOD" property and these should be added to the Methods Registry
defined in Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis]:
7.1. METHOD:PUBLISH 7.1. METHOD:PUBLISH
Value: PUBLISH Value: PUBLISH
Purpose: Standard iTIP "METHOD" value. Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property. Conformance: Only used with the "METHOD" property.
Examples: See this RFC. Examples: See this RFC.
skipping to change at page 122, line 19 skipping to change at page 125, line 19
9. Normative References 9. Normative References
[I-D.ietf-calsify-rfc2445bis] [I-D.ietf-calsify-rfc2445bis]
Desruisseaux, B., "Internet Calendaring and Scheduling Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", Core Object Specification (iCalendar)",
draft-ietf-calsify-rfc2445bis-08 (work in progress), draft-ietf-calsify-rfc2445bis-08 (work in progress),
February 2008. February 2008.
[I-D.ietf-calsify-rfc2447bis] [I-D.ietf-calsify-rfc2447bis]
Melnikov, A., "iCalendar Message-Based Interoperability Melnikov, A., "iCalendar Message-Based Interoperability
Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-04 (work Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-05 (work
in progress), May 2008. in progress), June 2008.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995. Multipart/Encrypted", RFC 1847, October 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
skipping to change at page 123, line 51 skipping to change at page 126, line 51
[I-D.ietf-calsify-rfc2445bis] and references to that have been [I-D.ietf-calsify-rfc2445bis] and references to that have been
removed in this document too. removed in this document too.
The "THISANDFUTURE" option for the "RANGE" parameter was removed in The "THISANDFUTURE" option for the "RANGE" parameter was removed in
[I-D.ietf-calsify-rfc2445bis] and references to that have been [I-D.ietf-calsify-rfc2445bis] and references to that have been
removed in this document too. removed in this document too.
Appendix B. Change History (to be removed prior to publication as an Appendix B. Change History (to be removed prior to publication as an
RFC) RFC)
Changes in -07: Changes in -08:
a. AD review: Changed "calendar entry" to "iCalendar object".
b. AD review: Added extra captions above restriction tables for more
clarity.
c. AD review: Added missing step of uninvited CU replying to
Organizer in description of event forwarding.
d. AD review: Clarified text about "unsuccessful" REQUEST
processing.
e. AD review: VFREEBUSY text about allowing multiple components
moved into description of PUBLISH method.
f. AD review: VTODO description changed to reflect fact that
originator is not always the Organizer.
g. AD review: Changed VTODO ADD description to use proper 3.14 code
instead of 5.3.
h. AD review: Changed short description on 5.0 status code.
i. AD review: Added IANA-PROPERTY/COMPONENT items to restrictions
tables and changed 3.7.3 to better reflect requirements on
handling extensions.
j. AD review: Fixed example in 4.2.4.
k. AD review: Clarified who is responsible for updating the
delegator in 4.2.5.
l. AD review: Fixed PARTSTAT in example in 4.2.6.
m. AD review: Added reference to IANA methods registry in 2445bis in
IANA section.
n. Removed section on calculating recurring due dates as that is
covered in 2445bis.
o. Fixed lots of issues from Reinhold Kainhofer review being tracked
on the WG wiki.
Changes in -07:
a. IANA considerations now registers METHOD values. a. IANA considerations now registers METHOD values.
b. Added Appendix with key 2446 changes and text to the introduction b. Added Appendix with key 2446 changes and text to the introduction
pointing to that. pointing to that.
Appendix C. Change History (to be removed prior to publication as an
RFC)
Changes in -06: Changes in -06:
a. Added text to SEQUENCE number description about detecting a a. Added text to SEQUENCE number description about detecting a
significant change. significant change.
b. Added text to REQUEST-STATUS section describing the allowed b. Added text to REQUEST-STATUS section describing the allowed
combinations of codes. combinations of codes.
c. Added text to REQUEST-STATUS section to require new codes to be c. Added text to REQUEST-STATUS section to require new codes to be
defined in a standard or experimental RFC. defined in a standard or experimental RFC.
d. Removed THISANDFUTURE. d. Removed THISANDFUTURE.
e. Cleaned up some examples. e. Cleaned up some examples.
 End of changes. 290 change blocks. 
563 lines changed or deleted 755 lines changed or added

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