The STRUCTURED-DATA property was introduced instead of extending the existing ATTACH property, because ATTACH does not allow TEXT value types, attachments are often treated as opaque data, and extending ATTACH to support a new value type would likely cause interoperability problems. Some implementations also strip attachments and replace them with links.

This specification defines new iCalendar components (PARTICIPANT, VLOCATION, VRESOURCE) rather than properties, breaking with prior convention. Components are a better match for how XML and JSON handle such structures, allow richer definitions, and permit the addition of extra properties inside the components.

json

A PARTICIPANT component is schedulable only if it contains a CALENDAR-ADDRESS property whose value exactly matches the value of an ATTENDEE property in the same calendar component. Without this match, the participant does not take part in iTIP scheduling operations.

Previous iCalendar libraries had trouble handling components nested deeper than those defined in RFC 5545. This specification introduces nested components (PARTICIPANT, VLOCATION, VRESOURCE inside VEVENT/VTODO/VJOURNAL/VFREEBUSY), which may require library updates for correct handling.

The LOCATION-TYPE property references values defined in RFC 4589 (Location Types Registry); new location types SHOULD be registered per RFC 4589 Section 5 rather than inventing private values.

registry

Clients MUST ignore STYLED-DESCRIPTION properties with value types they do not understand.

Clients SHOULD NOT follow URIs and fetch content automatically; they should only do so at the explicit request of the user, due to risks including IP/location exposure and potential denial-of-service amplification.

security, privacy

For backwards compatibility with existing clients and servers for scheduling, the ATTENDEE property MUST be used to specify scheduling parameters; for other future uses, CALENDAR-ADDRESS MUST be used.

For STRUCTURED-DATA properties with TEXT or inline BINARY values, the FMTTYPE and SCHEMA parameters MUST be present.

New PARTICIPANT-TYPE and RESOURCE-TYPE tokens MUST follow the character set restrictions for XML Names to ensure widespread usability across protocols.

registry

Servers SHOULD check the STRUCTURED-DATA property for malicious or inappropriate content and, upon detecting such content, SHOULD remove the property to prevent propagation via scheduling.

security

The PARTICIPANT-TYPE property MUST be specified exactly once within a PARTICIPANT component.

User agents MUST NOT broadcast participant location information (from a LOCATION property inside PARTICIPANT) without the express permission of the participants whose location would be exposed.

privacy

When DERIVED=TRUE is present on a property, clients MUST NOT update that property.

When STYLED-DESCRIPTION appears more than once, there MUST be exactly one instance with no DERIVED parameter or DERIVED=FALSE; all others MUST have DERIVED=TRUE.

Location information inside a PARTICIPANT component reveals where an individual will be at a future time, potentially enabling targeted attacks. This information MUST NOT be distributed without the participant's express permission, and agents should reveal only the minimum necessary.

privacy

Properties with URI values expose users to privacy leaks: any network access can be tracked by network observers and by the entity hosting the remote resource. Clients SHOULD NOT automatically download URI-referenced data without explicit user instruction; proxy services are recommended to mitigate this.

privacy

The CALENDAR-ADDRESS property specifies a cal-address for a participant. If this value matches an ATTENDEE property value, the participant is considered schedulable and subject to iTIP scheduling operations.

The DERIVED parameter (TRUE/FALSE, default FALSE) indicates that a property value is derived from another property. When DERIVED=TRUE, clients MUST NOT update the property. It enables multiple STYLED-DESCRIPTION instances where all but one are derived.

The ORDER parameter (integer >= 1) indicates the relative ordering of multiple instances of the same property. When absent, the property instance is treated as ordered last. It MUST NOT be applied to properties that do not allow multiple instances.

The PARTICIPANT component provides information about a participant in a VEVENT, VTODO, VJOURNAL, or VFREEBUSY component. PARTICIPANT-TYPE and UID are required; CALENDAR-ADDRESS, GEO, STYLED-DESCRIPTION, STRUCTURED-DATA, and nested VLOCATION/VRESOURCE sub-components are optional.

The PARTICIPANT-TYPE property specifies the role of a participant in an event. Defined values include ACTIVE, INACTIVE, SPONSOR, CONTACT, BOOKING-CONTACT, EMERGENCY-CONTACT, PUBLICITY-CONTACT, PLANNER-CONTACT, PERFORMER, SPEAKER, and IANA-registered extensions. It MUST appear exactly once in a PARTICIPANT component.

registry

The SCHEMA parameter specifies the schema URI for the content of a STRUCTURED-DATA property, supplementing the media type given by FMTTYPE. Its value is a double-quoted URI.

The STRUCTURED-DATA property specifies ancillary schema-based data associated with a calendar component. Its value may be TEXT, BINARY (BASE64-encoded), or URI. For TEXT or BINARY values, the FMTTYPE and SCHEMA parameters MUST be present.

json, registry

The STYLED-DESCRIPTION property provides one or more rich-text descriptions (e.g., HTML, RTF) replacing or supplementing the plain-text DESCRIPTION property. VALUE must be URI or TEXT; FMTTYPE, DERIVED, and LANGUAGE parameters are supported.

The VLOCATION component provides rich structured information about a location associated with an event, such as venue, parking, or dining. UID is required; NAME, GEO, LOCATION-TYPE, and STRUCTURED-DATA are optional. It may be nested inside VEVENT, VTODO, VJOURNAL, VFREEBUSY, or PARTICIPANT.

The VRESOURCE component provides a typed reference to a resource (e.g., room, projector, conferencing equipment) used by an event. UID is required; NAME, GEO, RESOURCE-TYPE, and STRUCTURED-DATA are optional. It may appear in VEVENT, VTODO, VJOURNAL, VFREEBUSY, or PARTICIPANT.

This document adds six properties to the iCalendar Properties registry (RFC 5545, Section 8.2.3): CALENDAR-ADDRESS, LOCATION-TYPE, PARTICIPANT-TYPE, RESOURCE-TYPE, STRUCTURED-DATA, and STYLED-DESCRIPTION.

registry

This document adds three components to the iCalendar Components registry (RFC 5545, Section 8.3.1): PARTICIPANT, VLOCATION, and VRESOURCE.

registry

This document adds three parameters to the iCalendar Parameters registry (RFC 5545, Section 8.2.4): ORDER, SCHEMA, and DERIVED.

registry

This document creates a new IANA Participant Types registry with Expert Review policy. Initial values: ACTIVE, INACTIVE, SPONSOR, CONTACT, BOOKING-CONTACT, EMERGENCY-CONTACT, PUBLICITY-CONTACT, PLANNER-CONTACT, PERFORMER, SPEAKER.

registry

This document creates a new IANA Resource Types registry with Expert Review policy. Initial values: PROJECTOR, ROOM, REMOTE-CONFERENCE-AUDIO, REMOTE-CONFERENCE-VIDEO.

registry

A maliciously constructed iCalendar object may contain a very large number of URIs; in published calendars with many subscribers, this could become a denial-of-service amplification vector. Implementations should limit automatic fetching of linked resources.

security

The STRUCTURED-DATA property can be abused to attack storage (via extremely large values) or processing time (via recurring events with many overrides combined with rapid add/update/delete). Agents should set and enforce reasonable limits on storage size and instance count.

security