draft-ietf-calsify-2446bis-08.txt   draft-ietf-calsify-2446bis-09.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) November 3, 2008 Obsoletes: 2446 (if approved) April 19, 2009
Intended status: Standards Track Intended status: Standards Track
Expires: May 7, 2009 Expires: October 21, 2009
iCalendar Transport-Independent Interoperability Protocol (iTIP) iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-08 draft-ietf-calsify-2446bis-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. This Internet-Draft will expire on October 21, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 calendaring 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
calendaring systems. These scheduling methods permit two or more calendaring systems. These scheduling methods permit two or more
calendaring systems to perform transactions such as publish, calendaring systems to perform transactions such as publish,
schedule, reschedule, respond to scheduling requests, negotiation of schedule, reschedule, respond to scheduling requests, negotiation of
changes or cancel. changes or cancel.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 6
1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 5 1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6
1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 6 1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 7
1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Interoperability Models . . . . . . . . . . . . . . . . . . . 8 2. Interoperability Models . . . . . . . . . . . . . . . . . . . 9
2.1. Application Protocol . . . . . . . . . . . . . . . . . . 9 2.1. Application Protocol . . . . . . . . . . . . . . . . . . 10
2.1.1. Scheduling State . . . . . . . . . . . . . . . . . . 9 2.1.1. Scheduling State . . . . . . . . . . . . . . . . . . 10
2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 10 2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 11
2.1.3. Acting on Behalf of other Calendar Users . . . . . . 10 2.1.3. Acting on Behalf of other Calendar Users . . . . . . 11
2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 10 2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 11
2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 12 2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 13
3. Application Protocol Elements . . . . . . . . . . . . . . . . 13 3. Application Protocol Elements . . . . . . . . . . . . . . . . 14
3.1. Common Component Restriction Tables . . . . . . . . . . . 14 3.1. Common Component Restriction Tables . . . . . . . . . . . 15
3.1.1. VCALENDAR . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1. VCALENDAR . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2. VTIMEZONE . . . . . . . . . . . . . . . . . . . . . . 14 3.1.2. VTIMEZONE . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3. VALARM . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.3. VALARM . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Methods for VEVENT Calendar Components . . . . . . . . . 16 3.2. Methods for VEVENT Calendar Components . . . . . . . . . 17
3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 33 3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 34
3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 34 3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 36
3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4. Methods For VTODO Components . . . . . . . . . . . . . . 39 3.4. Methods For VTODO Components . . . . . . . . . . . . . . 41
3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 40 3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 42 3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 50 3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 54 3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 56 3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 58
3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 58 3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 60
3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 58 3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 62 3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 65
3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 64 3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 67
3.7. Implementation Considerations . . . . . . . . . . . . . . 67 3.7. Implementation Considerations . . . . . . . . . . . . . . 70
3.7.1. Working With Recurrence Instances . . . . . . . . . . 67 3.7.1. Working With Recurrence Instances . . . . . . . . . . 70
3.7.2. Attendee Property Considerations . . . . . . . . . . 68 3.7.2. Attendee Property Considerations . . . . . . . . . . 71
3.7.3. Extension Tokens . . . . . . . . . . . . . . . . . . 69 3.7.3. Extension Tokens . . . . . . . . . . . . . . . . . . 72
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1. Published Event Examples . . . . . . . . . . . . . . . . 69 4.1. Published Event Examples . . . . . . . . . . . . . . . . 72
4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 70 4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 73
4.1.2. Changing A Published Event . . . . . . . . . . . . . 70 4.1.2. Changing A Published Event . . . . . . . . . . . . . 73
4.1.3. Canceling A Published Event . . . . . . . . . . . . . 71 4.1.3. Canceling A Published Event . . . . . . . . . . . . . 74
4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 71 4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 74
4.1.5. Anniversaries or Events attached to entire days . . . 73 4.1.5. Anniversaries or Events attached to entire days . . . 76
4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 73 4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 76
4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 74 4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 77
4.2.2. Reply To A Group Event Request . . . . . . . . . . . 75 4.2.2. Reply To A Group Event Request . . . . . . . . . . . 78
4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 75 4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 78
4.2.4. Countering an Event Proposal . . . . . . . . . . . . 76 4.2.4. Countering an Event Proposal . . . . . . . . . . . . 79
4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 79 4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 82
4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 81 4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 84
4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 82 4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 85
4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 83 4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 86
4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 83 4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 86
4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 84 4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 87
4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 86 4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 89
4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 87 4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 90
4.3.1. Publish Busy Time . . . . . . . . . . . . . . . . . . 87 4.3.1. Publish Busy Time . . . . . . . . . . . . . . . . . . 90
4.3.2. Request Busy Time . . . . . . . . . . . . . . . . . . 88 4.3.2. Request Busy Time . . . . . . . . . . . . . . . . . . 91
4.3.3. Reply To A Busy Time Request . . . . . . . . . . . . 89 4.3.3. Reply To A Busy Time Request . . . . . . . . . . . . 92
4.4. Recurring Event and Time Zone Examples . . . . . . . . . 89 4.4. Recurring Event and Time Zone Examples . . . . . . . . . 92
4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 89 4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 92
4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 91 4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 94
4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 93 4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 96
4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 94 4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 97
4.4.5. Change All Future Instances . . . . . . . . . . . . . 94 4.4.5. Change All Future Instances . . . . . . . . . . . . . 97
4.4.6. Add A New Instance To A Recurring Event . . . . . . . 95 4.4.6. Add A New Instance To A Recurring Event . . . . . . . 98
4.4.7. Add A New Series of Instances To A Recurring Event . 96 4.4.7. Add A New Series of Instances To A Recurring Event . 99
4.4.8. Counter An Instance Of A Recurring Event . . . . . . 101 4.4.8. Refreshing A Recurring Event . . . . . . . . . . . . 101
4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 102 4.4.9. Counter An Instance Of A Recurring Event . . . . . . 103
4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 104 4.4.10. Error Reply To A Request . . . . . . . . . . . . . . 104
4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 105 4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 106
4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 105 4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 107
4.5.3. A VTODO Request for Updated Status . . . . . . . . . 106 4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 107
4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 106 4.5.3. A VTODO Request for Updated Status . . . . . . . . . 108
4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 107 4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 108
4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 107 4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 109
4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 108 4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 109
4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 109 4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 110
4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 109 4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 111
4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 109 4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 111
4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 110 4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 111
5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 113 4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 112
5.1. Partial Implementation . . . . . . . . . . . . . . . . . 113 5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 115
5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 113 5.1. Partial Implementation . . . . . . . . . . . . . . . . . 115
5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 115 5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 115
5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 116 5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 117
5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 118 5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 118
5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 119 5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 120
5.2.1. Cancellation of an Unknown Calendar Component. . . . 119 5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 121
5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 120 5.2.1. Cancellation of an Unknown Calendar Component. . . . 121
5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 120 5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 122
6. Security Considerations . . . . . . . . . . . . . . . . . . . 120 5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 122
6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 120 6. Security Considerations . . . . . . . . . . . . . . . . . . . 122
6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 120 6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 122
6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 120 6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 122
6.1.3. Unauthorized Replacement of the Organizer . . . . . . 121 6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 122
6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 121 6.1.3. Unauthorized Replacement of the Organizer . . . . . . 123
6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 121 6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 123
6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 121 6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 123
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 121 6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 123
6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 121 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 123
6.2.2. Implementation Controls . . . . . . . . . . . . . . . 122 6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 123
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 122 6.2.2. Implementation Controls . . . . . . . . . . . . . . . 124
7.1. METHOD:PUBLISH . . . . . . . . . . . . . . . . . . . . . 123 6.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 124
7.2. METHOD:REQUEST . . . . . . . . . . . . . . . . . . . . . 123 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 124
7.3. METHOD:REPLY . . . . . . . . . . . . . . . . . . . . . . 123 7.1. METHOD:PUBLISH . . . . . . . . . . . . . . . . . . . . . 125
7.4. METHOD:ADD . . . . . . . . . . . . . . . . . . . . . . . 123 7.2. METHOD:REQUEST . . . . . . . . . . . . . . . . . . . . . 125
7.5. METHOD:CANCEL . . . . . . . . . . . . . . . . . . . . . . 124 7.3. METHOD:REPLY . . . . . . . . . . . . . . . . . . . . . . 125
7.6. METHOD:REFRESH . . . . . . . . . . . . . . . . . . . . . 124 7.4. METHOD:ADD . . . . . . . . . . . . . . . . . . . . . . . 125
7.7. METHOD:COUNTER . . . . . . . . . . . . . . . . . . . . . 124 7.5. METHOD:CANCEL . . . . . . . . . . . . . . . . . . . . . . 126
7.8. METHOD:DECLINE-COUNTER . . . . . . . . . . . . . . . . . 124 7.6. METHOD:REFRESH . . . . . . . . . . . . . . . . . . . . . 126
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 124 7.7. METHOD:COUNTER . . . . . . . . . . . . . . . . . . . . . 126
9. Normative References . . . . . . . . . . . . . . . . . . . . 125 7.8. METHOD:DECLINECOUNTER . . . . . . . . . . . . . . . . . . 126
Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 125 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 126
A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 125 9. Normative References . . . . . . . . . . . . . . . . . . . . 127
A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 126 Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 127
A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 127
A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 128
Appendix B. Change History (to be removed prior to Appendix B. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . 126 publication as an RFC) . . . . . . . . . . . . . . . 128
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 129 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 131
Intellectual Property and Copyright Statements . . . . . . . . . 130
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
calendaring 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
skipping to change at page 7, line 22 skipping to change at page 8, line 22
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
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 an iCalendar object to one or | | PUBLISH | Used to publish an iCalendar object to one or |
| | more 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. |
skipping to change at page 10, line 30 skipping to change at page 11, line 30
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
In many organizations one user will act on behalf of another to In many organizations one user will act on behalf of another to
organize and/or respond to meeting requests. ITIP provides two organize and/or respond to meeting requests. iTIP provides two
mechanisms that support these activities. mechanisms that support these activities.
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
skipping to change at page 13, line 13 skipping to change at page 14, line 13
in order to correctly process iTIP messages: "UID", "RECURRENCE-ID", in order to correctly process iTIP messages: "UID", "RECURRENCE-ID",
"SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property
of a component, "Organizer" CUAs will need to persist the "SEQUENCE" of a component, "Organizer" CUAs will need to persist the "SEQUENCE"
and "DTSTAMP" property values associated with the "Attendee's" last and "DTSTAMP" property values associated with the "Attendee's" last
response, so that any earlier responses from an "Attendee" that are 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 received out of order (e.g., due to a delay in the transport) can be
correctly discarded. 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.
+----------------+--------+-------+----------+-----------+ +----------------+--------+-------+----------+-----------+
| | VEVENT | VTODO | VJOURNAL | VFREEBUSY | | | VEVENT | VTODO | VJOURNAL | VFREEBUSY |
+----------------+--------+-------+----------+-----------+ +----------------+--------+-------+----------+-----------+
skipping to change at page 14, line 47 skipping to change at page 15, line 47
| VERSION | 1 | Value MUST be "2.0" | | VERSION | 1 | Value MUST be "2.0" |
| IANA-PROPERTY | 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 | | 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+ | |
| | | present | | RRULE | 0 or 1 | |
| RRULE | 0 or 1 | if present RDATE MUST NOT be |
| | | present |
| TZNAME | 0+ | | | TZNAME | 0+ | |
| TZOFFSETFROM | 1 | | | TZOFFSETFROM | 1 | |
| TZOFFSETTO | 1 | | | TZOFFSETTO | 1 | |
| IANA-PROPERTY | 0+ | | | 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 |
skipping to change at page 15, line 45 skipping to change at page 16, line 43
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| TZID | 1 | | | TZID | 1 | |
| TZURL | 0 or 1 | | | TZURL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | 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 | | Constraints for VALARM Components |
+-----------------------------------+ +-----------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| VALARM | 0+ | | | VALARM | 0+ | |
| ACTION | 1 | | | ACTION | 1 | |
| ATTACH | 0+ | | | ATTACH | 0+ | |
skipping to change at page 20, line 38 skipping to change at page 21, line 38
| 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 or 1 | | | 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+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
skipping to change at page 21, line 49 skipping to change at page 22, line 49
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
skipping to change at page 23, line 9 skipping to change at page 24, line 9
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 a "VEVENT" calendar component may send the
the event. The invited "Attendee" accomplishes this by forwarding "VEVENT" calendar component to another new CU, not previously
the original "REQUEST" method to the uninvited CU. The uninvited CU associated with the "VEVENT" calendar component. The current
then replies to the "Organizer". The "Organizer" decides whether or "Attendee" invited to the "VEVENT" calendar component does this by
not the uninvited CU is added to the attendee list. If the forwarding the original "REQUEST" method to the new CU. The new CU
"Organizer" decides not to add the uninvited CU no further action is can send a "REPLY" to the "Organizer" of the "VEVENT" calendar
required, however the "Organizer" MAY send the uninvited CU a component. The reply contains an "ATTENDEE" property for the new CU.
"CANCEL" message. If the "Organizer" decides to add an uninvited CU,
a new "ATTENDEE" property is added for the uninvited CU with its The "Organizer" ultimately decides whether or not the new CU becomes
property parameters set as the "Organizer" deems appropriate. When part of the event and is not obligated to do anything with a "REPLY"
forwarding a "REQUEST" to another CU, the forwarding "Attendee" MUST from a new (uninvited) CU. If the "Organizer" does not want the new
NOT make changes to the original message. CU to be part of the event, the new "ATTENDEE" property is not added
to the "VEVENT" calendar component. The "Organizer" MAY send the CU
a "CANCEL" message to indicate that they will not be added to the
event. If the "Organizer" decides to add the new CU, the new
"ATTENDEE" property is added to the "VEVENT" calendar component.
Furthermore, the "Organizer" is free to change any "ATTENDEE"
property parameter from the values supplied by the new CU to
something the "Organizer" considers appropriate. The "Organizer"
SHOULD send the new CU a "REQUEST" message to inform them that they
have been added.
When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
MUST 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 25, line 49 skipping to change at page 27, line 13
| 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
instances to an existing "VEVENT" using a single ITIP message without instances to an existing "VEVENT" using a single iTIP message without
having to send the entire "VEVENT" with all the existing instance having to send the entire "VEVENT" with all the existing instance
data, as it would have to do if the "REQUEST" method were used. data, as it would have to do if the "REQUEST" method were used.
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".
When handling an "ADD" message, the "Attendee" treats each component
in the "ADD" message as if it were referenced via an "RDATE"in the
main 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:ADD of a VEVENT | | Constraints for a METHOD:ADD of a VEVENT |
+------------------------------------------+ +------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 26, line 44 skipping to change at page 28, line 12
| 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 | Can be null | | DESCRIPTION | 0 or 1 | Can be null |
| 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+ | |
| 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+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 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+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| EXDATE | 0 | |
| RECURRENCE-ID | 0 | | | RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| RDATE | 0 | |
| RRULE | 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+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
skipping to change at page 27, line 51 skipping to change at page 29, line 20
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
"THISANDFUTURE" to indicate cancellation of the specified "THISANDFUTURE" to indicate cancellation of the specified
"VEVENT" calendar component and all instances after; or "VEVENT" calendar component and all instances after; or
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.
The "Organizer" is MUST send a "CANCEL" message to each "Attendee"
affected by the cancellation. This can be done using a single
"CANCEL" message for all "Attendees", or multiple messages with
different subsets of the affected "Attendees" in each.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented as described in Section 2.1.4.
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 | | 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 some or all |
| | | being removed from the event. | | | | "Attendees" being removed from |
| | | MUST include all "Attendees" if | | | | the event. MUST include some or |
| | | the entire event is cancelled. | | | | all "Attendees" if 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 31, line 21 skipping to change at page 32, line 45
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. The "Attendee" sends this message to counter proposal to the event. The "Attendee" sends this 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 "DECLINECOUNTER" method. The "Organizer" accepts the
the counter proposal by rescheduling the event as described in counter proposal by rescheduling the event as described in section
section 3.2.2.1 Rescheduling an Event. 3.2.2.1 Rescheduling an Event. The "Organizers" CUA SHOULD send a
"REQUEST" message to all "Attendees" affected by any change triggered
by an accepted "COUNTER".
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 | | Constraints for a METHOD:COUNTER of a VEVENT |
+----------------------------------------------+ +----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
skipping to change at page 33, line 25 skipping to change at page 34, line 48
+-----------------------------------------------------+ +-----------------------------------------------------+
| Constraints for a METHOD:DECLINECOUNTER of a VEVENT | | 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+ | All components MUST have the same |
| | | UID |
| ATTENDEE | 1+ | MUST for all attendees |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| UID | 1 | MUST, same UID specified in | | SEQUENCE | 1 | MUST echo the original SEQUENCE |
| | | original REQUEST and subsequent | | | | number |
| | | COUNTER | | UID | 1 | MUST echo original UID |
| ATTACH | 0+ | |
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null |
| DTSTART | 0 or 1 | |
| DTEND | 0 or 1 | if present DURATION MUST NOT be |
| | | present |
| DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | |
| 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+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| SEQUENCE | 0 or 1 | MUST be present if value is | | RESOURCES | 0+ | |
| | | greater than 0, MAY be present if | | RRULE | 0 or 1 | |
| | | 0 | | STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED |
| SUMMARY | 0 or 1 | Can be null |
| TRANSP | 0 or 1 | |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTACH | 0 | |
| ATTENDEE | 0 | |
| CATEGORIES | 0 | |
| CLASS | 0 | |
| CONTACT | 0 | |
| CREATED | 0 | |
| DESCRIPTION | 0 | |
| DTEND | 0 | |
| DTSTART | 0 | |
| DURATION | 0 | |
| EXDATE | 0 | |
| GEO | 0 | |
| LAST-MODIFIED | 0 | |
| LOCATION | 0 | |
| PRIORITY | 0 | |
| RDATE | 0 | |
| RELATED-TO | 0 | |
| RESOURCES | 0 | |
| RRULE | 0 | |
| STATUS | 0 | |
| SUMMARY | 0 | |
| TRANSP | 0 | |
| URL | 0 | |
| | | | | | | |
| VALARM | 0 | |
| | | | | | | |
| VTIMEZONE | 0+ | | | VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone |
| | | | | | | |
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VTODO | 0 | | | VALARM | 0 | |
| VFREEBUSY | 0 | |
| | | | | | | |
| VJOURNAL | 0 | | | VJOURNAL | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VTODO | 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
skipping to change at page 35, line 6 skipping to change at page 36, line 31
"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. Busy time periods may also span a day time for earlier today. Busy time periods can also span a day
boundary. boundary.
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. |
| | | | | |
skipping to change at page 39, line 15 skipping to change at page 41, 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 | MUST be the address of the | | ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. | | | | 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+ | MUST be BUSYTIME. Multiple |
| | | data type. Multiple instances | | | | instances are allowed. Multiple |
| | | SHOULD be sorted in ascending | | | | instances SHOULD be sorted in |
| | | order. Values MUST NOT overlap | | | | ascending order |
| ORGANIZER | 1 | MUST be the request originator's | | ORGANIZER | 1 | MUST be the request originator's |
| | | address | | | | address |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | 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+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
skipping to change at page 46, line 44 skipping to change at page 48, line 44
The "Organizer" ultimately decides whether or not the new CU becomes The "Organizer" ultimately decides whether or not the new CU becomes
part of the to-do and is not obligated to do anything with a "REPLY" part of the to-do and is not obligated to do anything with a "REPLY"
from a new (uninvited) CU. If the "Organizer" does not want the new from a new (uninvited) CU. If the "Organizer" does not want the new
CU to be part of the to-do, the new "ATTENDEE" property is not added CU to be part of the to-do, the new "ATTENDEE" property is not added
to the "VTODO" calendar component. The "Organizer" MAY send the CU a to the "VTODO" calendar component. The "Organizer" MAY send the CU a
"CANCEL" message to indicate that they will not be added to the to- "CANCEL" message to indicate that they will not be added to the to-
do. If the "Organizer" decides to add the new CU, the new "ATTENDEE" do. If the "Organizer" decides to add the new CU, the new "ATTENDEE"
property is added to the "VTODO" calendar component. Furthermore, property is added to the "VTODO" calendar component. Furthermore,
the "Organizer" is free to change any "ATTENDEE" property parameter the "Organizer" is free to change any "ATTENDEE" property parameter
from the values supplied by the new CU to something the "Organizer" from the values supplied by the new CU to something the "Organizer"
considers appropriate. considers appropriate. The "Organizer" SHOULD send the new attendee
a "REQUEST" message to inform them that they have been added.
When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
MUST NOT make changes to the original message.
3.4.2.5. REQUEST Updated Attendee Status 3.4.2.5. REQUEST Updated Attendee Status
An "Organizer" of a "VTODO" may request an updated status from one or An "Organizer" of a "VTODO" may request an updated status from one or
more "Attendees". The "Organizer" sends a "REQUEST" method to the more "Attendees". The "Organizer" sends a "REQUEST" method to the
"Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The
"SEQUENCE" property for the "VTODO" is not changed from its previous "SEQUENCE" property for the "VTODO" is not changed from its previous
value. A recipient determines that the only change in the "REQUEST" value. A recipient determines that the only change in the "REQUEST"
is that their "RSVP" property parameter indicates a request for an is that their "RSVP" property parameter indicates a request for an
updated status. The recipient SHOULD respond with a "REPLY" method updated status. The recipient SHOULD respond with a "REPLY" method
skipping to change at page 48, line 4 skipping to change at page 50, line 11
| 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 | 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 | |
| REQUEST-STATUS | 1+ | | | REQUEST-STATUS | 0+ | |
| UID | 1 | MUST be the UID of the original | | UID | 1 | MUST be the UID of the original |
| | | REQUEST | | | | 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 | |
skipping to change at page 49, line 10 skipping to change at page 51, line 17
| IANA-COMPONENT | 0+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 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 allows the "Organizer" to add one or more new
or more instances to an existing to-do. instances to an existing "VTODO" using a single iTIP message without
having to send the entire "VTODO" with all the existing instance
data, as it would have to do if the "REQUEST" method were used.
If the "UID" property value in the "ADD" is not found on the The "UID" must be that of the existing to-do. If the "UID" property
recipient's calendar, then the recipient SHOULD send a "REFRESH" to value in the "ADD" is not found on the recipient's calendar, then the
the "Organizer" in order to be updated with the latest version of the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
"VTODO". If an "Attendee" implementation does not support the "ADD" updated with the latest version of the "VTODO". If an "Attendee"
method it should respond with a "REQUEST-STATUS" value of 3.14 and implementation does not support the "ADD" method it should respond
ask for a "REFRESH". with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
When handling an "ADD" message, the "Attendee" treats each component
in the "ADD" message as if it were referenced via an "RDATE"in the
main component.
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 | | Constraints for a METHOD:ADD of a VTODO |
+-----------------------------------------+ +-----------------------------------------+
skipping to change at page 50, line 9 skipping to change at page 52, line 22
| 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 | Can be null | | DESCRIPTION | 0 or 1 | Can be null |
| 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 |
| | | 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+ | |
| 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+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RESOURCES | 0+ | | | RESOURCES | 0+ | |
| RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | COMPLETED/NEEDS-ACTION/ | | | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS | | | | IN-PROCESS |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| EXDATE | 0 | |
| RECURRENCE-ID | 0 | | | RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| RDATE | 0 | |
| RRULE | 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+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
skipping to change at page 51, line 21 skipping to change at page 53, line 34
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
"THISANDFUTURE" to indicate cancellation of the specified "VTODO" "THISANDFUTURE" to indicate cancellation of the specified "VTODO"
calendar component and all instances after calendar component and all instances after
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
The "Organizer" is MUST send a "CANCEL" message to each "Attendee"
affected by the cancellation. This can be done using a single
"CANCEL" message for all "Attendees", or multiple messages with
different subsets of the affected "Attendees" in each.
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented as described in Section 2.1.4.
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 | | 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+ | MUST include some or all |
| | | removed from the todo. MUST | | | | "Attendees" being removed from |
| | | include all "Attendees" if the | | | | the to-do. MUST include some or |
| | | entire todo is cancelled. | | | | all "Attendees" if the entire |
| | | to-do 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+ | |
| CLASS | 0 or 1 | | | CLASS | 0 or 1 | |
| COMMENT | 0+ | | | COMMENT | 0+ | |
| COMPLETED | 0 or 1 | | | COMPLETED | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
skipping to change at page 54, line 42 skipping to change at page 57, line 17
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 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 rescheduling the to-do as described in section
calendar component a "REQUEST" method rescheduling the "VTODO" 3.4.2.1 Rescheduling a To-Do. The "Organizers" CUA SHOULD send a
calendar component. In the latter case, the "Organizer" SHOULD reset "REQUEST" message to all "Attendees" affected by any change triggered
the individual "RSVP" property parameter values to TRUE on each by an accepted "COUNTER".
"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 | | Constraints for a METHOD:COUNTER of a VTODO |
+---------------------------------------------+ +---------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
skipping to change at page 60, line 10 skipping to change at page 63, line 10
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.5.2. ADD 3.5.2. ADD
The "ADD" method in a "VJOURNAL" calendar component is used to add The "ADD" method allows the "Organizer" to add one or more new
one or more instances to an existing "VJOURNAL" entry. There is no instances to an existing "VJOURNAL" using a single iTIP message
response to the "Organizer". without having to send the entire "VJOURNAL" with all the existing
instance data, as it would have to do if the "REQUEST" method were
used.
If the "UID" property value in the "ADD" is not found on the The "UID" must be that of the existing journal entry. If the "UID"
recipient's calendar, then the recipient MAY treat the "ADD" as a property value in the "ADD" is not found on the recipient's calendar,
"PUBLISH". then the recipient MAY treat the "ADD" as a "PUBLISH".
When handling an "ADD" message, the "Attendee" treats each component
in the "ADD" message as if it were referenced via an "RDATE"in the
main component. There is no response to the "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:ADD of a VJOURNAL | | Constraints for a METHOD:ADD of a VJOURNAL |
+--------------------------------------------+ +--------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 61, line 23 skipping to change at page 64, line 23
| ORGANIZER | 1 | | | ORGANIZER | 1 | |
| SEQUENCE | 1 | MUST be greater than 0 | | SEQUENCE | 1 | MUST be greater than 0 |
| UID | 1 | MUST match that of the original | | UID | 1 | MUST match that of the original |
| | | journal | | | | journal |
| 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+ | |
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| RDATE | 0+ | |
| RELATED-TO | 0+ | | | RELATED-TO | 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+ | | | IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| EXDATE | 0 | |
| RECURRENCE-ID | 0 | | | RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | | | REQUEST-STATUS | 0 | |
| RDATE | 0 | |
| RRULE | 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+ | | | IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | | | X-COMPONENT | 0+ | |
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
skipping to change at page 62, line 30 skipping to change at page 65, line 30
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
"THISANDFUTURE" to indicate cancellation of the specified "VTODO" "THISANDFUTURE" to indicate cancellation of the specified "VTODO"
calendar component and all instances after calendar component and all instances after
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 as described in Section 2.1.4.
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 | | Constraints for a METHOD:CANCEL of a VJOURNAL |
+-----------------------------------------------+ +-----------------------------------------------+
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
skipping to change at page 64, line 11 skipping to change at page 67, line 11
| 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
about a REPLY, COUNTER or DECLINE-COUNTER iTIP message. The codes about a REPLY, COUNTER or DECLINECOUNTER iTIP message. The codes
listed in the table below SHOULD be used. Additional codes MAY be listed in the table below SHOULD be used. Additional codes MAY be
used provided they are defined in a Standards Track or Experimental used provided they are defined in a Standards Track or Experimental
RFC. RFC.
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
skipping to change at page 68, line 35 skipping to change at page 71, line 35
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
problems. problems.
There are valid [RFC2822] addresses that represent groups. Sending There are valid [RFC5322] addresses that represent groups. Sending
email to such an address results in mail being sent to multiple email to such an address results in mail being sent to multiple
recipients. Such an address may be used as the value of an recipients. Such an address may be used as the value of an
"ATTENDEE" property. Thus, it is possible that the recipient of a "ATTENDEE" property. Thus, it is possible that the recipient of a
"REQUEST" does not appear explicitly in the list. "REQUEST" does not appear explicitly in the list.
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"
skipping to change at page 96, line 32 skipping to change at page 99, line 32
LOCATION:Conference Call LOCATION:Conference Call
DTSTAMP:19970629T093000Z DTSTAMP:19970629T093000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.7. Add A New Series of Instances To A Recurring Event 4.4.7. Add A New Series of Instances To A Recurring Event
The scenario for this example involves an ongoing meeting, originally The scenario for this example involves an ongoing meeting, originally
set up to occur every Tuesday. The "Organizer" later decides that set up to occur every Tuesday. The "Organizer" later decides that
the meetings need to be on Tuesdays and Thursdays, but does not want the meetings need to be on Tuesdays and Thursdays.
to reschedule the entire meeting or lose any of the per-instance
information already collected.
The original event: The original event:
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@example.com UID:123456789@example.com
SEQUENCE:0 SEQUENCE:0
skipping to change at page 97, line 25 skipping to change at page 100, line 25
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
SUMMARY:Review Accounts SUMMARY:Review Accounts
DTSTART:19980303T210000Z DTSTART:19980303T210000Z
DTEND:19980303T220000Z DTEND:19980303T220000Z
LOCATION:The White Room LOCATION:The White Room
DTSTAMP:19980301T093000Z DTSTAMP:19980301T093000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Assume that many other updates happen to this event and that a lot of The entire event can be rescheduled using a "REQUEST". This is done
instance-specific information exists in the recurring series. The by using the "UID" of the event to reschedule and including the
"SEQUENCE" property value is 7 for the next update. Now the modified "RRULE". Note, that since this is an entire rescheduling of
"Organizer" wants to add Thursdays to the event: the event, any instance-specific information will be lost, unless
explicitly included with the update "REQUEST".
BEGIN:VCALENDAR
METHOD:ADD
PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0
BEGIN:VEVENT
UID:123456789@example.com
SEQUENCE:7
RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY
ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com
SUMMARY:Review Accounts
DTSTART:19980303T210000Z
DTEND:19980303T220000Z
DTSTAMP:19980303T193000Z
LOCATION:The Usual conference room
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
Alternatively, if the "Organizer" is not concerned with per-instance
updates, the entire event can be rescheduled using a "REQUEST". This
is done by using the "UID" of the event to reschedule and including
the modified "RRULE". Note, that since this is an entire
rescheduling of the event, any instance-specific information will be
lost.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@example.com UID:123456789@example.com
SEQUENCE:7 SEQUENCE:7
RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
skipping to change at page 98, line 31 skipping to change at page 101, line 5
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
SUMMARY:Review Accounts SUMMARY:Review Accounts
DTSTART:19980303T210000Z DTSTART:19980303T210000Z
DTEND:19980303T220000Z DTEND:19980303T220000Z
DTSTAMP:19980303T193000Z DTSTAMP:19980303T193000Z
LOCATION:The White Room LOCATION:The White Room
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.8. Refreshing A Recurring Event
The next series of examples illustrate how an "Organizer" would The next series of examples illustrate how an "Organizer" would
respond to a "REFRESH" submitted by an "Attendee" after a series of respond to a "REFRESH" submitted by an "Attendee" after a series of
instance-specific modifications. To convey all instance-specific instance-specific modifications. To convey all instance-specific
changes, the "Organizer" must provide the latest event description changes, the "Organizer" must provide the latest event description
and the relevant instances. The first three examples show the and the relevant instances. The first three examples show the
history including the initial "VEVENT" request and subsequent history including the initial "VEVENT" request and subsequent
instance changes and finally the "REFRESH". instance changes and finally the "REFRESH".
Original Request: Original Request:
skipping to change at page 101, line 39 skipping to change at page 103, line 41
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
SUMMARY:Review Accounts SUMMARY:Review Accounts
DTSTART:19980311T160000Z DTSTART:19980311T160000Z
DTEND:19980304T180000Z DTEND:19980304T180000Z
DTSTAMP:19980306T193000Z DTSTAMP:19980306T193000Z
LOCATION:The Small conference room LOCATION:The Small conference room
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.8. Counter An Instance Of A Recurring Event 4.4.9. Counter An Instance Of A Recurring Event
In this example one of the "Attendees" counters the "DTSTART" In this example one of the "Attendees" counters the "DTSTART"
property of the proposed second July meeting. property of the proposed second July meeting.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:COUNTER METHOD:COUNTER
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@example.com UID:guid-1@example.com
skipping to change at page 102, line 29 skipping to change at page 104, line 29
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970715T220000Z DTSTART:19970715T220000Z
DTEND:19970715T230000Z DTEND:19970715T230000Z
LOCATION:Conference Call LOCATION:Conference Call
COMMENT:May we bump this by an hour? I have a conflict COMMENT:May we bump this by an hour? I have a conflict
DTSTAMP:19970629T094000Z DTSTAMP:19970629T094000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.9. Error Reply To A Request 4.4.10. Error Reply To A Request
The following example illustrates a scenario where a meeting is The following example illustrates a scenario where a meeting is
proposed containing an unsupported property and a bad property. proposed containing an unsupported property and a bad property.
Original Request Original Request
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
skipping to change at page 110, line 29 skipping to change at page 112, line 29
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 an iTIP "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends an iTIP
message to an "Attendee", there are three cases in which an instance message to an "Attendee", there are three cases in which an instance
cannot 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.
In case (1), two things can happen. If the "SEQUENCE" number of the In case (1), two things can happen. If the "SEQUENCE" number of the
"Attendee's" instance is larger than that in the "Organizer's" "Attendee's" instance is larger than that in the "Organizer's"
message then the "Attendee" is receiving an out-of-sequence message message then the "Attendee" is receiving an out-of-sequence message
and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" and MUST ignore it. If the "SEQUENCE" number of the "Attendee's"
skipping to change at page 113, line 23 skipping to change at page 115, line 23
section, it may be ignored. section, it may be ignored.
5.1.1. Event-Related Fallbacks 5.1.1. Event-Related Fallbacks
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Method | Fallback | | Method | Fallback |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| PUBLISH | Required | | PUBLISH | Required |
| REQUEST | PUBLISH | | REQUEST | PUBLISH |
| REPLY | Required | | REPLY | Required |
| ADD | Required | | ADD | Required if recurrences supported, otherwise |
| | reply with a REQUEST-STATUS "2.8;Success, |
| | repeating event ignored. Scheduled as a single |
| | component." and schedule as a single component. |
| CANCEL | Required | | CANCEL | Required |
| REFRESH | Required | | REFRESH | Required |
| COUNTER | Reply with "Not Supported" | | COUNTER | Reply with "Not Supported" |
| DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs, | | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs, |
| | otherwise reply with "Not Supported" | | | otherwise reply with "Not Supported" |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| iCalendar | Fallback | | iCalendar | Fallback |
| Property | | | Property | |
skipping to change at page 116, line 13 skipping to change at page 118, line 13
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
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 if recurrences supported, otherwise |
| | reply with a REQUEST-STATUS "2.8;Success, |
| | repeating event ignored. Scheduled as a single |
| | component." and schedule as a single component. |
| CANCEL | Required | | CANCEL | Required |
| REFRESH | Required | | REFRESH | Required |
| COUNTER | Reply with "Not Supported" | | COUNTER | Reply with "Not Supported" |
| DECLINECOUNTER | Required if COUNTER for VTODOs 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 | |
skipping to change at page 120, line 29 skipping to change at page 122, line 29
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
ITIP is an abstract transport protocol which will be bound to a real- iTIP is an abstract transport protocol which will be bound to a real-
time transport, a store-and-forward transport, and perhaps other time transport, a store-and-forward transport, and perhaps other
transports. The transport protocol will be responsible for providing transports. The transport protocol will be responsible for providing
facilities for authentication and encryption using standard Internet facilities for authentication and encryption using standard Internet
mechanisms that are mutually understood between the sender and mechanisms that are mutually understood between the sender and
receiver. receiver.
6.1. Security Threats 6.1. Security Threats
6.1.1. Spoofing the "Organizer" 6.1.1. Spoofing the "Organizer"
skipping to change at page 122, line 39 skipping to change at page 124, line 39
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.
6.3. Privacy Issues
The "Organizer" might want to keep "Attendees" from knowing which
other "Attendees" are participating in an event or to-do. The
"Organizer" has the choice of sending single iTIP messages with a
full list of "Attendees" or sending iTIP messages to each "Attendee"
with only that "Attendee" listed.
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 and these should be added to the Methods Registry "METHOD" property and these should be added to the Methods Registry
defined in Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis]: defined in Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis]:
7.1. METHOD:PUBLISH 7.1. METHOD:PUBLISH
Value: PUBLISH Value: PUBLISH
skipping to change at page 124, line 35 skipping to change at page 126, line 35
7.7. METHOD:COUNTER 7.7. METHOD:COUNTER
Value: COUNTER Value: COUNTER
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.
7.8. METHOD:DECLINE-COUNTER 7.8. METHOD:DECLINECOUNTER
Value: DECLINE-COUNTER Value: DECLINECOUNTER
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.
8. Acknowledgments 8. Acknowledgments
This is an update to the original iTIP document authored by This is an update to the original iTIP document authored by
skipping to change at page 125, line 14 skipping to change at page 127, line 14
specification, including: Oliver Block, Bernard Desruisseaux, Mike specification, including: Oliver Block, Bernard Desruisseaux, Mike
Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot
Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg
II, Robert Ransdell, Caleb Richardson. II, Robert Ransdell, Caleb Richardson.
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-09 (work in progress),
February 2008. October 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-05 (work Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-05 (work
in progress), June 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, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
April 2001. October 2008.
Appendix A. Differences from RFC 2446 Appendix A. Differences from RFC 2446
A.1. Changed Restrictions A.1. Changed Restrictions
This specification now defines an allowed combination of "REQUEST- This specification now defines an allowed combination of "REQUEST-
STATUS" codes when multiple iCalendar components are included in an STATUS" codes when multiple iCalendar components are included in an
iTIP message. iTIP message.
This specification now restricts "RECURRENCE-ID" to only a single This specification now restricts "RECURRENCE-ID" to only a single
skipping to change at page 126, line 51 skipping to change at page 128, 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 -08: Changes in -09:
a. Updated to RFC5322 reference.
b. Fixed more issues from Reinhold Kainhofer review being tracked on
the WG wiki.
Changes in -08:
a. AD review: Changed "calendar entry" to "iCalendar object". a. AD review: Changed "calendar entry" to "iCalendar object".
b. AD review: Added extra captions above restriction tables for more b. AD review: Added extra captions above restriction tables for more
clarity. clarity.
c. AD review: Added missing step of uninvited CU replying to c. AD review: Added missing step of uninvited CU replying to
Organizer in description of event forwarding. Organizer in description of event forwarding.
d. AD review: Clarified text about "unsuccessful" REQUEST d. AD review: Clarified text about "unsuccessful" REQUEST
processing. processing.
e. AD review: VFREEBUSY text about allowing multiple components e. AD review: VFREEBUSY text about allowing multiple components
moved into description of PUBLISH method. moved into description of PUBLISH method.
f. AD review: VTODO description changed to reflect fact that f. AD review: VTODO description changed to reflect fact that
skipping to change at page 127, line 32 skipping to change at page 129, line 37
j. AD review: Fixed example in 4.2.4. j. AD review: Fixed example in 4.2.4.
k. AD review: Clarified who is responsible for updating the k. AD review: Clarified who is responsible for updating the
delegator in 4.2.5. delegator in 4.2.5.
l. AD review: Fixed PARTSTAT in example in 4.2.6. l. AD review: Fixed PARTSTAT in example in 4.2.6.
m. AD review: Added reference to IANA methods registry in 2445bis in m. AD review: Added reference to IANA methods registry in 2445bis in
IANA section. IANA section.
n. Removed section on calculating recurring due dates as that is n. Removed section on calculating recurring due dates as that is
covered in 2445bis. covered in 2445bis.
o. Fixed lots of issues from Reinhold Kainhofer review being tracked o. Fixed lots of issues from Reinhold Kainhofer review being tracked
on the WG wiki. on the WG wiki.
p. Fixed DECLINE-COUNTER -> DECLINECOUNTER.
Changes in -07: 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.
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
skipping to change at page 128, line 45 skipping to change at page 131, line 4
from "0 or 1" to fall in line with 2445. from "0 or 1" to fall in line with 2445.
f. Added ATTENDEE entry in VALARM restriction table to match email f. Added ATTENDEE entry in VALARM restriction table to match email
alarm type in 2445. alarm type in 2445.
g. Changed CATEGORIES entry in component restriction tables to "0+" g. Changed CATEGORIES entry in component restriction tables to "0+"
from "0 or 1" to fall in line with 2445. from "0 or 1" to fall in line with 2445.
h. Changed RESOURCES entry in component restriction tables to "0+" h. Changed RESOURCES entry in component restriction tables to "0+"
from "0 or 1" to fall in line with 2445. from "0 or 1" to fall in line with 2445.
i. Changed CONTACT entry in VFREEBUSY restriction table to "0 or 1" i. Changed CONTACT entry in VFREEBUSY restriction table to "0 or 1"
from "0+" to fall in line with 2445. from "0+" to fall in line with 2445.
j. Made UID required in VFREEBUSY publish. j. Made UID required in VFREEBUSY publish.
k. Added COMPLETED entry in VTODO restriction tables to fall in line k. Added COMPLETED entry in VTODO restriction tables to fall in line
with 2445. with 2445.
l. Added REQUEST-STATUS entry in VJOURNAL restriction tables to fall l. Added REQUEST-STATUS entry in VJOURNAL restriction tables to fall
in line with 2445. in line with 2445.
Changes in -01: Changes in -01:
a. Updated to 2445bis and 2447bis references. a. Updated to 2445bis and 2447bis references.
Changes in -00 (from RFC2446): Changes in -00 (from RFC2446):
a. Updated to latest i-d boilerplate text. a. Updated to latest i-d boilerplate text.
b. Rewrote abstract and introduction. b. Rewrote abstract and introduction.
c. Reformatted Formatting Conventions section. c. Reformatted Formatting Conventions section.
d. Split ITIP Roles and Transactions into two sections d. Split iTIP Roles and Transactions into two sections
e. iTIP roles uses a table to describe different roles e. iTIP roles uses a table to describe different roles
f. Converted tables into xml2rfc format. 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/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 84 change blocks. 
297 lines changed or deleted 355 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/