draft-ietf-calsify-2446bis-05.txt   draft-ietf-calsify-2446bis-06.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) February 24, 2008 Obsoletes: 2446 (if approved) May 11, 2008
Intended status: Standards Track Intended status: Standards Track
Expires: August 27, 2008 Expires: November 12, 2008
iCalendar Transport-Independent Interoperability Protocol (iTIP) iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-05 draft-ietf-calsify-2446bis-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2008. This Internet-Draft will expire on November 12, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies a protocol using the iCalendar object This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between specification to provide scheduling interoperability between
different calendar systems. This is done without reference to a different calendar systems. This is done without reference to a
skipping to change at page 3, line 10 skipping to change at page 3, line 10
3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 50 3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 53 3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 53
3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 56 3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 56
3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 56 3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 60 3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 60
3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 62 3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 62
3.7. Implementation Considerations . . . . . . . . . . . . . . 64 3.7. Implementation Considerations . . . . . . . . . . . . . . 65
3.7.1. Working With Recurrence Instances . . . . . . . . . . 64 3.7.1. Working With Recurrence Instances . . . . . . . . . . 65
3.7.2. Attendee Property Considerations . . . . . . . . . . 65 3.7.2. Attendee Property Considerations . . . . . . . . . . 66
3.7.3. X-Tokens . . . . . . . . . . . . . . . . . . . . . . 66 3.7.3. X-Tokens . . . . . . . . . . . . . . . . . . . . . . 67
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1. Published Event Examples . . . . . . . . . . . . . . . . 66 4.1. Published Event Examples . . . . . . . . . . . . . . . . 67
4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 67 4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 68
4.1.2. Changing A Published Event . . . . . . . . . . . . . 67 4.1.2. Changing A Published Event . . . . . . . . . . . . . 68
4.1.3. Canceling A Published Event . . . . . . . . . . . . . 68 4.1.3. Canceling A Published Event . . . . . . . . . . . . . 69
4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 69 4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 69
4.1.5. Anniversaries or Events attached to entire days . . . 70 4.1.5. Anniversaries or Events attached to entire days . . . 71
4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 70 4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 71
4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 71 4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 72
4.2.2. Reply To A Group Event Request . . . . . . . . . . . 72 4.2.2. Reply To A Group Event Request . . . . . . . . . . . 73
4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 73 4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 73
4.2.4. Countering an Event Proposal . . . . . . . . . . . . 73 4.2.4. Countering an Event Proposal . . . . . . . . . . . . 74
4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 76 4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 77
4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 78 4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 79
4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 79 4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 80
4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 80 4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 81
4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 80 4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 81
4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 81 4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 82
4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 83 4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 84
4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 84 4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 85
4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 85 4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 86
4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 86 4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 87
4.4. Recurring Event and Time Zone Examples . . . . . . . . . 86 4.4. Recurring Event and Time Zone Examples . . . . . . . . . 87
4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 86 4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 87
4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 88 4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 89
4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 90 4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 91
4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 91 4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 92
4.4.5. Change All Future Instances . . . . . . . . . . . . . 91 4.4.5. Change All Future Instances . . . . . . . . . . . . . 92
4.4.6. Add A New Instance To A Recurring Event . . . . . . . 92 4.4.6. Add A New Instance To A Recurring Event . . . . . . . 93
4.4.7. Add A New Series of Instances To A Recurring Event . 93 4.4.7. Add A New Series of Instances To A Recurring Event . 94
4.4.8. Counter An Instance Of A Recurring Event . . . . . . 98 4.4.8. Counter An Instance Of A Recurring Event . . . . . . 99
4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 99 4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 100
4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 101 4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 102
4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 102 4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 103
4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 102 4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 103
4.5.3. A VTODO Request for Updated Status . . . . . . . . . 103 4.5.3. A VTODO Request for Updated Status . . . . . . . . . 104
4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 103 4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 104
4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 104 4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 105
4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 104 4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 105
4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 105 4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 106
4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 106 4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 107
4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 107 4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 108
4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 107 4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 108
4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 107 4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 108
5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 110 5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 111
5.1. Partial Implementation . . . . . . . . . . . . . . . . . 110 5.1. Partial Implementation . . . . . . . . . . . . . . . . . 111
5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 110 5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 111
5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 112 5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 113
5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 113 5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 114
5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 115 5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 116
5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 116 5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 117
5.2.1. Cancellation of an Unknown Calendar Component. . . . 116 5.2.1. Cancellation of an Unknown Calendar Component. . . . 117
5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 117 5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 118
5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 117 5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 118
6. Security Considerations . . . . . . . . . . . . . . . . . . . 117 6. Security Considerations . . . . . . . . . . . . . . . . . . . 118
6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 117 6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 118
6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 117 6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 118
6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 117 6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 118
6.1.3. Unauthorized Replacement of the Organizer . . . . . . 118 6.1.3. Unauthorized Replacement of the Organizer . . . . . . 119
6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 118 6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 119
6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 118 6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 119
6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 118 6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 119
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 118 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 119
6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 118 6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 119
6.2.2. Implementation Controls . . . . . . . . . . . . . . . 119 6.2.2. Implementation Controls . . . . . . . . . . . . . . . 120
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 119 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 120
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.1. Normative References . . . . . . . . . . . . . . . . . . 120 8.1. Normative References . . . . . . . . . . . . . . . . . . 121
8.2. Informative References . . . . . . . . . . . . . . . . . 120 8.2. Informative References . . . . . . . . . . . . . . . . . 121
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 120 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 121
Appendix B. Change History (to be removed prior to Appendix B. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . 120 publication as an RFC) . . . . . . . . . . . . . . . 121
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 122 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 123
Intellectual Property and Copyright Statements . . . . . . . . . 123 Intellectual Property and Copyright Statements . . . . . . . . . 124
1. Introduction and Overview 1. Introduction and Overview
This document specifies how calendaring systems use iCalendar This document specifies how calendaring systems use iCalendar
[I-D.ietf-calsify-rfc2445bis] objects to interoperate with other [I-D.ietf-calsify-rfc2445bis] objects to interoperate with other
calendar systems. In particular, it specifies how to schedule calendar systems. In particular, it specifies how to schedule
events, to-dos, or daily journal entries. It further specifies how events, to-dos, or daily journal entries. It further specifies how
to search for available busy time information. It does so in a to search for available busy time information. It does so in a
general way without specifying how communication between different general way without specifying how communication between different
systems actually takes place. Subsequent documents specify transport systems actually takes place. Subsequent documents specify transport
skipping to change at page 11, line 16 skipping to change at page 11, line 16
to the final revision sent out. In this situation, the "Organizer" to the final revision sent out. In this situation, the "Organizer"
may wish to send an update "REQUEST", and set "RSVP=TRUE" for all may wish to send an update "REQUEST", and set "RSVP=TRUE" for all
"Attendees", so that current responses can be collected. "Attendees", so that current responses can be collected.
The value of the "SEQUENCE" property contained in a response from an The value of the "SEQUENCE" property contained in a response from an
"Attendee" may not always match the "Organizer's" revision. "Attendee" may not always match the "Organizer's" revision.
Implementations may choose to have the CUA indicate to the CU that Implementations may choose to have the CUA indicate to the CU that
the response is to an entry that has been revised and allow the CU to the response is to an entry that has been revised and allow the CU to
decide whether or not to accept the response. decide whether or not to accept the response.
Whilst a change in SEQUENCE number is indicative of a significant
change to a previously scheduled item, ATTENDEE CUAs SHOULD NOT rely
solely on a change in SEQUENCE as a means of detecting a significant
change. Instead CUAs SHOULD compare the old and new versions of the
calendar components and determine the exact nature of the changes and
make decisions, possibly based on calendar user preferences, as to
whether the user needs to be explicitly informed of the change.
2.1.5. Message Sequencing 2.1.5. Message Sequencing
CUAs that handle the iTIP application protocol must often correlate a CUAs that handle the iTIP application protocol must often correlate a
component in a calendar store with a component received in the iTIP component in a calendar store with a component received in the iTIP
message. For example, an event may be updated with a later revision message. For example, an event may be updated with a later revision
of the same event. To accomplish this, a CUA must correlate the of the same event. To accomplish this, a CUA must correlate the
version of the event already in its calendar store with the version version of the event already in its calendar store with the version
sent in the iTIP message. In addition to this correlation, there are sent in the iTIP message. In addition to this correlation, there are
several factors that can cause iTIP messages to arrive in an several factors that can cause iTIP messages to arrive in an
unexpected order. That is, an "Organizer" could receive a reply to unexpected order. That is, an "Organizer" could receive a reply to
skipping to change at page 26, line 23 skipping to change at page 26, line 23
"RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In
order to cancel an individual instance of the event, the order to cancel an individual instance of the event, the
"RECURRENCE-ID" property value for the event MUST be specified in the "RECURRENCE-ID" property value for the event MUST be specified in the
"CANCEL" method. "CANCEL" method.
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
recurring "VEVENT" calendar component: recurring "VEVENT" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the THISANDFUTURE to indicate cancellation of the specified "VEVENT"
specified "VEVENT" calendar component and all instances before calendar component and all instances after; or
(or 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.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
skipping to change at page 33, line 47 skipping to change at page 33, line 47
+---------+-------------------------------------+ +---------+-------------------------------------+
3.3.1. PUBLISH 3.3.1. PUBLISH
The "PUBLISH" method in a "VFREEBUSY" calendar component is used to The "PUBLISH" method in a "VFREEBUSY" calendar component is used to
publish busy time data. The method may be sent from one CU to any publish busy time data. The method may be sent from one CU to any
other. The purpose of the method is to provide a message for sending other. The purpose of the method is to provide a message for sending
unsolicited busy time data. That is, the busy time data is not being unsolicited busy time data. That is, the busy time data is not being
sent as a "REPLY" to the receipt of a "REQUEST" method. sent as a "REPLY" to the receipt of a "REQUEST" method.
The "ATTENDEE" property must be specified in the busy time The "ORGANIZER" property must be specified in the busy time
information. The value is the CU address of the originator of the information. The value is the CU address of the originator of the
busy time information. busy time information.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "PUBLISH" | | METHOD | 1 | MUST be "PUBLISH" |
skipping to change at page 48, line 7 skipping to change at page 48, line 7
ID" MUST NOT be specified in the "CANCEL" method. In order to cancel ID" MUST NOT be specified in the "CANCEL" method. In order to cancel
an individual instance of a recurring "VTODO" calendar component, the an individual instance of a recurring "VTODO" calendar component, the
"RECURRENCE-ID" property value for the "VTODO" calendar component "RECURRENCE-ID" property value for the "VTODO" calendar component
MUST be specified in the "CANCEL" method. MUST be specified in the "CANCEL" method.
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
recurring "VTODO" calendar component: recurring "VTODO" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the THISANDFUTURE to indicate cancellation of the specified "VTODO"
specified "VTODO" calendar component and all instances before (or calendar component and all instances after
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
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
skipping to change at page 60, line 23 skipping to change at page 60, line 23
entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be
specified in the "CANCEL" method. In order to cancel an individual specified in the "CANCEL" method. In order to cancel an individual
instance of the journal entry, the "RECURRENCE-ID" property value for instance of the journal entry, the "RECURRENCE-ID" property value for
the journal entry MUST be specified in the "CANCEL" method. the journal entry MUST be specified in the "CANCEL" method.
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
recurring "VJOURNAL" calendar component: recurring "VJOURNAL" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the THISANDFUTURE to indicate cancellation of the specified "VTODO"
specified "VTODO" calendar component and all instances before (or calendar component and all instances after
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.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
skipping to change at page 62, line 9 skipping to change at page 62, line 9
| | | | | | | |
| VEVENT | 0 | | | VEVENT | 0 | |
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.6. Status Replies 3.6. Status Replies
The "REQUEST-STATUS" property may include the following values: The "REQUEST-STATUS" property is used to convey status information
about a REPLY, COUNTER or DECLINE-COUNTER iTIP message. The codes
listed in the table below SHOULD be used. Additional codes MAY be
used provided they are defined in a Standards Track or Experimental
RFC.
This specification allows for multiple "REQUEST-STATUS" properties to
be returned in iCalendar components in the appropriate iTIP messages.
When multiple "REQUEST-STATUS" properties are present, the following
restrictions apply:
1. Within any one component, the "top-level" numeric value of the
"short return status code" MUST be the same for all REQUEST-
STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx
and 5.xx codes within a single component.
2. Across all components in the iTIP message, the following applies:
A. If any one component would have a 3.xx code, then all
components MUST have a code in that range or "REQUEST-STATUS"
MUST NOT be present in the other components if a 3.xx code is
not appropriate for those components.
B. If any one component would have a 5.xx code, then all
components MUST have a code in that range or "REQUEST-STATUS"
MUST NOT be present in the other components if a 5.xx code is
not appropriate for those components. This rule overrides
(a) above.
C. 2.xx and 4.xx codes can be used in different components
provided that each component follows the restriction in (1)
above.
The following "REQUEST-STATUS" codes are defined:
+----------+------------------------+-------------------------------+ +----------+------------------------+-------------------------------+
| Short | Longer Return Status | Offending Data | | Short | Longer Return Status | Offending Data |
| Return | Description | | | Return | Description | |
| Status | | | | Status | | |
| Code | | | | Code | | |
+----------+------------------------+-------------------------------+ +----------+------------------------+-------------------------------+
| 2.0 | Success. | None. | | 2.0 | Success. | None. |
| | | | | | | |
| 2.1 | Success but fallback | Property name and value MAY | | 2.1 | Success but fallback | Property name and value MAY |
skipping to change at page 67, line 26 skipping to change at page 68, line 13
+-----------------+-----------------------+-------------------------+ +-----------------+-----------------------+-------------------------+
4.1.1. A Minimal Published Event 4.1.1. A Minimal Published Event
The iCalendar object below describes a single event that begins on The iCalendar object below describes a single event that begins on
July 1, 1997 at 20:00 UTC. This event contains the minimum set of July 1, 1997 at 20:00 UTC. This event contains the minimum set of
properties for a "PUBLISH" for a "VEVENT" calendar component. properties for a "PUBLISH" for a "VEVENT" calendar component.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:PUBLISH METHOD:PUBLISH
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
DTSTART:19970701T200000Z DTSTART:19970701T200000Z
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.1.2. Changing A Published Event 4.1.2. Changing A Published Event
The iCalendar object below describes an update to the event described The iCalendar object below describes an update to the event described
in 4.1.1, the time has been changed, an end time has been added, and in 4.1.1, the time has been changed, an end time has been added, and
the sequence number has been adjusted. the sequence number has been adjusted.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:PUBLISH METHOD:PUBLISH
VERSION:2.0 VERSION:2.0
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
DTSTART:19970701T210000Z DTSTART:19970701T210000Z
DTEND:19970701T230000Z DTEND:19970701T230000Z
SEQUENCE:1 SEQUENCE:1
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
skipping to change at page 68, line 42 skipping to change at page 69, line 22
updated. updated.
4.1.3. Canceling A Published Event 4.1.3. Canceling A Published Event
The iCalendar object below cancels the event described in 4.1.1. The iCalendar object below cancels the event described in 4.1.1.
This cancels the event with "SEQUENCE" property of 0, 1, and 2. This cancels the event with "SEQUENCE" property of 0, 1, and 2.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:CANCEL METHOD:CANCEL
VERSION:2.0 VERSION:2.0
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
COMMENT:DUKES forfeit the game COMMENT:DUKES forfeit the game
SEQUENCE:2 SEQUENCE:2
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.1.4. A Rich Published Event 4.1.4. A Rich Published Event
This example describes the same event as in 4.1.1, but in much This example describes the same event as in 4.1.1, but in much
greater detail. greater detail.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:PUBLISH METHOD:PUBLISH
SCALE:GREGORIAN SCALE:GREGORIAN
VERSION:2.0 VERSION:2.0
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America-Chicago TZID:America-Chicago
TZURL:http://zones.stds_r_us.net/tz/America-Chicago TZURL:http://example.com/tz/America-Chicago
BEGIN:STANDARD BEGIN:STANDARD
DTSTART:19671029T020000 DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0600 TZOFFSETTO:-0600
TZNAME:CST TZNAME:CST
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19870405T020000 DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZOFFSETFROM:-0600 TZOFFSETFROM:-0600
TZOFFSETTO:-0500 TZOFFSETTO:-0500
TZNAME:CDT TZNAME:CDT
END:DAYLIGHT END:DAYLIGHT
END:VTIMEZONE END:VTIMEZONE
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTACH:http://www.dukes.com/ ATTACH:http://www.example.com/
CATEGORIES:SPORTS EVENT,ENTERTAINMENT CATEGORIES:SPORTS EVENT,ENTERTAINMENT
CLASS:PRIVATE CLASS:PRIVATE
DESCRIPTION:MIDWAY STADIUM\n DESCRIPTION:MIDWAY STADIUM\n
Big time game. MUST see.\n Big time game. MUST see.\n
Expected duration:2 hours\n Expected duration:2 hours\n
DTEND;TZID=America-Chicago:19970701T180000 DTEND;TZID=America-Chicago:19970701T180000
DTSTART;TZID=America-Chicago:19970702T160000 DTSTART;TZID=America-Chicago:19970702T160000
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
STATUS:CONFIRMED STATUS:CONFIRMED
LOCATION;VALUE=URI:http://www.midwaystadium.com/ LOCATION;VALUE=URI:http://stadium.example.com/
PRIORITY:2 PRIORITY:2
RESOURCES:SCOREBOARD RESOURCES:SCOREBOARD
SEQUENCE:3 SEQUENCE:3
SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
RELATED-TO:0981234-1234234-14@example.com RELATED-TO:0981234-1234234-14@example.com
BEGIN:VALARM BEGIN:VALARM
TRIGGER:-PT2H TRIGGER:-PT2H
ACTION:DISPLAY ACTION:DISPLAY
DESCRIPTION:You should be leaving for the game now. DESCRIPTION:You should be leaving for the game now.
skipping to change at page 70, line 26 skipping to change at page 71, line 11
The "RELATED-TO" field contains the "UID" property of a related The "RELATED-TO" field contains the "UID" property of a related
calendar event. The "SEQUENCE" property 3 indicates that this event calendar event. The "SEQUENCE" property 3 indicates that this event
supersedes versions 0, 1, and 2. supersedes versions 0, 1, and 2.
4.1.5. Anniversaries or Events attached to entire days 4.1.5. Anniversaries or Events attached to entire days
This example demonstrates the use of the "VALUE" parameter to tie a This example demonstrates the use of the "VALUE" parameter to tie a
"VEVENT" to day rather than a specific time. "VEVENT" to day rather than a specific time.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:PUBLISH METHOD:PUBLISH
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
UID:0981234-1234234-23@example.com UID:0981234-1234234-23@example.com
DTSTART;VALUE=DATE:19970714 DTSTART;VALUE=DATE:19970714
RRULE:FREQ=YEARLY;INTERVAL=1 RRULE:FREQ=YEARLY;INTERVAL=1
SUMMARY: Bastille Day SUMMARY: Bastille Day
END:VEVENT END:VEVENT
skipping to change at page 72, line 6 skipping to change at page 72, line 32
A sample meeting request is sent from "A" to "B", "C", and "D". "E" A sample meeting request is sent from "A" to "B", "C", and "D". "E"
is also sent a copy of the request but is not expected to attend and is also sent a copy of the request but is not expected to attend and
need not reply. "E" illustrates how CUAs might implement an "FYI" need not reply. "E" illustrates how CUAs might implement an "FYI"
type feature. Note the use of the "ROLE" parameter. The default type feature. Note the use of the "ROLE" parameter. The default
value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not
be enumerated. In this case we are using the value "NON-PARTICIPANT" be enumerated. In this case we are using the value "NON-PARTICIPANT"
to indicate "E" is a non-attending CU. The parameter is not needed to indicate "E" is a non-attending CU. The parameter is not needed
on other "Attendees" since "PARTICIPANT" is the default value. on other "Attendees" since "PARTICIPANT" is the default value.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com
ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com
skipping to change at page 72, line 32 skipping to change at page 73, line 11
SEQUENCE:0 SEQUENCE:0
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.2. Reply To A Group Event Request 4.2.2. Reply To A Group Event Request
Attendee "B" accepts the meeting. Attendee "B" accepts the meeting.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
END:VEVENT END:VEVENT
skipping to change at page 73, line 12 skipping to change at page 74, line 6
"TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in "TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in
successful transactions. successful transactions.
4.2.3. Update An Event 4.2.3. Update An Event
The event is moved to a different time. The combination of the "UID" The event is moved to a different time. The combination of the "UID"
property (unchanged) and the "SEQUENCE" (bumped to 1) properties property (unchanged) and the "SEQUENCE" (bumped to 1) properties
indicate the update. indicate the update.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE; ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
CUTYPE=ROOM:mailto:conf@example.com CUTYPE=ROOM:mailto:conf@example.com
skipping to change at page 74, line 6 skipping to change at page 75, line 6
END:VCALENDAR END:VCALENDAR
4.2.4. Countering an Event Proposal 4.2.4. Countering an Event Proposal
"A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal
to "A" to change the time and location. to "A" to change the time and location.
"A" sends the following "REQUEST": "A" sends the following "REQUEST":
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
DTSTART:19970701T190000Z DTSTART:19970701T190000Z
DTEND:19970701T200000Z DTEND:19970701T200000Z
SUMMARY:Discuss the Merits of the election results SUMMARY:Discuss the Merits of the election results
skipping to change at page 74, line 31 skipping to change at page 75, line 31
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"B" sends "COUNTER" to "A", requesting changes to time and place. "B" sends "COUNTER" to "A", requesting changes to time and place.
"B" uses the "COMMENT" property to communicate a rationale for the "B" uses the "COMMENT" property to communicate a rationale for the
change. Note that the "SEQUENCE" property is NOT incremented on a change. Note that the "SEQUENCE" property is NOT incremented on a
"COUNTER". "COUNTER".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:COUNTER METHOD:COUNTER
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
DTSTART:19970701T160000Z DTSTART:19970701T160000Z
DTEND:19970701T190000Z DTEND:19970701T190000Z
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
skipping to change at page 75, line 9 skipping to change at page 76, line 9
UID:calsrv.example.com-873970198738777a@example.com UID:calsrv.example.com-873970198738777a@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"A" accepts the changes from "B". To accept a counter-proposal, the "A" accepts the changes from "B". To accept a counter-proposal, the
"Organizer" sends a new event "REQUEST" with an incremented sequence "Organizer" sends a new event "REQUEST" with an incremented sequence
number. number.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
DTSTART:19970701T160000Z DTSTART:19970701T160000Z
DTEND:19970701T190000Z DTEND:19970701T190000Z
skipping to change at page 75, line 32 skipping to change at page 76, line 32
LOCATION:Green Conference Room LOCATION:Green Conference Room
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1 SEQUENCE:1
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Instead, "A" rejects "B's" counter proposal Instead, "A" rejects "B's" counter proposal
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:DECLINECOUNTER METHOD:DECLINECOUNTER
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
COMMENT:Sorry, I cannot change this meeting time COMMENT:Sorry, I cannot change this meeting time
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
END:VEVENT END:VEVENT
skipping to change at page 77, line 40 skipping to change at page 78, line 40
| Optional: | "A" sends | | | Optional: | "A" sends | |
| Redistribute | REQUEST | | | Redistribute | REQUEST | |
| meeting to | message to | | | meeting to | message to | |
| attendees | "B", "C" and | | | attendees | "B", "C" and | |
| | "E". | | | | "E". | |
+-----------------+----------------+--------------------------------+ +-----------------+----------------+--------------------------------+
"C" responds to the "Organizer". "C" responds to the "Organizer".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
TO="mailto:e@example.com":mailto:c@example.com TO="mailto:e@example.com":mailto:c@example.com
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Attendee "C" delegates presence at the meeting to "E". Attendee "C" delegates presence at the meeting to "E".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
TO="mailto:e@example.com":mailto:c@example.com TO="mailto:e@example.com":mailto:c@example.com
ATTENDEE;RSVP=TRUE; ATTENDEE;RSVP=TRUE;
DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
DTSTART:19970701T180000Z DTSTART:19970701T180000Z
DTEND:19970701T200000Z DTEND:19970701T200000Z
skipping to change at page 78, line 35 skipping to change at page 79, line 35
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.6. Delegate Accepts the Meeting 4.2.6. Delegate Accepts the Meeting
To accept a delegated meeting, the delegate, "E", sends the following To accept a delegated meeting, the delegate, "E", sends the following
message to "A" and "C": message to "A" and "C":
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED- ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
FROM="mailto:c@example.com":mailto:e@example.com FROM="mailto:c@example.com":mailto:e@example.com
ATTENDEE;PARTSTAT=DELEGATED; ATTENDEE;PARTSTAT=DELEGATED;
DELEGATED-TO="mailto:e@example.com":mailto:c@example.com DELEGATED-TO="mailto:e@example.com":mailto:c@example.com
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
skipping to change at page 79, line 21 skipping to change at page 80, line 21
"Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT"
parameter of the "Delegate" set to "DECLINED". This lets the parameter of the "Delegate" set to "DECLINED". This lets the
"Delegator" know that the "Delegate" has declined and provides an "Delegator" know that the "Delegate" has declined and provides an
opportunity to the "Delegator" to either accept the request or opportunity to the "Delegator" to either accept the request or
delegate it to another CU. delegate it to another CU.
Response from "E" to "A" and "C". Note the use of the "COMMENT" Response from "E" to "A" and "C". Note the use of the "COMMENT"
property "E" uses to indicate why the delegation was declined. property "E" uses to indicate why the delegation was declined.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=DELEGATED; ATTENDEE;PARTSTAT=DELEGATED;
DELEGATED-TO="mailto:e@example.com":mailto:c@example.com DELEGATED-TO="mailto:e@example.com":mailto:c@example.com
ATTENDEE;PARTSTAT=DECLINED; ATTENDEE;PARTSTAT=DECLINED;
DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
COMMENT:Sorry, I will be out of town at that time. COMMENT:Sorry, I will be out of town at that time.
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
skipping to change at page 80, line 6 skipping to change at page 81, line 6
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"A" resends the "REQUEST" method to "C". "A" may also wish to "A" resends the "REQUEST" method to "C". "A" may also wish to
express the fact that the item was delegated in the "COMMENT" express the fact that the item was delegated in the "COMMENT"
property. property.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=DECLINED; ATTENDEE;PARTSTAT=DECLINED;
DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0 SEQUENCE:0
SUMMARY:Phone Conference SUMMARY:Phone Conference
skipping to change at page 81, line 24 skipping to change at page 82, line 24
| request | | parameter set to "DECLINED". | | request | | parameter set to "DECLINED". |
| | | | | | | |
| Cancel the | "A" sends a CANCEL | | | Cancel the | "A" sends a CANCEL | |
| meeting | message to "B", | | | meeting | message to "B", | |
| | "C" and "D" | | | | "C" and "D" | |
+-------------+--------------------+--------------------------------+ +-------------+--------------------+--------------------------------+
The example shows how "A" cancels the event. The example shows how "A" cancels the event.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:CANCEL METHOD:CANCEL
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;CUTYPE=INDIVIDUAL;mailto:a@example.com ATTENDEE;CUTYPE=INDIVIDUAL;mailto:a@example.com
ATTENDEE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
COMMENT:Mr. B cannot attend. It's raining. Lets cancel. COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
skipping to change at page 82, line 22 skipping to change at page 83, line 22
| copy of the event | the remaining "Attendees" | | | copy of the event | the remaining "Attendees" | |
+---------------------+--------------------------------+------------+ +---------------------+--------------------------------+------------+
The original meeting includes "A", "B", "C", and "D". The example The original meeting includes "A", "B", "C", and "D". The example
below shows the "CANCEL" that "A" sends to "B". Note that in the below shows the "CANCEL" that "A" sends to "B". Note that in the
example below the "STATUS" property is omitted. This is used when example below the "STATUS" property is omitted. This is used when
the meeting itself is cancelled and not when the intent is to remove the meeting itself is cancelled and not when the intent is to remove
an "Attendee" from the Event. an "Attendee" from the Event.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:CANCEL METHOD:CANCEL
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
COMMENT:You're off the hook for this meeting COMMENT:You're off the hook for this meeting
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
DTSTAMP:19970613T193000Z DTSTAMP:19970613T193000Z
SEQUENCE:1 SEQUENCE:1
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The updated master copy of the event is shown below. The "Organizer" The updated master copy of the event is shown below. The "Organizer"
MAY resend the updated event to the remaining "Attendees". Note that MAY resend the updated event to the remaining "Attendees". Note that
"B" has been removed. "B" has been removed.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
ATTENDEE;CUTYPE=ROOM:mailto:cr_big@example.com ATTENDEE;CUTYPE=ROOM:mailto:cr_big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT; ATTENDEE;ROLE=NON-PARTICIPANT;
RSVP=FALSE:mailto:e@example.com RSVP=FALSE:mailto:e@example.com
skipping to change at page 84, line 5 skipping to change at page 85, line 5
happened and reach an agreement that "B" should become the new happened and reach an agreement that "B" should become the new
"Organizer" for the meeting. To do this, "B" sends out a new version "Organizer" for the meeting. To do this, "B" sends out a new version
of the event and the other "Attendees" agree to accept "B" as the new of the event and the other "Attendees" agree to accept "B" as the new
"Organizer". "B" also removes "A" from the event. "Organizer". "B" also removes "A" from the event.
When the "Organizer" is replaced, the "SEQUENCE" property value MUST When the "Organizer" is replaced, the "SEQUENCE" property value MUST
be incremented. be incremented.
This is the message "B" sends to "C" and "D" This is the message "B" sends to "C" and "D"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:b@example.com ORGANIZER:mailto:b@example.com
ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:mailto:b@example.com ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:mailto:b@example.com
ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T200000Z DTSTART:19970701T200000Z
DTEND:19970701T203000Z DTEND:19970701T203000Z
skipping to change at page 85, line 6 skipping to change at page 86, line 6
Busy time objects can be used in several ways. First, a CU may Busy time objects can be used in several ways. First, a CU may
request busy time from another CU for a specific range of time. That request busy time from another CU for a specific range of time. That
request can be answered with a busy time Reply. Additionally, a CU request can be answered with a busy time Reply. Additionally, a CU
may simply publish their busy time for a given interval and point may simply publish their busy time for a given interval and point
other CUs to the published location. The following examples outline other CUs to the published location. The following examples outline
both scenarios. both scenarios.
Individual "A" publishes busy time for one week. Individual "A" publishes busy time for one week.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
METHOD:PUBLISH METHOD:PUBLISH
BEGIN:VFREEBUSY BEGIN:VFREEBUSY
DTSTAMP:19980101T124100Z DTSTAMP:19980101T124100Z
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
DTSTART:19980101T124200Z DTSTART:19980101T124200Z
DTEND:19980107T124200Z DTEND:19980107T124200Z
FREEBUSY:19980101T180000Z/19980101T190000Z FREEBUSY:19980101T180000Z/19980101T190000Z
FREEBUSY:19980103T020000Z/19980103T050000Z FREEBUSY:19980103T020000Z/19980103T050000Z
FREEBUSY:19980107T020000Z/19980107T050000Z FREEBUSY:19980107T020000Z/19980107T050000Z
skipping to change at page 86, line 5 skipping to change at page 87, line 5
| | | | | | | |
| Reply to the "BUSY" | | "B" sends a "REPLY" | | Reply to the "BUSY" | | "B" sends a "REPLY" |
| request with "BUSY" | | message to "A" with | | request with "BUSY" | | message to "A" with |
| time data | | busy time data | | time data | | busy time data |
+----------------------+--------------------+-----------------------+ +----------------------+--------------------+-----------------------+
4.3.1. Request Busy Time 4.3.1. Request Busy Time
"A" sends a "BUSY-REQUEST" to "B" and "C" for busy time "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VFREEBUSY BEGIN:VFREEBUSY
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
ATTENDEE:mailto:c@example.com ATTENDEE:mailto:c@example.com
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
DTSTART:19970701T080000Z DTSTART:19970701T080000Z
DTEND:19970701T200000 DTEND:19970701T200000
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
END:VFREEBUSY END:VFREEBUSY
END:VCALENDAR END:VCALENDAR
4.3.2. Reply To A Busy Time Request 4.3.2. Reply To A Busy Time Request
"B" sends a "REPLY" method type of a "VFREEBUSY" calendar component "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component
to "A" to "A"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VFREEBUSY BEGIN:VFREEBUSY
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
DTSTART:19970701T080000Z DTSTART:19970701T080000Z
DTEND:19970701T200000Z DTEND:19970701T200000Z
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M
DTSTAMP:19970613T190030Z DTSTAMP:19970613T190030Z
skipping to change at page 87, line 6 skipping to change at page 88, line 6
"B" is busy from 09:00 to 10:00 and from 14:00 to 14:30. "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30.
4.4. Recurring Event and Time Zone Examples 4.4. Recurring Event and Time Zone Examples
4.4.1. A Recurring Event Spanning Time Zones 4.4.1. A Recurring Event Spanning Time Zones
This event describes a weekly phone conference. The "Attendees" are This event describes a weekly phone conference. The "Attendees" are
each in a different time zone. each in a different time zone.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America-SanJose TZID:America-SanJose
TZURL:http://zones.stds_r_us.net/tz/America-SanJose TZURL:http://example.com/tz/America-SanJose
BEGIN:STANDARD BEGIN:STANDARD
DTSTART:19671029T020000 DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0700 TZOFFSETFROM:-0700
TZOFFSETTO:-0800 TZOFFSETTO:-0800
TZNAME:PST TZNAME:PST
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19870405T020000 DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
skipping to change at page 89, line 7 skipping to change at page 90, line 7
In this example the "Organizer" issues a recurring meeting. Later In this example the "Organizer" issues a recurring meeting. Later
the "Organizer" changes an instance of the event by changing the the "Organizer" changes an instance of the event by changing the
"DTSTART" property. Note the use of "RECURRENCE-ID" property and "DTSTART" property. Note the use of "RECURRENCE-ID" property and
"SEQUENCE" property in the second request. "SEQUENCE" property in the second request.
Original Request: Original Request:
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1.com UID:guid-1@example.com
SEQUENCE:0 SEQUENCE:0
RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
ATTENDEE:mailto:c@example.com ATTENDEE:mailto:c@example.com
ATTENDEE:mailto:d@example.com ATTENDEE:mailto:d@example.com
DESCRIPTION:IETF-C&S Conference Call DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
skipping to change at page 90, line 7 skipping to change at page 91, line 7
DTSTAMP:19970526T083000Z DTSTAMP:19970526T083000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The event request below is to change the time of a specific instance. The event request below is to change the time of a specific instance.
This changes the July 1st instance to July 3rd. This changes the July 1st instance to July 3rd.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1com UID:guid-1@example.com
RECURRENCE-ID:19970701T210000Z RECURRENCE-ID:19970701T210000Z
SEQUENCE:1 SEQUENCE:1
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
ATTENDEE:mailto:c@example.com ATTENDEE:mailto:c@example.com
ATTENDEE:mailto:d@example.com ATTENDEE:mailto:d@example.com
DESCRIPTION:IETF-C&S Conference Call DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
skipping to change at page 90, line 36 skipping to change at page 91, line 36
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.3. Cancel an Instance 4.4.3. Cancel an Instance
In this example the "Organizer" of a recurring event deletes the In this example the "Organizer" of a recurring event deletes the
August 1st instance. August 1st instance.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:CANCEL METHOD:CANCEL
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1.com UID:guid-1@example.com
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
ATTENDEE:mailto:c@example.com ATTENDEE:mailto:c@example.com
ATTENDEE:mailto:d@example.com ATTENDEE:mailto:d@example.com
RECURRENCE-ID:19970801T210000Z RECURRENCE-ID:19970801T210000Z
SEQUENCE:2 SEQUENCE:2
STATUS:CANCELLED STATUS:CANCELLED
DTSTAMP:19970721T093000Z DTSTAMP:19970721T093000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.4. Cancel Recurring Event 4.4.4. Cancel Recurring Event
In this example the "Organizer" wishes to cancel the entire recurring In this example the "Organizer" wishes to cancel the entire recurring
event and any exceptions. event and any exceptions.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:CANCEL METHOD:CANCEL
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1.com UID:guid-1@example.com
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
ATTENDEE:mailto:c@example.com ATTENDEE:mailto:c@example.com
ATTENDEE:mailto:d@example.com ATTENDEE:mailto:d@example.com
DTSTAMP:19970721T103000Z DTSTAMP:19970721T103000Z
STATUS:CANCELLED STATUS:CANCELLED
SEQUENCE:3 SEQUENCE:3
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.5. Change All Future Instances 4.4.5. Change All Future Instances
This example changes the meeting location from a conference call to This example changes the meeting location from a conference call to
Seattle starting September 1 and extends to all future instances. Seattle starting September 1 and extends to all future instances.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1.com UID:guid-1@example.com
RECURRENCE-ID;THISANDFUTURE:19970901T210000Z RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
SEQUENCE:3 SEQUENCE:3
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com
ATTENDEE;RSVP=TRUE:mailto:d@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com
DESCRIPTION:IETF-C&S Discussion DESCRIPTION:IETF-C&S Discussion
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
skipping to change at page 93, line 7 skipping to change at page 94, line 7
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.6. Add A New Instance To A Recurring Event 4.4.6. Add A New Instance To A Recurring Event
This example adds a one-time additional instance to the recurring This example adds a one-time additional instance to the recurring
event. "Organizer" adds a second July meeting on the 15th. event. "Organizer" adds a second July meeting on the 15th.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:ADD METHOD:ADD
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@host1.com UID:123456789@example.com
SEQUENCE:4 SEQUENCE:4
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com
ATTENDEE;RSVP=TRUE:mailto:d@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com
DESCRIPTION:IETF-C&S Conference Call DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970715T210000Z DTSTART:19970715T210000Z
skipping to change at page 94, line 7 skipping to change at page 95, line 7
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, but does not want
to reschedule the entire meeting or lose any of the per-instance to reschedule the entire meeting or lose any of the per-instance
information already collected. information already collected.
The original event: The original event:
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@host1.com UID:123456789@example.com
SEQUENCE:0 SEQUENCE:0
RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE: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
skipping to change at page 94, line 32 skipping to change at page 95, line 32
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Assume that many other updates happen to this event and that a lot of Assume that many other updates happen to this event and that a lot of
instance-specific information exists in the recurring series. The instance-specific information exists in the recurring series. The
"SEQUENCE" property value is 7 for the next update. Now the "SEQUENCE" property value is 7 for the next update. Now the
"Organizer" wants to add Thursdays to the event: "Organizer" wants to add Thursdays to the event:
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:ADD METHOD:ADD
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@host1.com UID:123456789@example.com
SEQUENCE:7 SEQUENCE:7
RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE: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 Usual conference room LOCATION:The Usual conference room
skipping to change at page 95, line 13 skipping to change at page 96, line 13
END:VCALENDAR END:VCALENDAR
Alternatively, if the "Organizer" is not concerned with per-instance Alternatively, if the "Organizer" is not concerned with per-instance
updates, the entire event can be rescheduled using a "REQUEST". This updates, the entire event can be rescheduled using a "REQUEST". This
is done by using the "UID" of the event to reschedule and including is done by using the "UID" of the event to reschedule and including
the modified "RRULE". Note, that since this is an entire the modified "RRULE". Note, that since this is an entire
rescheduling of the event, any instance-specific information will be rescheduling of the event, any instance-specific information will be
lost. lost.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@host1.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
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
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
skipping to change at page 96, line 7 skipping to change at page 97, line 7
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:
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@host1.com UID:123456789@example.com
SEQUENCE:0 SEQUENCE:0
RDATE:19980304T180000Z RDATE:19980304T180000Z
RDATE:19980311T180000Z RDATE:19980311T180000Z
RDATE:19980318T180000Z RDATE:19980318T180000Z
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
SUMMARY:Review Accounts SUMMARY:Review Accounts
DTSTART:19980304T180000Z DTSTART:19980304T180000Z
DTEND:19980304T200000Z DTEND:19980304T200000Z
DTSTAMP:19980303T193000Z DTSTAMP:19980303T193000Z
LOCATION:Conference Room A LOCATION:Conference Room A
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Organizer changes 2nd instance Location and Time: Organizer changes 2nd instance Location and Time:
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@host1.com UID:123456789@example.com
SEQUENCE:1 SEQUENCE:1
RECURRENCE-ID:19980311T180000Z RECURRENCE-ID:19980311T180000Z
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
SUMMARY:Review Accounts SUMMARY:Review Accounts
DTSTART:19980311T160000Z DTSTART:19980311T160000Z
DTEND:19980311T180000Z DTEND:19980311T180000Z
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
Organizer adds a 4th instance of the meeting using the "ADD" method Organizer adds a 4th instance of the meeting using the "ADD" method
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:ADD METHOD:ADD
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@host1.com UID:123456789@example.com
SEQUENCE:2 SEQUENCE:2
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
SUMMARY:Review Accounts SUMMARY:Review Accounts
DTSTART:19980315T180000Z DTSTART:19980315T180000Z
DTEND:19980315T200000Z DTEND:19980315T200000Z
DTSTAMP:19980307T193000Z DTSTAMP:19980307T193000Z
LOCATION:Conference Room A LOCATION:Conference Room A
STATUS:CONFIRMED STATUS:CONFIRMED
skipping to change at page 98, line 7 skipping to change at page 99, line 7
If "B" requests a "REFRESH", "A" responds with the following to If "B" requests a "REFRESH", "A" responds with the following to
capture all instance-specific data. In this case both the initial capture all instance-specific data. In this case both the initial
request and an additional "VEVENT" that specifies the instance- request and an additional "VEVENT" that specifies the instance-
specific data are included. Because these are both of the same type specific data are included. Because these are both of the same type
(they are both "VEVENTS"), they can be conveyed in the same iCalendar (they are both "VEVENTS"), they can be conveyed in the same iCalendar
object. object.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:123456789@host1.com UID:123456789@example.com
SEQUENCE:2 SEQUENCE:2
RDATE:19980304T180000Z RDATE:19980304T180000Z
RDATE:19980311T160000Z RDATE:19980311T160000Z
RDATE:19980315T180000Z RDATE:19980315T180000Z
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
SUMMARY:Review Accounts SUMMARY:Review Accounts
DTSTART:19980304T180000Z DTSTART:19980304T180000Z
DTEND:19980304T200000Z DTEND:19980304T200000Z
skipping to change at page 99, line 7 skipping to change at page 100, line 7
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.4.8. Counter An Instance Of A Recurring Event 4.4.8. 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:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1.com UID:guid-1@example.com
RECURRENCE-ID:19970715T210000Z RECURRENCE-ID:19970715T210000Z
SEQUENCE:4 SEQUENCE:4
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;RSVP=TRUE:mailto:a@example.com ATTENDEE;ROLE=CHAIR;RSVP=TRUE:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com
ATTENDEE;RSVP=TRUE:mailto:d@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com
DESCRIPTION:IETF-C&S Conference Call DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
skipping to change at page 100, line 6 skipping to change at page 101, line 6
END:VCALENDAR END:VCALENDAR
4.4.9. Error Reply To A Request 4.4.9. 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:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1.com UID:guid-1@example.com
SEQUENCE:0 SEQUENCE:0
RRULE:FREQ=MONTHLY;BYMONTHDAY=1 RRULE:FREQ=MONTHLY;BYMONTHDAY=1
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com
ATTENDEE;RSVP=TRUE:mailto:d@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com
DESCRIPTION:IETF-C&S Conference Call DESCRIPTION:IETF-C&S Conference Call
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
skipping to change at page 100, line 33 skipping to change at page 101, line 33
LOCATION:Conference Call LOCATION:Conference Call
STATUS:CONFIRMED STATUS:CONFIRMED
FOO:BAR FOO:BAR
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Response from "B" to indicate that RRULE is not supported and an Response from "B" to indicate that RRULE is not supported and an
unrecognized property was encountered unrecognized property was encountered
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single
event;RRULE event;RRULE
REQUEST-STATUS:3.0;Invalid Property Name;FOO REQUEST-STATUS:3.0;Invalid Property Name;FOO
UID:guid-1@host1.com UID:guid-1@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970603T094000Z DTSTAMP:19970603T094000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.5. Group To-do Examples 4.5. Group To-do Examples
Individual "A" creates a group task in which individuals "A", "B", Individual "A" creates a group task in which individuals "A", "B",
"C" and "D" will participate. Individual "B" confirms acceptance of "C" and "D" will participate. Individual "B" confirms acceptance of
the task. Individual "C" declines the task. Individual "D" the task. Individual "C" declines the task. Individual "D"
skipping to change at page 102, line 11 skipping to change at page 103, line 11
| indicates | | message indicating | | indicates | | message indicating |
| completion | | completion | | completion | | completion |
+--------------+------------------------+---------------------------+ +--------------+------------------------+---------------------------+
4.5.1. A VTODO Request 4.5.1. A VTODO Request
A sample "REQUEST" for a "VTODO" calendar component that "A" sends to A sample "REQUEST" for a "VTODO" calendar component that "A" sends to
"B", "C", and "D". "B", "C", and "D".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com
ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com
ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com
ATTENDEE;RSVP=TRUE:mailto:d@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com
DTSTART:19970701T170000Z DTSTART:19970701T170000Z
DUE:19970722T170000Z DUE:19970722T170000Z
skipping to change at page 102, line 36 skipping to change at page 103, line 36
DTSTAMP:19970717T200000Z DTSTAMP:19970717T200000Z
STATUS:Needs Action STATUS:Needs Action
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
4.5.2. A VTODO Reply 4.5.2. A VTODO Reply
"B" accepts the to-do. "B" accepts the to-do.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
COMMENT:I'll send you my input by e-mail COMMENT:I'll send you my input by e-mail
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970717T203000Z DTSTAMP:19970717T203000Z
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
skipping to change at page 103, line 13 skipping to change at page 104, line 13
END:VCALENDAR END:VCALENDAR
"B" could have declined the TODO or indicated tentative acceptance by "B" could have declined the TODO or indicated tentative acceptance by
setting the "PARTSTAT" property parameter sequence to "DECLINED" or setting the "PARTSTAT" property parameter sequence to "DECLINED" or
"TENTATIVE", respectively. "TENTATIVE", respectively.
4.5.3. A VTODO Request for Updated Status 4.5.3. A VTODO Request for Updated Status
"A" requests status from all "Attendees". "A" requests status from all "Attendees".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
SUMMARY:Create the requirements document SUMMARY:Create the requirements document
PRIORITY:1 PRIORITY:1
skipping to change at page 103, line 37 skipping to change at page 104, line 37
DTSTAMP:19970717T230000Z DTSTAMP:19970717T230000Z
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
4.5.4. A Reply: Percent-Complete 4.5.4. A Reply: Percent-Complete
A reply indicating the task being worked on and that "B" is 75% A reply indicating the task being worked on and that "B" is 75%
complete with "B's" part of the assignment. complete with "B's" part of the assignment.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com
PERCENT-COMPLETE:75 PERCENT-COMPLETE:75
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
DTSTAMP:19970717T233000Z DTSTAMP:19970717T233000Z
SEQUENCE:0 SEQUENCE:0
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
4.5.5. A Reply: Completed 4.5.5. A Reply: Completed
A reply indicating that "D" completed "D's" part of the assignment. A reply indicating that "D" completed "D's" part of the assignment.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;PARTSTAT=COMPLETED:mailto:d@example.com ATTENDEE;PARTSTAT=COMPLETED:mailto:d@example.com
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
DTSTAMP:19970717T233000Z DTSTAMP:19970717T233000Z
SEQUENCE:0 SEQUENCE:0
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
4.5.6. An Updated VTODO Request 4.5.6. An Updated VTODO Request
Organizer "A" resends the "VTODO" calendar component. "A" sets the Organizer "A" resends the "VTODO" calendar component. "A" sets the
overall completion for the to-do at 40%. overall completion for the to-do at 40%.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;PARTSTAT=IN-PROCESS;CUTYPE=INDIVIDUAL:mailto:d@example.com ATTENDEE;PARTSTAT=IN-PROCESS;CUTYPE=INDIVIDUAL:mailto:d@example.com
DTSTART:19970701T170000Z DTSTART:19970701T170000Z
DUE:19970722T170000Z DUE:19970722T170000Z
PRIORITY:1 PRIORITY:1
skipping to change at page 105, line 16 skipping to change at page 106, line 16
The following examples relate to recurring "VTODO" calendar The following examples relate to recurring "VTODO" calendar
components. components.
4.5.7.1. Request for a Recurring VTODO 4.5.7.1. Request for a Recurring VTODO
In this example "A" sends a recurring "VTODO" calendar component to In this example "A" sends a recurring "VTODO" calendar component to
"B" and "D". "B" and "D".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com
RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
DTSTART:19980101T100000-0700 DTSTART:19980101T100000-0700
DUE:19980103T100000-0700 DUE:19980103T100000-0700
skipping to change at page 106, line 11 skipping to change at page 107, line 11
"19970801T190000Z" the interval of one day which is applied to each "19970801T190000Z" the interval of one day which is applied to each
recurring instance of the "VTODO" calendar component to determine the recurring instance of the "VTODO" calendar component to determine the
"DUE" date of the instance. "DUE" date of the instance.
4.5.7.3. Replying to an instance of a recurring VTODO 4.5.7.3. Replying to an instance of a recurring VTODO
In this example "B" updates "A" on a single instance of the "VTODO" In this example "B" updates "A" on a single instance of the "VTODO"
calendar component. calendar component.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REPLY METHOD:REPLY
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com
PERCENT-COMPLETE:75 PERCENT-COMPLETE:75
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
DTSTAMP:19970717T233000Z DTSTAMP:19970717T233000Z
RECURRENCE-ID:19980101T170000Z RECURRENCE-ID:19980101T170000Z
SEQUENCE:1 SEQUENCE:1
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
4.6. Journal Examples 4.6. Journal Examples
The iCalendar object below describes a single journal entry for The iCalendar object below describes a single journal entry for
October 2, 1997. The "RELATED-TO" property references the phone October 2, 1997. The "RELATED-TO" property references the phone
conference event for which minutes were taken. conference event for which minutes were taken.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:PUBLISH METHOD:PUBLISH
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VJOURNAL BEGIN:VJOURNAL
DTSTART:19971002T200000Z DTSTART:19971002T200000Z
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
SUMMARY:Phone conference minutes SUMMARY:Phone conference minutes
DESCRIPTION:The editors meeting was held on October 1, 1997. DESCRIPTION:The editors meeting was held on October 1, 1997.
Details are in the attached document. Details are in the attached document.
UID:0981234-1234234-2410@example.com UID:0981234-1234234-2410@example.com
RELATED-TO:0981234-1234234-2402-35@example.com RELATED-TO:0981234-1234234-2402-35@example.com
ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt
END:VJOURNAL END:VJOURNAL
END:VCALENDAR END:VCALENDAR
4.7. Other Examples 4.7. Other Examples
4.7.1. Event Refresh 4.7.1. Event Refresh
Refresh the event with "UID" property value of "guid-1- Refresh the event with "UID" property value of "guid-1-
12345@host1.com": 12345@example.com":
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REFRESH METHOD:REFRESH
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
ATTENDEE:mailto:c@example.com ATTENDEE:mailto:c@example.com
ATTENDEE:mailto:d@example.com ATTENDEE:mailto:d@example.com
UID: guid-1-12345@host1.com UID: guid-1-12345@example.com
DTSTAMP:19970603T094000 DTSTAMP:19970603T094000
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.7.2. Bad RECURRENCE-ID 4.7.2. Bad RECURRENCE-ID
Component instances are identified by the combination of "UID", Component instances are identified by the combination of "UID",
"RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request
to an "Attendee", there are three cases in which an instance cannot to an "Attendee", there are three cases in which an instance cannot
be found. They are: be found. They are:
skipping to change at page 109, line 7 skipping to change at page 110, line 7
| | | | | | | |
| Attendee handles the | | "B" updates to the | | Attendee handles the | | "B" updates to the |
| request and updates the | | latest copy of the | | request and updates the | | latest copy of the |
| instance | | meeting. | | instance | | meeting. |
+-------------------------+--------------------+--------------------+ +-------------------------+--------------------+--------------------+
Request from "A": Request from "A":
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:acme-12345@host1.com UID:example-12345@example.com
SEQUENCE:3 SEQUENCE:3
RRULE:FREQ=WEEKLY RRULE:FREQ=WEEKLY
RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
DESCRIPTION:IETF-C&S Conference Call DESCRIPTION:IETF-C&S Conference Call
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970801T210000Z DTSTART:19970801T210000Z
DTEND:19970801T220000Z DTEND:19970801T220000Z
RECURRENCE-ID:19970809T210000Z RECURRENCE-ID:19970809T210000Z
DTSTAMP:19970726T083000 DTSTAMP:19970726T083000
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"B" has the event with "UID" property "acme-12345@host1.com" but "B" has the event with "UID" property "example-12345@example.com" but
"B's" "SEQUENCE" property value is "1" and the event does not have an "B's" "SEQUENCE" property value is "1" and the event does not have an
instance at the specified recurrence time. This means that "B" has instance at the specified recurrence time. This means that "B" has
missed at least one update and needs a new copy of the event. "B" missed at least one update and needs a new copy of the event. "B"
requests the latest copy of the event with the following refresh requests the latest copy of the event with the following refresh
message: message:
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REFRESH METHOD:REFRESH
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
ATTENDEE:mailto:b@example.com ATTENDEE:mailto:b@example.com
UID:acme-12345@host1.com UID:example-12345@example.com
DTSTAMP:19970603T094000 DTSTAMP:19970603T094000
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
5. Application Protocol Fallbacks 5. Application Protocol Fallbacks
5.1. Partial Implementation 5.1. Partial Implementation
Applications that support this specification are not required to Applications that support this specification are not required to
support the entire protocol. The following describes how methods and support the entire protocol. The following describes how methods and
skipping to change at page 120, line 10 skipping to change at page 121, line 10
TBD. Will be based on 2445bis changes. TBD. Will be based on 2445bis changes.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-calsify-rfc2445bis] [I-D.ietf-calsify-rfc2445bis]
Desruisseaux, B., "Internet Calendaring and Scheduling Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", Core Object Specification (iCalendar)",
draft-ietf-calsify-rfc2445bis-08 (work in progress), draft-ietf-calsify-rfc2445bis-07 (work in progress),
February 2008. July 2007.
[I-D.ietf-calsify-rfc2447bis] [I-D.ietf-calsify-rfc2447bis]
Melnikov, A., "iCalendar Message-Based Interoperability Melnikov, A., "iCalendar Message-Based Interoperability
Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-03 (work Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-03 (work
in progress), February 2007. in progress), February 2007.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995. Multipart/Encrypted", RFC 1847, October 1995.
skipping to change at page 120, line 35 skipping to change at page 121, line 35
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
8.2. Informative References 8.2. Informative References
Appendix A. Acknowledgments Appendix A. Acknowledgments
This is an update to the original iTIP document authored by This is an update to the original iTIP document authored by
S.Silverberg, S. Mansour, F. Dawson and R. Hopson. S.Silverberg, S. Mansour, F. Dawson and R. Hopson.
This revision is the product of the Calsify IETF Working Group, and
several participants have made important contributions to this
specification, including: Oliver Block, Bernard Desruisseaux, Mike
Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot
Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg
II, Robert Ransdell, Caleb Richardson.
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 -06:
a. Added text to SEQUENCE number description about detecting a
significant change.
b. Added text to REQUEST-STATUS section describing the allowed
combinations of codes.
c. Added text to REQUEST-STATUS section to require new codes to be
defined in a standard or experimental RFC.
d. Removed THISANDFUTURE.
e. Cleaned up some examples.
Changes in -05: Changes in -05:
a. Changed "memo" to "specification". a. Changed "memo" to "specification".
b. Removed EXRULE as it is no longer in 2445bis. b. Removed EXRULE as it is no longer in 2445bis.
c. Removed section on PROCEDURE alarms since those are no longer in c. Removed section on PROCEDURE alarms since those are no longer in
2445bis. 2445bis.
d. Changed TYPE= to CUTYPE=. d. Changed TYPE= to CUTYPE=.
e. Fixed formatting of examples. e. Fixed formatting of examples.
f. Use lowercase mailto everywhere. f. Use lowercase mailto everywhere.
Changes in -04: Changes in -04:
 End of changes. 95 change blocks. 
170 lines changed or deleted 226 lines changed or added

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