From nobody Wed Nov 1 21:22:13 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33C913F63E for ; Wed, 1 Nov 2017 21:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 2-7upo7AihTU for ; Wed, 1 Nov 2017 21:22:10 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (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 4B84A139078 for ; Wed, 1 Nov 2017 21:22:10 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-01v.sys.comcast.net with ESMTP id A717ehv5nSLjfA717eQNGY; Thu, 02 Nov 2017 04:22:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1509596529; bh=lMWAhBWbjTUpSvITZ9xUuTG8vLS5K80dOL+6tfjqqiY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=TNAxFfyKwjUrefDepw+C4vGuMrpT6XQGb5J7IVgSxKFwDDpbmsZ4sBbpz7dOfFtTH v7eUaxSJqvuZ29OSyjh/x7jaSZ9B+1MIRH9IhuYrUc/67F8+c5ZPlCP/Y4X7V7UQAX j5ReU43Xo6bZghfRBIVEaLFLlS/USgvt2s081kf9ipDBOri8oJcA1uYs/4nvQkwB7C AGTd/ge3GFnvboQHjo6dSrD9YPXT12Wl1Oam7P4tjJASlh1huscyjFRKQtGez36ZD/ V2YEa9ho/xPxVBGxhBo7H02HtezpvFvQwSpgRb4ypS8B8wpwXhecPzozstXmxYyeXr PfJU3Jwd+ighA== Received: from [192.168.1.129] ([73.42.15.222]) by resomta-po-01v.sys.comcast.net with SMTP id A716eQOARDnByA717ev0BK; Thu, 02 Nov 2017 04:22:09 +0000 To: Robert Stepanek , calsify@ietf.org Cc: Alexey Melnikov References: <1506588212.485384.1120898568.4273A4D9@webmail.messagingengine.com> From: Tim Hare Message-ID: Date: Thu, 2 Nov 2017 00:22:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1506588212.485384.1120898568.4273A4D9@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Envelope: MS4wfPuIjs6UEbrwTY4DwjyR3jFBQte+9FNes5LLQ/YaYn9eHnu2ZItXIj1mUsGLbB/L3pCKbUEhAFNXW9moiqyypoo+t7KoMcU1JjeaiHiJlrFJszjofkod o+cHSvbLKbCt62/fuKfbqI9HPY3Q0NPL+aIrAjJR7uq4rd6XHbd9DKmdjnaPCCGEjlZF+xzIwk0d1JSEEDx7VrL+ulMf27Wouf2OGCBOA608pBxBB2GrEGuF Archived-At: Subject: Re: [calsify] Feedback requested: draft-jenkins-jscalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 04:22:12 -0000 It literally took years to get RFC5545 to the interoperability state that it is in now.  I hope, for the sake of interoperability, that you are able to further reduce those "pitfalls and ambiguities" - and if you do, the PLEASE back-port them to RFC5545.  Not all calendar software necessarily needs to read and write JSON .  The "plain text"-based RFC5545 has its place as well. Tim Hare Interested Bystander, Non-Inc. On 9/28/2017 4:43 AM, Robert Stepanek wrote: > Hi, > > over the last year we have been working on JSCalendar, a JSON-based > representation of calendar data as an alternative to iCalendar > (RFC5545). We already got extensive feedback from the members of > CalConnect and individual contributors and we'd very much like to get > the discussion started on our proposal at IETF. > > There's an increasing amount of proprietary calendar data formats in the > industry, most of them JSON-based. We believe that a new standardised > calendar data representation that meets the requirements of these > applications would help to reduce interoperability issues while > overcoming iCalendar pitfalls and ambiguities. > > The current draft version is located at > https://datatracker.ietf.org/doc/draft-jenkins-jscalendar/ > > Do you have any feedback on this? What would make you use the new > format, what is it currently missing? > > Thanks for your thoughts, > Robert > > P.S.: This message got cross-posted to the DISPATCH workgroup. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > From nobody Tue Nov 14 23:03:08 2017 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3A212953B for ; Tue, 14 Nov 2017 23:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=t103HA7n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sgy7NOqo 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 aWZwroz69EMI for ; Tue, 14 Nov 2017 23:03:00 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A891127B60 for ; Tue, 14 Nov 2017 23:03:00 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D36F120D09 for ; Wed, 15 Nov 2017 02:02:59 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Wed, 15 Nov 2017 02:02:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=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=21xyJeBBLIctANt10 ANNzTJiEjpanZpujWxXyaxec8g=; b=t103HA7nx6qXOVaUDSTLb8tJ7KZek7Hx6 ZZjSgO+9/GefjnKSgoeyA5skUkyGIAM48AHU3sqZ8aWkSsMldn84OP9IA4l/oS7D y9k0tKzgerQXDaapzmngkt5fsIXW+xBESk9YSi2YX0up1+KNXAug51E6m5BTKn3s HUQsgrd6CclE3xA9sK4DtN0BUs3SIFX+G/IKsRP+T4MnyVDyqLEzrhRCw1bsk6iL KtTpKxkj7screzQpgDvFCi5wZ/m7ukPpv+r4+1iwkfrCfg1tH03Da/Zt7ZgMVj39 sHH6eK2SsIN+1/QwczJLBwbeIEMCvW+QTmlliiBi9IrkW5bbNRR9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=21xyJe BBLIctANt10ANNzTJiEjpanZpujWxXyaxec8g=; b=sgy7NOqo/0wcJhyD7dkqDb z/dluqCSNkW4cyKr6VRBhLJfDvZIwUwwiiIIWLyLImh7liODi/P4TCq609f7WTqz m7rgFLWZ/X6CXp/gZp2WJ6yS5PxgyuwcVp4FK1HRcORYwxCAAx2ChSxVpNLJ9jHB y9EP4eRu444e8iZUsbXtwUeBbBgPj+BnThjTe8/9kQpRecwglkVpQYBvPio+4RQ/ F2BUG4sqciAebWtp442cCGnYN/9UA7fxslNPYMQ+Z5y5EY8vkg/k1Vakjj0vyGp6 DihTRQjWY2CAhgarQZPhe6xfLeA/TjGLY9i3nWptety3/xcOhZiwRu6XKkeZVpxQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 94529BAB61; Wed, 15 Nov 2017 02:02:59 -0500 (EST) Message-Id: <1510729379.1676448.1173022368.562D52BB@webmail.messagingengine.com> From: Bron Gondwana To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151072937916764481" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f89283c9 In-Reply-To: Date: Wed, 15 Nov 2017 15:02:59 +0800 References: <1506588212.485384.1120898568.4273A4D9@webmail.messagingengine.com> Archived-At: Subject: Re: [calsify] Feedback requested: draft-jenkins-jscalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 07:03:07 -0000 This is a multi-part message in MIME format. --_----------=_151072937916764481 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi Tim, A good example of a "pitfall and ambiguity" in RFC5545 is that events can contain either a DURATION or a DTEND. If the event is recurring, the definition is that the DTEND of each recurrence is calculated by adding the duration from the master event to the DTSTART of the recurrence. This can be ambiguous if the master event starts or ends within a daylight savings crossover - where the DURATION of the event is ambiguous based on the DTSTART and DTEND values. If both DURATION and DTEND are specified, that is an error - which means semantic cross-key checking is required to see if a VEVENT is valid. In jscalendar there is only duration. If you need to represent a different timezone for the end, there's a way to do it, but it means we don't need to support the DTEND variant just to give somewhere to hang the end timezone. Backporting this to RFC5545 would not be possible without completely replacing 5545, since not allowing DTEND is a big change. Also, DURATION must be positive in RFC5455 - but if you don't give a DURATION or a DTEND you create an event with zero length. In jscalendar, you can create an event with zero duration and it's specified how to represent that. Many of the other parts of jscalendar have been created in cooperation with efforts to extend 5545 so that the models are compatible. Regards, Bron. On Thu, 2 Nov 2017, at 12:22, Tim Hare wrote: > It literally took years to get RFC5545 to the interoperability state > that it is in now. I hope, for the sake of interoperability, that you> are able to further reduce those "pitfalls and ambiguities" - > and if you> do, the PLEASE back-port them to RFC5545. Not all calendar software > necessarily needs to read and write JSON . The "plain text"-based > RFC5545 has its place as well. > > Tim Hare > Interested Bystander, Non-Inc. > > On 9/28/2017 4:43 AM, Robert Stepanek wrote: >> Hi, >> >> over the last year we have been working on JSCalendar, a JSON-based >> representation of calendar data as an alternative to iCalendar >> (RFC5545). We already got extensive feedback from the members of >> CalConnect and individual contributors and we'd very much >> like to get>> the discussion started on our proposal at IETF. >> >> There's an increasing amount of proprietary calendar data >> formats in the>> industry, most of them JSON-based. We believe that a new standardised>> calendar data representation that meets the requirements of these >> applications would help to reduce interoperability issues while >> overcoming iCalendar pitfalls and ambiguities. >> >> The current draft version is located at >> https://datatracker.ietf.org/doc/draft-jenkins-jscalendar/ >> >> Do you have any feedback on this? What would make you use the new >> format, what is it currently missing? >> >> Thanks for your thoughts, >> Robert >> >> P.S.: This message got cross-posted to the DISPATCH workgroup. >> >> _________________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > > _________________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151072937916764481 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi Tim,

A good example of a "pitfall and ambiguity" in RFC5545 is that events can contain either a DURATION or a DTEND.  If the event is recurring, the definition is that the DTEND of each recurrence is calculated by adding the duration from the master event to the DTSTART of the recurrence.

This can be ambiguous if the master event starts or ends within a daylight savings crossover - where the DURATION of the event is ambiguous based on the DTSTART and DTEND values.  If both DURATION and DTEND are specified, that is an error - which means semantic cross-key checking is required to see if a VEVENT is valid.

In jscalendar there is only duration.  If you need to represent a different timezone for the end, there's a way to do it, but it means we don't need to support the DTEND variant just to give somewhere to hang the end timezone.

Backporting this to RFC5545 would not be possible without completely replacing 5545, since not allowing DTEND is a big change.

Also, DURATION must be positive in RFC5455 - but if you don't give a DURATION or a DTEND you create an event with zero length.  In jscalendar, you can create an event with zero duration and it's specified how to represent that.


Many of the other parts of jscalendar have been created in cooperation with efforts to extend 5545 so that the models are compatible.


Regards,

Bron.


On Thu, 2 Nov 2017, at 12:22, Tim Hare wrote:
It literally took years to get RFC5545 to the interoperability state
that it is in now.  I hope, for the sake of interoperability, that you
are able to further reduce those "pitfalls and ambiguities" - and if you
do, the PLEASE back-port them to RFC5545.  Not all calendar software
necessarily needs to read and write JSON .  The "plain text"-based
RFC5545 has its place as well.

Tim Hare
Interested Bystander, Non-Inc.

On 9/28/2017 4:43 AM, Robert Stepanek wrote:
Hi,

over the last year we have been working on JSCalendar, a JSON-based
representation of calendar data as an alternative to iCalendar
(RFC5545).  We already got extensive feedback from the members of
CalConnect  and individual contributors and we'd very much like to get
the discussion started on our proposal at IETF.

There's an increasing amount of proprietary calendar data formats in the
industry, most of them JSON-based. We believe that a new standardised
calendar data representation that meets the requirements of these
applications would help to reduce interoperability issues while
overcoming iCalendar pitfalls and ambiguities.

The current draft version is located at

Do you have any feedback on this? What would make you use  the new
format, what is it currently missing?

Thanks for your thoughts,
Robert

P.S.: This message got cross-posted to the DISPATCH workgroup.

_______________________________________________
calsify mailing list


_______________________________________________
calsify mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_151072937916764481--