+----------------+--------------------------------------------------+ | Method | Description | +----------------+--------------------------------------------------+ | PUBLISH | Used to publish an iCalendar object to one or | | | more "Calendar Users". There is no | | | interactivity between the publisher and any | | | other "Calendar User". An example might include | | | a baseball team publishing its schedule to the | | | public. | | | | | REQUEST | Used to schedule an iCalendar object with other | | | "Calendar Users". Requests are interactive in | | | that they require the receiver to respond using | | | the reply methods. Meeting requests, busy-time | | | requests, and the assignment of tasks to other | | | "Calendar Users" are all examples. Requests are | | | also used by the Organizer to update the status | | | of an iCalendar object. | | | | | REPLY | A reply is used in response to a request to | | | convey Attendee status to the Organizer. | | | Replies are commonly used to respond to meeting | | | and task requests. | | | | | ADD | Add one or more new instances to an existing | | | recurring iCalendar object. | | | | | CANCEL | Cancel one or more instances of an existing | | | iCalendar object. | | | | | REFRESH | Used by an Attendee to request the latest | | | version of an iCalendar object. | | | | | COUNTER | Used by an Attendee to negotiate a change in an | | | iCalendar object. Examples include the request | | | to change a proposed event time or change the | | | due date for a task. | | | | | DECLINECOUNTER | Used by the Organizer to decline the proposed | | | counter proposal. | +----------------+--------------------------------------------------+
| Modifier and Type | Method and Description |
|---|---|
| public Calendar | Returns: a calendar object validated to conform to iTIP method ADDa calendar component to add component)Add a calendar component. |
| public Calendar | Returns: a calendar object validated to conform to iTIP method CANCELone or more component objects component)Cancel one or more calendar components. |
| public Calendar | |
| public Calendar | Returns: a calendar object validated to conform to iTIP method DECLINECOUNTERa counter to a request counter)Decline a counter to a request. |
| public Calendar | |
| public Calendar | Returns: a calendar object validated to conform to iTIP method PUBLISHone or more component objects component)Publish one or more calendar components. |
| public Calendar | Returns: a calendar object validated to conform to iTIP method REFRESHa calendar component to refresh component)Refresh a calendar component. |
| public Calendar | |
| public Calendar | Returns: a calendar object validated to conform to iTIP method REQUESTone or more component objects component)Request attendance to one or more calendar components. |
| add | back to summary |
|---|---|
| public Calendar add(T component) Add a calendar component.
| |
| cancel | back to summary |
|---|---|
| public Calendar cancel(T... component) Cancel one or more calendar components.
| |
| counter | back to summary |
|---|---|
| public Calendar counter(Calendar request) Counter a calendar request. | |
| declineCounter | back to summary |
|---|---|
| public Calendar declineCounter(Calendar counter) Decline a counter to a request. | |
| delegate | back to summary |
|---|---|
public Calendar delegate(Calendar request)
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.
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". Also, a new "ATTENDEE" property
for the "Delegate" MUST be included and must specify the calendar
user address set in the "DELEGATED-TO" parameter, as above.
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".
| |
| publish | back to summary |
|---|---|
| public Calendar publish(T... component) Publish one or more calendar components.
| |
| refresh | back to summary |
|---|---|
| public Calendar refresh(T component) Refresh a calendar component.
| |
| reply | back to summary |
|---|---|
| public Calendar reply(Calendar request) Reply to a calendar request. | |
| request | back to summary |
|---|---|
| public Calendar request(T... component) Request attendance to one or more calendar components.
| |