RFC 9253

Support for iCalendar Relationships

📅 published August 2022, from ietf

RFC 9253: Support for iCalendar Relationships 🎀

Bestie, the header info: this one is Standards Track 💅, written by M. Douglass of Bedework 🌸 in August 2022 ✨. It updates RFC 5545 🔥 and is ISSN 2070-1721. It's an official IETF document, so it's basically law for calendar apps 👑.

Abstract ✨

okay so this spec updates the iCalendar RELATED-TO property from RFC 5545 🦋. It adds new relation types and brings in three new properties, LINK, CONCEPT, and REFID 🧚. Together they make it way easier to link and group calendar components and their related data 💖.

Status of This Memo 🌈

This is an Internet Standards Track document 💅.

It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. For more on Internet Standards, check Section 2 of RFC 7841 🔍.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9253 💜.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 🌸.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date 📜. Please actually read these, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 🫶.

Table of Contents 🧚

1.  Introduction
  1.1.  Structured iCalendar Relationships
  1.2.  Grouped iCalendar Relationships
  1.3.  Concept Relationships
  1.4.  Linked Relationships
  1.5.  Caching and Offline Use
  1.6.  Conventions Used in This Document
2.  LINK Property Reference Types
3.  Link Relation Types
4.  New Temporal RELTYPE Parameter Values
5.  Additional New RELTYPE Parameter Values
6.  New Property Parameters
  6.1.  Link Relation
  6.2.  Gap
7.  New Value Data Types
8.  New Properties
  8.1.  Concept
  8.2.  Link
  8.3.  Refid
9.  Updates to RFC 5545
  9.1.  RELATED-TO
10. Security Considerations
11. IANA Considerations
  11.1.  iCalendar Property Registrations
  11.2.  iCalendar Property Parameter Registrations
  11.3.  iCalendar Value Data Type Registrations
  11.4.  iCalendar RELTYPE Value Registrations
12. References
  12.1.  Normative References
  12.2.  Informative References
Acknowledgements
Author's Address

1. Introduction ✨

okay so iCalendar entities from [RFC5545] constantly need to be related to each other, or to some extra metadata 🦋. This spec supports relationships in three flavours 💅:

  • Structured iCalendar: entities can be related in a structured way, like parent, sibling, before, or after 🌸.
  • Grouped iCalendar: entities can be grouped together. CATEGORIES get used for this a lot, but app devs struggle with them because they're inconsistent free-form tags 😭.
  • Linked: entities can link to other things, like vCards, using a URI plus the REL and FMTTYPE parameters 🔗.

1.1. Structured iCalendar Relationships 🧚

The RELATED-TO property from [RFC5545] has zero support for temporal relationships, which is a huge miss for project management tools 💀.

So the RELTYPE parameter gets new values that describe temporal relationships 💖. A new GAP parameter gives lead and lag values ⏳. And RELATED-TO gets extended to accept URI values too 🔥. Put together, RELATED-TO can describe a much richer set of relationships, which is exactly what project management needs 👑.

1.2. Grouped iCalendar Relationships 🌈

This spec defines a new REFID property ✨. It lets any arbitrary group of entities share the same key value 🫶.

REFID is a key that ties together components all related to the referring, aggregating component, and lets you retrieve them by that key 🔑. For example, you could find all the tasks for a project without having to share the whole task structure of the project 🎀. Another example is grouping every sub-task for delivering one specific package in a package delivery system 📦.

So a REFID property doesn't give the component any meaning at all. It's just a key for retrieval 🦋. That's different from categorization, which also groups things but adds meaning to whatever it's attached to 💅.

1.3. Concept Relationships 🌸

The name CONCEPT comes from the Simple Knowledge Organization System, defined in [W3C.REC-skos-reference-20090818] 📚. Honestly, "concept" describes what we usually mean by category way better 💜. What matters isn't the text string, it's the meaning attached to it 🧠. Like, "football" can mean totally different sports 🏈.

CONCEPT gives you a more structured way to categorize, with namespaced and path-like values possible 🌈. Unlike REFID, CONCEPT does carry meaning 💖. The value is assumed to reference a well-defined category ✨.

Right now the CATEGORIES property from [RFC5545] is used as a free-form 'tagging' field 🏷️. Those tags mean something to whoever applied them, but not necessarily to any consumer 🙈. So it's hard to build formal relationships between components based on their categories 😤.

Instead of piling semantics onto CATEGORIES, it makes more sense to keep it as an informal tag and set up CONCEPT as a new property with more constraints 💅.

1.4. Linked Relationships 🔗

The current iCalendar standard, [RFC5545], has no general-purpose way to reference extra external info about calendar components 😭.

So this document proposes a way to reference typed external information that adds detail to an iCalendar component ✨. This new LINK property is closely aligned with [RFC8288], which defines the generic concept of Web Linking and how it shows up in the HTTP LINK header field 🦋.

LINK is a typed reference or relation to external metadata or related resources 💖. Type and format come in as parameters, so clients and servers can discover these references and use them, maybe for indexing or for showing the user interesting links 👀.

Calendar components often get grouped into collections, like a calendar or a series of tasks, for example CalDAV calendar collections from [RFC4791] 📅.

Sometimes you also need to reference components in other collections 🧳. Say a VEVENT refers to the VTODO it came from 💅. The PARENT, SIBLING, and CHILD relationships for RELATED-TO only allow a unique identifier (UID), which just isn't enough for lots of uses 😤. Letting other value types into those relationships might help, but it would cause backward-compatibility issues 🙈. LINK can connect components in different collections or even on different servers 🌐.

When you publish events, it's super useful to point back to where the info came from 🎀. The event might have been pulled from a feed or an ics file on a website 🌸. A LINK property can reference the originator of the event ✨.

Beyond timing relationships, project management tools also need to specify how the events and tasks in a project relate to each other 📋. LINK provides that mechanism 💜.

The LINK property MUST NOT be treated as just another attachment 🚫. The ATTACH property from [RFC5545] got extended by [RFC8607] to handle server-side management and stripping of inline data, and to give extra data about the attachment, like size and filename 📎. Clients may choose to handle attachments differently from LINK, though, because attachments are often an integral part of the message, like the agenda 🗓️.

1.5. Caching and Offline Use 📴

In general, the calendar entity should make sense on its own without downloading referenced metadata, like a web page 🌸.

But for offline display, the link type may point out important pieces of data that should be downloaded ahead of time 💾.

1.6. Conventions Used in This Document 📖

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥.

The notation used here to (re-)define iCalendar elements is the ABNF notation of [RFC5234], as used by [RFC5545] 📐. Any syntax elements shown below that aren't explicitly defined in this specification come from iCalendar [RFC5545] 💜.

The reference value in the LINK property can take three forms, picked with the VALUE parameter 🧚:

  • URI: a URI referring to the target 🔗.
  • UID: lets you link within a single collection of calendar components 🗂️. The value MUST refer to another component within the same collection 🚫.
  • XML-REFERENCE: in an XML environment, you might need to refer to a fragment of an external XML artifact 📄. This value is a URI with an XPointer anchor value. The XPointer is defined in [W3C.WD-xptr-xpointer-20021219], and its use as an anchor is defined in [W3C.REC-xptr-framework-20030325] ✨.

Heads up: UID references may need updating on import 🙈. Say you import data from a file with VTODO and VEVENT components, and a VTODO refers to VEVENT components by UID 📁. When it lands in a CalDAV system, the VTODO components usually go into a different collection from the VEVENT components 🌸. That means the UID reference has to be replaced with a URI 🔄.

There are two forms of relation types defined in [RFC8288]: registered and extension 🌈. Registered relation types get added to the "Link Relations" registry, as specified in Section 2.1.1 of [RFC8288] 📋. Extension relation types, defined in Section 2.1.2 of [RFC8288], are specified as unique URIs that aren't registered in the registry 🔗.

The relation types defined in Section 6.1 will be registered with IANA in accordance with the specifications in [RFC8288] 🎀.

4. New Temporal RELTYPE Parameter Values ✨

Okay bestie, this section gives us the usual temporal relationships to use with the RELTYPE parameter from Section 3.2.15 of [RFC5545] 🦋. The four options are FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH, and STARTTOSTART. They're the classic "what has to happen before what" vibes ⏳

The [RFC5545] RELATED-TO property with one or more of these temporal relationships lives in the predecessor entity and points at the successor entity. So the predecessor is the one carrying the link 💅

The GAP parameter (see Section 6.2) is how you say how much lead time (a negative value) or lag time (a positive value) sits between the predecessor and the successor 🌸

When we talk about each temporal relationship below, we call the thing that contains and controls the relationship Task-A, and the target of the relationship Task-B. You can tell which is which from the direction of the arrows in the diagrams 🏹

Also, any of these relationships can be tweaked by adding a GAP parameter to the relationship that applies to the targeted component ✨

RELTYPE=FINISHTOSTART: Task-B cannot start until Task-A finishes. Like, when painting is done, carpet laying can begin 🎀

                  ============
                  |  Task-A  |
                  ============
                             |
                             V
                             ============
                             |  Task-B  |
                             ============

                    Figure 1: Finish-to-Start Relationship

RELTYPE=FINISHTOFINISH: Task-B can only be completed after Task-A is finished. The two tasks can run in parallel before they wrap up 🧚

For example, say you're building two related pieces of software, like an API and its implementation. The design of the implementation (Task-B) can't be completed until the design of the API (Task-A) is done 💜

                          ==================
                          |     Task-A     |--+
                          ==================  |
                                              |
                                ============  |
                                |  Task-B  |<-+
                                ============

                   Figure 2: Finish-to-Finish Relationship

RELTYPE=STARTTOFINISH: The start of Task-A (which happens after Task-B) controls the finish of Task-B 🎟️ Ticket sales (Task-B) end after the game starts (Task-A). Iconic, honestly 🏟️

                                 ============
                              +--|  Task-A  |
                              |  ============
                              +---------+
                          ============  |
                          |  Task-B  |<-+
                          ============

                    Figure 3: Start-to-Finish Relationship

RELTYPE=STARTTOSTART: The start of Task-A triggers the start of Task-B, which means Task-B can start any time after Task-A starts 🚀

                          ============
                       +--|  Task-A  |
                       |  ============
                       |
                       |  ============
                       +->|  Task-B  |
                          ============

                    Figure 4: Start-to-Start Relationship

5. Additional New RELTYPE Parameter Values 🌈

This section adds a few more relationship types, and they're giving variety 💖

RELTYPE=FIRST: This means the referenced calendar component is the first one in a series that the referencing calendar component belongs to 🥇

RELTYPE=NEXT: This means the referenced calendar component is the next one in a series that the referencing calendar component belongs to ⏭️

RELTYPE=DEPENDS-ON: This means the current calendar component depends on the referenced calendar component in some way. For example, a task might be blocked waiting on the other, referenced, task 🙈

RELTYPE=REFID: This sets up a reference from the current component to components with a REFID property whose value matches the value given in the associated RELATED-TO property 🔗

RELTYPE=CONCEPT: This sets up a reference from the current component to components with a CONCEPT property whose value matches the value given in the associated RELATED-TO property 🧠

Quick note, bestie: PARENT, CHILD, and SIBLING are all hierarchical relationships. FIRST and NEXT are an ordering relationship. Different vibes entirely 🍓

6. New Property Parameters 🎀

Parameter name: LINKREL

Purpose: This property tells you the relationship of data referenced by a LINK property 💅

Format Definition: This parameter is written in the following notation:

linkrelparam = "LINKREL" "="
                (DQUOTE uri DQUOTE
               / iana-token)   ; Other IANA registered type

Description: This parameter MUST be specified on all LINK properties, and it defines the type of reference 🫶 It's what lets programs reading this data automatically scan for the references they support, so no guessing! There is no default relation type, so you always have to name one 🙅‍♀️

Any link relation in the link registry established by [RFC8288] can be used, and so can new link relations 🌷 Link relation types that see a lot of use in calendaring are expected to have their calendaring usage described in an RFC, which is very organized of them ✨

LINKREL=latest-version: This identifies the latest version of the event information 🆕

Registration: These relation types are registered in [RFC8288] 📋

6.2. Gap ⏳

Parameter name: GAP

Purpose: This property tells you the length of the gap, positive or negative, between two components that have a temporal relationship 🦋

Format Definition: This parameter is written in the following notation, where dur-value is defined in Section 3.3.6 of [RFC5545]. :

  gapparam      = "GAP" "=" dur-value

Description: This parameter MAY be specified on the RELATED-TO property, and it defines the amount of time between the predecessor and successor in an interval 🕰️ When it's positive, it's the lag time between a task and its logical successor. When it's negative, it's the lead time 🌊

Here's a lag time example. Say Task-A is "paint the room" and Task-B is "lay the carpets". Task-A can be related to Task-B with RELTYPE=FINISHTOSTART and a gap of 1 day, which is long enough for the paint to dry 🎨

            ====================
            |  paint the room  |--+
            ====================  |
                                  |(lag of one day)
                                  |
                                  |  ===================
                                  +->| lay the carpet  |
                                     ===================

         Figure 5: Finish-to-Start Relationship with Lag

For a lead time example, think about building a two-story building 🏗️ The electrical work has to be done before painting. But! The painter can move into the first floor while the electricians move upstairs. Main character multitasking 💅

            =====================
            |  electrical work  |--+
            =====================  |
                     +-------------+
                     |(lead of estimated time)
                     |  ==================
                     +->|    painting    |
                        ==================

         Figure 6: Finish-to-Start Relationship with Lead

7. New Value Data Types 🧩

This specification defines the following new value types to be used with the VALUE property parameter:

UID: VALUE=UID means the associated value is the UID for a component 🆔

XML-REFERENCE: VALUE=XML-REFERENCE means the associated value references an associated XML artifact. It's a URI with an XPointer anchor value. The XPointer is defined in [W3C.WD-xptr-xpointer-20021219], and its use as an anchor is defined in [W3C.REC-xptr-framework-20030325] 🌐

8. New Properties 💜

8.1. Concept 🧠

Property name: CONCEPT

Purpose: This property defines the formal categories for a calendar component 📚

Value type: URI

Property Parameters: IANA and non-standard parameters can be specified on this property 🎀

Conformance: This property can be specified zero or more times in any iCalendar component ✨

Description: This property is used to specify formal categories or classifications of the calendar component. The values are super useful when you're searching for a calendar component of a particular type and category 🔍

This categorization is totally different from the more casual "tagging" you get from the existing CATEGORIES property 🏷️ It's expected that the value of the CONCEPT property will reference an external resource that gives information about the categorization 🌸

Also, a structured URI value lets you do hierarchical categorization of events, which is a very neat trick 🌳

Possible category resources include various proprietary systems, like the Library of Congress, or an open source of categorization data 📖

Format Definition: This property is written in the following notation:

  concept        =  "CONCEPT" conceptparam ":"
                        uri CRLF

  conceptparam = *(";" other-param)

Example: Here's an example of this property. It points to a server acting as the source for the calendar object 🎶

  CONCEPT:https://example.com/event-types/arts/music

Property name: LINK 🔗

Purpose: Okay, this one is giving "here's where you can find more stuff" 🦋 It gives you a reference to external info that's related to a component.

Value type: URI, UID, or XML-REFERENCE

Property Parameters: The VALUE parameter is required 💅 You can also add non-standard, link relation type, format type, label, and language parameters. The LABEL parameter comes from [RFC7986].

Conformance: You can drop this into any iCalendar component zero or more times 🌸

Description: When it's used in a component, the value points to extra info about that component. Like, it could point back at the web server where it came from 🌐

Format Definition: This property is defined by the following notation:

link           = "LINK" linkparam ":"
                    ( uri /  ; for VALUE=XML-REFERENCE
                      uri /  ; for VALUE=URI
                      text ) ; for VALUE=UID
                  CRLF

linkparam      = (";" "VALUE" "=" ("XML-REFERENCE" /
                                    "URI" /
                                    "UID"))
                  1*(";" linkrelparam)
                  1*(";" fmttypeparam)
                  1*(";" labelparam)
                  1*(";" languageparam)
                  *(";" other-param)
                  ; the elements herein may appear in any order,
                  ; and the order is not significant.

Okay so this property is basically a serialization of the model in [RFC8288] 🧠 The link target goes in the property value, the link context is the calendar entity that holds it, and the link relation type plus any target attributes ride along in the property parameters 💖

Here's how the LINK property parameters map onto [RFC8288] attributes:

  • LABEL: This parameter maps to the "title" attribute defined in Section 3.4.1 of [RFC8288].
  • LANGUAGE: This parameter maps to the "hreflang" attribute defined in Section 3.4.1 of [RFC8288].
  • LINKREL: This parameter maps to the link relation type defined in Section 2.1 of [RFC8288].
  • FMTTYPE: This parameter maps to the "type" attribute defined in Section 3.4.1 of [RFC8288].

There is no mapping for "title*", "anchor", "rev", or "media" [RFC8288] 🙈

Example: Here's a LINK that points to the source for the calendar object 🎟️

LINK;LINKREL=SOURCE;LABEL=Venue;VALUE=URI:
 https://example.com/events

Example: This one points to an entity that this one was derived from. The link relation is a vendor-defined value, so it's giving custom 🧚

LINK;LINKREL="https://example.com/linkrel/derivedFrom";
 VALUE=URI:
 https://example.com/tasks/01234567-abcd1234.ics

Example: And this one points to a fragment of an XML document. The link relation is vendor-defined here too 📄✨

LINK;LINKREL="https://example.com/linkrel/costStructure";
 VALUE=XML-REFERENCE:
 https://example.com/xmlDocs/bidFramework.xml
 #xpointer(descendant::CostStruc/range-to(
 following::CostStrucEND[1]))

8.3. Refid 🎀

Property name: REFID 🪪

Purpose: This property value works as a key for associated iCalendar entities 🔑

Value type: TEXT

Property Parameters: Non-standard parameters can be specified on this property.

Conformance: You can add this property zero or more times in any iCalendar component 💅

Description: The value is free-form text that creates an identifier for associated components. Every component that uses the same REFID value gets linked together through that value, so they can be found or fetched as a group 🫶 For example, all the events in a travel itinerary would share the same REFID value, so they stay grouped together ✈️

Format Definition: This property is defined by the following notation:

refid      = "REFID" refidparam ":" text CRLF


refidparam      = *(";" other-param)

Example: Here's an example of this property 🧁

REFID:itinerary-2014-11-17

9. Updates to RFC 5545 🌈

This specification updates the RELATED-TO property defined in Section 3.8.4.5 of [RFC5545] 📝 The contents of Section 9.1 replace that section.

The RELTYPE parameter gets extended to take new values that define temporal relationships ⏳ A GAP parameter is defined to provide lead and lag values, and RELATED-TO is extended to allow URI values too. Together, these changes let RELATED-TO describe a richer set of relationships that are useful for project management 📊👑

Property name: RELATED-TO 🔗

Purpose: This property represents a relationship or reference between one calendar component and another. This definition extends the one in Section 3.8.4.5 of [RFC5545] by allowing URI or UID values and a GAP parameter ✨

Value Type: URI, UID, or TEXT

Property Parameters: Relationship type, IANA, and non-standard property parameters can be specified on this property.

Conformance: This property MAY be specified in any iCalendar component 🌸

Description: By default, or when VALUE=UID is specified, the value is the persistent, globally unique identifier of another calendar component 🪄 In a calendar component, that value would be represented by the UID property.

By default, the value points to another calendar component that has a PARENT relationship to the one referencing it. The RELTYPE property parameter is used to either explicitly state that default PARENT relationship, or to override it and specify a CHILD or SIBLING relationship, or a temporal relationship ⏩

The PARENT relationship means the calendar component is a subordinate of the referenced calendar component 👶 The CHILD relationship means the calendar component is a superior of the referenced calendar component 👑 The SIBLING relationship means the calendar component is a peer of the referenced calendar component 👯

To preserve backwards compatibility, the value type MUST be UID when the PARENT, SIBLING, or CHILD relationships are specified 🔒

The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH, or STARTTOSTART relationships define temporal relationships, as specified in the RELTYPE parameter definition 🗓️

The FIRST and NEXT relationships define ordering relationships between calendar components 🥇🥈

The DEPENDS-ON relationship means the current calendar component depends on the referenced calendar component in some manner. For example, a task might be blocked waiting on another, referenced, task 🚧

The REFID and CONCEPT relationships establish a reference from the current component to the referenced component 🎯

Changes to a calendar component referenced by this property can have an implicit impact on the related calendar component. For example, if a group event changes its start or end date or time, then the related, dependent events will need to have their start and end dates and times changed in a corresponding way 🔁 Similarly, if a PARENT calendar component is canceled or deleted, there is an implied impact to the related CHILD calendar components. This property is only intended to provide information on the relationship of calendar components ℹ️

Deleting the target component can result in broken links. For example, if the target of a FIRST, NEXT, or temporal relationship is deleted, the link can break 💀

It is up to the target calendar system to maintain any property implications of these relationships 🛠️

Format Definition: This property is defined by the following notation:

related    = "RELATED-TO" relparam ":"
                         ( text / ; for VALUE=UID
                           uri /  ; for VALUE=URI
                           text ) ; for VALUE=TEXT or default
             CRLF

relparam   = ; the elements herein may appear in any order,
             ; and the order is not significant.
             [";" "VALUE" "=" ("UID" /
                               "URI" /
                               "TEXT")]
             [";" reltypeparam]
             [";" gapparam]
             *(";" other-param)

Example: Here are some examples of this property 🌷

RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com

RELATED-TO:19960401-080045-4000F192713-0052@example.com

RELATED-TO;VALUE=URI;RELTYPE=STARTTOFINISH:
 https://example.com/caldav/user/jb/cal/
 19960401-080045-4000F192713.ics

10. Security Considerations 🔐

All of the security considerations of Section 7 of [RFC5545] apply to this specification 🛡️

Applications using the LINK property need to be aware of the risks that come with the URIs provided as values. See Section 7 of [RFC3986] for a discussion of the security considerations relating to URIs 🌐

In particular, take a look at Section 7.1 (Reliability and Consistency) of [RFC3986], which points out that there is no stability guarantee for referenced resources 😬

When the value is an XML-REFERENCE type, the targeted data is an XML document or a portion of one. Consumers need to be aware of the security issues related to XML processing, in particular those related to XML entities. See Section 20.6 of [RFC4918]. Additionally, the reference may be invalid, or become invalid over time 🚨

The CONCEPT and redefined RELATED-TO properties have the same issues, since their values may be URIs 🧩

Extremely large values for the GAP parameter may lead to unexpected behavior. Please don't test this on your production calendar 💀🙈

11. IANA Considerations 📋

11.1. iCalendar Property Registrations 🗂️

The following iCalendar property names have been added to the iCalendar "Properties" registry defined in Section 8.3.2 of [RFC5545] 💖 IANA has also added a reference to this document, where the properties originally defined in [RFC5545] have been updated by this document.

       +============+=========+=============================+
       | Property   | Status  | Reference                   |
       +============+=========+=============================+
       | CONCEPT    | Current | Section 8.1                 |
       +------------+---------+-----------------------------+
       | LINK       | Current | Section 8.2                 |
       +------------+---------+-----------------------------+
       | REFID      | Current | Section 8.3                 |
       +------------+---------+-----------------------------+
       | RELATED-TO | Current | [RFC5545], Section 3.8.4.5; |
       |            |         | RFC 9253, Section 9.1       |
       +------------+---------+-----------------------------+

Table 1

11.2. iCalendar Property Parameter Registrations ✨

Okay bestie, these iCalendar property parameter names just got added to the iCalendar "Parameters" registry 🎀, which is defined in Section 8.3.3 of [RFC5545] 📋. Here they are, and yes, they're both Current 💅

               +===========+=========+=============+
               | Parameter | Status  | Reference   |
               +===========+=========+=============+
               | GAP       | Current | Section 6.2 |
               +-----------+---------+-------------+
               | LINKREL   | Current | Section 6.1 |
               +-----------+---------+-------------+

                                  Table 2

11.3. iCalendar Value Data Type Registrations 🦋

Next up, these names got added to the iCalendar "Value Data Types" registry 🌈, which lives in Section 8.3.4 of [RFC5545]. Wait, the section title says "property parameter names" even though we're doing value data types, so just know the registry is the thing we're adding to 🙈 Here's the table:

             +=================+=========+===========+
             | Value Data Type | Status  | Reference |
             +=================+=========+===========+
             | XML-REFERENCE   | Current | Section 7 |
             +-----------------+---------+-----------+
             | UID             | Current | Section 7 |
             +-----------------+---------+-----------+

                                  Table 3

11.4. iCalendar RELTYPE Value Registrations 💜

Now the big one 😭 These iCalendar "RELTYPE" values got added to the iCalendar "Relationship Types" registry, defined in Section 8.3.8 of [RFC5545]. Look at all these relationship types, it's giving organized chaos 🧚

            +===================+=========+===========+
            | Relationship Type | Status  | Reference |
            +===================+=========+===========+
            | CONCEPT           | Current | Section 5 |
            +-------------------+---------+-----------+
            | DEPENDS-ON        | Current | Section 5 |
            +-------------------+---------+-----------+
            | FINISHTOFINISH    | Current | Section 4 |
            +-------------------+---------+-----------+
            | FINISHTOSTART     | Current | Section 4 |
            +-------------------+---------+-----------+
            | FIRST             | Current | Section 5 |
            +-------------------+---------+-----------+
            | NEXT              | Current | Section 5 |
            +-------------------+---------+-----------+
            | REFID             | Current | Section 5 |
            +-------------------+---------+-----------+
            | STARTTOFINISH     | Current | Section 4 |
            +-------------------+---------+-----------+
            | STARTTOSTART      | Current | Section 4 |
            +-------------------+---------+-----------+

                                  Table 4

12. References 📚

12.1. Normative References 💖

These are the references the spec needs in order to make sense, so no skipping 🙅‍♀️

12.2. Informative References 🌸

These ones are extra reading, fun to browse but not required 🫶

Acknowledgements 🎀

The author would like to thank the members of CalConnect, the Calendaring and Scheduling Consortium technical committees, and the following individuals for contributing their ideas, support, and comments:

Adrian Apthorp, Cyrus Daboo, Marten Gajda, and Ken Murchison

The author would also like to thank CalConnect and the Calendaring and Scheduling Consortium for advice with this specification. Honestly, the whole village showed up for this one 🥹✨

Author's Address 💌

Michael Douglass
Bedework
226 3rd Street
Troy, NY 12180
United States of America
Email: mdouglass@bedework.com
URI:   https://bedework.com
📦 where this page comes from