Abstract
This document defines a set of new properties for iCalendar and extends the use of existing ones. Their primary purpose is to align the same set of features between the JSCalendar and iCalendar formats, but the new definitions also aim to be useful within just the iCalendar format.
Introduction
The JSCalendar IETF RFC 8984 format aims to be an alternative to the iCalendar IETF RFC 5545 format for representation of calendar data. As such, it introduces new semantics that are not covered in the current definition of iCalendar and its extensions. Converting calendar data between the two formats is defined in Internet-Draft draft-ietf-calext-jscalendar-icalendar-00 with the goal of not loosing any semantics during conversion. In order to do so, this document defines a new set of properties for iCalendar and extends existing definitions.
Requirements Language
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 IETF RFC 2119 IETF RFC 8174 when, and only when, they appear in all capitals, as shown here.
Preface
This document is a work in progress. The list of new or updated properties and parameters is likely to be incomplete. This section is removed from the document before publication.
iCalendar Format Extension for JSCalendar
2. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
IETF RFC 2119, S. BRADNER. Key words for use in RFCs to Indicate Requirement Levels. 1997. RFC Publisher. https://www.rfc-editor.org/info/rfc2119.
IETF RFC 5545, B. DESRUISSEAUX (ed.). Internet Calendaring and Scheduling Core Object Specification (iCalendar). 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5545.
IETF RFC 5870, A. MAYRHOFER and C. SPANRING. A Uniform Resource Identifier for Geographic Locations (’geo’ URI). 2010. RFC Publisher. https://www.rfc-editor.org/info/rfc5870.
IETF RFC 8174, B. LEIBA. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. 2017. RFC Publisher. https://www.rfc-editor.org/info/rfc8174.
IETF RFC 8288, M. NOTTINGHAM. Web Linking. 2017. RFC Publisher. https://www.rfc-editor.org/info/rfc8288.
IETF RFC 8984, N. JENKINS and R. STEPANEK. JSCalendar: A JSON Representation of Calendar Data. 2021. RFC Publisher. https://www.rfc-editor.org/info/rfc8984.
IETF RFC 9073, M. DOUGLASS. Event Publishing Extensions to iCalendar. 2021. RFC Publisher. https://www.rfc-editor.org/info/rfc9073.
3. Terms and definitions
No terms and definitions are listed in this document.
4. New Properties
4.1. COMP-ID Property
Property name
COMP-ID
Purpose
This property uniquely identifies a component among all its siblings of the same type.
Value type
TEXT, also see Format Definition for value restrictions.
Conformance
The property can be specified once in a calendar component.
Property parameters
IANA and non-standard property parameters can be specified on this property.
Description
A calendar component may embed multiple components of the same type. For example, a VEVENT component may embed multiple VALARM components. To distinguish these VALARMs among all global instances of VALARM calendar components, an application may choose to assign a uniquely global UID to each of them. However, some applications or formats such as JSCalendar, do not require globally uniqueness. Instead, they only require uniqueness among all instances of calendar components within one parent component. This is what the COMP-ID property is for.
The COMP-ID property identifies a component among all of its siblings of the same type. A valid COMP-ID value must be of 1 and a maximum of 255 octets in size, and it MUST only contain the ASCII alphanumeric characters ( A-Za-z0-9), hyphen (-), and underscore (_). The identifier only has the purpose to uniquely identify siblings, its value has no other meaning. If an application makes use of COMP-ID it SHOULD assign a unique identifier to each sibling component of the same type within their parent component. The same identifier MAY be used for components of a different type, and it MAY also be assigned to a same-typed component that is not a sibling.
Resolving duplicate identifier conflicts is specific to the application. Similarly, handling components where some but not all siblings have a COMP-ID is assigned, is application-specific.
Format definition
This property is defined by the following notation:
comp-id = "COMP-ID" comp-id-param ":" comp-id-value CRLF
comp-id-value = 1*255(ALPHA / DIGIT / "-"/ "_")
comp-id-param = *(";" other-param)Example(s)
COMP-ID:m2398
4.2. SHOW-WITHOUT-TIME Property
Property name
SHOW-WITHOUT-TIME
Purpose
This property indicates if an event or task should be displayed with time information.
Value type
BOOLEAN
Conformance
The property can be specified once in the VEVENT, VTODO or VJOURNAL calendar components.
Property parameters
IANA and non-standard property parameters can be specified on this property.
Description
This indicates that the time is not important to display to the user when rendering this calendar object. An example of this is an event that conceptually occurs all day or across multiple days, such as “New Year’s Day” or “Italy Vacation”. While the time component is important for free-busy calculations and checking for scheduling clashes, calendars may choose to omit displaying it and/or display the object separately to other objects to enhance the user’s view of their schedule.
Format definition
This property is defined by the following notation:
show-without-time = "SHOW-WITHOUT-TIME" show-without-time-param
":" boolean CRLF
show-without-time-param = *(";" other-param)Example(s)
SHOW-WITHOUT-TIME:TRUE
5. Updated Properties
5.1. GEO Property
This specification modifies the definition of the GEO property to allow storing spatial positions in form of URIs using the geo: scheme IETF RFC 5870. The following additions are made to the definition of this property, original specified in IETF RFC 5545, Section 3.8.1.6.
Value type
The default value type is FLOAT, where the value MUST be two SEMICOLON-separated FLOAT values. The value type can also be set to URI to indicate geo: encoded coordinates.
Property parameters
VALUE
Description
When the property value is a URI in the geo: scheme, then the VALUE property parameter MUST be set to URI.
Format definition
This property is defined by the following notation:
geo = "GEO" geoparam ( ":" geovalue ) /
(
";" "VALUE" "=" "URI"
":" uri ; uri MUST be in the geo: scheme
)
CRLF
geoparam = *(";" other-param)
geovalue = float ";" float
;Latitude and Longitude componentsExample(s)
GEO:37.386013;-122.082932
GEO;VALUE=URI:geo:48.198634,16.371648;crs=wgs84;u=40
6. New Parameters
6.1. CONTENT-ID Parameter
Parameter name
CONTENT-ID
Purpose
This parameter identifies an attachment contents for use with styled descriptions.
Format definition
cid-param = "CONTENT-ID" "=" DQUOTE uri DQUOTE
; uri must be a cid-url defined in <<RFC8288>>Description
This parameter MAY be set on an “ATTACH” or “IMAGE” property. It assigns the property an identifier that MUST be unique within the calendar component. A calendar component MAY include a STYLED-DESCRIPTION property as specified in IETF RFC 9073, Section 6.5, and MAY contain HTML text. URLs in the “cid:” scheme referred to by images and other data within that HTML description can be resolved to calendar component attachments having that content-id.
Example(s)
IMAGE;CONTENT-ID="cid:foo@bar.net":
data:image/jpeg;base64,SGVsbG8sIFdvcmxk..
STYLED-DESCRIPTION;VALUE=TEXT;FMTTYPE=text/html:
<html><body><img src="cid:foo@bar.net" alt="foo"/></body></html>
6.2. INVITED-BY Parameter
Parameter name
INVITED-BY
Purpose
This parameter specifies which calendar address user invited another.
Format definition
inviteby-param = "INVITED-BY" "=" DQUOTE cal-address DQUOTE
Description
This parameter MAY be set on an “ATTENDEE” property, specified in IETF RFC 5545, Section 3.8.4.1. If set, it identifies the participant that invited the calendar user represented by the ATTENDEE property to the calendar component.
Example(s)
ATTENDEE;INVITED-BY="inviter@example.com":invitee@example.com
6.3. LINK-REL Parameter
Parameter name
LINK-REL
Purpose
This parameter defines how an attachment relates to calendar component.
Format definition
linkrel-param = "LINK-REL" "=" paramtext
; one of Link Relation Types registered in
; the IANA Link Relations Registry (<<RFC8288>>)Description
This parameter MAY be set on an “ATTACH” or “IMAGE” property. It indicates how the contents of the attachment or image relate to the calendar component this property is part of. For the list of available relations, see the Link Relation Types in the IANA Link Relations Registry IETF RFC 8288.
Example(s)
ATTACH;LINK-REL=payment:https://example.com/donate
6.4. PROP-ID Parameter
Parameter name
PROP-ID
Purpose
This parameter identifies a property among all its siblings of the same type.
Format definition
prop-id-param = "PROP-ID" "=" 1*255(ALPHA / DIGIT / "-"/ "_")
Description
This parameter uniquely identifies a property among all of its siblings with the same name within a calendar component. A valid PROP-ID value must be of 1 and a maximum of 255 octets in size, and it MUST only contain the ASCII alphanumeric characters ( A-Za-z0-9), hyphen ( -), and underscore (_). The identifier only has the purpose to uniquely identify siblings, its value has no other meaning. If an application makes use of PROP-ID it SHOULD assign a unique identifier to each sibling property of the same name within their embedding component. The same identifier MAY be used for properties of a different name, and it MAY also be assigned to a same-named property that is not a sibling.
Resolving duplicate identifier conflicts is specific to the application. Similarly, handling properties where some but not all siblings have a PROP-ID is assigned, is application-specific.
Example(s)
ATTACH;PROP-ID=a983:https://example.com/something
7. Security Considerations
This section will be filled at a later stage.
8. IANA Considerations
This section will be filled at a later stage.
Bibliography
[1] Internet-Draft draft-ietf-calext-jscalendar-icalendar-00, NEIL JENKINS and ROBERT STEPANEK. JSCalendar: Converting from and to iCalendar. 2019. https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-icalendar-00.