Foreword
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 ( https://www.calconnect.org/about/liaisons-and-relationships).
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.
Introduction
This specification details how the “PARTICIPANT” calendar component introduced in IETF RFC 9073 may be used for scheduling in place of IETF RFC 5545 “ATTENDEE” and “ORGANIZER” properties. Additionally, some properties are defined in this specification to be used within the “PARTICIPANT” calendar component.
For “VEVENT”, “VTODO”, “VFREEBUSY”, and “VAVAILABILITY” calendar components; the “ORGANIZER” and “ATTENDEE” properties MUST be supplied as specified in IETF RFC 5546. For new components such as the “VPOLL” calendar component, defined elsewhere, only “PARTICIPANT” calendar components MUST be used. A participant object that takes part in group scheduling MUST have the following characteristics:
It MUST have a calendar address as defined in IETF RFC 9073, Section 6.4.
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.
Calendaring and scheduling — iTip using PARTICIPANT only
1. Scope
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.
2. Normative references
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.
IETF RFC 2518, Y. GOLAND, E. WHITEHEAD, A. FAIZI, S. CARTER and D. JENSEN. HTTP Extensions for Distributed Authoring — WEBDAV. In: RFC. 1999. RFC Publisher. https://www.rfc-editor.org/info/rfc2518. [viewed: November 7, 2024].
IETF RFC 3986, T. BERNERS-LEE, R. FIELDING and L. MASINTER. Uniform Resource Identifier (URI): Generic Syntax. In: STD. 2005. RFC Publisher. https://www.rfc-editor.org/info/rfc3986. [viewed: November 7, 2024].
IETF RFC 4791, C. DABOO, B. DESRUISSEAUX and L. DUSSEAULT. Calendaring Extensions to WebDAV (CalDAV). In: RFC. 2007. RFC Publisher. https://www.rfc-editor.org/info/rfc4791. [viewed: November 7, 2024].
IETF RFC 5234, P. OVERELL. Augmented BNF for Syntax Specifications: ABNF. In: STD. 2008. RFC Publisher. https://www.rfc-editor.org/info/rfc5234. [viewed: November 7, 2024].
IETF RFC 5545, B. DESRUISSEAUX (ed.). Internet Calendaring and Scheduling Core Object Specification (iCalendar). In: RFC. 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5545. [viewed: November 7, 2024].
IETF RFC 5546, C. DABOO (ed.). iCalendar Transport-Independent Interoperability Protocol (iTIP). In: RFC. 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5546. [viewed: November 7, 2024].
IETF RFC 6047, A. MELNIKOV (ed.). iCalendar Message-Based Interoperability Protocol (iMIP). In: RFC. 2010. RFC Publisher. https://www.rfc-editor.org/info/rfc6047. [viewed: November 7, 2024].
IETF RFC 9073, M. DOUGLASS. Event Publishing Extensions to iCalendar. In: RFC. 2021. RFC Publisher. https://www.rfc-editor.org/info/rfc9073. [viewed: November 7, 2024].
3. Terms and definitions
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 IETF RFC 2119.
The notation used in this memo to (re-)define iCalendar elements is the ABNF notation of IETF RFC 5234 as used by IETF RFC 5545. Any syntax elements shown below that are not explicitly defined in this specification come from iCalendar IETF RFC 5545.
Additionally, the following terms are used:
3.1. participant
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.
3.2. publishable
A component which takes part in IETF RFC 5546 publishing operations.
3.3. schedulable
A component which takes part in IETF RFC 5546 scheduling operations.
3.4. owner
The “Owner” of a “Schedulable” component is equivalent to the “Organizer” in IETF RFC 5546. As such, there may be only one “Owner” though future specifications may relax or extend that constraint. The “Owner” is indicated by a role of “OWNER”.
4. iCalendar Extensions
4.1. New Property Parameters
4.1.1. Required
Parameter name
REQUIRED
Purpose
To specify whether the associated property is required in the current context.
Format Definition
This parameter is defined by the following notation:
requiredparam = "REQUIRED" "=" ("TRUE" / "FALSE")
; Default is FALSEFigure 1
Description
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.
4.2. New Properties
4.2.1. Reply-URL
Property name
REPLY-URL
Purpose
This property may be used in scheduling messages to indicate additional reply methods, for example a web-service.
Value type
URI
Property Parameters
Non-standard, required or iana parameters can be specified on this property.
Conformance
This property MAY be specified once in any schedulable component.
Description
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.
Format Definition
This property is defined by the following notation:
reply-url = "REPLY-URL" reply-urlparams ":" uri CRLF
reply-urlparams = *(
(";" requiredparam) /
(";" other-param)
)
Figure 2
4.3. Redefined participation type
This specification redefines the “PARTICIPANT-TYPE” property allowing it to take multiple values and extending those values to align with IETF RFC 8984 roles. There are also changes to the description to clarify its use defining the roles that participant takes.
Property name
PARTICIPANT-TYPE
Purpose
This property is equivalent to the IETF RFC 5545 “ROLE” property parameter but includes more values to align with IETF RFC 8984.
Value Type
The value type for this property is TEXT. The allowable values are defined below.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MUST be specified once within a “PARTICIPANT” calendar component.
Description
This property defines the type of participation, that is the roles the participant takes.
It includes the values defined in IETF RFC 8984.
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.
Format Definition
This property is defined by the following notation:
participanttype = "PARTICIPANT-TYPE" partvalueparam ":"
partvalue
*("," partvalue) CRLF
partvalue = ("OWNER"
/ "ATTENDEE"
/ "OPTIONAL"
/ "INFORMATIONAL"
/ "CHAIR"
/ "ACTIVE"
/ "INACTIVE"
/ "SPONSOR"
/ "CONTACT"
/ "BOOKING-CONTACT"
/ "EMERGENCY-CONTACT"
/ "PUBLICITY-CONTACT"
/ "PLANNER-CONTACT"
/ "PERFORMER"
/ "SPEAKER"
/ iana-token) ; Other IANA-registered
; values
partvalueparam = *(";" other-param)
Figure 3
The values have the same meaning as defined in IETF RFC 8984 and IETF RFC 9073.
Other roles defined here have no direct equivalent in IETF RFC 5545
To map IETF RFC 5545 “ROLE” property parameter values to “PARTICIPANT-TYPE” property values use the following.
Table 1
| 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 IETF RFC 5545 values are shown.
Table 2
| PARTICIPANT-TYPE | RFC5545 ROLE |
|---|---|
OWNER | Create ORGANIZER |
ATTENDEE | REQ-PARTICIPANT |
OPTIONAL | OPT-PARTICIPANT |
INFORMATIONAL | NON-PARTICIPANT |
CHAIR | CHAIR |
Subsequent values have no IETF RFC 5545 equivalent | |
CONTACT | |
VOTER | |
ACTIVE | |
INACTIVE | |
SPONSOR | |
BOOKING-CONTACT | |
EMERGENCY-CONTACT | |
PUBLICITY-CONTACT | |
PLANNER-CONTACT | |
PERFORMER | |
SPEAKER | |
Examples
PARTICIPANT-TYPE=OWNER,… equivalent to the “ORGANIZER” property
PARTICIPANT-TYPE=ATTENDEE,… equivalent to the “ATTENDEE” property
5. New Participant Properties for iTip
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.
5.1. Kind
Property name
KIND
Purpose
This is what kind of entity this participant is, if known.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified in a “PARTICIPANT” calendar component.
Description
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 IETF RFC 5545 and aligned with IETF RFC 8984 .
Format Definition
This property is defined by the following notation:
kind = "KIND" kindparams ":"
"INDIVIDUAL" ; An individual
/ "GROUP" ; A group of individuals
/ "RESOURCE" ; A physical resource
/ "LOCATION" ; A location resource e.g a room
/ iana-token CRLF
kindparams = *(";" other-param)
Figure 4
5.2. Participation-status
Property name
PARTICIPATION-STATUS
Purpose
This property is used in the “PARTICIPANT” calendar component to indicate the participation status — if any.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified in a “PARTICIPANT” calendar component.
Description
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 IETF RFC 5545.
Format Definition
This property is defined by the following notation:
participation-status = "PARTICIPATION-STATUS"
participation-statusparams ":"
NEEDS-ACTION / ; No status
; has yet been set by the participant.
ACCEPTED / ; The invited
; participant will participate.
DECLINED / ; The invited
; participant will not participate.
TENTATIVE / ; The invited participant
; may participate.
DELEGATED / ; The invited participant
; has delegated their attendance to
; another participant, as specified
; in the PARTICIPATION-DELEGATED-TO property.
COMPLETED / ; The assigned task is
; completed.
IN-PROCESS / ; The assigned task is
; being worked on.
iana-token ("," iana-token) CRLF
participation-statusparams = *(";" other-param)
Figure 5
5.3. Participation delegated from
Property name
PARTICIPATION-DELEGATED-FROM
Purpose
This property is used in the “PARTICIPANT” calendar component to indicate who has delegated their participation to this participant.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified in a “PARTICIPANT” calendar component 0 or more times.
Description
This property specifies a calendar user that has delegated their participation in a group-scheduled component to the calendar user specified by the component.
Format Definition
This property is defined by the following notation:
participation-delfrom = "PARTICIPATION-DELEGATED-FROM"
participation-delfromparams ":"
CAL-ADDRESS
iana-token ("," iana-token) CRLF
participation-delfromparams = *(";" other-param)
Figure 6
5.4. Participation delegated to
Property name
PARTICIPATION-DELEGATED-TO
Purpose
To specify the calendar user to whom the calendar user specified by the component has delegated participation.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified in a “PARTICIPANT” calendar component 0 or more times.
Description
This property specifies the calendar user that has been delegated participation in a group-scheduled component by the calendar user specified by the component.
Format Definition
This property is defined by the following notation:
participation-delto = "PARTICIPATION-DELEGATED-TO"
participation-deltoparams ":"
CAL-ADDRESS
iana-token ("," iana-token) CRLF
participation-deltoparams = *(";" other-param)
Figure 7
5.5. Member of
Property name
MEMBER-OF
Purpose
To specify the group or list membership of the calendar user specified by the component.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified in a “PARTICIPANT” calendar component 0 or more times.
Description
This property identifies the group or list membership for the calendar user specified by the component.
Format Definition
This property is defined by the following notation:
member-of = "MEMBER-OF" member-ogparams ":"
CAL-ADDRESS
iana-token ("," iana-token) CRLF
memberofparams = *(";" other-param)
Figure 8
5.6. Lang
Property name
LANG
Purpose
This is the language tag, as defined in IETF RFC 5646, that best describes the participant’s preferred language, if known.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified in any appropriate component.
Format Definition
This property is defined by the following notation:
lang = "LANG" langparams ":" TEXT CRLF
langparams = *(";" other-param)
Figure 9
5.7. Expect reply
Property name
EXPECT-REPLY
Purpose
If true, the organizer is expecting the participant to notify them of their participation status.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified once in the “PARTICIPANT” calendar component.
Format Definition
This property is defined by the following notation:
expect-reply = "EXPECT-REPLY"
expect-replyparams ":"
( "TRUE" / "FALSE") CRLF
expect-replyparams = *(";" other-param)
Figure 10
5.8. Scheduling-agent
Property name
SCHEDULING-AGENT
Purpose
This is who is responsible for sending scheduling messages with this calendar object to the participant.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified once in the “PARTICIPANT” calendar component.
Format Definition
This property is defined by the following notation:
scheduling-agent = "SCHEDULING-AGENT"
scheduling-agentparams ":"
( "SERVER" /
"CLIENT" /
"NONE") CRLF
scheduling-agentparams = *(";" other-param)
Figure 11
The value MUST be one of the following values from the registry defined in IETF RFC 6638, Section 12.4.1, or a vendor-specific value.
SERVER
The calendar server will send the scheduling messages.
CLIENT
The calendar client will send the scheduling messages.
NONE
No scheduling messages are to be sent to this participant.
5.9. Scheduling-force-send
Property name
SCHEDULING-FORCE-SEND
Purpose
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.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified once in the “PARTICIPANT” calendar component.
Format Definition
This property is defined by the following notation:
scheduling-force-send = "SCHEDULING-FORCE-SEND"
scheduling-force-sendparams ":"
( "TRUE" / "FALSE") CRLF
scheduling-force-sendparams = *(";" other-param)
Figure 12
Description
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 IETF RFC 5546, Section 3.6.6) when the “SCHEDULE-FORCE-SEND” property is set to an iana-token value they do not recognize.
5.10. Scheduling-status
Property name
SCHEDULING-STATUS
Purpose
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.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified in any appropriate component.
Format Definition
This property is defined by the following notation:
scheduling-status = "SCHEDULING-STATUS"
scheduling-statusparams ":" TEXT CRLF
scheduling-statusparams = *(";" other-param)
Figure 13
5.11. Scheduling-dtstamp
Property name
SCHEDULING-DTSTAMP
Purpose
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.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified in any appropriate component.
Format Definition
This property is defined by the following notation:
scheduling-dtstamp = "SCHEDULING-DTSTAMP"
scheduling-dtstampparams ":" DATE-TIME CRLF
scheduling-dtstampparams = *(";" other-param)
Figure 14
5.12. Invited-by
Property name
INVITED-BY
Purpose
This is the calendar address of the participant who added this participant to the entity, if known.
Property Parameters
Non-standard or iana parameters can be specified on this property.
Conformance
This property MAY be specified in any appropriate component.
Format Definition
This property is defined by the following notation:
invited-by = "INVITED-BY"
invited-byparams ":" CAL-ADDRESS CRLF
invited-byparams = *(";" other-param)
Figure 15
6. Attendee parameters mapping
Table 3
| Parameter | iCalendar PARTICIPANT |
|---|---|
CN | NAME (defined in IETF RFC 7986) |
CUTYPE | KIND (defined here) |
DELEGATED-FROM | PARTICIPATION-DELEGATED-FROM Clause 5.3 |
DELEGATED-TO | PARTICIPATION-DELEGATED-TO (defined here) |
DIR | LINK IETF RFC 9253 |
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 |
7. Security Considerations
There should be no new security risks additional to those noted in IETF RFC 5546.
8. IANA Considerations
8.1. Parameter Registrations
This document defines the following new iCalendar property parameters to be added to the registry defined in IETF RFC 5545, Section 8.2.4:
Table 4
| Property Parameter | Status | Reference |
|---|---|---|
REQUIRED | Current |
8.2. Property Registrations
This document defines the following new iCalendar properties to be added to the registry defined in IETF RFC 5545, Section 8.2.3:
Table 5
| 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 |
8.3. Updated Participant Type Registrations
This updates the participant types registry defined in IETF RFC 9073, Section 11.2.1
Table 6
| Participant Type | Status | Reference |
|---|---|---|
OWNER | Current | RFC8984 IETF RFC 8984, Section 4.4.6 |
ATTENDEE | Current | RFC8984 IETF RFC 8984, Section 4.4.6 |
OPTIONAL | Current | RFC8984 IETF RFC 8984, Section 4.4.6 |
INFORMATIONAL | Current | RFC8984 IETF RFC 8984, Section 4.4.6 |
CHAIR | Current | RFC8984 IETF RFC 8984, Section 4.4.6 |
9. Acknowledgements
The authors would like to thank the members of the Calendaring and Scheduling Consortium (CalConnect) for contributing their ideas and support.
Bibliography
[1] IETF RFC 2119, S. BRADNER. Key words for use in RFCs to Indicate Requirement Levels. In: BCP. 1997. RFC Publisher. https://www.rfc-editor.org/info/rfc2119. [viewed: November 7, 2024].
[2] IETF RFC 5646, A. PHILLIPS and M. DAVIS (eds.). Tags for Identifying Languages. In: BCP. 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5646. [viewed: November 7, 2024].
[3] IETF RFC 6638, C. DABOO and B. DESRUISSEAUX. Scheduling Extensions to CalDAV. In: RFC. 2012. RFC Publisher. https://www.rfc-editor.org/info/rfc6638. [viewed: November 7, 2024].
[4] IETF RFC 7986, C. DABOO. New Properties for iCalendar. In: RFC. 2016. RFC Publisher. https://www.rfc-editor.org/info/rfc7986. [viewed: November 7, 2024].
[5] IETF RFC 8984, N. JENKINS and R. STEPANEK. JSCalendar: A JSON Representation of Calendar Data. In: RFC. 2021. RFC Publisher. https://www.rfc-editor.org/info/rfc8984. [viewed: November 7, 2024].
[6] IETF RFC 9253, M. DOUGLASS. Support for iCalendar Relationships. In: RFC. 2022. RFC Publisher. https://www.rfc-editor.org/info/rfc9253. [viewed: November 7, 2024].