draft-ietf-calext-jscalendar-12.txt   draft-ietf-calext-jscalendar-13.txt 
Calendaring extensions N. Jenkins Calendaring extensions N. Jenkins
Internet-Draft R. Stepanek Internet-Draft R. Stepanek
Intended status: Standards Track FastMail Intended status: Standards Track FastMail
Expires: September 6, 2019 March 5, 2019 Expires: November 3, 2019 May 2, 2019
JSCalendar: A JSON representation of calendar data JSCalendar: A JSON representation of calendar data
draft-ietf-calext-jscalendar-12 draft-ietf-calext-jscalendar-13
Abstract Abstract
This specification defines a data model and JSON representation of This specification defines a data model and JSON representation of
calendar data that can be used for storage and data exchange in a calendar data that can be used for storage and data exchange in a
calendaring and scheduling environment. It aims to be an alternative calendaring and scheduling environment. It aims to be an alternative
to the widely deployed iCalendar data format and to be unambiguous, to the widely deployed iCalendar data format and to be unambiguous,
extendable and simple to process. In contrast to the JSON-based jCal extendable and simple to process. In contrast to the JSON-based jCal
format, it is not a direct mapping from iCalendar and expands format, it is not a direct mapping from iCalendar and expands
semantics where appropriate. semantics where appropriate.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2019. This Internet-Draft will expire on November 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Relation to the iCalendar format . . . . . . . . . . . . 5 1.1. Relation to the iCalendar format . . . . . . . . . . . . 4
1.2. Relation to the jCal format . . . . . . . . . . . . . . . 5 1.2. Relation to the jCal format . . . . . . . . . . . . . . . 5
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 5 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 5
2. JSCalendar objects . . . . . . . . . . . . . . . . . . . . . 6 2. JSCalendar objects . . . . . . . . . . . . . . . . . . . . . 5
2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Structure of JSCalendar objects . . . . . . . . . . . . . . . 6 3. Structure of JSCalendar objects . . . . . . . . . . . . . . . 6
3.1. Type signatures . . . . . . . . . . . . . . . . . . . . . 7 3.1. Type signatures . . . . . . . . . . . . . . . . . . . . . 7
3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. UTCDate . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. UTCDate . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. LocalDate . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. LocalDate . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Duration . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. Duration . . . . . . . . . . . . . . . . . . . . . . 8
3.2.4. PatchObject . . . . . . . . . . . . . . . . . . . . . 8 3.2.4. PatchObject . . . . . . . . . . . . . . . . . . . . . 8
3.2.5. Identifiers . . . . . . . . . . . . . . . . . . . . . 9 3.2.5. Identifiers . . . . . . . . . . . . . . . . . . . . . 9
3.2.6. Time Zones . . . . . . . . . . . . . . . . . . . . . 9 3.2.6. Time Zones . . . . . . . . . . . . . . . . . . . . . 9
3.2.7. Normalization and equivalence . . . . . . . . . . . . 10 3.2.7. Normalization and equivalence . . . . . . . . . . . . 9
3.3. Custom property extensions and values . . . . . . . . . . 10 3.3. Custom property extensions and values . . . . . . . . . . 10
4. Common JSCalendar properties . . . . . . . . . . . . . . . . 10 4. Common JSCalendar properties . . . . . . . . . . . . . . . . 10
4.1. Metadata properties . . . . . . . . . . . . . . . . . . . 11 4.1. Metadata properties . . . . . . . . . . . . . . . . . . . 10
4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. uid . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. uid . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.3. relatedTo . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3. relatedTo . . . . . . . . . . . . . . . . . . . . . . 11
4.1.4. prodId . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.4. prodId . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.5. created . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.5. created . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.6. updated . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.6. updated . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.7. sequence . . . . . . . . . . . . . . . . . . . . . . 13 4.1.7. sequence . . . . . . . . . . . . . . . . . . . . . . 13
4.1.8. method . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.8. method . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. What and where properties . . . . . . . . . . . . . . . . 13 4.2. What and where properties . . . . . . . . . . . . . . . . 13
4.2.1. title . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. title . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. description . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. description . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. descriptionContentType . . . . . . . . . . . . . . . 13 4.2.3. descriptionContentType . . . . . . . . . . . . . . . 13
4.2.4. locations . . . . . . . . . . . . . . . . . . . . . . 14 4.2.4. locations . . . . . . . . . . . . . . . . . . . . . . 14
4.2.5. virtualLocations . . . . . . . . . . . . . . . . . . 15 4.2.5. virtualLocations . . . . . . . . . . . . . . . . . . 15
4.2.6. links . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.6. links . . . . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 14 skipping to change at page 3, line 14
4.3.3. excluded . . . . . . . . . . . . . . . . . . . . . . 24 4.3.3. excluded . . . . . . . . . . . . . . . . . . . . . . 24
4.4. Sharing and scheduling properties . . . . . . . . . . . . 24 4.4. Sharing and scheduling properties . . . . . . . . . . . . 24
4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 24 4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 24
4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 25 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 25
4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 25 4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 25
4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 26 4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.5. participants . . . . . . . . . . . . . . . . . . . . 26 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 26
4.5. Alerts properties . . . . . . . . . . . . . . . . . . . . 30 4.5. Alerts properties . . . . . . . . . . . . . . . . . . . . 30
4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 30 4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 30
4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 30 4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 30
4.6. Multilingual properties . . . . . . . . . . . . . . . . . 31 4.6. Multilingual properties . . . . . . . . . . . . . . . . . 32
4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 31 4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 32
4.7. Time zone properties . . . . . . . . . . . . . . . . . . 33 4.7. Time zone properties . . . . . . . . . . . . . . . . . . 33
4.7.1. timeZones . . . . . . . . . . . . . . . . . . . . . . 33 4.7.1. timeZones . . . . . . . . . . . . . . . . . . . . . . 33
5. Type-specific JSCalendar properties . . . . . . . . . . . . . 34 5. Type-specific JSCalendar properties . . . . . . . . . . . . . 34
5.1. JSEvent properties . . . . . . . . . . . . . . . . . . . 34 5.1. JSEvent properties . . . . . . . . . . . . . . . . . . . 34
5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 34 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.2. timeZone . . . . . . . . . . . . . . . . . . . . . . 34 5.1.2. timeZone . . . . . . . . . . . . . . . . . . . . . . 35
5.1.3. duration . . . . . . . . . . . . . . . . . . . . . . 35 5.1.3. duration . . . . . . . . . . . . . . . . . . . . . . 35
5.1.4. isAllDay . . . . . . . . . . . . . . . . . . . . . . 35 5.1.4. isAllDay . . . . . . . . . . . . . . . . . . . . . . 35
5.1.5. status . . . . . . . . . . . . . . . . . . . . . . . 35 5.1.5. status . . . . . . . . . . . . . . . . . . . . . . . 36
5.2. JSTask properties . . . . . . . . . . . . . . . . . . . . 36 5.2. JSTask properties . . . . . . . . . . . . . . . . . . . . 36
5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.2. start . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2.2. start . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.3. timeZone . . . . . . . . . . . . . . . . . . . . . . 36 5.2.3. timeZone . . . . . . . . . . . . . . . . . . . . . . 36
5.2.4. estimatedDuration . . . . . . . . . . . . . . . . . . 36 5.2.4. estimatedDuration . . . . . . . . . . . . . . . . . . 37
5.2.5. statusUpdatedAt . . . . . . . . . . . . . . . . . . . 36 5.2.5. statusUpdatedAt . . . . . . . . . . . . . . . . . . . 37
5.2.6. isAllDay . . . . . . . . . . . . . . . . . . . . . . 37 5.2.6. isAllDay . . . . . . . . . . . . . . . . . . . . . . 37
5.2.7. progress . . . . . . . . . . . . . . . . . . . . . . 37 5.2.7. progress . . . . . . . . . . . . . . . . . . . . . . 37
5.2.8. status . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.8. status . . . . . . . . . . . . . . . . . . . . . . . 38
5.3. JSGroup properties . . . . . . . . . . . . . . . . . . . 38 5.3. JSGroup properties . . . . . . . . . . . . . . . . . . . 39
5.3.1. entries . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.1. entries . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.2. source . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.2. source . . . . . . . . . . . . . . . . . . . . . . . 39
6. Conversion from and to iCalendar . . . . . . . . . . . . . . 39 6. JSCalendar object examples . . . . . . . . . . . . . . . . . 40
6.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.1. Simple event . . . . . . . . . . . . . . . . . . . . . . 40
6.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.2. Simple task . . . . . . . . . . . . . . . . . . . . . . . 40
6.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.3. Simple group . . . . . . . . . . . . . . . . . . . . . . 40
6.4. Common properties . . . . . . . . . . . . . . . . . . . . 42 6.4. All-day event . . . . . . . . . . . . . . . . . . . . . . 41
6.5. Locations and participants . . . . . . . . . . . . . . . 44 6.5. Task with a due date . . . . . . . . . . . . . . . . . . 41
6.6. Unknown properties . . . . . . . . . . . . . . . . . . . 47 6.6. Event with end time-zone . . . . . . . . . . . . . . . . 42
7. JSCalendar object examples . . . . . . . . . . . . . . . . . 47 6.7. Floating-time event (with recurrence) . . . . . . . . . . 42
7.1. Simple event . . . . . . . . . . . . . . . . . . . . . . 47 6.8. Event with multiple locations and localization . . . . . 43
7.2. Simple task . . . . . . . . . . . . . . . . . . . . . . . 48 6.9. Recurring event with overrides . . . . . . . . . . . . . 44
7.3. Simple group . . . . . . . . . . . . . . . . . . . . . . 48 6.10. Recurring event with participants . . . . . . . . . . . . 45
7.4. All-day event . . . . . . . . . . . . . . . . . . . . . . 48 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7.5. Task with a due date . . . . . . . . . . . . . . . . . . 49 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
7.6. Event with end time-zone . . . . . . . . . . . . . . . . 49 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
7.7. Floating-time event (with recurrence) . . . . . . . . . . 50 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.8. Event with multiple locations and localization . . . . . 50 10.1. Normative References . . . . . . . . . . . . . . . . . . 48
7.9. Recurring event with overrides . . . . . . . . . . . . . 51 10.2. Informative References . . . . . . . . . . . . . . . . . 50
7.10. Recurring event with participants . . . . . . . . . . . . 52 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8. Security Considerations . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.1. Normative References . . . . . . . . . . . . . . . . . . 55
11.2. Informative References . . . . . . . . . . . . . . . . . 57
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
This document defines a data model for calendar event and task This document defines a data model for calendar event and task
objects, or groups of such objects, in electronic calendar objects, or groups of such objects, in electronic calendar
applications and systems. It aims to be unambiguous, extendable and applications and systems. It aims to be unambiguous, extendable and
simple to process. simple to process.
The key design considerations for this data model are as follows: The key design considerations for this data model are as follows:
skipping to change at page 14, line 16 skipping to change at page 14, line 13
_cid_ property of the _Link_ object. _cid_ property of the _Link_ object.
4.2.4. locations 4.2.4. locations
Type: "String[Location]" (optional) Type: "String[Location]" (optional)
A map of location identifiers to Location objects, representing A map of location identifiers to Location objects, representing
locations associated with the object. locations associated with the object.
A *Location* object has the following properties. It must define at A *Location* object has the following properties. It must define at
least one other property than _rel_. least one other property than _relativeTo_.
o *name*: "String" (optional, default:"") The human-readable name of o *name*: "String" (optional, default:"") The human-readable name of
the location. the location.
o *description*: "String" (optional) Human-readable, plain-text o *description*: "String" (optional) Human-readable, plain-text
instructions for accessing this location. This may be an address, instructions for accessing this location. This may be an address,
set of directions, door access code, etc. set of directions, door access code, etc.
o *rel*: "String" (optional) The relation type of this location to o *relativeTo*: "String" (optional) The relation type of this
the JSCalendar object. location to the JSCalendar object.
This MUST be either one of the following values, registered in a This MUST be either one of the following values, registered in a
future RFC, or a vendor-specific value. Any value the client or future RFC, or a vendor-specific value. Any value the client or
server doesn't understand should be treated the same as if this server doesn't understand should be treated the same as if this
property is omitted. property is omitted.
* "start": The JSCalendar object starts at this location. * "start": The JSCalendar object starts at this location.
* "end": The JSCalendar object ends at this location. * "end": The JSCalendar object ends at this location.
skipping to change at page 17, line 34 skipping to change at page 17, line 34
Specifies a color clients MAY use when displaying this calendar Specifies a color clients MAY use when displaying this calendar
object. The value is a case-insensitive color name taken from the object. The value is a case-insensitive color name taken from the
CSS3 set of names, defined in Section 4.3 of W3C.REC- CSS3 set of names, defined in Section 4.3 of W3C.REC-
css3-color-20110607 [3] or a CSS3 RGB color hex value. css3-color-20110607 [3] or a CSS3 RGB color hex value.
4.3. Recurrence properties 4.3. Recurrence properties
4.3.1. recurrenceRule 4.3.1. recurrenceRule
Type: "Recurrence" Type: "Recurrence" (optional)
Defines a recurrence rule (repeating pattern) for recurring calendar Defines a recurrence rule (repeating pattern) for recurring calendar
objects. objects.
A *Recurrence* object is a JSON object mapping of a RECUR value type A *Recurrence* object is a JSON object mapping of a RECUR value type
in iCalendar, see [RFC5545] and[RFC7529]. A JSEvent recurs by in iCalendar, see [RFC5545] and[RFC7529]. A JSEvent recurs by
applying the recurrence rule (and _recurrenceOverrides_) to the applying the recurrence rule (and _recurrenceOverrides_) to the
_start_ date/time. A JSTask recurs by applying the recurrence rule _start_ date/time. A JSTask recurs by applying the recurrence rule
(and _recurrenceOverrides_) to its _start_ date/time, if defined. If (and _recurrenceOverrides_) to its _start_ date/time, if defined. If
the task does not define a start date-time, it recurs by its _due_ the task does not define a start date-time, it recurs by its _due_
skipping to change at page 27, line 4 skipping to change at page 26, line 49
o "web": Opening this URI in a web browser will provide the user o "web": Opening this URI in a web browser will provide the user
with a page where they can submit a reply to the organizer. with a page where they can submit a reply to the organizer.
o "other": The organizer is identified by this URI but the method o "other": The organizer is identified by this URI but the method
how to submit the RSVP is undefined. how to submit the RSVP is undefined.
4.4.5. participants 4.4.5. participants
Type: "String[Participant]" (optional) Type: "String[Participant]" (optional)
A map of participant identifiers to participants, describing their A map of participant identifiers to participants, describing their
participation in the calendar object. A UUID or the base-64 encoded participation in the calendar object.
email address of the participant is a good choice for the identifier.
If this property is set, then the _replyTo_ property of this calendar If this property is set, then the _replyTo_ property of this calendar
object MUST define at least one reply method. object MUST define at least one reply method.
A *Participant* object has the following properties: A *Participant* object has the following properties:
o *name*: "String" (optional) The display name of the participant o *name*: "String" (optional) The display name of the participant
(e.g. "Joe Bloggs"). (e.g. "Joe Bloggs").
o *email*: "String" (optional) The email address for the o *email*: "String" (optional) The email address for the
skipping to change at page 28, line 4 skipping to change at page 27, line 49
is, if known. is, if known.
This MUST be either one of the following values, registered in a This MUST be either one of the following values, registered in a
future RFC, or a vendor-specific value. Any value the client or future RFC, or a vendor-specific value. Any value the client or
server doesn't understand should be treated the same as if this server doesn't understand should be treated the same as if this
property is omitted. property is omitted.
* "individual": a single person * "individual": a single person
* "group": a collection of people invited as a whole * "group": a collection of people invited as a whole
* "resource": a non-human resource, e.g. a projector
* "resource": a non-human resource, e.g. a projector
* "location": a physical location involved in the calendar object * "location": a physical location involved in the calendar object
that needs to be scheduled, e.g. a conference room. that needs to be scheduled, e.g. a conference room.
o *roles*: "String[Boolean]" A set of roles that this participant o *roles*: "String[Boolean]" A set of roles that this participant
fulfills. fulfills.
At least one role MUST be specified for the participant. The keys At least one role MUST be specified for the participant. The keys
in the set MUST be either one of the following values, registered in the set MUST be either one of the following values, registered
in a future RFC, or a vendor-specific value: in a future RFC, or a vendor-specific value:
skipping to change at page 30, line 41 skipping to change at page 30, line 41
4.5.2. alerts 4.5.2. alerts
Type: "String[Alert]" (optional) Type: "String[Alert]" (optional)
A map of alert identifiers to Alert objects, representing alerts/ A map of alert identifiers to Alert objects, representing alerts/
reminders to display or send the user for this calendar object. reminders to display or send the user for this calendar object.
An *Alert* Object has the following properties: An *Alert* Object has the following properties:
o *offset*: "SignedDuration" Defines when to trigger the alert, o *trigger*: "OffsetTrigger|UnknownTrigger" Defines when to trigger
relative to the time property defined in the _relativeTo_ the alert.
property. If the calendar object does not define a time zone, the
user's default time zone SHOULD be used when determining the
offset, if known. Otherwise, the time zone to use is
implementation specific.
o *relativeTo*: "String" (optional, default:"start") Specifies the An *OffsetTrigger* object has the following properties:
time property which the alert _offset_ is relative to. The value
MUST be one of:
* "start": triggers the alert relative to the start of the * *type*: "String" The value of this property MUST be "offset".
calendar object
* "end": triggers the alert relative to the end/due time of the * *offset*: "SignedDuration" Defines to trigger the alert
calendar object relative to the time property defined in the _relativeTo_
property. If the calendar object does not define a time zone,
the user's default time zone SHOULD be used when determining
the offset, if known. Otherwise, the time zone to use is
implementation specific.
* *relativeTo*: "String" (optional, default:"start") Specifies
the time property which the alert _offset_ is relative to. The
value MUST be one of:
+ "start": triggers the alert relative to the start of the
calendar object
+ "end": triggers the alert relative to the end/due time of
the calendar object
An *UnknownTrigger* object is an object that contains a *type*
property whose value is not "offset", plus zero or more other
properties. This is for compatibility with client extensions and
future RFCs. Implementations SHOULD NOT trigger for trigger types
they do not understand, but MUST preserve them.
o *acknowledged*: "UTCDate" (optional) o *acknowledged*: "UTCDate" (optional)
When the user has permanently dismissed the alert the client MUST When the user has permanently dismissed the alert the client MUST
set this to the current time in UTC. Other clients which sync set this to the current time in UTC. Other clients which sync
this property can then automatically dismiss or suppress duplicate this property can then automatically dismiss or suppress duplicate
alerts (alerts with the same alert id that triggered on or before alerts (alerts with the same alert id that triggered on or before
this date-time). this date-time).
For a recurring calendar object, the _acknowledged_ property of For a recurring calendar object, the _acknowledged_ property of
skipping to change at page 35, line 26 skipping to change at page 35, line 39
event's time zone, for example a change from standard time to event's time zone, for example a change from standard time to
daylight-savings time. Leap seconds MUST NOT be considered when daylight-savings time. Leap seconds MUST NOT be considered when
computing an exact duration. When computing an exact duration, the computing an exact duration. When computing an exact duration, the
greatest order time components MUST be added first, that is, the greatest order time components MUST be added first, that is, the
number of days MUST be added first, followed by the number of hours, number of days MUST be added first, followed by the number of hours,
number of minutes, and number of seconds. Fractional seconds MUST be number of minutes, and number of seconds. Fractional seconds MUST be
added last. added last.
A JSEvent MAY involve start and end locations that are in different A JSEvent MAY involve start and end locations that are in different
time zones (e.g. a trans-continental flight). This can be expressed time zones (e.g. a trans-continental flight). This can be expressed
using the _rel_ and _timeZone_ properties of the JSEvent's _location_ using the _relativeTo_ and _timeZone_ properties of the JSEvent's
objects. _location_ objects.
5.1.4. isAllDay 5.1.4. isAllDay
Type: "Boolean" (optional, default:"false") Type: "Boolean" (optional, default:"false")
Specifies if the event is an all day event, such as a birthday or Specifies if the event is an all day event, such as a birthday or
public holiday. public holiday.
If _isAllDay_ is true, then the following restrictions apply: If _isAllDay_ is true, then the following restrictions apply:
skipping to change at page 39, line 35 skipping to change at page 40, line 5
_uid_ property value to the JSCalendar object member having that uid. _uid_ property value to the JSCalendar object member having that uid.
Implementations MUST ignore entries of unknown type. Implementations MUST ignore entries of unknown type.
5.3.2. source 5.3.2. source
Type: "String" (optional) Type: "String" (optional)
The source from which updated versions of this group may be retrieved The source from which updated versions of this group may be retrieved
from. The value MUST be a URI. from. The value MUST be a URI.
6. Conversion from and to iCalendar 6. JSCalendar object examples
This section specifies which JSCalendar properties can be mapped from
and to iCalendar format. Implementations SHOULD follow these
conversion guidelines. Still, JSCalendar does not restrict itself to
iCalendar and conversion between these two formats MAY be lossy.
6.1. JSEvent
The iCalendar counterpart to _JSEvent_ is the VEVENT component type
[RFC5545]. A VEVENT component that is a direct child of a VCALENDAR
component is equivalent to a standalone JSEvent. A VEVENT component
within a VEVENT maps to the entries of the JSEvent
_recurrenceOverrides_ property.
+----------+--------------------------------------------------------+
| Property | iCalendar counterpart |
+----------+--------------------------------------------------------+
| isAllDay | True, if the type of the DTSTART property in iCalendar |
| | is DATE. |
| | |
| start | Corresponds to the DTSTART property in iCalendar. Note |
| | that time zone information is stored separately in |
| | JSEvent. |
| | |
| timeZone | Corresponds to the TZID part of the DTSTART property |
| | in iCalendar. If the event has a different end time |
| | zone to start time zone, this should be added as a |
| | JSCalendar _location_ with just a _timeZone_ property |
| | and "rel="end"". |
| | |
| duration | Corresponds to the DURATION or DSTART+DTEND properties |
| | in iCalendar. |
+----------+--------------------------------------------------------+
Table 1: Translation between JSEvent and iCalendar
6.2. JSTask
The iCalendar counterpart to _JSTask_ is the VTODO component type
[RFC5545]. A VTODO component that is a direct child of a VCALENDAR
component is equivalent to a standalone JSTask. A VTODO component
within a master VTODO maps to the entries of the JSTask
_recurrenceOverrides_ property.
+-------------------+-----------------------------------------------+
| Property | iCalendar counterpart |
+-------------------+-----------------------------------------------+
| isAllDay | True, if the type of the DTSTART property in |
| | iCalendar is DATE. |
| | |
| due | Corresponds to the DUE and DTSTART+DURATION |
| | properties in iCalendar. When mapping |
| | iCalendar VTODOs with DTSTART+DURATION, the |
| | due date is the result of adding DURATION to |
| | DTSTART in the DTSTART time zone. |
| | |
| start | Corresponds to the DTSTART property in |
| | iCalendar. |
| | |
| timeZone | Corresponds to the TZID part of the |
| | DTSTART/DUE properties in iCalendar. If the |
| | task has a different end time zone to start |
| | or due time zone, this should be added as a |
| | JSCalendar _location_ with just a _timeZone_ |
| | property and "rel="end"". |
| | |
| estimatedDuration | Corresponds to the ESTIMATED-DURATION |
| | iCalendar property in the RFC draft |
| | [draft-apthorp-ical-tasks]. |
| | |
| statusUpdatedAt | Maps to the COMPLETED iCalendar property. The |
| | JSTask status property MUST have value |
| | "completed". |
| | |
| progress | Corresponds to the PARTSTAT and COMPLETED |
| | properties in iCalendar, including the |
| | definitions in the RFC draft |
| | [draft-apthorp-ical-tasks]. |
| | |
| status | Corresponds to the STATUS property in |
| | iCalendar, including the definitions in the |
| | RFC draft [draft-apthorp-ical-tasks]. |
+-------------------+-----------------------------------------------+
Table 2: Translation between JSTask and iCalendar
6.3. JSGroup
A JSGroup converts to a iCalendar VCALENDAR containing VEVENT or
VTODO components.
+----------+--------------------------------------------------------+
| Property | iCalendar counterpart |
+----------+--------------------------------------------------------+
| entries | The VEVENT and VTODO components within a top-level |
| | VCALENDAR component. |
| | |
| source | Corresponds to the SOURCE property in iCalendar. |
+----------+--------------------------------------------------------+
Table 3: Translation between JSGroup and iCalendar
6.4. Common properties
+------------------------+------------------------------------------+
| Property | iCalendar counterpart |
+------------------------+------------------------------------------+
| alerts | An _Alert_ corresponds to the VALARM |
| | component in iCalendar, where the |
| | _action_ is determined by the iCalendar |
| | ACTION property value (e.g., both |
| | "DISPLAY" and "AUDIO" actions map to a |
| | JSCalendar _display_ action, and |
| | similarly for "EMAIL"). The |
| | _relativeTo_ and _offset_ properties |
| | corresponds to the iCalendar TRIGGER |
| | property. |
| | |
| categories | Corresponds to the CONCEPT property in |
| | iCalendar, see in the RFC draft |
| | [draft-ietf-calext-ical-relations]. |
| | |
| color | Corresponds to the COLOR property in |
| | iCalendar, as specified in [RFC7986]. |
| | |
| created | Corresponds to the CREATED property in |
| | iCalendar. |
| | |
| description | Corresponds to the DESCRIPTION property |
| | and its ALTREP parameters in iCalendar. |
| | |
| descriptionContentType | Implementation-specific. |
| | |
| freeBusyStatus | Corresponds to the TRANSP property in |
| | iCalendar. |
| | |
| keywords | Corresponds to the CATEGORIES property |
| | in iCalendar, as specified in [RFC7986]. |
| | |
| links | Use the ATTACH ([RFC5545]), URL or IMAGE |
| | ([RFC7986]) property values of URI value |
| | type as the Link _href_. The Link |
| | _type_ property corresponds to the |
| | FMTTYPE parameter, the _size_ property |
| | to the SIZE parameter. Mapping all |
| | other properties is implementation- |
| | specific. |
| | |
| locale | Corresponds to the LANGUAGE parameter in |
| | iCalendar, which is added to individual |
| | properties. When converting from |
| | iCalendar, one language must be picked |
| | as the main locale for the object, and |
| | all properties in other languages moved |
| | to the localizations JSEvent property. |
| | |
| localizations | Implementation-specific. |
| | |
| locations | See Section 6.5. |
| | |
| method | Corresponds to the METHOD property of |
| | the embedding VCALENDAR in iCalendar. |
| | |
| participants | See Section 6.5. |
| | |
| priority | Corresponds to the PRIORITY property in |
| | iCalendar. |
| | |
| privacy | Corresponds to the CLASS property in |
| | iCalendar. |
| | |
| prodId | Corresponds to the PRODID property in |
| | iCalendar. |
| | |
| recurrenceOverrides | Corresponds to the RDATE and EXDATE |
| | properties in iCalendar, plus VEVENT |
| | (for JSEvent) or VTODO (for JSTask) |
| | instances with a recurrence-id. |
| | |
| recurrenceRule | Corresponds to the RRULE property in |
| | iCalendar. For all-day calendar objects, |
| | convert the _until_ property value to an |
| | iCalendar DATE (effectively removing the |
| | time component). To convert a DATE-typed |
| | UNTIL from iCalendar, set the time |
| | components of the LocalDate value to |
| | "23:59:59". If the iCalendar UNTIL value |
| | is a UTC date time, convert to the local |
| | time in the calendar object time zone. |
| | |
| relatedTo | Corresponds to the RELATED-TO property |
| | in iCalendar. |
| | |
| replyTo | An iCalendar ORGANIZER with a mailto: |
| | URI mapped to the "imip" method, or any |
| | other URI mapped to the "other" method. |
| | Mapping multiple methods is |
| | implementation-specific. |
| | |
| sequence | Corresponds to the SEQUENCE property in |
| | iCalendar. |
| | |
| status | Corresponds to the STATUS property in |
| | iCalendar (converted to lower-case). |
| | |
| title | Corresponds to the SUMMARY property in |
| | iCalendar. |
| | |
| uid | Corresponds to the UID property in |
| | iCalendar. |
| | |
| updated | Corresponds to the DTSTAMP and LAST- |
| | MODIFIED properties in iCalendar. (These |
| | are only different in the iTIP case, and |
| | the difference is not actually useful.) |
+------------------------+------------------------------------------+
Table 4: Translation between JSCalendar and iCalendar
6.5. Locations and participants
Both JSCalendar participants and locations have counterparts in
iCalendar but provide richer representation.
The following table outlines translation of JSCalendar participants.
Where iCalendar has distinct properties for ORGANIZER and ATTENDEE,
these are merged in JSCalendar into the Participant object type.
+---------------------+---------------------------------------------+
| Property | iCalendar counterpart |
+---------------------+---------------------------------------------+
| delegatedFrom | the DELEGATED-FROM parameter |
| | |
| delegatedTo | the DELEGATED-TO parameter |
| | |
| expectReply | the RSVP parameter |
| | |
| email | The value of the EMAIL parameter of the |
| | ORGANIZER or ATTENDEE property, if defined. |
| | Otherwise the property value, if it is a |
| | mailto: URI. |
| | |
| sendTo | An iCalendar ATTENDEE with a mailto: URI |
| | mapped to the "imip" method, or any other |
| | URI mapped to the "other" method. Mapping |
| | multiple methods is implementation- |
| | specific. |
| | |
| kind | the CUTYPE parameter |
| | |
| linkIds | Implementation-specific. |
| | |
| locationId | Implementation-specific. When mapping from |
| | iCalendar to JSCalendar this may be the |
| | JSCalendar identifier of a CONFERENCE |
| | property that has the MODERATOR feature |
| | defined in its FEATURE parameter values. If |
| | multiple such CONFERENCE properties are |
| | defined in iCalendar, then the one with the |
| | most interactive features is chosen. |
| | |
| memberOf | the MEMBER parameter |
| | |
| name | the CN parameter |
| | |
| attendance | Maps to the standard iCalendar ROLE |
| | parameter values REQ-PARTICIPANT, OPT- |
| | PARTICIPANT and NON-PARTICIPANT. |
| | |
| roles | The "chair" role maps to the standard |
| | iCalendar ROLE parameter value "chair", |
| | with an implicit participant of value |
| | "required". The mapping of non-required |
| | chairs and other roles is implementation- |
| | specific, but using "x-name" parameter |
| | values is recommended. |
| | |
| participationStatus | the PARTSTAT parameter |
| | |
| scheduleSequence | the SEQUENCE property of the participant's |
| | latest iMIP message |
| | |
| scheduleUpdated | the DTSTAMP property of the participant's |
| | latest iMIP message |
+---------------------+---------------------------------------------+
Table 5: Translation of Participant between JSCalendar and iCalendar
The iCalendar counterpart for JSCalendar Location objects is the
iCalendar [RFC5545] LOCATION property, or implementation-specific.
+-------------+-----------------------------------------------------+
| Property | iCalendar counterpart |
+-------------+-----------------------------------------------------+
| name | Corresponds to the LOCATION property value. |
| | |
| description | Implementation-specific. |
| | |
| rel | Implementation-specific. |
| | |
| timeZone | Implementation-specific. |
| | |
| coordinates | Implementation-specific. Consider using a GEO |
| | iCalendar property, along with one LOCATION. |
| | |
| uri | Corresponds to the LOCATION ALTREP parameter. |
| | |
| linkIds | Implementation-specific. |
+-------------+-----------------------------------------------------+
Table 6: Translation of Location between JSCalendar and iCalendar
The iCalendar counterpart for JSCalendar VirtualLocation objects is
the iCalendar [RFC7986] CONFERENCE property, or implementation-
specific.
+--------------+--------------------------------------------------+
| Property | iCalendar counterpart |
+--------------+--------------------------------------------------+
| name | Corresponds to the CONFERENCE LABEL parameter. |
| | |
| description | Implementation-specific. |
| | |
| uri | Corresponds to the CONFERENCE property value. |
+--------------+--------------------------------------------------+
Table 7: Translation of VirtualLocation between JSCalendar and
iCalendar
6.6. Unknown properties
Both JSCalendar and iCalendar calendar objects may contain properties
that are not expressible in the other format. This specification
does not mandate how to preserve these properties. Instead, it
leaves negotiation on how to treat unknown properties to client and
server implementations and their protocol used to exchange calendar
objects.
Two notable options to represent and preserve arbitrary iCalendar
object properties in JSCalendar are:
o _JCal_: Define iCalendar properties in JCal format ([RFC7265]) in
a vendor-specific property of the JCalendar object. The JCal-
formatted value may either only contain iCalendar properties that
were not mapped to JSCalendar properties, or contain the complete
iCalendar object representation.
o _Alternate link_: Define an alternate link (Section 4.2.6) value
pointing to the iCalendar representation of the JSCalendar object.
E.g. the alternative representation of a VEVENT would be
represented as a link with rel "alternate" and type "text/
calendar;component=VEVENT".
7. JSCalendar object examples
The following examples illustrate several aspects of the JSCalendar The following examples illustrate several aspects of the JSCalendar
data model and format. The examples may omit mandatory or additional data model and format. The examples may omit mandatory or additional
properties, which is indicated by a placeholder property with key properties, which is indicated by a placeholder property with key
"...". While most of the examples use calendar event objects, they "...". While most of the examples use calendar event objects, they
are also illustrative for tasks. are also illustrative for tasks.
7.1. Simple event 6.1. Simple event
This example illustrates a simple one-time event. It specifies a This example illustrates a simple one-time event. It specifies a
one-time event that begins on January 15, 2018 at 1pm New York local one-time event that begins on January 15, 2018 at 1pm New York local
time and ends after 1 hour. time and ends after 1 hour.
{ {
"@type": "jsevent", "@type": "jsevent",
"uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1",
"updated": "2018-01-15T18:00:00Z", "updated": "2018-01-15T18:00:00Z",
"title": "Some event", "title": "Some event",
"start": "2018-01-15T13:00:00", "start": "2018-01-15T13:00:00",
"timeZone": "America/New_York", "timeZone": "America/New_York",
"duration": "PT1H" "duration": "PT1H"
} }
7.2. Simple task 6.2. Simple task
This example illustrates a simple task for a plain to-do item. This example illustrates a simple task for a plain to-do item.
{ {
"@type": "jstask", "@type": "jstask",
"uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2",
"updated": "2018-01-15T18:00:00Z", "updated": "2018-01-15T18:00:00Z",
"title": "Do something" "title": "Do something"
} }
7.3. Simple group 6.3. Simple group
This example illustrates a simple calendar object group that contains This example illustrates a simple calendar object group that contains
an event and a task. an event and a task.
{ {
"@type": "jsgroup", "@type": "jsgroup",
"uid": "2a358cee-6489-4f14-a57f-c104db4dc343", "uid": "2a358cee-6489-4f14-a57f-c104db4dc343",
"updated": "2018-01-15T18:00:00Z", "updated": "2018-01-15T18:00:00Z",
"name": "A simple group", "name": "A simple group",
"entries": [ "entries": [
skipping to change at page 48, line 45 skipping to change at page 41, line 29
}, },
{ {
"@type": "jstask", "@type": "jstask",
"uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2",
"updated": "2018-01-15T18:00:00Z", "updated": "2018-01-15T18:00:00Z",
"title": "Do something" "title": "Do something"
} }
] ]
} }
7.4. All-day event 6.4. All-day event
This example illustrates an event for an international holiday. It This example illustrates an event for an international holiday. It
specifies an all-day event on April 1 that occurs every year since specifies an all-day event on April 1 that occurs every year since
the year 1900. the year 1900.
{ {
"...": "", "...": "",
"title": "April Fool's Day", "title": "April Fool's Day",
"isAllDay": true, "isAllDay": true,
"start": "1900-04-01T00:00:00", "start": "1900-04-01T00:00:00",
"duration": "P1D", "duration": "P1D",
"recurrenceRule": { "recurrenceRule": {
"frequency": "yearly" "frequency": "yearly"
} }
} }
7.5. Task with a due date 6.5. Task with a due date
This example illustrates a task with a due date. It is a reminder to This example illustrates a task with a due date. It is a reminder to
buy groceries before 6pm Vienna local time on January 19, 2018. The buy groceries before 6pm Vienna local time on January 19, 2018. The
calendar user expects to need 1 hour for shopping. calendar user expects to need 1 hour for shopping.
{ {
"...": "", "...": "",
"title": "Buy groceries", "title": "Buy groceries",
"due": "2018-01-19T18:00:00", "due": "2018-01-19T18:00:00",
"timeZone": "Europe/Vienna", "timeZone": "Europe/Vienna",
"estimatedDuration": "PT1H" "estimatedDuration": "PT1H"
} }
7.6. Event with end time-zone 6.6. Event with end time-zone
This example illustrates the use of end time-zones by use of an This example illustrates the use of end time-zones by use of an
international flight. The flight starts on April 1, 2018 at 9am in international flight. The flight starts on April 1, 2018 at 9am in
Berlin local time. The duration of the flight is scheduled at 10 Berlin local time. The duration of the flight is scheduled at 10
hours 30 minutes. The time at the flights destination is in the same hours 30 minutes. The time at the flights destination is in the same
time-zone as Tokyo. Calendar clients could use the end time-zone to time-zone as Tokyo. Calendar clients could use the end time-zone to
display the arrival time in Tokyo local time and highlight the time- display the arrival time in Tokyo local time and highlight the time-
zone difference of the flight. The location names can serve as input zone difference of the flight. The location names can serve as input
for navigation systems. for navigation systems.
skipping to change at page 50, line 24 skipping to change at page 42, line 43
"name": "Frankfurt Airport (FRA)" "name": "Frankfurt Airport (FRA)"
}, },
"c2c7ac67-dc13-411e-a7d4-0780fb61fb08": { "c2c7ac67-dc13-411e-a7d4-0780fb61fb08": {
"rel": "end", "rel": "end",
"name": "Narita International Airport (NRT)", "name": "Narita International Airport (NRT)",
"timeZone": "Asia/Tokyo" "timeZone": "Asia/Tokyo"
} }
} }
} }
7.7. Floating-time event (with recurrence) 6.7. Floating-time event (with recurrence)
This example illustrates the use of floating-time. Since January 1, This example illustrates the use of floating-time. Since January 1,
2018, a calendar user blocks 30 minutes every day to practice Yoga at 2018, a calendar user blocks 30 minutes every day to practice Yoga at
7am local time, in whatever time-zone the user is located on that 7am local time, in whatever time-zone the user is located on that
date. date.
{ {
"...": "", "...": "",
"title": "Yoga", "title": "Yoga",
"start": "2018-01-01T07:00:00", "start": "2018-01-01T07:00:00",
"duration": "PT30M", "duration": "PT30M",
"recurrenceRule": { "recurrenceRule": {
"frequency": "daily" "frequency": "daily"
} }
} }
7.8. Event with multiple locations and localization 6.8. Event with multiple locations and localization
This example illustrates an event that happens at both a physical and This example illustrates an event that happens at both a physical and
a virtual location. Fans can see a live convert on premises or a virtual location. Fans can see a live convert on premises or
online. The event title and descriptions are localized. online. The event title and descriptions are localized.
{ {
"...": "", "...": "",
"title": "Live from Music Bowl: The Band", "title": "Live from Music Bowl: The Band",
"description": "Go see the biggest music event ever!", "description": "Go see the biggest music event ever!",
"locale": "en", "locale": "en",
skipping to change at page 51, line 36 skipping to change at page 44, line 5
"localizations": { "localizations": {
"de": { "de": {
"title": "Live von der Music Bowl: The Band!", "title": "Live von der Music Bowl: The Band!",
"description": "Schau dir das groesste Musikereignis an!", "description": "Schau dir das groesste Musikereignis an!",
"virtualLocations/6f3696c6-1e07-47d0-9ce1-f50014b0041a/name": "virtualLocations/6f3696c6-1e07-47d0-9ce1-f50014b0041a/name":
"Gratis Live-Stream aus der Music Bowl" "Gratis Live-Stream aus der Music Bowl"
} }
} }
} }
7.9. Recurring event with overrides 6.9. Recurring event with overrides
This example illustrates the use of recurrence overrides. A math This example illustrates the use of recurrence overrides. A math
course at a University is held for the first time on January 8, 2018 course at a University is held for the first time on January 8, 2018
at 9am London time and occurs every week until June 25, 2018. Each at 9am London time and occurs every week until June 25, 2018. Each
lecture lasts for one hour and 30 minutes and is located at the lecture lasts for one hour and 30 minutes and is located at the
Mathematics department. This event has exceptional occurrences: at Mathematics department. This event has exceptional occurrences: at
the last occurrence of the course is an exam, which lasts for 2 hours the last occurrence of the course is an exam, which lasts for 2 hours
and starts at 10am. Also, the location of the exam differs from the and starts at 10am. Also, the location of the exam differs from the
usual location. On April 2 no course is held. On January 5 at 2pm usual location. On April 2 no course is held. On January 5 at 2pm
is an optional introduction course, that occurs before the first is an optional introduction course, that occurs before the first
skipping to change at page 52, line 42 skipping to change at page 45, line 42
"locations": { "locations": {
"2a358cee-6489-4f14-a57f-c104db4dc2f1": { "2a358cee-6489-4f14-a57f-c104db4dc2f1": {
"title": "Big Auditorium", "title": "Big Auditorium",
"description": "Big Auditorium, Other Road" "description": "Big Auditorium, Other Road"
} }
} }
} }
} }
} }
7.10. Recurring event with participants 6.10. Recurring event with participants
This example illustrates scheduled events. A team meeting occurs This example illustrates scheduled events. A team meeting occurs
every week since January 8, 2018 at 9am Johannesburg time. The event every week since January 8, 2018 at 9am Johannesburg time. The event
owner also chairs the event. Participants meet in a virtual meeting owner also chairs the event. Participants meet in a virtual meeting
room. An attendee has accepted the invitation, but on March 8, 2018 room. An attendee has accepted the invitation, but on March 8, 2018
he is unavailable and declined participation for this occurrence. he is unavailable and declined participation for this occurrence.
{ {
"...": "", "...": "",
"title": "FooBar team meeting", "title": "FooBar team meeting",
skipping to change at page 54, line 7 skipping to change at page 47, line 7
}, },
"recurrenceOverrides": { "recurrenceOverrides": {
"2018-03-08T09:00:00": { "2018-03-08T09:00:00": {
"participants/dG9tQGZvb2Jhci5leGFtcGxlLmNvbQ/participationStatus": "participants/dG9tQGZvb2Jhci5leGFtcGxlLmNvbQ/participationStatus":
"declined" "declined"
} }
} }
} }
8. Security Considerations 7. Security Considerations
The use of JSON as a format does have its own inherent security risks The use of JSON as a format does have its own inherent security risks
as discussed in Section 12 of [RFC8259]. Even though JSON is as discussed in Section 12 of [RFC8259]. Even though JSON is
considered a safe subset of JavaScript, it should be kept in mind considered a safe subset of JavaScript, it should be kept in mind
that a flaw in the parser processing JSON could still impose a that a flaw in the parser processing JSON could still impose a
threat, which doesn't arise with conventional iCalendar data. threat, which doesn't arise with conventional iCalendar data.
With this in mind, a parser for JSON data aware of the security With this in mind, a parser for JSON data aware of the security
implications should be used for the format described in this implications should be used for the format described in this
document. For example, the use of JavaScript's "eval()" function is document. For example, the use of JavaScript's "eval()" function is
considered an unacceptable security risk, as described in Section 12 considered an unacceptable security risk, as described in Section 12
of[RFC8259]. A native parser with full awareness of the JSON format of[RFC8259]. A native parser with full awareness of the JSON format
should be preferred. should be preferred.
9. IANA Considerations 8. IANA Considerations
This document defines a MIME media type for use with JSCalendar data This document defines a MIME media type for use with JSCalendar data
formatted in JSON. formatted in JSON.
Type name: application Type name: application
Subtype name: jscalendar+json Subtype name: jscalendar+json
Required parameters: type Required parameters: type
skipping to change at page 54, line 44 skipping to change at page 47, line 44
the body part, with the value being one of "jsevent", "jstask", or the body part, with the value being one of "jsevent", "jstask", or
"jsgroup". The parameter MUST NOT occur more than once. It MUST "jsgroup". The parameter MUST NOT occur more than once. It MUST
match the value of the "@type" property of the JSON-formatted match the value of the "@type" property of the JSON-formatted
JSCalendar object in the body. JSCalendar object in the body.
Optional parameters: none Optional parameters: none
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/json as specified in RFC8529, Section 11 [RFC8259]. application/json as specified in RFC8529, Section 11 [RFC8259].
Security considerations: See Section 8 of this document. Security considerations: See Section 7 of this document.
Interoperability considerations: This media type provides an Interoperability considerations: This media type provides an
alternative to iCalendar, jCal and proprietary JSON-based alternative to iCalendar, jCal and proprietary JSON-based
calendaring data formats. calendaring data formats.
Published specification: This specification. Published specification: This specification.
Applications that use this media type: Applications that currently Applications that use this media type: Applications that currently
make use of the text/calendar and application/calendar+json media make use of the text/calendar and application/calendar+json media
types can use this as an alternative. Similarily, applications types can use this as an alternative. Similarily, applications
skipping to change at page 55, line 33 skipping to change at page 48, line 33
calext@ietf.org calext@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See the "Author's Address" section of this document. Author: See the "Author's Address" section of this document.
Change controller: IETF Change controller: IETF
10. Acknowledgments 9. Acknowledgments
The authors would like to thank the members of CalConnect for their The authors would like to thank the members of CalConnect for their
valuable contributions. This specification originated from the work valuable contributions. This specification originated from the work
of the API technical committee of CalConnect, the Calendaring and of the API technical committee of CalConnect, the Calendaring and
Scheduling Consortium. Scheduling Consortium.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>. <https://www.rfc-editor.org/info/rfc2392>.
skipping to change at page 57, line 46 skipping to change at page 50, line 46
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
11.2. Informative References 10.2. Informative References
[draft-apthorp-ical-tasks] [draft-apthorp-ical-tasks]
"Task Extensions to iCalendar", "Task Extensions to iCalendar",
<https://tools.ietf.org/html/draft-apthorp-ical-tasks>. <https://tools.ietf.org/html/draft-apthorp-ical-tasks>.
[draft-ietf-calext-ical-relations] [draft-ietf-calext-ical-relations]
"Support for iCalendar Relationships", "Support for iCalendar Relationships",
<https://tools.ietf.org/html/ <https://tools.ietf.org/html/
draft-ietf-calext-ical-relations>. draft-ietf-calext-ical-relations>.
[MIME] "IANA Media Types", <https://www.iana.org/assignments/ [MIME] "IANA Media Types", <https://www.iana.org/assignments/
media-types/media-types.xhtml>. media-types/media-types.xhtml>.
11.3. URIs 10.3. URIs
[1] https://www.iana.org/time-zones [1] https://www.iana.org/time-zones
[2] https://www.iana.org/assignments/link-relations/link- [2] https://www.iana.org/assignments/link-relations/link-
relations.xhtml relations.xhtml
[3] https://www.w3.org/TR/2011/REC-css3-color-20110607/#svg-color [3] https://www.w3.org/TR/2011/REC-css3-color-20110607/#svg-color
Authors' Addresses Authors' Addresses
 End of changes. 45 change blocks. 
438 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/