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

worley@ariadne.com (Dale R. Worley) Fri, 29 September 2017 01:58 UTC

Return-Path: <worley@alum.mit.edu>
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 A4DC5134A18 for <dispatch@ietfa.amsl.com>; Thu, 28 Sep 2017 18:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 BFQfuNzfbOrd for <dispatch@ietfa.amsl.com>; Thu, 28 Sep 2017 18:58:23 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 001F9134A15 for <dispatch@ietf.org>; Thu, 28 Sep 2017 18:58:22 -0700 (PDT)
Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id xkY6ds7ddzQG8xkZKdfy4I; Fri, 29 Sep 2017 01:58:22 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-14v.sys.comcast.net with SMTP id xkZId4lCGCzrXxkZIdQ8oI; Fri, 29 Sep 2017 01:58:21 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v8T1wKLi023735; Thu, 28 Sep 2017 21:58:20 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v8T1wJf0023732; Thu, 28 Sep 2017 21:58:19 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Robert Stepanek <rsto@fastmailteam.com>
Cc: dispatch@ietf.org, neilj@fastmailteam.com, brong@fastmailteam.com
In-Reply-To: <1506588219.485384.1120927832.1112E2F6@webmail.messagingengine.com> (rsto@fastmailteam.com)
Sender: worley@ariadne.com
Date: Thu, 28 Sep 2017 21:58:19 -0400
Message-ID: <87h8vm8dvo.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfOJWG/6QXNxm5GioS1fQBSCTZk096+Tb9x2NTKwykN88uDHrHnxzg56/npxTrOB28FqfTef6cWhfTHlgw4rrADi9HVNsI+KLiS2nN6yTLP4zRkcj0+2/ epnvF/gSUtUSP1v/KCDeunhr0xIQDLio8liVLh2nfMtoW8pJxMqQ9zWKkabs8dJnZdnI39LBXO8uX+/rTTqiEffEX8V6pBNpTiCPa0pee7pOHLMCAwsARNyc yV+vviDP+p9wLhds2nOrZNmNbyeTiuqqTmhQzbHsgLY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/vRHpxLZ4xiJi2luhu-65cUcYMw0>
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: Fri, 29 Sep 2017 01:58:25 -0000

Robert Stepanek <rsto@fastmailteam.com> writes:
> Do you have any feedback on this? What would make you use  the new
> format, what is it currently missing?

Given that any practical implementation has to interoperate with iCal,
the barrier to entry is high.  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?  (Coming from the world of SIP,
I've learned that things that are nightmarish for implementors are often
criticial to real-world use of the protocol) Ease of implementation is
nice, but given the need to interoperate with iCal for many years, it
has limited value.  Also, to what degree does the simplicity of
JSCalendar simply push work back into the interface between the
calendaring system and the JSCalendar interface?

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?

Dale