From nobody Sun Jul 1 07:46:32 2018 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 63B9F130E67 for ; Sun, 1 Jul 2018 07:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 hkqFvmPPT_jw for ; Sun, 1 Jul 2018 07:46:28 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (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 8AE20130E43 for ; Sun, 1 Jul 2018 07:46:28 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-09v.sys.comcast.net with ESMTP id ZdGVfvPuOB0h4ZdcSfqRG1; Sun, 01 Jul 2018 14:46:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1530456388; bh=/++01M6GhDgY8ygeEWJ5sILZIm92kO2wKCFFjb3qJGM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=bo7EEG/5yk8iAuh3iMTRH5xyEIjNxfDLKChhx14wGfp9ylhDd8vyEtE/Iuvs73Z9w zTbkU4AuAPRWw81ZSXd2KTrZ/yy0S2AU3n8oQ8Wfe4Lk7S278IdzCLj0oEhcBYQ/8R O9osmaLzf13XrZ1wImP4BRioRZM5V8YJAQzeweGVlSMeTefQJja67ggJGJAXUHz8c7 4PSfYk/Y/dtW4hAa3I7JZvyu5r9WnDuL6AhTv2iSdZzMV3iXJ/AjmL8203r44/Jyus OxaVwwArtUQnJnn2wA3drIApQvmelcl3pCnyxfVS1c/WGjm9AeCy8Mb4ojKwEeOZF+ U+IEbO1ydrUOA== Received: from THARE ([73.42.14.246]) by resomta-po-15v.sys.comcast.net with ESMTPA id ZdcRfeBZZbdp7ZdcRftiI7; Sun, 01 Jul 2018 14:46:27 +0000 From: "Tim Hare" To: Date: Sun, 1 Jul 2018 10:46:25 -0400 Message-ID: <000001d4114a$49a5c600$dcf15200$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdQRRUzRnWK92vK6RHeVUABtuwJb0w== Content-Language: en-us X-CMAE-Envelope: MS4wfGKwjbRafevcjkQ36LgzAMA8PDJ0ZmgjEZhIkan9KaOGS8NCHxRLpLUXzqb1yCE2Gu7IFGVvS7tm9zkw+kEkAdr/hQRU14m+WsK14uTs5xbv7aBWOYYn F2U3g2nJ/DAUkbdTzqR3ZofbDx7bfQsadDE= Archived-At: Subject: [calsify] STYLE component? Was: Proposed Errata for RFC 7986: COLOR property with arbitrary RGB values X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 14:46:31 -0000 I haven't been keeping up with this as I once did, apparently, and I will be reading RFCs again to try to find out what I'm missing. But I want to ask here while this COLOR description prompts me. Why use style properties in components? Aren't we going down the same road HTML did prior to the introduction of CSS? Or going even further back, not learning from SGML? In my opinion, it is always better to keep style elements separately. I would propose replacing the COLOR property with a STYLE property in RFC 7986 - something like this ============================================================================ === 5.9. STYLE Property Property Name: STYLE Purpose: This property specifies a reference to a stylesheet used for calendar, event, todo, or journal data. The stylesheet will be a standard CSS3 stylesheet Value Type: URI Property Parameters: a standard URI can be used to reference where to find the stylesheet Conformance: This property can be specified once in an iCalendar object or in "VEVENT", "VTODO", or "VJOURNAL" calendar components. Description: This property specifies a URI to a stylesheet that clients MAY use when presenting the relevant data to a user. Typically, this stylesheet's primary purposes would be to provide the "background" color of events or tasks when presented to the user. The calendar client SHOULD apply the stylesheet values to the calendar components in a way similar to the way a stylesheet is applied to HTML tags, treating components like HTML elements and properties like HTML attributes. Format Definition: This property is defined by the following notation: style = "STYLE" styleparam":" URI CRLF ; Value is a valid URI styleparam = *(";" other-param) Example: The following is an example of this property: STYLE VALUE=URI:https://example.com/department_calendar.css ============================================================================ ======= Stylesheet COULD contain ============================================================================ ======= /* Department Calendar Stylesheet */ Vcalendar{background-color:white; font-family: Verdana, Geneva, Arial} Vevent{background-color: white} [organizer~='Boss']{background-color:red} ============================================================================ ======= Using CSS allows some leveraging of already developed code for displaying things as HTML. A calendar client Could reformat the calendar data as HTML with a link to a stylesheet and call the component which handles HTML mail To display the calendar. Using CSS also provides many more style options than just background color. As always, I am not an official part of any WG and these ideas are my own (although they do represent my current Employer, since I am self-employed). Tim Hare Interested Bystander, Non-Inc. From nobody Sun Jul 1 17:28:29 2018 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 B8C7D130EB1 for ; Sun, 1 Jul 2018 17:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=fatjTWxq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=unqYcegm 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 rd5MH5A8oCyq for ; Sun, 1 Jul 2018 17:28:26 -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 BE8EF130E5E for ; Sun, 1 Jul 2018 17:28:26 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 07B4C2073F for ; Sun, 1 Jul 2018 20:28:26 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute6.internal (MEProxy); Sun, 01 Jul 2018 20:28:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=BWVdtIxgt9bL2yLnxnbsoWHFL0NLaGtB5VbuNU2O1 mo=; b=fatjTWxq7+vP4D2nBX6acOVBq/0kcpeOnV/Ny/N3OjvkoC61QCMY53tw4 hg5MwBxJFfipTr4k/mg8MOdU0ytQSxmjTGbbuTGiKI30DrHwjB9NWRMioC/v1AZy 43NTmFbqc6ivmKdWXnK03UjEoqoPXGdaVtU229/pxD0wq45x1WQogueHMKsZpi1Y bgNda+rNoxUTbzVDLhEQobtXvM2h8bgqswmF3wkIWmC9nTRZ5RfMCDnQaSKBnT52 ayamfNCp+auZc/A7RiuVKXFKOK+SU6oS+MqDplGBor1bD0Tr0ncSMCW6F9eHFyt7 gFAU5cOxt8PRkytHrQiGaw4MfWmxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=BWVdtIxgt9bL2yLnxnbsoWHFL0NLaGtB5VbuNU2O1 mo=; b=unqYcegmsz3v3tfHX+5NmjyHLUoeVe37JHnF0eSLBxGLvUCv9nFz+z/K2 CLah5gWjFOtpnu2EhiKfSMHjxLqKCEZmJzCdIAJLaqXdeVnUAsegc+GldDRKMEnl r3gtphOpIL0JRYhDxRLPcmIt26Qx8VTvnlqxfSY0nBq2BP/UCqzfFrfelieeUb3f xe4wZt+FeLh93qOqa+fYtXqzWs20nVAvH3+VB9U4CLiyPv3k1LWqgQ1CeWpxayb+ +CLZxpp8r2OmAHHJlmKKFkt135FLtZsxP9u+h5QcfHIvgVnicICGsM6v0sijYLIT /9njORwZuPfiJFN0XmO8upZVxBpMg== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8310AC455B; Sun, 1 Jul 2018 20:28:25 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.3-669-gf2de8ca-next x-jmap-identity-id: 64588216 In-Reply-To: <000001d4114a$49a5c600$dcf15200$@comcast.net> References: <000001d4114a$49a5c600$dcf15200$@comcast.net> Date: Sun, 01 Jul 2018 20:28:24 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=d1722b38b7f94e8b87b947c50d9c0bdc Archived-At: Subject: Re: [calsify] =?utf-8?q?STYLE_component=3F_Was=3A_Proposed_Errata_fo?= =?utf-8?q?r_RFC_7986=3A_COLOR_property_with_arbitrary_RGB_values?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 00:28:28 -0000 --d1722b38b7f94e8b87b947c50d9c0bdc Content-Type: multipart/related; boundary=b169b4013680490083e77147bf5aa5cc --b169b4013680490083e77147bf5aa5cc Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, 2 Jul 2= 018, at 12:46 AM, Tim Hare wrote:
I would propose replacing the COLOR property with= a STYLE property in RFC
7986  - something like this<= br>

No. This would be ignored by e= veryone. A calendar app is not displaying arbitrary content where the st= yle is entirely determined by the author. It has (normally a number of d= ifferent) carefully planned and often information-dense ways of displayi= ng multiple events within a single time window. The COLOR property was = introduced because most calendar apps colour-code different calendars in= some way, and this allows the user to see the same colours when using d= ifferent apps, making it easier to move between them. Arbitrary CSS is n= ot useful or appropriate to apply here, and would range from confusing (= text-decoration:underline= =E2=80=93 is that a link? why is it underlined?) t= o nonsensical (float:lef= t).

Neil.
--b169b4013680490083e77147bf5aa5cc-- --d1722b38b7f94e8b87b947c50d9c0bdc Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 2 Jul 2018, at 12:46 AM, Tim Hare wrote: > I would propose replacing the COLOR property with a STYLE property in = RFC > 7986=C2=A0 - something like this No. This would be ignored by everyone. A calendar app is not displaying = arbitrary content where the style is entirely determined by the author. = It has (normally a number of different) carefully planned and often info= rmation-dense ways of displaying multiple events within a single time w= indow. The COLOR property was introduced because most calendar apps colo= ur-code different calendars in some way, and this allows the user to see= the same colours when using different apps, making it easier to move be= tween them. Arbitrary CSS is not useful or appropriate to apply here, an= d would range from confusing (text-decoration:underline =E2=80=93 is tha= t a link? why is it underlined?) to nonsensical (float:left). Neil. --d1722b38b7f94e8b87b947c50d9c0bdc-- From nobody Mon Jul 2 04:55:02 2018 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C49129385; Mon, 2 Jul 2018 04:54:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053249203.28124.3621450699141776323@ietfa.amsl.com> Date: Mon, 02 Jul 2018 04:54:52 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-05.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 11:54:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-05.txt Pages : 53 Date : 2018-07-02 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative to the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-05 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 13:16:02 2018 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 C817A131116 for ; Mon, 2 Jul 2018 13:16:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 d2fKROypyaUn for ; Mon, 2 Jul 2018 13:15:55 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 3D2E1131236 for ; Mon, 2 Jul 2018 13:15:40 -0700 (PDT) Authentication-Results: mail.aegee.org/w62KFXrc016582; auth=pass (PLAIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1530562534; i=dkim+MSA-tls@aegee.org; r=y; bh=0UdX2tBqOq+AU0hWKvgHfhWfihpQ1iXEbyNoCUCJOPM=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=IZxdR53Kb/bK6DF1PCyTIRs/fUxfpSQRWm6m04jhFyXRDtIHks3F8nQRJ70R6RqWD 4X/dqNLTEieG64yP3AO21GCoM73/UiCGRdJGLDdr93zmrQPCGL1VqRVMZW9P/HAxTW M/EqaUbhbSkgnGTsO3C9Bb4My8javTFMPC5wJM7LRJSO2cPoypT5HdozPz8l+cFlPA xCSV0o+zR1fj402fQTFir//jtMHSGnbVvEX4Bxs6qs7llD/XvpCL2JH4AtrdvhAyvR f6JIwGzugcPIs6HkUrceDKuyTDBX4FQKwX/EzRr3SxKl8p2rJckieqX7cbz+kh7Q/T Hn6fPVv5eCPUgBQaPZCkBpGYsdZbym95vqPi9pPeKPIbspQf0x2R1zrNhoSgfdDkD9 lrelk+QY4DLrc9P6quguyvypACmpT6HJkaxs7jIkuQLCyVfXUHzBSO/DI7xFx7ha0y xtirU53afyjc6C8WJC923LzwvE+niuVIO9ZWWMoS802UADZ33eW9ElEnNACEYp9Z7w uS6kByhteu2jnQu+Y5imvpiWyEW/OzTjk9UHvssqO7i5q+oeyXqCKu6cazV3IG6kC6 /vZqeJVuLWxZTdbF/wWvfID+9/Go86MHMbbjelpnYJhP8pv37gwAQLlDqvTEhj1/zk NxRQsVpMueVKBHp/m9JdI144= Authentication-Results: mail.aegee.org/w62KFXrc016582; dkim=none Received: from Tylan (80-110-70-89.cgn.dynamic.surfer.at [80.110.70.89]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id w62KFXrc016582 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Jul 2018 20:15:34 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Andrew Laurence , Neil Jenkins Cc: calsify@ietf.org Date: Mon, 02 Jul 2018 20:15:33 +0000 In-Reply-To: <531E76A8-D6E3-4DAB-A141-D44FC94E7583@me.com> References: <895f00bcf8af786b08011f8d3ee6f3cfd7f2f9f7.camel@aegee.org> <016cbf12-c998-4f89-9151-40fb75fbbbdc@sloti35d1t03> <531E76A8-D6E3-4DAB-A141-D44FC94E7583@me.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [calsify] Proposed Errata for RFC 7986: COLOR property with arbitrary RGB values X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 20:16:01 -0000 Hello, thanks for your feedback so far. CSS3 contains 140 distinct named colours (substracting gray and leaving gray). I don't think this plethora of different colours is suitable to create a branding palette. Moreover, even if some clients interpret the colour names to fit the branding, most of the clients will not do so. Then the same application will probably be used to read iCalendar data from other sources, that want to have different or no branding palette, so the application will have hard time to keep palettes per source. The last comment at https://github.com/w3c/csswg-drafts/issues/2813 states CSS3 colour names are not good idea. To simplify the implementations I will propose that "rgb()" has to be written lower case. By letting any value as colour an implementation is not prohibited to round the value during the interpretation to some preset palette. Regards Дилян New proposed text: Description: ...The value is either a case-insensitive color name taken from the CSS3 set of names, defined in Section 4.3 of [W3C.REC- css3-color-20110607], or a lower-cased rgb() functional notation with absolute values specified in Section 4.2.1 of the same document. Examples: The following are examples of this property: COLOR:turquoise COLOR:rgb(61\,211\,68) On Fri, 2018-06-29 at 09:08 -0700, Andrew Laurence wrote: > Users use colors to represent all sorts of known-to-them metadata. > They care *deeply* about color assignment and fidelity. When we > moved from a calendar system that let users assign colors according > to criteria (Boss is organizer? Red! Description contains "Lunch"? > Green!) to one that didn't, I heard about it for *ten* years. > > While preparing for the June 2017 CalConnect, I surveyed users about > issues with calendars. It came up *again*, in the context of wanting > to choose colors and have them remain the same across clients. > > -Andrew > > > On Jun 29, 2018, at 12:12 AM, Neil Jenkins > > wrote: > > > > I wasn't involved in the original discussion, but I have a vague > > recollection from seeing the emails go by that this was > > intentional: the theory was clients are not going to use the actual > > colour you specify as they will want to pick something that goes > > with their branding + background + event display design, so by > > using names they could then choose their "version" of the colour > > that was closest in spirit to the name given. > > > > Not sure I agree with this reasoning, but I think that was the > > idea. > > > > Neil._______________________________________________ > > 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 From nobody Tue Jul 3 09:48:26 2018 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 F1224130E6D for ; Tue, 3 Jul 2018 09:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 GAtwpzoE4xms for ; Tue, 3 Jul 2018 09:48:23 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 CCF5F130934 for ; Tue, 3 Jul 2018 09:48:22 -0700 (PDT) Authentication-Results: mail.aegee.org/w63GmKka031373; auth=pass (PLAIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1530636501; i=dkim+MSA-tls@aegee.org; r=y; bh=OkvhcK/i5cS1dJiHM3ywQjWHDBRNsDElnZMM3+EXk00=; h=Subject:From:To:Date; b=ZrfimlGddsP+bEwdhgiiCJLpdoJQFI4wdfIy4O8OfKW3GM8P3BEOC1Pi62mDMfwqn SH88Ei1CKE5Q7JH066p8MRiLQhUK18NUW1jwhZtyfg2ADvaW/tKOp4W5rrzL7iwr3o kSN/8itGjis/WMUdZKW5brxc/VlAUoAP1yO7ALuAEFFUnypZoFnSKamf5To8J1V7rs eplJM9fi4byzot5+8cLA8Qm8fYbveJ06e/dV0WxFaJQr6+1BHcdAiX9aavQ91nnx5d 4cc7Dvoozfvmc3uybnf3K1i+z4W5d/iRVmMv+jPebuY4hRq6xGp+CVgCZMu1RtL2WX AMEd5pcGPZRlEotmttjZFTX0MU/nAGnf2+8r8ajKCUHkDdV7mketmoRzwjUxyL6aQY BlGBQe68xTmG6GCr5bOTxZRijV2IAugEoR1AzOZrYwd3PELB5jBB/EBTB9DBAlDs1x 7H1kFN+GoXnvMWFCjsNN1m6esOFycjj9NftYzbIZkOgj0iaR/zAubUQmsmWMrJ7XJ5 0zNViB3T7AuZ+n8RpSHcr33a8mkZ3Zhm1m0sc78gxPAHQBbtfWq3wjEjqbS2o3DlMj HxPLENc1GkScTrHzDt0n6OvQZxF4dJlaGnsWhocMzM0P20GmG385esK4zIlXFJ1+S9 PDVz/EmrFzyb0G48nrKGhtEI= Authentication-Results: mail.aegee.org/w63GmKka031373; dkim=none Received: from Tylan (e252-251.eduroam.tuwien.ac.at [128.130.252.251]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id w63GmKka031373 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Jul 2018 16:48:20 GMT Message-ID: <2e1e55d7da12ac85311eda9f6f3d4ee8c83be031.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: calsify@ietf.org Date: Tue, 03 Jul 2018 16:48:20 +0000 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [calsify] mapping iCalendar properties to CALDAV properties X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:48:25 -0000 Hello, in iCalendar Core Specification (RFC 5546) the calprops has prodid, version, calscale, method. New Properties for iCalendar (RFC 7986) adds to calprops uid, color, refresh, name, and others. CalDAV (RFC 4791) defines for caldav collection the properties CALDAV:calendar-description, CALDAV:calendar-timezone. For a caldav collection with url https://example.int/url1 one can call "GET /url1 HTTP/1.1" to retrieve the iCalendar object and pick from it the DESCRIPTION, or query the same collection with webdav PROPFIND for CALDAV:calendar-description. Are CALDAV:calendar-descripion and iCalendar/calprops:DESCRIPTION implicitly or explicitly the same? Is the server supposed, upon change of CALDAV:calendar-descripion and subsequent GET htts://example.int/url1 , to return the updated DESCRIPTION? What about COLOR, REFRESH, NAME and so on, can these be altered via CALDAV:calendar-color and CALDAV:calendar-referesh and DAV:display-name (or CALDAV:calendar-name)? If not, how is a caldav client supposed to update the calprops- properties returned in the iCalendar object upon GET /url1? Regards Дилян From nobody Tue Jul 3 16:30:19 2018 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 C3057130E02 for ; Tue, 3 Jul 2018 16:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zonevs.eu header.b=vobabz9L; dkim=pass (2048-bit key) header.d=srs2.zonevs.eu header.b=mB30SAhG; dkim=pass (2048-bit key) header.d=dot.ee header.b=mV25bnoE 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 r8wr6mf3aIoL for ; Tue, 3 Jul 2018 16:30:12 -0700 (PDT) Received: from srs2.zonevs.eu (srs2.zonevs.eu [217.146.68.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A160130DD4 for ; Tue, 3 Jul 2018 16:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=sJy71TktR7T0Sn0ucMgHhYooVI4Jj7ix9pKzK/wNJKM=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=vobabz9L2vAKbtCVwAvmnXGz+8jd4Q+0FPc8Z0PiaOH495R2TaL1DRnZXA+oZbW8gaZCfdFaG i15BPvOzroWLPGM9dHE2Z8M/6wPvgoiL/6dZMgicThgne8lGotB0knIDt4UbhZ4lvD+qzz7Re3a 16cbyeIVxdTjVTg4+Bp6WY3wi3s0IgLb/Ia95uu1T0QqxqGDEeiZNVcM2UYjU0Gd520bz8pQniY SMaIVnHKmwhUDj3CiSiH4YVrrxp2tljE5d6/mm2PyeBgRpotCmk4q6PexfjPTkh5eTRBdL/ff42 Cq6w5GuU4OKy7Xm1liew8+/2oHGyGfg9WGNWZYxkvb/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs2.zonevs.eu; q=dns/txt; s=oct2016; bh=sJy71TktR7T0Sn0ucMgHhYooVI4Jj7ix9pKzK/wNJKM=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=mB30SAhGEC1CR6Sx0s0Z8eioJMvym1fLmUedNrpJivXxbDregzibpdKNDXqM55lO+vxkmLBwU S3ag9nLvkECTDQrJvgC81YS14pUyjD89/Ub0XqGTCpkjInQfvJwOAdSH5KR9OzXzmcd5++rDhUw ZbcBy4cPNr9ubeOrqVEpVpa3pvFz6k+Vl6MvHz4kV0GxtlilOcDc58StAyhGXMSr4Wyp0GCrf0E Fh1SwRjhA6zBpsFkWTMHiOsk0ZL/BDBHR7lr4J+fXW1R4BIsYNdwRLqK0nMyr7S7MrmSL2csrC+ x1Ns4ZGuNrMvKIx43RuPb/GOzqcC/lsg6b+ZAkseSvxw== Received: from smtp.zone.eu ([217.146.66.121] smtp.zone.eu) by srs2.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 164627b4e2f0002ace.001 for ; Tue, 03 Jul 2018 23:30:05 +0000 X-Zone-Loop: 9708263ab713d4d9bb32ddbcc30d017bbc3578228a8d Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.eu (Postfix) with ESMTPSA id 42F5418F9C02 for ; Wed, 4 Jul 2018 02:30:04 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1530660605; bh=/awtq4BRvRrSpVK0w/bBsh/lne211bj3dVuVVKX2V40=; h=Subject:To:References:From:Date:In-Reply-To; b=mV25bnoEMtho0kyOFknnBW6HNY46+8uW8Sp52jTSYi0fu9f7CeoieESK8lk4bKgYe lvLqRQ9W/s8L92seBOCsVoS3LUkuwKpGQDZTVOXypOKQX5PY2oiVvKWNIspMiQxAfW p4aCNtchJbvXfVmI1eNfyG4s/h0s2CGa9REo+R45e/JOF2d0IhE2EPKdpDdSSJNZT9 9E2FLeUbHAdBMx95xvjwJjIEo8GdMjSQm6fBugHI+FR+hmr0NWcNNuWkVH0JuxIhXy XARKEWg10mF7TFGJOeJieL3TPwgl0iHNwFLOAkumoLG7WXTxV5oVaMyf1iINOzx+0d w9f/M4QQ1m5iA== To: calsify@ietf.org References: <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: Date: Tue, 3 Jul 2018 23:30:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------FAFA4C046B747C2EB5349D21" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-3.101223, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.901223, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 23:30:17 -0000 This is a multi-part message in MIME format. --------------FAFA4C046B747C2EB5349D21 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > Side-note: at last CalConnect we discussed to allow all valid ISO8601 > durations, including years and months. On second thought this would > require implementations to handle in-existent dates in date-time > arithmetic, and break iCalendar compatibility for no compelling reason. While I don't think use of durations in years or months are that common, I can definitely see value in them for events like "an entire month every n months". If there's ever a time to fix old mistakes, now would be the time, wouldn't it? Switching from duration format /based on/ ISO 8601 to ISO 8601 proper would be a rather mild change after all. I haven't tested, so what do current implementations do given a full ISO 8601 durations? On 06/29/2018 09:39 AM, Robert Stepanek wrote: > The current JSCalendar duration definition neither is strictly > normalized nor compatible with the iCalendar DURATION type. > Specifically, it normalizes the zero duration to be written as P0D but > does not define any other normalization. In addition, it does not > support durations expressed in weeks. > > It might make sense to either require completely  normalized > durations, or to support the full value range of iCalendar durations. > I lean towards the latter, and intend to: > > * remove the P0D restriction for zero durations > * allow durations to be expressed in weeks, with the same > restrictions as iCalendar and ISO 8601 durations. > > > While normalization can provide value in some cases, it is likely to > be ignored by clients and robust implementations will have to deal > with them already for iCalendar. > > Side-note: at last CalConnect we discussed to allow all valid ISO8601 > durations, including years and months. On second thought this would > require implementations to handle in-existent dates in date-time > arithmetic, and break iCalendar compatibility for no compelling reason. > > What are your thoughts? > > Cheers, > Robert > > > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------FAFA4C046B747C2EB5349D21 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Side-note: at last CalConnect we discussed to allow all valid ISO8601 durations, including years and months. On second thought this would require implementations to handle in-existent dates in date-time arithmetic, and break iCalendar compatibility for no compelling reason.

While I don't think use of durations in years or months are that common, I can definitely see value in them for events like "an entire month every n months". If there's ever a time to fix old mistakes, now would be the time, wouldn't it? Switching from duration format based on ISO 8601 to ISO 8601 proper would be a rather mild change after all.

I haven't tested, so what do current implementations do given a full ISO 8601 durations?


On 06/29/2018 09:39 AM, Robert Stepanek wrote:
The current JSCalendar duration definition neither is strictly normalized nor compatible with the iCalendar DURATION type. Specifically, it normalizes the zero duration to be written as P0D but does not define any other normalization. In addition, it does not support durations expressed in weeks.

It might make sense to either require completely  normalized durations, or to support the full value range of iCalendar durations. I lean towards the latter, and intend to:

  • remove the P0D restriction for zero durations
  • allow durations to be expressed in weeks, with the same restrictions as iCalendar and ISO 8601 durations.

While normalization can provide value in some cases, it is likely to be ignored by clients and robust implementations will have to deal with them already for iCalendar.

Side-note: at last CalConnect we discussed to allow all valid ISO8601 durations, including years and months. On second thought this would require implementations to handle in-existent dates in date-time arithmetic, and break iCalendar compatibility for no compelling reason.

What are your thoughts?

Cheers,
Robert





_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

--------------FAFA4C046B747C2EB5349D21-- From nobody Tue Jul 3 18:27:57 2018 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 1CA95130E8A for ; Tue, 3 Jul 2018 18:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=DZeTUPHM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=trITjLbv 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 SYLjBk-fh5qj for ; Tue, 3 Jul 2018 18:27:54 -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 222E312D949 for ; Tue, 3 Jul 2018 18:27:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4C21B210F0 for ; Tue, 3 Jul 2018 21:27:53 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Tue, 03 Jul 2018 21:27:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=lXMS0sZXdcFV8o0cKkAqAXWGJfvKmGR7Yd/d8NJ4n 5Y=; b=DZeTUPHM0E1XoB608+MdjTk3gpBs39qPZYE/gQo+hQu+KitYJKc2lDcTv kjIgkCi0u+c9BMBBd/chSMZaW1JIfxSD/diYYOi0qtub4W1hQfXNBv0TdIPmuhCF 2G+unEzei4eRVgK7aaZoTb2MPssGLEJiE0Wyh100sJHyNrLMrhLpjCB3Y+Q1ZUpq 5lOUUaLyTQmAxwor7gKqsNJUcMgqA8JTmshUAhUb/1tru/rzensvl5QongM1RcSh 7F82slOJpOt8R3XYeclOlKMnX8LYqTak/UaZCshcidkyQUIgu0dFWUltT0ch6Dp7 +LfKpTN4dHre+O1pKdTxs7RoQHvOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=lXMS0sZXdcFV8o0cKkAqAXWGJfvKmGR7Yd/d8NJ4n 5Y=; b=trITjLbvuHnT2//TcSJ5XQTRpcaVNjGUB9VTIUdz9OexywMcC/gWeoBuG QnbEl77TJawzasM4u04NLfUAck6EZa7AxPxblB6gGFZL5sU0WRpYjTnCjVmD0jRm S6wXC4i9JXbmW9lsEQsAB5spnIa/qk1lGOT7VaxzGGd4BMxNOJBnmijVAlBU/79Y h9oJI66KYTHrnF1Haw83rFeWfs29dVs+4uXKcOvw5tTofJWxHQOSUcJwdP4bFvt6 C2QVCK77tBExAyuQBXUioVlFEUZDsCkAGX5GHIM/0SUG9bkRh2nZf91kTGW2Cx1x KcBusTMkHT6zPPPTNVEdj+BAU4o5A== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E6913CA13D; Tue, 3 Jul 2018 21:27:52 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.3-669-gf2de8ca-next x-jmap-identity-id: 64588216 In-Reply-To: References: <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> Date: Tue, 03 Jul 2018 21:28:14 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=1a2a9f8d490d41a4b6d57fd495525283 Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 01:27:56 -0000 --1a2a9f8d490d41a4b6d57fd495525283 Content-Type: multipart/related; boundary=a5b304c1bedb49deab2bf15d18f34d39 --a5b304c1bedb49deab2bf15d18f34d39 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, 4 = Jul 2018, at 9:30 AM, Andri M=C3=B6ll wrote:
While I don't think use of durations in years or months are = that common, I can definitely see value in them for events like "an entire month every n months". If there's ever a time to fix old mistakes, now would be the time, wouldn't it? Switching from duration format based on ISO 8601 to ISO 8601 proper would be a rather mild change after all.

=
No, strongly disagree. This makes implementation much = harder, as the duration may now have a dependency on the start date rath= er than being a fixed value. Not to mention what does it even mean if yo= u have a duration of 1 month starting 12pm on 31st May. June doesn't hav= e 31 days, so is this to 30 June? Or to 1st July? What if it recurs? Add= ing significant complexity for dubious utility (and no way to translate = into iCalendar) does not seem a good idea to me.

Neil.
--a5b304c1bedb49deab2bf15d18f34d39-- --1a2a9f8d490d41a4b6d57fd495525283 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 4 Jul 2018, at 9:30 AM, Andri M=C3=B6ll wrote: > While I don't think use of durations in years or months are that common, I can definitely see value in them for events like "an entire month every n months". If there's ever a time to fix old mistakes, now would be the time, wouldn't it? Switching from duration format *based on* ISO 8601 to ISO 8601 proper would be a rather mild change after all. No, strongly disagree. This makes implementation *much* harder, as the d= uration may now have a dependency on the start date rather than being a = fixed value. Not to mention what does it even mean if you have a duratio= n of 1 month starting 12pm on 31st May. June doesn't have 31 days, so is= this to 30 June? Or to 1st July? What if it recurs? Adding significant = complexity for dubious utility (and no way to translate into iCalendar) = does not seem a good idea to me. Neil. --1a2a9f8d490d41a4b6d57fd495525283-- From nobody Wed Jul 4 14:29:09 2018 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 B9B3E130E14 for ; Wed, 4 Jul 2018 14:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] 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 Od4FxxHJMdEH for ; Wed, 4 Jul 2018 14:29:05 -0700 (PDT) Received: from mailrelay1-1.pub.mailoutpod1-cph3.one.com (mailrelay1-1.pub.mailoutpod1-cph3.one.com [46.30.210.182]) (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 176E4124BE5 for ; Wed, 4 Jul 2018 14:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=MHLq1xjC/HcUlGU9WsUrTeAE+1v+xeYGuW4E1/vLsTU=; b=dq079jUK32zFnypHrVNKAMsfb+TXHPMwE378soGVKnji7Mofal3110nK7I3uu51ICnEpXtF6PfAO2 ZFqFU02qRuKyvone9Mg6VQYTdOb2vPnJaNknvh/C00emZLiQrjV02XLnoWvLj4RlIbc6EvIxq4t9jA Nsm4854RqCeUpo3M= X-HalOne-Cookie: 6cbe619e791aadba347cbe1e97952af2525330e5 X-HalOne-ID: 4484d6b1-7fd1-11e8-8fab-d0431ea8a283 Received: from smtp.dmfs.org (unknown [62.224.76.155]) by mailrelay1.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 4484d6b1-7fd1-11e8-8fab-d0431ea8a283; Wed, 04 Jul 2018 21:29:01 +0000 (UTC) Received: from boss.localdomain (x2f7f94e.dyn.telefonica.de [2.247.249.78]) by smtp.dmfs.org (Postfix) with ESMTPSA id B124959C for ; Wed, 4 Jul 2018 23:29:00 +0200 (CEST) To: calsify@ietf.org References: <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> From: Marten Gajda Message-ID: <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> Date: Wed, 4 Jul 2018 23:28:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2F1488411A3C81D99807253F" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 21:29:08 -0000 This is a multi-part message in MIME format. --------------2F1488411A3C81D99807253F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 04.07.2018 um 03:28 schrieb Neil Jenkins: > On Wed, 4 Jul 2018, at 9:30 AM, Andri Möll wrote: >> While I don't think use of durations in years or months are that >> common, I can definitely see value in them for events like "an entire >> month every n months". If there's ever a time to fix old mistakes, >> now would be the time, wouldn't it? Switching from duration format >> /based on/ ISO 8601 to ISO 8601 proper would be a rather mild change >> after all. > > No, strongly disagree. This makes implementation /much/ harder, as the > duration may now have a dependency on the start date rather than being > a fixed value. Not to mention what does it even mean if you have a > duration of 1 month starting 12pm on 31st May. June doesn't have 31 > days, so is this to 30 June? Or to 1st July? What if it recurs? Adding > significant complexity for dubious utility (and no way to translate > into iCalendar) does not seem a good idea to me. I agree with Neil. ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months? Does its duration depend on which day you start? This doesn't even touch issues with calendar scales other than Gregorian. How would you express the duration of a month in the Hebrew calendar? Week durations don't really add any value IMO. Conversion from/to days is trivial and without any loss of information and many tools probably convert weeks automatically to 7 days internally. Marten > > Neil. > > > _______________________________________________ > 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 --------------2F1488411A3C81D99807253F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Am 04.07.2018 um 03:28 schrieb Neil Jenkins:
On Wed, 4 Jul 2018, at 9:30 AM, Andri Möll wrote:
While I don't think use of durations in years or months are that common, I can definitely see value in them for events like "an entire month every n months". If there's ever a time to fix old mistakes, now would be the time, wouldn't it? Switching from duration format based on ISO 8601 to ISO 8601 proper would be a rather mild change after all.

No, strongly disagree. This makes implementation much harder, as the duration may now have a dependency on the start date rather than being a fixed value. Not to mention what does it even mean if you have a duration of 1 month starting 12pm on 31st May. June doesn't have 31 days, so is this to 30 June? Or to 1st July? What if it recurs? Adding significant complexity for dubious utility (and no way to translate into iCalendar) does not seem a good idea to me.
I agree with Neil. ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months? Does its duration depend on which day you start?

This doesn't even touch issues with calendar scales other than Gregorian. How would you express the duration of a month in the Hebrew calendar?

Week durations don't really add any value IMO. Conversion from/to days is trivial and without any loss of information and many tools probably convert weeks automatically to 7 days internally.

Marten

Neil.


_______________________________________________
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
--------------2F1488411A3C81D99807253F-- From nobody Wed Jul 4 15:15:01 2018 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 8FCA0130E54 for ; Wed, 4 Jul 2018 15:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zonevs.eu header.b=y1JG5l6E; dkim=pass (2048-bit key) header.d=srs1.zonevs.eu header.b=ImYC/Fky; dkim=pass (2048-bit key) header.d=dot.ee header.b=mq5H8Ctj 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 ZtUKjuhVA6tV for ; Wed, 4 Jul 2018 15:14:55 -0700 (PDT) Received: from srs1.zonevs.eu (srs1.zonevs.eu [217.146.68.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406F5130E0F for ; Wed, 4 Jul 2018 15:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=aJCQrW2HqcbmH5qAlOA+QxVUhKDa44g83Nx5sU7TcBw=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=y1JG5l6ExoOL9mKBW84tk2Fn3r/58pZyuffiLD7ynM14g/zAZqLJJqSUYtAHnif4Tz60CF39T 36vvOFLK5ueSbWbgHFQ/qo3COEK0zqZV/JRbj9mfMLcaAq6KWm9VGEeB6ew2utOfuIkhZFI4CuK rQpqp5U2aT4C8okTp0AUYqxr9bTg775n4V2taAkxY+JZrlXaxvNWJuBT8DfnH32Edp0ENoNfWJw YpmYId2MkO7TcC2+EoJrJIZUzvSuXFOAlH3ANDUiVq/eR8p2xQPkIdRe0wFUqm11Rr0EeBiKtxf KCVv2iCl/F0tTuT9i0UN7s+fXOCjZ2WOE8bf/dDuCPwg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs1.zonevs.eu; q=dns/txt; s=oct2016; bh=aJCQrW2HqcbmH5qAlOA+QxVUhKDa44g83Nx5sU7TcBw=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=ImYC/FkyKZbcy8HVfZNo6qOWjhGRcq4kkCEHMx+4cCW3bfRBQWmwut05NZCA0CTLwkmSJhPNN wary2WqrNIzZcY1CoZbiZ8K9889raEWq44/NUmIWhT7vmAneUfDrThy2fnrrNix5WAskRqe3U9e jQlmvV00DFSrmURzq+2CeiAS93ICwpJdK2m/Vry1UiNkrN17CfVcFIbSs6AM70Jkh2qaOcrraJj Zv7ev2Q/wrV7YT17g8bf8gW+hSlTNXM3URfmMjhIW46rSvoRsdnj1ub0eKY9l3ofC2UHBHOQ5+Q NaNCCk+uYXs/ZflBZY1hZWkfqxNBeg4LtY//5FACoXtg== Received: from smtp.zone.eu ([217.146.66.121] smtp.zone.eu) by srs1.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 164675cb9c70002ace.001 for ; Wed, 04 Jul 2018 22:14:47 +0000 X-Zone-Loop: b9e43932db79e507b525aa71e858e33f7dfe961769bd Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.eu (Postfix) with ESMTPSA id 36BF818F9C04 for ; Thu, 5 Jul 2018 01:14:47 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1530742487; bh=hc4KNAaZCMeeuwWBzhj1SEFgcAYdkAAXkoAiIG88I/c=; h=Subject:To:References:From:Date:In-Reply-To; b=mq5H8Ctjas80XNKTrkclHiHI9fi8Tnu/jsFXxXY3YlBpuCzxREIoRKm/F5xrfpEb1 od2yh42rnM3QJCiJ336/vdoISM4e+yqykbhEMVBfBOR8nrHz9R469u/b3rc/3wmRTx Ci1HcjgIyX+m1kEQSlUDvTPWOj/ipP3zwzZXJlmO85guMHniY5IEUrtPNsBzu22GQr 9uUHlPr3hV8RqbZpjyrfRDaPR1jw1v297DnW1qewUFfECV4aTQfag90TGehQi1mEug abOUj2ibKcZVBugwdRLrcy4HFf7co0Q83Szu79f0JqNBnJUU/iYprbjeXfxEQghoTq pp/hVMvYK60Aw== To: calsify@ietf.org References: <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> Date: Wed, 4 Jul 2018 22:14:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> Content-Type: multipart/alternative; boundary="------------9DF2230B73426801F723AB67" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.103296, required=15, tests=[HFILTER_HOSTNAME_5=3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.903296, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 22:15:00 -0000 This is a multi-part message in MIME format. --------------9DF2230B73426801F723AB67 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > No, strongly disagree. This makes implementation /much/ harder, as the > duration may now have a dependency on the start date rather than being > a fixed value. Fair argument that it's not as simple as I might've made it out to be, but I'd push back a little on where the difficulty lies. Coming to an agreement, for sure, but implementing clamping to the end of the previous month in your example is two trivial expressions. > What if it recurs? Recursion is irrelevant as instances are based on the start date/time. > dependency on the start date rather than being a fixed value. That's a good argument, however I see two counters to that. First, fixed value in units of what? iCalendar+jsCalendar support two non-interchangable units of duration already --- one nominal, one accurate. P1M is as fixed as P1D, just in a different frame. Second, by the current jsCalendar spec, P1D seems to be allowed for an event with time. If it is to remain, its accurate length is also dependent on the start time due to DST. It too would need consensus on how to do time arithmetic with a nominal duration. > ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 > days? 183 days? 182,621095 days? 6 months? Ah, I've forgotten it had fractional lengths. Yeah, I don't think their inclusion was particularly good. However, given your example and the fact ISO 8601 has only 3 atoms --- months, days and seconds --- 0.5Y translates to 6 months. > This doesn't even touch issues with calendar scales other than > Gregorian. How would you express the duration of a month in the Hebrew > calendar? My knowledge beyond Gregorian is lacking at the moment, but presumably someone's already thought of it given we have RRULE with MONTHLY. Even if the conclusion was to forbid. :) On 07/04/2018 09:28 PM, Marten Gajda wrote: > Am 04.07.2018 um 03:28 schrieb Neil Jenkins: >> On Wed, 4 Jul 2018, at 9:30 AM, Andri Möll wrote: >>> While I don't think use of durations in years or months are that >>> common, I can definitely see value in them for events like "an >>> entire month every n months". If there's ever a time to fix old >>> mistakes, now would be the time, wouldn't it? Switching from >>> duration format /based on/ ISO 8601 to ISO 8601 proper would be a >>> rather mild change after all. >> >> No, strongly disagree. This makes implementation /much/ harder, as >> the duration may now have a dependency on the start date rather than >> being a fixed value. Not to mention what does it even mean if you >> have a duration of 1 month starting 12pm on 31st May. June doesn't >> have 31 days, so is this to 30 June? Or to 1st July? What if it >> recurs? Adding significant complexity for dubious utility (and no way >> to translate into iCalendar) does not seem a good idea to me. > I agree with Neil. ISO 8601 also allows things like "P0.5Y". How long > is P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months? Does its > duration depend on which day you start? > > This doesn't even touch issues with calendar scales other than > Gregorian. How would you express the duration of a month in the Hebrew > calendar? > > Week durations don't really add any value IMO. Conversion from/to days > is trivial and without any loss of information and many tools probably > convert weeks automatically to 7 days internally. > > Marten >> >> Neil. >> --------------9DF2230B73426801F723AB67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

No, strongly disagree. This makes implementation much harder, as the duration may now have a dependency on the start date rather than being a fixed value.
Fair argument that it's not as simple as I might've made it out to be, but I'd push back a little on where the difficulty lies. Coming to an agreement, for sure, but implementing clamping to the end of the previous month in your example is two trivial expressions.


What if it recurs?
Recursion is irrelevant as instances are based on the start date/time.

dependency on the start date rather than being a fixed value.
That's a good argument, however I see two counters to that. First, fixed value in units of what? iCalendar+jsCalendar support two non-interchangable units of duration already --- one nominal, one accurate. P1M is as fixed as P1D, just in a different frame. Second, by the current jsCalendar spec, P1D seems to be allowed for an event with time. If it is to remain, its accurate length is also dependent on the start time due to DST. It too would need consensus on how to do time arithmetic with a nominal duration.

ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months?
Ah, I've forgotten it had fractional lengths. Yeah, I don't think their inclusion was particularly good. However, given your example and the fact ISO 8601 has only 3 atoms --- months, days and seconds --- 0.5Y translates to 6 months.


This doesn't even touch issues with calendar scales other than Gregorian. How would you express the duration of a month in the Hebrew calendar?
My knowledge beyond Gregorian is lacking at the moment, but presumably someone's already thought of it given we have RRULE with MONTHLY. Even if the conclusion was to forbid. :)


On 07/04/2018 09:28 PM, Marten Gajda wrote:
Am 04.07.2018 um 03:28 schrieb Neil Jenkins:
On Wed, 4 Jul 2018, at 9:30 AM, Andri Möll wrote:
While I don't think use of durations in years or months are that common, I can definitely see value in them for events like "an entire month every n months". If there's ever a time to fix old mistakes, now would be the time, wouldn't it? Switching from duration format based on ISO 8601 to ISO 8601 proper would be a rather mild change after all.

No, strongly disagree. This makes implementation much harder, as the duration may now have a dependency on the start date rather than being a fixed value. Not to mention what does it even mean if you have a duration of 1 month starting 12pm on 31st May. June doesn't have 31 days, so is this to 30 June? Or to 1st July? What if it recurs? Adding significant complexity for dubious utility (and no way to translate into iCalendar) does not seem a good idea to me.
I agree with Neil. ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months? Does its duration depend on which day you start?

This doesn't even touch issues with calendar scales other than Gregorian. How would you express the duration of a month in the Hebrew calendar?

Week durations don't really add any value IMO. Conversion from/to days is trivial and without any loss of information and many tools probably convert weeks automatically to 7 days internally.

Marten

Neil.

--------------9DF2230B73426801F723AB67-- From nobody Wed Jul 4 16:01:52 2018 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 04766130DDB for ; Wed, 4 Jul 2018 16:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] 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 g-3YxFZNdzzQ for ; Wed, 4 Jul 2018 16:01:47 -0700 (PDT) Received: from mailrelay2-1.pub.mailoutpod1-cph3.one.com (mailrelay2-1.pub.mailoutpod1-cph3.one.com [46.30.210.183]) (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 0B9FD130DC9 for ; Wed, 4 Jul 2018 16:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=ebecmliP8XoOl0aZLPHcoqGuC+rYx3eqBwilUUMO7CA=; b=qH1wdTqrAiNZ2JyoevMqwlzWl7BID/BKzesIbOt5VW6mpidLIpT6rALv8OpUwxjBgIgScuN29tH2Z EHdgaFgY+y13FLKSmyz/LNKtjOnK0vbyRpo5qM7J6oO/bI1wZONhTjIUvMjz6RKuLUWwNjOLNv8SCs 6BSLC381rewX2q2Y= X-HalOne-Cookie: 86b025c084ebe43641d5204c599e7e7f11bc2d0f X-HalOne-ID: 38243568-7fde-11e8-a8a4-d0431ea8a290 Received: from smtp.dmfs.org (unknown [62.224.76.155]) by mailrelay2.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 38243568-7fde-11e8-a8a4-d0431ea8a290; Wed, 04 Jul 2018 23:01:43 +0000 (UTC) Received: from boss.localdomain (x2f7f94e.dyn.telefonica.de [2.247.249.78]) by smtp.dmfs.org (Postfix) with ESMTPSA id 56B0859C for ; Thu, 5 Jul 2018 01:01:43 +0200 (CEST) To: calsify@ietf.org References: <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> From: Marten Gajda Message-ID: Date: Thu, 5 Jul 2018 01:01:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> Content-Type: multipart/alternative; boundary="------------DB7F9913B7281E5931593069" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 23:01:51 -0000 This is a multi-part message in MIME format. --------------DB7F9913B7281E5931593069 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit >> ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 >> days? 183 days? 182,621095 days? 6 months? > Ah, I've forgotten it had fractional lengths. Yeah, I don't think > their inclusion was particularly good. However, given your example and > the fact ISO 8601 has only 3 atoms --- months, days and seconds --- > 0.5Y translates to 6 months. You mean the same way P0.5D translates to 12 hours? Or P0.5M translates to 15 days or 15.5 days? How about P0.1Y or even P0.0001Y ? > > >> This doesn't even touch issues with calendar scales other than >> Gregorian. How would you express the duration of a month in the >> Hebrew calendar? > My knowledge beyond Gregorian is lacking at the moment, but presumably > someone's already thought of it given we have RRULE with MONTHLY. Even > if the conclusion was to forbid. :) Right, for RRULE there is RSCALE, which essentially let's you do the math in the other calendar scale. So a Hebrew Year has 12 months, 13 in a leap year (each 29 or 30 days long). How much is P0.5Y in a Hebrew leap year? > > > On 07/04/2018 09:28 PM, Marten Gajda wrote: >> Am 04.07.2018 um 03:28 schrieb Neil Jenkins: >>> On Wed, 4 Jul 2018, at 9:30 AM, Andri Möll wrote: >>>> While I don't think use of durations in years or months are that >>>> common, I can definitely see value in them for events like "an >>>> entire month every n months". If there's ever a time to fix old >>>> mistakes, now would be the time, wouldn't it? Switching from >>>> duration format /based on/ ISO 8601 to ISO 8601 proper would be a >>>> rather mild change after all. >>> >>> No, strongly disagree. This makes implementation /much/ harder, as >>> the duration may now have a dependency on the start date rather than >>> being a fixed value. Not to mention what does it even mean if you >>> have a duration of 1 month starting 12pm on 31st May. June doesn't >>> have 31 days, so is this to 30 June? Or to 1st July? What if it >>> recurs? Adding significant complexity for dubious utility (and no >>> way to translate into iCalendar) does not seem a good idea to me. >> I agree with Neil. ISO 8601 also allows things like "P0.5Y". How long >> is P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months? Does its >> duration depend on which day you start? >> >> This doesn't even touch issues with calendar scales other than >> Gregorian. How would you express the duration of a month in the >> Hebrew calendar? >> >> Week durations don't really add any value IMO. Conversion from/to >> days is trivial and without any loss of information and many tools >> probably convert weeks automatically to 7 days internally. >> >> Marten >>> >>> Neil. >>> > > > _______________________________________________ > 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 --------------DB7F9913B7281E5931593069 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months?
Ah, I've forgotten it had fractional lengths. Yeah, I don't think their inclusion was particularly good. However, given your example and the fact ISO 8601 has only 3 atoms --- months, days and seconds --- 0.5Y translates to 6 months.
You mean the same way P0.5D translates to 12 hours? Or P0.5M translates to 15 days or 15.5 days?

How about P0.1Y or even P0.0001Y ?


This doesn't even touch issues with calendar scales other than Gregorian. How would you express the duration of a month in the Hebrew calendar?
My knowledge beyond Gregorian is lacking at the moment, but presumably someone's already thought of it given we have RRULE with MONTHLY. Even if the conclusion was to forbid. :)
Right, for RRULE there is RSCALE, which essentially let's you do the math in the other calendar scale. So a Hebrew Year has 12 months, 13 in a leap year (each 29 or 30 days long). How much is P0.5Y in a Hebrew leap year?



On 07/04/2018 09:28 PM, Marten Gajda wrote:
Am 04.07.2018 um 03:28 schrieb Neil Jenkins:
On Wed, 4 Jul 2018, at 9:30 AM, Andri Möll wrote:
While I don't think use of durations in years or months are that common, I can definitely see value in them for events like "an entire month every n months". If there's ever a time to fix old mistakes, now would be the time, wouldn't it? Switching from duration format based on ISO 8601 to ISO 8601 proper would be a rather mild change after all.

No, strongly disagree. This makes implementation much harder, as the duration may now have a dependency on the start date rather than being a fixed value. Not to mention what does it even mean if you have a duration of 1 month starting 12pm on 31st May. June doesn't have 31 days, so is this to 30 June? Or to 1st July? What if it recurs? Adding significant complexity for dubious utility (and no way to translate into iCalendar) does not seem a good idea to me.
I agree with Neil. ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months? Does its duration depend on which day you start?

This doesn't even touch issues with calendar scales other than Gregorian. How would you express the duration of a month in the Hebrew calendar?

Week durations don't really add any value IMO. Conversion from/to days is trivial and without any loss of information and many tools probably convert weeks automatically to 7 days internally.

Marten

Neil.



_______________________________________________
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
--------------DB7F9913B7281E5931593069-- From nobody Wed Jul 4 16:10:34 2018 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 9B6FA130DEC for ; Wed, 4 Jul 2018 16:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=v7xVu62T; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f6IgJHO3 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 ybFbtXOXp1xD for ; Wed, 4 Jul 2018 16:10:30 -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 C215A130DC9 for ; Wed, 4 Jul 2018 16:10:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 219B421E0D for ; Wed, 4 Jul 2018 19:10:30 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Wed, 04 Jul 2018 19:10:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=3QeypDyRZLWGI+a1ezrup6JtC/hHO1tG9m43wTAdI bo=; b=v7xVu62TL/Pq6cWQZ7jt3F1oej9PvAACKbVSX5BqVrFxhxAWf+0iqMGpe rJrs/0G3e2L9bLI6jekhJvWjg1mCJjKbi5WWKdugtfFy/Vj/sAPH1zASKTILOOg7 Oa0PTNFbsiQMHsbtz1PFuWdRkQdUGcZKdDjfFF6UhQnKd8ty/xOWWuE0anHH9dO3 xh4LCgHA9zRcbY4gBoQwAHZRyOXSCU09iEvX3QQ21lvkc6JYVN7qsVwdRiHRni5O uGgbWbMM8RolVuFwrquBVOx47Br03Kmedv4KYKXv7tyS70s8vzAXqtv4+3sqTTFZ Fa2ydIpy6+NPHrnWOqFdJH6gYUfOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=3QeypDyRZLWGI+a1ezrup6JtC/hHO1tG9m43wTAdI bo=; b=f6IgJHO3Sfnkt9wMFV0ZEqck9ecHakONMGHY3BI6QTcaffTGVTF966VKA xM/w7bY5Eq6gS+PZvZoiTBjTHWIa8ag+q2uuIPOJg6fBkluoUGQChHYQrbGvuVWL XPWYn7QqXmXXzivnVie0EOxTTH4RBXuGw1dspgvHEDQ2bDfuGAS0XlbqOiXq1GRL EBd7IsAGI5CjZH3+E1Rk3XeAToLx/CYW8+8KHo1dmMQwCQ5OpYbtBpPZxZ1A3lyw nPU8WD1EHPvRT8IP5aFFFtzHhudJ3LQ3trGV4Na3sHEANs9RudH4gkP7zK0gFpj2 f9n2pamPsip91LFdQcXTj94/Jj9yA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 87149CA13D; Wed, 4 Jul 2018 19:10:29 -0400 (EDT) Message-Id: <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-669-gf2de8ca-next x-jmap-identity-id: 64588216 In-Reply-To: <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> References: <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> Date: Wed, 04 Jul 2018 19:10:29 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=812bbe6366bf41a2b182e2b9c4069ab1 Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 23:10:33 -0000 --812bbe6366bf41a2b182e2b9c4069ab1 Content-Type: multipart/related; boundary=9a8b78cdba02442fa52127e1677ed4d3 --9a8b78cdba02442fa52127e1677ed4d3 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, 5 = Jul 2018, at 8:15 AM, Andri M=C3=B6ll wrote:
dependency on th= e start date rather than being a fixed value.
Second, by the current= jsCalendar spec, P1D seems to be allowed for an event with time. If it is to remain, its accurate length is= also dependent on the start time due to DST. It too would need consensus on how to do time arithmetic with a nominal duration.


<=
b>
<=
a class=3D"selflink" name=3D"section-5.1.3" href=3D"https://tools.ietf.o=
rg/html/draft-ietf-calext-jscalendar-05#section-5.1.3" style=3D"color:bl=
ack;text-decoration-line:none;text-decoration-style:initial;text-decorat=
ion-color:initial;">5.1.3.  duration
=

   Type: "Duration", e.g.  "P2DT3H" (optional, default: "P0D")

   The zero or positive duration of the event in absolute time (i.e. in
   UTC time; ignoring DST shifts).

Th= erefore, P1D is exactly equivalent to PT24H in the context of the event = duration.

Neil.
--9a8b78cdba02442fa52127e1677ed4d3-- --812bbe6366bf41a2b182e2b9c4069ab1 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 5 Jul 2018, at 8:15 AM, Andri M=C3=B6ll wrote:=20 >> dependency on the start date rather than being a fixed value. > Second, by the current jsCalendar spec, P1D seems to be allowed for an event with time. If it is to remain, its accurate length is= also dependent on the start time due to DST. It too would need consensus on how to do time arithmetic with a nominal duration. No, see the actual spec : * 5.1.3 . duration * Type: "Duration", e.g. "P2DT3H" (optional, default: "P0D") The zero or positive duration of the event in absolute time (i.e. in UTC time; ignoring DST shifts). Therefore, P1D is exactly equivalent to PT24H in the context of the even= t duration. Neil. --812bbe6366bf41a2b182e2b9c4069ab1-- From nobody Wed Jul 4 17:16:23 2018 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 3097D130DEC for ; Wed, 4 Jul 2018 17:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.onmicrosoft.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 mgidLw3SKxnk for ; Wed, 4 Jul 2018 17:16:17 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0614.outbound.protection.outlook.com [IPv6:2a01:111:f400:febe::614]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4D1130DD8 for ; Wed, 4 Jul 2018 17:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.onmicrosoft.com; s=selector1-ribose-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KkI3LQWg8kH3TTgZV1kxAjRqsgTw3xNpOhS+huESXNE=; b=Yz9QaEkTtLtld1qXbmmv/cA8Ygo+4srOhsgKeJBSLNhxy9OjiNTd79c2u9rCeatYiqwqHru5+4auYYK4bImoJiA5/iBhfZion+gCT7NLwMtCtAotNzcL+M77oiGm2f7Zl2w26M3XEa1YNfmAunU5ot7UdcJfDQWWr+6ylsExiuY= Received: from HK0PR01MB2084.apcprd01.prod.exchangelabs.com (52.133.158.143) by HK0PR01MB2147.apcprd01.prod.exchangelabs.com (52.133.212.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Thu, 5 Jul 2018 00:16:13 +0000 Received: from HK0PR01MB2084.apcprd01.prod.exchangelabs.com ([fe80::b8c2:5837:f9cb:9503]) by HK0PR01MB2084.apcprd01.prod.exchangelabs.com ([fe80::b8c2:5837:f9cb:9503%6]) with mapi id 15.20.0930.016; Thu, 5 Jul 2018 00:16:12 +0000 From: Ronald Tse To: "calsify@ietf.org" Thread-Topic: [calsify] JSCalendar: duration normalization and weeks Thread-Index: AQHUD405YFPVHZ0b5EK6c+FqWJWB8KR+LG8AgAAhBACAAU98gIAADMsAgAAPkYCAABJbgA== Date: Thu, 5 Jul 2018 00:16:12 +0000 Message-ID: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> References: <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> In-Reply-To: <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [112.120.148.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK0PR01MB2147; 7:5oJo6FIj/qcdSMHko2gHle6O1JtDcZSeWb604+fM3Kg1OeLknLYEJq5iFSfbcdbsGt7NOBfhsWyeJ3KdyRsb2/F0ZQ2C4L6Hu0OxQEvsBfSyaOkKswzYEvAJutro7KF4SPgmiuibe3KPruHi1CJJpoSEAWcTWmNN8ypzcYbUHkpxyCJy9ZQP2/rUt9z+kDCIMs6RNFpVlHpOCF7hDP1GDX0WDEP12b2rwHIKfxTqyLg2cIrQ1/f/vyuStRIo9uGO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: cd3ac47c-51f0-4ee6-5ccc-08d5e20c844e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:HK0PR01MB2147; x-ms-traffictypediagnostic: HK0PR01MB2147: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231280)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(2016111802025)(20161123558120)(6072148)(6043046)(201708071742011)(7699016); SRVR:HK0PR01MB2147; BCL:0; PCL:0; RULEID:; SRVR:HK0PR01MB2147; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(39830400003)(346002)(376002)(189003)(199004)(478600001)(33656002)(6486002)(229853002)(6436002)(966005)(25786009)(97736004)(3846002)(26005)(186003)(8936002)(316002)(2900100001)(81156014)(2351001)(8676002)(1730700003)(14454004)(66066001)(81166006)(76176011)(102836004)(5250100002)(5640700003)(82746002)(236005)(2501003)(54896002)(106356001)(6916009)(53546011)(105586002)(6506007)(6306002)(486006)(476003)(83716003)(606006)(446003)(68736007)(2616005)(99286004)(11346002)(6246003)(5660300001)(256004)(93886005)(53936002)(6116002)(36756003)(2906002)(86362001)(7736002)(575784001)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:HK0PR01MB2147; H:HK0PR01MB2084.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: SjXU+7ehAAOo3e1Y+nsvjk8G9Er9gB+31WAlo3wHxbrSqjEzcpCVvT52/M/uKzBbteOKhG6jhXv7+4RUDr8JjtQWAplhrUlqW+mKvbRk9SHZXgOptFmqoz0q4zA/ZkgSb0dT+4Mu3VXv757Pz8v43WW3bJ4UhULJwiQ2QBzUcmbh4UfkXPyLtkDNvnLKBHIhoScNqEX4asoKUkPprMWqWJeKdUgh636BlzNBRHNRCBiIxhmxfHb4tgSn+xKpa4Ki8HmFY/NO1N5omDsiT5EU5L98SO8JLAWIMUKj7Hnt6eVvSu7CvH+1CEqlrMcso94dXlAFBDtS6CC3bCg4Lpqozzo1HbxKONZ2m4EKegBPsdI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_729E8F77EFA647B0851F5E0D892C6C1Eribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: cd3ac47c-51f0-4ee6-5ccc-08d5e20c844e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 00:16:12.8254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR01MB2147 Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:16:21 -0000 --_000_729E8F77EFA647B0851F5E0D892C6C1Eribosecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgbGlrZSB0byByZW1pbmQgb3Vyc2VsdmVzIHRoYXQgdGhlICJleGFjdCBkdXJhdGlvbiIg b2YgYW55IHRpbWUgc2NhbGUgdW5pdCAoZXhjZXB0IGZvciB0aGUgc2Vjb25kKSBhbHJlYWR5IGRl cGVuZHMgb24gdGhlIHN0YXJ0LiBUaGUgbGVhcCBzZWNvbmQgbW9kaWZpZXMgdGhlIGV4YWN0IGR1 cmF0aW9uIG9mIHRoZSBsYXN0IG1pbnV0ZSwgdGhlIGxhc3QgaG91ciwgdGhlIGxhc3QgZGF5IG9m IHRoZSB5ZWFyLCBldGMuIFRoZXJlIHdpbGwgYmUgYSBub3RlIG9uIHRoaXMgaW4gdGhlIG5ldyBJ U08gODYwMS0xLiBUaGUg4oCcc2Vjb25k4oCdIHVuaXQgZG9lc27igJl0IGNoYW5nZSBpbiBkdXJh dGlvbiBiZWNhdXNlIGl0IGlzIGRlZmluZWQgYXMgc28gYnkgVVRDL1VUMSBhbmQgdGhlIGxlYXAg c2Vjb25kIG1lY2hhbmlzbS4NCg0KVGhlIHNpbXBsZSB3YXkgb2YgZGVhbGluZyB3aXRoIFAxRCwg UDFNLCBQMVkgaXMgdG8gZmluZCB0aGUgY29ycmVzcG9uZGluZyBub21pbmFsIGR1cmF0aW9uLiBQ MUQgd2lsbCBsZWFkIHRvIHRoZSBzYW1lIHRpbWUgaW4gYSBkYXkgYWZ0ZXIsIHdoZXRoZXIgaXQg aXMgYSBub3JtYWwgZGF5IG9yIGEgbGVhcCBkYXkuIFAxTSB3aWxsIGxlYWQgdG8gdGhlIHNhbWUg ZGF5IGluIHRoZSBuZXh0IG1vbnRoLiBQMVkgd2lsbCBsZWFkIHRvIHRoZSBzYW1lIG1vbnRoIGRh eSBpbiB0aGUgbmV4dCB5ZWFyIHJlZ2FyZGxlc3MgaWYgaXQgaXMgYSBsZWFwIHllYXIuDQoNClRo ZSBkZWNpbWFsIGZyYWN0aW9uIG5vdGF0aW9uIGluIDg2MDEgaXMg4oCcb3B0aW9uYWzigJ0uIFRo ZXJl4oCZcyBubyBuZWVkIHRvIHN1cHBvcnQgdGhhdCB3aGlsZSBzdGF5aW5nIGNvbXBsaWFudCB3 aXRoIElTTyA4NjAxLg0KDQpRdWVzdGlvbjogVGhlcmUgaXMgb2J2aW91c2x5IGFuIGlzc3VlIHdo ZXJlIHRoZSB0YXJnZXQgZGF5IGlzIG5vdCBhbHdheXMgYXZhaWxhYmxlLCBzdWNoIGEgUDFZIHN0 YXJ0aW5nIG9uIGEgbGVhcCBkYXkgb3IgUDFNIGZyb20gRmVicnVhcnkgMjl0aC4gVGhpcyBiZWhh dmlvciBpcyBub3QgY3VycmVudGx5IGRlZmluZWQgaW4gSVNPIDg2MDEsIGJ1dCB3ZSBjb3VsZCBw cm9wb3NlLiBXaGF0IGlzIHlvdXIgdmlldz8NCg0KUC5TIHRvIEFuZHJpOiB0aGUgbmV3IElTTyA4 NjAxLTIgZGVmaW5lcyBhIOKAnHByb2ZpbGXigJ0gd2hlcmUgYSBzcGVjaWZpY2F0aW9uIGNhbiBz ZWxlY3RpdmVseSBwaWNrIGZlYXR1cmVzIG9mIElTTyA4NjAxIHRvIHN1cHBvcnQsIHNvIHRoZSBw aHJhc2Ug4oCcYmFzZWQgb24gODYwMeKAnSBjYW4gYmUgY2FsbGVkIGEg4oCccHJvZmlsZSBvZiA4 NjAx4oCdLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClJvbmFs ZCBUc2UNClJpYm9zZSBJbmMuDQoNCk9uIEp1bCA1LCAyMDE4LCBhdCA3OjEwIEFNLCBOZWlsIEpl bmtpbnMgPG5laWxqQGZhc3RtYWlsdGVhbS5jb208bWFpbHRvOm5laWxqQGZhc3RtYWlsdGVhbS5j b20+PiB3cm90ZToNCg0KT24gVGh1LCA1IEp1bCAyMDE4LCBhdCA4OjE1IEFNLCBBbmRyaSBNw7Zs bCB3cm90ZToNCmRlcGVuZGVuY3kgb24gdGhlIHN0YXJ0IGRhdGUgcmF0aGVyIHRoYW4NCiAgICAg ICBiZWluZyBhIGZpeGVkIHZhbHVlLg0KU2Vjb25kLCBieSB0aGUgY3VycmVudCBqc0NhbGVuZGFy IHNwZWMsIFAxRCBzZWVtcyB0byBiZSBhbGxvd2VkDQogICAgIGZvciBhbiBldmVudCB3aXRoIHRp bWUuIElmIGl0IGlzIHRvIHJlbWFpbiwgaXRzIGFjY3VyYXRlIGxlbmd0aCBpcw0KICAgICBhbHNv IGRlcGVuZGVudCBvbiB0aGUgc3RhcnQgdGltZSBkdWUgdG8gRFNULiBJdCB0b28gd291bGQgbmVl ZA0KICAgICBjb25zZW5zdXMgb24gaG93IHRvIGRvIHRpbWUgYXJpdGhtZXRpYyB3aXRoIGEgbm9t aW5hbCBkdXJhdGlvbi4NCg0KTm8sIHNlZSB0aGUgYWN0dWFsIHNwZWMgPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNhbGV4dC1qc2NhbGVuZGFyLTA1I3NlY3Rpb24tNS4x LjM+Og0KDQoqDQo1LjEuMyA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Y2FsZXh0LWpzY2FsZW5kYXItMDUjc2VjdGlvbi01LjEuMz4uICBkdXJhdGlvbg0KDQoNCioNCg0K ICBUeXBlOiAiRHVyYXRpb24iLCBlLmcuICAiUDJEVDNIIiAob3B0aW9uYWwsIGRlZmF1bHQ6ICJQ MEQiKQ0KDQogIFRoZSB6ZXJvIG9yIHBvc2l0aXZlIGR1cmF0aW9uIG9mIHRoZSBldmVudCBpbiBh YnNvbHV0ZSB0aW1lIChpLmUuIGluDQogIFVUQyB0aW1lOyBpZ25vcmluZyBEU1Qgc2hpZnRzKS4N Cg0KVGhlcmVmb3JlLCBQMUQgaXMgZXhhY3RseSBlcXVpdmFsZW50IHRvIFBUMjRIIGluIHRoZSBj b250ZXh0IG9mIHRoZSBldmVudCBkdXJhdGlvbi4NCg0KTmVpbC5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY2Fsc2lmeSBtYWlsaW5nIGxpc3QNCmNhbHNp ZnlAaWV0Zi5vcmc8bWFpbHRvOmNhbHNpZnlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NhbHNpZnkNCg0K --_000_729E8F77EFA647B0851F5E0D892C6C1Eribosecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCknigJlkIGxpa2UgdG8gcmVtaW5kIG91cnNlbHZl cyB0aGF0IHRoZSAmcXVvdDtleGFjdCBkdXJhdGlvbiZxdW90OyBvZiBhbnkgdGltZSBzY2FsZSB1 bml0Jm5ic3A7KGV4Y2VwdCBmb3IgdGhlIHNlY29uZCkgYWxyZWFkeSBkZXBlbmRzIG9uIHRoZSBz dGFydC4gVGhlIGxlYXAgc2Vjb25kIG1vZGlmaWVzIHRoZSBleGFjdCBkdXJhdGlvbiBvZiB0aGUg bGFzdCBtaW51dGUsIHRoZSBsYXN0IGhvdXIsIHRoZSBsYXN0IGRheSBvZiB0aGUgeWVhciwgZXRj LiBUaGVyZSB3aWxsIGJlIGENCiBub3RlIG9uIHRoaXMgaW4gdGhlIG5ldyBJU08gODYwMS0xLiBU aGUg4oCcc2Vjb25k4oCdIHVuaXQgZG9lc27igJl0IGNoYW5nZSBpbiBkdXJhdGlvbiBiZWNhdXNl IGl0IGlzIGRlZmluZWQgYXMgc28gYnkgVVRDL1VUMSBhbmQgdGhlIGxlYXAgc2Vjb25kIG1lY2hh bmlzbS4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlRoZSBzaW1wbGUgd2F5IG9mIGRlYWxpbmcgd2l0aCBQMUQsIFAxTSwgUDFZIGlzIHRvIGZpbmQg dGhlIGNvcnJlc3BvbmRpbmcgbm9taW5hbCBkdXJhdGlvbi4gUDFEIHdpbGwgbGVhZCB0byB0aGUg c2FtZSB0aW1lIGluIGEgZGF5IGFmdGVyLCB3aGV0aGVyIGl0IGlzIGEgbm9ybWFsIGRheSBvciBh IGxlYXAgZGF5LiBQMU0gd2lsbCBsZWFkIHRvIHRoZSBzYW1lIGRheSBpbiB0aGUgbmV4dCBtb250 aC4gUDFZIHdpbGwgbGVhZA0KIHRvIHRoZSBzYW1lIG1vbnRoIGRheSBpbiB0aGUgbmV4dCB5ZWFy IHJlZ2FyZGxlc3MgaWYgaXQgaXMgYSBsZWFwIHllYXIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgZGVjaW1hbCBmcmFjdGlvbiBu b3RhdGlvbiBpbiA4NjAxIGlzIOKAnG9wdGlvbmFs4oCdLiBUaGVyZeKAmXMgbm8gbmVlZCB0byBz dXBwb3J0IHRoYXQgd2hpbGUgc3RheWluZyBjb21wbGlhbnQgd2l0aCBJU08gODYwMS48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5RdWVzdGlvbjogVGhlcmUgaXMgb2J2aW91c2x5IGFuIGlzc3VlIHdoZXJlIHRo ZSB0YXJnZXQgZGF5IGlzIG5vdCBhbHdheXMgYXZhaWxhYmxlLCBzdWNoIGEgUDFZIHN0YXJ0aW5n IG9uIGEgbGVhcCBkYXkgb3IgUDFNIGZyb20gRmVicnVhcnkgMjl0aC4gVGhpcyBiZWhhdmlvciBp cyBub3QgY3VycmVudGx5IGRlZmluZWQgaW4gSVNPIDg2MDEsIGJ1dCB3ZSBjb3VsZCBwcm9wb3Nl LiBXaGF0IGlzIHlvdXIgdmlldz88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlAuUyB0byBBbmRyaTogdGhlIG5ldyBJU08gODYwMS0yIGRl ZmluZXMgYSDigJxwcm9maWxl4oCdIHdoZXJlIGEgc3BlY2lmaWNhdGlvbiBjYW4gc2VsZWN0aXZl bHkgcGljayBmZWF0dXJlcyBvZiBJU08gODYwMSB0byBzdXBwb3J0LCBzbyB0aGUgcGhyYXNlIOKA nGJhc2VkIG9uIDg2MDHigJ0gY2FuIGJlIGNhbGxlZCBhIOKAnHByb2ZpbGUgb2YgODYwMeKAnS48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpSb25hbGQgVHNlPGJyIGNsYXNzPSIiPg0KUmlib3NlIEluYy48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwgNSwgMjAxOCwgYXQgNzox MCBBTSwgTmVpbCBKZW5raW5zICZsdDs8YSBocmVmPSJtYWlsdG86bmVpbGpAZmFzdG1haWx0ZWFt LmNvbSIgY2xhc3M9IiI+bmVpbGpAZmFzdG1haWx0ZWFtLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2 Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIFRodSwgNSBKdWwgMjAxOCwgYXQgODoxNSBBTSwgQW5kcmkgTcO2 bGwgd3JvdGU6IDxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ZGVwZW5kZW5jeSBvbiB0aGUgc3Rh cnQgZGF0ZSByYXRoZXIgdGhhbjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2JlaW5nIGEg Zml4ZWQgdmFsdWUuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+U2Vjb25kLCBieSB0aGUgY3VycmVudCBqc0NhbGVuZGFyIHNwZWMsIFAxRCBzZWVtcyB0byBi ZSBhbGxvd2VkPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Zm9yIGFuIGV2ZW50IHdpdGggdGltZS4gSWYgaXQgaXMgdG8gcmVtYWluLCBp dHMgYWNjdXJhdGUgbGVuZ3RoIGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7YWxzbyBkZXBlbmRlbnQgb24gdGhlIHN0YXJ0IHRpbWUgZHVlIHRvIERTVC4gSXQg dG9vIHdvdWxkIG5lZWQ8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtjb25zZW5zdXMgb24gaG93IHRvIGRvIHRpbWUgYXJpdGhtZXRpYyB3aXRoIGEgbm9taW5hbCBk dXJhdGlvbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpObywgc2VlIHRoZSBhY3R1YWwg c3BlYyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Y2FsZXh0LWpzY2FsZW5kYXItMDUjc2VjdGlvbi01LjEuMyIgY2xhc3M9IiI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2FsZXh0LWpzY2FsZW5kYXItMDUjc2VjdGlvbi01 LjEuMzwvYT4mZ3Q7OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCio8YnIgY2xhc3M9IiI+ DQo1LjEuMyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY2FsZXh0LWpzY2FsZW5kYXItMDUjc2VjdGlvbi01LjEuMyIgY2xhc3M9IiI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2FsZXh0LWpzY2FsZW5kYXItMDUjc2VjdGlv bi01LjEuMzwvYT4mZ3Q7LiAmbmJzcDtkdXJhdGlvbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCio8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDtUeXBlOiAmcXVvdDtEdXJhdGlvbiZxdW90OywgZS5nLiAmbmJzcDsmcXVvdDtQMkRUM0gm cXVvdDsgKG9wdGlvbmFsLCBkZWZhdWx0OiAmcXVvdDtQMEQmcXVvdDspPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhlIHplcm8gb3IgcG9zaXRpdmUgZHVyYXRpb24g b2YgdGhlIGV2ZW50IGluIGFic29sdXRlIHRpbWUgKGkuZS4gaW48YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDtVVEMgdGltZTsgaWdub3JpbmcgRFNUIHNoaWZ0cykuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KVGhlcmVmb3JlLCBQMUQgaXMgZXhhY3RseSBlcXVpdmFsZW50IHRvIFBUMjRI IGluIHRoZSBjb250ZXh0IG9mIHRoZSBldmVudCBkdXJhdGlvbi48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpOZWlsLl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KY2Fsc2lmeSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJtYWlsdG86Y2Fsc2lmeUBpZXRmLm9yZyIgY2xhc3M9IiI+Y2Fsc2lmeUBpZXRmLm9y ZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NhbHNpZnk8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_729E8F77EFA647B0851F5E0D892C6C1Eribosecom_-- From nobody Wed Jul 4 17:18:04 2018 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 57ED9130E6B for ; Wed, 4 Jul 2018 17:18:01 -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, 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=zonevs.eu header.b=OM1PmAkK; dkim=pass (2048-bit key) header.d=srs2.zonevs.eu header.b=HimMpmgh; dkim=pass (2048-bit key) header.d=dot.ee header.b=lHNBnPB8 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 Qvwur0Ep8QB0 for ; Wed, 4 Jul 2018 17:17:57 -0700 (PDT) Received: from srs2.zonevs.eu (srs2.zonevs.eu [217.146.68.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57EED130DEC for ; Wed, 4 Jul 2018 17:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=v4CDfjGTw5xc8NGSbqboYhdG2oe9JIMDSwy3GfKMTkA=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=OM1PmAkKUsqx+9xZm+MDI8dVhyfjo+MXr8e+eKd+CYzDHhf0tYpPCjzCFeJnuky8CnepaieJD 0N1vl/jMlKFKea3tc0boQ5Y7svX1CRHTOoZXqhcO+jOA5OtJHQlEjyAveHtIf/cQWIMlo1yVhZJ u67X4U5tFh1fHGrD5AaasIqFya03NPp6Anwu2eb37IRDfgmwXo4H1XU+hMe8WHL9Uw0dkJgY6ws gRV/fGEaotRzHYM22uLA+/lFUKzoeWRrBcm/1tFbScPwvC2LVJGlV7k8lUgnY30expbNDi/+qw6 OZPIwp9Wbo9ZbCMMz8vNi3oi2xgcmuc3DTZtzyG6v38A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs2.zonevs.eu; q=dns/txt; s=oct2016; bh=v4CDfjGTw5xc8NGSbqboYhdG2oe9JIMDSwy3GfKMTkA=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=HimMpmghvfPHtOPVAKohPAD2CxPNky88uGagPC8vp3L/3BnQxJHBmweq9rEn6dPoXh5ye6az2 X63MSgV1XcUM0LM3Om9N4THGHy2wuBhra8FZULuXbNb5u+4tmdwtpdXn96zrUqlqS3pVv5pSpxw 4AoCHK04oth9ooK5FOCqFYeQnWPOKoos9/XrpT/XkLgKaN8hfGrUCygQjWxoUOIlSxWBtxYInvm Mrz9YCreHfys94MDSCCXq4bwqyj/avY+BtRJvBoqalZ+cwXirloRnWJwIXKOjrHFgT+6OCoHFmZ C7mQWpfSvWKddgDlD5Zd/yDJvZYo/vhvIdJ03uhc4LSQ== Received: from smtp.zone.eu ([217.146.66.121] smtp.zone.eu) by srs2.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 16467cd69ac0002ace.001 for ; Thu, 05 Jul 2018 00:17:52 +0000 X-Zone-Loop: a94a8af9895554df188c50cfa1da8ef498566350f935 Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.eu (Postfix) with ESMTPSA id 1755118F9C05 for ; Thu, 5 Jul 2018 03:17:52 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1530749872; bh=3Ik3nOP+wwKF2ApmiQGiQJCkSEhW17DxRas8GfyxXWc=; h=Subject:To:References:From:Date:In-Reply-To; b=lHNBnPB84u9Cz7BEURVMwxUQ6t+r3jteURARwNhMxCan5T7U89fPRJxYhtTJ8DNwq w09l6XbeEM4SCWRVVYe0mee12FRXZiAC2t/7XVHltdJ0PuKpKN4dfY5fSkhJv1GM8M q46n8O3hwUvIgAcAvf528hAw++AzoYoYDuxjIyADoj9Ai+iEw11qXxWmaRoFLqYMiV 3/RZK/B8Fo/4jpIjs4LXbcG7jf7MJqf9mOEKbk/XPSO8R7o2m/elbO+rCFHV/9HkHD u++SRSTX6vG7p63VFNvWXPVOV+0JS8ZdapKAyon2Hyzbrz3zVhmhO9t6U4UtbqDVSC lyqevVz8BJWjA== To: calsify@ietf.org References: <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: Date: Thu, 5 Jul 2018 00:17:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> Content-Type: multipart/alternative; boundary="------------D14283468A9ABE45467C43F3" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.082652, required=15, tests=[HFILTER_HOSTNAME_5=3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.882652, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:18:02 -0000 This is a multi-part message in MIME format. --------------D14283468A9ABE45467C43F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07/04/2018 11:10 PM, Neil Jenkins wrote: > On Thu, 5 Jul 2018, at 8:15 AM, Andri Möll wrote: >>> dependency on the start date rather than being a fixed value. >> Second, by the current jsCalendar spec, P1D seems to be allowed for >> an event with time. If it is to remain, its accurate length is also >> dependent on the start time due to DST. It too would need consensus >> on how to do time arithmetic with a nominal duration. > > No, see the actual spec > : > > * > > > 5.1.3 > . > duration > > * > Type: "Duration", e.g. "P2DT3H" (optional, default: "P0D") The zero or > positive duration of the event in absolute time (i.e. in UTC time; > ignoring DST shifts). > > Therefore, P1D is exactly equivalent to PT24H in the context of the > event duration. > > Neil. > Doh, I entirely missed the reference to DST there. Thanks! This in turn makes me question two things: 1. What was the reasoning behind tying duration to UTC times? I find it odd given good practices of handling events are focusing on and storing time zones and storing local times over UTC because time zones aren't static. If I had an event with time lasting P5D, overlapping the DST switch (an overlap I couldn't foresee, perhaps, because my government makes decisions in the last minute), I would expect it to start and end on the same time of day. If I meant 5*24H, I would've used PT120H. 2. My reading of ISO 8601 back in the day was that it differentiated between nominal and accurate durations quite clearly: > 2.1.7 > nominal duration > duration expressed amongst others in years, months, weeks or days > NOTE The duration of a calendar year, a calendar month, a calendar > week or a calendar day depends on its position in the calendar. > Therefore, the exact duration of a nominal duration can only be > evaluated if the duration of the calendar years, calendar months, > calendar weeks or calendar days used are known. Even if my proposal of including years and months doesn't get through, I don't think promoting or perhaps even permitting nominal durations for events with times is a good idea if there's a hidden assumption that P1D == PT24H (because arithmetic is to be done on the UTC time). I'm willing to bet there are going to be plenty of implementations that will tick time forward linearly given an accurate duration (stepping over DST moments fine), but do arithmetic on local times given nominal durations, and then there will be discrepancies in end times. --------------D14283468A9ABE45467C43F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 07/04/2018 11:10 PM, Neil Jenkins wrote:
On Thu, 5 Jul 2018, at 8:15 AM, Andri Möll wrote:
dependency on the start date rather than being a fixed value.
Second, by the current jsCalendar spec, P1D seems to be allowed for an event with time. If it is to remain, its accurate length is also dependent on the start time due to DST. It too would need consensus on how to do time arithmetic with a nominal duration.

No, see the actual spec:

5.1.3.  duration


   Type: "Duration", e.g.  "P2DT3H" (optional, default: "P0D")

   The zero or positive duration of the event in absolute time (i.e. in
   UTC time; ignoring DST shifts).

Therefore, P1D is exactly equivalent to PT24H in the context of the event duration.

Neil.

Doh, I entirely missed the reference to DST there. Thanks! This in turn makes me question two things:

1. What was the reasoning behind tying duration to UTC times? I find it odd given good practices of handling events are focusing on and storing time zones and storing local times over UTC because time zones aren't static. If I had an event with time lasting P5D, overlapping the DST switch (an overlap I couldn't foresee, perhaps, because my government makes decisions in the last minute), I would expect it to start and end on the same time of day. If I meant 5*24H, I would've used PT120H.

2. My reading of ISO 8601 back in the day was that it differentiated between nominal and accurate durations quite clearly:

2.1.7
nominal duration
duration expressed amongst others in years, months, weeks or days
NOTE The duration of a calendar year, a calendar month, a calendar week or a calendar day depends on its position in the calendar. Therefore, the exact duration of a nominal duration can only be evaluated if the duration of the calendar years, calendar months, calendar weeks or calendar days used are known.
Even if my proposal of including years and months doesn't get through, I don't think promoting or perhaps even permitting nominal durations for events with times is a good idea if there's a hidden assumption that P1D == PT24H (because arithmetic is to be done on the UTC time). I'm willing to bet there are going to be plenty of implementations that will tick time forward linearly given an accurate duration (stepping over DST moments fine), but do arithmetic on local times given nominal durations, and then there will be discrepancies in end times.
--------------D14283468A9ABE45467C43F3-- From nobody Wed Jul 4 17:18:10 2018 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 DE7F7130DEC for ; Wed, 4 Jul 2018 17:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zonevs.eu header.b=p9bylEhS; dkim=pass (2048-bit key) header.d=srs7.zonevs.eu header.b=Lr6mKlXW; dkim=pass (2048-bit key) header.d=dot.ee header.b=Ci1KMgXR 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 vHSW-xUp2FMQ for ; Wed, 4 Jul 2018 17:17:59 -0700 (PDT) Received: from srs7.zonevs.eu (srs7.zonevs.eu [217.146.68.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99CE130E59 for ; Wed, 4 Jul 2018 17:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=63oq94bct1Cs2xPpqKEAtCAAE82b7nn0wZmKZG8xf7M=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; b=p9bylEhSLvZjBq1hIxEzKEuMyLwPtil6a07ZLEQ90STlg1eM5M+KW/xGTB5nCnqKj2auKsyDo 3MkK3esrk/H/Kwza793C3aeXHK4Wr1tE3P1/l28/5HLWcxgvuYqqFro0eXdiFak71WPmcj551OA A42gB2v7rYddzmqs6ntrJWAVIDnS4qTJ0vYV9tfFkvPbt5ap+g0NRtvp8np7s3KqCfq0eQM8TAd qpJVOjHFrNdW6YggnSW4X2zXI4pc5wPnQuQK9JsUYJnxTxv9bLUZLB2S//IdpHYgRB4jrMCdSEL wZo7ltcCSrmK2dbbmtIDrH01d+jzqj5PrbDtpKZKDznw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs7.zonevs.eu; q=dns/txt; s=oct2016; bh=63oq94bct1Cs2xPpqKEAtCAAE82b7nn0wZmKZG8xf7M=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; b=Lr6mKlXWzUMNbNDxb8MgNpU/Iiyn58hxBDta4I/uYBiakcxygcroTuc8S2mJFL5qnhP4kMuC1 dAM6Z0LSDavFiivT9uKDjfLpVcH5ov117ioTa+7xaK+ucrKzN+dzzz+oQ2FJWSXuvbbQvUoODJ2 1uSTQnjFZML1Ax3+hKmNygL++FQKfOY+QFFjSvU2rFX7t9NXhrD9qnDTlbp3tLbDbgQzTp2tHT+ nvyG6t6dZGvYpXA9JISdX0Aqx5wduOJC1Bsib87WQVozOSTdn6Ce/xkpIGgWSM6AnVtiEcdaTLh l1AQ6ZVZ+y5K20pLZnaLv/KibOS2NQvnFUH/R+aSrr1w== Received: from smtp.zone.eu ([217.146.66.121] smtp.zone.eu) by srs7.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 16467cd6b330002ace.001 for ; Thu, 05 Jul 2018 00:17:52 +0000 X-Zone-Loop: 6360ea558b36a903e8083687ab15c89a71d41a1a6d9f Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.eu (Postfix) with ESMTPSA id BB85518F9C03 for ; Thu, 5 Jul 2018 03:17:52 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1530749872; bh=m4eWQaVdD72ieGlT/QHY5ZSUOtt3vgOMKdfaYzOSRg0=; h=Subject:To:References:From:Date:In-Reply-To; b=Ci1KMgXRlVICrYy6i/SB6mj9LGMilIbWvVwv9Aa1dL/mH5E/wfRqesczAM1rgJv9L qzGRRwEmn/qRT3VLUWRqzIdwtDHMZGGr/KMCs6MoELz8RvyLmoElfk5Q6f2+982e1v KW0G8ilWbID8biqgTWjbSG12dDcAvgF0ODksRFhjeAFGH2FKxr7z6DTMdtCES8kUQb sfuM7POrPNpQDxdyzqNBRz3f/2R8AjRMIBjjDycs/pLyTl7om/2/0kbf5M9J5BHbC7 Xgwvy27xGQ+KGGdskWeGde3E+Y39zM7wBwHgkmTESYshDTnesUH5XTHw+NpP5XA3TD KQ7lwiOtpfT9A== To: calsify@ietf.org References: <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <1dde5036-072f-9880-5c63-dfb977fd7207@dot.ee> Date: Thu, 5 Jul 2018 00:17:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-3.103993, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.903993, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:18:02 -0000 On 07/04/2018 11:01 PM, Marten Gajda wrote: >>> This doesn't even touch issues with calendar scales other than >>> Gregorian. How would you express the duration of a month in the >>> Hebrew calendar? >> My knowledge beyond Gregorian is lacking at the moment, but >> presumably someone's already thought of it given we have RRULE with >> MONTHLY. Even if the conclusion was to forbid. :) > > Right, for RRULE there is RSCALE, which essentially let's you do the > math in the other calendar scale. So a Hebrew Year has 12 months, 13 > in a leap year (each 29 or 30 days long). How much is P0.5Y in a > Hebrew leap year? Ah, if Hebrew years aren't a static product of Hebrew months, then years would have to become an atom as well. Coming back to your original point of fractional nominal durations, I checked ISO 8601 and I couldn't find it permitting fractions in anything other than seconds (and by overflow, other time components). Where did you get P0.5Y being a thing? >>> ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 >>> days? 183 days? 182,621095 days? 6 months? >> Ah, I've forgotten it had fractional lengths. Yeah, I don't think >> their inclusion was particularly good. However, given your example >> and the fact ISO 8601 has only 3 atoms --- months, days and seconds >> --- 0.5Y translates to 6 months. > > You mean the same way P0.5D translates to 12 hours? Or P0.5M > translates to 15 days or 15.5 days? My initial reasoning and translation was based on the Gregorian calendar where there are indeed only 3 factors (months, days and seconds). Years are a product of months. Hours and minutes of seconds. Now, as said above, P0.5D doesn't seem to exist as I wished it didn't. :) From nobody Wed Jul 4 17:40:58 2018 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 E1062130DD8 for ; Wed, 4 Jul 2018 17:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.onmicrosoft.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 HWqszIykIoEu for ; Wed, 4 Jul 2018 17:40:53 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0083.outbound.protection.outlook.com [104.47.125.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A061C129C6B for ; Wed, 4 Jul 2018 17:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.onmicrosoft.com; s=selector1-ribose-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dJaYRcGjM/SvSjrIOlQF3H3HHKZbyqwNYzEf8cI2L3s=; b=T2hg1ybRe+mUJLZQzCnz8AhJHZmYRUvPnHW5gQQmQ0QqxXyROKQbdzadNmhOkmyKm0j8hsDtGCPuNahe+tHlKIDPsT5mYkj9fPHzObdFKO5eYQxeWyE7bDkFcJKzwZfXcTFY+IdB8VKHZnJ55q7grcQe9kO3Bi0OSUf4Oo8UFfA= Received: from HK0PR01MB2084.apcprd01.prod.exchangelabs.com (52.133.158.143) by HK0PR01MB1985.apcprd01.prod.exchangelabs.com (52.133.157.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.18; Thu, 5 Jul 2018 00:40:48 +0000 Received: from HK0PR01MB2084.apcprd01.prod.exchangelabs.com ([fe80::b8c2:5837:f9cb:9503]) by HK0PR01MB2084.apcprd01.prod.exchangelabs.com ([fe80::b8c2:5837:f9cb:9503%6]) with mapi id 15.20.0930.016; Thu, 5 Jul 2018 00:40:48 +0000 From: Ronald Tse To: "calsify@ietf.org" Thread-Topic: [calsify] JSCalendar: duration normalization and weeks Thread-Index: AQHUD405YFPVHZ0b5EK6c+FqWJWB8KR+LG8AgAAhBACAAU98gIAADMsAgAAPkYCAABLRAIAABmqA Date: Thu, 5 Jul 2018 00:40:48 +0000 Message-ID: <2C15C743-A65B-476B-8636-38145287FA53@ribose.com> References: <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com; x-originating-ip: [112.120.148.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK0PR01MB1985; 7:buVr/edx067Mmj83+mItpuIZwYHhVTS4Cd8W1GE0LPcx5GQnWyJgrCt4IgZ9EVCzzPGvJDxbbC/SfZUkwXLaCVRSjE5M5/Nk/e93q8+4o3MpWHw5COyVBygBQhIJ72g8iNOM7KKT7MBg68UO+tSSuAEvBFQdaOdWE7PrHWQb1ER/bHFaiTdFB4zS6d3JJHE/C3BlnLFk8x20bVXJ9Zn7urnW01kOCegrW133MPQxYm1E6icKxxxSgDEoVUyl0Sdb x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8de472c2-03ee-41f2-f04b-08d5e20ff38b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:HK0PR01MB1985; x-ms-traffictypediagnostic: HK0PR01MB1985: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(42844554269416)(100405760836317); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(2016111802025)(20161123564045)(6072148)(6043046)(201708071742011)(7699016); SRVR:HK0PR01MB1985; BCL:0; PCL:0; RULEID:; SRVR:HK0PR01MB1985; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39830400003)(136003)(366004)(396003)(199004)(189003)(6116002)(93886005)(2900100001)(2501003)(102836004)(966005)(86362001)(83716003)(256004)(575784001)(14454004)(53546011)(316002)(6506007)(3846002)(6512007)(561944003)(478600001)(6246003)(82746002)(105586002)(97736004)(21615005)(6436002)(53936002)(54896002)(66066001)(6306002)(5660300001)(33656002)(236005)(106356001)(2351001)(5640700003)(6486002)(99286004)(5250100002)(25786009)(6916009)(8936002)(486006)(476003)(446003)(11346002)(2616005)(76176011)(81166006)(81156014)(1730700003)(26005)(606006)(36756003)(7736002)(68736007)(2906002)(229853002)(8676002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HK0PR01MB1985; H:HK0PR01MB2084.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Vrf5+KMO8P26Wlf372VqoyyFWadtmQFi9uN/hPcdMcp1NhDxxYgnfcEUyIftU9QZoFxQcX0gymb2H/p8+4EwmmMkoKb5uoHKfAhtVe1TZ0ffxU+h7NKeFXGHinOOtElX9Kld1Cl2NtvSK6Q1L3huXN4OKHwq30h5SyEPOpxRA96cgq1nP8AC2XRXVYljHRpXVsnY5DqoPQB6peiU21QtbkdqIYuFrWk/BUEnTkKKK/m4bPy+bxVbnFW39KiIcNzXQnp88059cOf0xrDQLKm22gkGG5Wn8QZWk4rx22GZ1shQbeegEXurI0qu5bAL+zpm6urDAdMDsdfVYH2aEZsni1TpgkOJzxH/0Ir0FbNojf0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2C15C743A65B476B863638145287FA53ribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8de472c2-03ee-41f2-f04b-08d5e20ff38b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 00:40:48.0784 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR01MB1985 Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:40:56 -0000 --_000_2C15C743A65B476B863638145287FA53ribosecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kcmksDQoNCjIuIE15IHJlYWRpbmcgb2YgSVNPIDg2MDEgYmFjayBpbiB0aGUgZGF5IHdhcyB0 aGF0IGl0IGRpZmZlcmVudGlhdGVkIGJldHdlZW4gbm9taW5hbCBhbmQgYWNjdXJhdGUgZHVyYXRp b25zIHF1aXRlIGNsZWFybHk6DQoNClRoZSB0ZXJtIOKAnG5vbWluYWwgZHVyYXRpb27igJ0gaGFz IGJlZW4gcmVtb3ZlZCBpbiB0aGUgbmV3IElTTyA4NjAxLTEuDQoNCkFoLCBpZiBIZWJyZXcgeWVh cnMgYXJlbid0IGEgc3RhdGljIHByb2R1Y3Qgb2YgSGVicmV3IG1vbnRocywgdGhlbiB5ZWFycyB3 b3VsZCBoYXZlIHRvIGJlY29tZSBhbiBhdG9tIGFzIHdlbGwuIENvbWluZyBiYWNrIHRvIHlvdXIg b3JpZ2luYWwgcG9pbnQgb2YgZnJhY3Rpb25hbCBub21pbmFsIGR1cmF0aW9ucywgSSBjaGVja2Vk IElTTyA4NjAxIGFuZCBJIGNvdWxkbid0IGZpbmQgaXQgcGVybWl0dGluZyBmcmFjdGlvbnMgaW4g YW55dGhpbmcgb3RoZXIgdGhhbiBzZWNvbmRzIChhbmQgYnkgb3ZlcmZsb3csIG90aGVyIHRpbWUg Y29tcG9uZW50cykuIFdoZXJlIGRpZCB5b3UgZ2V0IFAwLjVZIGJlaW5nIGEgdGhpbmc/DQoNClRo ZSBuZXcgSVNPIDg2MDEtMSB3aWxsIHN1cHBvcnQgUDAuNVkuDQoNClVuZm9ydHVuYXRlbHkgdGhl IGRvY3VtZW50IGlzIHBheS13YWxsZWQgYnV0IHlvdSBjYW4gZmluZCBpdCBoZXJlOiBodHRwczov L3d3dy5pc28ub3JnL3N0YW5kYXJkLzcwOTA3Lmh0bWwNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpSb25hbGQgVHNlDQpSaWJvc2UgSW5jLg0KDQpPbiBKdWwgNSwg MjAxOCwgYXQgODoxNyBBTSwgQW5kcmkgTcO2bGwgPGFuZHJpQGRvdC5lZTxtYWlsdG86YW5kcmlA ZG90LmVlPj4gd3JvdGU6DQoNCk9uIDA3LzA0LzIwMTggMTE6MTAgUE0sIE5laWwgSmVua2lucyB3 cm90ZToNCk9uIFRodSwgNSBKdWwgMjAxOCwgYXQgODoxNSBBTSwgQW5kcmkgTcO2bGwgd3JvdGU6 DQpkZXBlbmRlbmN5IG9uIHRoZSBzdGFydCBkYXRlIHJhdGhlciB0aGFuIGJlaW5nIGEgZml4ZWQg dmFsdWUuDQpTZWNvbmQsIGJ5IHRoZSBjdXJyZW50IGpzQ2FsZW5kYXIgc3BlYywgUDFEIHNlZW1z IHRvIGJlIGFsbG93ZWQgZm9yIGFuIGV2ZW50IHdpdGggdGltZS4gSWYgaXQgaXMgdG8gcmVtYWlu LCBpdHMgYWNjdXJhdGUgbGVuZ3RoIGlzIGFsc28gZGVwZW5kZW50IG9uIHRoZSBzdGFydCB0aW1l IGR1ZSB0byBEU1QuIEl0IHRvbyB3b3VsZCBuZWVkIGNvbnNlbnN1cyBvbiBob3cgdG8gZG8gdGlt ZSBhcml0aG1ldGljIHdpdGggYSBub21pbmFsIGR1cmF0aW9uLg0KDQpObywgc2VlIHRoZSBhY3R1 YWwgc3BlYzxodHRwczovL3Rvb2xzLi5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2FsZXh0LWpz Y2FsZW5kYXItMDUjc2VjdGlvbi01LjEuMz46DQoNCg0KNS4xLjM8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtY2FsZXh0LWpzY2FsZW5kYXItMDUjc2VjdGlvbi01LjEuMz4u ICBkdXJhdGlvbg0KDQoNCiAgIFR5cGU6ICJEdXJhdGlvbiIsIGUuZy4gICJQMkRUM0giIChvcHRp b25hbCwgZGVmYXVsdDogIlAwRCIpDQoNCiAgIFRoZSB6ZXJvIG9yIHBvc2l0aXZlIGR1cmF0aW9u IG9mIHRoZSBldmVudCBpbiBhYnNvbHV0ZSB0aW1lIChpLmUuIGluDQogICBVVEMgdGltZTsgaWdu b3JpbmcgRFNUIHNoaWZ0cykuDQoNCg0KVGhlcmVmb3JlLCBQMUQgaXMgZXhhY3RseSBlcXVpdmFs ZW50IHRvIFBUMjRIIGluIHRoZSBjb250ZXh0IG9mIHRoZSBldmVudCBkdXJhdGlvbi4NCg0KTmVp bC4NCg0KRG9oLCBJIGVudGlyZWx5IG1pc3NlZCB0aGUgcmVmZXJlbmNlIHRvIERTVCB0aGVyZS4g VGhhbmtzISBUaGlzIGluIHR1cm4gbWFrZXMgbWUgcXVlc3Rpb24gdHdvIHRoaW5nczoNCg0KMS4g V2hhdCB3YXMgdGhlIHJlYXNvbmluZyBiZWhpbmQgdHlpbmcgZHVyYXRpb24gdG8gVVRDIHRpbWVz PyBJIGZpbmQgaXQgb2RkIGdpdmVuIGdvb2QgcHJhY3RpY2VzIG9mIGhhbmRsaW5nIGV2ZW50cyBh cmUgZm9jdXNpbmcgb24gYW5kIHN0b3JpbmcgdGltZSB6b25lcyBhbmQgc3RvcmluZyBsb2NhbCB0 aW1lcyBvdmVyIFVUQyBiZWNhdXNlIHRpbWUgem9uZXMgYXJlbid0IHN0YXRpYy4gSWYgSSBoYWQg YW4gZXZlbnQgd2l0aCB0aW1lIGxhc3RpbmcgUDVELCBvdmVybGFwcGluZyB0aGUgRFNUIHN3aXRj aCAoYW4gb3ZlcmxhcCBJIGNvdWxkbid0IGZvcmVzZWUsIHBlcmhhcHMsIGJlY2F1c2UgbXkgZ292 ZXJubWVudCBtYWtlcyBkZWNpc2lvbnMgaW4gdGhlIGxhc3QgbWludXRlKSwgSSB3b3VsZCBleHBl Y3QgaXQgdG8gc3RhcnQgYW5kIGVuZCBvbiB0aGUgc2FtZSB0aW1lIG9mIGRheS4gSWYgSSBtZWFu dCA1KjI0SCwgSSB3b3VsZCd2ZSB1c2VkIFBUMTIwSC4NCg0KMi4xLjcNCm5vbWluYWwgZHVyYXRp b24NCmR1cmF0aW9uIGV4cHJlc3NlZCBhbW9uZ3N0IG90aGVycyBpbiB5ZWFycywgbW9udGhzLCB3 ZWVrcyBvciBkYXlzDQpOT1RFIFRoZSBkdXJhdGlvbiBvZiBhIGNhbGVuZGFyIHllYXIsIGEgY2Fs ZW5kYXIgbW9udGgsIGEgY2FsZW5kYXIgd2VlayBvciBhIGNhbGVuZGFyIGRheSBkZXBlbmRzIG9u IGl0cyBwb3NpdGlvbiBpbiB0aGUgY2FsZW5kYXIuIFRoZXJlZm9yZSwgdGhlIGV4YWN0IGR1cmF0 aW9uIG9mIGEgbm9taW5hbCBkdXJhdGlvbiBjYW4gb25seSBiZSBldmFsdWF0ZWQgaWYgdGhlIGR1 cmF0aW9uIG9mIHRoZSBjYWxlbmRhciB5ZWFycywgY2FsZW5kYXIgbW9udGhzLCBjYWxlbmRhciB3 ZWVrcyBvciBjYWxlbmRhciBkYXlzIHVzZWQgYXJlIGtub3duLg0KRXZlbiBpZiBteSBwcm9wb3Nh bCBvZiBpbmNsdWRpbmcgeWVhcnMgYW5kIG1vbnRocyBkb2Vzbid0IGdldCB0aHJvdWdoLCBJIGRv bid0IHRoaW5rIHByb21vdGluZyBvciBwZXJoYXBzIGV2ZW4gcGVybWl0dGluZyBub21pbmFsIGR1 cmF0aW9ucyBmb3IgZXZlbnRzIHdpdGggdGltZXMgaXMgYSBnb29kIGlkZWEgaWYgdGhlcmUncyBh IGhpZGRlbiBhc3N1bXB0aW9uIHRoYXQgUDFEID09IFBUMjRIIChiZWNhdXNlIGFyaXRobWV0aWMg aXMgdG8gYmUgZG9uZSBvbiB0aGUgVVRDIHRpbWUpLiBJJ20gd2lsbGluZyB0byBiZXQgdGhlcmUg YXJlIGdvaW5nIHRvIGJlIHBsZW50eSBvZiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB3aWxsIHRpY2sg dGltZSBmb3J3YXJkIGxpbmVhcmx5IGdpdmVuIGFuIGFjY3VyYXRlIGR1cmF0aW9uIChzdGVwcGlu ZyBvdmVyIERTVCBtb21lbnRzIGZpbmUpLCBidXQgZG8gYXJpdGhtZXRpYyBvbiBsb2NhbCB0aW1l cyBnaXZlbiBub21pbmFsIGR1cmF0aW9ucywgYW5kIHRoZW4gdGhlcmUgd2lsbCBiZSBkaXNjcmVw YW5jaWVzIGluIGVuZCB0aW1lcy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpjYWxzaWZ5IG1haWxpbmcgbGlzdA0KY2Fsc2lmeUBpZXRmLm9yZzxtYWls dG86Y2Fsc2lmeUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2Fsc2lmeQ0KDQo= --_000_2C15C743A65B476B863638145287FA53ribosecom_ Content-Type: text/html; charset="utf-8" Content-ID: <143EAA4EE33B894295E8A91666D1A8DA@apcprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkFuZHJpLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgdGV4dD0iIzAw MDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiIgY2xhc3M9IiI+Mi4gTXkgcmVhZGluZyBvZiBJU08gODYw MSBiYWNrIGluIHRoZSBkYXkgd2FzIHRoYXQgaXQgZGlmZmVyZW50aWF0ZWQgYmV0d2VlbiBub21p bmFsIGFuZCBhY2N1cmF0ZSBkdXJhdGlvbnMgcXVpdGUgY2xlYXJseTo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRoZSB0ZXJtIOKAnG5vbWluYWwg ZHVyYXRpb27igJ0gaGFzIGJlZW4gcmVtb3ZlZCBpbiB0aGUgbmV3IElTTyA4NjAxLTEuDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiIHN0eWxlPSJmbG9hdDogbm9u ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7Ij5BaCwgaWYgSGVicmV3IHllYXJzIGFyZW4n dCBhIHN0YXRpYyBwcm9kdWN0IG9mIEhlYnJldyBtb250aHMsIHRoZW4geWVhcnMgd291bGQgaGF2 ZSB0byBiZWNvbWUgYW4gYXRvbSBhcyB3ZWxsLiBDb21pbmcgYmFjayB0byB5b3VyIG9yaWdpbmFs IHBvaW50IG9mIGZyYWN0aW9uYWwNCiBub21pbmFsIGR1cmF0aW9ucywgSSBjaGVja2VkIElTTyA4 NjAxIGFuZCBJIGNvdWxkbid0IGZpbmQgaXQgcGVybWl0dGluZyBmcmFjdGlvbnMgaW4gYW55dGhp bmcgb3RoZXIgdGhhbiBzZWNvbmRzIChhbmQgYnkgb3ZlcmZsb3csIG90aGVyIHRpbWUgY29tcG9u ZW50cykuIFdoZXJlIGRpZCB5b3UgZ2V0IFAwLjVZIGJlaW5nIGEgdGhpbmc/PC9zcGFuPjxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFz cz0iIiBzdHlsZT0iZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyI+PGJy IGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgbmV3IElTTyA4NjAx LTEgd2lsbCBzdXBwb3J0IFAwLjVZLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlVuZm9ydHVuYXRlbHkgdGhl IGRvY3VtZW50IGlzIHBheS13YWxsZWQgYnV0IHlvdSBjYW4gZmluZCBpdCBoZXJlOiA8YSBocmVm PSJodHRwczovL3d3dy5pc28ub3JnL3N0YW5kYXJkLzcwOTA3Lmh0bWwiIGNsYXNzPSIiPg0KaHR0 cHM6Ly93d3cuaXNvLm9yZy9zdGFuZGFyZC83MDkwNy5odG1sPC9hPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIg Y2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KUm9uYWxkIFRzZTxiciBjbGFzcz0iIj4NClJpYm9zZSBJbmMu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDUsIDIw MTgsIGF0IDg6MTcgQU0sIEFuZHJpIE3DtmxsICZsdDs8YSBocmVmPSJtYWlsdG86YW5kcmlAZG90 LmVlIiBjbGFzcz0iIj5hbmRyaUBkb3QuZWU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiB0ZXh0 PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj5PbiAwNy8wNC8yMDE4IDExOjEw IFBNLCBOZWlsIEplbmtpbnMgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2l0ZT0ibWlkOjdjNzdkOGJkLTZmMDQtNDY3ZC04N2ZjLTNiZjc5ODgwNTViZkBzbG90 aTIyZDF0MDYiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBUaHUsIDUgSnVsIDIwMTgsIGF0 IDg6MTUgQU0sIEFuZHJpIE3DtmxsIHdyb3RlOiA8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGlkPSJmYXN0bWFpbC1xdW90ZWQiIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ZGVwZW5kZW5jeSBvbiB0aGUgc3RhcnQgZGF0ZSBy YXRoZXIgdGhhbiBiZWluZyBhIGZpeGVkIHZhbHVlLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCjxkaXYgY2xhc3M9IiI+U2Vjb25kLCBieSB0aGUgY3VycmVudCBqc0NhbGVuZGFyIHNwZWMs IFAxRCBzZWVtcyB0byBiZSBhbGxvd2VkIGZvciBhbiBldmVudCB3aXRoIHRpbWUuIElmIGl0IGlz IHRvIHJlbWFpbiwgaXRzIGFjY3VyYXRlIGxlbmd0aCBpcyBhbHNvIGRlcGVuZGVudCBvbiB0aGUg c3RhcnQgdGltZSBkdWUgdG8gRFNULiBJdCB0b28gd291bGQgbmVlZCBjb25zZW5zdXMgb24gaG93 IHRvIGRvIHRpbWUgYXJpdGhtZXRpYyB3aXRoIGEgbm9taW5hbA0KIGR1cmF0aW9uLjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm8sIHNlZSA8YSBocmVmPSJodHRwczovL3Rvb2xzLi5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2FsZXh0LWpzY2FsZW5kYXItMDUjc2VjdGlvbi01LjEu MyIgY2xhc3M9IiI+DQp0aGUgYWN0dWFsIHNwZWM8L2E+OjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2Ui IHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90 dG9tOiAwcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPjxiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTptb25vc3BhY2UiIGNsYXNzPSJmb250Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjFlbSIgY2xhc3M9InNpemUiPjxoNCBzdHlsZT0ibGluZS1oZWlnaHQ6MHB0O2Rpc3Bs YXk6aW5saW5lO3doaXRlLXNwYWNlOnByZTtmb250LWZhbWlseTptb25vc3BhY2U7Zm9udC1zaXpl OjFlbTtmb250LXdlaWdodDpib2xkOyIgY2xhc3M9IiI+PGEgY2xhc3M9InNlbGZsaW5rIiBuYW1l PSJzZWN0aW9uLTUuMS4zIiBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1jYWxleHQtanNjYWxlbmRhci0wNSNzZWN0aW9uLTUuMS4zIiBzdHlsZT0iIj41LjEuMzwv YT4uICBkdXJhdGlvbg0KPC9oND48L3NwYW4+PC9zcGFuPjwvYj48ZGl2IGNsYXNzPSIiPg0KICAg VHlwZTogJnF1b3Q7RHVyYXRpb24mcXVvdDssIGUuZy4gICZxdW90O1AyRFQzSCZxdW90OyAob3B0 aW9uYWwsIGRlZmF1bHQ6ICZxdW90O1AwRCZxdW90OykNCg0KICAgVGhlIHplcm8gb3IgcG9zaXRp dmUgZHVyYXRpb24gb2YgdGhlIGV2ZW50IGluIGFic29sdXRlIHRpbWUgKGkuZS4gaW4NCiAgIFVU QyB0aW1lOyBpZ25vcmluZyBEU1Qgc2hpZnRzKS4NCjwvZGl2PjwvcHJlPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlcmVmb3JlLCBQMUQgaXMg ZXhhY3RseSBlcXVpdmFsZW50IHRvIFBUMjRIIGluIHRoZSBjb250ZXh0IG9mIHRoZSBldmVudCBk dXJhdGlvbi48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk5laWwuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpEb2gsIEkgZW50aXJlbHkgbWlzc2VkIHRoZSByZWZl cmVuY2UgdG8gRFNUIHRoZXJlLiBUaGFua3MhIFRoaXMgaW4gdHVybiBtYWtlcyBtZSBxdWVzdGlv biB0d28gdGhpbmdzOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjEuIFdoYXQgd2FzIHRo ZSByZWFzb25pbmcgYmVoaW5kIHR5aW5nIGR1cmF0aW9uIHRvIFVUQyB0aW1lcz8gSSBmaW5kIGl0 IG9kZCBnaXZlbiBnb29kIHByYWN0aWNlcyBvZiBoYW5kbGluZyBldmVudHMgYXJlIGZvY3VzaW5n IG9uIGFuZCBzdG9yaW5nIHRpbWUgem9uZXMgYW5kIHN0b3JpbmcgbG9jYWwgdGltZXMgb3ZlciBV VEMgYmVjYXVzZSB0aW1lIHpvbmVzIGFyZW4ndCBzdGF0aWMuIElmIEkgaGFkIGFuIGV2ZW50IHdp dGggdGltZSBsYXN0aW5nDQogUDVELCBvdmVybGFwcGluZyB0aGUgRFNUIHN3aXRjaCAoYW4gb3Zl cmxhcCBJIGNvdWxkbid0IGZvcmVzZWUsIHBlcmhhcHMsIGJlY2F1c2UgbXkgZ292ZXJubWVudCBt YWtlcyBkZWNpc2lvbnMgaW4gdGhlIGxhc3QgbWludXRlKSwgSSB3b3VsZCBleHBlY3QgaXQgdG8g c3RhcnQgYW5kIGVuZCBvbiB0aGUgc2FtZSB0aW1lIG9mIGRheS4gSWYgSSBtZWFudCA1KjI0SCwg SSB3b3VsZCd2ZSB1c2VkIFBUMTIwSC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4yLjEuNzxiciBjbGFzcz0iIj4NCm5vbWluYWwg ZHVyYXRpb248YnIgY2xhc3M9IiI+DQpkdXJhdGlvbiBleHByZXNzZWQgYW1vbmdzdCBvdGhlcnMg aW4geWVhcnMsIG1vbnRocywgd2Vla3Mgb3IgZGF5czxiciBjbGFzcz0iIj4NCk5PVEUgVGhlIGR1 cmF0aW9uIG9mIGEgY2FsZW5kYXIgeWVhciwgYSBjYWxlbmRhciBtb250aCwgYSBjYWxlbmRhciB3 ZWVrIG9yIGEgY2FsZW5kYXIgZGF5IGRlcGVuZHMgb24gaXRzIHBvc2l0aW9uIGluIHRoZSBjYWxl bmRhci4gVGhlcmVmb3JlLCB0aGUgZXhhY3QgZHVyYXRpb24gb2YgYSBub21pbmFsIGR1cmF0aW9u IGNhbiBvbmx5IGJlIGV2YWx1YXRlZCBpZiB0aGUgZHVyYXRpb24gb2YgdGhlIGNhbGVuZGFyIHll YXJzLCBjYWxlbmRhciBtb250aHMsDQogY2FsZW5kYXIgd2Vla3Mgb3IgY2FsZW5kYXIgZGF5cyB1 c2VkIGFyZSBrbm93bi48L2Jsb2NrcXVvdGU+DQpFdmVuIGlmIG15IHByb3Bvc2FsIG9mIGluY2x1 ZGluZyB5ZWFycyBhbmQgbW9udGhzIGRvZXNuJ3QgZ2V0IHRocm91Z2gsIEkgZG9uJ3QgdGhpbmsg cHJvbW90aW5nIG9yIHBlcmhhcHMgZXZlbiBwZXJtaXR0aW5nIG5vbWluYWwgZHVyYXRpb25zIGZv ciBldmVudHMgd2l0aCB0aW1lcyBpcyBhIGdvb2QgaWRlYSBpZiB0aGVyZSdzIGEgaGlkZGVuIGFz c3VtcHRpb24gdGhhdCBQMUQgPT0gUFQyNEggKGJlY2F1c2UgYXJpdGhtZXRpYyBpcyB0byBiZSBk b25lDQogb24gdGhlIFVUQyB0aW1lKS4gSSdtIHdpbGxpbmcgdG8gYmV0IHRoZXJlIGFyZSBnb2lu ZyB0byBiZSBwbGVudHkgb2YgaW1wbGVtZW50YXRpb25zIHRoYXQgd2lsbCB0aWNrIHRpbWUgZm9y d2FyZCBsaW5lYXJseSBnaXZlbiBhbiBhY2N1cmF0ZSBkdXJhdGlvbiAoc3RlcHBpbmcgb3ZlciBE U1QgbW9tZW50cyBmaW5lKSwgYnV0IGRvIGFyaXRobWV0aWMgb24gbG9jYWwgdGltZXMgZ2l2ZW4g bm9taW5hbCBkdXJhdGlvbnMsIGFuZCB0aGVuIHRoZXJlDQogd2lsbCBiZSBkaXNjcmVwYW5jaWVz IGluIGVuZCB0aW1lcy4gPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCmNhbHNpZnkgbWFpbGlu ZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOmNhbHNpZnlAaWV0Zi5vcmciIGNs YXNzPSIiPmNhbHNpZnlAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxzaWZ5PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2C15C743A65B476B863638145287FA53ribosecom_-- From nobody Wed Jul 4 17:47:55 2018 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 D6B52130DFA for ; Wed, 4 Jul 2018 17:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=lMriMRqh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NVtSS4VF 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 isAdThYDdsQa for ; Wed, 4 Jul 2018 17:47:51 -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 70F79129C6B for ; Wed, 4 Jul 2018 17:47:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B6CA521990 for ; Wed, 4 Jul 2018 20:47:50 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Wed, 04 Jul 2018 20:47:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=eAITD0R/w35Mj7yO+UD8+3WRhgLdX9ryp/411Z5K4 pE=; b=lMriMRqhNVHxFd0YGlUxHxSjvPJG1jzNRCHiCQuxADXffnw/7vBNKZh5i tnaqzMjqhEg6jzp/0jicjlK1RfT5w1yntRcd+WSRtF1j/3YaKwQn5jei6V2WgY3E gyfM8BMtq47eIbFC8qgPFg3Vi6kvvXBbaYR1+jQcM/7QjcK3OzZdyf22WTabzdbE HTD1Lj2ZtWNyoDl06SBvop8/W9jHq8R6+OVdwJETXX+QeiVTn8Y99SI5OYae6iPG n1RbiXLjqmc7aw3Fxk04sGoM0R8ifFHIlmQ1ynlIKNBr/5S2qANREgV1xeYsWTw+ MJyCK+60KA0jtwITXANglnS5r5Xow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=eAITD0R/w35Mj7yO+UD8+3WRhgLdX9ryp/411Z5K4 pE=; b=NVtSS4VFZqOC0D142sMwC7QuwFRK0S05LTqS4OLtIAYyawvLlDu5BKPum xP3zDdMiWxW2Qt27PCJMPHDdEcgumbGs/swEUG+eJMwRYLt9iMX0Dt8E2kwm7xGq pvzx9zRgn+1ZwAOym327vSE3yBdBGLcyrFAMwpJm+E5l2MfAVBHKk+sONftH4MhL tqS873/on0fs7kqA0IxKpmE8h5hbCawoyvsAK65BldemlKeGXo4JkHMxJg6OiTKp Ew+maF/SBKVpfT2Mlf6xz0BLD2TMxnYvshRdeQfaDek5gJjv5xnP1r9Vwpt6U5bX ZTNuxX8eWGHwQ5TN1LMPKy0Kns0SA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4BAF5CA13D; Wed, 4 Jul 2018 20:47:49 -0400 (EDT) Message-Id: <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-669-gf2de8ca-next x-jmap-identity-id: 64588216 In-Reply-To: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> References: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> Date: Wed, 04 Jul 2018 20:47:49 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=3cf7f19836764eec9741c01b6f0c91cd Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:47:53 -0000 --3cf7f19836764eec9741c01b6f0c91cd Content-Type: multipart/related; boundary=9d2d153992794b05986adaf6f0298f2a --9d2d153992794b05986adaf6f0298f2a Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, 5 Jul 2= 018, at 10:16 AM, Ronald Tse wrote:
I=E2=80=99d like to remind ourselves that the= "exact duration" of any time scale unit (except for the second) al= ready depends on the start. The leap second modifies the exact duration = of the last minute, the last hour, the last day of the year, etc.

I don't believe any current (at leas= t common) calendar implementations implement leap seconds. While I appre= ciate your pedantry here, for the purposes of JSCalendar I expect most i= mplementations to treat minutes, hours, days, weeks as fixed multiples o= f seconds.

The simple way of dealing with P1D, P1M, P1Y is to find= the corresponding nominal duration. P1D will lead to the same time in a= day after, whether it is a normal day or a leap day. P1M will lead to t= he same day in the next month. P1Y will lead to the same month day in the next year regardless if it is a leap year.=

As has been pointed out, this= is not, in fact, simple, e.g. 31 July, 29 Feb. I'm sure future ISO 8601= revisions can come up with ever more complicated rules for how to handl= e this, but I come back to the point that the added complexity here outw= eighs the meagre benefits in functionality.

Neil.
--9d2d153992794b05986adaf6f0298f2a-- --3cf7f19836764eec9741c01b6f0c91cd Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 5 Jul 2018, at 10:16 AM, Ronald Tse wrote: > I=E2=80=99d like to remind ourselves that the "exact duration" of any = time scale unit=C2=A0(except for the second) already depends on the star= t. The leap second modifies the exact duration of the last minute, the l= ast hour, the last day of the year, etc. I don't believe any current (at least common) calendar implementations i= mplement leap seconds. While I appreciate your pedantry here, for the pu= rposes of JSCalendar I expect most implementations to treat minutes, hou= rs, days, weeks as fixed multiples of seconds. > The simple way of dealing with P1D, P1M, P1Y is to find the correspond= ing nominal duration. P1D will lead to the same time in a day after, whe= ther it is a normal day or a leap day. P1M will lead to the same day in = the next month. P1Y will lead to the same month day in the next year regardless if it is a leap year.= As has been pointed out, this is not, in fact, simple, e.g. 31 July, 29 = Feb. I'm sure future ISO 8601 revisions can come up with ever more compl= icated rules for how to handle this, but I come back to the point that t= he added complexity here outweighs the meagre benefits in functionality.= Neil. --3cf7f19836764eec9741c01b6f0c91cd-- From nobody Wed Jul 4 17:52:34 2018 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 ACDED130DFA for ; Wed, 4 Jul 2018 17:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.onmicrosoft.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 U-j-lBcR12bm for ; Wed, 4 Jul 2018 17:52:30 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0074.outbound.protection.outlook.com [104.47.124.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D367130E47 for ; Wed, 4 Jul 2018 17:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.onmicrosoft.com; s=selector1-ribose-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wib6ZbKH+s3t+/2bfpVoNLTwxu5mgr9LV3+PmFAO+cE=; b=YxaF7Oyw1f3hg+hmwlCif5JphEd+Oh/HmpxczFeEterZ1qtqAWrKuLnmtGfoxxFugM+spwuIJBOeH6MyDNJdlUVyJlsbCni78WPIjaCp6Mkag78kGeNGTvsxlhj80tT3HYMt9mrhmXhMdbupDSlDPMwFDzmVpFjkEP4AOzJVvfM= Received: from HK0PR01MB2084.apcprd01.prod.exchangelabs.com (52.133.158.143) by HK0PR01MB1940.apcprd01.prod.exchangelabs.com (52.133.157.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.18; Thu, 5 Jul 2018 00:52:18 +0000 Received: from HK0PR01MB2084.apcprd01.prod.exchangelabs.com ([fe80::b8c2:5837:f9cb:9503]) by HK0PR01MB2084.apcprd01.prod.exchangelabs.com ([fe80::b8c2:5837:f9cb:9503%6]) with mapi id 15.20.0930.016; Thu, 5 Jul 2018 00:52:18 +0000 From: Ronald Tse To: "calsify@ietf.org" Thread-Topic: [calsify] JSCalendar: duration normalization and weeks Thread-Index: AQHUD405YFPVHZ0b5EK6c+FqWJWB8KR+LG8AgAAhBACAAU98gIAADMsAgAAPkYCAABJbgIAACNeAgAABP4A= Date: Thu, 5 Jul 2018 00:52:18 +0000 Message-ID: <090323AF-C1F6-4CA4-8705-4D5345411686@ribose.com> References: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> In-Reply-To: <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com; x-originating-ip: [112.120.148.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK0PR01MB1940; 7:+TWKWOqaJtxfX3wvEaTWidkz/TvvHk8NzfpS9fYdh/Gb7azHWX2tf7TIuWHRaB+X3MuzsZnztDTknGMqx4bs0hSWeNVFFFuFkQ+ijRA0HkllwUiJ5arvtDSX+YLDbt111/Ct7yIjApkSmi4VRzLI3K/J2pIFb5DJ6kmlzhSGX1IsBMh92xwwM+iGHYklQ7TnAAGHzV4vIMmmBRgQDo8DDG34NxfJ6gqy5dDI/GxV9JXA/Gs0ehZlU+ggxK8BGaeQ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ff41682c-93aa-44f4-0fdc-08d5e2118eda x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:HK0PR01MB1940; x-ms-traffictypediagnostic: HK0PR01MB1940: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(2016111802025)(20161123564045)(6072148)(6043046)(201708071742011)(7699016); SRVR:HK0PR01MB1940; BCL:0; PCL:0; RULEID:; SRVR:HK0PR01MB1940; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(346002)(396003)(39830400003)(189003)(199004)(5640700003)(97736004)(99286004)(14454004)(5250100002)(102836004)(2501003)(966005)(76176011)(256004)(2351001)(86362001)(53936002)(6436002)(82746002)(478600001)(2900100001)(186003)(83716003)(6506007)(53546011)(26005)(316002)(5660300001)(6916009)(6246003)(486006)(229853002)(106356001)(66066001)(2906002)(105586002)(6486002)(6116002)(3846002)(476003)(11346002)(2616005)(7736002)(8676002)(8936002)(25786009)(68736007)(54896002)(6512007)(6306002)(446003)(81166006)(81156014)(1730700003)(236005)(36756003)(93886005)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HK0PR01MB1940; H:HK0PR01MB2084.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: FUcA76Pf6X26b7EM6UYhIQfS9NLRch8ufakDfQDXP+PYDdOwE+tZSTRbWSn+yBH9s/zI4y2HCOnngS0GPS/p+YRr8qSFTiGRfSRb5xIcNraYPp0IPSt5pGf35exkH4EtqMwIx9QqJI2rD0sYdvmovdnf0HRlkVrfAdDVIywgcWfxBRfbCuQBnsrcklXBKuuPtaZOWUfr9poBAgSbcsNNv5toPBTTm1qCgmRntGEOTSp0Cj/oqKR3xntl48f49yDaEqoycLlDTHJY4raes6rwIWqsmlLUJA5uCRk2QqI/kaQyMy5PMxxBala5Pk+GG6tV3fgvZxBmqXpwb9Fpo6riJwBFg1/PmMq3go7AxeoCIH0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_090323AFC1F64CA487054D5345411686ribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: ff41682c-93aa-44f4-0fdc-08d5e2118eda X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 00:52:18.0989 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR01MB1940 Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:52:33 -0000 --_000_090323AFC1F64CA487054D5345411686ribosecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2ltcGxpY2l0eSBpcyBjZXJ0YWlubHkgcHJlZmVycmVkLCBidXQgdGhlIGxlYXAgc2Vjb25kIGlz IGFscmVhZHkgcGFydCBvZiBSRkMgNTU0NS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpSb25hbGQgVHNlDQpSaWJvc2UgSW5jLg0KDQpPbiBKdWwgNSwgMjAxOCwg YXQgODo0NyBBTSwgTmVpbCBKZW5raW5zIDxuZWlsakBmYXN0bWFpbHRlYW0uY29tPG1haWx0bzpu ZWlsakBmYXN0bWFpbHRlYW0uY29tPj4gd3JvdGU6DQoNCk9uIFRodSwgNSBKdWwgMjAxOCwgYXQg MTA6MTYgQU0sIFJvbmFsZCBUc2Ugd3JvdGU6DQpJ4oCZZCBsaWtlIHRvIHJlbWluZCBvdXJzZWx2 ZXMgdGhhdCB0aGUgImV4YWN0IGR1cmF0aW9uIiBvZiBhbnkgdGltZSBzY2FsZSB1bml0IChleGNl cHQgZm9yIHRoZSBzZWNvbmQpIGFscmVhZHkgZGVwZW5kcyBvbiB0aGUgc3RhcnQuIFRoZSBsZWFw IHNlY29uZCBtb2RpZmllcyB0aGUgZXhhY3QgZHVyYXRpb24gb2YgdGhlIGxhc3QgbWludXRlLCB0 aGUgbGFzdCBob3VyLCB0aGUgbGFzdCBkYXkgb2YgdGhlIHllYXIsIGV0Yy4NCg0KSSBkb24ndCBi ZWxpZXZlIGFueSBjdXJyZW50IChhdCBsZWFzdCBjb21tb24pIGNhbGVuZGFyIGltcGxlbWVudGF0 aW9ucyBpbXBsZW1lbnQgbGVhcCBzZWNvbmRzLiBXaGlsZSBJIGFwcHJlY2lhdGUgeW91ciBwZWRh bnRyeSBoZXJlLCBmb3IgdGhlIHB1cnBvc2VzIG9mIEpTQ2FsZW5kYXIgSSBleHBlY3QgbW9zdCBp bXBsZW1lbnRhdGlvbnMgdG8gdHJlYXQgbWludXRlcywgaG91cnMsIGRheXMsIHdlZWtzIGFzIGZp eGVkIG11bHRpcGxlcyBvZiBzZWNvbmRzLg0KDQpUaGUgc2ltcGxlIHdheSBvZiBkZWFsaW5nIHdp dGggUDFELCBQMU0sIFAxWSBpcyB0byBmaW5kIHRoZSBjb3JyZXNwb25kaW5nIG5vbWluYWwgZHVy YXRpb24uIFAxRCB3aWxsIGxlYWQgdG8gdGhlIHNhbWUgdGltZSBpbiBhIGRheSBhZnRlciwgd2hl dGhlciBpdCBpcyBhIG5vcm1hbCBkYXkgb3IgYSBsZWFwIGRheS4gUDFNIHdpbGwgbGVhZCB0byB0 aGUgc2FtZSBkYXkgaW4gdGhlIG5leHQgbW9udGguIFAxWSB3aWxsIGxlYWQNCnRvIHRoZSBzYW1l IG1vbnRoIGRheSBpbiB0aGUgbmV4dCB5ZWFyIHJlZ2FyZGxlc3MgaWYgaXQgaXMgYSBsZWFwIHll YXIuDQoNCkFzIGhhcyBiZWVuIHBvaW50ZWQgb3V0LCB0aGlzIGlzIG5vdCwgaW4gZmFjdCwgc2lt cGxlLCBlLmcuIDMxIEp1bHksIDI5IEZlYi4gSSdtIHN1cmUgZnV0dXJlIElTTyA4NjAxIHJldmlz aW9ucyBjYW4gY29tZSB1cCB3aXRoIGV2ZXIgbW9yZSBjb21wbGljYXRlZCBydWxlcyBmb3IgaG93 IHRvIGhhbmRsZSB0aGlzLCBidXQgSSBjb21lIGJhY2sgdG8gdGhlIHBvaW50IHRoYXQgdGhlIGFk ZGVkIGNvbXBsZXhpdHkgaGVyZSBvdXR3ZWlnaHMgdGhlIG1lYWdyZSBiZW5lZml0cyBpbiBmdW5j dGlvbmFsaXR5Lg0KDQpOZWlsLl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpjYWxzaWZ5IG1haWxpbmcgbGlzdA0KY2Fsc2lmeUBpZXRmLm9yZzxtYWlsdG86 Y2Fsc2lmeUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2Fsc2lmeQ0KDQo= --_000_090323AFC1F64CA487054D5345411686ribosecom_ Content-Type: text/html; charset="utf-8" Content-ID: <52B3A68DF8EE6C4EA658D8FE4FC9BD40@apcprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClNpbXBsaWNpdHkgaXMgY2VydGFpbmx5IHByZWZl cnJlZCwgYnV0IHRoZSBsZWFwIHNlY29uZCBpcyBhbHJlYWR5IHBhcnQgb2YgUkZDIDU1NDUuDQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IiBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSb25hbGQgVHNlPGJyIGNsYXNzPSIiPg0KUmli b3NlIEluYy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBK dWwgNSwgMjAxOCwgYXQgODo0NyBBTSwgTmVpbCBKZW5raW5zICZsdDs8YSBocmVmPSJtYWlsdG86 bmVpbGpAZmFzdG1haWx0ZWFtLmNvbSIgY2xhc3M9IiI+bmVpbGpAZmFzdG1haWx0ZWFtLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIFRodSwgNSBKdWwgMjAxOCwgYXQg MTA6MTYgQU0sIFJvbmFsZCBUc2Ugd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+SeKAmWQgbGlrZSB0byByZW1pbmQgb3Vyc2VsdmVzIHRoYXQgdGhl ICZxdW90O2V4YWN0IGR1cmF0aW9uJnF1b3Q7IG9mIGFueSB0aW1lIHNjYWxlIHVuaXQmbmJzcDso ZXhjZXB0IGZvciB0aGUgc2Vjb25kKSBhbHJlYWR5IGRlcGVuZHMgb24gdGhlIHN0YXJ0LiBUaGUg bGVhcCBzZWNvbmQgbW9kaWZpZXMgdGhlIGV4YWN0IGR1cmF0aW9uIG9mIHRoZSBsYXN0IG1pbnV0 ZSwgdGhlIGxhc3QgaG91ciwgdGhlIGxhc3QgZGF5DQogb2YgdGhlIHllYXIsIGV0Yy48YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJIGRvbid0IGJlbGlldmUgYW55 IGN1cnJlbnQgKGF0IGxlYXN0IGNvbW1vbikgY2FsZW5kYXIgaW1wbGVtZW50YXRpb25zIGltcGxl bWVudCBsZWFwIHNlY29uZHMuIFdoaWxlIEkgYXBwcmVjaWF0ZSB5b3VyIHBlZGFudHJ5IGhlcmUs IGZvciB0aGUgcHVycG9zZXMgb2YgSlNDYWxlbmRhciBJIGV4cGVjdCBtb3N0IGltcGxlbWVudGF0 aW9ucyB0byB0cmVhdCBtaW51dGVzLCBob3VycywgZGF5cywgd2Vla3MgYXMgZml4ZWQgbXVsdGlw bGVzIG9mIHNlY29uZHMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+VGhlIHNpbXBsZSB3YXkgb2YgZGVhbGluZyB3aXRoIFAxRCwg UDFNLCBQMVkgaXMgdG8gZmluZCB0aGUgY29ycmVzcG9uZGluZyBub21pbmFsIGR1cmF0aW9uLiBQ MUQgd2lsbCBsZWFkIHRvIHRoZSBzYW1lIHRpbWUgaW4gYSBkYXkgYWZ0ZXIsIHdoZXRoZXIgaXQg aXMgYSBub3JtYWwgZGF5IG9yIGEgbGVhcCBkYXkuIFAxTSB3aWxsIGxlYWQgdG8gdGhlIHNhbWUg ZGF5IGluIHRoZSBuZXh0IG1vbnRoLg0KIFAxWSB3aWxsIGxlYWQ8YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQp0byB0aGUgc2FtZSBtb250aCBkYXkgaW4gdGhlIG5leHQgeWVhciByZWdhcmRs ZXNzIGlmIGl0IGlzIGEgbGVhcCB5ZWFyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFz IGhhcyBiZWVuIHBvaW50ZWQgb3V0LCB0aGlzIGlzIG5vdCwgaW4gZmFjdCwgc2ltcGxlLCBlLmcu IDMxIEp1bHksIDI5IEZlYi4gSSdtIHN1cmUgZnV0dXJlIElTTyA4NjAxIHJldmlzaW9ucyBjYW4g Y29tZSB1cCB3aXRoIGV2ZXIgbW9yZSBjb21wbGljYXRlZCBydWxlcyBmb3IgaG93IHRvIGhhbmRs ZSB0aGlzLCBidXQgSSBjb21lIGJhY2sgdG8gdGhlIHBvaW50IHRoYXQgdGhlIGFkZGVkIGNvbXBs ZXhpdHkgaGVyZSBvdXR3ZWlnaHMgdGhlIG1lYWdyZQ0KIGJlbmVmaXRzIGluIGZ1bmN0aW9uYWxp dHkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmVpbC5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCmNhbHNpZnkgbWFpbGlu ZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOmNhbHNpZnlAaWV0Zi5vcmciIGNs YXNzPSIiPmNhbHNpZnlAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxzaWZ5PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_090323AFC1F64CA487054D5345411686ribosecom_-- From nobody Wed Jul 4 17:56:40 2018 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 5019B129C6B for ; Wed, 4 Jul 2018 17:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=cXnQU53a; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eweizAK8 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 wtkPCs6FvhGK for ; Wed, 4 Jul 2018 17:56:37 -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 54E36130E12 for ; Wed, 4 Jul 2018 17:56:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B86AA20DC6 for ; Wed, 4 Jul 2018 20:56:36 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Wed, 04 Jul 2018 20:56:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Um3S8xojgBJPVFR5eKLZ3+rHpXkUEF5m7Li+dhiN+ EQ=; b=cXnQU53a93DCvneIbSdFgiYlIY6MHlBIzv1tsMXhp7mUoj2avt2OiQdHX CHgMMK/SKdSpp+CTvrIWeL7zIEDjA9ihwssRRrLbAsSEGd6/sEtfi35Y9pwOOnXz Rtv9BI1V/zMPxnqFB8WThJTtRg1WBTLPRNxhhSgmtH62dH/TpBJMDiJnEEILTI53 5hTiy/My6IS9UMXFih866J/OskCH7Goc1O53X0pIv1QpY9dQumtkJl3Stx/O3tgT d7dWGXJWOT9Z7GDAmpXvvsrSwisJHPAzb3XQT/+v2qPFDCn5vspYaiXpTj54LVnW xtQwdYtkPMXZ4w3UsPlGvjsm8rmwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Um3S8xojgBJPVFR5eKLZ3+rHpXkUEF5m7Li+dhiN+ EQ=; b=eweizAK8If9/mkkVcKI682yP2CTpmS7u3trI25aXJHwmAnF8dL0HxYdfd bkDKi+HeqNrqXk4Y4sGv6XMj8kauB7CI2RErZd1jvOrmAnIS09vAVtUW130ehHXm JnABMUKTIsn/qflwWNJO0bn8JhsIZwC/jQOmcVSgWlqYahvTiBx0Qwp74cATXVRa d4qtEjKg9y5y2f4dU7zo/HJCdf4x0PdmHbGkHRNLHYnl35Rbx/3jg5NMDc8ywrNm ER/3phRNyxgCQ3gnYCk6ysVg4HqpnNlgfFxrXnqUgrTqHALBKOSTsNCe0eaYRQUK P2VjgWnmRTgxAZzMC+RT9Jj3jsY/Q== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 401F5CA13D; Wed, 4 Jul 2018 20:56:36 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.3-669-gf2de8ca-next x-jmap-identity-id: 64588216 In-Reply-To: <090323AF-C1F6-4CA4-8705-4D5345411686@ribose.com> References: <090323AF-C1F6-4CA4-8705-4D5345411686@ribose.com> <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> Date: Wed, 04 Jul 2018 20:56:35 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=b5fff23804da4caabd13309891b615ff Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:56:39 -0000 --b5fff23804da4caabd13309891b615ff Content-Type: multipart/related; boundary=d6f9a035ea214245b61c93b780d45ac7 --d6f9a035ea214245b61c93b780d45ac7 Content-Type: text/html
On Thu, 5 Jul 2018, at 10:52 AM, Ronald Tse wrote:
Simplicity is certainly preferred, but the leap second is already part of RFC 5545.

Sure, but the spec allows it not to be supported, and it can trivially be ignored without any real world compatibility issues. The same could not be said for durations of "1 month".

Neil.
--d6f9a035ea214245b61c93b780d45ac7-- --b5fff23804da4caabd13309891b615ff Content-Type: text/plain On Thu, 5 Jul 2018, at 10:52 AM, Ronald Tse wrote: > Simplicity is certainly preferred, but the leap second is already part of RFC 5545. Sure, but the spec allows it not to be supported, and it can trivially be ignored without any real world compatibility issues. The same could not be said for durations of "1 month". Neil. --b5fff23804da4caabd13309891b615ff-- From nobody Tue Jul 24 13:05:45 2018 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 843C6130F52 for ; Tue, 24 Jul 2018 13:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=dcta.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 rDkmhabbm-nD for ; Tue, 24 Jul 2018 13:05:39 -0700 (PDT) Received: from maple.morsemedia.net (maple.morsemedia.net [72.51.43.139]) (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 484BF130DD9 for ; Tue, 24 Jul 2018 13:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dcta.com; s=default; h=To:Date:Message-Id:Subject:Mime-Version:Reply-To:Content-Type: From:Sender:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Tdwt8lCWW+MwPZCSMe/zjYto5YLj5+GszJa+HdCQM8U=; b=i4007Kp9UM/Dk/tlT+zCkK2a0+ jlfyS0Sgo31Vaa+nb5hzGhPEY+WNZBx1OpRoJpiMhB51uUpcWXfTwRDiV25fdx5tDLAoH3ISMPqNp N+EMPIYuNhBFzMEinB0n4R2eTa128SAHQXA8CRzGrexE/es5XomnH5N9KHjc0/6hnLYWLZGRNKKsS sVaTdvlq4WONb2CmUO/JR+dEC9hVI0urobi2Zj9uQL+9b54g+yxhQ361mnGsBpgHw+X2DVrhKYMUO nDyKHW4ElgNKNl6kxMmfsZ8sRBWlsm54VH63uwCUlmavewEjXqNLE0WQIXQH65OpKDQ15PQFWj8ry 6LhNQ2eQ==; Received: from 47-208-67-174.erkacmtk02.res.dyn.suddenlink.net ([47.208.67.174]:39591 helo=[192.168.0.218]) by maple.morsemedia.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fi3Yv-000SX9-HR; Tue, 24 Jul 2018 13:05:37 -0700 From: dave.thewlis@calconnect.org Content-Type: multipart/alternative; boundary="Apple-Mail=_A13C4260-3C7D-42AA-BE70-9C9FE9A9B041" Reply-To: Thewlis Dave Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Tue, 24 Jul 2018 13:05:36 -0700 To: caldeveloper-l mailing list , "calsify@ietf.org" X-Mailer: Apple Mail (2.3445.9.1) X-MorseMedia-MailScanner-Information: Please contact the ISP for more information X-MorseMedia-MailScanner-ID: 1fi3Yv-000SX9-HR X-MorseMedia-MailScanner: Found to be clean X-MorseMedia-MailScanner-SpamCheck: X-MorseMedia-MailScanner-From: dave.thewlis@calconnect.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - maple.morsemedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Get-Message-Sender-Via: maple.morsemedia.net: authenticated_id: dave@dcta.com X-Authenticated-Sender: maple.morsemedia.net: dave@dcta.com Archived-At: Subject: [calsify] Registration is open for CalConnect XLIII in Karlsruhe, Germany, September 24-27, 2018, hosted by 1&1 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 20:05:43 -0000 --Apple-Mail=_A13C4260-3C7D-42AA-BE70-9C9FE9A9B041 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Registration is now open for CalConnect XLIII in Karlsruhe, Germany, = September 24-27, 2018, hosted by 1&1 The CalConnect XLIII web page is located at = http://www.calconnect.org/events/calconnect-xliii-september-2018 = and = contains lodging information, airport and transfer information, meeting = venue, schedule, etc. Note that international travelers will probably = want to fly into Frankfurt Airport (FRA) and take the 1-hour train ride = to Karlsruhe; see = http://www.calconnect.org/events/calconnect-xliii-september-2018#transport= ation = for more information. The meeting venue is at the 1&1 facilities in Karlsruhe, at = Ernst-Frey-Stra=C3=9Fe 10, 76135 Karlsruhe, Germany. The venue is less = than a kilometer walk from the conference hotel, Hotel Santo = , Karlstra=C3=9Fe 67-69, 76137 Karlsruhe, = Germany. The hotel may be booked immediately, see = http://www.calconnect.org/events/calconnect-xliii-september-2018#lodging = = for more information and information. You must book by the end of = August to receive the CalConnect rate, and you must book via the e-mail = address provided on this Lodging page. This event is the first preview of our new conference format. = CalConnect XLIII will be four days (Monday through Thursday), and brings = together, as a single event and with a single fee, our traditional = conference (Conference Track), with elements of the former developers' = forum (Technical Track). The two tracks are simply a handy guide to the = session content, and all attendees are encouraged to attend sessions in = both tracks. We will use your feedback and experience at Karlsruhe to = help us fine-tune our new conference for events in 2019 and beyond. =20 Please see the introduction on the event web page linked above for a = fuller description of what the event will look lie. =20 The schedule for the four days is available on the event web page at = http://www.calconnect.org/events/calconnect-xliii-september-2018#conferenc= e-schedule = . We do expect that the schedule will evolve as we get = closer to the event, so please check periodically. =20 Fees and Registration Options: The registration fee for the full = four-day event is $800 (late registration is $900. We are also offering = a trial one-day registration fee of $300 (late registration $375). = Registration information is at = https://www.calconnect.org/events/event-registration-payment = and is = linked from the event web page. =20 As always, please let me know if you have any questions. =20 See you in Karlsruhe! Dave Thewlis -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org | = Dave.Thewlis@calconnect.org --Apple-Mail=_A13C4260-3C7D-42AA-BE70-9C9FE9A9B041 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Registration is now open  for CalConnect = XLIII in Karlsruhe, Germany, September 24-27, 2018, hosted by = 1&1

The CalConnect= XLIII web page is located at http://www.calconnect.org/events/calconnect-xliii-september-201= 8 and contains lodging information, airport and transfer = information, meeting venue, schedule, etc.  Note that = international travelers will probably want to fly into Frankfurt Airport = (FRA) and take the 1-hour train ride to Karlsruhe; see http://www.calconnect.org/events/calconnect-xliii-september-201= 8#transportation for more information.

The  meeting venue is at the 1&1 facilities in = Karlsruhe, at Ernst-Frey-Stra=C3=9Fe 10, 76135=20 Karlsruhe, Germany. The venue is less than a kilometer walk from the=20 conference hotel, Hotel Santo, Karlstra=C3=9Fe 67-69, = 76137 Karlsruhe, Germany.

The hotel may be booked immediately, see http://www.calconnect.org/events/calconnect-xliii-september-201= 8#lodging for more information and information. You= must book by the end of August to receive = the CalConnect rate, and you must book via the e-mail = address provided on this Lodging page.

This event is the first preview = of  our new conference format. =20 CalConnect XLIII will be four days (Monday through Thursday), and brings together, as a single event and with a single fee, our traditional=20 conference (Conference Track), with  elements of the former = developers'=20 forum (Technical Track). The two tracks are simply a handy guide to the=20= session  content, and all attendees are encouraged to attend = sessions in both tracks. We will use your feedback and experience at Karlsruhe to=20= help us fine-tune our new conference for events in 2019 and beyond. =  

Please = see the introduction on the event web page linked above for a fuller = description of what the event will look lie.  

The schedule for the four days is available on the event web = page at http://www.calconnect.org/events/calconnect-xliii-september-201= 8#conference-schedule.  We do expect that the schedule will = evolve as we get closer to the event, so please check periodically. =  

Fees and Registration Options:  The = registration fee for the full four-day event is $800 (late registration = is $900.  We are also offering a trial one-day = registration fee of $300 (late registration $375). =   Registration information is = at https://www.calconnect.org/events/event-registration-payment and is linked from the event web page.  

As always, please let me = know if you have any questions.  

See you in Karlsruhe!

Dave Thewlis


--
Dave Thewlis, Executive = Director
CalConnect - The = Calendaring and Scheduling Consortium
+1 707 = 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax
http://www.calconnect.org | Dave.Thewlis@calconnect.org


= --Apple-Mail=_A13C4260-3C7D-42AA-BE70-9C9FE9A9B041-- From nobody Thu Jul 26 07:09:10 2018 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 60265130FE6; Thu, 26 Jul 2018 07:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 S89ZWdWVOW_p; Thu, 26 Jul 2018 07:09:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83204130E06; Thu, 26 Jul 2018 07:09:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 139FFB80E84; Thu, 26 Jul 2018 07:08:57 -0700 (PDT) To: julian@lavanauts.org, cyrus@daboo.name, mdouglass@sphericalcowgroup.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aamelnikov@fastmail.fm, iesg@ietf.org, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180726140857.139FFB80E84@rfc-editor.org> Date: Thu, 26 Jul 2018 07:08:57 -0700 (PDT) Archived-At: Subject: [calsify] [Errata Verified] RFC7953 (5420) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 14:09:08 -0000 The following errata report has been verified for RFC7953, "Calendar Availability". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5420 -------------------------------------- Status: Verified Type: Editorial Reported by: Julian Cowley Date Reported: 2018-07-14 Verified by: Alexey Melnikov (IESG) Section: 3.1 Original Text ------------- availabilityprop = *( ; ; the following are REQUIRED ; but MUST NOT occur more than once ; dtstamp / uid ; ; the following are OPTIONAL ; but MUST NOT occur more than once ; busytype / class / created / description / dtstart / last-mod / location / organizer / priority /seq / summary / url / ; ; Either 'dtend' or 'duration' MAY appear ; in an 'availableprop', but 'dtend' and ^^^^^^^^^^^^^ ; 'duration' MUST NOT occur in the same ; 'availabilityprop'. ; 'duration' MUST NOT be present if ; 'dtstart' is not present ; dtend / duration / ; ; the following are OPTIONAL ; and MAY occur more than once ; categories / comment / contact / x-prop / iana-prop ; ) Corrected Text -------------- availabilityprop = *( ; ; the following are REQUIRED ; but MUST NOT occur more than once ; dtstamp / uid ; ; the following are OPTIONAL ; but MUST NOT occur more than once ; busytype / class / created / description / dtstart / last-mod / location / organizer / priority /seq / summary / url / ; ; Either 'dtend' or 'duration' MAY appear ; in an 'availabilityprop', but 'dtend' and ^^^^^^^^^^^^^^^^ ; 'duration' MUST NOT occur in the same ; 'availabilityprop'. ; 'duration' MUST NOT be present if ; 'dtstart' is not present ; dtend / duration / ; ; the following are OPTIONAL ; and MAY occur more than once ; categories / comment / contact / x-prop / iana-prop ; ) Notes ----- The text 'availableprop' is a typo and should be 'availabilityprop' instead. The text is only concerned with 'dtend' and 'duration' in the VAVAILABILITY component, and has nothing to do with the AVAILABLE component and its associated 'availableprop'. -------------------------------------- RFC7953 (draft-ietf-calext-availability-04) -------------------------------------- Title : Calendar Availability Publication Date : August 2016 Author(s) : C. Daboo, M. Douglass Category : PROPOSED STANDARD Source : Calendaring Extensions Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Fri Jul 27 10:37:11 2018 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 7160C130F63 for ; Sat, 14 Jul 2018 02:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 fgCofYWMe-Jc for ; Sat, 14 Jul 2018 02:21:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C90130F55 for ; Sat, 14 Jul 2018 02:21:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F2A41B80FD2; Sat, 14 Jul 2018 02:21:09 -0700 (PDT) To: cyrus@daboo.name, mdouglass@sphericalcowgroup.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, daniel.migault@ericsson.com, d3e3e3@gmail.com, mozilla@kewis.ch X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: julian@lavanauts.org, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180714092109.F2A41B80FD2@rfc-editor.org> Date: Sat, 14 Jul 2018 02:21:09 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 27 Jul 2018 10:37:07 -0700 Subject: [calsify] [Editorial Errata Reported] RFC7953 (5420) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 09:21:14 -0000 The following errata report has been submitted for RFC7953, "Calendar Availability". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5420 -------------------------------------- Type: Editorial Reported by: Julian Cowley Section: 3.1 Original Text ------------- ; Either 'dtend' or 'duration' MAY appear ; in an 'availableprop', but 'dtend' and ; 'duration' MUST NOT occur in the same ; 'availabilityprop'. ; 'duration' MUST NOT be present if ; 'dtstart' is not present ; dtend / duration / Corrected Text -------------- ; Either 'dtend' or 'duration' MAY appear ; in an 'availabilityprop', but 'dtend' and ; 'duration' MUST NOT occur in the same ; 'availabilityprop'. ; 'duration' MUST NOT be present if ; 'dtstart' is not present ; dtend / duration / Notes ----- The text 'availableprop' is a typo and should be 'availabilityprop' instead. The text is only concerned with 'dtend' and 'duration' in the VAVAILABILITY component, and has nothing to do with the AVAILABLE component and its associated 'availableprop'. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7953 (draft-ietf-calext-availability-04) -------------------------------------- Title : Calendar Availability Publication Date : August 2016 Author(s) : C. Daboo, M. Douglass Category : PROPOSED STANDARD Source : Calendaring Extensions Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Tue Jul 31 03:22:28 2018 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 3DAFE130E1A for ; Tue, 31 Jul 2018 03:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Hcz08z19P4ad for ; Tue, 31 Jul 2018 03:22:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD780130DEC for ; Tue, 31 Jul 2018 03:22:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C52B6B81B18; Tue, 31 Jul 2018 03:22:12 -0700 (PDT) To: Alexey.Melnikov@isode.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, lear@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: julian@lavanauts.org, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180731102212.C52B6B81B18@rfc-editor.org> Date: Tue, 31 Jul 2018 03:22:12 -0700 (PDT) Archived-At: Subject: [calsify] [Editorial Errata Reported] RFC6047 (5447) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 10:22:26 -0000 The following errata report has been submitted for RFC6047, "iCalendar Message-Based Interoperability Protocol (iMIP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5447 -------------------------------------- Type: Editorial Reported by: Julian Cowley Section: GLOBAL Original Text ------------- ATTENDEE;RSVP=YES:mailto:foo2@example.com Corrected Text -------------- ATTENDEE;RSVP=TRUE:mailto:foo2@example.com Notes ----- In the examples that include the ATTENDEE property, there is a minor issue. According to RFC 5545, Section 3.2.17, the RSVP parameter value should be "TRUE" or "FALSE", not "YES" or "NO". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6047 (draft-ietf-calsify-rfc2447bis-11) -------------------------------------- Title : iCalendar Message-Based Interoperability Protocol (iMIP) Publication Date : December 2010 Author(s) : A. Melnikov, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Jul 31 04:18:11 2018 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 88568130E95 for ; Tue, 31 Jul 2018 04:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RmpZKnJQyyoW for ; Tue, 31 Jul 2018 04:17:55 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324A9130F06 for ; Tue, 31 Jul 2018 04:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3451; q=dns/txt; s=iport; t=1533035875; x=1534245475; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=/+Y/Ie+TLi51lrl2eUlhLqnXROd3TAXZnzxr9zA3ZNI=; b=HgkLUhihjv7YGV+TwkUL/jU9JgApYAAq6Wql3956Qbhc1j8nRaHWvDRb TFK8SQbTakmF083ipw4NVrtJkWsDepyUMiXcKO/ctPNsMO8vthAeUk7Yx Kfji4ZMUrH1j4rhsnMcpAIG3LMMMSO0253gwhRtYDYMZZdcS3D3Tb/etE o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AgCtRGBb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQxbRIog36IZY1DLZVXgXoIAyOESQKDQjUXAQIBAQIBAQJ?= =?us-ascii?q?tHAyFNwEFI1YQCxgnAwICRhEGAQwGAgEBgxwBgX8Pq1WBLoo6D4kbggCBEie?= =?us-ascii?q?Ca4FBhj6CVQKHdx+GBYt6CYNngVmJcgaBSIQdgkyFXJI7gUMBNYFSMxoIGxU?= =?us-ascii?q?agwoJgiiIZIVAPTCQEAEB?= X-IronPort-AV: E=Sophos; i="5.51,427,1526342400"; d="asc'?scan'208"; a="5533070" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2018 11:17:53 +0000 Received: from [10.61.244.88] ([10.61.244.88]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w6VBHq3l032301; Tue, 31 Jul 2018 11:17:52 GMT To: RFC Errata System , Alexey.Melnikov@isode.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com Cc: julian@lavanauts.org, calsify@ietf.org References: <20180731102212.C52B6B81B18@rfc-editor.org> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <3e6e3e93-eeb1-f024-16dc-a626c445b40d@cisco.com> Date: Tue, 31 Jul 2018 13:17:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180731102212.C52B6B81B18@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kRLzsiflyy09OtzWbQNJlBIIp6gs2FMAi" X-Outbound-SMTP-Client: 10.61.244.88, [10.61.244.88] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [calsify] [Editorial Errata Reported] RFC6047 (5447) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 11:18:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kRLzsiflyy09OtzWbQNJlBIIp6gs2FMAi Content-Type: multipart/mixed; boundary="rl6pYxeJ1tPUP6ItfX9ASRqyfOywaDR2b"; protected-headers="v1" From: Eliot Lear To: RFC Errata System , Alexey.Melnikov@isode.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com Cc: julian@lavanauts.org, calsify@ietf.org Message-ID: <3e6e3e93-eeb1-f024-16dc-a626c445b40d@cisco.com> Subject: Re: [Editorial Errata Reported] RFC6047 (5447) References: <20180731102212.C52B6B81B18@rfc-editor.org> In-Reply-To: <20180731102212.C52B6B81B18@rfc-editor.org> --rl6pYxeJ1tPUP6ItfX9ASRqyfOywaDR2b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US I agree that this is an erratum, and it is a problem with ALL of the examples.=C2=A0 Thus I believe it should be VERIFIED; however it is technical, not editorial (IMHO). Eliot On 31.07.18 12:22, RFC Errata System wrote: > The following errata report has been submitted for RFC6047, > "iCalendar Message-Based Interoperability Protocol (iMIP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5447 > > -------------------------------------- > Type: Editorial > Reported by: Julian Cowley > > Section: GLOBAL > > Original Text > ------------- > ATTENDEE;RSVP=3DYES:mailto:foo2@example.com > > Corrected Text > -------------- > ATTENDEE;RSVP=3DTRUE:mailto:foo2@example.com > > Notes > ----- > In the examples that include the ATTENDEE property, there is a minor is= sue. According to RFC 5545, Section 3.2.17, the RSVP parameter value sho= uld be "TRUE" or "FALSE", not "YES" or "NO". > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 > > -------------------------------------- > RFC6047 (draft-ietf-calsify-rfc2447bis-11) > -------------------------------------- > Title : iCalendar Message-Based Interoperability Protocol= (iMIP) > Publication Date : December 2010 > Author(s) : A. Melnikov, Ed. > Category : PROPOSED STANDARD > Source : Calendaring and Scheduling Standards Simplificati= on > Area : Applications > Stream : IETF > Verifying Party : IESG > --rl6pYxeJ1tPUP6ItfX9ASRqyfOywaDR2b-- --kRLzsiflyy09OtzWbQNJlBIIp6gs2FMAi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltgRWEACgkQh7ZrRtnS ejPrJQf/b96P1WTPUCNCZjH4HyFP6P7UQnxHjW5czgCSqaVx5cYddbPe4ctHB3Ws +oVlJNpmB+ELD+5UTIG+mkzQWOMaBRGVpd3WrLtMT5wLz1XA4ArK/iwkkq57yFWJ QvtngwznTHoWBkklPxfqu3eJPPL/6ifkTyo/tFahVWgOPwyJKPC4P0ElujhbKnJQ 1x4fSuzTNPRrs0cDdhEy0fZ5y8du4uVdr5cvtJBoyIxIJi3A13kDdqfUw6vtIUR4 1i0lN8Qaxc1NXOno7eZt8S2kCv0EgL3mIJcEO12NyFmnsL8Up83eZMqQsl6mu7Qe zvnSiGBCmXLDi2HM/qgt6+AJLqjwqQ== =I/Rl -----END PGP SIGNATURE----- --kRLzsiflyy09OtzWbQNJlBIIp6gs2FMAi--