draft-ietf-calsify-2446bis-02.txt   draft-ietf-calsify-2446bis-03.txt 
Network Working Group C. Daboo Network Working Group C. Daboo, Ed.
Internet-Draft Editor Internet-Draft Apple
Expires: December 27, 2006 June 25, 2006 Obsoletes: 2446 (if approved) March 5, 2007
Intended status: Standards Track
Expires: September 6, 2007
iCalendar Transport-Independent Interoperability Protocol (iTIP) iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-02 draft-ietf-calsify-2446bis-03
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 33 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 December 27, 2006. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies a protocol using the iCalendar object This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between specification to provide scheduling interoperability between
different calendar systems. This is done without reference to a different calendar systems. This is done without reference to a
specific transport protocol so as to allow multiple methods of specific transport protocol so as to allow multiple methods of
communication between systems. Subsequent documents will define communication between systems. Subsequent documents will define
profiles of this protocol using specific interoperable methods of profiles of this protocol using specific interoperable methods of
communications between systems. communications between systems.
iTIP complements the iCalendar object specification by adding iTIP complements the iCalendar object specification by adding
semantics for group scheduling methods commonly available in current semantics for group scheduling methods commonly available in current
calendar systems. These scheduling methods permit two or more calendar systems. These scheduling methods permit two or more
calendar systems to perform transactions such as publish, schedule, calendar systems to perform transactions such as publish, schedule,
reschedule, respond to scheduling requests, negotiation of changes or reschedule, respond to scheduling requests, negotiation of changes or
cancel. cancel.
Change History (to be removed prior to publication as an RFC) Change History (to be removed prior to publication as an RFC)
Changes in -03:
a. Added empty IANA Considerations section - to be done.
Changes in -02: Changes in -02:
a. Tweaked abstract wording. a. Tweaked abstract wording.
b. Fixed some improper references. b. Fixed some improper references.
c. Removed bogus TZOFFSET entry from VTIMEZONE restriction table. c. Removed bogus TZOFFSET entry from VTIMEZONE restriction table.
d. Changed TZNAME entry in VTIMEZONE restriction table to "0+" from d. Changed TZNAME entry in VTIMEZONE restriction table to "0+" from
"0 or 1" to fall in line with 2445. "0 or 1" to fall in line with 2445.
e. Changed COMMENT entry in component restriction tables to "0+" e. Changed COMMENT entry in component restriction tables to "0+"
from "0 or 1" to fall in line with 2445. from "0 or 1" to fall in line with 2445.
f. Added ATTENDEE entry in VALARM restriction table to match email f. Added ATTENDEE entry in VALARM restriction table to match email
alarm type in 2445. alarm type in 2445.
skipping to change at page 4, line 13 skipping to change at page 4, line 13
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.1. Published Event Examples . . . . . . . . . . . . . . . . 66 4.1. Published Event Examples . . . . . . . . . . . . . . . . 66
4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 67 4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 67
4.1.2. Changing A Published Event . . . . . . . . . . . . . 67 4.1.2. Changing A Published Event . . . . . . . . . . . . . 67
4.1.3. Canceling A Published Event . . . . . . . . . . . . . 68 4.1.3. Canceling A Published Event . . . . . . . . . . . . . 68
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 . . . 70
4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 70 4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 70
4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 71 4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 71
4.2.2. Reply To A Group Event Request . . . . . . . . . . . 72 4.2.2. Reply To A Group Event Request . . . . . . . . . . . 72
4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 72 4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 73
4.2.4. Countering an Event Proposal . . . . . . . . . . . . 73 4.2.4. Countering an Event Proposal . . . . . . . . . . . . 73
4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 75 4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 75
4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 78 4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 78
4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 78 4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 79
4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 80 4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 80
4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 80 4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 80
4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 81 4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 81
4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 83 4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 83
4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 84 4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 83
4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 85 4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 84
4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 85 4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 85
4.4. Recurring Event and Time Zone Examples . . . . . . . . . 86 4.4. Recurring Event and Time Zone Examples . . . . . . . . . 85
4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 86 4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 85
4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 88 4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 87
4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 90 4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 89
4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 91 4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 90
4.4.5. Change All Future Instances . . . . . . . . . . . . . 91 4.4.5. Change All Future Instances . . . . . . . . . . . . . 90
4.4.6. Add A New Instance To A Recurring Event . . . . . . . 92 4.4.6. Add A New Instance To A Recurring Event . . . . . . . 91
4.4.7. Add A New Series of Instances To A Recurring Event . 93 4.4.7. Add A New Series of Instances To A Recurring Event . 92
4.4.8. Counter An Instance Of A Recurring Event . . . . . . 98 4.4.8. Counter An Instance Of A Recurring Event . . . . . . 97
4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 99 4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 98
4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 100 4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 100
4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 102 4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 101
4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 102 4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 101
4.5.3. A VTODO Request for Updated Status . . . . . . . . . 103 4.5.3. A VTODO Request for Updated Status . . . . . . . . . 102
4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 103 4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 102
4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 103 4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 102
4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 104 4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 103
4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 104 4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 103
4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 106 4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 105
4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 106 4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 105
4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 106 4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 105
4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 107 4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 106
5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 109 5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 108
5.1. Partial Implementation . . . . . . . . . . . . . . . . . 109 5.1. Partial Implementation . . . . . . . . . . . . . . . . . 108
5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 110 5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 109
5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 112 5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 111
5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 113 5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 112
5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 115 5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 114
5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 116 5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 115
5.2.1. Cancellation of an Unknown Calendar Component. . . . 116 5.2.1. Cancellation of an Unknown Calendar Component. . . . 115
5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 117 5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 116
5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 117 5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 116
6. Security Considerations . . . . . . . . . . . . . . . . . . . 117 6. Security Considerations . . . . . . . . . . . . . . . . . . . 116
6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 117 6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 116
6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 117 6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 116
6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 118 6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 117
6.1.3. Unauthorized Replacement of the Organizer . . . . . . 118 6.1.3. Unauthorized Replacement of the Organizer . . . . . . 117
6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 118 6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 117
6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 118 6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 117
6.1.6. Procedural Alarms . . . . . . . . . . . . . . . . . . 118 6.1.6. Procedural Alarms . . . . . . . . . . . . . . . . . . 117
6.1.7. Unauthorized REFRESH Requests . . . . . . . . . . . . 118 6.1.7. Unauthorized REFRESH Requests . . . . . . . . . . . . 117
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 119 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 118
6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 119 6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 118
6.2.2. Implementation Controls . . . . . . . . . . . . . . . 119 6.2.2. Implementation Controls . . . . . . . . . . . . . . . 118
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 119
7.1. Normative References . . . . . . . . . . . . . . . . . . 120 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.2. Informative References . . . . . . . . . . . . . . . . . 120 8.1. Normative References . . . . . . . . . . . . . . . . . . 119
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 120 8.2. Informative References . . . . . . . . . . . . . . . . . 119
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 121 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 119
Intellectual Property and Copyright Statements . . . . . . . . . 122 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 119
Intellectual Property and Copyright Statements . . . . . . . . . 121
1. Introduction and Overview 1. Introduction and Overview
This document specifies how calendaring systems use iCalendar This document specifies how calendaring systems use iCalendar
[I-D.ietf-calsify-rfc2445bis] objects to interoperate with other [I-D.ietf-calsify-rfc2445bis] objects to interoperate with other
calendar systems. In particular, it specifies how to schedule calendar systems. In particular, it specifies how to schedule
events, to-dos, or daily journal entries. It further specifies how events, to-dos, or daily journal entries. It further specifies how
to search for available busy time information. It does so in a to search for available busy time information. It does so in a
general way without specifying how communication between different general way without specifying how communication between different
systems actually takes place. Subsequent documents specify transport systems actually takes place. Subsequent documents specify transport
skipping to change at page 6, line 28 skipping to change at page 6, line 28
reply, in order to update their status and may also return reply, in order to update their status and may also return
transaction/request status information. The protocol supports the transaction/request status information. The protocol supports the
ability for the message originator to modify or cancel the original ability for the message originator to modify or cancel the original
message. The protocol also supports the ability for recipients to message. The protocol also supports the ability for recipients to
suggest changes to the originator of a message. The elements of the suggest changes to the originator of a message. The elements of the
protocol also define the user roles for its transactions. protocol also define the user roles for its transactions.
1.1. Formatting Conventions 1.1. Formatting Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
Calendaring and scheduling roles are referred to in quoted-strings of Calendaring and scheduling roles are referred to in quoted-strings of
text with the first character of each word in upper case. For text with the first character of each word in upper case. For
example, "Organizer" refers to a role of a "Calendar User" (CU) example, "Organizer" refers to a role of a "Calendar User" (CU)
within the scheduling protocol. within the scheduling protocol.
Calendar components defined by [I-D.ietf-calsify-rfc2445bis] are Calendar components defined by [I-D.ietf-calsify-rfc2445bis] are
referred to with capitalized, quoted-strings of text. All calendar referred to with capitalized, quoted-strings of text. All calendar
components start with the letter "V". For example, "VEVENT" refers components start with the letter "V". For example, "VEVENT" refers
skipping to change at page 9, line 32 skipping to change at page 9, line 32
are a subset of the above set. are a subset of the above set.
2. Interoperability Models 2. Interoperability Models
There are two distinct protocols relevant to interoperability: an There are two distinct protocols relevant to interoperability: an
"Application Protocol" and a "Transport Protocol". The Application "Application Protocol" and a "Transport Protocol". The Application
Protocol defines the content of the iCalendar objects sent between Protocol defines the content of the iCalendar objects sent between
sender and receiver to accomplish the scheduling transactions listed sender and receiver to accomplish the scheduling transactions listed
above. The Transport Protocol defines how the iCalendar objects are above. The Transport Protocol defines how the iCalendar objects are
sent between the sender and receiver. This document focuses on the sent between the sender and receiver. This document focuses on the
Application Protocol. Binding documents such as [I-D.ietf-calsify- Application Protocol. Binding documents such as
rfc2447bis] focus on the Transport Protocol. [I-D.ietf-calsify-rfc2447bis] focus on the Transport Protocol.
The connection between Sender and Receiver in the diagram below The connection between Sender and Receiver in the diagram below
refers to the Application Protocol. The iCalendar objects passed refers to the Application Protocol. The iCalendar objects passed
from the Sender to the Receiver are presented in Section 3, from the Sender to the Receiver are presented in Section 3,
Application Protocol Elements. Application Protocol Elements.
+----------+ +----------+ +----------+ +----------+
| | iTIP | | | | iTIP | |
| Sender |<-------------------->| Receiver | | Sender |<-------------------->| Receiver |
| | | | | | | |
skipping to change at page 10, line 8 skipping to change at page 10, line 8
There are several variations of this diagram in which the Sender and There are several variations of this diagram in which the Sender and
Receiver take on various roles of a "Calendar User Agent" (CUA) or a Receiver take on various roles of a "Calendar User Agent" (CUA) or a
"Calendar Service" (CS). "Calendar Service" (CS).
The architecture of iTIP is depicted in the diagram below. An The architecture of iTIP is depicted in the diagram below. An
application written to this specification may work with bindings for application written to this specification may work with bindings for
the store-and-forward transport, the real time transport, or both. the store-and-forward transport, the real time transport, or both.
Also note that iTIP could be bound to other transports. Also note that iTIP could be bound to other transports.
+-------------------+--------------------------+--------------------+ +------------------+---------------------------+--------------------+
| | iTIP | | | | iTIP | |
+-------------------+--------------------------+--------------------+ +------------------+---------------------------+--------------------+
| Real-time | Store-and-Forward | Other | | Real-time | Store-and-Forward | Other |
| Transport | Transport | Transports... | | Transport | Transport | Transports... |
+-------------------+--------------------------+--------------------+ +------------------+---------------------------+--------------------+
iTIP
2.1. Application Protocol 2.1. Application Protocol
In the iTIP model, a calendar entry is created and managed by an In the iTIP model, a calendar entry is created and managed by an
"Organizer". The "Organizer" interacts with other CUs by sending one "Organizer". The "Organizer" interacts with other CUs by sending one
or more of the iTIP messages listed above. "Attendees" use the or more of the iTIP messages listed above. "Attendees" use the
"REPLY" method to communicate their status. "Attendees" do not make "REPLY" method to communicate their status. "Attendees" do not make
direct changes to the master calendar entry. They can, however, use direct changes to the master calendar entry. They can, however, use
the "COUNTER" method to suggest changes to the "Organizer". In any the "COUNTER" method to suggest changes to the "Organizer". In any
case, the "Organizer" has complete control over the master calendar case, the "Organizer" has complete control over the master calendar
skipping to change at page 11, line 35 skipping to change at page 11, line 37
2.1.4. Component Revisions 2.1.4. Component Revisions
The "SEQUENCE" property is used by the "Organizer" to indicate The "SEQUENCE" property is used by the "Organizer" to indicate
revisions to the calendar component. The rules for incrementing the revisions to the calendar component. The rules for incrementing the
"SEQUENCE" number are defined in [I-D.ietf-calsify-rfc2445bis]. For "SEQUENCE" number are defined in [I-D.ietf-calsify-rfc2445bis]. For
clarity, these rules are paraphrased here in terms of how they are clarity, these rules are paraphrased here in terms of how they are
applied in iTIP. For a given "UID" in a calendar component: applied in iTIP. For a given "UID" in a calendar component:
o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
value is incremented according to the rules defined in [I-D.ietf- value is incremented according to the rules defined in
calsify-rfc2445bis]. [I-D.ietf-calsify-rfc2445bis].
o The "SEQUENCE" property value MUST be incremented each time the o The "SEQUENCE" property value MUST be incremented each time the
"Organizer" uses the "ADD" or "CANCEL" methods. "Organizer" uses the "ADD" or "CANCEL" methods.
o The "SEQUENCE" property value MUST NOT be incremented when using o The "SEQUENCE" property value MUST NOT be incremented when using
"REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
delegation "REQUEST". delegation "REQUEST".
In some circumstances the "Organizer" may not have received responses In some circumstances the "Organizer" may not have received responses
to the final revision sent out. In this situation, the "Organizer" to the final revision sent out. In this situation, the "Organizer"
skipping to change at page 34, line 19 skipping to change at page 34, line 19
The busy time information within the iCalendar object MAY be grouped The busy time information within the iCalendar object MAY be grouped
into more than one "VFREEBUSY" calendar component. This capability into more than one "VFREEBUSY" calendar component. This capability
allows busy time periods to be grouped according to some common allows busy time periods to be grouped according to some common
periodicity, such as a calendar week, month, or year. In this case, periodicity, such as a calendar week, month, or year. In this case,
each "VFREEBUSY" calendar component MUST include the "ATTENDEE", each "VFREEBUSY" calendar component MUST include the "ATTENDEE",
"DTSTART" and "DTEND" properties in order to specify the source of "DTSTART" and "DTEND" properties in order to specify the source of
the busy time information and the date and time interval over which the busy time information and the date and time interval over which
the busy time information covers. the busy time information covers.
The "FREEBUSY" property value MAY include a list of values, separated The "FREEBUSY" property value MAY include a list of values, separated
by the COMMA character ([US-ASCII] decimal 44). Alternately, by the COMMA character (US-ASCII decimal 44). Alternately, multiple
multiple busy time periods MAY be specified with multiple instances busy time periods MAY be specified with multiple instances of the
of the "FREEBUSY" property. Both forms MUST be supported by "FREEBUSY" property. Both forms MUST be supported by implementations
implementations conforming to this document. Duplicate busy time conforming to this document. Duplicate busy time periods SHOULD NOT
periods SHOULD NOT be specified in an iCalendar object. However, two be specified in an iCalendar object. However, two different busy
different busy time periods MAY overlap. time periods MAY overlap.
"FREEBUSY" properties should be sorted such that their values are in "FREEBUSY" properties should be sorted such that their values are in
ascending order, based on the start time, and then the end time, with ascending order, based on the start time, and then the end time, with
the earliest periods first. For example, today's busy time the earliest periods first. For example, today's busy time
information should appear after yesterday's busy time information. information should appear after yesterday's busy time information.
And the busy time for this half-hour should appear after the busy And the busy time for this half-hour should appear after the busy
time for earlier today. time for earlier today.
Since events may span a day boundary, free busy time period may also Since events may span a day boundary, free busy time period may also
span a day boundary. Individual "A" requests busy time from span a day boundary. Individual "A" requests busy time from
skipping to change at page 62, line 11 skipping to change at page 62, line 11
| | | | | | | |
| 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 may include the following values:
+---------+------------------------+--------------------------------+ +----------+------------------------+-------------------------------+
| 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 be | | 2.1 | Success but fallback | Property name and value MAY |
| | taken on one or more | specified. | | | taken on one or more | be specified. |
| | property values. | | | | property values. | |
| | | | | | | |
| 2.2 | Success, invalid | Property name MAY be | | 2.2 | Success, invalid | Property name MAY be |
| | property ignored. | specified. | | | property ignored. | specified. |
| | | | | | | |
| 2.3 | Success, invalid | Property parameter name and | | 2.3 | Success, invalid | Property parameter name and |
| | property parameter | value MAY be specified. | | | property parameter | value MAY be specified. |
| | ignored. | | | | ignored. | |
| | | | | | | |
| 2.4 | Success, unknown | Non-standard property name MAY | | 2.4 | Success, unknown | Non-standard property name |
| | non-standard property | be specified. | | | non-standard property | MAY be specified. |
| | ignored. | | | | ignored. | |
| | | | | | | |
| 2.5 | Success, unknown | Property and non-standard | | 2.5 | Success, unknown | Property and non-standard |
| | non-standard property | value MAY be specified. | | | non-standard property | value MAY be specified. |
| | value ignored. | | | | value ignored. | |
| | | | | | | |
| 2.6 | Success, invalid | Calendar component sentinel | | 2.6 | Success, invalid | Calendar component sentinel |
| | calendar component | (e.g., BEGIN:ALARM) MAY be | | | calendar component | (e.g., BEGIN:ALARM) MAY be |
| | ignored. | specified. | | | ignored. | specified. |
| | | | | | | |
| 2.7 | Success, request | Original and forwarded caluser | | 2.7 | Success, request | Original and forwarded |
| | forwarded to Calendar | addresses MAY be specified. | | | forwarded to Calendar | caluser addresses MAY be |
| | User. | | | | User. | specified. |
| | | | | | | |
| 2.8 | Success, repeating | RRULE or RDATE property name | | 2.8 | Success, repeating | RRULE or RDATE property name |
| | event ignored. | and value MAY be specified. | | | event ignored. | and value MAY be specified. |
| | Scheduled as a single | | | | Scheduled as a single | |
| | component. | | | | component. | |
| | | | | | | |
| 2.9 | Success, truncated end | DTEND property value MAY be | | 2.9 | Success, truncated end | DTEND property value MAY be |
| | date time to date | specified. | | | date time to date | specified. |
| | boundary. | | | | boundary. | |
| | | | | | | |
skipping to change at page 63, line 21 skipping to change at page 63, line 21
| | VTODO. | | | | VTODO. | |
| | | | | | | |
| 2.11 | Success, unbounded | RRULE property name and value | | 2.11 | Success, unbounded | RRULE property name and value |
| | RRULE clipped at some | MAY be specified. Number of | | | RRULE clipped at some | MAY be specified. Number of |
| | finite number of | instances MAY also be | | | finite number of | instances MAY also be |
| | instances | specified. | | | instances | specified. |
| | | | | | | |
| 3.0 | Invalid property name. | Property name MAY be | | 3.0 | Invalid property name. | Property name MAY be |
| | | specified. | | | | specified. |
| | | | | | | |
| 3.1 | Invalid property | Property name and value MAY be | | 3.1 | Invalid property | Property name and value MAY |
| | value. | specified. | | | value. | be specified. |
| | | | | | | |
| 3.2 | Invalid property | Property parameter name and | | 3.2 | Invalid property | Property parameter name and |
| | parameter. | value MAY be specified. | | | parameter. | value MAY be specified. |
| | | | | | | |
| 3.3 | Invalid property | Property parameter name and | | 3.3 | Invalid property | Property parameter name and |
| | parameter value. | value MAY be specified. | | | parameter value. | value MAY be specified. |
| | | | | | | |
| 3.4 | Invalid calendar | Calendar component sentinel | | 3.4 | Invalid calendar | Calendar component sentinel |
| | component sequence. | MAY be specified (e.g., | | | component sequence. | MAY be specified (e.g., |
| | | BEGIN:VTIMEZONE). | | | | BEGIN:VTIMEZONE). |
| | | | | | | |
| 3.5 | Invalid date or time. | Date/time value(s) MAY be | | 3.5 | Invalid date or time. | Date/time value(s) MAY be |
| | | specified. | | | | specified. |
| | | | | | | |
| 3.6 | Invalid rule. | Rule value MAY be specified. | | 3.6 | Invalid rule. | Rule value MAY be specified. |
| | | | | | | |
| 3.7 | Invalid Calendar User. | Attendee property value MAY be | | 3.7 | Invalid Calendar User. | Attendee property value MAY |
| | | specified. | | | | be specified. |
| | | | | | | |
| 3.8 | No authority. | METHOD and Attendee property | | 3.8 | No authority. | METHOD and Attendee property |
| | | values MAY be specified. | | | | values MAY be specified. |
| | | | | | | |
| 3.9 | Unsupported version. | VERSION property name and | | 3.9 | Unsupported version. | VERSION property name and |
| | | value MAY be specified. | | | | value MAY be specified. |
| | | | | | | |
| 3.10 | Request entity too | None. | | 3.10 | Request entity too | None. |
| | large. | | | | large. | |
| | | | | | | |
| 3.11 | Required component or | Component or property name MAY | | 3.11 | Required component or | Component or property name |
| | property missing. | be specified. | | | property missing. | MAY be specified. |
| | | | | | | |
| 3.12 | Unknown component or | Component or property name MAY | | 3.12 | Unknown component or | Component or property name |
| | property found | be specified | | | property found | MAY be specified |
| | | | | | | |
| 3.13 | Unsupported component | Component or property name MAY | | 3.13 | Unsupported component | Component or property name |
| | or property found | be specified | | | or property found | MAY be specified |
| | | | | | | |
| 3.14 | Unsupported capability | Method or action MAY be | | 3.14 | Unsupported capability | Method or action MAY be |
| | | specified | | | | specified |
| | | | | | | |
| 4.0 | Event conflict. | DTSTART and DTEND property | | 4.0 | Event conflict. | DTSTART and DTEND property |
| | Date/time is busy. | name and values MAY be | | | Date/time is busy. | name and values MAY be |
| | | specified. | | | | specified. |
| | | | | | | |
| 5.0 | Request MAY supported. | Method property value MAY be | | 5.0 | Request MAY supported. | Method property value MAY be |
| | | specified. | | | | specified. |
| | | | | | | |
| 5.1 | Service unavailable. | ATTENDEE property value MAY be | | 5.1 | Service unavailable. | ATTENDEE property value MAY |
| | | specified. | | | | be specified. |
| | | | | | | |
| 5.2 | Invalid calendar | ATTENDEE property value MAY be | | 5.2 | Invalid calendar | ATTENDEE property value MAY |
| | service. | specified. | | | service. | be specified. |
| | | | | | | |
| 5.3 | No scheduling support | ATTENDEE property value MAY be | | 5.3 | No scheduling support | ATTENDEE property value MAY |
| | for user. | specified. | | | for user. | be specified. |
+---------+------------------------+--------------------------------+ +----------+------------------------+-------------------------------+
3.7. Implementation Considerations 3.7. Implementation Considerations
3.7.1. Working With Recurrence Instances 3.7.1. Working With Recurrence Instances
iCalendar includes a recurrence grammar to represent recurring iCalendar includes a recurrence grammar to represent recurring
events. The benefit of such a grammar is the ability to represent a events. The benefit of such a grammar is the ability to represent a
number of events in a single object. However, while this simplifies number of events in a single object. However, while this simplifies
creation of a recurring event, meeting instances still need to be creation of a recurring event, meeting instances still need to be
referenced. For instance, an "Attendee" may decline the third referenced. For instance, an "Attendee" may decline the third
skipping to change at page 67, line 5 skipping to change at page 67, line 5
simply incorporate the event into a calendar. No reply is expected. simply incorporate the event into a calendar. No reply is expected.
Individual "A" publishes an event. Individual "B" reads the event Individual "A" publishes an event. Individual "B" reads the event
and incorporates it into their calendar. Events are published in and incorporates it into their calendar. Events are published in
several ways including: embedding the event as an object in a web several ways including: embedding the event as an object in a web
page, e- mailing the event to a distribution list, and posting the page, e- mailing the event to a distribution list, and posting the
event to a newsgroup. event to a newsgroup.
The table below illustrates the sequence of events between the The table below illustrates the sequence of events between the
publisher and the consumers of a published event. publisher and the consumers of a published event.
+----------------+-----------------------+--------------------------+ +-----------------+-----------------------+-------------------------+
| Action | Organizer | Receiver | | Action | Organizer | Receiver |
+----------------+-----------------------+--------------------------+ +-----------------+-----------------------+-------------------------+
| Publish an | "A" sends or posts a | "B" reads a published | | Publish an | "A" sends or posts a | "B" reads a published |
| event | PUBLISH message | event | | event | PUBLISH message | event |
| | | | | | | |
| Publish an | "A" sends or posts a | "B" reads the updated | | Publish an | "A" sends or posts a | "B" reads the updated |
| updated event | PUBLISH message | event | | updated event | PUBLISH message | event |
| | | | | | | |
| Cancel a | "A" sends or posts a | "B" reads the canceled | | Cancel a | "A" sends or posts a | "B" reads the canceled |
| published | CANCEL message | event publication | | published event | CANCEL message | event publication |
| event | | | +-----------------+-----------------------+-------------------------+
+----------------+-----------------------+--------------------------+
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:-//ACME/DesktopCalendar//EN
skipping to change at page 71, line 5 skipping to change at page 71, line 5
Group events are distinguished from published events in that they Group events are distinguished from published events in that they
have "Attendees" and that there is interaction between the have "Attendees" and that there is interaction between the
"Attendees" and the "Organizer" with respect to the event. "Attendees" and the "Organizer" with respect to the event.
Individual "A" requests a meeting between individuals "A", "B", "C" Individual "A" requests a meeting between individuals "A", "B", "C"
and "D". Individual "B" confirms attendance to the meeting. and "D". Individual "B" confirms attendance to the meeting.
Individual "C" declines attendance. Individual "D" tentatively Individual "C" declines attendance. Individual "D" tentatively
confirms attendance. The following table illustrates the the message confirms attendance. The following table illustrates the the message
flow between these individuals. A, the CU scheduling the meeting, is flow between these individuals. A, the CU scheduling the meeting, is
referenced as the "Organizer". referenced as the "Organizer".
+-------------+-----------------------+-----------------------------+ +--------------+-----------------------+----------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+-------------+-----------------------+-----------------------------+ +--------------+-----------------------+----------------------------+
| Initiate a | "A" sends a REQUEST | | | Initiate a | "A" sends a REQUEST | |
| meeting | message to "B", "C", | | | meeting | message to "B", "C", | |
| request | and "D" | | | request | and "D" | |
| | | | | | | |
| Accept the | | "B" sends a REPLY message | | Accept the | | "B" sends a REPLY message |
| meeting | | to "A" with its ATTENDEE | | meeting | | to "A" with its ATTENDEE |
| request | | "partstat" para-set to | | request | | "partstat" para-set to |
| | | "accepted" | | | | "accepted" |
| | | | | | | |
| Decline the | | "C" sends a REPLY message | | Decline the | | "C" sends a REPLY message |
skipping to change at page 71, line 31 skipping to change at page 71, line 31
| | | | | | | |
| Tentatively | | "D" sends a REPLY message | | Tentatively | | "D" sends a REPLY message |
| accept the | | to "A" with its ATTENDEE | | accept the | | to "A" with its ATTENDEE |
| meeting | | "partstat" para-set to | | meeting | | "partstat" para-set to |
| request | | "tentative" | | request | | "tentative" |
| | | | | | | |
| Confirm | "A" sends a REQUEST | | | Confirm | "A" sends a REQUEST | |
| meeting | message to "B" and | | | meeting | message to "B" and | |
| status with | "D" with updated | | | status with | "D" with updated | |
| attendees | information. | | | attendees | information. | |
+-------------+-----------------------+-----------------------------+ +--------------+-----------------------+----------------------------+
4.2.1. A Group Event Request 4.2.1. A Group Event Request
A sample meeting request is sent from "A" to "B", "C", and "D". _E_ A sample meeting request is sent from "A" to "B", "C", and "D". _E_
is also sent a copy of the request but is not expected to attend and is also sent a copy of the request but is not expected to attend and
need not reply. "E" illustrates how CUAs might implement an "FYI" need not reply. "E" illustrates how CUAs might implement an "FYI"
type feature. Note the use of the "role" parameter. The default type feature. Note the use of the "role" parameter. The default
value for the "role" parameter is "req-participant" and it need not value for the "role" parameter is "req-participant" and it need not
be enumerated. In this case we are using the value "non-participant" be enumerated. In this case we are using the value "non-participant"
to indicate "E" is a non-attending CU. The parameter is not needed to indicate "E" is a non-attending CU. The parameter is not needed
skipping to change at page 76, line 32 skipping to change at page 76, line 32
o The "Delegator" MUST also send a copy of the original "REQUEST" o The "Delegator" MUST also send a copy of the original "REQUEST"
method to the "Delegate". method to the "Delegate".
It is not required that the "Delegate" include the "Delegator" in It is not required that the "Delegate" include the "Delegator" in
their "REPLY" method. However, it is strongly advised since this their "REPLY" method. However, it is strongly advised since this
will inform the "Delegator" whether the "Delegate" plans to attend will inform the "Delegator" whether the "Delegate" plans to attend
the meeting. [Editors note: How so?] If the "Delegate" declines the the meeting. [Editors note: How so?] If the "Delegate" declines the
meeting, the "Delegator" may elect to delegate the "REQUEST" to meeting, the "Delegator" may elect to delegate the "REQUEST" to
another CUA. The process is the same. another CUA. The process is the same.
+----------------+-----------------+--------------------------------+ +-----------------+----------------+--------------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+----------------+-----------------+--------------------------------+ +-----------------+----------------+--------------------------------+
| Initiate a | "A" sends a | | | Initiate a | "A" sends a | |
| meeting | REQUEST message | | | meeting request | REQUEST | |
| request | to "B" and "C" | | | | message to "B" | |
| | and "C" | |
| | | | | | | |
| Delegate: "C" | | "C" sends a REPLY to "A" with | | Delegate: "C" | | "C" sends a REPLY to "A" with |
| delegates to | | the ATTENDEE "partstat" | | delegates to | | the ATTENDEE "partstat" |
| "E" | | parameter set to "delegated" | | "E" | | parameter set to "delegated" |
| | | and with a new "ATTENDEE" | | | | and with a new "ATTENDEE" |
| | | property for "E". "E's" | | | | property for "E". "E's" |
| | | ATTENDEE "delegated-from" | | | | ATTENDEE "delegated-from" |
| | | param is set to "C". "C's" | | | | param is set to "C". "C's" |
| | | ATTENDEE "delegated-to" param | | | | ATTENDEE "delegated-to" param |
| | | is set to "E". "C" sends | | | | is set to "E". "C" sends |
skipping to change at page 77, line 25 skipping to change at page 77, line 25
| | | information. The "partstat" | | | | information. The "partstat" |
| | | property parameter for "C" is | | | | property parameter for "C" is |
| | | set to "delegated" and the | | | | set to "delegated" and the |
| | | "delegated-to" parameter is | | | | "delegated-to" parameter is |
| | | set to the address of "E". An | | | | set to the address of "E". An |
| | | "ATTENDEE" property is added | | | | "ATTENDEE" property is added |
| | | for "E" and the | | | | for "E" and the |
| | | "delegated-from" parameter is | | | | "delegated-from" parameter is |
| | | set to the address of "C". | | | | set to the address of "C". |
| | | | | | | |
| Confirm | | "E" sends REPLY message to "A" | | Confirm meeting | | "E" sends REPLY message to "A" |
| meeting | | and optionally "C" with its | | attendance | | and optionally "C" with its |
| attendance | | "partstat" property parameter | | | | "partstat" property parameter |
| | | set to "ACCEPTED" | | | | set to "ACCEPTED" |
| | | | | | | |
| Optional: | "A" sends | | | Optional: | "A" sends | |
| Redistribute | REQUEST message | | | Redistribute | REQUEST | |
| meeting to | to "B", "C" and | | | meeting to | message to | |
| attendees | "E". | | | attendees | "B", "C" and | |
+----------------+-----------------+--------------------------------+ | | "E". | |
+-----------------+----------------+--------------------------------+
"C" responds to the "Organizer". "C" responds to the "Organizer".
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//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-
skipping to change at page 81, line 5 skipping to change at page 81, line 5
Individual "A" requests a meeting between individuals "A", "B", "C", Individual "A" requests a meeting between individuals "A", "B", "C",
and "D". Individual "B" declines attendance to the meeting. and "D". Individual "B" declines attendance to the meeting.
Individual "A" decides to cancel the meeting. The following table Individual "A" decides to cancel the meeting. The following table
illustrates the sequence of messages that would be exchanged between illustrates the sequence of messages that would be exchanged between
these individuals. these individuals.
Messages related to a previously canceled event ("SEQUENCE" property Messages related to a previously canceled event ("SEQUENCE" property
value is less than the "SEQUENCE" property value of the "CANCEL" value is less than the "SEQUENCE" property value of the "CANCEL"
message) MUST be ignored. message) MUST be ignored.
+------------+--------------------+---------------------------------+ +-------------+---------------------+-------------------------------+
| Action | "Organizer" | "Attendee" | | Action | "Organizer" | "Attendee" |
+------------+--------------------+---------------------------------+ +-------------+---------------------+-------------------------------+
| Initiate a | "A" sends a | | | Initiate a | "A" sends a REQUEST | |
| meeting | REQUEST message to | | | meeting | message to "B", | |
| request | "B", "C", and "D" | | | request | "C", and "D" | |
| | | | | | | |
| Decline | | "B" sends a "REPLY" message to | | Decline the | | "B" sends a "REPLY" message |
| the | | "A" with its "partstat" | | meeting | | to "A" with its "partstat" |
| meeting | | para-set to "declined". | | request | | para-set to "declined". |
| request | | |
| | | | | | | |
| Cancel the | "A" sends a CANCEL | | | Cancel the | "A" sends a CANCEL | |
| meeting | message to "B", | | | meeting | message to "B", "C" | |
| | "C" and "D" | | | | and "D" | |
+------------+--------------------+---------------------------------+ +-------------+---------------------+-------------------------------+
The example shows how "A" cancels the event. The example shows how "A" cancels the event.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:CANCEL METHOD:CANCEL
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com
skipping to change at page 82, line 5 skipping to change at page 81, line 47
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.2.10. Removing Attendees 4.2.10. Removing Attendees
"A" wants to remove "B" from a meeting. This is done by sending a "A" wants to remove "B" from a meeting. This is done by sending a
"CANCEL" to "B" and removing "B" from the attendee list in the master "CANCEL" to "B" and removing "B" from the attendee list in the master
copy of the event. copy of the event.
+--------------------+---------------------------------+------------+ +---------------------+--------------------------------+------------+
| Action | "Organizer" | "Attendee" | | Action | "Organizer" | "Attendee" |
+--------------------+---------------------------------+------------+ +---------------------+--------------------------------+------------+
| Remove an "B" as | "A" sends a CANCEL message to | | | Remove an "B" as an | "A" sends a CANCEL message to | |
| an "Attendee" | "B" | | | "Attendee" | "B" | |
| | | | | | | |
| Update the master | "A" sends the updated event to | | | Update the master | "A" sends the updated event to | |
| 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:-//ACME/DesktopCalendar//EN
METHOD:CANCEL METHOD:CANCEL
skipping to change at page 85, line 11 skipping to change at page 84, line 31
FREEBUSY:19980115T220000Z/19980115T230000Z FREEBUSY:19980115T220000Z/19980115T230000Z
FREEBUSY:19980116T013000Z/19980116T043000Z FREEBUSY:19980116T013000Z/19980116T043000Z
END:VFREEBUSY END:VFREEBUSY
END:VCALENDAR END:VCALENDAR
Individual "A" requests busy time from individuals "B", "C". Individual "A" requests busy time from individuals "B", "C".
Individual "B" and "C" replies with busy time data to individual "A". Individual "B" and "C" replies with busy time data to individual "A".
The following table illustrates the sequence of messages that would The following table illustrates the sequence of messages that would
be exchanged between these individuals. be exchanged between these individuals.
+---------------------+--------------------+------------------------+ +----------------------+--------------------+-----------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+---------------------+--------------------+------------------------+ +----------------------+--------------------+-----------------------+
| Initiate a busy | "A" sends | | | Initiate a busy time | "A" sends | |
| time request | "REQUEST" message | | | request | "REQUEST" message | |
| | to "B" and "C" | | | | to "B" and "C" | |
| | | | | | | |
| Reply to the "BUSY" | | "B" sends a "REPLY" | | Reply to the "BUSY" | | "B" sends a "REPLY" |
| request with "BUSY" | | message to "A" with | | request with "BUSY" | | message to "A" with |
| time data | | busy time data | | time data | | busy time data |
+---------------------+--------------------+------------------------+ +----------------------+--------------------+-----------------------+
4.3.1. Request Busy Time 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:-//ACME/DesktopCalendar//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
skipping to change at page 101, line 12 skipping to change at page 100, line 17
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"
tentatively accepts the task. The following table illustrates the tentatively accepts the task. The following table illustrates the
sequence of messages that would be exchanged between these sequence of messages that would be exchanged between these
individuals. Individual "A" then issues a "REQUEST" method to obtain individuals. Individual "A" then issues a "REQUEST" method to obtain
the status of the to-do from each participant. The response the status of the to-do from each participant. The response
indicates the individual "Attendee's" completion status. The table indicates the individual "Attendee's" completion status. The table
below illustrates the message flow. below illustrates the message flow.
+-------------+-----------------------+-----------------------------+ +--------------+------------------------+---------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+-------------+-----------------------+-----------------------------+ +--------------+------------------------+---------------------------+
| Initiate a | "A" sends a REQUEST | | | Initiate a | "A" sends a REQUEST | |
| to-do | message to "B", "C", | | | to-do | message to "B", "C", | |
| request | and "D" | | | request | and "D" | |
| | | | | | | |
| Accept the | | "B" sends a "REPLY" message | | Accept the | | "B" sends a "REPLY" |
| to-do | | to "A" with its "partstat" | | to-do | | message to "A" with its |
| request | | parameter set to | | request | | "partstat" parameter set |
| | | "accepted". | | | | to "accepted". |
| | | | | | | |
| Decline the | | "C" sends a REPLY message | | Decline the | | "C" sends a REPLY message |
| to-do | | to "A" with its "partstat" | | to-do | | to "A" with its |
| request | | parameter set to | | request | | "partstat" parameter set |
| | | "declined". | | | | to "declined". |
| | | | | | | |
| Tentatively | | "D" sends a REPLY message | | Tentatively | | "D" sends a REPLY message |
| accept the | | to "A" with its "partstat" | | accept the | | to "A" with its |
| to-do | | parameter set to | | to-do | | "partstat" parameter set |
| request | | "tentative". | | request | | to "tentative". |
| | | | | | | |
| Check | "A" sends a REQUEST | | | Check | "A" sends a REQUEST | |
| attendee | message to "B" and | | | attendee | message to "B" and "D" | |
| completion | "D" with current | | | completion | with current | |
| status | information. | | | status | information. | |
| | | | | | | |
| Attendee | | "B" sends a "REPLY" message | | Attendee | | "B" sends a "REPLY" |
| indicates | | indicating percent complete | | indicates | | message indicating |
| percent | | | | percent | | percent complete |
| complete | | | | complete | | |
| | | | | | | |
| Attendee | | "D" sends a "REPLY" message | | Attendee | | "D" sends a "REPLY" |
| indicates | | indicating completion | | indicates | | message indicating |
| 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:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
skipping to change at page 108, line 13 skipping to change at page 107, line 13
event. event.
In case (3), the limitations of the "Attendee's" CUA makes it In case (3), the limitations of the "Attendee's" CUA makes it
impossible to match an instance other than the single instance impossible to match an instance other than the single instance
scheduled. In this case, the "Attendee" need not send a "REFRESH" to scheduled. In this case, the "Attendee" need not send a "REFRESH" to
the "Organizer". the "Organizer".
The example below shows a sequence in which an "Attendee" sends a The example below shows a sequence in which an "Attendee" sends a
"REFRESH" to the "Organizer". "REFRESH" to the "Organizer".
+--------------------------+-------------------+--------------------+ +-------------------------+--------------------+--------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+--------------------------+-------------------+--------------------+ +-------------------------+--------------------+--------------------+
| Update an instance | "A" sends | | | Update an instance | "A" sends | |
| request | "REQUEST" message | | | request | "REQUEST" message | |
| | to "B" | | | | to "B" | |
| | | | | | | |
| Attendee requests | | "B" sends a | | Attendee requests | | "B" sends a |
| refresh because | | "REFRESH" message | | refresh because | | "REFRESH" message |
| "RECURRENCE-ID" was not | | to "A" | | "RECURRENCE-ID" was not | | to "A" |
| found | | | | found | | |
| | | | | | | |
| Refresh the entire Event | "A" sends the | | | Refresh the entire | "A" sends the | |
| | latest copy of | | | Event | latest copy of the | |
| | the Event to "B" | | | | Event to "B" | |
| | | | | | | |
| Attendee handles the | | "B" updates to the | | Attendee handles the | | "B" updates to the |
| request and updates the | | latest copy of the | | request and updates the | | latest copy of the |
| instance | | meeting. | | instance | | meeting. |
+--------------------------+-------------------+--------------------+ +-------------------------+--------------------+--------------------+
Request from "A": Request from "A":
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:REQUEST METHOD:REQUEST
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:acme-12345@host1.com UID:acme-12345@host1.com
SEQUENCE:3 SEQUENCE:3
skipping to change at page 120, line 10 skipping to change at page 119, line 10
The threat of unauthorized "REFRESH" requests SHOULD be mitigated by The threat of unauthorized "REFRESH" requests SHOULD be mitigated by
a calendar system that uses this protocol by providing controls or a calendar system that uses this protocol by providing controls or
alerts that allow "Calendar User" to decide whether or not the alerts that allow "Calendar User" to decide whether or not the
request should be honored. An implementation MAY decide to maintain, request should be honored. An implementation MAY decide to maintain,
for audit or historical purposes, "Calendar Users" who were part of for audit or historical purposes, "Calendar Users" who were part of
an attendee list and who were subsequently uninvited. Similar an attendee list and who were subsequently uninvited. Similar
controls or alerts should be provided when a "REFRESH" request is controls or alerts should be provided when a "REFRESH" request is
received from these "Calendar Users" as well. received from these "Calendar Users" as well.
7. References 7. IANA Consideration
7.1. Normative References TBD. Will be based on 2445bis changes.
8. 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-01 (work in progress), draft-ietf-calsify-rfc2445bis-05 (work in progress),
June 2006. January 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-02 (work in Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-03 (work
progress), June 2006. 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
7.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.
Author's Address Author's Address
Cyrus Daboo Cyrus Daboo (editor)
Editor Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Email: cyrus@daboo.name Email: cyrus@daboo.name
URI: http://www.apple.com/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 122, line 29 skipping to change at page 121, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 74 change blocks. 
194 lines changed or deleted 209 lines changed or added

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