draft-ietf-calsify-2446bis-03.txt   draft-ietf-calsify-2446bis-04.txt 
Network Working Group C. Daboo, Ed. Network Working Group C. Daboo, Ed.
Internet-Draft Apple Internet-Draft Apple
Obsoletes: 2446 (if approved) March 5, 2007 Obsoletes: 2446 (if approved) November 18, 2007
Intended status: Standards Track Intended status: Standards Track
Expires: September 6, 2007 Expires: May 21, 2008
iCalendar Transport-Independent Interoperability Protocol (iTIP) iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-03 draft-ietf-calsify-2446bis-04
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 September 6, 2007. This Internet-Draft will expire on May 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 calendar systems. This is done without reference to a
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 calendar systems. These scheduling methods permit two or more
calendar systems to perform transactions such as publish, schedule, calendar systems to perform transactions such as publish, schedule,
reschedule, respond to scheduling requests, negotiation of changes or reschedule, respond to scheduling requests, negotiation of changes or
cancel. cancel.
Change History (to be removed prior to publication as an RFC)
Changes in -03:
a. Added empty IANA Considerations section - to be done.
Changes in -02:
a. Tweaked abstract wording.
b. Fixed some improper references.
c. Removed bogus TZOFFSET entry from VTIMEZONE restriction table.
d. Changed TZNAME entry in VTIMEZONE restriction table to "0+" from
"0 or 1" to fall in line with 2445.
e. Changed COMMENT entry in component restriction tables to "0+"
from "0 or 1" to fall in line with 2445.
f. Added ATTENDEE entry in VALARM restriction table to match email
alarm type in 2445.
g. Changed CATEGORIES entry in component restriction tables to "0+"
from "0 or 1" to fall in line with 2445.
h. Changed RESOURCES entry in component restriction tables to "0+"
from "0 or 1" to fall in line with 2445.
i. Changed CONTACT entry in VFREEBUSY restriction table to "0 or 1"
from "0+" to fall in line with 2445.
j. Made UID required in VFREEBUSY publish.
k. Added COMPLETED entry in VTODO restriction tables to fall in line
with 2445.
l. Added REQUEST-STATUS entry in VJOURNAL restriction tables to fall
in line with 2445.
Changes in -01:
a. Updated to 2445bis and 2447bis references.
Changes in -00 (from RFC2446):
a. Updated to latest i-d boilerplate text.
b. Rewrote abstract and introduction.
c. Reformatted Formatting Conventions section.
d. Split ITIP Roles and Transactions into two sections
e. iTIP roles uses a table to describe different roles
f. Converted tables into xml2rfc format.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 6 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5
1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 5
1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 7 1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 6
1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Interoperability Models . . . . . . . . . . . . . . . . . . . 9 2. Interoperability Models . . . . . . . . . . . . . . . . . . . 8
2.1. Application Protocol . . . . . . . . . . . . . . . . . . 10 2.1. Application Protocol . . . . . . . . . . . . . . . . . . 9
2.1.1. Calendar Entry State . . . . . . . . . . . . . . . . 10 2.1.1. Calendar Entry State . . . . . . . . . . . . . . . . 9
2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 10 2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 9
2.1.3. Acting on Behalf of other Calendar Users . . . . . . 11 2.1.3. Acting on Behalf of other Calendar Users . . . . . . 10
2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 11 2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 10
2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 12 2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 11
3. Application Protocol Elements . . . . . . . . . . . . . . . . 13 3. Application Protocol Elements . . . . . . . . . . . . . . . . 12
3.1. Common Component Restriction Tables . . . . . . . . . . . 13 3.1. Common Component Restriction Tables . . . . . . . . . . . 12
3.2. Methods for VEVENT Calendar Components . . . . . . . . . 16 3.2. Methods for VEVENT Calendar Components . . . . . . . . . 15
3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 32 3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 31
3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 33 3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 32
3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4. Methods For VTODO Components . . . . . . . . . . . . . . 38 3.4. Methods For VTODO Components . . . . . . . . . . . . . . 37
3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 39 3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 41 3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 49 3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 51 3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 53 3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 54 3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 53
3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 56 3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 55
3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 56 3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 55
3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 60 3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 59
3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 62 3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 61
3.7. Implementation Considerations . . . . . . . . . . . . . . 64 3.7. Implementation Considerations . . . . . . . . . . . . . . 63
3.7.1. Working With Recurrence Instances . . . . . . . . . . 64 3.7.1. Working With Recurrence Instances . . . . . . . . . . 63
3.7.2. Attendee Property Considerations . . . . . . . . . . 65 3.7.2. Attendee Property Considerations . . . . . . . . . . 64
3.7.3. X-Tokens . . . . . . . . . . . . . . . . . . . . . . 66 3.7.3. X-Tokens . . . . . . . . . . . . . . . . . . . . . . 65
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1. Published Event Examples . . . . . . . . . . . . . . . . 66 4.1. Published Event Examples . . . . . . . . . . . . . . . . 65
4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 67 4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 66
4.1.2. Changing A Published Event . . . . . . . . . . . . . 67 4.1.2. Changing A Published Event . . . . . . . . . . . . . 66
4.1.3. Canceling A Published Event . . . . . . . . . . . . . 68 4.1.3. Canceling A Published Event . . . . . . . . . . . . . 67
4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 69 4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 68
4.1.5. Anniversaries or Events attached to entire days . . . 70 4.1.5. Anniversaries or Events attached to entire days . . . 69
4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 70 4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 69
4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 71 4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 70
4.2.2. Reply To A Group Event Request . . . . . . . . . . . 72 4.2.2. Reply To A Group Event Request . . . . . . . . . . . 71
4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 73 4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 72
4.2.4. Countering an Event Proposal . . . . . . . . . . . . 73 4.2.4. Countering an Event Proposal . . . . . . . . . . . . 72
4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 75 4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 75
4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 78 4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 77
4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 79 4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 78
4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 80 4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 79
4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 80 4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 79
4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 81 4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 80
4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 83 4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 82
4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 83 4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 83
4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 84 4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 84
4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 85 4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 85
4.4. Recurring Event and Time Zone Examples . . . . . . . . . 85 4.4. Recurring Event and Time Zone Examples . . . . . . . . . 85
4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 85 4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 85
4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 87 4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 87
4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 89 4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 89
4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 90 4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 90
4.4.5. Change All Future Instances . . . . . . . . . . . . . 90 4.4.5. Change All Future Instances . . . . . . . . . . . . . 90
4.4.6. Add A New Instance To A Recurring Event . . . . . . . 91 4.4.6. Add A New Instance To A Recurring Event . . . . . . . 91
4.4.7. Add A New Series of Instances To A Recurring Event . 92 4.4.7. Add A New Series of Instances To A Recurring Event . 92
4.4.8. Counter An Instance Of A Recurring Event . . . . . . 97 4.4.8. Counter An Instance Of A Recurring Event . . . . . . 97
4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 98 4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 98
4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 100 4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 100
4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 101 4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 101
4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 101 4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 101
4.5.3. A VTODO Request for Updated Status . . . . . . . . . 102 4.5.3. A VTODO Request for Updated Status . . . . . . . . . 102
4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 102 4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 102
4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 102 4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 103
4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 103 4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 103
4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 103 4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 104
4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 105 4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 105
4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 105 4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 106
4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 105 4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 106
4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 106 4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 106
5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 108 5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 109
5.1. Partial Implementation . . . . . . . . . . . . . . . . . 108 5.1. Partial Implementation . . . . . . . . . . . . . . . . . 109
5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 109 5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 109
5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 111 5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 111
5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 112 5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 112
5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 114 5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 114
5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 115 5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 115
5.2.1. Cancellation of an Unknown Calendar Component. . . . 115 5.2.1. Cancellation of an Unknown Calendar Component. . . . 115
5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 116 5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 116
5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 116 5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 116
6. Security Considerations . . . . . . . . . . . . . . . . . . . 116 6. Security Considerations . . . . . . . . . . . . . . . . . . . 116
6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 116 6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 116
skipping to change at page 5, line 26 skipping to change at page 4, line 34
6.1.6. Procedural Alarms . . . . . . . . . . . . . . . . . . 117 6.1.6. Procedural Alarms . . . . . . . . . . . . . . . . . . 117
6.1.7. Unauthorized REFRESH Requests . . . . . . . . . . . . 117 6.1.7. Unauthorized REFRESH Requests . . . . . . . . . . . . 117
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 118 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 118
6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 118 6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 118
6.2.2. Implementation Controls . . . . . . . . . . . . . . . 118 6.2.2. Implementation Controls . . . . . . . . . . . . . . . 118
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 119 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 119
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 119 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.1. Normative References . . . . . . . . . . . . . . . . . . 119 8.1. Normative References . . . . . . . . . . . . . . . . . . 119
8.2. Informative References . . . . . . . . . . . . . . . . . 119 8.2. Informative References . . . . . . . . . . . . . . . . . 119
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 119 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 119
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 119 Appendix B. Change History (to be removed prior to
Intellectual Property and Copyright Statements . . . . . . . . . 121 publication as an RFC) . . . . . . . . . . . . . . . 120
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 121
Intellectual Property and Copyright Statements . . . . . . . . . 122
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 calendar 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
skipping to change at page 6, line 29 skipping to change at page 5, line 29
transaction/request status information. The protocol supports the transaction/request status information. The protocol supports the
ability for the message originator to modify or cancel the original ability for the message originator to modify or cancel the original
message. The protocol also supports the ability for recipients to message. The protocol also supports the ability for recipients to
suggest changes to the originator of a message. The elements of the suggest changes to the originator of a message. The elements of the
protocol also define the user roles for its transactions. protocol also define the user roles for its transactions.
1.1. Formatting Conventions 1.1. Formatting Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119].
Calendaring and scheduling roles are referred to in quoted-strings of Calendaring and scheduling roles are referred to in quoted-strings of
text with the first character of each word in upper case. For text with the first character of each word in upper case. For
example, "Organizer" refers to a role of a "Calendar User" (CU) example, "Organizer" refers to a role of a "Calendar User" (CU)
within the scheduling protocol. within the scheduling protocol.
Calendar components defined by [I-D.ietf-calsify-rfc2445bis] are Calendar components defined by [I-D.ietf-calsify-rfc2445bis] are
referred to with capitalized, quoted-strings of text. All calendar referred to with capitalized, quoted-strings of text. All calendar
components start with the letter "V". For example, "VEVENT" refers components start with the letter "V". For example, "VEVENT" refers
to the event calendar component, "VTODO" refers to the to-do calendar to the event calendar component, "VTODO" refers to the to-do calendar
skipping to change at page 7, line 5 skipping to change at page 6, line 5
of text. For example, "REQUEST" refers to the method for requesting of text. For example, "REQUEST" refers to the method for requesting
a scheduling calendar component be created or modified, "REPLY" a scheduling calendar component be created or modified, "REPLY"
refers to the method a recipient of a request uses to update their refers to the method a recipient of a request uses to update their
status with the "Organizer" of the calendar component. status with the "Organizer" of the calendar component.
Properties defined by [I-D.ietf-calsify-rfc2445bis] are referred to Properties defined by [I-D.ietf-calsify-rfc2445bis] are referred to
with capitalized, quoted-strings of text, followed by the word with capitalized, quoted-strings of text, followed by the word
"property". For example, "ATTENDEE" property refers to the iCalendar "property". For example, "ATTENDEE" property refers to the iCalendar
property used to convey the calendar address of a "Calendar User". property used to convey the calendar address of a "Calendar User".
Property parameters defined by this memo are referred to with lower Property parameters defined by this memo are referred to with
case, quoted-strings of text, followed by the word "parameter". For capitalized, quoted-strings of text, followed by the word
example, "value" parameter refers to the iCalendar property parameter "parameter". For example, "VALUE" parameter refers to the iCalendar
used to override the default data type for a property value. property parameter used to override the default data type for a
property value.
Enumerated values defined by this memo are referred to with Enumerated values defined by this memo are referred to with
capitalized text, either alone or followed by the word "value". capitalized text, either alone or followed by the word "value".
In tables, the quoted-string text is specified without quotes in In tables, the quoted-string text is specified without quotes in
order to minimize the table length. order to minimize the table length.
1.2. Related Documents 1.2. Related Documents
Implementers will need to be familiar with several other Implementers will need to be familiar with several other
skipping to change at page 9, line 42 skipping to change at page 8, line 42
Application Protocol. Binding documents such as Application Protocol. Binding documents such as
[I-D.ietf-calsify-rfc2447bis] focus on the Transport Protocol. [I-D.ietf-calsify-rfc2447bis] focus on the Transport Protocol.
The connection between Sender and Receiver in the diagram below The connection between Sender and Receiver in the diagram below
refers to the Application Protocol. The iCalendar objects passed refers to the Application Protocol. The iCalendar objects passed
from the Sender to the Receiver are presented in Section 3, from the Sender to the Receiver are presented in Section 3,
Application Protocol Elements. Application Protocol Elements.
+----------+ +----------+ +----------+ +----------+
| | iTIP | | | | iTIP | |
| Sender |<-------------------->| Receiver | | Sender |<-------------->| Receiver |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
There are several variations of this diagram in which the Sender and There are several variations of this diagram in which the Sender and
Receiver take on various roles of a "Calendar User Agent" (CUA) or a Receiver take on various roles of a "Calendar User Agent" (CUA) or a
"Calendar Service" (CS). "Calendar Service" (CS).
The architecture of iTIP is depicted in the diagram below. An The architecture of iTIP is depicted in the diagram below. An
application written to this specification may work with bindings for application written to this specification may work with bindings for
the store-and-forward transport, the real time transport, or both. the store-and-forward transport, the real time transport, or both.
skipping to change at page 10, line 40 skipping to change at page 9, line 42
There are two distinct states relevant to calendar entries: the There are two distinct states relevant to calendar entries: the
overall state of the entry and the state associated with an overall state of the entry and the state associated with an
"Attendee" to that entry. "Attendee" to that entry.
The state of an entry is defined by the "STATUS" property and is The state of an entry is defined by the "STATUS" property and is
controlled by the "Organizer." There is no default value for the controlled by the "Organizer." There is no default value for the
"STATUS" property. The "Organizer" sets the "STATUS" property to the "STATUS" property. The "Organizer" sets the "STATUS" property to the
appropriate value for each calendar entry. appropriate value for each calendar entry.
The state of a particular "Attendee" relative to an entry is defined The state of a particular "Attendee" relative to an entry is defined
by the "partstat" parameter in the "ATTENDEE" property for each by the "PARTSTAT" parameter in the "ATTENDEE" property for each
"Attendee". When an "Organizer" issues the initial entry, "Attendee" "Attendee". When an "Organizer" issues the initial entry, "Attendee"
status is unknown. The "Organizer" specifies this by setting the status is unknown. The "Organizer" specifies this by setting the
"partstat" parameter to "NEEDS-ACTION". Each "Attendee" modifies "PARTSTAT" parameter to "NEEDS-ACTION". Each "Attendee" modifies
their "ATTENDEE" property "partstat" parameter to an appropriate their "ATTENDEE" property "PARTSTAT" parameter to an appropriate
value as part of a "REPLY" message sent back to the "Organizer". 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.
skipping to change at page 11, line 23 skipping to change at page 10, line 24
First, the "Organizer" is treated as a special entity, separate from First, the "Organizer" is treated as a special entity, separate from
"Attendees". All responses from "Attendees" flow to the "Organizer", "Attendees". All responses from "Attendees" flow to the "Organizer",
making it easy to separate a calendar user organizing a meeting from making it easy to separate a calendar user organizing a meeting from
calendar users attending the meeting. Additionally, iCalendar calendar users attending the meeting. Additionally, iCalendar
provides descriptive roles for each "Attendee". For instance, a role provides descriptive roles for each "Attendee". For instance, a role
of "chair" may be ascribed to one or more "Attendees". The "chair" of "chair" may be ascribed to one or more "Attendees". The "chair"
and the "Organizer" may or may not be the same calendar user. This and the "Organizer" may or may not be the same calendar user. This
maps well to scenarios where an assistant may manage meeting maps well to scenarios where an assistant may manage meeting
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. The rules for incrementing the
"SEQUENCE" number are defined in [I-D.ietf-calsify-rfc2445bis]. For "SEQUENCE" number are defined in [I-D.ietf-calsify-rfc2445bis]. For
clarity, these rules are paraphrased here in terms of how they are clarity, these rules are paraphrased here in terms of how they are
applied in iTIP. For a given "UID" in a calendar component: applied in iTIP. For a given "UID" in a calendar component:
skipping to change at page 16, line 46 skipping to change at page 15, line 46
| | 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. |
| | | | | |
| REFRESH | A request is sent to an "Organizer" by an | | REFRESH | A request is sent to an "Organizer" by an |
| | "Attendee" asking for the latest version of an | | | "Attendee" asking for the latest version of an |
| | event to be resent to the requester. | | | event to be resent to the requester. |
skipping to change at page 21, line 35 skipping to change at page 20, line 35
method describes an update of the event details, but no rescheduling method describes an update of the event details, but no rescheduling
of the event. of the event.
The update "REQUEST" method is the appropriate response to a The update "REQUEST" method is the appropriate response to a
"REFRESH" method sent from an "Attendee" to the "Organizer" of an "REFRESH" method sent from an "Attendee" to the "Organizer" of an
event. event.
The "Organizer" of an event may also send unsolicited "REQUEST" The "Organizer" of an event may also send unsolicited "REQUEST"
methods. The unsolicited "REQUEST" methods may be used to update the methods. The unsolicited "REQUEST" methods may be used to update the
details of the event without rescheduling it, to update the details of the event without rescheduling it, to update the
"partstat" parameter of "Attendees", or to reconfirm the event. "PARTSTAT" parameter of "Attendees", or to reconfirm the event.
3.2.2.3. Delegating an Event to another CU 3.2.2.3. Delegating an Event to another CU
Some calendar and scheduling systems allow "Attendees" to delegate Some calendar and scheduling systems allow "Attendees" to delegate
their presence at an event to another calendar user. ITIP supports their presence at an event to another calendar user. ITIP supports
this concept using the following workflow. Any "Attendee" may this concept using the following workflow. Any "Attendee" may
delegate their right to participate in a calendar VEVENT to another delegate their right to participate in a calendar VEVENT to another
CU. The implication is that the delegate participates in lieu of the CU. The implication is that the delegate participates in lieu of the
original "Attendee"; NOT in addition to the "Attendee". The original "Attendee"; NOT in addition to the "Attendee". The
delegator MUST notify the "Organizer" of this action using the steps delegator MUST notify the "Organizer" of this action using the steps
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".
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
skipping to change at page 22, line 38 skipping to change at page 21, line 38
incremented and value of the "ORGANIZER" property has been changed to incremented and value of the "ORGANIZER" property has been changed to
the calendar address of the new "Organizer". the calendar address of the new "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 "Organizer"
decides whether or not the uninvited CU is added to the attendee decides whether or not the uninvited CU is added to the attendee
skipping to change at page 23, line 27 skipping to change at page 22, line 27
"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"
method indicating their current status with respect to the "REQUEST". method indicating their current status with respect to the "REQUEST".
3.2.3. REPLY 3.2.3. REPLY
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 may also be used to respond to an unsuccessful
"REQUEST" method. Depending on the value of the "REQUEST-STATUS" "REQUEST" method. Depending on the value of the "REQUEST-STATUS"
property no scheduling action may have been performed. property no scheduling 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
skipping to change at page 24, line 4 skipping to change at page 23, line 4
to the uninvited "Attendee". to the uninvited "Attendee".
An "Attendee" can include a message to the "Organizer" using the An "Attendee" can 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:
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 25, line 31 skipping to change at page 24, line 31
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.2.4. ADD 3.2.4. ADD
The "ADD" method in a "VEVENT" calendar component is used to add one The "ADD" method allows the "Organizer" to add one or more new
or more instances to an existing "VEVENT". Unlike the "REQUEST" instances to an existing "VEVENT" using a single ITIP message without
method, when using issuing an "ADD" method, the "Organizer" does not having to send the entire "VEVENT" with all the existing instance
send the full "VEVENT" description; only the new instance(s). The data, as it would have to do if the "REQUEST" method were used.
"ADD" method is especially useful if there are instance-specific
properties to be preserved in a recurring "VEVENT". For instance, an
"Organizer" may have originally scheduled a weekly Thursday meeting.
At some point, several instances changed. Location or start time may
have changed, or some instances may have unique "DESCRIPTION"
properties. The "ADD" method allows the "Organizer" to add new
instances to an existing event using a single ITIP message without
redefining the entire recurring pattern.
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:
skipping to change at page 27, line 37 skipping to change at page 26, line 30
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
recurring "VEVENT" calendar component: recurring "VEVENT" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the
specified "VEVENT" calendar component and all instances before specified "VEVENT" calendar component and all instances before
(or after); or (or after); or
b. individual recurrence instances may be cancelled by specifying b. individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the multiple "VEVENT" components each with a "RECURRENCE-ID" property
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:
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 34, line 39 skipping to change at page 33, line 30
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.
Since events may span a day boundary, free busy time period may also Since events may span a day boundary, free busy time period may also
span a day boundary. Individual "A" requests busy time from span a day boundary. Individual "A" requests busy time from
individuals "B", "C" and "D". Individual "B" and "C" replies with individuals "B", "C" and "D". Individual "B" and "C" replies with
busy time data to individual "A". Individual "D" does not support busy time data to individual "A". Individual "D" does not support
busy time requests and does not reply with any data. If the busy time requests and does not reply with any data. If the
transport binding supports exception messages, then individual "D" transport binding supports exception messages, then individual "D"
returns an "unsupported capability" message to individual "A4.34.3". 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. |
skipping to change at page 35, line 29 skipping to change at page 34, line 21
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| 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 | 1+ | MUST be BUSYTIME. Multiple | | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
| | | instances are allowed. Multiple | | | | instances are allowed. Multiple |
| | | instances must be sorted in | | | | instances must 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 | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| URL | 0 or 1 | Specifies busy time URL | | URL | 0 or 1 | Specifies busy time URL |
skipping to change at page 38, line 15 skipping to change at page 37, line 15
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| 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 | (address of recipient 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 | 1+ | (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 | | | | are allowed. Multiple instances |
| | | MUST be sorted in ascending | | | | MUST be sorted in ascending |
| | | order. Values MAY 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 | |
| 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) |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| DURATION | 0 | | | DURATION | 0 | |
| SEQUENCE | 0 | | | SEQUENCE | 0 | |
skipping to change at page 44, line 46 skipping to change at page 43, line 46
"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.
The "REQUEST" method MUST also include an "ATTENDEE" property with The "REQUEST" method MUST also include an "ATTENDEE" property with
the calendar address of the "Delegate". The "Delegator" MUST also the calendar address of the "Delegate". The "Delegator" MUST also
send a "REPLY" method back to the "Organizer" with the "Delegator's" send a "REPLY" method back 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". A response to the delegation calendar address of the "Delegate". A response to the delegation
"REQUEST" is sent from the "Delegate" to the "Organizer" and "REQUEST" is sent from the "Delegate" to the "Organizer" and
optionally, to the "Delegator". The "REPLY" method from the optionally, to the "Delegator". The "REPLY" method from the
"Delegate" SHOULD include the "ATTENDEE" property with their calendar "Delegate" SHOULD include the "ATTENDEE" property with their calendar
address and the "delegated-from" parameter with the value of the address and the "DELEGATED-FROM" parameter with the value of the
"Delegator's" calendar address. "Delegator's" calendar address.
The delegation "REQUEST" method MUST assign a value for the "RSVP" The delegation "REQUEST" method MUST assign a value for the "RSVP"
property parameter associated with the "Delegator's" "Attendee" property parameter associated with the "Delegator's" "Attendee"
property to that of the "Delegate's" "ATTENDEE" property. For property to that of the "Delegate's" "ATTENDEE" property. For
example if the "Delegator's" "ATTENDEE" property specifies example if the "Delegator's" "ATTENDEE" property specifies
"RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify
"RSVP=TRUE". "RSVP=TRUE".
3.4.2.4. REQUEST Forwarded To An Uninvited Calendar User 3.4.2.4. REQUEST Forwarded To An Uninvited Calendar User
skipping to change at page 46, line 6 skipping to change at page 45, line 6
updated status. The recipient SHOULD respond with a "REPLY" method updated status. The recipient SHOULD respond with a "REPLY" method
indicating their current status with respect to the "REQUEST". indicating their current status with respect to the "REQUEST".
3.4.3. REPLY 3.4.3. REPLY
The "REPLY" method in a "VTODO" calendar component is used to respond The "REPLY" method in a "VTODO" calendar component is used to respond
(e.g., accept or decline) to a request or to reply to a delegation (e.g., accept or decline) to a request or to reply to a delegation
request. It is also used by an "Attendee" to update their completion request. It is also used by an "Attendee" to update their completion
status. When used to provide a delegation response, the "Delegator" status. When used to provide a delegation response, the "Delegator"
MUST include the calendar address of the "Delegate" in the MUST include the calendar address of the "Delegate" in the
"delegated-to" parameter of the "Delegator's" "ATTENDEE" property. "DELEGATED-TO" parameter of the "Delegator's" "ATTENDEE" property.
The "Delegate" MUST include the calendar address of the "Delegator" The "Delegate" MUST include the calendar address of the "Delegator"
on the "delegated-from" parameter of the "Delegate's" "ATTENDEE" on the "DELEGATED-FROM" parameter of the "Delegate's" "ATTENDEE"
property. property.
The "REPLY" method MAY also be used to respond to an unsuccessful The "REPLY" method MAY also be used to respond to an unsuccessful
"VTODO" calendar component "REQUEST" method. Depending on the "VTODO" calendar component "REQUEST" method. Depending on the
"REQUEST-STATUS" value, no scheduling action may have been performed. "REQUEST-STATUS" value, no scheduling action may have been performed.
The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY"
method from a "Calendar User" not in the original "REQUEST". For method from a "Calendar User" not in the original "REQUEST". For
example, a "REPLY" method MAY be received from a "Delegate" of a example, a "REPLY" method MAY be received from a "Delegate" of a
"VTODO" calendar component. In addition, the "REPLY" method MAY be "VTODO" calendar component. In addition, the "REPLY" method MAY be
skipping to change at page 49, line 46 skipping to change at page 48, line 46
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
recurring "VTODO" calendar component: recurring "VTODO" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the
specified "VTODO" calendar component and all instances before (or specified "VTODO" calendar component and all instances before (or
after) after)
b. individual recurrence instances may be cancelled by specifying b. individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the multiple "VTODO" components with a "RECURRENCE-ID" property
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:
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 60, line 28 skipping to change at page 59, line 28
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
recurring "VJOURNAL" calendar component: recurring "VJOURNAL" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the
specified "VTODO" calendar component and all instances before (or specified "VTODO" calendar component and all instances before (or
after) after)
b. individual recurrence instances may be cancelled by specifying b. individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the multiple "VJOURNAL" components with a "RECURRENCE-ID" property
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:
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 64, line 51 skipping to change at page 63, line 51
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 discreet, 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
effect on the meeting itself such as start time, location, due date effect on the meeting itself such as start time, location, due date
(for "VTODO" calendar component components) and possibly description. (for "VTODO" calendar component components) and possibly description.
"Organizer" initiated actions: "Organizer" initiated actions:
skipping to change at page 66, line 20 skipping to change at page 65, line 20
1. Search for the "Calendar User" in the attendee list where 1. Search for the "Calendar User" in the attendee list where
"TYPE=INDIVIDUAL" "TYPE=INDIVIDUAL"
2. Failing (1) look for attendees where "TYPE=GROUP" or 2. Failing (1) look for attendees where "TYPE=GROUP" or
'TYPE=UNKNOWN". The CUA then determines if the "Calendar User" 'TYPE=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:
* 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
3. Failing (2) the CUA MAY ignore or accept the request as the 3. 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. X-Tokens
To make iCalendar objects extensible, new property types MAY be To make iCalendar objects extensible, new property types MAY be
inserted into components. These properties are called X-Tokens as inserted into components. These properties are called X-Tokens as
they are prefixed with "X-". A client is not required to make sense they are prefixed with "X-". A client is not required to make sense
skipping to change at page 70, line 21 skipping to change at page 69, line 22
END:VALARM END:VALARM
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The "RELATED-TO" field contains the "UID" property of a related The "RELATED-TO" field contains the "UID" property of a related
calendar event. The "SEQUENCE" property 3 indicates that this event calendar event. The "SEQUENCE" property 3 indicates that this event
supersedes versions 0, 1, and 2. supersedes versions 0, 1, and 2.
4.1.5. Anniversaries or Events attached to entire days 4.1.5. Anniversaries or Events attached to entire days
This example demonstrates the use of the "value" parameter to tie a This example demonstrates the use of the "VALUE" parameter to tie a
"VEVENT" to day rather than a specific time. "VEVENT" to day rather than a specific time.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:PUBLISH METHOD:PUBLISH
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
skipping to change at page 71, line 14 skipping to change at page 70, line 15
+--------------+-----------------------+----------------------------+ +--------------+-----------------------+----------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+--------------+-----------------------+----------------------------+ +--------------+-----------------------+----------------------------+
| Initiate a | "A" sends a REQUEST | | | Initiate a | "A" sends a REQUEST | |
| meeting | message to "B", "C", | | | meeting | message to "B", "C", | |
| request | and "D" | | | request | and "D" | |
| | | | | | | |
| Accept the | | "B" sends a REPLY message | | Accept the | | "B" sends a REPLY message |
| meeting | | to "A" with its ATTENDEE | | meeting | | to "A" with its ATTENDEE |
| request | | "partstat" para-set to | | request | | "PARTSTAT" parameter set |
| | | "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" para-set to | | request | | "PARTSTAT" parameter set |
| | | "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" para-set to | | meeting | | "PARTSTAT" parameter set |
| request | | "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"
is also sent a copy of the request but is not expected to attend and is also sent a copy of the request but is not expected to attend and
need not reply. "E" illustrates how CUAs might implement an "FYI" need not reply. "E" illustrates how CUAs might implement an "FYI"
type feature. Note the use of the "role" parameter. The default type feature. Note the use of the "ROLE" parameter. The default
value for the "role" parameter is "req-participant" and it need not value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not
be enumerated. In this case we are using the value "non-participant" be enumerated. In this case we are using the value "NON-PARTICIPANT"
to indicate "E" is a non-attending CU. The parameter is not needed to indicate "E" is a non-attending CU. The parameter is not needed
on other "Attendees" since "participant" is the default value. on other "Attendees" since "PARTICIPANT" is the default value.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//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;CN=A:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
skipping to change at page 72, line 46 skipping to change at page 71, line 46
ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com
ORGANIZER:MAILTO:A@example.com ORGANIZER:MAILTO:A@example.com
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"B" could have declined the meeting or indicated tentative acceptance "B" could have declined the meeting or indicated tentative acceptance
by setting the "ATTENDEE" "partstat" parameter to "declined" or by setting the "ATTENDEE" "PARTSTAT" parameter to "DECLINED" or
"tentative", respectively. Also, "REQUEST-STATUS" is not required in "TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in
successful transactions. successful transactions.
4.2.3. Update An Event 4.2.3. Update An Event
The event is moved to a different time. The combination of the "UID" The event is moved to a different time. The combination of the "UID"
property (unchanged) and the "SEQUENCE" (bumped to 1) properties property (unchanged) and the "SEQUENCE" (bumped to 1) properties
indicate the update. indicate the update.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
skipping to change at page 76, line 8 skipping to change at page 75, line 17
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 o The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter set to
"delegated" and the "delegated-to" parameter is set to the address "DELEGATED" and the "DELEGATED-TO" parameter is set to the address
of the "Delegate" of the "Delegate"
o Add an additional "ATTENDEE" property for the "Delegate" with the o Add an additional "ATTENDEE" property for the "Delegate" with the
"delegated-from" property parameter set to the "Delegator" "DELEGATED-FROM" property parameter set to the "Delegator"
o Indicate whether they want to continue to receive updates when the o Indicate whether they want to continue to receive updates when the
"Organizer" sends out updated versions of the event. Setting the "Organizer" sends out updated versions of the event. Setting the
"rsvp" property parameter to "TRUE" will cause the updates to be "RSVP" property parameter to "TRUE" will cause the updates to be
sent, setting it to "FALSE" causes no further updates to be sent. sent, setting it to "FALSE" causes no further updates to be sent.
Note that in either case, if the "Delegate" declines the Note that in either case, if the "Delegate" declines the
invitation the "Delegator" will be notified. 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".
It is not required that the "Delegate" include the "Delegator" in It is not required that the "Delegate" include the "Delegator" in
their "REPLY" method. However, it is strongly advised since this their "REPLY" method. However, it is strongly advised since this
will inform the "Delegator" whether the "Delegate" plans to attend will inform the "Delegator" whether the "Delegate" plans to attend
skipping to change at page 77, line 5 skipping to change at page 76, line 5
+-----------------+----------------+--------------------------------+ +-----------------+----------------+--------------------------------+
| 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 |
| delegates to | | the ATTENDEE "partstat" | | delegates to | | the ATTENDEE "PARTSTAT" |
| "E" | | parameter set to "delegated" | | "E" | | parameter set to "DELEGATED" |
| | | and with a new "ATTENDEE" | | | | and with a new "ATTENDEE" |
| | | property for "E". "E's" | | | | property for "E". "E's" |
| | | ATTENDEE "delegated-from" | | | | ATTENDEE "DELEGATED-FROM" |
| | | param is set to "C". "C's" | | | | parameter is set to "C". |
| | | ATTENDEE "delegated-to" param | | | | "C's" ATTENDEE "DELEGATED-TO" |
| | | is set to "E". "C" sends | | | | parameter is set to "E". "C" |
| | | REQUEST message to "E" with | | | | sends REQUEST message to "E" |
| | | the original meeting request | | | | with the original meeting |
| | | information. The "partstat" | | | | request information. The |
| | | property parameter for "C" is | | | | "PARTSTAT" property parameter |
| | | set to "delegated" and the | | | | for "C" is set to "DELEGATED" |
| | | "delegated-to" parameter is | | | | and the "DELEGATED-TO" |
| | | set to the address of "E". An | | | | parameter is set to the |
| | | "ATTENDEE" property is added | | | | address of "E". An "ATTENDEE" |
| | | for "E" and the | | | | property is added for "E" and |
| | | "delegated-from" parameter is | | | | the "DELEGATED-FROM" parameter |
| | | set to the address of "C". | | | | is set to the address of "C". |
| | | | | | | |
| Confirm meeting | | "E" sends REPLY message to "A" | | Confirm meeting | | "E" sends REPLY message to "A" |
| attendance | | and optionally "C" with its | | attendance | | and optionally "C" with its |
| | | "partstat" property parameter | | | | "PARTSTAT" property parameter |
| | | set to "ACCEPTED" | | | | set to "ACCEPTED" |
| | | | | | | |
| Optional: | "A" sends | | | Optional: | "A" sends | |
| Redistribute | REQUEST | | | Redistribute | REQUEST | |
| meeting to | message to | | | meeting to | message to | |
| attendees | "B", "C" and | | | attendees | "B", "C" and | |
| | "E". | | | | "E". | |
+-----------------+----------------+--------------------------------+ +-----------------+----------------+--------------------------------+
"C" responds to the "Organizer". "C" responds to the "Organizer".
skipping to change at page 79, line 8 skipping to change at page 78, line 10
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.7. Delegate Declines the Meeting 4.2.7. Delegate Declines the Meeting
In this example the "Delegate" declines the meeting request and sets In this example the "Delegate" declines the meeting request and sets
the "ATTENDEE" property "partstat" parameter to "DECLINED". The the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The
"Organizer" SHOULD resend the "REQUEST" to "C" with the "partstat" "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT"
parameter of the "Delegate" set to "declined". This lets the parameter of the "Delegate" set to "DECLINED". This lets the
"Delegator" know that the "Delegate" has declined and provides an "Delegator" know that the "Delegate" has declined and provides an
opportunity to the "Delegator" to either accept the request or opportunity to the "Delegator" to either accept the request or
delegate it to another CU. delegate it to another CU.
Response from "E" to "A" and "C". Note the use of the "COMMENT" Response from "E" to "A" and "C". Note the use of the "COMMENT"
property "E" uses to indicate why the delegation was declined. property "E" uses to indicate why the delegation was declined.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REPLY METHOD:REPLY
skipping to change at page 81, line 5 skipping to change at page 80, line 5
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
these individuals. these individuals.
Messages related to a previously canceled event ("SEQUENCE" property Messages related to a previously canceled event ("SEQUENCE" property
value is less than the "SEQUENCE" property value of the "CANCEL" value is less than the "SEQUENCE" property value of the "CANCEL"
message) MUST be ignored. message) MUST be ignored.
+-------------+---------------------+-------------------------------+ +-------------+--------------------+--------------------------------+
| Action | "Organizer" | "Attendee" | | Action | "Organizer" | "Attendee" |
+-------------+---------------------+-------------------------------+ +-------------+--------------------+--------------------------------+
| Initiate a | "A" sends a REQUEST | | | Initiate a | "A" sends a | |
| meeting | message to "B", | | | meeting | REQUEST message to | |
| request | "C", and "D" | | | request | "B", "C", and "D" | |
| | | | | | | |
| Decline the | | "B" sends a "REPLY" message | | Decline the | | "B" sends a "REPLY" message to |
| meeting | | to "A" with its "partstat" | | meeting | | "A" with its "PARTSTAT" |
| request | | para-set to "declined". | | request | | parameter set to "DECLINED". |
| | | | | | | |
| Cancel the | "A" sends a CANCEL | | | Cancel the | "A" sends a CANCEL | |
| meeting | message to "B", "C" | | | meeting | message to "B", | |
| | and "D" | | | | "C" and "D" | |
+-------------+---------------------+-------------------------------+ +-------------+--------------------+--------------------------------+
The example shows how "A" cancels the event. The example shows how "A" cancels the event.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//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;TYPE=INDIVIDUAL;Mailto:A@example.com ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com
skipping to change at page 100, line 26 skipping to change at page 100, line 26
+--------------+------------------------+---------------------------+ +--------------+------------------------+---------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+--------------+------------------------+---------------------------+ +--------------+------------------------+---------------------------+
| Initiate a | "A" sends a REQUEST | | | Initiate a | "A" sends a REQUEST | |
| to-do | message to "B", "C", | | | to-do | message to "B", "C", | |
| request | and "D" | | | request | and "D" | |
| | | | | | | |
| Accept the | | "B" sends a "REPLY" | | Accept the | | "B" sends a "REPLY" |
| to-do | | message to "A" with its | | to-do | | message to "A" with its |
| request | | "partstat" parameter set | | request | | "PARTSTAT" parameter set |
| | | to "accepted". | | | | to "ACCEPTED". |
| | | | | | | |
| Decline the | | "C" sends a REPLY message | | Decline the | | "C" sends a REPLY message |
| to-do | | to "A" with its | | to-do | | to "A" with its |
| 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 | | accept the | | to "A" with its |
| to-do | | "partstat" parameter set | | to-do | | "PARTSTAT" parameter set |
| request | | to "tentative". | | request | | to "TENTATIVE". |
| | | | | | | |
| Check | "A" sends a REQUEST | | | Check | "A" sends a REQUEST | |
| attendee | message to "B" and "D" | | | attendee | message to "B" and "D" | |
| completion | with current | | | completion | with current | |
| status | information. | | | status | information. | |
| | | | | | | |
| Attendee | | "B" sends a "REPLY" | | Attendee | | "B" sends a "REPLY" |
| indicates | | message indicating | | indicates | | message indicating |
| percent | | percent complete | | percent | | percent complete |
| complete | | | | complete | | |
skipping to change at page 101, line 49 skipping to change at page 102, line 4
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
COMMENT:I'll send you my input by e-mail COMMENT:I'll send you my input by e-mail
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970717T203000Z DTSTAMP:19970717T203000Z
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
"B" could have declined the TODO or indicated tentative acceptance by "B" could have declined the TODO or indicated tentative acceptance by
setting the "partstat" property parameter sequence to "declined" or setting the "PARTSTAT" property parameter sequence to "DECLINED" or
"tentative", respectively. "TENTATIVE", respectively.
4.5.3. A VTODO Request for Updated Status 4.5.3. A VTODO Request for Updated Status
"A" requests status from all "Attendees". "A" requests status from all "Attendees".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
skipping to change at page 119, line 21 skipping to change at page 119, line 21
TBD. Will be based on 2445bis changes. TBD. Will be based on 2445bis changes.
8. References 8. References
8.1. Normative References 8.1. 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-05 (work in progress), draft-ietf-calsify-rfc2445bis-07 (work in progress),
January 2007. July 2007.
[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-03 (work Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-03 (work
in progress), February 2007. in progress), February 2007.
[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.
skipping to change at page 120, line 5 skipping to change at page 120, line 5
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
8.2. Informative References 8.2. Informative References
Appendix A. Acknowledgments Appendix A. Acknowledgments
This is an update to the original iTIP document authored by This is an update to the original iTIP document authored by
S.Silverberg, S. Mansour, F. Dawson and R. Hopson. S.Silverberg, S. Mansour, F. Dawson and R. Hopson.
Appendix B. Change History (to be removed prior to publication as an
RFC)
Changes in -04:
a. Added empty IANA Considerations section - to be done.
b. Formatting fixes.
c. Changed VEVENT, VTODO, VJOURNAL cancel descriptions that
incorrectly implied RECURRENCE-ID could appear multiple times in
a single component.
d. [Issue91] FREEBUSY properties changed to '0+' from '1+' in
VFREEBUSY PUBLISH and REPLY tables.
e. [Issue89] Description for VEVENT ADD method simplified for
clarity.
f. Fixed some iCalendar property/parameter/value capitalization
issues.
g. MAY NOT -> MUST NOT in VFREEBUSY FREEBUSY response type.
Changes in -03:
a. Added empty IANA Considerations section - to be done.
Changes in -02:
a. Tweaked abstract wording.
b. Fixed some improper references.
c. Removed bogus TZOFFSET entry from VTIMEZONE restriction table.
d. Changed TZNAME entry in VTIMEZONE restriction table to "0+" from
"0 or 1" to fall in line with 2445.
e. Changed COMMENT entry in component restriction tables to "0+"
from "0 or 1" to fall in line with 2445.
f. Added ATTENDEE entry in VALARM restriction table to match email
alarm type in 2445.
g. Changed CATEGORIES entry in component restriction tables to "0+"
from "0 or 1" to fall in line with 2445.
h. Changed RESOURCES entry in component restriction tables to "0+"
from "0 or 1" to fall in line with 2445.
i. Changed CONTACT entry in VFREEBUSY restriction table to "0 or 1"
from "0+" to fall in line with 2445.
j. Made UID required in VFREEBUSY publish.
k. Added COMPLETED entry in VTODO restriction tables to fall in line
with 2445.
l. Added REQUEST-STATUS entry in VJOURNAL restriction tables to fall
in line with 2445.
Changes in -01:
a. Updated to 2445bis and 2447bis references.
Changes in -00 (from RFC2446):
a. Updated to latest i-d boilerplate text.
b. Rewrote abstract and introduction.
c. Reformatted Formatting Conventions section.
d. Split ITIP Roles and Transactions into two sections
e. iTIP roles uses a table to describe different roles
f. Converted tables into xml2rfc format.
Author's Address Author's Address
Cyrus Daboo (editor) Cyrus Daboo (editor)
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
Email: cyrus@daboo.name Email: cyrus@daboo.name
URI: http://www.apple.com/ URI: http://www.apple.com/
 End of changes. 66 change blocks. 
225 lines changed or deleted 235 lines changed or added

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