ietf-corpus

rfc-9253

Support for iCalendar Relationships

M. Douglass
date2022-08 streamIETF areaart wgcalext statusPROPOSED STANDARD pages19 canonicalhttps://www.rfc-editor.org/rfc/rfc9253 doi10.17487/RFC9253 errataview
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.

updates

Extracted elements (28)

design-rationale §1.3

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.

design-rationale §1.2

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.

design-rationale §1.4

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.

design-rationale §1.4

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.

interoperability-note §9.1

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.

interoperability-note §2

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.

normative-requirement §1.4 MUST NOT

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.

normative-requirement §6.1 MUST

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.

normative-requirement §9.1 MAY

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.

normative-requirement §9.1 MUST

To preserve backwards compatibility, the RELATED-TO value type MUST be UID when the PARENT, SIBLING, or CHILD relationship types are specified.

normative-requirement §2 MUST

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.

protocol-element §5

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).

protocol-element §4

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.

protocol-element §8.1

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.

registry

protocol-element §6.2

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).

protocol-element §8.2

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.

registry

protocol-element §2

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).

protocol-element §6.1

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.

registry

protocol-element §8.3

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.

registry

protocol-element §9.1

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.

protocol-element §7

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).

registry §11.4

Nine new RELTYPE values are registered in the RFC 5545 'Relationship Types' registry: CONCEPT, DEPENDS-ON, FINISHTOFINISH, FINISHTOSTART, FIRST, NEXT, REFID, STARTTOFINISH, and STARTTOSTART.

registry

registry §11.1

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.

registry

registry §11.2

Two new iCalendar property parameters are registered in the RFC 5545 'Parameters' registry: GAP (Section 6.2) and LINKREL (Section 6.1).

registry

registry §11.3

Two new iCalendar value data types are registered in the RFC 5545 'Value Data Types' registry: XML-REFERENCE (Section 7) and UID (Section 7).

registry

security-consideration §10

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.

security

security-consideration §10

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.

security

security-consideration §10

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.

security