tech-invite   World Map     

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

RFC 2446

 
 
 

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

Part 3 of 4, p. 50 to 78
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 50 
3.5 Methods For VJOURNAL Components

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

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

Top      Up      ToC       Page 51 
   +================+==================================================+
   | Method         |  Description                                     |
   |================+==================================================|
   | PUBLISH        | Post a journal entry. Used primarily as a method |
   |                | of advertising the existence of a journal entry. |
   |                |                                                  |
   | ADD            | Add one or more instances to an existing journal |
   |                | entry.                                           |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | journal entry.                                   |
   +================+==================================================+

3.5.1 PUBLISH

   The "PUBLISH" method in a "VJOURNAL" calendar component has no
   associated response. It is simply a posting of an iCalendar object
   that may be added to a calendar. It MUST have an "Organizer". It MUST
   NOT have "Attendees". The expected usage is for encapsulating an

   arbitrary journal entry as an iCalendar object. The "Organizer" MAY
   subsequently update (with another "PUBLISH" method) or cancel (with a
   "CANCEL" method) a previously published journal entry.

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD               1       MUST be "PUBLISH"
VJOURNAL             1+
    DESCRIPTION      1       Can be null.
    DTSTAMP          1
    DTSTART          1
    ORGANIZER        1
    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
    EXDATE           0+
    EXRULE           0+
    LAST-MODIFIED    0 or 1
    RDATE            0+
    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a

Top      Up      ToC       Page 52 
                             recurring calendar component.  Otherwise
                             it MUST NOT be present.
    RELATED-TO       0+
    RRULE            0+
    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 DRAFT/FINAL/CANCELLED
    SUMMARY          0 or 1  Can be null
    URL              0 or 1
    X-PROPERTY       0+

    ATTENDEE         0

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

VEVENT               0
VFREEBUSY            0
VTODO                0

3.5.2 ADD

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

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

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

Component/Property  Presence
------------------- ----------------------------------------------
METHOD               1      MUST be "ADD"
VJOURNAL             1
    DESCRIPTION      1      Can be null.
    DTSTAMP          1
    DTSTART          1
    ORGANIZER        1
    SEQUENCE         1      MUST be greater than 0
    UID              1      MUST match that of the original journal

    ATTACH           0+

Top      Up      ToC       Page 53 
    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
    EXDATE           0+
    EXRULE           0+
    LAST-MODIFIED    0 or 1
    RDATE            0+
    RELATED-TO       0+
    RRULE            0+
    STATUS           0 or 1  MAY be one of DRAFT/FINAL/CANCELLED
    SUMMARY          0 or 1  Can be null
    URL              0 or 1
    X-PROPERTY       0+

    ATTENDEE         0
    RECURRENCE-ID    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
VTODO                0

3.5.3 CANCEL

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

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

Top      Up      ToC       Page 54 
   (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 "VJOURNAL" 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"
VJOURNAL             1+      All MUST have the same UID
    DTSTAMP          1
    ORGANIZER        1
    SEQUENCE         1
    UID              1       MUST be the UID of the original REQUEST

    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
    DTSTART          0 or 1
    EXDATE           0+
    EXRULE           0+
    LAST-MODIFIED    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+
    RRULE            0+
    STATUS           0 or 1  MAY be present, must be "CANCELLED" if
                             present
    SUMMARY          0 or 1
    URL              0 or 1
    X-PROPERTY       0+

Top      Up      ToC       Page 55 
    REQUEST-STATUS   0

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

3.6 Status Replies

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

|==============+============================+=========================|
| Short Return | Longer Return Status       | Offending Data          |
| Status Code  | Description                |                         |
|==============+============================+=========================|
| 2.0          | Success.                   | None.                   |
|==============+============================+=========================|
| 2.1          | Success but fallback taken | Property name and value |
|              | on one or more property    | MAY be specified.       |
|              | values.                    |                         |
|==============+============================+=========================|
| 2.2          | Success, invalid property  | Property name MAY be    |
|              | ignored.                   | specified.              |
|==============+============================+=========================|
| 2.3          | Success, invalid property  | Property parameter name |
|              | parameter ignored.         | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 2.4          | Success, unknown non-      | Non-standard property   |
|              | standard property ignored. | name MAY be specified.  |
|==============+============================+=========================|
| 2.5          | Success, unknown non       | Property and non-       |
|              | standard property value    | standard value MAY be   |
|              | ignored.                   | specified.              |
|==============+============================+=========================|
| 2.6          | Success, invalid calendar  | Calendar component      |
|              | component ignored.         | sentinel (e.g., BEGIN:  |
|              |                            | ALARM) MAY be           |
|              |                            | specified.              |
|==============+============================+=========================|
| 2.7          | Success, request forwarded | Original and forwarded  |
|              | to Calendar User.          | caluser addresses MAY   |
|              |                            | be specified.           |
|==============+============================+=========================|
| 2.8          | Success, repeating event   | RRULE or RDATE property |

Top      Up      ToC       Page 56 
|              | ignored. Scheduled as a    | name and value MAY be   |
|              | single component.          | specified.              |
|==============+============================+=========================|
| 2.9          | Success, truncated end date| DTEND property value    |
|              | time to date boundary.     | MAY be specified.       |
|==============+============================+=========================|
| 2.10         | Success, repeating VTODO   | RRULE or RDATE property |
|              | ignored. Scheduled as a    | name and value MAY be   |
|              | single VTODO.              | specified.              |
|==============+============================+=========================|
| 2.11         | Success, unbounded RRULE   | RRULE property name and |
|              | clipped at some finite     | value MAY be specified. |
|              | number of instances        | Number of instances MAY |
|              |                            | also be specified.      |
|==============+============================+=========================|
| 3.0          | Invalid property name.     | Property name MAY be    |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.1          | Invalid property value.    | Property name and value |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 3.2          | Invalid property parameter.| Property parameter name |
|              |                            | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.3          | Invalid property parameter | Property parameter name |
|              | value.                     | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.4          | Invalid calendar component | Calendar component      |
|              | sequence.                  | sentinel MAY be         |
|              |                            | specified (e.g., BEGIN: |
|              |                            | VTIMEZONE).             |
|==============+============================+=========================|
| 3.5          | Invalid date or time.      | Date/time value(s) MAY  |
|              |                            | be specified.           |
|==============+============================+=========================|
| 3.6          | Invalid rule.              | Rule value MAY be       |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.7          | Invalid Calendar User.     | Attendee property value |
|              |                            |MAY be specified.        |
|==============+============================+=========================|
| 3.8          | No authority.              | METHOD and Attendee     |
|              |                            | property values MAY be  |
|              |                            | specified.              |
|==============+============================+=========================|

Top      Up      ToC       Page 57 
| 3.9          | Unsupported version.       | VERSION property name   |
|              |                            | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.10         | Request entity too large.  | None.                   |
|==============+============================+=========================|
| 3.11         | Required component or      | Component or property   |
|              | property missing.          | name MAY be specified.  |
|==============+============================+=========================|
| 3.12         | Unknown component or       | Component or property   |
|              | property found             | name MAY be specified   |
|==============+============================+=========================|
| 3.13         | Unsupported component or   | Component or property   |
|              | property found             | name MAY be specified   |
|==============+============================+=========================|
| 3.14         | Unsupported capability     | Method or action MAY    |
|              |                            | be specified            |
|==============+============================+=========================|
| 4.0          | Event conflict. Date/time  | DTSTART and DTEND       |
|              | is busy.                   | property name and values|
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.0          | Request MAY supported.     | Method property value   |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.1          | Service unavailable.       | ATTENDEE property value |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.2          | Invalid calendar service.  | ATTENDEE property value |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.3          | No scheduling support for  | ATTENDEE property value |
|              | user.                      | MAY be specified.       |
|==============+============================+=========================|

3.7 Implementation Considerations

3.7.1 Working With Recurrence Instances

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

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

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

   "Organizer" initiated actions:

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

   "Attendee" initiated actions:

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

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

3.7.2 Attendee Property Considerations

   The "ORGANIZER" property is required on published events, to-dos, and
   journal entries for two reasons. First, only the "Organizer" is
   allowed to update and redistribute an event or to-do component. It
   follows that the "ORGANIZER" property MUST be present in the event,
   to-do, or journal entry component so that the CUA has a basis for

Top      Up      ToC       Page 59 
   authorizing an update.  Second, it is prudent to provide a point of
   contact for anyone who receives a published component in case of
   problems.

   There are valid [RFC-822] addresses that represent groups. Sending
   email to such an address results in mail being sent to multiple
   recipients.  Such an address may be used as the value of an
   "ATTENDEE" property.  Thus, it is possible that the recipient of a
   "REQUEST" does not appear explicitly in the list.

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

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

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

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

3.7.3 X-Tokens

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

4 Examples

4.1 Published Event Examples

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

Top      Up      ToC       Page 60 
   The table below illustrates the sequence of events between the
   publisher and the consumers of a published event.

   +-------------------------------------------------------------------+
   | Action                          |  "Organizer"                    |
   +---------------------------------+---------------------------------+
   | Publish an event                | "A" sends or posts a PUBLISH    |
   |                                 | message                         |
   +---------------------------------+---------------------------------+
   | "B" reads a published event     |                                 |
   +---------------------------------+---------------------------------+
   | Publish an updated event        | "A" sends or posts a PUBLISH    |
   |                                 | message                         |
   +---------------------------------+---------------------------------+
   | "B" reads the updated event     |                                 |
   +---------------------------------+---------------------------------+
   | Cancel a published event        | "A" sends or posts a CANCEL     |
   |                                 | message                         |
   +---------------------------------+---------------------------------+
   | "B" reads the canceled event    |                                 |
   |  publication                    |                                 |
   +---------------------------------+---------------------------------+

4.1.1 A Minimal Published Event

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

   BEGIN:VCALENDAR
   METHOD:PUBLISH
   PRODID:-//ACME/DesktopCalendar//EN
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   DTSTART:19970701T200000Z
   DTSTAMP:19970611T190000Z
   SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
   UID:0981234-1234234-23@example.com
   END:VEVENT
   END:VCALENDAR

4.1.2 Changing A Published Event

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

Top      Up      ToC       Page 61 
   BEGIN:VCALENDAR
   METHOD:PUBLISH
   VERSION:2.0
   PRODID:-//ACME/DesktopCalendar//EN
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   DTSTAMP:19970612T190000Z
   DTSTART:19970701T210000Z
   DTEND:19970701T230000Z
   SEQUENCE:1
   UID:0981234-1234234-23@example.com
   SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
   END:VEVENT
   END:VCALENDAR

   The "UID" property is used by the client to identify the event. The
   "SEQUENCE" property indicates that this is a change to the event. The
   event with a matching UID and sequence number 0 is superseded by this
   event.

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

4.1.3 Canceling A Published Event

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

   BEGIN:VCALENDAR
   METHOD:CANCEL
   VERSION:2.0
   PRODID:-//ACME/DesktopCalendar//EN
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   COMMENT:DUKES forfeit the game
   SEQUENCE:2
   UID:0981234-1234234-23@example.com
   DTSTAMP:19970613T190000Z
   END:VEVENT
   END:VCALENDAR

Top      Up      ToC       Page 62 
4.1.4 A Rich Published Event

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:PUBLISH
   SCALE:GREGORIAN
   VERSION:2.0
   BEGIN:VTIMEZONE
   TZID:America-Chicago
   TZURL:http://zones.stds_r_us.net/tz/America-Chicago
   BEGIN:STANDARD
   DTSTART:19671029T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0600
   TZNAME:CST
   END:STANDARD
   BEGIN:DAYLIGHT
   DTSTART:19870405T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZOFFSETFROM:-0600
   TZOFFSETTO:-0500
   TZNAME:CDT
   END:DAYLIGHT
   END:VTIMEZONE
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   ATTACH:http://www.dukes.com/
   CATEGORIES:SPORTS EVENT,ENTERTAINMENT
   CLASS:PRIVATE
   DESCRIPTION:MIDWAY STADIUM\n
    Big time game. MUST see.\n
    Expected duration:2 hours\n
   DTEND;TZID=America-Chicago:19970701T180000
   DTSTART;TZID=America-Chicago:19970702T160000
   DTSTAMP:19970614T190000Z
   STATUS:CONFIRMED
   LOCATION;VALUE=URI:http://www.midwaystadium.com/
   PRIORITY:2
   RESOURCES:SCOREBOARD
   SEQUENCE:3
   SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
   UID:0981234-1234234-23@example.com
   RELATED-TO:0981234-1234234-14@example.com
   BEGIN:VALARM

Top      Up      ToC       Page 63 
   TRIGGER:-PT2H
   ACTION:DISPLAY
   DESCRIPTION:You should be leaving for the game now.
   END:VALARM
   BEGIN:VALARM
   TRIGGER:-PT30M
   ACTION:AUDIO
   END:VALARM
   END:VEVENT
   END:VCALENDAR

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

4.1.5 Anniversaries or Events attached to entire days

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:PUBLISH
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   DTSTAMP:19970614T190000Z
   UID:0981234-1234234-23@example.com
   DTSTART;VALUE=DATE:19970714
   RRULE:FREQ=YEARLY;INTERVAL=1
   SUMMARY: Bastille Day
   END:VEVENT
   END:VCALENDAR

4.2 Group Event Examples

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

Top      Up      ToC       Page 64 
+---------------------------------------------------------------------+
| Action             |  "Organizer"        | Attendee                 |
+---------------------------------------------------------------------+
| Initiate a meeting | "A" sends a REQUEST |                          |
| request            | message to "B", "C",|                          |
|                    | and "D"             |                          |
+---------------------------------------------------------------------+
| Accept the meeting |                     | "B" sends a REPLY        |
| request            |                     | message to "A" with its  |
|                    |                     | ATTENDEE "partstat" para-|
|                    |                     | set to "accepted"        |
+---------------------------------------------------------------------+
| Decline the meeting|                     | "C" sends a REPLY        |
| request            |                     | message to "A" with its  |
|                    |                     | ATTENDEE "partstat" para-|
|                    |                     | set to "declined"        |
+---------------------------------------------------------------------+
| Tentatively accept |                     | "D" sends a REPLY        |
| the meeting request|                     | message to "A" with its  |
|                    |                     | ATTENDEE "partstat" para-|
|                    |                     | set to "tentative"       |
+---------------------------------------------------------------------+
| Confirm meeting    | "A" sends a REQUEST |                          |
| status with        | message to "B" and  |                          |
| attendees          | "D" with updated    |                          |
|                    | information.        |                          |
+---------------------------------------------------------------------+

4.2.1 A Group Event Request

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com

Top      Up      ToC       Page 65 
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
   ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com
   ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T200000Z
   DTEND:19970701T2000000Z
   SUMMARY:Conference
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.2.2 Reply To A Group Event Request

   Attendee "B" accepts the meeting.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VEVENT
   ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com
   ORGANIZER:MAILTO:A@example.com
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   REQUEST-STATUS:2.0;Success
   DTSTAMP:19970612T190000Z
   END:VEVENT
   END:VCALENDAR

   "B" could have declined the meeting or indicated tentative acceptance
   by setting the "ATTENDEE" "partstat" parameter to "declined" or
   "tentative", respectively. Also, "REQUEST-STATUS" is not required in
   successful transactions.

4.2.3 Update An Event

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com

Top      Up      ToC       Page 66 
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
   ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
    CUTYPE=ROOM:Mailto:Conf@example.com
   ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
   DTSTART:19970701T180000Z
   DTEND:19970701T190000Z
   SUMMARY:Phone Conference
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:1
   DTSTAMP:19970613T190000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.2.4 Countering an Event Proposal

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

   "A" sends the following "REQUEST":

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
   DTSTART:19970701T190000Z
   DTEND:19970701T200000Z
   SUMMARY:Discuss the Merits of the election results
   LOCATION:Green Conference Room
   UID:calsrv.example.com-873970198738777a@example.com
   SEQUENCE:0
   DTSTAMP:19970611T190000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   "B" sends "COUNTER" to "A", requesting changes to time and place. "B"
   uses the "COMMENT" property to communicate a rationale for the
   change.  Note that the "SEQUENCE" property is NOT incremented on a
   "COUNTER".

Top      Up      ToC       Page 67 
   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:COUNTER
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
   DTSTART:19970701T160000Z
   DTEND:19970701T190000Z
   DTSTAMP:19970612T190000Z
   SUMMARY:Discuss the Merits of the election results
   LOCATION:Green Conference Room
   COMMENT:This time works much better and I think the big conference
     room is too big
   UID:calsrv.example.com-873970198738777a@example.com
   SEQUENCE:0
   DTSTAMP:19970611T190000Z
   END:VEVENT
   END:VCALENDAR

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
   DTSTAMP:19970613T190000Z
   DTSTART:19970701T160000Z
   DTEND:19970701T190000Z
   SUMMARY:Discuss the Merits of the election results - changed to
     meet B's schedule
   LOCATION:Green Conference Room
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:1
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

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

Top      Up      ToC       Page 68 
   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:DECLINECOUNTER
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   COMMENT:Sorry, I cannot change this meeting time
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   DTSTAMP:19970614T190000Z
   END:VEVENT
   END:VCALENDAR

4.2.5 Delegating an Event

   When delegating an event request to another "Calendar User", the
   "Delegator" must both update the "Organizer" with a "REPLY" and send
   a request to the "Delegate". There is currently no protocol
   limitation to delegation depth. It is possible for the original

   delegate to delegate the meeting to someone else, and so on. When a
   request is delegated from one CUA to another there are a number of
   responsibilities required of the "Delegator". The "Delegator" MUST:

     .  Send a "REPLY" to the "Organizer" with the following updates:
     .  The "Delegator's" "ATTENDEE" property "partstat" parameter set
        to "delegated" and the "delegated-to" parameter is set to the
        address of the "Delegate"
     .  Add an additional "ATTENDEE" property for the "Delegate" with
        the "delegated-from" property parameter set to the "Delegator"
     .  Indicate whether they want to continue to receive updates when
        the "Organizer" sends out updated versions of the event.
        Setting the "rsvp" property parameter to "TRUE" will cause the
        updates to be sent, setting it to "FALSE" causes no further
        updates to be sent. Note that in either case, if the "Delegate"
        declines the invitation the "Delegator" will be notified.
     .  The "Delegator" MUST also send a copy of the original "REQUEST"
        method to the "Delegate".

   It is not required that the "Delegate" include the "Delegator" in
   their "REPLY" method. However, it is strongly advised since this will
   inform the "Delegator" whether the "Delegate" plans to attend the
   meeting.  [Editors note:  How so?] If the "Delegate" declines the
   meeting, the "Delegator" may elect to delegate the "REQUEST" to
   another CUA. The process is the same.

Top      Up      ToC       Page 69 
+---------------------------------------------------------------------+
| Action             |  "Organizer"        | Attendee                 |
+---------------------------------------------------------------------+
| Initiate a meeting | "A" sends a REQUEST |                          |
| request            | message to "B" and  |                          |
|                    | "C"                 |                          |
+---------------------------------------------------------------------+
| Delegate:          |                     | "C" sends a REPLY to "A" |
| "C" delegates to   |                     | with the ATTENDEE.       |
| "E"                |                     | "partstat" parameter set |
|                    |                     | to "delegated" and with a|
|                    |                     | new "ATTENDEE" property  |
|                    |                     | for "E". "E's" ATTENDEE  |
|                    |                     | "delegated-from" param   |
|                    |                     | is set to "C". "C's"     |
|                    |                     | ATTENDEE "delegated-to"  |
|                    |                     | param is set to "E".     |
|                    |                     | "C" sends REQUEST message|
|                    |                     | to "E" with the original |
|                    |                     | meeting request          |
|                    |                     | information. The         |
|                    |                     |  "partstat" property     |
|                    |                     | parameter for "C" is set |
|                    |                     | to "delegated" and the   |
|                    |                     |  "delegated-to"          |
|                    |                     | parameter is set to      |
|                    |                     | the address of "E". An   |
|                    |                     | "ATTENDEE" property is   |
|                    |                     | added for "E" and the    |
|                    |                     | "delegated-from"         |
|                    |                     | parameter is set to      |
|                    |                     | the address of "C".      |
+---------------------------------------------------------------------+
| Confirm meeting    |                     | "E" sends REPLY message  |
| attendance         |                     | to "A" and optionally "C"|
|                    |                     | with its "partstat"      |
|                    |                     | property parameter set   |
|                    |                     | to "ACCEPTED"            |
+---------------------------------------------------------------------+
| Optional:          | "A" sends REQUEST   |                          |
| Redistribute       | message to "B", "C" |                          |
| meeting to         | and "E".            |                          |
| attendees          |                     |                          |
+---------------------------------------------------------------------+

Top      Up      ToC       Page 70 
   "C" responds to the "Organizer".

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:MAILTO:A@Example.com
   ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
    TO="Mailto:E@example.com":Mailto:C@example.com
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   REQUEST-STATUS:2.0;Success
   DTSTAMP:19970611T190000Z
   END:VEVENT
   END:VCALENDAR

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
    TO="Mailto:E@example.com":Mailto:C@example.com
   ATTENDEE;RSVP=TRUE;
    DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
   DTSTART:19970701T180000Z
   DTEND:19970701T200000Z
   SUMMARY:Phone Conference
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   STATUS:CONFIRMED
   DTSTAMP:19970611T190000Z
   END:VEVENT
   END:VCALENDAR

4.2.6 Delegate Accepts the Meeting

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0

Top      Up      ToC       Page 71 
   BEGIN:VEVENT
   ORGANIZER:MAILTO:A@Example.com
   ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
    FROM="Mailto:C@example.com":Mailto:E@example.com
   ATTENDEE;PARTSTAT=DELEGATED;
    DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   REQUEST-STATUS:2.0;Success
   DTSTAMP:19970614T190000Z
   END:VEVENT
   END:VCALENDAR

4.2.7 Delegate Declines the Meeting

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

   Response from "E" to "A" and "C". Note the use of the "COMMENT"
   property "E" uses to indicate why the delegation was declined.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:MAILTO:A@Example.com
   ATTENDEE;PARTSTAT=DELEGATED;
    DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
   ATTENDEE;PARTSTAT=DECLINED;
    DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
   COMMENT:Sorry, I will be out of town at that time.
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   REQUEST-STATUS:2.0;Success
   DTSTAMP:19970614T190000Z
   END:VEVENT
   END:VCALENDAR

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

Top      Up      ToC       Page 72 
   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:MAILTO:A@Example.com
   ATTENDEE;PARTSTAT=DECLINED;
    DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
   ATTENDEE;RSVP=TRUE:Mailto:C@example.com
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   SUMMARY:Phone Conference
   DTSTART:19970701T180000Z
   DTEND:19970701T200000Z
   DTSTAMP:19970614T200000Z
   COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR
    INVITATION
   END:VEVENT
   END:VCALENDAR

4.2.8 Forwarding an Event Request

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

4.2.9 Cancel A Group Event

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

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

Top      Up      ToC       Page 73 
   +--------------------------------------------------------------------+
   | Action             |  "Organizer"        | "Attendee"              |
   +--------------------------------------------------------------------+
   | Initiate a meeting | "A" sends a REQUEST |                         |
   | request            | message to "B", "C",|                         |
   |                    | and "D"             |                         |
   +--------------------------------------------------------------------+
   | Decline the meeting|                     | "B" sends a "REPLY"     |
   | request            |                     | message to "A" with its |
   |                    |                     | "partstat" para-         |
   |                    |                     | set to "declined".      |
   +--------------------------------------------------------------------+
   | Cancel the meeting | "A" sends a CANCEL  |                         |
   |                    | message to "B", "C" |                         |
   |                    | and "D"             |                         |
   +--------------------------------------------------------------------+

   The example shows how "A" cancels the event.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:CANCEL
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
   COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:1
   STATUS:CANCELLED
   DTSTAMP:19970613T190000Z
   END:VEVENT
   END:VCALENDAR

Top      Up      ToC       Page 74 
4.2.10 Removing Attendees

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

   +--------------------------------------------------------------------+
   | Action             |  "Organizer"        | "Attendee"              |
   +--------------------------------------------------------------------+
   | Remove an "B"      | "A" sends a CANCEL  |                         |
   | as an "Attendee"   | message to "B"      |                         |
   +--------------------------------------------------------------------+
   | Update the master  | "A" sends the       |                         |
   | copy of the event  | updated event to    |                         |
   |                    | the remaining       |                         |
   |                    | "Attendees"         |                         |
   +--------------------------------------------------------------------+

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:CANCEL
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE:mailto:B@example.com
   COMMENT:You're off the hook for this meeting
   UID:calsrv.example.com-873970198738777@example.com
   DTSTAMP:19970613T193000Z
   SEQUENCE:1
   END:VEVENT
   END:VCALENDAR

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com

Top      Up      ToC       Page 75 
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
   ATTENDEE;TYPE=ROOM:CR_Big@example.com
   ATTENDEE;ROLE=NON-PARTICIPANT;
    RSVP=FALSE:Mailto:E@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T200000Z
   DTEND:19970701T203000Z
   SUMMARY:Phone Conference
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:2
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.2.11 Replacing the Organizer

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

   When the "Organizer" is replaced, the "SEQUENCE" property value MUST
   be incremented.

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:B@example.com
   ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T200000Z
   DTEND:19970701T203000Z
   RRULE:FREQ=WEEKLY
   SUMMARY:Phone Conference
   UID:123456@example.com

Top      Up      ToC       Page 76 
   SEQUENCE:1
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.3 Busy Time Examples

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

   Individual "A" publishes busy time for one week.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   VERSION:2.0
   METHOD:PUBLISH
   BEGIN:VFREEBUSY
   DTSTAMP:19980101T124100Z
   ORGANIZER:MAILTO:A@Example.com
   DTSTART:19980101T124200Z
   DTEND:19980107T124200Z
   FREEBUSY:19980101T180000Z/19980101T190000Z
   FREEBUSY:19980103T020000Z/19980103T050000Z
   FREEBUSY:19980107T020000Z/19980107T050000Z
   FREEBUSY:19980113T000000Z/19980113T010000Z
   FREEBUSY:19980115T190000Z/19980115T200000Z
   FREEBUSY:19980115T220000Z/19980115T230000Z
   FREEBUSY:19980116T013000Z/19980116T043000Z
   END:VFREEBUSY
   END:VCALENDAR

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

Top      Up      ToC       Page 77 
+--------------------------------------------------------------------+
| Action             |  "Organizer"        | Attendee                |
+--------------------------------------------------------------------+
| Initiate a busy    | "A" sends "REQUEST" |                         |
| time request       | message to "B" and  |                         |
|                    | and "C"             |                         |
+--------------------------------------------------------------------+
| Reply to the "BUSY"|                     | "B" sends a "REPLY"     |
| request with "BUSY"|                     | message to "A" with     |
| time data          |                     | busy time data          |
+--------------------------------------------------------------------+

4.3.1 Request Busy Time

   "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VFREEBUSY
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   ATTENDEE:Mailto:C@example.com
   DTSTAMP:19970613T190000Z
   DTSTART:19970701T080000Z
   DTEND:19970701T200000
   UID:calsrv.example.com-873970198738777@example.com
   END:VFREEBUSY
   END:VCALENDAR

4.3.2 Reply To A Busy Time Request

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

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VFREEBUSY
   ORGANIZER:MAILTO:A@example.com
   ATTENDEE:Mailto:B@example.com
   DTSTART:19970701T080000Z
   DTEND:19970701T200000Z
   UID:calsrv.example.com-873970198738777@example.com
   FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M

Top      Up      ToC       Page 78 
   DTSTAMP:19970613T190030Z
   END:VFREEBUSY
   END:VCALENDAR

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



(page 78 continued on part 4)

Next RFC Part