--- 1/draft-ietf-calext-jscalendar-15.txt 2019-06-24 06:13:56.401623694 -0700 +++ 2/draft-ietf-calext-jscalendar-16.txt 2019-06-24 06:13:56.453624321 -0700 @@ -1,18 +1,18 @@ Calendaring extensions N. Jenkins Internet-Draft R. Stepanek Intended status: Standards Track FastMail -Expires: December 19, 2019 June 17, 2019 +Expires: December 26, 2019 June 24, 2019 JSCalendar: A JSON representation of calendar data - draft-ietf-calext-jscalendar-15 + draft-ietf-calext-jscalendar-16 Abstract This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative to the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 19, 2019. + This Internet-Draft will expire on December 26, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -77,51 +77,51 @@ 4.1.3. relatedTo . . . . . . . . . . . . . . . . . . . . . . 11 4.1.4. prodId . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.5. created . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.6. updated . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.7. sequence . . . . . . . . . . . . . . . . . . . . . . 12 4.1.8. method . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. What and where properties . . . . . . . . . . . . . . . . 13 4.2.1. title . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. description . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. descriptionContentType . . . . . . . . . . . . . . . 13 - 4.2.4. locations . . . . . . . . . . . . . . . . . . . . . . 13 - 4.2.5. virtualLocations . . . . . . . . . . . . . . . . . . 14 - 4.2.6. links . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.2.7. locale . . . . . . . . . . . . . . . . . . . . . . . 16 - 4.2.8. keywords . . . . . . . . . . . . . . . . . . . . . . 16 - 4.2.9. categories . . . . . . . . . . . . . . . . . . . . . 16 - 4.2.10. color . . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.2.4. showWithoutTime . . . . . . . . . . . . . . . . . . . 13 + 4.2.5. locations . . . . . . . . . . . . . . . . . . . . . . 14 + 4.2.6. virtualLocations . . . . . . . . . . . . . . . . . . 15 + 4.2.7. links . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.2.8. locale . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.2.9. keywords . . . . . . . . . . . . . . . . . . . . . . 17 + 4.2.10. categories . . . . . . . . . . . . . . . . . . . . . 17 + 4.2.11. color . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Recurrence properties . . . . . . . . . . . . . . . . . . 17 4.3.1. recurrenceRule . . . . . . . . . . . . . . . . . . . 17 4.3.2. recurrenceOverrides . . . . . . . . . . . . . . . . . 23 4.3.3. excluded . . . . . . . . . . . . . . . . . . . . . . 24 4.4. Sharing and scheduling properties . . . . . . . . . . . . 24 4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 24 - 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 24 + 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 25 4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 25 4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 26 - 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 26 + 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 27 4.5. Alerts properties . . . . . . . . . . . . . . . . . . . . 30 4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 30 4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 30 4.6. Multilingual properties . . . . . . . . . . . . . . . . . 32 4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 32 4.7. Time zone properties . . . . . . . . . . . . . . . . . . 33 4.7.1. timeZones . . . . . . . . . . . . . . . . . . . . . . 33 - 5. Type-specific JSCalendar properties . . . . . . . . . . . . . 34 - 5.1. JSEvent properties . . . . . . . . . . . . . . . . . . . 34 + 5. Type-specific JSCalendar properties . . . . . . . . . . . . . 35 + 5.1. JSEvent properties . . . . . . . . . . . . . . . . . . . 35 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 35 5.1.2. timeZone . . . . . . . . . . . . . . . . . . . . . . 35 5.1.3. duration . . . . . . . . . . . . . . . . . . . . . . 35 - 5.1.4. isAllDay . . . . . . . . . . . . . . . . . . . . . . 35 - 5.1.5. status . . . . . . . . . . . . . . . . . . . . . . . 36 + 5.1.4. status . . . . . . . . . . . . . . . . . . . . . . . 36 5.2. JSTask properties . . . . . . . . . . . . . . . . . . . . 36 5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2.2. start . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2.3. timeZone . . . . . . . . . . . . . . . . . . . . . . 36 5.2.4. estimatedDuration . . . . . . . . . . . . . . . . . . 36 5.2.5. statusUpdatedAt . . . . . . . . . . . . . . . . . . . 37 5.2.6. progress . . . . . . . . . . . . . . . . . . . . . . 37 5.2.7. status . . . . . . . . . . . . . . . . . . . . . . . 38 5.3. JSGroup properties . . . . . . . . . . . . . . . . . . . 38 5.3.1. entries . . . . . . . . . . . . . . . . . . . . . . . 39 @@ -135,46 +135,45 @@ 6.6. Event with end time-zone . . . . . . . . . . . . . . . . 42 6.7. Floating-time event (with recurrence) . . . . . . . . . . 42 6.8. Event with multiple locations and localization . . . . . 43 6.9. Recurring event with overrides . . . . . . . . . . . . . 44 6.10. Recurring event with participants . . . . . . . . . . . . 45 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 10.1. Normative References . . . . . . . . . . . . . . . . . . 48 - 10.2. Informative References . . . . . . . . . . . . . . . . . 50 + 10.2. Informative References . . . . . . . . . . . . . . . . . 51 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 1. Introduction This document defines a data model for calendar event and task objects, or groups of such objects, in electronic calendar applications and systems. It aims to be unambiguous, extendable and simple to process. The key design considerations for this data model are as follows: o The attributes of the calendar entry represented must be described as a simple key-value pair, reducing complexity of its representation. o The data model should avoid all ambiguities and make it difficult to make mistakes during implementation. o Most of the initial set of attributes should be taken from the - iCalendar data format ([RFC5545] and [RFC7986], also see - Section 1.1), but the specification should add new attributes or - value types, or not support existing ones, where appropriate. - Conversion between the data formats need not fully preserve - semantic meaning. + iCalendar data format [RFC5545] and [RFC7986] and extensions, but + the specification should add new attributes or value types, or not + support existing ones, where appropriate. Conversion between the + data formats need not fully preserve semantic meaning. o Extensions, such as new properties and components, MUST NOT lead to requiring an update to this document. The representation of this data model is defined in the I-JSON format [RFC7493], which is a strict subset of the JavaScript Object Notation (JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a pragmatic choice: its widespread use makes JSCalendar easier to adopt, and the ready availability of production-ready JSON implementations eliminates a whole category of parser-related @@ -338,21 +337,21 @@ dur-time = "T" (dur-hour / dur-minute / dur-second) dur-day = 1*DIGIT "D" dur-week = 1*DIGIT "W" duration = "P" (dur-day [dur-time] / dur-time / dur-week) In addition, the duration MUST NOT include fractional second values unless the fraction is non-zero. A SignedDuration object is represented as a duration, optionally - preceeded by a sign character. It typically is used to express the + preceded by a sign character. It typically is used to express the offset of a point in time relative to an associated time. It is specified by the following ABNF: signed-duration = (["+"] / "-") duration A negative sign indicates a point in time at or before the associated time, a positive or no sign a time at or after the associated time. 3.2.4. PatchObject @@ -593,21 +592,34 @@ Type: String (optional, default: "text/plain"). Describes the media type ([RFC6838]) of the contents of the "description" property. Media types MUST be sub-types of type "text", and SHOULD be "text/plain" or "text/html" ([MIME]). They MAY define parameters and the "charset" parameter value MUST be "utf-8", if specified. Descriptions of type "text/html" MAY contain "cid" URLs ([RFC2392]) to reference links in the calendar object by use of the "cid" property of the Link object. -4.2.4. locations +4.2.4. showWithoutTime + + Type: Boolean (optional, default: "false"). + + Indicates the time is not important to display to the user when + rendering this calendar object, for example an event that + conceptually occurs all day or across multiple days, such as "New + Year's Day" or "Italy Vacation". While the time component is + important for free-busy calculations and checking for scheduling + clashes, calendars may choose to omit displaying it and/or display + the object separately to other objects to enhance the user's view of + their schedule. + +4.2.5. locations Type: String[Location] (optional). A map of location identifiers to Location objects, representing locations associated with the object. A Location object has the following properties. It must define at least one other property than the "relativeTo" property. o name: String (optional, default: empty String). The human- @@ -638,21 +650,21 @@ o linkIds: String[Boolean] (optional). A set of link ids for links to alternate representations of this location. Each key in the set MUST be the identifier of a Link object defined in the "links" property of this calendar object. The value for each key in the set MUST be "true". This MUST be omitted if none (rather than an empty set). For example, an alternative representation could be in vCard format. -4.2.5. virtualLocations +4.2.6. virtualLocations Type: String[VirtualLocation] (optional). A map of identifiers to VirtualLocation objects, representing virtual locations, such as video conferences or chat rooms, associated with the object. A VirtualLocation object has the following properties. o name: String (optional, default: empty String). The human- @@ -662,21 +674,21 @@ instructions for accessing this location. This may be an address, set of directions, door access code, etc. o uri: String (mandatory). A URI that represents how to connect to this virtual location. This may be a telephone number (represented as "tel:+1-555-555-555") for a teleconference, a web address for online chat, or any custom URI. -4.2.6. links +4.2.7. links Type: String[Link] (optional). A map of link identifiers to Link objects, representing external resources associated with the object. A Link object has the following properties: o href: String (mandatory). A URI from which the resource may be fetched. @@ -724,49 +736,49 @@ * "graphic": a full image replacement for the object itself * "fullsize": an image that is used to enhance the object * "thumbnail": a smaller variant of "fullsize " to be used when space for the image is constrained o title: String (optional). A human-readable plain-text description of the resource. -4.2.7. locale +4.2.8. locale Type: String (optional). The [RFC5646] language tag that best describes the locale used for the calendar object, if known. -4.2.8. keywords +4.2.9. keywords Type: String[Boolean] (optional). A set of keywords or tags that relate to the object. The set is represented as a map, with the keys being the keywords. The value for each key in the map MUST be "true". -4.2.9. categories +4.2.10. categories Type: String[Boolean] (optional). 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 URIs. The value for each key in the map MUST be "true". In contrast to keywords, categories typically are structured. For example, a vendor owning the domain "example.com" might define the categories "http://example.com/categories/sports/american-football"" and "http://example.com/categories/music/r-b". -4.2.10. color +4.2.11. color Type: String (optional). Specifies a color clients MAY use when displaying this calendar 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-color-20110607 [3] or a CSS3 RGB color hex value. 4.3. Recurrence properties @@ -956,38 +969,38 @@ last occurrence within that period. * byHour: the date-time has the given hour value. * byMinute: the date-time has the given minute value. * bySecond: the date-time has the given second value. If a skip property is defined and is not "omit", there may be candidates that do not correspond to valid dates (e.g. 31st - Februrary in the gregorian calendar). In this case, the + February in the gregorian calendar). In this case, the properties MUST be considered in the order above and: 1. After applying the byMonth filter, if the candidate's month is invalid for the given year increment it (if skip is "forward") or decrement it (if skip is "backward") until a valid month is found, incrementing/decrementing the year as well if you pass through the beginning/end of the year. This only applies to calendar systems with leap months. 2. After applying the byMonthDay filter, if the day of the month is invalid for the given month and year, change the date to the first day of the next month (if skip == "forward") or the last day of the current month (if skip == "backward"). 3. If any valid date produced after applying the skip is already a candidate, eliminate the duplicate. (For example after - adjusting, 30th Februrary and 31st February would both become + adjusting, 30th February and 31st February would both become the same "real" date, so one is eliminated as a duplicate.) 3. If a bySetPosition property is included, this is now applied to the ordered list of remaining dates (this property specifies the indexes of date-times to keep; all others should be eliminated. Negative numbers are indexes from the end of the list, with -1 being the last item). 4. Any date-times before the start date of the event are eliminated (see below for why this might be needed). @@ -1159,47 +1173,47 @@ o "public": The full details of the object are visible to those whom the object's calendar is shared with. o "private": The details of the object are hidden; only the basic time and metadata is shared. The following properties MAY be shared, any other properties MUST NOT be shared: * @type - * uid - * created - * updated + * due + * duration - * sequence + * estimatedDuration * freeBusyStatus * privacy - * start + * recurrenceOverrides. Only patches whose keys are prefixed with + one of the above properties are allowed to be shared. - * isAllDay + * sequence - * timeZone - * timeZones + * showWithoutTime - * duration + * start - * estimatedDuration + * timeZone - * due + * timeZones - * recurrenceOverrides. Only patches whose keys are prefixed with - one of the above properties are allowed to be shared. + * uid + + * updated o "secret": The object is hidden completely (as though it did not exist) when the object is shared. 4.4.4. replyTo Type: String[String] (optional). Represents methods by which participants may submit their RSVP response to the organizer of the calendar object. The keys in the @@ -1638,30 +1652,21 @@ 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 minutes, and number of seconds. Fractional seconds MUST be added last. A JSEvent MAY involve start and end locations that are in different time zones (e.g. a trans-continental flight). This can be expressed using the "relativeTo" and "timeZone" properties of the JSEvent's "location" objects. -5.1.4. isAllDay - - Type: Boolean (optional, default: "false"). - - Indicates whether this event is meant to represent an all-day event, - and SHOULD be presented accordingly in a calendaring application. - The value of this property is independent of the actual time-span - covered by this event. - -5.1.5. status +5.1.4. status Type: String (optional, default: "confirmed"). The scheduling status (Section 4.4) of a JSEvent. If set, it MUST be one of: o "confirmed": Indicates the event is definite. o "cancelled": Indicates the event is cancelled. @@ -1883,21 +1888,21 @@ 6.4. All-day event This example illustrates an event for an international holiday. It specifies an all-day event on April 1 that occurs every year since the year 1900. { "...": "", "title": "April Fool's Day", - "isAllDay": true, + "showWithoutTime": true, "start": "1900-04-01T00:00:00", "duration": "P1D", "recurrenceRule": { "frequency": "yearly" } } 6.5. Task with a due date This example illustrates a task with a due date. It is a reminder to @@ -2116,20 +2121,24 @@ that a flaw in the parser processing JSON could still impose a threat, which doesn't arise with conventional iCalendar data. With this in mind, a parser for JSON data aware of the security implications should be used for the format described in this document. For example, the use of JavaScript's "eval()" function is considered an unacceptable security risk, as described in Section 12 of[RFC8259]. A native parser with full awareness of the JSON format should be preferred. + Several JSCalendar properties contain URIs as values, and processing + these properties requires extra care. Section 7 of [RFC3986] + discusses security risk related to URIs. + 8. IANA Considerations This document defines a MIME media type for use with JSCalendar data formatted in JSON. Type name: application Subtype name: jscalendar+json Required parameters: type @@ -2148,21 +2157,21 @@ Security considerations: See Section 7 of this document. Interoperability considerations: This media type provides an alternative to iCalendar, jCal and proprietary JSON-based calendaring data formats. Published specification: This specification. Applications that use this media type: Applications that currently 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. Similarly, applications that use the application/json media type to transfer calendaring data can use this to further specify the content. Fragment identifier considerations: N/A Additional information: Magic number(s): N/A File extensions(s): N/A