tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2446

 
 
 

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

Part 2 of 4, p. 12 to 50
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 12 
3 Application Protocol Elements

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

   +=================================================+
   |         | VEVENT | VTODO | VJOURNAL | VFREEBUSY |
   |=================================================|
   |Publish  |  Yes   |  Yes  |  Yes     |   Yes     |
   |Request  |  Yes   |  Yes  |  No      |   Yes     |
   |Refresh  |  Yes   |  Yes  |  No      |   No      |
   |Cancel   |  Yes   |  Yes  |  Yes     |   No      |
   |Add      |  Yes   |  Yes  |  Yes     |   No      |
   |Reply    |  Yes   |  Yes  |  No      |   Yes     |
   |Counter  |  Yes   |  Yes  |  No      |   No      |
   |Decline- |        |       |          |           |
   |Counter  |  Yes   |  Yes  |  No      |   No      |
   +=================================================+

   Each method type is defined in terms of its associated components and
   properties. Some components and properties are required, some are
   optional and others are excluded. The restrictions are expressed in
   this document using a simple "restriction table". The first column
   indicates the name of a component or property. Properties of the
   iCalendar object are not indented. Properties of a component are
   indented. The second column contains "MUST" if the component or
   property must be present, "MAY" if the component or property is
   optional, and "NOT" if the component or property must not be present.
   Entries in the second column sometimes contain comments for further
   clarification.

Top      Up      ToC       Page 13 
3.1 Common Component Restriction Tables

   The restriction table below applies to properties of the iCalendar
   object. That is, the properties at the outermost scope. The presence
   column uses the following values to assert whether a property is
   required, is optional and the number of times it may appear in the
   iCalendar object.

   Presence Value       Description
   --------------------------------------------------------------
   1                 One instance MUST be present
   1+                At least one instance MUST be present
   0                 Instances of this property Must NOT be present
   0+                Multiple instances 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 vendor-specific properties and components can appear.  The
   tables do not lay out the restrictions of property parameters. Those
   restrictions are defined in [iCAL].

   Component/Property  Presence
   ------------------- ----------------------------------------------
   CALSCALE            0 or 1
   PRODID              1
   VERSION             1       Value MUST be "2.0"
   X-PROPERTY          0+


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

   Component/Property  Presence
   ------------------- ----------------------------------------------
   VTIMEZONE           0+      MUST be present if any date/time refers
                               to timezone
       DAYLIGHT        0+      MUST be one or more of either STANDARD or
                               DAYLIGHT
          COMMENT      0 or 1
          DTSTART      1       MUST be local time format
          RDATE        0+      if present RRULE MUST NOT be present
          RRULE        0+      if present RDATE MUST NOT be present
          TZNAME       0 or 1
          TZOFFSET     1
          TZOFFSETFROM 1
          TZOFFSETTO   1

Top      Up      ToC       Page 14 
          X-PROPERTY   0+
       LAST-MODIFIED   0 or 1
       STANDARD        0+      MUST be one or more of either STANDARD or
                               DAYLIGHT
          COMMENT      0 or 1
          DTSTART      1       MUST be local time format
          RDATE        0+      if present RRULE MUST NOT be present
          RRULE        0+      if present RDATE MUST NOT be present
          TZNAME       0 or 1
          TZOFFSETFROM 1
          TZOFFSETTO   1
          X-PROPERTY   0+
       TZID            1
       TZURL           0 or 1
       X-PROPERTY      0+

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

   Component/Property  Presence
   ------------------- ----------------------------------------------
   VALARM              0+
       ACTION          1
       ATTACH          0+
       DESCRIPTION     0 or 1
       DURATION        0 or 1  if present REPEAT MUST be present
       REPEAT          0 or 1  if present DURATION MUST be present
       SUMMARY         0 or 1
       TRIGGER         1
       X-PROPERTY      0+

3.2 Methods for VEVENT Calendar Components

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

Top      Up      ToC       Page 15 
   The following summarizes the methods that are defined for the
   "VEVENT" calendar component.

   +================+==================================================+
   | Method         |  Description                                     |
   |================+==================================================|
   | PUBLISH        | Post notification of an event. Used primarily as |
   |                | a method of advertising the existence of an      |
   |                | event.                                           |
   |                |                                                  |
   | REQUEST        | Make a request for an event. This is an explicit |
   |                | invitation to one or more "Attendees". Event     |
   |                | Requests are also used to update or change an    |
   |                | existing event. Clients that cannot handle       |
   |                | REQUEST may degrade the event to view it as an   |
   |                | PUBLISH.                                         |
   |                |                                                  |
   | REPLY          | Reply to an event request. Clients may set their |
   |                | status ("partstat") to ACCEPTED, DECLINED,       |
   |                | TENTATIVE, or DELEGATED.                         |
   |                |                                                  |
   | ADD            | Add one or more instances to an existing event.  |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | event.                                           |
   |                |                                                  |
   | REFRESH        | A request is sent to an "Organizer" by an        |
   |                | "Attendee" asking for the latest version of an   |
   |                | event to be resent to the requester.             |
   |                |                                                  |
   | COUNTER        | Counter a REQUEST with an alternative proposal,  |
   |                | Sent by an "Attendee" to the "Organizer".        |
   |                |                                                  |
   | DECLINECOUNTER | Decline a counter proposal. Sent to an           |
   |                | "Attendee" by the "Organizer".                   |
   +================+==================================================+

3.2.1 PUBLISH

   The "PUBLISH" method in a "VEVENT" calendar component is an
   unsolicited posting of an iCalendar object. Any CU may add published
   components to their calendar. The "Organizer" MUST be present in a
   published iCalendar component. "Attendees" MUST NOT be present. Its
   expected usage is for encapsulating an arbitrary event as an
   iCalendar object. The "Organizer" may subsequently update (with
   another "PUBLISH" method), add instances to (with an "ADD" method),
   or cancel (with a "CANCEL" method) a previously published "VEVENT"
   calendar component.

Top      Up      ToC       Page 16 
   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST equal "PUBLISH"
VEVENT              1+
     DTSTAMP        1
     DTSTART        1
     ORGANIZER      1
     SUMMARY        1       Can be null.
     UID            1
     RECURRENCE-ID  0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise
                            it MUST NOT be present.
     SEQUENCE       0 or 1  MUST be present if value is greater than
                            0, MAY be present if 0
     ATTACH         0+
     CATEGORIES     0 or 1  This property may contain a list of
                            values
     CLASS          0 or 1
     COMMENT        0 or 1
     CONTACT        0+
     CREATED        0 or 1
     DESCRIPTION    0 or 1  Can be null
     DTEND          0 or 1  if present DURATION MUST NOT be present
     DURATION       0 or 1  if present DTEND MUST NOT be present
     EXDATE         0+
     EXRULE         0+
     GEO            0 or 1
     LAST-MODIFIED  0 or 1
     LOCATION       0 or 1
     PRIORITY       0 or 1
     RDATE          0+
     RELATED-TO     0+
     RESOURCES      0 or 1 This property MAY contain a list of values
     RRULE          0+
     STATUS         0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED
     TRANSP         0 or 1
     URL            0 or 1
     X-PROPERTY     0+

     ATTENDEE       0
     REQUEST-STATUS 0

VALARM              0+
VFREEBUSY           0
VJOURNAL            0

Top      Up      ToC       Page 17 
VTODO               0
VTIMEZONE           0+    MUST be present if any date/time refers to
                          a timezone
X-COMPONENT         0+

3.2.2 REQUEST

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

     .  Invite "Attendees" to an event;
     .  Reschedule an existing event;
     .  Response to a REFRESH request;
     .  Update the details of an existing event, without rescheduling it;
     .  Update the status of "Attendees" of an existing event, without
        rescheduling it;
     .  Reconfirm an existing event, without rescheduling it;
     .  Forward a "VEVENT" to another uninvited CU.
     .  For an existing "VEVENT" calendar component, delegate the role of
        "Attendee" to another CU;
     .  For an existing "VEVENT" calendar component, changing the role of
        "Organizer" to another CU.

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

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

   For the "REQUEST" method, multiple "VEVENT" components in a single
   iCalendar object are only permitted when for components with the same
   "UID" property.  That is, a series of recurring events may have
   instance-specific information.  In this case, multiple "VEVENT"
   components are needed to express the entire series.

Top      Up      ToC       Page 18 
   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
-----------------------------------------------------------------
METHOD              1       MUST be "REQUEST"
VEVENT              1+      All components MUST have the same UID
    ATTENDEE        1+
    DTSTAMP         1
    DTSTART         1
    ORGANIZER       1
    SEQUENCE        0 or 1  MUST be present if value is greater than 0,
                            MAY be present if 0
    SUMMARY         1       Can be null
    UID             1

    ATTACH          0+
    CATEGORIES      0 or 1  This property may contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1  Can be null
    DTEND           0 or 1  if present DURATION MUST NOT be present
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.
    RELATED-TO      0+
    REQUEST-STATUS  0+
    RESOURCES       0 or 1  This property MAY contain a list of values
    RRULE           0+
    STATUS          0 or 1  MAY be one of TENTATIVE/CONFIRMED
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+

VALARM              0+
VTIMEZONE           0+      MUST be present if any date/time refers to
                            a timezone
X-COMPONENT         0+

Top      Up      ToC       Page 19 
VFREEBUSY           0
VJOURNAL            0
VTODO               0

3.2.2.1 Rescheduling an Event

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

3.2.2.2 Updating or Reconfirmation of an Event

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

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

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

3.2.2.3 Delegating an Event to another CU

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

Top      Up      ToC       Page 20 
   The "Delegator" of an event forwards the existing "REQUEST" to the
   "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
   with the calendar address of the "Delegate". The "Delegator" MUST
   also send a "REPLY" method to the "Organizer" with the "Delegator's"
   "ATTENDEE" property "partstat" parameter value set to "delegated". In
   addition, the "delegated-to" parameter MUST be included with the
   calendar address of the "Delegate".

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

   The "Delegator" may continue to receive updates to the event even
   though they will not be attending. This is accomplished by the
   "Delegator" setting their "role" attribute to " NON-PARTICIPANT" in
   the "REPLY" to the "Organizer"

3.2.2.4 Changing the Organizer

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

3.2.2.5 Sending on Behalf of the Organizer

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

3.2.2.6 Forwarding to An Uninvited CU

   An "Attendee" invited to an event may invite another uninvited CU to
   the event. The invited "Attendee" accomplishes this by forwarding the
   original "REQUEST" method to the uninvited CU. The "Organizer"
   decides whether or not the uninvited CU is added to the attendee

Top      Up      ToC       Page 21 
   list. If the "Organizer" decides not to add the uninvited CU no
   further action is required, however the "Organizer" MAY send the
   uninvited CU a "CANCEL" message.  If the "Organizer" decides to add
   an uninvited CU, a new "ATTENDEE" property is added for the uninvited
   CU with its property parameters set as the "Organizer" deems
   appropriate. When forwarding a "REQUEST" to another CU, the
   forwarding "Attendee" MUST NOT make changes to the VEVENT property
   set.

3.2.2.7 Updating Attendee Status

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

3.2.3 REPLY

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

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

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

   An "Attendee" can include a message to the "Organizer" using the
   "COMMENT" property. For example, if the user indicates tentative
   acceptance and wants to let the "Organizer" know why, the reason can
   be expressed in the "COMMENT" property value.

Top      Up      ToC       Page 22 
   The "Organizer" may also receive a "REPLY" from one CU on behalf of
   another. Like the scenario enumerated above for the "Organizer",
   "Attendees" may have another CU respond on their behalf. This is done
   using the "sent-by" parameter.

   The optional properties listed in the table below (those listed as
   "0+" or "0 or 1") MUST NOT be changed from those of the original
   request.  If property changes are desired the COUNTER message must be
   used.

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST be "REPLY"
VEVENT              1+      All components MUST have the same UID
    ATTENDEE        1       MUST be the address of the Attendee
                            replying.
    DTSTAMP         1
    ORGANIZER       1
    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise
                            it must NOT be present.
    UID             1       MUST be the UID of the original REQUEST

    SEQUENCE        0 or 1  MUST if non-zero, MUST be the sequence
                            number of the original REQUEST. MAY be
                            present if 0.

    ATTACH          0+
    CATEGORIES      0 or 1  This property may contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1
    DTEND           0 or 1  if present DURATION MUST NOT be present
    DTSTART         0 or 1
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RELATED-TO      0+

Top      Up      ToC       Page 23 
    RESOURCES       0 or 1  This property MAY contain a list of values
    REQUEST-STATUS  0+
    RRULE           0+
    STATUS          0 or 1
    SUMMARY         0 or 1
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+

VTIMEZONE           0 or 1 MUST be present if any date/time refers
                           to a timezone
X-COMPONENT         0+

VALARM              0
VFREEBUSY           0
VJOURNAL            0
VTODO               0

3.2.4 ADD

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

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

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

Top      Up      ToC       Page 24 
Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "ADD"
VEVENT              1
    DTSTAMP         1
    DTSTART         1
    ORGANIZER       1
    SEQUENCE        1      MUST be greater than 0
    SUMMARY         1      Can be null
    UID             1      MUST match that of the original event

    ATTACH          0+
    ATTENDEE        0+
    CATEGORIES      0 or 1 This property MAY contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1  Can be null
    DTEND           0 or 1  if present DURATION MUST NOT be present
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RELATED-TO      0+
    RESOURCES       0 or 1  This property MAY contain a list of values
    RRULE           0+
    STATUS          0 or 1  MAY be one of TENTATIVE/CONFIRMED
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+

    RECURRENCE-ID   0
    REQUEST-STATUS  0

VALARM              0+
VTIMEZONE           0+     MUST be present if any date/time refers to
                           a timezone
X-COMPONENT         0+

VFREEBUSY           0
VTODO               0
VJOURNAL            0

Top      Up      ToC       Page 25 
3.2.5 CANCEL

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

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

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

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

   When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
   incremented.

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "CANCEL"

VEVENT              1+     All must have the same UID
    ATTENDEE        0+     MUST include all "Attendees" being removed
                           the event. MUST include all "Attendees" if
                           the entire event is cancelled.
    DTSTAMP         1
    ORGANIZER       1
    SEQUENCE        1
    UID             1       MUST be the UID of the original REQUEST

    COMMENT         0 or 1
    ATTACH          0+
    CATEGORIES      0 or 1  This property may contain a list of values

Top      Up      ToC       Page 26 
    CLASS           0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1
    DTEND           0 or 1 if present DURATION MUST NOT be present
    DTSTART         0 or 1
    DURATION        0 or 1 if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RECURRENCE-ID   0 or 1  MUST be present if referring to one or
                            more or more recurring instances.
                            Otherwise it MUST NOT be present
    RELATED-TO      0+
    RESOURCES       0 or 1
    RRULE           0+
    STATUS          0 or 1  MUST be set to CANCELLED. If uninviting
                            specific "Attendees" then MUST NOT be
                            included.
    SUMMARY         0 or 1
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+
    REQUEST-STATUS  0

VTIMEZONE           0+     MUST be present if any date/time refers to
                           a timezone
X-COMPONENT         0+

VTODO               0
VJOURNAL            0
VFREEBUSY           0
VALARM              0

3.2.6 REFRESH

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

Top      Up      ToC       Page 27 
   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "REFRESH"

VEVENT              1
    ATTENDEE        1      MUST be the address of requestor
    DTSTAMP         1
    ORGANIZER       1
    UID             1      MUST be the UID associated with original
                           REQUEST
    COMMENT         0 or 1
    RECURRENCE-ID   0 or 1 MUST only if referring to an instance of a
                           recurring calendar component.  Otherwise
                           it must NOT be present.
    X-PROPERTY      0+

    ATTACH          0
    CATEGORIES      0
    CLASS           0
    CONTACT         0
    CREATED         0
    DESCRIPTION     0
    DTEND           0
    DTSTART         0
    DURATION        0
    EXDATE          0
    EXRULE          0
    GEO             0
    LAST-MODIFIED   0
    LOCATION        0
    PRIORITY        0
    RDATE           0
    RELATED-TO      0
    REQUEST-STATUS  0
    RESOURCES       0
    RRULE           0
    SEQUENCE        0
    STATUS          0
    SUMMARY         0
    TRANSP          0
    URL             0

X-COMPONENT         0+

VTODO               0

Top      Up      ToC       Page 28 
VJOURNAL            0
VFREEBUSY           0
VTIMEZONE           0
VALARM              0

3.2.7 COUNTER

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

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

   The "Organizer" rejects the counter proposal by sending the
   "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts
   the counter proposal by rescheduling the event as described in
   section 3.2.2.1 Rescheduling an Event.

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "COUNTER"

VEVENT              1
    DTSTAMP         1
    DTSTART         1
    ORGANIZER       1       MUST be the "Organizer" of the original
                            event
    SEQUENCE        1       MUST be present if value is greater than 0,
                            MAY be present if 0
    SUMMARY         1       Can be null
    UID             1       MUST be the UID associated with the REQUEST
                            being countered

    ATTACH          0+
    ATTENDEE        0+      Can also  be used to propose other
                            "Attendees"
    CATEGORIES      0 or 1  This property may contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1

Top      Up      ToC       Page 29 
    DTEND           0 or 1  if present DURATION MUST NOT be present
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RECURRENCE-ID   0 or 1  MUST only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.
    RELATED-TO      0+
    REQUEST-STATUS  0+
    RESOURCES       0 or 1  This property may contain a list of values
    RRULE           0+
    STATUS          0 or 1  Value must be one of CONFIRMED/TENATIVE/
                            CANCELLED
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+

VALARM              0+
VTIMEZONE           0+      MUST be present if any date/time refers to
                            a timezone
X-COMPONENT         0+

VTODO               0
VJOURNAL            0
VFREEBUSY           0

3.2.8 DECLINECOUNTER

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

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

Top      Up      ToC       Page 30 
Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "DECLINECOUNTER"

VEVENT              1
    DTSTAMP         1
    ORGANIZER       1
    UID             1       MUST, same UID specified in original
                            REQUEST and subsequent COUNTER
    COMMENT         0 or 1
    RECURRENCE-ID   0 or 1  MUST only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.
    REQUEST-STATUS  0+
    SEQUENCE        0 OR 1  MUST be present if value is greater than 0,
                            MAY be present if 0
    X-PROPERTY      0+
    ATTACH          0
    ATTENDEE        0
    CATEGORIES      0
    CLASS           0
    CONTACT         0
    CREATED         0
    DESCRIPTION     0
    DTEND           0
    DTSTART         0
    DURATION        0
    EXDATE          0
    EXRULE          0
    GEO             0
    LAST-MODIFIED   0
    LOCATION        0
    PRIORITY        0
    RDATE           0
    RELATED-TO      0
    RESOURCES       0
    RRULE           0
    STATUS          0
    SUMMARY         0
    TRANSP          0
    URL             0

X-COMPONENT         0+
VTODO               0
VJOURNAL            0
VFREEBUSY           0
VTIMEZONE           0
VALARM              0

Top      Up      ToC       Page 31 
3.3 Methods For VFREEBUSY Components

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

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

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

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

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

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

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

Top      Up      ToC       Page 32 
   |================|==================================================|
   | Method         |  Description                                     |
   |================|==================================================|
   | PUBLISH        | Publish unsolicited busy time data.              |
   | REQUEST        | Request busy time data.                          |
   | REPLY          | Reply to a busy time request.                    |
   |================|==================================================|

3.3.1 PUBLISH

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

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

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST be "PUBLISH"

VFREEBUSY           1+
    DTSTAMP         1
    DTSTART         1       DateTime values must be in UTC
    DTEND           1       DateTime values must be in UTC
    FREEBUSY        1+      MUST be BUSYTIME. Multiple instances are
                            allowed. Multiple instances must be sorted
                            in ascending order
    ORGANIZER       1       MUST contain the address of originator of
                            busy time data.

    COMMENT         0 or 1
    CONTACT         0+
    X-PROPERTY      0+
    URL             0 or 1  Specifies busy time URL

    ATTENDEE        0
    DURATION        0
    REQUEST-STATUS  0
    UID             0

X-COMPONENT         0+

Top      Up      ToC       Page 33 
VEVENT              0
VTODO               0
VJOURNAL            0
VTIMEZONE           0
VALARM              0

3.3.2 REQUEST

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

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

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

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "REQUEST"

VFREEBUSY           1
    ATTENDEE        1+     contain the address of the calendar store
    DTEND           1      DateTime values must be in UTC
    DTSTAMP         1
    DTSTART         1      DateTime values must be in UTC
    ORGANIZER       1      MUST be the request originator's address
    UID             1
    COMMENT         0 or 1
    CONTACT         0+
    X-PROPERTY      0+

    FREEBUSY        0
    DURATION        0
    REQUEST-STATUS  0
    URL             0

X-COMPONENT         0+
VALARM              0
VEVENT              0

Top      Up      ToC       Page 34 
VTODO               0
VJOURNAL            0
VTIMEZONE           0

3.3.3 REPLY

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

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

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "REPLY"

VFREEBUSY           1
    ATTENDEE        1      (address of recipient replying)
    DTSTAMP         1
    DTEND           1      DateTime values must be in UTC
    DTSTART         1      DateTime values must be in UTC
    FREEBUSY        1+      (values MUST all be of the same data
                            type. Multiple instances are allowed.
                            Multiple instances MUST be sorted in
                            ascending order. Values MAY NOT overlap)
    ORGANIZER       1       MUST be the request originator's address
    UID             1

    COMMENT         0 or 1
    CONTACT         0+
    REQUEST-STATUS  0+
    URL             0 or 1  (specifies busy time URL)
    X-PROPERTY      0+
    DURATION        0
    SEQUENCE        0

X-COMPONENT         0+
VALARM              0
VEVENT              0
VTODO               0
VJOURNAL            0
VTIMEZONE           0

Top      Up      ToC       Page 35 
3.4 Methods For VTODO Components

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

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

   +================+==================================================+
   | Method         |  Description                                     |
   |================+==================================================|
   | PUBLISH        | Post notification of a VTODO. Used primarily as  |
   |                | a method of advertising the existence of a VTODO.|
   |                |                                                  |
   | REQUEST        | Assign a VTODO. This is an explicit assignment to|
   |                | one or more Calendar Users. The REQUEST method   |
   |                | is also used to update or change an existing     |
   |                | VTODO. Clients that cannot handle REQUEST MAY    |
   |                | degrade the method to treat it as a PUBLISH.     |
   |                |                                                  |
   | REPLY          | Reply to a VTODO request. Attendees MAY set      |
   |                | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE,       |
   |                | DELEGATED, PARTIAL, and COMPLETED.               |
   |                |                                                  |
   | ADD            | Add one or more instances to an existing to-do.  |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | to-do.                                           |
   |                |                                                  |
   | REFRESH        | A request sent to a VTODO Organizer asking for   |
   |                | the latest version of a VTODO.                   |
   |                |                                                  |
   | COUNTER        | Counter a REQUEST with an alternative proposal.  |
   |                |                                                  |
   | DECLINECOUNTER | Decline a counter proposal by an Attendee.       |
   +================+==================================================+

3.4.1 PUBLISH

   The "PUBLISH" method in a "VTODO" calendar component has no
   associated response. It is simply a posting of an iCalendar object
   that maybe added to a calendar. It MUST have an "Organizer".  It MUST
   NOT have "Attendees". Its expected usage is for encapsulating an
   arbitrary "VTODO" calendar component as an iCalendar object. The
   "Organizer" MAY subsequently update (with another "PUBLISH" method),
   add instances to (with an "ADD" method), or cancel (with a "CANCEL"

Top      Up      ToC       Page 36 
   method) a previously published "VTODO" calendar component.

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD               1       MUST be "PUBLISH"
VTODO                1+
    DTSTAMP          1
    DTSTART          1
    ORGANIZER        1
    PRIORITY         1
    SEQUENCE         0 or 1  MUST be present if value is greater than
                             0, MAY be present if 0
    SUMMARY          1       Can be null.
    UID              1

    ATTACH           0+
    CATEGORIES       0 or 1  This property may contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1  Can be null
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1
    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    RDATE            0+
    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a
                             recurring calendar component.  Otherwise
                             it MUST NOT be present.

    RELATED-TO       0+
    RESOURCES        0 or 1  This property may contain a list of values
    RRULE            0+
STATUS           0 or 1  MAY be one of COMPLETED/NEEDS ACTION/IN-
                             PROCESS/CANCELLED
    URL              0 or 1
    X-PROPERTY      0+

    ATTENDEE         0
    REQUEST-STATUS   0

Top      Up      ToC       Page 37 
VTIMEZONE            0+    MUST be present if any date/time refers to
                           a timezone
VALARM               0+
X-COMPONENT          0+

VFREEBUSY            0
VEVENT               0
VJOURNAL             0

3.4.2 REQUEST

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

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

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

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

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

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

   For the "REQUEST" method, multiple "VTODO" components in a single
   iCalendar object are only permitted when for components with the same
   "UID" property.  That is, a series of recurring events may have

Top      Up      ToC       Page 38 
   instance-specific information.  In this case, multiple "VTODO"
   components are needed to express the entire series.

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD                1       MUST be "REQUEST"
VTODO                 1+      All components must have the same UID
    ATTENDEE          1+
    DTSTAMP           1
    DTSTART           1
    ORGANIZER         1
    PRIORITY          1
    SEQUENCE          0 or 1  MUST be present if value is greater than
                              0, MAY be present if 0
    SUMMARY           1       Can be null.
    UID               1

    ATTACH            0+
    CATEGORIES        0 or 1   This property may contain a list of
                               values
    CLASS             0 or 1
    COMMENT           0 or 1
    CONTACT           0+
    CREATED           0 or 1
    DESCRIPTION       0 or 1  Can be null
    DUE               0 or 1  If present DURATION MUST NOT be present
    DURATION          0 or 1  If present DUE MUST NOT be present
    EXDATE            0+
    EXRULE            0+
    GEO               0 or 1
    LAST-MODIFIED     0 or 1
    LOCATION          0 or 1
    PERCENT-COMPLETE  0 or 1
    RDATE             0+
    RECURRENCE-ID     0 or 1  present if referring to an instance of a
                              recurring calendar component.  Otherwise
                              it MUST NOT be present.
    RELATED-TO        0+
    RESOURCES         0 or 1  This property may contain a list of
                              values
    RRULE             0+
    STATUS            0 or 1  MAY be one of COMPLETED/NEEDS ACTION/IN-
                              PROCESS
    URL               0 or 1
    X-PROPERTY        0+

Top      Up      ToC       Page 39 
    REQUEST-STATUS    0

VALARM                0+

VTIMEZONE             0+  MUST be present if any date/time refers
                          to a timezone
X-COMPONENT           0+

VEVENT                0
VFREEBUSY             0
VJOURNAL              0

3.4.2.1 REQUEST for Rescheduling a VTODO

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

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

3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO

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

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

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

   Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a
   "VTODO" calendar component. The unsolicited "REQUEST" methods are

Top      Up      ToC       Page 40 
   used to update the details of the "VTODO" (without rescheduling it or
   updating the completion status of "Attendees") or the "VTODO"
   calendar component itself (i.e., reconfirm the "VTODO").

3.4.2.3 REQUEST for Delegating a VTODO

   The "REQUEST" method is also used to delegate or reassign ownership
   of a "VTODO" calendar component to another "Calendar User". For
   example, it may be used to delegate an "Attendee's" role (i.e.
   "chair", or "participant") for a "VTODO" calendar component. The
   "REQUEST" method is sent by one of the "Attendees" of an existing

   "VTODO" calendar component to some other individual. An "Attendee" of
   a "VTODO" calendar component MUST NOT delegate to the "Organizer" of
   the event.

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

   The "Delegator" of a "VTODO" calendar component MUST forward the
   existing "REQUEST" method for a "VTODO" calendar component to the
   "Delegate". The "VTODO" calendar component description MUST include
   the "Delegator's" up-to-date "VTODO" calendar component definition.
   The "REQUEST" method MUST also include an "ATTENDEE" property with
   the calendar address of the "Delegate". The "Delegator" MUST also
   send a "REPLY" method back to the "Organizer" with the "Delegator's"
   "Attendee" property "partstat" parameter value set to "DELEGATED". In
   addition, the "delegated-to" parameter MUST be included with the
   calendar address of the "Delegate". A response to the delegation
   "REQUEST" is sent from the "Delegate" to the "Organizer" and
   optionally, to the "Delegator". The "REPLY" method from the
   "Delegate" SHOULD include the "ATTENDEE" property with their calendar
   address and the "delegated-from" parameter with the value of the
   "Delegator's" calendar address.

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

3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User

   An "Attendee" assigned a "VTODO" calendar component may send the
   "VTODO" calendar component to another new CU, not previously
   associated with the "VTODO" calendar component. The current

Top      Up      ToC       Page 41 
   "Attendee" assigned the "VTODO" calendar component does this by
   forwarding the original "REQUEST" method to the new CU. The new CU
   can send a "REPLY" to the "Organizer" of the "VTODO" calendar
   component. The reply contains an "ATTENDEE" property for the new CU.

   The "Organizer" ultimately decides whether or not the new CU becomes
   part of the to-do and is not obligated to do anything with a "REPLY"
   from a new (uninvited) CU. If the "Organizer" does not want the new
   CU to be part of the to-do, the new "ATTENDEE" property is not added
   to the "VTODO" calendar component. The "Organizer" MAY send the CU a
   "CANCEL" message to indicate that they will not be added to the to-
   do. If the "Organizer" decides to add the new CU, the new "ATTENDEE"
   property is added to the "VTODO" calendar component. Furthermore, the
   "Organizer" is free to change any "ATTENDEE" property parameter from
   the values supplied by the new CU to something the "Organizer"
   considers appropriate.

3.4.2.5 REQUEST Updated Attendee Status

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

3.4.3 REPLY

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

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

   The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY"
   method from a "Calendar User" not in the original "REQUEST". For
   example, a "REPLY" method MAY be received from a "Delegate" of a
   "VTODO" calendar component. In addition, the "REPLY" method MAY be

Top      Up      ToC       Page 42 
   received from an unknown "Calendar User", having been forwarded the
   "REQUEST" by an original "Attendee" of the "VTODO" calendar
   component. This uninvited "Attendee" MAY be accepted, or the
   "Organizer" MAY cancel the "VTODO" calendar component for the
   uninvited "Attendee" by sending them a "CANCEL" method.

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

Component/Property   Presence
-------------------  ---------------------------------------------
METHOD               1      MUST be "REPLY"
VTODO                1+     All component MUST have the same UID
    ATTENDEE         1+
    DTSTAMP          1
    ORGANIZER        1
    REQUEST-STATUS   1+
    UID              1      MUST must be the address of the replying
                            attendee

    ATTACH           0+
    CATEGORIES       0 or 1 This property may contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1
    DTSTART          0 or 1
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1
    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    PRIORITY         0 or 1
    RDATE            0+
    RELATED-TO       0+
    RESOURCES        0 or 1  This property may contain a list of values
    RRULE            0+
    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a
                             Recurring calendar component. Otherwise it
                             MUST NOT be present
    SEQUENCE         0 or 1  MUST be the sequence number of
                             the original REQUEST if greater than 0.
                             MAY be present if 0.
    STATUS           0 or 1

Top      Up      ToC       Page 43 
    SUMMARY          0 or 1  Can be null
    URL              0 or 1
    X-PROPERTY       0+

VTIMEZONE            0 or 1  MUST be present if any date/time refers to
                             a timezone
X-COMPONENT          0+

VALARM               0
VEVENT               0
VFREEBUSY            0

3.4.4 ADD

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

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

   The "SEQUENCE" property value is incremented as the sequence of to-
   dos has changed.

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD                1       MUST be "ADD"
VTODO                 1
    DTSTAMP           1
    ORGANIZER         1
    PRIORITY          1
    SEQUENCE          1       MUST be greater than 0
    SUMMARY           1       Can be null.
    UID               1       MUST match that of the original to-do

    ATTACH            0+
    ATTENDEE          0+
    CATEGORIES        0 or 1  This property may contain a list of
                              values
    CLASS             0 or 1
    COMMENT           0 or 1
    CONTACT           0+

Top      Up      ToC       Page 44 
    CREATED           0 or 1
    DESCRIPTION       0 or 1  Can be null
    DTSTART           0 or 1
    DUE               0 or 1  If present DURATION MUST NOT be present
    DURATION          0 or 1  If present DUE MUST NOT be present
    EXDATE            0+
    EXRULE            0+
    GEO               0 or 1
    LAST-MODIFIED     0 or 1
    LOCATION          0 or 1
    PERCENT-COMPLETE  0 or 1
    RDATE             0+
    RELATED-TO        0+
    RESOURCES         0 or 1  This property may contain a list of
                              values
    RRULE             0+
    STATUS            0 or 1  MAY be one of COMPLETED/NEEDS ACTION/IN-
                              PROCESS
    URL               0 or 1
    X-PROPERTY        0+

    RECURRENCE-ID     0
    REQUEST-STATUS    0

VALARM                0+
VTIMEZONE             0+      MUST be present if any date/time refers
                              to a timezone
X-COMPONENT           0+

VEVENT                0
VJOURNAL              0
VFREEBUSY             0

3.4.5 CANCEL

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

Top      Up      ToC       Page 45 
   There are two options for canceling a sequence of instances of a
   recurring "VTODO" calendar component:

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

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

   When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
   incremented.

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

Component/Property   Presence
-------------------  ---------------------------------------------
METHOD               1     MUST be "CANCEL"
VTODO                1
    ATTENDEE         0+    include all "Attendees" being removed from
                           the todo. MUST include all "Attendees" if
                           the entire todo is cancelled.
    UID              1     MUST echo original UID
    DTSTAMP          1
    ORGANIZER        1
    SEQUENCE         1

    ATTACH           0+
    CATEGORIES       0 or 1 This property MAY contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1
    DTSTART          0 or 1
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1
    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    RDATE            0+

Top      Up      ToC       Page 46 
    RECURRENCE-ID    0 or 1 MUST only if referring to one or more
                            instances of a recurring calendar
                            component. Otherwise it MUST NOT be
                            present.
    RELATED-TO       0+
    RESOURCES        0 or 1 This property MAY contain a list of values
    RRULE            0+
    PRIORITY         0 or 1
    STATUS           0 or 1  If present it MUST be set to "CANCELLED".
                             MUST NOT be used if purpose is to remove
                             "ATTENDEES" rather than cancel the entire
                             VTODO.
    URL              0 or 1
    X-PROPERTY       0+

    REQUEST-STATUS   0

VTIMEZONE            0 or 1  MUST be present if any date/time refers to
                             a timezone
X-COMPONENT          0+

VALARM               0
VEVENT               0
VFREEBUSY            0

3.4.6 REFRESH

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

   A refresh of a recurrence instance of a "VTODO" calendar component
   may be requested by specifying the "RECURRENCE-ID" property
   corresponding to the associated "VTODO" calendar component. The
   "Organizer" responds with the latest description and rendition of the
   "VTODO" calendar component.  In most cases this will be a REQUEST
   unless the "VTODO" has been cancelled, in which case the ORGANIZER
   MUST send a "CANCEL". This method is intended to facilitate machine
   processing of requests for updates to a "VTODO" calendar component.

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

Top      Up      ToC       Page 47 
Component/Property   Presence
-------------------  ---------------------------------------------
METHOD               1      MUST be "REFRESH"
VTODO                1
    ATTENDEE         1
    DTSTAMP          1
    UID              1       MUST echo original UID

    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a
                             Recurring calendar component. Otherwise it
                             MUST NOT be present
    X-PROPERTY       0+

    ATTACH           0
    CATEGORIES       0
    CLASS            0
    COMMENT          0
    CONTACT          0
    CREATED          0
    DESCRIPTION      0
    DTSTART          0
    DUE              0
    DURATION         0
    EXDATE           0
    EXRULE           0
    GEO              0
    LAST-MODIFIED    0
    LOCATION         0
    ORGANIZER        0
    PERCENT-COMPLETE 0
    PRIORITY         0
    RDATE            0
    RELATED-TO       0
    REQUEST-STATUS   0
    RESOURCES        0
    RRULE            0
    SEQUENCE         0
    STATUS           0
    URL              0

X-COMPONENT          0+

VALARM               0
VEVENT               0
VFREEBUSY            0
VTIMEZONE            0

Top      Up      ToC       Page 48 
3.4.7 COUNTER

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

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

   The "Organizer" rejects the counter proposal by sending the
   "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
   counter proposal by sending all of the "Attendees" of the "VTODO"
   calendar component a "REQUEST" method rescheduling the "VTODO"
   calendar component. In the latter case, the "Organizer" SHOULD reset
   the individual "RSVP" property parameter values to TRUE on each
   "ATTENDEE" property; in order to force a response by the "Attendees".

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD               1      MUST be "COUNTER"
VTODO                1
    ATTENDEE         1+
    DTSTAMP          1
    ORGANIZER        1
    PRIORITY         1
    SUMMARY          1      Can be null
    UID              1

    ATTACH           0+
    CATEGORIES       0 or 1 This property MAY contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1 Can be null
    DTSTART          0 or 1
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1

Top      Up      ToC       Page 49 
    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    RDATE            0+
    RECURRENCE-ID    0 or 1 MUST only 3.5if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.
    RELATED-TO       0+
    REQUEST-STATUS   0+
    RESOURCES        0 or 1 This property MAY contain a list of values
    RRULE            0 or 1
    SEQUENCE         0 or 1 MUST echo the original SEQUENCE number.
                            MUST be present if non-zero. MAY be present
                            if zero.
    STATUS           0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
                            PROCESS/CANCELLED
    URL              0 or 1
    X-PROPERTY       0+


VALARM               0+
VTIMEZONE            0 or 1  MUST be present if any date/time refers to
                             a timezone
X-COMPONENT          0+

VEVENT               0
VFREEBUSY            0

3.4.8 DECLINECOUNTER

   The "DECLINECOUNTER" method in a "VTODO" calendar component is used
   by an "Organizer" of "VTODO" calendar component to reject a counter
   proposal offered by one of the "Attendees". The "Organizer" sends the
   message to the "Attendee" that sent the "COUNTER" method to the
   "Organizer".

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

Component/Property   Presence
-------------------  ---------------------------------------------
METHOD               1       MUST be "DECLINECOUNTER"

VTODO                1
    ATTENDEE         1+      MUST for all attendees
    DTSTAMP          1
    ORGANIZER        1
    SEQUENCE         1       MUST echo the original SEQUENCE number
    UID              1       MUST echo original UID

Top      Up      ToC       Page 50 
    ATTACH           0+
    CATEGORIES       0 or 1  This property may contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1
    DTSTART          0 or 1
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1
    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    PRIORITY         0 or 1
    RDATE            0+
    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a
                             recurring calendar component.  Otherwise
                             it MUST NOT be present.
    RELATED-TO       0+
    REQUEST-STATUS   0+
    RESOURCES        0 or 1  This property MAY contain a list of values
    RRULE            0+
    STATUS           0 or 1  MAY be one of COMPLETED/NEEDS ACTION/IN-
                             PROCESS
    URL              0 or 1
    X-PROPERTY       0+

VTIMEZONE            0+  MUST be present if any date/time refers to
                         a timezone
X-COMPONENT          0+

VALARM               0
VEVENT               0
VFREEBUSY            0



(page 50 continued on part 3)

Next RFC Part