Re: [dispatch] Feedback requested: draft-jenkins-jscalendar

Robert Stepanek <rsto@fastmailteam.com> Mon, 02 October 2017 12:17 UTC

Return-Path: <rsto@fastmailteam.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3B01344EA for <dispatch@ietfa.amsl.com>; Mon, 2 Oct 2017 05:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.722
X-Spam-Level:
X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJWpyBGEDxGI for <dispatch@ietfa.amsl.com>; Mon, 2 Oct 2017 05:17:39 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2768E1345DF for <dispatch@ietf.org>; Mon, 2 Oct 2017 05:17:39 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9F66D20CD2; Mon, 2 Oct 2017 08:17:37 -0400 (EDT)
Received: from web1 ([10.202.2.211]) by compute1.internal (MEProxy); Mon, 02 Oct 2017 08:17:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=7WnbfD 6CZnX4zS6Q78RXkomv+RnCTGxAM4ONXqgCQos=; b=V+//CLzpEY/TjJyRp3JP59 +s98A/2qBgkaR7DLqKXvzpD8z0TBoIOsb3cPR0uFE6P/vfFGIvVejYs6IrzDRy78 uz7FV6JP3BxBXb0Hrlkx7ZE0mp9U+g6Ef+rn5EUZgm5dRGu8VA1d5WvYvroWzv/o 0a4WAnkCu6k64bZEREor1bmIUeC8Gg+o1CQsdw3PNn/uezBNeP0EHNL2zHOjmZyW xiNNfLmYqOWaRU0b8YNo6XDWnubWGg0JOD3ASl9EvPAycfmyGzH1zQggJL3/kAl0 vBgZLK/apLWbpNl91qq4xJnOrcWEkRy/716h/bQig/5E5Uus2suCRDmQeRBOd1oQ ==
X-ME-Sender: <xms:YS7SWXEbsoMbNMxppcX3lIB-zckJMxSomvEBGsCX5UU0AelBI4DoAA>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7754B95799; Mon, 2 Oct 2017 08:17:37 -0400 (EDT)
Message-Id: <1506946657.1867996.1124819272.427835FD@webmail.messagingengine.com>
From: Robert Stepanek <rsto@fastmailteam.com>
To: "Dale R. Worley" <worley@ariadne.com>
Cc: dispatch@ietf.org, neilj@fastmailteam.com, brong@fastmailteam.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-6cb49228
Date: Mon, 02 Oct 2017 14:17:37 +0200
References: <87h8vm8dvo.fsf@hobgoblin.ariadne.com>
In-Reply-To: <87h8vm8dvo.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/FjiOKt5K1GT2CA7jaOk9U9qOR5o>
Subject: Re: [dispatch] Feedback requested: draft-jenkins-jscalendar
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Oct 2017 12:17:41 -0000

On Fri, Sep 29, 2017, at 03:58, Dale R. Worley wrote:
> To what degree is this addressing actual
> failures of iCal (e.g., where iCal is ambiguous) and to what degree is
> it just *simpler* for the implementor? 

Two common pitfalls in iCalendar are embedded, custom timezones as well
as time-span definitions that overlap daylight-savings time boundaries.
JSCalendar addresses this by restricting timezones to the common IANA
timezone definitions and requiring time-spans to be expressed by
durations. In both cases, iCalendar per spec wasn't ambiguous, but in
practice has shown to confuse many implementations about the intent of
the calendar object creator.

> to what degree does the simplicity of
> JSCalendar simply push work back into the interface between the
> calendaring system and the JSCalendar interface?

Moving away from iCalendar format to JSON makes it actually simpler on
both client and server implementations to handle the wire format.
Feature-wise there isn't additional effort due to the data model, it's
very much in line with iCalendar.

> I suspect that in practice, semantic upward-compatibility from iCal will
> be important. 
> You mention in section 1 item 3, "a conversion between
> the data formats is not guaranteed to be completed without losing
> semantic meaning".  What exactly are the incompatibilities?

In Cyrus IMAPd, we store calendar objects in iCalendar format on disk
and serve them in JSCalendar format; compatibility with iCalendar is
important to us. I also know of other vendors who implemented a draft
version of JSCalendar to serve both formats with success. We take the
liberty to be incompatible with iCalendar where it benefits users and
allows richer semantics.

Notable differences are the ability to define multiple owners for an
event (versus a single ORGANIZER in iCalendar), the ability to localize
all text properties (versus a single allowed SUMMARY in iCalendar), the
ability to relate participants with locations and multi-location events
(e.g. a meeting that has participants attending by video, audio and
on-premises vs. a single LOCATION property in iCalendar). Probably we'll
also propose to allow rich-text descriptions similar to HTML email
bodies (versus plain-text only DESCRIPTION in iCalendar), but that's
undecided, yet.

Cheers,
Robert