idnits 2.17.1 

draft-ietf-calsch-itip-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** Missing expiration date.  The document expiration date should appear on
     the first and last page.

  ** The document seems to lack a 1id_guidelines paragraph about
     Internet-Drafts being working documents. 

  ** The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  ** The document seems to lack a 1id_guidelines paragraph about the list of
     current Internet-Drafts. 

  ** The document seems to lack a 1id_guidelines paragraph about the list of
     Shadow Directories. 

  == Mismatching filename: the document gives the document name as
     'draft-calsch-itip-03', but the file name used is
     'draft-ietf-calsch-itip-03'

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  == The page length should not exceed 58 lines per page, but there was 97
     longer pages, the longest (page 1) being 62 lines


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** There are 4 instances of too long lines in the document, the longest one
     being 3 characters in excess of 72.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords -- however, there's a paragraph with a matching beginning.
     Boilerplate error?

     RFC 2119 keyword, line 464: '...DateTime values MAY refer to a "VTIMEZ...'
     RFC 2119 keyword, line 470: '...MEZONE           MUST be present if an...'
     RFC 2119 keyword, line 472: '...    LAST-MODIFIED   MAY...'
     RFC 2119 keyword, line 473: '...    TZID            MUST...'
     RFC 2119 keyword, line 474: '...    TZURL           MAY...'
     (849 more instances...)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == The "Author's Address" (or "Authors' Addresses") section title is
     misspelled.

  == Line 814 has weird spacing: '...rameter  of th...'

  -- The exact meaning of the all-uppercase expression 'MAY NOT' is not
     defined in RFC 2119.  If it is intended as a requirements expression, it
     should be rewritten using one of the combinations defined in RFC 2119;
     otherwise it should not be all-uppercase.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).
     
     Found 'MAY NOT' in this paragraph:
     
     VFREEBUSY           MUST ATTENDEE        MUST (address of recipient
     replying) DTSTAMP         MUST DTSTART         MUST DTEND           MUST
     FREEBUSY        MUST (values MUST all be of the same data type. Multiple
     instances are allowed. Multiple instances MUST be sorted in ascending
     order. Values MAY NOT overlap) ORGANIZER       MUST be the request
     originator's address RECURRENCE-ID   MUST only if referring to an
     instance of a recurring calendar component.  Otherwise it must NOT be
     present. UID             MUST

  == Couldn't figure out when the document was first submitted -- there may
     comments or warnings related to the use of a disclaimer for pre-RFC5378
     work that could not be issued because of this.  Please check the Legal
     Provisions document at https://trustee.ietf.org/license-info to determine
     if you need the pre-RFC5378 disclaimer.

  -- The document date (March 13, 1998) is 9541 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Missing reference section? 'ICMS' on line 4742 looks like a reference

  -- Missing reference section? 'ICAL' on line 4738 looks like a reference

  -- Missing reference section? 'ITIP' on line 267 looks like a reference

  -- Missing reference section? 'RFC 2119' on line 219 looks like a reference

  -- Missing reference section? 'IRIP' on line 340 looks like a reference

  -- Missing reference section? 'IMIP' on line 4750 looks like a reference

  -- Missing reference section? 'RFC1847' on line 4690 looks like a reference

  -- Missing reference section? 'ID-UTF8' on line 4746 looks like a reference

  -- Missing reference section? 'ISO8601' on line 4754 looks like a reference

  -- Missing reference section? 'VCAL' on line 4758 looks like a reference

  -- Missing reference section? 'VCARD' on line 4762 looks like a reference

  -- Missing reference section? 'RFC821' on line 4766 looks like a reference

  -- Missing reference section? 'RFC1983' on line 4769 looks like a reference

  -- Missing reference section? 'RFC2119' on line 4772 looks like a reference

  -- Missing reference section? 'RFC2045' on line 4775 looks like a reference

  -- Missing reference section? 'RFC2046' on line 4780 looks like a reference

  -- Missing reference section? 'UNICODE' on line 4784 looks like a reference

  -- Missing reference section? 'US-ASCII' on line 4788 looks like a reference


     Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 20 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group                       Steve Silverberg, Microsoft
3	INTERNET-DRAFT                                  Steve Mansour, Netscape
4	Calendaring and Scheduling Working Group            Frank Dawson, Lotus
5	<ietf-draft-calsch-itip-03.txt             Ross Hopson, ON Technologies
6	Expires in six months from                               March 13, 1998

8	       iCalendar Transport-Independent Interoperability Protocol
9	                                 (iTIP)
10	        Scheduling Events, BusyTime, To-dos and Journal Entries

12	Status of this Memo
13	This document is an Internet-Draft. Internet-Drafts are working
14	documents of the Internet Engineering Task Force (IETF), its areas, and
15	its working groups. Note that other groups may also distribute working
16	documents as Internet-Drafts.

18	Internet-Drafts are draft documents valid for a maximum of six months.
19	Internet-Drafts may be updated, replaced, or made obsolete by other
20	documents at any time. It is not appropriate to use Internet-Drafts as
21	reference material or to cite them other than as a "working draft" or
22	"work in progress".

24	To learn the current status of any Internet-Draft, please check the 1id-
25	abstracts.txt listing contained in the Internet-Drafts Shadow
26	Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
27	ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

29	Distribution of this document is unlimited.

31	Copyright (C) The Internet Society 1997. All Rights Reserved.

33	Abstract
34	This document specifies how calendaring systems use iCalendar objects to
35	interoperate with other calendar systems. It does so in a general way so
36	as to allow multiple methods of communication between systems.
37	Subsequent documents specify interoperable methods of communications
38	between systems that use this protocol.

40	The document outlines a model for calendar exchange that defines both
41	static and dynamic event, to-do, journal and free/busy objects. Static
42	objects are used to transmit information from one entity to another
43	without the expectation of continuity or referential integrity with the
44	original item. Dynamic objects are a superset of static objects and will
45	gracefully degrade to their static counterparts for clients that only
46	support static objects.

48	Table of Contents

50	1 INTRODUCTION.........................................................9

52	 1.1 FORMATTING CONVENTIONS ...........................................9
53	 1.2 RELATED DOCUMENTS ...............................................10
54	 1.3 ITIP ROLES AND TRANSACTIONS .....................................10

56	2 INTEROPERABILITY MODELS.............................................11

58	 2.1 APPLICATION PROTOCOL ............................................12
59	   2.1.1 Calendar Entry State ........................................12
60	   2.1.2 Delegation ..................................................13
61	   2.1.3 Acting on Behalf of other Calendar Users ....................13

63	3 APPLICATION PROTOCOL ELEMENTS.......................................13

65	 3.1 COMMON COMPONENT RESTRICTION TABLES .............................14
66	 3.2 METHODS FOR VEVENT CALENDAR COMPONENTS ..........................15
67	   3.2.1 PUBLISH .....................................................16
68	   3.2.2 REQUEST .....................................................17
69	     3.2.2.1 Rescheduling an Event....................................18
70	     3.2.2.2 Updating or Reconfirmation of an Event...................19
71	     3.2.2.3 Delegating an Event to another CU........................19
72	     3.2.2.4 Changing the Organizer...................................20
73	     3.2.2.5 Sending on Behalf of the Organizer.......................20
74	     3.2.2.6 Forwarding to An Uninvited CU............................20
75	     3.2.2.7 Updating Attendee Status.................................20
76	   3.2.3 REPLY .......................................................20
77	   3.2.4 ADD .........................................................22
78	   3.2.5 CANCEL ......................................................23
79	   3.2.6 REFRESH .....................................................25
80	   3.2.7 COUNTER .....................................................26
81	   3.2.8 DECLINECOUNTER ..............................................28
82	 3.3 METHODS FOR VFREEBUSY COMPONENTS ................................29
83	   3.3.1 PUBLISH .....................................................30
84	   3.3.2 REQUEST .....................................................31
85	   3.3.3 REPLY .......................................................32
86	 3.4 METHODS FOR VTODO COMPONENTS ....................................34
87	   3.4.1 PUBLISH .....................................................35
88	   3.4.2 REQUEST .....................................................36
89	     3.4.2.1 REQUEST for Rescheduling a VTODO.........................37
90	     3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO..........38
91	     3.4.2.3 REQUEST for Delegating a VTODO...........................38
92	     3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User..........39
93	     3.4.2.5 REQUEST Updated Attendee Status..........................39
94	   3.4.3 REPLY .......................................................39
95	   3.4.4 ADD .........................................................41
96	   3.4.5 CANCEL ......................................................42
97	   3.4.6 REFRESH .....................................................43
98	   3.4.7 COUNTER .....................................................45
99	   3.4.8 DECLINECOUNTER ..............................................46
100	 3.5 METHODS FOR VJOURNAL COMPONENTS .................................47
101	   3.5.1 PUBLISH .....................................................47
102	   3.5.2 ADD .........................................................49
103	   3.5.3 CANCEL ......................................................50
104	 3.6 STATUS REPLIES ..................................................51
105	 3.7 IMPLEMENTATION CONSIDERATIONS ...................................53
106	   3.7.1 Working With Recurrence Instances ...........................53
107	   3.7.2 Attendee Property Considerations ............................54
108	   3.7.3 X-Tokens ....................................................55

110	4 EXAMPLES............................................................55

112	 4.1 PUBLISHED EVENT EXAMPLES ........................................55
113	   4.1.1 A Minimal Published Event ...................................56
114	   4.1.2 Changing A Published Event ..................................56
115	   4.1.3 Canceling A Published Event .................................57
116	   4.1.4 A Rich Published Event ......................................57
117	   4.1.5 Anniversaries or Events attached to entire days .............58
118	 4.2 GROUP EVENT EXAMPLES ............................................59
119	   4.2.1 A Group Event Request .......................................60
120	   4.2.2 Reply To A Group Event Request ..............................60
121	   4.2.3 Update An Event .............................................61
122	   4.2.4 Countering an Event Proposal ................................61
123	   4.2.5 Delegating an Event .........................................63
124	   4.2.6 Delegate Accepts the Meeting ................................65
125	   4.2.7 Delegate Declines the Meeting ...............................66
126	   4.2.8 Forwarding an Event Request .................................67
127	   4.2.9 Cancel A Group Event ........................................67
128	   4.2.10 Removing Attendees .........................................68
129	   4.2.11 Replacing the Organizer ....................................69
130	 4.3 BUSY TIME EXAMPLES ..............................................70
131	   4.3.1 Request Busy Time ...........................................70
132	   4.3.2 Reply To A Busy Time Request ................................71
133	 4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ..........................71
134	   4.4.1 A Recurring Event Spanning Time Zones .......................71
135	   4.4.2 Modify A Recurring Instance .................................73
136	   4.4.3 Cancel an Instance ..........................................74
137	   4.4.4 Cancel Recurring Event ......................................75
138	   4.4.5 Change All Future Instances .................................75
139	   4.4.6 Add A New Instance To A Recurring Event .....................75
140	   4.4.7 Add A New Series of Instances To A Recurring Event ..........76
141	   4.4.8 Counter An Instance Of A Recurring Event ....................80
142	   4.4.9 Error Reply To A Request ....................................80
143	 4.5 GROUP TO-DO EXAMPLES ............................................81
144	   4.5.1 A VTODO Request .............................................82
145	   4.5.2 A VTODO Reply ...............................................83
146	   4.5.3 A VTODO Request for Updated Status ..........................83
147	   4.5.4 A Reply: Percent-Complete ...................................84
148	   4.5.5 A Reply: Completed ..........................................84
149	   4.5.6 An Updated VTODO Request ....................................84
150	   4.5.7 Recurring VTODOs ............................................85
151	     4.5.7.1 Request for a Recurring VTODO............................85
152	     4.5.7.2 Calculating due dates in recurring VTODOs................85
153	     4.5.7.3 Replying to an instance of a recurring VTODO.............86
154	 4.6 JOURNAL EXAMPLES ................................................86
155	 4.7 OTHER EXAMPLES ..................................................87
156	   4.7.1 Event Refresh ...............................................87
157	   4.7.2 Bad RECURRENCE-ID ...........................................87

159	5 APPLICATION PROTOCOL FALLBACKS......................................88

161	 5.1 PARTIAL IMPLEMENTATION ..........................................88
162	   5.1.1 Event-Related Fallbacks .....................................89
163	   5.1.2 To-Do-Related Fallbacks .....................................90
164	   5.1.3 Journal-Related Fallbacks ...................................92
165	 5.2 LATENCY ISSUES ..................................................93
166	   5.2.1 Cancellation of an Unknown Calendar Component. ..............93
167	   5.2.2 Unexpected Reply from an Unknown Delegate ...................93
168	 5.3 SEQUENCE NUMBER .................................................94

170	6 SECURITY CONSIDERATIONS.............................................94

172	 6.1 SECURITY THREATS ................................................94
173	   6.1.1 Spoofing the "Organizer" ....................................94
174	   6.1.2 Spoofing the "Attendee" .....................................94
175	   6.1.3 Unauthorized Replacement of the Organizer ...................95
176	   6.1.4 Eavesdropping ...............................................95
177	   6.1.5 Flooding a Calendar .........................................95
178	   6.1.6 Procedural Alarms ...........................................95
179	   6.1.7 Unauthorized REFRESH Requests ...............................95
180	 6.2 RECOMMENDATIONS .................................................95
181	   6.2.1 Use of [RFC1847] to secure iTIP transactions ................96
182	   6.2.2 Implementation Controls .....................................96

184	7 ACKNOWLEDGMENTS.....................................................96

186	8 BIBLIOGRAPHY........................................................97

188	9 AUTHORS ADDRESSES...................................................98

190	10 FULL COPYRIGHT STATEMENT...........................................99
191	1  Introduction

193	This document specifies how calendaring systems use iCalendar objects to
194	interoperate with other calendar systems. In particular, it specifies
195	how to schedule events, to-dos, or daily journal entries. It further
196	specifies how to search for available busy time information. It does so
197	in a general way so as to allow multiple methods of communication
198	between systems. Subsequent documents specify transport bindings between
199	systems that use this protocol.

201	This protocol is based on messages sent from an originator to one or
202	more recipients. For certain types of messages, a recipient may reply,
203	in order to update their status and may also return transaction/request
204	status information. The protocol supports the ability for the message
205	originator to modify or cancel the original message. The protocol also
206	supports the ability for recipients to suggest changes to the originator
207	of a message. The elements of the protocol also define the user roles
208	for its transactions.

210	1.1 Formatting Conventions

212	In order to refer to elements of the calendaring and scheduling model,
213	core object or interoperability protocol defined in [ICMS], [ICAL] and
214	[ITIP] several formatting conventions have been utilized.

216	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
217	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
218	document are to be interpreted as described in [RFC 2119].

220	Calendaring and scheduling roles described by [ICMS] are referred to in
221	quoted-strings of text with the first character of each word in upper
222	case. For example, "Organizer" refers to a role of a "Calendar User"
223	(CU) within the scheduling protocol defined by [ITIP]. Calendar
224	components defined by [ICAL] are referred to with capitalized, quoted-
225	strings of text. All calendar components start with the letter "V". For
226	example, "VEVENT" refers to the event calendar component, "VTODO" refers
227	to the to-do calendar component and "VJOURNAL" refers to the daily
228	journal calendar component. Scheduling methods defined by [ITIP] are
229	referred to with capitalized, quoted-strings of text. For example,
230	"REQUEST" refers to the method for requesting a scheduling calendar
231	component be created or modified, "REPLY" refers to the method a
232	recipient of a request uses to update their status with the "Organizer"
233	of the calendar component.

235	Properties defined by [ICAL] are referred to with capitalized, quoted-
236	strings of text, followed by the word "property". For example,
237	"ATTENDEE" property refers to the iCalendar property used to convey the
238	calendar address of a "Calendar User". Property parameters defined by
239	this memo are referred to with lower case, quoted-strings of text,
240	followed by the word "parameter". For example, "value" parameter refers
241	to the iCalendar property parameter used to override the default data
242	type for a property value. Enumerated values defined by this memo are
243	referred to with capitalized text, either alone or followed by the word
244	"value".

246	In tables, the quoted-string text is specified without quotes in order
247	to minimize the table length.

249	1.2 Related Documents

251	Implementers will need to be familiar with several other memos that,
252	along with this one, describe the Internet calendaring and scheduling
253	standards. This document, [ITIP], specifies an interoperability protocol
254	for scheduling between different implementations. The related documents
255	are:

257	     [ICMS] - describes the abstract model and defines common terms and
258	     concepts;

260	     [ICAL] - specifies the objects, data types, properties and property
261	     parameters used in the protocols, along with the methods for
262	     representing and encoding them;

264	     [IRIP] - specifies an Internet real time protocol binding for
265	     [ITIP];

267	     [IMIP] specifies an Internet email binding for [ITIP].

269	This memo does not attempt to repeat the specification of concepts or
270	definitions from these other memos. Where possible, references are made
271	to the memo that provides for the specification of these concepts or
272	definitions.

274	1.3 ITIP Roles and Transactions

276	ITIP defines seven methods for exchanging [ICAL] objects for the
277	purposes of group calendaring and scheduling between "Calendar Users"
278	(CUs). CUs take on one of two roles in iTIP. The CU who initiates an
279	exchange takes on the role of "Organizer". For example, the CU who
280	proposes a group meeting is the "Organizer". The CUs asked to
281	participate in the group meeting by the "Organizer" take on the role of
282	"Attendee". Note that  "role" is also a descriptive parameter to the
283	_ATTENDEE_ property. Its use is to convey descriptive context to an
284	"Attendee" such as "chair", "req-participant" or "non-participant" and
285	has nothing to do with the calendaring workflow.

287	The ITIP methods are defined below and their usage and semantics are
288	outlined in section 3 of this document.

290	+================+==================================================+
291	| Method         |  Description                                     |
292	|================+==================================================|
293	| PUBLISH        | Used to publish a calendar entry to one or more  |
294	|                | Calendar Users. There is no interactivity        |
295	|                | between the publisher and any other calendar     |
296	|                | user. An example might include a baseball team   |
297	|                | publishing its schedule to the public.           |
298	|                |                                                  |
299	| REQUEST        | Used to schedule a calendar entry with other     |
300	|                | Calendar Users. Requests are interactive in that |
301	|                | they require the receiver to respond using       |
302	|                | the the Reply methods. Meeting Requests, Busy    |
303	|                | Time requests and the assignment of VTODOs to    |
304	|                | other Calendar Users are all examples.           |
305	|                | Requests are also used by the "Organizer" to     |
306	|                | update the status of a calendar entry.           |
307	|                |                                                  |
308	| REPLY          | A Reply is used in response to a Request to      |
309	|                | convey "Attendee" status to the "Organizer".     |
310	|                | Replies are commonly used to respond to meeting  |
311	|                | and task requests.                               |
312	|                |                                                  |
313	| ADD            | Add one or more instances to an existing         |
314	|                | VEVENT, VTODO, or VJOURNAL.                      |
315	|                |                                                  |
316	| CANCEL         | Cancel one or more instances of an existing      |
317	|                | VEVENT, VTODO, or VJOURNAL.                      |
318	|                |                                                  |
319	| REFRESH        | The Refresh method is used by an "Attendee" to   |
320	|                | request the latest version of a calendar entry.  |
321	|                |                                                  |
322	| COUNTER        | The Counter method is used by an "Attendee" to   |
323	|                | negotiate a change in the calendar entry.        |
324	|                | Examples include the request to change a         |
325	|                | proposed Event time or change the due date for a |
326	|                | VTODO.                                           |
327	|                |                                                  |
328	| DECLINE-       | Used by the "Organizer" to decline the proposed  |
329	| COUNTER        | counter-proprosal.                               |
330	+================+==================================================+

332	2  Interoperability Models

334	There are two distinct protocols relevant to interoperability: an
335	"Application Protocol" and a "Transport Protocol". The Application
336	Protocol defines the content of the iCalendar objects sent between
337	sender and receiver to accomplish the scheduling transactions described
338	above. The Transport Protocol defines how the iCalendar objects are sent
339	between the sender and receiver. This document focuses on the
340	Application Protocol. Binding documents such as [IMIP] and [IRIP] focus
341	on the Transport Protocol.

343	The connection between Sender and Receiver in the diagram below refers
344	to the Application Protocol. The iCalendar objects passed from the
345	Sender to the Receiver are presented in Section 3, Application Protocol
346	Elements.

348	+----------+                      +----------+
349	|          |        iTIP          |          |
350	|  Sender  |<-------------------->| Receiver |
351	|          |                      |          |
352	+----------+                      +----------+

354	There are several variations of this diagram in which the Sender and
355	Receiver take on various roles of a "Calendar User Agent" (CUA) or a
356	"Calendar Service" (CS). These variants are detailed in the Model
357	document [ICMS].

359	The architecture of iTIP is depicted in the diagram below. An
360	application written to this specification may work with bindings for the
361	store-and-forward transport, the real time transport, or both. Also note
362	that iTIP could be bound to other transports.

364	+------------------------------------------+
365	|                   iTIP                   |
366	+------------------------------------------+
367	|Real-time | Store-and-Fwd | Other         |
368	|Transport | Transport     | Transports... |
369	+------------------------------------------+

371	2.1 Application Protocol

373	The iTIP model is in which a calendar entry is created and managed by an
374	"Organizer". The "Organizer" interacts with other CUs by sending one or
375	more of the iTIP messages described above. "Attendees" use the "REPLY"
376	method to communicate their status. "Attendees" do not make direct
377	changes to the master calendar entry. They can, however, use the
378	"COUNTER" method to suggest changes to the "Organizer". The "Organizer"
379	has complete control over the master calendar entry.

381	2.1.1     Calendar Entry State

383	There are two distinct states relevant to calendar entries: the overall
384	state of the entry and the state associated with an "Attendee" to that
385	entry.

387	The state of an entry is defined by the "STATUS" property and is
388	controlled by the "Organizer." There is no default value for the
389	"STATUS" property. The "Organizer" sets the "STATUS" property to the
390	appropriate value for each calendar entry.

392	The state of a particular "Attendee" relative to an entry is defined by
393	the "attstat" parameter in the "ATTENDEE" property for each "Attendee".
394	When an "Organizer" issues the initial entry, "Attendee" status is
395	unknown. The "Organizer" specifies this by setting the "attstat"
396	parameter to "needs-action". Each "Attendee" modifies their "ATTENDEE"
397	property "attstat" parameter to an appropriate value as part of a
398	"REPLY" message sent back to the "Organizer".

400	2.1.2     Delegation

402	Delegation is defined as the process by which an "Attendee" grants
403	another CU (or several CUs) the right to attend on their behalf. The
404	"Organizer" is made aware of this change because the delegating
405	"Attendee" informs the "Organizer" of this change. These steps are
406	detailed in the REQUEST method section.

408	2.1.3     Acting on Behalf of other Calendar Users

410	In many organizations one user will act on behalf of another to organize
411	and/or respond to meeting requests. ITIP provides two mechanisms that
412	support these activities.

414	First, the "Organizer" is treated as a special entity, separate from
415	"Attendees". All responses from "Attendees" flow to the "Organizer",
416	making it easy to separate a calendar user organizing a meeting from
417	calendar users attending the meeting. Additionally, iCalendar provides
418	descriptive roles for each "Attendee". For instance, a role of "chair"
419	may be ascribed to one or more "Attendees". The "chair and the
420	"Organizer" may or may not be the same calendar user. This maps well to
421	scenarios where an assistant may manage meeting logistics for another
422	individual who chairs a one-time or recurring meeting.

424	Second, a "sent-by" parameter may be specified in either the "Organizer"
425	or "Attendee" properties. When specified, the "sent-by" parameter
426	indicates that the responding CU acted on behalf of the specified
427	"Attendee" or "Organizer".

429	3 Application Protocol Elements

431	ITIP messages are "text/calendar" MIME entities that contain calendaring
432	and scheduling information. The particular type of [ICAL] message is
433	referred to as the "method type". Each method type is identified by a
434	"METHOD" property specified as part of the "text/calendar" content type.
435	The table below shows various combinations of calendar components and
436	the method types that this memo supports.

438	+=================================================+
439	|         | VEVENT | VTODO | VJOURNAL | VFREEBUSY |
440	|=================================================|
441	|Publish  |  Yes   |  Yes  |  Yes     |   Yes     |
442	|Request  |  Yes   |  Yes  |  No      |   Yes     |
443	|Refresh  |  Yes   |  Yes  |  No      |   No      |
444	|Cancel   |  Yes   |  Yes  |  Yes     |   No      |
445	|Add      |  Yes   |  Yes  |  Yes     |   No      |
446	|Reply    |  Yes   |  Yes  |  No      |   Yes     |
447	|Counter  |  Yes   |  Yes  |  No      |   No      |
448	|Decline- |        |       |          |           |
449	|Counter  |  Yes   |  Yes  |  No      |   No      |
450	+=================================================+
451	Each method type is defined in terms of its associated components and
452	properties. Some components and properties are required, some are
453	optional and others are excluded. The restrictions are expressed in this
454	document using a simple "restriction table". The first column indicates
455	the name of a component or property. Properties of the iCalendar object
456	are not indented. Properties of a component are indented. The second
457	column contains "MUST" if the component or property must be present,
458	"MAY" if the component or property is optional, and "NOT" if the
459	component or property must not be present. Entries in the second column
460	sometimes contain comments for further clarification.

462	3.1 Common Component Restriction Tables

464	DateTime values MAY refer to a "VTIMEZONE" component. The property
465	restrictions in the table below apply to any "VTIMEZONE" component in an
466	ITIP message.

468	Component/Property  Presence
469	------------------- ----------------------------------------------
470	VTIMEZONE           MUST be present if any date/time refers to a
471	                        timezone
472	    LAST-MODIFIED   MAY
473	    TZID            MUST
474	    TZURL           MAY
475	    STANDARD        MUST
476	       DTSTART      MUST be present if RRULE is present
477	       TZOFFSETFROM MUST
478	       TZOFFSETTO   MUST
479	       COMMENT      MAY
480	       RDATE        MAY be present, if present RRULE must not be
481	                        present
482	       RRULE        MAY be present, if present RDATE must not be
483	                        present
484	       TZNAME       MAY
485	    DAYLIGHT        MAY
486	      DTSTART       MUST
487	      TZOFFSET      MUST
488	      COMMENT       MAY
489	      RDATE         MAY be present, if present RRULE must not be
490	                        present
491	      RRULE         MAY be present, if present RDATE must not be
492	                        present
493	      TZNAME        MAY

495	The property restrictions in the table below apply to any "VALARM"
496	component in an ITIP message.

498	Component/Property  Presence
499	------------------- ----------------------------------------------
500	VALARM              MAY
501	    ALARM-TYPE      MUST
502	    DURATION        MUST
503	    REPEAT          MUST
504	    TRIGGER         MUST
505	    ATTACH          MAY
506	    DESCRIPTION     MAY
507	    SUMMARY         MAY
508	    COMMENT         NOT
509	    CREATED         NOT
510	    LAST-MODIFIED   NOT
511	    RELATED-TO      NOT
512	    URL             NOT

514	3.2 Methods for VEVENT Calendar Components

516	This section defines the property set restrictions for the method types
517	that are applicable to the "VEVENT" calendar component. Each method is
518	defined using a table that clarifies the property constraints that
519	define the particular method.

521	The following summarizes the methods that are defined for the "VEVENT"
522	calendar component.

524	+================+==================================================+
525	| Method         |  Description                                     |
526	|================+==================================================|
527	| PUBLISH        | Post notification of an event. Used primarily as |
528	|                | a method of advertising the existence of an      |
529	|                | event.                                           |
530	|                |                                                  |
531	| REQUEST        | Make a request for an event. This is an explicit |
532	|                | invitation to one or more "Attendees". Event     |
533	|                | Requests are also used to update or change an    |
534	|                | existing event. Clients that cannot handle       |
535	|                | REQUEST may degrade the event to view it as an   |
536	|                | PUBLISH.                                         |
537	|                |                                                  |
538	| REPLY          | Reply to an event request. Clients may set their |
539	|                | status ("attstat") to ACCEPTED, DECLINED,        |
540	|                | TENTATIVE, or DELEGATED.                         |
541	|                |                                                  |
542	| ADD            | Add one or more instances to an existing event.  |
543	|                |                                                  |
544	| CANCEL         | Cancel one or more instances of an existing      |
545	|                | event.                                           |
546	|                |                                                  |
547	| REFRESH        | A request is sent to an "Organizer" by an        |
548	|                | "Attendee" asking for the latest version of an   |
549	|                | event to be resent to the requester.             |
550	|                |                                                  |
551	| COUNTER        | Counter a REQUEST with an alternative proposal,  |
552	|                | Sent by an "Attendee" to the "Organizer".        |
553	|                |                                                  |
554	| DECLINECOUNTER | Decline a counter proposal. Sent to an           |
555	|                | "Attendee" by the "Organizer".                   |
556	+================+==================================================+

558	3.2.1     PUBLISH

560	The "PUBLISH" method in a "VEVENT" calendar component is an unsolicited
561	posting of an iCalendar object. Any CU may add published components to
562	their calendar. The "Organizer" MUST be present in a published iCalendar
563	component. Other "Attendees" MAY be present. However, no replies are
564	expected. Its expected usage is for encapsulating an arbitrary event as
565	an iCalendar object. The "Organizer" may subsequently update (with
566	another "PUBLISH" method), add instances to (with an "ADD" method), or
567	cancel (with a "CANCEL" method) a previously published "VEVENT" calendar
568	component.

570	This method type is an iCalendar object that conforms to the following
571	property constraints:

573	Component/Property  Presence
574	------------------- ----------------------------------------------
575	PRODID              MUST
576	VERSION             MUST be "2.0"
577	METHOD              MUST be "PUBLISH"
578	VEVENT              MUST
579	     DTSTAMP        MUST
580	     DTSTART        MUST
581	     ORGANIZER      MUST
582	     RECURRENCE-ID  MUST only if referring to an instance of a
583	                        recurring calendar component.  Otherwise it
584	                        must NOT be present.
585	     SEQUENCE       MUST be present if not 0, may be present if 0
586	     SUMMARY        MUST; may be null.
587	     UID            MUST

589	     ATTENDEE       MAY
590	     ATTACH         MAY
591	     CATEGORIES     MAY
592	     CLASS          MAY
593	     COMMENT        MAY
594	     CONTACT        MAY
595	     CREATED        MAY
596	     DESCRIPTION    MAY be present and MAY be NULL
597	     DTEND          MAY
598	     EXDATE         MAY
599	     EXRULE         MAY
600	     GEO            MAY
601	     LAST-MODIFIED  MAY
602	     LOCATION       MAY
603	     PRIORITY       MAY
604	     RELATED-TO     MAY
605	     RDATE          MAY
606	     RESOURCES      MAY
607	     RRULE          MAY
608	     STATUS         MAY be one of TENTATIVE/CONFIRMED/CANCELLED
609	     TRANSP         MAY
610	     URL            MAY

612	     DURATION       NOT

614	VTODO               NOT
615	VJOURNAL            NOT

617	VTIMEZONE           MUST be present if any date/time refers to a
618	                        timezone
619	VALARM              MAY
620	VFREEBUSY           NOT
621	X-TOKENS            MAY

623	3.2.2     REQUEST

625	The "REQUEST" method in a "VEVENT" component provides the following
626	scheduling functions:

628	. Invite "Attendees" to an event;
629	. Reschedule an existing event;
630	. Update the details of an existing event, without rescheduling it;
631	. Update the status of "Attendees" of an existing event, without
632	  rescheduling it;
633	. Reconfirm an existing event, without rescheduling it;
634	. To forward a VEVENT to another uninvited CU.
635	. For an existing "VEVENT" calendar component, delegate the role of
636	  "Attendee" to another CU;
637	. For an existing "VEVENT" calendar component, changing the role of
638	  "Organizer" to another CU.

640	The "Organizer" originates the "REQUEST". The recipients of the
641	"REQUEST" method are the CUs invited to the event, the "Attendees".
642	"Attendees" use the "REPLY" method to convey attendance status to the
643	"Organizer".

645	The "UID" and "SEQUENCE" properties are used to distinguish the various
646	uses of the "REQUEST" method. If the "UID" property value in the
647	"REQUEST" is not found on the recipient's calendar, then the "REQUEST"
648	is for a new "VEVENT" calendar component. If the "UID" property value is
649	found on the recipient's calendar, then the "REQUEST" is for a
650	rescheduling, an update, or a reconfirm of the "VEVENT" calendar
651	component.

653	This method type is an iCalendar object that conforms to the following
654	property constraints:

656	Component/Property  Presence
657	------------------- ----------------------------------------------
658	PRODID              MUST
659	VERSION             MUST be "2.0"
660	METHOD              MUST be "REQUEST"
661	VEVENT              MUST
662	    ATTENDEE        MUST
663	    DTSTAMP         MUST
664	    DTSTART         MUST
665	    ORGANIZER       MUST
666	    RECURRENCE-ID   MUST only if referring to an instance of a
667	                        recurring calendar component.  Otherwise it
668	                        must NOT be present.
669	    SEQUENCE        MUST be present if non-zero, may be present if zero
670	    SUMMARY         MUST be present, may be NULL
671	    UID             MUST

673	    ATTACH          MAY
674	    CATEGORIES      MAY
675	    CLASS           MAY
676	    COMMENT         MAY
677	    CONTACT         MAY
678	    CREATED         MAY
679	    DESCRIPTION     MAY be present and may be NULL
680	    DTEND           MAY
681	    EXDATE          MAY
682	    EXRULE          MAY
683	    GEO             MAY
684	    LAST-MODIFIED   MAY
685	    LOCATION        MAY
686	    PRIORITY        MAY
687	    RDATE           MAY
688	    RELATED-TO      MAY
689	    RESOURCES       MAY
690	    RRULE           MAY
691	    STATUS          MAY be one of TENTATIVE/CONFIRMED
692	    TRANSP          MAY
693	    URL             MAY

695	    DURATION        NOT
696	    REQUEST-STATUS  NOT

698	VTODO               NOT
699	VJOURNAL            NOT
700	VTIMEZONE           MUST be present if any date/time refers to a
701	                        timezone
702	VALARM              MAY
703	VFREEBUSY           NOT
704	X-TOKENS            MAY

706	3.2.2.1   Rescheduling an Event

708	The "REQUEST" method may be used to reschedule an event. A rescheduled
709	event involves a change to the existing event in terms of its time or
710	recurrence intervals and possibly the location or description. If the
711	recipient CUA of a "REQUEST" method finds that the "UID" property value
712	already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP")
713	property value in the "REQUEST" method is greater than the value for the
714	existing event, then the "REQUEST" method describes a rescheduling of
715	the event.

717	3.2.2.2   Updating or Reconfirmation of an Event

719	The "REQUEST" method may be used to update or reconfirm an event. An
720	update to an existing event does not involve changes to the time or
721	recurrence intervals, and might not involve a change to the location or
722	description for the event. If the recipient CUA of a "REQUEST" method
723	finds that the "UID" property value already exists on the calendar and
724	that the "SEQUENCE" property value in the "REQUEST" is the same as the
725	value for the existing event, then the "REQUEST" method describes an
726	update of the event details, but no rescheduling of the event.

728	The update "REQUEST" method is the appropriate response to a "REFRESH"
729	method sent from an "Attendee" to the "Organizer" of an event.

731	The "Organizer" of an event may also send unsolicited "REQUEST" methods.
732	The unsolicited "REQUEST" methods may be used to update the details of
733	the event without rescheduling it, to update the "attstat" parameter of
734	"Attendees", or to reconfirm the event.

736	3.2.2.3   Delegating an Event to another CU

738	Some calendar and scheduling systems allow "Attendees" to delegate their
739	presence at an event to another calendar user. ITIP supports this
740	concept using the following workflow. Any "Attendee" may delegate their
741	right to participate in a calendar VEVENT to another CU. The implication
742	is that the delegate participates in lieu of the original "Attendee";
743	NOT in addition to the "Attendee". The delegator MUST notify the
744	"Organizer" of this action using the steps outlined below.
745	Implementations may support or restrict delegation as they see fit. For
746	instance, some implementations may restrict a delegate from delegating a
747	"REQUEST" to another CU.

749	The "Delegator" of an event forwards the existing "REQUEST" to the
750	"Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
751	with the calendar address of the "Delegate". The "Delegator" MUST also
752	send a "REPLY" method to the "Organizer" with the "Delegator's"
753	"ATTENDEE" property "attstat" parameter value set to "delegated". In
754	addition, the "delegated-to" parameter MUST be included with the
755	calendar address of the "Delegate".

757	In response to the request, the "Delegate" MUST send a "REPLY" method to
758	the "Organizer" and optionally, to the "Delegator". The "REPLY" method "
759	SHOULD include the "ATTENDEE" property with the "delegated-from"
760	parameter value of the "Delegator's" calendar address.

762	3.2.2.4   Changing the Organizer

764	The situation may arise where the "Organizer" of a VEVENT is no longer
765	able to perform the "Organizer" role and abdicates without passing on
766	the "Organizer" role to someone else. When this occurs the "Attendees"
767	of the VEVENT may use out-of-band mechanisms to communicate the
768	situation and agree upon a new "Organizer".  The new "Organizer" should
769	then send out a new "REQUEST" with a modified version of the VEVENT in
770	which the "SEQUENCE" number has been incremented and value of the
771	"ORGANIZER" property has been changed to the calendar address of the new
772	"Organizer".

774	3.2.2.5   Sending on Behalf of the Organizer

776	There are a number of scenarios that support the need for a calendar
777	user to act on behalf of the "Organizer" without explicit role changing.
778	This might be the case if the CU designated as "Organizer" was sick or
779	unable to perform duties associated with that function. In these cases
780	iTIP supports the notion of one CU acting on behalf of another. Using
781	the "sent-by" parameter, a calendar user could send an updated "VEVENT"
782	REQUEST. In the case where one CU sends on behalf of another CU, the
783	"Attendee" responses are still directed back towards the CU designated
784	as "Organizer".

786	3.2.2.6   Forwarding to An Uninvited CU

788	An "Attendee" invited to an event may invite another uninvited CU to the
789	event. The invited "Attendee" accomplishes this by forwarding the
790	original "REQUEST" method to the uninvited CU. Whether the uninvited CU
791	is added to the attendee list, and thus informed of changes to the
792	"VEVENT" calendar component, is an issue left to individual
793	implementations. It is not required. It is important to note that when
794	forwarding a "REQUEST" to another CU, the forwarding "Attendee" MUST NOT
795	make changes to the VEVENT property set.

797	3.2.2.7   Updating Attendee Status

799	The "Organizer" of an event may also request updated status from one or
800	more "Attendees. The "Organizer" sends a "REQUEST" method to the
801	"Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
802	"SEQUENCE" property for the event is not changed from its previous
803	value. A recipient will determine that the only change in the "REQUEST"
804	is that their "RSVP" property parameter indicates a request for updated
805	status. The recipient SHOULD respond with a "REPLY" method indicating
806	their current status with respect to the "REQUEST".

808	3.2.3     REPLY

810	The "REPLY" method in a "VEVENT" calendar component is used to respond
811	(e.g., accept or decline) to a "REQUEST" or to reply to a delegation
812	"REQUEST". When used to provide a delegation response, the "Delegator"
813	SHOULD include the calendar address of the "Delegate" on the "delegated-
814	to" property parameter  of the "Delegator's" "ATTENDEE" property. The
815	"Delegate" SHOULD include the calendar address of the "Delegator" on the
816	"delegated-from" property parameter of the "Delegate's" "ATTENDEE"
817	property.

819	The "REPLY" method may also be used to respond to an unsuccessful
820	"REQUEST" method. Depending on the value of the "REQUEST-STATUS"
821	property no scheduling action may have been performed.

823	The "Organizer" of an event may receive the "REPLY" method from a CU not
824	in the original "REQUEST". For example, a "REPLY" may be received from a
825	"Delegate" to an event. In addition, the "REPLY" method may be received
826	from an unknown CU (a "Party Crasher"). This uninvited "Attendee" may be
827	accepted, or the "Organizer" may cancel the event for the uninvited
828	"Attendee" by sending a "CANCEL" method to the uninvited "Attendee".

830	The "Organizer" may also receive a "REPLY" from one CU on behalf of
831	another. Like the scenario enumerated above for the "Organizer",
832	"Attendees" may have another CU respond on their behalf. This is done
833	using the "sent-by" parameter.

835	The optional properties listed in the table below (those listed as
836	"MAY") MUST NOT be changed from those of the original request.  If
837	property changes are desired the COUNTER message must be used.

839	This method type is an iCalendar object that conforms to the following
840	property constraints:

842	Component/Property  Presence
843	------------------- ----------------------------------------------
844	PRODID              MUST
845	VERSION             MUST be "2.0"
846	METHOD              MUST be "REPLY"

848	VEVENT              MUST
849	    ATTENDEE        MUST be the address of the Attendee replying.
850	    DTSTAMP         MUST
851	    ORGANIZER       MUST
852	    RECURRENCE-ID   MUST only if referring to an instance of a
853	                        recurring calendar component.  Otherwise it
854	                        must NOT be present.
855	    SEQUENCE        MUST if non-zero
856	    UID             MUST be the UID of the original REQUEST

858	    ATTACH          MAY
859	    COMMENT         MAY
860	    CONTACT         MAY
861	    EXDATE          MAY
862	    EXRULE          MAY
863	    REQUEST-STATUS  MAY

865	    CATEGORIES      MAY
866	    CLASS           MAY
867	    CREATED         MAY
868	    DESCRIPTION     MAY
869	    DTSTART         MAY
870	    DTEND           MAY
871	    DURATION        MAY
872	    GEO             MAY
873	    LAST-MODIFIED   MAY
874	    PRIORITY        MAY
875	    RELATED-TO      MAY
876	    RESOURCES       MAY
877	    RDATE           MAY
878	    RRULE           MAY
879	    STATUS          MAY
880	    SUMMARY         MAY
881	    TRANSP          MAY
882	    URL             MAY

884	VTIMEZONE           MUST be present if any date/time refers to a
885	                        timezone
886	X-TOKENS            NOT
887	VTODO               NOT
888	VJOURNAL            NOT
889	VFREEBUSY           NOT
890	VALARM              NOT

892	3.2.4     ADD

894	The "ADD" method in a "VEVENT" calendar component is used to add one or
895	more instances to an existing "VEVENT". Unlike the "REQUEST" method,
896	when using issuing an "ADD" method, the "Organizer" does not send the
897	full "VEVENT" description; only the new instance(s). The "ADD" method is
898	especially useful if there are instance-specific properties to be
899	preserved in a recurring "VEVENT". For instance, an "Organizer" may have
900	originally scheduled a weekly Thursday meeting. At some point, several
901	instances changed. Location or start time may have changed, or some
902	instances may have unique "DESCRIPTION" properties. The "ADD" method
903	allows the "Organizer" to add new instances to an existing event using a
904	single ITIP message without redefining the entire recurring pattern.

906	The "UID" must be that of the existing event. If the "UID" property
907	value in the "ADD" is not found on the recipient's calendar, then the
908	recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
909	updated with the latest version of the "VEVENT".  If an "Attendee"
910	implementation does not support the "ADD" method it should respond with
911	a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH".

913	This method type is an iCalendar object that conforms to the following
914	property constraints:

916	Component/Property  Presence
917	------------------- ----------------------------------------------
918	PRODID              MUST
919	VERSION             MUST be "2.0"
920	METHOD              MUST be "ADD"
921	VEVENT              MUST
922	DTSTAMP         MUST
923	    DTSTART         MUST
924	    ORGANIZER       MUST
925	    SEQUENCE        MUST be greater than 0
926	    SUMMARY         MUST be present, may be NULL
927	    UID             MUST match that of the original event

929	    ATTACH          MAY
930	    ATTENDEE        MAY
931	    CATEGORIES      MAY
932	    CLASS           MAY
933	    COMMENT         MAY
934	    CONTACT         MAY
935	    CREATED         MAY
936	    DESCRIPTION     MAY be present and may be NULL
937	    DTEND           MAY
938	    EXDATE          MAY
939	    EXRULE          MAY
940	    GEO             MAY
941	    LAST-MODIFIED   MAY
942	    LOCATION        MAY
943	    PRIORITY        MAY
944	    RDATE           MAY
945	    RELATED-TO      MAY
946	    RESOURCES       MAY
947	    RRULE           MAY
948	    STATUS          MAY be one of TENTATIVE/CONFIRMED
949	    TRANSP          MAY
950	    URL             MAY

952	    DURATION        NOT
953	    RECURRENCE-ID   NOT
954	    REQUEST-STATUS  NOT

956	VTODO               NOT
957	VJOURNAL            NOT
958	VTIMEZONE           MUST be present if any date/time refers to a
959	                        timezone
960	VALARM              MAY
961	VFREEBUSY           NOT
962	X-TOKENS            MAY

964	3.2.5     CANCEL

966	The "CANCEL" method in a "VEVENT" calendar component is used to send a
967	cancellation notice of an existing event request to the "Attendees". The
968	message is sent by the "Organizer" of the event. For a recurring event,
969	either the whole event or instances of an event may be cancelled. To
970	cancel the complete range of recurring event, the "UID" property value
971	for the event MUST be specified and a "RECURRENCE-ID" MUST NOT be
972	specified in the "CANCEL" method. In order to cancel an individual
973	instance of the event, the "RECURRENCE-ID" property value for the event
974	MUST be specified in the "CANCEL" method.

976	There are two options for canceling a sequence of instances of a
977	recurring "VEVENT" calendar component:

979	(a)    the "RECURRENCE-ID" property for an instance in the sequence MUST be
980	  specified with the "RANGE" property parameter value of THISANDPRIOR
981	  (or THISANDFUTURE)  to indicate cancellation of the specified
982	  "VEVENT" calendar component and all instances before (or after); or

984	(b)    individual recurrence instances may be cancelled by specifying
985	  multiple "RECURRENCE-ID" properties corresponding to the instances to
986	  be cancelled.

988	This method type is an iCalendar object that conforms to the following
989	property constraints:

991	Component/Property  Presence
992	------------------- ----------------------------------------------
993	PRODID              MUST
994	VERSION             MUST be "2.0"
995	METHOD              MUST be "CANCEL"

997	VEVENT              MUST
998	    DTSTAMP         MUST
999	    ORGANIZER       MUST
1000	    RECURRENCE-ID   MUST only if referring to one or more instances of
1001	                        a recurring calendar component.  Otherwise it
1002	                        MUST NOT be present.
1003	    SEQUENCE        MUST
1004	    UID             MUST be the UID of the original REQUEST

1006	    COMMENT         MAY
1007	    STATUS          Must be set to "Cancelled". If uninviting specific
1008	                        "Attendees" then MUST NOT be included.

1010	    ATTACH          MAY
1011	    ATTENDEE        MAY
1012	    CATEGORIES      MAY
1013	    CLASS           MAY
1014	    CONTACT         MAY
1015	    CREATED         MAY
1016	    DESCRIPTION     MAY
1017	    DTSTART         MAY
1018	    DURATION        MAY
1019	    DTEND           MAY
1020	    EXDATE          MAY
1021	    EXRULE          MAY
1022	    GEO             MAY
1023	    LAST-MODIFIED   MAY
1024	    PRIORITY        MAY
1025	    RELATED-TO      MAY
1026	    REQUEST-STATUS  MAY
1027	    RESOURCES       MAY
1028	    RDATE           MAY
1029	    RRULE           MAY
1030	    STATUS          MAY
1031	    SUMMARY         MAY
1032	    TRANSP          MAY
1033	    URL             MAY

1035	VTIMEZONE           MUST be present if any date/time refers to a
1036	                        timezone

1038	X-TOKENS            MAY
1039	VTODO               NOT
1040	VJOURNAL            NOT
1041	VFREEBUSY           NOT
1042	VALARM              NOT

1044	3.2.6     REFRESH

1046	The "REFRESH" method in a "VEVENT" calendar component is used by
1047	"Attendees" of an existing event to request an updated description from
1048	the event "Organizer". The "REFRESH" method must specify the "UID"
1049	property of the event to update. A recurrence instance of an event may
1050	be requested by specifying the "RECURRENCE-ID" property corresponding to
1051	the associated event. The "Organizer" responds with the latest
1052	description and version of the event.

1054	This method type is an iCalendar object that conforms to the following
1055	property constraints:

1057	Component/Property  Presence
1058	------------------- ----------------------------------------------
1059	PRODID              MUST
1060	VERSION             MUST be "2.0"
1061	METHOD              MUST be "REFRESH"

1063	VEVENT              MUST
1064	    ATTENDEE        MUST be the address of requestor
1065	    DTSTAMP         MUST
1066	    RECURRENCE-ID   MUST only if referring to an instance of a
1067	                        recurring calendar component.  Otherwise it
1068	                        must NOT be present.
1069	    UID             MUST be the UID associated with original
1070	                        REQUEST

1072	    COMMENT         MAY

1074	    ATTACH          NOT
1075	    ATEGORIES       NOT
1076	    CLASS           NOT
1077	    CONTACT         MAY
1078	    CREATED         NOT
1079	    DESCRIPTION     NOT
1080	    DTSTART         NOT
1081	    DTEND           NOT
1082	    DURATION        NOT
1083	    EXDATE          NOT
1084	    EXRULE          NOT
1085	    GEO             NOT
1086	    LAST-MODIFIED   NOT
1087	    ORGANIZER       NOT
1088	    PRIORITY        NOT
1089	    RDATE           NOT
1090	    RELATED-TO      NOT
1091	    RESOURCES       NOT
1092	    REQUEST-STATUS  NOT
1093	    RRULE           NOT
1094	    SEQUENCE        NOT
1095	    SUMMARY         NOT
1096	    STATUS          NOT
1097	    TRANSP          NOT
1098	    URL             NOT

1100	VTIMEZONE           MUST be present if any date/time refers to a
1101	                        timezone

1103	X-TOKENS            MAY
1104	VTODO               NOT
1105	VJOURNAL            NOT
1106	VFREEBUSY           NOT
1107	VALARM              NOT

1109	3.2.7     COUNTER

1111	The "COUNTER" method for a "VEVENT" calendar component is used by an
1112	"Attendee" of an existing event to submit to the "Organizer" a counter
1113	proposal to the event description. The "Attendee" sends this message to
1114	the "Organizer" of the event.

1116	The counter proposal is an iCalendar object consisting of a VEVENT
1117	calendar component describing the complete description of the alternate
1118	event.

1120	The "Organizer" rejects the counter proposal by sending the "Attendee" a
1121	VEVENT "DECLINE-COUNTER" method. The "Organizer" accepts the counter
1122	proposal by sending all of the "Attendees" to the event a VEVENT
1123	"REQUEST" method rescheduling the event. In the latter case, the
1124	"Organizer" SHOULD reset the individual "RSVP" property parameter values
1125	to TRUE on each "ATTENDEE" property in order to force a response by the
1126	"Attendees".

1128	This method type is an iCalendar object that conforms to the following
1129	property constraints:

1131	Component/Property  Presence
1132	------------------- ----------------------------------------------
1133	PRODID              MUST
1134	VERSION             MUST be "2.0"
1135	METHOD              MUST be "COUNTER"

1137	VEVENT              MUST
1138	    DTSTAMP         MUST
1139	    RECURRENCE-ID   MUST only if referring to an instance of a
1140	                        recurring calendar component.  Otherwise it
1141	                        must NOT be present.
1142	    SEQUENCE        MUST be present if non-zero, MAY be present if zero
1143	    SUMMARY         MUST be present may be NULL
1144	    UID             MUST be the UID associated with the REQUEST
1145	                        being countered

1147	    ATTACH          MAY
1148	    ATTENDEE        MAY be used to propose other "Attendees"
1149	    CATEGORIES      MAY
1150	    CLASS           MAY
1151	    COMMENT         MAY
1152	    CONTACT         MAY
1153	    CREATED         MAY
1154	    DESCRIPTION     MAY be present, may be NULL
1155	    DTSTART         MAY
1156	    DTEND           MAY
1157	    EXDATE          MAY
1158	    EXRULE          MAY
1159	    GEO             MAY
1160	    LAST-MODIFIED   MAY
1161	    LOCATION        MAY
1162	    PRIORITY        MAY
1163	    RDATE           MAY
1164	    RELATED-TO      MAY
1165	    RESOURCES       MAY
1166	    RRULE           MAY
1167	    STATUS          MAY
1168	    TRANSP          MAY
1169	    URL             MAY

1171	    COMPLETED       NOT
1172	    DUE             NOT
1173	    DURATION        NOT
1174	    ORGANIZER       NOT
1175	    REQUEST-STATUS  NOT

1177	VTIMEZONE           MUST be present if any date/time refers to a
1178	                        timezone
1179	VALARM              MAY

1181	X-TOKENS            MAY
1182	VTODO               NOT
1183	VJOURNAL            NOT
1184	VFREEBUSY           NOT
1185	3.2.8     DECLINECOUNTER

1187	The "DECLINE-COUNTER" method in a "VEVENT" calendar component is used by
1188	the "Organizer" of an event to reject a counter proposal submitted by an
1189	"Attendee". The "Organizer" must send the "DECLINE-COUNTER" message to
1190	the "Attendee" that sent the "COUNTER" method to the "Organizer".

1192	This method type is an iCalendar object that conforms to the following
1193	property constraints:

1195	Component/Property  Presence
1196	------------------- ----------------------------------------------
1197	PRODID              MUST
1198	VERSION             MUST be "2.0"
1199	METHOD              MUST be "DECLINECOUNTER"

1201	VEVENT              MUST
1202	    DTSTAMP         MUST
1203	    ORGANIZER       MUST
1204	    RECURRENCE-ID   MUST only if referring to an instance of a
1205	                        recurring calendar component.  Otherwise it
1206	                        must NOT be present.
1207	    SEQUENCE        MUST if non-zero, MAY be present if zero
1208	    UID             MUST, same UID specified in original
1209	                        REQUEST and subsequent COUNTER

1211	    COMMENT         MAY
1212	    REQUEST-STATUS  MAY

1214	    ATTACH          NOT
1215	    ATTENDEE        NOT
1216	    CATEGORIES      NOT
1217	    CLASS           NOT
1218	    CONTACT         NOT
1219	    CREATED         NOT
1220	    DESCRIPTION     NOT
1221	    DTSTART         NOT
1222	    DTEND           NOT
1223	    DURATION        NOT
1224	    EXDATE          NOT
1225	    EXRULE          NOT
1226	    GEO             NOT
1227	    LAST-MODIFIED   NOT
1228	    PRIORITY        NOT
1229	    RDATE           NOT
1230	    RELATED-TO      NOT
1231	    RESOURCES       NOT
1232	    RRULE           NOT
1233	    STATUS          NOT
1234	    SUMMARY         NOT
1235	    TRANSP          NOT
1236	    URL             NOT

1238	VTIMEZONE           MUST be present if any date/time refers to a
1239	                        timezone
1240	X-TOKENS            MAY
1241	VTODO               NOT
1242	VJOURNAL            NOT
1243	VFREEBUSY           NOT
1244	VALARM              NOT

1246	3.3 Methods For VFREEBUSY Components

1248	This section defines the property set for the methods that are
1249	applicable to the "VFREEBUSY" calendar component. Each of the methods is
1250	defined using a restriction table.

1252	This document only addresses the transfer of busy time information.
1253	Applications desiring free time information MUST infer this from
1254	available busy time information.

1256	The busy time information within the iCalendar object MAY be grouped
1257	into more than one "VFREEBUSY" calendar component. This capability
1258	allows busy time periods to be grouped according to some common
1259	periodicity, such as a calendar week, month, or year. In this case, each
1260	"VFREEBUSY" calendar component MUST include the "ATTENDEE", "DTSTART"
1261	and "DTEND" properties in order to specify the source of the busy time
1262	information and the date and time interval over which the busy time
1263	information covers.

1265	The "FREEBUSY" property value MAY include a list of values, separated by
1266	the COMMA character (ASCII decimal 44). Alternately, multiple busy time
1267	periods MAY be specified with multiple instances of the "FREEBUSY"
1268	property. Both forms MUST be supported by implementations conforming to
1269	this document. Duplicate busy time periods SHOULD NOT be specified in an
1270	iCalendar object. However, two different busy time periods MAY overlap.

1272	"FREEBUSY" properties should be sorted such that their values are in
1273	ascending order, based on the start time, and then the end time, with
1274	the earliest periods first. For example, today's busy time information
1275	should appear after yesterday's busy time information. And the busy time
1276	for this half-hour should appear after the busy time for earlier today.

1278	Since events may span a day boundary, free busy time period may also
1279	span a day boundary. Individual "A" requests busy time from individuals
1280	"B", "C" and "D". Individual "B" and "C" replies with busy time data to
1281	individual "A". Individual "D" does not support busy time requests and
1282	does not reply with any data. If the transport binding supports
1283	exception messages, then individual "D" returns an "unsupported
1284	capability" message to individual "A".

1286	The following summarizes the methods that are defined for the
1287	"VFREEBUSY" calendar component.

1289	|================|==================================================|
1290	| Method         |  Description                                     |
1291	|================|==================================================|
1292	| PUBLISH        | Publish unsolicited busy time data.              |
1293	| REQUEST        | Request busy time data.                          |
1294	| REPLY          | Reply to a busy time request.                    |
1295	|================|==================================================|

1297	3.3.1     PUBLISH

1299	The "PUBLISH" method in a "VFREEBUSY" calendar component is used to
1300	publish busy time data. The method may be sent from one CU to any other.
1301	The purpose of the method is to provide a message for sending
1302	unsolicited busy time data. That is, the busy time data is not being
1303	sent as a "REPLY" to the receipt of a "REQUEST" method.

1305	The "ATTENDEE" property must be specified in the busy time information.
1306	The value is the CU address of the originator of the busy time
1307	information.

1309	This method type is an iCalendar object that conforms to the following
1310	property constraints:

1312	Component/Property  Presence
1313	------------------- ----------------------------------------------
1314	PRODID              MUST
1315	VERSION             MUST be "2.0"
1316	METHOD              MUST be "PUBLISH"

1318	VFREEBUSY           MUST
1319	    ATTENDEE        MUST contain the address of originator of
1320	                        busy time data
1321	    DTSTAMP         MUST
1322	    FREEBUSY        MUST be BUSYTIME. Multiple instances are allowed.
1323	                        Multiple instances must be sorted in ascending
1324	                        order.
1325	    ATTACH          MAY
1326	    RELATED-TO      MAY
1327	    COMMENT         MAY
1328	    CONTACT         MAY
1329	    CREATED         MAY specifies when the busy time data was
1330	                        Created
1331	    DTSTART         MAY be present to represent start of the
1332	                        interval for busy time data
1333	    DTEND           MAY be present to represent the end of
1334	                        the interval for busy time data
1335	    GEO             MAY
1336	    ORGANIZER       MAY
1337	    URL             MAY (specifies busy time URL)

1339	    CATEGORIES      NOT
1340	    CLASS           NOT
1341	    DESCRIPTION     NOT
1342	    DURATION        NOT
1343	    EXDATE          NOT
1344	    EXRULE          NOT
1345	    LAST-MODIFIED   NOT
1346	    PRIORITY        NOT
1347	    RDATE           NOT
1348	    RECURRENCE-ID   NOT
1349	    REQUEST-STATUS  NOT
1350	    RESOURCES       NOT
1351	    RRULE           NOT
1352	    SEQUENCE        NOT
1353	    STATUS          NOT
1354	    SUMMARY         NOT
1355	    TRANSP          NOT
1356	    UID             NOT

1358	VTIMEZONE           MUST be present if any date/time refers to a
1359	                        timezone
1360	X-TOKENS            NOT
1361	VEVENT              NOT
1362	VTODO               NOT
1363	VJOURNAL            NOT
1364	VALARM              NOT

1366	3.3.2     REQUEST

1368	The "REQUEST" method in a "VFREEBUSY" calendar component is used to ask
1369	a "Calendar User" for their busy time information. The request may be
1370	for a busy time information bounded by a specific date and time
1371	interval.

1373	This message only permits requests for busy time information. The
1374	message is sent from a "Calendar User" requesting the busy time
1375	information to one or more intended recipients.

1377	If the originator of the "REQUEST" method is not authorized to make a
1378	busy time request on the recipient's calendar system, then an exception
1379	message SHOULD be returned in a "REPLY" method, but no busy time data
1380	need be returned.

1382	This method type is an iCalendar object that conforms to the following
1383	property constraints:

1385	Component/Property  Presence
1386	------------------- ----------------------------------------------
1387	PRODID              MUST
1388	VERSION             MUST be "2.0"
1389	METHOD              MUST be "REQUEST"

1391	VFREEBUSY           MUST
1392	    ATTENDEE        MUST contain the address of the calendar store
1393	                        for which busy time is being requested.

1395	    DTEND           MUST
1396	    DTSTAMP         MUST
1397	    DTSTART         MUST
1398	    ORGANIZER       MUST be the request originator's address

1400	    ATTACH          MAY
1401	    COMMENT         MAY
1402	    CONTACT         MAY
1403	    GEO             MAY
1404	    URL             MAY

1406	    CATEGORIES      NOT
1407	    CLASS           NOT
1408	    CREATED         NOT
1409	    DESCRIPTION     NOT
1410	    DURATION        NOT
1411	    EXDATE          NOT
1412	    EXRULE          NOT
1413	    FREEBUSY        NOT
1414	    LAST-MODIFIED   NOT
1415	    PRIORITY        NOT
1416	    RDATE           NOT
1417	    RECURRENCE-ID   NOT
1418	    RELATED-TO      NOT
1419	    REQUEST-STATUS  NOT
1420	    RESOURCES       NOT
1421	    RRULE           NOT
1422	    SEQUENCE        NOT
1423	    STATUS          NOT
1424	    SUMMARY         NOT
1425	    TRANSP          NOT
1426	    UID             NOT

1428	VTIMEZONE           MUST be present if any date/time refers to a

1430	X-TOKENS            MAY
1431	VEVENT              NOT
1432	VTODO               NOT
1433	VJOURNAL            NOT
1434	VALARM              NOT

1436	3.3.3     REPLY

1438	The "REPLY" method in a "VFREEBUSY" calendar component is used to
1439	respond to a busy time request. The method is sent by the recipient of a
1440	busy time request to the originator of the request.

1442	The "REPLY" method may also be used to respond to an unsuccessful
1443	"REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy time
1444	information may be returned.

1446	This method type is an iCalendar object that conforms to the following
1447	property constraints:

1449	Component/Property  Presence
1450	------------------- ----------------------------------------------
1451	PRODID              MUST
1452	VERSION             MUST be "2.0"
1453	METHOD              MUST be "REPLY"

1455	VFREEBUSY           MUST
1456	    ATTENDEE        MUST (address of recipient replying)
1457	    DTSTAMP         MUST
1458	    DTSTART         MUST
1459	    DTEND           MUST
1460	    FREEBUSY        MUST (values MUST all be of the same data
1461	                        type. Multiple instances are allowed.
1462	                        Multiple instances MUST be sorted in
1463	                        ascending order. Values MAY NOT overlap)
1464	    ORGANIZER       MUST be the request originator's address
1465	    RECURRENCE-ID   MUST only if referring to an instance of a
1466	                        recurring calendar component.  Otherwise it
1467	                        must NOT be present.
1468	    UID             MUST

1470	    ATTACH          MAY
1471	    COMMENT         MAY
1472	    CONTACT         MAY
1473	    CREATED         MAY specifies when the busy time data was
1474	                        created)
1475	    DTSTART         MAY (represents start of interval for busy
1476	                        time data}, DTEND{represents end of
1477	                        interval for busy time data)
1478	    GEO             MAY
1479	    RELATED-TO      MAY
1480	    REQUEST-STATUS  MAY
1481	    SEQUENCE        MAY be present if non-zero
1482	    URL             MAY (specifies busy time URL)

1484	    CATEGORIES      NOT
1485	    CLASS           NOT
1486	    DESCRIPTION     NOT
1487	    DURATION        NOT
1488	    EXDATE          NOT
1489	    EXRULE          NOT
1490	    FREEBUSY        NOT
1491	    LAST-MODIFIED   NOT
1492	    PRIORITY        NOT
1493	    RDATE           NOT
1494	    RESOURCES       NOT
1495	    RRULE           NOT
1496	    SEQUENCE        NOT
1497	    STATUS          NOT
1498	    SUMMARY         NOT
1499	    TRANSP          NOT

1501	VTIMEZONE           MUST be present if any date/time refers to a
1502	                        timezone

1504	X-TOKENS            MAY
1505	VEVENT              NOT
1506	VTODO               NOT
1507	VJOURNAL            NOT
1508	VALARM              NOT

1510	3.4 Methods For VTODO Components

1512	This section defines the property set for the methods that are
1513	applicable to the "VTODO" calendar component. Each of the methods is
1514	defined using a restriction table that specifies the property
1515	constraints that define the particular method.

1517	The following summarizes the methods that are defined for the "VTODO"
1518	calendar component.

1520	+================+==================================================+
1521	| Method         |  Description                                     |
1522	|================+==================================================|
1523	| PUBLISH        | Post notification of a VTODO. Used primarily as  |
1524	|                | a method of advertising the existence of a VTODO.|
1525	|                |                                                  |
1526	| REQUEST        | Assign a VTODO. This is an explicit assignment to|
1527	|                | one or more Calendar Users. The REQUEST method   |
1528	|                | is also used to update or change an existing     |
1529	|                | VTODO. Clients that cannot handle REQUEST MAY    |
1530	|                | degrade the method to treat it as a PUBLISH.     |
1531	|                |                                                  |
1532	| REPLY          | Reply to a VTODO request. Attendees MAY set      |
1533	|                | ATTSTAT to ACCEPTED, DECLINED, TENTATIVE,        |
1534	|                | DELEGATED, PARTIAL, and COMPLETED.               |
1535	|                |                                                  |
1536	| ADD            | Add one or more instances to an existing to-do.  |
1537	|                |                                                  |
1538	| CANCEL         | Cancel one or more instances of an existing      |
1539	|                | to-do.                                           |
1540	|                |                                                  |
1541	| REFRESH        | A request sent to a VTODO "Organizer" asking for |
1542	|                | the latest version of a VTODO.                   |
1543	|                |                                                  |
1544	| COUNTER        | Counter a REQUEST with an alternative proposal.  |
1545	|                |                                                  |
1546	| DECLINECOUNTER | Decline a counter proposal by an "Attendee."     |
1547	+================+==================================================+
1548	3.4.1     PUBLISH

1550	The "PUBLISH" method in a "VTODO" calendar component has no associated
1551	response. It is simply a posting of an iCalendar object that maybe added
1552	to a calendar by a "Calendar User". Its expected usage is for
1553	encapsulating an arbitrary "VTODO" calendar component as an iCalendar
1554	object. The "Organizer" MAY subsequently update (with another "PUBLISH"
1555	method), add instances to (win an "ADD" method), or cancel (with a
1556	"CANCEL" method) a previously published "VTODO" calendar component.

1558	This method type is an iCalendar object that conforms to the following
1559	property constraints:

1561	Component/Property  Presence
1562	------------------- ----------------------------------------------
1563	PRODID               MUST
1564	VERSION              MUST be "2.0"
1565	METHOD               MUST be "PUBLISH"
1566	VTODO                MUST
1567	    DTSTAMP          MUST
1568	    DTSTART          MUST
1569	    ORGANIZER        MUST
1570	    RECURRENCE-ID    MUST only if referring to an instance of a
1571	                         recurring calendar component.  Otherwise it
1572	                         must NOT be present.
1573	    SEQUENCE         MUST be present if not 0, may be present if 0
1574	    SUMMARY          MUST; may be null.
1575	    UID              MUST

1577	    ATTENDEE         MAY
1578	    ATTACH           MAY
1579	    CATEGORIES       MAY
1580	    CLASS            MAY
1581	    COMMENT          MAY
1582	    CONTACT          MAY
1583	    CREATED          MAY
1584	    DESCRIPTION      MAY be present and MAY be NULL
1585	    DURATION         MAY
1586	    DTEND            MAY
1587	    EXDATE           MAY
1588	    EXRULE           MAY
1589	    GEO              MAY
1590	    LAST-MODIFIED    MAY
1591	    LOCATION         MAY
1592	    PERCENT-COMPLETE MAY
1593	    PRIORITY         MAY
1594	    RELATED-TO       MAY
1595	    RDATE            MAY
1596	    RESOURCES        MAY
1597	    RRULE            MAY
1598	    STATUS           MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS
1599	    TRANSP           MAY
1600	    URL              MAY
1601	VEVENT               NOT
1602	VJOURNAL             NOT
1603	VTIMEZONE            MUST be present if any date/time refers to a
1604	                        timezone
1605	VALARM               MAY
1606	VFREEBUSY            NOT
1607	X-TOKENS             MAY

1609	3.4.2     REQUEST

1611	The "REQUEST" method in a "VTODO" calendar component provides the
1612	following scheduling functions:

1614	. Assign a to-do to one or more "Calendar Users";
1615	. Reschedule an existing to-do;
1616	. Update the details of an existing to-do, without rescheduling it;
1617	. Update the completion status of "Attendees" of an existing to-do,
1618	  without rescheduling it;
1619	. Reconfirm an existing to-do, without rescheduling it;
1620	. Delegate/reassign an existing to-do to another "Calendar User".

1622	The assigned "Calendar Users" are identified in the "VTODO" calendar
1623	component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property value
1624	sequences.

1626	The originator of a "REQUEST" is the "Organizer" of the to-do. The
1627	recipient of a "REQUEST" is the "Calendar User" assigned the to-do-the
1628	"Attendee". The "Attendee" uses the "REPLY" method to convey their
1629	acceptance and completion status to the "Organizer" of the "REQUEST".

1631	The "UID", "SEQUENCE", and "DTSTAMP" properties are used to distinguish
1632	the various uses of the "REQUEST" method. If the "UID" property value in
1633	the "REQUEST" is not found on the recipient's calendar, then the
1634	"REQUEST" is for a new to-do. If the "UID" property value is found on
1635	the recipient's calendar, then the "REQUEST" is a rescheduling, an
1636	update, or a reconfirm of the "VTODO" calendar object.

1638	If the "Organizer" of the "REQUEST" method is not authorized to make a
1639	to-do request on the "Attendee's" calendar system, then an exception is
1640	returned in the "REQUEST-STATUS" property of a subsequent "REPLY"
1641	method, but no scheduling action is performed.

1643	This method type is an iCalendar object that conforms to the following
1644	property constraints:

1646	Component/Property  Presence
1647	------------------- ----------------------------------------------
1648	PRODID                MUST
1649	VERSION               MUST be "2.0"
1650	METHOD                MUST be "REQUEST"
1651	VTODO                 MUST
1652	    ATTENDEE          MUST
1653	    DTSTAMP           MUST
1654	    DTSTART           MUST
1655	    ORGANIZER         MUST
1656	    RECURRENCE-ID     MUST only if referring to an instance of a
1657	                          recurring calendar component.  Otherwise it
1658	                          must NOT be present.
1659	    SEQUENCE          MUST be present if not 0, may be present if 0
1660	    SUMMARY           MUST; may be null.
1661	    UID               MUST
1662	    ATTACH            MAY
1663	    CATEGORIES        MAY
1664	    CLASS             MAY
1665	    COMMENT           MAY
1666	    CONTACT           MAY
1667	    CREATED           MAY
1668	    DESCRIPTION       MAY be present and MAY be NULL
1669	    DURATION          MAY
1670	    DTEND             MAY
1671	    EXDATE            MAY
1672	    EXRULE            MAY
1673	    GEO               MAY
1674	    LAST-MODIFIED     MAY
1675	    LOCATION          MAY
1676	    PERCENT-COMPLETE  MAY
1677	    PRIORITY          MAY
1678	    RELATED-TO        MAY
1679	    RDATE             MAY
1680	    RESOURCES         MAY
1681	    RRULE             MAY
1682	    STATUS            MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS
1683	    TRANSP            MAY
1684	    URL               MAY

1686	VEVENT                NOT
1687	VJOURNAL              NOT
1688	VTIMEZONE             MUST be present if any date/time refers to a
1689	                          timezone
1690	VALARM                MAY
1691	VFREEBUSY             NOT
1692	X-TOKENS              MAY

1694	3.4.2.1   REQUEST for Rescheduling a VTODO

1696	The "REQUEST" method may be used to reschedule a "VTODO" calendar
1697	component.

1699	Rescheduling a "VTODO" calendar component involves a change to the
1700	existing "VTODO" calendar component in terms of its start or due time or
1701	recurrence intervals and possibly the description. If the recipient CUA
1702	of a "REQUEST" method finds that the "UID" property value already exists
1703	on the calendar, but that the "SEQUENCE" property value in the "REQUEST"
1704	is greater than the value for the existing VTODO, then the "REQUEST"
1705	method describes a rescheduling of the "VTODO" calendar component.

1707	3.4.2.2   REQUEST for Update or Reconfirmation of a VTODO

1709	The "REQUEST" method may be used to update or reconfirm a "VTODO"
1710	calendar component. Reconfirmation is merely an update of "Attendee"
1711	completion status or overall "VTODO" calendar component status.

1713	An update to an existing "VTODO" calendar component does not involve
1714	changes to the start or due time or recurrence intervals, nor generally
1715	to the description for the "VTODO" calendar component. If the recipient
1716	CUA of a "REQUEST" method finds that the "UID" property value already
1717	exists on the calendar and that the "SEQUENCE" property value in the
1718	"REQUEST" is the same as the value for the existing event, then the
1719	"REQUEST" method describes an update of the "VTODO" calendar component
1720	details, but not a rescheduling of the "VTODO" calendar component.

1722	The update "REQUEST" is the appropriate response to a "REFRESH" method
1723	sent from an "Attendee" to the "Organizer" of a "VTODO" calendar
1724	component.

1726	Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a
1727	"VTODO" calendar component. The unsolicited "REQUEST" methods are used
1728	to update the details of the "VTODO" (without rescheduling it or
1729	updating the completion status of "Attendees") or the "VTODO" calendar
1730	component itself (i.e., reconfirm the "VTODO").

1732	3.4.2.3   REQUEST for Delegating a VTODO

1734	The "REQUEST" method is also used to delegate or reassign ownership of a
1735	"VTODO" calendar component to another "Calendar User". For example, it
1736	may be used to delegate an "Attendee's" role (i.e. "chair", or
1737	"participant") for a "VTODO" calendar component. The "REQUEST" method is
1738	sent by one of the "Attendees" of an existing "VTODO" calendar component
1739	to some other individual. An "Attendee" of a "VTODO" calendar component
1740	MUST NOT delegate to the "Organizer" of the event.

1742	For the purposes of this description, the "Attendee" delegating the
1743	"VTODO" calendar component is referred to as the "Delegator". The
1744	"Attendee" receiving the delegation request is referred to as the
1745	"Delegate".

1747	The "Delegator" of a "VTODO" calendar component MUST forward the
1748	existing "REQUEST" method for a "VTODO" calendar component to the
1749	"Delegate". The "VTODO" calendar component description MUST include the
1750	"Delegator's" up-to-date "VTODO" calendar component definition. The
1751	"REQUEST" method MUST also include an "ATTENDEE" property with the
1752	calendar address of the "Delegate". The "Delegator" MUST also send a
1753	"REPLY" method back to the "Organizer" with the "Delegator's" "Attendee"
1754	property "attstat" parameter value set to "DELEGATED". In addition, the
1755	"delegated-to" parameter SHOULD be included with the calendar address of
1756	the "Delegate". A response to the delegation "REQUEST" is sent from the
1757	"Delegate" to the "Organizer" and optionally, to the "Delegator". The
1758	"REPLY" method from the "Delegate" SHOULD include the "ATTENDEE"
1759	property with their calendar address and the "delegated-from" parameter
1760	with the value of the "Delegator's" calendar address.

1762	The delegation "REQUEST" method MUST assign a value for the "RSVP"
1763	property parameter associated with the "Delegator's" "Attendee" property
1764	to that of the "Delegate's" "ATTENDEE" property. For example if the
1765	"Delegator's" "ATTENDEE" property specifies "RSVP=TRUE", then the
1766	"Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE".

1768	3.4.2.4   REQUEST Forwarded To An Uninvited Calendar User

1770	An "Attendee" assigned a "VTODO" calendar component may assign the
1771	"VTODO" calendar component to another new "Calendar User", not
1772	previously associated with the "VTODO" calendar component. The current
1773	"Attendee" assigned the "VTODO" calendar component accomplishes this
1774	scheduling action by forwarding the original "REQUEST" method to the new
1775	"Calendar User".

1777	3.4.2.5   REQUEST Updated Attendee Status

1779	An "Organizer" of a "VTODO" may request an updated status from one or
1780	more "Attendees". The "Organizer" sends a "REQUEST" method to the
1781	"Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The
1782	"SEQUENCE" property for the "VTODO" is not changed from its previous
1783	value. A recipient determines that the only change in the "REQUEST" is
1784	that their "RSVP" property parameter indicates a request for an updated
1785	status. The recipient SHOULD respond with a "REPLY" method indicating
1786	their current status with respect to the "REQUEST".

1788	3.4.3     REPLY

1790	The "REPLY" method in a "VTODO" calendar component is used to respond
1791	(e.g., accept or decline) to a request or to reply to a delegation
1792	request. It is also used by an "Attendee" to update their completion
1793	status. When used to provide a delegation response, the "Delegator"
1794	SHOULD include the calendar address of the "Delegate" in the "delegated-
1795	to" parameter of the "Delegator's" "ATTENDEE" property. The "Delegate"
1796	SHOULD include the calendar address of the "Delegator" on the
1797	"delegated-from" parameter of the "Delegate's" "ATTENDEE" property.

1799	The "REPLY" method MAY also be used to respond to an unsuccessful
1800	"VTODO" calendar component "REQUEST" method. Depending on the "REQUEST-
1801	STATUS" value, no scheduling action may have been performed.

1803	The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY"
1804	method from a "Calendar User" not in the original "REQUEST". For
1805	example, a "REPLY" method MAY be received from a "Delegate" of a "VTODO"
1806	calendar component. In addition, the "REPLY" method MAY be received from
1807	an unknown "Calendar User", having been forwarded the "REQUEST" by an
1808	original "Attendee" of the "VTODO" calendar component. This uninvited
1809	"Attendee" MAY be accepted, or the "Organizer" MAY cancel the "VTODO"
1810	calendar component for the uninvited "Attendee" by sending them a
1811	"CANCEL" method.

1813	This method type is an iCalendar object that conforms to the following
1814	property constraints:

1816	Component/Property   Presence
1817	-------------------  ---------------------------------------------
1818	PRODID               MUST
1819	VERSION              MUST be "2.0"
1820	METHOD               MUST be "REPLY"
1821	VTODO                MUST
1822	    ATTENDEE         MUST
1823	    UID              MUST must be the address of the replying attendee
1824	    DTSTAMP          MUST
1825	    ORGANIZER        MUST
1826	    RECURRENCE-ID    MUST only if referring to an instance of a
1827	                          Recurring calendar component. Otherwise it
1828	                          Must NOT be present
1829	    SEQUENCE         MUST

1831	    COMMENT          MAY
1832	    PERCENT-COMPLETE MAY
1833	    REQUEST-STATUS   MAY

1835	    DTSTART          NOT
1836	    CREATED          NOT
1837	    DESCRIPTION      NOT
1838	    PRIORITY         NOT
1839	    CLASS            NOT
1840	    CATEGORIES       NOT
1841	    CONTACT          NOT
1842	    CREATED          NOT
1843	    DTEND            NOT
1844	    GEO              NOT
1845	    LAST-MODIFIED    NOT
1846	    LOCATION         NOT
1847	    RDATE            NOT
1848	    RRULE            NOT
1849	    RELATED-TO       NOT
1850	    RESOURCE         NOT
1851	    STATUS           NOT
1852	    TRANSP           NOT
1853	    URL              NOT
1854	VTIMEZONE            MUST be present if any date/time refers to a
1855	                         timezone
1856	VALARM               NOT
1857	VEVENT               NOT
1858	VFREEBUSY            NOT
1859	X-TOKENS             NOT
1860	3.4.4     ADD

1862	The "ADD" method in a "VTODO" calendar component is used to add one or
1863	more instances to an existing to-do.

1865	If the "UID" property value in the "ADD" is not found on the recipient's
1866	calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer"
1867	in order to be updated with the latest version of the "VTODO". If an
1868	"Attendee" implementation does not support the "ADD" method it should
1869	respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH".

1871	This method type is an iCalendar object that conforms to the following
1872	property constraints:

1874	Component/Property  Presence
1875	------------------- ----------------------------------------------
1876	PRODID                MUST
1877	VERSION               MUST be "2.0"
1878	METHOD                MUST be "ADD"
1879	VTODO                 MUST
1880	    DTSTAMP           MUST
1881	    DTSTART           MUST
1882	    ORGANIZER         MUST
1883	    SEQUENCE          MUST be greater than 0
1884	    SUMMARY           MUST; may be null.
1885	    UID               MUST match that of the original to-do

1887	    ATTENDEE          MAY
1888	    ATTACH            MAY
1889	    CATEGORIES        MAY
1890	    CLASS             MAY
1891	    COMMENT           MAY
1892	    CONTACT           MAY
1893	    CREATED           MAY
1894	    DESCRIPTION       MAY be present and MAY be NULL
1895	    DTEND             MAY
1896	    DURATION          MAY
1897	    EXDATE            MAY
1898	    EXRULE            MAY
1899	    GEO               MAY
1900	    LAST-MODIFIED     MAY
1901	    LOCATION          MAY
1902	    PERCENT-COMPLETE  MAY
1903	    PRIORITY          MAY
1904	    RELATED-TO        MAY
1905	    RDATE             MAY
1906	    RESOURCES         MAY
1907	    RRULE             MAY
1908	    STATUS           MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS
1909	    TRANSP            MAY
1910	    URL               MAY
1911	    RECURRENCE-ID     NOT
1912	    REQUEST-STATUS    NOT

1914	VEVENT                NOT
1915	VJOURNAL              NOT
1916	VTIMEZONE             MUST be present if any date/time refers to a
1917	                          timezone
1918	VALARM                MAY
1919	VFREEBUSY             NOT
1920	X-TOKENS              MAY

1922	3.4.5     CANCEL

1924	The "CANCEL" method in a "VTODO" calendar component is used to send a
1925	cancellation notice of an existing "VTODO" calendar request to the
1926	"Attendees". The message is sent by the "Organizer" of a "VTODO"
1927	calendar component to the "Attendees" of the "VTODO" calendar component.
1928	For a recurring "VTODO" calendar component, either the whole "VTODO"
1929	calendar component or instances of a "VTODO" calendar component may be
1930	cancelled. To cancel the complete range of a recurring "VTODO" calendar
1931	component, the "UID" property value for the "VTODO" calendar component
1932	MUST be specified and a "RECURRENCE-ID" MUST NOT be specified in the
1933	"CANCEL" method. In order to cancel an individual instance of a
1934	recurring "VTODO" calendar component, the "RECURRENCE-ID" property value
1935	for the "VTODO" calendar component MUST be specified in the "CANCEL"
1936	method.

1938	There are two options for canceling a sequence of instances of a
1939	recurring "VTODO" calendar component:

1941	(a)    the "RECURRENCE-ID" property for an instance in the sequence MUST be
1942	  specified with the "RANGE" property parameter value of THISANDPRIOR
1943	  (or THISANDFUTURE)  to indicate cancellation of the specified "VTODO"
1944	  calendar component and all instances before (or after); or

1946	(b)    individual recurrence instances may be cancelled by specifying
1947	  multiple "RECURRENCE-ID" properties corresponding to the instances to
1948	  be cancelled.

1950	This method type is an iCalendar object that conforms to the following
1951	property constraints:

1953	Component/Property   Presence
1954	-------------------  ---------------------------------------------
1955	PRODID               MUST
1956	VERSION              MUST be "2.0"
1957	METHOD               MUST be "CANCEL"
1958	VTODO                MUST
1959	    UID              MUST must echo original UID
1960	    DTSTAMP          MUST
1961	    ORGANIZER        MUST
1962	    SEQUENCE         MUST
1963	    RECURRENCE-ID    MUST only if referring to one or more instances
1964	                          of a recurring calendar component. Otherwise
1965	                          it MUST NOT be present
1966	    COMMENT          MAY
1967	    ATTENDEE         MAY
1968	    DTSTART          MAY
1969	    CREATED          MAY
1970	    DESCRIPTION      MAY
1971	    ORGANIZER        MAY
1972	    PRIORITY         MAY
1973	    CLASS            MAY
1974	    CATEGORIES       MAY
1975	    CONTACT          MAY
1976	    CREATED          MAY
1977	    DTEND            MAY
1978	    GEO              MAY
1979	    LAST-MODIFIED    MAY
1980	    LOCATION         MAY
1981	    PERCENT-COMPLETE MAY
1982	    PRIORITY         MAY
1983	    RDATE            MAY
1984	    RRULE            MAY
1985	    RELATED-TO       MAY
1986	    REQUEST-STATUS   MAY
1987	    RESOURCE         MAY
1988	    STATUS           MAY If present it must be set to "CANCELLED".
1989	                         MUST NOT be used if purpose is to remove
1990	                         "ATTENDEES" rather than cancel the entire
1991	                         VTODO.
1992	    TRANSP           MAY
1993	    URL              MAY

1995	VTIMEZONE             MUST be present if any date/time refers to a
1996	                          timezone
1997	VALARM               MAY
1998	VEVENT               MAY
1999	VFREEBUSY            MAY
2000	X-TOKENS             MAY

2002	3.4.6     REFRESH

2004	The "REFRESH" method in a "VTODO" calendar component is used by
2005	"Attendees" of an existing "VTODO" calendar component to request an
2006	updated description from the "Organizer" of the "VTODO" calendar
2007	component. The "Organizer" of the "VTODO" calendar component MAY use
2008	this method to request an updated status from the "Attendees". The
2009	"REFRESH" method MUST specify the "UID" property corresponding to the
2010	"VTODO" calendar component needing update.

2012	A refresh of a recurrence instance of a "VTODO" calendar component may
2013	be requested by specifying the "RECURRENCE-ID" property corresponding to
2014	the associated "VTODO" calendar component. The "Organizer" responds with
2015	the latest description and rendition of the "VTODO" calendar component.

2017	This method is intended to facilitate machine processing of requests for
2018	updates to a "VTODO" calendar component.

2020	This method type is an iCalendar object that conforms to the following
2021	property constraints:

2023	Component/Property   Presence
2024	-------------------  ---------------------------------------------
2025	PRODID               MUST
2026	VERSION              MUST be "2.0"
2027	METHOD               MUST be "REFRESH"
2028	VTODO                MUST
2029	    ATTENDEE         MUST
2030	    DTSTAMP          MUST
2031	    RECURRENCE-ID    MUST only if referring to an instance of a
2032	                          Recurring calendar component. Otherwise it
2033	                          MUST NOT be present
2034	    UID              MUST echo original UID
2035	    COMMENT          MAY
2036	    REQUEST-STATUS   MAY
2037	    DTSTART          MAY
2038	    CREATED          MAY
2039	    DESCRIPTION      MAY
2040	    PRIORITY         MAY
2041	    CLASS            MAY
2042	    CATEGORIES       MAY
2043	    CONTACT          MAY
2044	    CREATED          MAY
2045	    DTEND            MAY
2046	    GEO              MAY
2047	    LAST-MODIFIED    MAY
2048	    PERCENT-COMPLETE MAY
2049	    ORGANIZER        MAY
2050	    PRIORITY         MAY
2051	    LOCATION         MAY
2052	    RDATE            MAY
2053	    RRULE            MAY
2054	    RELATED-TO       MAY
2055	    RESOURCE         MAY
2056	    SEQUENCE         MAY
2057	    STATUS           MAY
2058	    TRANSP           MAY
2059	    URL              MAY
2060	VTIMEZONE            MUST be present if any date/time refers to a
2061	                         timezone
2062	VALARM               MAY
2063	VEVENT               MAY
2064	VFREEBUSY            MAY
2065	X-TOKENS             MAY
2066	3.4.7     COUNTER

2068	The "COUNTER" method in a "VTODO" calendar component is used by an
2069	"Attendee" of an existing "VTODO" calendar component to submit to the
2070	"Organizer" a counter proposal for the "VTODO" calendar component. The
2071	"Attendee" sends the message to the "Organizer" of the "VTODO" calendar
2072	component.

2074	The counter proposal is an iCalendar object consisting of a "VTODO"
2075	calendar component describing the complete description of the alternate
2076	"VTODO" calendar component.

2078	The "Organizer" rejects the counter proposal by sending the "Attendee" a
2079	"DECLINE-COUNTER" method. The "Organizer" accepts the counter proposal
2080	by sending all of the "Attendees" of the "VTODO" calendar component a
2081	"REQUEST" method rescheduling the "VTODO" calendar component. In the
2082	latter case, the "Organizer" SHOULD reset the individual "RSVP" property
2083	parameter values to TRUE on each "ATTENDEE" property; in order to force
2084	a response by the "Attendees".

2086	This method type is an iCalendar object that conforms to the following
2087	property constraints:

2089	Component/Property  Presence
2090	------------------- ----------------------------------------------
2091	PRODID               MUST
2092	VERSION              MUST be "2.0"
2093	METHOD               MUST be "COUNTER"
2094	VTODO                MUST
2095	    DTSTAMP          MUST
2096	    DTSTART          MAY
2097	    ORGANIZER        MUST
2098	    RECURRENCE-ID    MUST only if referring to an instance of a
2099	                         recurring calendar component.  Otherwise it
2100	                         MUST NOT be present.
2101	    SEQUENCE         MUST be present if NOT 0, MAY be present if 0
2102	    SUMMARY          MUST be present; MAY be NULL
2103	    UID              MUST

2105	    ATTENDEE         MAY
2106	    ATTACH           MAY
2107	    CATEGORIES       MAY
2108	    CLASS            MAY
2109	    COMMENT          MAY
2110	    CONTACT          MAY
2111	    CREATED          MAY
2112	    DESCRIPTION      MAY be present; MAY be NULL
2113	    DURATION         MAY
2114	    DTEND            MAY
2115	    EXDATE           MAY
2116	    EXRULE           MAY
2117	    GEO              MAY
2118	    LAST-MODIFIED    MAY
2119	    LOCATION         MAY
2120	    PERCENT-COMPLETE MAY
2121	    PRIORITY         MAY
2122	    RELATED-TO       MAY
2123	    RDATE            MAY
2124	    RESOURCES        MAY
2125	    RRULE            MAY
2126	    STATUS           MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS
2127	    TRANSP           MAY
2128	    URL              MAY
2129	VEVENT               MAY
2130	VJOURNAL             MAY
2131	VTIMEZONE            MUST be present if any date/time refers to a
2132	                         timezone
2133	VALARM               MAY
2134	VFREEBUSY            MAY
2135	X-TOKENS             MAY

2137	3.4.8     DECLINECOUNTER

2139	The "DECLINE-COUNTER" method in a "VTODO" calendar component is used by
2140	an "Organizer" of "VTODO" calendar component to reject a counter
2141	proposal offered by one of the "Attendees". The "Organizer" sends the
2142	message to the "Attendee" that sent the "COUNTER" method to the
2143	"Organizer".

2145	This method type is an iCalendar object that conforms to the following
2146	property constraints:

2148	Component/Property   Presence
2149	-------------------  ---------------------------------------------
2150	PRODID               MUST
2151	VERSION              MUST be "2.0"

2153	METHOD               MUST be "DECLINECOUNTER"

2155	VTODO                MUST
2156	    ATTENDEE         MUST for all attendees
2157	    UID              MUST must echo original UID
2158	    DTSTAMP          MUST
2159	    SEQUENCE         MUST
2160	    RECURRENCE-ID    MUST only if referring to an instance of a
2161	                          recurring calendar component.  Otherwise it
2162	                          MUST NOT be present.

2164	    COMMENT          MAY
2165	    PERCENT-COMPLETE MAY
2166	    REQUEST-STATUS   MAY
2167	    DTSTART          MAY
2168	    CREATED          MAY
2169	    DESCRIPTION      MAY
2170	    ORGANIZER        MAY
2171	    PRIORITY         MAY
2172	    CLASS            MAY
2173	    CATEGORIES       MAY
2174	    CONTACT          MAY
2175	    CREATED          MAY
2176	    DTEND            MAY
2177	    GEO              MAY
2178	    LAST-MODIFIED    MAY
2179	    LOCATION         MAY
2180	    RDATE            MAY
2181	    RRULE            MAY
2182	    RELATED-TO       MAY
2183	    RESOURCE         MAY
2184	    STATUS           MAY be one of COMPLETED/NEEDS ACTION/IN-PROCESS
2185	    TRANSP           MAY
2186	    URL              MAY

2188	VTIMEZONE            MUST be present if any date/time refers to a
2189	                         timezone
2190	VALARM               MAY
2191	VEVENT               MAY
2192	VTODO                MAY
2193	VFREEBUSY            MAY
2194	X-TOKENS             MAY

2196	3.5 Methods For VJOURNAL Components

2198	This section defines the property set for the methods that are
2199	applicable to the "VJOURNAL" calendar component.

2201	The following summarizes the methods that are defined for the "VJOURNAL"
2202	calendar component.

2204	+================+==================================================+
2205	| Method         |  Description                                     |
2206	|================+==================================================|
2207	| PUBLISH        | Post a journal entry. Used primarily as a method |
2208	|                | of advertising the existence of a journal entry. |
2209	|                |                                                  |
2210	| ADD            | Add one or more instances to an existing journal |
2211	|                | entry.                                           |
2212	|                |                                                  |
2213	| CANCEL         | Cancel one or more instances of an existing      |
2214	|                | journal entry.                                   |
2215	+================+==================================================+

2217	3.5.1     PUBLISH

2219	The "PUBLISH" method in a "VJOURNAL" calendar component has no
2220	associated response. It is simply a posting of an iCalendar object that
2221	may be added to a calendar by a CUA. There is no response to the
2222	"Organizer". The expected usage is for encapsulating an arbitrary
2223	journal entry as an iCalendar object. The "Organizer" MAY subsequently
2224	update (with another "PUBLISH" method) or cancel (with a "CANCEL"
2225	method) a previously published journal entry.

2227	This method type is an iCalendar object that conforms to the following
2228	property constraints:

2230	Component/Property  Presence
2231	------------------- ----------------------------------------------
2232	PRODID               MUST
2233	VERSION              MUST be "2.0"
2234	METHOD               MUST be "PUBLISH"
2235	VJOURNAL             MUST
2236	    DTSTAMP          MUST
2237	    DTSTART          MUST
2238	    ORGANIZER        MUST
2239	    RECURRENCE-ID    MUST only if referring to an instance of a
2240	                         recurring calendar component.  Otherwise it
2241	                         MUST NOT be present.
2242	    SEQUENCE         MUST be present if not 0, MAY be present if 0
2243	    SUMMARY          MUST be present and MAY be NULL
2244	    UID              MUST

2246	    ATTENDEE         MAY
2247	    ATTACH           MAY
2248	    CATEGORIES       MAY
2249	    CLASS            MAY
2250	    COMMENT          MAY
2251	    CONTACT          MAY
2252	    CREATED          MAY
2253	    DESCRIPTION      MAY be present; MAY be NULL.
2254	    DURATION         MAY
2255	    DTEND            MAY
2256	    EXDATE           MAY
2257	    EXRULE           MAY
2258	    GEO              MAY
2259	    LAST-MODIFIED    MAY
2260	    LOCATION         MAY
2261	    PRIORITY         MAY
2262	    RELATED-TO       MAY
2263	    RDATE            MAY
2264	    RESOURCES        MAY
2265	    RRULE            MAY
2266	    STATUS           MAY be one of DRAFT/FINAL/CANCELLED
2267	    TRANSP           MAY
2268	    URL              MAY

2270	VEVENT               MAY
2271	VTODO                MAY
2272	VTIMEZONE            MUST be present if any date/time refers to a
2273	                         timezone
2274	VALARM               MAY
2275	VFREEBUSY            MAY
2276	X-TOKENS             MAY
2277	3.5.2     ADD

2279	The "ADD" method in a "VJOURNAL" calendar component is used to add one
2280	or more instances to an existing "VJOURNAL" entry. There is no response
2281	to the "Organizer".

2283	If the "UID" property value in the "ADD" is not found on the recipient's
2284	calendar, then the recipient MAY treat the "ADD" as a "PUBLISH".

2286	This method type is an iCalendar object that conforms to the following
2287	property constraints:

2289	Component/Property  Presence
2290	------------------- ----------------------------------------------
2291	PRODID               MUST
2292	VERSION              MUST be "2.0"
2293	METHOD               MUST be "ADD"
2294	VJOURNAL             MUST
2295	    DTSTAMP          MUST
2296	    DTSTART          MUST
2297	    ORGANIZER        MUST
2298	    SEQUENCE         MUST be greater than 0
2299	    SUMMARY          MUST be present and MAY be NULL
2300	    UID              MUST match that of the original journal

2302	    ATTACH           MAY
2303	    CATEGORIES       MAY
2304	    CLASS            MAY
2305	    COMMENT          MAY
2306	    CONTACT          MAY
2307	    CREATED          MAY
2308	    DESCRIPTION      MAY be present; may be null.
2309	    DURATION         MAY
2310	    DTEND            MAY
2311	    EXDATE           MAY
2312	    EXRULE           MAY
2313	    GEO              MAY
2314	    LAST-MODIFIED    MAY
2315	    LOCATION         MAY
2316	    PRIORITY         MAY
2317	    RELATED-TO       MAY
2318	    RDATE            MAY
2319	    RESOURCES        MAY
2320	    RRULE            MAY
2321	    STATUS           MAY be one of DRAFT/FINAL/CANCELLED
2322	    TRANSP           MAY
2323	    URL              MAY

2325	    ATTENDEE         NOT
2326	    RECURRENCE-ID    NOT

2328	VEVENT               MAY
2329	VTODO                MAY
2330	VTIMEZONE            MUST be present if any date/time refers to a
2331	                         timezone
2332	VALARM               MAY
2333	VFREEBUSY            MAY
2334	X-TOKENS             MAY

2336	3.5.3     CANCEL

2338	The "CANCEL" method in a "VJOURNAL" calendar component is used to send a
2339	cancellation notice of an existing journal entry. The message is sent by
2340	the "Organizer" of a journal entry. For a recurring journal entry,
2341	either the whole journal entry or instances of a journal entry may be
2342	cancelled. To cancel the complete range of a recurring journal entry,
2343	the "UID" property value for the journal entry MUST be specified and a
2344	"RECURRENCE-ID" property MUST NOT be specified in the "CANCEL" method.
2345	In order to cancel an individual instance of the journal entry, the
2346	"RECURRENCE-ID" property value for the journal entry MUST be specified
2347	in the "CANCEL" method.

2349	There are two options for canceling a sequence of instances of a
2350	recurring "VJOURNAL" calendar component:

2352	(a)    the "RECURRENCE-ID" property for an instance in the sequence MUST be
2353	  specified with the "RANGE" property parameter value of THISANDPRIOR
2354	  (or THISANDFUTURE)  to indicate cancellation of the specified "VTODO"
2355	  calendar component and all instances before (or after); or

2357	(b)    individual recurrence instances may be cancelled by specifying
2358	  multiple "RECURRENCE-ID" properties corresponding to the instances to
2359	  be cancelled.

2361	This method type is an iCalendar object that conforms to the following
2362	property constraints:

2364	Component/Property   Presence
2365	-------------------  ---------------------------------------------
2366	PRODID              MUST
2367	VERSION             MUST be "2.0"
2368	METHOD              MUST be "CANCEL"
2369	VJOURNAL            MUST
2370	    DTSTAMP         MUST
2371	    ORGANIZER       MUST
2372	    RECURRENCE-ID   MUST only if referring to an instance of a
2373	                         recurring calendar component.  Otherwise it
2374	                         MUST NOT be present.
2375	    SEQUENCE        MUST
2376	    UID             MUST be the UID of the original REQUEST

2378	    COMMENT         MAY
2379	    STATUS          MAY be present, must be "CANCELLED" if present
2380	    ATTACH          MAY
2381	    ATTENDEE        MAY
2382	    CATEGORIES      MAY
2383	    CLASS           MAY
2384	    CONTACT         MAY
2385	    CREATED         MAY
2386	    DESCRIPTION     MAY
2387	    DTSTART         MAY
2388	    DTEND           MAY
2389	    EXDATE          MAY
2390	    EXRULE          MAY
2391	    GEO             MAY
2392	    LAST-MODIFIED   MAY
2393	    %-COMPLETE      MAY
2394	    PRIORITY        MAY
2395	    RELATED-TO      MAY
2396	    REQUEST-STATUS  MAY
2397	    RESOURCES       MAY
2398	    RDATE           MAY
2399	    RRULE           MAY
2400	    STATUS          MAY
2401	    SUMMARY         MAY
2402	    TRANSP          MAY
2403	    URL             MAY

2405	VTODO               MAY
2406	VEVENT              MAY
2407	VFREEBUSY           MAY
2408	VTIMEZONE           MUST be present if any date/time refers to a
2409	                        timezone
2410	VALARM              MAY
2411	X-TOKENS            MAY

2413	3.6 Status Replies

2415	The "REQUEST-STATUS" property may include the following values:

2417	|==============+============================+=========================|
2418	| Short Return | Longer Return Status       | Offending Data          |
2419	| Status Code  | Description                |                         |
2420	|==============+============================+=========================|
2421	| 2.0          | Success.                   | None.                   |
2422	|==============+============================+=========================|
2423	| 2.1          | Success but fallback taken | Property name and value |
2424	|              | on one or more property    | MAY be specified.       |
2425	|              | values.                    |                         |
2426	|==============+============================+=========================|
2427	| 2.2          | Success, invalid property  | Property name MAY be    |
2428	|              | ignored.                   | specified.              |
2429	|==============+============================+=========================|
2430	| 2.3          | Success, invalid property  | Property parameter name |
2431	|              | parameter ignored.         | and value MAY be        |
2432	|              |                            | specified.              |
2433	|==============+============================+=========================|
2434	| 2.4          | Success, unknown non-      | Non-standard property   |
2435	|              | standard property ignored. | name MAY be specified.  |
2436	|==============+============================+=========================|
2437	| 2.5          | Success, unknown non       | Property and non-       |
2438	|              | standard property value    | standard value MAY be   |
2439	|              | ignored.                   | specified.              |
2440	|==============+============================+=========================|
2441	| 2.6          | Success, invalid calendar  | Calendar component      |
2442	|              | component ignored.         | sentinel (e.g., "BEGIN: |
2443	|              |                            | ALARM") MAY be          |
2444	|              |                            | specified.              |
2445	|==============+============================+=========================|
2446	| 2.7          | Success, request forwarded | Original and forwarded  |
2447	|              | to Calendar User.          | caluser addresses MAY   |
2448	|              |                            | be specified.           |
2449	|==============+============================+=========================|
2450	| 2.8          | Success, repeating event   | RRULE or RDATE property |
2451	|              | ignored. Scheduled as a    | name and value MAY be   |
2452	|              | single event.              | specified.              |
2453	|==============+============================+=========================|
2454	| 2.9          | Success, truncated end date| DTEND property value    |
2455	|              | time to date boundary.     | MAY be specified.       |
2456	|==============+============================+=========================|
2457	| 2.10         | Success, repeating VTODO   | RRULE or RDATE property |
2458	|              | ignored. Scheduled as a    | name and value MAY be   |
2459	|              | single VTODO.              | specified.              |
2460	|==============+============================+=========================|
2461	| 2.11         | Success, RRULE or EXRULE   | RRULE or EXRULE property|
2462	|              | too complex. Scheduled as  | name and value MAY be   |
2463	|              | a single event.            | specified.              |
2464	|==============+============================+=========================|
2465	| 2.12         | Success, unbounded RRULE   | RRULE property name and |
2466	|              | clipped at some finite     | value MAY be specified. |
2467	|              | number of instances        | Number of instances MAY |
2468	|              |                            | also be specified.      |
2469	|==============+============================+=========================|
2470	| 3.0          | Invalid property name.     | Property name MAY be    |
2471	|              |                            | specified.              |
2472	|==============+============================+=========================|
2473	| 3.1          | Invalid property value.    | Property name and value |
2474	|              |                            | MAY be specified.       |
2475	|==============+============================+=========================|
2476	| 3.2          | Invalid property parameter.| Property parameter name |
2477	|              |                            | and value MAY be        |
2478	|              |                            | specified.              |
2479	|==============+============================+=========================|
2480	| 3.3          | Invalid property parameter | Property parameter name |
2481	|              | value.                     | and value MAY be        |
2482	|              |                            | specified.              |
2483	|==============+============================+=========================|
2484	| 3.4          | Invalid calendar component | Calendar component      |
2485	|              | sequence.                  | sentinel MAY be         |
2486	|              |                            | specified (e.g., BEGIN: |
2487	|              |                            | VTIMEZONE).             |
2488	|==============+============================+=========================|
2489	| 3.5          | Invalid date or time.      | Date/time value(s) MAY  |
2490	|              |                            | be specified.           |
2491	|==============+============================+=========================|
2492	| 3.6          | Invalid rule.              | Rule value MAY be       |
2493	|              |                            | specified.              |
2494	|==============+============================+=========================|
2495	| 3.7          | Invalid Calendar User.     | Attendee property value |
2496	|              |                            |MAY be specified.        |
2497	|==============+============================+=========================|
2498	| 3.8          | No authority.              | PROFILE and Attendee    |
2499	|              |                            | property values MAY be  |
2500	|              |                            | specified.              |
2501	|==============+============================+=========================|
2502	| 3.9          | Unsupported version.       | VERSION property name   |
2503	|              |                            | and value MAY be        |
2504	|              |                            | specified.              |
2505	|==============+============================+=========================|
2506	| 3.10         | Request entity too large.  | None.                   |
2507	|==============+============================+=========================|
2508	| 3.11         | Required component or      | Component or property   |
2509	|              | property missing.          | name MAY be specified.  |
2510	|==============+============================+=========================|
2511	| 4.0          | Event conflict. Date/time  | DTSTART and DTEND       |
2512	|              | is busy.                   | property name and values|
2513	|              |                            | MAY be specified.       |
2514	|==============+============================+=========================|
2515	| 5.0          | Request MAY supported.     | Method property value   |
2516	|              |                            | MAY be specified.       |
2517	|==============+============================+=========================|
2518	| 5.1          | Service unavailable.       | ATTENDEE property value |
2519	|              |                            | MAY be specified.       |
2520	|==============+============================+=========================|
2521	| 5.2          | Invalid calendar service.  | ATTENDEE property value |
2522	|              |                            | MAY be specified.       |
2523	|==============+============================+=========================|
2524	| 5.3          | No scheduling support for  | ATTENDEE property value |
2525	|              | user.                      | MAY be specified.       |
2526	|==============+============================+=========================|

2528	3.7 Implementation Considerations

2530	3.7.1     Working With Recurrence Instances

2532	iCalendar includes a recurrence grammar to represent recurring events.
2533	The benefit of such a grammar is the ability to represent a number of
2534	events in a single object. However, while this simplifies creation of a
2535	recurring event, meeting instances still need to be referenced. For
2536	instance, an "Attendee" may decline the third instance of a recurring
2537	Friday event. Similarly, the "Organizer" may change the time or location
2538	to a single instance of the recurring event.

2540	Since implementations may elect to store recurring events as either a
2541	single event object or a collection of discreet, related event objects,
2542	the protocol is designed so that each recurring instance may be both
2543	referenced and versioned. Hence, implementations that choose to maintain
2544	per-instance properties (such as "ATTENDEE" property "attstat"
2545	parameter) may do so. However, the protocol does not require per-
2546	instance recognition unless the instance itself must be renegotiated.

2548	The scenarios for recurrence instance referencing are listed below. For
2549	purposes of simplification a change to an event refers to a "trigger
2550	property."  That is, a property that has a substantive effect on the
2551	meeting itself such as start time, location, due date (for "VTODO"
2552	calendar component components) and possibly description.

2554	"Organizer" initiated actions:

2556	. "Organizer" deletes or changes a single instance of a recurring event
2557	. "Organizer" makes changes that affect all future instances
2558	. "Organizer" makes changes that affect all previous instances
2559	. "Organizer" deletes or modifies a previously changed instance

2561	"Attendee" initiated actions:

2563	. "Attendee" changes status for a particular recurrence instance
2564	. "Attendee" sends Event-Counter for a particular recurrence instance

2566	An instance of a recurring event is assigned a unique identification,
2567	"RECURRENCE-ID" property, when that instance is renegotiated.
2568	Negotiation may be necessary when a substantive change to the event or
2569	to-do has be made (such as changing the start time, end time, due date
2570	or location). The "Organizer" can identify a specific recurrence
2571	instance using the "RECURRENCE-ID" property. The property value is equal
2572	to the date/time of the instance. If the "Organizer" wishes to change
2573	the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID"
2574	property and the new "DTSTART" and "DTEND" values reflect the change.
2575	Note that after the change has occurred, the "RECURRENCE-ID" has changed
2576	to the new "DTSTART" value.

2578	3.7.2     Attendee Property Considerations

2580	The "ORGANIZER" property is required on published events, to-dos, and
2581	journal entries for two reasons. First, only the "Organizer" is allowed
2582	to update and redistribute an event or to-do component. It follows that
2583	the "ORGANIZER" property MUST be present in the event, to-do, or journal
2584	entry component so that the CUA has a basis for authorizing an update.
2585	Second, it is prudent to provide a point of contact for anyone who
2586	receives a published component in case of problems.

2588	There are valid RFC 822 addresses that represent groups. Sending email
2589	to such an address results in mail being sent to multiple recipients.
2590	Such an address may be used as the value of an "ATTENDEE" property.

2592	Thus, it is possible that the recipient of a "REQUEST" does not appear
2593	explicitly in the list.

2595	It is recommended that the general approach to finding a "Calendar User"
2596	in an attendee list be as follows:

2598	     1.        Search for the "Calendar User" in the attendee list where
2599	       "TYPE=INDIVIDUAL"

2601	     2.        Failing (1) look for attendees where "TYPE=GROUP" or
2602	       'TYPE=UNKNOWN". The CUA then determines if the "Calendar User"
2603	       is a member of one of these groups. If so, the "REPLY" method
2604	       sent to the "Organizer" MUST contain a new "ATTENDEE" property
2605	       in which the "TYPE" property parameter is set to INDIVIDUAL and
2606	       the "group" property parameter is set to the name of the group.

2608	     3.        Failing (2) the CUA MAY ignore or accept the request as the
2609	       "Calendar User" wishes.

2611	3.7.3     X-Tokens

2613	To make iCalendar objects extensible, new property types MAY be inserted
2614	into components. These properties are called X-Tokens as they are
2615	prefixed with "X-". A client is not required to make sense of X-Tokens.
2616	Clients are not required to save X-Tokens or use them in replies.

2618	4  Examples

2620	4.1 Published Event Examples

2622	In the calendaring and scheduling context, publication refers to the one
2623	way transfer of event information. Consumers of published events simply
2624	incorporate the event into a calendar. No reply is expected. Individual
2625	"A" publishes an event. Individual "B" reads the event and incorporates
2626	it into their calendar. Events are published in several ways including:
2627	embedding the event as an object in a web page, e-mailing the event to a
2628	distribution list, and posting the event to a newsgroup.

2630	The table below illustrates the sequence of events between the publisher
2631	and the consumers of a published event.

2633	+-------------------------------------------------------------------+
2634	| Action                          |  "Organizer"                    |
2635	+---------------------------------+---------------------------------+
2636	| Publish an event                | "A" sends or posts a PUBLISH    |
2637	|                                 | message                         |
2638	+---------------------------------+---------------------------------+
2639	| "B" reads a published event     |                                 |
2640	+---------------------------------+---------------------------------+
2641	| Publish an updated event        | "A" sends or posts a PUBLISH    |
2642	|                                 | message                         |
2643	+---------------------------------+---------------------------------+
2644	| "B" reads the updated event     |                                 |
2645	+---------------------------------+---------------------------------+
2646	| Cancel a published event        | "A" sends or posts a CANCEL     |
2647	|                                 | message                         |
2648	+---------------------------------+---------------------------------+
2649	| "B" reads the canceled event    |                                 |
2650	|  publication                    |                                 |
2651	+---------------------------------+---------------------------------+

2653	4.1.1     A Minimal Published Event

2655	The iCalendar object below describes a single event that begins on July
2656	1, 1997 at 20:00 UTC. This event contains the minimum set of properties
2657	for a "PUBLISH" for a "VEVENT" calendar component.

2659	BEGIN:VCALENDAR
2660	METHOD:PUBLISH
2661	PRODID:-//ACME/DesktopCalendar//EN
2662	VERSION:2.0
2663	BEGIN:VEVENT
2664	ORGANIZER:mailto:a@example.com
2665	DTSTART:19970701T200000Z
2666	DTSTAMP:19970611T190000Z
2667	SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
2668	UID:0981234-1234234-23@example.com
2669	END:VEVENT
2670	END:VCALENDAR

2672	4.1.2     Changing A Published Event

2674	The iCalendar object below describes an update to the event described in
2675	4.1.1, the time has been changed, an end time has been added, and the
2676	sequence number has been adjusted.

2678	BEGIN:VCALENDAR
2679	METHOD:PUBLISH
2680	VERSION:2.0
2681	PRODID:-//ACME/DesktopCalendar//EN
2682	BEGIN:VEVENT
2683	ORGANIZER:mailto:a@example.com
2684	DTSTAMP:19970612T190000Z
2685	DTSTART:19970701T210000Z
2686	DTEND:19970701T230000Z
2687	SEQUENCE:2
2688	UID:0981234-1234234-23@example.com
2689	SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
2690	END:VEVENT
2691	END:VCALENDAR
2692	The "UID" property is used by the client to identify the event. The
2693	"SEQUENCE" property indicates that this is the second change to the
2694	event. Events with sequence numbers 0 and 1 are superseded by this
2695	event.

2697	The "SEQUENCE" property provides a reliable way to distinguish different
2698	versions of the same event. Each time an event is published, its
2699	sequence number is incremented. If a client receives an event with a
2700	sequence number 5 and finds it has the same event with sequence number
2701	2, the event SHOULD be updated. However, if the client received an event
2702	with sequence number 2 and finds it already has sequence number 5 of the
2703	same event, the event MUST NOT be updated.

2705	4.1.3     Canceling A Published Event

2707	The iCalendar object below cancels the event described in 4.1.1. This
2708	cancels the event with "SEQUENCE" property of 0, 1, and 2.

2710	BEGIN:VCALENDAR
2711	METHOD:CANCEL
2712	VERSION:2.0
2713	PRODID:-//ACME/DesktopCalendar//EN
2714	BEGIN:VEVENT
2715	ORGANIZER:mailto:a@example.com
2716	COMMENT:DUKES forfeit the game
2717	SEQUENCE:2
2718	UID:0981234-1234234-23@example.com
2719	DTSTAMP:19970613T190000Z
2720	END:VEVENT
2721	END:VCALENDAR

2723	4.1.4     A Rich Published Event

2725	This example describes the same event as in 4.1.1, but in much greater
2726	detail.

2728	BEGIN:VCALENDAR
2729	PRODID:-//ACME/DesktopCalendar//EN
2730	METHOD:PUBLISH
2731	SCALE:GREGORIAN
2732	SOURCE:http://www.midwaystadium.com/stadium-cal/1997-events.or4
2733	VERSION:2.0
2734	BEGIN:VTIMEZONE
2735	TZID:America-Chicago
2736	TZURL:http://zones.stds_r_us.net/tz/America-Chicago
2737	LAST-MODIFIED:19870101T000000Z
2738	BEGIN:STANDARD
2739	DTSTART:19671029T020000
2740	RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2741	TZOFFSETFROM:-0500
2742	TZOFFSETTO:-0600
2743	TZNAME:CST
2744	END:STANDARD
2745	BEGIN:DAYLIGHT
2746	DTSTART:19870405T020000
2747	RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2748	TZOFFSETFROM:-0600
2749	TZOFFSETTO:-0500
2750	TZNAME:CDT
2751	END:DAYLIGHT
2752	END:VTIMEZONE
2753	BEGIN:VEVENT
2754	ORGANIZER:mailto:a@example.com
2755	ATTACH:http://www.midwaystadium.com
2756	CATEGORIES:SPORTS EVENT,ENTERTAINMENT
2757	CLASS:PRIVATE
2758	CREATED:19970415T194319Z
2759	DESCRIPTION:MIDWAY STADIUM\n
2760	 Big time game. MUST see.\n
2761	 Expected duration:2 hours\n
2762	DTEND;TZID=America-Chicago:19970701T180000
2763	DTSTART;TZID=America-Chicago:19970702T160000
2764	DTSTAMP:19970614T190000Z
2765	STATUS:CONFIRMED
2766	LAST-MODIFIED:19970416T162421Z
2767	LOCATION;VALUE=URL:http://www.midwaystadium.com/
2768	PRIORITY:2
2769	RESOURCES:SCOREBOARD
2770	SEQUENCE:3
2771	SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
2772	UID:0981234-1234234-23@example.com
2773	RELATED-TO:0981234-1234234-14@example.com

2775	BEGIN:VALARM
2776	TRIGGER:PT2H
2777	ALARM-TYPE:DISPLAY
2778	DESCRIPTION:It's almost game time
2779	END:VALARM

2781	BEGIN:VALARM
2782	TRIGGER:PT30M
2783	ALARM-TYPE:AUDIO
2784	DESCRIPTION:You SHOULD leave now. Game starts in 30 minutes!
2785	END:VALARM
2786	END:VEVENT
2787	END:VCALENDAR

2789	The "RELATED-TO" field contains the "UID" property of a related calendar
2790	event. The "SEQUENCE" property 3 indicates that this event supersedes
2791	versions 0, 1, and 2.

2793	4.1.5     Anniversaries or Events attached to entire days

2795	This example demonstrates the use of the "value" parameter to tie a
2796	VEVENT to day rather than a specific time.

2798	BEGIN:VCALENDAR
2799	PRODID:-//ACME/DesktopCalendar//EN
2800	METHOD:PUBLISH
2801	VERSION:2.0
2802	BEGIN:VEVENT
2803	DTSTAMP:19970614T190000Z
2804	UID:0981234-1234234-23@example.com
2805	DTSTART;VALUE=DATE:19970714
2806	RRULE:FREQ=YEARLY;INTERVAL=1
2807	SUMMARY: Bastille Day
2808	END:VEVENT
2809	END:VCALENDAR

2811	4.2 Group Event Examples

2813	Group events are distinguished from published events in that they have
2814	"Attendees" and that there is interaction between the "Attendees" and
2815	the "Organizer" with respect to the event. Individual "A" requests a
2816	meeting between individuals "A", "B", "C" and "D". Individual "B"
2817	confirms attendance to the meeting. Individual "C" declines attendance.
2818	Individual "D" tentatively confirms attendance. The following table
2819	illustrates the the message flow between these individuals. A, the CU
2820	scheduling the meeting, is referenced as the "Organizer".

2822	+--------------------------------------------------------------------+
2823	| Action             |  "Organizer"        | Attendee                |
2824	+--------------------------------------------------------------------+
2825	| Initiate a meeting | "A" sends a REQUEST |                         |
2826	| request            | message to "B", "C",|                         |
2827	|                    | and "D"             |                         |
2828	+--------------------------------------------------------------------+
2829	| Accept the meeting |                     | "B" sends a REPLY       |
2830	| request            |                     | message to "A" with its |
2831	|                    |                     | ATTENDEE "attstat" para-|
2832	|                    |                     | set to "accepted"       |
2833	+--------------------------------------------------------------------+
2834	| Decline the meeting|                     | "C" sends a REPLY       |
2835	| request            |                     | message to "A" with its |
2836	|                    |                     | ATTENDEE "attstat" para-|
2837	|                    |                     | set to "declined"       |
2838	+--------------------------------------------------------------------+
2839	| Tentatively accept |                     | "D" sends a REPLY       |
2840	| the meeting request|                     | message to "A" with its |
2841	|                    |                     | ATTENDEE "attstat" para-|
2842	|                    |                     | set to "tentative"      |
2843	+--------------------------------------------------------------------+
2844	| Confirm meeting    | "A" sends a REQUEST |                         |
2845	| status with        | message to "B" and  |                         |
2846	| attendees          | "C" with updated    |                         |
2847	|                    | information.        |                         |
2848	+--------------------------------------------------------------------+
2849	4.2.1     A Group Event Request

2851	A sample meeting request is sent from "A" to "B", "C", and "D". _E_ is
2852	also sent a copy of the request but is not expected to attend and need
2853	not reply. "E" illustrates how CUAs might implement a "CC" type feature.
2854	Note the use of the "role" parameter. The default value for the "role"
2855	parameter is "req-participant" and it need not be enumerated. In this
2856	case we are using the value "non-participant" to indicate "E" is a non-
2857	attending CU. The parameter is not needed on other "Attendees" since
2858	"participant" is the default value.

2860	BEGIN:VCALENDAR
2861	PRODID:-//ACME/DesktopCalendar//EN
2862	METHOD:REQUEST
2863	VERSION:2.0
2864	BEGIN:VEVENT
2865	ORGANIZER:Mailto:A@example.com
2866	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
2867	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
2868	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
2869	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
2870	ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com
2871	ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
2872	DTSTAMP:19970611T190000Z
2873	DTSTART:19970701T200000Z
2874	DTEND:19970701T203000Z
2875	SUMMARY:Phone Conference
2876	UID:www.acme.com-873970198738777@example.com
2877	SEQUENCE:0
2878	STATUS:CONFIRMED
2879	END:VEVENT
2880	END:VCALENDAR

2882	4.2.2     Reply To A Group Event Request

2884	Attendee "B" accepts the meeting.

2886	BEGIN:VCALENDAR
2887	PRODID:-//ACME/DesktopCalendar//EN
2888	METHOD:REPLY
2889	VERSION:2.0
2890	BEGIN:VEVENT
2891	ATTENDEE;ATTSTAT=ACCEPTED:Mailto:B@example.com
2892	ORGANIZER:MAILTO:A@example.com
2893	UID:www.acme.com-873970198738777@example.com
2894	SEQUENCE:0
2895	REQUEST-STATUS:2.0;Success
2896	DTSTAMP:19970612T190000Z
2897	END:VEVENT
2898	END:VCALENDAR
2899	"B" could have declined the meeting or indicated tentative acceptance by
2900	setting the ATTENDEE "attstat" parameter to "declined" or "tentative",
2901	respectively. Also, "REQUEST-STATUS" is not required on a successful
2902	transactions.

2904	4.2.3     Update An Event

2906	The event is moved to a different time. The combination of the "UID"
2907	property (unchanged) and the "SEQUENCE" (bumped to 1) properties
2908	indicate the update.

2910	BEGIN:VCALENDAR
2911	PRODID:-//ACME/DesktopCalendar//EN
2912	METHOD:REQUEST
2913	VERSION:2.0
2914	BEGIN:VEVENT
2915	ORGANIZER:Mailto:A@example.com
2916	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
2917	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
2918	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
2919	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com
2920	ATTENDEE;RSVP=FALSE;TYPE=ROOM:Mailto:Conf@example.com
2921	ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
2922	DTSTART:19970701T180000Z
2923	DTEND:19970701T1200000Z
2924	SUMMARY:Phone Conference
2925	UID:www.acme.com-873970198738777@example.com
2926	SEQUENCE:1
2927	DTSTAMP:19970613T190000Z
2928	STATUS:CONFIRMED
2929	END:VEVENT
2930	END:VCALENDAR

2932	4.2.4     Countering an Event Proposal

2934	"A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to
2935	"A" to change the time and location.

2937	"A" sends the following "REQUEST":

2939	BEGIN:VCALENDAR
2940	PRODID:-//ACME/DesktopCalendar//EN
2941	METHOD:REQUEST
2942	VERSION:2.0
2943	BEGIN:VEVENT
2944	ORGANIZER:Mailto:A@example.com
2945	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
2946	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
2947	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
2948	DTSTART:19970701T190000Z
2949	DTEND:19970701T200000Z
2950	SUMMARY:Discuss the Merits of the election results
2951	LOCATION:The Big Conference Room
2952	UID:www.acme.com-873970198738777@example.com
2953	SEQUENCE:0
2954	DTSTAMP:19970611T190000Z
2955	STATUS:CONFIRMED
2956	END:VEVENT
2957	END:VCALENDAR

2959	"B" sends "COUNTER" to "A", requesting changes to time and place. "B"
2960	uses the "COMMENT" property to communicate a rationale for the change:

2962	BEGIN:VCALENDAR
2963	PRODID:-//ACME/DesktopCalendar//EN
2964	METHOD:COUNTER
2965	VERSION:2.0
2966	BEGIN:VEVENT
2967	ORGANIZER:Mailto:A@example.com
2968	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
2969	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
2970	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
2971	DTSTART:19970701T160000Z
2972	DTEND:19970701T190000Z
2973	DTSTAMP:19970612T190000Z
2974	SUMMARY:Discuss the Merits of the election results
2975	LOCATION:The Small Conference Room
2976	COMMENT:This time works much better and I think the big conference
2977	  room is too big
2978	UID:www.acme.com-873970198738777@example.com
2979	SEQUENCE:0
2980	DTSTAMP:19970611T190000Z
2981	END:VEVENT
2982	END:VCALENDAR

2984	"A" accepts the changes from "B". To accept a counter-proposal, the
2985	"Organizer" sends a new Event REQUEST with an incremented sequence
2986	number.

2988	BEGIN:VCALENDAR
2989	PRODID:-//ACME/DesktopCalendar//EN
2990	METHOD:REQUEST
2991	VERSION:2.0
2992	BEGIN:VEVENT
2993	ORGANIZER:Mailto:A@example.com
2994	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
2995	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
2996	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
2997	DTSTAMP:19970613T190000Z
2998	DTSTART:19970701T160000Z
2999	DTEND:19970701T190000Z
3000	SUMMARY:Discuss the Merits of the election results - changed to
3001	  meet B's schedule
3002	LOCATION:The Small Conference Room
3003	UID:www.acme.com-873970198738777@example.com
3004	SEQUENCE:1
3005	STATUS:CONFIRMED
3006	END:VEVENT
3007	END:VCALENDAR

3009	Instead, "A" rejects "B's" counter proposal

3011	BEGIN:VCALENDAR
3012	PRODID:-//ACME/DesktopCalendar//EN
3013	METHOD:DECLINECOUNTER
3014	VERSION:2.0
3015	BEGIN:VEVENT
3016	ORGANIZER:Mailto:A@example.com
3017	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
3018	COMMENT:Sorry, I cannot change this meeting time
3019	UID:www.acme.com-873970198738777@example.com
3020	SEQUENCE:1
3021	DTSTAMP:19970614T190000Z
3022	END:VEVENT

3024	4.2.5     Delegating an Event

3026	When delegating an event request to another "Calendar User", the
3027	"Delegator" must both update the "Organizer" with a "REPLY" and send a
3028	request to the "Delegate". There is currently no protocol limitation to
3029	delegation depth. It is possible for the original delegate to delegate
3030	the meeting to someone else, and so on. When a request is delegated from
3031	one CUA to another there are a number of responsibilities required of
3032	the "Delegator". They MUST:

3034	. Send an REPLY to the "Organizer" with their "ATTENDEE" property
3035	  "attstat" parameter set to "delegated"
3036	. Include the delegate as an additional "Attendee" with the "delegated-
3037	  from" property parameter set to the value of the delegator
3038	. Include the original UID of the "REQUEST" method
3039	. The "Delegator" MUST also send a copy of the original "REQUEST"
3040	  method to the "Delegate". The delegator modifies the request as
3041	  follows:
3042	. The "ATTENDEE" property "attstat" parameter for the delegator (sender
3043	  in this case) is set to "delegated"
3044	. "ATTENDEE" "delegated-to" parameter is set to the address of the
3045	  "Delegate"
3046	. An "ATTENDEE" property is added for the "Delegate"

3048	It is not required that the "Delegate" include the "Delegator" in their
3049	"REPLY" method. However, it is strongly advised since this will inform
3050	the "Delegator" whether the "Delegate" plans to attend the meeting. If
3051	the "Delegate" declines the meeting, the "Delegator" may elect to
3052	delegate the "REQUEST" to another CUA. The process is the same.

3054	+---------------------------------------------------------------------+
3055	| Action             |  "Organizer"        | Attendee                 |
3056	+---------------------------------------------------------------------+
3057	| Initiate a meeting | "A" sends a REQUEST |                          |
3058	| request            | message to "B" and  |                          |
3059	|                    | "C"                 |                          |
3060	+---------------------------------------------------------------------+
3061	| Delegate:          |                     | "C" sends a REPLY to "A" |
3062	| "C" delegates to   |                     | with the ATTENDEE.       |
3063	| "E"                |                     | "attstat"parameter set to|
3064	|                    |                     | "delegated" and with a   |
3065	|                    |                     | new "ATTENDEE" property  |
3066	|                    |                     | for "E". "E's" ATTENDEE  |
3067	|                    |                     | "delegated-from" param   |
3068	|                    |                     | is set to "C". "C's"     |
3069	|                    |                     | ATTENDEE "delegated-to"  |
3070	|                    |                     | param is set to "E".     |
3071	|                    |                     | "C" sends REQUEST message|
3072	|                    |                     | to "E" with the original |
3073	|                    |                     | meeting request          |
3074	|                    |                     | information. The         |
3075	|                    |                     |  "attstat" property      |
3076	|                    |                     | parameter for "C" is set |
3077	|                    |                     | to "delegated" and the   |
3078	|                    |                     |  "delegated-to"          |
3079	|                    |                     | parameter is set to      |
3080	|                    |                     | the address of "E". An   |
3081	|                    |                     | "ATTENDEE" property is   |
3082	|                    |                     | added for "E" and the    |
3083	|                    |                     | "delegated-from"         |
3084	|                    |                     | parameter is set to      |
3085	|                    |                     | the address of "C".      |
3086	+---------------------------------------------------------------------+
3087	| Confirm meeting    |                     | "E" sends REPLY message  |
3088	| attendance         |                     | to "A" and optionally "C"|
3089	|                    |                     | with its "attstat"       |
3090	|                    |                     | property parameter set   |
3091	|                    |                     | to "accepted"            |
3092	+---------------------------------------------------------------------+
3093	| Optional:          | "A" sends REQUEST   |                          |
3094	| Redistribute       | message to "B", "C" |                          |
3095	| meeting to         | and "E". SEQUENCE   |                          |
3096	| attendees          | number is now 1.    |                          |
3097	+---------------------------------------------------------------------+

3099	"C" responds to the "Organizer".

3101	BEGIN:VCALENDAR
3102	PRODID:-//ACME/DesktopCalendar//EN
3103	METHOD:REPLY
3104	VERSION:2.0
3105	BEGIN:VEVENT
3106	ORGANIZER:MAILTO:A@Example.com
3107	ATTENDEE;ATTSTAT=DELEGATED;DELEGATED-
3108	TO=Mailto:E@example.com:Mailto:C@example.com
3109	UID:www.acme.com-873970198738777@example.com
3110	SEQUENCE:0
3111	REQUEST-STATUS:2.0;Success
3112	DTSTAMP:19970611T190000Z
3113	END:VEVENT
3114	END:VCALENDAR

3116	Attendee "C" delegates presence at the meeting to "E".

3118	BEGIN:VCALENDAR
3119	PRODID:-//ACME/DesktopCalendar//EN
3120	METHOD:REQUEST
3121	VERSION:2.0
3122	BEGIN:VEVENT
3123	ORGANIZER:Mailto:A@example.com
3124	ATTENDEE;ATTSTAT=DELEGATED;DELEGATED-
3125	TO=Mailto:E@example.com:Mailto:C@example.com
3126	ATTENDEE;ROLE=DELEGATE;RSVP=TRUE;
3127	 DELEGATED-FROM=Mailto:C@example.com:Mailto:E@example.com
3128	DTSTART:19970701T180000Z
3129	DTEND:19970701T120000Z
3130	SUMMARY:Phone Conference
3131	UID:www.acme.com-873970198738777@example.com
3132	SEQUENCE:0
3133	STATUS:CONFIRMED
3134	DTSTAMP:19970611T190000Z
3135	END:VEVENT
3136	END:VCALENDAR

3138	4.2.6     Delegate Accepts the Meeting

3140	To accept a delegated meeting, the delegate, "E", sends the following
3141	message to "A" and "C"

3143	BEGIN:VCALENDAR
3144	PRODID:-//ACME/DesktopCalendar//EN
3145	METHOD:REPLY
3146	VERSION:2.0
3147	BEGIN:VEVENT
3148	ORGANIZER:MAILTO:A@Example.com
3149	ATTENDEE;ATTSTAT=CONFIRMED;DELEGATED-
3150	FROM=Mailto:C@example.com:Mailto:E@example.com
3151	ATTENDEE;ATTSTAT=DELEGATED;DELEGATED-
3152	TO=Mailto:E@example.com:Mailto:C@example.com
3153	UID:www.acme.com-873970198738777@example.com
3154	SEQUENCE:1
3155	REQUEST-STATUS:2.0;Success
3156	DTSTAMP:19970614T190000Z
3157	END:VEVENT
3158	END:VCALENDAR

3160	4.2.7     Delegate Declines the Meeting

3162	In this example the "Delegate" declines the meeting request and sets the
3163	"ATTENDEE" property "attstat" parameter to DECLINED. The "Organizer"
3164	SHOULD resend the "REQUEST" to "C" with the "attstat" parameter of the
3165	"Delegate" set to "declined". This lets the "Delegator" know that the
3166	"Delegate" has declined and provides an opportunity to the "Delegator"
3167	to either accept the request or delegate it to another CU.

3169	Response from "E" to "A" and "C".

3171	BEGIN:VCALENDAR
3172	PRODID:-//ACME/DesktopCalendar//EN
3173	METHOD:REPLY
3174	VERSION:2.0
3175	BEGIN:VEVENT
3176	ORGANIZER:MAILTO:A@Example.com
3177	ATTENDEE;ATTSTAT=DECLINED;DELEGATED-
3178	FROM=Mailto:C@example.com:Mailto:E@example.com
3179	UID:www.acme.com-873970198738777@example.com
3180	ATTENDEE;ATTSTAT=DELEGATED;DELEGATED-
3181	TO=Mailto:E@example.com:Mailto:C@example.com
3182	SEQUENCE:1
3183	REQUEST-STATUS:2.0;Success
3184	DTSTAMP:19970614T190000Z
3185	END:VEVENT
3186	END:VCALENDAR

3188	"A" resends the "REQUEST" method to "C". "A" may also wish to express
3189	the fact that the item was delegated in the "COMMENT" property.

3191	BEGIN:VCALENDAR
3192	PRODID:-//ACME/DesktopCalendar//EN
3193	METHOD:REPLY
3194	VERSION:2.0
3195	BEGIN:VEVENT
3196	ORGANIZER:MAILTO:A@Example.com
3197	ATTENDEE;ATTSTAT=DECLINED;DELEGATED-
3198	FROM=Mailto:C@example.com:Mailto:E@example.com
3199	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
3200	UID:www.acme.com-873970198738777@example.com
3201	SEQUENCE:2
3202	REQUEST-STATUS:2.0;Success
3203	DTSTAMP:19970614T200000Z
3204	COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR
3205	 INVITATION
3206	END:VEVENT
3207	END:VCALENDAR

3209	4.2.8     Forwarding an Event Request

3211	The protocol does not prevent an "Attendee" from "forwarding" an
3212	"VEVENT" calendar component to other "Calendar Users". Forwarding
3213	differs from delegation in that the forwarded "Calendar User" (often
3214	referred to as a "Party Crasher") does not replace the forwarding
3215	"Calendar User". Implementations are not required to add the "Party
3216	Crasher" to the "Attendee" list and hence there is no guarantee that a
3217	"Party Crasher" will receive additional updates to the Event. The
3218	forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the
3219	attendee list. The "Organizer" MAY add the forwarded "Calendar User" to
3220	the attendee list.

3222	4.2.9     Cancel A Group Event

3224	Individual "A" requests a meeting between individuals "A", "B", "C", and
3225	"D". Individual "B" declines attendance to the meeting. Individual "A"
3226	decides to cancel the meeting. The following table illustrates the
3227	sequence of messages that would be exchanged between these individuals.

3229	Messages related to a previously canceled event ("SEQUENCE" property
3230	value is less than the "SEQUENCE" property value of the "CANCEL"
3231	message) MUST be ignored.

3233	+--------------------------------------------------------------------+
3234	| Action             |  "Organizer"        | "Attendee"              |
3235	+--------------------------------------------------------------------+
3236	| Initiate a meeting | "A" sends a REQUEST |                         |
3237	| request            | message to "B", "C",|                         |
3238	|                    | and "D"             |                         |
3239	+--------------------------------------------------------------------+
3240	| Decline the meeting|                     | "B" sends a "REPLY"     |
3241	| request            |                     | message to "A" with its |
3242	|                    |                     | "attstat" para-         |
3243	|                    |                     | set to "declined".      |
3244	+--------------------------------------------------------------------+
3245	| Cancel the meeting | "A" sends a CANCEL  |                         |
3246	|                    | message to "B", "C" |                         |
3247	|                    | and "D"             |                         |
3248	+--------------------------------------------------------------------+

3250	The example shows how "A" cancels the event.

3252	BEGIN:VCALENDAR
3253	PRODID:-//ACME/DesktopCalendar//EN
3254	METHOD:CANCEL
3255	VERSION:2.0
3256	BEGIN:VEVENT
3257	ORGANIZER:Mailto:A@example.com
3258	ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com
3259	ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com
3260	ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
3261	ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
3262	COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
3263	UID:www.acme.com-873970198738777@example.com
3264	SEQUENCE:0
3265	STATUS:CANCELLED
3266	DTSTAMP:19970613T190000Z
3267	END:VEVENT
3268	END:VCALENDAR

3270	4.2.10    Removing Attendees

3272	"A" wants to remove "B" from a meeting. This is done by sending a
3273	"CANCEL" to "B" and removing "B" from the attendee list in the master
3274	copy of the event.

3276	+--------------------------------------------------------------------+
3277	| Action             |  "Organizer"        | "Attendee"              |
3278	+--------------------------------------------------------------------+
3279	| Remove an "B"      | "A" sends a CANCEL  |                         |
3280	| as an "Attendee"   | message to "B"      |                         |
3281	+--------------------------------------------------------------------+
3282	| Update the master  | "A" sends the       |                         |
3283	| copy of the event  | updated event to    |                         |
3284	|                    | the remaining       |                         |
3285	|                    | "Attendees"         |                         |
3286	+--------------------------------------------------------------------+

3288	The original meeting includes "A", "B", "C", and "D". The example below
3289	shows the "CANCEL" that "A" sends to "B". Note that in the example below
3290	the "STATUS" property is omitted. This is used when the meeting itself
3291	is cancelled and not when the intent is to remove an "Attendee" from the
3292	Event.

3294	BEGIN:VCALENDAR
3295	PRODID:-//ACME/DesktopCalendar//EN
3296	METHOD:CANCEL
3297	VERSION:2.0
3298	BEGIN:VEVENT
3299	ORGANIZER:Mailto:A@example.com
3300	COMMENT:You're off the hook for this meeting
3301	UID:www.acme.com-873970198738777@example.com
3302	DTSTAMP:19970613T193000Z
3303	END:VEVENT
3304	END:VCALENDAR

3306	The updated master copy of the event is shown below. The "Organizer" MAY
3307	resend the updated event to the remaining "Attendees". Note that "B" has
3308	been removed.

3310	BEGIN:VCALENDAR
3311	PRODID:-//ACME/DesktopCalendar//EN
3312	METHOD:REQUEST
3313	VERSION:2.0
3314	BEGIN:VEVENT
3315	ORGANIZER:Mailto:A@example.com
3316	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3317	ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
3318	ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
3319	ATTENDEE;TYPE=ROOM:CR_Big@example.com
3320	ATTENDEE;ROLE=NON-PARTICIPANT;
3321	 RSVP=FALSE:Mailto:E@example.com
3322	DTSTAMP:19970611T190000Z
3323	DTSTART:19970701T200000Z
3324	DTEND:19970701T203000Z
3325	SUMMARY:Phone Conference
3326	UID:www.acme.com-873970198738777@example.com
3327	SEQUENCE:0
3328	STATUS:CONFIRMED
3329	END:VEVENT
3330	END:VCALENDAR

3332	4.2.11    Replacing the Organizer

3334	The scenario for this example begins with "A" as the "Organizer" for a
3335	recurring meeting with "B", "C", and "D". "A" receives a new job offer
3336	in another country and leaves without changing the "Organizer" to this
3337	meeting.  "A" left no forwarding address or way to be reached.  Using
3338	out-of-band communication, the other "Attendees" eventually learn what
3339	has happened and reach an agreement that "B" should become the new
3340	"Organizer" for the meeting. To do this, "B" sends out a new version of
3341	the event and the other "Attendees" agree to accept "B" as the new
3342	"Organizer". "B" also removes "A" from the event

3344	This is the message "B" sends to "C" and "D"

3346	BEGIN:VCALENDAR
3347	PRODID:-//ACME/DesktopCalendar//EN
3348	METHOD:REQUEST
3349	VERSION:2.0
3350	BEGIN:VEVENT
3351	ORGANIZER:Mailto:B@example.com
3352	ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com
3353	ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
3354	ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
3355	DTSTAMP:19970611T190000Z
3356	DTSTART:19970701T200000Z
3357	DTEND:19970701T203000Z
3358	RRULE:FREQ=WEEKLY
3359	SUMMARY:Phone Conference
3360	UID:123456@example.com
3361	SEQUENCE:1
3362	STATUS:CONFIRMED
3363	END:VEVENT
3364	END:VCALENDAR
3365	4.3 Busy Time Examples

3367	Busy time objects can be used in several ways. First, a CU may Request
3368	busy time from another CU for a specific range of time. That request can
3369	be answered with a busy time Reply. Additionally, a CU may simply
3370	publish busy their busy time for a given interval and point other CUs to
3371	the published location. The following examples outline both scenarios.

3373	Individual "A" publishes Busy time for one week.

3375	BEGIN:VCALENDAR
3376	PRODID:-//ACME/DesktopCalendar//ENVERSION:2.0
3377	METHOD:PUBLISH
3378	BEGIN:VFREEBUSY
3379	DTSTAMP:19980101T124100Z
3380	ATTENDEE:MAILTO:A@Example.com
3381	DTSTART:19980101T124200Z
3382	DTEND:19980107T124200Z
3383	FREEBUSY:19980101T180000Z/19980101T190000Z
3384	FREEBUSY:19980103T020000Z/19980103T050000Z
3385	FREEBUSY:19980107T020000Z/19980107T050000Z
3386	FREEBUSY:19980113T000000Z/19980113T010000Z
3387	FREEBUSY:19980115T190000Z/19980115T200000Z
3388	FREEBUSY:19980115T220000Z/19980115T230000Z
3389	FREEBUSY:19980116T013000Z/19980116T043000Z
3390	END:VFREEBUSY
3391	END:VCALENDAR

3393	Individual "A" requests busy time from individuals "B", "C". Individual
3394	"B" and "C" replies with busy time data to individual "A". The following
3395	table illustrates the sequence of messages that would be exchanged
3396	between these individuals.

3398	+--------------------------------------------------------------------+
3399	| Action             |  "Organizer"        | Attendee                |
3400	+--------------------------------------------------------------------+
3401	| Initiate a busy    | "A" sends "REQUEST" |                         |
3402	| time request       | message to "B" and  |                         |
3403	|                    | and "C"             |                         |
3404	+--------------------------------------------------------------------+
3405	| Reply to the "BUSY"|                     | "B" sends a "REPLY"     |
3406	| request with "BUSY"|                     | message to "A" with     |
3407	| time data          |                     | busy time data          |
3408	+--------------------------------------------------------------------+

3410	4.3.1     Request Busy Time

3412	"A" sends a "BUSY-REQUEST" to "B" and "C" for busy time
3413	BEGIN:VCALENDAR
3414	PRODID:-//ACME/DesktopCalendar//EN
3415	METHOD:REQUEST
3416	VERSION:2.0
3417	BEGIN:VFREEBUSY
3418	ORGANIZER:Mailto:A@example.com
3419	ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
3420	ATTENDEE:Mailto:B@example.com
3421	ATTENDEE:Mailto:C@example.com
3422	DTSTAMP:19970613T190000Z
3423	DTSTART:19970701T080000Z
3424	DTEND:19970701T200000
3425	UID:www.acme.com-873970198738777@example.com
3426	END:VFREEBUSY
3427	END:VCALENDAR

3429	4.3.2     Reply To A Busy Time Request

3431	"B" sends a "REPLY" method type of a "VFREEBUSY" calendar component to
3432	"A"

3434	BEGIN:VCALENDAR
3435	PRODID:-//ACME/DesktopCalendar//EN
3436	METHOD:REPLY
3437	VERSION:2.0
3438	BEGIN:VFREEBUSY
3439	ORGANIZER:MAILTO:A@example.com
3440	ATTENDEE:Mailto:B@example.com
3441	DTSTART:19970701T080000Z
3442	DTEND:19970701T200000Z
3443	UID:www.acme.com-873970198738777@example.com
3444	FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30H
3445	DTSTAMP:19970613T190030Z
3446	END:VFREEBUSY
3447	END:VCALENDAR

3449	"B" is busy from 09:00 to 10:00 and from 14:00 to 14:30.

3451	4.4 Recurring Event and Time Zone Examples

3453	4.4.1     A Recurring Event Spanning Time Zones

3455	This event describes a weekly phone conference. The "Attendees" are each
3456	in a different time zone.

3458	BEGIN:VCALENDAR

3460	PRODID:-//ACME/DesktopCalendar//EN
3461	METHOD:REQUEST
3462	VERSION:2.0

3464	BEGIN:VTIMEZONE
3465	TZID:America-SanJose
3466	TZURL:http://zones.stds_r_us.net/tz/America-SanJose
3467	LAST-MODIFIED:19870101T000000Z
3468	BEGIN:STANDARD
3469	DTSTART:19671029T020000
3470	RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3471	TZOFFSETFROM:-0700
3472	TZOFFSETTO:-0800
3473	TZNAME:PST
3474	END:STANDARD
3475	BEGIN:DAYLIGHT
3476	DTSTART:19870405T020000
3477	RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3478	TZOFFSETFROM:-0800
3479	TZOFFSETTO:-0700
3480	TZNAME:PDT
3481	END:DAYLIGHT
3482	END:VTIMEZONE

3484	BEGIN:VEVENT
3485	ORGANIZER:Mailto:A@example.com
3486	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM
3487	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr
3488	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp
3489	DTSTAMP:19970613T190030Z
3490	DTSTART;TZID=America-SanJose:19970701T140000
3491	DTEND;TZID=America-SanJose:19970701T150000
3492	RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU
3493	RDATE;TZID=America-SanJose:19970910T140000
3494	EXDATE;TZID=America-SanJose:19970909T140000
3495	EXDATE;TZID=America-SanJose:19971028T140000
3496	SUMMARY:Weekly Phone Conference
3497	UID:www.acme.com-873970198738777@example.com
3498	SEQUENCE:0
3499	STATUS:CONFIRMED
3500	END:VEVENT

3502	END:VCALENDAR

3504	The first two components of this iCalendar object are the time zone
3505	components. The "DTSTART" date coincides with the first instance of the
3506	RRULE property.

3508	The recurring meeting is defined in a particular time zone, presumably
3509	that of the originator. The client for each "Attendee" has the
3510	responsibility of determining the recurrence time in the "Attendee's"
3511	time zone.

3513	The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT.
3514	"Attendee" B@example.fr is in France where the local time on this date
3515	is 7 hours later than PDT or 21:00. "Attendee" C@example.jp is in Japan
3516	where local time is 9 hours ahead of than UTC or Wednesday, July 2 at
3517	07:00. The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE"
3518	property results in 20 instances. The last instance falls on Tuesday,
3519	November 11, 1997 2:00pm PST. The "RDATE" property adds another
3520	instance: WED, 10-SEP-1997 2:00 PM PST.

3522	There are two exceptions to this recurring appointment. The first one
3523	is:

3525	TUE, 09-SEP-1997 21:00 GMT
3526	TUE, 09-SEP-1997 14:00 PDT
3527	WED, 10-SEP-1997 07:00 JDT

3529	and the second is:

3531	TUE, 28-OCT-1997 22:00 GMT
3532	TUE, 28-OCT-1997 14:00 PST
3533	WED, 29-OCT-1997 07:00 JST

3535	4.4.2     Modify A Recurring Instance

3537	In this example the "Organizer" issues a recurring meeting. Later the
3538	"Organizer" changes an instance of the event by changing the "DTSTART"
3539	property. Note the use of "RECURRENCE-ID" property and "SEQUENCE"
3540	property in the second request.

3542	Original Request:

3544	BEGIN:VCALENDAR
3545	METHOD:REQUEST
3546	PRODID:-//RDU Software//NONSGML HandCal//EN
3547	VERSION:2.0
3548	BEGIN:VEVENT
3549	CREATED:19970526T083000Z
3550	UID:guid-1@host1.com
3551	SEQUENCE:0
3552	RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
3553	ORGANIZER:Mailto:A@example.com
3554	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3555	ATTENDEE:Mailto:B@example.com
3556	ATTENDEE:Mailto:C@example.com
3557	ATTENDEE:Mailto:D@example.com
3558	DESCRIPTION:IETF-C&S Conference Call
3559	CLASS:PUBLIC
3560	SUMMARY:IETF Calendaring Working Group Meeting
3561	DTSTART:19970601T210000Z
3562	DTEND:19970601T220000Z
3563	LOCATION:Conference Call
3564	DTSTAMP:19970526T083000Z
3565	STATUS:CONFIRMED
3566	END:VEVENT
3567	END:VCALENDAR
3568	The event request below is to change the time of a specific instance.
3569	This changes the July 1st instance to July 3rd.

3571	BEGIN:VCALENDAR
3572	METHOD:REQUEST
3573	PRODID:-//RDU Software//NONSGML HandCal//EN
3574	VERSION:2.0
3575	BEGIN:VEVENT
3576	CREATED:19970526T083000Z
3577	UID:guid-1@host1com
3578	RECURRENCE-ID:19970701T210000Z
3579	SEQUENCE:1
3580	ORGANIZER:Mailto:A@example.com
3581	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3582	ATTENDEE:Mailto:B@example.com
3583	ATTENDEE:Mailto:C@example.com
3584	ATTENDEE:Mailto:D@example.com
3585	DESCRIPTION:IETF-C&S Conference Call
3586	CLASS:PUBLIC
3587	SUMMARY:IETF Calendaring Working Group Meeting
3588	DTSTART:19970703T210000Z
3589	DTEND:19970703T220000Z
3590	LOCATION:Conference Call
3591	DTSTAMP:19970626T093000Z
3592	STATUS:CONFIRMED
3593	END:VEVENT
3594	END:VCALENDAR

3596	4.4.3     Cancel an Instance

3598	In this example the "Organizer" of a recurring event deletes the August
3599	1st instance.

3601	BEGIN:VCALENDAR
3602	METHOD:CANCEL
3603	PRODID:-//RDU Software//NONSGML HandCal//EN
3604	VERSION:2.0
3605	BEGIN:VEVENT
3606	UID:guid-1@host1.com
3607	ORGANIZER:Mailto:A@example.com
3608	RECURRENCE-ID:19970801T210000Z
3609	SEQUENCE:2
3610	STATUS:CANCELLED
3611	DTSTAMP:19970721T093000Z
3612	END:VEVENT
3613	END:VCALENDAR
3614	4.4.4     Cancel Recurring Event

3616	In this example the "Organizer" wishes to cancel the entire recurring
3617	event and any exceptions.

3619	BEGIN:VCALENDAR
3620	METHOD:CANCEL
3621	PRODID:-//RDU Software//NONSGML HandCal//EN
3622	VERSION:2.0
3623	BEGIN:VEVENT
3624	UID:guid-1@host1.com
3625	ORGANIZER:Mailto:A@example.com
3626	DTSTAMP:19970721T103000Z
3627	SEQUENCE:2
3628	END:VEVENT
3629	END:VCALENDAR

3631	4.4.5     Change All Future Instances

3633	This example changes the meeting location from a conference call to
3634	Seattle starting September 1 and extends to all future instances.

3636	BEGIN:VCALENDAR
3637	METHOD:REQUEST
3638	PRODID:-//RDU Software//NONSGML HandCal//EN
3639	VERSION:2.0
3640	BEGIN:VEVENT
3641	CREATED:19970526T083000Z
3642	UID:guid-1@host1.com
3643	RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
3644	SEQUENCE:3
3645	ORGANIZER:Mailto:A@example.com
3646	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3647	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3648	ATTENDEE;RSVP=TRUE:Mailto:C@example.com
3649	ATTENDEE;RSVP=TRUE:Mailto:D@example.com
3650	DESCRIPTION:IETF-C&S Discussion
3651	CLASS:PUBLIC
3652	SUMMARY:IETF Calendaring Working Group Meeting
3653	DTSTART:19970901T210000Z
3654	DTEND:19970901T220000Z
3655	LOCATION:Building 32, Microsoft, Seattle, WA
3656	DTSTAMP:19970526T083000Z
3657	STATUS:CONFIRMED
3658	END:VEVENT
3659	END:VCALENDAR

3661	4.4.6     Add A New Instance To A Recurring Event

3663	This example adds a one-time additional instance to the recurring event.
3664	"Organizer" adds a second July meeting on the 15th.

3666	BEGIN:VCALENDAR
3667	METHOD:ADD
3668	PRODID:-//RDU Software//NONSGML HandCal//EN
3669	VERSION:2.0
3670	BEGIN:VEVENT
3671	CREATED:19970526T083000Z
3672	UID:123456789@host1.com
3673	SEQUENCE:4
3674	ORGANIZER:Mailto:A@example.com
3675	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3676	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3677	ATTENDEE;RSVP=TRUE:Mailto:C@example.com
3678	ATTENDEE;RSVP=TRUE:Mailto:D@example.com
3679	DESCRIPTION:IETF-C&S Conference Call
3680	CLASS:PUBLIC
3681	SUMMARY:IETF Calendaring Working Group Meeting
3682	DTSTART:19970715T210000Z
3683	DTEND:19970715T220000Z
3684	LOCATION:Conference Call
3685	DTSTAMP:19970629T093000Z
3686	STATUS:CONFIRMED
3687	END:VEVENT
3688	END:VCALENDAR

3690	4.4.7     Add A New Series of Instances To A Recurring Event

3692	The scenario for this example involves an ongoing meeting, originally
3693	set up to occur every Tuesday.  The "Organizer" later decides that the
3694	meetings need to be on Tuesdays and Thursdays, but does not want to
3695	reschedule the entire meeting or lose any of the per-instance
3696	information already collected.

3698	The original event:

3700	BEGIN:VCALENDAR
3701	METHOD:REQUEST
3702	PRODID:-//RDU Software//NONSGML HandCal//EN
3703	VERSION:2.0
3704	BEGIN:VEVENT
3705	UID:123456789@host1.com
3706	SEQUENCE:0
3707	RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY
3708	ORGANIZER:Mailto:A@example.com
3709	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3710	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3711	SUMMARY:Review Accounts
3712	DTSTART:19980303T210000Z
3713	DTEND:19980303T220000Z
3714	LOCATION:The White Room
3715	DTSTAMP:19980301T093000Z
3716	STATUS:CONFIRMED
3717	END:VEVENT
3718	END:VCALENDAR
3719	The "Organizer" adds Thursdays to the event:

3721	BEGIN:VCALENDAR
3722	METHOD:ADD
3723	PRODID:-//RDU Software//NONSGML HandCal//EN
3724	VERSION:2.0
3725	BEGIN:VEVENT
3726	UID:123456789@host1.com
3727	SEQUENCE:7
3728	RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY
3729	ORGANIZER:Mailto:A@example.com
3730	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3731	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3732	SUMMARY:Review Accounts
3733	DTSTART:19980303T210000Z
3734	DTEND:19980303T220000Z
3735	DTSTAMP:19980303T193000Z
3736	LOCATION:The Usual conference room
3737	STATUS:CONFIRMED
3738	END:VEVENT
3739	END:VCALENDAR

3741	Alternatively, if the "Organizer" is not concerned with per-instance
3742	updates, the entire event can be rescheduled using a "REQUEST". This is
3743	done by using the "UID" of the event to reschedule and including the
3744	modified RRULE.

3746	BEGIN:VCALENDAR
3747	METHOD:ADD
3748	PRODID:-//RDU Software//NONSGML HandCal//EN
3749	VERSION:2.0
3750	BEGIN:VEVENT
3751	UID:123456789@host1.com
3752	SEQUENCE:7
3753	RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY
3754	ORGANIZER:Mailto:A@example.com
3755	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3756	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3757	SUMMARY:Review Accounts
3758	DTSTART:19980303T210000Z
3759	DTEND:19980303T220000Z
3760	DTSTAMP:19980303T193000Z
3761	LOCATION:The White Room
3762	STATUS:CONFIRMED
3763	END:VEVENT
3764	END:VCALENDAR

3766	The next series of examples illustrate how an "Organizer" would respond
3767	to a "REFRESH" submitted by an "Attendee" after a series of instance-
3768	specific modifications. To convey all instance-specific changes, the
3769	"Organizer" must provide the latest event description and the relevant
3770	instances. The first three examples show the history including the
3771	initial "VEVENT" request and subsequent instance changes and finally the
3772	"REFRESH".

3774	Original Request:

3776	BEGIN:VCALENDAR
3777	METHOD:REQUEST
3778	PRODID:-//RDU Software//NONSGML HandCal//EN
3779	VERSION:2.0
3780	BEGIN:VEVENT
3781	UID:123456789@host1.com
3782	SEQUENCE:0
3783	RDATE:19980304T180000Z
3784	RDATE:19980311T180000Z
3785	RDATE:19980318T180000Z
3786	RDATE:19980325T180000Z
3787	ORGANIZER:Mailto:A@example.com
3788	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3789	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3790	SUMMARY:Review Accounts
3791	DTSTART:19980304T180000Z
3792	DTEND:19980304T200000Z
3793	DTSTAMP:19980303T193000Z
3794	LOCATION:Conference Room A
3795	STATUS:CONFIRMED
3796	END:VEVENT
3797	END:VCALENDAR

3799	Organizer changes 2nd instance Location and Time:

3801	BEGIN:VCALENDAR
3802	METHOD:REQUEST
3803	PRODID:-//RDU Software//NONSGML HandCal//EN
3804	VERSION:2.0
3805	BEGIN:VEVENT
3806	UID:123456789@host1.com
3807	SEQUENCE:1
3808	RECURRENCE-ID:19980311T180000Z
3809	ORGANIZER:Mailto:A@example.com
3810	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3811	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3812	SUMMARY:Review Accounts
3813	DTSTART:19980311T160000Z
3814	DTEND:19980304T180000Z
3815	DTSTAMP:19980306T193000Z
3816	LOCATION:The Small conference room
3817	STATUS:CONFIRMED
3818	END:VEVENT
3819	END:VCALENDAR

3821	Organizer adds a 4th instance of the meeting using the "ADD" method

3823	BEGIN:VCALENDAR
3824	METHOD:ADD
3825	PRODID:-//RDU Software//NONSGML HandCal//EN
3826	VERSION:2.0
3827	BEGIN:VEVENT
3828	UID:123456789@host1.com
3829	SEQUENCE:2
3830	ORGANIZER:Mailto:A@example.com
3831	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3832	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3833	SUMMARY:Review Accounts
3834	DTSTART:19980315T180000Z
3835	DTEND:19980315T200000Z
3836	DTSTAMP:19980307T193000Z
3837	LOCATION:Conference Room A
3838	STATUS:CONFIRMED
3839	END:VEVENT
3840	END:VCALENDAR

3842	If "B" requests a "REFRESH", "A" responds with the following to capture
3843	all instance-specific data. In this case both the initial request and an
3844	additional "VEVENT" that specifies the instance-specific data are
3845	included. Because these are both of the same type (they are both
3846	"VEVENTS"), they can be conveyed in the same iCalendar object.

3848	BEGIN:VCALENDAR
3849	METHOD:REQUEST
3850	PRODID:-//RDU Software//NONSGML HandCal//EN
3851	VERSION:2.0
3852	BEGIN:VEVENT
3853	UID:123456789@host1.com
3854	SEQUENCE:3
3855	RDATE:19980304T180000Z
3856	RDATE:19980318T180000Z
3857	RDATE:19980315T180000Z
3858	Error! Bookmark not defined.
3859	ORGANIZER:Mailto:A@example.com
3860	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
3861	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3862	SUMMARY:Review Accounts
3863	DTSTART:19980304T180000Z
3864	DTEND:19980304T200000Z
3865	DTSTAMP:19980303T193000Z
3866	LOCATION:Conference Room A
3867	STATUS:CONFIRMED
3868	END:VEVENT

3870	BEGIN:VEVENT
3871	Error! Bookmark not defined.
3872	SEQUENCE:3
3873	RECURRENCE-ID:19980311T160000Z
3874	Error! Bookmark not defined.
3875	ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined.
3876	ATTENDEE;Error! Bookmark not defined.
3877	SUMMARY:Review Accounts
3878	DTSTART:19980311T160000Z
3879	DTEND:19980304T180000Z
3880	DTSTAMP:19980306T193000Z
3881	LOCATION:The Small conference room
3882	STATUS:CONFIRMED
3883	END:VEVENT

3885	END:VCALENDAR

3887	4.4.8     Counter An Instance Of A Recurring Event

3889	In this example one of the "Attendees" counters the "DTSTART" property
3890	of the proposed second July meeting.

3892	BEGIN:VCALENDAR
3893	METHOD:COUNTER
3894	PRODID:-//RDU Software//NONSGML HandCal//EN
3895	VERSION:2.0
3896	BEGIN:VEVENT
3897	CREATED:19970526T083000Z
3898	UID:guid-1@host1.com
3899	RECURRENCE-ID:19970715T210000Z
3900	SEQUENCE:4
3901	ORGANIZER:Mailto:A@example.com
3902	ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A@example.com
3903	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3904	ATTENDEE;RSVP=TRUE:Mailto:C@example.com
3905	ATTENDEE;RSVP=TRUE:Mailto:D@example.com
3906	DESCRIPTION:IETF-C&S Conference Call
3907	CLASS:PUBLIC
3908	SUMMARY:IETF Calendaring Working Group Meeting
3909	DTSTART:19970715T220000Z
3910	DTEND:19970715T230000Z
3911	LOCATION:Conference Call
3912	COMMENT:May we bump this by an hour? I have a conflict
3913	DTSTAMP:19970629T094000Z
3914	END:VEVENT
3915	END:VCALENDAR

3917	4.4.9     Error Reply To A Request

3919	The following example illustrates a scenario where a meeting is proposed
3920	containing an unsupported property and a bad property.

3922	Original Request

3924	BEGIN:VCALENDAR
3925	METHOD:REQUEST
3926	PRODID:-//RDU Software//NONSGML HandCal//EN
3927	VERSION:2.0
3928	BEGIN:VEVENT
3929	CREATED:19970526T083000Z
3930	UID:guid-1@host1.com
3931	SEQUENCE:0
3932	RRULE:FREQ=MONTHLY;BYMONTHDAY=1
3933	ORGANIZER:Mailto:A@example.com
3934	ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
3935	ATTENDEE;RSVP=TRUE:Mailto:B@example.com
3936	ATTENDEE;RSVP=TRUE:Mailto:C@example.com
3937	ATTENDEE;RSVP=TRUE:Mailto:D@example.com
3938	DESCRIPTION:IETF-C&S Conference Call
3939	CLASS:PUBLIC
3940	SUMMARY:IETF Calendaring Working Group Meeting
3941	DTSTART:19970601T210000Z
3942	DTEND:19970601T220000Z
3943	DTSTAMP:19970602T094000Z
3944	LOCATION:Conference Call
3945	STATUS:CONFIRMED
3946	FOO:BAR
3947	END:VEVENT
3948	END:VCALENDAR

3950	Response from "B" to indicate that RRULE is not supported and an
3951	unrecognized property was encountered

3953	BEGIN:VCALENDAR
3954	PRODID:-//RDU Software//NONSGML HandCal//EN
3955	METHOD:REPLY
3956	VERSION:2.0
3957	BEGIN:VEVENT
3958	ORGANIZER:Mailto:A@example.com
3959	ATTENDEE:Mailto:B@example.com
3960	REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single
3961	  event;RRULE
3962	REQUEST-STATUS:3.0;Invalid Property Name;FOO
3963	UID:guid-1@host1.com
3964	SEQUENCE:0
3965	DTSTAMP:19970603T094000Z
3966	END:VEVENT
3967	END:VCALENDAR

3969	4.5 Group To-do Examples

3971	Individual "A" creates a group task in which individuals "A", "B", "C"
3972	and "D" will participate. Individual "B" confirms acceptance of the
3973	task. Individual "C" declines the task. Individual "D" tentatively
3974	accepts the task. The following table illustrates the sequence of
3975	messages that would be exchanged between these individuals. Individual
3976	"A" then issues a "REQUEST" method to obtain the status of the to-do
3977	from each participant. The response indicates the individual
3978	"Attendee's" completion status. The table below illustrates the message
3979	flow.

3981	+--------------------------------------------------------------------+
3982	| Action             |  "Organizer"        | Attendee                |
3983	+--------------------------------------------------------------------+
3984	| Initiate a to-do   | "A" sends a REQUEST |                         |
3985	| request            | message to "B", "C",|                         |
3986	|                    | and "D"             |                         |
3987	+--------------------------------------------------------------------+
3988	| Accept the to-do   |                     | "B" sends a "REPLY"     |
3989	| request            |                     | message to "A" with its |
3990	|                    |                     | "attstat" paramater     |
3991	|                    |                     | set to "accepted".      |
3992	+--------------------------------------------------------------------+
3993	| Decline the to-do  |                     | "C" sends a REPLY       |
3994	| request            |                     | message to "A" with its |
3995	|                    |                     | "attstat" parameter     |
3996	|                    |                     | set to "declined".      |
3997	+--------------------------------------------------------------------+
3998	| Tentatively accept |                     | "D" sends a REPLY       |
3999	| the to-do request  |                     | message to "A" with its |
4000	|                    |                     | "attstat" parameter     |
4001	|                    |                     | set to "tentative".     |
4002	+--------------------------------------------------------------------+
4003	| Check attendee     | "A" sends a REQUEST |                         |
4004	| completion status  | message to "B" and  |                         |
4005	|                    | "C" with current    |                         |
4006	|                    | information.        |                         |
4007	+--------------------------------------------------------------------+
4008	| Attendee indicates |                     | "B" sends a "REPLY"     |
4009	| percent complete   |                     | message indicating      |
4010	|                    |                     | percent complete        |
4011	+--------------------------------------------------------------------+
4012	| Attendee indicates |                     | "C" sends a "REPLY"     |
4013	| completion         |                     | message indicating      |
4014	|                    |                     | completion              |
4015	+--------------------------------------------------------------------+

4017	4.5.1     A VTODO Request

4019	A sample "REQUEST" with for a "VTODO" calendar component that "A" sends
4020	to "B", "C", and "D".

4022	BEGIN:VCALENDAR
4023	PRODID:-//ACME/DesktopCalendar//EN
4024	METHOD:REQUEST
4025	VERSION:2.0
4026	BEGIN:VTODO
4027	ORGANIZER:Mailto:A@example.com
4028	ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
4029	ATTENDEE;RSVP=TRUE:B@example.com
4030	ATTENDEE;RSVP=TRUE:Mailto:C@example.com
4031	ATTENDEE;RSVP=TRUE:Mailto:D@example.com
4032	DTSTART:19970701T170000Z
4033	DUE:19970722T170000Z
4034	SUMMARY:Create the requirements document
4035	UID:www.acme.com-873970198738777-00@example.com
4036	SEQUENCE:0
4037	DTSTAMP:19970717T200000Z
4038	STATUS:Needs Action
4039	END:VTODO
4040	END:VCALENDAR

4042	4.5.2     A VTODO Reply

4044	Attendee "B" accepts the meeting.

4046	BEGIN:VCALENDAR
4047	PRODID:-//ACME/DesktopCalendar//EN
4048	METHOD:REPLY
4049	VERSION:2.0
4050	BEGIN:VTODO
4051	ORGANIZER:Mailto:A@example.com
4052	ATTENDEE;ATTSTAT=ACCEPTED:Mailto:B@example.com
4053	UID:www.acme.com-873970198738777-00@example.com
4054	COMMENT:I'll send you my input by e-mail
4055	SEQUENCE:0
4056	DTSTAMP:19970717T203000Z
4057	REQUEST-STATUS:2.0;Success
4058	END:VTODO
4059	END:VCALENDAR

4061	"B" could have declined the TODO or indicated tentative acceptance by
4062	setting the "attstat" property parameter sequence to "declined" or
4063	"tentative", respectively.

4065	4.5.3     A VTODO Request for Updated Status

4067	"A" requests status from all "Attendees".

4069	BEGIN:VCALENDAR
4070	PRODID:-//ACME/DesktopCalendar//EN
4071	METHOD:REQUEST
4072	VERSION:2.0
4073	BEGIN:VTODO
4074	ORGANIZER:Mailto:A@example.com
4075	ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
4076	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
4077	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
4078	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com
4079	UID:www.acme.com-873970198738777-00@example.com
4080	SEQUENCE:0
4081	STATUS:IN-PROCESS
4082	DTSTAMP:19970717T230000Z
4083	END:VTODO
4084	END:VCALENDAR

4086	4.5.4     A Reply: Percent-Complete

4088	A reply indicating the task being worked on and that "B" is 75% complete
4089	with "B's" part of the assignment.

4091	BEGIN:VCALENDAR
4092	PRODID:-//ACME/DesktopCalendar//EN
4093	METHOD:REPLY
4094	VERSION:2.0
4095	BEGIN:VTODO
4096	ORGANIZER:MAILTO:A@example.com
4097	ATTENDEE;ATTSTAT=IN-PROCESS:Mailto:B@example.com
4098	PERCENT-COMPLETE:75
4099	UID:www.acme.com-873970198738777-00@example.com
4100	DTSTAMP:19970717T233000Z
4101	SEQUENCE:0
4102	END:VTODO
4103	END:VCALENDAR

4105	4.5.5     A Reply: Completed

4107	A reply indicating that "C" completed "C's" part of the assignment.

4109	BEGIN:VCALENDAR
4110	PRODID:-//ACME/DesktopCalendar//EN
4111	METHOD:REPLY
4112	VERSION:2.0
4113	BEGIN:VTODO
4114	ORGANIZER:MAILTO:A@example.com
4115	ATTENDEE;ATTSTAT=COMPLETED:Mailto:C@example.com
4116	UID:www.acme.com-873970198738777-00@example.com
4117	DTSTAMP:19970717T233000Z
4118	SEQUENCE:0
4119	END:VTODO
4120	END:VCALENDAR

4122	4.5.6     An Updated VTODO Request

4124	Organizer "A" resends the "VTODO" calendar component. "A" sets the
4125	overall completion for the to-do at 40%.

4127	BEGIN:VCALENDAR
4128	PRODID:-//ACME/DesktopCalendar//EN
4129	METHOD:REQUEST
4130	VERSION:2.0
4131	BEGIN:VTODO
4132	ORGANIZER:Mailto:A@example.com
4133	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
4134	ATTENDEE;ATTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com
4135	ATTENDEE;ATTSTAT=COMPLETED;TYPE=INDIVIDUAL:Mailto:C@example.com
4136	ATTENDEE;ATTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com
4137	DTSTART:19970701T100000-0700
4138	DUE:19970722T100000-0700
4139	SUMMARY:Create the requirements document
4140	UID:www.acme.com-873970198738777-00@example.com
4141	SEQUENCE:1
4142	DTSTAMP:19970718T100000Z
4143	STATUS:IN-PROGRESS
4144	PERCENT-COMPLETE:40
4145	END:VTODO
4146	END:VCALENDAR

4148	4.5.7     Recurring VTODOs

4150	The following examples relate to recurring "VTODO" calendar components.

4152	4.5.7.1   Request for a Recurring VTODO

4154	In this example "A" sends a recurring "VTODO" calendar component to "B"
4155	and "C".

4157	BEGIN:VCALENDAR
4158	PRODID:-//ACME/DesktopCalendar//EN
4159	METHOD:REQUEST
4160	VERSION:2.0
4161	BEGIN:VTODO
4162	ORGANIZER:Mailto:A@example.com
4163	ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
4164	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
4165	ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
4166	RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
4167	DTSTART:19980101T100000-0700
4168	DUE:19980103T100000-0700
4169	SUMMARY:Send Status Reports to Area Managers
4170	UID:www.acme.com-873970198738777-00@example.com
4171	SEQUENCE:0
4172	DTSTAMP:19970717T200000Z
4173	STATUS:NEEDS ACTION
4174	END:VTODO
4175	END:VCALENDAR

4177	4.5.7.2   Calculating due dates in recurring VTODOs

4179	The due date in a recurring "VTODO" calendar component is either a fixed
4180	interval specified in the "REQUEST" method or specified using the
4181	"RECURRENCE-ID" property. The former is calculated by applying the
4182	difference between "DTSTART" and "DUE" properties and applying it to
4183	each of the start of each recurring instance. Hence, if the initial
4184	"VTODO" calendar component specifies a "DTSTART" property value of
4185	"19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the
4186	interval of one day which is applied to each recurring instance of the
4187	"VTODO" calendar component to determine the "DUE" date of the instance.

4189	4.5.7.3   Replying to an instance of a recurring VTODO

4191	In this example "B" updates "A" on a single instance of the "VTODO"
4192	calendar component.

4194	BEGIN:VCALENDAR
4195	PRODID:-//ACME/DesktopCalendar//EN
4196	METHOD:REPLY
4197	VERSION:2.0
4198	BEGIN:VTODO
4199	ATTENDEE;ATTSTAT=IN-PROCESS:Mailto:B@example.com
4200	PERCENT-COMPLETE:75
4201	UID:www.acme.com-873970198738777-00@example.com
4202	DTSTAMP:19970717T233000Z
4203	RECURRENCE-ID:19980101T170000Z
4204	SEQUENCE:1
4205	END:VTODO
4206	END:VCALENDAR

4208	4.6 Journal Examples

4210	The iCalendar object below describes a single journal entry for October
4211	2, 1997. The "RELATED-TO" property references the phone conference event
4212	for which minutes were taken.

4214	BEGIN:VCALENDAR
4215	PROFILE:PUBLISH
4216	PRODID:-//ACME/DesktopCalendar//EN
4217	VERSION:2.0
4218	BEGIN:VJOURNAL
4219	DTSTART:19971002T200000Z
4220	SUMMARY:Phone conference minutes
4221	DESCRIPTION:The editors meeting was held on October 1, 1997.
4222	  Details are in the attached document.
4223	UID:0981234-1234234-2410@example.com
4224	RELATED-TO:0981234-1234234-2402-35@example.com
4225	ATTACH:ftp\://ftp.example.com/pub/ed/minutes100197.txt
4226	END:VJOURNAL
4227	END:VCALENDAR
4228	4.7 Other Examples

4230	4.7.1     Event Refresh

4232	Refresh the event with "UID" property value of "guid-1-12345@host1.com":

4234	BEGIN:VCALENDAR
4235	PRODID:-//RDU Software//NONSGML HandCal//EN
4236	METHOD:REFRESH
4237	VERSION:2.0
4238	BEGIN:VEVENT
4239	ORGANIZER:Mailto:A@example.com
4240	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
4241	ATTENDEE:Mailto:B@example.com
4242	ATTENDEE:Mailto:C@example.com
4243	ATTENDEE:Mailto:D@example.com
4244	UID: guid-1-12345@host1.com
4245	DTSTAMP:19970603T094000
4246	END:VEVENT
4247	END:VCALENDAR

4249	4.7.2     Bad RECURRENCE-ID

4251	If an "Attendee" receives a request that references a "RECURRENCE-ID"
4252	property that cannot be found, the "Attendee" SHOULD send a "REFRESH"
4253	method back to the "Organizer" for the latest copy of the event.

4255	+--------------------------------------------------------------------+
4256	| Action             |  "Organizer"        | Attendee                |
4257	+--------------------------------------------------------------------+
4258	| Update an instance | "A" sends  "REQUEST"|                         |
4259	| request            | message to "B"      |                         |
4260	+--------------------------------------------------------------------+
4261	| Attendee requests  |                     | "B" sends a "REFRESH"   |
4262	| refresh because    |                     | message to "A"          |
4263	| "RECURRENCE-ID" was|                     |                         |
4264	| not found          |                     |                         |
4265	+--------------------------------------------------------------------+
4266	| Refresh the entire | "A" sends the       |                         |
4267	| Event              | latest copy of the  |                         |
4268	|                    | Event to "B"        |                         |
4269	+--------------------------------------------------------------------+
4270	| Attendee handles   |                     | "B" updates to the      |
4271	| the request and    |                     | latest copy of the      |
4272	| updates the        |                     | meeting.                |
4273	| instance           |                     |                         |
4274	+--------------------------------------------------------------------+

4276	Request from "A":

4278	BEGIN:VCALENDAR
4279	METHOD:REQUEST
4280	PRODID:-//RDU Software//NONSGML HandCal//EN
4281	VERSION:2.0
4282	BEGIN:VEVENT
4283	UID:acme-12345@host1.com
4284	SEQUENCE:3
4285	RRULE:FREQ=WEEKLY
4286	RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z
4287	ORGANIZER:Mailto:A@example.com
4288	ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:Mailto:A@example.com
4289	ATTENDEE:Mailto:B@example.com
4290	DESCRIPTION:IETF-C&S Conference Call
4291	SUMMARY:IETF Calendaring Working Group Meeting
4292	DTSTART:19970801T210000Z
4293	DTEND:19970801T220000Z
4294	DTSTAMP:19970726T083000
4295	STATUS:CONFIRMED
4296	END:VEVENT
4297	END:VCALENDAR

4299	"B" has the event with "UID" property "acme-12345@host1.com" but the
4300	"SEQUENCE" property value is "1" and the event does not have an instance
4301	at the specified recurrence time. This means that "B" has missed one
4302	update and needs a new copy of the event.

4304	BEGIN:VCALENDAR
4305	PRODID:-//RDU Software//NONSGML HandCal//EN
4306	METHOD:REFRESH
4307	VERSION:2.0
4308	BEGIN:VEVENT
4309	ORGANIZER:Mailto:A@example.com
4310	ATTENDEE;ATTSTAT=ACCEPTED:Mailto:B@example.com
4311	UID:acme-12345@host1.com
4312	DTSTAMP:19970603T094000
4313	END:VEVENT
4314	END:VCALENDAR

4316	5  Application Protocol Fallbacks

4318	5.1 Partial Implementation

4320	Applications that support this memo are not required to support the
4321	entire protocol. The following describes how methods and properties
4322	SHOULD "fallback" in applications that do not support the complete
4323	protocol. If a method or property is not addressed in this section, it
4324	may be ignored.

4326	5.1.1     Event-Related Fallbacks

4328	Method           Fallback
4329	--------------   -----------------------------------------------------
4330	PUBLISH          Required.
4331	CANCEL           Required.
4332	REQUEST          PUBLISH
4333	REPLY            Required.
4334	ADD              Required.
4335	DELEGATE         Reply with Not Supported.
4336	REQUEST          Reply with Not Supported.
4337	REPLY            Reply with Not Supported.
4338	COUNTER          Reply with Not Supported
4339	DECLINECOUNTER   Required if EVENT-COUNTER is implemented; otherwise
4340	                 reply with Not Supported.

4342	iCalendar
4343	Property         Fallback
4344	--------------   -----------------------------------------------------
4345	CALSCALE         Ignore; assume GREGORIAN.
4346	GEO              Ignore.
4347	PRODID           Ignore.
4348	METHOD           Required as described in the Method list above.
4349	SOURCE           Ignore
4350	NAME             Ignore.
4351	VERSION          Ignore.

4353	Event-Related
4354	Components       Fallback
4355	--------------   -----------------------------------------------------
4356	VFREEBUSY        Reply with Not Supported.
4357	VALARM           Reply with Not Supported.
4358	VTIMEZONE        Required if RRULE or RDATE is implemented; otherwise
4359	                 ignore and use local time.

4361	Component
4362	Property         Fallback
4363	--------------   -----------------------------------------------------
4364	ATTACH           Ignore.
4365	ATTENDEE         Required if EVENT-REQUEST is not implemented;
4366	                 otherwise reply with Not Supported.
4367	CATEGORIES       Ignore.
4368	CLASS            Ignore.
4369	COMMENT          Ignore.
4370	COMPLETED        Ignore.
4371	CREATED          Ignore.
4372	DAYLIGHT         Required if VTIMEZONE is implemented; otherwise
4373	                 Ignore.
4374	DESCRIPTION      Required.
4375	DELEGATED-FROM   Required if EVENT-DELEGATE is implemented; otherwise
4376	                 Ignore.
4377	DELEGATED-TO     Required if EVENT-DELEGATE is implemented; otherwise
4378	                 Ignore.

4380	DUE              Ignore.
4381	DURATION         Reply with Not Supported.
4382	DTSTAMP          Required.
4383	DTSTART          Required.
4384	DTEND            Required.
4385	EXDATE           Ignore.
4386	EXRULE           Ignore.
4387	FREEBUSY         Reply with Not Supported.
4388	LAST-MODIFIED    Ignore.
4389	LOCATION         Required.
4390	PRIORITY         Ignore.
4391	RELATED-TO       Ignore.
4392	RDATE            Ignore. If implemented, VTIMEZONE MUST also be
4393	                 implemented.
4394	RRULE            Ignore. The first instance occurs on the DTStart
4395	                 property.
4396	RECURRENCE-ID    Required if RRULE is implemented; otherwise Ignore.
4397	REQUEST-STATUS   Required.
4398	RESOURCES        Ignore.
4399	SEQUENCE         Required.
4400	STATUS           Ignore.
4401	SUMMARY          Ignore.
4402	TRANSP           Required if FREEBUSY is implemented; otherwise Ignore.
4403	TZNAME           Required if VTIMEZONE is implemented; otherwise
4404	                 Ignore.
4405	TZOFFSET         Required if VTIMEZONE is implemented; otherwise
4406	                 Ignore.
4407	URL              Ignore.
4408	UID              Required.
4409	X-               Ignore.

4411	5.1.2     To-Do-Related Fallbacks

4413	Method           Fallback
4414	--------------   -----------------------------------------------------
4415	PUBLISH          Required.
4416	CANCEL           Required.
4417	ADD              Required.
4418	REQUEST          TODO-PUBLISH.
4419	REPLY            Required.

4421	iCalendar
4422	Property         Fallback
4423	--------------   -----------------------------------------------------
4424	CALSCALE         Ignore; assume GREGORIAN.
4425	GEO              Ignore.
4426	PRODID           Ignore.
4427	METHOD           Required as described in the Method list above.
4428	SOURCE           Ignore
4429	NAME             Ignore.
4430	VERSION          Ignore.

4432	To-Do-Related
4433	Components       Fallback
4434	--------------   -----------------------------------------------------
4435	VALARM           Reply with Not Supported.
4436	VTIMEZONE        Required if RRULE or RDATE is implemented;
4437	                 otherwise ignore and use local time.

4439	Component
4440	Property         Fallback
4441	--------------   -----------------------------------------------------
4442	CALSCALE         Ignore; assume GREGORIAN.
4443	GEO              Ignore.
4444	PRODID           Ignore.
4445	PROFILE          Required as described in the Method list above.
4446	SOURCE           Ignore.
4447	NAME             Ignore.
4448	VERSION          Assume "2.0".
4449	Property         Fallback
4450	ATTACH           Ignore.
4451	ATTENDEE         Required if REQUEST is not implemented; otherwise
4452	                 ignore.
4453	CATEGORIES       Ignore.
4454	CLASS            Ignore.
4455	COMMENT          Ignore.
4456	COMPLETED        Required.
4457	CREATED          Ignore.
4458	DAYLIGHT         Required if VTIMEZONE is implemented; otherwise
4459	                 ignore.
4460	DESCRIPTION      Required.
4461	DUE              Required.
4462	DURATION         Ignore. Reply with Not Supported.
4463	DTSTAMP          Required.
4464	DTSTART          Required.
4465	EXDATE           Ignore. Reply with Not Supported.
4466	EXRULE           Ignore. Reply with Not Supported.
4467	LAST-MODIFIED    Ignore.
4468	LOCATION         Ignore.
4469	PERCENT-COMPLETE Ignore.
4470	PRIORITY         Required.
4471	RELATED-TO       Ignore.
4472	RDATE            Ignore. If implemented, VTIMEZONE MUST also be
4473	                 implemented.
4474	RRULE            Ignore. The first instance occurs on the DTSTART
4475	                 property.
4476	RESOURCES        Ignore.
4477	SEQUENCE         Required.
4478	STATUS           Required.
4479	SUMMARY          Ignore.
4480	TRANSP           Required if FREEBUSY is implemented; otherwise ignore.
4481	TZNAME           Required if VTIMEZONE is implemented; otherwise
4482	                 ignore.
4483	TZOFFSET         Required if VTIMEZONE is implemented; otherwise
4484	                 ignore.
4485	URL              Ignore.

4487	UID              Required.
4488	X-               Ignore.

4490	5.1.3     Journal-Related Fallbacks

4492	Method           Fallback
4493	--------------   -----------------------------------------------------
4494	PUBLISH          Implementations MAY ignore the profile type. The
4495	                 REQUEST-STATUS "302;Request Not supported" MUST be
4496	                 returned.
4497	CANCEL           Implementations MAY ignore the profile type. The
4498	                 REQUEST-STATUS "302;Request Not supported" MUST be
4499	                 returned.
4500	ADD              Implementations MAY ignore the profile type. The
4501	                 REQUEST-STATUS "302;Request Not supported" MUST be
4502	                 returned.

4504	iCalendar
4505	Property         Fallback
4506	--------------   -----------------------------------------------------
4507	CALSCALE         Ignore; assume GREGORIAN.
4508	GEO              Ignore.
4509	PRODID           Ignore.
4510	METHOD           Required as described in the Method list above.
4511	SOURCE           Ignore
4512	NAME             Ignore.
4513	VERSION          Ignore.

4515	Journal-Related
4516	Components       Fallback
4517	--------------   -----------------------------------------------------
4518	VTIMEZONE        Required if RRULE or RDATE is implemented; otherwise
4519	                 ignore and use local time.
4520	CALSCALE         Ignore; assume GREGORIAN.
4521	GEO              Ignore.
4522	PRODID           Ignore.
4523	METHOD           Required as described in the Method section above.
4524	SOURCE           Ignore
4525	NAME             Ignore.
4526	VERSION          Assume "2.0".

4528	Component
4529	Property         Fallback
4530	--------------   -----------------------------------------------------
4531	ATTACH           Ignore.
4532	ATTENDEE         Required if JOURNAL-REQUEST is implemented; otherwise
4533	                 ignore.
4534	CATEGORIES       Ignore.
4535	CLASS            Ignore.
4536	COMMENT          Ignore.
4537	CREATED          Ignore.
4538	DAYLIGHT         Required if VTIMEZONE is implemented; otherwise
4539	                 ignore.
4540	DESCRIPTION      Required.
4541	DTSTAMP          Required.
4542	DTSTART          Required.
4543	DTEND            Required.
4544	EXDATE           Ignore.
4545	EXRULE           Ignore.
4546	LAST-MODIFIED    Ignore.
4547	RELATED-TO       Ignore.
4548	RDATE            Ignore. If implemented, VTIMEZONE MUST also be
4549	                 implemented.
4550	RRULE            Ignore. The first instance occurs on the DTSTART
4551	                 property.
4552	SEQUENCE         Required.
4553	STATUS           Ignore.
4554	TRANSP           Required if FREEBUSY is implemented; otherwise ignore.
4555	TZNAME           Required if VTIMEZONE is implemented; otherwise
4556	                 ignore.
4557	TZOFFSET         Required if VTIMEZONE is implemented; otherwise
4558	                 ignore.
4559	URL              Ignore.
4560	UID              Required.
4561	X-               Ignore.

4563	5.2 Latency Issues

4565	With a store-and-forward transport, it is possible for events to arrive
4566	out of sequence. That is, a "CANCEL" method may be received prior to
4567	receiving the associated "REQUEST" for the calendar component. This
4568	section discusses a few of these scenarios.

4570	5.2.1     Cancellation of an Unknown Calendar Component.

4572	When a "CANCEL" method is received before the original "REQUEST" method
4573	the calendar will be unable to correlate the "UID" property of the
4574	cancellation with an existing calendar component. It is suggested that
4575	messages that can not be correlated that also contain non-zero sequence
4576	numbers be held and not discarded. Implementations MAY age them out if
4577	no other messages arrive with the same "UID" property value and a lower
4578	sequence number.

4580	5.2.2     Unexpected Reply from an Unknown Delegate

4582	When an "Attendee" delegates an item to another CU they MUST send a
4583	"REPLY" method to the "Organizer" using the "ATTENDEE" properties to
4584	indicate that the request was delegated and to whom. Hence, it is
4585	possible for an "Organizer" to receive an "REPLY" from a CU not listed
4586	as one of the original "Attendees". The resolution is left to the
4587	implementation but it is expected that the calendaring software will
4588	either accept the reply or hold it until the related "REPLY" method is
4589	received from the "Delegator". If the version of the "REPLY" method is
4590	out of date the "Organizer" SHOULD treat the message as a "STATUS-
4591	REQUEST" and update the delegate with the correct version.

4593	5.3 Sequence Number

4595	Under some conditions, a CUA may receive requests and replies with the
4596	same "SEQUENCE" property value. The "DTSTAMP" property is utilized as a
4597	tie-breaker when two items with the same "SEQUENCE" property value are
4598	evaluated. Furthermore, the "SEQUENCE" property SHOULD only incremented
4599	when one or more of the following properties changes:

4601	DTSTART
4602	DTEND
4603	RDATE
4604	RRULE
4605	EXDATE
4606	EXRULE
4607	DUE (for VTODO components)
4608	and possibly LOCATION  (at the user's discretion)

4610	6  Security Considerations

4612	ITIP is an abstract transport protocol which will be bound to a real-
4613	time transport, a store-and-forward transport, and perhaps other
4614	transports. The transport protocol will be responsible for providing
4615	facilities for authentication and encryption using standard Internet
4616	mechanisms that are mutually understood between the sender and receiver.

4618	6.1 Security Threats

4620	6.1.1     Spoofing the "Organizer"

4622	In iTIP, the "Organizer" (or someone working on the "Organizer's"
4623	behalf) is the only person authorized to make changes to an existing
4624	"VEVENT", "VTODO", "VJOURNAL" calendar component and republish it or
4625	redistribute updates to the "Attendees". An iCalendar object that
4626	maliciously changes or cancels an existing "VEVENT", "VTODO" or
4627	"VJOURNAL" calendar component may be constructed by someone other than
4628	the "Organizer" and republished or sent to the "Attendees".

4630	6.1.2     Spoofing the "Attendee"

4632	In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component (or
4633	someone working on the "Attendee's" behalf) is the only person
4634	authorized to update any parameter associated with their "ATTENDEE"
4635	property and send it to the "Organizer". An iCalendar object that
4636	maliciously changes the "ATTENDEE" parameters may be constructed by
4637	someone other than the real "Attendee" and sent to the "Organizer".

4639	6.1.3     Unauthorized Replacement of the Organizer

4641	There will be circumstances when "Attendees" of an event or to-do
4642	decide, using out-of-band mechanisms, that the "Organizer" must be
4643	replaced. When the new "Organizer" sends out the updated "VEVENT" or
4644	"VTODO" the "Attendee's" CUA will detect that the "Organizer" has been
4645	changed, but it has no way of knowing whether or not the change was
4646	mutually upon.

4648	6.1.4     Eavesdropping

4650	The iCalendar object is constructed with human-readable clear text. Any
4651	information contained in an iCalendar object may be read and/or changed
4652	by unauthorized persons while the object is in transit.

4654	6.1.5     Flooding a Calendar

4656	Implementations MAY provide a means to automatically incorporate
4657	"REQUEST" methods into a calendar. This presents the opportunity for a
4658	calendar to be flooded with requests, which effectively block all the
4659	calendar's free time.

4661	6.1.6     Procedural Alarms

4663	The "REQUEST" methods for "VEVENT" and "VTODO" calendar components MAY
4664	contain "VALARM" calendar components. The "VALARM" calendar component
4665	may be of type PROCEDURE and MAY have an attachment containing an
4666	executable program. Implementations that incorporate these types of
4667	alarms are subject to any virus or malicious attack that may occur as a
4668	result of executing the attachment.

4670	6.1.7     Unauthorized REFRESH Requests

4672	It is possible for an "Organizer" to receive a "REFRESH" request from
4673	someone who is not an "Attendee" of an event or to-do. Only "Attendee's"
4674	of an event or to-do are authorized to receive replies to "REFRESH"
4675	requests. Replying to such requests to anyone who is not an "Attendee"
4676	may be a security problem.

4678	6.2 Recommendations

4680	For an application where the information is sensitive or critical and
4681	the network is subject is subject to a high probability of attack, iTIP
4682	transactions SHOULD be secured. This may be accomplished using public
4683	key technology, specifically Security Multiparts for MIME [RFC1847] in
4684	the iTIP transport binding. This helps mitigate the threats of spoofing,
4685	eavesdropping and malicious changes in transit.

4687	6.2.1     Use of [RFC1847] to secure iTIP transactions

4689	iTIP transport bindings SHOULD provide a mechanism based on Security
4690	Multiparts for MIME [RFC1847] to enable authentication of the sender's
4691	identity, and privacy and integrity of the data being transmitted. This
4692	allows the receiver of a signed iCalendar object to verify the identity
4693	of the sender. This sender may then be correlated to an "ATTENDEE"
4694	property in the iCalendar object. If the correlation is made and the
4695	sender is authorized to make the requested change or update then the
4696	operation may proceed. It also allows the message to be encrypted to
4697	prevent unauthorized reading of the message contents in transit. iTIP
4698	transport binding documents describe this process in detail.

4700	6.2.2     Implementation Controls

4702	The threat of unauthorized replacement of the "Organizer" SHOULD be
4703	mitigated by a calendar system that uses this protocol by providing
4704	controls or alerts that make "Calendar Users" aware of such "Organizer"
4705	changes and allowing them to decide whether or not the request should be
4706	honored.

4708	The threat of flooding a calendar SHOULD be mitigated by a calendar
4709	system that uses this protocol by providing controls that may be used to
4710	limit the acceptable sources for iTIP transactions, and perhaps the size
4711	of messages and volume of traffic, by source.

4713	The threat of malicious procedural alarms SHOULD be mitigated by a
4714	calendar system that uses this protocol by providing controls that may
4715	be used to disallow procedural alarms in iTIP transactions and/or remove
4716	all alarms from the object before delivery to the recipient.

4718	The threat of unauthorized "REFRESH" requests SHOULD be mitigated by a
4719	calendar system that uses this protocol by providing controls or alerts
4720	that allow "Calendar User" to decide whether or not the request should
4721	be honored.  An implementation MAY decide to maintain, for audit or
4722	historical purposes,  "Calendar Users" who were part of an attendee list
4723	and who were subsequently uninvited.  Similar controls or alerts should
4724	be provided when a "REFRESH" request is received from these "Calendar
4725	Users" as well.

4727	7  Acknowledgments

4729	A hearty thanks to the following individuals who have participated in
4730	the drafting, review and discussion of this memo:

4732	Anik Ganguly, Bruce Kahn, John Noerenberg, Leo Parker, John Rose, Vinod
4733	Seraphin, Richard Shusterman, Derik Stenerson, John Sun, Kevin
4734	Tsurutome.

4736	8  Bibliography

4738	[ICAL] "Internet Calendaring and Scheduling Core Object Specification -
4739	iCalendar", Internet-Draft, October 1997, ftp://ftp.ietf.org/internet-
4740	drafts/draft-ietf-calsch-ical-03.txt.

4742	[ICMS] "Internet Calendaring Model Specification", Internet-Draft,
4743	October 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-
4744	01.txt.

4746	[ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646",
4747	Internet-Draft, July 1996, ftp://ftp.ietf.org/internet-drafts/draft-
4748	yergeau-utf8-01.txt.

4750	[IMIP] "iCalendar Message-Based Interoperability Protocol - iMIP",
4751	Internet-Draft, October 1997, ftp://ftp.ietf.org/internet-drafts/draft-
4752	ietf-calsch-imip-01.txt.

4754	[ISO8601] "Data elements and interchange formats - information
4755	interchange - Representation of dates and times", ISO 8601, 1996-06-15,
4756	+1 (212) 642-4900 for ANSI Sales.

4758	[VCAL] "vCalendar - The Electronic Calendaring and Scheduling Format -
4759	Version 1.0", Versit Consortium, September 18, 1996,
4760	http://www.imc.org/pdi/vcal-10.doc.

4762	[VCARD] "vCard - The Electronic Business Card Exchange Format - Version
4763	2.1", Versit Consortium, September 18, 1996,
4764	http://www.imc.org/pdi/vcard-21.doc.

4766	[RFC821] Postel, "Simple Mail Transfer Protocol", RFC 821, organization
4767	name, November 1996, http://ds.internic.net/rfc/rfc821.txt.

4769	[RFC1983] "Internet Users' Glossary", RFC 1983, August 1996,
4770	http://ds.internic.net/rfc/rfc1983.txt.

4772	[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
4773	RFC 2119, March 1997, http://ds.internic.net/rfc/rfc2119.txt.

4775	[RFC2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail
4776	Extensions - Part One - Format of Internet Message Bodies", RFC 2045,
4777	Innosoft, First Virtual, November 1996,
4778	http://ds.internic.net/rfc/rfc2045.txt.

4780	[RFC2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail
4781	Extensions - Part Two - Media Types", RFC 2046, Innosoft, First Virtual,
4782	November 1996, http://ds.internic.net/rfc/rfc2046.txt.

4784	[UNICODE] The Unicode Consortium, "The Unicode Standard -Version 2.0",
4785	Addison-Wesley Developers Press, July 1996. UTF-8 is described in
4786	section A-2.

4788	[US-ASCII] Coded Character Set--7-bit American Standard Code for
4789	Information Interchange, ANSI X3.4-1986.

4791	9  Authors Addresses

4793	The following address information is provided in a MIME-VCARD,
4794	Electronic Business Card, format.

4796	The authors of this draft are:

4798	BEGIN:VCARD
4799	VERSION:2.1
4800	FN:Frank Dawson
4801	ORG:Lotus Development Corporation
4802	ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-
4803	  3502;USA
4804	TEL;WORK;MSG:+1-919-676-9515
4805	TEL;WORK;FAX:+1-919-676-9564
4806	EMAIL;INTERNET:Frank_Dawson@Lotus.com
4807	URL:http://home.earthlink.net/~fdawson
4808	END:VCARD

4810	BEGIN:VCARD
4811	VERSION:2.1
4812	FN:Ross Hopson
4813	ORG:On Technology, Inc.
4814	ADR;WORK;POSTAL;PARCEL:Suite 1600;;434 Fayetteville St.
4815	  Mall, Two Hannover Square;Raleigh;NC;27601
4816	TEL;WORK;MSG:+1-919-890-4036
4817	TEL;WORK;FAX:+1-919-890-4100
4818	EMAIL;INTERNET:rhopson@on.com
4819	END:VCARD

4821	BEGIN:VCARD
4822	VERSION:2.1
4823	FN:Steve Mansour
4824	ORG:Netscape Communications Corporation
4825	ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain
4826	  View;CA;94043;USA
4827	TEL;WORK;MSG:+1-650-937-2378
4828	TEL;WORK;FAX:+1-650-937-2103
4829	EMAIL;INTERNET:sman@netscape.com
4830	END:VCARD

4832	BEGIN:VCARD
4833	VERSION:2.1
4834	FN:Steve Silverberg
4835	ORG:Microsoft Corporation
4836	ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way;
4837	Redmond;WA;98052-6399;USA
4838	TEL;WORK;MSG:+1-425-936-9277
4839	TEL;WORK;FAX:+1-425-936-8019
4840	EMAIL;INTERNET:stevesil@Microsoft.com
4841	END:VCARD
4842	The iCalendar object is a result of the work of the Internet Engineering
4843	Task Force Calendaring and scheduling Working Group. The chairman of
4844	that working group is:

4846	BEGIN:VCARD
4847	FN:Anik Ganguly
4848	ORG:Campbel Services, Inc.
4849	ADR;WORK;POSTAL;PARCEL:10 Floor;;21700 Northwestern
4850	  Highway;Southfield;MI;48075;USA
4851	TEL;WORK;MSG:+1-248-559-5955
4852	TEL;WORK;FAX:+1-248-559-5034
4853	EMAIL;INTERNET:anik@ontime.com
4854	END:VCARD

4856	10 Full Copyright Statement

4858	"Copyright (C) The Internet Society (date). All Rights Reserved.

4860	This document and translations of it may be copied and furnished to
4861	others, and derivative works that comment on or otherwise explain it or
4862	assist in its implmentation may be prepared, copied, published and
4863	distributed, in whole or in part, without restriction of any kind,
4864	provided that the above copyright notice and this paragraph are included
4865	on all such copies and derivative works. However, this document itself
4866	may not be modified in any way, such as by removing the copyright notice
4867	or references to the Internet Society or other Internet organizations,
4868	except as needed for the purpose of developing Internet standards in
4869	which case the procedures for copyrights defined in the Internet
4870	Standards process must be followed, or as required to translate it into
4871	languages other than English.

4873	The limited permissions granted above are perpetual and will may be
4874	revoked by the Internet Society or its successors or assigns.

4876	This document and the information contained herein is provided on an "AS
4877	IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
4878	FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
4879	LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
4880	INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
4881	FITNESS FOR A PARTICULAR PURPOSE.