draft-ietf-calsify-2446bis-00.txt   draft-ietf-calsify-2446bis-01.txt 
Network Working Group C. Daboo Network Working Group C. Daboo
Internet-Draft Editor Internet-Draft Editor
Expires: April 19, 2006 October 16, 2005 Expires: September 7, 2006 March 6, 2006
iCalendar Transport-Independent Interoperability Protocol (iTIP) iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-00 draft-ietf-calsify-2446bis-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies a protocol using the iCalendar object This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between specification to provide scheduling interoperability between
different calendar systems. This is done in a general way so as to different calendar systems. This is done in a general way so as to
allow multiple methods of communication between systems. Subsequent allow multiple methods of communication between systems. Subsequent
documents will define profiles of this protocol using specific documents will define profiles of this protocol using specific
interoperable methods of communications between systems. interoperable methods of communications between systems.
iTIP complements the iCalendar object specification by adding iTIP complements the iCalendar object specification by adding
semantics for group scheduling methods commonly available in current semantics for group scheduling methods commonly available in current
calendar systems. These scheduling methods permit two or more calendar systems. These scheduling methods permit two or more
calendar systems to perform transactions such as publish, schedule, calendar systems to perform transactions such as publish, schedule,
reschedule, respond to scheduling requests, negotiation of changes or reschedule, respond to scheduling requests, negotiation of changes or
cancel. cancel.
Change History (to be removed prior to publication as an RFC) Change History (to be removed prior to publication as an RFC)
Initial document Changes in -01:
Updated to 2445bis and 2447bis references.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5
1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 5 1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 5
1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 6 1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 6
1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Interoperability Models . . . . . . . . . . . . . . . . . . . 8 2. Interoperability Models . . . . . . . . . . . . . . . . . . . 8
2.1. Application Protocol . . . . . . . . . . . . . . . . . . 9 2.1. Application Protocol . . . . . . . . . . . . . . . . . . 9
skipping to change at page 5, line 8 skipping to change at page 5, line 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.1. Normative References . . . . . . . . . . . . . . . . . . 120 7.1. Normative References . . . . . . . . . . . . . . . . . . 120
7.2. Informative References . . . . . . . . . . . . . . . . . 120 7.2. Informative References . . . . . . . . . . . . . . . . . 120
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 120 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 120
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 121
Intellectual Property and Copyright Statements . . . . . . . . . 122 Intellectual Property and Copyright Statements . . . . . . . . . 122
1. Introduction and Overview 1. Introduction and Overview
This document specifies how calendaring systems use iCalendar This document specifies how calendaring systems use iCalendar
[RFC2445] objects to interoperate with other calendar systems. In [I-D.ietf-calsify-rfc2445bis] objects to interoperate with other
particular, it specifies how to schedule events, to-dos, or daily calendar systems. In particular, it specifies how to schedule
journal entries. It further specifies how to search for available events, to-dos, or daily journal entries. It further specifies how
busy time information. It does so in a general way without to search for available busy time information. It does so in a
specifying how communication between different systems actually takes general way without specifying how communication between different
place. Subsequent documents specify transport bindings between systems actually takes place. Subsequent documents specify transport
systems that use this protocol. bindings between systems that use this protocol.
This protocol is based on messages sent from an originator to one or This protocol is based on messages sent from an originator to one or
more recipients. For certain types of messages, a recipient may more recipients. For certain types of messages, a recipient may
reply, in order to update their status and may also return reply, in order to update their status and may also return
transaction/request status information. The protocol supports the transaction/request status information. The protocol supports the
ability for the message originator to modify or cancel the original ability for the message originator to modify or cancel the original
message. The protocol also supports the ability for recipients to message. The protocol also supports the ability for recipients to
suggest changes to the originator of a message. The elements of the suggest changes to the originator of a message. The elements of the
protocol also define the user roles for its transactions. protocol also define the user roles for its transactions.
skipping to change at page 5, line 36 skipping to change at page 5, line 36
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
Calendaring and scheduling roles are referred to in quoted-strings of Calendaring and scheduling roles are referred to in quoted-strings of
text with the first character of each word in upper case. For text with the first character of each word in upper case. For
example, "Organizer" refers to a role of a "Calendar User" (CU) example, "Organizer" refers to a role of a "Calendar User" (CU)
within the scheduling protocol. within the scheduling protocol.
Calendar components defined by [RFC2445] are referred to with Calendar components defined by [I-D.ietf-calsify-rfc2445bis] are
capitalized, quoted-strings of text. All calendar components start referred to with capitalized, quoted-strings of text. All calendar
with the letter "V". For example, "VEVENT" refers to the event components start with the letter "V". For example, "VEVENT" refers
calendar component, "VTODO" refers to the to-do calendar component to the event calendar component, "VTODO" refers to the to-do calendar
and "VJOURNAL" refers to the daily journal calendar component. component and "VJOURNAL" refers to the daily journal calendar
component.
Scheduling methods are referred to with capitalized, quoted-strings Scheduling methods are referred to with capitalized, quoted-strings
of text. For example, "REQUEST" refers to the method for requesting of text. For example, "REQUEST" refers to the method for requesting
a scheduling calendar component be created or modified, "REPLY" a scheduling calendar component be created or modified, "REPLY"
refers to the method a recipient of a request uses to update their refers to the method a recipient of a request uses to update their
status with the "Organizer" of the calendar component. status with the "Organizer" of the calendar component.
Properties defined by [iCAL] are referred to with capitalized, Properties defined by [iCAL] are referred to with capitalized,
quoted-strings of text, followed by the word "property". For quoted-strings of text, followed by the word "property". For
example, "ATTENDEE" property refers to the iCalendar property used to example, "ATTENDEE" property refers to the iCalendar property used to
skipping to change at page 6, line 21 skipping to change at page 6, line 21
capitalized text, either alone or followed by the word "value". capitalized text, either alone or followed by the word "value".
In tables, the quoted-string text is specified without quotes in In tables, the quoted-string text is specified without quotes in
order to minimize the table length. order to minimize the table length.
1.2. Related Documents 1.2. Related Documents
Implementers will need to be familiar with several other Implementers will need to be familiar with several other
specifications that, along with this one, describe the Internet specifications that, along with this one, describe the Internet
calendaring and scheduling standards. The related documents are: calendaring and scheduling standards. The related documents are:
[RFC2445] - specifies the objects, data types, properties and [I-D.ietf-calsify-rfc2445bis] - specifies the objects, data types,
property parameters used in the protocols, along with the methods properties and property parameters used in the protocols, along
for representing and encoding them. with the methods for representing and encoding them.
[RFC2447] specifies an Internet email binding for iTIP. [I-D.ietf-calsify-rfc2447bis] specifies an Internet email binding
for iTIP.
This memo does not attempt to repeat the specification of concepts or This memo does not attempt to repeat the specification of concepts or
definitions from these other memos. Where possible, references are definitions from these other memos. Where possible, references are
made to the memo that provides for the specification of these made to the memo that provides for the specification of these
concepts or definitions. concepts or definitions.
1.3. Roles 1.3. Roles
Exchanges of iCalendar objects for the purposes of group calendaring Exchanges of iCalendar objects for the purposes of group calendaring
and scheduling occur between "Calendar Users" (CUs). CUs take on one and scheduling occur between "Calendar Users" (CUs). CUs take on one
of two roles in iTIP: of two roles in iTIP:
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Role | Description | | Role | Description |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Organizer | The CU who initiates an exchange takes on the role of | | Organizer | The CU who initiates an exchange takes on the role of |
| | "Organizer". For example, the CU who proposes a group | | | "Organizer". For example, the CU who proposes a |
| | meeting is the "Organizer". | | | group meeting is the "Organizer". |
| | | | | |
| Attendee | The CUs asked to participate in the group meeting by | | Attendee | The CUs asked to participate in the group meeting by |
| | the "Organizer" take on the role of "Attendee". | | | the "Organizer" take on the role of "Attendee". |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Note that "role" is also a descriptive parameter to the iCalendar Note that "role" is also a descriptive parameter to the iCalendar
"ATTENDEE" property. Its use is to convey descriptive context to an "ATTENDEE" property. Its use is to convey descriptive context to an
"Attendee" such as "chair", "req-participant" or "non-participant" "Attendee" such as "chair", "req-participant" or "non-participant"
and has nothing to do with the calendaring workflow. and has nothing to do with the calendaring workflow.
skipping to change at page 7, line 20 skipping to change at page 7, line 20
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Method | Description | | Method | Description |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| PUBLISH | Used to publish a calendar entry to one or more | | PUBLISH | Used to publish a calendar entry to one or more |
| | Calendar Users. There is no interactivity | | | Calendar Users. There is no interactivity |
| | between the publisher and any other calendar | | | between the publisher and any other calendar |
| | user. An example might include a baseball team | | | user. An example might include a baseball team |
| | publishing its schedule to the public. | | | publishing its schedule to the public. |
| | | | | |
| REQUEST | Used to schedule a calendar entry with other | | REQUEST | Used to schedule a calendar entry with other |
| | Calendar Users. Requests are interactive in that | | | Calendar Users. Requests are interactive in |
| | they require the receiver to respond using the | | | that they require the receiver to respond using |
| | Reply methods. Meeting Requests, Busy Time | | | the Reply methods. Meeting Requests, Busy Time |
| | requests and the assignment of VTODOs to other | | | requests and the assignment of VTODOs to other |
| | Calendar Users are all examples. Requests are | | | Calendar Users are all examples. Requests are |
| | also used by the "Organizer" to update the | | | also used by the "Organizer" to update the |
| | status of a calendar entry. | | | status of a calendar entry. |
| | | | | |
| REPLY | A Reply is used in response to a Request to | | REPLY | A Reply is used in response to a Request to |
| | convey "Attendee" status to the "Organizer". | | | convey "Attendee" status to the "Organizer". |
| | Replies are commonly used to respond to meeting | | | Replies are commonly used to respond to meeting |
| | and task requests. | | | and task requests. |
| | | | | |
skipping to change at page 8, line 27 skipping to change at page 8, line 27
are a subset of the above set. are a subset of the above set.
2. Interoperability Models 2. Interoperability Models
There are two distinct protocols relevant to interoperability: an There are two distinct protocols relevant to interoperability: an
"Application Protocol" and a "Transport Protocol". The Application "Application Protocol" and a "Transport Protocol". The Application
Protocol defines the content of the iCalendar objects sent between Protocol defines the content of the iCalendar objects sent between
sender and receiver to accomplish the scheduling transactions listed sender and receiver to accomplish the scheduling transactions listed
above. The Transport Protocol defines how the iCalendar objects are above. The Transport Protocol defines how the iCalendar objects are
sent between the sender and receiver. This document focuses on the sent between the sender and receiver. This document focuses on the
Application Protocol. Binding documents such as [RFC2447] focus on Application Protocol. Binding documents such as [I-D.ietf-calsify-
the Transport Protocol. rfc2447bis] focus on the Transport Protocol.
The connection between Sender and Receiver in the diagram below The connection between Sender and Receiver in the diagram below
refers to the Application Protocol. The iCalendar objects passed refers to the Application Protocol. The iCalendar objects passed
from the Sender to the Receiver are presented in Section 3, from the Sender to the Receiver are presented in Section 3,
Application Protocol Elements. Application Protocol Elements.
+----------+ +----------+ +----------+ +----------+
| | iTIP | | | | iTIP | |
| Sender |<-------------------->| Receiver | | Sender |<-------------------->| Receiver |
| | | | | | | |
skipping to change at page 12, line 51 skipping to change at page 12, line 51
| 1 | One instance MUST be present | | 1 | One instance MUST be present |
| 1+ | At least one instance MUST be present | | 1+ | At least one instance MUST be present |
| 0 | Instances of this property Must NOT be present | | 0 | Instances of this property Must NOT be present |
| 0+ | Multiple instances MAY be present | | 0+ | Multiple instances MAY be present |
| 0 or 1 | Up to 1 instance of this property MAY be present | | 0 or 1 | Up to 1 instance of this property MAY be present |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
The tables also call out "X-PROPERTY" and "X-COMPONENT" to show where The tables also call out "X-PROPERTY" and "X-COMPONENT" to show where
vendor-specific properties and components can appear. The tables do vendor-specific properties and components can appear. The tables do
not lay out the restrictions of property parameters. Those not lay out the restrictions of property parameters. Those
restrictions are defined in [RFC2445]. restrictions are defined in [I-D.ietf-calsify-rfc2445bis].
+--------------------+----------+---------------------+ +--------------------+----------+---------------------+
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+---------------------+ +--------------------+----------+---------------------+
| CALSCALE | 0 or 1 | | | CALSCALE | 0 or 1 | |
| PRODID | 1 | | | PRODID | 1 | |
| VERSION | 1 | Value MUST be "2.0" | | VERSION | 1 | Value MUST be "2.0" |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
+--------------------+----------+---------------------+ +--------------------+----------+---------------------+
skipping to change at page 14, line 35 skipping to change at page 14, line 35
types that are applicable to the "VEVENT" calendar component. Each types that are applicable to the "VEVENT" calendar component. Each
method is defined using a table that clarifies the property method is defined using a table that clarifies the property
constraints that define the particular method. constraints that define the particular method.
The following summarizes the methods that are defined for the The following summarizes the methods that are defined for the
"VEVENT" calendar component. "VEVENT" calendar component.
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Method | Description | | Method | Description |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| PUBLISH | Post notification of an event. Used primarily as | | PUBLISH | Post notification of an event. Used primarily |
| | a method of advertising the existence of an | | | as a method of advertising the existence of an |
| | event. | | | event. |
| | | | | |
| REQUEST | Make a request for an event. This is an explicit | | REQUEST | Make a request for an event. This is an |
| | invitation to one or more "Attendees". Event | | | explicit invitation to one or more "Attendees". |
| | Requests are also used to update or change an | | | Event Requests are also used to update or change |
| | existing event. Clients that cannot handle | | | an existing event. Clients that cannot handle |
| | REQUEST may degrade the event to view it as an | | | REQUEST may degrade the event to view it as an |
| | PUBLISH. | | | PUBLISH. |
| | | | | |
| REPLY | Reply to an event request. Clients may set their | | REPLY | Reply to an event request. Clients may set |
| | status ("partstat") to ACCEPTED, DECLINED, | | | their status ("partstat") to ACCEPTED, DECLINED, |
| | TENTATIVE, or DELEGATED. | | | TENTATIVE, or DELEGATED. |
| | | | | |
| ADD | Add one or more instances to an existing event. | | ADD | Add one or more instances to an existing event. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | event. | | | event. |
| | | | | |
| REFRESH | A request is sent to an "Organizer" by an | | REFRESH | A request is sent to an "Organizer" by an |
| | "Attendee" asking for the latest version of an | | | "Attendee" asking for the latest version of an |
| | event to be resent to the requester. | | | event to be resent to the requester. |
skipping to change at page 36, line 23 skipping to change at page 36, line 23
| Component/Property | Presence | Comment | | Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" | | METHOD | 1 | MUST be "REPLY" |
| | | | | | | |
| VFREEBUSY | 1 | | | VFREEBUSY | 1 | |
| ATTENDEE | 1 | (address of recipient replying) | | ATTENDEE | 1 | (address of recipient replying) |
| DTSTAMP | 1 | | | DTSTAMP | 1 | |
| DTEND | 1 | DateTime values must be in UTC | | DTEND | 1 | DateTime values must be in UTC |
| DTSTART | 1 | DateTime values must be in UTC | | DTSTART | 1 | DateTime values must be in UTC |
| FREEBUSY | 1+ | (values MUST all be of the same | | FREEBUSY | 1+ | (values MUST all be of the same |
| | | data type. Multiple instances are | | | | data type. Multiple instances |
| | | allowed. Multiple instances MUST | | | | are allowed. Multiple instances |
| | | be sorted in ascending order. | | | | MUST be sorted in ascending |
| | | Values MAY NOT overlap) | | | | order. Values MAY NOT overlap) |
| ORGANIZER | 1 | MUST be the request originator's | | ORGANIZER | 1 | MUST be the request originator's |
| | | address | | | | address |
| UID | 1 | | | UID | 1 | |
| COMMENT | 0 or 1 | | | COMMENT | 0 or 1 | |
| CONTACT | 0+ | | | CONTACT | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| URL | 0 or 1 | (specifies busy time URL) | | URL | 0 or 1 | (specifies busy time URL) |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| DURATION | 0 | | | DURATION | 0 | |
| SEQUENCE | 0 | | | SEQUENCE | 0 | |
skipping to change at page 53, line 26 skipping to change at page 53, line 26
| | | instance of a recurring calendar | | | | instance of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | | | REQUEST-STATUS | 0+ | |
| RESOURCES | 0 or 1 | This property MAY contain a list | | RESOURCES | 0 or 1 | This property MAY contain a list |
| | | of values | | | | of values |
| RRULE | 0 or 1 | | | RRULE | 0 or 1 | |
| SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE | | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE |
| | | number. MUST be present if | | | | number. MUST be present if |
| | | non-zero. MAY be present if zero. | | | | non-zero. MAY be present if |
| | | zero. |
| STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | | STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS |
| | | ACTION/IN- PROCESS/CANCELLED | | | | ACTION/IN- PROCESS/CANCELLED |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time | | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone | | | | refers to a timezone |
| | | | | | | |
skipping to change at page 57, line 35 skipping to change at page 57, line 35
| LAST-MODIFIED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | |
| RDATE | 0+ | | | RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | MUST only if referring to an | | RECURRENCE-ID | 0 or 1 | MUST only if referring to an |
| | | instance of a recurring calendar | | | | instance of a recurring calendar |
| | | component. Otherwise it MUST NOT | | | | component. Otherwise it MUST NOT |
| | | be present. | | | | be present. |
| RELATED-TO | 0+ | | | RELATED-TO | 0+ | |
| RRULE | 0+ | | | RRULE | 0+ | |
| SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE | | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE |
| | | number. MUST be present if | | | | number. MUST be present if |
| | | non-zero. MAY be present if zero. | | | | non-zero. MAY be present if |
| | | zero. |
| STATUS | 0 or 1 | MAY be one of | | STATUS | 0 or 1 | MAY be one of |
| | | DRAFT/FINAL/CANCELLED | | | | DRAFT/FINAL/CANCELLED |
| SUMMARY | 0 or 1 | Can be null | | SUMMARY | 0 or 1 | Can be null |
| URL | 0 or 1 | | | URL | 0 or 1 | |
| X-PROPERTY | 0+ | | | X-PROPERTY | 0+ | |
| ATTENDEE | 0 | | | ATTENDEE | 0 | |
| | | | | | | |
| VALARM | 0+ | | | VALARM | 0+ | |
| | | | | | | |
| VTIMEZONE | 0+ | MUST be present if any date/time | | VTIMEZONE | 0+ | MUST be present if any date/time |
skipping to change at page 120, line 14 skipping to change at page 120, line 14
request should be honored. An implementation MAY decide to maintain, request should be honored. An implementation MAY decide to maintain,
for audit or historical purposes, "Calendar Users" who were part of for audit or historical purposes, "Calendar Users" who were part of
an attendee list and who were subsequently uninvited. Similar an attendee list and who were subsequently uninvited. Similar
controls or alerts should be provided when a "REFRESH" request is controls or alerts should be provided when a "REFRESH" request is
received from these "Calendar Users" as well. received from these "Calendar Users" as well.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.ietf-calsify-rfc2445bis]
Requirement Levels", BCP 14, RFC 2119, March 1997. Desruisseaux, B. and C. Stoner, "Internet Calendaring and
[RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", Scheduling Core Object Specification (iCalendar)",
RFC 2445, November 1998. draft-ietf-calsify-rfc2445bis-00 (work in progress),
October 2005.
[RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar [I-D.ietf-calsify-rfc2447bis]
Message-Based Interoperability Protocol (iMIP)", RFC 2447, Melnikov, A., "iCalendar Message-Based Interoperability
November 1998. Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-01 (work
in progress), March 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References 7.2. Informative References
Appendix A. Acknowledgments Appendix A. Acknowledgments
This is an update to the original iTIP document authored by This is an update to the original iTIP document authored by
S.Silverberg, S. Mansour, F. Dawson and R. Hopson. S.Silverberg, S. Mansour, F. Dawson and R. Hopson.
Author's Address Author's Address
skipping to change at page 122, line 41 skipping to change at page 122, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 22 change blocks. 
52 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/