New Properties for iCalendar
updates
- rfc-5545 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Extracted elements (34)
All new properties not defined in RFC 5545 should always include a VALUE parameter when the type is other than TEXT. This avoids parser ambiguity where a generator unaware of the property's default type might incorrectly apply backslash escaping (e.g., treating a URI with a comma as TEXT).
This document updates RFC 5545 by extending the applicability of DESCRIPTION, UID, LAST-MODIFIED, URL, and CATEGORIES to the VCALENDAR object level. Implementations not aware of RFC 7986 will ignore these properties at the VCALENDAR level, which is safe due to iCalendar's extensibility rules.
Calendar user agents SHOULD use the EMAIL parameter value for the contact's email address over any mailto: calendar user address in the property value. Calendar user agents SHOULD NOT include an EMAIL parameter when its value matches the property's calendar user address.
Clients MUST expect to find the LABEL property parameter present on many different properties, as it is anticipated for reuse in future iCalendar extensions.
Clients SHOULD honor the REFRESH-INTERVAL value when periodically retrieving data from the SOURCE URI.
Each NAME property MUST represent the name of the calendar in a different language when multiple instances appear in an iCalendar object.
If calendar user agents use opaque identifiers for UID values, they MUST have a length less than 255 octets and MUST conform to the 'iana-token' ABNF syntax defined in Section 3.1 of RFC 5545.
In the absence of the DISPLAY parameter, the default value BADGE MUST be used. Servers and clients MUST handle unrecognized x-name and iana-token values by not displaying any image at all.
The value of REFRESH-INTERVAL SHOULD be used by calendar user agents to limit polling interval for calendar data updates to no less than the specified minimum.
UID values MUST NOT include any data that might identify a user, host, domain, or any other security- or privacy-sensitive information. It is RECOMMENDED to generate UID values as hex-encoded random UUID values per RFC 4122 Sections 4.4 and 4.5.
When multiple IMAGE properties are present, calendar user agents SHOULD display only one of them, selecting the most appropriate image quality, or display none.
A publisher can uniquely identify each subscriber by assigning different REFRESH-INTERVAL values and tracking refresh timing and IP addresses. To mitigate this, clients SHOULD add or subtract a random amount of time from the published REFRESH-INTERVAL when performing actual refreshes.
Access to external URIs referenced by new properties can be tracked, compromising subscriber privacy. Calendar publishers wishing to protect privacy MUST use HTTPS (not HTTP) for calendar and ancillary data access. Clients SHOULD obtain user permission before dereferencing external URIs.
Conferencing systems accessed via the CONFERENCE property may log user activity and participation. Calendar user agents SHOULD track which conferencing systems are used and warn users the first time a new one is about to be accessed, especially when the client auto-dials in at event start.
The CATEGORIES property is extended to apply at the VCALENDAR object level, defining categories for the entire calendar. Multiple instances are permitted; the effective category set is the union of all listed values.
The COLOR property (new) specifies a display color for a calendar or calendar component (VEVENT, VTODO, VJOURNAL). Its value is a case-insensitive CSS3 color name from W3C CSS Color Module Level 3. It may appear at most once per context.
The CONFERENCE property (new) specifies a URI for accessing a conferencing system for attendees of a VEVENT or VTODO. Value type is URI (no default, VALUE=URI required). Supports FEATURE and LABEL parameters. Multiple instances are permitted.
The DESCRIPTION property is extended to apply at the VCALENDAR object level, providing a lengthy textual description of the calendar. Multiple instances are permitted, each representing a different language variant.
The DISPLAY property parameter specifies how an image should be presented: BADGE (inline with event title, default), GRAPHIC (full image replacement), FULLSIZE (image enhancing the event), or THUMBNAIL (constrained-space variant). Default is BADGE when parameter is absent.
The EMAIL property parameter specifies an email address for identifying or contacting an ORGANIZER or ATTENDEE when the calendar user address is not a recognizable identifier (e.g., an opaque token). Its value is a plain email address.
The FEATURE property parameter describes capabilities of a conference system on a CONFERENCE property. Values include AUDIO, CHAT, FEED, MODERATOR, PHONE, SCREEN, VIDEO, plus extensible x-name and iana-token values. Multiple values may be specified.
The IMAGE property (new) specifies an image associated with a calendar or calendar component via a URI or inline BASE64-encoded binary data. The value MUST be of media type 'image'. Multiple instances may be present to offer alternative images at varying resolutions or subtypes.
The LABEL property parameter provides a human-readable label for a CONFERENCE property (and anticipated future properties). It supports the LANGUAGE parameter for language tagging of the label text.
The LAST-MODIFIED property is extended to apply at the VCALENDAR object level, specifying the date and time the calendar information was last revised. It can appear at most once.
The NAME property specifies the name of the calendar (VCALENDAR object). It is TEXT-typed, may appear multiple times (once per language variant using the LANGUAGE parameter), and supports ALTREP and LANGUAGE parameters.
The REFRESH-INTERVAL property (new) specifies a suggested minimum polling interval for retrieving updated calendar data. Its value type is DURATION (no default, so VALUE=DURATION parameter is required), and it may appear at most once in a VCALENDAR object.
The SOURCE property (new) identifies a URI from which calendar data can be refreshed. Its value type is URI (no default, VALUE=URI required). It may appear at most once and differs from URL in that SOURCE is the origin location of the data.
The UID property is extended to apply at the VCALENDAR object level, providing a persistent, globally unique identifier for the iCalendar object. It can be used to detect duplicate calendar streams and, combined with LAST-MODIFIED, identify the most recent version.
The URL property is extended to apply at the VCALENDAR object level, conveying a location where a more dynamic rendition of the calendar information can be found. It differs from SOURCE in that URL is an alternative representation, not the origin location.
IANA created two new iCalendar registries: 'Display Types' (initial values: BADGE, GRAPHIC, FULLSIZE, THUMBNAIL) and 'Feature Types' (initial values: AUDIO, CHAT, FEED, MODERATOR, PHONE, SCREEN, VIDEO). New values may be added per RFC 5545 Sections 8.2.1 and 8.2.6.
This document registers eleven iCalendar properties in the RFC 5545 'Properties' registry: NAME, REFRESH-INTERVAL, SOURCE, COLOR, IMAGE, CONFERENCE (new), and updated entries for DESCRIPTION, UID, LAST-MODIFIED, URL, and CATEGORIES.
This document registers four new iCalendar property parameters in the RFC 5545 'Parameters' registry: DISPLAY, EMAIL, FEATURE, and LABEL.
A short REFRESH-INTERVAL value could be used to cause rapid polling, leading to denial-of-service attacks against servers. Clients MUST throttle requests; if REFRESH-INTERVAL is shorter than once per day, clients SHOULD warn the user and allow them to override with a longer value.
Properties and parameters referencing external URIs (SOURCE, IMAGE, CONFERENCE, etc.) can carry malicious content. Clients MUST ensure suitable user permission before dereferencing such URIs, MUST throttle REFRESH-INTERVAL-driven requests to a reasonable rate, and MUST NOT send MODERATOR CONFERENCE properties to attendees.