draft-ietf-calsch-itip-04.txt   draft-ietf-calsch-itip-05.txt 
Network Working Group Steve Silverberg, Microsoft Network Working Group Steve Silverberg, Microsoft
INTERNET-DRAFT Steve Mansour, Netscape INTERNET-DRAFT Steve Mansour, Netscape
Calendaring and Scheduling Working Group Frank Dawson, Lotus Calendaring and Scheduling Working Group Frank Dawson, Lotus
<draft-ietf-calsch-itip-04.txt Ross Hopson, ON Technologies <draft-ietf-calsch-itip-05.txt> Ross Hopson, ON Technologies
Expires six months after: May 11, 1998 Expires six months after: June 29, 1998
iCalendar Transport-Independent Interoperability Protocol iCalendar Transport-Independent Interoperability Protocol
(iTIP) (iTIP)
Scheduling Events, BusyTime, To-dos and Journal Entries Scheduling Events, BusyTime, To-dos and Journal Entries
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or made obsolete by other Internet-Drafts may be updated, replaced, or made obsolete by other
documents at any time. It is not appropriate to use Internet-Drafts as documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or reference material or to cite them other than as a "working draft" or
"work in progress". "work in progress".
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
(US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Copyright (C) The Internet Society 1997. All Rights Reserved. Copyright (C) The Internet Society 1997. All Rights Reserved.
Abstract Abstract
This document specifies how calendaring systems use iCalendar objects to This document specifies how calendaring systems use iCalendar objects to
interoperate with other calendar systems. It does so in a general way so interoperate with other calendar systems. It does so in a general way so
as to allow multiple methods of communication between systems. as to allow multiple methods of communication between systems.
Subsequent documents specify interoperable methods of communications Subsequent documents specify interoperable methods of communications
skipping to change at line 53 skipping to change at line 52
static and dynamic event, to-do, journal and free/busy objects. Static static and dynamic event, to-do, journal and free/busy objects. Static
objects are used to transmit information from one entity to another objects are used to transmit information from one entity to another
without the expectation of continuity or referential integrity with the without the expectation of continuity or referential integrity with the
original item. Dynamic objects are a superset of static objects and will original item. Dynamic objects are a superset of static objects and will
gracefully degrade to their static counterparts for clients that only gracefully degrade to their static counterparts for clients that only
support static objects. support static objects.
This document specifies an Internet protocol based on the iCalendar This document specifies an Internet protocol based on the iCalendar
object specification that provides scheduling interoperability between object specification that provides scheduling interoperability between
different calendar systems. The Internet protocol is called the different calendar systems. The Internet protocol is called the
'iCalendar Transport-Independent Interoperability Protocol (iTIP)'. "iCalendar Transport-Independent Interoperability Protocol (iTIP)".
iTIP complements the iCalendar object specification by adding semantics iTIP complements the iCalendar object specification by adding semantics
for group scheduling methods commonly available in current calendar for group scheduling methods commonly available in current calendar
systems. These scheduling methods permit two or more calendar systems to systems. These scheduling methods permit two or more calendar systems to
perform transactions such as publish, schedule, reschedule, respond to
Silverberg/Mansour/Daws/Hopson 1 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 1 - Expires December 1998
perform transactions such as publish, schedule, reschedule, respond to
scheduling requests, negotiation of changes or cancel iCalendar-based scheduling requests, negotiation of changes or cancel iCalendar-based
calendar components. calendar components.
iTIP is defined independent of the particular transport used to transmit iTIP is defined independent of the particular transport used to transmit
the scheduling information. Companion memos to iTIP provide bindings of the scheduling information. Companion memos to iTIP provide bindings of
the interoperability protocol to a number of Internet protocols. the interoperability protocol to a number of Internet protocols.
Silverberg/Mansour/Daws/Hopson 2 Expires November 1998
Table of Contents Table of Contents
1 INTRODUCTION.........................................................6 1 INTRODUCTION.........................................................6
1.1 FORMATTING CONVENTIONS ...........................................6 1.1 FORMATTING CONVENTIONS ...........................................6
1.2 RELATED DOCUMENTS ................................................7 1.2 RELATED DOCUMENTS ................................................7
1.3 ITIP ROLES AND TRANSACTIONS ......................................7 1.3 ITIP ROLES AND TRANSACTIONS ......................................7
2 INTEROPERABILITY MODELS..............................................9 2 INTEROPERABILITY MODELS..............................................9
skipping to change at line 114 skipping to change at line 113
3.2.8 DECLINECOUNTER ..............................................27 3.2.8 DECLINECOUNTER ..............................................27
3.3 METHODS FOR VFREEBUSY COMPONENTS ................................28 3.3 METHODS FOR VFREEBUSY COMPONENTS ................................28
3.3.1 PUBLISH .....................................................29 3.3.1 PUBLISH .....................................................29
3.3.2 REQUEST .....................................................30 3.3.2 REQUEST .....................................................30
3.3.3 REPLY .......................................................31 3.3.3 REPLY .......................................................31
3.4 METHODS FOR VTODO COMPONENTS ....................................32 3.4 METHODS FOR VTODO COMPONENTS ....................................32
3.4.1 PUBLISH .....................................................33 3.4.1 PUBLISH .....................................................33
3.4.2 REQUEST .....................................................34 3.4.2 REQUEST .....................................................34
3.4.2.1 REQUEST for Rescheduling a VTODO.........................36 3.4.2.1 REQUEST for Rescheduling a VTODO.........................36
3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO..........36 3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO..........36
Silverberg/Mansour/Dawson/Hopson - 2 - Expires December 1998
3.4.2.3 REQUEST for Delegating a VTODO...........................37 3.4.2.3 REQUEST for Delegating a VTODO...........................37
3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User..........37 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User..........37
3.4.2.5 REQUEST Updated Attendee Status..........................38 3.4.2.5 REQUEST Updated Attendee Status..........................38
3.4.3 REPLY .......................................................38 3.4.3 REPLY .......................................................38
3.4.4 ADD .........................................................39 3.4.4 ADD .........................................................39
3.4.5 CANCEL ......................................................41 3.4.5 CANCEL ......................................................41
Silverberg/Mansour/Daws/Hopson 3 Expires November 1998
3.4.6 REFRESH .....................................................42 3.4.6 REFRESH .....................................................42
3.4.7 COUNTER .....................................................44 3.4.7 COUNTER .....................................................44
3.4.8 DECLINECOUNTER ..............................................45 3.4.8 DECLINECOUNTER ..............................................45
3.5 METHODS FOR VJOURNAL COMPONENTS .................................46 3.5 METHODS FOR VJOURNAL COMPONENTS .................................46
3.5.1 PUBLISH .....................................................47 3.5.1 PUBLISH .....................................................47
3.5.2 ADD .........................................................48 3.5.2 ADD .........................................................48
3.5.3 CANCEL ......................................................49 3.5.3 CANCEL ......................................................49
3.6 STATUS REPLIES ..................................................50 3.6 STATUS REPLIES ..................................................50
3.7 IMPLEMENTATION CONSIDERATIONS ...................................52 3.7 IMPLEMENTATION CONSIDERATIONS ...................................52
3.7.1 Working With Recurrence Instances ...........................52 3.7.1 Working With Recurrence Instances ...........................52
skipping to change at line 170 skipping to change at line 169
4.4.2 Modify A Recurring Instance .................................72 4.4.2 Modify A Recurring Instance .................................72
4.4.3 Cancel an Instance ..........................................73 4.4.3 Cancel an Instance ..........................................73
4.4.4 Cancel Recurring Event ......................................74 4.4.4 Cancel Recurring Event ......................................74
4.4.5 Change All Future Instances .................................74 4.4.5 Change All Future Instances .................................74
4.4.6 Add A New Instance To A Recurring Event .....................75 4.4.6 Add A New Instance To A Recurring Event .....................75
4.4.7 Add A New Series of Instances To A Recurring Event ..........75 4.4.7 Add A New Series of Instances To A Recurring Event ..........75
4.4.8 Counter An Instance Of A Recurring Event ....................79 4.4.8 Counter An Instance Of A Recurring Event ....................79
4.4.9 Error Reply To A Request ....................................79 4.4.9 Error Reply To A Request ....................................79
4.5 GROUP TO-DO EXAMPLES ............................................80 4.5 GROUP TO-DO EXAMPLES ............................................80
4.5.1 A VTODO Request .............................................81 4.5.1 A VTODO Request .............................................81
Silverberg/Mansour/Dawson/Hopson - 3 - Expires December 1998
4.5.2 A VTODO Reply ...............................................82 4.5.2 A VTODO Reply ...............................................82
4.5.3 A VTODO Request for Updated Status ..........................82 4.5.3 A VTODO Request for Updated Status ..........................82
4.5.4 A Reply: Percent-Complete ...................................83 4.5.4 A Reply: Percent-Complete ...................................83
4.5.5 A Reply: Completed ..........................................83 4.5.5 A Reply: Completed ..........................................83
4.5.6 An Updated VTODO Request ....................................83 4.5.6 An Updated VTODO Request ....................................83
4.5.7 Recurring VTODOs ............................................84 4.5.7 Recurring VTODOs ............................................84
Silverberg/Mansour/Daws/Hopson 4 Expires November 1998
4.5.7.1 Request for a Recurring VTODO............................84 4.5.7.1 Request for a Recurring VTODO............................84
4.5.7.2 Calculating due dates in recurring VTODOs................85 4.5.7.2 Calculating due dates in recurring VTODOs................85
4.5.7.3 Replying to an instance of a recurring VTODO.............85 4.5.7.3 Replying to an instance of a recurring VTODO.............85
4.6 JOURNAL EXAMPLES ................................................85 4.6 JOURNAL EXAMPLES ................................................85
4.7 OTHER EXAMPLES ..................................................86 4.7 OTHER EXAMPLES ..................................................86
4.7.1 Event Refresh ...............................................86 4.7.1 Event Refresh ...............................................86
4.7.2 Bad RECURRENCE-ID ...........................................86 4.7.2 Bad RECURRENCE-ID ...........................................86
5 APPLICATION PROTOCOL FALLBACKS......................................88 5 APPLICATION PROTOCOL FALLBACKS......................................88
skipping to change at line 220 skipping to change at line 219
6.2.2 Implementation Controls .....................................96 6.2.2 Implementation Controls .....................................96
7 ACKNOWLEDGMENTS.....................................................96 7 ACKNOWLEDGMENTS.....................................................96
8 BIBLIOGRAPHY........................................................96 8 BIBLIOGRAPHY........................................................96
9 AUTHORS ADDRESSES...................................................97 9 AUTHORS ADDRESSES...................................................97
10 FULL COPYRIGHT STATEMENT...........................................99 10 FULL COPYRIGHT STATEMENT...........................................99
Silverberg/Mansour/Daws/Hopson 5 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 4 - Expires December 1998
1 Introduction 1 Introduction
This document specifies how calendaring systems use iCalendar objects to This document specifies how calendaring systems use iCalendar objects to
interoperate with other calendar systems. In particular, it specifies interoperate with other calendar systems. In particular, it specifies
how to schedule events, to-dos, or daily journal entries. It further how to schedule events, to-dos, or daily journal entries. It further
specifies how to search for available busy time information. It does so specifies how to search for available busy time information. It does so
in a general way so as to allow multiple methods of communication in a general way so as to allow multiple methods of communication
between systems. Subsequent documents specify transport bindings between between systems. Subsequent documents specify transport bindings between
systems that use this protocol. systems that use this protocol.
skipping to change at line 273 skipping to change at line 273
of the calendar component. of the calendar component.
Properties defined by [iCAL] are referred to with capitalized, quoted- Properties defined by [iCAL] are referred to with capitalized, quoted-
strings of text, followed by the word "property". For example, strings of text, followed by the word "property". For example,
"ATTENDEE" property refers to the iCalendar property used to convey the "ATTENDEE" property refers to the iCalendar property used to convey the
calendar address of a "Calendar User". Property parameters defined by calendar address of a "Calendar User". Property parameters defined by
this memo are referred to with lower case, quoted-strings of text, this memo are referred to with lower case, quoted-strings of text,
followed by the word "parameter". For example, "value" parameter refers followed by the word "parameter". For example, "value" parameter refers
to the iCalendar property parameter used to override the default data to the iCalendar property parameter used to override the default data
Silverberg/Mansour/Daws/Hopson 6 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 5 - Expires December 1998
type for a property value. Enumerated values defined by this memo are type for a property value. Enumerated values defined by this memo are
referred to with capitalized text, either alone or followed by the word referred to with capitalized text, either alone or followed by the word
"value". "value".
In tables, the quoted-string text is specified without quotes in order In tables, the quoted-string text is specified without quotes in order
to minimize the table length. to minimize the table length.
1.2 Related Documents 1.2 Related Documents
Implementers will need to be familiar with several other memos that, Implementers will need to be familiar with several other memos that,
skipping to change at line 327 skipping to change at line 328
defined in section 3 of this document. defined in section 3 of this document.
+================+==================================================+ +================+==================================================+
| Method | Description | | Method | Description |
|================+==================================================| |================+==================================================|
| PUBLISH | Used to publish a calendar entry to one or more | | PUBLISH | Used to publish a calendar entry to one or more |
| | Calendar Users. There is no interactivity | | | Calendar Users. There is no interactivity |
| | between the publisher and any other calendar | | | between the publisher and any other calendar |
| | user. An example might include a baseball team | | | user. An example might include a baseball team |
Silverberg/Mansour/Daws/Hopson 7 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 6 - Expires December 1998
| | publishing its schedule to the public. | | | publishing its schedule to the public. |
| | | | | |
| REQUEST | Used to schedule a calendar entry with other | | REQUEST | Used to schedule a calendar entry with other |
| | Calendar Users. Requests are interactive in that | | | Calendar Users. Requests are interactive in that |
| | they require the receiver to respond using | | | they require the receiver to respond using |
| | the the Reply methods. Meeting Requests, Busy | | | the Reply methods. Meeting Requests, Busy |
| | Time requests and the assignment of VTODOs to | | | Time requests and the assignment of VTODOs to |
| | other Calendar Users are all examples. | | | other Calendar Users are all examples. |
| | Requests are also used by the "Organizer" to | | | Requests are also used by the "Organizer" to |
| | update the status of a calendar entry. | | | update the status of a calendar entry. |
| | | | | |
| REPLY | A Reply is used in response to a Request to | | REPLY | A Reply is used in response to a Request to |
| | convey "Attendee" status to the "Organizer". | | | convey "Attendee" status to the "Organizer". |
| | Replies are commonly used to respond to meeting | | | Replies are commonly used to respond to meeting |
| | and task requests. | | | and task requests. |
| | | | | |
skipping to change at line 379 skipping to change at line 381
|================+==================================================| |================+==================================================|
| Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER |
| | | | | |
| Attendee | REPLY, REFRESH, COUNTER | | Attendee | REPLY, REFRESH, COUNTER |
| | REQUEST only when delegating | | | REQUEST only when delegating |
+================+==================================================+ +================+==================================================+
Note that for some calendar component types, the allowable methods are a Note that for some calendar component types, the allowable methods are a
subset of the above set. subset of the above set.
Silverberg/Mansour/Daws/Hopson 8 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 7 - Expires December 1998
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 sent above. The Transport Protocol defines how the iCalendar objects are sent
between the sender and receiver. This document focuses on the between the sender and receiver. This document focuses on the
Application Protocol. Binding documents such as [iMIP] focus on the Application Protocol. Binding documents such as [iMIP] focus on the
Transport Protocol. Transport Protocol.
skipping to change at line 429 skipping to change at line 432
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 or "Organizer". The "Organizer" interacts with other CUs by sending one or
more of the iTIP messages listed above. "Attendees" use the "REPLY" more of the iTIP messages listed above. "Attendees" use the "REPLY"
method to communicate their status. "Attendees" do not make direct method to communicate their status. "Attendees" do not make direct
changes to the master calendar entry. They can, however, use the changes to the master calendar entry. They can, however, use the
"COUNTER" method to suggest changes to the "Organizer". In any case, the "COUNTER" method to suggest changes to the "Organizer". In any case, the
"Organizer" has complete control over the master calendar entry. "Organizer" has complete control over the master calendar entry.
Silverberg/Mansour/Daws/Hopson 9 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 8 - Expires December 1998
2.1.1 Calendar Entry State 2.1.1 Calendar Entry State
There are two distinct states relevant to calendar entries: the overall There are two distinct states relevant to calendar entries: the overall
state of the entry and the state associated with an "Attendee" to that state of the entry and the state associated with an "Attendee" to that
entry. entry.
The state of an entry is defined by the "STATUS" property and is The state of an entry is defined by the "STATUS" property and is
controlled by the "Organizer." There is no default value for the controlled by the "Organizer." There is no default value for the
"STATUS" property. The "Organizer" sets the "STATUS" property to the "STATUS" property. The "Organizer" sets the "STATUS" property to the
appropriate value for each calendar entry. appropriate value for each calendar entry.
skipping to change at line 484 skipping to change at line 488
or "Attendee" properties. When specified, the "sent-by" parameter or "Attendee" properties. When specified, the "sent-by" parameter
indicates that the responding CU acted on behalf of the specified indicates that the responding CU acted on behalf of the specified
"Attendee" or "Organizer". "Attendee" or "Organizer".
2.1.4 Component Revisions 2.1.4 Component Revisions
The "SEQUENCE" property is used by the "Organizer" to indicate revisions The "SEQUENCE" property is used by the "Organizer" to indicate revisions
to the calendar component. The rules for incrementing the "SEQUENCE" to the calendar component. The rules for incrementing the "SEQUENCE"
number are defined in [iCAL]. For clarity, these rules are paraphrased number are defined in [iCAL]. For clarity, these rules are paraphrased
Silverberg/Mansour/Daws/Hopson 10 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 9 - Expires December 1998
here in terms of how they are applied in [iTIP]. For a given "UID" in a here in terms of how they are applied in [iTIP]. For a given "UID" in a
calendar component: calendar component:
. For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property . For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
value is incremented according to the rules defined in [iCAL]. value is incremented according to the rules defined in [iCAL].
. The "SEQUENCE" property value MUST be incremented each time the . The "SEQUENCE" property value MUST be incremented each time the
"Organizer" uses the "ADD" or "CANCEL" methods. "Organizer" uses the "ADD" or "CANCEL" methods.
. The "SEQUENCE" property value MUST NOT be incremented when using . The "SEQUENCE" property value MUST NOT be incremented when using
skipping to change at line 538 skipping to change at line 543
2. The secondary key for referencing a component is the "SEQUENCE" 2. The secondary key for referencing a component is the "SEQUENCE"
property value. For components where the "UID" is the same, the property value. For components where the "UID" is the same, the
component with the highest numeric value for the "SEQUENCE" property component with the highest numeric value for the "SEQUENCE" property
obsoletes all other revisions of the component with lower values. obsoletes all other revisions of the component with lower values.
3. "Attendees" send "REPLY" messages to the "Organizer". For replies 3. "Attendees" send "REPLY" messages to the "Organizer". For replies
where the "UID" property value is the same, the value of the where the "UID" property value is the same, the value of the
"SEQUENCE" property indicates the revision of the component to which "SEQUENCE" property indicates the revision of the component to which
Silverberg/Mansour/Daws/Hopson 11 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 10 - Expires December 1998
the "Attendee" is replying. The reply with the highest numeric value the "Attendee" is replying. The reply with the highest numeric value
for the "SEQUENCE" property obsoletes all other replies with lower for the "SEQUENCE" property obsoletes all other replies with lower
values. values.
4. In situations where the "UID" and "SEQUENCE" properties match, the 4. In situations where the "UID" and "SEQUENCE" properties match, the
"DTSTAMP" property is used as the tie-breaker. The component with the "DTSTAMP" property is used as the tie-breaker. The component with the
latest "DTSTAMP" overrides all others. Similarly, for "Attendee" latest "DTSTAMP" overrides all others. Similarly, for "Attendee"
responses where the "UID" property values match and the "SEQUENCE" responses where the "UID" property values match and the "SEQUENCE"
property values match, the response with the latest "DTSTAMP" property values match, the response with the latest "DTSTAMP"
overrides all others. overrides all others.
skipping to change at line 589 skipping to change at line 594
properties. Some components and properties are required, some are properties. Some components and properties are required, some are
optional and others are excluded. The restrictions are expressed in this optional and others are excluded. The restrictions are expressed in this
document using a simple "restriction table". The first column indicates document using a simple "restriction table". The first column indicates
the name of a component or property. Properties of the iCalendar object the name of a component or property. Properties of the iCalendar object
are not indented. Properties of a component are indented. The second are not indented. Properties of a component are indented. The second
column contains "MUST" if the component or property must be present, column contains "MUST" if the component or property must be present,
"MAY" if the component or property is optional, and "NOT" if the "MAY" if the component or property is optional, and "NOT" if the
component or property must not be present. Entries in the second column component or property must not be present. Entries in the second column
sometimes contain comments for further clarification. sometimes contain comments for further clarification.
Silverberg/Mansour/Daws/Hopson 12 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 11 - Expires December 1998
3.1 Common Component Restriction Tables 3.1 Common Component Restriction Tables
The restriction table below applies to properties of the iCalendar The restriction table below applies to properties of the iCalendar
object. That is, the properties at the outermost scope. The presence object. That is, the properties at the outermost scope. The presence
column uses the following values to assert whether a property is column uses the following values to assert whether a property is
required, is optional and the number of times it may appear in the required, is optional and the number of times it may appear in the
iCalendar object. iCalendar object.
Presence Value Description Presence Value Description
-------------------------------------------------------------- --------------------------------------------------------------
skipping to change at line 643 skipping to change at line 649
TZNAME 0 or 1 TZNAME 0 or 1
TZOFFSET 1 TZOFFSET 1
TZOFFSETFROM 1 TZOFFSETFROM 1
TZOFFSETTO 1 TZOFFSETTO 1
X-PROPERTY 0+ X-PROPERTY 0+
LAST-MODIFIED 0 or 1 LAST-MODIFIED 0 or 1
STANDARD 0+ MUST be one or more of either STANDARD or STANDARD 0+ MUST be one or more of either STANDARD or
DAYLIGHT DAYLIGHT
COMMENT 0 or 1 COMMENT 0 or 1
Silverberg/Mansour/Daws/Hopson 13 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 12 - Expires December 1998
DTSTART 1 MUST be local time format DTSTART 1 MUST be local time format
RDATE 0+ if present RRULE MUST NOT be present RDATE 0+ if present RRULE MUST NOT be present
RRULE 0+ if present RDATE MUST NOT be present RRULE 0+ if present RDATE MUST NOT be present
TZNAME 0 or 1 TZNAME 0 or 1
TZOFFSETFROM 1 TZOFFSETFROM 1
TZOFFSETTO 1 TZOFFSETTO 1
X-PROPERTY 0+ X-PROPERTY 0+
TZID 1 TZID 1
TZURL 0 or 1 TZURL 0 or 1
X-PROPERTY 0+ X-PROPERTY 0+
skipping to change at line 697 skipping to change at line 703
| REQUEST | Make a request for an event. This is an explicit | | REQUEST | Make a request for an event. This is an explicit |
| | invitation to one or more "Attendees". Event | | | invitation to one or more "Attendees". Event |
| | Requests are also used to update or change an | | | Requests are also used to update or change an |
| | existing event. Clients that cannot handle | | | existing event. Clients that cannot handle |
| | REQUEST may degrade the event to view it as an | | | REQUEST may degrade the event to view it as an |
| | PUBLISH. | | | PUBLISH. |
| | | | | |
| REPLY | Reply to an event request. Clients may set their | | REPLY | Reply to an event request. Clients may set their |
| | status ("partstat") to ACCEPTED, DECLINED, | | | status ("partstat") to ACCEPTED, DECLINED, |
Silverberg/Mansour/Daws/Hopson 14 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 13 - Expires December 1998
| | TENTATIVE, or DELEGATED. | | | TENTATIVE, or DELEGATED. |
| | | | | |
| ADD | Add one or more instances to an existing event. | | ADD | Add one or more instances to an existing event. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | event. | | | event. |
| | | | | |
| REFRESH | A request is sent to an "Organizer" by an | | REFRESH | A request is sent to an "Organizer" by an |
| | "Attendee" asking for the latest version of an | | | "Attendee" asking for the latest version of an |
| | event to be resent to the requester. | | | event to be resent to the requester. |
skipping to change at line 752 skipping to change at line 759
SEQUENCE 0 or 1 MUST be present if value is greater than 0, SEQUENCE 0 or 1 MUST be present if value is greater than 0,
MAY be present if 0 MAY be present if 0
ATTACH 0+ ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1 CLASS 0 or 1
COMMENT 0 or 1 COMMENT 0 or 1
CONTACT 0+ CONTACT 0+
CREATED 0 or 1 CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null DESCRIPTION 0 or 1 Can be null
Silverberg/Mansour/Daws/Hopson 15 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 14 - Expires December 1998
DTEND 0 or 1 if present DURATION MUST NOT be present DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+ EXDATE 0+
EXRULE 0+ EXRULE 0+
GEO 0 or 1 GEO 0 or 1
LAST-MODIFIED 0 or 1 LAST-MODIFIED 0 or 1
LOCATION 0 or 1 LOCATION 0 or 1
PRIORITY 0 or 1 PRIORITY 0 or 1
RDATE 0+ RDATE 0+
RELATED-TO 0+ RELATED-TO 0+
skipping to change at line 807 skipping to change at line 814
"Organizer" to another CU. "Organizer" to another CU.
The "Organizer" originates the "REQUEST". The recipients of the The "Organizer" originates the "REQUEST". The recipients of the
"REQUEST" method are the CUs invited to the event, the "Attendees". "REQUEST" method are the CUs invited to the event, the "Attendees".
"Attendees" use the "REPLY" method to convey attendance status to the "Attendees" use the "REPLY" method to convey attendance status to the
"Organizer". "Organizer".
The "UID" and "SEQUENCE" properties are used to distinguish the various The "UID" and "SEQUENCE" properties are used to distinguish the various
uses of the "REQUEST" method. If the "UID" property value in the uses of the "REQUEST" method. If the "UID" property value in the
Silverberg/Mansour/Daws/Hopson 16 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 15 - Expires December 1998
"REQUEST" is not found on the recipient's calendar, then the "REQUEST" "REQUEST" is not found on the recipient's calendar, then the "REQUEST"
is for a new "VEVENT" calendar component. If the "UID" property value is is for a new "VEVENT" calendar component. If the "UID" property value is
found on the recipient's calendar, then the "REQUEST" is for a found on the recipient's calendar, then the "REQUEST" is for a
rescheduling, an update, or a reconfirm of the "VEVENT" calendar rescheduling, an update, or a reconfirm of the "VEVENT" calendar
component. component.
For the "REQUEST" method, multiple "VEVENT" components in a single For the "REQUEST" method, multiple "VEVENT" components in a single
iCalendar object are only permitted when for components with the same iCalendar object are only permitted when for components with the same
"UID" property. That is, a series of recurring events may have "UID" property. That is, a series of recurring events may have
instance-specific information. In this case, multiple "VEVENT" instance-specific information. In this case, multiple "VEVENT"
skipping to change at line 863 skipping to change at line 871
recurring calendar component. Otherwise it recurring calendar component. Otherwise it
MUST NOT be present. MUST NOT be present.
RELATED-TO 0+ RELATED-TO 0+
REQUEST-STATUS 0+ REQUEST-STATUS 0+
RESOURCES 0 or 1 This property MAY contain a list of values RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+ RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED
TRANSP 0 or 1 TRANSP 0 or 1
URL 0 or 1 URL 0 or 1
Silverberg/Mansour/Daws/Hopson 17 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 16 - Expires December 1998
X-PROPERTY 0+ X-PROPERTY 0+
VALARM 0+ VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers to VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone a timezone
X-COMPONENT 0+ X-COMPONENT 0+
VFREEBUSY 0 VFREEBUSY 0
VJOURNAL 0 VJOURNAL 0
VTODO 0 VTODO 0
skipping to change at line 916 skipping to change at line 924
Some calendar and scheduling systems allow "Attendees" to delegate their Some calendar and scheduling systems allow "Attendees" to delegate their
presence at an event to another calendar user. ITIP supports this presence at an event to another calendar user. ITIP supports this
concept using the following workflow. Any "Attendee" may delegate their concept using the following workflow. Any "Attendee" may delegate their
right to participate in a calendar VEVENT to another CU. The implication right to participate in a calendar VEVENT to another CU. The implication
is that the delegate participates in lieu of the original "Attendee"; is that the delegate participates in lieu of the original "Attendee";
NOT in addition to the "Attendee". The delegator MUST notify the NOT in addition to the "Attendee". The delegator MUST notify the
"Organizer" of this action using the steps outlined below. "Organizer" of this action using the steps outlined below.
Implementations may support or restrict delegation as they see fit. For Implementations may support or restrict delegation as they see fit. For
Silverberg/Mansour/Daws/Hopson 18 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 17 - Expires December 1998
instance, some implementations may restrict a delegate from delegating a instance, some implementations may restrict a delegate from delegating a
"REQUEST" to another CU. "REQUEST" to another CU.
The "Delegator" of an event forwards the existing "REQUEST" to the The "Delegator" of an event forwards the existing "REQUEST" to the
"Delegate". The "REQUEST" method MUST include an "ATTENDEE" property "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
with the calendar address of the "Delegate". The "Delegator" MUST also with the calendar address of the "Delegate". The "Delegator" MUST also
send a "REPLY" method to the "Organizer" with the "Delegator's" send a "REPLY" method to the "Organizer" with the "Delegator's"
"ATTENDEE" property "partstat" parameter value set to "delegated". In "ATTENDEE" property "partstat" parameter value set to "delegated". In
addition, the "delegated-to" parameter MUST be included with the addition, the "delegated-to" parameter MUST be included with the
calendar address of the "Delegate". calendar address of the "Delegate".
In response to the request, the "Delegate" MUST send a "REPLY" method to In response to the request, the "Delegate" MUST send a "REPLY" method to
the "Organizer" and optionally, to the "Delegator". The "REPLY" method " the "Organizer" and optionally, to the "Delegator". The "REPLY" method "
SHOULD include the "ATTENDEE" property with the "delegated-from" SHOULD include the "ATTENDEE" property with the "delegated-from"
parameter value of the "Delegator's" calendar address. parameter value of the "Delegator's" calendar address.
The "Delegator" may continue to receive updates to the event even though The "Delegator" may continue to receive updates to the event even though
they will not be attending. This is accomplished by When the "Delegator" they will not be attending. This is accomplished by the "Delegator"
sends "REPLY" to the "Organizer" setting their "role" attribute to " NON-PARTICIPANT" in the "REPLY" to
the "Organizer"
3.2.2.4 Changing the Organizer 3.2.2.4 Changing the Organizer
The situation may arise where the "Organizer" of a VEVENT is no longer The situation may arise where the "Organizer" of a VEVENT is no longer
able to perform the "Organizer" role and abdicates without passing on able to perform the "Organizer" role and abdicates without passing on
the "Organizer" role to someone else. When this occurs the "Attendees" the "Organizer" role to someone else. When this occurs the "Attendees"
of the VEVENT may use out-of-band mechanisms to communicate the of the VEVENT may use out-of-band mechanisms to communicate the
situation and agree upon a new "Organizer". The new "Organizer" should situation and agree upon a new "Organizer". The new "Organizer" should
then send out a new "REQUEST" with a modified version of the VEVENT in then send out a new "REQUEST" with a modified version of the VEVENT in
which the "SEQUENCE" number has been incremented and value of the which the "SEQUENCE" number has been incremented and value of the
skipping to change at line 967 skipping to change at line 977
REQUEST. In the case where one CU sends on behalf of another CU, the REQUEST. In the case where one CU sends on behalf of another CU, the
"Attendee" responses are still directed back towards the CU designated "Attendee" responses are still directed back towards the CU designated
as "Organizer". as "Organizer".
3.2.2.6 Forwarding to An Uninvited CU 3.2.2.6 Forwarding to An Uninvited CU
An "Attendee" invited to an event may invite another uninvited CU to the An "Attendee" invited to an event may invite another uninvited CU to the
event. The invited "Attendee" accomplishes this by forwarding the event. The invited "Attendee" accomplishes this by forwarding the
original "REQUEST" method to the uninvited CU. The "Organizer" decides original "REQUEST" method to the uninvited CU. The "Organizer" decides
whether or not the uninvited CU is added to the attendee list. If the whether or not the uninvited CU is added to the attendee list. If the
"Organizer" decides not to add the uninvited CU no further action is
Silverberg/Mansour/Daws/Hopson 19 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 18 - Expires December 1998
"Organizer" decides not to add the uninvited CU no further action is
required, however the "Organizer" MAY send the uninvited CU a "CANCEL" required, however the "Organizer" MAY send the uninvited CU a "CANCEL"
message. If the "Organizer" decides to add uninvited CU, a new message. If the "Organizer" decides to add an uninvited CU, a new
"ATTENDEE" property is added for the uninvited CU with its property "ATTENDEE" property is added for the uninvited CU with its property
parameters set as the "Organizer" deems appropriate. When forwarding a parameters set as the "Organizer" deems appropriate. When forwarding a
"REQUEST" to another CU, the forwarding "Attendee" MUST NOT make changes "REQUEST" to another CU, the forwarding "Attendee" MUST NOT make changes
to the VEVENT property set. to the VEVENT property set.
3.2.2.7 Updating Attendee Status 3.2.2.7 Updating Attendee Status
The "Organizer" of an event may also request updated status from one or The "Organizer" of an event may also request updated status from one or
more "Attendees. The "Organizer" sends a "REQUEST" method to the more "Attendees. The "Organizer" sends a "REQUEST" method to the
"Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
skipping to change at line 1020 skipping to change at line 1031
An "Attendee" can include a message to the "Organizer" using the An "Attendee" can include a message to the "Organizer" using the
"COMMENT" property. For example, if the user indicates tentative "COMMENT" property. For example, if the user indicates tentative
acceptance and wants to let the "Organizer" know why, the reason can be acceptance and wants to let the "Organizer" know why, the reason can be
expressed in the "COMMENT" property value. expressed in the "COMMENT" property value.
The "Organizer" may also receive a "REPLY" from one CU on behalf of The "Organizer" may also receive a "REPLY" from one CU on behalf of
another. Like the scenario enumerated above for the "Organizer", another. Like the scenario enumerated above for the "Organizer",
"Attendees" may have another CU respond on their behalf. This is done "Attendees" may have another CU respond on their behalf. This is done
using the "sent-by" parameter. using the "sent-by" parameter.
Silverberg/Mansour/Daws/Hopson 20 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 19 - Expires December 1998
The optional properties listed in the table below (those listed as "0+" The optional properties listed in the table below (those listed as "0+"
or "0 or 1") MUST NOT be changed from those of the original request. If or "0 or 1") MUST NOT be changed from those of the original request. If
property changes are desired the COUNTER message must be used. property changes are desired the COUNTER message must be used.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
METHOD 1 MUST be "REPLY" METHOD 1 MUST be "REPLY"
skipping to change at line 1076 skipping to change at line 1088
RRULE 0+ RRULE 0+
STATUS 0 or 1 STATUS 0 or 1
SUMMARY 0 or 1 SUMMARY 0 or 1
TRANSP 0 or 1 TRANSP 0 or 1
URL 0 or 1 URL 0 or 1
X-PROPERTY 0+ X-PROPERTY 0+
VTIMEZONE 0 or 1 MUST be present if any date/time refers to a VTIMEZONE 0 or 1 MUST be present if any date/time refers to a
timezone timezone
Silverberg/Mansour/Daws/Hopson 21 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 20 - Expires December 1998
X-COMPONENT 0+ X-COMPONENT 0+
VALARM 0 VALARM 0
VFREEBUSY 0 VFREEBUSY 0
VJOURNAL 0 VJOURNAL 0
VTODO 0 VTODO 0
3.2.4 ADD 3.2.4 ADD
The "ADD" method in a "VEVENT" calendar component is used to add one or The "ADD" method in a "VEVENT" calendar component is used to add one or
skipping to change at line 1131 skipping to change at line 1144
CATEGORIES 0 or 1 This property MAY contain a list of values CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1 CLASS 0 or 1
COMMENT 0 or 1 COMMENT 0 or 1
CONTACT 0+ CONTACT 0+
CREATED 0 or 1 CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null DESCRIPTION 0 or 1 Can be null
DTEND 0 or 1 if present DURATION MUST NOT be present DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+ EXDATE 0+
Silverberg/Mansour/Daws/Hopson 22 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 21 - Expires December 1998
EXRULE 0+ EXRULE 0+
GEO 0 or 1 GEO 0 or 1
LAST-MODIFIED 0 or 1 LAST-MODIFIED 0 or 1
LOCATION 0 or 1 LOCATION 0 or 1
PRIORITY 0 or 1 PRIORITY 0 or 1
RDATE 0+ RDATE 0+
RELATED-TO 0+ RELATED-TO 0+
RESOURCES 0 or 1 This property MAY contain a list of values RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+ RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED
skipping to change at line 1185 skipping to change at line 1198
(or THISANDFUTURE) to indicate cancellation of the specified (or THISANDFUTURE) to indicate cancellation of the specified
"VEVENT" calendar component and all instances before (or after); or "VEVENT" calendar component and all instances before (or after); or
(b) individual recurrence instances may be cancelled by specifying (b) individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the instances to multiple "RECURRENCE-ID" properties corresponding to the instances to
be cancelled. 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.
Silverberg/Mansour/Daws/Hopson 23 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 22 - Expires December 1998
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
METHOD 1 MUST be "CANCEL" METHOD 1 MUST be "CANCEL"
VEVENT 1+ All must have the same UID VEVENT 1+ All must have the same UID
ATTENDEE 0+ MUST include all "Attendees" being removed ATTENDEE 0+ MUST include all "Attendees" being removed
the event. MUST include all "Attendees" if the event. MUST include all "Attendees" if
skipping to change at line 1241 skipping to change at line 1255
X-PROPERTY 0+ X-PROPERTY 0+
REQUEST-STATUS 0 REQUEST-STATUS 0
VTIMEZONE 0+ MUST be present if any date/time refers to VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone a timezone
X-COMPONENT 0+ X-COMPONENT 0+
VTODO 0 VTODO 0
VJOURNAL 0 VJOURNAL 0
Silverberg/Mansour/Daws/Hopson 24 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 23 - Expires December 1998
VFREEBUSY 0 VFREEBUSY 0
VALARM 0 VALARM 0
3.2.6 REFRESH 3.2.6 REFRESH
The "REFRESH" method in a "VEVENT" calendar component is used by The "REFRESH" method in a "VEVENT" calendar component is used by
"Attendees" of an existing event to request an updated description from "Attendees" of an existing event to request an updated description from
the event "Organizer". The "REFRESH" method must specify the "UID" the event "Organizer". The "REFRESH" method must specify the "UID"
property of the event to update. A recurrence instance of an event may property of the event to update. A recurrence instance of an event may
be requested by specifying the "RECURRENCE-ID" property corresponding to be requested by specifying the "RECURRENCE-ID" property corresponding to
skipping to change at line 1296 skipping to change at line 1311
LAST-MODIFIED 0 LAST-MODIFIED 0
LOCATION 0 LOCATION 0
PRIORITY 0 PRIORITY 0
RDATE 0 RDATE 0
RELATED-TO 0 RELATED-TO 0
REQUEST-STATUS 0 REQUEST-STATUS 0
RESOURCES 0 RESOURCES 0
RRULE 0 RRULE 0
SEQUENCE 0 SEQUENCE 0
Silverberg/Mansour/Daws/Hopson 25 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 24 - Expires December 1998
STATUS 0 STATUS 0
SUMMARY 0 SUMMARY 0
TRANSP 0 TRANSP 0
URL 0 URL 0
X-COMPONENT 0+ X-COMPONENT 0+
VTODO 0 VTODO 0
VJOURNAL 0 VJOURNAL 0
VFREEBUSY 0 VFREEBUSY 0
skipping to change at line 1351 skipping to change at line 1366
UID 1 MUST be the UID associated with the REQUEST UID 1 MUST be the UID associated with the REQUEST
being countered being countered
ATTACH 0+ ATTACH 0+
ATTENDEE 0+ Can also be used to propose other ATTENDEE 0+ Can also be used to propose other
"Attendees" "Attendees"
CATEGORIES 0 or 1 This property may contain a list of values CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1 CLASS 0 or 1
COMMENT 0 or 1 COMMENT 0 or 1
Silverberg/Mansour/Daws/Hopson 26 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 25 - Expires December 1998
CONTACT 0+ CONTACT 0+
CREATED 0 or 1 CREATED 0 or 1
DESCRIPTION 0 or 1 DESCRIPTION 0 or 1
DTEND 0 or 1 if present DURATION MUST NOT be present DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+ EXDATE 0+
EXRULE 0+ EXRULE 0+
GEO 0 or 1 GEO 0 or 1
LAST-MODIFIED 0 or 1 LAST-MODIFIED 0 or 1
LOCATION 0 or 1 LOCATION 0 or 1
skipping to change at line 1406 skipping to change at line 1421
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
METHOD 1 MUST be "DECLINECOUNTER" METHOD 1 MUST be "DECLINECOUNTER"
VEVENT 1 VEVENT 1
DTSTAMP 1 DTSTAMP 1
ORGANIZER 1 ORGANIZER 1
UID 1 MUST, same UID specified in original UID 1 MUST, same UID specified in original
REQUEST and subsequent COUNTER REQUEST and subsequent COUNTER
Silverberg/Mansour/Daws/Hopson 27 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 26 - Expires December 1998
COMMENT 0 or 1 COMMENT 0 or 1
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise it recurring calendar component. Otherwise it
MUST NOT be present. MUST NOT be present.
REQUEST-STATUS 0+ REQUEST-STATUS 0+
SEQUENCE 0 OR 1 MUST be present if value is greater than 0, SEQUENCE 0 OR 1 MUST be present if value is greater than 0,
MAY be present if 0 MAY be present if 0
X-PROPERTY 0+ X-PROPERTY 0+
ATTACH 0 ATTACH 0
skipping to change at line 1458 skipping to change at line 1473
3.3 Methods For VFREEBUSY Components 3.3 Methods For VFREEBUSY Components
This section defines the property set for the methods that are This section defines the property set for the methods that are
applicable to the "VFREEBUSY" calendar component. Each of the methods is applicable to the "VFREEBUSY" calendar component. Each of the methods is
defined using a restriction table. defined using a restriction table.
This document only addresses the transfer of busy time information. This document only addresses the transfer of busy time information.
Applications desiring free time information MUST infer this from Applications desiring free time information MUST infer this from
available busy time information. available busy time information.
Silverberg/Mansour/Daws/Hopson 28 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 27 - Expires December 1998
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, each periodicity, such as a calendar week, month, or year. In this case, each
"VFREEBUSY" calendar component MUST include the "ATTENDEE", "DTSTART" "VFREEBUSY" calendar component MUST include the "ATTENDEE", "DTSTART"
and "DTEND" properties in order to specify the source of the busy time 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. information covers.
The "FREEBUSY" property value MAY include a list of values, separated by The "FREEBUSY" property value MAY include a list of values, separated by
skipping to change at line 1512 skipping to change at line 1528
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 other. 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 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 information. The "ATTENDEE" property must be specified in the busy time information.
The value is the CU address of the originator of the busy time The value is the CU address of the originator of the busy time
information. information.
Silverberg/Mansour/Daws/Hopson 29 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 28 - Expires December 1998
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
METHOD 1 MUST be "PUBLISH" METHOD 1 MUST be "PUBLISH"
VFREEBUSY 1+ VFREEBUSY 1+
DTSTAMP 1 DTSTAMP 1
DTSTART 1 DateTime values must be in UTC DTSTART 1 DateTime values must be in UTC
skipping to change at line 1567 skipping to change at line 1584
information to one or more intended recipients. information to one or more intended recipients.
If the originator of the "REQUEST" method is not authorized to make a If the originator of the "REQUEST" method is not authorized to make a
busy time request on the recipient's calendar system, then an exception busy time request on the recipient's calendar system, then an exception
message SHOULD be returned in a "REPLY" method, but no busy time data message SHOULD be returned in a "REPLY" method, but no busy time data
need be returned. need be returned.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Silverberg/Mansour/Daws/Hopson 30 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 29 - Expires December 1998
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
METHOD 1 MUST be "REQUEST" METHOD 1 MUST be "REQUEST"
VFREEBUSY 1 VFREEBUSY 1
ATTENDEE 1+ contain the address of the calendar store ATTENDEE 1+ contain the address of the calendar store
for which busy time is being requested. for which busy time is being requested.
DTEND 1 DateTime values must be in UTC DTEND 1 DateTime values must be in UTC
DTSTAMP 1 DTSTAMP 1
DTSTART 1 DateTime values must be in UTC DTSTART 1 DateTime values must be in UTC
skipping to change at line 1620 skipping to change at line 1638
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
METHOD 1 MUST be "REPLY" METHOD 1 MUST be "REPLY"
VFREEBUSY 1 VFREEBUSY 1
ATTENDEE 1 (address of recipient replying) ATTENDEE 1 (address of recipient replying)
DTSTAMP 1 DTSTAMP 1
DTEND 1 DateTime values must be in UTC DTEND 1 DateTime values must be in UTC
DTSTART 1 DateTime values must be in UTC DTSTART 1 DateTime values must be in UTC
FREEBUSY 1+ (values MUST all be of the same data FREEBUSY 1+ (values MUST all be of the same data
Silverberg/Mansour/Daws/Hopson 31 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 30 - Expires December 1998
type. Multiple instances are allowed. type. Multiple instances are allowed.
Multiple instances MUST be sorted in Multiple instances MUST be sorted in
ascending order. Values MAY NOT overlap) ascending order. Values MAY NOT overlap)
ORGANIZER 1 MUST be the request originator's address ORGANIZER 1 MUST be the request originator's address
UID 1 UID 1
COMMENT 0 or 1 COMMENT 0 or 1
CONTACT 0+ CONTACT 0+
REQUEST-STATUS 0+ REQUEST-STATUS 0+
URL 0 or 1 (specifies busy time URL) URL 0 or 1 (specifies busy time URL)
skipping to change at line 1674 skipping to change at line 1692
| REPLY | Reply to a VTODO request. Attendees MAY set | | REPLY | Reply to a VTODO request. Attendees MAY set |
| | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, |
| | DELEGATED, PARTIAL, and COMPLETED. | | | DELEGATED, PARTIAL, and COMPLETED. |
| | | | | |
| ADD | Add one or more instances to an existing to-do. | | ADD | Add one or more instances to an existing to-do. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | to-do. | | | to-do. |
| | | | | |
Silverberg/Mansour/Daws/Hopson 32 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 31 - Expires December 1998
| REFRESH | A request sent to a VTODO Organizer asking for | | REFRESH | A request sent to a VTODO Organizer asking for |
| | the latest version of a VTODO. | | | the latest version of a VTODO. |
| | | | | |
| COUNTER | Counter a REQUEST with an alternative proposal. | | COUNTER | Counter a REQUEST with an alternative proposal. |
| | | | | |
| DECLINECOUNTER | Decline a counter proposal by an Attendee. | | DECLINECOUNTER | Decline a counter proposal by an Attendee. |
+================+==================================================+ +================+==================================================+
3.4.1 PUBLISH 3.4.1 PUBLISH
The "PUBLISH" method in a "VTODO" calendar component has no associated The "PUBLISH" method in a "VTODO" calendar component has no associated
response. It is simply a posting of an iCalendar object that maybe added response. It is simply a posting of an iCalendar object that maybe added
to a calendar. It MUST have an "Organizer". It MUST NOT have to a calendar. It MUST have an "Organizer". It MUST NOT have
"Attendees". Its expected usage is for encapsulating an arbitrary "Attendees". Its expected usage is for encapsulating an arbitrary
"VTODO" calendar component as an iCalendar object. The "Organizer" MAY "VTODO" calendar component as an iCalendar object. The "Organizer" MAY
subsequently update (with another "PUBLISH" method), add instances to subsequently update (with another "PUBLISH" method), add instances to
(win an "ADD" method), or cancel (with a "CANCEL" method) a previously (with an "ADD" method), or cancel (with a "CANCEL" method) a previously
published "VTODO" calendar component. published "VTODO" calendar component.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
METHOD 1 MUST be "PUBLISH" METHOD 1 MUST be "PUBLISH"
VTODO 1+ VTODO 1+
DTSTAMP 1 DTSTAMP 1
skipping to change at line 1728 skipping to change at line 1747
DURATION 0 or 1 If present DUE MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+ EXDATE 0+
EXRULE 0+ EXRULE 0+
GEO 0 or 1 GEO 0 or 1
LAST-MODIFIED 0 or 1 LAST-MODIFIED 0 or 1
LOCATION 0 or 1 LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1 PERCENT-COMPLETE 0 or 1
RDATE 0+ RDATE 0+
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
Silverberg/Mansour/Daws/Hopson 33 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 32 - Expires December 1998
recurring calendar component. Otherwise recurring calendar component. Otherwise
it MUST NOT be present. it MUST NOT be present.
RELATED-TO 0+ RELATED-TO 0+
RESOURCES 0 or 1 This property may contain a list of values RESOURCES 0 or 1 This property may contain a list of values
RRULE 0+ RRULE 0+
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
PROCESS/CANCELLED PROCESS/CANCELLED
URL 0 or 1 URL 0 or 1
X-PROPERTY 0+ X-PROPERTY 0+
skipping to change at line 1781 skipping to change at line 1800
"Attendee" uses the "REPLY" method to convey their acceptance and "Attendee" uses the "REPLY" method to convey their acceptance and
completion status to the "Organizer" of the "REQUEST". completion status to the "Organizer" of the "REQUEST".
The "UID", "SEQUENCE", and "DTSTAMP" properties are used to distinguish The "UID", "SEQUENCE", and "DTSTAMP" properties are used to distinguish
the various uses of the "REQUEST" method. If the "UID" property value in the various uses of the "REQUEST" method. If the "UID" property value in
the "REQUEST" is not found on the recipient's calendar, then the the "REQUEST" is not found on the recipient's calendar, then the
"REQUEST" is for a new to-do. If the "UID" property value is found on "REQUEST" is for a new to-do. If the "UID" property value is found on
the recipient's calendar, then the "REQUEST" is a rescheduling, an the recipient's calendar, then the "REQUEST" is a rescheduling, an
update, or a reconfirm of the "VTODO" calendar object. update, or a reconfirm of the "VTODO" calendar object.
Silverberg/Mansour/Daws/Hopson 34 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 33 - Expires December 1998
If the "Organizer" of the "REQUEST" method is not authorized to make a If the "Organizer" of the "REQUEST" method is not authorized to make a
to-do request on the "Attendee's" calendar system, then an exception is to-do request on the "Attendee's" calendar system, then an exception is
returned in the "REQUEST-STATUS" property of a subsequent "REPLY" returned in the "REQUEST-STATUS" property of a subsequent "REPLY"
method, but no scheduling action is performed. method, but no scheduling action is performed.
For the "REQUEST" method, multiple "VTODO" components in a single For the "REQUEST" method, multiple "VTODO" components in a single
iCalendar object are only permitted when for components with the same iCalendar object are only permitted when for components with the same
"UID" property. That is, a series of recurring events may have "UID" property. That is, a series of recurring events may have
instance-specific information. In this case, multiple "VTODO" instance-specific information. In this case, multiple "VTODO"
components are needed to express the entire series. components are needed to express the entire series.
skipping to change at line 1836 skipping to change at line 1856
RDATE 0+ RDATE 0+
RECURRENCE-ID 0 or 1 present if referring to an instance of a RECURRENCE-ID 0 or 1 present if referring to an instance of a
recurring calendar component. Otherwise recurring calendar component. Otherwise
it MUST NOT be present. it MUST NOT be present.
RELATED-TO 0+ RELATED-TO 0+
RESOURCES 0 or 1 This property may contain a list of RESOURCES 0 or 1 This property may contain a list of
values values
RRULE 0+ RRULE 0+
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
Silverberg/Mansour/Daws/Hopson 35 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 34 - Expires December 1998
PROCESS PROCESS
URL 0 or 1 URL 0 or 1
X-PROPERTY 0+ X-PROPERTY 0+
REQUEST-STATUS 0 REQUEST-STATUS 0
VALARM 0+ VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers VTIMEZONE 0+ MUST be present if any date/time refers
to a timezone to a timezone
X-COMPONENT 0+ X-COMPONENT 0+
skipping to change at line 1890 skipping to change at line 1910
The update "REQUEST" is the appropriate response to a "REFRESH" method The update "REQUEST" is the appropriate response to a "REFRESH" method
sent from an "Attendee" to the "Organizer" of a "VTODO" calendar sent from an "Attendee" to the "Organizer" of a "VTODO" calendar
component. component.
Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a
"VTODO" calendar component. The unsolicited "REQUEST" methods are used "VTODO" calendar component. The unsolicited "REQUEST" methods are used
to update the details of the "VTODO" (without rescheduling it or to update the details of the "VTODO" (without rescheduling it or
updating the completion status of "Attendees") or the "VTODO" calendar updating the completion status of "Attendees") or the "VTODO" calendar
component itself (i.e., reconfirm the "VTODO"). component itself (i.e., reconfirm the "VTODO").
Silverberg/Mansour/Daws/Hopson 36 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 35 - Expires December 1998
3.4.2.3 REQUEST for Delegating a VTODO 3.4.2.3 REQUEST for Delegating a VTODO
The "REQUEST" method is also used to delegate or reassign ownership of a The "REQUEST" method is also used to delegate or reassign ownership of a
"VTODO" calendar component to another "Calendar User". For example, it "VTODO" calendar component to another "Calendar User". For example, it
may be used to delegate an "Attendee's" role (i.e. "chair", or may be used to delegate an "Attendee's" role (i.e. "chair", or
"participant") for a "VTODO" calendar component. The "REQUEST" method is "participant") for a "VTODO" calendar component. The "REQUEST" method is
sent by one of the "Attendees" of an existing "VTODO" calendar component sent by one of the "Attendees" of an existing "VTODO" calendar component
to some other individual. An "Attendee" of a "VTODO" calendar component to some other individual. An "Attendee" of a "VTODO" calendar component
MUST NOT delegate to the "Organizer" of the event. MUST NOT delegate to the "Organizer" of the event.
skipping to change at line 1945 skipping to change at line 1966
for the new CU. for the new CU.
The "Organizer" ultimately decides whether or not the new CU becomes The "Organizer" ultimately decides whether or not the new CU becomes
part of the to-do and is not obligated to do anything with a "REPLY" part of the to-do and is not obligated to do anything with a "REPLY"
from a new (uninvited) CU. If the "Organizer" does not want the new CU from a new (uninvited) CU. If the "Organizer" does not want the new CU
to be part of the to-do, the new "ATTENDEE" property is not added to the to be part of the to-do, the new "ATTENDEE" property is not added to the
"VTODO" calendar component. The "Organizer" MAY send the CU a "CANCEL" "VTODO" calendar component. The "Organizer" MAY send the CU a "CANCEL"
message to indicate that they will not be added to the to-do. If the message to indicate that they will not be added to the to-do. If the
"Organizer" decides to add the new CU, the new "ATTENDEE" property is "Organizer" decides to add the new CU, the new "ATTENDEE" property is
Silverberg/Mansour/Daws/Hopson 37 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 36 - Expires December 1998
added to the "VTODO" calendar component. Furthermore, the "Organizer" is added to the "VTODO" calendar component. Furthermore, the "Organizer" is
free to change any "ATTENDEE" property parameter from the values free to change any "ATTENDEE" property parameter from the values
supplied by the new CU to something the "Organizer" considers supplied by the new CU to something the "Organizer" considers
appropriate. appropriate.
3.4.2.5 REQUEST Updated Attendee Status 3.4.2.5 REQUEST Updated Attendee Status
An "Organizer" of a "VTODO" may request an updated status from one or An "Organizer" of a "VTODO" may request an updated status from one or
more "Attendees". The "Organizer" sends a "REQUEST" method to the more "Attendees". The "Organizer" sends a "REQUEST" method to the
"Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The
skipping to change at line 1998 skipping to change at line 2020
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- --------------------------------------------- ------------------- ---------------------------------------------
METHOD 1 MUST be "REPLY" METHOD 1 MUST be "REPLY"
VTODO 1+ All component MUST have the same UID VTODO 1+ All component MUST have the same UID
ATTENDEE 1+ ATTENDEE 1+
DTSTAMP 1 DTSTAMP 1
ORGANIZER 1 ORGANIZER 1
Silverberg/Mansour/Daws/Hopson 38 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 37 - Expires December 1998
REQUEST-STATUS 1+ REQUEST-STATUS 1+
UID 1 MUST must be the address of the replying UID 1 MUST must be the address of the replying
attendee attendee
ATTACH 0+ ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1 CLASS 0 or 1
COMMENT 0 or 1 COMMENT 0 or 1
CONTACT 0+ CONTACT 0+
CREATED 0 or 1 CREATED 0 or 1
skipping to change at line 2054 skipping to change at line 2076
The "ADD" method in a "VTODO" calendar component is used to add one or The "ADD" method in a "VTODO" calendar component is used to add one or
more instances to an existing to-do. more instances to an existing to-do.
If the "UID" property value in the "ADD" is not found on the recipient's If the "UID" property value in the "ADD" is not found on the recipient's
calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer"
in order to be updated with the latest version of the "VTODO". If an in order to be updated with the latest version of the "VTODO". If an
"Attendee" implementation does not support the "ADD" method it should "Attendee" implementation does not support the "ADD" method it should
respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH". respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH".
Silverberg/Mansour/Daws/Hopson 39 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 38 - Expires December 1998
The "SEQUENCE" property value is incremented as the sequence of to-dos The "SEQUENCE" property value is incremented as the sequence of to-dos
has changed. has changed.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- ---------------------------------------------- ------------------- ----------------------------------------------
METHOD 1 MUST be "ADD" METHOD 1 MUST be "ADD"
VTODO 1 VTODO 1
skipping to change at line 2110 skipping to change at line 2133
RECURRENCE-ID 0 RECURRENCE-ID 0
REQUEST-STATUS 0 REQUEST-STATUS 0
VALARM 0+ VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers VTIMEZONE 0+ MUST be present if any date/time refers
to a timezone to a timezone
X-COMPONENT 0+ X-COMPONENT 0+
VEVENT 0 VEVENT 0
Silverberg/Mansour/Daws/Hopson 40 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 39 - Expires December 1998
VJOURNAL 0 VJOURNAL 0
VFREEBUSY 0 VFREEBUSY 0
3.4.5 CANCEL 3.4.5 CANCEL
The "CANCEL" method in a "VTODO" calendar component is used to send a The "CANCEL" method in a "VTODO" calendar component is used to send a
cancellation notice of an existing "VTODO" calendar request to the cancellation notice of an existing "VTODO" calendar request to the
"Attendees". The message is sent by the "Organizer" of a "VTODO" "Attendees". The message is sent by the "Organizer" of a "VTODO"
calendar component to the "Attendees" of the "VTODO" calendar component. calendar component to the "Attendees" of the "VTODO" calendar component.
For a recurring "VTODO" calendar component, either the whole "VTODO" For a recurring "VTODO" calendar component, either the whole "VTODO"
skipping to change at line 2155 skipping to change at line 2179
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- --------------------------------------------- ------------------- ---------------------------------------------
METHOD 1 MUST be "CANCEL" METHOD 1 MUST be "CANCEL"
VTODO 1 VTODO 1
ATTENDEE 0+ include all "Attendees" being removed from ATTENDEE 0+ include all "Attendees" being removed from
the todo. MUST include all "Attendees" if the todo. MUST include all "Attendees" if
the entire todo is cancelled. the entire todo is cancelled.
UID 1 MUST must echo original UID UID 1 MUST echo original UID
DTSTAMP 1 DTSTAMP 1
ORGANIZER 1 ORGANIZER 1
SEQUENCE 1 SEQUENCE 1
ATTACH 0+ ATTACH 0+
CATEGORIES 0 or 1 This property MAY contain a list of values CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1 CLASS 0 or 1
COMMENT 0 or 1 COMMENT 0 or 1
Silverberg/Mansour/Daws/Hopson 41 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 40 - Expires December 1998
CONTACT 0+ CONTACT 0+
CREATED 0 or 1 CREATED 0 or 1
DESCRIPTION 0 or 1 DESCRIPTION 0 or 1
DTSTART 0 or 1 DTSTART 0 or 1
DUE 0 or 1 If present DURATION MUST NOT be present DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+ EXDATE 0+
EXRULE 0+ EXRULE 0+
GEO 0 or 1 GEO 0 or 1
LAST-MODIFIED 0 or 1 LAST-MODIFIED 0 or 1
skipping to change at line 2220 skipping to change at line 2244
this method to request an updated status from the "Attendees". The this method to request an updated status from the "Attendees". The
"REFRESH" method MUST specify the "UID" property corresponding to the "REFRESH" method MUST specify the "UID" property corresponding to the
"VTODO" calendar component needing update. "VTODO" calendar component needing update.
A refresh of a recurrence instance of a "VTODO" calendar component may A refresh of a recurrence instance of a "VTODO" calendar component may
be requested by specifying the "RECURRENCE-ID" property corresponding to be requested by specifying the "RECURRENCE-ID" property corresponding to
the associated "VTODO" calendar component. The "Organizer" responds with the associated "VTODO" calendar component. The "Organizer" responds with
the latest description and rendition of the "VTODO" calendar component. the latest description and rendition of the "VTODO" calendar component.
In most cases this will be a REQUEST unless the "VTODO" has been In most cases this will be a REQUEST unless the "VTODO" has been
Silverberg/Mansour/Daws/Hopson 42 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 41 - Expires December 1998
cancelled, in which case the ORGANIZER MUST send a "CANCEL". This method cancelled, in which case the ORGANIZER MUST send a "CANCEL". This method
is intended to facilitate machine processing of requests for updates to is intended to facilitate machine processing of requests for updates to
a "VTODO" calendar component. a "VTODO" calendar component.
This method type is an iCalendar object that conforms to the following This method type is an iCalendar object that conforms to the following
property constraints: property constraints:
Component/Property Presence Component/Property Presence
------------------- --------------------------------------------- ------------------- ---------------------------------------------
METHOD 1 MUST be "REFRESH" METHOD 1 MUST be "REFRESH"
skipping to change at line 2275 skipping to change at line 2300
STATUS 0 STATUS 0
URL 0 URL 0
X-COMPONENT 0+ X-COMPONENT 0+
VALARM 0 VALARM 0
VEVENT 0 VEVENT 0
VFREEBUSY 0 VFREEBUSY 0
VTIMEZONE 0 VTIMEZONE 0
Silverberg/Mansour/Daws/Hopson 43 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 42 - Expires December 1998
3.4.7 COUNTER 3.4.7 COUNTER
The "COUNTER" method in a "VTODO" calendar component is used by an The "COUNTER" method in a "VTODO" calendar component is used by an
"Attendee" of an existing "VTODO" calendar component to submit to the "Attendee" of an existing "VTODO" calendar component to submit to the
"Organizer" a counter proposal for the "VTODO" calendar component. The "Organizer" a counter proposal for the "VTODO" calendar component. The
"Attendee" sends the message to the "Organizer" of the "VTODO" calendar "Attendee" sends the message to the "Organizer" of the "VTODO" calendar
component. component.
The counter proposal is an iCalendar object consisting of a "VTODO" The counter proposal is an iCalendar object consisting of a "VTODO"
calendar component describing the complete description of the alternate calendar component describing the complete description of the alternate
skipping to change at line 2328 skipping to change at line 2354
DUE 0 or 1 If present DURATION MUST NOT be present DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+ EXDATE 0+
EXRULE 0+ EXRULE 0+
GEO 0 or 1 GEO 0 or 1
LAST-MODIFIED 0 or 1 LAST-MODIFIED 0 or 1
LOCATION 0 or 1 LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1 PERCENT-COMPLETE 0 or 1
RDATE 0+ RDATE 0+
Silverberg/Mansour/Daws/Hopson 44 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 43 - Expires December 1998
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise it recurring calendar component. Otherwise it
MUST NOT be present. MUST NOT be present.
RELATED-TO 0+ RELATED-TO 0+
REQUEST-STATUS 0+ REQUEST-STATUS 0+
RESOURCES 0 or 1 This property MAY contain a list of values RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0 or 1 RRULE 0 or 1
SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. SEQUENCE 0 or 1 MUST echo the original SEQUENCE number.
MUST be present if non-zero. MAY be present MUST be present if non-zero. MAY be present
if zero. if zero.
skipping to change at line 2383 skipping to change at line 2409
ATTACH 0+ ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1 CLASS 0 or 1
COMMENT 0 or 1 COMMENT 0 or 1
CONTACT 0+ CONTACT 0+
CREATED 0 or 1 CREATED 0 or 1
DESCRIPTION 0 or 1 DESCRIPTION 0 or 1
DTSTART 0 or 1 DTSTART 0 or 1
Silverberg/Mansour/Daws/Hopson 45 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 44 - Expires December 1998
DUE 0 or 1 If present DURATION MUST NOT be present DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+ EXDATE 0+
EXRULE 0+ EXRULE 0+
GEO 0 or 1 GEO 0 or 1
LAST-MODIFIED 0 or 1 LAST-MODIFIED 0 or 1
LOCATION 0 or 1 LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1 PERCENT-COMPLETE 0 or 1
PRIORITY 0 or 1 PRIORITY 0 or 1
RDATE 0+ RDATE 0+
skipping to change at line 2435 skipping to change at line 2461
| PUBLISH | Post a journal entry. Used primarily as a method | | PUBLISH | Post a journal entry. Used primarily as a method |
| | of advertising the existence of a journal entry. | | | of advertising the existence of a journal entry. |
| | | | | |
| ADD | Add one or more instances to an existing journal | | ADD | Add one or more instances to an existing journal |
| | entry. | | | entry. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | journal entry. | | | journal entry. |
+================+==================================================+ +================+==================================================+
Silverberg/Mansour/Daws/Hopson 46 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 45 - Expires December 1998
3.5.1 PUBLISH 3.5.1 PUBLISH
The "PUBLISH" method in a "VJOURNAL" calendar component has no The "PUBLISH" method in a "VJOURNAL" calendar component has no
associated response. It is simply a posting of an iCalendar object that associated response. It is simply a posting of an iCalendar object that
may be added to a calendar. It MUST have an "Organizer". It MUST NOT may be added to a calendar. It MUST have an "Organizer". It MUST NOT
have "Attendees". The expected usage is for encapsulating an arbitrary have "Attendees". The expected usage is for encapsulating an arbitrary
journal entry as an iCalendar object. The "Organizer" MAY subsequently journal entry as an iCalendar object. The "Organizer" MAY subsequently
update (with another "PUBLISH" method) or cancel (with a "CANCEL" update (with another "PUBLISH" method) or cancel (with a "CANCEL"
method) a previously published journal entry. method) a previously published journal entry.
skipping to change at line 2491 skipping to change at line 2518
ATTENDEE 0 ATTENDEE 0
VALARM 0+ VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers to VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone a timezone
X-COMPONENT 0+ X-COMPONENT 0+
VEVENT 0 VEVENT 0
Silverberg/Mansour/Daws/Hopson 47 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 46 - Expires December 1998
VFREEBUSY 0 VFREEBUSY 0
VTODO 0 VTODO 0
3.5.2 ADD 3.5.2 ADD
The "ADD" method in a "VJOURNAL" calendar component is used to add one The "ADD" method in a "VJOURNAL" calendar component is used to add one
or more instances to an existing "VJOURNAL" entry. There is no response or more instances to an existing "VJOURNAL" entry. There is no response
to the "Organizer". to the "Organizer".
If the "UID" property value in the "ADD" is not found on the recipient's If the "UID" property value in the "ADD" is not found on the recipient's
skipping to change at line 2546 skipping to change at line 2574
RECURRENCE-ID 0 RECURRENCE-ID 0
VALARM 0+ VALARM 0+
VTIMEZONE 0 or 1 MUST be present if any date/time refers to VTIMEZONE 0 or 1 MUST be present if any date/time refers to
a timezone a timezone
X-COMPONENT 0+ X-COMPONENT 0+
VEVENT 0 VEVENT 0
VFREEBUSY 0 VFREEBUSY 0
Silverberg/Mansour/Daws/Hopson 48 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 47 - Expires December 1998
VTODO 0 VTODO 0
3.5.3 CANCEL 3.5.3 CANCEL
The "CANCEL" method in a "VJOURNAL" calendar component is used to send a The "CANCEL" method in a "VJOURNAL" calendar component is used to send a
cancellation notice of an existing journal entry. The message is sent by cancellation notice of an existing journal entry. The message is sent by
the "Organizer" of a journal entry. For a recurring journal entry, the "Organizer" of a journal entry. For a recurring journal entry,
either the whole journal entry or instances of a journal entry may be either the whole journal entry or instances of a journal entry may be
cancelled. To cancel the complete range of a recurring journal entry, cancelled. To cancel the complete range of a recurring journal entry,
the "UID" property value for the journal entry MUST be specified and a the "UID" property value for the journal entry MUST be specified and a
skipping to change at line 2600 skipping to change at line 2629
ATTENDEE 0+ ATTENDEE 0+
CATEGORIES 0 or 1 This property MAY contain a list of values CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1 CLASS 0 or 1
COMMENT 0 or 1 COMMENT 0 or 1
CONTACT 0+ CONTACT 0+
CREATED 0 or 1 CREATED 0 or 1
DESCRIPTION 0 or 1 DESCRIPTION 0 or 1
DTSTART 0 or 1 DTSTART 0 or 1
EXDATE 0+ EXDATE 0+
Silverberg/Mansour/Daws/Hopson 49 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 48 - Expires December 1998
EXRULE 0+ EXRULE 0+
LAST-MODIFIED 0 or 1 LAST-MODIFIED 0 or 1
RDATE 0+ RDATE 0+
RECURRENCE-ID 0 or 1 only if referring to an instance of a RECURRENCE-ID 0 or 1 only if referring to an instance of a
recurring calendar component. Otherwise recurring calendar component. Otherwise
it MUST NOT be present. it MUST NOT be present.
RELATED-TO 0+ RELATED-TO 0+
RRULE 0+ RRULE 0+
STATUS 0 or 1 MAY be present, must be "CANCELLED" if STATUS 0 or 1 MAY be present, must be "CANCELLED" if
present present
skipping to change at line 2654 skipping to change at line 2683
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.4 | Success, unknown non- | Non-standard property | | 2.4 | Success, unknown non- | Non-standard property |
| | standard property ignored. | name MAY be specified. | | | standard property ignored. | name MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.5 | Success, unknown non | Property and non- | | 2.5 | Success, unknown non | Property and non- |
| | standard property value | standard value MAY be | | | standard property value | standard value MAY be |
| | ignored. | specified. | | | ignored. | specified. |
|==============+============================+=========================| |==============+============================+=========================|
Silverberg/Mansour/Daws/Hopson 50 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 49 - Expires December 1998
| 2.6 | Success, invalid calendar | Calendar component | | 2.6 | Success, invalid calendar | Calendar component |
| | component ignored. | sentinel (e.g., BEGIN: | | | component ignored. | sentinel (e.g., BEGIN: |
| | | ALARM) MAY be | | | | ALARM) MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.7 | Success, request forwarded | Original and forwarded | | 2.7 | Success, request forwarded | Original and forwarded |
| | to Calendar User. | caluser addresses MAY | | | to Calendar User. | caluser addresses MAY |
| | | be specified. | | | | be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 2.8 | Success, repeating event | RRULE or RDATE property | | 2.8 | Success, repeating event | RRULE or RDATE property |
skipping to change at line 2710 skipping to change at line 2740
| | | be specified. | | | | be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.6 | Invalid rule. | Rule value MAY be | | 3.6 | Invalid rule. | Rule value MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.7 | Invalid Calendar User. | Attendee property value | | 3.7 | Invalid Calendar User. | Attendee property value |
| | |MAY be specified. | | | |MAY be specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.8 | No authority. | METHOD and Attendee | | 3.8 | No authority. | METHOD and Attendee |
Silverberg/Mansour/Daws/Hopson 51 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 50 - Expires December 1998
| | | property values MAY be | | | | property values MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.9 | Unsupported version. | VERSION property name | | 3.9 | Unsupported version. | VERSION property name |
| | | and value MAY be | | | | and value MAY be |
| | | specified. | | | | specified. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.10 | Request entity too large. | None. | | 3.10 | Request entity too large. | None. |
|==============+============================+=========================| |==============+============================+=========================|
| 3.11 | Required component or | Component or property | | 3.11 | Required component or | Component or property |
skipping to change at line 2764 skipping to change at line 2795
The benefit of such a grammar is the ability to represent a number of The benefit of such a grammar is the ability to represent a number of
events in a single object. However, while this simplifies creation of a events in a single object. However, while this simplifies creation of a
recurring event, meeting instances still need to be referenced. For recurring event, meeting instances still need to be referenced. For
instance, an "Attendee" may decline the third instance of a recurring instance, an "Attendee" may decline the third instance of a recurring
Friday event. Similarly, the "Organizer" may change the time or location Friday event. Similarly, the "Organizer" may change the time or location
to a single instance of the recurring event. to a single instance of the recurring event.
Since implementations may elect to store recurring events as either a Since implementations may elect to store recurring events as either a
single event object or a collection of discreet, related event objects, single event object or a collection of discreet, related event objects,
Silverberg/Mansour/Daws/Hopson 52 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 51 - Expires December 1998
the protocol is designed so that each recurring instance may be both the protocol is designed so that each recurring instance may be both
referenced and versioned. Hence, implementations that choose to maintain referenced and versioned. Hence, implementations that choose to maintain
per-instance properties (such as "ATTENDEE" property "partstat" per-instance properties (such as "ATTENDEE" property "partstat"
parameter) may do so. However, the protocol does not require per- parameter) may do so. However, the protocol does not require per-
instance recognition unless the instance itself must be renegotiated. instance recognition unless the instance itself must be renegotiated.
The scenarios for recurrence instance referencing are listed below. For The scenarios for recurrence instance referencing are listed below. For
purposes of simplification a change to an event refers to a "trigger purposes of simplification a change to an event refers to a "trigger
property." That is, a property that has a substantive effect on the property." That is, a property that has a substantive effect on the
meeting itself such as start time, location, due date (for "VTODO" meeting itself such as start time, location, due date (for "VTODO"
skipping to change at line 2816 skipping to change at line 2848
to update and redistribute an event or to-do component. It follows that to update and redistribute an event or to-do component. It follows that
the "ORGANIZER" property MUST be present in the event, to-do, or journal the "ORGANIZER" property MUST be present in the event, to-do, or journal
entry component so that the CUA has a basis for authorizing an update. entry component so that the CUA has a basis for authorizing an update.
Second, it is prudent to provide a point of contact for anyone who Second, it is prudent to provide a point of contact for anyone who
receives a published component in case of problems. receives a published component in case of problems.
There are valid [RFC-822] addresses that represent groups. Sending email There are valid [RFC-822] addresses that represent groups. Sending email
to such an address results in mail being sent to multiple recipients. to such an address results in mail being sent to multiple recipients.
Such an address may be used as the value of an "ATTENDEE" property. Such an address may be used as the value of an "ATTENDEE" property.
Silverberg/Mansour/Daws/Hopson 53 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 52 - Expires December 1998
Thus, it is possible that the recipient of a "REQUEST" does not appear Thus, it is possible that the recipient of a "REQUEST" does not appear
explicitly in the list. explicitly in the list.
It is recommended that the general approach to finding a "Calendar User" It is recommended that the general approach to finding a "Calendar User"
in an attendee list be as follows: in an attendee list be as follows:
1. Search for the "Calendar User" in the attendee list where 1. Search for the "Calendar User" in the attendee list where
"TYPE=INDIVIDUAL" "TYPE=INDIVIDUAL"
2. Failing (1) look for attendees where "TYPE=GROUP" or 'TYPE=UNKNOWN". 2. Failing (1) look for attendees where "TYPE=GROUP" or 'TYPE=UNKNOWN".
skipping to change at line 2869 skipping to change at line 2902
| Action | "Organizer" | | Action | "Organizer" |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Publish an event | "A" sends or posts a PUBLISH | | Publish an event | "A" sends or posts a PUBLISH |
| | message | | | message |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| "B" reads a published event | | | "B" reads a published event | |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Publish an updated event | "A" sends or posts a PUBLISH | | Publish an updated event | "A" sends or posts a PUBLISH |
| | message | | | message |
Silverberg/Mansour/Daws/Hopson 54 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 53 - Expires December 1998
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| "B" reads the updated event | | | "B" reads the updated event | |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Cancel a published event | "A" sends or posts a CANCEL | | Cancel a published event | "A" sends or posts a CANCEL |
| | message | | | message |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| "B" reads the canceled event | | | "B" reads the canceled event | |
| publication | | | publication | |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
skipping to change at line 2920 skipping to change at line 2954
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
Silverberg/Mansour/Daws/Hopson 55 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 54 - Expires December 1998
The "UID" property is used by the client to identify the event. The The "UID" property is used by the client to identify the event. The
"SEQUENCE" property indicates that this is a change to the event. The "SEQUENCE" property indicates that this is a change to the event. The
event with a matching UID and sequence number 0 is superseded by this event with a matching UID and sequence number 0 is superseded by this
event. event.
The "SEQUENCE" property provides a reliable way to distinguish different The "SEQUENCE" property provides a reliable way to distinguish different
versions of the same event. Each time an event is published, its versions of the same event. Each time an event is published, its
sequence number is incremented. If a client receives an event with a sequence number is incremented. If a client receives an event with a
sequence number 5 and finds it has the same event with sequence number sequence number 5 and finds it has the same event with sequence number
2, the event SHOULD be updated. However, if the client received an event 2, the event SHOULD be updated. However, if the client received an event
skipping to change at line 2974 skipping to change at line 3009
TZURL:http://zones.stds_r_us.net/tz/America-Chicago TZURL:http://zones.stds_r_us.net/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
Silverberg/Mansour/Daws/Hopson 56 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 55 - Expires December 1998
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.dukes.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=URL:http://www.midwaystadium.com/ LOCATION;VALUE=URI:http://www.midwaystadium.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 line 3029 skipping to change at line 3065
This example demonstrates the use of the "value" parameter to tie a This example demonstrates the use of the "value" parameter to tie a
"VEVENT" to day rather than a specific time. "VEVENT" to day rather than a specific time.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:PUBLISH METHOD:PUBLISH
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:a@example.com ORGANIZER:mailto:a@example.com
Silverberg/Mansour/Daws/Hopson 57 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 56 - Expires December 1998
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
END:VCALENDAR END:VCALENDAR
4.2 Group Event Examples 4.2 Group Event Examples
skipping to change at line 3083 skipping to change at line 3120
| attendees | "D" with updated | | | attendees | "D" with updated | |
| | information. | | | | 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_ is 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 need 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" type not reply. "E" illustrates how CUAs might implement an "FYI" type
Silverberg/Mansour/Daws/Hopson 58 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 57 - Expires December 1998
feature. Note the use of the "role" parameter. The default value for the feature. Note the use of the "role" parameter. The default value for the
"role" parameter is "req-participant" and it need not be enumerated. In "role" parameter is "req-participant" and it need not be enumerated. In
this case we are using the value "non-participant" to indicate "E" is a this case we are using the value "non-participant" to indicate "E" is a
non-attending CU. The parameter is not needed on other "Attendees" since non-attending CU. The parameter is not needed on other "Attendees" since
"participant" is the default value. "participant" is the default value.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
skipping to change at line 3135 skipping to change at line 3173
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970612T190000Z DTSTAMP:19970612T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"B" could have declined the meeting or indicated tentative acceptance by "B" could have declined the meeting or indicated tentative acceptance by
setting the "ATTENDEE" "partstat" parameter to "declined" or setting the "ATTENDEE" "partstat" parameter to "declined" or
"tentative", respectively. Also, "REQUEST-STATUS" is not required in "tentative", respectively. Also, "REQUEST-STATUS" is not required in
successful transactions. successful transactions.
Silverberg/Mansour/Daws/Hopson 59 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 58 - Expires December 1998
4.2.3 Update An Event 4.2.3 Update An Event
The event is moved to a different time. The combination of the "UID" The event is moved to a different time. The combination of the "UID"
property (unchanged) and the "SEQUENCE" (bumped to 1) properties property (unchanged) and the "SEQUENCE" (bumped to 1) properties
indicate the update. indicate the update.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
skipping to change at line 3188 skipping to change at line 3227
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;RSVP=TRUE;TYPE=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
LOCATION:Green Conference Room LOCATION:Green Conference Room
UID:calsrv.example.com-873970198738777a@example.com UID:calsrv.example.com-873970198738777a@example.com
SEQUENCE:0 SEQUENCE:0
Silverberg/Mansour/Daws/Hopson 60 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 59 - Expires December 1998
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
"B" sends "COUNTER" to "A", requesting changes to time and place. "B" "B" sends "COUNTER" to "A", requesting changes to time and place. "B"
uses the "COMMENT" property to communicate a rationale for the change. uses the "COMMENT" property to communicate a rationale for the change.
Note that the "SEQUENCE" property is NOT incremented on a "COUNTER". Note that the "SEQUENCE" property is NOT incremented on a "COUNTER".
BEGIN:VCALENDAR BEGIN:VCALENDAR
skipping to change at line 3242 skipping to change at line 3282
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
DTSTART:19970701T160000Z DTSTART:19970701T160000Z
DTEND:19970701T190000Z DTEND:19970701T190000Z
SUMMARY:Discuss the Merits of the election results - changed to SUMMARY:Discuss the Merits of the election results - changed to
meet B's schedule meet B's schedule
LOCATION:Green Conference Room LOCATION:Green Conference Room
UID:calsrv.example.com-873970198738777@example.com UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1 SEQUENCE:1
Silverberg/Mansour/Daws/Hopson 61 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 60 - Expires December 1998
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:-//ACME/DesktopCalendar//EN
METHOD:DECLINECOUNTER METHOD:DECLINECOUNTER
VERSION:2.0 VERSION:2.0
skipping to change at line 3295 skipping to change at line 3336
. The "Delegator" MUST also send a copy of the original "REQUEST" . 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 their It is not required that the "Delegate" include the "Delegator" in their
"REPLY" method. However, it is strongly advised since this will inform "REPLY" method. However, it is strongly advised since this will inform
the "Delegator" whether the "Delegate" plans to attend the meeting. the "Delegator" whether the "Delegate" plans to attend the meeting.
[Editors note: How so?] If the "Delegate" declines the meeting, the [Editors note: How so?] If the "Delegate" declines the meeting, the
"Delegator" may elect to delegate the "REQUEST" to another CUA. The "Delegator" may elect to delegate the "REQUEST" to another CUA. The
process is the same. process is the same.
Silverberg/Mansour/Daws/Hopson 62 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 61 - Expires December 1998
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| Initiate a meeting | "A" sends a REQUEST | | | Initiate a meeting | "A" sends a REQUEST | |
| request | message to "B" and | | | request | message to "B" and | |
| | "C" | | | | "C" | |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| Delegate: | | "C" sends a REPLY to "A" | | Delegate: | | "C" sends a REPLY to "A" |
| "C" delegates to | | with the ATTENDEE. | | "C" delegates to | | with the ATTENDEE. |
| "E" | | "partstat" parameter set | | "E" | | "partstat" parameter set |
skipping to change at line 3350 skipping to change at line 3392
"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
Silverberg/Mansour/Daws/Hopson 63 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 62 - Expires December 1998
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".
skipping to change at line 3404 skipping to change at line 3447
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
REQUEST-STATUS:2.0;Success REQUEST-STATUS:2.0;Success
DTSTAMP:19970614T190000Z DTSTAMP:19970614T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Daws/Hopson 64 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 63 - Expires December 1998
4.2.7 Delegate Declines the Meeting 4.2.7 Delegate Declines the Meeting
In this example the "Delegate" declines the meeting request and sets the In this example the "Delegate" declines the meeting request and sets the
"ATTENDEE" property "partstat" parameter to "DECLINED". The "Organizer" "ATTENDEE" property "partstat" parameter to "DECLINED". The "Organizer"
SHOULD resend the "REQUEST" to "C" with the "partstat" parameter of the SHOULD resend the "REQUEST" to "C" with the "partstat" parameter of the
"Delegate" set to "declined". This lets the "Delegator" know that the "Delegate" set to "declined". This lets the "Delegator" know that the
"Delegate" has declined and provides an opportunity to the "Delegator" "Delegate" has declined and provides an opportunity to the "Delegator"
to either accept the request or delegate it to another CU. to either accept the request or delegate it to another CU.
Response from "E" to "A" and "C". Note the use of the "COMMENT" property Response from "E" to "A" and "C". Note the use of the "COMMENT" property
skipping to change at line 3458 skipping to change at line 3502
SEQUENCE:0 SEQUENCE:0
SUMMARY:Phone Conference SUMMARY:Phone Conference
DTSTART:19970701T180000Z DTSTART:19970701T180000Z
DTEND:19970701T200000Z DTEND:19970701T200000Z
DTSTAMP:19970614T200000Z DTSTAMP:19970614T200000Z
COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR
INVITATION INVITATION
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Daws/Hopson 65 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 64 - Expires December 1998
4.2.8 Forwarding an Event Request 4.2.8 Forwarding an Event Request
The protocol does not prevent an "Attendee" from "forwarding" an The protocol does not prevent an "Attendee" from "forwarding" an
"VEVENT" calendar component to other "Calendar Users". Forwarding "VEVENT" calendar component to other "Calendar Users". Forwarding
differs from delegation in that the forwarded "Calendar User" (often differs from delegation in that the forwarded "Calendar User" (often
referred to as a "Party Crasher") does not replace the forwarding referred to as a "Party Crasher") does not replace the forwarding
"Calendar User". Implementations are not required to add the "Party "Calendar User". Implementations are not required to add the "Party
Crasher" to the "Attendee" list and hence there is no guarantee that a Crasher" to the "Attendee" list and hence there is no guarantee that a
"Party Crasher" will receive additional updates to the Event. The "Party Crasher" will receive additional updates to the Event. The
forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the
skipping to change at line 3510 skipping to change at line 3555
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
Silverberg/Mansour/Daws/Hopson 66 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 65 - Expires December 1998
ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;TYPE=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
SEQUENCE:1 SEQUENCE:1
STATUS:CANCELLED STATUS:CANCELLED
DTSTAMP:19970613T190000Z DTSTAMP:19970613T190000Z
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
skipping to change at line 3564 skipping to change at line 3610
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" MAY The updated master copy of the event is shown below. The "Organizer" MAY
resend the updated event to the remaining "Attendees". Note that "B" has resend the updated event to the remaining "Attendees". Note that "B" has
been removed. been removed.
Silverberg/Mansour/Daws/Hopson 67 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 66 - Expires December 1998
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
ATTENDEE;TYPE=ROOM:CR_Big@example.com ATTENDEE;TYPE=ROOM:CR_Big@example.com
skipping to change at line 3620 skipping to change at line 3667
ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T200000Z DTSTART:19970701T200000Z
DTEND:19970701T203000Z DTEND:19970701T203000Z
RRULE:FREQ=WEEKLY RRULE:FREQ=WEEKLY
SUMMARY:Phone Conference SUMMARY:Phone Conference
UID:123456@example.com UID:123456@example.com
Silverberg/Mansour/Daws/Hopson 68 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 67 - Expires December 1998
SEQUENCE:1 SEQUENCE:1
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
4.3 Busy Time Examples 4.3 Busy Time Examples
Busy time objects can be used in several ways. First, a CU may request 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 can busy time from another CU for a specific range of time. That request can
be answered with a busy time Reply. Additionally, a CU may simply be answered with a busy time Reply. Additionally, a CU may simply
publish busy their busy time for a given interval and point other CUs to publish their busy time for a given interval and point other CUs to the
the published location. The following examples outline both scenarios. published location. The following examples outline 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:-//ACME/DesktopCalendar//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
skipping to change at line 3672 skipping to change at line 3720
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Initiate a busy | "A" sends "REQUEST" | | | Initiate a busy | "A" sends "REQUEST" | |
| time request | message to "B" and | | | time request | message to "B" and | |
| | and "C" | | | | 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 |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
Silverberg/Mansour/Daws/Hopson 69 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 68 - Expires December 1998
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
skipping to change at line 3722 skipping to change at line 3771
"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 each This event describes a weekly phone conference. The "Attendees" are each
in a different time zone. in a different time zone.
Silverberg/Mansour/Daws/Hopson 70 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 69 - Expires December 1998
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//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://zones.stds_r_us.net/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
skipping to change at line 3777 skipping to change at line 3827
The recurring meeting is defined in a particular time zone, presumably The recurring meeting is defined in a particular time zone, presumably
that of the originator. The client for each "Attendee" has the that of the originator. The client for each "Attendee" has the
responsibility of determining the recurrence time in the "Attendee's" responsibility of determining the recurrence time in the "Attendee's"
time zone. time zone.
The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT. The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT.
"Attendee" B@example.fr is in France where the local time on this date "Attendee" B@example.fr is in France where the local time on this date
is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in Japan is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in Japan
Silverberg/Mansour/Daws/Hopson 71 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 70 - Expires December 1998
where local time is 8 hours ahead of UTC or Wednesday, July 2 at 06:00. where local time is 8 hours ahead of UTC or Wednesday, July 2 at 06:00.
The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property
results in 20 instances. The last instance falls on Tuesday, November results in 20 instances. The last instance falls on Tuesday, November
11, 1997 2:00pm PDT. The "RDATE" property adds another instance: WED, 11, 1997 2:00pm PDT. The "RDATE" property adds another instance: WED,
10-SEP-1997 2:00 PM PST. 10-SEP-1997 2:00 PM PST.
There are two exceptions to this recurring appointment. The first one There are two exceptions to this recurring appointment. The first one
is: is:
TUE, 09-SEP-1997 23:00 GMT TUE, 09-SEP-1997 23:00 GMT
skipping to change at line 3830 skipping to change at line 3881
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970601T210000Z DTSTART:19970601T210000Z
DTEND:19970601T220000Z DTEND:19970601T220000Z
LOCATION:Conference Call LOCATION:Conference Call
DTSTAMP:19970526T083000Z DTSTAMP:19970526T083000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Daws/Hopson 72 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 71 - Expires December 1998
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:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
UID:guid-1@host1com UID:guid-1@host1com
RECURRENCE-ID:19970701T210000Z RECURRENCE-ID:19970701T210000Z
skipping to change at line 3881 skipping to change at line 3933
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
Silverberg/Mansour/Daws/Hopson 73 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 72 - Expires December 1998
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:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
skipping to change at line 3933 skipping to change at line 3986
CLASS:PUBLIC CLASS:PUBLIC
SUMMARY:IETF Calendaring Working Group Meeting SUMMARY:IETF Calendaring Working Group Meeting
DTSTART:19970901T210000Z DTSTART:19970901T210000Z
DTEND:19970901T220000Z DTEND:19970901T220000Z
LOCATION:Building 32, Microsoft, Seattle, WA LOCATION:Building 32, Microsoft, Seattle, WA
DTSTAMP:19970526T083000Z DTSTAMP:19970526T083000Z
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Daws/Hopson 74 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 73 - Expires December 1998
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 event. This example adds a one-time additional instance to the recurring event.
"Organizer" adds a second July meeting on the 15th. "Organizer" adds a second July meeting on the 15th.
BEGIN:VCALENDAR BEGIN:VCALENDAR
METHOD:ADD METHOD:ADD
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
skipping to change at line 3989 skipping to change at line 4043
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
Silverberg/Mansour/Daws/Hopson 75 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 74 - Expires December 1998
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Assume that many other updates happen to this event and that a lot of 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 "Organizer" "SEQUENCE" property value is 7 for the next update. Now the "Organizer"
wants to add Thursdays to the event: wants to add Thursdays to the event:
BEGIN:VCALENDAR BEGIN:VCALENDAR
skipping to change at line 4043 skipping to change at line 4098
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
STATUS:CONFIRMED STATUS:CONFIRMED
Silverberg/Mansour/Daws/Hopson 76 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 75 - Expires December 1998
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The next series of examples illustrate how an "Organizer" would respond The next series of examples illustrate how an "Organizer" would respond
to a "REFRESH" submitted by an "Attendee" after a series of instance- to a "REFRESH" submitted by an "Attendee" after a series of instance-
specific modifications. To convey all instance-specific changes, the specific modifications. To convey all instance-specific changes, the
"Organizer" must provide the latest event description and the relevant "Organizer" must provide the latest event description and the relevant
instances. The first three examples show the history including the instances. The first three examples show the history including the
initial "VEVENT" request and subsequent instance changes and finally the initial "VEVENT" request and subsequent instance changes and finally the
"REFRESH". "REFRESH".
skipping to change at line 4099 skipping to change at line 4155
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
Silverberg/Mansour/Daws/Hopson 77 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 76 - Expires December 1998
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:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
skipping to change at line 4155 skipping to change at line 4212
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
BEGIN:VEVENT BEGIN:VEVENT
Error! Bookmark not defined. Error! Bookmark not defined.
Silverberg/Mansour/Daws/Hopson 78 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 77 - Expires December 1998
SEQUENCE:2 SEQUENCE:2
RECURRENCE-ID:19980311T160000Z RECURRENCE-ID:19980311T160000Z
Error! Bookmark not defined. Error! Bookmark not defined.
ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined. ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined.
ATTENDEE;Error! Bookmark not defined. ATTENDEE;Error! Bookmark not defined.
SUMMARY:Review Accounts SUMMARY:Review Accounts
DTSTART:19980311T160000Z DTSTART:19980311T160000Z
DTEND:19980304T180000Z DTEND:19980304T180000Z
DTSTAMP:19980306T193000Z DTSTAMP:19980306T193000Z
LOCATION:The Small conference room LOCATION:The Small conference room
skipping to change at line 4207 skipping to change at line 4265
END:VEVENT END:VEVENT
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 proposed The following example illustrates a scenario where a meeting is proposed
containing an unsupported property and a bad property. containing an unsupported property and a bad property.
Original Request Original Request
Silverberg/Mansour/Daws/Hopson 79 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 78 - Expires December 1998
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:guid-1@host1.com UID:guid-1@host1.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
skipping to change at line 4261 skipping to change at line 4320
4.5 Group To-do Examples 4.5 Group To-do Examples
Individual "A" creates a group task in which individuals "A", "B", "C" Individual "A" creates a group task in which individuals "A", "B", "C"
and "D" will participate. Individual "B" confirms acceptance of the and "D" will participate. Individual "B" confirms acceptance of the
task. Individual "C" declines the task. Individual "D" tentatively task. Individual "C" declines the task. Individual "D" tentatively
accepts the task. The following table illustrates the sequence of accepts the task. The following table illustrates the sequence of
messages that would be exchanged between these individuals. Individual messages that would be exchanged between these individuals. Individual
"A" then issues a "REQUEST" method to obtain the status of the to-do "A" then issues a "REQUEST" method to obtain the status of the to-do
Silverberg/Mansour/Daws/Hopson 80 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 79 - Expires December 1998
from each participant. The response indicates the individual from each participant. The response indicates the individual
"Attendee's" completion status. The table below illustrates the message "Attendee's" completion status. The table below illustrates the message
flow. flow.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Action | "Organizer" | Attendee | | Action | "Organizer" | Attendee |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Initiate a to-do | "A" sends a REQUEST | | | Initiate a to-do | "A" sends a REQUEST | |
| request | message to "B", "C",| | | request | message to "B", "C",| |
| | and "D" | | | | and "D" | |
skipping to change at line 4304 skipping to change at line 4364
| percent complete | | message indicating | | percent complete | | message indicating |
| | | percent complete | | | | percent complete |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Attendee indicates | | "D" sends a "REPLY" | | Attendee indicates | | "D" sends a "REPLY" |
| completion | | message indicating | | completion | | message indicating |
| | | completion | | | | completion |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
4.5.1 A VTODO Request 4.5.1 A VTODO Request
A sample "REQUEST" with for a "VTODO" calendar component that "A" sends A sample "REQUEST" for a "VTODO" calendar component that "A" sends to
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
BEGIN:VTODO BEGIN:VTODO
ORGANIZER:Mailto:A@example.com ORGANIZER:Mailto:A@example.com
Silverberg/Mansour/Daws/Hopson 81 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 80 - Expires December 1998
ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
ATTENDEE;RSVP=TRUE:B@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com
ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com
ATTENDEE;RSVP=TRUE:Mailto:D@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com
DTSTART:19970701T170000Z DTSTART:19970701T170000Z
DUE:19970722T170000Z DUE:19970722T170000Z
PRIORITY:1 PRIORITY:1
SUMMARY:Create the requirements document SUMMARY:Create the requirements document
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970717T200000Z DTSTAMP:19970717T200000Z
STATUS:Needs Action STATUS:Needs Action
skipping to change at line 4367 skipping to change at line 4428
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
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;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com
Silverberg/Mansour/Daws/Hopson 82 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 81 - Expires December 1998
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
SEQUENCE:0 SEQUENCE:0
STATUS:IN-PROCESS STATUS:IN-PROCESS
DTSTART:19970701T170000Z DTSTART:19970701T170000Z
DTSTAMP:19970717T230000Z DTSTAMP:19970717T230000Z
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
skipping to change at line 4419 skipping to change at line 4481
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%.
Silverberg/Mansour/Daws/Hopson 83 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 82 - Expires December 1998
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
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;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com
DTSTART:19970701T170000Z DTSTART:19970701T170000Z
skipping to change at line 4471 skipping to change at line 4534
DUE:19980103T100000-0700 DUE:19980103T100000-0700
SUMMARY:Send Status Reports to Area Managers SUMMARY:Send Status Reports to Area Managers
UID:calsrv.example.com-873970198738777-00@example.com UID:calsrv.example.com-873970198738777-00@example.com
SEQUENCE:0 SEQUENCE:0
DTSTAMP:19970717T200000Z DTSTAMP:19970717T200000Z
STATUS:NEEDS ACTION STATUS:NEEDS ACTION
PRIORITY:1 PRIORITY:1
END:VTODO END:VTODO
END:VCALENDAR END:VCALENDAR
Silverberg/Mansour/Daws/Hopson 84 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 83 - Expires December 1998
4.5.7.2 Calculating due dates in recurring VTODOs 4.5.7.2 Calculating due dates in recurring VTODOs
The due date in a recurring "VTODO" calendar component is either a fixed The due date in a recurring "VTODO" calendar component is either a fixed
interval specified in the "REQUEST" method or specified using the interval specified in the "REQUEST" method or specified using the
"RECURRENCE-ID" property. The former is calculated by applying the "RECURRENCE-ID" property. The former is calculated by applying the
difference between "DTSTART" and "DUE" properties and applying it to difference between "DTSTART" and "DUE" properties and applying it to
each of the start of each recurring instance. Hence, if the initial each of the start of each recurring instance. Hence, if the initial
"VTODO" calendar component specifies a "DTSTART" property value of "VTODO" calendar component specifies a "DTSTART" property value of
"19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the "19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the
interval of one day which is applied to each recurring instance of the interval of one day which is applied to each recurring instance of the
skipping to change at line 4521 skipping to change at line 4585
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//ACME/DesktopCalendar//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
Silverberg/Mansour/Daws/Hopson 85 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 84 - Expires December 1998
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-12345@host1.com": Refresh the event with "UID" property value of "guid-1-12345@host1.com":
skipping to change at line 4572 skipping to change at line 4637
3. The "UID" and "SEQUENCE" numbers are found but the CUA does not 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not
support recurrences. support recurrences.
In case (1), two things can happen. If the "SEQUENCE" number of the In case (1), two things can happen. If the "SEQUENCE" number of the
"Attendee's" instance is larger than that in the "Organizer's" message "Attendee's" instance is larger than that in the "Organizer's" message
then the "Attendee" is receiving an out-of-sequence message and MUST then the "Attendee" is receiving an out-of-sequence message and MUST
ignore it. If the "SEQUENCE" number of the "Attendee's" instance is ignore it. If the "SEQUENCE" number of the "Attendee's" instance is
smaller, then the "Organizer" is sending out a newer version of the smaller, then the "Organizer" is sending out a newer version of the
component and the "Attendee's" version needs to be updated. Since one or component and the "Attendee's" version needs to be updated. Since one or
Silverberg/Mansour/Daws/Hopson 86 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 85 - Expires December 1998
more updates have been missed, the "Attendee" SHOULD send a "REFRESH" more updates have been missed, the "Attendee" SHOULD send a "REFRESH"
message to the "Organizer" to get an updated version of the event. message to the "Organizer" to get an updated version of the event.
In case (2), something has gone wrong. Both the "Organizer" and the In case (2), something has gone wrong. Both the "Organizer" and the
"Attendee" should have the same instances, but the "Attendee" does not "Attendee" should have the same instances, but the "Attendee" does not
have the referenced instance. In this case the "Attendee" SHOULD send a have the referenced instance. In this case the "Attendee" SHOULD send a
"REFRESH" to the "Organizer" to get an updated version of the event. "REFRESH" to the "Organizer" to get an updated version of the event.
In case (3), the limitations of the "Attendee's" CUA makes it impossible In case (3), the limitations of the "Attendee's" CUA makes it impossible
to match an instance other than the single instance scheduled. In this to match an instance other than the single instance scheduled. In this
skipping to change at line 4627 skipping to change at line 4693
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
Silverberg/Mansour/Daws/Hopson 87 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 86 - Expires December 1998
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's" "B" has the event with "UID" property "acme-12345@host1.com" but "B's"
"SEQUENCE" property value is "1" and the event does not have an instance "SEQUENCE" property value is "1" and the event does not have an instance
at the specified recurrence time. This means that "B" has missed at at the specified recurrence time. This means that "B" has missed at
skipping to change at line 4677 skipping to change at line 4744
PUBLISH Required PUBLISH Required
REQUEST PUBLISH REQUEST PUBLISH
REPLY Required REPLY Required
ADD Required ADD Required
CANCEL Required CANCEL Required
REFRESH Required REFRESH Required
COUNTER Reply with Not Supported COUNTER Reply with Not Supported
DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise
reply with Not Supported reply with Not Supported
Silverberg/Mansour/Daws/Hopson 88 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 87 - Expires December 1998
iCalendar iCalendar
Property Fallback Property Fallback
-------------- ----------------------------------------------------- -------------- -----------------------------------------------------
CALSCALE Ignore; assume GREGORIAN CALSCALE Ignore; assume GREGORIAN
PRODID Ignore PRODID Ignore
METHOD Required as described in the Method list above METHOD Required as described in the Method list above
VERSION Ignore VERSION Ignore
Event-Related Event-Related
Components Fallback Components Fallback
skipping to change at line 4733 skipping to change at line 4801
REQUEST-STATUS Required REQUEST-STATUS Required
RESOURCES Ignore RESOURCES Ignore
SEQUENCE Required SEQUENCE Required
STATUS Ignore STATUS Ignore
SUMMARY Ignore SUMMARY Ignore
TRANSP Required if FREEBUSY is implemented; otherwise Ignore TRANSP Required if FREEBUSY is implemented; otherwise Ignore
URL Ignore URL Ignore
UID Required UID Required
X- Ignore X- Ignore
Silverberg/Mansour/Daws/Hopson 89 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 88 - Expires December 1998
5.1.2 Free/Busy-Related Fallbacks 5.1.2 Free/Busy-Related Fallbacks
Method Fallback Method Fallback
-------------- ----------------------------------------------------- -------------- -----------------------------------------------------
PUBLISH Implementations MAY ignore the METHOD type. The PUBLISH Implementations MAY ignore the METHOD type. The
REQUEST-STATUS "3.14;Unsupported capability" MUST be REQUEST-STATUS "3.14;Unsupported capability" MUST be
returned. returned.
REQUEST Implementations MAY ignore the METHOD type. The REQUEST Implementations MAY ignore the METHOD type. The
REQUEST-STATUS "3.14;Unsupported capability" MUST be REQUEST-STATUS "3.14;Unsupported capability" MUST be
returned. returned.
skipping to change at line 4782 skipping to change at line 4851
5.1.3 To-Do-Related Fallbacks 5.1.3 To-Do-Related Fallbacks
Method Fallback Method Fallback
-------------- ----------------------------------------------------- -------------- -----------------------------------------------------
PUBLISH Required PUBLISH Required
REQUEST PUBLISH REQUEST PUBLISH
REPLY Required REPLY Required
ADD Required ADD Required
CANCEL Required CANCEL Required
Silverberg/Mansour/Daws/Hopson 90 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 89 - Expires December 1998
REFRESH Required REFRESH Required
COUNTER Reply with Not Supported COUNTER Reply with Not Supported
DECLINECOUNTER Required if VTODO - COUNTER is implemented; otherwise DECLINECOUNTER Required if VTODO - COUNTER is implemented; otherwise
reply with Not Supported reply with Not Supported
iCalendar iCalendar
Property Fallback Property Fallback
-------------- ----------------------------------------------------- -------------- -----------------------------------------------------
CALSCALE Ignore; assume GREGORIAN. CALSCALE Ignore; assume GREGORIAN.
PRODID Ignore PRODID Ignore
skipping to change at line 4836 skipping to change at line 4906
PRIORITY Required PRIORITY Required
RECURRENCE-ID Ignore RECURRENCE-ID Ignore
RELATED-TO Ignore RELATED-TO Ignore
REQUEST-STATUS Ignore REQUEST-STATUS Ignore
RDATE Ignore RDATE Ignore
RRULE Ignore. The first instance occurs on the DTSTART RRULE Ignore. The first instance occurs on the DTSTART
property. If implemented, VTIMEZONE MUST also be property. If implemented, VTIMEZONE MUST also be
implemented. implemented.
RESOURCES Ignore RESOURCES Ignore
Silverberg/Mansour/Daws/Hopson 91 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 90 - Expires December 1998
SEQUENCE Required SEQUENCE Required
STATUS Required STATUS Required
SUMMARY Ignore SUMMARY Ignore
URL Ignore URL Ignore
UID Required UID Required
X- Ignore X- Ignore
5.1.4 Journal-Related Fallbacks 5.1.4 Journal-Related Fallbacks
Method Fallback Method Fallback
skipping to change at line 4887 skipping to change at line 4958
CATEGORIES Ignore CATEGORIES Ignore
CLASS Ignore CLASS Ignore
COMMENT Ignore COMMENT Ignore
CONTACT Ignore CONTACT Ignore
CREATED Ignore CREATED Ignore
DESCRIPTION Required DESCRIPTION Required
DTSTAMP Required DTSTAMP Required
DTSTART Required DTSTART Required
EXDATE Ignore EXDATE Ignore
Silverberg/Mansour/Daws/Hopson 92 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 91 - Expires December 1998
EXRULE Ignore Reply with Not Supported. If implemented, EXRULE Ignore Reply with Not Supported. If implemented,
VTIMEZONE MUST also be implemented. VTIMEZONE MUST also be implemented.
LAST-MODIFIED Ignore LAST-MODIFIED Ignore
ORGANIZER Ignore ORGANIZER Ignore
RECURRENCE-ID Ignore RECURRENCE-ID Ignore
RELATED-TO Ignore RELATED-TO Ignore
RDATE Ignore. RDATE Ignore.
RRULE Ignore. The first instance occurs on the DTSTART RRULE Ignore. The first instance occurs on the DTSTART
property. If implemented, VTIMEZONE MUST also be property. If implemented, VTIMEZONE MUST also be
implemented. implemented.
skipping to change at line 4940 skipping to change at line 5012
either accept the reply or hold it until the related "REPLY" method is either accept the reply or hold it until the related "REPLY" method is
received from the "Delegator". If the version of the "REPLY" method is received from the "Delegator". If the version of the "REPLY" method is
out of date the "Organizer" SHOULD treat the message as a "REFRESH" out of date the "Organizer" SHOULD treat the message as a "REFRESH"
message and update the delegate with the correct version. message and update the delegate with the correct version.
5.3 Sequence Number 5.3 Sequence Number
Under some conditions, a CUA may receive requests and replies with the Under some conditions, a CUA may receive requests and replies with the
same "SEQUENCE" property value. The "DTSTAMP" property is utilized as a same "SEQUENCE" property value. The "DTSTAMP" property is utilized as a
Silverberg/Mansour/Daws/Hopson 93 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 92 - Expires December 1998
tie-breaker when two items with the same "SEQUENCE" property value are tie-breaker when two items with the same "SEQUENCE" property value are
evaluated. evaluated.
6 Security Considerations 6 Security Considerations
ITIP is an abstract transport protocol which will be bound to a real- ITIP is an abstract transport protocol which will be bound to a real-
time transport, a store-and-forward transport, and perhaps other time transport, a store-and-forward transport, and perhaps other
transports. The transport protocol will be responsible for providing transports. The transport protocol will be responsible for providing
facilities for authentication and encryption using standard Internet facilities for authentication and encryption using standard Internet
mechanisms that are mutually understood between the sender and receiver. mechanisms that are mutually understood between the sender and receiver.
skipping to change at line 4988 skipping to change at line 5061
"VTODO" the "Attendee's" CUA will detect that the "Organizer" has been "VTODO" the "Attendee's" CUA will detect that the "Organizer" has been
changed, but it has no way of knowing whether or not the change was changed, but it has no way of knowing whether or not the change was
mutually agreed upon. mutually agreed upon.
6.1.4 Eavesdropping 6.1.4 Eavesdropping
The iCalendar object is constructed with human-readable clear text. Any The iCalendar object is constructed with human-readable clear text. Any
information contained in an iCalendar object may be read and/or changed information contained in an iCalendar object may be read and/or changed
by unauthorized persons while the object is in transit. by unauthorized persons while the object is in transit.
Silverberg/Mansour/Daws/Hopson 94 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 93 - Expires December 1998
6.1.5 Flooding a Calendar 6.1.5 Flooding a Calendar
Implementations MAY provide a means to automatically incorporate Implementations MAY provide a means to automatically incorporate
"REQUEST" methods into a calendar. This presents the opportunity for a "REQUEST" methods into a calendar. This presents the opportunity for a
calendar to be flooded with requests, which effectively block all the calendar to be flooded with requests, which effectively block all the
calendar's free time. calendar's free time.
6.1.6 Procedural Alarms 6.1.6 Procedural Alarms
The "REQUEST" methods for "VEVENT" and "VTODO" calendar components MAY The "REQUEST" methods for "VEVENT" and "VTODO" calendar components MAY
skipping to change at line 5038 skipping to change at line 5112
of the sender. This sender may then be correlated to an "ATTENDEE" of the sender. This sender may then be correlated to an "ATTENDEE"
property in the iCalendar object. If the correlation is made and the property in the iCalendar object. If the correlation is made and the
sender is authorized to make the requested change or update then the sender is authorized to make the requested change or update then the
operation may proceed. It also allows the message to be encrypted to operation may proceed. It also allows the message to be encrypted to
prevent unauthorized reading of the message contents in transit. iTIP prevent unauthorized reading of the message contents in transit. iTIP
transport binding documents describe this process in detail. transport binding documents describe this process in detail.
Implementations MAY provide controls for users to disable this Implementations MAY provide controls for users to disable this
capability. capability.
Silverberg/Mansour/Daws/Hopson 95 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 94 - Expires December 1998
6.2.2 Implementation Controls 6.2.2 Implementation Controls
The threat of unauthorized replacement of the "Organizer" SHOULD be The threat of unauthorized replacement of the "Organizer" SHOULD be
mitigated by a calendar system that uses this protocol by providing mitigated by a calendar system that uses this protocol by providing
controls or alerts that make "Calendar Users" aware of such "Organizer" controls or alerts that make "Calendar Users" aware of such "Organizer"
changes and allowing them to decide whether or not the request should be changes and allowing them to decide whether or not the request should be
honored. honored.
The threat of flooding a calendar SHOULD be mitigated by a calendar The threat of flooding a calendar SHOULD be mitigated by a calendar
system that uses this protocol by providing controls that may be used to system that uses this protocol by providing controls that may be used to
skipping to change at line 5073 skipping to change at line 5148
be provided when a "REFRESH" request is received from these "Calendar be provided when a "REFRESH" request is received from these "Calendar
Users" as well. Users" as well.
7 Acknowledgments 7 Acknowledgments
A hearty thanks to the following individuals who have participated in A hearty thanks to the following individuals who have participated in
the drafting, review and discussion of this memo: the drafting, review and discussion of this memo:
Anik Ganguly, Dan Hickman, Paul Hill, Daryl Huff, Bruce Kahn, Antoine Anik Ganguly, Dan Hickman, Paul Hill, Daryl Huff, Bruce Kahn, Antoine
Leca, Bob Mahoney, John Noerenberg, Leo Parker, John Rose, Doug Royer, Leca, Bob Mahoney, John Noerenberg, Leo Parker, John Rose, Doug Royer,
Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun, Kevin Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun, Alexander
Tsurutome. Taler, Kevin Tsurutome.
8 Bibliography 8 Bibliography
[iCAL] "Internet Calendaring and Scheduling Core Object Specification - [iCAL] "Internet Calendaring and Scheduling Core Object Specification -
iCalendar", Internet-Draft, October 1997, ftp://ftp.ietf.org/internet- iCalendar", Internet-Draft, October 1997, ftp://ftp.ietf.org/internet-
drafts/draft-ietf-calsch-ical-07.txt. drafts/draft-ietf-calsch-ical-07.txt.
[ICMS] "Internet Calendaring Model Specification", Internet-Draft, [ICMS] "Internet Calendaring Model Specification", Internet-Draft,
October 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod- October 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-
03.txt. 03.txt.
[ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646",
Internet-Draft, July 1996, ftp://ftp.ietf.org/internet-drafts/draft- Internet-Draft, July 1996, ftp://ftp.ietf.org/internet-drafts/draft-
yergeau-utf8-01.txt. yergeau-utf8-01.txt.
Silverberg/Mansour/Daws/Hopson 96 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 95 - Expires December 1998
[iMIP] "iCalendar Message-Based Interoperability Protocol - iMIP", [iMIP] "iCalendar Message-Based Interoperability Protocol - iMIP",
Internet-Draft, October 1997, ftp://ftp.ietf.org/internet-drafts/draft- Internet-Draft, October 1997, ftp://ftp.ietf.org/internet-drafts/draft-
ietf-calsch-imip-05.txt. ietf-calsch-imip-05.txt.
[ISO8601] "Data elements and interchange formats - information [ISO8601] "Data elements and interchange formats - information
interchange - Representation of dates and times", ISO 8601, 1996-06-15, interchange - Representation of dates and times", ISO 8601, 1996-06-15,
+1 (212) 642-4900 for ANSI Sales. +1 (212) 642-4900 for ANSI Sales.
[VCAL] "vCalendar - The Electronic Calendaring and Scheduling Format - [VCAL] "vCalendar - The Electronic Calendaring and Scheduling Format -
Version 1.0", Versit Consortium, September 18, 1996, Version 1.0", Versit Consortium, September 18, 1996,
skipping to change at line 5144 skipping to change at line 5220
The following address information is provided in a MIME-VCARD, The following address information is provided in a MIME-VCARD,
Electronic Business Card, format. Electronic Business Card, format.
The authors of this draft are: The authors of this draft are:
BEGIN:VCARD BEGIN:VCARD
VERSION:2.1 VERSION:2.1
FN:Frank Dawson FN:Frank Dawson
ORG:Lotus Development Corporation ORG:Lotus Development Corporation
Silverberg/Mansour/Daws/Hopson 97 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 96 - Expires December 1998
ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613- ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-
3502;USA 3502;USA
TEL;WORK;MSG:+1-919-676-9515 TEL;WORK;MSG:+1-919-676-9515
TEL;WORK;FAX:+1-919-676-9564 TEL;WORK;FAX:+1-919-676-9564
EMAIL;INTERNET:Frank_Dawson@Lotus.com EMAIL;INTERNET:Frank_Dawson@Lotus.com
URL:http://home.earthlink.net/~fdawson URL:http://home.earthlink.net/~fdawson
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:2.1 VERSION:2.1
skipping to change at line 5199 skipping to change at line 5276
BEGIN:VCARD BEGIN:VCARD
FN:Anik Ganguly FN:Anik Ganguly
ORG:Campbel Services, Inc. ORG:Campbel Services, Inc.
ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern
Highway;Southfield;MI;48075;USA Highway;Southfield;MI;48075;USA
TEL;WORK;MSG:+1-248-559-5955 TEL;WORK;MSG:+1-248-559-5955
TEL;WORK;FAX:+1-248-559-5034 TEL;WORK;FAX:+1-248-559-5034
EMAIL;INTERNET:anik@ontime.com EMAIL;INTERNET:anik@ontime.com
Silverberg/Mansour/Daws/Hopson 98 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 97 - Expires December 1998
END:VCARD END:VCARD
10 Full Copyright Statement 10 Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
skipping to change at line 5229 skipping to change at line 5307
The limited permissions granted above are perpetual and will may be The limited permissions granted above are perpetual and will may be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN "AS THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN "AS
IS" BASIS AND THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" BASIS AND THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
Silverberg/Mansour/Daws/Hopson 99 Expires November 1998 Silverberg/Mansour/Dawson/Hopson - 98 - Expires December 1998
 End of changes. 116 change blocks. 
125 lines changed or deleted 203 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/