Internet-Draft | iCalendar JSCalendar Extensions | July 2022 |
Stepanek & Douglass | Expires 12 January 2023 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 January 2023.¶
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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
The JSCalendar [RFC8984] format aims to be an alternative to the iCalendar [RFC5545] 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 [ref-jscalendar-icalendar] 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.¶
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.¶
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.¶
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)¶
COMP-ID:m2398¶
VEVENT
, VTODO
or VJOURNAL
calendar components.¶
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)¶
SHOW-WITHOUT-TIME:TRUE¶
This specification modifies the definition of the GEO
property
to allow storing spatial positions in form of URIs using the geo:
scheme [RFC5870]. The following additions are made to the
definition of this property, original specified in
Section 3.8.1.6 of [RFC5545].¶
geo:
encoded coordinates.¶
geo:
scheme, then the VALUE
property parameter MUST be set to URI
.¶
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 components¶
GEO:37.386013;-122.082932 GEO;VALUE=URI:geo:48.198634,16.371648;crs=wgs84;u=40¶
cid-param = "CONTENT-ID" "=" DQUOTE uri DQUOTE ; uri must be a cid-url defined in RFC 8288¶
STYLED-DESCRIPTION
property as specified in Section 6.5 of [RFC9073], 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.¶
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>¶
inviteby-param = "INVITED-BY" "=" DQUOTE cal-address DQUOTE¶
ATTENDEE
property to the calendar component.¶
ATTENDEE;INVITED-BY="inviter@example.com":invitee@example.com¶
linkrel-param = "LINK-REL" "=" paramtext ; one of Link Relation Types registered in ; the IANA Link Relations Registry (RFC 8288)¶
ATTACH;LINK-REL=payment:https://example.com/donate¶
prop-id-param = "PROP-ID" "=" 1*255(ALPHA / DIGIT / "-"/ "_")¶
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.¶
ATTACH;PROP-ID=a983:https://example.com/something¶
This section will be filled at a later stage.¶
This section will be filled at a later stage.¶