draft-ietf-calext-jscalendar-06.txt   draft-ietf-calext-jscalendar-07.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: March 3, 2019 August 30, 2018 Expires: March 24, 2019 September 20, 2018
JSCalendar: A JSON representation of calendar data JSCalendar: A JSON representation of calendar data
draft-ietf-calext-jscalendar-06 draft-ietf-calext-jscalendar-07
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. extendable and simple to process.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 March 3, 2019. This Internet-Draft will expire on March 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 8 skipping to change at page 3, line 8
4.3.2. recurrenceOverrides . . . . . . . . . . . . . . . . . 21 4.3.2. recurrenceOverrides . . . . . . . . . . . . . . . . . 21
4.3.3. excluded . . . . . . . . . . . . . . . . . . . . . . 22 4.3.3. excluded . . . . . . . . . . . . . . . . . . . . . . 22
4.4. Sharing and scheduling properties . . . . . . . . . . . . 22 4.4. Sharing and scheduling properties . . . . . . . . . . . . 22
4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 22 4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 22
4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 22 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 22
4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 23 4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 24 4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.5. participants . . . . . . . . . . . . . . . . . . . . 25 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 25
4.5. Alerts properties . . . . . . . . . . . . . . . . . . . . 27 4.5. Alerts properties . . . . . . . . . . . . . . . . . . . . 27
4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 27 4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 27
4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 27 4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 28
4.6. Multilingual properties . . . . . . . . . . . . . . . . . 29 4.6. Multilingual properties . . . . . . . . . . . . . . . . . 29
4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 29 4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 29
5. Type-specific JSCalendar properties . . . . . . . . . . . . . 30 5. Type-specific JSCalendar properties . . . . . . . . . . . . . 30
5.1. JSEvent properties . . . . . . . . . . . . . . . . . . . 30 5.1. JSEvent properties . . . . . . . . . . . . . . . . . . . 30
5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.2. timeZone . . . . . . . . . . . . . . . . . . . . . . 30 5.1.2. timeZone . . . . . . . . . . . . . . . . . . . . . . 30
5.1.3. duration . . . . . . . . . . . . . . . . . . . . . . 30 5.1.3. duration . . . . . . . . . . . . . . . . . . . . . . 30
5.1.4. isAllDay . . . . . . . . . . . . . . . . . . . . . . 31 5.1.4. isAllDay . . . . . . . . . . . . . . . . . . . . . . 31
5.1.5. status . . . . . . . . . . . . . . . . . . . . . . . 31 5.1.5. status . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. JSTask properties . . . . . . . . . . . . . . . . . . . . 31 5.2. JSTask properties . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 8, line 41 skipping to change at page 8, line 41
o Anything else: The value to replace the inherited property on the o Anything else: The value to replace the inherited property on the
patch object with (if present) or add to the property (if not patch object with (if present) or add to the property (if not
present). present).
Implementations MUST reject a PatchObject if any of its patches are Implementations MUST reject a PatchObject if any of its patches are
invalid. invalid.
3.2.5. Identifiers 3.2.5. Identifiers
If not noted otherwise, properties that define identifiers MUST be If not noted otherwise, properties and object keys that define
string values, MUST be at least 1 character in length and maximum 256 identifiers MUST be string values, MUST be at least 1 character in
octets in size, and MUST only contain characters from the "URL and length and maximum 256 octets in size, and MUST only contain
Filename safe" Base 64 Alphabet, as defined in section 5 of characters from the "URL and Filename safe" Base 64 Alphabet, as
[RFC4648]. This is the ASCII alphanumeric characters (A-Za-z0-9), defined in section 5 of [RFC4648]. This is the ASCII alphanumeric
hyphen (-), and underscore (_). characters (A-Za-z0-9), hyphen (-), and underscore (_).
3.2.6. Normalization and equivalence 3.2.6. Normalization and equivalence
JSCalendar aims to provide unambiguous definitions for value types JSCalendar aims to provide unambiguous definitions for value types
and properties, but does not define a general normalization or and properties, but does not define a general normalization or
equivalence method for JSCalendar objects and types. This is because equivalence method for JSCalendar objects and types. This is because
the notion of equivalence might range from byte-level equivalence to the notion of equivalence might range from byte-level equivalence to
semantic equivalence, depending on the respective use case (for semantic equivalence, depending on the respective use case (for
example, the CalDAV protocol [RFC4791] requires octet equivalence of example, the CalDAV protocol [RFC4791] requires octet equivalence of
the encoded calendar object to determine ETag equivalence). the encoded calendar object to determine ETag equivalence).
skipping to change at page 10, line 48 skipping to change at page 10, line 48
Relates the object to other JSCalendar objects. This is represented Relates the object to other JSCalendar objects. This is represented
as a map of the uids of the related objects to information about the as a map of the uids of the related objects to information about the
relation. relation.
A *Relation* object has the following properties: A *Relation* object has the following properties:
o *relation*: "String[]" Describes how the linked object is related o *relation*: "String[]" Describes how the linked object is related
to this object. to this object.
The strings in the array MUST each be at most one of the following Strings in the array MUST be one of the following values, defined
values, registered in a future RFC, or a vendor-specific value: in a future specification or a vendor-specific value. There MUST
NOT be duplicate strings in the array.
* "first": The linked object is the first in the series this * "first": The linked object is the first in the series this
object is part of. object is part of.
* "next": The linked object is the next in the series this object * "next": The linked object is the next in the series this object
is part of. is part of.
* "child": The linked object is a subpart of this object. * "child": The linked object is a subpart of this object.
* "parent": This object is part of the overall linked object. * "parent": This object is part of the overall linked object.
skipping to change at page 12, line 50 skipping to change at page 12, line 50
define parameters and the "charset" parameter MUST be "utf-8", if define parameters and the "charset" parameter MUST be "utf-8", if
specified. Descriptions of type "text/html" MAY contain "cid" URLs specified. Descriptions of type "text/html" MAY contain "cid" URLs
([RFC2392]) to reference links in the calendar object by use of the ([RFC2392]) to reference links in the calendar object by use of the
*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 ids to Location objects, representing locations A map of location ids to Location objects, representing locations
associated with the object. A location id may be any valid [RFC6901] associated with the object. A location id MUST be unique to this
JSON pointer and need only be unique to this object; a UUID is a object; a UUID is a practical choice.
practical choice.
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 *rel*.
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.
skipping to change at page 13, line 47 skipping to change at page 13, line 47
For example, an alternative representation could be in vCard For example, an alternative representation could be in vCard
format. format.
4.2.5. virtualLocations 4.2.5. virtualLocations
Type: "String[VirtualLocation]" (optional) Type: "String[VirtualLocation]" (optional)
A map of ids to VirtualLocation objects, representing virtual A map of ids to VirtualLocation objects, representing virtual
locations, such as video conferences or chat rooms, associated with locations, such as video conferences or chat rooms, associated with
the object. A virtual location id may be any valid [RFC6901] JSON the object. A virtual location id MUST be unique to this object; a
pointer and need only be unique to this object; a UUID is a practical UUID is a practical choice.
choice.
A *VirtualLocation* object has the following properties. A *VirtualLocation* object has the following properties.
o *name*: "String" (optional, default:"") The human-readable name of o *name*: "String" (optional, default:"") The human-readable name of
the virtual location. the virtual 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.
skipping to change at page 14, line 24 skipping to change at page 14, line 24
This may be a telephone number (represented as This may be a telephone number (represented as
"tel:+1-555-555-555") for a teleconference, a web address for "tel:+1-555-555-555") for a teleconference, a web address for
online chat, or any custom URI. online chat, or any custom URI.
4.2.6. links 4.2.6. links
Type: "String[Link]" (optional) Type: "String[Link]" (optional)
A map of link ids to Link objects, representing external resources A map of link ids to Link objects, representing external resources
associated with the object. A link id may be any valid [RFC6901] associated with the object. A link id MUST be unique to this
JSON pointer and need only be unique to this object; the href or a calendar object; a UUID is a practical choice.
UUID are practical choices.
A *Link* object has the following properties: A *Link* object has the following properties:
o *href*: "String" A URI from which the resource may be fetched. o *href*: "String" A URI from which the resource may be fetched.
This MAY be a "data:" URL, but it is recommended that the file be This MAY be a "data:" URL, but it is recommended that the file be
hosted on a server to avoid embedding arbitrarily large data in hosted on a server to avoid embedding arbitrarily large data in
JSCalendar object instances. JSCalendar object instances.
o *cid* "String" (optional) This MUST be a valid "content-id" value o *cid* "String" (optional) This MUST be a valid "content-id" value
skipping to change at page 24, line 20 skipping to change at page 24, line 20
Type: "String[String]" (optional) Type: "String[String]" (optional)
Represents methods by which participants may submit their RSVP Represents methods by which participants may submit their RSVP
response to the organizer of the calendar object. The keys in the response to the organizer of the calendar object. The keys in the
property value are the available methods. The value is a URI to use property value are the available methods. The value is a URI to use
that method. Future methods may be defined in future specifications; that method. Future methods may be defined in future specifications;
a calendar client MUST ignore any method it does not understand. a calendar client MUST ignore any method it does not understand.
The following methods are defined: The following methods are defined:
o "imip": The organizer accepts an iMIP [RFC6047] response. The o "imip": The organizer accepts an iMIP [RFC6047] response at this
value MUST be a "mailto:" URI. email address. The value MUST be a "mailto:" URI.
o "web": There is a web page where the user may submit the RSVP o "other": The user may submit the RSVP using this URI. The URI
response using a browser. The value MUST be a "https:" URI MUST be a valid URI Template ([RFC6570]) in level 2 format. The
Template ([RFC6570]) in level 1 format. The template MAY contain template MAY contain variables that MUST be expanded from the
variables that MUST be expanded from the JSCalendar object as JSCalendar object as defined in table Table 1. Calendar clients
defined in table Table 1. Calendar clients SHOULD be prepared to SHOULD be prepared to handle authentication requests from the
handle authentication requests from the respective web page and respective URI and for the participant email, but this
for the participant email, but this specification does not mandate specification does not mandate any specific mechanism.
any specific mechanism.
+--------------+----------------------------------------------------+ +---------------+---------------------------------------------------+
| Variable | Expand to | | Variable | Expand to |
+--------------+----------------------------------------------------+ +---------------+---------------------------------------------------+
| email | The *email* property value of the replying | | participantId | The participant id of the replying *Participant* |
| | *Participant* object. | | | object. |
| | | | | |
| uid | The *uid* property value of the JSCalendar object. | | uid | The *uid* property value of the JSCalendar |
| | | | | object. |
| sequence | The *sequence* property value of the JSCalendar | | | |
| | object. | | sequence | The *sequence* property value of the JSCalendar |
| | | | | object. |
| recurrenceId | The recurrence-id when replying for a single | | | |
| | occurrence of a recurring JSCalendar object. The | | recurrenceId | The recurrence-id when replying for a single |
| | LocalDate-typed value is the recurrence-id of a | | | occurrence of a recurring JSCalendar object. The |
| | non-overridden recurrence, or the key of a | | | LocalDate-typed value is the recurrence-id of a |
| | recurrenceOverride of this JSCalendar object. | | | non-overridden recurrence, or the key of a |
+--------------+----------------------------------------------------+ | | recurrenceOverride of this JSCalendar object. |
+---------------+---------------------------------------------------+
Table 1: replyTo URI Template variables Table 1: replyTo URI Template variables
4.4.5. participants 4.4.5. participants
Type: "String[Participant]" (optional) Type: "String[Participant]" (optional)
A map of participant ids to participants, describing their A map of participant ids to participants, describing their
participation in the calendar object. A participant id may be any participation in the calendar object. A participant id MUST be a
valid [RFC6901] JSON pointer and need only be unique to this calendar valid [RFC3986] URI and MUST be unique to this calendar object; a
object; the email address of the participant is a good choice. "mailto:" URI with the email address of the participant is a good
choice.
A *Participant* object has the following properties: A *Participant* object has the following properties:
o *name*: "String" The display name of the participant (e.g. "Joe o *name*: "String" The display name of the participant (e.g. "Joe
Bloggs"). Bloggs").
o *email*: "String" The email address for the participant. o *email*: "String" (optional) The email address for the
participant.
o *kind*: "String" (optional) What kind of entity this participant o *kind*: "String" (optional) What kind of entity this participant
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
skipping to change at page 28, line 4 skipping to change at page 28, line 8
If "true", use the user's default alerts and ignore the value of the If "true", use the user's default alerts and ignore the value of the
*alerts* property. Fetching user defaults is dependent on the API *alerts* property. Fetching user defaults is dependent on the API
from which this JSCalendar object is being fetched, and is not from which this JSCalendar object is being fetched, and is not
defined in this specification. If an implementation cannot determine defined in this specification. If an implementation cannot determine
the user's default alerts, or none are set, it MUST process the the user's default alerts, or none are set, it MUST process the
alerts property as if useDefaultAlerts is set to "false". alerts property as if useDefaultAlerts is set to "false".
4.5.2. alerts 4.5.2. alerts
Type: "String[Alert]" (optional) Type: "String[Alert]" (optional)
A map of alert ids to Alert objects, representing alerts/reminders to A map of alert ids to Alert objects, representing alerts/reminders to
display or send the user for this calendar object. An alert id may display or send the user for this calendar object. The id MUST be
be any valid [RFC6901] JSON pointer and need only be unique to this unique to this calendar object; a UUID is a practical choice.
calendar object; a globally unique id is a practical choice (also see
Section 4.1.2)).
An *Alert* Object has the following properties: An *Alert* Object has the following properties:
o *relativeTo*: "String" (optional, default:"before-start") o *relativeTo*: "String" (optional, default:"before-start")
Specifies where the offset is relative to for the alarm to Specifies where the offset is relative to for the alarm to
trigger. The value MUST be one of: trigger. The value MUST be one of:
* "before-start" * "before-start"
* "after-start" * "after-start"
skipping to change at page 33, line 24 skipping to change at page 33, line 24
but "accepted". but "accepted".
A *ParticipantProgress* object has the following properties: A *ParticipantProgress* object has the following properties:
o *status*: "String" Describes the completion status of the o *status*: "String" Describes the completion status of the
participant's progress. participant's progress.
The value MUST be at most one of the following values, registered The value MUST be at most one of the following values, registered
in a future RFC, or a vendor-specific value: in a future RFC, or a vendor-specific value:
* "completed": The participant completed their progress. * "completed": The participant completed their task.
* "in-process": The participant processes this task. * "in-process": The participant has started this task.
* "failed": The participant failed to complete their progress. * "failed": The participant failed to complete their task.
o *timestamp*: "UTCDate" Describes the last time when the o *timestamp*: "UTCDate" Describes the last time when the
participant progress got updated. participant progress got updated.
5.2.8. status 5.2.8. status
Type: "String" Type: "String"
Defines the overall status of this task. If omitted, the default Defines the overall status of this task. If omitted, the default
status (Section 4.4) of a JSTask is defined as follows (in order of status (Section 4.4) of a JSTask is defined as follows (in order of
skipping to change at page 40, line 11 skipping to change at page 40, line 11
| recurrenceRule | Corresponds to the RRULE property in | | recurrenceRule | Corresponds to the RRULE property in |
| | iCalendar. See the property definition | | | iCalendar. See the property definition |
| | at section Section 4.3.1 how to map a | | | at section Section 4.3.1 how to map a |
| | RRULE value. | | | RRULE value. |
| | | | | |
| relatedTo | Corresponds to the RELATED-TO property | | relatedTo | Corresponds to the RELATED-TO property |
| | in iCalendar. | | | in iCalendar. |
| | | | | |
| replyTo | An iCalendar ORGANIZER with one of the | | replyTo | An iCalendar ORGANIZER with one of the |
| | mapped URIs as value. If URIs are | | | mapped URIs as value. If URIs are |
| | defined for both the "imip" and "web" | | | defined for both the "imip" and "other" |
| | type, it is recommended to map the | | | type, it is recommended to map the |
| | "imip" value to the calendar address | | | "imip" value to the calendar address |
| | value of the ORGANIZER. | | | value of the ORGANIZER. |
| | | | | |
| sequence | Corresponds to the SEQUENCE property in | | sequence | Corresponds to the SEQUENCE property in |
| | iCalendar. | | | iCalendar. |
| | | | | |
| status | Corresponds to the STATUS property in | | status | Corresponds to the STATUS property in |
| | iCalendar (converted to lower-case). | | | iCalendar (converted to lower-case). |
| | | | | |
skipping to change at page 40, line 45 skipping to change at page 40, line 45
6.5. Locations and participants 6.5. Locations and participants
Both JSCalendar participants and locations have counterparts in Both JSCalendar participants and locations have counterparts in
iCalendar but provide richer representation. iCalendar but provide richer representation.
The following table outlines translation of JSCalendar participants. The following table outlines translation of JSCalendar participants.
Where iCalendar has distinct properties for ORGANIZER and ATTENDEE, Where iCalendar has distinct properties for ORGANIZER and ATTENDEE,
these are merged in JSCalendar into the Participant object type. these are merged in JSCalendar into the Participant object type.
+--------------------------------------------------+----------------+ +---------------+---------------------------------------------------+
| Property | iCalendar | | Property | iCalendar counterpart |
| | counterpart | +---------------+---------------------------------------------------+
+--------------------------------------------------+----------------+ | delegatedFrom | the DELEGATED-FROM parameter |
| delegatedFrom | the DELEGATED- | | | |
| | FROM parameter | | delegatedTo | the DELEGATED-TO parameter |
| | | | | |
| delegatedTo | email | | email | the value of the ORGANIZER or ATTENDEE property |
| | | | | |
| the value of the ORGANIZER or ATTENDEE property | kind | | kind | the CUTYPE parameter |
| | | | | |
| the CUTYPE parameter | linkIds | | linkIds | Implementation-specific. |
| | | | | |
| Implementation-specific. | locationId | | locationId | Implementation-specific. When mapping from |
| | | | | iCalendar to JSCalendar this may be the |
| Implementation-specific. When mapping from | memberOf | | | JSCalendar identifier of a CONFERENCE property |
| iCalendar to JSCalendar this may be the | | | | that has the MODERATOR feature defined in its |
| JSCalendar identifier of a CONFERENCE property | | | | FEATURE parameter values. If multiple such |
| that has the MODERATOR feature defined in its | | | | CONFERENCE properties are defined in iCalendar, |
| FEATURE parameter values. If multiple such | | | | then the one with the most interactive features |
| CONFERENCE properties are defined in iCalendar, | | | | is chosen. |
| then the one with the most interactive features | | | | |
| is chosen. | | | memberOf | the MEMBER parameter |
| | | | | |
| the MEMBER parameter | name | | name | the CN parameter |
| | | | | |
| the CN parameter | participation | | participation | Maps to the standard iCalendar ROLE parameter |
| | | | | values REQ-PARTICIPANT, OPT-PARTICIPANT and NON- |
| Maps to the standard iCalendar ROLE parameter | roles | | | PARTICIPANT. |
| values REQ-PARTICIPANT, OPT-PARTICIPANT and NON- | | | | |
| PARTICIPANT. | | | roles | The "chair" role maps to the standard iCalendar |
| | | | | ROLE parameter value "chair", with an implicit |
| The "chair" role maps to the standard iCalendar | rsvpResponse | | | participant of value "required". The mapping of |
| ROLE parameter value "chair", with an implicit | | | | non-required chairs and other roles is |
| participant of value "required". The mapping of | | | | implementation-specific, but using "x-name" |
| non-required chairs and other roles is | | | | parameter values is recommended. |
| implementation-specific, but using "x-name" | | | | |
| parameter values is recommended. | | | rsvpResponse | the PARTSTAT parameter |
| | | | | |
| the PARTSTAT parameter | the DELEGATED- | | the | scheduleSequence |
| | TO parameter | | DELEGATED-TO | |
| | | | parameter | |
| scheduleSequence | the SEQUENCE | | | |
| | property of | | the SEQUENCE | scheduleUpdated |
| | the | | property of | |
| | participant's | | the | |
| | latest iMIP | | participant's | |
| | message | | latest iMIP | |
| | | | message | |
| scheduleUpdated | the DTSTAMP | | | |
| | property of | | the DTSTAMP |
| | the | | property of |
| | participant's | | the |
| | latest iMIP | | participant's |
| | message | | latest iMIP |
+--------------------------------------------------+----------------+ | message |
+---------------+---------------------------------------------------+
Table 6: Translation of Participant between JSCalendar and iCalendar Table 6: Translation of Participant between JSCalendar and iCalendar
The iCalendar counterpart for JSCalendar Location objects is the The iCalendar counterpart for JSCalendar Location objects is the
iCalendar [RFC5545] LOCATION property, or implementation-specific. iCalendar [RFC5545] LOCATION property, or implementation-specific.
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Property | iCalendar counterpart | | Property | iCalendar counterpart |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| name | Corresponds to the LOCATION property value. | | name | Corresponds to the LOCATION property value. |
skipping to change at page 45, line 38 skipping to change at page 45, line 38
} }
7.6. Event with end time-zone 7.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. zone difference of the flight. The location names can serve as input
for navigation systems.
{ {
"...": "", "...": "",
"title": "Flight XY51 from FRA to NRT", "title": "Flight XY51 to Tokyo",
"start": "2018-04-01T09:00:00", "start": "2018-04-01T09:00:00",
"timeZone": "Europe/Berlin", "timeZone": "Europe/Berlin",
"duration": "PT10H30M", "duration": "PT10H30M",
"locations": { "locations": {
"2a358cee-6489-4f14-a57f-c104db4dc2f1": { "2a358cee-6489-4f14-a57f-c104db4dc2f1": {
"rel": "start",
"name": "Frankfurt Airport (FRA)"
},
"c2c7ac67-dc13-411e-a7d4-0780fb61fb08": {
"rel": "end", "rel": "end",
"name": "Narita International Airport (NRT)",
"timeZone": "Asia/Tokyo" "timeZone": "Asia/Tokyo"
} }
} }
} }
7.7. Floating-time event (with recurrence) 7.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
 End of changes. 25 change blocks. 
118 lines changed or deleted 124 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/