Support for iCalendar Relationships
updates
- rfc-5545 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Extracted elements (28)
CONCEPT is introduced instead of extending CATEGORIES because CATEGORIES is used as informal free-form tagging with no guaranteed meaning to consumers, making formal inter-component relationships unreliable. CONCEPT uses URI values referencing well-defined external category resources, enabling hierarchical and namespaced categorization.
REFID is designed as a pure retrieval key with no semantic meaning, contrasting with CONCEPT (which imparts categorization meaning) and CATEGORIES (informal tagging). This allows grouping components (e.g., all tasks in a project) without encoding hierarchical structure or semantic categories.
The LINK property is introduced because the existing ATTACH property is purpose-built for managed attachments (with size, filename, server-side stripping) and clients treat attachments as integral message content. A separate LINK property allows typed, discoverable external references without conflating them with attachments.
The RELATED-TO property is extended to allow URI values because the existing PARENT/CHILD/SIBLING types only allow UID references, which are inadequate for linking components across different CalDAV collections or servers. Adding new value types to those relationships would cause backward-compatibility issues.
The PARENT, SIBLING, and CHILD RELTYPE values require VALUE=UID for backward compatibility with RFC 5545. Implementations must enforce this constraint when processing or generating these relationship types.
UID references in LINK properties may need updating on import into systems like CalDAV, where VTODO and VEVENT components are placed in different collections. Such inter-collection UID references must be replaced with URI references.
The LINK property MUST NOT be treated as just another attachment. It differs semantically from ATTACH, which handles server-side management, stripping, and inline data; clients may handle them differently.
The LINKREL parameter MUST be specified on all LINK properties to define the type of reference. There is no default relation type; its presence allows consuming programs to scan for supported reference types.
The RELATED-TO property MAY be specified in any iCalendar component, and the GAP parameter MAY be specified on RELATED-TO to define the duration between predecessor and successor in a temporal relationship.
To preserve backwards compatibility, the RELATED-TO value type MUST be UID when the PARENT, SIBLING, or CHILD relationship types are specified.
When VALUE=UID is used in the LINK property, the value MUST refer to another component within the same collection. If that collection context changes (e.g., on CalDAV import into a different collection), the UID reference must be replaced with a URI.
Five additional RELTYPE values are defined: FIRST (first in a series), NEXT (next in a series), DEPENDS-ON (dependency on another component), REFID (reference to components sharing a REFID value), and CONCEPT (reference to components sharing a CONCEPT value).
Four new temporal RELTYPE values are defined for RELATED-TO: FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH, and STARTTOSTART. These model project-management predecessor/successor relationships; the property appears in the predecessor entity and refers to the successor.
The CONCEPT property defines formal categories for a calendar component using a URI value. It provides structured, hierarchical categorization distinct from the informal CATEGORIES property, and is expected to reference external resources describing the categorization.
The GAP parameter specifies the lead or lag duration between two calendar components with a temporal RELATED-TO relationship. Positive values indicate lag time (delay after predecessor finishes); negative values indicate lead time (overlap allowed).
The LINK property provides a typed reference to external information related to a calendar component. It accepts URI, UID, or XML-REFERENCE values and requires LINKREL and FMTTYPE parameters; it is a serialization of the RFC 8288 web linking model.
The LINK property supports three reference value types via the VALUE parameter: URI (reference to a target), UID (link within the same collection), and XML-REFERENCE (URI with an XPointer anchor for referencing fragments of external XML documents).
The LINKREL parameter specifies the relationship type of data referenced by a LINK property. It takes either a quoted URI or an IANA-registered token, and any relation in the RFC 8288 link registry or new link relations may be used.
The REFID property provides a free-form text key for grouping associated iCalendar entities. All components sharing the same REFID value are associated and can be retrieved as a group; the property imparts no semantic meaning, only a retrieval key.
The RELATED-TO property is updated to accept URI or UID values in addition to TEXT, and gains a GAP parameter. The relparam now includes optional VALUE (UID/URI/TEXT), RELTYPE, GAP, and other parameters in any order.
Two new value data types are defined: UID (VALUE=UID, indicating the value is the UID of another component) and XML-REFERENCE (VALUE=XML-REFERENCE, a URI with an XPointer anchor referencing an XML artifact fragment).
Nine new RELTYPE values are registered in the RFC 5545 'Relationship Types' registry: CONCEPT, DEPENDS-ON, FINISHTOFINISH, FINISHTOSTART, FIRST, NEXT, REFID, STARTTOFINISH, and STARTTOSTART.
Three new iCalendar properties are registered in the RFC 5545 'Properties' registry: CONCEPT (Section 8.1), LINK (Section 8.2), and REFID (Section 8.3). RELATED-TO is updated with a cross-reference to RFC 9253 Section 9.1.
Two new iCalendar property parameters are registered in the RFC 5545 'Parameters' registry: GAP (Section 6.2) and LINKREL (Section 6.1).
Two new iCalendar value data types are registered in the RFC 5545 'Value Data Types' registry: XML-REFERENCE (Section 7) and UID (Section 7).
Applications using the LINK property must be aware of URI security risks per RFC 3986 Section 7, including reliability and consistency issues (Section 7.1), as there is no stability guarantee for referenced resources.
Extremely large values for the GAP parameter may lead to unexpected behavior in calendar systems. CONCEPT and the redefined RELATED-TO also carry URI-related security risks identical to those of the LINK property.
When LINK values are of type XML-REFERENCE, consumers must account for XML processing security issues, particularly XML entity attacks (see RFC 4918 Section 20.6), and the possibility that the reference is or becomes invalid.