From nobody Mon Jun 3 09:15:39 2019 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 792881204A7 for ; Mon, 3 Jun 2019 09:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ennNQt8p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vDS/t91o 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 UpbUVGKQKDAl for ; Mon, 3 Jun 2019 09:15:37 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBADA12048A for ; Mon, 3 Jun 2019 09:15:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 613E8778 for ; Mon, 3 Jun 2019 12:15:36 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 03 Jun 2019 12:15:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=pD/Yk7LZDBhUAFiPFiT8Dhim93kyNRvbJFqSdmR wEhg=; b=ennNQt8pEeyAVw/cKXIJM5FtEchps9ruEa8xqvQadSP3J+OaDg0XY/3 IikDfnG9kgCf1CEB6CFsdUNtT/yPnOb/tTpvUaRxCfjVTgOaqofKtXjdJCRJxoZp Z2wzUkZbA4KfGFG4eljR3S3DzSbzbC7S6mCy2n3mgkwF/K06jzU1kQQ0fLKYIZ0B SKIDUxFBZr+e+VUMgj7AkGfZ850bn9buzNwHgPYIQWr4tUfUIAXbCKIPjUtmRjGD R8+L73viS7W/mJsgOggOs4jl0kP0xvcVNowSI2VaNgN8TaRLmSp+zZq5yewpOGyY m5hMWQZhngDBhM0M9XBdPviZxgczinw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=pD/Yk7LZDBhUAFiPFiT8Dhim93kyN RvbJFqSdmRwEhg=; b=vDS/t91oUL0fY18BrbjHCVISdZG2pV3L5rx+Fu18PvSCY t77mmnrMEc2CuR9x/9IjogXIdjQaPzxusRqVz9TKtXyllViDpM3qWSqqxWZSeFq3 MlpImItJq0Fm7NQXqpesYd81jVQPGxpP56SoLX8I0hngZ5OkOs2Xz1xX5qh5xOnU eTcanC5UqvuqfScdJFfgCTCEMODZ/WLOzPGg8gcRNlx8fKUChrQrskbVttvtgkoY Y+cyxn/gdJUdm0FC38PqVnlzLvAwzAI+pZoMEpag+8dxVfJJKPelTddRLcYctD3f Ow+ntmDc7Gm1wuMiBz9Ggta0Et1pRddLpZYx5f6XA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefjedgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepiihoohhmrdhushenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5BF56180091; Mon, 3 Jun 2019 12:15:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-555-g49357e1-fmstable-20190528v2 Mime-Version: 1.0 Message-Id: <67b70165-e5fb-40ab-a138-9d4aa981c8a9@www.fastmail.com> Date: Mon, 03 Jun 2019 17:15:34 +0100 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=895aa2e27bfe40e592d18c107c4b88f4 Archived-At: Subject: [calsify] Testing zoom link for tomorrow's meeting X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 16:15:38 -0000 --895aa2e27bfe40e592d18c107c4b88f4 Content-Type: text/plain We have the link up now https://zoom.us/j/4574164360 I'll leave it running for the next half hour or so if anyone wants to test. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --895aa2e27bfe40e592d18c107c4b88f4 Content-Type: text/html
We have the link up now


I'll leave it running for the next half hour or so if anyone wants to test.

Bron.

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


--895aa2e27bfe40e592d18c107c4b88f4-- From nobody Mon Jun 3 18:05:49 2019 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 46546120161; Mon, 3 Jun 2019 18:05:48 -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 uVjW_iw_Y5Dq; Mon, 3 Jun 2019 18:05:46 -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 94FBF120137; Mon, 3 Jun 2019 18:05:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 238C0B82282; Mon, 3 Jun 2019 18:05:39 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, calsify@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190604010539.238C0B82282@rfc-editor.org> Date: Mon, 3 Jun 2019 18:05:39 -0700 (PDT) Archived-At: Subject: [calsify] =?utf-8?q?RFC_8607_on_Calendaring_Extensions_to_WebDAV?= =?utf-8?q?_=28CalDAV=29=3A_Managed_Attachments?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 01:05:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8607 Title: Calendaring Extensions to WebDAV (CalDAV): Managed Attachments Author: C. Daboo, A. Quillaud, K. Murchison, Ed. Status: Informational Stream: IETF Date: June 2019 Mailbox: cyrus@daboo.name, arnaud.quillaud@oracle.com, murch@fastmailteam.com Pages: 34 Characters: 66117 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-calext-caldav-attachments-04.txt URL: https://www.rfc-editor.org/info/rfc8607 DOI: 10.17487/RFC8607 This specification adds an extension to the Calendaring Extensions to WebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server. This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP. This document is a product of the Calendaring Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jun 4 07:44:50 2019 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 05454120077 for ; Tue, 4 Jun 2019 07:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=l5zi4yXZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=v2yYLhk/ 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 zn4PG1CaPerc for ; Tue, 4 Jun 2019 07:44:46 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB71120044 for ; Tue, 4 Jun 2019 07:44:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 5493E3253 for ; Tue, 4 Jun 2019 10:44:44 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 04 Jun 2019 10:44:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=omIXPQrLn/G+BOTbuFEOnv/CO7l5v/nTNvxKhdN tI9Q=; b=l5zi4yXZzXjLtCpooR07Ugu6XjltAQ/hMst/9/DmikV2C5nPlKxPQ0C 3aXqROaOmniD02nsYVCIHTn8iuq59dA9O1Akg4yvYxmryzoJacBz+z85dsjOgIX0 3JCcyrmwZej6b1AXosCcphAoGBAEuT32wHgqmRNszxxhySQ+u+QpXUfvXXnfUDst ygx4wWXL1jDkw79gS/HJE4shScbgXrbcH/x4Zn8MLP2wpEiB00iyU454Mtmpn6id mLg7n508QLmmr5vgv8/cZLnNYJ7FDxODXjiINWhcvqjViXWe2LgVtNjzzkwXsD/o V3O3JONiaXyWFNkkYMEIciXpEv4V/Og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=omIXPQrLn/G+BOTbuFEOnv/CO7l5v /nTNvxKhdNtI9Q=; b=v2yYLhk/hV35r9++LjTdG4VSNlfopBS5WKCpMmWi9qk2a PsGMrbxuwhfU3tHIvqCbl/8mhEL22hICJbYzlVXV6DZ0ohFQDA3OPEemvpauk0Fa nmQmn1OUlbYpef8cwqjexD7bsiuNse+vExmNuF1aNUH5aa6we8pEY3xInTzH5Tg2 /pg8EzXlWo/zlUwmr0Tf7IuU+GXnVnzs3a9JgnTmM8OV4b9lfiQcXh2yzG5sxVcJ 8AkYnvIMrxP/RJq1P95vPredXKKq8i6v95URAXzwNk66fZ0KNJZxL78xOvRjLJQ2 xUtdiYHU3HeAQac7ENWgJGU7MtPbefSoXOMG07Nrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefledgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne gorfhhihhshhhinhhgqdfvgeduuddqgeehucdlfedttddmnecujfgurhepofgfggfkfffh vffutgesrgdtreerreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoe gsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpeiiohho mhdruhhspdgurhhophgsohigrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrh honhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 976051800FD; Tue, 4 Jun 2019 10:44:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-555-g49357e1-fmstable-20190528v2 Mime-Version: 1.0 Message-Id: <8ccf75f3-6b8c-4822-b5f3-f6ae0235bc4f@www.fastmail.com> Date: Wed, 05 Jun 2019 00:44:43 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c83a4f7b4a89404bb675f02da2f3537c Archived-At: Subject: [calsify] Meeting starting in 15 minutes: X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 14:44:48 -0000 --c83a4f7b4a89404bb675f02da2f3537c Content-Type: text/plain The meeting link is here: https://zoom.us/j/4574164360 I'm taking notes and presenting from this doc: https://paper.dropbox.com/doc/Calext-meeting-2019-06-04--AebvTLrj2QcqpXwCcCxzzr79Ag-XwxXQZnAahVfhEBrwJ1La (which will be converted into minutes at the end) The meeting is already up, so you're welcome to join when ready. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --c83a4f7b4a89404bb675f02da2f3537c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
The meeting link is here:


= I'm taking notes and presenting from this doc:


(which will be converted into minutes at the end)

The meeting is already up, so you're welcome to join when read= y.

Bron.

--
  Bron Gondwana, C= EO, FastMail Pty Ltd
  brong@fast= mailteam.com


--c83a4f7b4a89404bb675f02da2f3537c-- From nobody Wed Jun 5 12:48:21 2019 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 9336B12024F; Wed, 5 Jun 2019 12:48:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mglt.ietf@gmail.com, barryleiba@computer.org, calsify@ietf.org, calext-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155976408159.22389.10683937833516861716.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2019 12:48:01 -0700 Archived-At: Subject: [calsify] calext - New Meeting Session Request for IETF 105 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 19:48:08 -0000 A new meeting session request has just been submitted by Daniel Migault, a Chair of the calext working group. --------------------------------------------------------- Working Group Name: Calendaring Extensions Area Name: Applications and Real-Time Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 15 Conflicts to Avoid: First Priority: ipsecme quic tls ace lwig dnsop People who must be present: Barry Leiba Daniel Migault Bron Gondwana Resources Requested: Special Requests: We will need to make possible remote participation --------------------------------------------------------- From nobody Wed Jun 5 13:05:09 2019 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 D81CE12021B for ; Wed, 5 Jun 2019 13:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8Vo4sqLKt6f for ; Wed, 5 Jun 2019 13:05:06 -0700 (PDT) Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (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 D6F80120159 for ; Wed, 5 Jun 2019 13:05:05 -0700 (PDT) Received: by mail-qk1-f181.google.com with SMTP id s22so5978603qkj.12 for ; Wed, 05 Jun 2019 13:05:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IKQwHumfEth5lkQdGrZZPTosm/Njf58YIbLerLi29ro=; b=hc1BqI7TDnehu6Ch9Efga8nCY9JT9G6AYmDJ/fP53RTCTsfOrJHzUq1ssfdSQnOmaT NVlAYDUf11XnLJ5aIqTAE761l5IXKHbs6eJsOcPgJ/c7LX4OZSVQio8n2jxlC2kU0RGx DWe9QWC++w1sQor4Fw7b5NPHmW3T53/EJTR0ZePKsk9Ec/Sl+423OPWPeb/D3Lq837Up ZgVd+1R6lht/Lp5rLmp2lsHf6IalrPxIA07L3oUWtOPppXLns6jH7zSWuOYWnVcKXsqu 5azOSN6yYE4xzKa+DoOaCgZrgelQi+8AUR4CeJoXncF7FOsDacasGQNaasGaQi0y3yI6 Wz0A== X-Gm-Message-State: APjAAAXGncN3IokSAWaSqzVe14cHQdgiaJ4Cbzqg8LFJYfgCVKBSYgDF DgeILVDpw9gVn7sZutzvqr7DDIV7bAwUPEWbiNeBm9BL X-Google-Smtp-Source: APXvYqxs/nJx1wJ61Msl1jrE5ys1nhT7W/ESegyYovTJQMss7IVCRHDDESddb/J8FIgk1UBnB8lOAHZR7qXwfG2XeKg= X-Received: by 2002:a37:5cc6:: with SMTP id q189mr34600550qkb.166.1559765104588; Wed, 05 Jun 2019 13:05:04 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Wed, 5 Jun 2019 16:04:53 -0400 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="000000000000fdfadd058a991ce3" Archived-At: Subject: [calsify] meeting in Montreal IETF 105 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 20:05:08 -0000 --000000000000fdfadd058a991ce3 Content-Type: text/plain; charset="UTF-8" Hi, We have requested a session for calext at the IETF in Montreal. If you are planning to come that is great otherwise there will be remote access being provided. If you think that is a very bad idea, feel free to share. We currently expect to sync the ongoing work as we did during the interim meeting. Feel free to let us know if there any other topic you are willing to discuss. Exact time day and time will be provided when set. Yours, Daniel and Bron --000000000000fdfadd058a991ce3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

We have requested a session f= or calext at the IETF in Montreal. If you are planning to come that is grea= t otherwise there will be remote access being provided. If you think that i= s a very bad idea, feel free to share.=C2=A0

We cu= rrently expect to sync the ongoing work as we did during the interim meetin= g. Feel free to let us know if there any other topic you are willing to dis= cuss.=C2=A0

Exact time day and time will be provid= ed when set.=C2=A0

Yours,=C2=A0
Daniel a= nd Bron
--000000000000fdfadd058a991ce3-- From nobody Thu Jun 6 03:13:07 2019 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 16C381200D7; Thu, 6 Jun 2019 03:12:58 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155981597800.11630.3379225239073140334@ietfa.amsl.com> Date: Thu, 06 Jun 2019 03:12:58 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-14.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 10:12:58 -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-14.txt Pages : 51 Date : 2019-06-06 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. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-14 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 Thu Jun 6 03:44:32 2019 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 C1CD612021B for ; Thu, 6 Jun 2019 03:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=Xf6tpkAk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jWZh6WFq 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 8Q3Gnl_2zAF4 for ; Thu, 6 Jun 2019 03:44:29 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DA01201FA for ; Thu, 6 Jun 2019 03:44:28 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CA3E4221C2 for ; Thu, 6 Jun 2019 06:44:27 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 06 Jun 2019 06:44:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=xctu5XhXXgdvF1hfLArl34udnKiJ8NRT9gubIYN ZfnM=; b=Xf6tpkAkONJhggjCniwZa2ELT/l8OZhlkBXS8nHdFNcUx24FDlOEsZZ /PhnzwGfPYOKjHM7f4Bd45KPrw0W6cMpb6IiDG6VMFLILITl9VtRADdoYZX1I99x TyeoLqi0sg/Auf8zTVFpQkubgizcsEz4xa87xgFGnjLK4DBiy+As3nzMvZHM0Mm2 1rcTi/jrk0wkCBbj9AiEplGed7ipEkJMSRRdD09fCVY7SqQE9vSMkVFEcNWtb4B9 95VjuK0yLTBXmk0u3L6Vj0OThSE6bplWYpifdB4FZnQgTKHlhfZ0TgdH1pbgGd1G 7srHMAstvHTAunMH79QHSHatlg/uAQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=xctu5XhXXgdvF1hfLArl34udnKiJ8 NRT9gubIYNZfnM=; b=jWZh6WFqBgPKaQTy1+MfxRj4TyoVSTPq2n1eSHoCr+XgH m9gVnjPPjFQJhSAYJtz6cTGq7jt9oqwzYulvw3Wi7TeWRX3XVDfmPL9a7PL7oEc8 9jvRS5Ax9iQb7k6MwqefOTHqsJmh93rJ5u6ayfff0bBp3/RFJBhTD9hIDcKg8WZw aqg6KFqVyTPXEffmlM7FD+XwmQrg4VrqnN8jf9HHNwS+290AeNQ7pp8gaue8YG4J 40mhTawqZbJy+pjFNLRnXF3YcyYX/5zQFVFHjqmCQX5WUYqH6ys30dwrPsmyZaB5 tEEeV5Qx85BZO0Dz1Mt+foHam6sOAlHFhssbFzR2A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh dpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshht mhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 478EE1801DB; Thu, 6 Jun 2019 06:44:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-662-gd87dd0f-fmstable-20190606v1 Mime-Version: 1.0 Message-Id: <1530f510-069a-40dc-b66d-8cd85ce92f08@www.fastmail.com> Date: Thu, 06 Jun 2019 11:44:11 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a46b7b9fc2404fb5ad72ee1fbf148d8c Archived-At: Subject: [calsify] Updated JSCalendar RFC draft version 14 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 10:44:31 -0000 --a46b7b9fc2404fb5ad72ee1fbf148d8c Content-Type: text/plain Hi All, I have submitted version 14 of the JSCalendar RFC draft. This version includes the feedback on the mailing list over the last weeks as well as from current CalConnect XLV in Bedford, UK. *Changes*: * Reduced markup and formatting for legibility. * Reworded sharing section and changed definition of "private" privacy from property black-list to white-list. The complete list of changes is available at https://github.com/CalConnect/PUBLIC_DRAFTS/commits/master/jscalendar *Open points*: * As agreed in the joint IETF/CalConnect virtual meeting on June 4, we'll revisit the definition of all day calendar objects. I'll send out an email to discuss on this mailing list. Cheers, Robert --a46b7b9fc2404fb5ad72ee1fbf148d8c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

I have submitted version 14 of= the JSCalendar RFC draft. This version includes the feedback on the mai= ling list over the last weeks as well as from current CalConnect XLV in = Bedford, UK.

Changes:
=
  • Reduced markup and formatting for legibility.
  • = Reworded sharing section and changed definition of "private" privacy fro= m property black-list to white-list.


Open points:
  • As agreed in= the joint IETF/CalConnect virtual meeting on June 4, we'll revisit the = definition of all day calendar objects. I'll send out an email to discus= s on this mailing list.

Chee= rs,
Robert

--a46b7b9fc2404fb5ad72ee1fbf148d8c-- From nobody Thu Jun 6 04:49:45 2019 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 529201200F9 for ; Thu, 6 Jun 2019 04:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=gzk1ZOt6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JQ/xSMzq 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 75sD47CrjhZI for ; Thu, 6 Jun 2019 04:49:42 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4134E1200F1 for ; Thu, 6 Jun 2019 04:49:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 541CF21FB5 for ; Thu, 6 Jun 2019 07:49:41 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 06 Jun 2019 07:49:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=nfc87AYrHMhJ+DFO/oilytUZV7lJWClo5iz/G0o Q0NM=; b=gzk1ZOt6Bs0Iu9um644pwcYchR+nQLqICddQ82aFlBsL06g1IAFhX07 NtnY4InMgZPyjYHSF7VQOgCiepRTHELLss8Wr5Tp638dGcrO20AblgR8AyPyAeu9 NQ8wD201JU9KFfsBGDqtnQSuyHQlvuRgh0mscdyjMzUrpce8aGC22e+IUmM4BQUg WLB+PeJWdpDGj4ZhSLA7klmzlLGM1BRhil/5UdLjGv5uAU3N3JUZEvFOa9etj8Yx NatF9Hn0iqX/dmnf5MxW0/epff9KfcYZGn57qPXTCoKxS0FWWlepQef+or8Ce/SV XfS1kS/bVX5EigJfXWX+1uq6w0iUKuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=nfc87AYrHMhJ+DFO/oilytUZV7lJW Clo5iz/G0oQ0NM=; b=JQ/xSMzq1NQgBlb6B7y7OwctUFJI9GPp2LUomhcIXnYgw w6FSLS9dDRzDHoJRoFPRGN9FhU2onAypv8u3Jq/nWkOpaTL8pMdaJwJN9HwQXgNT PdlPYNhILbNhAkM1dUsTNA5TmW5QCAgSQXPEoBfY0d5ebPbSauin7nqu55vOz6kL mchNOspoDMiK3kUK5vlSt8Tky0A0knHQyaLx0EHU4PIElKGdJ2DQbIQ5rpTRBHsu 89gBowL6wVUnpPCvsjjuH7HiW15karJlDa5q5aP0Rss1aKwWu9kDi9cNEbtfmcRC xEOvd22IyMlXMKR7fL8jCFZBsa95LATBYSJijdQNg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrsh htohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD1211801DD; Thu, 6 Jun 2019 07:49:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-662-gd87dd0f-fmstable-20190606v1 Mime-Version: 1.0 Message-Id: Date: Thu, 06 Jun 2019 12:49:40 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=f3f70d40b0944c2881fafc1317e5469a Archived-At: Subject: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 11:49:44 -0000 --f3f70d40b0944c2881fafc1317e5469a Content-Type: text/plain It just occurred to me that the current JSCalendar RFC draft ambiguously defines if fractional seconds are allowed in the LocalDate time type. To be clear: we intend to allow fractional seconds in the start property (and any other LocalDate property). The next version of the RFC draft will define this more clearly. Unfortunately, fractional second date-times and durations can not be round-tripped out of the box with iCalendar. We will define an iCalendar extension parameter in the informational guide for mapping iCalendar and JSCalendar (draft-ietf-calext-jscalendar-icalendar): * X-FRACSEC of value type INTEGER * This parameter MAY be set on iCalendar properties of type DATE-TIME or DURATION. It MUST NOT be set more than once per property. * The value of this parameter defines the fractional seconds of the DATE-TIME or DURATION type. * This will allow iCalendar implementations not being aware of this extension parameter to display the time value "good enough" with second precision. Please let me know if you prefer another approach. Cheers, Robert --f3f70d40b0944c2881fafc1317e5469a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
It just occurre= d to me that the current JSCalendar RFC draft ambiguously defines if fra= ctional seconds are allowed in the LocalDate time type.
To be clear: we intend to allow fractional seconds in the s= tart property (and any other LocalDate property). The next version of th= e RFC draft will define this more clearly.

= Unfortunately, fractional second date-times and durations can not be rou= nd-tripped out of the box with iCalendar. We will define an iCalendar ex= tension parameter in the informational guide for mapping iCalendar and J= SCalendar (draft-ietf-calext-jscalendar-icalendar):
  • X-F= RACSEC of value type INTEGER
  • This parameter MAY be set on iC= alendar properties of type DATE-TIME or DURATION. It MUST NOT be set mor= e than once per property.
  • The value of this parameter define= s the fractional seconds of the DATE-TIME or DURATION type.
  • = This will allow iCalendar implementations  not being aware of this = extension parameter to display the time value "good enough" with second = precision.

Please let me know if you pr= efer another approach.

Cheers,
Robert
--f3f70d40b0944c2881fafc1317e5469a-- From nobody Thu Jun 6 05:04:07 2019 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 B0929120139 for ; Thu, 6 Jun 2019 05:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_NONE=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 vG0qbXWiHAkb for ; Thu, 6 Jun 2019 05:04:03 -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 E00B112004F for ; Thu, 6 Jun 2019 05:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=fD6qjzHAQcGZQjAFMAyscgSNkRtXNWu3EqaUNmdsTyM=; b=zF2IR7TTmD4X1xXCSKoy1BCfmnIaWvOJ1FWUnfUKMqpfRB1sdCCbgRpPrhLOLdvEL7uZjhd2vmLDS +a5KEj7unGhJ0jXCVh80I8HvelmYKMU7Os+1z7Qmu0e7eR6QAxBo5aGGTqQ7WLvLkuv39sf/lXnjLH ODfgp8YcjVHyOerg= X-HalOne-Cookie: cf1ff79195288d95dc785159c412c672a43a6148 X-HalOne-ID: 2a9bd84b-8853-11e9-bc2a-d0431ea8a283 Received: from smtp.dmfs.org (unknown [2003:5f:6e16:2f00:201:2eff:fe40:2624]) by mailrelay1.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 2a9bd84b-8853-11e9-bc2a-d0431ea8a283; Thu, 06 Jun 2019 12:03:59 +0000 (UTC) Received: from boss.localdomain (unknown [5.148.88.162]) by smtp.dmfs.org (Postfix) with ESMTPSA id C783A589 for ; Thu, 6 Jun 2019 14:03:58 +0200 (CEST) To: calsify@ietf.org References: From: Marten Gajda Message-ID: Date: Thu, 6 Jun 2019 14:03:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------355FD07BC6B85EB6507C1135" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 12:04:06 -0000 This is a multi-part message in MIME format. --------------355FD07BC6B85EB6507C1135 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Is this parameter is meant to preserve the fractional seconds for round-trips or are iCalendar clients encouraged to use the value? I mean, would a client that's aware of X-FRACSEC have to match RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds into account? I think we should advise against that and make clear that this is not meant to increase the precision of times in iCalendar, but merely to preserve it. Btw, how do we cope with unaware clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override. Marten Am 06.06.19 um 13:49 schrieb Robert Stepanek: > It just occurred to me that the current JSCalendar RFC draft > ambiguously defines if fractional seconds are allowed in the LocalDate > time type. > > To be clear: we intend to allow fractional seconds in the start > property (and any other LocalDate property). The next version of the > RFC draft will define this more clearly. > > Unfortunately, fractional second date-times and durations can not be > round-tripped out of the box with iCalendar. We will define an > iCalendar extension parameter in the informational guide for mapping > iCalendar and JSCalendar (draft-ietf-calext-jscalendar-icalendar): > > * X-FRACSEC of value type INTEGER > * This parameter MAY be set on iCalendar properties of type > DATE-TIME or DURATION. It MUST NOT be set more than once per property. > * The value of this parameter defines the fractional seconds of the > DATE-TIME or DURATION type. > * This will allow iCalendar implementations  not being aware of this > extension parameter to display the time value "good enough" with > second precision. > > > Please let me know if you prefer another approach. > > Cheers, > Robert > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------355FD07BC6B85EB6507C1135 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Is this parameter is meant to preserve the fractional seconds for round-trips or are iCalendar clients encouraged to use the value?

I mean, would a client that's aware of X-FRACSEC have to match RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds into account?

I think we should advise against that and make clear that this is not meant to increase the precision of times in iCalendar, but merely to preserve it.

Btw, how do we cope with unaware clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override.

Marten

Am 06.06.19 um 13:49 schrieb Robert Stepanek:
It just occurred to me that the current JSCalendar RFC draft ambiguously defines if fractional seconds are allowed in the LocalDate time type.

To be clear: we intend to allow fractional seconds in the start property (and any other LocalDate property). The next version of the RFC draft will define this more clearly.

Unfortunately, fractional second date-times and durations can not be round-tripped out of the box with iCalendar. We will define an iCalendar extension parameter in the informational guide for mapping iCalendar and JSCalendar (draft-ietf-calext-jscalendar-icalendar):
  • X-FRACSEC of value type INTEGER
  • This parameter MAY be set on iCalendar properties of type DATE-TIME or DURATION. It MUST NOT be set more than once per property.
  • The value of this parameter defines the fractional seconds of the DATE-TIME or DURATION type.
  • This will allow iCalendar implementations  not being aware of this extension parameter to display the time value "good enough" with second precision.

Please let me know if you prefer another approach.

Cheers,
Robert

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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------355FD07BC6B85EB6507C1135-- From nobody Thu Jun 6 05:04:34 2019 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 A8EFA120139 for ; Thu, 6 Jun 2019 05:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=aUpTsBiQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Zbjz1hbZ 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 sgEueoohnT9P for ; Thu, 6 Jun 2019 05:04:31 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EECDA12004F for ; Thu, 6 Jun 2019 05:04:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EAAFB221E5 for ; Thu, 6 Jun 2019 08:04:29 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 06 Jun 2019 08:04:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=y7GXhwX jmdidCcpSRFgptfpMJMMYc83eUO/mD1Mxy6w=; b=aUpTsBiQZOOnB+6+xEix0xG IvJv33yPLfbub674EcZRHoCraKExHO6JdnV3+0oA6JNnZZgtcaAoc029UbsTkNH7 0/h/lGRpV3dc+I+tH4YuR+QOhUNs8tIo1tV3INVcP45miTtJE0XupvXH5Pd3Wo1m I9GnBNR7Tlx5ECDBJl8hUUNsaphmZ45OAca4UznuoG2RNleXMgDfcOwAn4aSoBz7 ihJrRhvvXCTS95Yoe4rhgWeuLFc6OWCwoCwS1AGM2ik5vYSjcUuNdLgDi+W1KZtX jAnefdkiKxS+Q3spK2wus7hdOsW/lau4eFCGJhHPQtiLEg3s1vI8Vk7zc+/syqQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=y7GXhw XjmdidCcpSRFgptfpMJMMYc83eUO/mD1Mxy6w=; b=Zbjz1hbZ4Tde5oa9FTSP/3 NFFcq4+Kp1PAIqH547bvvwo3ydiwXMveXTesaYsGWczsQNoa6bfCbOKitNf+3VDB TlXki4Mn2WIRYbi/3rYFY3irVQAr6+rsu4dyV2EZHUh9lBXL3ahyOz72F1RUBj94 Y1QiZi4hfMqccTfo806kMGp4zTUAo7HCdZpFWSYffnP0BKEX9uycFzjqStd8syl1 e2Sp2+XzK6GPZLiw+tcJE0suoNyxuewVqt+2lupNTc9v549oyGFMVOiz2fvyOiTY 3go2W0OqIRL5Nh9tD6ioiWaGY/rzCEaqF90uWKNXj/hTQtANIpKdPKGgImElAl4Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 42A7D1801DD; Thu, 6 Jun 2019 08:04:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-662-gd87dd0f-fmstable-20190606v1 Mime-Version: 1.0 Message-Id: <5ee23d93-7723-41b0-9005-bc1c15e29904@www.fastmail.com> In-Reply-To: References: Date: Thu, 06 Jun 2019 13:04:19 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=6b7a2489d79e475d893e45677a78b371 Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 12:04:33 -0000 --6b7a2489d79e475d893e45677a78b371 Content-Type: text/plain On second thought, I'll change the X-FRACSEC name to FRACSEC and its parameter type to FLOAT: So On Thu, Jun 6, 2019, at 12:49 PM, Robert Stepanek wrote: > * X-FRACSEC of value type INTEGER will be changed to FRACSEC of type FLOAT, where the float value MUST be positive and MUST have an integral part of 0. Cheers, Robert --6b7a2489d79e475d893e45677a78b371 Content-Type: text/html
On second thought, I'll change the X-FRACSEC name to FRACSEC and its parameter type to FLOAT:

So

On Thu, Jun 6, 2019, at 12:49 PM, Robert Stepanek wrote:
  • X-FRACSEC of value type INTEGER

will be changed to

FRACSEC of type FLOAT, where the float value MUST be positive and MUST have an integral part of 0.

Cheers,
Robert


--6b7a2489d79e475d893e45677a78b371-- From nobody Thu Jun 6 05:07:25 2019 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 8408D1200B5 for ; Thu, 6 Jun 2019 05:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=NeDJ8vnE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GeUgbcFD 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 Ivqi-xVfkaaO for ; Thu, 6 Jun 2019 05:07:22 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDE112004F for ; Thu, 6 Jun 2019 05:07:22 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 15EE12207F for ; Thu, 6 Jun 2019 08:07:21 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 06 Jun 2019 08:07:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=M7S7siD s4ZH8g3hvSldBcLv5zL5tjBRFfXMk16G7w9o=; b=NeDJ8vnEfvfSjBHrM2Kj5bv LPiX8CVc6uwmr3rGFpu2SZfnrnGL7xd4ptFRcl10e2Cy5PcZamIliyvtOTHbBe6n HAjaTMq1vJ7O3AfRI+8oar8DEMCveOi72M0jijRSamzbfC9cH6Fivgqb23D0ftC5 mKaVjYaeKWV1f5q5JMFZ+c0IjT9v4bjlrKT7zb/bTc8UkD7F2bFTMmuJ4iXAPSYo eHpEB6DCHwn5Z5jsC3T4gcQr/EXYIEjzmbtOZdy9KxwY/sEWVb3QTa1Uyaxf2+6W bEP4501PvV7wNvNoa9YbAhFNJt8ZQ1VJBo/4xsJcW3yd5a4EwyIbpmjhwChdLuA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=M7S7si Ds4ZH8g3hvSldBcLv5zL5tjBRFfXMk16G7w9o=; b=GeUgbcFDUG6WTuCzsuAbo0 IXRWJdqhB/Jc/641nM2YvIrDrNL5xH3orbsdZCxE/9UHN8/ks4+kx0SNfaoE66oJ nvkGBfvEXRX0Ys5Co+2jnrNwGS4CTfDSsiL523UognxxDD0KZiR5rcdTiO/I6VMT 5RPFN5nVo7lr3QAej6JRoeZbetxEvF8oBDojGn6i1EADtwoJd2dXH9S9uxx0Ambf utRgU2T6fEPC381xox64bc+dU5uN4/LK43Fb551keLNYgfzbn0L6zg/JBDzHUfsF UIdYr5wVl+JCPE0qu9orvq+XAmntVjgL2JZoYO2zknq8mZgBmWN/C1A63CD+95sg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9A1581801DD; Thu, 6 Jun 2019 08:07:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-662-gd87dd0f-fmstable-20190606v1 Mime-Version: 1.0 Message-Id: <367309f8-a04d-48fa-8c9f-0ce04dfbd07a@www.fastmail.com> In-Reply-To: References: Date: Thu, 06 Jun 2019 13:07:08 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=88af2d101cbe4afbae34315b5252de7d Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 12:07:24 -0000 --88af2d101cbe4afbae34315b5252de7d Content-Type: text/plain On Thu, Jun 6, 2019, at 1:04 PM, Marten Gajda wrote: > I think we should advise against that and make clear that this is not meant to increase the precision of times in iCalendar, but merely to preserve it. Agreed. > Btw, how do we cope with unaware clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override I'd say the JSCalendar implementation should leniently treat this as an override. --88af2d101cbe4afbae34315b5252de7d Content-Type: text/html
On Thu, Jun 6, 2019, at 1:04 PM, Marten Gajda wrote:

I think we should advise against that and make clear that this is not meant to increase the precision of times in iCalendar, but merely to preserve it.


Agreed.

Btw, how do we cope with unaware clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override


I'd say the JSCalendar implementation should leniently treat this as an override.

--88af2d101cbe4afbae34315b5252de7d-- From nobody Thu Jun 6 05:56:02 2019 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 806D212007C for ; Thu, 6 Jun 2019 05:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=fastmail.com header.b=TNV445Uz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3y+t5Tom 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 BYAhJsmzr5QD for ; Thu, 6 Jun 2019 05:55:58 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A91120018 for ; Thu, 6 Jun 2019 05:55:58 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3D2B72221E; Thu, 6 Jun 2019 08:55:57 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute5.internal (MEProxy); Thu, 06 Jun 2019 08:55:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=cjpXpST+uzwIo3boRDQezse3SAnNKTR TStgYIQtI/Yc=; b=TNV445UzEcXMWWmva35QOcHF6E5vIe6Bp61+x97VQTLTNrq 205ttxC2nH0PM1YgNuGFtkC33MoYZ+StmaFESpagJEk3qTekfUWiyJbwZS4bZNnu I8HIaqx7qqs/N6J0oNRzUsFyf+Wi8Osaf5sZdcDHqEICVjvnu78OCNGsLe08/GiY VYujbIbnZholpXqHYQa/dZ1A7cwnDxALkDANsmqeq7IiBw/tdK7GIP/QGfp43Xnn 7434Sucs3TpAuFfbp7gLSGekuaSfPs9nYTnbH05AoAKNBCaMhEOaGpX+c1h4foWD 7P65xLKaMLZESUusQX3Y1zTxrMxaBADA/oGxggw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=cjpXpS T+uzwIo3boRDQezse3SAnNKTRTStgYIQtI/Yc=; b=3y+t5TomYErnBQ2Me90MK+ fVt7PueeXACEGU4fqQ8ZoIA8THuI1zZkfuIZklQ9ioPGsuhzKiPIGWwUyYPw6cBX pW0eJ5Mf3/ASNvTW0BNX11MROoqZqOEZx8HXjn0aIxB87QFJmf5Hok5Eo42NU9de 2X7bShijdR8geDPKaRodU++RKG9pfevqR+PMGxW1TRVxq53gaN0pj67hcIXamxEh VxFsOZnlq25NzSJ0JSMpggRG/XDdl9OlH74yCoq0NcKOvtT8kKPLhlwqgendA+06 0Iho2ReTgxL7PhZh/EENcIHsW5VfA2dpAWtDlym+vEKnhJuMnGpMg3yt3pctv8Jg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfmvghn ucfouhhrtghhihhsohhnfdcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuff homhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgt hhesfhgrshhtmhgrihhlrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 866161801F3; Thu, 6 Jun 2019 08:55:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-662-gd87dd0f-fmstable-20190606v1 Mime-Version: 1.0 Message-Id: <3edec26e-1b87-4f30-97c7-d0a18cda615e@www.fastmail.com> In-Reply-To: References: Date: Thu, 06 Jun 2019 08:55:56 -0400 From: "Ken Murchison" To: "Marten Gajda" , calsify@ietf.org Content-Type: multipart/alternative; boundary=41d16161907445369d20f0fc5229880a Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 12:56:02 -0000 --41d16161907445369d20f0fc5229880a Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable As a related topic, a libical user/developer submitted a PR to add milli= second precision to time values. I haven=E2=80=99t committed it because = it simply changes the DATETIME values which certainly isn=E2=80=99t back= wards compatible. I suggested a new VALUE type but even that isn=E2=80=99= t compatible with unaware clients.=20 Regardless, there does appear to be *some* desire to have fractional sec= onds support in iCalendar.=20 -- Kenneth Murchison Cyrus Development Team FastMail US LLC murch@fastmaileam.com On Thu, Jun 6, 2019, at 8:04 AM, Marten Gajda wrote: > Is this parameter is meant to preserve the fractional seconds for roun= d-trips or are iCalendar clients encouraged to use the value? > I mean, would a client that's aware of X-FRACSEC have to match RECURRE= NCE-IDs ,RDATES and EXDATES taking the fractional seconds into account?=20= > I think we should advise against that and make clear that this is not = meant to increase the precision of times in iCalendar, but merely to pre= serve it. > Btw, how do we cope with unaware clients doing partial updates? I.e. a= client which is not aware of X-FRACSEC adds a new recurrence-override (= not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSC= alendar, this would result in an additional instance instead of an overr= ide. > Marten > Am 06.06.19 um 13:49 schrieb Robert Stepanek: >> It just occurred to me that the current JSCalendar RFC draft ambiguou= sly defines if fractional seconds are allowed in the LocalDate time type= . >>=20 >> To be clear: we intend to allow fractional seconds in the start prope= rty (and any other LocalDate property). The next version of the RFC draf= t will define this more clearly. >>=20 >> Unfortunately, fractional second date-times and durations can not be = round-tripped out of the box with iCalendar. We will define an iCalendar= extension parameter in the informational guide for mapping iCalendar an= d JSCalendar (draft-ietf-calext-jscalendar-icalendar): >> * X-FRACSEC of value type INTEGER >> * This parameter MAY be set on iCalendar properties of type DATE-TIM= E or DURATION. It MUST NOT be set more than once per property. >> * The value of this parameter defines the fractional seconds of the = DATE-TIME or DURATION type. >> * This will allow iCalendar implementations not being aware of this = extension parameter to display the time value "good enough" with second = precision. >>=20 >> Please let me know if you prefer another approach. >>=20 >> Cheers, >> Robert >>=20 >> _______________________________________________ calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >>=20 > --=20 Marten Gajda CEO dmfs GmbH Schandauer Stra=C3=9Fe 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 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify >=20 --41d16161907445369d20f0fc5229880a Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
As a relat= ed topic, a libical user/developer submitted a PR to add millisecond pre= cision to time values. I haven=E2=80=99t committed it because it simply = changes the DATETIME values which certainly isn=E2=80=99t backwards comp= atible. I suggested a new VALUE type but even that isn=E2=80=99t compati= ble with unaware clients. 

Regardless,= there does appear to be *some* desire to have fractional seconds suppor= t in iCalendar. 

--
Kenneth Murchiso= n
Cyrus Development Team
FastMail US LLC
m= urch@fastmaileam.com

<= div>

On Thu, Jun 6, 2019, at 8:04 AM, Marte= n Gajda wrote:

Is this p= arameter is meant to preserve the fractional seconds for round-trips or are iCalendar clients encouraged to use the value?<= br>

I mean, would a client that's aware of X-FRACSEC have to match= RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds into account?

I think we should advise against that and= make clear that this is not meant to increase the precision of times in iCalendar, but merely to preserve it.

Btw, how do we cope with unaware = clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override.

Marten

Am 06.06.19 um 13:49 schrieb Robert Stepanek:
It just occurred to m= e that the current JSCalendar RFC draft ambiguously defines if fractional seconds are allowed in the LocalDate time type.

To be clear: w= e intend to allow fractional seconds in the start property (and any other LocalDate property). The next version of the RFC draft will define this more clearly.

Unfortunately, fractional second date-times and dur= ations can not be round-tripped out of the box with iCalendar. We will define an iCalendar extension parameter in the informational guide for mapping iCalendar and JSCalendar (draft-ietf-calext-jscalendar-icalendar):
  • X-FRA= CSEC of value type INTEGER
  • This parameter MAY be set on iCal= endar properties of type DATE-TIME or DURATION. It MUST NOT be set more than once per property.
  • The value of this parameter defines the = fractional seconds of the DATE-TIME or DURATION type.
  • This will allow= iCalendar implementations  not being aware of this extension parameter to display the time value "good enough" with second precision.

Please let me know if you prefer another approach.

<= /div>
Cheers,
Robert

_______________________________________=
________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

--=20=

Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 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
________________________________= _______________
calsify mailing list
calsify= @ietf.org
https://www.ietf.org/mailman/listinfo/calsify


--41d16161907445369d20f0fc5229880a-- From nobody Thu Jun 6 06:07:36 2019 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 AFB7B120099 for ; Thu, 6 Jun 2019 06:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=QH2ZC5jv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d/tFDxQP 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 JX6vfyOhjthO for ; Thu, 6 Jun 2019 06:07:32 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F334A12006D for ; Thu, 6 Jun 2019 06:07:31 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E36E221ED6 for ; Thu, 6 Jun 2019 09:07:30 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 06 Jun 2019 09:07:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=wlW2Toc cRJfrFjNQ4isCW4eSjTRoI/D6sr8hj7og/eA=; b=QH2ZC5jv1aUE08VrahWg3or TKuONK0Rnp3diCnlrQbG1j7WZ9gUqs6McCSTmILF4Oitd9Aiiaipgx9weoOlG0GT uVD+Vkh3q5Gnid0FUFvtnEuSw0NiiDvbdX2R5bsN3WTFzYyCR3mkGuN3SoAsZrpH RIohmwQ3kpuJUVhE5jZ4juecxyasnOSg/TO50HqonfK7W9K8mnU/De3UlazsXe24 Rok8H2R+p/FKRnRsI6a93VOdE8XwT+ik+qTymUmr3pBbwYgg16UZn7igxTJeizCv YlTgVqq929gOpYI+hFKOWV4dlFP2kZJBbvuWRAncUieYfjjayKFMLeO+LaNrHPA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=wlW2To ccRJfrFjNQ4isCW4eSjTRoI/D6sr8hj7og/eA=; b=d/tFDxQP0xoVHkTRFdgKM5 05zJsfOBDRGgDSxNFYhr6cWL5+PTHuV+Ap5CFm7E9PeCfAD1SxcRC+GhqQdPtCwb 5FKdH7t7dHAA2Kzg7pwr1gTNeRwhftz7SxshHg9LsjsotvN5P4bwh05FUPQz0G/I 5OwHExwfiuMSG8DWnHcSjb4WPYEwXXQon4VCRyctXB/J2fiCqFY0aBUtVCDdR1BZ R3NAD1QgUreblbNgm42w7LJ4QSGXmXFV1rzDxJK0VRIJOXIu0N34GMno4F4snVr/ NKp+GRQ2ozqMv0m0XWbEi34cJQaEzV/sKJdXxqB2OoUpYDCEBa4Ii+htM1H6WUvg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggedgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrgh enucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 527A01801F3; Thu, 6 Jun 2019 09:07:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-662-gd87dd0f-fmstable-20190606v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <3edec26e-1b87-4f30-97c7-d0a18cda615e@www.fastmail.com> References: <3edec26e-1b87-4f30-97c7-d0a18cda615e@www.fastmail.com> Date: Thu, 06 Jun 2019 14:07:30 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a864ba3e22bc494a810a4d141b012e2c Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 13:07:35 -0000 --a864ba3e22bc494a810a4d141b012e2c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable This is a draft specification, happy about any input: 2.1. FRACSEC parameter Parameter name: FRACSEC Purpose: This parameter is used to define fractional seconds for time values and durations. It is meant to preserve time precision on time values and duration with sub-second precision, without increasing the time value range within iCalendar. Description: This parameter MAY be specified on properties of type DATE-TIME or DURATION. The integral part of the float value MUST be zero. The value MUST NOT be negative. iCalendar implementations MAY ignore this parameter in date time arithmetic. Implementations MUST ignore presence of the FRACSEC parameter on RECURRENCE-ID properties when determining recurrence overrides. If present on a RECURRENCE-ID property, its value MUST match the FRACSEC parameter value on the DTSTART property. Format Definition: This parameter is defined by the following notation: fracsec-param =3D float Example: DTSTART;FRACSEC=3D0.03:20190605T133015 On Thu, Jun 6, 2019, at 1:56 PM, Ken Murchison wrote: > As a related topic, a libical user/developer submitted a PR to add mil= lisecond precision to time values. I haven=E2=80=99t committed it becaus= e it simply changes the DATETIME values which certainly isn=E2=80=99t ba= ckwards compatible. I suggested a new VALUE type but even that isn=E2=80= =99t compatible with unaware clients.=20 >=20 > Regardless, there does appear to be *some* desire to have fractional s= econds support in iCalendar.=20 >=20 > -- > Kenneth Murchison > Cyrus Development Team > FastMail US LLC > murch@fastmaileam.com >=20 >=20 >=20 > On Thu, Jun 6, 2019, at 8:04 AM, Marten Gajda wrote: >> Is this parameter is meant to preserve the fractional seconds for rou= nd-trips or are iCalendar clients encouraged to use the value? >> I mean, would a client that's aware of X-FRACSEC have to match RECURR= ENCE-IDs ,RDATES and EXDATES taking the fractional seconds into account?= =20 >> I think we should advise against that and make clear that this is not= meant to increase the precision of times in iCalendar, but merely to pr= eserve it. >> Btw, how do we cope with unaware clients doing partial updates? I.e. = a client which is not aware of X-FRACSEC adds a new recurrence-override = (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JS= Calendar, this would result in an additional instance instead of an over= ride. >> Marten >> Am 06.06.19 um 13:49 schrieb Robert Stepanek: >>> It just occurred to me that the current JSCalendar RFC draft ambiguo= usly defines if fractional seconds are allowed in the LocalDate time typ= e. >>>=20 >>> To be clear: we intend to allow fractional seconds in the start prop= erty (and any other LocalDate property). The next version of the RFC dra= ft will define this more clearly. >>>=20 >>> Unfortunately, fractional second date-times and durations can not be= round-tripped out of the box with iCalendar. We will define an iCalenda= r extension parameter in the informational guide for mapping iCalendar a= nd JSCalendar (draft-ietf-calext-jscalendar-icalendar): >>> * X-FRACSEC of value type INTEGER >>> * This parameter MAY be set on iCalendar properties of type DATE-TI= ME or DURATION. It MUST NOT be set more than once per property. >>> * The value of this parameter defines the fractional seconds of the= DATE-TIME or DURATION type. >>> * This will allow iCalendar implementations not being aware of this= extension parameter to display the time value "good enough" with second= precision. >>>=20 >>> Please let me know if you prefer another approach. >>>=20 >>> Cheers, >>> Robert >>>=20 >>> _______________________________________________ calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>>=20 >> --=20 Marten Gajda CEO dmfs GmbH Schandauer Stra=C3=9Fe 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 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >>=20 >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify >=20 --a864ba3e22bc494a810a4d141b012e2c Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
This = is a draft specification, happy about any input:

=
2.1.  FRACSEC parameter

   Parameter name:  FRACSEC
<= div>
   Purpose:  This parameter is u= sed to define fractional seconds for
   &nb= sp;  time values and durations.  It is meant to preserve time = precision
      on time values an= d duration with sub-second precision, without
  =     increasing the time value range within iCalendar.
=

   Description:  Thi= s parameter MAY be specified on properties of type
 &= nbsp;    DATE-TIME or DURATION.  The integral part o= f the float value MUST
      be z= ero.  The value MUST NOT be negative.  iCalendar
      implementations MAY ignore this paramete= r in date time arithmetic.
      = Implementations MUST ignore presence of the FRACSEC parameter on
      RECURRENCE-ID properties when dete= rmining recurrence overrides.
    &nbs= p; If present on a RECURRENCE-ID property, its value MUST match the
<= /div>
      FRACSEC parameter value on the = DTSTART property.

   F= ormat Definition:

   T= his parameter is defined by the following notation:
<= br>
        &nbs= p;           &nbs= p;           &nbs= p;      fracsec-param =3D float
<= div>
   Example:  DTSTART;FRACSEC=3D0= .03:20190605T133015


On Thu, Jun 6, 2019, at 1:56 PM, Ken Murchison wrote:
As a related topic, a libic= al user/developer submitted a PR to add millisecond precision to time va= lues. I haven=E2=80=99t committed it because it simply changes the DATET= IME values which certainly isn=E2=80=99t backwards compatible. I suggest= ed a new VALUE type but even that isn=E2=80=99t compatible with unaware = clients. 

Regardless, there does appea= r to be *some* desire to have fractional seconds support in iCalendar.&n= bsp;

--
Kenneth Murchison
Cyrus Development Team
FastMail US LLC
murch@fastmaileam.com



On Thu, Jun 6, 2019, at 8:04 A= M, Marten Gajda wrote:
<= p>Is this parameter is meant to preserve the fractional seconds for round-trips or are iCalendar clients encouraged to use the value?<= br>

I mean, would a client that's aware of X-FRACSEC have to match= RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds into account?

I think we should advise against that and= make clear that this is not meant to increase the precision of times in iCalendar, but merely to preserve it.

Btw, how do we cope with unaware = clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override.

Marten

Am 06.06.19 um 13:49 schrieb Robe= rt Stepanek:
It just occurred to m= e that the current JSCalendar RFC draft ambiguously defines if fractional seconds are allowed in the LocalDate time type.

To be clear: w= e intend to allow fractional seconds in the start property (and any other LocalDate property). The next version of the RFC draft will define this more clearly.

Unfortunately, fractional second date-times and dur= ations can not be round-tripped out of the box with iCalendar. We will define an iCalendar extension parameter in the informational guide for mapping iCalendar and JSCalendar (draft-ietf-calext-jscalendar-icalendar):
  • X-FRA= CSEC of value type INTEGER
  • This parameter MAY be set on iCal= endar properties of type DATE-TIME or DURATION. It MUST NOT be set more than once per property.
  • The value of this parameter defines the = fractional seconds of the DATE-TIME or DURATION type.
  • This will allow= iCalendar implementations  not being aware of this extension parameter to display the time value "good enough" with second precision.

Please let me know if you prefer another approach.

<= /div>
Cheers,
Robert

____________________________________=
___________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

--=
=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 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
________________________________= _______________
calsify mailing list
calsify= @ietf.org
https://www.ietf.org/mailman/listinfo/calsify


_________________= ______________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/list= info/calsify


= --a864ba3e22bc494a810a4d141b012e2c-- From nobody Thu Jun 6 08:37:49 2019 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 E00CC120124 for ; Thu, 6 Jun 2019 08:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YxwiO2eFg9XT for ; Thu, 6 Jun 2019 08:37:44 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 18129120020 for ; Thu, 6 Jun 2019 08:37:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8293B300B9F814; Thu, 6 Jun 2019 11:37:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6_TlEkVBVQx; Thu, 6 Jun 2019 11:37:43 -0400 (EDT) Received: from [172.16.111.68] (unknown [144.178.28.141]) by daboo.name (Postfix) with ESMTPSA id 9834A300B9F804; Thu, 6 Jun 2019 11:37:42 -0400 (EDT) Date: Thu, 06 Jun 2019 08:37:40 -0700 From: Cyrus Daboo To: Robert Stepanek , calsify@ietf.org Message-ID: <2482E64E5B84338407DE3EB0@cyrus.local> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2343 Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 15:37:46 -0000 Hi Robert, Some initial thoughts: --On June 6, 2019 at 2:07:30 PM +0100 Robert Stepanek wrote: > Purpose: This parameter is used to define fractional seconds for > time values and durations. It is meant to preserve time precision > on time values and duration with sub-second precision, without > increasing the time value range within iCalendar. I think we should have a strong statement here, something equivalent to: FRACSEC MUST NOT be used in date-time calculations or comparisons in iCalendar On the other hand, if your intent is that it is used in such calculations, then you are going to need much more detailed language on how to handle cases where it is missing on things like RECURRENCE-ID, RDATE, EXDATE etc. > Description: This parameter MAY be specified on properties of type > DATE-TIME or DURATION. The integral part of the float value MUST Can this also be used with value type TIME? How will PERIOD be handled? Right now that is only used in iCalendar FREEBUSY and RDATE. Looks like JSCalendar does not support a "period" on its equivalent of RDATE (something that might need to be called out in the mapping document if not already there). Also, JSCalendar does not seem to support an equivalent to VFREEBUSY, which may be a big barrier to adoption by "enterprise" calendaring system which typically do use free busy a lot. > be zero. The value MUST NOT be negative. iCalendar > implementations MAY ignore this parameter in date time arithmetic. > Implementations MUST ignore presence of the FRACSEC parameter on > RECURRENCE-ID properties when determining recurrence overrides. > If present on a RECURRENCE-ID property, its value MUST match the > FRACSEC parameter value on the DTSTART property. In components other than VEVENT, a DTSTART is not required to be present when RECURRENCE-ID is present (e.g. VTODO with just a DUE). So this should probably be re-worded, something like: its value MUST match the FRACSEC parameter value on the DATE-TIME property that defines the reference point for the recurring instances. Should FRACSEC be allowed on an RRULE containing a DATE-TIME UNTIL value? Looks like JSCalendar allows fraction seconds on UNTIL. Is there any need to use fraction seconds in an RRULE BY... rule? (I hope not). -- Cyrus Daboo From nobody Thu Jun 6 08:56:32 2019 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 04CBA12018A for ; Thu, 6 Jun 2019 08:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=K0kz/5pp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a7u5e43d 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 ZW7NT61QU5DJ for ; Thu, 6 Jun 2019 08:56:23 -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 7FC4612015D for ; Thu, 6 Jun 2019 08:56:23 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9892C21C48 for ; Thu, 6 Jun 2019 11:56:22 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 06 Jun 2019 11:56:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=tC+5nLuI5DjugapIqTlmkWvls82jTqM33zjyVYo yjfc=; b=K0kz/5ppaiOMCjMR1OoGdL1wZoe6RexydBZNTh1jJfKJ61vTyIBy9TG srQ8Ao0WY4Cst6QBCf2DeFJ2HRiyRhLnF/AgSgaSvCpR6WpA+ZSNHpgLus1ZiBJL 42PgS+cbf0Z/TY9bNPimZKH7OG0snJI5V84Pg32GlUPBBr0hubHunuNLKLVUu4AC 5o2aCt9xV1ufT5OLGEZc7gzuoJlJ2Io5NAlOLA4xf1coX53j0ehxVwZG1KxMDnps lsMvrOPzNIeXxRVaLWR4C1NLWKgl7EJGkJGrGZeD3VA3BS/zxIXRW9GIFyvXqAYq IOjTyBfPqPPko54T9uYkgbKWzdlcPRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=tC+5nLuI5DjugapIqTlmkWvls82jT qM33zjyVYoyjfc=; b=a7u5e43dbcN3dhJrwZVTXe3N+YxuJWZE3prpEX2objNQp udZnuN8weaGJhv6NCfEMjfpL8EqSsB6Cj/haYuFqyCAApSq7qWxGfM2nHNlansQq LkFc1v6jABWnR55X5SIl7yEzDf4qQEktLA9F8nxY99kVJa32NF5Dq6o2zuL+35Nc JU5iS4sDJOTmK6Q5qL6m+00GWJRYd8xJiyr+UEzy5WMPLsmEEZ2THvsjAx5C4wQQ dufiz7BLsUb1RWrIZGFOSuVy1R48Ean7G3tbhMO7OvUB7saqnz3v23je65Fll/su wn+41tHqCFS0q6kfl9GPt9JbrwedyEWN1CHTl8dbg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrsh htohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E4CAD1801FB; Thu, 6 Jun 2019 11:56:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-662-gd87dd0f-fmstable-20190606v1 Mime-Version: 1.0 Message-Id: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> Date: Thu, 06 Jun 2019 16:56:21 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=107ff695754244bdb98b3a427506082c Archived-At: Subject: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 15:56:31 -0000 --107ff695754244bdb98b3a427506082c Content-Type: text/plain One of the repeatedly discussed topics in JSCalendar is how to model all-day events. Specifically, variants of the following uses repeatedly come up, where the current JSCalendar model seems not to be adequate: * Calendar users create an event starting e.g. 8am and ending 7pm, but want to view this an all-day event in their UI. The current model misses a flag to express this, as the isAllDay property is not appropriate to indicate the user intention. * Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI. In both cases, developers thought to use the isAllDay property to express a user intention, but came they learn they couldn't. This is reason enough to revisit that part of the specification and discuss alternatives. *Currently*: * Any event MUST define a start property value in the form "YYYY-MM-DDTHH:MM:SS[.DIGITS]" * An all-day event: * MUST have the isAllDay property set to "true" * MUST NOT have a non-zero time in the start and duration property values * MUST NOT define a time zone * Any other event: * MUST have the isAllDay property set to "false" * MAY define non-zero time in start, duration * MAY set a timeZone. * This allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME, UTC DATE-TIME. *Alternative*: * The isAllDay boolean property gets removed. * A new showAsAllDay boolean defines how the user intends to view this event. Setting this property does not have any implications on the allowed values in the event time properties. * The start, duration, timeZone properties and their recurrence overrides can all can be defined independently. The recurrenceRule{until} property also can be defined independently. * It is up to implementations to convert this time model to iCalendar. Most probably: * an event with zero time in start, duration, until and no time zone will be converted DATE value types * an event with no time zone will be converted to a local DATE-TIME without TZID * otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME What do you think? Did we miss something? Cheers, Robert --107ff695754244bdb98b3a427506082c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
= One of the repeatedly discussed topics in JSCalendar is how to model all= -day events.

Specifically, variants of the = following uses repeatedly come up, where the current JSCalendar model se= ems not to be adequate:

  • Calendar u= sers create an event starting e.g. 8am and ending 7pm, but want to view = this an all-day event in their UI. The current model misses a flag to ex= press this, as the isAllDay property is not appropriate to indicate the = user intention.
  • Calendar users want to set their calendar on= their birthday, when they only would like to set it for the complete da= y in their usual time zone. They still want it to show up as an all-day = event in their UI.

In both cases, devel= opers thought to use the isAllDay property to express a user intention, = but came they learn they couldn't.

This is = reason enough to revisit that part of the specification and discuss alte= rnatives.

Currently:
=
  • Any event MUST define a start property value in the form "YYYY-M= M-DDTHH:MM:SS[.DIGITS]"
  • An all-day event:
    • MU= ST have the isAllDay property set to "true"
    • MUST NOT have a = non-zero time in the start and duration property values
    • MUST= NOT define a time zone
  • Any other event:
      • MUST have the isAllDay property set to "false"
    • MAY define = non-zero time  in start, duration
    • MAY set a timeZone.
  • This allows to model iCalendar DATE, local DATE-TIME, fl= oating DATE-TIME, UTC DATE-TIME.

Alt= ernative:
  • The isAllDay boolean property gets remove= d.
  • A new showAsAllDay boolean defines how the user intends t= o view this event. Setting this property does not have any implications = on the allowed values in the event time properties.
  • The star= t, duration, timeZone properties and their recurrence overrides can all = can be defined independently. The recurrenceRule{until} property also ca= n be defined independently.
  • It is up to implementations to c= onvert this time model to iCalendar. Most probably:
    • an e= vent with zero time in start, duration, until and no time zone will be c= onverted DATE value types
    • an event with no time zone will be= converted to a local DATE-TIME without TZID
    • otherwise it wi= ll be a DATE-TIME with TZID or UTC DATE-TIME

=
What do you think? Did we miss something?

<= /div>
Cheers,
Robert


=



--107ff695754244bdb98b3a427506082c-- From nobody Thu Jun 6 09:00:50 2019 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 4631912012E for ; Thu, 6 Jun 2019 09:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=dtSGOoGz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A6tcjm5m 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 Qew38S5Ij8ik for ; Thu, 6 Jun 2019 09:00:46 -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 BFB3B120125 for ; Thu, 6 Jun 2019 09:00:37 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D2A3E22274; Thu, 6 Jun 2019 12:00:36 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 06 Jun 2019 12:00:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=EgPiw8F QoEJkXhGt/IK7wby4g08NK32yChTyviUuKlM=; b=dtSGOoGzCNcT6clFYLyYcCP rqZJ+60yDAZtId3UnkHhykcjPIrxxDVbxpWgCT0sZh/mV059u0oNe0TtrQVWNt5X W+ITBLGWqQ2QPRalVx4Al/byoYkM+M2qhLo80vgU/CfJCBWMEDXgEwwXkxcZgwga OtVidytexGky2CY5FXQAyuPTqv93VYZasPo+MAmkHcXcvqp7t3BkVt/htNRkK6AQ qPNvcA0yZ/9eOtUy/d5VIvyDv0YrJ0yIIiQhGwyLEGJpphQzV+YSMC2vI10tx9rF RpQimI54yBsDFL37VbINqJLcwNGV1977Zc1pGymK8YA2yNJHgBP14PyGMTuFLhw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=EgPiw8 FQoEJkXhGt/IK7wby4g08NK32yChTyviUuKlM=; b=A6tcjm5mwDVROtAYPf5LQk aCNDlR+QhUSVsqCQnF62VV1vvaDd7yFDFxquQOUmmPaZwl5Xdcv6BxJdNZJW4MrU Tq9i0DBoh9lS+aF1t1Xo89PLDyx54kang5YlAwrV9e9ALDH/2TDZzfFeyqAksHku s/t+s1O8WwxKscV1lC1SUi+PkWpNh81RR7GazxFWSU2k0z7Uti6b1PsLV3VNF6CR ITEU6drjjL6tzKHpauO2mJumnUwK/xuGJqqIu0TuoKikIiNKsVO7Zz7jrm9QU93m 9L5as6BTkjujc5q2gHj09+JkDv6s9uVL2qMeftLROayqkhTEhj/5ukU6K2MyDAsw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdftohgs vghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggr mhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A80411801FB; Thu, 6 Jun 2019 12:00:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-662-gd87dd0f-fmstable-20190606v1 Mime-Version: 1.0 Message-Id: <251f234b-7a41-4eda-bca7-ea244de97c07@www.fastmail.com> In-Reply-To: <2482E64E5B84338407DE3EB0@cyrus.local> References: <2482E64E5B84338407DE3EB0@cyrus.local> Date: Thu, 06 Jun 2019 16:58:28 +0100 From: "Robert Stepanek" To: "Cyrus Daboo" , calsify@ietf.org Content-Type: multipart/alternative; boundary=1fe466f6a89a41e3b1a68fc99db6a243 Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 16:00:48 -0000 --1fe466f6a89a41e3b1a68fc99db6a243 Content-Type: text/plain Hi Cyrus, thanks for you input and greetings from Bedford from the CalConnect crowd :) On Thu, Jun 6, 2019, at 4:37 PM, Cyrus Daboo wrote: > FRACSEC MUST NOT be used in date-time calculations or comparisons in > iCalendar Yes, that's better. > > Description: This parameter MAY be specified on properties of type > > DATE-TIME or DURATION. The integral part of the float value MUST > > Can this also be used with value type TIME? We currently don't need it defined for TIME for JSCalendar conversion. But I guess it would do no harm. I don't want to define this for PERIOD, we don't have a use case for it and. I'll take note of VFREEBUSY, but it will go into its own extension RFC. > In components other than VEVENT, a DTSTART is not required to be present > when RECURRENCE-ID is present (e.g. VTODO with just a DUE). So this should > probably be re-worded, something like: > > its value MUST match the FRACSEC parameter value on the DATE-TIME > property that defines the reference point for the recurring instances. Great, thanks. > Should FRACSEC be allowed on an RRULE containing a DATE-TIME UNTIL value? > Looks like JSCalendar allows fraction seconds on UNTIL. It'd be great to add e.g. UNTIL-FRACSEC to RRULE. But from experience client implementations tend to just ignore unknown parameters, whereas they fail for unknown RRULE fields. I'm not sure how we will handle that. > Is there any need to use fraction seconds in an RRULE BY... rule? (I hope > not). None that I know of. Cheers, Robert --1fe466f6a89a41e3b1a68fc99db6a243 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Cyrus,<= br>

thanks for you input and greetings from Bed= ford from the CalConnect crowd :)

On Thu, J= un 6, 2019, at 4:37 PM, Cyrus Daboo wrote:
    FRACSEC MUST NOT be used in date= -time calculations or comparisons in 
iCalendar

Yes, that's better.
<= br>
>  Description= : This parameter MAY be specified on properties of type
&g= t;  DATE-TIME or DURATION. The integral part of the float value MUS= T

Can this also be used with value type TIM= E?

We currently don't need it = defined for TIME for JSCalendar conversion. But I guess it would do no h= arm. I don't want to define this for PERIOD, we don't have a use case fo= r it and. I'll take note of VFREEBUSY, but it will go into its own exten= sion RFC.

In components other than VEVENT, a DTSTART is not required to be pres= ent 
when RECURRENCE-ID is present (e.g. VTODO with j= ust a DUE). So this should 
probably be re-worded, so= mething like:

    its value = MUST match the FRACSEC parameter value on the DATE-TIME
&n= bsp;   property that defines the reference point for the recur= ring instances.

Great, thanks.=

Should= FRACSEC be allowed on an RRULE containing a DATE-TIME UNTIL value? = ;
Looks like JSCalendar allows fraction seconds on UNTIL.<= br>

It'd be great to add e.g. UNTI= L-FRACSEC to RRULE. But from experience client implementations tend to j= ust ignore unknown parameters, whereas they fail for unknown RRULE field= s. I'm not sure how we will handle that.

Is there any need to use fraction seco= nds in an RRULE BY... rule? (I hope 
not).
<= /blockquote>

None that I know of.

<= /div>
Cheers,
Robert
--1fe466f6a89a41e3b1a68fc99db6a243-- From nobody Thu Jun 6 09:08:09 2019 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 281D7120125 for ; Thu, 6 Jun 2019 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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=fastmail.com header.b=foZAzzl4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IHrw+8x4 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 EPNTXFVZtxRC for ; Thu, 6 Jun 2019 09:08:06 -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 52B9C120124 for ; Thu, 6 Jun 2019 09:08:06 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 5A1B5221E5 for ; Thu, 6 Jun 2019 12:08:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 06 Jun 2019 12:08:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=5iGc8fP1NwV2AUl02CtqiPn3RNl SU77Ihm/Psn43exU=; b=foZAzzl4kz+2uULxlHzJLLFDTc/U9sv/hDaOWLPe0Io mRodE3vmqh9DTGYatphgpbYyYsJnpOCyuclqdRZh/pv5ROJRq/bE+FPduwTAnpAJ J5IGfnT7ssJGW2ZL4TO/9qFcGgSMdSCvawXdJZoV+xF2rwCaOoAl8swO2f82tq6n Y4yNP/hGbQrzy7096yVBQG32HbX1YYF9FLMlEkTbdNCQCokSFLYXdo6AMgFCfrhg mBH9nIGewG/8YMACSuz6FsIbC4vTmX+d1ZI1Q6YiAK3A1ZXoF9gyMVkrZFQBStRZ /bO5adXeDKNn8j63iB6T9gVhoJwh2AbmLB/QAKJjVoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5iGc8f P1NwV2AUl02CtqiPn3RNlSU77Ihm/Psn43exU=; b=IHrw+8x4LcRDGDQECXG0mD yxshFaqVt9L0JgehchfkBl5k0jj1fMtu9aCFfZQM0XKRmY3BQklgnlokZ5o4gWDs 5jKivL7yTRWEfHf0WJ0r3FYuQyMi9Ni7pWFvTrMUuBXkszKLej0NOHZPjZiOChvu /RaQI+KEo1rjOkyuJEbzb9ldFmRyCkD8aPUdFDo85f93sLgv3rDNaNUpsSIKydWx foo4QAdNuc9PGy5NrqfIWHDnnmq0mOURLBU3WDuA9BCUJIgoYDOhPfnw5NsdbKPI h3Qe2Oj58Lrt+TFSI9EknHEeAZ0rZHs4J1WTBx7RYhif9xX4hpiCQbVB4PQjyRFg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhfhokffffgggjggtsehmtd erredtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucfkphepjeegrdejjedrkeehrddvhedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomhenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 8B36D80071 for ; Thu, 6 Jun 2019 12:08:04 -0400 (EDT) To: calsify@ietf.org References: <2482E64E5B84338407DE3EB0@cyrus.local> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Thu, 6 Jun 2019 12:08:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2482E64E5B84338407DE3EB0@cyrus.local> Content-Type: multipart/mixed; boundary="------------CCF575BAD97A1C35F798017F" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 16:08:08 -0000 This is a multi-part message in MIME format. --------------CCF575BAD97A1C35F798017F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 6/6/19 11:37 AM, Cyrus Daboo wrote: > > Is there any need to use fraction seconds in an RRULE BY... rule? (I > hope not). FWIW, the libical PR includes FREQ=MSEC (millisecond frequency). -- Ken Murchison Cyrus Development Team FastMail US LLC --------------CCF575BAD97A1C35F798017F Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------CCF575BAD97A1C35F798017F-- From nobody Fri Jun 7 08:43:22 2019 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 3EC8E120260; Fri, 7 Jun 2019 08:43:14 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155992219411.20220.15511434849780424587@ietfa.amsl.com> Date: Fri, 07 Jun 2019 08:43:14 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-00.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 15:43:15 -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 : Calendar subscription upgrades Author : Michael Douglass Filename : draft-ietf-calext-subscription-upgrade-00.txt Pages : 15 Date : 2019-06-07 Abstract: This specification introduces an approach to allow subscribers to calendar feeds to upgrade to a more performant protocol. This specification updates [RFC5545] to add the value DELETED to the STATUS property. This specification also updates [RFC7240] to add the subscribe- enhanced-get and limit preferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-00 https://datatracker.ietf.org/doc/html/draft-ietf-calext-subscription-upgrade-00 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 Jun 10 09:16:44 2019 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 021EA1200CC for ; Mon, 10 Jun 2019 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=fastmail.com header.b=rnPYHqfN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EwNUbiwb 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 hdKS6Fwx8zt5 for ; Mon, 10 Jun 2019 09:16:40 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31435120033 for ; Mon, 10 Jun 2019 09:16:40 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 58CDF222F1 for ; Mon, 10 Jun 2019 12:16:39 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 10 Jun 2019 12:16:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=WdWv+EGm9R4+wZ59hyeHx2YKd0l HuJ9TNpkKUcSczmc=; b=rnPYHqfNtyh0vWGcIaHXgndOz3t8GGYED4YeSDtF5MA vNWGTYPGYDk8aAKnpuvJ0nTPU4M78TOu74UWgtAnfrdtA81Bu93xyWTTKoigoiDi udCKYeB2BEhiK0hHR5iOqYcNPxEcCAfZAqyBRWkuo+tAuMIhAjTac2YzQoJ9aw5Y jz/5EkenbHNVup4l1PeYofxGc2o93xZfy/x5qpQOd5QX0MAUoBHcZe6POAzsfFt5 6oZcU62Msts8nKxf2XXgS1BRiE71FgCAl+uPfsDqgZe5iHKppXGBqES0/FjEaxFB no+MW6SZtGFLDQZiwZJgPkDM7WmWTD3/nsn63qmk0Fg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=WdWv+E Gm9R4+wZ59hyeHx2YKd0lHuJ9TNpkKUcSczmc=; b=EwNUbiwb6uKXufU50HN2D8 KYJn5yR9SuXZmcEzUDYXbDPBTTzcULZcJkbRIDeIXVmL3UKS6SPPwLgWI9aFMblh E1lvjyH0ODE4uf8XPu1fMrGSBl1m6tzZGS9Luht/tK5TTBPoLeY0jyRg3yWH2zIT mRJTsabSk+lxzzjzKl/5BRWrR5+axtHbWD/KPSkw4/hvfMjQgrMInGTJvCTndAHs oA+j1i36E1y1Hvm42La9ZNPkK47KhYTWYfzXrbJIWMc923KlJbI3aFuMHXX/Bk5U v7vd5paUnY/ZiDasxmrccvgvs918AMC8VE8ieoFnB1f8Sstnc98mnI9qxWIl2tEw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehvddgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhfhokffffgggjggtsehmtd erredtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejge drjeejrdekhedrvdehtdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgr shhtmhgrihhlrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D58280068 for ; Mon, 10 Jun 2019 12:16:38 -0400 (EDT) To: calsify@ietf.org References: <3edec26e-1b87-4f30-97c7-d0a18cda615e@www.fastmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <21c20d83-fceb-0d11-492a-6a54909a0413@fastmail.com> Date: Mon, 10 Jun 2019 12:16:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------63B802BC8DDCA1C1A57E3DCC" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 16:16:43 -0000 This is a multi-part message in MIME format. --------------63B802BC8DDCA1C1A57E3DCC Content-Type: multipart/alternative; boundary="------------72DE364B4DC482D88EEDB608" --------------72DE364B4DC482D88EEDB608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Would it make sense to change the parameter name to SUBSECOND as its a known term? This also would allow extending recurrence rules to have a matching SUBSECONDLY frequency if needed.  As stated early in the thread, a libical user wants to extend RRULE to do exactly this. On 6/6/19 9:07 AM, Robert Stepanek wrote: > This is a draft specification, happy about any input: > > 2.1.  FRACSEC parameter > >    Parameter name:  FRACSEC > >    Purpose:  This parameter is used to define fractional seconds for >       time values and durations.  It is meant to preserve time precision >       on time values and duration with sub-second precision, without >       increasing the time value range within iCalendar. > >    Description:  This parameter MAY be specified on properties of type >       DATE-TIME or DURATION.  The integral part of the float value MUST >       be zero.  The value MUST NOT be negative.  iCalendar >       implementations MAY ignore this parameter in date time arithmetic. >       Implementations MUST ignore presence of the FRACSEC parameter on >       RECURRENCE-ID properties when determining recurrence overrides. >       If present on a RECURRENCE-ID property, its value MUST match the >       FRACSEC parameter value on the DTSTART property. > >    Format Definition: > >    This parameter is defined by the following notation: > >                                        fracsec-param = float > >    Example:  DTSTART;FRACSEC=0..03:20190605T133015 > > > > On Thu, Jun 6, 2019, at 1:56 PM, Ken Murchison wrote: >> As a related topic, a libical user/developer submitted a PR to add >> millisecond precision to time values. I haven’t committed it because >> it simply changes the DATETIME values which certainly isn’t backwards >> compatible. I suggested a new VALUE type but even that isn’t >> compatible with unaware clients. >> >> Regardless, there does appear to be *some* desire to have fractional >> seconds support in iCalendar. >> >> -- >> Kenneth Murchison >> Cyrus Development Team >> FastMail US LLC >> murch@fastmaileam.com >> >> >> >> On Thu, Jun 6, 2019, at 8:04 AM, Marten Gajda wrote: >>> >>> Is this parameter is meant to preserve the fractional seconds for >>> round-trips or are iCalendar clients encouraged to use the value? >>> >>> I mean, would a client that's aware of X-FRACSEC have to match >>> RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds >>> into account? >>> >>> I think we should advise against that and make clear that this is >>> not meant to increase the precision of times in iCalendar, but >>> merely to preserve it. >>> >>> Btw, how do we cope with unaware clients doing partial updates? I.e. >>> a client which is not aware of X-FRACSEC adds a new >>> recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When >>> being converted back to JSCalendar, this would result in an >>> additional instance instead of an override. >>> >>> Marten >>> >>> Am 06.06.19 um 13:49 schrieb Robert Stepanek: >>>> It just occurred to me that the current JSCalendar RFC draft >>>> ambiguously defines if fractional seconds are allowed in the >>>> LocalDate time type. >>>> >>>> To be clear: we intend to allow fractional seconds in the start >>>> property (and any other LocalDate property). The next version of >>>> the RFC draft will define this more clearly. >>>> >>>> Unfortunately, fractional second date-times and durations can not >>>> be round-tripped out of the box with iCalendar. We will define an >>>> iCalendar extension parameter in the informational guide for >>>> mapping iCalendar and JSCalendar >>>> (draft-ietf-calext-jscalendar-icalendar): >>>> >>>> * X-FRACSEC of value type INTEGER >>>> * This parameter MAY be set on iCalendar properties of type >>>> DATE-TIME or DURATION. It MUST NOT be set more than once per >>>> property. >>>> * The value of this parameter defines the fractional seconds of >>>> the DATE-TIME or DURATION type. >>>> * This will allow iCalendar implementations  not being aware of >>>> this extension parameter to display the time value "good >>>> enough" with second precision. >>>> >>>> >>>> Please let me know if you prefer another approach. >>>> >>>> Cheers, >>>> Robert >>>> >>>> _______________________________________________ >>>> calsify mailing list >>>> calsify@ietf.org >>>> https://www.ietf.org/mailman/listinfo/calsify >>>> >>> -- >>> Marten Gajda >>> CEO >>> >>> dmfs GmbH >>> Schandauer Straße 34 >>> 01309 Dresden >>> GERMANY >>> >>> phone: +49 177 4427167 >>> email:marten@dmfs.org >>> >>> Managing Director: Marten Gajda >>> Registered address: Dresden >>> Registered No.: AG Dresden HRB 34881 >>> VAT Reg. No.: DE303248743 >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team FastMail US LLC --------------72DE364B4DC482D88EEDB608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Would it make sense to change the parameter name to SUBSECOND as its a known term? 

This also would allow extending recurrence rules to have a matching SUBSECONDLY frequency if needed.  As stated early in the thread, a libical user wants to extend RRULE to do exactly this.


On 6/6/19 9:07 AM, Robert Stepanek wrote:
This is a draft specification, happy about any input:

2.1.  FRACSEC parameter

   Parameter name:  FRACSEC

   Purpose:  This parameter is used to define fractional seconds for
      time values and durations.  It is meant to preserve time precision
      on time values and duration with sub-second precision, without
      increasing the time value range within iCalendar.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME or DURATION.  The integral part of the float value MUST
      be zero.  The value MUST NOT be negative.  iCalendar
      implementations MAY ignore this parameter in date time arithmetic.
      Implementations MUST ignore presence of the FRACSEC parameter on
      RECURRENCE-ID properties when determining recurrence overrides.
      If present on a RECURRENCE-ID property, its value MUST match the
      FRACSEC parameter value on the DTSTART property.

   Format Definition:

   This parameter is defined by the following notation:

                                       fracsec-param = float

   Example:  DTSTART;FRACSEC=0..03:20190605T133015



On Thu, Jun 6, 2019, at 1:56 PM, Ken Murchison wrote:
As a related topic, a libical user/developer submitted a PR to add millisecond precision to time values. I haven’t committed it because it simply changes the DATETIME values which certainly isn’t backwards compatible. I suggested a new VALUE type but even that isn’t compatible with unaware clients. 

Regardless, there does appear to be *some* desire to have fractional seconds support in iCalendar. 

--
Kenneth Murchison
Cyrus Development Team
FastMail US LLC
murch@fastmaileam.com



On Thu, Jun 6, 2019, at 8:04 AM, Marten Gajda wrote:

Is this parameter is meant to preserve the fractional seconds for round-trips or are iCalendar clients encouraged to use the value?

I mean, would a client that's aware of X-FRACSEC have to match RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds into account?

I think we should advise against that and make clear that this is not meant to increase the precision of times in iCalendar, but merely to preserve it.

Btw, how do we cope with unaware clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override.

Marten

Am 06.06.19 um 13:49 schrieb Robert Stepanek:
It just occurred to me that the current JSCalendar RFC draft ambiguously defines if fractional seconds are allowed in the LocalDate time type.

To be clear: we intend to allow fractional seconds in the start property (and any other LocalDate property). The next version of the RFC draft will define this more clearly.

Unfortunately, fractional second date-times and durations can not be round-tripped out of the box with iCalendar. We will define an iCalendar extension parameter in the informational guide for mapping iCalendar and JSCalendar (draft-ietf-calext-jscalendar-icalendar):
  • X-FRACSEC of value type INTEGER
  • This parameter MAY be set on iCalendar properties of type DATE-TIME or DURATION. It MUST NOT be set more than once per property.
  • The value of this parameter defines the fractional seconds of the DATE-TIME or DURATION type.
  • This will allow iCalendar implementations  not being aware of this extension parameter to display the time value "good enough" with second precision.

Please let me know if you prefer another approach.

Cheers,
Robert

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


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

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


_______________________________________________
calsify mailing list



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

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------72DE364B4DC482D88EEDB608-- --------------63B802BC8DDCA1C1A57E3DCC Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------63B802BC8DDCA1C1A57E3DCC-- From nobody Mon Jun 10 09:23:46 2019 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 28B1E120128 for ; Mon, 10 Jun 2019 09:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=fastmail.com header.b=lsyWfBvI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dojHWLun 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 22ZldrLOxVW6 for ; Mon, 10 Jun 2019 09:23:42 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACCD120033 for ; Mon, 10 Jun 2019 09:23:42 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id F0DFD22116 for ; Mon, 10 Jun 2019 12:23:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 10 Jun 2019 12:23:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=Dq5cuSzwbiJDpfblNNiKk3uEXbI L9snmH6rp+RG0KI4=; b=lsyWfBvI2piiW4WBJ0uROUvqNkDmVvuCMyqI5Vs3GH4 K1frDKwH2fflk2j8x23tqvOAmi7R33Agy7yREmKS8JbsEnrBL4ASdhEZ27XjXHy2 Pm0rHhtLqsz3O7/yJPvETEszKVvMvccl0YCjx+IyVldknKTu35obOtZ+Z+yrFg2D ivnT+YZIfmeTW07JPTaO+RA16WZbGyZLIUFQPN7Y6MYINdSefZNDbDYr3Br24doc i55TmGJVgU/ZVaDCmep5s+MnRG/t+PP9gW1BRbXA7Zs3yBdTBVEDCwNK+cyR6hpT dL9G1ZbN3pgBn48P0kVB6C5EujvlaA/vGKHV0ePCHRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Dq5cuS zwbiJDpfblNNiKk3uEXbIL9snmH6rp+RG0KI4=; b=dojHWLunKibtXW+s1bxKhB cTRaNGl6pHQeAB2IgM3Wodyi7PlPdL35qo8t1LTJKtIEYZBs4b68Yn2h3MP3h8b0 BBaxDfFBe9KD+aNJl0Hz35AmqsZ6je/bGdbUUKmQPvgZVeyDw+z79p/MXyKATpYY iHOcwt8ADP5di0gQEyRugejs0Fl7Qu7uMT9zE9inzYC7r7YMj4Kg3nIqBwLGSe0Y uYryfqOR+K1jkbTbdF8uxMDUcyLFlraLEMXbhU7LS2W6BSCLWsZ63Ium7N8wE+QU 26mDFpJcVrD0xiHh4Lvz10QYZORKk+Jatug40Y9neGe7QPZ/22yWFD5cNpZWOsng == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehvddguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhohfkffgfgggjtgesmh dtreertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehf rghsthhmrghilhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepje egrdejjedrkeehrddvhedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehf rghsthhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 3BF4880059 for ; Mon, 10 Jun 2019 12:23:41 -0400 (EDT) To: calsify@ietf.org References: <3edec26e-1b87-4f30-97c7-d0a18cda615e@www.fastmail.com> <21c20d83-fceb-0d11-492a-6a54909a0413@fastmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <6c3ed5d3-4d66-3ec5-3808-ca44efe367d4@fastmail.com> Date: Mon, 10 Jun 2019 12:23:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <21c20d83-fceb-0d11-492a-6a54909a0413@fastmail.com> Content-Type: multipart/mixed; boundary="------------9581F9694226C3BA92048EB9" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 16:23:45 -0000 This is a multi-part message in MIME format. --------------9581F9694226C3BA92048EB9 Content-Type: multipart/alternative; boundary="------------C6EF6178FBF005BB6B40E93D" --------------C6EF6178FBF005BB6B40E93D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/10/19 12:16 PM, Ken Murchison wrote: > > Would it make sense to change the parameter name to SUBSECOND as its a > known term? > > This also would allow extending recurrence rules to have a matching > SUBSECONDLY frequency if needed.  As stated early in the thread, a > libical user wants to extend RRULE to do exactly this. > Hmm, but since INTERVAL is an integer, we would have to specify the scale for subseconds (milli, micro, pico, nano?)  Or we allow MILLISECONDLY, etc as frequencies. > On 6/6/19 9:07 AM, Robert Stepanek wrote: >> This is a draft specification, happy about any input: >> >> 2.1.  FRACSEC parameter >> >>    Parameter name:  FRACSEC >> >>    Purpose:  This parameter is used to define fractional seconds for >>       time values and durations.  It is meant to preserve time precision >>       on time values and duration with sub-second precision, without >>       increasing the time value range within iCalendar. >> >>    Description:  This parameter MAY be specified on properties of type >>       DATE-TIME or DURATION.  The integral part of the float value MUST >>       be zero.  The value MUST NOT be negative. iCalendar >>       implementations MAY ignore this parameter in date time arithmetic. >>       Implementations MUST ignore presence of the FRACSEC parameter on >>       RECURRENCE-ID properties when determining recurrence overrides. >>       If present on a RECURRENCE-ID property, its value MUST match the >>       FRACSEC parameter value on the DTSTART property. >> >>    Format Definition: >> >>    This parameter is defined by the following notation: >> >>                                        fracsec-param = float >> >>    Example:  DTSTART;FRACSEC=0..03:20190605T133015 >> >> >> >> On Thu, Jun 6, 2019, at 1:56 PM, Ken Murchison wrote: >>> As a related topic, a libical user/developer submitted a PR to add >>> millisecond precision to time values. I haven’t committed it because >>> it simply changes the DATETIME values which certainly isn’t >>> backwards compatible. I suggested a new VALUE type but even that >>> isn’t compatible with unaware clients. >>> >>> Regardless, there does appear to be *some* desire to have fractional >>> seconds support in iCalendar. >>> >>> -- >>> Kenneth Murchison >>> Cyrus Development Team >>> FastMail US LLC >>> murch@fastmaileam.com >>> >>> >>> >>> On Thu, Jun 6, 2019, at 8:04 AM, Marten Gajda wrote: >>>> >>>> Is this parameter is meant to preserve the fractional seconds for >>>> round-trips or are iCalendar clients encouraged to use the value? >>>> >>>> I mean, would a client that's aware of X-FRACSEC have to match >>>> RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds >>>> into account? >>>> >>>> I think we should advise against that and make clear that this is >>>> not meant to increase the precision of times in iCalendar, but >>>> merely to preserve it. >>>> >>>> Btw, how do we cope with unaware clients doing partial updates? >>>> I.e. a client which is not aware of X-FRACSEC adds a new >>>> recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When >>>> being converted back to JSCalendar, this would result in an >>>> additional instance instead of an override. >>>> >>>> Marten >>>> >>>> Am 06.06.19 um 13:49 schrieb Robert Stepanek: >>>>> It just occurred to me that the current JSCalendar RFC draft >>>>> ambiguously defines if fractional seconds are allowed in the >>>>> LocalDate time type. >>>>> >>>>> To be clear: we intend to allow fractional seconds in the start >>>>> property (and any other LocalDate property). The next version of >>>>> the RFC draft will define this more clearly. >>>>> >>>>> Unfortunately, fractional second date-times and durations can not >>>>> be round-tripped out of the box with iCalendar. We will define an >>>>> iCalendar extension parameter in the informational guide for >>>>> mapping iCalendar and JSCalendar >>>>> (draft-ietf-calext-jscalendar-icalendar): >>>>> >>>>> * X-FRACSEC of value type INTEGER >>>>> * This parameter MAY be set on iCalendar properties of type >>>>> DATE-TIME or DURATION. It MUST NOT be set more than once per >>>>> property. >>>>> * The value of this parameter defines the fractional seconds of >>>>> the DATE-TIME or DURATION type. >>>>> * This will allow iCalendar implementations  not being aware of >>>>> this extension parameter to display the time value "good >>>>> enough" with second precision. >>>>> >>>>> >>>>> Please let me know if you prefer another approach. >>>>> >>>>> Cheers, >>>>> Robert >>>>> >>>>> _______________________________________________ >>>>> calsify mailing list >>>>> calsify@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/calsify >>>>> >>>> -- >>>> Marten Gajda >>>> CEO >>>> >>>> dmfs GmbH >>>> Schandauer Straße 34 >>>> 01309 Dresden >>>> GERMANY >>>> >>>> phone: +49 177 4427167 >>>> email:marten@dmfs.org >>>> >>>> Managing Director: Marten Gajda >>>> Registered address: Dresden >>>> Registered No.: AG Dresden HRB 34881 >>>> VAT Reg. No.: DE303248743 >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > -- > Ken Murchison > Cyrus Development Team > FastMail US LLC > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team FastMail US LLC --------------C6EF6178FBF005BB6B40E93D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 6/10/19 12:16 PM, Ken Murchison wrote:

Would it make sense to change the parameter name to SUBSECOND as its a known term? 

This also would allow extending recurrence rules to have a matching SUBSECONDLY frequency if needed.  As stated early in the thread, a libical user wants to extend RRULE to do exactly this.

Hmm, but since INTERVAL is an integer, we would have to specify the scale for subseconds (milli, micro, pico, nano?)  Or we allow MILLISECONDLY, etc as frequencies.


On 6/6/19 9:07 AM, Robert Stepanek wrote:
This is a draft specification, happy about any input:

2.1.  FRACSEC parameter

   Parameter name:  FRACSEC

   Purpose:  This parameter is used to define fractional seconds for
      time values and durations.  It is meant to preserve time precision
      on time values and duration with sub-second precision, without
      increasing the time value range within iCalendar.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME or DURATION.  The integral part of the float value MUST
      be zero.  The value MUST NOT be negative.  iCalendar
      implementations MAY ignore this parameter in date time arithmetic.
      Implementations MUST ignore presence of the FRACSEC parameter on
      RECURRENCE-ID properties when determining recurrence overrides.
      If present on a RECURRENCE-ID property, its value MUST match the
      FRACSEC parameter value on the DTSTART property.

   Format Definition:

   This parameter is defined by the following notation:

                                       fracsec-param = float

   Example:  DTSTART;FRACSEC=0..03:20190605T133015



On Thu, Jun 6, 2019, at 1:56 PM, Ken Murchison wrote:
As a related topic, a libical user/developer submitted a PR to add millisecond precision to time values. I haven’t committed it because it simply changes the DATETIME values which certainly isn’t backwards compatible. I suggested a new VALUE type but even that isn’t compatible with unaware clients. 

Regardless, there does appear to be *some* desire to have fractional seconds support in iCalendar. 

--
Kenneth Murchison
Cyrus Development Team
FastMail US LLC
murch@fastmaileam.com



On Thu, Jun 6, 2019, at 8:04 AM, Marten Gajda wrote:

Is this parameter is meant to preserve the fractional seconds for round-trips or are iCalendar clients encouraged to use the value?

I mean, would a client that's aware of X-FRACSEC have to match RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds into account?

I think we should advise against that and make clear that this is not meant to increase the precision of times in iCalendar, but merely to preserve it.

Btw, how do we cope with unaware clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override.

Marten

Am 06.06.19 um 13:49 schrieb Robert Stepanek:
It just occurred to me that the current JSCalendar RFC draft ambiguously defines if fractional seconds are allowed in the LocalDate time type.

To be clear: we intend to allow fractional seconds in the start property (and any other LocalDate property). The next version of the RFC draft will define this more clearly.

Unfortunately, fractional second date-times and durations can not be round-tripped out of the box with iCalendar. We will define an iCalendar extension parameter in the informational guide for mapping iCalendar and JSCalendar (draft-ietf-calext-jscalendar-icalendar):
  • X-FRACSEC of value type INTEGER
  • This parameter MAY be set on iCalendar properties of type DATE-TIME or DURATION. It MUST NOT be set more than once per property.
  • The value of this parameter defines the fractional seconds of the DATE-TIME or DURATION type.
  • This will allow iCalendar implementations  not being aware of this extension parameter to display the time value "good enough" with second precision.

Please let me know if you prefer another approach.

Cheers,
Robert

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


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

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


_______________________________________________
calsify mailing list



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

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

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

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------C6EF6178FBF005BB6B40E93D-- --------------9581F9694226C3BA92048EB9 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------9581F9694226C3BA92048EB9-- From nobody Mon Jun 10 10:28:45 2019 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 5D4BE1200CD; Mon, 10 Jun 2019 10:28:43 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <156018772326.10599.2205369636775675847@ietfa.amsl.com> Date: Mon, 10 Jun 2019 10:28:43 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-valarm-extensions-00.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 17:28:43 -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 : VALARM Extensions for iCalendar Authors : Cyrus Daboo Kenneth Murchison Filename : draft-ietf-calext-valarm-extensions-00.txt Pages : 14 Date : 2019-06-10 Abstract: This document defines a set of extensions to the iCalendar VALARM component to enhance use of alarms and improve interoperability between clients and servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-valarm-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-valarm-extensions-00 https://datatracker.ietf.org/doc/html/draft-ietf-calext-valarm-extensions-00 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 Jun 10 19:25:47 2019 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 D1057120026 for ; Mon, 10 Jun 2019 19:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=bVAji2Px; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yWtGh+qm 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 KeQmei6i73UX for ; Mon, 10 Jun 2019 19:25:41 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A4012000E for ; Mon, 10 Jun 2019 19:25:41 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DEAC83F9 for ; Mon, 10 Jun 2019 22:25:40 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 10 Jun 2019 22:25:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=EsvGXJ9IJxoYBnZmL0OKL+xuLMJ4dFEnfz+NBl7 d+Go=; b=bVAji2Px1z0wxxPl+iHYkSD+QkybnOqA847uvYaVqXlpmdm6d7npHv/ 3ljZf493XD/78lsAuO6TKu1UOMcQpEfKuB7F1GNz+mD+7nqLJVmTRct8AdnSJjKy KczgZtEfSweJD+lFyavWPEonNK6mIZr2IR8wh4xxkel88aA+x14uieABlnN7aepn i70M4zDgwPcYqZLejwzbM4iyB5QIGAf0hyotee9M21BLnINrsp2hqmXNjQbe0BKd BMZVyCd6iCkWEt8zcPELTPvwt4Dw401z6Fm3wLbTg+GuoHfhixbjC34AX50Ee8Hg uRhmLQXFVxA/EPniZdjK0d9SNGI/Y5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=EsvGXJ9IJxoYBnZmL0OKL+xuLMJ4d FEnfz+NBl7d+Go=; b=yWtGh+qmg1hLyO+CcK4ckPfco2AKTg5719Zk4LjT/KSZ8 fbcJzp5mhEkwxOOxaf0HIxfwJoJAyM+WSfBfjemmhCMMApJgekddkGq4ulzwTmTw U3tw3vyGpbc78/I5eEZKKQisJ3LTjmb4AU2tpyba4tNxc6F9Q+wIe1EJGS5rZKPK EjivrxKF6/RTB4jtp17SEnZpsqF//EhQfA8ocbjtWkODG86mD6exgX3Qe3Nn9Car UPiNV2IqzibllHrQaLLoVv6FWNGt6A1wuOo6VRcifKcfs9vy1BBTJ491WftDRFqy 4cuotXvCS2ERXM0RR9akGcZXAgnBSggKc4xi2huKg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehfedgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtgho mhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D279F1803AB; Mon, 10 Jun 2019 22:25:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-663-gf46ad30-fmstable-20190607v1 Mime-Version: 1.0 Message-Id: Date: Tue, 11 Jun 2019 12:25:39 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=4f326acd30a048289c59f4d0db40375b Archived-At: Subject: [calsify] Interim meeting notes uploaded X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 02:25:46 -0000 --4f326acd30a048289c59f4d0db40375b Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All, I've uploaded the minutes from the meeting in Bedford, as well as the no= tes from the "document status meeting" which was done later in the week.= In my notes for the next CalConnect meeting, I have suggested that the = document status should be done before a collaborative external call so w= e can present it! https://datatracker.ietf.org/doc/minutes-interim-2019-calext-01-20190604= 1600/ Anyway, here's the key document status info as pretty-text as well :) >From Last time! * Managed Attachments - final status * *Ken* will do * VPOLL * Need to lock down poll * *Mike*! (Ken can help with) * VALARM Extensions * Draft written by Cyrus Daboo * Main one we want to keep is acknowledgement - Apple, Thunderbird su= pport * Probably *Ken*? (currently co-author) * Considering removing Apple=E2=80=99s =E2=80=9Cdefault alarms=E2=80=9D= hack. * Avoid server putting defaults back on! * Proximity alarm (Apple already using) * If close to supermarket, fire an alarm! * Specify if you want an alarm, and how important the event is for yo= u. * Is it really important for me to get to this event? * Spend time in TC-CALENDAR debating if we want to change behaviour= ? * *SECOND DRAFT* * ALARM AGENT =E2=86=92 client/server. * *Related events* =E2=86=92 * alarm tied to multiple events? * X-travel-time? Client side will decide when to notify, not server= side at all with Android * Proprietary API anyway. * Subscription Upgrade * Smart updates to an ICS feed * Conditional request with a prefer header. * Adds =E2=80=9CStatus DELETED=E2=80=9D. * OPTIONS =E2=86=92 can specify what=E2=80=99s available. * Is =E2=80=9CeTag=E2=80=9D being used? Need to use weak eTag. * Does it support pagination? NO! * A header that says =E2=80=9Cstill more changes=E2=80=9D. * A way to say =E2=80=9Cthere=E2=80=99s been a change=E2=80=9D =E2=86= =92 aka push. * Author: *Mike* - individual submission *(rev** 3)* * Ask HTTPBIS to look at it. * CalDAV Sharing =E2=86=92 * what Apple has already implemented * *is 3 drafts* * DAV Notifications * DAV sharing * CALDAV sharing * Author: Evert wrote originally (*Ken* to write?) * *MAY WANT TO STANDARDISE Per-USER write capability* * DAV namespace * Go via Dispatch? * Per user notes on a vcard? * TODO: organizer, owner, etc in the caldav part. * VPATCH * Cyrus Daboo originated * Reduce client/server chatter. * Describes how to use it with RFC PATCH method. * ENHANCED CalDAV sync * Plz send patches * *Top level*: * Do you have anything new in calendar home. * Existing collection on the homeset * Use Depth: infinity * =E2=80=9Csupported report set=E2=80=9D * =E2=80=9Cerror status for un-traversable children=E2=80=9D * VINSTANCE * Effort to reduce size of recurring events with a bunch of overrides= .=20 * *Suggestion: Punt these three in favour of JSCalendar.* * Informational draft =E2=86=92 or DEVGUIDE. List all the resources a d= eveloper needs for a caldav client/server. * Evert=E2=80=99s website. * *MIKE*: Series draft * related events =E2=86=92 recurring event going on forever * Proposed a replacement =E2=86=92 series. * Master event, all instances are independent events with their own U= ID and a related-to to show that they are joined together. * *try implementing first=E2=80=A6* * *NEEDS TESTING* * There=E2=80=99s a spec already! * (SRULE) draft-douglass-series NOTES: * ICalendar Series * *Mike* to do * Fairly complete * Needs implementation experience * Blocking events =E2=86=92 other calendars know stuff that server ca= n use but client may not know. * (implementation: alarm? bot?) * *ICal Relations* * Has already gone through Calext. * *RESTART* * ICALENDAR:2.0+ =E2=86=92 *no point, JSCalendar is basically that* * cal-resource-vcard + vcard-* * takes existing systems and maps them to vcard * important to get back to * *Mike*! (is the last one standing) * feed in ISO work with names and addresses * *feed into JSContact work* * server-info * makes sense! * still valuable, clients can just add it at the time they add the ne= w features * *Mike*! and Ken=E2=80=A6 * any other volunteers? * serverside-subscriptions * came out of Apple and Sam * *Mike* again! * streaming * early days! * *TASKS* * Adrian from DHL * *Need to find out status* NOW: * ical-relations * server-info * tasks SOON: * series * serverside-subscriptions -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --4f326acd30a048289c59f4d0db40375b Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I've uploaded the minutes from the = meeting in Bedford, as well as the notes from the "document status meeti= ng" which was done later in the week.  In my notes for the next Cal= Connect meeting, I have suggested that the document status should be don= e before a collaborative external call so we can present it!


Anyway, here's the key do= cument status info as pretty-text as well :)

From Last time!

  • Managed Attachments - final status
    • Ken wi= ll do
  • VPOLL
    • Need to lock down po= ll
    • Mike!  (Ken can help with)
  • VALARM Extensions
    • Draft written by C= yrus Daboo
    • Main one we want to keep is acknowl= edgement - Apple, Thunderbird support
    • Probably= Ken?  (currently co-author)
      • =
    • Considering removing Apple=E2=80=99s =E2=80=9Cdefault alarms=E2=80=9D hack.=
        • <= li>Avoid server putting defaults back on!
      Proximity alarm (A= pple already using)
      • If close to supermarket, fire= an alarm!
    • Specify if you want an alarm, = and how important the event is for you.
      • Is it really important = for me to get to this event?
      • Spend time in TC-= CALENDAR debating if we want to change behaviour?
      • SECOND DRAFT
    • ALARM AGENT =E2=86= =92 client/server.
    • Related events =E2=86=92
      • alarm tied  to multiple events?<= br>
      • X-travel-time?  Client side will decide when to = notify, not server side at all with Android
      • Pr= oprietary API anyway.
  • Subscription U= pgrade
    • Smart updates to an ICS feed
    • C= onditional request with a prefer header.
    • Adds =E2=80=9CStatus = DELETED=E2=80=9D.
    • OPTIONS =E2=86=92 can specif= y what=E2=80=99s available.
    • Is =E2=80=9CeTag=E2=80=9D being = used?  Need to use weak eTag.
    • Does it sup= port pagination?  NO!
      • A header that says =E2=80=9Cstill more changes=E2=80= =9D.
    • A way to say <= /span>=E2=80=9Cthere=E2=80=99s been a chang= e=E2=80=9D =E2=86=92 aka push.
    • Author: = Mike - individual submission (rev 3)
    • Ask HTTPBIS to look at it.
  • = CalDAV Sharing =E2=86=92
    • what Apple has already implemen= ted
    • is 3 drafts
      • DAV Notificati= ons
      • DAV sharing
      • CALD= AV sharing
    • Author: Evert wrote originally=  (Ken to write?)
    • MAY = WANT TO STANDARDISE Per-USER write capability
      • DAV namespace=
      • Go via Dispatch?
    • Per user notes on a vcard?
    • TODO: organizer,= owner, etc in the caldav part.
  • VPATCH
    • = Cyrus Daboo originated
    • Reduce client/se= rver chatter.
    • Describes how to use it with RFC= PATCH method.
  • ENHANCED CalDAV sync
    • Plz send patches
    • Top level:
      • Do you have anything new in calendar home.
      • Existing collection on the homeset
      • =E2=80=9Csupported repor= t set=E2=80=9D
      • =E2=80=9Cerror status for un-tr= aversable children=E2=80=9D
  • VINSTANC= E
      • =
    • Effort to reduce size of recurring events with a bunch of ove= rrides.  
  • Suggestion: Punt these = three in favour of JSCalendar.
  • Information= al draft =E2=86=92 or DEVGUIDE.  List all the resources a developer= needs for a caldav client/server.
    • Evert=E2=80=99s website.
  • MIKE: Series draft
    • related events =E2=86=92 recurring event going on forever
    • Proposed a replacement =E2=86=92 series.
    • Master event, all instances are independent events with thei= r own UID and a related-to to show that they are joined together.=
    • try implementing first=E2=80=A6
      • N= EEDS TESTING
    • There=E2=80=99s a spec a= lready!
    • (SRULE) draft-douglass-series


NOTES:=
  • ICalendar Series
    • Mike to do
      =
    • Fairly complete
    • Needs implemen= tation experience
    • Blocking events =E2=86=92 ot= her calendars know stuff that server can use but client may not know.
    • (implementation: alarm? bot?)
    • ICal Relations
      • Has already gone through Cal= ext.
      • RESTART
    • ICALENDAR:2.0+ =E2=86=92 no point, JSCalendar is b= asically that
    • cal-resource-vcard + vcard-*=
        • <= li>takes existing systems and maps them to vcard
        <= li>important to get back to
      • Mike= ! (is= the last one standing)
      • feed in ISO wor= k with names and addresses
      • feed into JSCont= act work
    • server-info
      • <= ul class=3D"listtype-bullet listindent2 list-bullet2">
    • makes s= ense!
    • still valuable, clients can just add it = at the time they add the new features
    • Mike<= /b>! and Ken=E2=80=A6
    • any other = volunteers?
  • serverside-subscriptions
    • came out of Apple and Sam
    • Mike again!
  • streaming
    • earl= y days!
  • TASKS
    • Adrian from= DHL
    • Need to find out status
      =

NOW:
  • ical-relations<= /span>
  • server-info
  • tasks

SOON:
  • series
  • serverside-subscriptions





<= div id=3D"sig56629417">
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--4f326acd30a048289c59f4d0db40375b-- From nobody Tue Jun 11 12:51:04 2019 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 3327112006A for ; Tue, 11 Jun 2019 12:51:02 -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, SPF_NONE=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 EzUg-vW7cOMe for ; Tue, 11 Jun 2019 12:50:59 -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 14212120176 for ; Tue, 11 Jun 2019 12:50:58 -0700 (PDT) Authentication-Results: mail.aegee.org/x5BJotNm016786; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1560282656; i=dkim+MSA-tls@aegee.org; r=y; bh=WJoolw2ebrzlPGP9uYRM3XKfzd+UeY1Gh2WUxNNftMk=; h=Subject:From:To:Date:In-Reply-To:References; b=WM63i7dZ+MGXFF+BqRKxgOmN1a6t5MGo9BlsARd/egF+SKEWFZ5UpnarNb6R6k+B5 BV9mIWKkMU6W3LUcPMW7VszOZksthj6NZeBCw4om4wDH1m901CvS+FJQtswXfcgfBw kn/QQOFrbNIF3Fj08QsE+Z/BEepM7z9uJwu2r+a16hllgJZmsYFgQ1O63PvU2T7DCd UuBE6yuSq77YqyI4zEvbZ45vmcU6AtM1JGBrnFbgQ1zgUIhm5qmI/nTH+QlL+PJNVD e64nAHw9ZeX3bBVqNDvu5F0v8zfwm++aPS0Otb+nMl9I+NlGiJRJsUT9jKogOMh2Iq O+3/sdM1otrKH+ceFYwtBhuXf5qrZLHPOdRnxvUUFQbKU57rYF9d8Rj+To+AHbI+vT 4CICkiqayeU1UYz2mEikiCHMIDevhW5yNLbvulr6Tru8tVBWSCsk3wWIEd+9SDda3q 7xYXXpPKYJmhc/VYFHttrt+FVTaeJ4LIFnUOYykbp0nXm269ESaN5cZ+ejNNl4cggh KLpQpIfnIO5B1moUyDFORFi0f2xWosjtzRFVsYX9GXp67GpNxCw8JBUyxVRgzI25Co coYRzZQE+gdFJklcf4d+gfE1xxKXd6YQ7DjpnkDwcBbZVVpgZ9a8k11SZ545Ju2DRC VQ/52hlTwbiXL+Vr+dXoflzU= Authentication-Results: mail.aegee.org/x5BJotNm016786; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x5BJotNm016786 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 11 Jun 2019 19:50:56 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: calsify@ietf.org Date: Tue, 11 Jun 2019 19:50:55 +0000 In-Reply-To: <155992219411.20220.15511434849780424587@ietfa.amsl.com> References: <155992219411.20220.15511434849780424587@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-00.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 19:51:02 -0000 Hello, this document does not talk about where the CUAs get the calendar feeds from, or how the CUAs can know, to which feeds a user is subscribed. One possible approach is to get the feeds from diverse web pages and keep then only on the client, while some servers support the approach described at http://sabre.io/dav/clients/ical/#subscriptions . My big question is: A user gets a webcal URL, let’s say secured webcals://A/B . Why doesn’t the client just do: OPTIONS /B HTTP/1.1 Host: A If the answer contains DAV: calendar-access, then apply the mechanisms from Calendaring Extensions to WebDAV (CalDAV) RFC4791 and Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) to get all data; get the changes since the last synchronization; get only events after certain date…? Otherwise call from time to time GET on the URL to get all the data. Why there needs to be a different protocol for calendar subscription feeds, different from the regular calendar transport protocols? On another note, about VJOURNAL, https://tools.ietf.org/html/rfc5545#section-3.8.1.11 says for STATUS: Description: In a group-scheduled calendar component, the property is used by the "Organizer" to provide a confirmation of the event to the "Attendees". For example in a "VEVENT" calendar component, the "Organizer" can indicate that a meeting is tentative, confirmed, or cancelled. In a "VTODO" calendar component, the "Organizer" can indicate that an action item needs action, is completed, is in process or being worked on, or has been cancelled. In a "VJOURNAL" calendar component, the "Organizer" can indicate that a journal entry is draft, final, or has been cancelled or removed. Possible value for VJOURNAL's STATUS: are DRAFT, FINAL and CANCELLED. So the “cancelled or removed” stati above are both mapped to STATUS:CANCELLED. However, the description above in the RFC does not say, that there is a status for removed in VTASK or VEVENT. https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-00#section-4.1 Redefined Status property contains another: Description In a group-scheduled calendar component, the property is used by the "Organizer" to provide a confirmation of the event to the "Attendees". For example in a "VEVENT" calendar component, the "Organizer" can indicate that a meeting is tentative, confirmed, or cancelled. In a "VTODO" calendar component, the "Organizer" can indicate that an action item needs action, is completed, is in process or being worked on, or has been cancelled. In a "VJOURNAL" calendar component, the "Organizer" can indicate that a journal entry is draft, final, or has been cancelled or removed. There is no extra text to accomodate, that VEVENT and VTODO can also be “removed” ⇔ deleted. “For example” is not correct, as the text in the original RFC does try to describe all possible cases. This shall be the intention of the redefinition. Regards Дилян On Fri, 2019-06-07 at 08:43 -0700, internet-drafts@ietf.org wrote: > 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 : Calendar subscription upgrades > Author : Michael Douglass > Filename : draft-ietf-calext-subscription-upgrade-00.txt > Pages : 15 > Date : 2019-06-07 > > Abstract: > This specification introduces an approach to allow subscribers to > calendar feeds to upgrade to a more performant protocol. > > This specification updates [RFC5545] to add the value DELETED to the > STATUS property. > > This specification also updates [RFC7240] to add the subscribe- > enhanced-get and limit preferences. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-00 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-subscription-upgrade-00 > > > 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/ > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Tue Jun 11 20:11:07 2019 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 B4049120071; Tue, 11 Jun 2019 20:11:05 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 H9Gs4t3zRjvM; Tue, 11 Jun 2019 20:11:04 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 0087012002F; Tue, 11 Jun 2019 20:11:03 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id m29so17144253qtu.1; Tue, 11 Jun 2019 20:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=TcHCd8TXrzKOfzVvz3XffbawfYldhOZqkClaRWt/q8w=; b=cOnG5U6dZVp+OcrH6Mo7w4s5HwCKpKAkxHFY3mBke0gm/LPCQNlVeK8t3OSgmm3+aO dCC/JnI+RKi14vm/lf3u72QGS9ylb/ovHsXkEXOIGAY+cDTIZwZLwN5zQ0z0F+XttszH Mil1ECQAmVLt5gUY2Umm0DMZUZ3IfIKq8CnEu5vWGLot6/pOkV2jTU6avV52ENBqZYay ThISiNvzeTEEc9j1bZm4eVeiehwDe4TK26/t2OFSjyyQvcrvUsy8imbXV6hfT6daiZwd 0+XUSXzCrpP5yNoVdB7kB5cFILOik8R22aZK7LdVcEfH+5r7hr0ddsWzyMPFTvvhlAiq idFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=TcHCd8TXrzKOfzVvz3XffbawfYldhOZqkClaRWt/q8w=; b=nRKgQyhwK/68zIcWXJWF5BJQr+RBhC8y52n7yOYynhchep35NtoG/z1pzqQTBzkjsr ECb3c92nnedLGzDtLEvLp3bbPkSQEh3cSZbmNn5MuvL8o1fp7c4tsX+t32W3lYGkaMNG AuokQCKA+0ntciYBlVYL40QZ6ElZJpoF+HX0ehEDN8eujajJVJ3t/gs2kWFGAUhFOEP2 rgCmmm2Zc6Fhw2ek4h//h7JEfLhHx0mcESS2SauNxDyetjb4FCDUz0BRyY/EvdcVIwzn T7PsnsyW0TD3VbKPAX9jjIeAuiJAnXl5ry3/aQUA7WVBCjwG6PCdF8QglfWELCXlR/wT QSpg== X-Gm-Message-State: APjAAAUNwkaqWGx92bu7Vvj8y846cEBe2Dv0HMG3ZzkmTKg5ofiipnH+ 2loVB86hwFzk1Dzc44vSELPZmgniJQA= X-Google-Smtp-Source: APXvYqyuQ3UWZ+7uBaZLeuDM/KuPfugNCB6dIjHzIyUfJhB3gH+O1Zglzh/G1OtAjtckHb81jZFgJg== X-Received: by 2002:ac8:1829:: with SMTP id q38mr49819320qtj.252.1560309062743; Tue, 11 Jun 2019 20:11:02 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id r5sm2274598qkc.42.2019.06.11.20.11.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jun 2019 20:11:02 -0700 (PDT) To: Benjamin Kaduk , The IESG Cc: draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org References: <155908852723.25806.3708247030243239163.idtracker@ietfa.amsl.com> From: Michael Douglass Message-ID: Date: Tue, 11 Jun 2019 23:11:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <155908852723.25806.3708247030243239163.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 03:11:06 -0000 On 5/28/19 20:08, Benjamin Kaduk via Datatracker wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I want to talk some about the redefinition of SOURCE. While I agree > that the original definition's applicability is more narrow than it > needs to be, that doesn't seem to be enough to convince me that there's > enough justification to make it so broad as to provide vcard information > about a participant or an event link-back, as opposed to just the > canonical source of updates for a given object/component. I must > apologize for having essentially not done a search of the WG discussion > archives for this topic, and pointers into the archive could help to > convince me that this redefinition is a stable, interoperable, and > backwards-compatible choice. On this particular issue I've come round to agreeing with the points made here and in other messages. As an alternative i was considering suggesting dropping the VALUE=TEXT. Having a vcard inline can always be handled with a data uri. However, it seems to me that I can come closer to the intent by using the STRUCTURED-DATA property - it is intended to provide supporting data and of course there's no backwards compatibility issues. Does this seem an appropriate way forward? From nobody Thu Jun 13 18:13:16 2019 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 BCB1D1200EF for ; Thu, 13 Jun 2019 18:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 plIK6AP8Eass for ; Thu, 13 Jun 2019 18:13:13 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 28CDA1200D7 for ; Thu, 13 Jun 2019 18:13:13 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id x15so344131pfq.0 for ; Thu, 13 Jun 2019 18:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version; bh=hh/nVZr0jd2JwypOBT3WvLXJiUBczBDXs7w9gsyx7Rk=; b=dqvgQJnDqhdsooiPUezYIea3C1d875y3D6Az8Q+4JuKIQqaGI+SlIPqXKnkdB9IVbt PHn7nMhbKtyZFC0KX52SEpHtQmrX8WpCvndC5A44mvaBW7Of/v9EcjEIs3WlRq40GZrB gQFI0sSKWjBtqTZkkH/IoJwz8A5qoGRuIf0rKvIt4qpC6FeoumIq1yymTuZLvQF3LdhM alItu62ubQ0te4FSaIBhwrgiLEkkCugcal40JSLHjyc7FhCLHTHW0PzUemz4cbX5j/qm /tBGm2333/CHX3riv6yJXPuEx6Kgx+esYhKj907iJ4rQKOp1YK676HMEYSDV+P2qdvZo RBwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version; bh=hh/nVZr0jd2JwypOBT3WvLXJiUBczBDXs7w9gsyx7Rk=; b=huty4OyPKS6crHkEYOxz4xB8oCCr+2P054u2Jw8UmBmMVU64PafD0C645IVYhGOK7n 6h2jP/Zc8RilVQgcbbjkGwlNTA6Mrzi6UvbYnjppC99/WYn8nBkfh4mMd1E6Yr82Fnmy 4CD+JgDmj0A7uF7OVgZOtnQAbC+MeqryZ2a0d1p/Hf+c5h1SgERoTejEKIgojv9tDYUo 19Ee0c0RfG0J7oz4CgYELq/+nLfu+svBVm9aZ0Anci3V+UdmTagldZw0dIx8GynpcSja Nhe7mpbZ8RcYhQgX3JLAaMIli8/hUItpbF4xnvzL+Tfon2l+BejJNSzGryBwXP/5/h7K 5q1A== X-Gm-Message-State: APjAAAXDQlbjQ2QEBN9GlJmHkJKHyt/PrYZvGs4Xj1qcEDyeE1wfHG8T +nMWCSXTE02/rOZY3RSqmddX0fAAIkhL X-Google-Smtp-Source: APXvYqwhd1I570QtYdiKifM/w6Nqf3WIKv66OTYAUoJiEnyLc66YM7Hh0eAjwXJIUvthmGFvo0iPpA== X-Received: by 2002:a17:90a:3724:: with SMTP id u33mr8277300pjb.19.1560474792088; Thu, 13 Jun 2019 18:13:12 -0700 (PDT) Received: from [192.168.1.7] ([174.27.189.124]) by smtp.googlemail.com with ESMTPSA id j14sm910402pfe.10.2019.06.13.18.13.10 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2019 18:13:10 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org Organization: http://SoftwareAndServices.NET Message-ID: Date: Thu, 13 Jun 2019 19:13:10 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040900070402030404070606" Archived-At: Subject: [calsify] Calendar spam - it is speeding up - security issue / warning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 01:13:15 -0000 This is a cryptographically signed message in MIME format. --------------ms040900070402030404070606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Years ago, I predicted without more controls (no clue what), that=20 calendaring can be used to attempt to schedule appointments and spam. No proposal from me. Perhaps after reading the article below, new=20 security controls may be needed soon. It might make a new great topic /=20 draft. Clearly - do not click on appointments in email to find out what=20 they are about. This article is pointing out the latest calendaring security abuse. (it=20 is a bit of pay-to-view, you can still read it). Summary, spammers are sending out calendar appointments with URLs that=20 look like appointments (and are fake links or malicious links), or have=20 valid iCalendar objects that have or link to malicious calendar=20 attachments. The MUA/CUA or perhaps user is being careless about what is = loaded. The original post that led me to this article pointed out that=20 Thunderbird with the calendar add-on, may be vulnerable to this. Not entirely new or new news. But it seems to be picking up. =20 https://www.forbes.com/sites/daveywinder/2019/06/11/new-security-warning-= issued-for-googles-1-5-billion-gmail-and-calendar-users/#700c55f7565e No proposal from me. Just for those on this list, if you happen to have=20 an idea for helping slow or stop this kind of thing, it may be time to=20 rethink iTIP and calendar security. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms040900070402030404070606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE0MDExMzEwWjAvBgkq hkiG9w0BCQQxIgQgapEa28ikWgRV5Z3J9a9VE0eCrjvS6bwLwAP91MYgMucwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQCziN6VPvTAxY6IS3uKyY8ClwGsfJ+a8HODr3G2JbXtILxGj6nT kYYn/VY6FJF/kjXnDBa6BNDjJR+/m+6edY2c9IIEYHanIz3VFddrSPlyIXr+YRD6NGaxjgF/ /kmI84OhY9pSA1MD30z4R7blfpdFues1ZeaURZxnTq1nDriFF+xm2UVhZZlmOeHKfQiE14NH CsDeQ7fF/C9/Uf/i7qBjGm/TtvFgKkbUMvZHg1Zaieoo4Nze0YXLaNaytdqhxpVgsHRg9rz5 vN5581QC/DFW4gpU4Xf+D/hRiRLIPMaQPpMQAxw3iMwTpE4KFLncsnBlhxd9DfTk1boZSMdM oL4AAAAAAAAA --------------ms040900070402030404070606-- From nobody Thu Jun 13 19:10:23 2019 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 381831200F9 for ; Thu, 13 Jun 2019 19:10:22 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=calconnect.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 xGg5E2o68EjV for ; Thu, 13 Jun 2019 19:10:19 -0700 (PDT) Received: from dog.birch.relay.mailchannels.net (dog.birch.relay.mailchannels.net [23.83.209.48]) (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 E8EAA1200EF for ; Thu, 13 Jun 2019 19:10:18 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|dave.thewlis@calconnect.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 42ED1500364; Fri, 14 Jun 2019 02:10:17 +0000 (UTC) Received: from pdx1-sub0-mail-a62.g.dreamhost.com (100-96-28-110.trex.outbound.svc.cluster.local [100.96.28.110]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8504F501775; Fri, 14 Jun 2019 02:10:16 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|dave.thewlis@calconnect.org Received: from pdx1-sub0-mail-a62.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Fri, 14 Jun 2019 02:10:17 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|dave.thewlis@calconnect.org X-MailChannels-Auth-Id: dreamhost X-Trade-Coil: 2937892746a79c86_1560478217052_1635630132 X-MC-Loop-Signature: 1560478217052:1102051751 X-MC-Ingress-Time: 1560478217051 Received: from pdx1-sub0-mail-a62.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a62.g.dreamhost.com (Postfix) with ESMTP id 3DC0582A93; Thu, 13 Jun 2019 19:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=calconnect.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=calconnect.org; bh=QhXnxzm408NpdQE4 KksV8e9+WVk=; b=f2k8qw/55uaWYmQ4skn/AaBBCkE2/vYTJiOSxOJKF10afY+t /xrLteZqXFba2kjZ7UH5OB/JGTSZmuefyvBS7XGUhiJBMsMSi1AnHxGRFIXN37vl piRKkIjeGTfm42e0TVcA3mV7IqrjCiWZS4FwdIctsfygU5Rry+InycMBBog= Received: from [192.168.0.218] (47-208-67-174.erkacmtk02.res.dyn.suddenlink.net [47.208.67.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: dave.thewlis@calconnect.org) by pdx1-sub0-mail-a62.g.dreamhost.com (Postfix) with ESMTPSA id CC9D782A83; Thu, 13 Jun 2019 19:10:10 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_38E03D48-FCE6-4E97-B52A-543D4DB5E1FE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) X-DH-BACKEND: pdx1-sub0-mail-a62 From: David Thewlis In-Reply-To: Date: Thu, 13 Jun 2019 19:10:09 -0700 Cc: Doug Royer Message-Id: <25453529-BE41-4A4E-B6BD-5EB662C73DEC@calconnect.org> References: To: "calsify@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrudeitddgheegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffkfhfvffosegrtdhmrehhtddvnecuhfhrohhmpeffrghvihguucfvhhgvfihlihhsuceouggrvhgvrdhthhgvfihlihhssegtrghltghonhhnvggtthdrohhrgheqnecuffhomhgrihhnpehfohhrsggvshdrtghomhdptggrlhgtohhnnhgvtghtrdhorhhgpdhivghtfhdrohhrghdpughouhhgrhhohigvrhdruhhsnecukfhppeegjedrvddtkedrieejrddujeegnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopegludelvddrudeikedrtddrvddukegnpdhinhgvthepgeejrddvtdekrdeijedrudejgedprhgvthhurhhnqdhprghthhepffgrvhhiugcuvfhhvgiflhhishcuoegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgqedpmhgrihhlfhhrohhmpegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgpdhnrhgtphhtthhopegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [calsify] Calendar spam - it is speeding up - security issue / warning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 02:10:22 -0000 --Apple-Mail=_38E03D48-FCE6-4E97-B52A-543D4DB5E1FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI earlier this year, CalConnect published a best current practices for = calendar operators on calendar spam. This was developed in conjunction = with M3AAWG; we understand that they will be publishing it as well. See = https://standards.calconnect.org/csd/cc-18003.html = . Dave Thewlis > On Jun 13, 2019, at 18:13, Doug Royer wrote: >=20 > Years ago, I predicted without more controls (no clue what), that = calendaring can be used to attempt to schedule appointments and spam. >=20 > No proposal from me. Perhaps after reading the article below, new = security controls may be needed soon. It might make a new great topic / = draft. Clearly - do not click on appointments in email to find out what = they are about. >=20 > This article is pointing out the latest calendaring security abuse. = (it is a bit of pay-to-view, you can still read it). >=20 > Summary, spammers are sending out calendar appointments with URLs that = look like appointments (and are fake links or malicious links), or have = valid iCalendar objects that have or link to malicious calendar = attachments. The MUA/CUA or perhaps user is being careless about what is = loaded. >=20 > The original post that led me to this article pointed out that = Thunderbird with the calendar add-on, may be vulnerable to this. >=20 > Not entirely new or new news. But it seems to be picking up. >=20 > = https://www.forbes.com/sites/daveywinder/2019/06/11/new-security-warning-i= ssued-for-googles-1-5-billion-gmail-and-calendar-users/#700c55f7565e >=20 > No proposal from me. Just for those on this list, if you happen to = have an idea for helping slow or stop this kind of thing, it may be time = to rethink iTIP and calendar security. >=20 > --=20 >=20 > Doug Royer - (http://DougRoyer.US) > Douglas.Royer@gmail.com > 714-989-6135 >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- 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=_38E03D48-FCE6-4E97-B52A-543D4DB5E1FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI = earlier this year, CalConnect published a best current practices for = calendar operators on calendar spam.  This was developed in = conjunction with M3AAWG; we understand that they will be publishing it = as well.  See https://standards.calconnect.org/csd/cc-18003.html.

Dave Thewlis


On Jun 13, 2019, at 18:13, Doug Royer <douglasroyer@gmail.com> wrote:

Years = ago, I predicted without more controls (no clue what), that calendaring = can be used to attempt to schedule appointments and spam.

No proposal from me. Perhaps after reading the = article below, new security controls may be needed soon. It might make a = new great topic / draft. Clearly - do not click on appointments in email = to find out what they are about.

This = article is pointing out the latest calendaring security abuse. (it is a = bit of pay-to-view, you can still read it).

Summary, spammers are sending out calendar appointments with = URLs that look like appointments (and are fake links or malicious = links), or have valid iCalendar objects that have or link to malicious = calendar attachments. The MUA/CUA or perhaps user is being careless = about what is loaded.

The original post = that led me to this article pointed out that Thunderbird with the = calendar add-on, may be vulnerable to this.

Not entirely new or new news. But it seems to be picking = up.

https://www.forbes.com/sites/daveywinder/2019/06/11/new-securit= y-warning-issued-for-googles-1-5-billion-gmail-and-calendar-users/#700c55f= 7565e

No proposal from me. Just for = those on this list, if you happen to have an idea for helping slow or = stop this kind of thing, it may be time to rethink iTIP and calendar = security.

--

Doug Royer - (http://DougRoyer.US)
Douglas.Royer@gmail.com
714-989-6135

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





--
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=_38E03D48-FCE6-4E97-B52A-543D4DB5E1FE-- From nobody Thu Jun 13 19:57:59 2019 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 A3E8B1200E6 for ; Thu, 13 Jun 2019 19:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 svxeuhW_qaGz for ; Thu, 13 Jun 2019 19:57:55 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 2446B12003E for ; Thu, 13 Jun 2019 19:57:55 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id a93so359185pla.7 for ; Thu, 13 Jun 2019 19:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=LAch2dvogMShR1E89CExExriTSjTX9iAnUNUqc02O7k=; b=mMmNyKaiN7PX8JKPxDue1NLGKPEIDY29FB93oMiz67484hTDIlMIxJEObZ/FftGa5+ +QFW5L9erDKGNLTzebk2DPynPQ0lMqJ+7JBZA3/RpwISXnthYpkpKrV0y0c+cgYbAr71 m1q1OTjo2Ek3lO/8SGB9xegvbKCDAVtHQdOQ7tLKpNyAMjCRNGcaVdCEbXgLJV3VAQfm 0CE07neFWaQsGWi3PXy1b5D3Vh+dNykw3ZvydOeRIV6q8dsofQmff6Gfyq1na3bM6IhM PDsMhdJ3Xf9ekWJWAlVAPZO7VS+ZD6t+vq7pWn9ea/lyzVEu/yQ8BcNalexzDzE2GoHK IyDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=LAch2dvogMShR1E89CExExriTSjTX9iAnUNUqc02O7k=; b=FI9u8Nn8YdSk/HtS8VyI60Q3R2stgeubV9q+1XrgAz4qw6c+Arz/2IK3fnwkipDuDt Mq8lIYmPVuFOqKTUgVe16cP7asebf3pZCAxaWTQS/PYH4ATnmMrBJJRMIJ6AZBV+8Uxq kFq5ho60ATq2lFT8vL4lS1zVFAGhntDPybAumuhw347SL2TsCEwzhd32dk1RMGOs4KPb PL5LdtufH7K3LcwNmCX/BrJS/76kCJgEHBJgoiMMK8hhO+Q/HeHBuOTR6z2s39511GO6 v/SaHLNjiNXX2w18q/719rwj12/Ou7PoriWqSHIm1Lpnzuv8B/cVf7kGkL4H+W9vHn6t 1Qiw== X-Gm-Message-State: APjAAAUZpugTTtN/SQRs6UStaMaNr6dz0FwZAzItoXKy8ivLVFOmad5W 6m3XGu5T6BGEMCK5NGJ/nvDoHH4SUjDV X-Google-Smtp-Source: APXvYqwdPHJn3+32KxNrfIutlznxTGzX+YHlXMWY5Ia5ucnuOnDCCUKgqeX+qFsD9/cWmwsKqNqNgg== X-Received: by 2002:a17:902:824:: with SMTP id 33mr93607946plk.29.1560481074042; Thu, 13 Jun 2019 19:57:54 -0700 (PDT) Received: from [192.168.1.7] ([174.27.189.124]) by smtp.googlemail.com with ESMTPSA id p27sm1088678pfq.136.2019.06.13.19.57.52 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2019 19:57:52 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <25453529-BE41-4A4E-B6BD-5EB662C73DEC@calconnect.org> Organization: http://SoftwareAndServices.NET Message-ID: Date: Thu, 13 Jun 2019 20:57:52 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <25453529-BE41-4A4E-B6BD-5EB662C73DEC@calconnect.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050409080900010405080902" Archived-At: Subject: Re: [calsify] Calendar spam - it is speeding up - security issue / warning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 02:57:57 -0000 This is a cryptographically signed message in MIME format. --------------ms050409080900010405080902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/13/19 8:10 PM, David Thewlis wrote: > FYI earlier this year, CalConnect published a best current practices fo= r=20 > calendar operators on calendar spam. =A0This was developed in conjuncti= on=20 > with M3AAWG; we understand that they will be publishing it as well. =A0= See=20 > https://standards.calconnect.org/csd/cc-18003.html. >=20 > Dave Thewlis Great! Just read it for the first time. I did not know it existed. Should drafts start using 'https' and not 'http' in the examples? It is=20 not just about security over the wire. It can be about verifying the=20 destination host is from a verified and expected site. Should https be=20 required for all links in the future? I could add a URL into an iCalendar property/ parameter that links to a=20 =2EDOC file that has malicious code. Several proposals lately have added = or used URL links to related documents. Some CUAs could execute the=20 related viewing application themselves after the user says 'yes' to load = "YourIntroPacket.doc" - without virus checking. This is a security issue= =2E A warning about the user saying "yes" to download and not automatic=20 loading is the first half. Virus checking and malicious site checking is = the second (and not mentioned) half. Last time I wrote a CUA, I just used the OS call to load and view the=20 reflated application using the OS 'start the correct application' calls=20 - without checking. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms050409080900010405080902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE0MDI1NzUyWjAvBgkq hkiG9w0BCQQxIgQgozGjSTozsmO2EzLLyhNw3sEQ21hG0sVUxCrLP378M+4wbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQBzqwu19fJnshwn5la8y/9yyQVKpm0zMhX5mHxbQTn/L+a5XXJe jv5cI7+dO+Lk4KG647TllmxlfJ3JXZczvzv0ZLK+m8WHDtopIcuo97sT2vRuRXou7QOoXsNt g3A9HPha9GJV6WCmTzTvx97FuJlpPxeom6V/eTAGqbu5rYr3bcRQ6W0cpOLtIeYWJSwAI9LK m2i8oXh7Qz2LsOyy6evBndnvge+Ry9SCkN5yPDMImuJpvYle6/hJgEAXOF6TsQgvwypKuoxz bkdanUCoqlOSnouXLQDwQryqNgSQsjLw8kML48tJz5KZUkj8ORPnF+IHd+iM0EGuORuybpZK ZDOKAAAAAAAA --------------ms050409080900010405080902-- From nobody Mon Jun 17 07:40:08 2019 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 4ADD4120139 for ; Mon, 17 Jun 2019 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=J4GZho5Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wRkDgnMt 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 xcbumyM4imYp for ; Mon, 17 Jun 2019 07:40:04 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4580012012B for ; Mon, 17 Jun 2019 07:40:04 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 613C78BD for ; Mon, 17 Jun 2019 10:40:03 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 17 Jun 2019 10:40:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=upR17PL tpF/EZxyQLGIs4ASMvP6UCX3wzRrOHa+z5Ls=; b=J4GZho5YnRwmQ8jsatMxBbf qtQt1w9OOJ74rd9xNvsloXLbIt+0itpsGCSOF388dxP2vaGqapERY3Q8R6Qr1Cc3 R84V9ps14QwO20zuMDm25bE5pwIYFK+vqrCobXIKI9UKk04dQfT48MQH8bzhTY3p vaViIeQ0GkE+G40++6zEESyMvCNw6UZrlS89YgtzfqY8mBhFpt+1jWFYsKl6ffoc LWcA/8SX5IPBprfwZ3Ls0+4PFLe52U3qqSgfE660UpUwjcM6Y0C7yL+Wd8nL4fLO eE54IawG/Q3SA7v040P1WnPaSZORbjNYVEkqA6kbvPSuno7tFaXIKCmcB4x3tZg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=upR17P LtpF/EZxyQLGIs4ASMvP6UCX3wzRrOHa+z5Ls=; b=wRkDgnMtbRjEDrvMLVNddb travk4g60dXwqHqRmKt98ego9gfdZtaOmEKgFxpGxWeCYbMwZtQx6gGravsp/dBs SwHfCzbNz1qEF18uMZj+KFzKfiu59eV/srANpPCAIX3ArmogZawxG4sK7/5b2KHx L4lpxdPmATPUn4WML17fn8t3nqese21rTZdIiAfuOOkZnrfGmfLzWFOl9nwodQw4 Dwe9UyV8VyaBSD/TT0VxRGMaZm/NELkKX70jxsIs2glJqvqfDUGGzrFiMXjkEd0q 8kSo2A6AvJ0j7hUHKN72SWgWz6JlwelG9Fb+0sqGlCybTczfzaeIRqbrUWNHOaCw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeijedgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 860531806CD; Mon, 17 Jun 2019 10:40:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-666-gb2312fa-fmstable-20190614v4 Mime-Version: 1.0 Message-Id: In-Reply-To: <21c20d83-fceb-0d11-492a-6a54909a0413@fastmail.com> References: <3edec26e-1b87-4f30-97c7-d0a18cda615e@www.fastmail.com> <21c20d83-fceb-0d11-492a-6a54909a0413@fastmail.com> Date: Mon, 17 Jun 2019 16:40:02 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=e5a2f9d0d386481b833b16ea883486ad Archived-At: Subject: Re: [calsify] JSCalendar: fractional seconds X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 14:40:06 -0000 --e5a2f9d0d386481b833b16ea883486ad Content-Type: text/plain On Mon, Jun 10, 2019, at 6:16 PM, Ken Murchison wrote: > Would it make sense to change the parameter name to SUBSECOND as its a known term? I think that's a better than name than FRACSEC. I'll use it. Thanks. --e5a2f9d0d386481b833b16ea883486ad Content-Type: text/html
On Mon, Jun 10, 2019, at 6:16 PM, Ken Murchison wrote:

Would it make sense to change the parameter name to SUBSECOND as its a known term?


I think that's a better than name than FRACSEC. I'll use it.

Thanks.
--e5a2f9d0d386481b833b16ea883486ad-- From nobody Mon Jun 17 09:10:11 2019 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 B276C12030D; Mon, 17 Jun 2019 09:09:53 -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.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <156078779363.6363.10760788289641803790@ietfa.amsl.com> Date: Mon, 17 Jun 2019 09:09:53 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-15.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:10:04 -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-15.txt Pages : 51 Date : 2019-06-17 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. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-15 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 Jun 17 09:15:18 2019 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 5ADC21202CA for ; Mon, 17 Jun 2019 09:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=Rc2A3S26; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=0BPt/0XO 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 rCINAKlvTE4z for ; Mon, 17 Jun 2019 09:15:13 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1701202BF for ; Mon, 17 Jun 2019 09:15:10 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A4A1F8FF for ; Mon, 17 Jun 2019 12:15:09 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 17 Jun 2019 12:15:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=G1INDh1 dtFw8PJ78/NG7N/1iWfUIP7e6MzHpVg3tmsY=; b=Rc2A3S26ySWpoJhBybupo1N ZTnoVZJI3ufW7bcPyjF9XqNwylEjQMDHfA/oDYU3rNNRQi591eyf6jnRu1P89xOg jTfK+ssQBF3Qqq1dRyHFYYw36YvJbpuWdeBj5XFeZPbFUaudRTpBU3hH4tJVqHHp 3bn/z7qYfPqPMUfGVs7iJa+1TG+3/H/L1Ab1ryklKCJ2ZBaYC4T9t/LnFTUkAzN+ i6H8OIQ/OIdOQbboxnWsli9dhH9cIm1h5jnKdjaUiXXKnJqGHG+rBAJ/o5R1C3WQ 9mEw89xWqFcef7OnUwCRYxzMADN+V7osLyChPr/+Ba/7d6nyNzW9XLbF64bMh2A= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=G1INDh 1dtFw8PJ78/NG7N/1iWfUIP7e6MzHpVg3tmsY=; b=0BPt/0XOd3lZSL1D14ohCn 6//MdzLc3JcWR6z8ajCqK+Idmg9MgF6CtUfSUpZi0d+g4vhe7h1EifraB7ru986t S8arr3dE8IOEVmSAasgLYdd0FTkIEtz35+KEQS2u/pkt4qZOzSqBzmwKdLiaBgzT MkKWar2qT92FNPrMKo8sXZkf06C+0RMtdSZbuAs9lUWz8fcebHFAzo3jv69Si3Au mhzTQzFI7psO+D3MQ3AKUczHbHhjhySkemi6yJ8+zF/zv7msoT3MFM1bkMom6vo0 FeQK27420nX0KguX3TR/iHGc3c1rHQqk4BLQ76H63cH/LN/N5iZVip0k7+ZUeq6A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeijedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrgh enucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AED101806DD; Mon, 17 Jun 2019 12:15:08 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-666-gb2312fa-fmstable-20190614v4 Mime-Version: 1.0 Message-Id: <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> In-Reply-To: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> Date: Mon, 17 Jun 2019 18:14:54 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=2fd0060f27a94ed1aa1f39734d173e37 Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:15:17 -0000 --2fd0060f27a94ed1aa1f39734d173e37 Content-Type: text/plain I have uploaded RFC draft version 15 which now includes the proposed changes. I chose to keep the name "isAllDay" for the property, rather than renaming it to "showAsAllDay". I also removed the "isAllDay" property entirely from the JSTask object. See https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1.4 >From my initial analysis, the mapping to iCalendar is rather simple: * If the JSEvent timeZone is null, the start time has zero time, and the duration is a multiple of days or weeks, then DTSTART is of type DATE. In this case, clip off any non-zero time from the recurrence rule "until" property. * Otherwise map "start" to a DTSTART of type DATE-TIME. * I also consider using a new iCalendar boolean property IS-ALL-DAY to cleanly map "isAllDay". I will update the informational iCalendar mapping guideline accordingly. Cheers, Robert On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote: > One of the repeatedly discussed topics in JSCalendar is how to model all-day events. > > Specifically, variants of the following uses repeatedly come up, where the current JSCalendar model seems not to be adequate: > > * Calendar users create an event starting e.g. 8am and ending 7pm, but want to view this an all-day event in their UI. The current model misses a flag to express this, as the isAllDay property is not appropriate to indicate the user intention. > * Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI. > > In both cases, developers thought to use the isAllDay property to express a user intention, but came they learn they couldn't. > > This is reason enough to revisit that part of the specification and discuss alternatives. > > *Currently*: > * Any event MUST define a start property value in the form "YYYY-MM-DDTHH:MM:SS[.DIGITS]" > * An all-day event: > * MUST have the isAllDay property set to "true" > * MUST NOT have a non-zero time in the start and duration property values > * MUST NOT define a time zone > * Any other event: > * MUST have the isAllDay property set to "false" > * MAY define non-zero time in start, duration > * MAY set a timeZone. > * This allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME, UTC DATE-TIME. > > *Alternative*: > * The isAllDay boolean property gets removed. > * A new showAsAllDay boolean defines how the user intends to view this event. Setting this property does not have any implications on the allowed values in the event time properties. > * The start, duration, timeZone properties and their recurrence overrides can all can be defined independently. The recurrenceRule{until} property also can be defined independently. > * It is up to implementations to convert this time model to iCalendar. Most probably: > * an event with zero time in start, duration, until and no time zone will be converted DATE value types > * an event with no time zone will be converted to a local DATE-TIME without TZID > * otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME > > What do you think? Did we miss something? > > Cheers, > Robert > > > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --2fd0060f27a94ed1aa1f39734d173e37 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I have upl= oaded RFC draft version 15 which now includes the proposed changes. I ch= ose to keep the name "isAllDay" for the property, rather than renaming i= t to "showAsAllDay". I also removed the "isAllDay" property entirely fro= m the JSTask object.




Cheers,








=
calsify mailing list
calsify@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/calsify


--2fd0060f27a94ed1aa1f39734d173e37-- From nobody Mon Jun 17 09:18:24 2019 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 48BCC12031D for ; Mon, 17 Jun 2019 09:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 RQoo_0AkAUya for ; Mon, 17 Jun 2019 09:18:18 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780048.outbound.protection.outlook.com [40.107.78.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB166120269 for ; Mon, 17 Jun 2019 09:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tN1zln8Kj+cLoH3rtJWGq14tRsOhpcEy20DQXO64rcc=; b=eO/gVLZczWRq2yWPQo5PFiQTBfjs5sRvgCPE3+gwEg5oO3ewGd52O+W6qeKl7/fPVkcnumo2WKvvxECYjJqFOg5GjOXkpFYoYMDYHZ11S9wQyUkJaPByk5isSNw8lDQyFe803SEcfn/Wjp/9/Dn5e5rlgzVNlHvzajDkQWifphM= Received: from DM6PR15MB3531.namprd15.prod.outlook.com (10.141.164.29) by DM6PR15MB2985.namprd15.prod.outlook.com (20.178.231.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Mon, 17 Jun 2019 16:17:59 +0000 Received: from DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::15f0:ad13:112d:529d]) by DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::15f0:ad13:112d:529d%7]) with mapi id 15.20.1987.014; Mon, 17 Jun 2019 16:17:58 +0000 From: Daniel Migault To: Robert Stepanek , "calsify@ietf.org" Thread-Topic: [calsify] JSCalendar: alternative to current all-day events Thread-Index: AQHVHIBx+fLBwFvQJUyJaCxTZRiMbKagFpcAgAAAXuA= Date: Mon, 17 Jun 2019 16:17:58 +0000 Message-ID: References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> In-Reply-To: <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> 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=daniel.migault@ericsson.com; x-originating-ip: [192.75.88.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41c8e1a4-9666-4fb7-e5d0-08d6f33f5d18 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR15MB2985; x-ms-traffictypediagnostic: DM6PR15MB2985: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0071BFA85B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(346002)(376002)(366004)(199004)(189003)(25786009)(3846002)(5660300002)(6246003)(14454004)(8936002)(52536014)(2906002)(229853002)(6436002)(110136005)(71200400001)(71190400001)(256004)(486006)(966005)(6306002)(81156014)(81166006)(14444005)(6116002)(790700001)(446003)(476003)(9686003)(33656002)(11346002)(44832011)(236005)(53936002)(64756008)(66556008)(7736002)(66446008)(86362001)(76176011)(66066001)(478600001)(26005)(316002)(2501003)(55016002)(8676002)(54896002)(186003)(99286004)(68736007)(102836004)(73956011)(76116006)(66946007)(6506007)(66476007)(74316002)(606006)(53546011)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2985; H:DM6PR15MB3531.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PSimi5smoffVffpXczcS7GRWv/vxwo2JNMr49YqNWYiOYqc0LXZJjQGFJHaMd/PIihVlQKBpyhuptgc4WY2XBLgBl2AhVb97ekvL7i6ZC252+2q/c3WsROx+59tnrmrOdTpVGGDlJ+38JXUaKBuUcrwMbvNwbGs2WfvALhkQ4PVqYGgjUWxeywkSa1OEjw91v1Dz2O/6K+MswgAlEGUtNFbJbKMEAlecEoKRRadC9A8IInxz/JFj9usH4k3Ct/YM3LryaGtJIF+CYw0T82AvLn7Z8U9tYVbkGTEiQ/7AacO65NwgK9knQXaH0mRyuOeQ6n/57MhuS20PYLMxPNWrmOH9C156005ufnKTihzH6CJ1YrubLGODa2xPfe2KaZgLJUnRLjV6NJfzmFbQYaUoYqbyApx0d3/fU+6QF5P2fSE= Content-Type: multipart/alternative; boundary="_000_DM6PR15MB3531538370731F00D0363A6CE3EB0DM6PR15MB3531namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41c8e1a4-9666-4fb7-e5d0-08d6f33f5d18 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2019 16:17:58.8436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: daniel.migault@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2985 Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:18:21 -0000 --_000_DM6PR15MB3531538370731F00D0363A6CE3EB0DM6PR15MB3531namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Robert for the clarification. If there are any other point to discus= s or that are raising concerns, please let us know as we are close to move = the document forward. Yours, Daniel From: calsify On Behalf Of Robert Stepanek Sent: Monday, June 17, 2019 12:15 PM To: calsify@ietf.org Subject: Re: [calsify] JSCalendar: alternative to current all-day events I have uploaded RFC draft version 15 which now includes the proposed change= s. I chose to keep the name "isAllDay" for the property, rather than renami= ng it to "showAsAllDay". I also removed the "isAllDay" property entirely fr= om the JSTask object. See https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1= .4 >From my initial analysis, the mapping to iCalendar is rather simple: * If the JSEvent timeZone is null, the start time has zero time, and th= e duration is a multiple of days or weeks, then DTSTART is of type DATE. In= this case, clip off any non-zero time from the recurrence rule "until" pro= perty. * Otherwise map "start" to a DTSTART of type DATE-TIME. * I also consider using a new iCalendar boolean property IS-ALL-DAY to = cleanly map "isAllDay". I will update the informational iCalendar mapping guideline accordingly. Cheers, Robert On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote: One of the repeatedly discussed topics in JSCalendar is how to model all-da= y events. Specifically, variants of the following uses repeatedly come up, where the = current JSCalendar model seems not to be adequate: * Calendar users create an event starting e.g. 8am and ending 7pm, but = want to view this an all-day event in their UI. The current model misses a = flag to express this, as the isAllDay property is not appropriate to indica= te the user intention. * Calendar users want to set their calendar on their birthday, when the= y only would like to set it for the complete day in their usual time zone. = They still want it to show up as an all-day event in their UI. In both cases, developers thought to use the isAllDay property to express a= user intention, but came they learn they couldn't. This is reason enough to revisit that part of the specification and discuss= alternatives. Currently: * Any event MUST define a start property value in the form "YYYY-MM-DDT= HH:MM:SS[.DIGITS]" * An all-day event: * MUST have the isAllDay property set to "true" * MUST NOT have a non-zero time in the start and duration property v= alues * MUST NOT define a time zone * Any other event: * MUST have the isAllDay property set to "false" * MAY define non-zero time in start, duration * MAY set a timeZone. * This allows to model iCalendar DATE, local DATE-TIME, floating DATE-T= IME, UTC DATE-TIME. Alternative: * The isAllDay boolean property gets removed. * A new showAsAllDay boolean defines how the user intends to view this = event. Setting this property does not have any implications on the allowed = values in the event time properties. * The start, duration, timeZone properties and their recurrence overrid= es can all can be defined independently. The recurrenceRule{until} property= also can be defined independently. * It is up to implementations to convert this time model to iCalendar. = Most probably: * an event with zero time in start, duration, until and no time zone= will be converted DATE value types * an event with no time zone will be converted to a local DATE-TIME = without TZID * otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME What do you think? Did we miss something? Cheers, Robert _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --_000_DM6PR15MB3531538370731F00D0363A6CE3EB0DM6PR15MB3531namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Robert for the clarification. If there are an= y other point to discuss or that are raising concerns, please let us know a= s we are close to move the document forward.

Yours,

Daniel

 

From: calsify <calsify-bounces@ietf.org>= ; On Behalf Of Robert Stepanek
Sent: Monday, June 17, 2019 12:15 PM
To: calsify@ietf.org
Subject: Re: [calsify] JSCalendar: alternative to current all-day ev= ents

 

I have uploaded RFC draft version 15 which now inclu= des the proposed changes. I chose to keep the name "isAllDay" for= the property, rather than renaming it to "showAsAllDay". I also = removed the "isAllDay" property entirely from the JSTask object.

 

 

From my initial analysis, the mapping to iCalendar i= s rather simple:

  • If the JSEvent timeZone is null, the start time has zero time, and the dura= tion is a multiple of days or weeks, then DTSTART is of type DATE. In this = case, clip off any non-zero time from the recurrence rule "until"= property.
  • Otherwise map "start" to a DTSTART of type DATE-TIME.<= /li>
  • I also consider using a new iCalendar boolean property IS-ALL-DAY to cleanl= y map "isAllDay".

 

I will update the informational iCalendar mapping gu= ideline accordingly.

 

Cheers,

Robert

 

On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wro= te:

One of the repeatedly discussed topics in JSCalendar= is how to model all-day events.

 

Specifically, variants of the following uses repeate= dly come up, where the current JSCalendar model seems not to be adequate:

 

  • Calendar users create an event starting e.g. 8am and ending 7pm, but want t= o view this an all-day event in their UI. The current model misses a flag t= o express this, as the isAllDay property is not appropriate to indicate the= user intention.
  • Calendar users want to set their calendar on their birthday, when they only= would like to set it for the complete day in their usual time zone. They s= till want it to show up as an all-day event in their UI.

    •  

    In both cases, developers thought to use the isAllDa= y property to express a user intention, but came they learn they couldn't.<= o:p>

     

    This is reason enough to revisit that part of the sp= ecification and discuss alternatives.

     

    Currently:

  • Any event MUST define a start property value in the form "YYYY-MM-DDTH= H:MM:SS[.DIGITS]"
  • An all-day event:
    • MUST have the isAllDay property set to "true"
    • MUST NOT have a non-zero time in the start and duration property values
    • MUST NOT define a time zone
  • Any other event:
    • MUST have the isAllDay property set to "false"
      • MAY define non-zero time  in start, duration
    • MAY set a timeZone.
  • This allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME, U= TC DATE-TIME.

 

Alternative:

  • The isAllDay boolean property gets removed.
  • A new showAsAllDay boolean defines how the user intends to view this event.= Setting this property does not have any implications on the allowed values= in the event time properties.
  • The start, duration, timeZone properties and their recurrence overrides can= all can be defined independently. The recurrenceRule{until} property also = can be defined independently.
  • It is up to implementations to convert this time model to iCalendar. Most p= robably:
    • an event with zero time in start, duration, until and no time zone will be = converted DATE value types
    • an event with no time zone will be converted to a local DATE-TIME without T= ZID
    • otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME
      • =

 

What do you think? Did we miss something?=

 

Cheers,

Robert

 

 

 

 

 

_______________________________________________=

calsify mailing list

 

 

--_000_DM6PR15MB3531538370731F00D0363A6CE3EB0DM6PR15MB3531namp_-- From nobody Mon Jun 17 09:23:03 2019 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 469281201D0 for ; Mon, 17 Jun 2019 09:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=J+e8hkAP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RiE9ulZi 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 YsU9Yv8MbWOF for ; Mon, 17 Jun 2019 09:22:58 -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 BA4BF12035B for ; Mon, 17 Jun 2019 09:22:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E68182235E; Mon, 17 Jun 2019 12:22:57 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 17 Jun 2019 12:22:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=ZdakZGK kPQJYFYBA83v0SMv4F/acDr9KN3ZfJlHBScA=; b=J+e8hkAPJN4my8O2jOgZBLN AfO0YBsSvHUATJKpre53uLhGc9uzSDLmA9v2fihsJfyOLbQiji/FrsWFcBGDuRGo IpreUjaw2K2vnXAaKvCyOi8P1TVPsKdApvwg0Y2Kwj5piRF6fVR4b+xlUnXSO6H1 bu99hel8uJqM7cJ+stvIkeOor8QuM00XWi6xErqBAzELlKDp4HGYgzYoukO7dCz2 wJu387wn3SkreTjhBHjfW8JdrRoCsTlxKgS6hYjrYa+ZXbxjFkPNHk4gvErOQSKe wsG6GWSWkDZtg10ucg7XKmU0evtE8sImssyZH5nF4TTZvBvZuzH3Jzr5mqZpcrw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ZdakZG KkPQJYFYBA83v0SMv4F/acDr9KN3ZfJlHBScA=; b=RiE9ulZip8qRNcJ3yTWhEp Ws2kSrd5fFFAZ3bvYXya9OPP8KJq4vTfNHGjslfZn6BVRJ9n/6FohMHr4mZzdPFS BqQ/zomxNvOSxb7AkTv67qMZD4Oht7rJbBfWxgQ/iUGiS2sUtQ7EhGUGCF1rm+CZ hKedVTZaQsZQs+ena17BK7qNrE/x0zsDJunZuV9Y/7AGkNDbT3hTM3L2QHfGVG1S 9CYoXrG7JnAeXBAZQ9ephZW8vMVznOD0/Le+p6ttsVwK94wA8geZXv3B5nRiHuON XggQ+F3kOhEnIf1+jkC9NjkydVxDDUNUie/pHc/avVwwHMZhh/RFOCSDCdFXrQoQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeijedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedftfho sggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehfrghsthhmrghilhhtvggrmhdrtg homheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhho mheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AE8E41806DD; Mon, 17 Jun 2019 12:22:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-666-gb2312fa-fmstable-20190614v4 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> Date: Mon, 17 Jun 2019 18:22:56 +0200 From: "Robert Stepanek" To: "Daniel Migault" , "calsify@ietf.org" Content-Type: multipart/alternative; boundary=09f8cd18aa3e4f819d7769227fd10e74 Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:23:02 -0000 --09f8cd18aa3e4f819d7769227fd10e74 Content-Type: text/plain Hi Daniel, I am not aware of any open points, the draft includes all feedback we got. I suggest to move this document forward, irrespective of its accompanying informational RFC https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar. I will update the latter in the next few days. Cheers, Robert On Mon, Jun 17, 2019, at 6:18 PM, Daniel Migault wrote: > Thanks Robert for the clarification. If there are any other point to discuss or that are raising concerns, please let us know as we are close to move the document forward. > Yours, > Daniel > > *From:* calsify *On Behalf Of *Robert Stepanek > *Sent:* Monday, June 17, 2019 12:15 PM > *To:* calsify@ietf.org > *Subject:* Re: [calsify] JSCalendar: alternative to current all-day events > > I have uploaded RFC draft version 15 which now includes the proposed changes. I chose to keep the name "isAllDay" for the property, rather than renaming it to "showAsAllDay". I also removed the "isAllDay" property entirely from the JSTask object. > > See https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1.4 > > From my initial analysis, the mapping to iCalendar is rather simple: > * If the JSEvent timeZone is null, the start time has zero time, and the duration is a multiple of days or weeks, then DTSTART is of type DATE. In this case, clip off any non-zero time from the recurrence rule "until" property. > * Otherwise map "start" to a DTSTART of type DATE-TIME. > * I also consider using a new iCalendar boolean property IS-ALL-DAY to cleanly map "isAllDay". > > I will update the informational iCalendar mapping guideline accordingly. > > Cheers, > Robert > > On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote: >> One of the repeatedly discussed topics in JSCalendar is how to model all-day events. >> >> Specifically, variants of the following uses repeatedly come up, where the current JSCalendar model seems not to be adequate: >> >> * Calendar users create an event starting e.g. 8am and ending 7pm, but want to view this an all-day event in their UI. The current model misses a flag to express this, as the isAllDay property is not appropriate to indicate the user intention. >> * Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI. >> >> In both cases, developers thought to use the isAllDay property to express a user intention, but came they learn they couldn't. >> >> This is reason enough to revisit that part of the specification and discuss alternatives. >> >> *Currently*: >> * Any event MUST define a start property value in the form "YYYY-MM-DDTHH:MM:SS[.DIGITS]" >> * An all-day event: >> * MUST have the isAllDay property set to "true" >> * MUST NOT have a non-zero time in the start and duration property values >> * MUST NOT define a time zone >> * Any other event: >> * MUST have the isAllDay property set to "false" >> * MAY define non-zero time in start, duration >> * MAY set a timeZone. >> * This allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME, UTC DATE-TIME. >> >> *Alternative*: >> * The isAllDay boolean property gets removed. >> * A new showAsAllDay boolean defines how the user intends to view this event. Setting this property does not have any implications on the allowed values in the event time properties. >> * The start, duration, timeZone properties and their recurrence overrides can all can be defined independently. The recurrenceRule{until} property also can be defined independently. >> * It is up to implementations to convert this time model to iCalendar. Most probably: >> * an event with zero time in start, duration, until and no time zone will be converted DATE value types >> * an event with no time zone will be converted to a local DATE-TIME without TZID >> * otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME >> >> What do you think? Did we miss something? >> >> Cheers, >> Robert >> >> >> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > --09f8cd18aa3e4f819d7769227fd10e74 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Daniel,=

I am not aware of any open points, the dra= ft includes all feedback we got.

I suggest = to move this document forward, irrespective of its accompanying informat= ional RFC https://tools.ietf.org/html/draft-ietf-calext-jscalenda= r-icalendar. I will update the latter in the next few days.

Cheers,
Robert

On Mon, Jun 17, 2019, at 6:18 PM, Daniel Migault wrote:
=

Thanks Robert for the clarification. If there are a= ny other point to discuss or that are raising concerns, please let us kn= ow as we are close to move the document forward.

Yours,

Daniel

 

From: calsify <calsify-bounces@iet= f.org> On Behalf Of Robert Stepanek
Sent: Monday, June 17, 2019 12:15 PM
To: calsify@ietf.= org
Subject: Re: [calsify] JSCalendar: alternative= to current all-day events

 

I have uploaded RF= C draft version 15 which now includes the proposed changes. I chose to k= eep the name "isAllDay" for the property, rather than renaming it to "sh= owAsAllDay". I also removed the "isAllDay" property entirely from the JS= Task object.

From my initial analysis, the mapping to iCalendar is rather sim= ple:

  • If the JSEvent timeZone is null, the start time has zero time, and the= duration is a multiple of days or weeks, then DTSTART is of type DATE. = In this case, clip off any non-zero time from the recurrence rule "until= " property.
  • Otherwise map = "start" to a DTSTART of type DATE-TIME.
  • I also consider using a new iCalendar boolean property IS-= ALL-DAY to cleanly map "isAllDay".

 

I will update = the informational iCalendar mapping guideline accordingly.

=

 

Cheers,

Robert
=

 

On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wro= te:

One of the repeat= edly discussed topics in JSCalendar is how to model all-day events.
<= /p>

 

Specifically, variants of the following uses repeated= ly come up, where the current JSCalendar model seems not to be adequate:=

 

<= ul type=3D"disc">
  • Calendar users cr= eate an event starting e.g. 8am and ending 7pm, but want to view this an= all-day event in their UI. The current model misses a flag to express t= his, as the isAllDay property is not appropriate to indicate the user in= tention.
  • Calendar users wa= nt to set their calendar on their birthday, when they only would like to= set it for the complete day in their usual time zone. They still want i= t to show up as an all-day event in their UI.

    •  

    In = both cases, developers thought to use the isAllDay property to express a= user intention, but came they learn they couldn't.

     

    This is reason enough to revisit that part of the specification and d= iscuss alternatives.

     <= br>

    Currently:

    • Any eve= nt MUST define a start property value in the form "YYYY-MM-DDTHH:MM:SS[.= DIGITS]"
    • An all-day event:=
      • MUST have the isAllDay property set to "true"
        • =
      • MUST NOT have a non-zero time in t= he start and duration property values
      • MUST NOT define a time zone
    • Any other event:
    =
      • MUST have the isAllDay property set to "false"
      • MAY define non-zero time  in start, durati= on
      • MAY set a timeZone.
        =
    • T= his allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME,= UTC DATE-TIME.

     

    Alternative:

    =
    • The isAllDay boo= lean property gets removed.
    • A new showAsAllDay boolean defines how the user intends to view this e= vent. Setting this property does not have any implications on the allowe= d values in the event time properties.
    • The start, duration, timeZone properties and their recurren= ce overrides can all can be defined independently. The recurrenceRule{un= til} property also can be defined independently.
    • It is up to implementations to convert this time = model to iCalendar. Most probably:
      • an event with zero t= ime in start, duration, until and no time zone will be converted DATE va= lue types
      • an event with no= time zone will be converted to a local DATE-TIME without TZID
        • <= li style=3D"" class=3D"qt-MsoNormal">otherwise it will be a DATE-TIME wi= th TZID or UTC DATE-TIME

     

    What do you think? = Did we miss something?

     = ;

    Cheers,

    =

    Robert

     

     

     

     

     <= br>

    ____________________________= ___________________

    calsify = mailing list

     

     


    --09f8cd18aa3e4f819d7769227fd10e74-- From nobody Mon Jun 17 09:43:37 2019 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 7A1901203B7; Mon, 17 Jun 2019 09:43:34 -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_HELO_NONE=0.001, 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 0tyy2XJHq5Tg; Mon, 17 Jun 2019 09:43:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9C619120375; Mon, 17 Jun 2019 09:43:25 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5HGhKM9030148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jun 2019 12:43:22 -0400 Date: Mon, 17 Jun 2019 11:43:19 -0500 From: Benjamin Kaduk To: Michael Douglass Cc: The IESG , draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org Message-ID: <20190617164319.GG52381@kduck.mit.edu> References: <155908852723.25806.3708247030243239163.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:43:35 -0000 On Tue, Jun 11, 2019 at 11:11:01PM -0400, Michael Douglass wrote: > > On 5/28/19 20:08, Benjamin Kaduk via Datatracker wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I want to talk some about the redefinition of SOURCE. While I agree > > that the original definition's applicability is more narrow than it > > needs to be, that doesn't seem to be enough to convince me that there's > > enough justification to make it so broad as to provide vcard information > > about a participant or an event link-back, as opposed to just the > > canonical source of updates for a given object/component. I must > > apologize for having essentially not done a search of the WG discussion > > archives for this topic, and pointers into the archive could help to > > convince me that this redefinition is a stable, interoperable, and > > backwards-compatible choice. > On this particular issue I've come round to agreeing with the points > made here and in other messages. As an alternative i was considering > suggesting dropping the VALUE=TEXT. Having a vcard inline can always be > handled with a data uri. > > However, it seems to me that I can come closer to the intent by using > the STRUCTURED-DATA property - it is intended to provide supporting data > and of course there's no backwards compatibility issues. > > Does this seem an appropriate way forward? > It seems appropriate to me (with the caveat that I am not a domain expert here). Thanks, Ben From nobody Mon Jun 17 10:44:14 2019 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 9F12E120496 for ; Mon, 17 Jun 2019 10:44:12 -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=sywm5uEt; dkim=pass (2048-bit key) header.d=srs1.zonevs.eu header.b=wytS2PYC; dkim=pass (2048-bit key) header.d=dot.ee header.b=m7wM99uG 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 kMedadrS41dz for ; Mon, 17 Jun 2019 10:44:07 -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 07E83120493 for ; Mon, 17 Jun 2019 10:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=nGFt6GoNJTepS20MITwjXDSOY52yQElGhyUvYc4iepA=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=sywm5uEtJDvYVVdzl9eGi4nO0ov5Lkg1KXJRAP70B0i+vd+R6ocjHW7fRjsMY8a1dEyeIxqXf 1QkOTTSBNrzyXaPjvWPmf0CtBxkuQTldQWnPOBOqiSv78MKeClhS85HK9QOgRxT9lWbDZQqvew4 KLIxVw42O7B9U9cjbDiLGQoYXXGlkwzg6JxpmMktQq334xmrFglmKLW7C82ajc7OseZt9imLUnK AKSwqRlEfcN6ZeszF36yv4+Suv8eL4a0W9AIyzoi2XKQoe0mTuFRD0u4CZlHKzcFD+F+oO4GW9j 8WZeHP8cXvAGofJr8sOlfQ0o+4Sqw7uBqIKFgerbY9/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs1.zonevs.eu; q=dns/txt; s=oct2016; bh=nGFt6GoNJTepS20MITwjXDSOY52yQElGhyUvYc4iepA=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=wytS2PYCAmoF+1qVGTsO+W6kuq00/T5zj69/9GumOGA8XxYsQ/idZjsev+7IcMS0Lr2nlQfD+ EnM5ez+jFmz5WUROdesfigxZkdETMER5yLrJbVQX1cXAsNJiIT7jEXrks6HW50V17glmE5X04Nb qYZZ0SWC3QwG5uwrjlLcrj7XYhkchVW3AAcDWC/IasM8ihl1BuWH5FepnBbFvmn7thWdHbfDEVH bl02yAR9cb3o9rKh4syZAdS+ld7RC4X5CZFmCIreMygRkSQhVDONHm89j9RbHS7kPJrQeylpZhT qfx1Ew7AI/3RUlfW8QNJskKvIsPbyOSeqG7QvRWXzrrQ== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs1.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 16b6689e7d70000d2d.001 for ; Mon, 17 Jun 2019 17:44:02 +0000 X-Zone-Loop: f242a5928caa48c0ff21c104b45abe4dc47bbf5d65a9 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.ee (Postfix) with ESMTPSA id F0F79128B5C4 for ; Mon, 17 Jun 2019 20:44:01 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1560793442; bh=OkYi1f/rjoU7zOCtm2mEh78uPQSWhpOK0jMNHaWDoYs=; h=Subject:To:References:From:Date:In-Reply-To; b=m7wM99uGDmPQlvtSmAm8h7fgQn23ZG/2eAtRpq2ZE5NOzpajA5bfR+5ejblFro4d8 C7X13Zrb19qS6acREc4HCL64qVdcMiZkz4Sv71NsvSV5go21EklcYuRbOdWUYCEgee vtoGEkDq3SZcrVledVwwvsZ76YI0gNIo6objn9wdDDPuHwxWB0F/UG+sZZ/8U5Fuqq 91oT7YfAucmGY6n6Nv+RHIoN6I6r02DJ1Sq5+JMto5Y3A4SOPRfxoVCsDUyoReocyW j+ZNJW52fERLCBr8OCOO9lmqAtr3IhTpfqCX+USNzaljj/YzDKTt0eUJX45QWjnuzh Mbv/qppcWNACg== To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <3d19b106-c5ae-0bfe-7afc-72540ea10623@dot.ee> Date: Mon, 17 Jun 2019 17:44:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7930397B8FF2F680A58ECDD7" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-1.473384, required=15, tests=[R_DKIM_ALLOW=-0.2, NEURAL_HAM=0, TO_DN_NONE=0, PREVIOUSLY_DELIVERED=0, RCVD_TLS_ALL=0, BAYES_HAM=-3, RCVD_COUNT_ONE=0, RCVD_VIA_SMTP_AUTH=0, FROM_HAS_DN=0, ASN=0, HFILTER_HOSTNAME_5=3, RCPT_COUNT_ONE=0, URI_COUNT_ODD=1, IP_SCORE=-2.273384, FROM_EQ_ENVFROM=0, MIME_GOOD=-0.1, MID_RHS_MATCH_FROM=0, DKIM_TRACE=0, ARC_NA=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 17:44:13 -0000 This is a multi-part message in MIME format. --------------7930397B8FF2F680A58ECDD7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > If the JSEvent timeZone is null, the start time has zero time, and the > duration is a multiple of days or weeks, then DTSTART is of type DATE. > In this case, clip off any non-zero time from the recurrence rule > "until" property. This probably got covered early in JSCalendar's life, so apologies for bringing it up again, but how did JSCalendar end up with no date type? The above sounds like a error prone and complicated heuristic approach to something that should just be explicit. Why didn't JSCalendar include a date type for events with dates and keep the time type for events with times? I'm willing to take bets there will be implementations that miss the "timeZone is null" clause and accidentally truncate timed events with nominal durations. And while on the subject, isn't calling the date-time formats `UTCDate` and `LocalDate` (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-3.2.1) slightly misleading given they're date-times? On 6/17/19 4:22 PM, Robert Stepanek wrote: > Hi Daniel, > > I am not aware of any open points, the draft includes all feedback we got. > > I suggest to move this document forward, irrespective of its > accompanying informational RFC > https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar. > I > will update the latter in the next few days. > > Cheers, > Robert > > On Mon, Jun 17, 2019, at 6:18 PM, Daniel Migault wrote: >> >> Thanks Robert for the clarification. If there are any other point to >> discuss or that are raising concerns, please let us know as we are >> close to move the document forward. >> >> Yours, >> >> Daniel >> >> >> *From:* calsify *On Behalf Of *Robert Stepanek >> *Sent:* Monday, June 17, 2019 12:15 PM >> *To:* calsify@ietf.org >> *Subject:* Re: [calsify] JSCalendar: alternative to current all-day >> events >> >> >> I have uploaded RFC draft version 15 which now includes the proposed >> changes. I chose to keep the name "isAllDay" for the property, rather >> than renaming it to "showAsAllDay". I also removed the "isAllDay" >> property entirely from the JSTask object. >> >> >> See >> https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1.4 >> >> >> From my initial analysis, the mapping to iCalendar is rather simple: >> >> * If the JSEvent timeZone is null, the start time has zero time, >> and the duration is a multiple of days or weeks, then DTSTART is >> of type DATE. In this case, clip off any non-zero time from the >> recurrence rule "until" property. >> * Otherwise map "start" to a DTSTART of type DATE-TIME. >> * I also consider using a new iCalendar boolean property IS-ALL-DAY >> to cleanly map "isAllDay". >> >> >> I will update the informational iCalendar mapping guideline accordingly. >> >> >> Cheers, >> >> Robert >> >> >> On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote: >> >> One of the repeatedly discussed topics in JSCalendar is how to >> model all-day events. >> >> >> Specifically, variants of the following uses repeatedly come up, >> where the current JSCalendar model seems not to be adequate: >> >> >> * Calendar users create an event starting e.g. 8am and ending >> 7pm, but want to view this an all-day event in their UI. The >> current model misses a flag to express this, as the isAllDay >> property is not appropriate to indicate the user intention. >> * Calendar users want to set their calendar on their birthday, >> when they only would like to set it for the complete day in >> their usual time zone. They still want it to show up as an >> all-day event in their UI. >> >> >> In both cases, developers thought to use the isAllDay property to >> express a user intention, but came they learn they couldn't. >> >> >> This is reason enough to revisit that part of the specification >> and discuss alternatives. >> >> >> *Currently*: >> >> * Any event MUST define a start property value in the form >> "YYYY-MM-DDTHH:MM:SS[.DIGITS]" >> * An all-day event: >> >> o MUST have the isAllDay property set to "true" >> o MUST NOT have a non-zero time in the start and duration >> property values >> o MUST NOT define a time zone >> >> * Any other event: >> >> o MUST have the isAllDay property set to "false" >> o MAY define non-zero time  in start, duration >> o MAY set a timeZone. >> >> * This allows to model iCalendar DATE, local DATE-TIME, >> floating DATE-TIME, UTC DATE-TIME. >> >> >> *Alternative*: >> >> * The isAllDay boolean property gets removed. >> * A new showAsAllDay boolean defines how the user intends to >> view this event. Setting this property does not have any >> implications on the allowed values in the event time properties. >> * The start, duration, timeZone properties and their recurrence >> overrides can all can be defined independently. The >> recurrenceRule{until} property also can be defined independently. >> * It is up to implementations to convert this time model to >> iCalendar. Most probably: >> >> o an event with zero time in start, duration, until and no >> time zone will be converted DATE value types >> o an event with no time zone will be converted to a local >> DATE-TIME without TZID >> o otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME >> >> >> What do you think? Did we miss something? >> >> >> Cheers, >> >> Robert >> >> >> >> >> >> >> _______________________________________________ >> >> 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 --------------7930397B8FF2F680A58ECDD7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    If the JSEvent timeZone is null, the start time has zero time, and the duration is a multiple of days or weeks, then DTSTART is of type DATE. In this case, clip off any non-zero time from the recurrence rule "until" property.

    This probably got covered early in JSCalendar's life, so apologies for bringing it up again, but how did JSCalendar end up with no date type? The above sounds like a error prone and complicated heuristic approach to something that should just be explicit. Why didn't JSCalendar include a date type for events with dates and keep the time type for events with times? I'm willing to take bets there will be implementations that miss the "timeZone is null" clause and accidentally truncate timed events with nominal durations.

    And while on the subject, isn't calling the date-time formats `UTCDate` and `LocalDate` (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-3.2.1) slightly misleading given they're date-times?

    On 6/17/19 4:22 PM, Robert Stepanek wrote:
    Hi Daniel,

    I am not aware of any open points, the draft includes all feedback we got.

    I suggest to move this document forward, irrespective of its accompanying informational RFC https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar. I will update the latter in the next few days.

    Cheers,
    Robert

    On Mon, Jun 17, 2019, at 6:18 PM, Daniel Migault wrote:

    Thanks Robert for the clarification. If there are any other point to discuss or that are raising concerns, please let us know as we are close to move the document forward.

    Yours,

    Daniel

     

    From: calsify <calsify-bounces@ietf.org> On Behalf Of Robert Stepanek
    Sent: Monday, June 17, 2019 12:15 PM
    Subject: Re: [calsify] JSCalendar: alternative to current all-day events

     

    I have uploaded RFC draft version 15 which now includes the proposed changes. I chose to keep the name "isAllDay" for the property, rather than renaming it to "showAsAllDay". I also removed the "isAllDay" property entirely from the JSTask object.

     

     

    From my initial analysis, the mapping to iCalendar is rather simple:

    • If the JSEvent timeZone is null, the start time has zero time, and the duration is a multiple of days or weeks, then DTSTART is of type DATE. In this case, clip off any non-zero time from the recurrence rule "until" property.
    • Otherwise map "start" to a DTSTART of type DATE-TIME.
    • I also consider using a new iCalendar boolean property IS-ALL-DAY to cleanly map "isAllDay".

     

    I will update the informational iCalendar mapping guideline accordingly.

     

    Cheers,

    Robert

     

    On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote:

    One of the repeatedly discussed topics in JSCalendar is how to model all-day events.

     

    Specifically, variants of the following uses repeatedly come up, where the current JSCalendar model seems not to be adequate:

     

    • Calendar users create an event starting e.g. 8am and ending 7pm, but want to view this an all-day event in their UI. The current model misses a flag to express this, as the isAllDay property is not appropriate to indicate the user intention.
    • Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI.

     

    In both cases, developers thought to use the isAllDay property to express a user intention, but came they learn they couldn't.

     

    This is reason enough to revisit that part of the specification and discuss alternatives.

     

    Currently:

    • Any event MUST define a start property value in the form "YYYY-MM-DDTHH:MM:SS[.DIGITS]"
    • An all-day event:
      • MUST have the isAllDay property set to "true"
      • MUST NOT have a non-zero time in the start and duration property values
      • MUST NOT define a time zone
    • Any other event:
      • MUST have the isAllDay property set to "false"
      • MAY define non-zero time  in start, duration
      • MAY set a timeZone.
    • This allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME, UTC DATE-TIME.

     

    Alternative:

    • The isAllDay boolean property gets removed.
    • A new showAsAllDay boolean defines how the user intends to view this event. Setting this property does not have any implications on the allowed values in the event time properties.
    • The start, duration, timeZone properties and their recurrence overrides can all can be defined independently. The recurrenceRule{until} property also can be defined independently.
    • It is up to implementations to convert this time model to iCalendar. Most probably:
      • an event with zero time in start, duration, until and no time zone will be converted DATE value types
      • an event with no time zone will be converted to a local DATE-TIME without TZID
      • otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME

     

    What do you think? Did we miss something?

     

    Cheers,

    Robert

     

     

     

     

     

    _______________________________________________

    calsify mailing list

     

     



    _______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
    --------------7930397B8FF2F680A58ECDD7-- From nobody Mon Jun 17 14:48:54 2019 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 34943120180 for ; Mon, 17 Jun 2019 14:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_NONE=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 hZVb9gtMCQSS for ; Mon, 17 Jun 2019 14:48:48 -0700 (PDT) Received: from mailrelay4-1.pub.mailoutpod1-cph3.one.com (mailrelay4-1.pub.mailoutpod1-cph3.one.com [46.30.210.185]) (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 B1E441200D5 for ; Mon, 17 Jun 2019 14:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=hwyylLAR+liy82Tt8k6uwCj3O54NO34/W1PiduBqebY=; b=mDVX3JnDGrIYr7/2necYjH0HE/SLwZbo81wOv8n+fZg4qXtu4/EEydhYWPJH1+JZ40/Ac77MmK68C jiPiSAStF2Ra1Qqkr+s3gfki6HwS/J27snfXlC8IshycnjyorzxuYgMaHKlvc2Q8dMmaNpJ7xGFqnU fDh66KYJO/GCoViA= X-HalOne-Cookie: 0e903284a5afbebf0755b8e8045914f955e06bcf X-HalOne-ID: ac9c773a-9149-11e9-abcd-d0431ea8bb10 Received: from smtp.dmfs.org (unknown [2003:5f:6e14:3c00:201:2eff:fe40:2624]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id ac9c773a-9149-11e9-abcd-d0431ea8bb10; Mon, 17 Jun 2019 21:48:42 +0000 (UTC) Received: from boss.localdomain (p548B1ED8.dip0.t-ipconnect.de [84.139.30.216]) by smtp.dmfs.org (Postfix) with ESMTPSA id 6473686 for ; Mon, 17 Jun 2019 23:48:42 +0200 (CEST) To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> <3d19b106-c5ae-0bfe-7afc-72540ea10623@dot.ee> From: Marten Gajda Message-ID: <246c6142-45c3-e7ed-259d-02646a07b171@dmfs.org> Date: Mon, 17 Jun 2019 23:48:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <3d19b106-c5ae-0bfe-7afc-72540ea10623@dot.ee> Content-Type: multipart/alternative; boundary="------------730C7293DC0DBE5617229425" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 21:48:52 -0000 This is a multi-part message in MIME format. --------------730C7293DC0DBE5617229425 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Andri, Am 17.06.19 um 19:44 schrieb Andri Möll: > >> If the JSEvent timeZone is null, the start time has zero time, and >> the duration is a multiple of days or weeks, then DTSTART is of type >> DATE. In this case, clip off any non-zero time from the recurrence >> rule "until" property. > > This probably got covered early in JSCalendar's life, so apologies for > bringing it up again, but how did JSCalendar end up with no date type? > Indeed we've been talking about this and there was mostly consensus in that a date type (as used in iCalendar) encodes two things: * value: a point in (local) time, i.e. midnight (the start) of that particular day * presentation: show as all-day These are, however, two unrelated things. "all-day" is really just a UI issue and has no effect on the calendar math. Aside from the presentation, an all-day event is the same as an event which explicitly starts at midnight and has a duration of full days. There are even use cases when you might want to present an event like an "all-day" event even though it doesn't have a duration of full days or even though it may not start or end at midnight. Also, sometimes, the date type falsely suggests an interpretation as a range (midnight to midnight). I've seen discussions on whether a date-type EXDATE would cancel all/any occurrences of a recurring date-time event on that day. In addition: DTSTART:20190617 is the implicit form. It implies a time component of 00:00:00 and a presentation as all-day event, whereas start: 2019-06-17T00:00:00 isAllDay: true is the explicit form. Both properties are explicitly stated. >  I'm willing to take bets there will be implementations that miss the > "timeZone is null" clause and accidentally truncate timed events with > nominal durations. > This is actually a perfect example for why the implicit date type is a bad idea and why the explicit form of JSCalendar is much better. You have to make sure *all* preconditions (implications) are met before you can use the implicit form. This is not an issue with the explicit form and it's not a problem of JSCalendar (the problem is iCalendar). JSCalendar is supposed to be the successor of iCalendar and to fix some its well known issues. This is one of them. Eventually JSCalendar will replace iCalendar and the conversion won't be necessary anymore. A correct data model has a higher priority than the conversion to legacy formats. > And while on the subject, isn't calling the date-time formats > `UTCDate` and `LocalDate` > (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-3.2.1) > slightly misleading given they're date-times? > I have no strong feelings on this particular issue. Given that, in the current spec, *all* date values have a time component there is no need to emphasize this fact again in the name of the type. On the other hand I wouldn't mind if these were called "UTCDateTime" and "LocalDateTime". Cheers, Marten > On 6/17/19 4:22 PM, Robert Stepanek wrote: >> Hi Daniel, >> >> I am not aware of any open points, the draft includes all feedback we >> got. >> >> I suggest to move this document forward, irrespective of its >> accompanying informational RFC >> https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar. >> >> I will update the latter in the next few days. >> >> Cheers, >> Robert >> >> On Mon, Jun 17, 2019, at 6:18 PM, Daniel Migault wrote: >>> >>> Thanks Robert for the clarification. If there are any other point to >>> discuss or that are raising concerns, please let us know as we are >>> close to move the document forward. >>> >>> Yours, >>> >>> Daniel >>> >>>   >>> >>> *From:* calsify *On Behalf Of *Robert >>> Stepanek >>> *Sent:* Monday, June 17, 2019 12:15 PM >>> *To:* calsify@ietf.org >>> *Subject:* Re: [calsify] JSCalendar: alternative to current all-day >>> events >>> >>>   >>> >>> I have uploaded RFC draft version 15 which now includes the proposed >>> changes. I chose to keep the name "isAllDay" for the property, >>> rather than renaming it to "showAsAllDay". I also removed the >>> "isAllDay" property entirely from the JSTask object. >>> >>>   >>> >>> See >>> https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1.4 >>> >>>   >>> >>> From my initial analysis, the mapping to iCalendar is rather simple: >>> >>> * If the JSEvent timeZone is null, the start time has zero time, >>> and the duration is a multiple of days or weeks, then DTSTART is >>> of type DATE. In this case, clip off any non-zero time from the >>> recurrence rule "until" property. >>> * Otherwise map "start" to a DTSTART of type DATE-TIME. >>> * I also consider using a new iCalendar boolean property >>> IS-ALL-DAY to cleanly map "isAllDay". >>> >>>   >>> >>> I will update the informational iCalendar mapping guideline accordingly. >>> >>>   >>> >>> Cheers, >>> >>> Robert >>> >>>   >>> >>> On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote: >>> >>> One of the repeatedly discussed topics in JSCalendar is how to >>> model all-day events. >>> >>>   >>> >>> Specifically, variants of the following uses repeatedly come up, >>> where the current JSCalendar model seems not to be adequate: >>> >>>   >>> >>> * Calendar users create an event starting e.g. 8am and ending >>> 7pm, but want to view this an all-day event in their UI. The >>> current model misses a flag to express this, as the isAllDay >>> property is not appropriate to indicate the user intention. >>> * Calendar users want to set their calendar on their birthday, >>> when they only would like to set it for the complete day in >>> their usual time zone. They still want it to show up as an >>> all-day event in their UI. >>> >>>   >>> >>> In both cases, developers thought to use the isAllDay property >>> to express a user intention, but came they learn they couldn't. >>> >>>   >>> >>> This is reason enough to revisit that part of the specification >>> and discuss alternatives. >>> >>>   >>> >>> *Currently*: >>> >>> * Any event MUST define a start property value in the form >>> "YYYY-MM-DDTHH:MM:SS[.DIGITS]" >>> * An all-day event: >>> >>> o MUST have the isAllDay property set to "true" >>> o MUST NOT have a non-zero time in the start and duration >>> property values >>> o MUST NOT define a time zone >>> >>> * Any other event: >>> >>> o MUST have the isAllDay property set to "false" >>> o MAY define non-zero time  in start, duration >>> o MAY set a timeZone. >>> >>> * This allows to model iCalendar DATE, local DATE-TIME, >>> floating DATE-TIME, UTC DATE-TIME. >>> >>>   >>> >>> *Alternative*: >>> >>> * The isAllDay boolean property gets removed. >>> * A new showAsAllDay boolean defines how the user intends to >>> view this event. Setting this property does not have any >>> implications on the allowed values in the event time properties. >>> * The start, duration, timeZone properties and their >>> recurrence overrides can all can be defined independently. >>> The recurrenceRule{until} property also can be defined >>> independently. >>> * It is up to implementations to convert this time model to >>> iCalendar. Most probably: >>> >>> o an event with zero time in start, duration, until and no >>> time zone will be converted DATE value types >>> o an event with no time zone will be converted to a local >>> DATE-TIME without TZID >>> o otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME >>> >>>   >>> >>> What do you think? Did we miss something? >>> >>>   >>> >>> Cheers, >>> >>> Robert >>> >>>   >>> >>>   >>> >>>   >>> >>>   >>> >>>   >>> >>> _______________________________________________ >>> >>> 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 > > _______________________________________________ > 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 --------------730C7293DC0DBE5617229425 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    Hi Andri,

    Am 17.06.19 um 19:44 schrieb Andri Möll:

    If the JSEvent timeZone is null, the start time has zero time, and the duration is a multiple of days or weeks, then DTSTART is of type DATE. In this case, clip off any non-zero time from the recurrence rule "until" property.

    This probably got covered early in JSCalendar's life, so apologies for bringing it up again, but how did JSCalendar end up with no date type?

    Indeed we've been talking about this and there was mostly consensus in that a date type (as used in iCalendar) encodes two things:

    * value: a point in (local) time, i.e. midnight (the start) of that particular day
    * presentation: show as all-day

    These are, however, two unrelated things. "all-day" is really just a UI issue and has no effect on the calendar math. Aside from the presentation, an all-day event is the same as an event which explicitly starts at midnight and has a duration of full days. There are even use cases when you might want to present an event like an "all-day" event even though it doesn't have a duration of full days or even though it may not start or end at midnight.

    Also, sometimes, the date type falsely suggests an interpretation as a range (midnight to midnight). I've seen discussions on whether a date-type EXDATE would cancel all/any occurrences of a recurring date-time event on that day.

    In addition:

    DTSTART:20190617

    is the implicit form. It implies a time component of 00:00:00 and a presentation as all-day event, whereas

    start: 2019-06-17T00:00:00
    isAllDay: true

    is the explicit form. Both properties are explicitly stated.

     I'm willing to take bets there will be implementations that miss the "timeZone is null" clause and accidentally truncate timed events with nominal durations.

    This is actually a perfect example for why the implicit date type is a bad idea and why the explicit form of JSCalendar is much better. You have to make sure *all* preconditions (implications) are met before you can use the implicit form. This is not an issue with the explicit form and it's not a problem of JSCalendar (the problem is iCalendar).

    JSCalendar is supposed to be the successor of iCalendar and to fix some its well known issues. This is one of them. Eventually JSCalendar will replace iCalendar and the conversion won't be necessary anymore. A correct data model has a higher priority than the conversion to legacy formats.

    And while on the subject, isn't calling the date-time formats `UTCDate` and `LocalDate` (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-3.2.1) slightly misleading given they're date-times?

    I have no strong feelings on this particular issue. Given that, in the current spec, *all* date values have a time component there is no need to emphasize this fact again in the name of the type. On the other hand I wouldn't mind if these were called "UTCDateTime" and "LocalDateTime".

    Cheers,

    Marten

    On 6/17/19 4:22 PM, Robert Stepanek wrote:
    Hi Daniel,

    I am not aware of any open points, the draft includes all feedback we got.

    I suggest to move this document forward, irrespective of its accompanying informational RFC https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar. I will update the latter in the next few days.

    Cheers,
    Robert

    On Mon, Jun 17, 2019, at 6:18 PM, Daniel Migault wrote:

    Thanks Robert for the clarification. If there are any other point to discuss or that are raising concerns, please let us know as we are close to move the document forward.

    Yours,

    Daniel

     

    From: calsify <calsify-bounces@ietf.org> On Behalf Of Robert Stepanek
    Sent: Monday, June 17, 2019 12:15 PM
    Subject: Re: [calsify] JSCalendar: alternative to current all-day events

     

    I have uploaded RFC draft version 15 which now includes the proposed changes. I chose to keep the name "isAllDay" for the property, rather than renaming it to "showAsAllDay". I also removed the "isAllDay" property entirely from the JSTask object.

     

     

    From my initial analysis, the mapping to iCalendar is rather simple:

    • If the JSEvent timeZone is null, the start time has zero time, and the duration is a multiple of days or weeks, then DTSTART is of type DATE. In this case, clip off any non-zero time from the recurrence rule "until" property.
    • Otherwise map "start" to a DTSTART of type DATE-TIME.
    • I also consider using a new iCalendar boolean property IS-ALL-DAY to cleanly map "isAllDay".

     

    I will update the informational iCalendar mapping guideline accordingly.

     

    Cheers,

    Robert

     

    On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote:

    One of the repeatedly discussed topics in JSCalendar is how to model all-day events.

     

    Specifically, variants of the following uses repeatedly come up, where the current JSCalendar model seems not to be adequate:

     

    • Calendar users create an event starting e.g. 8am and ending 7pm, but want to view this an all-day event in their UI. The current model misses a flag to express this, as the isAllDay property is not appropriate to indicate the user intention.
    • Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI.

     

    In both cases, developers thought to use the isAllDay property to express a user intention, but came they learn they couldn't.

     

    This is reason enough to revisit that part of the specification and discuss alternatives.

     

    Currently:

    • Any event MUST define a start property value in the form "YYYY-MM-DDTHH:MM:SS[.DIGITS]"
    • An all-day event:
      • MUST have the isAllDay property set to "true"
      • MUST NOT have a non-zero time in the start and duration property values
      • MUST NOT define a time zone
    • Any other event:
      • MUST have the isAllDay property set to "false"
      • MAY define non-zero time  in start, duration
      • MAY set a timeZone.
    • This allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME, UTC DATE-TIME.

     

    Alternative:

    • The isAllDay boolean property gets removed.
    • A new showAsAllDay boolean defines how the user intends to view this event. Setting this property does not have any implications on the allowed values in the event time properties.
    • The start, duration, timeZone properties and their recurrence overrides can all can be defined independently. The recurrenceRule{until} property also can be defined independently.
    • It is up to implementations to convert this time model to iCalendar. Most probably:
      • an event with zero time in start, duration, until and no time zone will be converted DATE value types
      • an event with no time zone will be converted to a local DATE-TIME without TZID
      • otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME

     

    What do you think? Did we miss something?

     

    Cheers,

    Robert

     

     

     

     

     

    _______________________________________________

    calsify mailing list

     

     



    _______________________________________________
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

    -- 
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
    --------------730C7293DC0DBE5617229425-- From nobody Mon Jun 17 15:04:20 2019 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 2E6541202F1 for ; Mon, 17 Jun 2019 15:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_NONE=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 Eif3mYCi110a for ; Mon, 17 Jun 2019 15:04:16 -0700 (PDT) Received: from mailrelay3-1.pub.mailoutpod1-cph3.one.com (mailrelay3-1.pub.mailoutpod1-cph3.one.com [46.30.210.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9ED12004D for ; Mon, 17 Jun 2019 15:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=+Iy48D/oavXFHTfRIjVL1G61IyCno+m0z7b61RbExME=; b=fIr8UNi6jHjgDZE1LURk/lkoQjdepiqlrHCNaXQNWuYYB1IoxkopEoq6a4S8cxSH6pdNzU4LKkajm NZZwNspCyHAe1QtDYkYEDkxUcmMLM/WzBiMUOnh7bT/s1DdyAJFjVAgshbNiqiQ6qV9fAh/lpfLP1o iV4vxrtHXhk+6jdc= X-HalOne-Cookie: 0775b3919b2e773786c01fab9fa68bb83d9e1a49 X-HalOne-ID: d692aac5-914b-11e9-a0e4-d0431ea8bb03 Received: from smtp.dmfs.org (unknown [84.129.207.176]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id d692aac5-914b-11e9-a0e4-d0431ea8bb03; Mon, 17 Jun 2019 22:04:12 +0000 (UTC) Received: from boss.localdomain (p548B1ED8.dip0.t-ipconnect.de [84.139.30.216]) by smtp.dmfs.org (Postfix) with ESMTPSA id C53B629B for ; Tue, 18 Jun 2019 00:04:11 +0200 (CEST) To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> From: Marten Gajda Message-ID: Date: Tue, 18 Jun 2019 00:04:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------512DF6065737B46D56F58912" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 22:04:19 -0000 This is a multi-part message in MIME format. --------------512DF6065737B46D56F58912 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 17.06.19 um 18:14 schrieb Robert Stepanek: > I also removed the "isAllDay" property entirely from the JSTask object. Hmm ... I see how "isAllDay" doesn't really apply to a task, but it would be nice to have a way to express this kind of fussiness for start and/or due dates in cases when the actual time is not that important (or even unknown). Always terminating tasks on a specific time can give a false sense of accuracy which might not exist. Sometimes you just want to express "at some time throughout that day". Does that make sense? Marten > > See > https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1.4 > > From my initial analysis, the mapping to iCalendar is rather simple: > > * If the JSEvent timeZone is null, the start time has zero time, and > the duration is a multiple of days or weeks, then DTSTART is of > type DATE. In this case, clip off any non-zero time from the > recurrence rule "until" property. > * Otherwise map "start" to a DTSTART of type DATE-TIME. > * I also consider using a new iCalendar boolean property IS-ALL-DAY > to cleanly map "isAllDay". > > > I will update the informational iCalendar mapping guideline accordingly. > > Cheers, > Robert > > On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote: >> One of the repeatedly discussed topics in JSCalendar is how to model >> all-day events. >> >> Specifically, variants of the following uses repeatedly come up, >> where the current JSCalendar model seems not to be adequate: >> >> * Calendar users create an event starting e.g. 8am and ending 7pm, >> but want to view this an all-day event in their UI. The current >> model misses a flag to express this, as the isAllDay property is >> not appropriate to indicate the user intention. >> * Calendar users want to set their calendar on their birthday, when >> they only would like to set it for the complete day in their >> usual time zone. They still want it to show up as an all-day >> event in their UI. >> >> >> In both cases, developers thought to use the isAllDay property to >> express a user intention, but came they learn they couldn't. >> >> This is reason enough to revisit that part of the specification and >> discuss alternatives. >> >> *Currently*: >> >> * Any event MUST define a start property value in the form >> "YYYY-MM-DDTHH:MM:SS[.DIGITS]" >> * An all-day event: >> o MUST have the isAllDay property set to "true" >> o MUST NOT have a non-zero time in the start and duration >> property values >> o MUST NOT define a time zone >> * Any other event: >> o MUST have the isAllDay property set to "false" >> o MAY define non-zero time  in start, duration >> o MAY set a timeZone. >> * This allows to model iCalendar DATE, local DATE-TIME, floating >> DATE-TIME, UTC DATE-TIME. >> >> >> *Alternative*: >> >> * The isAllDay boolean property gets removed. >> * A new showAsAllDay boolean defines how the user intends to view >> this event. Setting this property does not have any implications >> on the allowed values in the event time properties. >> * The start, duration, timeZone properties and their recurrence >> overrides can all can be defined independently. The >> recurrenceRule{until} property also can be defined independently. >> * It is up to implementations to convert this time model to >> iCalendar. Most probably: >> o an event with zero time in start, duration, until and no time >> zone will be converted DATE value types >> o an event with no time zone will be converted to a local >> DATE-TIME without TZID >> o otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME >> >> >> What do you think? Did we miss something? >> >> Cheers, >> Robert >> >> >> >> >> >> _______________________________________________ >> 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 -- 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 --------------512DF6065737B46D56F58912 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


    Am 17.06.19 um 18:14 schrieb Robert Stepanek:
    I also removed the "isAllDay" property entirely from the JSTask object.

    Hmm ... I see how "isAllDay" doesn't really apply to a task, but it would be nice to have a way to express this kind of fussiness for start and/or due dates in cases when the actual time is not that important (or even unknown). Always terminating tasks on a specific time can give a false sense of accuracy which might not exist. Sometimes you just want to express "at some time throughout that day". Does that make sense?

    Marten



    From my initial analysis, the mapping to iCalendar is rather simple:
    • If the JSEvent timeZone is null, the start time has zero time, and the duration is a multiple of days or weeks, then DTSTART is of type DATE. In this case, clip off any non-zero time from the recurrence rule "until" property.
    • Otherwise map "start" to a DTSTART of type DATE-TIME.
    • I also consider using a new iCalendar boolean property IS-ALL-DAY to cleanly map "isAllDay".

    I will update the informational iCalendar mapping guideline accordingly.

    Cheers,
    Robert

    On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote:
    One of the repeatedly discussed topics in JSCalendar is how to model all-day events.

    Specifically, variants of the following uses repeatedly come up, where the current JSCalendar model seems not to be adequate:

    • Calendar users create an event starting e.g. 8am and ending 7pm, but want to view this an all-day event in their UI. The current model misses a flag to express this, as the isAllDay property is not appropriate to indicate the user intention.
    • Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI.

    In both cases, developers thought to use the isAllDay property to express a user intention, but came they learn they couldn't.

    This is reason enough to revisit that part of the specification and discuss alternatives.

    Currently:
    • Any event MUST define a start property value in the form "YYYY-MM-DDTHH:MM:SS[.DIGITS]"
    • An all-day event:
      • MUST have the isAllDay property set to "true"
      • MUST NOT have a non-zero time in the start and duration property values
      • MUST NOT define a time zone
    • Any other event:
      • MUST have the isAllDay property set to "false"
      • MAY define non-zero time  in start, duration
      • MAY set a timeZone.
    • This allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME, UTC DATE-TIME.

    Alternative:
    • The isAllDay boolean property gets removed.
    • A new showAsAllDay boolean defines how the user intends to view this event. Setting this property does not have any implications on the allowed values in the event time properties.
    • The start, duration, timeZone properties and their recurrence overrides can all can be defined independently. The recurrenceRule{until} property also can be defined independently.
    • It is up to implementations to convert this time model to iCalendar. Most probably:
      • an event with zero time in start, duration, until and no time zone will be converted DATE value types
      • an event with no time zone will be converted to a local DATE-TIME without TZID
      • otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME

    What do you think? Did we miss something?

    Cheers,
    Robert





    _______________________________________________
    calsify mailing list



    _______________________________________________
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
    --------------512DF6065737B46D56F58912-- From nobody Mon Jun 17 16:16:35 2019 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 6F093120130 for ; Mon, 17 Jun 2019 16:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tYjkluztucgK for ; Mon, 17 Jun 2019 16:16:31 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 C112A12004F for ; Mon, 17 Jun 2019 16:16:31 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id h6so25358369ioh.3 for ; Mon, 17 Jun 2019 16:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=5IOQJLYQ1xUxD9G0d3wzeSChy8vJSn3Yr67MRDnuSFc=; b=HRPfZPii7PbFTYv8AQw3CoIT8y0+0LteiByIv41cxl+6E39HArAewwnoMqOrQk7Xnh aBFATY/0PSGS8MMGWWtq1Yrs1kmTLzEMHX8vKr4Q2cOUyYzawdMGcMNgcSGCDQDOyi8b uz23VOiNoFiCcNiAGpAzDP2RaY8+h+k/aSI+jcmCQ4FIYI99kgarsueM/IaL6Dc8KCfk FjRbWZOstWzvJJAcc+HVHLC2q1XV+N5Rf1Ud3TjS0zhVI3y2SjZg2i1vGnJlhKycvfkx WcDAHgw597jZmnhW28TJrWhxsMlwXKV8i+P1oxqRrSfsHmyskG4QFJgIgfHFVO5SCUoD zbQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=5IOQJLYQ1xUxD9G0d3wzeSChy8vJSn3Yr67MRDnuSFc=; b=nOzL0+wBJw98oSLICimgD0Chlmi2Lti2NbrHg+b8seELjsfSkQvVqQsdJlU6sAsp99 aQiUZW+iHszB9pN5LLQ0TYnncYW83+svmmbdzywe7y3DMjNnRUqQtKKJI/9f93UiAC1X xoyc/BOUrZrhEGPIIKUwJ6jS3jpGBG2ASfoSeiGahsi4ffyWuU8U9QsYgeaThZm3xX/w xovc4rlJ7ZglaaU6NJsfk9VsQnBA5bEAKvhDq12lcFWiKDOJ8m0Rc68Q02kZ4ExyLlTY P4ZGmxwj8WCiyKvo8ZIOSDvCNSaFTKenSmZJY3/YxvzklZD1hg6VJvWI3TBPGKrVUDeA enXA== X-Gm-Message-State: APjAAAXYvnJMKXgXn/FNd9Glwhff+cf1a0fYNHSjVbX7gA5fOCqTeAsq JHpcq1uf0qsqS2/jLNoXbRxeTJxng2Cd X-Google-Smtp-Source: APXvYqx7nOB6FP0Zon+7iEICREVaCSrdVgO0j4wffztb3PaRfgpGOJq+k+JGL2akR+XygYoI7fkmcQ== X-Received: by 2002:a6b:8b8b:: with SMTP id n133mr32924825iod.183.1560813390595; Mon, 17 Jun 2019 16:16:30 -0700 (PDT) Received: from [192.168.1.7] ([174.27.172.40]) by smtp.googlemail.com with ESMTPSA id l11sm18664287ioj.32.2019.06.17.16.16.29 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 16:16:29 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <596bfc3f-375d-205e-9ce2-de3e1c9301b4@gmail.com> Date: Mon, 17 Jun 2019 17:16:28 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050902090904070806010802" Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 23:16:33 -0000 This is a cryptographically signed message in MIME format. --------------ms050902090904070806010802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/17/19 10:14 AM, Robert Stepanek wrote: > I have uploaded RFC draft version 15 which now includes the proposed=20 > changes. I chose to keep the name "isAllDay" for the property, rather=20 > than renaming it to "showAsAllDay". I also removed the "isAllDay"=20 > property entirely from the JSTask object. >=20 > See=20 > https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1= =2E4 And add a description of "all day", because it is not "all day". Is it you want it to be marked on the calendar, but be free time? --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms050902090904070806010802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE3MjMxNjI4WjAvBgkq hkiG9w0BCQQxIgQgdhVhJts8sUiDug1+wpoToAUyi9CGfnj5/lPXcNseWq0wbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQBSNrrOqPDM+lw6OS5viV+Y6pllwXSUg/YenDx3cZV+hoEW51/+ 0cUwBttmOHupjxaRlO1oPqN6r2Ma2QwlS3UQLDUjT3jm8tuDtu093ibTDRo3uI4MfPPfr46P mAw4+3s1GjuaGPYx7gSJ5QI68lUFQ3ubyytEAxX/0L1/si/tCRHfEnlFdyWgCVbtat6mqDbf Vqgzh7hIVVa77hW1FtbEdMlfFv1iechmcJX/A9KYuxtqZxIABhVgjZzGjZrK8Qrx5DvDF+7b sCWoSiTMDEd6mtnSTfWEVo0/Pu5cgSq++x8BRZ32YyFO4StpUWQY0tq6pdlsi5MwVj/XMnSV cg8KAAAAAAAA --------------ms050902090904070806010802-- From nobody Mon Jun 17 16:25:42 2019 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 8B01212032D for ; Mon, 17 Jun 2019 16:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 73i3yyZZUzb9 for ; Mon, 17 Jun 2019 16:25:40 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 A56DC120130 for ; Mon, 17 Jun 2019 16:25:40 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id h6so25399760ioh.3 for ; Mon, 17 Jun 2019 16:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=sNX5QGr66K/0i/DT9fcPKsVWG7j8TuW75va/UL7PmDU=; b=tejd95lXhBPKd8Ht8wRZNN5KGcckGu2j5RdftfohcKYcAH2lRWEbfV+763LKcFHlJT HtE6/CJUiD0HKOH1Xn9hZ7aPdPDE52oRghoh6yz/cDuJ9OEX0dFziOnjZ6cSixlht49E 1nIESR+89PKXS+cVTALQ2Vf/IdvyXaqLNFQd3gIcMkkZMm8lUiPfXNGIpNrPr9jyBHDQ ucHI4oT/zAnkvif6OQnGITom9tXJ5bxf7mjHldQe78YAKrE4JubDOqTGIaZqrfbnf1tq pViXIpjzn35bREzsLvTx0BndHJIdaFXU4uAA0bkltiLG0txM5lfQwNEZm0d8Uz5MgTOK D/BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=sNX5QGr66K/0i/DT9fcPKsVWG7j8TuW75va/UL7PmDU=; b=JmegyE35GpjztzeOYprgFElNmBcz+83R/WPwnxWMd4eHw2P36OcijJd0jGSlFRR5h3 vFUE0imkdqG+Co1dKFnhjeJyStlfYxZn3C55LscqA7UX5UnsdSo8xQFgchpjLUjdbzOw ZhQKzE2OJc+kPAQs6amU8j+whBv8Ue9rjgzzNIkLKgNS7CNW30wINSRwXRqjo0plPmI9 ++gYLo5fKDLtECLngpuObucYxYW521e2Uz5YulxHd/fSOLriEk9dMuOTVWjl2vSWmQhk kLLLVzr9WJPl3ZWRhHf3ZTktEHBpaBXklhAkrdjw45vGUFewIoXryzRSM3QNPDpbzcvR TAsA== X-Gm-Message-State: APjAAAUtll4TuI1PRqCyR5brD2WsmSIwcTooM0ccOKt7rpiZt2uC1hrq kZaRY/M736G7vNPJZy/+YezoVARxrSKO X-Google-Smtp-Source: APXvYqwZDdzjQbUzLOyooUfGjAJa5OtztHTIZahC41vxmUx+fhfa1Wb1wj4xZRg7COyLEX8RJB7XJg== X-Received: by 2002:a5e:9b05:: with SMTP id j5mr925792iok.75.1560813939660; Mon, 17 Jun 2019 16:25:39 -0700 (PDT) Received: from [192.168.1.7] ([174.27.172.40]) by smtp.googlemail.com with ESMTPSA id k3sm5709255iog.76.2019.06.17.16.25.38 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 16:25:38 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Mon, 17 Jun 2019 17:25:37 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090700020900000004070109" Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 23:25:41 -0000 This is a cryptographically signed message in MIME format. --------------ms090700020900000004070109 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable "Indicates whether this event is meant to represent an all-day event, and SHOULD be presented accordingly in a calendaring application. The value of this property is independent of the actual time-span covered by this event." So, an isAllDay could as an example, be 36 or more hours long? --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms090700020900000004070109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE3MjMyNTM3WjAvBgkq hkiG9w0BCQQxIgQgD4tpK6ciGr+ujnV8exxLNwQnfjNxL0tmCKMVkiodQ+MwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQA59cHMmQAxBOaaG3tke1SeqjziIJIOJ70RWDdvd0/Oykpud2sp ftIE1Sdhy+Fbt0k3fF1Yng5b00xQVNbaTmdLvkuU1lqHMcaHmfoTX+0XEr9RFxazooSsDE3k PMOx55m4IhWGeSeHFdlww8FIIgo2DTxBf7KPbellcsdfZEQSjTksHGA/39u9CViHSP7FQAjs BzpgSuO5o43/EY9YL1w7W9TtrTdOCCSiIOT6gIzmA6oA4O+RsUBeh1HJx5ZiWlsvCSDl98ec L8VJb/RiwrZL4b1tuVgpS8ewEW98QVjqn4TDO47q7eyKNCB9ZpDBG9AfcqzmIHYrkawPSQcQ b8bCAAAAAAAA --------------ms090700020900000004070109-- From nobody Mon Jun 17 17:39:53 2019 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 9FC01120130 for ; Mon, 17 Jun 2019 17:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=JU62ktfW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XFL4wDB+ 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 43_n2INuz2QC for ; Mon, 17 Jun 2019 17:39:50 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B8212003F for ; Mon, 17 Jun 2019 17:39:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1504322382 for ; Mon, 17 Jun 2019 20:39:49 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 17 Jun 2019 20:39:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=9vy6j9c ijkDRBjrislA7uf6muO30D0x93GWjwMnsYyk=; b=JU62ktfWpMO1jNhGGZaabO/ UdyJGhaa3DtHvxr2IpaA7pyJ1zmbthDA4u3Hbx90wIZurL+5V8ybz5OhF7LUADly MIlXlXFUEXxkAPFYYSLyblInFox7kAf9ukHiuhZhbi97M2A7f1f9PC4AN73rbt80 AT9FQKpe8QpUTVM6vhRU7oszLS+AgB6EXOOx8d0tKC2cH3KrLUIQF3NguuoUGt60 yUXHEG8usxCZVtWBjbJwaFqg201t/4k7FPQqIpGJgem7/UF4nO6iJeHisTlbZxC2 bVsV73XkxYhg5BICBqm7+GDQtmZcONbK4NgUdbb7fDeS7HxG3GKv2PxBVw3VbDw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9vy6j9 cijkDRBjrislA7uf6muO30D0x93GWjwMnsYyk=; b=XFL4wDB+MdCTPHnF17LEKr jR7siEpQmZyEkSvzA/PAOJ7IVbuSA4bRv4QNItDDd6gV891r9iN9pUTw8yMLmb0y 7NrrVqZ8sNdOHX1uvMlvpW0CdEkuHQE+L7zOcWffM+U3enLLbMgW6+iuxOdvuw8u 1xlkcUBrelk05PRdBqA+ad4q2Qg+kINtXrbAeKjyTil5RraAckOomYDdFk41bLnL mwKQ58An90FDIjn+B4Eorgm0fStLEyAuCe9QIOOOHvlekjeJ6vRCbTUGJ2U+dDMF U6pGIuMCerVYaaJSYrrMb8rAx6jjyhXvvs1JFri3lwo6C2I05oyUcB/GPEaVZj2g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeikedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsg hrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7D7061803AC; Mon, 17 Jun 2019 20:39:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-666-gb2312fa-fmstable-20190614v4 Mime-Version: 1.0 Message-Id: <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> In-Reply-To: References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> Date: Tue, 18 Jun 2019 10:39:48 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=f7c7b9e0a5bf445eb24b405f7086b9f2 Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 00:39:52 -0000 --f7c7b9e0a5bf445eb24b405f7086b9f2 Content-Type: text/plain On Tue, Jun 18, 2019, at 09:25, Doug Royer wrote: > "Indicates whether this event is meant to represent an all-day event, > and SHOULD be presented accordingly in a calendaring application. > The value of this property is independent of the actual time-span > covered by this event." > > > So, an isAllDay could as an example, be 36 or more hours long? It certainly could. This is already very possible with iCalendar, e.g. this event here: BEGIN:VCALENDAR VERSION:2.0 CALSCALE:GREGORIAN PRODID:-//FastMail/1.0/EN BEGIN:VEVENT CREATED:20190219T071436Z DTEND;VALUE=DATE:20190608 DTSTAMP:20190219T071436Z DTSTART;VALUE=DATE:20190603 SEQUENCE:0 SUMMARY:CalConnect Bedford TRANSP:TRANSPARENT UID:xxx END:VEVENT END:VCALENDAR Which is an "all day event" with a duration of 5 days. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --f7c7b9e0a5bf445eb24b405f7086b9f2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Tue, Jun 18, 2019, at 09:25, Doug Royer wrote:
      "Indicates whether this= event is meant to represent an all-day event,
      = ;  and SHOULD be presented accordingly in a calendaring application= .
        The value of this property is indepen= dent of the actual time-span
        covered by= this event."


    So, an isAllDa= y could as an example, be 36 or more hours long?
    <= div style=3D"font-family:Arial;">
    It certainly could.  This is already very possible with iCalen= dar, e.g. this event here:
    BEGIN:VCALENDAR
    VERSION:2.0
    CALSCALE:GREGORIAN
    PRODID:-//FastMail/1.0/EN
    B= EGIN:VEVENT
    CREATED:20190219T= 071436Z
    DTEND;VALUE=3DDATE:20= 190608
    DTSTAMP:20190219T07143= 6Z
    DTSTART;VALUE=3DDATE:20190= 603
    SEQUENCE:0
    SUMMARY:CalConnect Bedford
    TRANSP:TRANSPARENT
    UID:xxx
    END:= VEVENT
    END:VCALENDAR

    Which is an "all day event" with a duration of 5 days.
    <= div style=3D"font-family:Arial;">
    Bron.
    --<= br>
      Bron Gondwana, CEO, FastMail Pt= y Ltd
      brong@fastmailteam.com


    --f7c7b9e0a5bf445eb24b405f7086b9f2-- From nobody Mon Jun 17 20:16:06 2019 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 4CC1E120116 for ; Mon, 17 Jun 2019 20:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=f+EbO7Gg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=luqSQ1Z/ 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 CacwnYVicfOc for ; Mon, 17 Jun 2019 20:16:02 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1387612003F for ; Mon, 17 Jun 2019 20:16:02 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E366C22136 for ; Mon, 17 Jun 2019 23:16:00 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 17 Jun 2019 23:16:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=xOJ2bh6 5kifxbc7A3aW3FRJjG3RFDBalqeOK3S0Pwq4=; b=f+EbO7GgviWgiQC968qhPxF 4lW8qSvQ9GK4VkK5VbKYiMbJDMQFpKkMI0drpUi8StsUTUOmTCPvV71sZB26UGrK gkDKYy5ze7R3iPQPUJpxdoRD8BfPsj3i8RBIL1tmzje8koDhzLrw2BCGTVC5UNCP TpbZVxR/wFm7UV8UscgQOe6J/zoqmcWFhxldU9p1G7LlXji/nVsilzYmT89B1Whc 4ktBZBeutRbe6fs2TLrUQkEbQXdhfyyo1yyicjoi1/FoDb+1YHFZcxsCQiD48foK VGVyOVd77eC86UKMMi0BBFvk2mkyPpU5WHeoQBbkv1H9CxckKEcA80ahGVPQKGQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=xOJ2bh 65kifxbc7A3aW3FRJjG3RFDBalqeOK3S0Pwq4=; b=luqSQ1Z/U6mxjOspQXftsf Pa/cgXxkLzDpCyahOq6vad45y48z5ZA6K+rAJEDKRm0HLBATTijwfQsLr/+8YlGU KkviMp3WL06zCXbIQIOP1KjSe/nZ9z3rTaazAvNMfgrVdmOTZc6u5ktyRS3NGN/p ZmcylxtV2Gy/7uyjHxr4CXqoWO49UuHir5kI5cfyzKQ1InHnLtEaM4zgV8yJcnae 1QwvETKUNzmvbcHQiJDSKJ+CY3ZCZb/cCd+AuF/b7Ns7YYyTSVt3QaXHlXNpfR8Q N60edhgf/JZhNruRKouJFCxzm2TsgxcWWg4ld61vcVodnD/XM0jvVGkVHsVFMJyQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeikedgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3B424180725; Mon, 17 Jun 2019 23:16:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-666-gb2312fa-fmstable-20190614v4 Mime-Version: 1.0 Message-Id: In-Reply-To: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> Date: Tue, 18 Jun 2019 13:15:59 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=1dddc7c784eb4586ba640aa950a3e02a Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 03:16:04 -0000 --1dddc7c784eb4586ba640aa950a3e02a Content-Type: text/plain On Fri, 7 Jun 2019, at 01:56, Robert Stepanek wrote: > Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI. Suppose I have such an event (24h long, starts at midnight on 1st Jan 2020 in Australia/Melbourne). It is unclear to me what I should show the user if their time zone is different (e.g. I view the calendar in Europe/London); does it show up in the "all day" section on both 31st Dec and 1st Jan? That's the only sensible thing I can come up with. But that would give the impression the event happens over two days, which is incorrect. (But perhaps the issue here is really more that the birthday should not have been given a time zone.) I agree the name could perhaps be better. `showWithoutTime` perhaps? And a description something like: *Indicates the time is not important to display to the user when rendering this event, for example an event that conceptually occurs all day or across multiple days, such as "New Year's Day" or "Italy Vacation". While the time component is important for free-busy calculations and checking for scheduling clashes, calendars may choose to omit displaying it and/or display the event separately to other events to enhance the user's view of their schedule.* I also agree we want this for JSTask. For example you might set a *due* of `2019-06-30T23:59:59` , i.e. the task deadline is by the end of 30 June. Most UIs would probably just want to show *Due: 30 June*, but it would make sense to have this explicitly stated on the JSTask object so you could signal when the time truly was important. Neil. --1dddc7c784eb4586ba640aa950a3e02a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Fri, 7 = Jun 2019, at 01:56, Robert Stepanek wrote:
    Calendar users want to set their calendar= on their birthday, when they only would like to set it for the complete= day in their usual time zone. They still want it to show up as an all-d= ay event in their UI.

    <= div>Suppose I have such an event (24h long, starts at midnight on 1st Ja= n 2020 in Australia/Melbourne). It is unclear to me what I should show t= he user if their time zone is different (e.g. I view the calendar in Eur= ope/London); does it show up in the "all day" section on both 31st Dec a= nd 1st Jan? That's the only sensible thing I can come up with. But that = would give the impression the event happens over two days, which is inco= rrect. (But perhaps the issue here is really more that the birthday shou= ld not have been given a time zone.)

    I agre= e the name could perhaps be better. showWithoutTime perh= aps? And a description something like:

    I= ndicates the time is not important to display to the user when rendering= this event, for example an event that conceptually occurs all day or ac= ross multiple days, such as "New Year's Day" or "Italy Vacation". While = the time component is important for free-busy calculations and checking = for scheduling clashes, calendars may choose to omit displaying it and/o= r display the event separately to other events to enhance the user's vie= w of their schedule.

    I also agree we wa= nt this for JSTask. For example you might set a due of 2019-06-30T= 23:59:59 , i.e. the task deadline is by the end of 30 June. = Most UIs would probably just want to show Due: 30 June, but it wo= uld make sense to have this explicitly stated on the JSTask object so yo= u could signal when the time truly was important.

    Neil.
    --1dddc7c784eb4586ba640aa950a3e02a-- From nobody Tue Jun 18 04:55:40 2019 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 C7DD612015A for ; Tue, 18 Jun 2019 04:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=fnDMzc7l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OjoJw45u 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 FqU3JBHItbGv for ; Tue, 18 Jun 2019 04:55:36 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82AF120075 for ; Tue, 18 Jun 2019 04:55:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B73C82239F for ; Tue, 18 Jun 2019 07:55:34 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 18 Jun 2019 07:55:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=O7vfiLc DKHaTXAyRLNS+Xd0UfF4dKnIXmMtOu4YndRQ=; b=fnDMzc7lxsVhf1FV5LCc/0G ogO1w2s/l4ZAbT9lySfqcYte7rEzK7gIsbJYzTacU+6CnvwHEWXmB14Ui5YI6PlK 1kx7JZGG/CRBtvvlARVlkGcTw3nSkeCdouo4ULWDOtU+V2+N4pXNbCk3UNjP6FlN pO329j89lRUOqtshqjBaurfSVWomgwD07xAmHzpHK+InmFbI3njHwFLxa/oyXPyY bPsfv6oI941YSWt+IE0053W+/m/L3cFOGVx5NgWHHQfBW/nlRySHqfu6bcW9CBhr 7S37N2qeTC5+msVROo60j46kn7qzhHlAHT7A8ydCoQ3x+Qq4MKJDOkpZotDsfvA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=O7vfiL cDKHaTXAyRLNS+Xd0UfF4dKnIXmMtOu4YndRQ=; b=OjoJw45uF+JaIYc5bU8GGP KOtKu022JmGuI62EAj5FYb8EVq11de6Zb85MEUxMx/2308Ii5Y1CjmnJC4Kt/yqG sm8dxk5LsGCgBYL3zod0llsks2JL6yg4QFHKebqV1WkrDklj/HNjuFDa6s1sx003 O6ZWxcTZLJBtvRM9q0XHcyH8VUD7XmaK/EsLtLs28xDz2wgYMlAkTaTvnJXJlVFK +rzDZs46qw2Nz0JZnUD/ykVhpnXydetV1jOw8yYE8YtvLxXncTtW3RfmuZ/cn1/F jztfAJH4iEh+7/HMneQ3ZRvrMUbR3GsQdcFcJZTNsTvMG7W2pXBT8WnLLwfHmybQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtddtgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomheprh hsthhosehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 46EF0180776; Tue, 18 Jun 2019 07:55:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-666-gb2312fa-fmstable-20190614v4 Mime-Version: 1.0 Message-Id: <12b5d7b2-5d97-4bcb-b918-31833b557fef@www.fastmail.com> In-Reply-To: References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> Date: Tue, 18 Jun 2019 13:55:33 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=eeea7e65e41349ddb5aeb3d08474a1d9 Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 11:55:39 -0000 --eeea7e65e41349ddb5aeb3d08474a1d9 Content-Type: text/plain On Tue, Jun 18, 2019, at 5:16 AM, Neil Jenkins wrote: > On Fri, 7 Jun 2019, at 01:56, Robert Stepanek wrote: >> Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI. > > Suppose I have such an event (24h long, starts at midnight on 1st Jan 2020 in Australia/Melbourne). It is unclear to me what I should show the user if their time zone is different (e.g. I view the calendar in Europe/London); does it show up in the "all day" section on both 31st Dec and 1st Jan? That's the only sensible thing I can come up with. But that would give the impression the event happens over two days, which is incorrect. (But perhaps the issue here is really more that the birthday should not have been given a time zone.) I also wouldn't set a timezone on my birthday, but there's been a number of people at last CalConnect reporting that this actually is what users do. I don't have a good answer how to render that if the event timezone and UI timezone don't match - probably a calendaring UI should just ignore the "isAllDay" property if the timezones of the UI and event don't match. > > I agree the name could perhaps be better. `showWithoutTime` perhaps? And a description something like: That's fine for me as well. I chose "isAllDay" rather than "showAsAllDay", because I figured that "show" implies a graphical user interface, which might not be adequate in all cases (think: calendar applications for visual impaired). But I'm not too vested in it. > I also agree we want this for JSTask. Yeah, there's several people now asking for it, so I guess I shouldn't have removed it in the first place. But it's great we got that established :) --eeea7e65e41349ddb5aeb3d08474a1d9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Tue, Ju= n 18, 2019, at 5:16 AM, Neil Jenkins wrote:
    On Fri, 7 Jun 2019, at 01:56, Robert Stepanek wrot= e:
    Calend= ar users want to set their calendar on their birthday, when they only wo= uld like to set it for the complete day in their usual time zone. They s= till want it to show up as an all-day event in their UI.
    =

    Suppose I have such an event (24h= long, starts at midnight on 1st Jan 2020 in Australia/Melbourne). It is= unclear to me what I should show the user if their time zone is differe= nt (e.g. I view the calendar in Europe/London); does it show up in the "= all day" section on both 31st Dec and 1st Jan? That's the only sensible = thing I can come up with. But that would give the impression the event h= appens over two days, which is incorrect. (But perhaps the issue here is= really more that the birthday should not have been given a time zone.)<= br>

    I also wouldn't set a timezone= on my birthday, but there's been a number of people at last CalConnect = reporting that this actually is what users do. I don't have a good answe= r how to render that if the event timezone and UI timezone don't match -= probably a calendaring UI should just ignore the "isAllDay" property if= the timezones of the UI and event don't match.

    =

    I agree the name= could perhaps be better. showWithoutTime&= nbsp;perhaps? And a description something like:

    That's fine for me as well. I chose "isAllDay" rather = than "showAsAllDay", because I figured that "show" implies a graphical u= ser interface, which might not be adequate in all cases (think: calendar= applications for visual impaired). But I'm not too vested in it.

    I also agree = we want this for JSTask.

    Yeah= , there's several people now asking for it, so I guess I shouldn't have = removed it in the first place. But it's great we got that established :)=
    --eeea7e65e41349ddb5aeb3d08474a1d9-- From nobody Tue Jun 18 09:23:14 2019 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 E2965120291 for ; Tue, 18 Jun 2019 09:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=web.de 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 3f3-wqSxql62 for ; Tue, 18 Jun 2019 09:23:10 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) (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 295931201E8 for ; Tue, 18 Jun 2019 09:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1560874984; bh=BmdqRSNZbeg1CXDIXtDk8xtNRFqv0zGoH+mhXCO5m+8=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=FvdizvLYjaberHBOcX5J8v0aU+mJJz8YssQvgKX1h9cJxO145O/kULXmWsKNigUTt artamt7LlVIXY2hgygLgvsRFLEbRaNr4CqKi5eZ7y161W0LFsOyovYBgXSXRK2VlbC u/qW+hLPF68fEwAMSAeOqUP5OMtX5IQsXbbzRe7k= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [82.165.232.202] ([82.165.232.202]) by web-mail.web.de (3c-app-webde-bap44.server.lan [172.19.172.44]) (via HTTP); Tue, 18 Jun 2019 18:23:04 +0200 MIME-Version: 1.0 Message-ID: From: =?UTF-8?Q?=22Thomas_Sch=C3=A4fer=22?= To: "Doug Royer" Cc: calsify@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Tue, 18 Jun 2019 18:23:04 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: <25453529-BE41-4A4E-B6BD-5EB662C73DEC@calconnect.org> Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:gfHFvRwNdvrm6N4lEFGcoAGmk58sR2sPUstXjTPSp51aVZxB2MANxgWJqkyM6Psbduo9s cImmsBB6E0pGV8HZvL4EY2DRkifR4idgOVcvQqimeAZ2zsHeMUbJgyJ4cHjL26ZEewI6e29tm7nE AMc8yYp6FoxV9ww1k48ttAi4RW/Kfjqf97xLu6nADTj/u9fQ+TfeLdgFe3rRUvLNa5zJg9372k3U crvMYFr1V/z1ioYZcuMXja3kiBDPIf+pDTbphJeGctwpciPhXByUtm6ft3R2JAlw+Ase7WaNMbZP yI= X-UI-Out-Filterresults: notjunk:1;V03:K0:OopGMPIp/7w=:699+d/6oJI+nAFPjyrwBXj 6YC92bisTWlFOo6V+saZn7wtnNA4cqBLSNRImHzSaDVXz3BTJ/YFJkjvKbCqgdSbGSOKETL8G /KtNHFE34wUspjn1Npzxzf/0s85t6AZRMFhUKpWMPWcjF/KDh5/Ov/Lvq+4ne6zZi/55eC/96 8dVoWBcmosBC01qLgaVKNu0Xqb7i/Zah6JImIZOMzisVMJZCfcRJ3uJn8TglTBeTEx/lM5nLU 5C8yQU0v3YUDWpZXorHLD9x3xOawAjRgtsU7TkGWCSxxUZNgruP5ZiPGQcMu6V/y9Qv3j/vpp gXghQN7PhjE3iOIBfHSTLX5ZHiWmEGJsf6L7WNl83O40EnxMRn0ZL3C7WWdBS4z0MxMq1laUY iedj8wJ4XPfqvT8nDys+sDHK9kfxKILzeQcvrAbLBhNhRRX3gmbvqDFYMbayJSEGAULh3Pr3s D9HdfK97/Gdf+qLv4OOd4baoqAeOp7ht7z3zUvQe5Y4SOVjqGJ3D6MAmDYhth83kZahHaILyM q7zVC4uS2rs473YLrL9cMDGTDMcW3weZB5GqT5UHuCK+dQ8zJDn1NvwXN7Xxje9OyTSdxrUur z4at1o2rVQ+jBqjmzEh1jGxDtT7FtppaZjadzPXBhv6VZzz95PoijwIQ== Archived-At: Subject: Re: [calsify] Calendar spam - it is speeding up - security issue / warning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 16:23:12 -0000 Hi Doug, Thanks for pointing to the mentioned article=2E Members of CalConnect started thinking about this as soon as the big wave = of calendar spam hit Apple users in November 2016 (https://www=2Ebbc=2Ecom/= news/technology-38144377)=2E We soon started working on it by issuing artic= le describing what happened (https://www=2Ecalconnect=2Eorg/news/2017/01/30= /calendar-spam) and also started reaching out for E-Mail people at Messagin= g Malware Mobile Anti-Abuse Working Group (M3AAWG, https://www=2Em3aawg=2Eo= rg/) to work together on the topic=2E In 2018 we finally managed to agree on working together on the topic (http= s://www=2Ecalconnect=2Eorg/news/2018/04/05/taking-calendar-spam-scheduling-= developers-organization-calconnect-collaborates) and as Dave mentioned, the= result was our published Calendar operator practices=E2=80=89=E2=80=94=E2= =80=89Guidelines to protect against calendar abuse (https://standards=2Ecal= connect=2Eorg/csd/cc-18003=2Ehtml) which also includes suggestions for mail= and calendar service providers how to address the topic=2E Which now waits= to be co-published by M3AAWG as well=2E You are right, that the document may also address the area of calendar cli= ent developers a little bit more, but unfortunately we were not able to att= ract people developing clients to join=2E Regarding some of your points: >Virus checking and malicious site checking is the second (and not mention= ed) half=2E It is mentioned in https://standards=2Ecalconnect=2Eorg/csd/cc-18003=2Ehtm= l#toc15 and https://standards=2Ecalconnect=2Eorg/csd/cc-18003=2Ehtml#toc18,= but as said, it does not contain a deep section about expected calendar cl= ient behaviour, as it aims for not inserting malicious events in your calen= dar at all and therefor preventing them to appear in your calendar client= =2E Thomas Sch=C3=A4fer chair of TC CALSPAM @ CalConnect > Gesendet: Freitag, 14=2E Juni 2019 um 04:57 Uhr > Von: "Doug Royer" > An: calsify@ietf=2Eorg > Betreff: Re: [calsify] Calendar spam - it is speeding up - security issu= e / warning > > On 6/13/19 8:10 PM, David Thewlis wrote: > > FYI earlier this year, CalConnect published a best current practices f= or=20 > > calendar operators on calendar spam=2E =C2=A0This was developed in con= junction=20 > > with M3AAWG; we understand that they will be publishing it as well=2E = =C2=A0See=20 > > https://standards=2Ecalconnect=2Eorg/csd/cc-18003=2Ehtml=2E > >=20 > > Dave Thewlis >=20 > Great! Just read it for the first time=2E I did not know it existed=2E >=20 > Should drafts start using 'https' and not 'http' in the examples? It is= =20 > not just about security over the wire=2E It can be about verifying the= =20 > destination host is from a verified and expected site=2E Should https be= =20 > required for all links in the future? >=20 > I could add a URL into an iCalendar property/ parameter that links to a= =20 > =2EDOC file that has malicious code=2E Several proposals lately have add= ed=20 > or used URL links to related documents=2E Some CUAs could execute the= =20 > related viewing application themselves after the user says 'yes' to load= =20 > "YourIntroPacket=2Edoc" - without virus checking=2E This is a security = issue=2E >=20 > A warning about the user saying "yes" to download and not automatic=20 > loading is the first half=2E Virus checking and malicious site checking = is=20 > the second (and not mentioned) half=2E >=20 > Last time I wrote a CUA, I just used the OS call to load and view the=20 > reflated application using the OS 'start the correct application' calls= =20 > - without checking=2E >=20 > --=20 >=20 > Doug Royer - (http://DougRoyer=2EUS) > Douglas=2ERoyer@gmail=2Ecom > 714-989-6135 >=20 > _______________________________________________ > calsify mailing list > calsify@ietf=2Eorg > https://www=2Eietf=2Eorg/mailman/listinfo/calsify > From nobody Tue Jun 18 10:39:48 2019 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 B17F212006F for ; Tue, 18 Jun 2019 10:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 U1jCcYHP5RcH for ; Tue, 18 Jun 2019 10:39:43 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 BE8E312001E for ; Tue, 18 Jun 2019 10:39:43 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id c85so8082583pfc.1 for ; Tue, 18 Jun 2019 10:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=JGUnWJMcBeKYIWpPRAT4GrX8kccpFQW1aaMNSdBYG5c=; b=dIAn6zz4t5zmkRyMsHAD9x/n38pzjHpc0CU4XM3aa0e9niSu7zQKj+/aAtLDfJu7IM tGxQUAzrRSiTgDONrCV6HmQvgIHoFNLG8EO62lJJjrGRmJ559Jhrxxw5GUwnP0u2GZ7s 9EECx1c47Jk802wGZqXtX5U7wR57FoxJgiBITM7pL6Y6apHr+EqidL6zvD/LRFqBkJRW zcueB8MBiwTz/5l8rnSMJjxoJUjkrz7HjbcrfW5Jsfq+cYZDQ/H9/LcXfvUUIODMui02 i/vmzgZxoB+GhLdfEjpXtTyruuWt3glYyFjg80A9BoHbKECG3E59VMn6SXmuXJuKf5Ne Wm6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=JGUnWJMcBeKYIWpPRAT4GrX8kccpFQW1aaMNSdBYG5c=; b=iylVKjkRBFJQ1DeYRdg7Be8hEO/3IyAkna4mco67dDJBAwiEQFfJ5cK0syIZgQbXIe b0fpOKO2K+baik4uokY6zLVj5tGJ7SRPtkHM62/mImpGLN+hFtfLjf08h7lNbJo11L0q 20Pq4lgZxboqBcnIAyoep7bbGnizijwuzfIOFBrYYlX43oeaUQJ6qQiBsksrI17VXyfW oARd1wUjCAQXeCULShYeJYQsv+OHMVBPoKpI507ymYuU0zTggBmwvHUWYYZayYy8oqNb X5VxAKJarqzXGd9D6mRpH93k3CnEMhCUquo7Yn9s66lKZLKDND5LSdwpQtFqMyz+X2w6 C1fw== X-Gm-Message-State: APjAAAWNAuAn+MtignaAyttxVe/0oFPNMcO4wkhXRrwsvh1MmDkGkCEJ vug96JfkxLnZdu/gX5OMMSKPrmRsUE/w X-Google-Smtp-Source: APXvYqz1dRrZP/6cww1z1o7nrQpcpdsKLucSD6AdG+oPhqQ6DE0DcH5A7zXrF2su9Euo/GIPePJV+w== X-Received: by 2002:a62:6344:: with SMTP id x65mr16491914pfb.111.1560879582643; Tue, 18 Jun 2019 10:39:42 -0700 (PDT) Received: from [192.168.1.7] ([174.27.172.40]) by smtp.googlemail.com with ESMTPSA id z2sm15147525pgg.58.2019.06.18.10.39.40 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jun 2019 10:39:40 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <25453529-BE41-4A4E-B6BD-5EB662C73DEC@calconnect.org> Organization: http://SoftwareAndServices.NET Message-ID: Date: Tue, 18 Jun 2019 11:39:39 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060802050506090209000602" Archived-At: Subject: Re: [calsify] Calendar spam - it is speeding up - security issue / warning X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 17:39:46 -0000 This is a cryptographically signed message in MIME format. --------------ms060802050506090209000602 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/18/19 10:23 AM, "Thomas Sch=C3=A4fer" wrote: > Hi Doug, >=20 > Thanks for pointing to the mentioned article. >=20 > Members of CalConnect started thinking about this as soon as the big wa= ve of calendar spam hit Apple users in November 2016 (https://www.bbc.com= /news/technology-38144377). We soon started working on it by issuing arti= cle describing what happened (https://www.calconnect.org/news/2017/01/30/= calendar-spam) and also started reaching out for E-Mail people at Messagi= ng Malware Mobile Anti-Abuse Working Group (M3AAWG, https://www.m3aawg.or= g/) to work together on the topic. >=20 > ... > Regarding some of your points: >=20 >> Virus checking and malicious site checking is the second (and not ment= ioned) half. >=20 > It is mentioned in https://standards.calconnect.org/csd/cc-18003.html#t= oc15 and https://standards.calconnect.org/csd/cc-18003.html#toc18, but as= said, it does not contain a deep section about expected calendar client = behaviour, as it aims for not inserting malicious events in your calendar= at all and therefor preventing them to appear in your calendar client. That is great, however these are IETF documents. And I am NOT talking=20 about SMTP or EMAIL (the references you pointed to). I am talking about=20 URLs to external documents that could have been transferred with a=20 MAILTO URL. However, the examples in the drafts are using an HTTP url=20 (not covered under SMTP or EMAIL and not transferred with SMTP). Email virus checking might find that related document URL contains=20 malicious content if it were a multipart/mime with a CID, or as a=20 related and inline included content. However it is often the case that=20 the calendar embedded URL point to external documents. Not all calendar objects are transferred with IMIP. Enterprise internal=20 hacking, WebCal, or just a link someone puts on some public sporting=20 event would not be transferred with iMIP. All of which could have=20 related document URL links that point to malicious items. And related: can an RFC refer to a calconnect document as a NORMATIVE=20 reference? --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms060802050506090209000602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE4MTczOTM5WjAvBgkq hkiG9w0BCQQxIgQgoNa1F6zmSUmawH42lxC/6wfGm4huM8v0n7RylZg6OOgwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQBGgMOFxAXzuBFf7Een3u4xydBkcqmUGBFyUkH4pPIA7TiZC8SP MroTrJ4RLeBDNDtCR8iQpXm7Vqbw5fm91pzne2BAhySeu4iQS4560fwzjGWWsgoHd9O08vED 0BWNSPa3e1+DRy04B9VI1CagOOO694NCuHUOBDVSurtUMz/iFmfZJWBQE55s+3ARa+dRaFpc l57uVxki5aqT4NEGCW6VPGjOUVTGKnf7ciXQtioV39ri9T/I99dRNDrEimosiilXWKtpp/sR O0jnGm1OfyUl+DXEwpYIpXw+R6RtIlhCTio7jE6XMzP3TZNF4ghHnc64lQHfPo/7XwUm1r3F saAOAAAAAAAA --------------ms060802050506090209000602-- From nobody Tue Jun 18 10:50:44 2019 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 CD8D41201C8 for ; Tue, 18 Jun 2019 10:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 0NoOsGAo0VvU for ; Tue, 18 Jun 2019 10:50:41 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 6F15B1201C5 for ; Tue, 18 Jun 2019 10:50:41 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id q10so8082102pff.9 for ; Tue, 18 Jun 2019 10:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=OdmLpsXhAWmyM+1wwFNfKaV00mEOJx9wkYUZDLJwMbA=; b=N5bbbfGw7mfpljyDcogRIuDVQ55ecqe+P3edlEai8DWYtnmPPziRO8cdWAFvbeJhh6 rPo80nYE4iZf6l/Qv7yqLZz+GvZMBmTqzHVEnq+tO7Z0T5kNfuWexhPTe8zuBJoOLj1Q VFttd9BL07y2tSNScm3d12LOX3cMA6pJNY5E1UzM3ETcZ7ZWj1MMM0kQg332qiVMQ+aQ RpnP9xyDZfkQzSulDAtjcxMm9tJOJhvgRhTaklaWIkIvOZnKeM7Z6ka1Fc85Z/7sHxNU IOkOhRU9TQmH/Ta2kt7B4kWaINWM5TRBm2sJfKs0jGpeoJhVarSFEMT9PhB90vm1Gmd5 lOug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=OdmLpsXhAWmyM+1wwFNfKaV00mEOJx9wkYUZDLJwMbA=; b=mur1wierjru7/0NoFPj6jeIcN8fN1qYwWx+Dk/NS/H8JG2dijE5Y6CbuZsJq6jfnWV peGGTWJTPFi7UnNSxw4QS4QVo0n7TqDx/hWbgHoDc83f9k7Kx2INLdGW+4U9CsWjMvAN CHVVlv5ZAAL35lKIlYBk+lTyGHLKU7LlZ7Vd/6xn91nKqKbFPLp/N5WjT8PMI8oMHPTy dQI/5lz3OLN6Zu+GAbyQ4+g6BOUtTJmPXnwyQ/T5Mh7JjtMTC5O5tq6E0auIcCZlDwG6 aleJH35t4tfdeHYk8L5WmWxsK7nmq+y10bx9+I30+lNlW8f5/3XNORV9unTo0iaQHBUF 0i0w== X-Gm-Message-State: APjAAAVf8djKV7/NjUmFdC9Ou87cNZb2zjILFa0X3YWCFlW2LH71Lwf3 hGZCPnsPTcbTuQSnrv5Bp32zKjqxlnDq X-Google-Smtp-Source: APXvYqzcfZo8Rk5zWALwWD32HmXscbcw0/VfbRfKp1P8NVCy1JVkvQra5/eOyM8gyyABVx6fOLYkZg== X-Received: by 2002:a62:6d41:: with SMTP id i62mr120872923pfc.227.1560880240516; Tue, 18 Jun 2019 10:50:40 -0700 (PDT) Received: from [192.168.1.7] ([174.27.172.40]) by smtp.googlemail.com with ESMTPSA id m19sm25785012pff.153.2019.06.18.10.50.39 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jun 2019 10:50:39 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> Date: Tue, 18 Jun 2019 11:50:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030204020306010103010209" Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 17:50:43 -0000 This is a cryptographically signed message in MIME format. --------------ms030204020306010103010209 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/17/19 6:39 PM, Bron Gondwana wrote: > On Tue, Jun 18, 2019, at 09:25, Doug Royer wrote: >> =C2=A0 "Indicates whether this event is meant to represent an all-day = event, >> =C2=A0=C2=A0=C2=A0 and SHOULD be presented accordingly in a calendarin= g application. >> =C2=A0=C2=A0=C2=A0 The value of this property is independent of the ac= tual time-span >> =C2=A0=C2=A0=C2=A0 covered by this event." >> >> >> So, an isAllDay could as an example, be 36 or more hours long? >=20 > It certainly could.=C2=A0 This is already very possible with iCalendar,= e.g.=20 > this event here: >=20 (example not included) >=20 > Which is an "all day event" with a duration of 5 days. So, with, or without 'isAllDay' they mean EXACTLY the same thing. What=20 is the point of 'isAllDay' when with or without it, it means the same thi= ng? If I am incorrect, what does it mean? --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms030204020306010103010209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE4MTc1MDM4WjAvBgkq hkiG9w0BCQQxIgQg68A3h77C0E+JvI5r0gLsLBr9Gv/rJGL96eDLlRmE5W0wbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQB57HhvuMLPyXkQ3HyaVl1Nus3l1zs4Bs1sun7L0D1WAKjDRNoX JBj40wCRv6rl3q03xm21QrX/ISUTU2P4OOfb6IQq0tNB5sVrj0F9b5YxtjZ2mnwkWyvEb392 4onC/2ZDwwlhenMUHJCNBhN6rs+rJSFZ/uTQedJvIAbuYei4rfcKJNYzwZuA6zqRcjsSTPLR cxUu5ysllD771BsR0hgo5+/1fEWMErFq1zF21iOvPZ1OiKY6GHqP+nWALWJZHRL3vkCxu49R 3Ftsn90R9WvjLvRCLA/d5UoGTtv0pvZUU1q8MQkR/gbs0V/j7q35GEd0CMyCKsdnEcfndppr 8lJXAAAAAAAA --------------ms030204020306010103010209-- From nobody Tue Jun 18 12:26:13 2019 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 E7B60120404 for ; Tue, 18 Jun 2019 12:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 1F-H1TmD4p8o for ; Tue, 18 Jun 2019 12:26:09 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 8767812031D for ; Tue, 18 Jun 2019 12:26:09 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id c70so9331403qkg.7 for ; Tue, 18 Jun 2019 12:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=jcEDwgtVwujerwj6hEbVHM5m8yLy2+o9E40ObLy3SRc=; b=imr6X9JQOxoy9Hnyu3+ex6ukxWQNn3XVsFY1JPv6T2MM35gbJ0B1Lniz7yzcP9FcFa hs/FMp9iWTBOfED/Ik5jbsDIpniX4hOriVTiTcR7EnZ++4x6l8HaXOEHKaQuKxTuXcnS EPCOq4xSa9kCNsDpR29Q0EDbnnEIDfuvtSh5+4fJTqdGmsPQ+GcAX1Af/qv8DajLUdJf bCrwyues0o7CJIdJYq581BFRaPRUL95Y+LQJVPiYS1XnFIrnYeFEz9rXBxnfOUzppRjw h+mt+FhyR6ZC3a/rctTVSfja5tKElhNr0ymaAO3RaPzhqR0X1DXY0vy3693VLIzvmR+S vd7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=jcEDwgtVwujerwj6hEbVHM5m8yLy2+o9E40ObLy3SRc=; b=tRzmAw+aZQVtavcm0I9zKcPrmQnVl51lG9PRgbmCDOuuGeFdDbSssOT+uhQF97Hyxz MaGD6IRn4jzcxKEtELmPF5YYdJ7TToSH6g/d8du4m9kuqgcBQLTubzim7rkDo48A6zvO inMcS/5H4wNTPFaz2luWAuuLQwK7HdQdwYdbv8zSv1izds4va4yTS4L0BAj0K3oDvQRC ezPacc/uBnEetkTtz7h6Wd51I5UlalEkaiV4Q1UdkahyfvrK98v+uEBdgowlQqI62yBs kFkrlvu/VMkBLSJyoDMBVcYq7KdbsZ5MJD/tQuebw/zJnXRCrYWycA7RlhYnPhM3ShL2 z9CQ== X-Gm-Message-State: APjAAAXyNkjMiTrfu2GIJRlefzopJknhbmluOuR59D9w1HmdG+LoxR63 a4kaNeT3f9SVRIJS3QipnCOC1zra8a0= X-Google-Smtp-Source: APXvYqwxW3TKA2BDZAmXOhBGrBfRkpCQqGUeydMRO26gyvtp488nWc3QuXMrnhyvs5XxV49kUQiwPQ== X-Received: by 2002:a37:9e93:: with SMTP id h141mr74921025qke.142.1560885968348; Tue, 18 Jun 2019 12:26:08 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id r39sm11675740qtc.87.2019.06.18.12.26.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jun 2019 12:26:07 -0700 (PDT) To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> From: Michael Douglass Message-ID: <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> Date: Tue, 18 Jun 2019 15:26:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> Content-Type: multipart/alternative; boundary="------------0D8CD6B1248D5F7597BCD027" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 19:26:12 -0000 This is a multi-part message in MIME format. --------------0D8CD6B1248D5F7597BCD027 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Putting aside the  exact representation for the moment there is a need - expressed by calendar users - to represent what they mean by "all day". For birthdays etc the current date-only is probably fine (though possibly being able to flag these as anniversary events might be useful). However, for public and social events things are different. These are generally known as 'all day' - the start and end may be ill-defined if at all. They also often take place in a specific timezone. For years creators of ics files have been trying to put timezones on dates. I tell them they can't - they say why? The only answer is that the standard says so. They want to flag an all day event as taking place in a certain timezone. Setting the start and end to midnight doesn't have the same meaning - that is a 24hour event. The uis for public calendars need to know the difference between a true 24hour event and an all-day event in a certain timezone - we display them differently. So I think the first issue is to decide whether our users are simply being unreasonable or if they have a genuine unfulfilled need. If you want an analogy - we can either see where people walk and then lay down the paths or we can lay the paths and forever repair the grass. On 6/18/19 13:50, Doug Royer wrote: > On 6/17/19 6:39 PM, Bron Gondwana wrote: >> On Tue, Jun 18, 2019, at 09:25, Doug Royer wrote: >>>   "Indicates whether this event is meant to represent an all-day event, >>>     and SHOULD be presented accordingly in a calendaring application. >>>     The value of this property is independent of the actual time-span >>>     covered by this event." >>> >>> >>> So, an isAllDay could as an example, be 36 or more hours long? >> >> It certainly could.  This is already very possible with iCalendar, >> e.g. this event here: >> > (example not included) >> >> Which is an "all day event" with a duration of 5 days. > > So, with, or without 'isAllDay' they mean EXACTLY the same thing. What > is the point of 'isAllDay' when with or without it, it means the same > thing? > > If I am incorrect, what does it mean? > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------0D8CD6B1248D5F7597BCD027 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Putting aside the  exact representation for the moment there is a need - expressed by calendar users - to represent what they mean by "all day".

    For birthdays etc the current date-only is probably fine (though possibly being able to flag these as anniversary events might be useful).

    However, for public and social events things are different. These are generally known as 'all day' - the start and end may be ill-defined if at all. They also often take place in a specific timezone.

    For years creators of ics files have been trying to put timezones on dates. I tell them they can't - they say why? The only answer is that the standard says so. They want to flag an all day event as taking place in a certain timezone. Setting the start and end to midnight doesn't have the same meaning - that is a 24hour event.

    The uis for public calendars need to know the difference between a true 24hour event and an all-day event in a certain timezone - we display them differently.

    So I think the first issue is to decide whether our users are simply being unreasonable or if they have a genuine unfulfilled need.

    If you want an analogy - we can either see where people walk and then lay down the paths or we can lay the paths and forever repair the grass.


    On 6/18/19 13:50, Doug Royer wrote:
    On 6/17/19 6:39 PM, Bron Gondwana wrote:
    On Tue, Jun 18, 2019, at 09:25, Doug Royer wrote:
      "Indicates whether this event is meant to represent an all-day event,
        and SHOULD be presented accordingly in a calendaring application.
        The value of this property is independent of the actual time-span
        covered by this event."


    So, an isAllDay could as an example, be 36 or more hours long?

    It certainly could.  This is already very possible with iCalendar, e.g. this event here:

    (example not included)

    Which is an "all day event" with a duration of 5 days.

    So, with, or without 'isAllDay' they mean EXACTLY the same thing. What is the point of 'isAllDay' when with or without it, it means the same thing?

    If I am incorrect, what does it mean? 



    _______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
    --------------0D8CD6B1248D5F7597BCD027-- From nobody Tue Jun 18 14:13:13 2019 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 5617C12019C for ; Tue, 18 Jun 2019 14:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 sgYAoXU_RlWq for ; Tue, 18 Jun 2019 14:13:09 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 697C2120048 for ; Tue, 18 Jun 2019 14:13:09 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id d126so8363086pfd.2 for ; Tue, 18 Jun 2019 14:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=/aqnjTMsZ2ob8F+KfUhTqnkljL/uog66pPcUZUaOnb4=; b=AHYQEAaKiMbkTwkWOsxFFcYutjVNSd49nBqI7eGydI0UArCEmLvyYOGT5411rmGhAU 1Ckn/DSVQQpXUaxtdTn5DjSS3LyXTdZ8zhcD5digSelMeOGkDAAsaswAA6zan5U8TYnV Cs3tRD/xSF+kcnpFC2hkrdRF9yoRr9Z8H24a9jzdOI2XAqtbwoG3NXZae8l+WRfvtXeF c2JHIrokXt8DYTZUrKq9SUZ70psAyNTYtCYlgI99oqvKodSb9y+mRC5flUj+6adcSeOs 58/6iwODmPtNFC+Ost5y890kXISRD4nxlmjOWh+Zsxz2UEcZlPVnbY2HBk/toxd+DGQc 46aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=/aqnjTMsZ2ob8F+KfUhTqnkljL/uog66pPcUZUaOnb4=; b=Ecy821GCQNsjHqDvpm0eVQ8H+QenD7FzMsDosqHE0FSge7OeMQFRkGPfsQjZI/O05C BTSokrAEhEJrpEyQDD6fWsGMqhfVKnXT57Cth4ln/KT3M+w4J3ztABGyhYjntK5Cfahg LRvrGINYEldq4Z1hNrQXAX3f8FSGJUSLW2Rq+ttUcq9VjtLVS99DvBBhQhpc/bydJnjT oQ1u2m/KCJvtZeQ0RMUU/wzI5bBUuUuJlN4tinDG3DBHJM1GjP5zZebbwJgu/gIgymaT v0j1xwK15f387WCogxMdFZaErpAoPvBJFRMWJyXMt/7J9N+4QUQP3HiJfkHNkZrH+Hy/ raTA== X-Gm-Message-State: APjAAAWgJM1O0TiNHJ8NoupiocgDBJg9YMef9KKlhvu5XPD89kuSy3mr dI+AmgAffvPogMHvUnSm8oo2N5VypwBb X-Google-Smtp-Source: APXvYqweKqBhGV/k8cJ2KuBG7K4IMHYtR4GNN/7Vijzka3F5UXuZJUiWkslK3gvG1/43gEfuEZA1qg== X-Received: by 2002:a17:90a:bb8b:: with SMTP id v11mr7182133pjr.64.1560892388408; Tue, 18 Jun 2019 14:13:08 -0700 (PDT) Received: from [192.168.1.7] ([174.27.172.40]) by smtp.googlemail.com with ESMTPSA id e20sm15299385pfi.35.2019.06.18.14.13.06 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jun 2019 14:13:06 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Tue, 18 Jun 2019 15:13:06 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090003070305090500070008" Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 21:13:11 -0000 This is a cryptographically signed message in MIME format. --------------ms090003070305090500070008 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Great - It needs to be documented in the spec. If it means fuzzy dtstart/duration, that's fine. But say so. Does it mean "no earlier than dtstart" and "no longer than duration"? Without knowing, what will get displayed will be different across=20 implementations. So far, I would just ignore it, as it has no specific=20 meaning yet. So, not sure what you mean when you say: "For years creators of ics files have been trying to put timezones on dates. I tell them they can't - they say why? The only answer is that the standard says so. They want to flag an all day event as taking place in a certain timezone. Setting the start and end to midnight doesn't have the same meaning - that is a 24hour event." So, don't set them to midnight. If you mean Anniversary events, they=20 are date-only. That has nothing to do with all day. An anniversary is=20 'on that date', not 'all day'. Those can be localtime or TZ specific,=20 and may or might not have a dtend/duration. TZ is not required, and *is* allowed on Date-Time and Date events. DTSTART;TZID=3DAmerica/New_York;VALUE-DATE:19980119 and DTSTART;TZID=3DAmerica/New_York:19980119T020000 and DTSTART:19980119T020000 Are all valid. Timezones are *not* required on the events. So users do=20 not need a timezone in an ics file. When omitted, those are localtime=20 (like new years day and birthdays). So isAllDay does not need to exist=20 to specify those. When you say: "The uis for public calendars need to know the difference=20 between a true 24hour event and an all-day event in a certain timezone - = we display them differently." I am guessing that a 'uis' is a CUA? Exactly how will they be displayed differently? An anniversary may=20 display differently (it can have no duration). But any other=20 start/duration event simply takes up the time on the CUA like any other. Still confused by "all day" vs any other event that may or might not be=20 24-hours in duration. On 6/18/19 1:26 PM, Michael Douglass wrote: > Putting aside the=C2=A0 exact representation for the moment there is a = need -=20 > expressed by calendar users - to represent what they mean by "all day".= >=20 > For birthdays etc the current date-only is probably fine (though=20 > possibly being able to flag these as anniversary events might be useful= ). >=20 > However, for public and social events things are different. These are=20 > generally known as 'all day' - the start and end may be ill-defined if = > at all. They also often take place in a specific timezone. >=20 > For years creators of ics files have been trying to put timezones on=20 > dates. I tell them they can't - they say why? The only answer is that=20 > the standard says so. They want to flag an all day event as taking plac= e=20 > in a certain timezone. Setting the start and end to midnight doesn't=20 > have the same meaning - that is a 24hour event. >=20 > The uis for public calendars need to know the difference between a true= =20 > 24hour event and an all-day event in a certain timezone - we display=20 > them differently. >=20 > So I think the first issue is to decide whether our users are simply=20 > being unreasonable or if they have a genuine unfulfilled need. >=20 > If you want an analogy - we can either see where people walk and then=20 > lay down the paths or we can lay the paths and forever repair the grass= =2E >=20 >=20 > On 6/18/19 13:50, Doug Royer wrote: >> On 6/17/19 6:39 PM, Bron Gondwana wrote: >>> On Tue, Jun 18, 2019, at 09:25, Doug Royer wrote: >>>> =C2=A0 "Indicates whether this event is meant to represent an all-da= y event, >>>> =C2=A0=C2=A0=C2=A0 and SHOULD be presented accordingly in a calendar= ing application. >>>> =C2=A0=C2=A0=C2=A0 The value of this property is independent of the = actual time-span >>>> =C2=A0=C2=A0=C2=A0 covered by this event." >>>> >>>> >>>> So, an isAllDay could as an example, be 36 or more hours long? >>> >>> It certainly could.=C2=A0 This is already very possible with iCalenda= r,=20 >>> e.g. this event here: >>> >> (example not included) >>> >>> Which is an "all day event" with a duration of 5 days. >> >> So, with, or without 'isAllDay' they mean EXACTLY the same thing. What= =20 >> is the point of 'isAllDay' when with or without it, it means the same = >> thing? >> >> If I am incorrect, what does it mean? >> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms090003070305090500070008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE4MjExMzA2WjAvBgkq hkiG9w0BCQQxIgQgGFkizWltKGDd4Mnho2w1oNcbtCkU6byEtD9Pd9B4hZMwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQBHyY240eGGGlIVA6mnJuueskka5JCW2GHCdrmjLP4dJFRs9tkj 9fNnQs69d0cVyxrbcj4nMuaLqKGAPrkDDna6qY755xx+vKH5N8ZjvKG0Y3BmByFHmAiF+bHy YpJU8zetb6L7tfuOUk45Rw8ErYUjGKzKs0/5hjPa7N7qXWFAg3gq6YJI0/FC4fIYSb2FnDDF Yd7//gd8HrrS7tUqB6bHDTK5spXKfimN8jFmW+IDsHMl2SErE7cC5KsOqYBnFcRT1ITctm/o 3khgs3Dd51IWHSboSOX0rg4wd3HzClNs2vbrf3+wr+uBYWol1MdDXe5R4CI9OJVK9+fTMLwm nvRGAAAAAAAA --------------ms090003070305090500070008-- From nobody Tue Jun 18 18:20:54 2019 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 2FB4F12006A for ; Tue, 18 Jun 2019 18:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KmBT9IuS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZOJL/+Ht 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 W4mNfa-doelP for ; Tue, 18 Jun 2019 18:20:51 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688E1120044 for ; Tue, 18 Jun 2019 18:20:51 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A9FC722404 for ; Tue, 18 Jun 2019 21:20:50 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 18 Jun 2019 21:20:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=p2BxeWz 2SUCyPIH8G2r7BWn8s/TvUE8Z2XnhdLGIQ9k=; b=KmBT9IuSIGNOixt8Z9Wg98F 3x9JzSqxQm64O4bLunXi50yAgCHopO4ClfyK3a2OpajSlhtWZowYM8Ne8zr+JHIF GMkKiIw9p/6cz0EQiC/gBNMXe19xskmJdW2MpmV2eYzE1zK+WaTa+SWa7696dJx1 O5s7u7xmmL8t/mYAevYIdIIi4fh7DuUVB2EpbpEtI/Pb83G8ckvSLNOpBQSczICD LLDtFXoJeIjiE9i/zTDUYtE7p/gqunI5sxdGoVFZt8YzKrAbRiEzryG5FexdctTq iS/yEiJ0MlWJSDabepwMzCtmMEmnaWlgt0UhDGJ3+FitNkAODMVWF0R37NXUkng= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=p2BxeW z2SUCyPIH8G2r7BWn8s/TvUE8Z2XnhdLGIQ9k=; b=ZOJL/+Htfj9zEBR+4XTTzq pgVuYMkElQo3NeO1TUHQeqw34/xpaMu1bbTk/4tzdIG/ZUu/uV7G8w/Uze6/JUPD 2SBm/TIlLWeA3Xt9+tulAX/xK95+UuHY9rxV32z0xS3NhSSb83HhhQTbh4bLBdA0 F1zG6ScGv/bEfHJtsPCysFwCi37hGMhlWAuwTxBM3MQUIO+0N6BQx1M0/caY40io HIeGFHyKzvTkOaTlgmCgeGh29i2X6Uh7zsnY4ciFwN+LV30vgKjAJdxnWsJML4Ac BrVGlygASRpF0jfhQT2FPGZn49ic2ueseIQdy+FhdlaARC6hHsc+1w+0GE8Argnw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtddugdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrh honhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1222F18073C; Tue, 18 Jun 2019 21:20:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-666-gb2312fa-fmstable-20190614v4 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> Date: Wed, 19 Jun 2019 11:20:49 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=3104ea221338414081d66558022f835f Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 01:20:53 -0000 --3104ea221338414081d66558022f835f Content-Type: text/plain On Wed, Jun 19, 2019, at 07:13, Doug Royer wrote: > TZ is not required, and *is* allowed on Date-Time and Date events. > > DTSTART;TZID=America/New_York;VALUE-DATE:19980119 Do you have a citation to support this statement? Mike and I are basing our understanding from reading RFC 5545: Section 3.2.19 The "TZID" property parameter MUST NOT be applied to DATE properties and DATE-TIME or TIME properties whose time values are specified in UTC. It does is somewhat fuzzy langauge, but our impression at CalConnect the other week when we look at this was that RFC5545 prohibits the use of TZID with VALUE=DATE. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --3104ea221338414081d66558022f835f Content-Type: text/html
    On Wed, Jun 19, 2019, at 07:13, Doug Royer wrote:
    TZ is not required, and *is* allowed on Date-Time and Date events.

    DTSTART;TZID=America/New_York;VALUE-DATE:19980119

    Do you have a citation to support this statement?

    Mike and I are basing our understanding from reading RFC 5545: Section 3.2.19

          The "TZID" property parameter MUST NOT be applied to DATE
      properties and DATE-TIME or TIME properties whose time values are
      specified in UTC.

    It does is somewhat fuzzy langauge, but our impression at CalConnect the other week when we look at this was that RFC5545 prohibits the use of TZID with VALUE=DATE.

    Regards,

    Bron.

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


    --3104ea221338414081d66558022f835f-- From nobody Tue Jun 18 19:57:12 2019 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 0F83D12001B for ; Tue, 18 Jun 2019 19:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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=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 eciMyQVFJPQM for ; Tue, 18 Jun 2019 19:57:08 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 481B9120183 for ; Tue, 18 Jun 2019 19:57:08 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-04v.sys.comcast.net with ESMTP id dQTZhgixwtwecdQmZhvLbA; Wed, 19 Jun 2019 02:57:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1560913027; bh=qh4C/F1yjvb4uoFmX54wh3ic3n0FcEOeeH6tBdNnu5E=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=m1+/GIcT+CgMr5SxR+0cpFt7Y4EF50mu+2arEd4qyeKOuIg6un0H3KtnJtwez23Ia QwWgpg9bq7MQNEM1thF+gFEhe4xEsr8AqxwCQz6+whU3CAFp1Z7kOPwKHouPOVh+Ie niyqMUtE3mwCWK+Tu9g1LcPQBSmeZ2P0D/F9l+vq0uf6wrqQVDFp355p4eYq8xMpie 5LM5R/hgyiwfH132R+YSHy37RRrJgdzYDzzFotqDAvv7lLJcu071oA3+sdxaKqAPqx +ja+HlWtWm2Q3PvmewPkKNSYeW4Owoi9XKID0Q4bBnuDbI/g8p7Zx8fNfj3udCAoii VBi9OXqzYKXlg== Received: from THARE ([98.192.130.240]) by resomta-po-01v.sys.comcast.net with ESMTPA id dQmYhsm0llRVidQmZh8G4H; Wed, 19 Jun 2019 02:57:07 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduvddrtddugdeigecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfggtgfothesrgdtghepvddtvdenucfhrhhomhepfdfvihhmucfjrghrvgdfuceovfhimhfjrghrvgestghomhgtrghsthdrnhgvtheqnecuffhomhgrihhnpehsvghnihhorhgtvghnthgvrhdrohhrghenucfkphepleekrdduledvrddufedtrddvgedtnecurfgrrhgrmhephhgvlhhopefvjfettffgpdhinhgvthepleekrdduledvrddufedtrddvgedtpdhmrghilhhfrhhomhepthhimhhhrghrvgestghomhgtrghsthdrnhgvthdprhgtphhtthhopegtrghlshhifhihsehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=0;st=legit From: "Tim Hare" To: Date: Tue, 18 Jun 2019 22:57:05 -0400 Message-ID: <01a701d5264a$ae2d56e0$0a8804a0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A8_01D52629.271E27E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdUmR4569c2q4iwZQHuWDK2fgGtxjA== Content-Language: en-us Archived-At: Subject: [calsify] Asking for feedback on an idea for an RFC5545 extension X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 02:57:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A8_01D52629.271E27E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Before I go through trying to write up an RFC document, I thought I'd float the idea here first and ask for feedback. I would like to propose a new component, INCLUDE, at the BEGIN:VCALENDAR level (the same level as PRODID: ) INCLUDE would have a value that was a URI referencing iCalendar object. Implementations would read in that object, discard the "envelope" (BEGIN:VCALENDAR / END:VCALENDAR, VERSION, PRODID) and add the other items to the current object. One use case: when an organization maintains calendars for several different parts, but would also like to include all of it at once. For example - a senior center maintains one calendar for language classes, one calendar for meals, one calendar for special events. The sub-organizations maintaining these calendars only need to see their calendars, but to publish to the public all of it needs to be seen. With VINCLUDE this "overall" calendar object would be BEGIN:VCALENDAR VERSION:2.0 PRODID:SeniorCalendar1.5 INCLUDE: https://seniorcenter.org/calendars/language.ics INCLUDE: https://seniorcenter.org/calendars/meals.ics INCLUDE: https://seniorcenter.org/calendars/events.ics BEGIN:VEVENT . other VEVENTS in this calendar END:VEVENT END:VCALENDAR Obviously this idea needs to be "fleshed" out, and some issues looked at - such as how to handle an INCLUDE of an object that also has INCLUDE(s) - but I see utility in this idea and other places it could be used. If there are others who think it's worth the effort I will try to work on an extension RFC for it. Thanks for any and all feedback Tim Hare Interested Bystander, Non-Inc. ------=_NextPart_000_01A8_01D52629.271E27E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Before I go through trying to write up an RFC = document, I thought I’d float the idea here first and ask for = feedback.

     

    I would like to propose a new component,  = INCLUDE, at the BEGIN:VCALENDAR level (the same level as PRODID: = )

    INCLUDE would have a value that was a URI  referencing = iCalendar object. Implementations would read in that object, discard the = “envelope”  (BEGIN:VCALENDAR / END:VCALENDAR, VERSION, = PRODID) and add the other items to the current object.

    One use = case:  when an organization maintains calendars for several = different parts, but would also like to include all of it at = once.   For example -  a senior center maintains one = calendar for language classes, one calendar for meals, one calendar for = special events.   The sub-organizations maintaining these = calendars only need to see their calendars, but to publish to the public = all of it needs to be seen.  With VINCLUDE this = “overall” calendar object would = be

    BEGIN:VCALENDAR
    VERSION:2.0

    PRODID:SeniorCalendar1.5
    INCLUDE: https://seniorce= nter.org/calendars/language.ics

    INCLUDE: https://seniorcente= r.org/calendars/meals.ics

    INCLUDE: https://seniorcent= er.org/calendars/events.ics

    BEGIN:VEVENT

    … other VEVENTS in this = calendar
    END:VEVENT

    END:VCALENDAR

     

     

    Obviously = this idea needs to be “fleshed” out, and some issues looked = at – such as how to handle an INCLUDE of an object that also has = INCLUDE(s) - but I see utility in this idea and other places it could be = used.  If there are others who think it’s worth the effort I = will try to work on an extension RFC for it.

     

    Thanks for = any and all feedback
    Tim Hare
    Interested Bystander, = Non-Inc.

     

     

    ------=_NextPart_000_01A8_01D52629.271E27E0-- From nobody Tue Jun 18 21:28:32 2019 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 F16851201E4 for ; Tue, 18 Jun 2019 21:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=PpgNHjSL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wiC1p4uP 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 YIywKUDcIWXV for ; Tue, 18 Jun 2019 21:28:27 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A2912018D for ; Tue, 18 Jun 2019 21:28:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BA6CA2238F for ; Wed, 19 Jun 2019 00:28:26 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 19 Jun 2019 00:28:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=LAiyutk ZWXahb0RVaGovaVbvl/oJ27BBnpCIQ0bMcPo=; b=PpgNHjSLhG8FyD1uSQKyD/q mKqb3HZINmVpX9nHVTw3vsUAHM29F/2TiulCvV8A0E0HRbiipRE6D1l6t24oW6nI SgqtH1TfsnPGA2EZPG/RdvjL81ObVweZWyNr/Ia21Rw1y8Lt9CUqpABp5bKoXLJh oajG8EMEGK+XiRAg9pYKH98AdSeJLA/NSROsef0rZS1i8wdmQfBYrWS4fiqqJ3NS CzrGOflOKl/MxrFFNZgd02aoclm5ZNlwygbZ8lsb9TnZHdqgXl+maggvAfMi6Jna iDeJ0+SL4i/iRFtu1L1pLkjqK4XHb+H3spx9YYlGUq7fBkCz1/LCq39grASLNCg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=LAiyut kZWXahb0RVaGovaVbvl/oJ27BBnpCIQ0bMcPo=; b=wiC1p4uPhbviGLe5MlbWf9 2XmPlbLLOJ21fIGLicIpsPsQmoIgFacBxXfoEr7vPksuDIBFFRAdEy3m5URX1lWW xNcbd6vAOHO3WjoPiQljdfGxyepVbJ7AAinRt2RtTitRn05Apt/jkWiSNcaqK7kt afqsH6WR+ki6GGJCpd3i3uttUeSXdHjGH30/mqe85OiaJniJi43QxC5RDzwRScL/ ITRxAzO1osymwTwonvCPTOhggUq6xj36aY7X1pLmR0Cvn79vkZyHm0SerB4pUsXu jIarStRaCaMITPMVOPKS9gzqdOhNfuDAu0K6QzSK1o7ZUF9gpJYBM+2jSrg7QAXA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtddugdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepnhgvih hljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AFFB618073C; Wed, 19 Jun 2019 00:28:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-666-gb2312fa-fmstable-20190614v4 Mime-Version: 1.0 Message-Id: <148d9346-06fc-45c0-9c69-b486578b24ed@beta.fastmail.com> In-Reply-To: References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> Date: Wed, 19 Jun 2019 14:28:25 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c029def5653a4bdea6581a9dcec70356 Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 04:28:30 -0000 --c029def5653a4bdea6581a9dcec70356 Content-Type: text/plain On Wed, 19 Jun 2019, at 07:13, Doug Royer wrote: > Great - It needs to be documented in the spec. Yes, I have suggested text in a previous email in this thread. > Exactly how will they be displayed differently? I suggest try using a common CUA such as Outlook, Google Calendar, Apple Calendar. These all have an option to mark an event as "all day" (this is literally the term normally used in the interface), which causes the client to display it separate to timed events in the spatial view (e.g. Day, Week view) of the calendar. When storing in iCalendar format, clients distinguish these events by using the DATE format rather than the DATETIME format. In JSCalendar we are using an explicit boolean property instead, which we believe is better aligned with developers' mental model and is easier to implement. This particular thread is discussing loosening some current restrictions, designed to ensure a 1:1 mapping to iCalendar, to allow more representation of data not currently possible in iCalendar (which some developers have expressed a wish for in their applications). Neil. --c029def5653a4bdea6581a9dcec70356 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Wed, 19 Jun = 2019, at 07:13, Doug Royer wrote:
    Great - It needs to be documented in the spec.

    Yes, I have suggested text in a previous emai= l in this thread.

    Exactly how will they be displayed differently?

    I suggest try using a common CUA such as Out= look, Google Calendar, Apple Calendar. These all have an option to mark = an event as "all day" (this is literally the term normally used in the i= nterface), which causes the client to display it separate to timed event= s in the spatial view (e.g. Day, Week view) of the calendar.

    When storing in iCalendar format, clients distinguish = these events by using the DATE format rather than the DATETIME format. I= n JSCalendar we are using an explicit boolean property instead, which we= believe is better aligned with developers' mental model and is easier t= o implement.

    This particular thread is disc= ussing loosening some current restrictions, designed to ensure a 1:1 map= ping to iCalendar, to allow more representation of data not currently po= ssible in iCalendar (which some developers have expressed a wish for in = their applications).

    Neil.
    = --c029def5653a4bdea6581a9dcec70356-- From nobody Tue Jun 18 22:04:54 2019 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 EDD8412023C for ; Tue, 18 Jun 2019 22:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 0LMpXDII-enP for ; Tue, 18 Jun 2019 22:04:51 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 6412E12004F for ; Tue, 18 Jun 2019 22:04:51 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id u13so35321393iop.0 for ; Tue, 18 Jun 2019 22:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=PU7cAqyZxvcz2xQGJR1SDOWidMeHCoxS9thD3KUs5E8=; b=LKYeIgi0sO5lEaX6739Zhi4dvyM9al8Lrpq512ZQM0XALURxoeW3tVgNH/OjX9FwKO m0gS5PAXifFp5Bq9TuvFpYTnqf6lhk8HMBtxQAnZfrAaH8wi6SJw3In/YCEqoh0Z+++G I7Vi5KLsUHFsnD9jr50hWrPwP7lp9fNi5/4PtYBRJ4vvIAriK0m//HpBPw6GjJ715b1u t93XNgouFyjOjPQ/zYfqRdYGnW7F46zR2l57AYIGHq3I8SDkprb3CDpCP4hx/iQ1qFSP J64quMHMVQ/lta6fah5OXHyU8RrqEdFTLBr63ulLnyk2iX4FIeEc5PuPtAHzpboCmReE ZkjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=PU7cAqyZxvcz2xQGJR1SDOWidMeHCoxS9thD3KUs5E8=; b=tY6pW304sszI7MasX9XAgH+XMMCqmhWHSudFsJ8vusMgyJNywN8w8PUskIZHIXS5TU lm3aqhoGOWlkTHZmIUoHa9Ku9SQAXo3iWqxixVPZHlqrqJdYCcbPH8gYtE3q1dE94PKR +GFA9hXtcY/ef/R8Yvlm7Y1H/rVkIU+jChdKSDfXrqwdP3gigql2IB2ZBDPDkTDynDPd w2B73EOgnAdbdk+yXzfzpLfZ5hrE/fykYslChCEZEYP3cFSpUehYFJRcnoZaVJ5XWcrf TMQ7W7sVEMO+KyOS3yIpB/JXqnGTj+7Fzo611JQlVg5V1fVYRV4X01Z+paNzCRBb1fDH ymEw== X-Gm-Message-State: APjAAAUwiV4nchmhCmd7FIPwjnF/YJnqcieheNDyd2PuyUQ3ApKy62e4 kCa6Uhok5aJ6oPMexMC5l83BmSpCuUVl X-Google-Smtp-Source: APXvYqxg3ixn88itf4ieIwAYPx6pHzNy3SmFyOtt/9WktTF11t3FD/p87yQAtIrCdkySB3Ppv9Ydag== X-Received: by 2002:a5e:8508:: with SMTP id i8mr23315879ioj.108.1560920690491; Tue, 18 Jun 2019 22:04:50 -0700 (PDT) Received: from [192.168.1.7] ([174.27.172.40]) by smtp.googlemail.com with ESMTPSA id e188sm19131668ioa.3.2019.06.18.22.04.49 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jun 2019 22:04:49 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Tue, 18 Jun 2019 23:04:48 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000906000506010701020809" Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 05:04:53 -0000 This is a cryptographically signed message in MIME format. --------------ms000906000506010701020809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/18/19 7:20 PM, Bron Gondwana wrote: > On Wed, Jun 19, 2019, at 07:13, Doug Royer wrote: >> TZ is not required, and *is* allowed on Date-Time and Date events. >> >> DTSTART;TZID=3DAmerica/New_York;VALUE-DATE:19980119 >=20 > Do you have a citation to support this statement? >=20 > Mike and I are basing our understanding from reading RFC 5545: Section = > 3.2.19 >=20 > The "TZID" property parameter MUST NOT be applied to DATE > properties and DATE-TIME or TIME properties whose time values ar= e > specified in UTC. >=20 That is because UTC (Z) is a time zone. It has nothing to do with all=20 day or anniversary. A 'Z' in addition to a TZID would be placing two=20 time zones into the same property. That would be nonsensical. > It does is somewhat fuzzy langauge, but our impression at CalConnect th= e=20 > other week when we look at this was that RFC5545 prohibits the use of=20 > TZID with VALUE=3DDATE. The ABNF does not exclude TZID with VALUE=3DDATE. I can not find anything= =20 that does. It is not excluded in DTSTART, DUE, DTEND, RECURRENCE-ID,=20 EXDATE, or RDATE. All of their ABNF allows for it. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms000906000506010701020809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE5MDUwNDQ4WjAvBgkq hkiG9w0BCQQxIgQgt5nLnAa6ecDo+bKJtJ/cUVsa5cNoY2jeTHaNPMuRj6kwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQB72RmX/bWLXAn8xHYuj1S9ctzEBG83gUJe3TjiHCi7klpYoTv2 tMpdM77+f+3RoMPyYA7w6gWljW04ZBN0B+JKt0lEJ7eTeLU8uVJillG7YUrbzB5J7KAMuRMX KaWlyJS8Obj1fMiiEsp47hyAbDtlb3MucJHQIJw8/3Uawm65W+fHrbpjywS4pYk3HTONaJjE WuGzWIwMOvG28YmayIwAGb0ZcfPAjMKVwC6de8Xjz00zRaNQ0ou26OtTOD8ZVGrQo/Ywiiqb kHA7q0hacVtxzFYfZ4fc9yo9d7ZAKPmiedLUbxZwgrHjEDeTVTdiTsjsKbR6/7yNMx+81XHJ h53NAAAAAAAA --------------ms000906000506010701020809-- From nobody Tue Jun 18 22:23:40 2019 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 8421612031D for ; Tue, 18 Jun 2019 22:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 nZfASS_-27Xr for ; Tue, 18 Jun 2019 22:23:37 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 16B7912004F for ; Tue, 18 Jun 2019 22:23:37 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id w25so35233233ioc.8 for ; Tue, 18 Jun 2019 22:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=bpUQUhUe6SJqz2QpPoZ1yJJvqDmn3QbFQLN2s6Qx2ys=; b=rdTnMbTgrzOj24rZQVkvFlIPZmV8l+779RyW5pn1B4iACfawwR1cP9erQxR3CKTFbC pnCFUkVntW9MzglxDk0OxeU83bVXRAY5WLFE94qu7/RRVX200U2VLSnDHcGxpuvfRVIP 6R8bHaFtro0reoOfnyJm6gvjI5ck7admFDfKzWW9htNkpckEWGWecSTcEzJbKqS1RWFg bfDuJcmNiaVOJCSltdDvLV8PZ6tlcmGMYGgpII9zHaL2Vl+IXY2zcBr3H/e35Na1BFB3 VrLsUD253nkDlFfeX/klX/xdNAoOGOD72Vjh0QWvpbtPA0rIQs2h5KBmLafP3UNl39nc lH3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=bpUQUhUe6SJqz2QpPoZ1yJJvqDmn3QbFQLN2s6Qx2ys=; b=MJuDn0y1KwmUJtxxvvM6PAt8Fu0aeFcFJTS+XbvlbwmHRI6WC5PlXQ+vz96Gcz34J0 JGzT0i/BEfErckK8j9jJjMCAI0zhoyX1MpXjDXmJ8NyUDx5+i0+4q5Lvd8kZv34uxEDp SKhro52hayjXCd4ycl14ySnCHHKK4Th/jG4esD3fSxNZgYs1volI6ERgNDFzVCBqljz5 ZIKIl0Pu5hpfyjS6VhvIjzjNIJAhfu4Ix5ANr/jNy+sYMCKSorarARRJXvNqoVKc1j7B hR5s4rGEVeV2fYK3mTitW7Ac9FVeVh2teiEGBSUqMP199JAtb04L4ZhQLLvYrrJwAbRW Wk2Q== X-Gm-Message-State: APjAAAW/UoqczWSK7incHm+v0Ft2LppdcUprRN2mYiqIRW0YVEqE1Jh3 awC8XpYRpISsRISq2Pv2IJyyxzu/NcRe X-Google-Smtp-Source: APXvYqzFNIOMjQt32DYKo0opd81yziDydvvdYKUgnYNeGgpXTwoZrlPj2ZuYaIu1YeM9E3UK6cTvCA== X-Received: by 2002:a5e:c803:: with SMTP id y3mr7645832iol.308.1560921816025; Tue, 18 Jun 2019 22:23:36 -0700 (PDT) Received: from [192.168.1.7] ([174.27.172.40]) by smtp.googlemail.com with ESMTPSA id a8sm14724460ioh.29.2019.06.18.22.23.34 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jun 2019 22:23:34 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> <148d9346-06fc-45c0-9c69-b486578b24ed@beta.fastmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Tue, 18 Jun 2019 23:23:33 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <148d9346-06fc-45c0-9c69-b486578b24ed@beta.fastmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090400040308040104030002" Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 05:23:39 -0000 This is a cryptographically signed message in MIME format. --------------ms090400040308040104030002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/18/19 10:28 PM, Neil Jenkins wrote: > I suggest try using a common CUA such as Outlook, Google Calendar, Appl= e=20 > Calendar. These all have an option to mark an event as "all day" (this = > is literally the term normally used in the interface), which causes the= =20 > client to display it separate to timed events in the spatial view (e.g.= =20 > Day, Week view) of the calendar. Yes, my question was as defined in the spec. And the fact that its usage = is not consistent. Some apps give 'all-day' events with a 1 hour=20 duration (or maybe it is the default event duration set by the user=20 settings). Some have no DTEND (anniversary). > When storing in iCalendar format, clients distinguish these events by=20 > using the DATE format rather than the DATETIME format. In JSCalendar we= =20 > are using an explicit boolean property instead, which we believe is=20 > better aligned with developers' mental model and is easier to implement= =2E I can not find an RFC that defines 'all day' events. Just anniversaries=20 which some use to mean 'all day'. > This particular thread is discussing loosening some current=20 > restrictions, designed to ensure a 1:1 mapping to iCalendar, to allow=20 > more representation of data not currently possible in iCalendar (which = > some developers have expressed a wish for in their applications). I still do not understand the concept of 'all-day' that is not really=20 'all-day'. Do people really mean anniversary or day (daily) reminder? When I check 'all day' on my google calendar, it removes DTEND, which=20 makes it an anniversary type event. Then shows it consumes exactly=20 24-hours when I get a summary of events. On the calendar itself, it=20 shows zero duration. The google android calendar app seem to do the same = thing. Thunderbird keeps DTEND making it equal to DTSTART and takes away the=20 TIME value from DTSTART and DTEND (making it VALUE=3DDATE - WITH a time=20 zone). And views as a 0 seconds duration event on the user interface.=20 =20 =20 =20 So, looking at what I have, there is no consistent meaning for all-day. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms090400040308040104030002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE5MDUyMzMzWjAvBgkq hkiG9w0BCQQxIgQgE+Q0N+QsK3PEm3ElNA16WLRDiI88Y4WRe8pBDAxsx2MwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQBXpHzJwqO0F77nFQKgmMr6VeyncIDIV2mO/STRfYg2WbY2rCnL zO/oUSJ1QagPiQ1VqWsM6fTr4VJM333UnkyAIsXFtPn40l1ln2eK5BVFv50QC7NVJcOBNgX4 gwFlMgBWgD9yCwCH1dGWsVU8Kyw9G+5RAejsqRjZpYmT+zeLQoC8908qt573oB/bN6jbpFbJ fVf3FxNN+WwoUXAs54r4UjYW5b7ZBGJUMJMeofbiaz/vkm+HMz144ccJwnQsggDuf7jSCZr4 2Fht7YXb8sIDt6z9WCFBUBv6R4uWrRCU87q0rUaZlbWI4PYdf42Bp6lguEOiryHFRoTDv+ap ZJBmAAAAAAAA --------------ms090400040308040104030002-- From nobody Wed Jun 19 01:40:48 2019 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 9CC5612016C for ; Wed, 19 Jun 2019 01:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=XKl3Fy4U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pzhB7XqX 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 sjcOanDX3bR8 for ; Wed, 19 Jun 2019 01:40:45 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8959612002F for ; Wed, 19 Jun 2019 01:40:45 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 80C69223DB for ; Wed, 19 Jun 2019 04:40:44 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 19 Jun 2019 04:40:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=qW3I8kk f2/Gj4LfQ8+3GIf+0znTr7yKP1Pda6xC0wP0=; b=XKl3Fy4UyfPIFMgzCw3zp4n Bhi3nHHUuVbAyFaahScppJhbEB5IQXkhJFFWkdu9eY6hGYlmb0wz6qJ+/aUSrWOa 5LVcptXToMlqR/sGPj9SG37/NxyonH8IDeyV9sUcqcptYIAprMhZJlkMOZrPFBvg KAmjW7X33+Mx/EclnIlFIfjgIe+JBlGRyD7x0uFuIsKhIT2Fyh780mGfHpTvLh5D HyRC41OLX7Yr21X7H/abhzJSp93PQXoHItYwq3B/2LpNp8XagTNXqUoPYyieTkSu zQ5BjXawGluo90JcuQH1XPsQoF537i6h92rsPUHbhCUfM5uI+6TgDevPdRowDLw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=qW3I8k kf2/Gj4LfQ8+3GIf+0znTr7yKP1Pda6xC0wP0=; b=pzhB7XqX+iELBOBQpwNwA+ 65Cooyk5j/MBlkPqkugYmFuSG3PvyerRUzO3p2nEmpfpuS6JHDzrpjPH+nOlgcSK HT39ZHcFG8C3eUFdPPKDU8wmzHqJLfvvAwPFXtQYK3mdYd+V8Q/HuyjUSBuLM3/5 EgWKLMrVkdkJ4MbKrVQW06w0AYc+MItvfP2NoQcm2GW/VUp8tF5kZ+QBFkwLw3QD WZTyAFsrstkpqTU5YYHOYbHhvVOqGILnfC0HGQlqpR88goIc9OFNPJKeZ8tqBp+D vBWgbm8qepaBNYCg9Q0d7cBRoTzzWL7q5mMJvcz5t1TB6wBA5iJ+k/NWtfs3LMCg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtddugddufeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E6ED318073C; Wed, 19 Jun 2019 04:40:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-727-gabab71a-fmstable-20190619v1 Mime-Version: 1.0 Message-Id: <68de4336-72ad-46fa-89eb-75c6dd44f69d@www.fastmail.com> In-Reply-To: References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> Date: Wed, 19 Jun 2019 10:40:43 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=3c397d7d922a43bf971506e230e0366d Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 08:40:48 -0000 --3c397d7d922a43bf971506e230e0366d Content-Type: text/plain On Wed, Jun 19, 2019, at 7:05 AM, Doug Royer wrote: > On 6/18/19 7:20 PM, Bron Gondwana wrote: > > On Wed, Jun 19, 2019, at 07:13, Doug Royer wrote: > >> TZ is not required, and *is* allowed on Date-Time and Date events. > >> > >> DTSTART;TZID=America/New_York;VALUE-DATE:19980119 > > > > Do you have a citation to support this statement? > > > > Mike and I are basing our understanding from reading RFC 5545: Section > > 3.2.19 > > > > The "TZID" property parameter MUST NOT be applied to DATE > > properties and DATE-TIME or TIME properties whose time values are > > specified in UTC. > > > > That is because UTC (Z) is a time zone. It has nothing to do with all > day or anniversary. A 'Z' in addition to a TZID would be placing two > time zones into the same property. That would be nonsensical. We read 'The "TZID" property parameter MUST NOT be applied to DATE properties' as 'The TZID property parameter MUST NOT be applied to properties *with value type* DATE'. Regards, Robert --3c397d7d922a43bf971506e230e0366d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Wed, Jun 19,= 2019, at 7:05 AM, Doug Royer wrote:
    On 6/18/19 7:20 PM, Bron Gondwana wrote:
    &g= t; On Wed, Jun 19, 2019, at 07:13, Doug Royer wrote:
    >&= gt; TZ is not required, and *is* allowed on Date-Time and Date events.
    >>
    >> DTSTART;TZID=3DAmerica/New_= York;VALUE-DATE:19980119
    > 
    > Do = you have a citation to support this statement?
    > <= br>
    > Mike and I are basing our understanding from reading = RFC 5545: Section 
    > 3.2.19
    >&nbs= p;
    >        The "TZI= D" property parameter MUST NOT be applied to DATE
    >&nbs= p;       properties and DATE-TIME or TIME = properties whose time values are
    >   &nb= sp;    specified in UTC.
    > 

    That is because UTC (Z) is a time zone. It has not= hing to do with all 
    day or anniversary. A 'Z' in add= ition to a TZID would be placing two 
    time zones into= the same property. That would be nonsensical.

    We read
       'The "TZID" property= parameter MUST NOT be applied to DATE properties'
    as
    <= /div>
       'The TZID property parameter MUST NOT be applied = to properties with value type DATE'.

    Regards,
    Robert

    --3c397d7d922a43bf971506e230e0366d-- From nobody Wed Jun 19 07:21:08 2019 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 06F16120605 for ; Wed, 19 Jun 2019 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rlykRBMUgh5R for ; Wed, 19 Jun 2019 07:20:45 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id D7F091205CC for ; Wed, 19 Jun 2019 07:20:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 41F8B300C3D821; Wed, 19 Jun 2019 10:20:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Egf10jdvYDwF; Wed, 19 Jun 2019 10:20:43 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 5AA8A300C3D810; Wed, 19 Jun 2019 10:20:43 -0400 (EDT) Date: Wed, 19 Jun 2019 10:20:40 -0400 From: Cyrus Daboo To: Robert Stepanek , calsify@ietf.org Message-ID: <6249690360859C0CCA4EF7CF@caldav.corp.apple.com> In-Reply-To: <68de4336-72ad-46fa-89eb-75c6dd44f69d@www.fastmail.com> References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> <68de4336-72ad-46fa-89eb-75c6dd44f69d@www.fastmail.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1823 Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 14:20:53 -0000 Hi Robert, --On June 19, 2019 at 10:40:43 AM +0200 Robert Stepanek wrote: >> That is because UTC (Z) is a time zone. It has nothing to do with all >> day or anniversary. A 'Z' in addition to a TZID would be placing two >> time zones into the same property. That would be nonsensical. > > We read > 'The "TZID" property parameter MUST NOT be applied to DATE properties' > as > 'The TZID property parameter MUST NOT be applied to properties *with > value type* DATE'. Yes, but let me quote the whole sentence here because there is a slight problem with it: The "TZID" property parameter MUST NOT be applied to DATE properties and DATE-TIME or TIME properties whose time values are specified in UTC. I think there is a comma missing here! There ought to be a comma after "DATE properties", which would make it clear that the whose clause applies to DATE-TIME and TIME only. i.e., the correct interpretation of this using parenthesis to group terms properly is: TZID MUST NOT be applied to either (DATE value properties) or ((DATE-TIME or TIME) properties whose time values are specified in UTC) I think the missing comma is a minor infraction, but one that could be fixed via an erratum if needed. In any case I think your further clarification of adding "with value type" is correct and could also be part of the erratum. Even if one were not to agree with that, at best all that could be said is that 5545 does not define how TZID is interpreted when applied to a DATE value property. In all likelihood it would not be interoperable. I would guess that many iCalendar libraries might simply ignore it and not round trip it since they will likely use platform specific classes for date and date-time representation -- Cyrus Daboo From nobody Wed Jun 19 08:29:01 2019 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 ECC051207A7 for ; Wed, 19 Jun 2019 08:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 TpTd4QPS3cba for ; Wed, 19 Jun 2019 08:28:58 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 D9844120757 for ; Wed, 19 Jun 2019 08:28:57 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id m24so39186039ioo.2 for ; Wed, 19 Jun 2019 08:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=nwt30qK1gcZDD9gtS6+rRCQL4mbePt9BTEV8OnM/Tnk=; b=fljNFDktiWFM7DE2+O9JmDFpZrCc0lWvUe37n3hJ7DcKPkK+TxyQmgTIiOtesOWAGh e355c6fZwd/f2k2bFCDJmaDSsF4SQgfe97qXcq9wyE6bkaVTGvgL8hN10Jj/Gz3HMG/D gc6hQlQxClb4WHD17mWFN2jP4y+0hOUJbskOFe1Vo28hu2Ea60vPMvMgz1w0+IMeBJFk EORyYCPnCIsiwCyvGkC4JRLSQjBkJERil7Hcou+8hAMsK6tS3zYezTg8VtA1Un4/hGE2 DoeIDO4r7VCo4eolKWXfy8zXqHztYGFJGrA0wt8EAzdF+mUmjtJ3UWh09vlbXmIPMSlC M+dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=nwt30qK1gcZDD9gtS6+rRCQL4mbePt9BTEV8OnM/Tnk=; b=XdQChxVtziIBKk7NUKEfdxtZzDQEMD20vI2JhWxoXzCnUu1+A2NrjdUx5sxgHGT5NW M2G2vmjYOwkdm+0c8tvYGsLsv31bHAm6eXPxR8OSFwOYV2nzzlfpBLduOeIqozQsCZPq uXBmkSCtea2Z6ZKU3InVuM5TJlUXwj+XAmP0E/DFtks1IvjJpZ32B9KuXSJMcstlK1mq tpfHzkxPR81RvyhN8LlTYxG8Oobz66s/hqxkTM8YVDwTsCVSj/PYWqI9kpqAwwFPb4rQ CIPdHPg7lrL+JraOBWgv4rLce/7xODSa1CaqJ7tslBeTqftKbdMZq8R4/EYpxuDPftKm Z4JA== X-Gm-Message-State: APjAAAWKenc4jvZnjYKBv/RdqeAgSExghI4+tzwMVNTwdDbo3XFRZY7x K72rjWw6no98C5kNNZnqAyS+bAnlr1YH X-Google-Smtp-Source: APXvYqyOUGb3DbuBqtH6HqGbLTLMLJHO3cNIddPjDAodEsu6B7xKqsk7Rpc7GKkqW/6DzwUzxSumQA== X-Received: by 2002:a6b:7e41:: with SMTP id k1mr6847994ioq.285.1560958136709; Wed, 19 Jun 2019 08:28:56 -0700 (PDT) Received: from [192.168.1.7] ([174.27.172.40]) by smtp.googlemail.com with ESMTPSA id y20sm15030029ion.77.2019.06.19.08.28.54 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jun 2019 08:28:54 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> <68de4336-72ad-46fa-89eb-75c6dd44f69d@www.fastmail.com> <6249690360859C0CCA4EF7CF@caldav.corp.apple.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Wed, 19 Jun 2019 09:28:53 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6249690360859C0CCA4EF7CF@caldav.corp.apple.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040107090701050905080908" Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 15:29:00 -0000 This is a cryptographically signed message in MIME format. --------------ms040107090701050905080908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/19/19 8:20 AM, Cyrus Daboo wrote: > Even if one were not to agree with that, at best all that could be said= =20 > is that 5545 does not define how TZID is interpreted when applied to a = > DATE value property. In all likelihood it would not be interoperable. I= =20 > would guess that many iCalendar libraries might simply ignore it and no= t=20 > round trip it since they will likely use platform specific classes for = > date and date-time representation >=20 In the ISO standard ISO.8601.2004 referred to in 5545, you can use=20 200004 to mean 1-April of 2000. It also allows for 20000401T01 to mean=20 1am (0 minutes 0 seconds) on 1-April of 2000. I no longer have the pay to see ISO standard. I do have my notes from my = old code. My notes indicate that omitted values are the same as the=20 first valid value for the omitted data (as in 20000101 =3D=3D 20000101T000000). Does someone have ISO.8601.2004? As to date-time classes, the ones I have looked at in the past, they=20 default to zeros for values. So 20010101 is the same as 20000101T000000=20 in those implementations. Maybe that is why it has not been noticed befor= e. They also default to zero for month and day of month. I suspect no one=20 uses that feature and the implementations use and set at least year,=20 month, and day. They seems to work maybe because they default to 0 hours, 0 minutes, and = 0 seconds with their comparison operators. The ICU date-time libraries also know the difference between a date and=20 date time value, an can compare between them. NOTE that the WWW also treats omitted values the same a default value. See https://www.w3.org/TR/NOTE-datetime "Examples 1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 1994-11-05T13:15:30Z corresponds to the same instant." For which I read that as also with omitted time. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms040107090701050905080908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzEwggUZMIIEAaADAgECAhBn8vXwDUV8978WdKwnVwFkMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDUxODAwMDAw MFoXDTIwMDUxNzIzNTk1OVowJzElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVyQGdtYWls LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDGtlMsQ9o1mpdyueu44VJD Uu+u08pKoLokLqdi3Ago8npLii0AdXuvqg1YcQKgJ3Dt65Be9VTHUHNjk28Yy7ntvowGEvQA JlGtke75veRr5QFwrI6pBymzZyTkBmoSipHULdMSk5cKNtJENgI9wkdXShZvFTt/Pw7Pp1bJ coMC+xyVO6mRZSVLwPGmU8+nbl/lby3rVNWLPK4BE3x16sT6vh6zJ4K5w5p+fP/56wblijj7 LtoSq2m5jooReuoH6YxrxTeVTHMPmfwZ07+2V+sQLCwa6U/a79MCLa97i1IO/Cd/WcUyJhr9 24AF4zpo3hOotNeAdexytwgcW6NcVMsCAwEAAaOCAc8wggHLMB8GA1UdIwQYMBaAFAnA8vwL 2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSdtH5JtCEZQAtueVSI8sco3w0THjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0 aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9T ZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYI KwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3Rp Z29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJA Z21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQBd6kxTPVg6p7WyEpDE/OJs0XiiD1PRTtTx uRA7lDv6I5D1WkMzsZgynK6+j+RHZ+d5rbyy6zRC6BPnMRJVLaJr7gHy/xpbs1FuPzvYhDRg NSkGqDUDeo4c6sa1lKrvRWVgCw5/WDCurxiq9GSjR4WM2v1kcbasCIpXmUaReALQWDXsBXrf 838JtSa3kZ0WfDuc0ngfNfmFwK4rZ0ytTVy2W3YJnU5JQMP5IXzhXrHKzwmsXCmKVUX/AbVV 5adx1RephWcbXYn+QD6rAEx82/gpIoBvzpB6Tf93UE5xus3UPXTATArhT4X1vbZrqaZt7krA PF8hPvNCw0njI1sLV7HqMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG 9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgxMTAyMDAwMDAw WhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4w PAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY7 5tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHb SuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfq B6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJORHtbC 0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3ndD3sA3If/JBz 6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULPyeCtADAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9j cmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNy bDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3Au dXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6VbTJxaIwA3RfX ehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQNRsJiD4KLu+E2 f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lKzcT+mLO1NLGW MeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF 8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bw c/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F 2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORds NmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8plBNK cIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY0fO5ssebmHQR EJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWYLcAi14ACHuVv JsmzNicxggQyMIIELgIBATCBqzCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVk MT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDANBglghkgBZQMEAgEFAKCCAlcwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNjE5MTUyODUzWjAvBgkq hkiG9w0BCQQxIgQg1/JFsHDsCKii6KxltnMD2Fu5NOfdc1yVBshnq8SVtSYwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvAYJKwYB BAGCNxAEMYGuMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhBn8vXwDUV8978WdKwnVwFkMIG+BgsqhkiG9w0BCRACCzGBrqCBqzCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEY MBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ/L18A1FfPe/FnSsJ1cBZDAN BgkqhkiG9w0BAQEFAASCAQB9ptwcJ5QmidICx3+GFtJhlnikEpTLf7/rD4LodV4yvwZ0Mhys vbiXo5HnFbH9qMi9mvaxGIEmMB04Tlnbz5A7A98xYO4lSIaapeazxMNjzoCozif1LoJGrJQS tDUmhB0RedVEWYVx2vWPDIq+8D4f+cI5EaoOoLrog20E0pURjE9mQsFO3iEXD7IuVE8D8+aF q6/t+y2+3qU86ASPKgk2SkmQwg0z7w/c4Ow54+1zcy+GZX3Vqt3eGPFzAS5LKh//+aItX+bB BpSsGWI3f6pw/hDPt4+OHWcvW473PMcaL9WhW7as+FAM2W+QrPAzlhZWQWWdfVM7vTBs1cch 58uHAAAAAAAA --------------ms040107090701050905080908-- From nobody Wed Jun 19 10:49:42 2019 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 508421206FD for ; Wed, 19 Jun 2019 10:49:40 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=googlemail.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 b9RrE-3F3q8S for ; Wed, 19 Jun 2019 10:49:38 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 A739A1206FC for ; Wed, 19 Jun 2019 10:49:37 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id s3so383012wms.2 for ; Wed, 19 Jun 2019 10:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Dm+Z06gJAdgVg7CeryoRGFHiu1+VlrVk7am7nYIL4zY=; b=Z3H3KYyTpX6Qi91DbCXbWZEzwaLiGckTIFAphUQJqSZpIMN65J7agYjVLRG7uYd8+b gwPzatTK83Rmo017/wpJ0JX1vEbB22eSpB6iZ7sWZtTVHXSthB57q0sCbB758fB3hMyi m/ac3rGQqi0LRIuEiJTVgUyduMiv1e2mqLOesQnHvKtg1z0VbI+Qmk21yI3vem2dX3Xc ZJ5g8NVGGsANlp5NuUtbilwOK/TkjdtlZKzUPJm3Zl/oB6+pL2Wt6X8WIVCheEOAWx8d yjtGOma7Vmz/3xkFKeRje66PdvtHCW0XJTZPt8bZbUiKLYRHGX46ZVCwtHuONVSaznEq G1gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Dm+Z06gJAdgVg7CeryoRGFHiu1+VlrVk7am7nYIL4zY=; b=qnb1OvyFt/mAGSA2tH6GpBBRWPFglGdu2AbicMBUoaKl3xUq7Z/BrGYKwp1VkIJ1gl LR8PmqlgVowwJoifdpUaSNzR0eUGbe1CeGf2cKgDgnki51pY2opHCSARBxdxtut9vDr2 4U4aFxvNuk5gp7YPlAIn29Q0VhPK97CxIe/qSzrzhjdAiTSwP78YvaNwlKXiVvwTVQa5 9nKJvC/bp1zm8H8M1UfSzwe2+qTk/pkHO5o3Z311LclESaCimq4D1kxQowqjOZUfXYKP EhE3SfqtgeN6bEqlFrTiVvcI3UuPgfdzw23GiAc8oTtpIsNYphjlECFrzcK6im+pdmUE sp7g== X-Gm-Message-State: APjAAAWHmoGk1UdQlaDlEEDQ3wVjAZsl+xibMqz58d553kNQXpHCYeBt 0QphYxcWI3g7X0OCxv+7tTuwQc/G X-Google-Smtp-Source: APXvYqywHhqrbRinStc82NGX3dtwLxDc+VpNccwXK0hBDl8D+f3I2ZULnSsX7SGRygPS/o4SuVNJsQ== X-Received: by 2002:a1c:7f93:: with SMTP id a141mr9430630wmd.131.1560966575915; Wed, 19 Jun 2019 10:49:35 -0700 (PDT) Received: from [192.168.1.107] (ppp-46-244-251-231.dynamic.mnet-online.de. [46.244.251.231]) by smtp.gmail.com with ESMTPSA id d201sm1242062wmd.19.2019.06.19.10.49.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jun 2019 10:49:35 -0700 (PDT) From: Michael H Deckers X-Google-Original-From: Michael H Deckers To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> <68de4336-72ad-46fa-89eb-75c6dd44f69d@www.fastmail.com> <6249690360859C0CCA4EF7CF@caldav.corp.apple.com> Message-ID: Date: Wed, 19 Jun 2019 17:49:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 17:49:40 -0000   On 2019-06-19 15:28, Doug Royer asked: > > In the ISO standard ISO.8601.2004 referred to in 5545, you can use > 200004 to mean 1-April of 2000. It also allows for 20000401T01 to mean > 1am (0 minutes 0 seconds) on 1-April of 2000. > > I no longer have the pay to see ISO standard. I do have my notes from > my old code. My notes indicate that omitted values are the same as the > first valid value for the omitted data > (as in 20000101 == 20000101T000000). > > Does someone have ISO.8601.2004?    ISO 8601:2004 used to be free for a while, so I can send    you a pdf (239 kB) copy privately.    Note however that a new standard ISO 8601:2019 in two parts    (8601-1 and 8601-2) is in force since 2019-02. The first part    is more or less the same as the old ISO 8601:2004 and is    available online in a pirate version at    [http://biaozhun.doc88.com/p-8751736368436.html].    The second part also used to be available on this site, but    I cannot find it right now.    Anyway, in the new ISO 8601:2019, dates without time may well    have a time zone offset, but only in the new explicit format,    like:             2019Y06M19DZ+02H    In the implicit format 2019-06-16, time zone offsets are still    not allowed.    HTH.    Michael Deckers. From nobody Wed Jun 19 14:42:58 2019 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 522B6120497 for ; Wed, 19 Jun 2019 14:42:57 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 V6wskXP7hf-j for ; Wed, 19 Jun 2019 14:42:55 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 60BB51202E5 for ; Wed, 19 Jun 2019 14:42:55 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id u8so1019753wmm.1 for ; Wed, 19 Jun 2019 14:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=CcVdwsP1Bj8UI/mLztcDKyQ/48A4fZDlecGfnKIX9Mw=; b=Clbm+bbFBt2JiSFndocdQmz+eF7olJNOPfM2Bvh0Bj7YiAnLE2Ia7oeQLxF73/oFpG d1LpNFC+g1w92/rLYYs1Xdpcj9lAfdD+R1HwfDowiZxph0xeogQJoHDaKHkmDC/S9ctO PRQed4Gcfqb5D0mZDegV2invwMXe/0LEvj+mnZBuVRowKWAq35ASnqRNHCYab/0alWyK Mgidqlr0DsfoQmdRNut987DCSBD1SXKTvFPaoWC4UfwsVWx81EY3H78oP06BeIVCsz8m /k6JRS0nzN0LHXokkv5tLNTwJfOISBS8YimmoIIhLiXzv4ZPis0W/rzoq8HGbGaV3IuA m3VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CcVdwsP1Bj8UI/mLztcDKyQ/48A4fZDlecGfnKIX9Mw=; b=TgFYcN594qcJTYo2zXUuPb0J8lPoFblZ15BHffMP8Ibla+kRcFOKQMnEXnlpl/Hhq+ 7HSsPCTzWvAkG0W9BtAVlWugxwS79EvSHBAl8tDr1PVjC5xgYpA0mCTpXmSXKJZC46mR xhAIOL5y4gC0h0y2WK+wLFt2STnQ4/OiFlpD71mcvJ+eg3S5vbvC8pZraSrwRSuGHshz VfjTDXyhIw+GzeunzyfAnQfytKtLPR478aiNOuTRIPDQ6q3jEmSNvJlDEBLGaccMgjUW yqMuvJF41o1BfrBITPEp93SDyn3m5nr+SVdq+IBkOiuv6n/N5XPjmJewWWO7uL4WKZX0 xbeA== X-Gm-Message-State: APjAAAVAOe8LGexrSz3fkaoNOHXX3cBG5T0k03qHeT58Hg2D0DqljBgp H/I0fRo34z1zq8yxqcL9hgdPc2Yw X-Google-Smtp-Source: APXvYqyOe4UtXWUy2Vlikov5FyB1DqWgkjroV+hlJJ3hkLrasKeTI9BxlX4oRapuUDsqG1dQpGw3Ug== X-Received: by 2002:a1c:9d86:: with SMTP id g128mr10595498wme.51.1560980573691; Wed, 19 Jun 2019 14:42:53 -0700 (PDT) Received: from [192.168.1.107] (ppp-46-244-251-231.dynamic.mnet-online.de. [46.244.251.231]) by smtp.gmail.com with ESMTPSA id i25sm8191809wrc.91.2019.06.19.14.42.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jun 2019 14:42:53 -0700 (PDT) From: Michael H Deckers X-Google-Original-From: Michael H Deckers To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <69247523-c59b-49b2-9304-3f460cdbbc24@beta.fastmail.com> <2da7e240-326b-23fb-3a29-190d4b65f31f@gmail.com> <8397aa6c-4924-a47e-66c4-98f4b459e70e@gmail.com> <68de4336-72ad-46fa-89eb-75c6dd44f69d@www.fastmail.com> <6249690360859C0CCA4EF7CF@caldav.corp.apple.com> Message-ID: Date: Wed, 19 Jun 2019 21:42:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 21:42:57 -0000 On 2019-06-19 17:49, Michael H Deckers wrote incorrectly: > >    Anyway, in the new ISO 8601:2019, dates without time may well >    have a time zone offset, but only in the new explicit format, >    like: >             2019Y06M19DZ+02H    This example is wrong -- the positive sign is not    allowed in extended format, so that one must write             2019Y06M19DZ02H    (String comparison of two extended format datetime    notations without leading zeroes yields a strict semantic    comparison.)    Sorry.    Michael Deckers. From nobody Thu Jun 20 11:24:07 2019 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 994C412011F for ; Thu, 20 Jun 2019 11:24:05 -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, SPF_NONE=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 sA3eHLX9TJ0U for ; Thu, 20 Jun 2019 11:24:03 -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 EAA111200F3 for ; Thu, 20 Jun 2019 11:24:02 -0700 (PDT) Authentication-Results: mail.aegee.org/x5KINqWQ023054; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1561055033; i=dkim+MSA-tls@aegee.org; r=y; bh=p4L6Im7N0vXpcaYZ2YYxFg0Xd//OewhF+iCZyhU29Vo=; h=Subject:From:To:Date:In-Reply-To:References; b=rOlgxrZNTotv2+cIkrOxN0DDoxiyQ0Ub7o9g5EyQP4Zufsa+pseNamzOlekqklJSS k8TptzZOV25qusZdf5t/gxTbtyL8JwNJ5dUlsL3tjFjKe8alJ+6FJbHO/FhmJ2A1x0 E1jtDR27JGDxB5Nz6/S79mBxHs8Tu624e7vrY6QRWfCZsdYdBkO7z3avll4indUPlJ miPsV+FhJhZ0P8vUSLe0HDu8z1RhpzCD9k6f3TDa4SbFmAuvh0i4e179JhFOX2o/8w t16PDaqcVkS9MHAQ1bNoqjXEtFMH7GmcE7vAo/fYTrJFTpFWGaUzonDNxLQb86o3Bp SjG75QtkEe+RnfTdQ3eF4r1xbmz7uYE3fgMQe+QGTD5sEyZb3J6NFHwHtjRi+ddam+ GQlrYTEzBOh59aA5hRo4xVqtAoAj6KII0ut3Si3Adr/HobPpiw9seCmTY8QBNiXWQr 7sc9KBTRyiwppYb+T8fVtKl0kbAAx5HOmPoczRkD7yvjaInhQk6hhuNHonY5+rEfWv md7ii2Y+X76NKgX2IwNawyJ3GjvXJVD6t/5w7gQ0paAr9waTOJfa7pNLRSA3pjXtR3 ti11dvBJsnSAiKBA39+Ib+6LlQTqs4tzxld5glMLf8x8LNaVdhFisPrQyUoM6J4R4H udictG1dRK+Lb0zZwo/I71j4= Authentication-Results: mail.aegee.org/x5KINqWQ023054; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x5KINqWQ023054 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 20 Jun 2019 18:23:53 GMT Message-ID: <4dea3a75f19539914b96cd361053f7309e547bfd.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: Tim Hare , calsify@ietf.org Date: Thu, 20 Jun 2019 18:23:52 +0000 In-Reply-To: <01a701d5264a$ae2d56e0$0a8804a0$@comcast.net> References: <01a701d5264a$ae2d56e0$0a8804a0$@comcast.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [calsify] Asking for feedback on an idea for an RFC5545 extension X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 18:24:06 -0000 Hello Tim, to elaborate on your uses case: - the users want to import in their CUA one calender (iCalendar object), or actually an URL to that object, but get updates from three calenders, whenever they change. - the use case is for the HTTP(S) schema, although FTP would in theory also work. The current approach for the use case you described, is: - the user registers to a server, per RFC 6764. The server communicates to the client which calendars it offers, here three calendars, and the user choses from the list which calendars they want to subscribe. Clicking on five calendars, out of five offered, is not a big deal, neither is selecting five out of ten calendars offered. What is the problem with the approach per RFC6764? I do not know if this scales for 100 calendars and if there is a use case for 100 calendars. That said I do not see the added value of INCLUDE in the use case you provided. There are other in considerations, covering the same use case: - webcal subscriptions, where the user provides a server/domain name and the server communicates to the client to which calenders the user is subscribed. Lets say, this can be used by the server to communicate to the client the subscribed calenders by default, and the user can unregister from each of them - webdav sharing (https://tools.ietf.org/html/draft-pot-webdav-resource-sharing-04), just without the Notification part and without the calendar sharing (scheduling) parts and without the invitations. Greetings Дилян On Tue, 2019-06-18 at 22:57 -0400, Tim Hare wrote: > Before I go through trying to write up an RFC document, I thought I’d float the idea here first and ask for feedback. > > I would like to propose a new component, INCLUDE, at the BEGIN:VCALENDAR level (the same level as PRODID: ) > > INCLUDE would have a value that was a URI referencing iCalendar object. Implementations would read in that object, discard the “envelope” (BEGIN:VCALENDAR / END:VCALENDAR, VERSION, PRODID) and add the other items to the current object. > > One use case: when an organization maintains calendars for several different parts, but would also like to include all of it at once. For example - a senior center maintains one calendar for language classes, one calendar for meals, one calendar for special events. The sub-organizations maintaining these calendars only need to see their calendars, but to publish to the public all of it needs to be seen. With VINCLUDE this “overall” calendar object would be > > BEGIN:VCALENDAR > VERSION:2.0 > PRODID:SeniorCalendar1.5 > INCLUDE: https://seniorcenter.org/calendars/language.ics > INCLUDE: https://seniorcenter.org/calendars/meals.ics > INCLUDE: https://seniorcenter.org/calendars/events.ics > BEGIN:VEVENT > … other VEVENTS in this calendar > END:VEVENT > END:VCALENDAR > > > Obviously this idea needs to be “fleshed” out, and some issues looked at – such as how to handle an INCLUDE of an object that also has INCLUDE(s) - but I see utility in this idea and other places it could be used. If there are others who think it’s worth the effort I will try to work on an extension RFC for it. > > Thanks for any and all feedback > Tim Hare > Interested Bystander, Non-Inc. > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Fri Jun 21 14:21:40 2019 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 DFD791203B2 for ; Fri, 21 Jun 2019 14:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 3ckv8anUqy35 for ; Fri, 21 Jun 2019 14:21:36 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 3BB5812008A for ; Fri, 21 Jun 2019 14:21:36 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id a93so3589367pla.7 for ; Fri, 21 Jun 2019 14:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=Dk5qYzRIXarBV64Ee2ltX8TcasFg9P/lsjHl2MeweEE=; b=QMs1wom6gZohNhpK6ITqeUmHN8e6ylZb8/1kQoC1bpuoMn/LjMFgXrkEEW3uH8S6Wg pPsqAjEMsae6ctJIRjOg9IqiEhGVKfSOY7iu/ah3xA0tBCOQeLvVGW/pDhJnqLnrFBhA IPxOFOr+2xxZUnGNwsYm6KaxiK3H4CIiYss2aXoEitB2bjkUosd+OiBrB8EsgGUAR4Qy wbow7xqFZw5m201ylLFS4VhDiE2C4TyxxeMy+hLx05gl26leJfbmSsLJ+KtibS3FS2u9 9SC2IVe2gOi0ToNliHF3UQyQC4hiuBUmu/xrxsQWRx1Yn6LQ5r3ZjUNbfJ9azCfXHs97 NgGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=Dk5qYzRIXarBV64Ee2ltX8TcasFg9P/lsjHl2MeweEE=; b=T6nM7PniqgNclchdxiEWLzIhnZp5Lr/vT2IIhqFK5KhYjQBfjble05tVYj5Y4TDHNH l4UTk/8qUfEBfTi/hPEFlZZHo2piWnhF6vOqBNvGt1cw87h5/ERu2EcFYCq0Qw6TyLAE jEdjKZaOK6M4ohGt0D7/26cFUJFMOH/EsmJbT8+IKrhCnM3JZzyS48R2elQsEolrDQrk 07wFZhJpDGCOj1pss0UcqRTaHFH1/1GdbgzuIXC6q5ftMuDi1htHRTxlK+hmUxFPW2zw Zsik9vnUFfxYNR5DXT5EZHx6vcD8+bwJMaElZF8XO871gvbwFBaRUDxm0V5Wtjcsg7kU Uc3Q== X-Gm-Message-State: APjAAAVHg9nEaaczIf04NbO2mmnJK1zcSR9kt3NMOg9fRSY1zxnJYYUk IRtvgX+G+pbgSVDH3dKSqP/7oXxoXBiY X-Google-Smtp-Source: APXvYqzkRiIQXPyuCdWMMuFrWgVDRRg0K6LsoL5Da18iDU3o3AbYTNqQAGLiCRyB4F4/KHdW0UK3Aw== X-Received: by 2002:a17:902:521:: with SMTP id 30mr2564296plf.302.1561152095330; Fri, 21 Jun 2019 14:21:35 -0700 (PDT) Received: from [192.168.1.7] ([174.27.68.92]) by smtp.googlemail.com with ESMTPSA id f3sm4765410pfg.165.2019.06.21.14.21.34 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 14:21:34 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org Organization: http://SoftwareAndServices.NET Message-ID: <2bf763c5-6e44-3283-7941-857b19ea4b22@gmail.com> Date: Fri, 21 Jun 2019 15:21:33 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [calsify] Z, UTC, DATE, DATE-TIME, comparing and clarification X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 21:21:38 -0000 Statement of what I think is fact, and a proposal for future documentation. I think the following are true in iCalendar and should be specifically documented: (A) That when 'Z' is appended to date-time value, it is shorthand for: TZID=UTC:YYYYMMDDTHHMMSS It is also currently valid and acceptable. Because a time zone FOO could exist now or in the future that is equivalent to UTC. (B) For the purpose of comparison specifically declare that: YYYYMMDDT000000 is the same value as: YYYYMMDD (C) The existing 5545 text: "The "TZID" property parameter MUST NOT be applied to DATE-TIME properties whose time values are specified in UTC." Means do not do this: ...TZID=notZtz;VALUE=DATE-TIME:YYYYMMDDTHHMMSSZ And do not to this: ...TZID=UTC;VALUE=DATE-TIME:YYYYMMDDTHHMMSSZ And I think the text should changed to be: "The "TZID" property parameter MUST NOT be applied to date or date-time property values whose values are already specified in UTC." Because it is nonsensical when YYYYMMDDTHHMMSSZ also has a TZID not equal to UTC (Z). Or duplicated when a TZID=UTC is added to a UTC property value specified in Z (UTC). (D) Issues / questions: Can existing implementations compare DATE to DATE-TIME values? If yes, then they are treating the TIME part of a DATE value as 00:00:00 - correct? So, I don't see how my above declarations would effect any code. If an implementation can not currently compare DATE to DATE-TIME values, then nothing should be effected. Not sure how they sort items on the calendar. Do current implementations ignore TZID on VALUE=DATE properties of YYYYMMDD? or do they treat it as if it were: "...;TZID=DATE-TIME:YYYYMMDDT000000" If a current implementation wants to declare a DATE value in UTC, then currently it must use the format ....;TZID=UTC:HHMMSS, as the ABNF does not allow for 'Z' on a DATE value, and does allow a TZID parameter, that might be 'UTC'. Which is the equivalent of YYYYMMDDZ. The only two things controversial is: (1) YYYYMMDD == YYYYMMDDT0000. For which I see no problem. And (2) ...TZID=tzid;VALUE=DATE:YYMMDD is valid, because the ABNF currently allows for it is all properties that allow date/date-time property values. And that it is possible for TZID=UTC in those cases. And 5545 says: "... This ABNF is required for the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the memo. Additional restrictions that could not easily be expressed with the ABNF syntax are specified as comments in the ABNF...." And TZID is not excluded in the ABNF or comments in the ABNF for DATE values. If this WG wants them excluded, it should be explicitly decided and declared in the ABNF of the release of 5545 bis. Calconnect is great for finding issues, however, it is not the platform for making IETF decisions or declarations. Those must take place on the appropriate IETF mailing list. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Fri Jun 21 14:27:53 2019 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 9BA691201A3 for ; Fri, 21 Jun 2019 14:27:52 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SZPiG3F-TROx for ; Fri, 21 Jun 2019 14:27:51 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 1BF96120019 for ; Fri, 21 Jun 2019 14:27:51 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id d23so8457765qto.2 for ; Fri, 21 Jun 2019 14:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=IRUHmoVo+u+4V1psc15yxMcB/IFBEndyBse65buKbB8=; b=GLBZeE9kUiNp1+frafaeFHXOIl5PxCog+sHxD//UfInJnQKiwCI2C5yUOmf0pN1vUe weFO/mrGB/jSFmA9kgQF7wmVEYWenGeCriruLy2HDX1aHMcnbz0Hc4gmGe0vtig3u80X PmpkGCWm3UJ78+38Q1tU5+MgacD7SXbRr9CAvIceQFPxD4Yu4xJgcdI/hXzm+9HVJSQC ozXCkxEFPtO5OF379TRRUgcT9q5QA/LOTULcFNstCCyCawQWWplaRK8n3eLOySlB4U+G QQB4s9PIMMA30mfDlzkZSb5gXyyajbN3y5QjKZu3CRRDansohnrVgk0vXVjIeLdmiuUB QNng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=IRUHmoVo+u+4V1psc15yxMcB/IFBEndyBse65buKbB8=; b=clG12AMYIkM5mbvXK29+YkLhIE/IX36/V6XdW41ZUbLL54UMAycZFf3n5dMFxO83XM IYI3OwZOAeVsyqXJ+ku3RiI9wF7neJbA6hHcJY4dqbmwyCRWyWY5DSKzoFpY8NiAX/Ew w7XRqdZJ4uTcDJWIlvja90Dej68qORuECOauJ/wTx7+KPbO+QbmSpbwEZrQH7jvRpEnB rqyBJxICF32oEjKnwjfRHJPSvn/NZ9Igj6NkbtX9aXEEfkEiokG9N+fmM51T34Jnf7op wO+6h03/PTEpP/f5x07sP6yK3xOZzlpBGV2aZPau7XH2BvLD031Z4Cco5phoqNOSUmT8 Wtcg== X-Gm-Message-State: APjAAAVe2Ct9wuVGVv33uOzzrCR20vCnZqaxq+JYEIMekhV8Unf9JJl9 4zk6vKF8p7BQQ76KuygBSkJcmztin7Y= X-Google-Smtp-Source: APXvYqxX0ktxQWtYQpWna75B9I6lTMYaGu//82OZqFjaVW7vUZzdRuRPHim3AHOtUwqtO0s+m4LiSA== X-Received: by 2002:ac8:24e3:: with SMTP id t32mr43263448qtt.104.1561152470056; Fri, 21 Jun 2019 14:27:50 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id g10sm1858045qki.37.2019.06.21.14.27.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 14:27:49 -0700 (PDT) To: Doug Royer , calsify@ietf.org References: <2bf763c5-6e44-3283-7941-857b19ea4b22@gmail.com> From: Michael Douglass Message-ID: <87bb7b1f-7334-2c6f-7099-49c6f631ed81@gmail.com> Date: Fri, 21 Jun 2019 17:27:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <2bf763c5-6e44-3283-7941-857b19ea4b22@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] Z, UTC, DATE, DATE-TIME, comparing and clarification X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 21:27:53 -0000 On 6/21/19 17:21, Doug Royer wrote: > > > (B) For the purpose of comparison specifically declare that: > >     YYYYMMDDT000000 > >     is the same value as: > >     YYYYMMDD > I'm not sure that's correct. A date value at the moment implies ANY time with that date. It depends what you're trying to achieve. So is 20190315T081500 == 20190315? Depends. From nobody Fri Jun 21 14:47:56 2019 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 C77A312008A for ; Fri, 21 Jun 2019 14:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 3t8Jc3y4nS2f for ; Fri, 21 Jun 2019 14:47:52 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 5A456120019 for ; Fri, 21 Jun 2019 14:47:52 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id bi6so3599555plb.12 for ; Fri, 21 Jun 2019 14:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LT0pPhYGFKpcScZwCHMimj6QBQGg6jDY9TE79Et2FS0=; b=P/RD9Cc+tJSWpixIbyzz8EXhfXkeZzQPPv1cPMwq5NNGXLJUuXxPifz+S9xtAW09EY be7ZI5j6UCN+tGZRt9hiYotdJDwJqkV+PttR0BvgOyjManSTxjgm0MYw2Bif+z/K8rk4 dVmhOU5lKVu41FayfrOZeaNWAgEwDpw9JPCGfTFHnF2sZzq1atKd3g8HKv3M1RHTtPXQ YqQkSJ0a1maHaQTdPVkQkHzHhlPkk5DgLfxFqbFGWAXi1TgsdAKlglyIA3Y3QuH9ib8z 2cCMlN34UdHTiKfDjkphugzWJdn++ULAfFAd30abW38hNNC80OvqoR5lSVtxMlt8FAf9 YVGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LT0pPhYGFKpcScZwCHMimj6QBQGg6jDY9TE79Et2FS0=; b=hFYZBDz0IkqBQm3ffo2zyvJf0Pk9k1ns3FG152SXPqgSVIzXD6tWDpcKM5jEd+/3XO F2vRVoo5cLQ7bO3c1blkxH6owEpn4WBgZQZUnFHHqUCZMWnxxLuAZGwOZiZyg5MhVXU5 ngiiBmL3nnykc6wkyp/ecG0oDrYpYoRprl7Nwp+XzBJA54qrJsWm4rSi3PNVn36NC7te puKRJ41zObhlvfjIp6CBhpNq0oo1hfbBlhKyWjWOKeNVsoHq3TsQzg6hNsw2GV0mXdMS UEOcuoEMBlxZsQQhLuCl1mZsZBEZ+JCW2ikEiQ0A+NfGAAW1r+0Kljj+r6wS2tPh4WkR jLvA== X-Gm-Message-State: APjAAAWkz3VI51Wyc528s9VBD/Hs/OTUSEnk6pJC6tmFhNW3UXuk4N2C wGG02P34IEp/9QhcBb5a2hQcHbrLlPyf X-Google-Smtp-Source: APXvYqxG4L9ZvTgVBdKXbvEEfucU/zB0cNKDzzmCL/dBkXAXLwIYrHpK4CDKK+PXGLQXInlR2SVgBw== X-Received: by 2002:a17:902:7883:: with SMTP id q3mr132109649pll.89.1561153671485; Fri, 21 Jun 2019 14:47:51 -0700 (PDT) Received: from [192.168.1.7] ([174.27.68.92]) by smtp.googlemail.com with ESMTPSA id g8sm3765362pfi.8.2019.06.21.14.47.50 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 14:47:50 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: Michael Douglass , calsify@ietf.org References: <2bf763c5-6e44-3283-7941-857b19ea4b22@gmail.com> <87bb7b1f-7334-2c6f-7099-49c6f631ed81@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <995c7a60-88ad-9a93-1f0c-b04d2041225b@gmail.com> Date: Fri, 21 Jun 2019 15:47:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87bb7b1f-7334-2c6f-7099-49c6f631ed81@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] Z, UTC, DATE, DATE-TIME, comparing and clarification X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 21:47:54 -0000 On 6/21/19 3:27 PM, Michael Douglass wrote: > > On 6/21/19 17:21, Doug Royer wrote: >> >> >> (B) For the purpose of comparison specifically declare that: >> >>     YYYYMMDDT000000 >> >>     is the same value as: >> >>     YYYYMMDD >> > I'm not sure that's correct. A date value at the moment implies ANY time > with that date. It depends what you're trying to achieve. Where is the implication in 5545? When sorting them on the user interface, are they randomly placed as you find them? Or do you place VALUE=DATE items first? -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Fri Jun 21 20:27:02 2019 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 6306812014F for ; Fri, 21 Jun 2019 20:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eYhuOb0vO2vF for ; Fri, 21 Jun 2019 20:26:58 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 BC76A120136 for ; Fri, 21 Jun 2019 20:26:58 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id r6so5968701qkc.0 for ; Fri, 21 Jun 2019 20:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=cDeoQbM34tE5VP1gL+sAYukYGDeJDrnGK5FkUXHHc+0=; b=H7zn1V8pIa+Qn9SzD2OgTBg5/NVhJoBB76SdrxV1SoFLEB+RNcGuqW011D38NudAjV ZmH0eimS5Zq3DCxnJ4j1/U2OXp32Xoeeey9McFd9fi9lhzSY+3WsfWTsgn3mvDVKesy+ KhTUCwI+vx/pt4jI/FmDnINUbbtN/I1M51zm0YTMNQO267DllbvHEgw9etiTibNQBct2 is6mzNaMpjDeJaz8TgyNXRmYdHrm1Bqf+hutsWuYxrJtSODxzziQKcqcTpdZNVrwTvjf cDjpATHxf4E8nbEQr7TiUOtjopKWJjAA8ORurk5kAk0OcL1gcmZgsjtZW5/75N3xo3U5 CnJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=cDeoQbM34tE5VP1gL+sAYukYGDeJDrnGK5FkUXHHc+0=; b=lRXdDJ091mlH2iuuRsyn7VwhITfuHnX7BdJfsAeeK1VSCZRFeQp3/MvVjoAJOZ812V CCKlxwKX8cOcIGIvBbotH7Va9Sz/RW3Nwur154dGC8w+Qd2l0Icf3t3jgKSDGFY5VGJC yojbC3uMbIlSbXYOC2x6O0e+jVMlAwZAnetW+uafl4eqMgfDqE8maLarW9DlBpZI7Zq5 Vl5KHLF9wZgnQ7XDoiwE1iqLLb2w/npFCP5rtcE4aeHhNJ0/JFfV/RZSISTGXthPquz7 fEP+8M6P+C3sfucyDuinkE/GNkCvrACvhRkdgaeHD4ViOD+jMoJk/g8cfsUoMPFQCFOD d9mQ== X-Gm-Message-State: APjAAAUGWijWc3V6+PkoPuBJB5OwxYEcHY+t8iY9DBfa7tpNzrteDwEI V4e/faBbIez5db68zRu6POBNqgZkgT8= X-Google-Smtp-Source: APXvYqxu3pI2a0vGg6wC43ENdRAsthcfhHjrGkAuZLxDJpL9zigkGydpwMLrF1wPfg/+am/zFVaUmw== X-Received: by 2002:a05:620a:14ba:: with SMTP id x26mr91833202qkj.328.1561174017669; Fri, 21 Jun 2019 20:26:57 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id z126sm2342603qkb.7.2019.06.21.20.26.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 20:26:57 -0700 (PDT) To: Doug Royer , calsify@ietf.org References: <2bf763c5-6e44-3283-7941-857b19ea4b22@gmail.com> <87bb7b1f-7334-2c6f-7099-49c6f631ed81@gmail.com> <995c7a60-88ad-9a93-1f0c-b04d2041225b@gmail.com> From: Michael Douglass Message-ID: Date: Fri, 21 Jun 2019 23:26:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <995c7a60-88ad-9a93-1f0c-b04d2041225b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] Z, UTC, DATE, DATE-TIME, comparing and clarification X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 03:27:00 -0000 On 6/21/19 17:47, Doug Royer wrote: > On 6/21/19 3:27 PM, Michael Douglass wrote: >> >> On 6/21/19 17:21, Doug Royer wrote: >>> >>> >>> (B) For the purpose of comparison specifically declare that: >>> >>>     YYYYMMDDT000000 >>> >>>     is the same value as: >>> >>>     YYYYMMDD >>> >> I'm not sure that's correct. A date value at the moment implies ANY >> time with that date. It depends what you're trying to achieve. > > Where is the implication in 5545? > > When sorting them on the user interface, are they randomly placed as > you find them? Or do you place VALUE=DATE items first? It depends on the UI. But a VALUE=DATE item is often treated differently from a date-time, e.g. it reminds me it's somebody's birthday or it's a holiday. No alarm set it's just a date. Sometimes the entire day is colored because there's a date value. The iPhone (6 and portrait) puts the all-day events in a static bar at the top and all the others in a scrollable section - so no they don't get sorted first they get separated out in that case As does the desktop and thunderbird calendar. If I add an event with time 00:00 it gets put in the scrollable section at 00:00 as I'd expect. I think most humans expect an all-day(date only) event to be treated differently from an event with a date and time - Most UIs already assume that. In reality I don't think there's much of an issue with date-time and date other than what's lacking is a way to signal what people colloquially mean by all-day. Google for "all day event" - apart from the technical descriptions I get "All day happy hour at UNO". I'm guessing they're not serving pizza or anything else happily from midnight to midnight. Or we get "The 2019 Freihofer's Saratoga Jazz Festival" which doesn't go from 12:00 AM – 11:59 PM as google claims - it's date only in the ics and actually takes place in America/New_York time - but we have no (valid) way of saying that. In fact gates open at 10am. If this were a streamed event how would I know from my calendar when to watch from e.g Hong Kong? But it's an "all day event" because people will be queuing up at the gates - strolling around - then listening to performances. I can guarantee that if we didn't have the distinction between an 'all-day' date only and 24 hours midnight to midnight we'd have to add it as a non-standard property. To repeat my original request: Can't we simply allow a timezoneid on a date? > > -- > > Doug Royer - (http://DougRoyer.US) > Douglas.Royer@gmail.com > 714-989-6135 From nobody Fri Jun 21 20:36:15 2019 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 E98E012025F for ; Fri, 21 Jun 2019 20:36:13 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8Bot-Vxu3cP3 for ; Fri, 21 Jun 2019 20:36:10 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 98A8B12014F for ; Fri, 21 Jun 2019 20:36:10 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id a27so5940563qkk.5 for ; Fri, 21 Jun 2019 20:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=wyFRD03V+l9zqkCMDbCDLcjirZGpljiP/0/kRIMfhL4=; b=TJ7BG6tnjxFdk1moTT5GWM4orQRrRTDrwKT0ZzZt3WhOZ+QKBKJ7pDeJ+mYmKa3Umx BcLHkKDhmg5BWROhY3LQgDy5fL9z7GN0IGOHfmuW1zp/Gz0lm2nvMcekdEPhHTf4xHe8 8MxUfHRbH+Ys4xfz6WaYGbTJ3ss9leO2lzkVpTOtLvcM6lE+QLHOWY/fl7GFhfjYo1N5 zEftVNFzeBBacJrReve5w0jYnoj+a5wcMj6yMqMKMmqifvSm5rKngvTTKwmcNqQEyOZF EAQjnsVPnMIDyml8S/S/dHJ3dUyJjpmMkGHz0huJIoyZwOz5k16mYUfsJppFWMWjA7ur FLjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=wyFRD03V+l9zqkCMDbCDLcjirZGpljiP/0/kRIMfhL4=; b=IdvoOQmitl8NO9n1G6+l2bJFUtjy1glfoUw8QJbE+f7NFmBNWYByktIl5X0LxlswDQ BLI1mWvvTEhpOoWi4UTM5DRbfzF2lmYHsdmDWkNwWM8iKa1lfvQhH073eJLLI0Njtr6K pI9tIB63ycjL7dE7KjV1jdvtZiCyNJDZu/cFtDCWLUqx4uPekp4xtuLTGDH2noNVV9un r5KPwmMHYkEsFMdFGV/IZXZfahnNOP3eC09t5RZNbN3awaRBY4gf+8WxC1QBB/OkjZnn 5UMCD5qE8KD/jQIYFcf2RKaUzWVHwD04xrtW69min7PQuDuVGAkTjkSm2nEMlQfFVNt7 9SNw== X-Gm-Message-State: APjAAAXCyQRvCxm8KpDislNEPYLzXdeAaltyQb2k9bX2NmEHBS8kFSVn WDdDrGhbOOJF+ulYRPRr+MIuSkCItkw= X-Google-Smtp-Source: APXvYqy43xVMZ9pR1csqmQB1fHDU7RdS2nAntMYpnF8iXn/1FzO6Zq153niyHENl38Fc4y+VnS0z/g== X-Received: by 2002:a05:620a:15d7:: with SMTP id o23mr15128798qkm.125.1561174569464; Fri, 21 Jun 2019 20:36:09 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id s25sm2348505qkm.130.2019.06.21.20.36.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jun 2019 20:36:08 -0700 (PDT) To: Marten Gajda , calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com> From: Michael Douglass Message-ID: Date: Fri, 21 Jun 2019 23:36:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------34014392398BD8FBCA383B8E" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 03:36:14 -0000 This is a multi-part message in MIME format. --------------34014392398BD8FBCA383B8E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/17/19 18:04, Marten Gajda wrote: > > > Am 17.06.19 um 18:14 schrieb Robert Stepanek: >> I also removed the "isAllDay" property entirely from the JSTask object. > > Hmm ... I see how "isAllDay" doesn't really apply to a task, but it > would be nice to have a way to express this kind of fussiness for > start and/or due dates in cases when the actual time is not that > important (or even unknown). Always terminating tasks on a specific > time can give a false sense of accuracy which might not exist. > Sometimes you just want to express "at some time throughout that day". > Does that make sense? > Absolutely - Thursday is take out the garbage sometime during the day - I generally need to be reminded all day. I don't see why tasks are any different in this respect. > > Marten > >> >> See >> https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1.4 >> >> From my initial analysis, the mapping to iCalendar is rather simple: >> >> * If the JSEvent timeZone is null, the start time has zero time, >> and the duration is a multiple of days or weeks, then DTSTART is >> of type DATE. In this case, clip off any non-zero time from the >> recurrence rule "until" property. >> * Otherwise map "start" to a DTSTART of type DATE-TIME. >> * I also consider using a new iCalendar boolean property IS-ALL-DAY >> to cleanly map "isAllDay". >> >> >> I will update the informational iCalendar mapping guideline accordingly. >> >> Cheers, >> Robert >> >> On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote: >>> One of the repeatedly discussed topics in JSCalendar is how to model >>> all-day events. >>> >>> Specifically, variants of the following uses repeatedly come up, >>> where the current JSCalendar model seems not to be adequate: >>> >>> * Calendar users create an event starting e.g. 8am and ending 7pm, >>> but want to view this an all-day event in their UI. The current >>> model misses a flag to express this, as the isAllDay property is >>> not appropriate to indicate the user intention. >>> * Calendar users want to set their calendar on their birthday, >>> when they only would like to set it for the complete day in >>> their usual time zone. They still want it to show up as an >>> all-day event in their UI. >>> >>> >>> In both cases, developers thought to use the isAllDay property to >>> express a user intention, but came they learn they couldn't. >>> >>> This is reason enough to revisit that part of the specification and >>> discuss alternatives. >>> >>> *Currently*: >>> >>> * Any event MUST define a start property value in the form >>> "YYYY-MM-DDTHH:MM:SS[.DIGITS]" >>> * An all-day event: >>> o MUST have the isAllDay property set to "true" >>> o MUST NOT have a non-zero time in the start and duration >>> property values >>> o MUST NOT define a time zone >>> * Any other event: >>> o MUST have the isAllDay property set to "false" >>> o MAY define non-zero time  in start, duration >>> o MAY set a timeZone. >>> * This allows to model iCalendar DATE, local DATE-TIME, floating >>> DATE-TIME, UTC DATE-TIME. >>> >>> >>> *Alternative*: >>> >>> * The isAllDay boolean property gets removed. >>> * A new showAsAllDay boolean defines how the user intends to view >>> this event. Setting this property does not have any implications >>> on the allowed values in the event time properties. >>> * The start, duration, timeZone properties and their recurrence >>> overrides can all can be defined independently. The >>> recurrenceRule{until} property also can be defined independently. >>> * It is up to implementations to convert this time model to >>> iCalendar. Most probably: >>> o an event with zero time in start, duration, until and no >>> time zone will be converted DATE value types >>> o an event with no time zone will be converted to a local >>> DATE-TIME without TZID >>> o otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME >>> >>> >>> What do you think? Did we miss something? >>> >>> Cheers, >>> Robert >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > -- > 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 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------34014392398BD8FBCA383B8E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


    On 6/17/19 18:04, Marten Gajda wrote:


    Am 17.06.19 um 18:14 schrieb Robert Stepanek:
    I also removed the "isAllDay" property entirely from the JSTask object.

    Hmm ... I see how "isAllDay" doesn't really apply to a task, but it would be nice to have a way to express this kind of fussiness for start and/or due dates in cases when the actual time is not that important (or even unknown). Always terminating tasks on a specific time can give a false sense of accuracy which might not exist. Sometimes you just want to express "at some time throughout that day". Does that make sense?

    Absolutely - Thursday is take out the garbage sometime during the day - I generally need to be reminded all day. I don't see why tasks are any different in this respect.

    Marten



    From my initial analysis, the mapping to iCalendar is rather simple:
    • If the JSEvent timeZone is null, the start time has zero time, and the duration is a multiple of days or weeks, then DTSTART is of type DATE. In this case, clip off any non-zero time from the recurrence rule "until" property.
    • Otherwise map "start" to a DTSTART of type DATE-TIME.
    • I also consider using a new iCalendar boolean property IS-ALL-DAY to cleanly map "isAllDay".

    I will update the informational iCalendar mapping guideline accordingly.

    Cheers,
    Robert

    On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote:
    One of the repeatedly discussed topics in JSCalendar is how to model all-day events.

    Specifically, variants of the following uses repeatedly come up, where the current JSCalendar model seems not to be adequate:

    • Calendar users create an event starting e.g. 8am and ending 7pm, but want to view this an all-day event in their UI. The current model misses a flag to express this, as the isAllDay property is not appropriate to indicate the user intention.
    • Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI.

    In both cases, developers thought to use the isAllDay property to express a user intention, but came they learn they couldn't.

    This is reason enough to revisit that part of the specification and discuss alternatives.

    Currently:
    • Any event MUST define a start property value in the form "YYYY-MM-DDTHH:MM:SS[.DIGITS]"
    • An all-day event:
      • MUST have the isAllDay property set to "true"
      • MUST NOT have a non-zero time in the start and duration property values
      • MUST NOT define a time zone
    • Any other event:
      • MUST have the isAllDay property set to "false"
      • MAY define non-zero time  in start, duration
      • MAY set a timeZone.
    • This allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME, UTC DATE-TIME.

    Alternative:
    • The isAllDay boolean property gets removed.
    • A new showAsAllDay boolean defines how the user intends to view this event. Setting this property does not have any implications on the allowed values in the event time properties.
    • The start, duration, timeZone properties and their recurrence overrides can all can be defined independently. The recurrenceRule{until} property also can be defined independently.
    • It is up to implementations to convert this time model to iCalendar. Most probably:
      • an event with zero time in start, duration, until and no time zone will be converted DATE value types
      • an event with no time zone will be converted to a local DATE-TIME without TZID
      • otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME

    What do you think? Did we miss something?

    Cheers,
    Robert





    _______________________________________________
    calsify mailing list



    _______________________________________________
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

    _______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
    --------------34014392398BD8FBCA383B8E-- From nobody Sat Jun 22 10:29:07 2019 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 D8A1E1200D7 for ; Sat, 22 Jun 2019 10:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uKjkL0Y52Kpn for ; Sat, 22 Jun 2019 10:29:04 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 20427120091 for ; Sat, 22 Jun 2019 10:29:04 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id z75so2263071pgz.5 for ; Sat, 22 Jun 2019 10:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cBmrFjL2afDdfIpsL1fKsDs8qfMDMW2ipuOP/R5/nyI=; b=kjQeuITDIktLdhu1ic262eUcCjMZ39vNU83ANLcVtNBr7ThtHxEpanjzKP7q2p/PY2 TlMbFUzaw8QTnAzpyEQSQ0lzklN+scgNTCED0lz/L4YQlAfvKl7KmviabmZ++vLF7hFY n6OTVyLkuY/lS2HS/8dVBV8GrktFBs9noHUI4bDVv2WUZ29M97COmya9FDDpmQXFLXvQ eRhlZhRp/slLXanqvXJ2Du0dPXo787042WBRWTS4QFJ54UtBSg6oLTFv44X5uurtm1LS vzd2Sb0/fjSNn1PCPyyJVmCadnYb9ZJxbnzJomxoCryfOl/lu9ofOkzT2Ey5apVLNj6b 3KIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cBmrFjL2afDdfIpsL1fKsDs8qfMDMW2ipuOP/R5/nyI=; b=ELcDvwovlUePUtFnmBDT981osn//eNI0JBJwblc+f/4eQSeAELBRdMHZeNmhzaxWkF fUtFd5cCd06gXJkVVTiVo1Ia78FEpyRuvNH1o/I+z+G4ndU4I/P5YKEj7Wx/mzpGOHy7 DsdQ5OZ9579MPazOAoHCH9QbLJie+WLZKRjbAjcyHC9kij9nEM1EkORDEAM90dJsI8dJ X3TTgkH4DFoOLhAyyklbPb6GEWX3kPr/B6rsRNFVp0vAGhMZFurooupugyGdnxJoQJHK Rwfo9u2C2g/x+OZ3unsoCVNzG9oDJSf3BnfNvVjy2hd05JvKYd/X85m097i1i+RvfQEX nn7w== X-Gm-Message-State: APjAAAVIJkLppxyXjc9lBVmt2O1HW2AVsT/oEqN1AOlvM/ew8LVjXzcZ dJplDoUkqHa+3VikidfeEr4ArBObnklj X-Google-Smtp-Source: APXvYqx/Esty4RcGPpiC2vICXPBIaEeycd0kVxE7MqpB8Qw37JJ+6b5hNjie7nkqpC3r7TGRdzeZiQ== X-Received: by 2002:a17:90a:9b08:: with SMTP id f8mr14261959pjp.103.1561224543086; Sat, 22 Jun 2019 10:29:03 -0700 (PDT) Received: from [192.168.1.7] ([174.27.68.92]) by smtp.googlemail.com with ESMTPSA id n140sm7809288pfd.132.2019.06.22.10.29.02 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jun 2019 10:29:02 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <2bf763c5-6e44-3283-7941-857b19ea4b22@gmail.com> <87bb7b1f-7334-2c6f-7099-49c6f631ed81@gmail.com> <995c7a60-88ad-9a93-1f0c-b04d2041225b@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <1fbb88a5-0915-07cb-717e-f96ebe57aaf7@gmail.com> Date: Sat, 22 Jun 2019 11:29:01 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] Z, UTC, DATE, DATE-TIME, comparing and clarification X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 17:29:06 -0000 On 6/21/19 9:26 PM, Michael Douglass wrote: > > On 6/21/19 17:47, Doug Royer wrote: >> On 6/21/19 3:27 PM, Michael Douglass wrote: >>> >>> On 6/21/19 17:21, Doug Royer wrote: >>>> >>>> >>>> (B) For the purpose of comparison specifically declare that: >>>> >>>>     YYYYMMDDT000000 >>>> >>>>     is the same value as: >>>> >>>>     YYYYMMDD >>>> >>> I'm not sure that's correct. A date value at the moment implies ANY >>> time with that date. It depends what you're trying to achieve. >> >> Where is the implication in 5545? >> >> When sorting them on the user interface, are they randomly placed as >> you find them? Or do you place VALUE=DATE items first? > > It depends on the UI. But a VALUE=DATE item is often treated differently > from a date-time, e.g. it reminds me it's somebody's birthday or it's a > holiday. No alarm set it's just a date. Yes, when they have no DTEND or DURATION. However they still get sorted on the user interface. > Sometimes the entire day is colored because there's a date value. iCalendar has no 'all-day' definition. Still waiting to see that that means. > The iPhone (6 and portrait) puts the all-day events in a static bar at > the top and all the others in a scrollable section - so no they don't > get sorted first they get separated out in that case At the top of the day? Is sorted. As there is no such thing as 'all-day' in iCalendar, do you mean anniversary (no DTEND or DURATION)? Or floating (No time zone)? > As does the desktop and thunderbird calendar. If I add an event with > time 00:00 it gets put in the scrollable section at 00:00 as I'd expect. I assume you mean those that have a DTEND or DURATION? As expected. > I think most humans expect an all-day(date only) event to be treated > differently from an event with a date and time - Most UIs already assume > that. Again: No such thing as 'all-day' in iCalendar. Unless your talking about an anniversary that MUST BE a multiple of day (no fractional days per 5545). Types of VEVENTS defined in RFC-5545 "anniversary" is as defined in 3.6.1 and also called a "reminder". +----------------------------------------------------------------------+ | | VALUE= | | | | | | date or | Has DTEND or| Has Z | Is a... | | |date-time| or DURATION | or TZID| | +---------------|----------------------|-------------------------------+ | (A) |date-time| Yes | Yes |Normal VEVENT starting at | | | | | |specific UTC offset. | | | | | |Ending at specific UTC Offset | +---------------|----------------------|-------------------------------+ | (B) |date-time| Yes | No |Normal VEVENT starting at | | | | | |specific local time offset. | | | | | |Ending at specific local Offset| +---------------|----------------------|-------------------------------+ | (C) |date-time| No | Yes | Normal VEVENT. | | | | | | Starts at specific UTC offset.| | | | | | Ends at DTSTART. | +---------------|----------------------|-------------------------------+ | (D) |date-time| No | No | Normal VEVENT. | | | | | | Starts at specific local time | | | | | | offset. | | | | | | Ends at DTSTART. | +-----|---------|-------------|--------|-------------------------------+ | (E) | date | Yes | Yes | Anniversary starting at | | | | | | midnight on date | | | | | | as defined by UTC offset. | | | | | | Ends at midnight on days | | | | | | specified by UTC offset. | +-----|-----------------------|--------|-------------------------------+ | (F) | date | Yes | No | Anniversary starting at | | | | | | midnight on date | | | | | | as defined by local time | | | | | | offset. | | | | | | Ends at midnight at specified | | | | | | local time offset. | +---------------|-------------|--------|-------------------------------+ | (G) | date | No | Yes | Anniversary at midnight | | | | | | at specific UTC offset. | | | | | | Ends at midnight at specified | | | | | | UTC offset in DTSTART. | +---------------|-------------|--------|-------------------------------+ | (H) | date | No | No | Anniversary at midnight | | | | | | at specific local time offset.| | | | | | Ends at midnight at specified | | | | | | local time offset in DTSTART. | +-----|---------|-------------|--------|-------------------------------+ NOTE: A DATE can have a TZID as specified in the ABNF, and the 'date' ABNF does NOT allow for a 'Z' on DATE values. NOTE: A DATE or DATE-TIME values can not have both a TZID or and a (Z) on the value as quoted here: In (3.3.5.): ".... The "TZID" property parameter MUST NOT be applied to DATE-TIME properties whose time values are specified in UTC. ..." and (3.3.12.): "... The "TZID" property parameter MUST NOT be applied to TIME properties whose time values are specified in UTC. ..." and (3.2.19): "... The "TZID" property parameter MUST NOT be applied to DATE properties and DATE-TIME or TIME properties whose time values are specified in UTC. ..." > In reality I don't think there's much of an issue with date-time and > date other than what's lacking is a way to signal what people > colloquially mean by all-day. Google for "all day event" - apart from > the technical descriptions I get "All day happy hour at UNO". I'm > guessing they're not serving pizza or anything else happily from > midnight to midnight. Then it is NOT 'all-day'. It is a fractional part of a day, and that is just makes it a normal VEVENT - nothing special. That would make all-day has no more meaning that the color of the display. A meaningless attribute that redefines the 'all' in any spoken language. What 'people' mean by 'all'? Confusing in itself. All the time they are open? All Morning? All week? It has no meaning by itself. In effect your saying "all means all of the time in the normal VEVENT". Which is what a normal VEVENT already means. I (as a people) would expect 'all-day' to mean all 24-hours. I am guessing I am not the only one. Some might think it means 'all-daylight', others might think 'all-work-hours'. No computer program can read the context of the VEVENT and guess what hours to consume on the user interface - without DTSTART with VALUE=DATE-TIME, and that makes it a *normal* VEVENT. > > To repeat my original request: Can't we simply allow a timezoneid on a > date? We can. 5545 does not say we can not. (as quoted above), it specifies you can not put TWO time zones in the same property. And it says that in multiple places. AND the ABNF for DTSTART, DTEND, EXDATE, and RDATE, and DUE allow for DATE-TIME / DATE *and* tzidparam. As they ALL have ABNF like this: ...param = *( ... ; ; The following are OPTIONAL, ; but MUST NOT occur more than once. ; (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / (";" tzidparam) / ... -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Sat Jun 22 13:23:40 2019 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 1CB65120108 for ; Sat, 22 Jun 2019 13:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XE7LS2si_z2I for ; Sat, 22 Jun 2019 13:23:36 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 B010912000E for ; Sat, 22 Jun 2019 13:23:36 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id c14so4670883plo.0 for ; Sat, 22 Jun 2019 13:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qwOSMmkgnNj4o1JnJWgCqYoNAC0Racb8tPMKOZ/rhnc=; b=h3npWXrCGcTjHLnqmiZEX5OmwmYSSiKMm77nlaqlyDUJ6oE/OAVJWawdp2GnsuMtb6 aqgeJ2aQAlHRINGzPxg1MYOsQuwGvhPqjWp/0V3XEAQ0W57kZMMwJViS+voLBFAElr0z nrBN/6ioYWOO2JBP271a8/2xlvUbmJjWVZ0Jz80iaclDy98kpsr+FuefKNHqvlFfyXLE x6bkspu3TZeMB0Uf3trilUlXGfhRTMh2dZJYMacsISYJoEnC6OCvohB0bJ/KoKovoPrW X7XwlAWn6aTWWWI6+gNBz+bKKf787wA0T5UEZQTQ90CryDZcff919602XhjxO0JErRF/ DcDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qwOSMmkgnNj4o1JnJWgCqYoNAC0Racb8tPMKOZ/rhnc=; b=Ang155fJPrFeyFf2fP8Pa53MDFiTq88W6YbsFlHaom7pW7OfOdpSM81uB2TV13s6Kn dw1PUvAjbZnmwgrhQqujH8g4Rl3dOdTFiGuzWuY8HF+AFsN6AkROA8ESloVyNR853IIB A5wSm3p98jS24n/lxnls/q+sy/FNZOQmpOdTJP0MR89SLsOWKWgfWOKNZ25r7EzgZdrl VsXqxFif9/5l6o5RI9Xnng6KWHvy2T0JF7VRrWmZ8UYx+X4Bloa26tYb2j99x7LzlgCA gqDifW5wHTlgETJX226cjOHvZVWr4h9rXAynuTvGjMCYIuTEpdNnsJanMbpTEmoT9trh C5Fw== X-Gm-Message-State: APjAAAWxbmw6zmrmeG5zvW5yleJC2b2l+/gdf9Oa+JvmvclP5yChA2zd JxGtvbE3xr4CetN4gh/vXmNtwkIK5TH0 X-Google-Smtp-Source: APXvYqzDomqWVx9kldvwpYBCIUvtgYXBTxnbTvXmYSr+cdQboUcHpbToMvOhEXbisPeFTF7Rn9PeBA== X-Received: by 2002:a17:902:542:: with SMTP id 60mr117026882plf.68.1561235015791; Sat, 22 Jun 2019 13:23:35 -0700 (PDT) Received: from [192.168.1.7] ([174.27.68.92]) by smtp.googlemail.com with ESMTPSA id q10sm6339416pgg.35.2019.06.22.13.23.34 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jun 2019 13:23:35 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <12b5d7b2-5d97-4bcb-b918-31833b557fef@www.fastmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Sat, 22 Jun 2019 14:23:34 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <12b5d7b2-5d97-4bcb-b918-31833b557fef@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] JSCalendar: alternative to current all-day events X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 20:23:38 -0000 On 6/18/19 5:55 AM, Robert Stepanek wrote: > On Tue, Jun 18, 2019, at 5:16 AM, Neil Jenkins wrote: >> On Fri, 7 Jun 2019, at 01:56, Robert Stepanek wrote: >>> Calendar users want to set their calendar on their birthday, when >>> they only would like to set it for the complete day in their usual >>> time zone. They still want it to show up as an all-day event in their UI. >> >> Suppose I have such an event (24h long, starts at midnight on 1st Jan >> 2020 in Australia/Melbourne). It is unclear to me what I should show >> the user if their time zone is different (e.g. I view the calendar in >> Europe/London); does it show up in the "all day" section on both 31st >> Dec and 1st Jan? That's the only sensible thing I can come up with. >> But that would give the impression the event happens over two days, >> which is incorrect. (But perhaps the issue here is really more that >> the birthday should not have been given a time zone.) > > I also wouldn't set a timezone on my birthday, but there's been a number > of people at last CalConnect reporting that this actually is what users > do. I don't have a good answer how to render that if the event timezone > and UI timezone don't match - probably a calendaring UI should just > ignore the "isAllDay" property if the timezones of the UI and event > don't match. Per 5445, that means they are in local time. That is to be displayed using your display time zone. Which is interesting on web user interfaces x-hosted back from another time zone. I have servers in both Mountain and Central time zones. When I remotely display a local time event, they are 1 hour different than each other - as it should be. You could mark your birthday as defined by the UTC time you were born. In that case set the TZID to the TZID of your birth location, date, and time. In which case you set TZID (without Z), or set the UTC time (Z) and do not use a TZID. Most people celibate their birthday on the date in local time. In which case you set the DTSTART and do not use TZID or (Z). If you travel across the international date line, do you want your reminder/anniversary on the date specified that you are in? Or up to 24-hours offset and seemingly wrong? The purpose of 5445 and hopefully bis, is to define the data and what it means. It sounds like a user interface guide should be written that explains or suggests how to represent the data to a user across vendors so it is consistently understood by the average user. It appears to me that checking 'all-day' on google and Thunderbird, make a floating time anniversary VEVENT. They do not seem to allow the user to make other versions of anniversary. With Thunderbird, when I click 'All day Event', it grays out the time. Set the start equal to end, and mails out: DTSTART;VALUE=DATE:20190628 DTEND;VALUE=DATE:20190629 GOOGLE: DTSTART;VALUE=DATE:20190628 DTEND;VALUE=DATE:20190629 Same thing. Both call 'All-Day' to be a anniversary with floating time. No special iCalendar tag needed. *AND* both when they get a anniversary with floating time VEVENT, automatically check 'All Day' on their user interfaces. Again no special iCalendar tag needed. >> >> I agree the name could perhaps be better. |showWithoutTime| perhaps? >> And a description something like: That already exists. To have an iCalendar object without time, per 5545: "...For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE-TIME value type but no "DTEND" property, the event ends on the same calendar date and time of day specified by the "DTSTART" property. ..." Because 5545 says: "...For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE value type but no "DTEND" nor "DURATION" property, the event's duration is taken to be one day. ..." The only way (and the only way needed), is to specify a VEVENT with Floating time: DTSTART;...;YYYYMMDDTHHMMSS or for non-floating time. DTSTART;...TZID=aTz:YYYYMMDDTHHMMSS or DTSTART;...:YYYYMMDDTHHMMSSZ > That's fine for me as well. I chose "isAllDay" rather than > "showAsAllDay", because I figured that "show" implies a graphical user > interface, which might not be adequate in all cases (think: calendar > applications for visual impaired). But I'm not too vested in it. Or process based events that are acted on - like a sequence of events like Alexa or Google home. >> I also agree we want this for JSTask. > > Yeah, there's several people now asking for it, so I guess I shouldn't > have removed it in the first place. But it's great we got that > established :) They already exist in iCalendar. It is the user interfaces that omit them. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Sat Jun 22 13:46:57 2019 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 2C5CF120046 for ; Sat, 22 Jun 2019 13:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BV3k137aPyuo for ; Sat, 22 Jun 2019 13:46:53 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 AD6FB12001A for ; Sat, 22 Jun 2019 13:46:53 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id m30so5308108pff.8 for ; Sat, 22 Jun 2019 13:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lVBN+APrU7IoKwz2mLMDm+PVhMABPUKK077829/OlBc=; b=tRIyo7m0T8tLgUYrUaQCOmz0zcg8UzXtsLbTo/5/NvES/3NmyQgXZdFxxav74CEmLr eZx2kEI9HyD8gigRME3RywDxzT17z3NAQPqpA+Sx3pIAzkHFf/MgbK2KioXoJut7NQ3J Ac9I/sNgyW6mf9oGJ4gXPHE4Yake8nmHVOL4/U/lxvqOIyeoGkLdC72ieQGdqb5gSK+5 A37G4jaMKU0bX/Ldkp9NJUcgnqGDyu1kQ7s0RkjY0TnGMsgzZ+fXS2Iv0k78k8EJwK4N l0X1p+fHDFEZRof2V0fMo/ugrwk1gsk01hOBBP+oammvC5nym8cN+wUagfNxPvj44wzP 3Onw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=lVBN+APrU7IoKwz2mLMDm+PVhMABPUKK077829/OlBc=; b=Gd3OfyNUoJB9KS3s1hopv5qrxa9Qu2FsIG4uepqjBEuQYs2Dki3M+nIx9fJOiFtSZq b9Z29zgx2qUiDEpGEvc4xfDW+b0HJShFtNmszFZ5BWQ2SEnaHuFpvm3VPnvm4x0IBCpo TziC/wxJVbMxKIUHO1CLwHx6I3Rj6h2eHJNz6girkJcsy1FWZtHUA9wWU6yK6cYpTUBm W0XS5MfJ2IHl+7OhuuXGCDmNl/PTjFzfLql1virRQ/MElpwImJFemDQ4WympPiVfeBAk U4haiQoiq9g98Z/rJABTGjD/B92xbwQhPPHa26f0Jom2R/nsuUp5Pm05LQG6cg7kEja7 FdKg== X-Gm-Message-State: APjAAAWMgmuwa4veoBV6hLR2F81jHmlFIDts7oIcERc8UYxVyLwh32I4 Lhwl3uE+zVw5o1ouySQJ5cLvgRdReuvc X-Google-Smtp-Source: APXvYqyhMsi2n0RGqUyuTKaiflUJuU8yZ4aTq9YwiTmOhMogop4kCXGmRzo7vrgicIQegH5SD0cBEA== X-Received: by 2002:a65:64d5:: with SMTP id t21mr25500502pgv.310.1561236412872; Sat, 22 Jun 2019 13:46:52 -0700 (PDT) Received: from [192.168.1.7] ([174.27.68.92]) by smtp.googlemail.com with ESMTPSA id n26sm7168973pfa.83.2019.06.22.13.46.51 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jun 2019 13:46:51 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <2bf763c5-6e44-3283-7941-857b19ea4b22@gmail.com> <87bb7b1f-7334-2c6f-7099-49c6f631ed81@gmail.com> <995c7a60-88ad-9a93-1f0c-b04d2041225b@gmail.com> <1fbb88a5-0915-07cb-717e-f96ebe57aaf7@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <22f24fca-13a5-5fc4-1ca6-2a0b293c1e2a@gmail.com> Date: Sat, 22 Jun 2019 14:46:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1fbb88a5-0915-07cb-717e-f96ebe57aaf7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] Z, UTC, DATE, DATE-TIME, comparing and clarification X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 20:46:55 -0000 On 6/22/19 11:29 AM, Doug Royer wrote: > Types of VEVENTS defined in RFC-5545 > "anniversary" is as defined in 3.6.1 and also called a "reminder". > > +---------------|-------------|--------|-------------------------------+ > | (H) | date    | No          | No     | Anniversary at midnight       | > |     |         |             |        | at specific local time offset.| > |     |         |             |        | Ends at midnight at specified | > |     |         |             |        | local time offset in DTSTART. | > +-----|---------|-------------|--------|-------------------------------+ Oops, this should be: +---------------|-------------|--------|-------------------------------+ | (H) | date | No | No | Anniversary at midnight | | | | | | at specific local time offset.| | | | | | Ends DURATION=1 day. | +-----|---------|-------------|--------|-------------------------------+ -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Mon Jun 24 06:02:02 2019 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 23F3A120072; Mon, 24 Jun 2019 06:01:54 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <156138131406.17467.6108760880516656418@ietfa.amsl.com> Date: Mon, 24 Jun 2019 06:01:54 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-16.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 13:01:54 -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-16.txt Pages : 51 Date : 2019-06-24 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. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-16 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 Jun 24 06:10:08 2019 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 EE148120289 for ; Mon, 24 Jun 2019 06:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=xa3sg4Gw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZJ15rR5F 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 EDYNn1aB7Vc3 for ; Mon, 24 Jun 2019 06:10:05 -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 F3659120155 for ; Mon, 24 Jun 2019 06:10:04 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 12F81223FA for ; Mon, 24 Jun 2019 09:10:04 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 24 Jun 2019 09:10:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=dK9FSgFs8SDs9OI2FVEhBTIsK4FznKriRCGlcUL Mh3Y=; b=xa3sg4GwnRdrKt1AF+jHY3K9iIFgmhcFqnLVQBwayYn5DdJDA2LV04o lzYub5R/EAzTgwzTkVaRqgKDbWWYvmHaG8luCR1hffg+QHUA/AIHgvoMi0D71Bug mOs7D92JJmScaxF3alzZZVIIm6dqsO8nxhhf9pUhk7uHgof3EqIc3yDfDhEjPfOm y0A3Onpy2rA1cNZNZ+l1bm4v83t5dsRPLOiayg0s8KrRURrYyjgkQsdpP1tfH2R7 VsklWI0UtAtkxCgH1GXKvBcxp191gJqLzWvF8Ir6bN67ofPbhp4NSsNOjxJSEP6M L52Kh/Pb9KukhhPspaZlhm/OhK4Xx0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=dK9FSgFs8SDs9OI2FVEhBTIsK4Fzn KriRCGlcULMh3Y=; b=ZJ15rR5FJdBXb+eiy/dLsvXvD5nuquw+slZqc8S6/z/h1 3SebOqL69SwaCsYFh/qFWqXKK+AAeDe06nzsCeZ8c1Hd/Uhqybu/hiH5fLdPAVA+ XIVKLh3GSJAIFnw1B3oKEPA928bWHr8V7EYacF2iBKhoWHyL6SxEHOOgGTuRWauR UTOLtaoJUw4Mmodfy9EuFSqCOHh6UsKoWkRmMHVCwVrPKSbeChHp32O24IiQqUtW /Hb0eo8GlKjq6lO21adlWLxRRy6DKjql8EaDgHng3p6hqY0CuvIUpK2gg+sOxCwn ScrI8VhSlwgFnF+3hc6QGI/c0zUnHl4ugAYIAzMnQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddvgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 805A81800A3; Mon, 24 Jun 2019 09:10:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-730-g63f2c3b-fmstable-20190622v1 Mime-Version: 1.0 Message-Id: <9cb2ae87-3a86-415f-9b94-2d2052e49234@www.fastmail.com> Date: Mon, 24 Jun 2019 15:10:02 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=7df3f93d727c4e49b1d33e7513cd693b Archived-At: Subject: [calsify] JSCalendar: Updated draft-ietf-calext-jscalendar-16 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 13:10:07 -0000 --7df3f93d727c4e49b1d33e7513cd693b Content-Type: text/plain Hi all, I just updated draft-ietf-calext-jscalendar to version 16: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-16 This update redefines the "isAllDay" property to "showWithoutTime" and allows it for both JSEvent and JSTask, as discussed on this mailing list. In addition, the draft references RFC 3986 in the security considerations for URIs. There are no open points remaining and we consider this RFC draft complete, apart from editor review. If you find any point in the document unclear or disputable, please let us know now. Thanks, Robert --7df3f93d727c4e49b1d33e7513cd693b Content-Type: text/html
    Hi all,

    I just updated draft-ietf-calext-jscalendar to version 16: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-16

    This update redefines the "isAllDay" property to "showWithoutTime" and allows it for both JSEvent and JSTask, as discussed on this mailing list.

    In addition, the draft references RFC 3986 in the security considerations for URIs.

    There are no open points remaining and we consider this RFC draft complete, apart from editor review. If you find any point in the document unclear or disputable, please let us know now.

    Thanks,
    Robert
    --7df3f93d727c4e49b1d33e7513cd693b-- From nobody Mon Jun 24 07:49:04 2019 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 C39611203E5 for ; Mon, 24 Jun 2019 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 k1b1FNBI-n81 for ; Mon, 24 Jun 2019 07:49:00 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 F07D31203C5 for ; Mon, 24 Jun 2019 07:48:44 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id bh12so7012566plb.4 for ; Mon, 24 Jun 2019 07:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vAVQr7zJOP7ME/L2/BzAGvBwYcRzIrMMCKDCgklzYwE=; b=hK/nbLg4zrOP1baV9u+A9YxTczCvKbf6zKahknezej1p0mnjs3kSWCx9ulHyjQXm2a GKTpPdz9DlD7u+lEd8DZP6pto/MIRvGwYXkvv7OoJDCkGKekG4QsvbeWSK61bkRdA/Jb QJdFqZSFKduzRABX37L6ejp9lUPnnGFXCRgtPAaNyiOLg7uwF43TLwKbbkApk3pP1Gix kL1ZzYZ9ON1AWiIEGk86bc01pYqMy5XIqWWUHzz/I+i4cqTsh8LDptU7ftfXNh1do+Yp sIpLuqkC3yKaJVRO9WDixTA9ZaVzYPfXrE6WgiVwGNrRe5epfI2oEbFuW4yy6E8Vkdx4 a9zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=vAVQr7zJOP7ME/L2/BzAGvBwYcRzIrMMCKDCgklzYwE=; b=Xt/F/pVd2eLsJtlfOvQO+REAjFQvqbVp1RuPGRgKVH6Mjo+u2lILTvf2CSMtb0wZZX LJSVu6SPqx83W7IGNvYXJA66GXWsR6jfK7y3Cejh3Uix1I0PvN0C/ABxRBbwPEWaLoJs nGhrNAoqXcD3oIShyqg8UNgmsfhevqHVT8E8dLMrotD+OrG8kE/HdyVm/USy6B+yR8NP ANFyq8nCtCkDLK8TWZXNOJUftS62axiPbwb+K8q0daVenbuzetThRGHnCzihQKvMVYWR qqIzpa6iFB/ltJZrIAidAMYtxWe+VEHHsXJheEfpkqatARC1RvJQuYD5YzQuM9/TM7Ir KPmA== X-Gm-Message-State: APjAAAXJCuKQgGskoG+7IRUVNdE3D9gAcWGliTJPs7S/6pXzijWVfi0W NmJXZs11uk5VSzNNqvF5vIJeU2xZY6qf X-Google-Smtp-Source: APXvYqxgHckfG2j/4hV6UO/PmbwG1m1hwwktkcim+z5N2VDyc3YBV/Zoy2X88TimTBNKEJUzaQLwmA== X-Received: by 2002:a17:902:7043:: with SMTP id h3mr90438609plt.10.1561387724105; Mon, 24 Jun 2019 07:48:44 -0700 (PDT) Received: from [192.168.1.7] ([174.27.68.92]) by smtp.googlemail.com with ESMTPSA id 137sm12413796pfz.116.2019.06.24.07.48.43 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jun 2019 07:48:43 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <9cb2ae87-3a86-415f-9b94-2d2052e49234@www.fastmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <9eaef0ef-92d7-149c-b996-d894acda66ac@gmail.com> Date: Mon, 24 Jun 2019 08:48:42 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9cb2ae87-3a86-415f-9b94-2d2052e49234@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] JSCalendar: Updated draft-ietf-calext-jscalendar-16 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 14:49:02 -0000 On 6/24/19 7:10 AM, Robert Stepanek wrote: > Hi all, > > I just updated draft-ietf-calext-jscalendar to version 16: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-16 > > This update redefines the "isAllDay" property to "showWithoutTime" and allows it for both JSEvent and JSTask, as discussed on this mailing list. I - now understand :-) > In addition, the draft references RFC 3986 in the security considerations for URIs. > > There are no open points remaining and we consider this RFC draft complete, apart from editor review. If you find any point in the document unclear or disputable, please let us know now. Deep reading starting tomorrow :-) -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Mon Jun 24 13:02:07 2019 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 4CA251200B2 for ; Mon, 24 Jun 2019 13:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_NONE=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 elfF2ew_DyVG for ; Mon, 24 Jun 2019 13:02:03 -0700 (PDT) Received: from mailrelay3-1.pub.mailoutpod1-cph3.one.com (mailrelay3-1.pub.mailoutpod1-cph3.one.com [46.30.210.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FE0120139 for ; Mon, 24 Jun 2019 13:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=B3KFCipzUjG/tMFITrlt/6od2Rcc6BMApbNECfVxoGY=; b=juooWw8cIgrWormnbYSFoYZzp5Z1mkrHvboexCzEUuMMWqkp/YTX8tB3D0r0didWpDet2SgsJazlm jVE73rmkRBZhVj09gVPHhuwMVvpKHbGKlGhIpv5YgDhOGRc+a+C3teBZCDcaVOKZuQ7yw6GaekwNoT bqfdHJBGN7sMjdiM= X-HalOne-Cookie: ad5d71b8a650f12056083edceafbc7139e281455 X-HalOne-ID: ec44f468-96ba-11e9-b5e9-d0431ea8bb03 Received: from smtp.dmfs.org (unknown [84.129.207.176]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id ec44f468-96ba-11e9-b5e9-d0431ea8bb03; Mon, 24 Jun 2019 20:01:58 +0000 (UTC) Received: from boss.localdomain (p548B1167.dip0.t-ipconnect.de [84.139.17.103]) by smtp.dmfs.org (Postfix) with ESMTPSA id 33220589 for ; Mon, 24 Jun 2019 22:01:58 +0200 (CEST) To: calsify@ietf.org References: <9cb2ae87-3a86-415f-9b94-2d2052e49234@www.fastmail.com> From: Marten Gajda Message-ID: <3f041fa7-d61a-5637-7823-a85463bfa88d@dmfs.org> Date: Mon, 24 Jun 2019 22:01:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <9cb2ae87-3a86-415f-9b94-2d2052e49234@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------287511C3D5F6CFB67ECD71B8" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar: Updated draft-ietf-calext-jscalendar-16 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 20:02:07 -0000 This is a multi-part message in MIME format. --------------287511C3D5F6CFB67ECD71B8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Robert, the location object states: > o name: String (optional, default: empty String). The human- > readable name of the location. > > o description: String (optional). Human-readable, plain-text > instructions for accessing this location. This may be an address, > set of directions, door access code, etc. Just out of curiosity, why does "name" default to "empty String", as opposed to 'no default' like the description? Is "empty String" the same as "this location has no specific name"? Cheers, Marten Am 24.06.19 um 15:10 schrieb Robert Stepanek: > Hi all, > > I just updated draft-ietf-calext-jscalendar to version 16: > https://tools.ietf.org/html/draft-ietf-calext-jscalendar-16 > > This update redefines the "isAllDay" property to "showWithoutTime" and > allows it for both JSEvent and JSTask, as discussed on this mailing list. > > In addition, the draft references RFC 3986 in the security > considerations for URIs. > > There are no open points remaining and we consider this RFC draft > complete, apart from editor review. If you find any point in the > document unclear or disputable, please let us know now. > > Thanks, > Robert > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------287511C3D5F6CFB67ECD71B8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hi Robert,

    the location object states:

       o  name: String (optional, default: empty String).  The human-
      readable name of the location.

   o  description: String (optional).  Human-readable, plain-text
      instructions for accessing this location.  This may be an address,
      set of directions, door access code, etc.
    Just out of curiosity, why does "name" default to "empty String", as opposed to 'no default' like the description?

    Is "empty String" the same as "this location has no specific name"?

    Cheers,

    Marten

    Am 24.06.19 um 15:10 schrieb Robert Stepanek:
    Hi all,

    I just updated draft-ietf-calext-jscalendar to version 16: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-16

    This update redefines the "isAllDay" property to "showWithoutTime" and allows it for both JSEvent and JSTask, as discussed on this mailing list.

    In addition, the draft references RFC 3986 in the security considerations for URIs.

    There are no open points remaining and we consider this RFC draft complete, apart from editor review. If you find any point in the document unclear or disputable, please let us know now.

    Thanks,
    Robert

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

    -- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
    --------------287511C3D5F6CFB67ECD71B8-- From nobody Tue Jun 25 01:05:51 2019 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 A9E38120219 for ; Tue, 25 Jun 2019 01:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BppMfEiQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iL6KPo0L 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 lw1qgE46uLxv for ; Tue, 25 Jun 2019 01:05:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB21E120019 for ; Tue, 25 Jun 2019 01:05:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 03AAF22605 for ; Tue, 25 Jun 2019 04:05:47 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 25 Jun 2019 04:05:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=582SbOB EqdhyunyguVsPHF4UkyicmnBuDkWAMMnz4Tg=; b=BppMfEiQUEji8JxAwJona3o HQnxDifud8Sd3tT5EjDd6vrg1JinAkWR3O9HRQS7PG2eHr1sIDjHVA+oF/GsKlWA jpqYJrK2KlafD4BDJESYZukNLDvL9kvhPEVxRdS0uVsUKe5XMhc4x2Ohjw8Csk2q 9+FdKYqxUq/lzMBFZPtVuIuPpDryJD7/z00ClFa1U6Yd4Mkql+xM1o3xfucu6Eda 8NpaASkk38ISHpFtor38GbHqYMybJIf5X0w0PzLa0HoDu1zxEIXxk7eYtRQ4G4Ki 7RR1gX/xzHi47tb51Afp0nsSBKAqQI41qH8Htyr4MmZMORAya+LyS5u/y1eJl9A= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=582SbO BEqdhyunyguVsPHF4UkyicmnBuDkWAMMnz4Tg=; b=iL6KPo0LFLtAidh1184ZSm 4k4dlURl1Q4DcuoigVkIJBVk14lkSQiylbSZgqAFTICUpl51YiSEwomtuBA7DKfs jg8MkfPv8IQkjh66KiCQ7693+Qi1IobXZRhn13WTCL51xuyote90ndEtLUGLqlzf yUw4xtPYHtD0Qn1NAplleTbnQ37z56iXv8kR8nurrcSbA2rutNByjFlruW4ffgBo V2cDK7jYZhL0FwD9BE4D1wFaj3wfvBzX/5XKvmZLj/ZFk4Civft/l7HssbjK6e0K td4ck0goMCnccqVgM1J+dsVTihtoQf5O1ZPtjX4A7Vg88DrU/CEQFeTiMTglUbQg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefgddufeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 843BB1800B0; Tue, 25 Jun 2019 04:05:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-730-g63f2c3b-fmstable-20190622v1 Mime-Version: 1.0 Message-Id: <8040de7d-08ba-4b89-8cf8-fcc882a19557@www.fastmail.com> In-Reply-To: <3f041fa7-d61a-5637-7823-a85463bfa88d@dmfs.org> References: <9cb2ae87-3a86-415f-9b94-2d2052e49234@www.fastmail.com> <3f041fa7-d61a-5637-7823-a85463bfa88d@dmfs.org> Date: Tue, 25 Jun 2019 10:05:46 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=9ca59bb5c665463a9b6f493889fe0a6e Archived-At: Subject: Re: [calsify] JSCalendar: Updated draft-ietf-calext-jscalendar-16 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 08:05:50 -0000 --9ca59bb5c665463a9b6f493889fe0a6e Content-Type: text/plain Hi Marten, On Mon, Jun 24, 2019, at 10:02 PM, Marten Gajda wrote: > Just out of curiosity, why does "name" default to "empty String", as opposed to 'no default' like the description? > Is "empty String" the same as "this location has no specific name"? Thanks. I can't think of a good reason, other than an implementation detail of our JSCalendar code. I'll remove the default empty String from Location.name and keep the property optional. Cheers, Robert --9ca59bb5c665463a9b6f493889fe0a6e Content-Type: text/html
    Hi Marten,

    On Mon, Jun 24, 2019, at 10:02 PM, Marten Gajda wrote:

    Just out of curiosity, why does "name" default to "empty String", as opposed to 'no default' like the description?

    Is "empty String" the same as "this location has no specific name"?


    Thanks. I can't think of a good reason, other than an implementation detail of our JSCalendar code.

    I'll remove the default empty String from Location.name and keep the property optional.

    Cheers,
    Robert

    --9ca59bb5c665463a9b6f493889fe0a6e-- From nobody Wed Jun 26 07:41:44 2019 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 2FF32120150; Wed, 26 Jun 2019 07:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyBrgbuLl1in; Wed, 26 Jun 2019 07:41:42 -0700 (PDT) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 51E33120162; Wed, 26 Jun 2019 07:41:33 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id i10so3800752iol.13; Wed, 26 Jun 2019 07:41:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wV4PfBeMNJQ7TfqSFxp4L+1FqGHaJpfFf+a70VDGDUM=; b=Dm+aOyEIYwvv3viQnFT0ZSP4vqZ8AGCUhhGedl9mp8F8pnZxp917akNyoBm1OO0tBy Gayfpt6oRSf8LQ1x/KgZwTFKMGfi+rC2PAA39AwQ7cNrcQoYNWlB33bjvVb7eldzVqaV 5pWiU75On+0klmPFXwGeMaNIlVa+LHc5dJZNpDCUXcL+qByUwseXltsX5nFGpaGm2jb9 qzNMUoLjr0KlB5LbD8pGGt4kojW/Gpjytbt/F/2Om7INHZPrh5uucffVgiKdTkdZwOm4 PZ4nDA39fB2mHu/erUVxX6cray2bXorhJ6XpvB+GptPoK4pTh2BZ7yctVOHZnzAt1sZM qlyQ== X-Gm-Message-State: APjAAAV0V3Ck+ovJbDEkLZchSPM/JR6/tYXxdUZjySnLNJZl8k/TADIy FC2ZGG62a2meuCLiFkEmYgbhdo+3BTuHDWzX5QY= X-Google-Smtp-Source: APXvYqx72NNt8WTBUu5O/dw0BPCgoMQpY6efDaNQTvUSswiRxedMwuo6JPdzFOI7ayYvCoohiapeSQtMfdQJicdSrJE= X-Received: by 2002:a02:cb96:: with SMTP id u22mr5332487jap.118.1561560092155; Wed, 26 Jun 2019 07:41:32 -0700 (PDT) MIME-Version: 1.0 References: <155799446016.19593.5421721957765362252.idtracker@ietfa.amsl.com> <309a7ae1-09fb-137b-a639-f0b04328aeed@gmail.com> In-Reply-To: From: Barry Leiba Date: Wed, 26 Jun 2019 15:41:21 +0100 Message-ID: To: Michael Douglass Cc: The IESG , draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 14:41:44 -0000 > >> =E2=80=94 Section 10 =E2=80=94 > >> It=E2=80=99s good to refer to RFC 3986 for URI-related security consid= erations, and all > >> of them do apply here. > >> > >> Something else that comes to mind that comes along with a set of new U= RIs is > >> whether they actually point to what they say they do. I don=E2=80=99t= see that there=E2=80=99s > >> any way to verify that they do, and I=E2=80=99m very skeptical about t= he effectiveness > >> of warning an end user about this sort of thing, for many reasons. I = can see > >> why allowing URIs is convenient and compelling, but I=E2=80=99m very h= eavily concerned > >> about tracking and other privacy leaks, malicious and deceptive conten= t, and > >> other such problems, especially considering the prevalence of abusive = calendar > >> invitations these days. > >> > >> I=E2=80=99m not sure what the answer is here, but let=E2=80=99s have a= discussion about it and > >> see where we can go with it. > > > > Maybe a brief discussion at CalConect/IETF meeting? > > Yes, that sounds like a good idea. We'll hold this until then. I see the notes from the meeting, and all I see about this document is: > Eventpub: > - https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > - Discussion about the SOURCE property (drop it) > - Need to define =E2=80=9Csocial calendaring=E2=80=9D. Was the URI issue I raised discussed? If not, when can we discuss it and clear this up? Barry From nobody Wed Jun 26 08:07:41 2019 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 1D6D312008D for ; Wed, 26 Jun 2019 08:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sphericalcowgroup-com.20150623.gappssmtp.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 X8Wg9UZwYhVI for ; Wed, 26 Jun 2019 08:07:32 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 2BC51120136 for ; Wed, 26 Jun 2019 08:07:29 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id x18so1889456qkn.13 for ; Wed, 26 Jun 2019 08:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sphericalcowgroup-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=XYrYMLmsgm1GAc9jxG2k4c7WSMaVPD1cgfi+C3GKnEk=; b=dN0sDfN3pPHZqXgRYlER+pyyIYdRr4R54gR39rFpnZ6YzPQbtYi6Ynnaizl48p4cbE WqzWCOSQYprJHFdzsDmrA9Ud30RrVUSlVPvKO8Mmcp9RBPO/ZA0Yw/mtEh0gqoGvel+H myA3OFdGdGiMjB7KZg2JwByhkBy/3m2ZzBRGz1f+jFTVi/+W1shcgoL/uTmT3YJbvdzj 7hAdhQOdzcf6vKDr1jfcAFipFp2mgrKAUN9nbDM7FnFRlolOCJiUMjrPPjpVTjuvSwRy st2ZI6SIBMcj9Hz7Ti5P/OqxSKDbHqJcZTZfXzNLYYvzBoegvXyCAZQar2+vH5Rez6E0 GHCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=XYrYMLmsgm1GAc9jxG2k4c7WSMaVPD1cgfi+C3GKnEk=; b=R9zOhpFRGbd9GH+4quTbDKkqNnbkbFtOlgmcn//oowbE3Wa2c0tp6pP8Zy9ppodBJU 0zG0gl9eC1P62RZiFNXzdKU/JGw9bAQ7anJwbou+vRyVREkoUY/fZwi8/JUMuDuD6HtB mGlmxmHidYcWeGOENqPcv3FeUt/NwfLBk4EQse++khYi9UtCHOvC+AF5+/LiFWmg5omT pRhPTCer+2B7FGS8HDgi76xL37hZwLp4ay6NXMEEM2DzekfzHL4ZfpyzPNOak4Rutdlm sZNJqurvDz8hHlifQxzIN/iZWbHjHX2/khWYapWjEWFZzM/n5M89gvRjK8SEogHxAThO aHuQ== X-Gm-Message-State: APjAAAXhKkQWXKVex3CgREVYgZIIDp3blsmclpzBi/sZ/2nAV+8u3oN2 GvUAgbY/gpYsbB8uVU3zCYLSynTSFpw= X-Google-Smtp-Source: APXvYqzYrPStFIAQmL6EG7eaQePSVOqMNRNExS6aKTruGoI4zG3uC/+39vIW9lkOZJiNvgQklquQ4A== X-Received: by 2002:a05:620a:16b2:: with SMTP id s18mr4175104qkj.323.1561561648054; Wed, 26 Jun 2019 08:07:28 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.gmail.com with ESMTPSA id g2sm3146212qkf.32.2019.06.26.08.07.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2019 08:07:27 -0700 (PDT) To: Barry Leiba , Michael Douglass Cc: The IESG , draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org References: <155799446016.19593.5421721957765362252.idtracker@ietfa.amsl.com> <309a7ae1-09fb-137b-a639-f0b04328aeed@gmail.com> From: Michael Douglass Message-ID: <5709c851-a615-1ae4-8f3a-e74936267754@sphericalcowgroup.com> Date: Wed, 26 Jun 2019 11:07:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B638751C8720ACF6EFB9EE25" Content-Language: en-US Archived-At: Subject: Re: [calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 15:07:34 -0000 This is a multi-part message in MIME format. --------------B638751C8720ACF6EFB9EE25 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit That would have been a good discussion to have. Somehow it dropped off the list. I'd suggest it's not specifically a problem with this draft - we already have that issue with other properties and other drafts but I certainly don't mind using it as a starting point. I think we need more than just a single paragraph: we do have this Guidelines to protect against calendar abuse (https://standards.calconnect.org/csd/cc-18003.html) It does refer to links as an issue but maybe we need more detail? On 6/26/19 10:41, Barry Leiba wrote: >>>> — Section 10 — >>>> It’s good to refer to RFC 3986 for URI-related security considerations, and all >>>> of them do apply here. >>>> >>>> Something else that comes to mind that comes along with a set of new URIs is >>>> whether they actually point to what they say they do. I don’t see that there’s >>>> any way to verify that they do, and I’m very skeptical about the effectiveness >>>> of warning an end user about this sort of thing, for many reasons. I can see >>>> why allowing URIs is convenient and compelling, but I’m very heavily concerned >>>> about tracking and other privacy leaks, malicious and deceptive content, and >>>> other such problems, especially considering the prevalence of abusive calendar >>>> invitations these days. >>>> >>>> I’m not sure what the answer is here, but let’s have a discussion about it and >>>> see where we can go with it. >>> Maybe a brief discussion at CalConect/IETF meeting? >> Yes, that sounds like a good idea. We'll hold this until then. > I see the notes from the meeting, and all I see about this document is: > >> Eventpub: >> - https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ >> - Discussion about the SOURCE property (drop it) >> - Need to define “social calendaring”. > Was the URI issue I raised discussed? If not, when can we discuss it > and clear this up? > > Barry --------------B638751C8720ACF6EFB9EE25 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    That would have been a good discussion to have. Somehow it dropped off the list.

    I'd suggest it's not specifically a problem with this draft - we already have that issue with other properties and other drafts but I certainly don't mind using it as a starting point.

    I think we need more than just a single paragraph: we do have this

    Guidelines to protect against calendar abuse (https://standards.calconnect.org/csd/cc-18003.html)

    It does refer to links as an issue but maybe we need more detail?

    On 6/26/19 10:41, Barry Leiba wrote:
    — Section 10 —
It’s good to refer to RFC 3986 for URI-related security considerations, and all
of them do apply here.

Something else that comes to mind that comes along with a set of new URIs is
whether they actually point to what they say they do.  I don’t see that there’s
any way to verify that they do, and I’m very skeptical about the effectiveness
of warning an end user about this sort of thing, for many reasons.  I can see
why allowing URIs is convenient and compelling, but I’m very heavily concerned
about tracking and other privacy leaks, malicious and deceptive content, and
other such problems, especially considering the prevalence of abusive calendar
invitations these days.

I’m not sure what the answer is here, but let’s have a discussion about it and
see where we can go with it.

    Maybe a brief discussion at CalConect/IETF meeting?

    Yes, that sounds like a good idea.  We'll hold this until then.

    I see the notes from the meeting, and all I see about this document is:


    Eventpub:
- https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
- Discussion about the SOURCE property (drop it)
- Need to define “social calendaring”.

    Was the URI issue I raised discussed?  If not, when can we discuss it
and clear this up?

Barry
    --------------B638751C8720ACF6EFB9EE25-- From nobody Thu Jun 27 07:53:01 2019 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 B0D9C120167 for ; Thu, 27 Jun 2019 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 Sf11RojfvyCB for ; Thu, 27 Jun 2019 07:52:58 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 78EEC12015F for ; Thu, 27 Jun 2019 07:52:58 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id f25so1128409pgv.10 for ; Thu, 27 Jun 2019 07:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BXfMJuY3QrGhDesxMmtFgd1rfXScFBWARzgLN603ONU=; b=newm5Gib6S5+eUJTIjA41ENgJyTDO1tCA2HxcCJSw0bNQyLMU3SM4sG0vDFTLmzFoP G11J/qzqv6PqCMm6V795ChyjG3WMheSY0hWd38ihv68nzG9QRPbC2x+HsbpmmNGE9wUs sQIY4yrNDw+HAa7c6Q84G7QQ2qbDajdTcFopR5mSzP0/wzjZcewB7Q8gbkbfJbbkyd4G gp9L3f7rX1JEmBp5+mNP18vj4TszdyJ6HnWD7MBLxYR6uj4eNLjSpk88cMiUCy101hvW b8odvj2er9WF6shHz2bpEzWAlleAFaiAJlJ3KAeYUxmwhUCdg6ucI+HtMmGg7KFfs5kH lz1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=BXfMJuY3QrGhDesxMmtFgd1rfXScFBWARzgLN603ONU=; b=NVeVTCJMEVbkE29xG9KSc2pQhKen4UuPxuKEA/bCxJLbuHZp93EOd0rV0XvDP/vb1g lG5ck+zGdCMhfUT/ufR0K2lbGheNj20eCw0ZkpctLO2Hg1D7lwyebeBULeEpO9uC88BZ 0/+E1iMuSQ7YRYQyRuPy+7Uws5XJEfpmBigHNaBsTb/NTBal62hMif7WZNT9Gkvr/u9A CUoN2J7zHHOSGELZxf0b1C+l+bXOPC9iNtOmIwZ+nJ+Vc6CA+zgW/kBj7i60hmh2p46Z EGmXt/wE52x6fZh256tN+hT2LHT0DQ68ejyOVRTG6g4iZNXX+vw2uTSRcb4sUQDARIhO 179A== X-Gm-Message-State: APjAAAUqNH0ZifFrACqid1hcDniEhjKa46nBjw57NYGhzUfvI+f1982C bEghx+n+sgK4BhyeVIUjwAbW4Cda5DqG X-Google-Smtp-Source: APXvYqzQTb2g1ZsESc3xANN1ijRnCaCmPC21PGJydru4RPl8mceHvZLF88a1z89/rTNXMuhiLt2/Mg== X-Received: by 2002:a17:90a:a404:: with SMTP id y4mr6824940pjp.58.1561647177569; Thu, 27 Jun 2019 07:52:57 -0700 (PDT) Received: from [192.168.1.7] ([174.27.175.146]) by smtp.googlemail.com with ESMTPSA id w22sm2861878pfi.175.2019.06.27.07.52.56 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2019 07:52:56 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <155799446016.19593.5421721957765362252.idtracker@ietfa.amsl.com> <309a7ae1-09fb-137b-a639-f0b04328aeed@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <9382a364-b9e7-b054-1add-19e6553cb130@gmail.com> Date: Thu, 27 Jun 2019 08:52:55 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <309a7ae1-09fb-137b-a639-f0b04328aeed@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 14:53:00 -0000 On 5/25/19 8:44 PM, Michael Douglass wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks for the work in this document; I think there’s useful stuff here, and I >> appreciate what it took to put it together. Two things at the DISCUSS level: >> >> — Sections 5.2, 7.1, and 8.1 — >> Please see BCP 178 (RFC 6648), and then remove x-name and x-prop. Thanks. > Removed Your really limiting *ALL* resources to *ONLY* these: "ROOM", "PROJECTOR", "REMOTE-CONFERENCE-AUDIO", "REMOTE-CONFERENCE-VIDEO" ? I have seen many more over the years. Such as: Car, Laptop, Cabin, Test-Station, ... At a more global level. I think that resource type is one of the most free-for-all value types in iCalendar. It is not going to be possible to define what vertical market calendar applications need. The removal of x-name will be ignored (as it is now). I have seen many that do not start with "X-" and are not IANA defined. It started off years ago (before 2445) with a suggestion or example. So examples were added, that became IANA defined. However *MANY* non standard values exist in the WWW wild world. Would it be more realistic to open it up to any name the user or application needs? I am guessing that closing it down - will be ignored, as it is now. Similar with x-prop. Vendors add properties they need in vertical market calendaring applications. They are going to add them. They are going to be seen. So now your going to remove a preferred way and almost invite confusion. Currently an implementation can simply ignore x-whatever. Now it is easy to filter out vendor specific X-PROP properties. It is going to be a mess for an existing implementation to guess if it is vendor specific, or a new IANA defined property that should be preserved. For the most part, they prefix their vendor specific properties with X-, now your removing that restriction? What was the reasoning for removing them? Without them, this looks more like a candidate for an FYI-only RFC documentation that describes how a single (or few) vendor does things. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Thu Jun 27 08:27:59 2019 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 552B412006F for ; Thu, 27 Jun 2019 08:27:57 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VEo0OkowYslA for ; Thu, 27 Jun 2019 08:27:55 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 50F7A120045 for ; Thu, 27 Jun 2019 08:27:55 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id c11so2051758qkk.8 for ; Thu, 27 Jun 2019 08:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=cK4c0D5YYcn72t1LqMF841kKBZtXoacNI3Yi3slPGro=; b=uvZwNuKY0ftvZohfEbdfMD+YwnCBZfS9n6QS654UlpPFy3BwF+7YSlk+qqPFdNTBap hfQdbzDBVxoUOdv4lKmmFO6WM3klSS7+GfUZjU2Cu0BMwEG1sVUDWqgVMrdYPxfWywJf hhM4oRhetPHkOJ0VLKk9Vd3eVCtb7Es7UDfDU8exDiM7HqQ9kik389rR0/CXsLDFlgcI ZiZ9lh3oYGa1+Gk43/BUgULR206xfQMsBtbhKCCJTVNzgdko7xWwKob5awypx73S9Si4 fLGCjxTWH15nVTG9HxU38TbBvNhL76VOxnix6gz9Qd9roZwR+x+bXVCbRX4UzboLuxqs SMlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=cK4c0D5YYcn72t1LqMF841kKBZtXoacNI3Yi3slPGro=; b=e/76p0HUaOuT+TmLFtUgjLLX18BkMFgNXudQx30YEA6oLDRSjKfJ4p7MmLsnoluaT2 Bus3oOKeBNFj+2Mc7DzrUsq2fHJ0kPd6URejUsup9h61SlaJgJe1kHNpyIS5hPvxaALT y6t1VQPu7stQNATB1mL8/3hWF0yfiN3r3MI5l4pEzX9+HDFbeG+K8PMIte4lDyxYyiL3 sujblqMljvXwtRQkn7UD4FLefC92Op5ifmo/i0OG7XpGj5kS4bKDeVFzelWo22mnYqgK 6ygV0hSKNuQi3xr+6U+Sz/Q+0A4Y/yBhmFsuFCXplgpTs6Ql8dy4+CxkcLxOh1VJEcux NmhA== X-Gm-Message-State: APjAAAXPn7MwqR+th6G/eX2q6qa85vwgQ2r+Rz+QuDy6OXip5An62awZ i+hfPNZD0cxEiGArTeaijj+giKPRrZU= X-Google-Smtp-Source: APXvYqzRo3UkWzwyVA497wtdt1IqAsYpSs9eBUIvABlU5VH0yjkjfFFQtkrcHQxgr4hEG0fF71nX4Q== X-Received: by 2002:ae9:f101:: with SMTP id k1mr3956182qkg.337.1561649274289; Thu, 27 Jun 2019 08:27:54 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id f26sm1343734qtf.44.2019.06.27.08.27.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2019 08:27:53 -0700 (PDT) To: Doug Royer , calsify@ietf.org References: <155799446016.19593.5421721957765362252.idtracker@ietfa.amsl.com> <309a7ae1-09fb-137b-a639-f0b04328aeed@gmail.com> <9382a364-b9e7-b054-1add-19e6553cb130@gmail.com> From: Michael Douglass Message-ID: <90771e1c-699b-99fd-7391-4fb277f200b3@gmail.com> Date: Thu, 27 Jun 2019 11:27:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <9382a364-b9e7-b054-1add-19e6553cb130@gmail.com> Content-Type: multipart/alternative; boundary="------------1D381D2BE315A0A07066AA8B" Content-Language: en-US Archived-At: Subject: Re: [calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 15:27:57 -0000 This is a multi-part message in MIME format. --------------1D381D2BE315A0A07066AA8B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 6/27/19 10:52, Doug Royer wrote: > On 5/25/19 8:44 PM, Michael Douglass wrote: >> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> Thanks for the work in this document; I think there’s useful stuff >>> here, and I >>> appreciate what it took to put it together.  Two things at the >>> DISCUSS level: >>> >>> — Sections 5.2, 7.1, and 8.1 — >>> Please see BCP 178 (RFC 6648), and then remove x-name and x-prop.  >>> Thanks. >> Removed > > Your really limiting *ALL* resources to *ONLY* these: "ROOM", > "PROJECTOR", "REMOTE-CONFERENCE-AUDIO", > "REMOTE-CONFERENCE-VIDEO" ? I have seen many more over the years. Such > as: Car, Laptop, Cabin, Test-Station, ... No - as the spec says The registered values are described below. New resource types SHOULD be registered in the manner laid down in this specification. > > At a more global level. I think that resource type is one of the most > free-for-all value types in iCalendar. It is not going to be possible > to define what vertical market calendar applications need. The removal > of x-name will be ignored (as it is now). I have seen many that do not > start with "X-" and are not IANA defined. It started off years ago > (before 2445) with a suggestion or example. So examples were added, > that became IANA defined. However *MANY* non standard values exist in > the WWW wild world. > > Would it be more realistic to open it up to any name the user or > application needs? > I am guessing that closing it down - will be ignored, as it is now. There is value in having a 'standard' set of resources - it allows UIs, applications etc to handle it in a more automated manner. > > Similar with x-prop. Vendors add properties they need in vertical > market calendaring applications. They are going to add them. They are > going to be seen. So now your going to remove a preferred way and > almost invite confusion. Currently an implementation can simply ignore > x-whatever. Now it is easy to filter out vendor specific X-PROP > properties. It is going to be a mess for an existing implementation to > guess if it is vendor specific, or a new IANA defined property that > should be preserved. For the most part, they prefix their vendor > specific properties with X-, now your removing that restriction? > > What was the reasoning for removing them? > > Without them, this looks more like a candidate for an FYI-only RFC > documentation that describes how a single (or few) vendor does things. > --------------1D381D2BE315A0A07066AA8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


    On 6/27/19 10:52, Doug Royer wrote:
    On 5/25/19 8:44 PM, Michael Douglass wrote:

    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------

    Thanks for the work in this document; I think there’s useful stuff here, and I
    appreciate what it took to put it together.  Two things at the DISCUSS level:

    — Sections 5.2, 7.1, and 8.1 —
    Please see BCP 178 (RFC 6648), and then remove x-name and x-prop.  Thanks.
    Removed

    Your really limiting *ALL* resources to *ONLY* these: "ROOM", "PROJECTOR", "REMOTE-CONFERENCE-AUDIO",
    "REMOTE-CONFERENCE-VIDEO" ? I have seen many more over the years. Such as: Car, Laptop, Cabin, Test-Station, ...

    No - as the spec says

          The registered values are described below.  New resource types
      SHOULD be registered in the manner laid down in this
      specification.

    At a more global level. I think that resource type is one of the most free-for-all value types in iCalendar. It is not going to be possible to define what vertical market calendar applications need. The removal of x-name will be ignored (as it is now). I have seen many that do not start with "X-" and are not IANA defined. It started off years ago (before 2445) with a suggestion or example. So examples were added, that became IANA defined. However *MANY* non standard values exist in the WWW wild world.

    Would it be more realistic to open it up to any name the user or application needs?
    I am guessing that closing it down - will be ignored, as it is now.
    There is value in having a 'standard' set of resources - it allows UIs, applications etc to handle it in a more automated manner.

    Similar with x-prop. Vendors add properties they need in vertical market calendaring applications. They are going to add them. They are going to be seen. So now your going to remove a preferred way and almost invite confusion. Currently an implementation can simply ignore x-whatever. Now it is easy to filter out vendor specific X-PROP properties. It is going to be a mess for an existing implementation to guess if it is vendor specific, or a new IANA defined property that should be preserved. For the most part, they prefix their vendor specific properties with X-, now your removing that restriction?

    What was the reasoning for removing them?


    Without them, this looks more like a candidate for an FYI-only RFC documentation that describes how a single (or few) vendor does things.

    --------------1D381D2BE315A0A07066AA8B-- From nobody Thu Jun 27 10:54:39 2019 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 77FBC120125 for ; Thu, 27 Jun 2019 10:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 F639zSF4ry7H for ; Thu, 27 Jun 2019 10:54:35 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 F0BF512018F for ; Thu, 27 Jun 2019 10:54:33 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id 81so1587066pfy.13 for ; Thu, 27 Jun 2019 10:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=F1Tx3JyiaLTOylVqxfjgDevLHc3QbEM1sIkb1ZJcQc0=; b=tsR2+uEWrKDS4Nm2Lk4UWpbDylNfQL60Wx5TAsja7mH/OAOr+KmQR1aIJ5JeyjR0Qg s0Hm5xiGo+pjWF4FP715vp+KnYhEQgE+AWGgZ08RRsfxfWdw6obRHSZiNNXpBQ68IoS5 za6Z6YQ9vjKJ0+CgtTMXpGMkPabqKirbHb3OXY8NDPXy5BpLCvH/psrOI8dQkMEgByct m74AV+bwHHM/teryo6O8/OfUcaBUMYbf+dwbLVZmIv+10YDwFCFEQUauzvfqUD1sUXU8 1ah1XB5AujLtCCc3mS86S8f8G7qW9Ntu54iFqjRiiSjxnU2nk6VBmvlfAN2hL+LJuq61 lt/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=F1Tx3JyiaLTOylVqxfjgDevLHc3QbEM1sIkb1ZJcQc0=; b=Q13wyWULtD3FS3B0jT5DMSzBG/Pwwjs2UImlSPKyRy2AOwp47oqgpTXZEEWXL//Pjx pFh/v2AhkTBrGFTnjw+9GFssjktfPKWquJarirxFf/EN45fS156Vdg6Q/IDf7012IfOb 2oIvSDk3mogBv1StfJrgemrXmEOtdJNa7u0fN/UGYQKpa9a99AzNRcc2hEjRiPoWJAVM YTcSac8ByomD41qnBOp5EsJGZoDk+1ngBIhEpFXekQxj1h0nDNVqJf+92MheqaSON7ix +2PG+Afj3CxwKwXleKND4mH/CbMHCpW/KdE/OU3fA50f1M097lOMmwa1v9hc2/hsr9BQ w+8A== X-Gm-Message-State: APjAAAXFiifptCXed/pxVhmpzlEtO1gxikrO6hyajSKZpg1Y0Lra438f SIbHCXPDN+kDa7qX3s68vekM3ZHH2mzd X-Google-Smtp-Source: APXvYqzkx/nuxobudAFmTnKmWnDR0qnJATDBtL5R689rqzFJx7HWECrUn63R35X5A33Oht88uMKOLw== X-Received: by 2002:a17:90b:8d2:: with SMTP id ds18mr7667888pjb.132.1561658072889; Thu, 27 Jun 2019 10:54:32 -0700 (PDT) Received: from [192.168.1.7] ([174.27.175.146]) by smtp.googlemail.com with ESMTPSA id n26sm6367121pfa.83.2019.06.27.10.54.31 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2019 10:54:31 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <155799446016.19593.5421721957765362252.idtracker@ietfa.amsl.com> <309a7ae1-09fb-137b-a639-f0b04328aeed@gmail.com> <9382a364-b9e7-b054-1add-19e6553cb130@gmail.com> <90771e1c-699b-99fd-7391-4fb277f200b3@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Thu, 27 Jun 2019 11:54:30 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <90771e1c-699b-99fd-7391-4fb277f200b3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 17:54:38 -0000 On 6/27/19 9:27 AM, Michael Douglass wrote: >>>> >>>> Thanks for the work in this document; I think there’s useful stuff here, and I >>>> appreciate what it took to put it together.  Two things at the DISCUSS level: >>>> >>>> — Sections 5.2, 7.1, and 8.1 — >>>> Please see BCP 178 (RFC 6648), and then remove x-name and x-prop.  Thanks. >>> Removed >> >> Your really limiting *ALL* resources to *ONLY* these: "ROOM", "PROJECTOR", "REMOTE-CONFERENCE-AUDIO", >> "REMOTE-CONFERENCE-VIDEO" ? I have seen many more over the years. Such as: Car, Laptop, Cabin, Test-Station, ... > > No - as the spec says > > The registered values are described below. New resource types > SHOULD be registered in the manner laid down in this > specification. That is inconsistent with the ABNF. And over time, the ABNF wins. Except, it will be ignored making it another -bis debate. >> >> At a more global level. I think that resource type is one of the most free-for-all value types in iCalendar. It is not going to be possible to define what vertical market calendar applications need. The removal of x-name will be ignored (as it is now). I have seen many that do not start with "X-" and are not IANA defined. It started off years ago (before 2445) with a suggestion or example. So examples were added, that became IANA defined. However *MANY* non standard values exist in the WWW wild world. >> >> Would it be more realistic to open it up to any name the user or application needs? >> I am guessing that closing it down - will be ignored, as it is now. > There is value in having a 'standard' set of resources - it allows UIs, applications etc to handle it in a more automated manner. And, they can't, because there are already a lot of undocumented values that vendors are not going to just toss out of their implementation just because this makes it into an RFC. So, automate what? Is your implementation going be able to handle "CAR"? "Laptop"? ... I'll bet exactly zero implementations will come out that only handle IANA values. They are used and in existing implementations. They are treated as user values, not keywords. I will bet there will be zero implementations that fail when they get currently used and undefined values. So, your not documenting the world as it exists. And your not documenting the way the world wants things to exist. You seem to be documenting a way to make some code easier to implement, except I will bet you do not restrict your implementation to these. I say open them up, because there is not a definitive list, and can not be a definitive list. Same with x-prop. When google, apple, FB, or someone big makes a new one up. Are you going to be the implementation that breaks? Or are you in version one of your implementation accept them? >> Similar with x-prop. Vendors add properties they need in vertical market calendaring applications. They are going to add them. They are going to be seen. So now your going to remove a preferred way and almost invite confusion. Currently an implementation can simply ignore x-whatever. Now it is easy to filter out vendor specific X-PROP properties. It is going to be a mess for an existing implementation to guess if it is vendor specific, or a new IANA defined property that should be preserved. For the most part, they prefix their vendor specific properties with X-, now your removing that restriction? >> >> What was the reasoning for removing them? >> >> Without them, this looks more like a candidate for an FYI-only RFC documentation that describes how a single (or few) vendor does things. >> -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Fri Jun 28 16:11:06 2019 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 ADF55120A10; Fri, 28 Jun 2019 15:58:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: barryleiba@computer.org, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176268870.11015.4416252135459044077.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:58:08 -0700 Archived-At: Subject: [calsify] calext - Requested session has been scheduled for IETF 105 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 23:10:59 -0000 Dear Daniel Migault, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. calext Session 1 (1:00 requested) Wednesday, 24 July 2019, Afternoon Session II 1550-1650 Room Name: Notre Dame size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/calext.ics Request Information: --------------------------------------------------------- Working Group Name: Calendaring Extensions Area Name: Applications and Real-Time Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 15 Conflicts to Avoid: First Priority: ipsecme quic tls ace lwig dnsop People who must be present: Barry Leiba Daniel Migault Bron Gondwana Resources Requested: Special Requests: We will need to make possible remote participation --------------------------------------------------------- From nobody Sat Jun 29 08:57:27 2019 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 6DBB212004C; Sat, 29 Jun 2019 08:57:24 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <156182384436.12435.13108287695244909487@ietfa.amsl.com> Date: Sat, 29 Jun 2019 08:57:24 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-17.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 15:57:25 -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-17.txt Pages : 51 Date : 2019-06-29 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. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. 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-17 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-17 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 Sat Jun 29 08:57:50 2019 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 3156F1200F9; Sat, 29 Jun 2019 08:57:39 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <156182385852.12862.3959237958465742388@ietfa.amsl.com> Date: Sat, 29 Jun 2019 08:57:39 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-icalendar-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 15:57:49 -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: Converting from and to iCalendar Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-icalendar-01.txt Pages : 13 Date : 2019-06-29 Abstract: This document provides an informational guideline for converting JSCalendar from and to iCalendar. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar-icalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar-01 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-icalendar-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-icalendar-01 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 Sat Jun 29 09:09:07 2019 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 84C18120058 for ; Sat, 29 Jun 2019 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=fastmailteam.com header.b=Vh+QbVLN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qJonLYEt 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 gdWu5Ipt-zCl for ; Sat, 29 Jun 2019 09:09:03 -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 05F7E1200B3 for ; Sat, 29 Jun 2019 09:09:03 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 032F621BBF for ; Sat, 29 Jun 2019 12:09:02 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Sat, 29 Jun 2019 12:09:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=A7P03GV5+xyLiDFA3rkwgldnZeYENZXt43GOcNt QwP0=; b=Vh+QbVLNU14/AAzBtMzocOZGLhjQ97Oy9/5F3AsS2tDzrvpNTEHFKFT wooJzPYoSQn9eNyN+VVbunRQuT2TnwxJxKKRx90YWOJ6EhEnl3INyy7oufAAXvfW M2S18nhZok7uSMU/Pgvv3cpL1z3ARIfowgLnosPCx9xAnfxMDFezIyHZx/DyCap8 YX5XUSj8xIJkuO47d1dldEgazovlmNYUSCVwG16AUDwitfRdQfdeRJmphUjD8CwW zZ28cdVupyrumKdRkT+ewhrQjAiESRLP3U8+cXjSSNlP33Q9yxE9de8i09utdpw2 DXwDGyLztgO79HWa7m6+o4PnYfGTT+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=A7P03GV5+xyLiDFA3rkwgldnZeYEN ZXt43GOcNtQwP0=; b=qJonLYEtgWe5WPYy8oZMdQOAED/2bj98uNn/TDbFehFhd BfexC6LF2PQKFlXhma/vRe6wYBtZYQiy3u0O2kl+lBiUWgTxAoJ0rN0adFmkQ0+6 YaLGf5zz8h7sHgq13S0R3jLiBwgwgNOiuLhIcJGHDxgPrpF++c1tSxvQdkvsn+QG BYBbIXkfKxsXrmEjuxg8n5cSnDiyhB3sVN7C8tAcGPLo1bF9ElOm/S97E1Dz7HnM hsZeJuEBGqoGdVRsrOobOtUNC7TTLdqtMLUw0/J7nom3+1Pzq5P+w4lGYFuU2xfU bgVKXiHU4/4NzpxG6WxCtVtCZmPTmrAoxvKsEq24A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvddvgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 846EF180092; Sat, 29 Jun 2019 12:09:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <85aa8835-086a-4f71-aad3-c18f53fd5c0f@www.fastmail.com> Date: Sat, 29 Jun 2019 18:08:46 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=0367f11032f548c2b6d3531ca206f9a6 Archived-At: Subject: [calsify] JSCalendar: updated version 17 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 16:09:06 -0000 --0367f11032f548c2b6d3531ca206f9a6 Content-Type: text/plain Hi, I have uploaded version 17 of the JSCalendar RFC draft: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-17 This version includes a couple of clarifications and rephrasing: - Renamed UTCDate and LocalDate types to UTCDateTime and LocalDateTime, respectively. - Clarified that UTCDateTime values MUST end with 'Z' (zero offsets are not allowed). - Clarified to ignore pointers with forbidden key prefixes in recurrenceOverrides. - Removed the empty String Location.name default value for consistency. Based on the feedback on this list, we consider this RFC complete. The informational guide for mapping iCalendar and JSCalendar is updated to version 01: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar-01. I suggest we wait with completing this draft until the JSCalendar spec is officially accepted. It would help to hear from other developers if the recommended iCalendar mapping makes sense in their environments. FYI - I will be out of office over the summer months, and will not be able to reply to your feedback. Neil Jenkins is the co-author of this RFC and reads this list. Regards, Robert --0367f11032f548c2b6d3531ca206f9a6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    Hi,

    I have uploaded version 17 of the JSCalendar RFC draft= : https://tools.ietf.org/html/draft-ietf-calext-jscalendar-17

    This version includes a couple of clarifications = and rephrasing:
    - Renamed UTCDate and LocalDate types to U= TCDateTime and LocalDateTime, respectively.
    - Clarified th= at UTCDateTime values MUST end with 'Z' (zero offsets are not allowed).<= br>
    - Clarified to ignore pointers with forbidden key prefixes= in recurrenceOverrides.
    - Removed the empty String Locat= ion.name default value for consistency.

    Bas= ed on the feedback on this list, we consider this RFC complete.

    The informational guide for mapping iCalendar and J= SCalendar is updated to version 01: https://tools.ietf.org/htm= l/draft-ietf-calext-jscalendar-icalendar-01. I suggest we wait with = completing this draft until the JSCalendar spec is officially accepted. = It would help to hear from other developers if the recommended iCalendar= mapping makes sense in their environments.

    FYI - I will be out of office over the summer months, and will not be able=20= to reply to your feedback. Neil Jenkins is the co-author of this RFC and= reads this list.

    Regards,
    Ro= bert
    --0367f11032f548c2b6d3531ca206f9a6--