© 2024 The Calendaring and Scheduling Consortium, Inc.
This document is not a CalConnect Standard. It is distributed for review and comment, and is subject to change without notice and may not be referred to as a Standard. Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the address below.
The Calendaring and Scheduling Consortium, Inc.
4390 Chaffin Lane
McKinleyville
California 95519
United States of America
www.calconnect.org
This specification defines updates to RFC5546 iTip which allow scheduling using the “PARTICIPANT” calendar components specified in RFC9073.
New properties are also defined for use within the “PARTICIPANT” calendar component.
The Calendaring and Scheduling Consortium (“CalConnect”) is a global non-profit organization with the aim to facilitate interoperability of collaborative technologies and tools through open standards.
CalConnect works closely with international and regional partners, of which the full list is available on our website ().
The procedures used to develop this document and those intended for its further maintenance are described in the CalConnect Directives.
In particular the different approval criteria needed for the different types of CalConnect documents should be noted. This document was drafted in accordance with the editorial rules of the CalConnect Directives.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CalConnect shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be provided in the Introduction.
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
This document was prepared by Technical Committee FREEBUSY.
This specification details how the “PARTICIPANT” calendar component introduced in
For “VEVENT”, “VTODO”, “VFREEBUSY”, and “VAVAILABILITY” calendar components; the “ORGANIZER” and “ATTENDEE” properties MUST be supplied as specified in
It MUST have a calendar address as defined in
It must have one or more scheduling roles defined in PARTICIPANT-TYPE
Exactly 1 PARTICIPANT MUST have the OWNER role
Scheduling with “PARTICIPANT” calendar components behaves exactly as with “ATTENDEE” and “ORGANIZER” properties. When iTip specifies the setting of “ATTENDEE” or “ORGANIZER” property parameters then the appropriate properties will be set within the “PARTICIPANT” calendar component.
This document provides a mechanism in iCalendar for consensus scheduling of events, using the “PARTICIPANT” calendar component.
This document also defines new properties for use within the “PARTICIPANT” calendar component.
For the purposes of this document, the following terms and definitions apply.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in
The notation used in this memo to (re-)define iCalendar elements is the ABNF notation of
Additionally, the following terms are used:
Represents an agent that takes part in scheduling or publishing. A participant may be a human, for example an attendee, or a resource, for example a conference room.
A component which takes part in
A component which takes part in
The “Owner” of a “Schedulable” component is equivalent to the “Organizer” in
REQUIRED
To specify whether the associated property is required in the current context.
This parameter is defined by the following notation:
This parameter MAY be specified on “REPLY-URL” property and, if the value is TRUE, indicates the “Owner” requires all replies to be made via the specified service rather than iTip replies.
REPLY-URL
This property may be used in scheduling messages to indicate additional reply methods, for example a web-service.
URI
Non-standard, required or iana parameters can be specified on this property.
This property MAY be specified once in any schedulable component.
When used in a scheduling message this property indicates an additional or required service that can be used to reply. Typically, this would be a web service of some form.
When the “REQUIRED” property parameter is absent then this property provides an alternative to standard iTip based scheduling.
When the “REQUIRED” property parameter is present then this property provides the only mechanism by which participants can reply. This allows the implementation of a web-based service without the ability to accept incoming mail for example.
This property is defined by the following notation:
This specification redefines the “PARTICIPANT-TYPE” property allowing it to take multiple values and extending those values to align with
PARTICIPANT-TYPE
This property is equivalent to the
The value type for this property is TEXT. The allowable values are defined below.
Non-standard or iana parameters can be specified on this property.
This property MUST be specified once within a “PARTICIPANT” calendar component.
This property defines the type of participation, that is the roles the participant takes.
It includes the values defined in
Note that the kind of participant, for example individual or group, is defined in the “KIND” property specified here.
Some of the roles are required for the participant to be a “schedulable” object. These are the roles that are shown below.
This property is defined by the following notation:
The values have the same meaning as defined in
Other roles defined here have no direct equivalent in
To map
| RFC5545 ROLE | PARTICIPANT-TYPE |
|---|---|
CHAIR |
CHAIR |
REQ-PARTICIPANT |
ATTENDEE |
OPT-PARTICIPANT |
OPTIONAL |
NON-PARTICIPANT |
INFORMATIONAL |
The following table shows those roles that MUST appear in the “PARTICIPANT-TYPE” property for group-scheduling. Additionally, the mapping for “PARTICIPANT-TYPE” property values to
| PARTICIPANT-TYPE | RFC5545 ROLE |
|---|---|
OWNER |
Create ORGANIZER |
ATTENDEE |
REQ-PARTICIPANT |
OPTIONAL |
OPT-PARTICIPANT |
INFORMATIONAL |
NON-PARTICIPANT |
CHAIR |
CHAIR |
Subsequent values have no |
|
CONTACT |
|
VOTER |
|
ACTIVE |
|
INACTIVE |
|
SPONSOR |
|
BOOKING-CONTACT |
|
EMERGENCY-CONTACT |
|
PUBLICITY-CONTACT |
|
PLANNER-CONTACT |
|
PERFORMER |
|
SPEAKER |
|
PARTICIPANT-TYPE=OWNER,… equivalent to the “ORGANIZER” property
PARTICIPANT-TYPE=ATTENDEE,… equivalent to the “ATTENDEE” property
The following properties are defined to be used within the “PARTICIPANT” calendar component during scheduling and take the place of “ATTENDEE” and “ORGANIZER” properties and parameters.
KIND
This is what kind of entity this participant is, if known.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified in a “PARTICIPANT” calendar component.
When used in a “PARTICIPANT” calendar component this property indicates the kind of entity, individual, group etc.
It takes the values shown below which are a redefinition of the “CUTYPE” property parameter values defined in
This property is defined by the following notation:
PARTICIPATION-STATUS
This property is used in the “PARTICIPANT” calendar component to indicate the participation status — if any.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified in a “PARTICIPANT” calendar component.
When used in a “PARTICIPANT” calendar component this property indicates what status, if any, the participant has.
It takes the same values as the “PARTSTAT” property parameter defined in
This property is defined by the following notation:
PARTICIPATION-DELEGATED-FROM
This property is used in the “PARTICIPANT” calendar component to indicate who has delegated their participation to this participant.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified in a “PARTICIPANT” calendar component 0 or more times.
This property specifies a calendar user that has delegated their participation in a group-scheduled component to the calendar user specified by the component.
This property is defined by the following notation:
PARTICIPATION-DELEGATED-TO
To specify the calendar user to whom the calendar user specified by the component has delegated participation.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified in a “PARTICIPANT” calendar component 0 or more times.
This property specifies the calendar user that has been delegated participation in a group-scheduled component by the calendar user specified by the component.
This property is defined by the following notation:
MEMBER-OF
To specify the group or list membership of the calendar user specified by the component.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified in a “PARTICIPANT” calendar component 0 or more times.
This property identifies the group or list membership for the calendar user specified by the component.
This property is defined by the following notation:
LANG
This is the language tag, as defined in
Non-standard or iana parameters can be specified on this property.
This property MAY be specified in any appropriate component.
This property is defined by the following notation:
EXPECT-REPLY
If true, the organizer is expecting the participant to notify them of their participation status.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified once in the “PARTICIPANT” calendar component.
This property is defined by the following notation:
SCHEDULING-AGENT
This is who is responsible for sending scheduling messages with this calendar object to the participant.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified once in the “PARTICIPANT” calendar component.
This property is defined by the following notation:
The value MUST be one of the following values from the registry defined in
The calendar server will send the scheduling messages.
The calendar client will send the scheduling messages.
No scheduling messages are to be sent to this participant.
SCHEDULING-FORCE-SEND
A client may set the property on a participant to true to request that the server send a scheduling message to the participant when it would not normally do so (e.g., if no significant change is made the object or the scheduleAgent is set to client). The property MUST NOT be stored in the object on the server or appear in a scheduling message.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified once in the “PARTICIPANT” calendar component.
This property is defined by the following notation:
This property MAY be specified in “PARTICIPANT” calendar components for which the “SCHEDULE-AGENT” property is set to the value “SERVER” or is absent. This property is used to force a server to send a scheduling message to a specific calendar user in situations where the server would not send a scheduling message otherwise (e.g., when no change that warrants the delivery of a new scheduling message was performed on the scheduling object resource). An “Owner” MAY specify this property for a PARTICIPANT with the value “REQUEST” to force a “REQUEST” scheduling message to be sent to the user.
Participants who are not the “Owner” MAY specify this property in the “Owner” PARTICIPANT with the value “REPLY” to force a “REPLY” scheduling message to be sent to the “Owner”.
Servers MUST NOT preserve this property in scheduling object resources, nor include it in any scheduling messages sent as the result of a scheduling operation.
Clients MUST NOT include this property in any scheduling messages that they themselves send.
Servers MUST set the “SCHEDULING-STATUS” property of the participant to 2.5 (i.e., “Success; unknown, non-standard property value ignored.”; see
SCHEDULING-STATUS
This is a list of status codes, returned from the processing of the most recent scheduling message sent to this participant. The status codes MUST be valid statcode values as defined in the ABNF in Section 3.8.8.3 of [RFC5545].
Servers MUST only add or change this property when they send a scheduling message to the participant. Clients SHOULD NOT change or remove this property if it was provided by the server. Clients MAY add, change, or remove the property for participants where the client is handling the scheduling.This property MUST NOT be included in scheduling messages.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified in any appropriate component.
This property is defined by the following notation:
SCHEDULING-DTSTAMP
This is the timestamp for the most recent response from this participant.
This is the updated property of the last response when using iTIP. It can be compared to the updated property in future responses to detect and discard older responses delivered out of order.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified in any appropriate component.
This property is defined by the following notation:
INVITED-BY
This is the calendar address of the participant who added this participant to the entity, if known.
Non-standard or iana parameters can be specified on this property.
This property MAY be specified in any appropriate component.
This property is defined by the following notation:
| Parameter | iCalendar PARTICIPANT |
|---|---|
CN |
NAME (defined in |
CUTYPE |
KIND (defined here) |
DELEGATED-FROM |
PARTICIPATION-DELEGATED-FROM |
DELEGATED-TO |
PARTICIPATION-DELEGATED-TO (defined here) |
DIR |
LINK |
LANGUAGE |
LANG (defined here) |
MEMBER |
MEMBER-OF (defined here) |
PARTSTAT |
PARTICIPATION-STATUS (defined here) |
ROLE |
PARTICIPATION-TYPE (updated here) |
RSVP |
EXPECT-REPLY (defined here) |
SENT-BY |
There should be no new security risks additional to those noted in
This document defines the following new iCalendar property parameters to be added to the registry defined in
| Property Parameter | Status | Reference |
|---|---|---|
REQUIRED |
Current |
This document defines the following new iCalendar properties to be added to the registry defined in
| Property | Status | Reference |
|---|---|---|
EXPECT-REPLY |
Current |
|
INVITED-BY |
Current |
|
KIND |
Current |
|
LANG |
Current |
|
MEMBER-OF |
Current |
|
PARTICIPATION-DELEGATED-FROM |
Current |
|
PARTICIPATION-DELEGATED-TO |
Current |
|
PARTICIPATION-STATUS |
Current |
|
REPLY-URL |
Current |
|
SCHEDULING-AGENT |
Current |
|
SCHEDULING-DTSTAMP |
Current |
|
SCHEDULING-FORCE-SEND |
Current |
|
SCHEDULING-STATUS |
Current |
This updates the participant types registry defined in
| Participant Type | Status | Reference |
|---|---|---|
OWNER |
Current |
RFC8984 |
ATTENDEE |
Current |
RFC8984 |
OPTIONAL |
Current |
RFC8984 |
INFORMATIONAL |
Current |
RFC8984 |
CHAIR |
Current |
RFC8984 |
The authors would like to thank the members of the Calendaring and Scheduling Consortium (CalConnect) for contributing their ideas and support.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK]
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the “calendar-access” feature of CalDAV. [STANDARDS-TRACK]
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]
This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.
The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]
This document, “iCalendar Message-Based Interoperability Protocol (iMIP)”, specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]
This specification updates RFC 5545 by introducing a number of new iCalendar properties and components that are of particular use for event publishers and in social networking.
This specification also defines a new “STRUCTURED-DATA” property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the calendar data.
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) “calendar-access” feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the “calendar-auto-schedule” feature of CalDAV. [STANDARDS-TRACK]
This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object.
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate.
This specification updates the iCalendar RELATED-TO property defined in RFC 5545 by adding new relation types and introduces new iCalendar properties (LINK, CONCEPT, and REFID) to allow better linking and grouping of iCalendar components and related data.