draft-ietf-calext-jscalendar-25.txt   draft-ietf-calext-jscalendar-26.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: August 27, 2020 February 24, 2020 Expires: September 9, 2020 March 8, 2020
JSCalendar: A JSON representation of calendar data JSCalendar: A JSON representation of calendar data
draft-ietf-calext-jscalendar-25 draft-ietf-calext-jscalendar-26
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
and, over time, successor to the widely deployed iCalendar data and, over time, successor to the widely deployed iCalendar data
format, and to be unambiguous, extendable, and simple to process. In format, and to be unambiguous, extendable, and simple to process. In
contrast to the jCal format, which is also JSON-based, JSCalendar is contrast to the jCal format, which is also JSON-based, JSCalendar is
not a direct mapping from iCalendar, but defines the data model not a direct mapping from iCalendar, but defines the data model
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 August 27, 2020. This Internet-Draft will expire on September 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1.4. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Int . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Int . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2. UnsignedInt . . . . . . . . . . . . . . . . . . . . . 7 1.4.2. UnsignedInt . . . . . . . . . . . . . . . . . . . . . 7
1.4.3. UTCDateTime . . . . . . . . . . . . . . . . . . . . . 7 1.4.3. UTCDateTime . . . . . . . . . . . . . . . . . . . . . 7
1.4.4. LocalDateTime . . . . . . . . . . . . . . . . . . . . 7 1.4.4. LocalDateTime . . . . . . . . . . . . . . . . . . . . 7
1.4.5. Duration . . . . . . . . . . . . . . . . . . . . . . 7 1.4.5. Duration . . . . . . . . . . . . . . . . . . . . . . 7
1.4.6. SignedDuration . . . . . . . . . . . . . . . . . . . 8 1.4.6. SignedDuration . . . . . . . . . . . . . . . . . . . 8
1.4.7. Id . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4.7. Id . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.8. PatchObject . . . . . . . . . . . . . . . . . . . . . 9 1.4.8. PatchObject . . . . . . . . . . . . . . . . . . . . . 9
1.4.9. Time Zones . . . . . . . . . . . . . . . . . . . . . 9 1.4.9. Time Zones . . . . . . . . . . . . . . . . . . . . . 9
1.4.10. Relation . . . . . . . . . . . . . . . . . . . . . . 9 1.4.10. Relation . . . . . . . . . . . . . . . . . . . . . . 10
2. JSCalendar Objects . . . . . . . . . . . . . . . . . . . . . 10 2. JSCalendar Objects . . . . . . . . . . . . . . . . . . . . . 10
2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Structure of JSCalendar Objects . . . . . . . . . . . . . . . 11 3. Structure of JSCalendar Objects . . . . . . . . . . . . . . . 11
3.1. Normalization and Equivalence . . . . . . . . . . . . . . 11 3.1. Normalization and Equivalence . . . . . . . . . . . . . . 11
3.2. Vendor-specific Property Extensions and Values . . . . . 12 3.2. Vendor-specific Property Extensions and Values . . . . . 12
4. Common JSCalendar Properties . . . . . . . . . . . . . . . . 12 4. Common JSCalendar Properties . . . . . . . . . . . . . . . . 12
4.1. Metadata Properties . . . . . . . . . . . . . . . . . . . 12 4.1. Metadata Properties . . . . . . . . . . . . . . . . . . . 12
4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 4, line 33 skipping to change at page 4, line 33
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 73
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.1. Normative References . . . . . . . . . . . . . . . . . . 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 73
10.2. Informative References . . . . . . . . . . . . . . . . . 75 10.2. Informative References . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
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. The format aims to be unambiguous,
simple to process. extendable and 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:
o The attributes of the calendar entry represented must be described o The attributes of the calendar entry represented must be described
as simple key-value pairs. Simple events are simple to represent; as simple key-value pairs. Simple events are simple to represent;
complex events can be modelled accurately. complex events can be modelled accurately.
o Wherever possible, there should be only one way to express the o Wherever possible, there should be only one way to express the
desired semantics, reducing complexity. desired semantics, reducing complexity.
o The data model should avoid ambiguities, which often lead to o The data model should avoid ambiguities, which often lead to
interoperability issues between implementations. interoperability issues between implementations.
o The data model should be compatible with the iCalendar data format o The data model should be compatible with the iCalendar data format
[RFC5545] [RFC7986] and extensions, but the specification should [RFC5545] [RFC7986] and extensions, but the specification should
add new attributes where the iCalendar format currently lacks add new attributes where the iCalendar format currently lacks
expressivity, and drop seldom-used, obsolete, or redundant expressivity, and drop seldom-used, obsolete, or redundant
properties. This means translation with no loss of semantics properties. This means translation with no loss of semantics
should be easy with most common iCalendar files. should be easy with most common iCalendar files.
o Extensions, such as new properties and components, generally do o Extensions, such as new properties and components, should not
not require updates to this document. require updates to this document.
The representation of this data model is defined in the I-JSON format The representation of this data model is defined in the I-JSON format
[RFC7493], which is a strict subset of the JavaScript Object Notation [RFC7493], which is a strict subset of the JavaScript Object Notation
(JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a (JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a
pragmatic choice: its widespread use makes JSCalendar easier to pragmatic choice: its widespread use makes JSCalendar easier to
adopt, and the ready availability of production-ready JSON adopt, and the ready availability of production-ready JSON
implementations eliminates a whole category of parser-related implementations eliminates a whole category of parser-related
interoperability issues, which iCalendar has often suffered from. interoperability issues, which iCalendar has often suffered from.
1.1. Motivation and Relation to iCalendar and jCal 1.1. Motivation and Relation to iCalendar and jCal
skipping to change at page 5, line 46 skipping to change at page 5, line 46
o The iCalendar format itself causes interoperability issues due to o The iCalendar format itself causes interoperability issues due to
misuse of CRLF-terminated strings, line continuations, and subtle misuse of CRLF-terminated strings, line continuations, and subtle
differences among iCalendar parsers. differences among iCalendar parsers.
In recent years, many new products and services have appeared that In recent years, many new products and services have appeared that
wish to use a JSON representation of calendar data within their APIs. wish to use a JSON representation of calendar data within their APIs.
The JSON format for iCalendar data, jCal [RFC7265], is a direct The JSON format for iCalendar data, jCal [RFC7265], is a direct
mapping between iCalendar and JSON. In its effort to represent full mapping between iCalendar and JSON. In its effort to represent full
iCalendar semantics, it inherits all the same pitfalls and uses a iCalendar semantics, it inherits all the same pitfalls and uses a
complicated JSON structure unlike most common JSON data complicated JSON structure.
representations.
As a consequence, since the standardization of jCal, the majority of As a consequence, since the standardization of jCal, the majority of
implementations and service providers either kept using iCalendar, or implementations and service providers either kept using iCalendar, or
came up with their own proprietary JSON representations, which are came up with their own proprietary JSON representations, which are
incompatible with each other and often suffer from common pitfalls, incompatible with each other and often suffer from common pitfalls,
such as storing event start times in UTC (which become incorrect if such as storing event start times in UTC (which become incorrect if
the timezone's rules change in the future). JSCalendar meets the the timezone's rules change in the future). JSCalendar meets the
demand for JSON-formatted calendar data that is free of such known demand for JSON-formatted calendar data that is free of such known
problems and provides a standard representation as an alternative to problems and provides a standard representation as an alternative to
the proprietary formats. the proprietary formats.
skipping to change at page 7, line 31 skipping to change at page 7, line 31
1.4.3. UTCDateTime 1.4.3. UTCDateTime
This is a string in [RFC3339] "date-time" format, with the further This is a string in [RFC3339] "date-time" format, with the further
restrictions that any letters MUST be in uppercase, the time restrictions that any letters MUST be in uppercase, the time
component MUST be included and the time offset MUST be the character component MUST be included and the time offset MUST be the character
"Z". Fractional second values MUST NOT be included unless non-zero "Z". Fractional second values MUST NOT be included unless non-zero
and MUST NOT have trailing zeros, to ensure there is only a single and MUST NOT have trailing zeros, to ensure there is only a single
representation for each date-time. representation for each date-time.
For example "2010-10-10T10:10:10.003Z" is OK, but For example "2010-10-10T10:10:10.003Z" is OK, but
"2010-10-10T10:10:10.000Z" is invalid and MUST be encoded as "2010-10-10T10:10:10.000Z" is invalid and is correctly encoded as
"2010-10-10T10:10:10Z". "2010-10-10T10:10:10Z".
1.4.4. LocalDateTime 1.4.4. LocalDateTime
This is a date-time string with no time zone/offset information. It This is a date-time string with no time zone/offset information. It
is otherwise in the same format as UTCDateTime, including fractional is otherwise in the same format as UTCDateTime, including fractional
seconds. For example "2006-01-02T15:04:05" and seconds. For example "2006-01-02T15:04:05" and
"2006-01-02T15:04:05.003" are both valid. The time zone to associate "2006-01-02T15:04:05.003" are both valid. The time zone to associate
the LocalDateTime with comes from an associated property, or if no the LocalDateTime with comes from an associated property, or if no
time zone is associated it defines *floating time*. Floating date- time zone is associated it defines "floating time". Floating date-
times are not tied to any specific time zone. Instead, they occur in times are not tied to any specific time zone. Instead, they occur in
each time zone at the given wall-clock time (as opposed to the same each time zone at the given wall-clock time (as opposed to the same
instant point in time). instant point in time).
1.4.5. Duration 1.4.5. Duration
Where Duration is given as a type, it means a length of time Where Duration is given as a type, it means a length of time
represented by a subset of ISO8601 duration format, as specified by represented by a subset of ISO8601 duration format, as specified by
the following ABNF: the following ABNF [RFC5234]:
dur-secfrac = "." 1*DIGIT dur-secfrac = "." 1*DIGIT
dur-second = 1*DIGIT [dur-secfrac] "S" dur-second = 1*DIGIT [dur-secfrac] "S"
dur-minute = 1*DIGIT "M" [dur-second] dur-minute = 1*DIGIT "M" [dur-second]
dur-hour = 1*DIGIT "H" [dur-minute] dur-hour = 1*DIGIT "H" [dur-minute]
dur-time = "T" (dur-hour / dur-minute / dur-second) dur-time = "T" (dur-hour / dur-minute / dur-second)
dur-day = 1*DIGIT "D" dur-day = 1*DIGIT "D"
dur-week = 1*DIGIT "W" dur-week = 1*DIGIT "W"
duration = "P" (dur-day [dur-time] / dur-time / dur-week) duration = "P" (dur-day [dur-time] / dur-time / dur-week)
skipping to change at page 9, line 26 skipping to change at page 9, line 26
1. The pointer MUST NOT insert/delete from an array; the array MUST 1. The pointer MUST NOT insert/delete from an array; the array MUST
be replaced in its entirety instead. be replaced in its entirety instead.
2. When evaluating a path, all parts prior to the last (i.e., the 2. When evaluating a path, all parts prior to the last (i.e., the
value after the final slash) MUST exist. value after the final slash) MUST exist.
3. There MUST NOT be two patches in the PatchObject where the 3. There MUST NOT be two patches in the PatchObject where the
pointer of one is a prefix of the pointer of the other, e.g., pointer of one is a prefix of the pointer of the other, e.g.,
"alerts/foo/offset" and "alerts". "alerts/foo/offset" and "alerts".
4. The value for the patch MUST be valid for the property being set
(of the correct type and obeying any other applicable
restrictions), or if null the property MUST be optional.
The value associated with each pointer is either: The value associated with each pointer is either:
o null: Remove the property at the given path from the patched o null: Remove the property at the given path from the patched
object. If the property is not present in the object, this a no- object. If the property is not present in the object, this a no-
op. op.
o Anything else: Set the value for the property to this value (this o Anything else: Set the value for the property to this value (this
may be a replacement or addition to the object being patched). may be a replacement or addition to the object being patched).
Implementations MUST reject in its entirety a PatchObject if any of Implementations MUST reject in its entirety a PatchObject if any of
skipping to change at page 16, line 18 skipping to change at page 16, line 18
o description: "String" (optional) o description: "String" (optional)
Human-readable, plain-text instructions for accessing this Human-readable, plain-text instructions for accessing this
location. This may be an address, set of directions, door access location. This may be an address, set of directions, door access
code, etc. code, etc.
o locationTypes: "String[Boolean]" (optional) o locationTypes: "String[Boolean]" (optional)
A set of one or more location types that describe this location. A set of one or more location types that describe this location.
All types MUST be from the Location Types Registry as defined in All types MUST be from the Location Types Registry [LOCATIONTYPES]
[RFC4589]. The set is represented as a map, with the keys being as defined in [RFC4589]. The set is represented as a map, with
the location types. The value for each key in the map MUST be the keys being the location types. The value for each key in the
true. map MUST be true.
o relativeTo: "String" (optional) o relativeTo: "String" (optional)
Specifies the relation between this location and the time of the Specifies the relation between this location and the time of the
JSCalendar object. This is primarily to allow events representing JSCalendar object. This is primarily to allow events representing
travel to specify the location of departure (at the start of the travel to specify the location of departure (at the start of the
event) and location of arrival (at the end); this is particularly event) and location of arrival (at the end); this is particularly
important if these locations are in different time zones, as a important if these locations are in different time zones, as a
client may wish to highlight this information for the user. client may wish to highlight this information for the user.
skipping to change at page 18, line 37 skipping to change at page 18, line 37
different from the link id for this Link object. different from the link id for this Link object.
o contentType: "String" (optional) o contentType: "String" (optional)
The media type [RFC6838] of the resource, if known. The media type [RFC6838] of the resource, if known.
o size: "UnsignedInt" (optional) o size: "UnsignedInt" (optional)
The size, in octets, of the resource when fully decoded (i.e., the The size, in octets, of the resource when fully decoded (i.e., the
number of octets in the file the user would download), if known. number of octets in the file the user would download), if known.
Note that this is an informational estimate, and implementations
must be prepared to handle the actual size being quite different
when the resource is fetched.
o rel: "String" (optional) o rel: "String" (optional)
Identifies the relation of the linked resource to the object. If Identifies the relation of the linked resource to the object. If
set, the value MUST be a relation type from the IANA registry set, the value MUST be a relation type from the IANA registry
[LINKRELS], as established in [RFC8288]. [LINKRELS], as established in [RFC8288].
Links with a rel of "enclosure" SHOULD be considered by the client Links with a rel of "enclosure" SHOULD be considered by the client
as attachments for download. as attachments for download.
skipping to change at page 20, line 7 skipping to change at page 20, line 7
4.2.10. categories 4.2.10. categories
Type: "String[Boolean]" (optional). Type: "String[Boolean]" (optional).
A set of categories that relate to the calendar object. The set is A set of categories that relate to the calendar object. The set is
represented as a map, with the keys being the categories specified as represented as a map, with the keys being the categories specified as
URIs. The value for each key in the map MUST be true. URIs. The value for each key in the map MUST be true.
In contrast to keywords, categories typically are structured. For In contrast to keywords, categories typically are structured. For
example, a vendor owning the domain "example.com" might define the example, a vendor owning the domain "example.com" might define the
categories "http://example.com/categories/sports/american-football"" categories "http://example.com/categories/sports/american-football"
and "http://example.com/categories/music/r-b". and "http://example.com/categories/music/r-b".
4.2.11. color 4.2.11. color
Type: "String" (optional). Type: "String" (optional).
A color clients MAY use when displaying this calendar object. The A color clients MAY use when displaying this calendar object. The
value is a color name taken from the set of names defined in value is a color name taken from the set of names defined in
Section 4.3 of CSS Color Module Level 3 [COLORS], or an RGB value in Section 4.3 of CSS Color Module Level 3 [COLORS], or an RGB value in
hexadecimal notation, as defined in Section 4.2.1 of CSS Color Module hexadecimal notation, as defined in Section 4.2.1 of CSS Color Module
skipping to change at page 22, line 44 skipping to change at page 22, line 44
* "fr" * "fr"
* "sa" * "sa"
* "su" * "su"
This is the WKST part from iCalendar. This is the WKST part from iCalendar.
o byDay: "NDay[]" (optional) o byDay: "NDay[]" (optional)
Days of the week on which to repeat. An *NDay* object has the Days of the week on which to repeat. An "NDay" object has the
following properties: following properties:
* day: "String" (mandatory) * day: "String" (mandatory)
A day of the week on which to repeat; the allowed values are A day of the week on which to repeat; the allowed values are
the same as for the "firstDayOfWeek" RecurrenceRule property. the same as for the "firstDayOfWeek" RecurrenceRule property.
This is the day-of-the-week of the BYDAY part in iCalendar, This is the day-of-the-week of the BYDAY part in iCalendar,
converted to lowercase. converted to lowercase.
skipping to change at page 36, line 17 skipping to change at page 36, line 17
The sequence number of the last response from the participant. If The sequence number of the last response from the participant. If
defined, this MUST be a non-negative integer. defined, this MUST be a non-negative integer.
This can be used to determine whether the participant has sent a This can be used to determine whether the participant has sent a
new RSVP following significant changes to the calendar object, and new RSVP following significant changes to the calendar object, and
to determine if future responses are responding to a current or to determine if future responses are responding to a current or
older view of the data. older view of the data.
o scheduleUpdated: "UTCDateTime" (optional) o scheduleUpdated: "UTCDateTime" (optional)
The "updated" property of the last iTIP response from the The timestamp for the most recent response from this participant.
participant.
This can be compared to the "updated" property timestamp in future This is the "updated" property of the last response when using
iTIP responses to determine if the response is older or newer than iTIP. It can be compared to the "updated" property in future
the current data. responses to detect and discard older responses delivered out of
order.
o invitedBy: "String" (optional) o invitedBy: "String" (optional)
The participant id of the participant who invited this one, if The participant id of the participant who invited this one, if
known. known.
o delegatedTo: "String[Boolean]" (optional) o delegatedTo: "String[Boolean]" (optional)
A set of participant ids that this participant has delegated their A set of participant ids that this participant has delegated their
participation to. Each key in the set MUST be the id of a participation to. Each key in the set MUST be the id of a
skipping to change at page 38, line 7 skipping to change at page 38, line 7
o @type: "String" (mandatory) o @type: "String" (mandatory)
Specifies the type of this object. This MUST be "Alert". Specifies the type of this object. This MUST be "Alert".
o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger"
(mandatory) (mandatory)
Defines when to trigger the alert. New types may be defined in Defines when to trigger the alert. New types may be defined in
future documents. future documents.
An *OffsetTrigger* object has the following properties: An "OffsetTrigger" object has the following properties:
* @type: "String" (mandatory) * @type: "String" (mandatory)
Specifies the type of this object. This MUST be Specifies the type of this object. This MUST be
"OffsetTrigger". "OffsetTrigger".
* offset: "SignedDuration" (mandatory). * offset: "SignedDuration" (mandatory).
Defines the offset at which to trigger the alert relative to Defines the offset at which to trigger the alert relative to
the time property defined in the "relativeTo" property of the the time property defined in the "relativeTo" property of the
skipping to change at page 38, line 35 skipping to change at page 38, line 35
Specifies the time property that the alert offset is relative Specifies the time property that the alert offset is relative
to. The value MUST be one of: to. The value MUST be one of:
+ "start": triggers the alert relative to the start of the + "start": triggers the alert relative to the start of the
calendar object calendar object
+ "end": triggers the alert relative to the end/due time of + "end": triggers the alert relative to the end/due time of
the calendar object the calendar object
An *AbsoluteTrigger* object has the following properties: An "AbsoluteTrigger" object has the following properties:
* @type: "String" (mandatory) * @type: "String" (mandatory)
Specifies the type of this object. This MUST be Specifies the type of this object. This MUST be
"AbsoluteTrigger". "AbsoluteTrigger".
* when: "UTCDateTime" (mandatory). * when: "UTCDateTime" (mandatory).
Defines a specific UTC date-time when the alert is triggered. Defines a specific UTC date-time when the alert is triggered.
An *UnknownTrigger* object is an object that contains a *@type* An "UnknownTrigger" object is an object that contains a "@type"
property whose value is not recognized (i.e., not "OffsetTrigger" property whose value is not recognized (i.e., not "OffsetTrigger"
or "AbsoluteTrigger"), plus zero or more other properties. This or "AbsoluteTrigger"), plus zero or more other properties. This
is for compatibility with client extensions and future is for compatibility with client extensions and future
specifications. Implementations SHOULD NOT trigger for trigger specifications. Implementations SHOULD NOT trigger for trigger
types they do not understand, but MUST preserve them. types they do not understand, but MUST preserve them.
o acknowledged: "UTCDateTime" (optional) o acknowledged: "UTCDateTime" (optional)
This records when an alert was last acknowledged. This is set This records when an alert was last acknowledged. This is set
when the user has dismissed the alert; other clients that sync when the user has dismissed the alert; other clients that sync
skipping to change at page 55, line 21 skipping to change at page 55, line 21
implementations may still wish to place limits on the size of implementations may still wish to place limits on the size of
allocations they are willing to make in any given context, to avoid allocations they are willing to make in any given context, to avoid
untrusted data causing excessive memory allocation. untrusted data causing excessive memory allocation.
7.3. URI Values 7.3. URI Values
Several JSCalendar properties contain URIs as values, and processing Several JSCalendar properties contain URIs as values, and processing
these properties requires extra care. Section 7 of [RFC3986] these properties requires extra care. Section 7 of [RFC3986]
discusses security risk related to URIs. discusses security risk related to URIs.
A maliciously constructed JSCalendar object may contain a very large
number of URIs. In the case of published calendars with a large
number of subscribers, such objects could be widely distributed.
Implementations should be careful to limit the automatic fetching of
linked resources to reduce the risk of this being an amplification
vector for a denial-of-service attack.
8. IANA Considerations 8. IANA Considerations
8.1. Media Type Registration 8.1. Media Type Registration
This document defines a media type for use with JSCalendar data This document defines a 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
skipping to change at page 56, line 38 skipping to change at page 56, line 46
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
8.2. Creation of "JSCalendar Properties" Registry 8.2. Creation of "JSCalendar Properties" Registry
The IANA will create the "JSCalendar Properties" registry to allow The IANA will create the "JSCalendar Properties" registry to allow
interoperability of extensions to JSCalendar objects. interoperability of extensions to JSCalendar objects.
This registry follows the Expert Review process ([RFC8126], This registry follows the Expert Review process ([RFC8126],
Section 4.5) unless the "intended use" field is "common", in which Section 4.5). If the "intended use" field is "common", sufficient
case registration follows the Specification Required process documentation is required to enable interoperability. Preliminary
([RFC8126], Section 4.6). Preliminary community review for this community review for this registry is optional but strongly
registry is optional but strongly encouraged. encouraged.
A registration can have an intended use of "common", "reserved", or A registration can have an intended use of "common", "reserved", or
"obsolete". The IANA will list common-use registrations prominently "obsolete". The IANA will list common-use registrations prominently
and separately from those with other intended use values. and separately from those with other intended use values.
A "reserved" registration reserves a property name without assigning A "reserved" registration reserves a property name without assigning
semantics to avoid name collisions with future extensions or protocol semantics to avoid name collisions with future extensions or protocol
use. use.
An "obsolete" registration denotes a property that is no longer An "obsolete" registration denotes a property that is no longer
skipping to change at page 74, line 30 skipping to change at page 74, line 30
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types
Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006,
<https://www.rfc-editor.org/info/rfc4589>. <https://www.rfc-editor.org/info/rfc4589>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", Scheduling Core Object Specification (iCalendar)",
RFC 5545, DOI 10.17487/RFC5545, September 2009, RFC 5545, DOI 10.17487/RFC5545, September 2009,
<https://www.rfc-editor.org/info/rfc5545>. <https://www.rfc-editor.org/info/rfc5545>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
skipping to change at page 75, line 37 skipping to change at page 75, line 42
[TZDB] "IANA Time Zone Database", [TZDB] "IANA Time Zone Database",
<https://www.iana.org/time-zones>. <https://www.iana.org/time-zones>.
10.2. Informative References 10.2. Informative References
[LINKRELS] [LINKRELS]
"IANA Link Relation Types", "IANA Link Relation Types",
<https://www.iana.org/assignments/link-relations/link- <https://www.iana.org/assignments/link-relations/link-
relations.xhtml>. relations.xhtml>.
[LOCATIONTYPES]
"IANA Location Types Registry",
<https://www.iana.org/assignments/location-type-registry/
location-type-registry.xhtml>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
 End of changes. 24 change blocks. 
31 lines changed or deleted 54 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/