Re: [calsify] Updated JSCalendar draft version 08

Marten Gajda <marten@dmfs.org> Mon, 08 October 2018 12:48 UTC

Return-Path: <marten@dmfs.org>
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 02338130E78 for <calsify@ietfa.amsl.com>; Mon, 8 Oct 2018 05:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org
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 DH0H2L-RHDuB for <calsify@ietfa.amsl.com>; Mon, 8 Oct 2018 05:48:16 -0700 (PDT)
Received: from mailrelay3-1.pub.mailoutpod1-cph3.one.com (mailrelay3-1.pub.mailoutpod1-cph3.one.com [46.30.210.184]) (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 83BFB130E7C for <calsify@ietf.org>; Mon, 8 Oct 2018 05:48:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=UYTPHkpef8zZiePVHEkP9wEWk/RerIyBeugGFs7w4bg=; b=Ks4Pcyru1JMOmlhXILf0XbOWisq+2bB7vEM6wpOlrH+iW3n2dSgsc9jTcr9O2R9sLg7Zc7dIXQpph yM223b6xaercDEM4bIDwoc0sXge1lhmdLoGtnYfW97CvZcfDifE4KFS2YDZn9l+S4r868HU6lnZzk1 yuB4K+GfncsPxx7Y=
X-HalOne-Cookie: 26d594cf23dc87c71f55a93932d104bef19751ee
X-HalOne-ID: 6a8bab37-caf8-11e8-af49-d0431ea8bb03
Received: from smtp.dmfs.org (unknown [84.129.200.204]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 6a8bab37-caf8-11e8-af49-d0431ea8bb03; Mon, 08 Oct 2018 12:48:12 +0000 (UTC)
Received: from boss.localdomain (unknown [185.127.111.228]) by smtp.dmfs.org (Postfix) with ESMTPSA id 2224149B for <calsify@ietf.org>; Mon, 8 Oct 2018 14:48:12 +0200 (CEST)
To: calsify@ietf.org
References: <4e76bb0f-0b05-409f-960c-add3f39f702e@sloti22d1t06> <e25fe2f3-c199-c096-1aa4-593313ff5251@dmfs.org> <b32127ab-f3d0-2354-4d3f-fddd4f8755f8@dot.ee> <b05d34e5-2418-4ee8-9025-9bc12263d251@sloti22d1t06>
From: Marten Gajda <marten@dmfs.org>
Message-ID: <7f0bb4a3-b7c0-bcc1-aabf-692217d509c5@dmfs.org>
Date: Mon, 08 Oct 2018 14:48:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <b05d34e5-2418-4ee8-9025-9bc12263d251@sloti22d1t06>
Content-Type: multipart/alternative; boundary="------------152BFC3542F356E2BFCD6ED2"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/RPZLKVMcdWC0bZ3LhxIE9t-NkVI>
Subject: Re: [calsify] Updated JSCalendar draft version 08
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Oct 2018 12:48:19 -0000

Am 08.10.2018 um 14:20 schrieb Robert Stepanek:
> The duration requirements for isAllDay are incomplete anyways: it can
> include day or week components. I'll update that.
>
> On P0D vs PT0S: I don't see a reason why a zero duration sub-field
> would signify anything but the absence of the according time unit, and
> vice versa. We do the same for the start LocalDate-property, which
> also is required to have a zero time component if isAllDay is true (as
> opposed to omitting the time fields). If we'd have gone with
> normalized durations, it might have made sense to require all zero
> duration fields to be omitted from the string representation, but the
> current spec doesn't require normalized durations.
>
> I do agree that the spec should be more clear on that zero duration
> components are equivalent to their absence, and I'll take note to
> update the Duration type description and isAllDay restrictions
> accordingly. Any objections to that?
No objections. If we're clear on what a "component" is and what it means
if it has a 0 coefficient vs. being absent I'm fine with it.

For me it would preferable to only allow a notation which contains no
"T" though. Allowing something like PT0H0M0S is just an additional
source for errors. People could come up the idea of specifying PT86400S
and argue that this equals 24 hours, "which is a day". After all, one of
the objectives of this new format is to "make it hard to get it wrong."

Having a format which is strict in cases like this makes it much easier
to argue about that.

>
> Note: in my opinion even P0W1D should be legit, but it's forbidden by
> the ABNF in iCalendar, so we might want to keep it at that.
>
> Cheers,
> Robert
>
>
>
>
>
>
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743