iCalendar extension properties and parameters with 'X-' prefixes are handled identically to standard properties and parameters: the property is an array, the parameter is in the params object, and the name is lowercased. This ensures extensions need no special-casing and jCal need not be updated for new extensions.

json

jCal is designed so that round-tripping — converting an iCalendar instance to jCal and back — preserves all semantic meaning, including all components, properties, and property parameters. Ordering of elements and case of property/parameter names need not be preserved, but semantic data must be.

json

There is no defined equivalent to an iCalendar stream in jCal because the typical use case is transporting a single iCalendar object. To transport multiple jCal objects in a stream, a simple JSON array is used.

json

When converting component, property, and parameter names from jCal to iCalendar, names SHOULD be converted to uppercase to follow common iCalendar practice, even though iCalendar names are case insensitive.

json

Any iCalendar property without a VALUE parameter whose default value type is not known MUST be converted to a primitive JSON string with the raw unprocessed value text, and the value type MUST be set to 'unknown'. Using 'text' instead risks incorrect escaping that breaks round-tripping.

json

Any unrecognized iCalendar property parameter MUST be converted to a string value with its content set to the property parameter value text, treated as if it were a TEXT value.

json

For properties with ENCODING=BASE64: if the value type is BINARY, the base64 encoding MUST be preserved; if the value type is not BINARY, the ENCODING parameter MUST be removed and the value MUST be base64 decoded. Base64 encoding MUST conform to RFC 4648 Section 4.

json

Multi-value iCalendar parameters (COMMA-separated lists) MUST be represented in jCal as an array of string values. A jCal parser MUST be able to understand both a single string value and an array with one string element for single-value parameters.

json

Parameter names in jCal MUST be in lowercase; the original case of parameter values MUST be preserved. For example, the PARTSTAT parameter becomes the 'partstat' key in the JSON parameters object.

json

Property names in jCal MUST be in lowercase. The iCalendar format specifies property names are case insensitive and recommends uppercase, but jCal mandates lowercase for all property names.

json

The iCalendar VALUE property parameter MUST NOT be added to the jCal parameters object. Instead, the value type is signaled through the type identifier string in the third element of the property array.

json

The 'unknown' value type MUST NOT be used in any iCalendar data as specified by RFC 5545 or any extensions. When converting jCal with type 'unknown' to iCalendar, the VALUE parameter MUST NOT be specified and the value MUST be copied without processing.

json, registry

When converting from iCalendar to jCal, lines MUST first be unfolded, then iCalendar escaping MUST be unescaped, and finally JSON escaping MUST be applied. The reverse order applies when converting from jCal to iCalendar.

json

When converting from jCal to iCalendar, JSON escaping MUST be unescaped first, then iCalendar escaping (per RFC 5545 and RFC 6868) MUST be applied, and long lines SHOULD be folded per RFC 5545 Section 3.1. Non-binary value types MUST NOT be base64 encoded.

json

jCal introduces an 'unknown' property value type to allow preserving unknown property values during round-tripping between jCal and iCalendar. When a converter does not know the default value type of a property, it uses 'unknown' and stores the raw unprocessed value as a JSON string.

json

IANA added the 'UNKNOWN' entry to the iCalendar Value Data Types registry, marked 'Reserved - Do not use', exclusively for jCal round-tripping of properties whose default value type is not known. It MUST NOT appear in native iCalendar data.

json, registry

This document registers the 'application/calendar+json' MIME media type for transfer of iCalendar data in JSON format. Optional parameters 'method', 'component', and 'optinfo' are inherited from text/calendar (RFC 5545 Section 8.1).

json, registry

jCal does not change the semantic meaning of underlying iCalendar data, so all security considerations from RFC 5545 Section 7 and any iCalendar extensions remain applicable. Wider dissemination of calendar data through web applications may increase exposure to these risks.

json, security

Using JavaScript's eval() to process jCal JSON data is an unacceptable security risk as noted in RFC 7159 Section 12. A native JSON parser with full awareness of the JSON format should be preferred. JSON parsing flaws can introduce threats not present with conventional iCalendar data.

json, security

A jCal component is a fixed-length JSON array with three fields: (1) a lowercase string with the component name, (2) an array of jCal properties, and (3) an array of sub-components. This applies to top-level VCALENDAR objects and all sub-components.

json

A jCal property is a JSON array with three fixed elements — lowercase property name string, parameters object, and value type identifier string — followed by one or more value elements. Multi-valued properties have one element per value beyond the fixed three.

json

iCalendar DATE-TIME values are encoded in jCal as JSON strings using the ISO 8601 extended complete representation format YYYY-MM-DDTHH:MM:SS[zone]. Reduced accuracy variations MUST NOT be used; leap second and time zone offset restrictions from RFC 5545 still apply.

json

iCalendar DATE values are encoded in jCal as JSON strings using the ISO 8601 extended complete representation format YYYY-MM-DD. Reduced accuracy and other variations MUST NOT be used.

json

iCalendar PERIOD values are encoded in jCal as an array of two JSON strings: the start (always a date-time) and end (a date-time or duration). All contained date, date-time, or duration values MUST follow the jCal formatting rules for those types.

json

iCalendar RECUR values are encoded as jCal JSON objects with lowercase rule-part keys. The 'freq' and 'wkst' values are strings with case preserved; 'until' is a date or date-time string; 'count' and 'interval' are JSON numbers; numeric rule parts with multiple values use JSON number arrays.

json

iCalendar TIME values are encoded in jCal as JSON strings using the ISO 8601 extended complete representation format HH:MM:SS[zone]. Reduced accuracy and other variations MUST NOT be used.

json

iCalendar UTC-OFFSET values are encoded in jCal as JSON strings matching the ISO 8601 time zone offset extended format, with a ':' separating hours and minutes (e.g., '-05:00', '+12:45'), unlike iCalendar's undelimited format.

json

The iCalendar GEO property is represented in jCal as an array of two JSON float numbers: the first is latitude and the second is longitude. When converting back to iCalendar, the two values MUST be joined with a semicolon separator.

json

The iCalendar REQUEST-STATUS property is represented in jCal as an array of two or three string values: status code, description, and optional additional data. The third element SHOULD NOT be present if there is no additional data.

json