From nobody Sun Nov 3 13:41: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 E1E8A1200F1 for ; Sun, 3 Nov 2019 13:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 YSO34lWB41y8 for ; Sun, 3 Nov 2019 13:41:05 -0800 (PST) Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (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 75B2312002E for ; Sun, 3 Nov 2019 13:41:05 -0800 (PST) Received: by mail-vk1-f170.google.com with SMTP id o198so3349597vko.11 for ; Sun, 03 Nov 2019 13:41:05 -0800 (PST) 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; bh=iTulYed4c3ZC8u7pNadZ9wg2IaAsCjncporKpPkmfc4=; b=Qfbq7/zJcccEigxdPV1L59mLuEL3HFVAGqFbWbSxvkjr4/W5XAsHxQyG+9HlhFmg/H tpeBO+lu+IjGRlvJAZb5jO/iRkTu7j5wSo6WDY4/GfinxJdnXdrF7TXu/M7lXDmWK9Xw K1scH0NJUOoShYKl66Z2VAFyGZAqkKZXIP013PgSyArEPfNcFpIH6r/qcXqZ1WGVYTL/ KdDbY7fZRWLiCgCNPVh6+e1iDz0gjqfRp1zvDzxDRMso4ArIAImWWzf93cqmj1iu6L0/ a7DqRCmVqzhj7kb4u/E1+8FlEchQrAZSRUTfjo8pcAOht3ouHFMTc5z77ndg2p3DLvfh qSPQ== X-Gm-Message-State: APjAAAVkYU5Z7fFhisvFdNpEHuM1lbFYvLrLICeuZ+PcuTQg/MQVAyPB +G0QkIfKWM1iwoz9qXaNBXTHiaX8zyQAdtKx/BU= X-Google-Smtp-Source: APXvYqxm8W06IFHb6rF+G0DhfFgU2yK8wbAplRUutAYy0Y1QpVHoqaUR7vf0qPUcNWsT9N8Fvp9RIjYK4db3JkTxz7k= X-Received: by 2002:a1f:1781:: with SMTP id 123mr10387075vkx.39.1572817264457; Sun, 03 Nov 2019 13:41:04 -0800 (PST) MIME-Version: 1.0 References: <6d0fa1f3-5dbe-d4df-821f-a0bddb61546b@gmail.com> <3d216646-0235-0af4-b9ad-1401eea482c4@gmail.com> <7f83a966-d1e9-464e-acd2-45bb7fd05107@beta.fastmail.com> <98a0f7ca-213d-4be0-9b0c-310dad70c0ab@gmail.com> <595e1efa-97a0-4373-8d5f-d4e5e05a1838@dogfood.fastmail.com> <601a4ef3-d922-71e0-ab4b-8e539ed3f7ae@gmail.com> <669b29a4-1734-4ea1-9ac9-33e590d91762@dogfood.fastmail.com> <07d3a19b-5198-e9fa-acbf-94c5161e11fb@gmail.com> <322a91d4-3246-49df-a1c4-628a59cf5304@dogfood.fastmail.com> In-Reply-To: From: Daniel Migault Date: Sun, 3 Nov 2019 16:40:53 -0500 Message-ID: To: Michael Douglass Cc: Neil Jenkins , Daniel Migault , "calsify@ietf.org" Content-Type: multipart/alternative; boundary="000000000000583bbd0596780e9d" Archived-At: Subject: Re: [calsify] WGLC JSCalendar 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: Sun, 03 Nov 2019 21:41:07 -0000 --000000000000583bbd0596780e9d Content-Type: text/plain; charset="UTF-8" Hi, While discussion can continue. I am confident a consensus will be find. I am writing the write-up shepherd and here are some elements I would like to clarify: 1) IPR Could each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. 2) existing implementation Has any organization planing to implement JSCalendar - apart fast mail. If you are aware of any implementation that would help our ADs. 3) URIs section. This is clearly a detail, but I am not sure the URIs section is actually standard. I expect that we will be asked to move it to Informative section. Yours, Daniel On Mon, Oct 28, 2019 at 1:18 AM Michael Douglass wrote: > > On 10/28/19 00:55, Neil Jenkins wrote: > > On Mon, 28 Oct 2019, at 15:36, Michael Douglass wrote: > > As for the @path - In section 4.3.3 (version 21) for recurrence overrrides > we have > > A pointer in the PatchObject MUST be ignored if it starts with one of > the following prefixes: > > o @type > and a bunch more > > > That's just to do with the application of the patch in this instance, not > an inherent attribute of the PatchObject. The PatchObject is used > generically in JMAP RFC8620, Section 5.3 > , and it makes no sense > for it to have properties that are not patches; that would mean > semantically "every key in this object is a patch except if it's this > special value", which would be horrible to work with. > > Well my experience in implementing it is the reverse. Having the @type > simplifies things considerably. > > However - in the absence of any other input (an invitation for anybody > else to state an opinion on either side) I'll live with it. > > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --000000000000583bbd0596780e9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

While discussion can continue= . I am confident a consensus will be find.=C2=A0

I= am writing=C2=A0the write-up shepherd and here are some elements I would l= ike=C2=A0to clarify:

1) IPR

Could each author confirmed that any and all appropriate IPR
disclosu= res required for full conformance with the provisions of BCP 78
and BCP = 79 have already been filed.

2) existing implem= entation

Has any organization planing to implement= JSCalendar - apart fast mail. If you are aware of any implementation that = would=C2=A0help our ADs.=C2=A0

3) URIs section.

This is clearly a detail, but I am not sure the URIs= section is actually standard. I expect that we will be asked to move it to= Informative section.=C2=A0


Yours,= =C2=A0
Daniel

On Mon, Oct 28, 2019 at 1:18 AM Michael Dougl= ass <mikeadouglass@gmail.com<= /a>> wrote:
=20 =20 =20


On 10/28/19 00:55, Neil Jenkins wrote:
=20 =20 =20
On Mon, 28 Oct 2019, at 15:36, Michael Douglass wrote:

As for the @path - In section 4.3.3 (version 21) for recurrence overrrides we have

   A pointer in the PatchObject MUST be ignored if it starts w=
ith one of
   the following prefixes:

   o  @type
and a bunch more

That's just to do with the application of the patch in this instance, not an inherent attribute of the PatchObject. The PatchObject is used generically in JMAP RFC8620, Section 5.3= , and it makes no sense for it to have properties that are not patches; that would mean semantically "every key in this object is a patch except if it's this special value", which would be horribl= e to work with.

Well my experience in implementing it is the reverse. Having the @type simplifies things considerably.

However - in the absence of any other input (an invitation for anybody else to state an opinion on either side) I'll live with it.


Neil.
_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--000000000000583bbd0596780e9d-- From nobody Sun Nov 3 15:32:00 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 0D2A912003E for ; Sun, 3 Nov 2019 15:31:58 -0800 (PST) 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=JBVHxjh2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VsJX3VYt 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 DxyBor7Izlcq for ; Sun, 3 Nov 2019 15:31:55 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91410120026 for ; Sun, 3 Nov 2019 15:31:55 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8743620D89; Sun, 3 Nov 2019 18:31:54 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Sun, 03 Nov 2019 18:31:54 -0500 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:cc:subject:content-type; s=fm1; bh=0VmJ kErmha+qHMenWShaoL8rk5ZuG9jPX8uYzjotDY4=; b=JBVHxjh2FokN6RWLx+Jz Y6svJBkaxHUygUqHuqwORDLyByCOSuZ/j0vCp5EzipyjWs6IJtDJ5anCUAKVg3r9 hGRpixQqjLqSV/CdIWbejQjt277qiGUCGH/izUUoxw6BcGHbIYbDt5hKGKjXT+SJ sfwW4MmQkPq5ZQ6OFLwRu7Wp4YdxWmZf4CxQURpbxwbYVwIdbThfQcURJ4Gjw1xw /DADXGz3nAOJHq0E61d8ovjNTi35IHHEm4Gvp7Z1JxdTEhSS2vmRTFUfDJ3FGG09 dLVFODc5LGQTTa1kmNNPPGaY6OIvef6Jq9v7TsW6fYBqGEmQIzKkvTREBMaFltov fw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=0VmJkE rmha+qHMenWShaoL8rk5ZuG9jPX8uYzjotDY4=; b=VsJX3VYtSlYw5bunRNEm6s jez7KKKvujFxynIEmwqIQkVZHsJQfVkACis7wmNkTYjqRhx5cPtyLEshFDs7+4E7 sjtXI3XGe6Y1Cothmt1yi2cBbZsWgYpvVKin/XQhahwZkb7dOJne/7BTflpJ68nu /g6OfuOJM5D0x4+KS9mHC5Y0OBVhQwMUqc8dRNhWEO4PdWScG4WlcoWFd9iv37Uj xGk+og2qVTPCHZFsr9jDmwoWYToZRao2UjEGUq8CZ+XBfv6pgZOYWUrMP9DjT3DT 4hdsq7oY9WVUMduO/LjD39I70Mz636KuEEqCzzSAWltZA3+zyn9qL15ndNDXUPug == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduvddgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghm rdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2352030006F; Sun, 3 Nov 2019 18:31:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-516-g7c923bb-fmnext-20191030v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6d0fa1f3-5dbe-d4df-821f-a0bddb61546b@gmail.com> <3d216646-0235-0af4-b9ad-1401eea482c4@gmail.com> <7f83a966-d1e9-464e-acd2-45bb7fd05107@beta.fastmail.com> <98a0f7ca-213d-4be0-9b0c-310dad70c0ab@gmail.com> <595e1efa-97a0-4373-8d5f-d4e5e05a1838@dogfood.fastmail.com> <601a4ef3-d922-71e0-ab4b-8e539ed3f7ae@gmail.com> <669b29a4-1734-4ea1-9ac9-33e590d91762@dogfood.fastmail.com> <07d3a19b-5198-e9fa-acbf-94c5161e11fb@gmail.com> <322a91d4-3246-49df-a1c4-628a59cf5304@dogfood.fastmail.com> Date: Mon, 04 Nov 2019 10:31:33 +1100 From: "Neil Jenkins" To: "Daniel Migault" , "Michael Douglass" Cc: Calsify Content-Type: multipart/alternative; boundary=0c569ac87afd49e1a3fa0de76e24f786 Archived-At: Subject: Re: [calsify] WGLC JSCalendar 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: Sun, 03 Nov 2019 23:31:58 -0000 --0c569ac87afd49e1a3fa0de76e24f786 Content-Type: text/plain On Mon, 4 Nov 2019, at 08:40, Daniel Migault wrote: > 1) IPR > Could each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. Confirmed from me. > 3) URIs section. > > This is clearly a detail, but I am not sure the URIs section is actually standard. I expect that we will be asked to move it to Informative section. These should probably all be Normative References actually, looking at where they are being referenced from. I'll fix that. Neil. --0c569ac87afd49e1a3fa0de76e24f786 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, 4 Nov 2= 019, at 08:40, Daniel Migault wrote:
1) IPR
Could each aut= hor confirmed that any and all appropriate IPR
disclosures= required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

Confirmed from me.

3) URIs section.

This is clearly a detail, but I am not sure the = URIs section is actually standard. I expect that we will be asked to mov= e it to Informative section. 

=
These should probably all be Normative References actually, l= ooking at where they are being referenced from. I'll fix that.
=

Neil.
--0c569ac87afd49e1a3fa0de76e24f786-- From nobody Sun Nov 3 21:20:23 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 BE63C120096; Sun, 3 Nov 2019 21:20:14 -0800 (PST) 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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <157284481472.13465.1219128470520403284@ietfa.amsl.com> Date: Sun, 03 Nov 2019 21:20:14 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-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: Mon, 04 Nov 2019 05:20: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-01.txt Pages : 16 Date : 2019-11-03 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-calext-subscription-upgrade-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-subscription-upgrade-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 Tue Nov 5 07:03: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 33B421200B9 for ; Tue, 5 Nov 2019 07:03:38 -0800 (PST) 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 d22sG_cHKyt5 for ; Tue, 5 Nov 2019 07:03:36 -0800 (PST) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 1A05612001A for ; Tue, 5 Nov 2019 07:03:36 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id 190so9088717vss.8 for ; Tue, 05 Nov 2019 07:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/pfJ0Qe3s7bV7lsWd8MMrJ/5f6Dru4knBXNRQeC6dLc=; b=falRRJeuccG5+OPCf3LbL1pdnGeJ2hKCTdD67D6VdOEhhgabz25gYbh96b03KlBAKE H5+aOO3YFrn2hvZVlDYbTa1TOjcfRzDIjFX591fOu3x0uQlvcPfIk2UpZm+H5m4cEQWF fcbp+4PYb5lTZ1MFpuEQVKMJOKIvBzbQcCPL7P2/dyCsMYUVWMeEqB65tWdLrkP2gyka c7v5RaaTXrE3wSBRMMq2IJKbmOcrFHJlFJ8mztcW7513+gtGrZwQOgbG4hbkBITGcN2+ 3O14ey/dTP7BpCo6pYWcLWwUHZxmrC/OFuia2bm9f1btZiyjlZZMYfS8FeKR7o0Am1J7 cXDg== 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=/pfJ0Qe3s7bV7lsWd8MMrJ/5f6Dru4knBXNRQeC6dLc=; b=nHL/RpRAp8F4katU8W+/9t21inD1NiNQq9OtBw6zaES5VQ2LIFqG0XsBalh3n+1mah kH8p4AqL5cNlXxN6JU1fIvdtvG2+P3TfHwuZdWF5N8gQxeuxm2CKYCqWEeRDGUUgIrrq ffAy6Pqp+JwiPgXClM0bYZ1QK28hO/hIqsLQ2qbdbVcfStsbKwlPe09QGtO6I4FEa5oa LA+2Evy12gR5+W9soZxdaC3u1/Aa9dr/qrfH6radlQHwds93EfGy0Bs1cTK5y9YPvTrx 4w0mlCoFy8cKcoMqmEE83SGRHHHT9ALX7J/c0Qwb8Mzv3V6u8zKYTSrkX8rb1xP9TBU5 4iyg== X-Gm-Message-State: APjAAAXlj29yDX5OAmeqTLaUb1WDtqp4h7JRZflm7oZPJwFT832ZeuJB RmkI6o3kHcr5ezAqTg2E0cQDveXEBvf1kYfTNemgL1zAeGA= X-Google-Smtp-Source: APXvYqwcT64NHcR3Ymgo9oKiI/IXjqZBHxlqkmTZ+oKGX3/wu7jLzUgwLiAbZSiatpzhSXPbHC50t8X1nEp3n7jV93k= X-Received: by 2002:a67:f6d4:: with SMTP id v20mr10904687vso.31.1572966214844; Tue, 05 Nov 2019 07:03:34 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Tue, 5 Nov 2019 10:03:24 -0500 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="0000000000007ac81f05969abc03" Archived-At: Subject: [calsify] Calext @IETF 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, 05 Nov 2019 15:03:38 -0000 --0000000000007ac81f05969abc03 Content-Type: text/plain; charset="UTF-8" Hi, Calext is meeting at the IETF106 13:30-15:30 Monday Afternoon session I. Please let us know if you intend to present and request a presentation slot. We expect to go through all documents that are in the WG. If you will not be able to present, please provide to the mailing a short status update of the document as well as the next envisioned steps by the end of the year. Presentations are expected to be uploaded for Friday Nov 15: https://datatracker.ietf.org/meeting/106/session/calext IETF106 CALEXT WORKING GROUP AGENDA - Singapore 2019-11-18, 14:30-15:30 * Welcome, Notewell, Bluesheets, Agenda bashing: 5m * Current Drafts: * draft-ietf-calext-eventpub-extensions-15 * draft-ietf-calext-icalendar-series-00 * draft-ietf-calext-jscalendar-21 * draft-ietf-calext-jscalendar-icalendar-01 * draft-ietf-calext-subscription-upgrade-01 * draft-ietf-calext-valarm-extensions-00 Yours, Bron and Daniel -- Daniel Migault Ericsson --0000000000007ac81f05969abc03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Calext is meeting at the = IETF106=C2=A013:30-15:30 Monday Afternoon session I. Please let us know if = you intend to present and request=C2=A0a presentation slot.=C2=A0

We expect to go through all documents=C2=A0that are in the = WG. If you will not be able to present, please provide to the mailing a sho= rt status update of the document as well as the next envisioned=C2=A0steps = by the end of the year.=C2=A0

Presentations are ex= pected to be uploaded for Friday Nov 15:


IETF106 CALEXT WORKING GROUP =
AGENDA - Singapore 2019-11-18, 14:30-15:30

* Welcome, N=
otewell, Bluesheets, Agenda bashing: 5m
* Current Drafts:
  * draft-ietf-calext-eventpub-extensions-15 
  * draft-ietf-calext-icalendar-series-00 
  * draft-ietf-cale=
xt-jscalendar-21 
  * draft-ietf-calext-jscalendar-icalendar-01 
  * draft-ietf-calext-subscription-upgrade-0=
1 
  * draft-ietf=
-calext-valarm-extensions-00 
Yours,=C2=A0
Bron and Dan=
iel=C2=A0


-- 
=

Daniel Migault
Ericsson


--0000000000007ac81f05969abc03--


From nobody Tue Nov  5 09:16: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 352BE1200FE for ; Tue,  5 Nov 2019 09:15:58 -0800 (PST)
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 qdyDTXVmeUGG for ; Tue,  5 Nov 2019 09:15:56 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 390B512001A for ; Tue,  5 Nov 2019 09:15:56 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id q70so21801103qke.12 for ; Tue, 05 Nov 2019 09:15:56 -0800 (PST)
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=U0w/pikg3fSHk27+Asgxb7qYThLTkGUyk/aB2ZRj4BM=; b=oHTHAGi7rpNNUcs33V7HVDna5wf1w74v7aEkuGab7c0BN0JzMtYvUoVKTGtqG/fUbe QVI95Kp7LlQEzJYqQI57tFjGx+o+BS1HswmChsE71JsYqZMvcfwqMPhJgYznn85dZ3sh 9KuPl8wi90TnBRMZth1ZARxW5jRAOCJZeMTvo6TNDJK+Y31xtc09OUhGKYZjumZv5iDJ +pgVuiLxyyYfpq729ifvSjlt9mqysCXWi665N7iYjB0AEqVv9PsSR2NvLJ0t1IyyEGRq 9GDF9BPic/0kaX2kpMqndk4a2e6bbhDHMgCPqVLCALyLhpUihoIlWAS3Yrsodnp+PA/d Ecog==
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=U0w/pikg3fSHk27+Asgxb7qYThLTkGUyk/aB2ZRj4BM=; b=ku5IH2evpXeN9fQ1jvz1iZZKmQYk6NNqAI+9ShTwNq7kHBfOHqxgZ/RMc9SF7OoaGu JEK609wSCbVH4X3V6c1y3MWnjVw8lDbQhi0IznV8yEbzYq08lXae3qeLx96iDU8QOq14 +ADngMAdpI0uXm2weUjckk98CBkwo7byMRCrZofq8ArEZrRmNUy1lKCawOMvBgoyqIEh ViJNiqPfJvVN5d5xTHaV1GrbXOj30PyRWnW8fWqr9THdScyExQFX6bz5oPs28gxQPSSp eyy2f/RROxU04+ZDWkfdheGGi2/672OFD14+kwn5V47/6HiobwREQxBqHqDg59ITFUKk CEMg==
X-Gm-Message-State: APjAAAXqUW0RwKXopQwLKKU9YSMrZCF0xNByDi7QAjf3r0GtATs2BDKv JE/TVhHiSHn70b9U4CjaMfAh1XW2+pY=
X-Google-Smtp-Source: APXvYqx2+GU7+GN2/HC2jzVXF3S8wig9QGPOOmcGAksTon1Fv+NGxCxrGrN85qcs7hNxEnMCqODgSg==
X-Received: by 2002:a05:620a:133b:: with SMTP id p27mr18077027qkj.363.1572974154944;  Tue, 05 Nov 2019 09:15:54 -0800 (PST)
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 n21sm7843682qtn.33.2019.11.05.09.15.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2019 09:15:54 -0800 (PST)
To: Daniel Migault , IETF-Calsify 
References: 
From: Michael Douglass 
Message-ID: 
Date: Tue, 5 Nov 2019 12:15:52 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A791307F98A0E9D556F9E80C"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Calext @IETF
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, 05 Nov 2019 17:15:58 -0000

This is a multi-part message in MIME format.
--------------A791307F98A0E9D556F9E80C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I intend to be on the call - I make it as 00:30 on the 18th here in Troy NY.

I don't think I need a presentation slot:

Short status on each:

Eventpub extensions: I believe this is ready

iCalendar series - a new spec providing an alternative to recurring events

Subscription upgrade - slightly modified to point out the benefits to 
mobile devices.

On 11/5/19 10:03, Daniel Migault wrote:
> Hi,
>
> Calext is meeting at the IETF106 13:30-15:30 Monday Afternoon session 
> I. Please let us know if you intend to present and request a 
> presentation slot.
>
> We expect to go through all documents that are in the WG. If you will 
> not be able to present, please provide to the mailing a short status 
> update of the document as well as the next envisioned steps by the end 
> of the year.
>
> Presentations are expected to be uploaded for Friday Nov 15:
> https://datatracker.ietf.org/meeting/106/session/calext
>
>
> IETF106 CALEXT WORKING GROUP AGENDA - Singapore 2019-11-18, 14:30-15:30
>
> * Welcome, Notewell, Bluesheets, Agenda bashing: 5m
> * Current Drafts:
>    * draft-ietf-calext-eventpub-extensions-15
>    * draft-ietf-calext-icalendar-series-00
>    * draft-ietf-calext-jscalendar-21
>    * draft-ietf-calext-jscalendar-icalendar-01
>    * draft-ietf-calext-subscription-upgrade-01
>    * draft-ietf-calext-valarm-extensions-00
> Yours,
> Bron and Daniel
>
>
> -- 
> Daniel Migault
> Ericsson
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

--------------A791307F98A0E9D556F9E80C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I intend to be on the call - I make it as 00:30 on the 18th here
      in Troy NY.

    
I don't think I need a presentation slot:

    
Short status on each:

    
Eventpub extensions: I believe this is ready

    
iCalendar series - a new spec providing an alternative to
      recurring events

    
Subscription upgrade - slightly modified to point out the
      benefits to mobile devices. 

    

    
On 11/5/19 10:03, Daniel Migault wrote:

    

    

      
      
Hi, 

        


        

        
Calext is meeting at the IETF106 13:30-15:30 Monday
          Afternoon session I. Please let us know if you intend to
          present and request a presentation slot. 

        


        

        
We expect to go through all documents that are in the WG.
          If you will not be able to present, please provide to the
          mailing a short status update of the document as well as the
          next envisioned steps by the end of the year. 

        


        

        
Presentations are expected to be uploaded for Friday Nov
          15:

        
        


        

        


        

        
IETF106 CALEXT WORKING GROUP AGENDA - Singapore 2019-11-18, 14:30-15:30



        
* Welcome, Notewell, Bluesheets, Agenda bashing: 5m
* Current Drafts:

        
  * draft-ietf-calext-eventpub-extensions-15 

        
  * draft-ietf-calext-icalendar-series-00 

        
  * draft-ietf-calext-jscalendar-21 

        
  * draft-ietf-calext-jscalendar-icalendar-01 

        
  * draft-ietf-calext-subscription-upgrade-01 

        
  * draft-ietf-calext-valarm-extensions-00 

        
Yours, 

        
Bron and Daniel 

        

        


        

        -- 

        

          

            
Daniel Migault

            

            
Ericsson

          

        

      

      

      

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


    

  


--------------A791307F98A0E9D556F9E80C--


From nobody Tue Nov  5 18:09:55 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 9AFA91202DD for ; Tue,  5 Nov 2019 18:09:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level: 
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 YBukuCzV9Kdc for ; Tue,  5 Nov 2019 18:09:51 -0800 (PST)
Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 B5962120154 for ; Tue,  5 Nov 2019 18:09:51 -0800 (PST)
Received: by mail-vs1-f47.google.com with SMTP id b184so11366840vsc.5 for ; Tue, 05 Nov 2019 18:09:51 -0800 (PST)
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=HoVUrUrdj3kf6r1WS0oqe8I5HPyy5vmfcVzMOEd+nWY=; b=TefcNljDmBNh5sjGme7MybPuQ+rTFV3YyE14/JJZuOzrtlUbhNvmBPHnv5oey1gGhM RRWna31A4G5hvfDN3Y60yxY2Fc25KiB66lcqTRza87MKWBmTV/GZHZ8RYfXfSjUBcppQ UzL72JFSWrBH9SW9e9RgKUEKPAASITGJ9PH5hJnDWUMsUfdf2cAG9koNQgCUHH/sg+Wd TmHRec8zbCqdbJwzf3ua/X4M89qKwgCyPsyyUGVXUdTla4PQHyfaxGCqlUw3Y6QcmVmB ZKVurbkCBsKMS/nK+wwkNoMEZ3l/36wiq5eE0jnRsCWD7ijEZsoVYMkuz9rLGsnJ25XZ Il1g==
X-Gm-Message-State: APjAAAX79Mtq4Rnoy8ZawXuf7vfSeZfc95C0oC9tfOl8deDTf7ZvEXfn ySBGckWZatBoKTvgT3C7EulUHGFol82xDPAzVI/FKAIcLVg=
X-Google-Smtp-Source: APXvYqwGI0hG6Byfvn+aNZRNQSaMyao75GgAZZdykXft+BpJ5C5Z4ejfzFqnh5NbagXOCepgQbYfGFiQEeFI6XsSffY=
X-Received: by 2002:a67:7a8d:: with SMTP id v135mr91536vsc.97.1573006190499; Tue, 05 Nov 2019 18:09:50 -0800 (PST)
MIME-Version: 1.0
From: Daniel Migault 
Date: Tue, 5 Nov 2019 21:09:39 -0500
Message-ID: 
To: IETF-Calsify 
Content-Type: multipart/alternative; boundary="00000000000036db250596a40b7a"
Archived-At: 
Subject: [calsify] WGLC for draft-ietf-calext-icalendar-series
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, 06 Nov 2019 02:09:53 -0000

--00000000000036db250596a40b7a
Content-Type: text/plain; charset="UTF-8"

Hi,

This email starts a WGLC for the
document draft-ietf-calext-icalendar-series [1]. In order to move the
document forward, please review the document and state your opinion or
comments until Tuesday November 19.

Note that given the history of the document, it is important to show the
IESG the document is supported by the WG.

Yours,
Bron and Daniel

[1] https://datatracker.ietf.org/doc/draft-ietf-calext-icalendar-series/

--00000000000036db250596a40b7a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,=C2=
=A0

This email starts a WGLC for the document=C2=A0draft=
-ietf-calext-icalendar-series [1]. In order to move the document forward, p=
lease review the document and state your opinion or comments until Tuesday =
November 19.=C2=A0

Note that given the history of =
the document, it is important to show the IESG the document is supported by=
 the WG.=C2=A0

Yours,=C2=A0
Bron and Dan=
iel



--00000000000036db250596a40b7a--


From nobody Tue Nov  5 18:09: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 44FD3120154 for ; Tue,  5 Nov 2019 18:09:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level: 
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 21zHMMOf68zJ for ; Tue,  5 Nov 2019 18:09:53 -0800 (PST)
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (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 2DA79120236 for ; Tue,  5 Nov 2019 18:09:53 -0800 (PST)
Received: by mail-vs1-f42.google.com with SMTP id k15so14919197vsp.2 for ; Tue, 05 Nov 2019 18:09:53 -0800 (PST)
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=SoOf2ghOxYG7wssj0vKoIu1Zy1cIo64iH4XvE5iv0uY=; b=SUQT08KgPnbWZwCmjg+S+GHxrn8FUxvKgYZYh0y5yRgAZRQ7PgiXmX34ofeyjyo0mF BM5pXmBitpVGUT/P719SFx3wgcIuxhkgocO5C+LE7r+sznWW730cdRJv3BKrNNkoicXf GmmzfcQifOtcuWjHLmiYs5nAWUNgUTy+wDzmu3D965KTVolcVJPrZrz0SlG36R2+WMpT X9PRNc6k3dbHzgY/nS0ES12dUYbbV9w0IXIv1wPSdneUmFBy392mO3/rHcTSa8/MSTNs Lkoc9ujJ1akpexn3cc8IGcpDmqFaJHDVa3uHINN4GsHF7+ABwSn+2yZIfDO1lXLkmAGx BYGg==
X-Gm-Message-State: APjAAAUf/hTQC6xJXUeuP2ha0QFbQ5bAlH2iWGKb8pkeBCUprZ/sJwW/ UUI5jx/wwhFk2MNZYEkoFrct0Mg6YvfliV4zw4Cg/ReSOzQ=
X-Google-Smtp-Source: APXvYqx1gq2ewyaQ7/RN2fNoDTwTi50oOMKfQGDJ4+TIRlV9jcwFoAPVWW6kla+Dh3h6rs3SDHOgf7Eu9gmTF2iK3yY=
X-Received: by 2002:a67:bd05:: with SMTP id y5mr113042vsq.180.1573006192084; Tue, 05 Nov 2019 18:09:52 -0800 (PST)
MIME-Version: 1.0
From: Daniel Migault 
Date: Tue, 5 Nov 2019 21:09:41 -0500
Message-ID: 
To: IETF-Calsify 
Content-Type: multipart/alternative; boundary="0000000000004f0bb80596a40baa"
Archived-At: 
Subject: [calsify] WGLC for draft-ietf-calext-subscription-upgrade
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, 06 Nov 2019 02:09:54 -0000

--0000000000004f0bb80596a40baa
Content-Type: text/plain; charset="UTF-8"

This email starts a WGLC for the
document draft-ietf-calext-subscription-upgrade [1]. In order to move the
document forward, please review the document and state your opinion or
comments until Tuesday November 19.

Note that given the history of the document, it is important to show the
IESG the document is supported by the WG.

Yours,
Bron and Daniel

[1] https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/

--0000000000004f0bb80596a40baa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This email starts a WGLC for the document=C2=A0draft-ietf-cale=
xt-subscription-upgrade [1]. In order to move the document forward, please =
review the document and state your opinion or comments until Tuesday Novemb=
er 19.=C2=A0

Note that given the history of the do=
cument, it is important to show the IESG the document is supported by the W=
G.=C2=A0

Yours,=C2=A0


--0000000000004f0bb80596a40baa--


From nobody Thu Nov  7 14:53:29 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 E890A12085B for ; Thu,  7 Nov 2019 14:53:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level: 
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 sm-ARMtHhUuj for ; Thu,  7 Nov 2019 14:53:26 -0800 (PST)
Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) (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 1C8EC120835 for ; Thu,  7 Nov 2019 14:53:26 -0800 (PST)
Received: by mail-ua1-f48.google.com with SMTP id n41so1147634uae.2 for ; Thu, 07 Nov 2019 14:53:26 -0800 (PST)
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; bh=n1IkVHN+3uXkRevmZe+9/p08u3t5MQmmmBqTzI+BY+o=; b=Bo+v/Is9iIN+97R4OrV0VSBXoLe+Kw6Ehz3OIt+Ees3L4lFcrLHmxhv4ZRHKaAzxWm AxaSK3wl1fYbY6vV19GRAeJQqdh9V6qcg7LgWkHqCUze7nDkNWEfDArIHmRzzOLW4Keu WFPcEUnY6ic+3Vv19BAICSZFQfS0EBKrtbChtEolm/M5N+TuNhgLGvwW29BFmngg4a1G EmIUuPSq4sWYbXzE0LszoTPs7/hzpKBAmgKUjR1qC43sc+QK0mMFOA9KpHZG1DL59eFa p9BHLEVG7T6Z+Ebq4zbND/+TQSUz08SClKi3a3jCGsOmEafkP4MSYeMQsFv93ZJogm0M 0AZw==
X-Gm-Message-State: APjAAAVhui4oe6+b/WZ5rOVo/ZX+bPXsdUf4kUK96fkutFhCpIoJRc8z nrQwIOLVNkqwBIFDhJeftZfK1BlwKl+cSorJdtU=
X-Google-Smtp-Source: APXvYqwL6Dn/9KkuOn2mMZZgfs7S4aj5C5AtWLKKfMKgpI/1srHNYaAPA0NFInNNcLpyuGUT6IwiY8cBLitz6GiXWaY=
X-Received: by 2002:ab0:5ea9:: with SMTP id y41mr4061440uag.114.1573167205184;  Thu, 07 Nov 2019 14:53:25 -0800 (PST)
MIME-Version: 1.0
References:  <6d0fa1f3-5dbe-d4df-821f-a0bddb61546b@gmail.com> <3d216646-0235-0af4-b9ad-1401eea482c4@gmail.com>  <7f83a966-d1e9-464e-acd2-45bb7fd05107@beta.fastmail.com> <98a0f7ca-213d-4be0-9b0c-310dad70c0ab@gmail.com> <595e1efa-97a0-4373-8d5f-d4e5e05a1838@dogfood.fastmail.com> <601a4ef3-d922-71e0-ab4b-8e539ed3f7ae@gmail.com> <669b29a4-1734-4ea1-9ac9-33e590d91762@dogfood.fastmail.com> <07d3a19b-5198-e9fa-acbf-94c5161e11fb@gmail.com> <322a91d4-3246-49df-a1c4-628a59cf5304@dogfood.fastmail.com>   
In-Reply-To: 
From: Daniel Migault 
Date: Thu, 7 Nov 2019 17:53:14 -0500
Message-ID: 
To: Neil Jenkins 
Cc: Michael Douglass , Calsify 
Content-Type: multipart/alternative; boundary="0000000000006ff9350596c988ce"
Archived-At: 
Subject: Re: [calsify] WGLC JSCalendar
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, 07 Nov 2019 22:53:28 -0000

--0000000000006ff9350596c988ce
Content-Type: text/plain; charset="UTF-8"

Please find the draft for the writer shepherd.
https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/shepherdwriteup/

I invite you to have a look and eventually raise any issue you find. In
particular, it would be good to report your implementation if not
mentioned.
Yours,
Daniel

On Sun, Nov 3, 2019 at 6:32 PM Neil Jenkins  wrote:

> On Mon, 4 Nov 2019, at 08:40, Daniel Migault wrote:
>
> 1) IPR
> Could each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed.
>
>
> Confirmed from me.
>
> 3) URIs section.
>
> This is clearly a detail, but I am not sure the URIs section is actually
> standard. I expect that we will be asked to move it to Informative section.
>
>
> These should probably all be Normative References actually, looking at
> where they are being referenced from. I'll fix that.
>
> Neil.
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify
>

--0000000000006ff9350596c988ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Please find the draft for the writer shepherd.=C2=A0
<=
a href=3D"https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/she=
pherdwriteup/">https://datatracker.ietf.org/doc/draft-ietf-calext-jscalenda=
r/shepherdwriteup/

I invite you to have a =
look and eventually raise any issue you find. In particular, it would be go=
od to report your implementation if not mentioned.=C2=A0
Yours,=
=C2=A0
Daniel

On Sun, Nov 3, 2019 at 6:32 PM Neil Jenkins <neilj@fastmailteam.com> wrote:<=
br>
On Mon, 4 Nov 2019, at 08:40, Daniel Migault wrote:
1)=
 IPR
Could each author confirmed that any and all approp=
riate IPR
disclosures required for full conformance with the =
provisions of BCP 78
and BCP 79 have already been filed.
<=
/div>

Confirmed from me.

3) URIs section.

=
This is clearly a detail, but I am not sure the URIs section is actually st=
andard. I expect that we will be asked to move it to Informative section.=
=C2=A0

These should probabl=
y all be Normative References actually, looking at where they are being ref=
erenced from. I'll fix that.

Neil.
_______________________________________________

calsify mailing list

calsify@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/calsify




--0000000000006ff9350596c988ce--


From nobody Fri Nov 15 09:43:31 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 C95BB12092D for ; Fri, 15 Nov 2019 09:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.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, 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=fastmail.com header.b=MhY9e0TC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NMfp8g3X
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 Gf4dKUy0DoYX for ; Fri, 15 Nov 2019 09:43:28 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2B4120921 for ; Fri, 15 Nov 2019 09:43:28 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B540A21249 for ; Fri, 15 Nov 2019 12:43:27 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 15 Nov 2019 12:43:27 -0500
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=fm1; bh=zbpodBY2N0SRv19G56a0xm0UTEk tF46ToIGKA9vtIqs=; b=MhY9e0TCCLbMvEO0D7zKykIZtkb2vuLHtiqemYyFmRh jzlXbHNYeHWT1PTgFQaP+SKuicVSOZ7/IqXKvBcJ81cP80+t9Fbj4qTQJYwhleU0 ThBXVqM3gGchvsOKwMoj+EEUpYex2ZxWiPhQ3q4ELrBJRjU7v7b/HULTyjoYcl7I gHxHuzLMj9Mxd05pk7SExo3H9nxRkr53HeMAyqyBE4q0YmviTZXhhB3BbJGgF21p DD8ghGYgZETJcwvampAizbQxCR+f3KQZO1C0noyIFXED+9VRTGLA34ofC4iYpxTb HTdkba1OGYgywVEEF6S/yk6O+ltQVFdhVTt9GN0cwhw==
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=fm1; bh=zbpodB Y2N0SRv19G56a0xm0UTEktF46ToIGKA9vtIqs=; b=NMfp8g3XV1gZDGWY82BVml eo0FtvsZcFFV9Fotk/+ZSDTqrWSiDRHgOrAvbDV4DpB0EEWfHjligbIScU+XPfTW ckGfHowut2PRlJYVL033UVIrBKbKVnTj3cTpMJOmWxCRYiXZUs2VIvHiRqYItkwV hdl5SXtapGw/4289zXC2dr3b4hUeWK8kmoizmYGIxVKkEWjGfrecgdt+yc4/+kd5 BTImqzEZz3rXUNafD+a8s4L6JyX3SVqp9BoBED3CV7sXsIPiv+tNxjzY6z5owQjK GqPLichEu29FfIzdR/dRQlh470vr32W87RllblWCdxMXAKp9P3eH8ezuJsfTbGAg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudefhedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhohfkffgfgggjtgesrg 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 5AEA53060057 for ; Fri, 15 Nov 2019 12:43:27 -0500 (EST)
To: calsify@ietf.org
References: 
From: Ken Murchison 
Organization: FastMail US LLC
Message-ID: <619b9893-fa1c-4520-77cf-8879d0b5fc51@fastmail.com>
Date: Fri, 15 Nov 2019 12:43:26 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A269C0F209D8FC4ECFDD3D7B"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Calext @IETF
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, 15 Nov 2019 17:43:31 -0000

This is a multi-part message in MIME format.
--------------A269C0F209D8FC4ECFDD3D7B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Daniel,

Sorry for the late response, I thought I had responded immediately, but 
apparently I did not.

Unfortunately, I haven't had time to update the VALARM extensions 
draft.  I have no slides for the meeting.  My plan, as discussed during 
the interim, is to add back in the RELATED-TO property for VALARMS, and 
to add security considerations for the use or proximity triggers in VALARMs.


On 11/5/19 10:03 AM, Daniel Migault wrote:
> Hi,
>
> Calext is meeting at the IETF106 13:30-15:30 Monday Afternoon session 
> I. Please let us know if you intend to present and request a 
> presentation slot.
>
> We expect to go through all documents that are in the WG. If you will 
> not be able to present, please provide to the mailing a short status 
> update of the document as well as the next envisioned steps by the end 
> of the year.
>
> Presentations are expected to be uploaded for Friday Nov 15:
> https://datatracker.ietf.org/meeting/106/session/calext
>
>
> IETF106 CALEXT WORKING GROUP AGENDA - Singapore 2019-11-18, 14:30-15:30
>
> * Welcome, Notewell, Bluesheets, Agenda bashing: 5m
> * Current Drafts:
>    * draft-ietf-calext-eventpub-extensions-15
>    * draft-ietf-calext-icalendar-series-00
>    * draft-ietf-calext-jscalendar-21
>    * draft-ietf-calext-jscalendar-icalendar-01
>    * draft-ietf-calext-subscription-upgrade-01
>    * draft-ietf-calext-valarm-extensions-00
> Yours,
> Bron and Daniel
>
>
> -- 
> Daniel Migault
> Ericsson
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC


--------------A269C0F209D8FC4ECFDD3D7B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Daniel,

    
Sorry for the late response, I thought I had responded
      immediately, but apparently I did not.

    
Unfortunately, I haven't had time to update the VALARM extensions
      draft.  I have no slides for the meeting.  My plan, as discussed
      during the interim, is to add back in the RELATED-TO property for
      VALARMS, and to add security considerations for the use or
      proximity triggers in VALARMs.

    

    


    

    
On 11/5/19 10:03 AM, Daniel Migault
      wrote:

    

    

      
      
Hi, 

        


        

        
Calext is meeting at the IETF106 13:30-15:30 Monday
          Afternoon session I. Please let us know if you intend to
          present and request a presentation slot. 

        


        

        
We expect to go through all documents that are in the WG.
          If you will not be able to present, please provide to the
          mailing a short status update of the document as well as the
          next envisioned steps by the end of the year. 

        


        

        
Presentations are expected to be uploaded for Friday Nov
          15:

        
        


        

        


        

        
IETF106 CALEXT WORKING GROUP AGENDA - Singapore 2019-11-18, 14:30-15:30



        
* Welcome, Notewell, Bluesheets, Agenda bashing: 5m
* Current Drafts:

        
  * draft-ietf-calext-eventpub-extensions-15 

        
  * draft-ietf-calext-icalendar-series-00 

        
  * draft-ietf-calext-jscalendar-21 

        
  * draft-ietf-calext-jscalendar-icalendar-01 

        
  * draft-ietf-calext-subscription-upgrade-01 

        
  * draft-ietf-calext-valarm-extensions-00 

        
Yours, 

        
Bron and Daniel 

        

        


        

        -- 

        

          

            
Daniel Migault

            

            
Ericsson

          

        

      

      

      

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


    

    
-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

  


--------------A269C0F209D8FC4ECFDD3D7B--


From nobody Mon Nov 18 00:51: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 1764F120104 for ; Mon, 18 Nov 2019 00:51:00 -0800 (PST)
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=wnVq7PsR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TfLi22Ut
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 EdNkMh_-uYkv for ; Mon, 18 Nov 2019 00:50:57 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0BA1200C3 for ; Mon, 18 Nov 2019 00:50:56 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5B4842244E for ; Mon, 18 Nov 2019 03:50:56 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Mon, 18 Nov 2019 03:50:56 -0500
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=fm1; bh=iz3IqfCQIvzZ1bTpXgJC8Xn13JI4dP4uPTpI7wN kO1o=; b=wnVq7PsRFAtp14BRAkp1Ls5Uv/2PF0j6o3qepEobcv1decl1nLUQW7r bZDB/hjfPPTbApvM8wlIv8bQBhfbDUneSzCgRFb/SGa04cXHwnKEdwukIqPQNalx a1NG45ra5CqdvwoBtdymMgJlzmxBRoeOCBux5FIFwZz3QPmYQUYBmo42O1TZM0Pa hDwNpotoFAoC6sJLwaQ76jMJaF4lCqS/lSIDgaErBXXwagRx6by844T4fzjA0sW2 XlkiUwavhlXPb+IM6JCPIfTrxeZ4oOijXBUe8ub0TbFAqqE2739svK1CE5wR1gJR VGETY6uQh0sbK3UpOalzWT1KcR08/fg==
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=fm1; bh=iz3IqfCQIvzZ1bTpXgJC8Xn13JI4d P4uPTpI7wNkO1o=; b=TfLi22Ut+nkhUo9YyDb4XPa7bhfIiqJLpDo0hyufEvNMr tn4oLfW7iE46bFBWFYad5DlfQTbmv5A4Md5MsbXYxKuRCr8IAfzLzNjrCvxHxWkx hnH4hkbTzAwkEiQ6m3Fuq/W8r7Xs1nbMLj57bJQw7cjQNqekEifHCpJAV4BMIIN4 HIe1JeDbaXnKQQ3gYtTC4eS1BaW6+xaaTYxKHlOXFi4jyLPerGQgLXPCGsb9C2Nn JA0XuW6nUlUud3W2M1me5T5Aufy/G5g6v4dOHW1eJsnM+/DcZ1BZB1yXafBdu4Il sFma68oZWZMsN8G6L+GXOpcqsBWM3pqnh6cRt52+w==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeggedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrh honhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 14275323CAD; Mon, 18 Nov 2019 03:50:56 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1
Mime-Version: 1.0
Message-Id: 
Date: Mon, 18 Nov 2019 19:50:52 +1100
From: "Bron Gondwana" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=ea5e04189eef4e1d9e10df5fee847ce3
Archived-At: 
Subject: [calsify] Minutes from today'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, 18 Nov 2019 08:51:00 -0000

--ea5e04189eef4e1d9e10df5fee847ce3
Content-Type: text/plain

Hi all, I've uploaded the minutes from today's meeting to the datatracker. I reproduce them below as well. Please note any action points at the top of this document and get on those!

Thanks,

Bron.

IETF106 CALEXT WORKING GROUP - Singapore 2019-11-18, 13:30-14:30

= AGENDA

Welcome, Notewell, Bluesheets, Agenda bashing: 5m
Current Drafts:
* eventpub: 5m
* jscalendar & interop doc: 10m
* subscription upgrade: 5m
* valarm extensions: 5m
* series: 10m
Proposed Drafts:
* vpoll: 10m
Milestone Review: 5m
Any other business: 5m

= ACTIONS*
*
*
*
*Bron:**
*
** Update milestones**
*
*
*
*Daniel:**
*
** talk to IANA this week about jscalendar registrations**
*
*
*
*Neil:**
*
** change jscalendar to have recurrenceRules**
*
*
*
*Mike:**
*
** update EVENTPUB to have initial data copied into event and URLs just for refreshing**
*
** define CALDAV better in subscription upgrade**
*
** keep working with Ken on VPOLL**
*
*
*
*Ken:**
*
** add geopriv text and documentation to VALARM**
*
** keep working with Mike on VPOLL*

= DETAILED NOTES

The meeting started with significant technical difficulties with both Ken Murchison and Mike Douglass having trouble getting reliable sound.

Meetecho suggests that Safari is only recently supported, and using Firefox or Chrome would be a better choice.

There was no agenda bashing.

== Eventpub

Barry:
* Clients often follow URIs
* This draft adds tons more URIs in places where it's common to dereference
* Would prefer to remove URIs entirely where not necessary
* In the alternative, strongly advise against their use and insist that the user be prompted before loading them.

Mike:
* URIs already exist in lots of places.
* Don't feel that eventpub is the right place to solve this, we should build a BCP.
* ICALENDAR already has the URI field

Barry:
* Agree this isn't the best place, but might need to block until we have BCP

Mike:
* Don't want to block, but happy to add strong text and commit to building BCP and have the eventpub doc reference "look for BCP when it arrives".

Neil:
* Main problem is the HTML description, because that will be loaded before display.

Mike:
* use case is thinks like "VCARD contains user info, look there rather than copying into the event".
* URI will point to the up-to-date version.

Neil:
* Generally - URIs should be a way to look up more detail or refresh, but initial information should be embedded in the event so it's useful without following URIs.
* Also means that the data won't change under you or disappear (Barry: or have malware put in place) so the event is self contained. (e.g. domain expires)
* That way, can prompt user to follow URIs for updated without hurting usability if they don't.

Daniel:
* Agree from a privacy standpoint - event shouldn't need to follow URIs to be usable.

ACTION: Mike to update draft to have initial data copied into the event and the URIs be a way to get updated data.

== JSCalendar

Neil:
* has been in last call for a while now
* good feedback received and has been included
* registries have been created

Daniel:
* have sent registries to IANA for review, will follow up with them

Neil:
* haven't done any work on translation doc for icalendar/jscalendar. Will get back to that once jscalendar is final.

Mike:
* I still want multiple RRULE support - the removal in 5545 was a mistake IMHO
* most clients will support it, because ical4j does, and most use it
* have customers with events that they need many of because a single RRULE can't describe the event
* event publishers need complexity even if average client creating a simple event doesn't

Neil:
* Not much support - clients won't set it
* Potential issue with server data model when pulling in ICS feeds and losing the recurrence.
* But: willing to put it in (change recurrenceRule to recurrenceRules and make it an array) even if just about everyone only does one value

ACTION: Daniel to talk with IANA this week while they're colocated.
ACTION: Neil to change recurrenceRule(s) and take it back to the list

== Subscription upgrade

Bron:
* Question about recurrences - does ANY mention of the UID invalidate all items with that UID.
- e.g. does sending UID METHOD:DELETED for just the UID delete all the recurrences as well?
* I argue yes, since we're mapping over CALDAV which stores all the records for a UID in a single file.
* Important to be clear on this, as otherwise clients could wind up with stale recurrences which were no longer mentioned on the server.

Neil:
* the draft has both GET extensions and references to auth and non-auth caldav, is that excessive?
* if we keep the caldav stuff, it needs to reference the RFCs and be better specified.

Mike:
* GET is useful for simple clients, but if CALDAV is also available, it's more powerful.
* would like to keep both
* will improve the text to reference RFCs and etc
* biggest gain is mobile clients

ACTION: Mike to define CALDAV details better and new draft will be discussed on the list

== VALARM extensions

Daniel:
* geopriv chairs advised us to send questions to mailing list
* expect it might be hard to find traction
* there is a geopriv framework, we should reference it and follow the recommendations
* on the flip side, if we do nothing people will just use GPS, and mostly this data is being stored to the same service where GPS data is also sent for maps, etc!

Alexey:
* the right thing is to state your assumptions in the draft, e.g
 - we know geopriv data is in here, but we assume it's going to a service which already gets the GEO data anyway
 - add limitations/risks and security section detailing how to be careful with the data
* this should help it progress

ACTION: Ken will add geopriv text and documentation of assumptions

== SERIES

Mike:
* background - orgs produce long running events where every recurrence is an override, which is very inefficient
* this is a different model which treats each as a separate event and links using relations back to a master event

Neil:
* idea is good, but the draft needs lots of work - shouldn't be in last call!

Mike:
* agree, that was a misunderstanding

Neil:
* needs details on WHO generates the separate events and when
* series master is not a member of the series -> how will that work with non-aware clients?
 - suggestion of different top-level type? What will clients do.
 - METHOD:SERIESMASTER?
 - BEGIN:VEVENTSERIESMASTER?
 - will clients ignore it? or crash? needs research

Daniel:
* how does this compare to RRULE?

Mike/Neil:
* it's for different situations - both are useful for different things
* RRULE good for "same thing happens every so often"

ACTION: discuss on list

== VPOLL

Mike:
* nearly finished convering to PARTICIPANT
* problem is document structure - should there be separate documents for different modes?

ACTION: Mike and Ken to continue iterating and discuss on list

== Milestones

* jscalendar - Dec 2019
* eventput - sent to IESG! TICK
* valarm - Dec 2019
* vpoll - Apr 2020
* series - Jun 2020


== Other business

tzdist:
* This was a private chat with Daniel which didn't happen on mic - but the conclusion was "let's do the same as with VALARM and document assumptions but keep progressing".
* goal: get IANA or similar to run a public canonical tzdist server

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


--ea5e04189eef4e1d9e10df5fee847ce3
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


Hi all, I've uploaded the minutes from today's meeting to =
the datatracker.  I reproduce them below as well.  Please note=
 any action points at the top of this document and get on those!

Thanks,

Bron.

IETF106 CALEXT WORKING GROUP - Singa=
pore 2019-11-18, 13:30-14:30
=

=3D AGENDA

We=
lcome, Notewell, Bluesheets, Agenda bashing: 5m
Current Drafts:
* eventpub: 5m
* jscale=
ndar & interop doc:  10m
* subscription upgrade: 5m
* valarm extensions: 5m
* =
series: 10m
Proposed Drafts:<=
br>
* vpoll: 10m
Milestone Review: 5m
Any other business: 5m

=3D ACTIONS<=
br>

Bron:
* Update milestones

=
Daniel:
* ta=
lk to IANA this week about jscalendar registrations
=


Neil:
* change jscalendar to have recurrenceRules
<=
div style=3D"font-family:Arial;">
Mike:
* update EVENTPUB to have initial data copied into event and URLs =
just for refreshing
* define CALDAV better in subscription upgrade
=

* keep working with Ken on VPOLL

Ken:
* add geopriv text and documentation to VALARM
* keep working w=
ith Mike on VPOLL

=3D DETAILED NOTES

T=
he meeting started with significant technical difficulties with both Ken=
 Murchison and Mike Douglass having trouble getting reliable sound.
<=
/div>

Meetecho suggests that Safari is only recently supported, and=
 using Firefox or Chrome would be a better choice.

There w=
as no agenda bashing.

=3D=3D Eventpub

Barr=
y:
* Clients often follow URI=
s
* This draft adds tons more=
 URIs in places where it's common to dereference
* Would prefer to remove URIs entirely where not nec=
essary
* In the alternative, =
strongly advise against their use and insist that the user be prompted b=
efore loading them.

Mike:
* URIs already exist in lots of places.
* Don't feel that eventpub is the right place to so=
lve this, we should build a BCP.
* ICALENDAR already has the URI field

Barry:
* Agree this isn't the best place, bu=
t might need to block until we have BCP

Mike:
* Don't want to block, but happy to add =
strong text and commit to building BCP and have the eventpub doc referen=
ce "look for BCP when it arrives".

Neil:
* Main problem is the HTML description, becau=
se that will be loaded before display.

Mike:
* use case is thinks like "VCARD contains=
 user info, look there rather than copying into the event".
* URI will point to the up-to-date versio=
n.

Neil:
* Gen=
erally - URIs should be a way to look up more detail or refresh, but ini=
tial information should be embedded in the event so it's useful without =
following URIs.
* Also means =
that the data won't change under you or disappear (Barry: or have malwar=
e put in place) so the event is self contained. (e.g. domain expires)
* That way, can prompt user to =
follow URIs for updated without hurting usability if they don't.

Daniel:
* Agree from =
a privacy standpoint - event shouldn't need to follow URIs to be usable.=


ACTION: Mike to update draft to have initial data copied=
 into the event and the URIs be a way to get updated data.

=3D=3D JSCalendar

Neil:
* has been in last call for a while now
* good feedback received and has been included
<=
/div>
* registries have been created

Daniel:
* have s=
ent registries to IANA for review, will follow up with them

Neil:
* haven't done any w=
ork on translation doc for icalendar/jscalendar.  Will get back to =
that once jscalendar is final.

Mike:
* I still want multiple RRULE support - the removal=
 in 5545 was a mistake IMHO
*=
 most clients will support it, because ical4j does, and most use it
<=
/div>
* have customers with events that=
 they need many of because a single RRULE can't describe the event
* event publishers need complexity=
 even if average client creating a simple event doesn't

N=
eil:
* Not much support - cli=
ents won't set it
* Potential=
 issue with server data model when pulling in ICS feeds and losing the r=
ecurrence.
* But: willing to =
put it in (change recurrenceRule to recurrenceRules and make it an array=
) even if just about everyone only does one value

ACTION:=
 Daniel to talk with IANA this week while they're colocated.
ACTION: Neil to change recurrenceRule(s)=
 and take it back to the list

=3D=3D Subscription upgrade=


Bron:
* Quest=
ion about recurrences - does ANY mention of the UID invalidate all items=
 with that UID.
- e.g. does s=
ending UID METHOD:DELETED for just the UID delete all the recurrences as=
 well?
* I argue yes, since w=
e're mapping over CALDAV which stores all the records for a UID in a sin=
gle file.
* Important to be c=
lear on this, as otherwise clients could wind up with stale recurrences =
which were no longer mentioned on the server.

Neil:
* the draft has both GET extension=
s and references to auth and non-auth caldav, is that excessive?
* if we keep the caldav stuff, it ne=
eds to reference the RFCs and be better specified.

Mike:
* GET is useful for simple cli=
ents, but if CALDAV is also available, it's more powerful.
* would like to keep both
* will improve the text to reference RFCs and=
 etc
* biggest gain is mobile=
 clients

ACTION: Mike to define CALDAV details better and=
 new draft will be discussed on the list

=3D=3D VALARM ex=
tensions

Daniel:
* geopriv chairs advised us to send questions to mailing list
* expect it might be hard to find tr=
action
* there is a geopriv f=
ramework, we should reference it and follow the recommendations
* on the flip side, if we do nothing =
people will just use GPS, and mostly this data is being stored to the sa=
me service where GPS data is also sent for maps, etc!

Ale=
xey:
* the right thing is to =
state your assumptions in the draft, e.g
  - we know geopriv data is in here, but we assume it's=
 going to a service which already gets the GEO data anyway
  - add limitations/risks and securit=
y section detailing how to be careful with the data
* this should help it progress

ACTION:=
 Ken will add geopriv text and documentation of assumptions

=3D=3D SERIES

Mike:
* background - orgs produce long running events where every rec=
urrence is an override, which is very inefficient
* this is a different model which treats each as a =
separate event and links using relations back to a master event

Neil:
* idea is good, =
but the draft needs lots of work - shouldn't be in last call!
<=
div style=3D"font-family:Arial;">
Mike:
* agree, that was =
a misunderstanding

=

Neil:
* needs details on WHO generates the separate events and when=

* series master is not a mem=
ber of the series -> how will that work with non-aware clients?
  - suggestion of different t=
op-level type?  What will clients do.
  - METHOD:SERIESMASTER?
  - BEGIN:VEVENTSERIESMASTER?
  - will clients ignore it? or crash? needs re=
search

Daniel:
=
* how does this compare to RRULE?

Mike/Neil:
* it's for different situations - both ar=
e useful for different things
* RRULE good for "same thing happens every so often"

ACT=
ION: discuss on list

=3D=3D VPOLL

Mike:
* nearly finished convering to =
PARTICIPANT
* problem is docu=
ment structure - should there be separate documents for different modes?=


ACTION: Mike and Ken to continue iterating and discuss o=
n list

=3D=3D Milestones

* jscalendar - Dec=
 2019
* eventput - sent to IE=
SG!  TICK
* valarm - Dec=
 2019
* vpoll - Apr 2020
<=
/div>
* series - Jun 2020


=3D=3D Other business
<=
/div>

tzdist:
* This was=
 a private chat with Daniel which didn't happen on mic - but the conclus=
ion was "let's do the same as with VALARM and document assumptions but k=
eep progressing".
* goal: get=
 IANA or similar to run a public canonical tzdist server

--
  Bron Gondwana=
, CEO, Fastmail Pty Ltd
  brong@f=
astmailteam.com



--ea5e04189eef4e1d9e10df5fee847ce3--


From nobody Mon Nov 18 01:59: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 1F3B312008D for ; Mon, 18 Nov 2019 01:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 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_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=FHQkWUc2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PHFs7Hd+
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 64VzlYBHC-Aj for ; Mon, 18 Nov 2019 01:59:54 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF0D120043 for ; Mon, 18 Nov 2019 01:59:54 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 5B0BC637 for ; Mon, 18 Nov 2019 04:59:54 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Mon, 18 Nov 2019 04:59:54 -0500
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=fm1; bh=UI4RAmP 8jqw0zcXUh4qEA4tgxCEjiNX5rXEvBxU/e40=; b=FHQkWUc2qByyZzjDQ0Z1X/4 K6ZE48e7HGUq5Qt1IQ3ZPwYAVBZ7RTLKyLycMEqQnJFZfZG4VjM1btH0lQ2gwlje X7q92RkRHfHK48MJQKGYtZ1ZsdK3tNiW58TFjwSo5NCXMocZAPt6jN9gYkN29FTM CktP5Jnv27CFB/j8U9AzyHMj9UOY9/lCr2KJ1yaNL+RYq8PvkMLxktquw9apgq7U g0uuW00nmCWENtarJlT2oNvRhp1Ax/hDY/2limrHag1618bwNWI5eZZEPNbFd9tV 3RVRzzOi09PhH4pXH753Zhr5jgGtULwVXQSZORtzWBNmC7aKe4hzVP9GEtLAr/A= =
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=fm1; bh=UI4RAm P8jqw0zcXUh4qEA4tgxCEjiNX5rXEvBxU/e40=; b=PHFs7Hd+VhXeZyKnIgVld0 0xDCtzUo06WS/vOTLao/lMMXdtoejKicE5Dic4w2CvfYFWPvkr3fE16DO7P1TtYq 07x735DeiHL+zciTB914miZraNXoVm4o5SH/85/BSGlkhcTX/OsyBs6q4ZCYC7gR GlbGn72FynsSviK8jtXJmsJhshz2qJ1UX6Zzs0XgKsu7SZKJZmDngXR3iCNsaTtP c0Y19zdJutcwRhp70UsRDFYTcbHmzeoCGm8qh2zuAVyb3rZIc/qu3YdJDwbofYCi 0OnRg4F/MPRpMq0TY5GCmz7bsL+jfqHqweqnfR8dpnlAhxWfHZejwikKSftCiJsA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeghedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 91C6E324B95; Mon, 18 Nov 2019 04:59:53 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References: 
Date: Mon, 18 Nov 2019 17:59:33 +0800
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [calsify] WGLC for draft-ietf-calext-icalendar-series
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, 18 Nov 2019 09:59:56 -0000

My notes and queries after reading this through:

> These LINK headers will be delivered when a client carries out a HEAD
> request targeting the URL of the resource.

Is there a reason this isn't added in response to the GET request as
well? If the client is hoping to use CalDAV then it makes sense to do
the HEAD first, but if it only supports the "enhanced get" it'll need to
do the GET next anyway regardless of the response and so it would save
you a request.

> by specifying the Prefer header field preference "limit=n" where n is
> the number of components.

If you want to specify "limit=n" as well as "subscribe-enhanced-get",
it's unclear to me whether that's two Prefer header fields or one (e.g.
comma separated). I'd guess two (since it's not specified), but use of
the definite article "the Prefer header field" implies maybe not. This
needs to be clarified, and an example would be very welcome.

> 5.  Header Field: Sync-Token
>   The value MUST be a URI.

Why is this a URI? It's unclear to me the purpose of that, especially
given the spec says:

> Client MUST not attempt to interpret the data URI value.

Shouldn't this just be an opaque string?

> 7.  Link relations

As discussed in the meeting today, this needs more fleshing out and some spec references.

>  The following preferences have been added to the HTTP Preferences
>   Registry defined in [RFC7240]
>
>   Preference
>    subscribe-enhanced-get

We'll need to check with the HTTP folks whether this is considered
appropriate use of the Prefer header. There's already the
"return=minimal" Prefer option registered, which maybe we could use? If
registering a new one, given how tied this is to calendaring and
iCalendar the name probably shouldn't be quite so generic.

> 9.3.  Link Relation Registrations
>
>   This document defines the following new iCalendar properties to be
>   added to the registry defined in section=8.2.3 [RFC5545]:

I am very confused by this; why is anything being added to the iCalendar
property registry? How are these meant to be used as iCalendar
properties?

Neil.


From nobody Mon Nov 18 04:13: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 20AC91208E5 for ; Mon, 18 Nov 2019 04:13:58 -0800 (PST)
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=CEFPLYdP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cXIEqio4
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 2A03X4VUBrzh for ; Mon, 18 Nov 2019 04:13:56 -0800 (PST)
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 CF8391200EB for ; Mon, 18 Nov 2019 04:13:56 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C38322266D for ; Mon, 18 Nov 2019 07:13:55 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Mon, 18 Nov 2019 07:13:55 -0500
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=fm1; bh=XDcr3Eu 2jiXwaLrN2o9z84fzuC9UzVtr64yaTgRxT+c=; b=CEFPLYdP/DhAJ6NEzhoIra4 Kl+Q/FD/Fe0Xt3cCCxT8hdqsv12HYxrVFBlwPFIgva8Cy43RqxP325Bwva4sICaT MWG+RgPRyFqGwG+umQHrVo87tgXw2P/okMZkqyGFh+D94CcF3wFyHNe+4Jn2vmbx S+6dgb0GEujbqlvyGQhiUozzr/W6ezSJTZ2c6L4HbAe/zY0MU6WpXldSHg161dlz Xo4GP2FfnYDNDp0Rs9q3wZyDSuOzkeqMMIC3Hd3Z0VkqOW65v0Yk/op9ehkkUUfo L3DPQNk4dx4Ec7ie97LBKFkPJ6fTwnOndCqKPIMOa6tQrcCrbGGmWrm624kcMOA= =
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=fm1; bh=XDcr3E u2jiXwaLrN2o9z84fzuC9UzVtr64yaTgRxT+c=; b=cXIEqio4wypJyri62BdWwx u+iLCfaCsckS0EjoOpl24gjWx8qcQd0ndxDWDVIv8RBFshkfGAC4e4fflJCgcOy4 wPp6x7o75wqs62fmmnZLUMmEcCzY2drrlIrZrdWlHHvhXypoYgrfzkxh03rOBck7 tLXNGx79DygDOUMSceHwejHdvXjX8uY6QABoO1Ag06uWQ8ErCrAKeLCm46z343mr z1KYJ+OxgMXsWpdjnsHybQYbwlTDSDJLPH/qezuc5qE2du/gRc6o75ToBRHXk7WT sLcH2Yox0unWxOE/hhnK1hNX5lNMwfHGD3CN/g4g9/aQs00gt/r34TfcJgos9Otw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegiedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 510F9326D5C; Mon, 18 Nov 2019 07:13:55 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1
Mime-Version: 1.0
Message-Id: <906c0722-ba19-44d9-ad09-b2a97ec4a2b6@dogfood.fastmail.com>
In-Reply-To: 
References:  
Date: Mon, 18 Nov 2019 20:13:35 +0800
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=4e640b6dce0b4ea2b3e394f329fd22d5
Archived-At: 
Subject: Re: [calsify] WGLC for draft-ietf-calext-icalendar-series
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, 18 Nov 2019 12:13:58 -0000

--4e640b6dce0b4ea2b3e394f329fd22d5
Content-Type: text/plain

Damn, got my threads mixed up. The above reply was of course meant to be about draft-ietf-calext-subscription-upgrade.
--4e640b6dce0b4ea2b3e394f329fd22d5
Content-Type: text/html


Damn, got my threads mixed up. The above reply was of course meant to be about draft-ietf-calext-subscription-upgrade.

--4e640b6dce0b4ea2b3e394f329fd22d5--


From nobody Mon Nov 18 04:14: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 A64FD1208E5 for ; Mon, 18 Nov 2019 04:14:30 -0800 (PST)
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=mZPzkiN1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Mt3wny4/
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 uw35b2TeaBHQ for ; Mon, 18 Nov 2019 04:14:28 -0800 (PST)
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 9E2151200EB for ; Mon, 18 Nov 2019 04:14:28 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ADAFC22670 for ; Mon, 18 Nov 2019 07:14:27 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Mon, 18 Nov 2019 07:14:27 -0500
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=fm1; bh=Nrm0ke1buTWlENmH1TkfDy79PhnbgkCkd+bX33t CJi0=; b=mZPzkiN17cejTbzq2kWRgImnpoBoDsz2Mbpt7oB/kGzcD28K2TlvKLy AgFyQjLlfUZHyhMGX8ViLmawU3yNbh9/9vt8H59VAYfWm2GHhR53dbag6QwRWGdT n6EUxH5Gg9dsPTRY15DyyFNutQUNADK6H3uavar0HPA/vk8aPgrPYwsmmzhKKi3/ ep/wiN2zWJv2OgHl7gcGXwGOkSADLWJvyJ9fqvSeZl/OMyPTx5CbhyETgeqSaoWU TsDElXaI5An1YODg3RtFinqWrBuDunjYr2H9DBYwOncgl3dPWLCAlZ8PB56Vr9Iw AuN/klQ++IX1Ds/GmyqBfJIpMqPXlUw==
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=fm1; bh=Nrm0ke1buTWlENmH1TkfDy79Phnbg kCkd+bX33tCJi0=; b=Mt3wny4/nBn3uNnziPf2OZBaaheAYtMJIQe5aa3udWFwb W6qw1KtepPyunfzl1v//2U10XSHRgbHyEcJG8wFVGuVCebeBO/5GtpAJIQlSKaoU xOmQ+3Gg3lGdnlC5l8dW8E8Ne3qSxvDcCoDrCT80TX3ehBXUXV91uipFHFadIaf1 fVhES0k0qclrRKQMlf3GTuXrQeoL64c7TRWzZR2643x+O92VjaC93wvxmLlHzj2A WxOR/nabW7+Tn+d06AJ1oYfZ+tI0NL95TxEdR+N1wR3cF2qbHDEsrlIaqQL7xhlS KDVFegRSlLNj3DIrDQLBi1ywIjP3wXoxG6BPHjtJw==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegiedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghs thhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilh hjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7BEC6326DD7; Mon, 18 Nov 2019 07:14:27 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1
Mime-Version: 1.0
Message-Id: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com>
Date: Mon, 18 Nov 2019 20:14:07 +0800
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=4fd9938585bb46ea8542e5801f98db46
Archived-At: 
Subject: [calsify] Feedback on draft-ietf-calext-icalendar-series
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, 18 Nov 2019 12:14:31 -0000

--4fd9938585bb46ea8542e5801f98db46
Content-Type: text/plain

I think this concept is good, but this spec needs a fair bit more work (as noted in the meeting today, this should have been a call for adoption, not WGLC!)

The "series master" is a kind of template; it's not an event itself, it just generates them. It might make more sense therefore to make this a different component, e.g. `VEVENTTEMPLATE`. Clients that don't support the spec should simply ignore them, which is what we want. We can also then reuse standard RRULE etc. properties and don't need to define separate SRULE etc. properties.

I think we should mandate that the server manages generating the instances; that's going to be by far the most useful option and we can clearly define when this should happen in the spec. Changing the template (series master) should not change any generated event that's now in the past; the question is what to do about those in the future. It probably depends on what the change is (what if you change the template SUMMARY? What about adding an RDATE? What about changing the RRULE? Have iTIP messages already been sent out inviting people to the event?). More thought needed here I think.

I was very unclear how the "SPLIT" thing was meant to work in the spec, which is related to the above; I would be interested to know more about what Mike's proposing here.

Neil.
--4fd9938585bb46ea8542e5801f98db46
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


I think th=
is concept is good, but this spec needs a fair bit more work (as noted i=
n the meeting today, this should have been a call for adoption, not WGLC=
!)

The "series master" is a kind=
 of template; it's not an event itself, it just generates them. It might=
 make more sense therefore to make this a different component, e.g. VEV=
ENTTEMPLATE. Clients that don't support the spec should simp=
ly ignore them, which is what we want. We can also then reuse standard R=
RULE etc. properties and don't need to define separate SRULE etc. proper=
ties.

I think we should mandate =
that the server manages generating the instances; that's going to be by =
far the most useful option and we can clearly define when this should ha=
ppen in the spec. Changing the template (series master) should not chang=
e any generated event that's now in the past; the question is what to do=
 about those in the future. It probably depends on what the change is (w=
hat if you change the template SUMMARY? What about adding an RDATE? What=
 about changing the RRULE? Have iTIP messages already been sent out invi=
ting people to the event?). More thought needed here I think.
<=
div>

I was very unclear how the "SPLIT" thing w=
as meant to work in the spec, which is related to the above; I would be =
interested to know more about what Mike's proposing here.
=


Neil.

--4fd9938585bb46ea8542e5801f98db46--


From nobody Mon Nov 18 21:32:44 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 AAEE2120822 for ; Mon, 18 Nov 2019 21:32:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.110.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157414156269.14031.4302118333643320554.idtracker@ietfa.amsl.com>
Date: Mon, 18 Nov 2019 21:32:42 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [calsify] Milestones changed for calext WG
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: Tue, 19 Nov 2019 05:32:43 -0000

Changed milestone "Send attachment dratf to IESG", resolved as "Done", added
draft-ietf-calext-caldav-attachments to milestone.

Changed milestone "Adopt a document for subscription upgrade", resolved as
"Done", added draft-ietf-calext-subscription-upgrade to milestone.

Changed milestone "Send Event Publication draft to IESG", resolved as "Done",
added draft-ietf-calext-eventpub-extensions to milestone.

Changed milestone "Send iCal relation draft to IESG", resolved as "Done",
added draft-ietf-calext-ical-relations to milestone.

Changed milestone "Adopt a document for consensus scheduling", set due date
to December 2019 from April 2019, resolved as "Done", added
draft-calext-vpoll to milestone.

Changed milestone "Send JSCalendar draft to IESG", set due date to December
2019 from June 2019, added draft-ietf-calext-jscalendar to milestone.

Changed milestone "Submit scheduling controls document to IESG for
publication", set due date to February 2020 from August 2019, added
draft-ietf-calext-caldav-scheduling-controls to milestone.

Changed milestone "Update charter/milestones to reflect current and planned
work", set due date to April 2020 from April 2019.

URL: https://datatracker.ietf.org/wg/calext/about/


From nobody Mon Nov 18 21:37:18 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 7BE1712081D for ; Mon, 18 Nov 2019 21:37:16 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.110.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157414183650.14086.490154920676702478.idtracker@ietfa.amsl.com>
Date: Mon, 18 Nov 2019 21:37:16 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [calsify] Milestones changed for calext WG
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: Tue, 19 Nov 2019 05:37:16 -0000

Changed milestone "Submit valarm document to IESG for publication", set state
to active from review, accepting new milestone.

Changed milestone "Submit vpoll document to IESG for publication", set state
to active from review, accepting new milestone.

Changed milestone "Submit calendar series document to IESG for publication",
set state to active from review, accepting new milestone.

URL: https://datatracker.ietf.org/wg/calext/about/


From nobody Tue Nov 19 01:27: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 69281120897 for ; Tue, 19 Nov 2019 01:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.405
X-Spam-Level: 
X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 WGmNM64YLad3 for ; Tue, 19 Nov 2019 01:27:49 -0800 (PST)
Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) (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 48D7B120887 for ; Tue, 19 Nov 2019 01:27:49 -0800 (PST)
Received: by mail-vs1-f53.google.com with SMTP id k15so13748701vsp.2 for ; Tue, 19 Nov 2019 01:27:49 -0800 (PST)
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=J3n4t+or/GpU+aHNDvmpio0HT6Z9SGyL2rxu3RC3U8U=; b=KUeQZBt/21YcMI7UVpYKdrizgXCk5O+qvhXA0FhvVt4q7vRf7CjChRY4AFmyCkABpk 1XCgXqVrinC77tJqAW5SI8IWLL0GNZwks+znt8lSij63JQsNjP97HIT5+23ZHgGGf7B/ FthLKXvQ/XZc5oCJiD3S9fBDIWhQS4Jd8f8N5kTPG4LuBMpqtPYKuEQ1gqGu4xOslbTX 4/xfMaFYMOXy20yj4J1E7KC1/+5h34Zo5VT2v1PzVjAu3lHm8wpx/iKtabbgF0w2D04s RqR8YyqN8ISMEABhef1JjqW5kYI5omjIM9B6poEXNeM7ZEeyw6bvxS4aV6++A0IUsFHW Ne3Q==
X-Gm-Message-State: APjAAAX/pSFeUHLEFiF6tEjZrEUo0VBbHPjS5U905Nyw9Snz+1A06LDt gLAlP7p887G5iAflRcbepNX9whWIfINarI6mYumMJw==
X-Google-Smtp-Source: APXvYqyMbOoFZdFZFDciv+vaIKhz0FL4JPyvK7lAmAfxNFxpRD9aLIf25qd9wuIRfczIURyUkMShDTGpsV/Xj2E6IU8=
X-Received: by 2002:a67:bd05:: with SMTP id y5mr20918232vsq.180.1574155668238;  Tue, 19 Nov 2019 01:27:48 -0800 (PST)
MIME-Version: 1.0
From: Daniel Migault 
Date: Tue, 19 Nov 2019 17:27:37 +0800
Message-ID: 
To: IETF-Calsify 
Content-Type: multipart/alternative; boundary="0000000000006d36340597afad74"
Archived-At: 
Subject: [calsify] compliance with jscalendar
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, 19 Nov 2019 09:27:50 -0000

--0000000000006d36340597afad74
Content-Type: text/plain; charset="UTF-8"

Hi,

Given that jscalendar is shipped, I wondering if what we define for
iCalendar should not be defined as well for jscalendar.

Yours,
Daniel

--0000000000006d36340597afad74
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

Given that jscalendar is shippe=
d, I wondering if what we define for iCalendar=C2=A0should=C2=A0not be defi=
ned as well for jscalendar.=C2=A0

Yours,=C2=A0
Daniel


--0000000000006d36340597afad74--


From nobody Tue Nov 19 08:12: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 4C70A120961 for ; Tue, 19 Nov 2019 08:12:23 -0800 (PST)
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, 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 zFPfRO1elD59 for ; Tue, 19 Nov 2019 08:12:21 -0800 (PST)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 DEB7F12095C for ; Tue, 19 Nov 2019 08:12:20 -0800 (PST)
Received: by mail-qv1-xf31.google.com with SMTP id d3so8329902qvs.11 for ; Tue, 19 Nov 2019 08:12:20 -0800 (PST)
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=EIEZuweYMsiX7T5eKsEJLdzQuM/VjRSIMb3xkZxfmtw=; b=uwEG34kME2qyPw9ZCjKS6UV32lGkWWEeW9qnXjLtdfIx/aSctaVn2PsQzcuUBZ0hC3 iQopm6yNSIfzv5BGt54D/uVV/CnZLDm88KV+PwFrgjbcjgep+r1FZaU2acFOnrwxOUjU k9PQO9wbNfOkWt+pTcDhMVrprv3MVg3jPK+/9t0U8HLKEEmPSNHoC70NvEQwoF2AiN9c RT04hx44+OTKsWULo3++az6MNJdkY7LpVwF26XpAQDPf75bWsJWInNBq2XaDL9RWriS2 gD2kegB7hhlwbalvowXiJ426jtBi92xWMvheYXD2gCSaX4r81sqNU95mWtQNPcIxVNoG Eqgg==
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=EIEZuweYMsiX7T5eKsEJLdzQuM/VjRSIMb3xkZxfmtw=; b=WgHg6fBgO+3fZ+Xj44KLyEm2/5lxwN9k7nCsjFA2b11agJ+Prej8oDyCE8WtEya9H9 86Q7IeOXsBvqENxMl1HSWl2DkvW5IqtDwdyCSKZt2ru6KYh5xZ/EkL+EamvPPwK1Xlri C4h4CQ6dQFp/YUNyZKerveAFVSOzzmcdU7KmisbloBdzd8Jj8p2VQDge8hbt03PD1aWA Mu11GprKrFH8jsnuHFl5S1J1Aav2GS4iF5enyOKrDMxIeIU4qDgGno4BTqNgw4d9ACtj ERXlIvwBRI9eFEE9KmWJNSM03bLqHokcj3Aqzyw8eCANlydpKN2JyDY6y19bm3OhWz9O Ssqg==
X-Gm-Message-State: APjAAAXspU9puV0jdHoCfC+dhtR+MU+2QngzrLHfPjbjSjjqgzlRrMBS iWVY3gILYdoSbiFftQerCUYeiUTJXJU=
X-Google-Smtp-Source: APXvYqxsxmpgdOIPCMf7kYZJ1zzURXfxw2pgUBf9DtVoJD9XtR1hUBpC6FQaMOiZn+5eDdPa8PHJVw==
X-Received: by 2002:ad4:4770:: with SMTP id d16mr5762042qvx.92.1574179939762;  Tue, 19 Nov 2019 08:12:19 -0800 (PST)
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 i41sm12887034qti.42.2019.11.19.08.12.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 08:12:19 -0800 (PST)
To: Neil Jenkins , calsify@ietf.org
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com>
From: Michael Douglass 
Message-ID: <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com>
Date: Tue, 19 Nov 2019 11:12:16 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------60DE5E2E4EE128928827DC79"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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, 19 Nov 2019 16:12:23 -0000

This is a multi-part message in MIME format.
--------------60DE5E2E4EE128928827DC79
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks Neil

On 11/18/19 07:14, Neil Jenkins wrote:
> I think this concept is good, but this spec needs a fair bit more work 
> (as noted in the meeting today, this should have been a call for 
> adoption, not WGLC!)
>
> The "series master" is a kind of template; it's not an event itself, 
> it just generates them. It might make more sense therefore to make 
> this a different component, e.g. |VEVENTTEMPLATE|. Clients that don't 
> support the spec should simply ignore them, which is what we want. We 
> can also then reuse standard RRULE etc. properties and don't need to 
> define separate SRULE etc. properties.
>
Good idea - I'll work on that.
> I think we should mandate that the server manages generating the 
> instances; that's going to be by far the most useful option and we can 
> clearly define when this should happen in the spec.
That ties the data model in with one or more protocols. I'd prefer to 
leave that to related specs (or sections). However, I can see that with 
say a CalDAV stored series it MUST be the server.
> Changing the template (series master) should not change any generated 
> event that's now in the past; the question is what to do about those 
> in the future. It probably depends on what the change is (what if you 
> change the template SUMMARY? What about adding an RDATE? What about 
> changing the RRULE? Have iTIP messages already been sent out inviting 
> people to the event?). More thought needed here I think.
>
> I was very unclear how the "SPLIT" thing was meant to work in the 
> spec, which is related to the above; I would be interested to know 
> more about what Mike's proposing here.
I'll reread. I want to standardize the split approach from the start so 
we don't have the current recurrence issues. Dangling future overrides 
are always a problem if the rules change - this has been a major problem 
- set up months worth of instances - every one different then chaneg 
from weekly to bi-weekly.
>
> Neil.
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

--------------60DE5E2E4EE128928827DC79
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks Neil

    

    
On 11/18/19 07:14, Neil Jenkins wrote:

    

    

      
      
      
      

        
I think this concept is good, but this spec needs a fair
          bit more work (as noted in the meeting today, this should have
          been a call for adoption, not WGLC!)

        

        

          


          

        

        
The "series master" is a kind of template; it's not an
          event itself, it just generates them. It might make more sense
          therefore to make this a different component, e.g. VEVENTTEMPLATE. Clients
          that don't support the spec should simply ignore them, which
          is what we want. We can also then reuse standard RRULE etc.
          properties and don't need to define separate SRULE etc.
          properties.

        

        

          


          

        

      

    

    Good idea - I'll work on that.

    

      

        
I think we should mandate that the server manages
          generating the instances; that's going to be by far the most
          useful option and we can clearly define when this should
          happen in the spec.

      

    

    That ties the data model in with one or more protocols. I'd prefer
    to leave that to related specs (or sections). However, I can see
    that with say a CalDAV stored series it MUST be the server. 

    

      

        
 Changing the template (series master) should not change
          any generated event that's now in the past; the question is
          what to do about those in the future. It probably depends on
          what the change is (what if you change the template SUMMARY?
          What about adding an RDATE? What about changing the RRULE?
          Have iTIP messages already been sent out inviting people to
          the event?). More thought needed here I think.

        

        

          


          

        

        
I was very unclear how the "SPLIT" thing was meant to work
          in the spec, which is related to the above; I would be
          interested to know more about what Mike's proposing here.

        

      

    

    I'll reread. I want to standardize the split approach from the start
    so we don't have the current recurrence issues. Dangling future
    overrides are always a problem if the rules change - this has been a
    major problem - set up months worth of instances - every one
    different then chaneg from weekly to bi-weekly.

    

      

        

          


          

        

        
Neil.

        

      

      

      

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


    

  


--------------60DE5E2E4EE128928827DC79--


From nobody Tue Nov 19 08:21: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 D1F95120980 for ; Tue, 19 Nov 2019 08:20:59 -0800 (PST)
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 xQxp1Qm6yrC6 for ; Tue, 19 Nov 2019 08:20:57 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 39FC2120959 for ; Tue, 19 Nov 2019 08:20:28 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id r20so25168361qtp.13 for ; Tue, 19 Nov 2019 08:20:28 -0800 (PST)
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=StHRxwAzWNDhJubQC9UtJvoJxhlt2C6ewo0IgX/j7zg=; b=lUsnMJuAJ9xEzSZXlL6DXzZF9TxjFr9p7Fso1o013sZvX4/NjZtP20PLF4jbdLofjz 73vx5GbiLtCzRuSnzBRE9dCK7jzHLTIW7k8u+jS7+qZwhG1GDR+3/NiNkP5KKjdPeiAb LqGYJ7wi5eaMuuHnnx6Ct/Y9VmRX6cjWYvpq6oi5sTs4b9aVv+xP7YmvPOO9TkpOGRDS lP6cMb3GoIxFAn1MG591c295c2ShAKwzNCNtYVS5cpP1Ag1KzrKwQ+1stjkF2Qx5stJJ NxE+sS3NOCdaB5/V0kmo6DBasUeT6MLGlJeULOQQmY4RBOg69iGIdH6dNpCqufpUFEp8 FoBw==
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=StHRxwAzWNDhJubQC9UtJvoJxhlt2C6ewo0IgX/j7zg=; b=oiFdfE/CQoK/r20lSUwbr71+ZkcCyVWy3fGYAtxtYoSIQQXv4BZw/F02DcHIuVJ5oZ H67DGdWF/OkdEIyWl9DbSmsCSO45tD1nY8KrVFxTKwGe9Xjpdhe3QTpQF8tC62IffayS 7KbHrPNtNkRCINUtN0BGWgavTqkFicNe1B0XhY06WPnCxUoQXeBD5+a0SqhEJ3pWmb8A giJtxwl/8edDF7NPWkWkzY0wTIEpcq5CuyA7RvGkuTQSW4qpIziIoiXwy874MSQlJ1eS 8ZP0nlov5ys1tWO6hYEuAMdk6pGpHpBg2aERJSO1G+y4nnLtDmiTSuStZYmP9IEHP0iC 3w0A==
X-Gm-Message-State: APjAAAWOxTWiF92eLidCsrWUiJsaQAQ4am798mFSBpak+BCtRtVeltl4 RDCWk2Hsouw6QuTAcFwG5IHrj+nTLrQ=
X-Google-Smtp-Source: APXvYqz5B6Dz1LNZcW3vlgMaRiBxiha+qYRj+3Pdm+1JQ9kEe7lS4Lx+ua/3sMdRc1NE/6Yxwwi7tg==
X-Received: by 2002:ac8:2d19:: with SMTP id n25mr33698316qta.144.1574180427011;  Tue, 19 Nov 2019 08:20:27 -0800 (PST)
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 x39sm12955421qth.92.2019.11.19.08.20.26 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 08:20:26 -0800 (PST)
To: calsify@ietf.org
References: 
From: Michael Douglass 
Message-ID: <736e3f26-86fc-eca8-54a0-72d16c7a6ec6@gmail.com>
Date: Tue, 19 Nov 2019 11:20:24 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8D7399D32AD778A2C75896EF"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] WGLC for draft-ietf-calext-subscription-upgrade
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, 19 Nov 2019 16:21:00 -0000

This is a multi-part message in MIME format.
--------------8D7399D32AD778A2C75896EF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

(Reposted Neil's reply to the wrong list)

> My notes and queries after reading this through:
>
>> These LINK headers will be delivered when a client carries out a HEAD
>> request targeting the URL of the resource.
> Is there a reason this isn't added in response to the GET request as
> well? If the client is hoping to use CalDAV then it makes sense to do
> the HEAD first, but if it only supports the "enhanced get" it'll need to
> do the GET next anyway regardless of the response and so it would save
> you a request.
A number of people have asked for this. I can specify that they MUST be 
returned on GET as well. The issue for some people is that they want to 
farm the download off to another process as it's potentially very large.
>
>> by specifying the Prefer header field preference "limit=n" where n is
>> the number of components.
> If you want to specify "limit=n" as well as "subscribe-enhanced-get",
> it's unclear to me whether that's two Prefer header fields or one (e.g.
> comma separated). I'd guess two (since it's not specified), but use of
> the definite article "the Prefer header field" implies maybe not. This
> needs to be clarified, and an example would be very welcome.
I'd need to read the Prefer spec again but (also http). I suspect it 
doesn't matter if it's one or two header fields.
>
>> 5.  Header Field: Sync-Token
>>    The value MUST be a URI.
> Why is this a URI? It's unclear to me the purpose of that, especially
> given the spec says:
because it has to be in WebDAV sync (perhaps a point to consider in 
jscalendar). Anything can be turned into a data URI. As to why it's a 
URI in WebDAV sync maybe the authors can tell us (or maybe the spec does)
>
>> Client MUST not attempt to interpret the data URI value.
> Shouldn't this just be an opaque string?
>
>> 7.  Link relations
> As discussed in the meeting today, this needs more fleshing out and some spec references.
>
>>   The following preferences have been added to the HTTP Preferences
>>    Registry defined in [RFC7240]
>>
>>    Preference
>>     subscribe-enhanced-get
> We'll need to check with the HTTP folks whether this is considered
> appropriate use of the Prefer header. There's already the
> "return=minimal" Prefer option registered, which maybe we could use? If
> registering a new one, given how tied this is to calendaring and
> iCalendar the name probably shouldn't be quite so generic.
I think that we started there. However it might conflict with other 
intended uses. I'd really prefer a specific option for this purpose.
>
>> 9.3.  Link Relation Registrations
>>
>>    This document defines the following new iCalendar properties to be
>>    added to the registry defined in section=8.2.3 [RFC5545]:
> I am very confused by this; why is anything being added to the iCalendar
> property registry? How are these meant to be used as iCalendar
> properties?
Maybe a leftover
>
> Neil.

On 11/5/19 21:09, Daniel Migault wrote:
>
> This email starts a WGLC for the 
> document draft-ietf-calext-subscription-upgrade [1]. In order to move 
> the document forward, please review the document and state your 
> opinion or comments until Tuesday November 19.
>
> Note that given the history of the document, it is important to show 
> the IESG the document is supported by the WG.
>
> Yours,
> Bron and Daniel
>
> [1] 
> https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

--------------8D7399D32AD778A2C75896EF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
(Reposted Neil's reply to the wrong list)

    

      

        
My notes and queries after reading this through:



        

          
These LINK headers will be delivered when a client carries out a HEAD
request targeting the URL of the resource.


        

        
Is there a reason this isn't added in response to the GET request as
well? If the client is hoping to use CalDAV then it makes sense to do
the HEAD first, but if it only supports the "enhanced get" it'll need to
do the GET next anyway regardless of the response and so it would save
you a request.

      

      A number of people have asked for this. I can specify that they
      MUST be returned on GET as well. The issue for some people is that
      they want to farm the download off to another process as it's
      potentially very large.  

      

        



        

          
by specifying the Prefer header field preference "limit=n" where n is
the number of components.


        

        
If you want to specify "limit=n" as well as "subscribe-enhanced-get",
it's unclear to me whether that's two Prefer header fields or one (e.g.
comma separated). I'd guess two (since it's not specified), but use of
the definite article "the Prefer header field" implies maybe not. This
needs to be clarified, and an example would be very welcome.

      

      I'd need to read the Prefer spec again but (also http). I suspect
      it doesn't matter if it's one or two header fields.

      

        



        

          
5.  Header Field: Sync-Token
  The value MUST be a URI.


        

        
Why is this a URI? It's unclear to me the purpose of that, especially
given the spec says:

      

      because it has to be in WebDAV sync (perhaps a point to consider
      in jscalendar). Anything can be turned into a data URI. As to why
      it's a URI in WebDAV sync maybe the authors can tell us (or maybe
      the spec does)

      

        



        

          
Client MUST not attempt to interpret the data URI value.


        

        
Shouldn't this just be an opaque string?



        

          
7.  Link relations


        

        
As discussed in the meeting today, this needs more fleshing out and some spec references.



        

          
 The following preferences have been added to the HTTP Preferences
  Registry defined in [RFC7240]

  Preference
   subscribe-enhanced-get


        

        
We'll need to check with the HTTP folks whether this is considered
appropriate use of the Prefer header. There's already the
"return=minimal" Prefer option registered, which maybe we could use? If
registering a new one, given how tied this is to calendaring and
iCalendar the name probably shouldn't be quite so generic.

      

      I think that we started there. However it might conflict with
      other intended uses. I'd really prefer a specific option for this
      purpose. 

      

        



        

          
9.3.  Link Relation Registrations

  This document defines the following new iCalendar properties to be
  added to the registry defined in section=8.2.3 [RFC5545]:


        

        
I am very confused by this; why is anything being added to the iCalendar
property registry? How are these meant to be used as iCalendar
properties?

      

      Maybe a leftover

      

        

Neil.


      

      

    

    
On 11/5/19 21:09, Daniel Migault wrote:

    

    

      
      

        

          

            

              


              

              
This email starts a WGLC for the
                document draft-ietf-calext-subscription-upgrade [1]. In
                order to move the document forward, please review the
                document and state your opinion or comments until
                Tuesday November 19. 

              


              

              
Note that given the history of the document, it is
                important to show the IESG the document is supported by
                the WG. 

              


              

              
Yours, 

              
Bron and Daniel

              


              

              
            

          

        

      

      

      

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


    

  


--------------8D7399D32AD778A2C75896EF--


From nobody Wed Nov 20 08:00: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 C7DE21208FE for ; Wed, 20 Nov 2019 08:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 lSpxtzpisebq for ; Wed, 20 Nov 2019 08:00:08 -0800 (PST)
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 436651208F6 for ; Wed, 20 Nov 2019 08:00:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20191106;  h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=84w1S4d1GHd0cPyf/Xm1FPUygNMhbFnZ03rVmiIpeNo=; b=btlfTvIJZGzLc9w6GemTS9Vugb6FmOSs320H2RzxUQGBj3/EKgcYl/tSyiSAjlEWgFOQlZVAIGQSW kTUsmGaGpRZntsTkcRtuLINW02EeEYatiBqOh4B4Zf6aEZJrMNH4TXElY9pI60utnd+uRbFn7wWUDu O8orUJ6iNPf6VugIEE0hvXmoYJhT/xZtWB+1nZDEddSRtmRQdDi7i03v48UCLtOwOnRWgO3KNJlEor qLskO576aAdESn1RmNIL6YjEomal0Nuz8/jFMOrE7BvbE0PrgGbkiS5YbLyhUCZp9lGxXJKH86t+Uq wc0ARbBnttdMzPlXDchiMrC6u158Tig==
X-HalOne-Cookie: 3a40d7fca001ee40aeeffeeaa7c5b4eb565f1ab7
X-HalOne-ID: d0c91088-0bae-11ea-b5f1-d0431ea8bb03
Received: from smtp.dmfs.org (unknown [2003:fa:af05:8e00:201:2eff:fe40:2624]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id d0c91088-0bae-11ea-b5f1-d0431ea8bb03; Wed, 20 Nov 2019 16:00:04 +0000 (UTC)
Received: from boss.localdomain (pD95ED904.dip0.t-ipconnect.de [217.94.217.4]) by smtp.dmfs.org (Postfix) with ESMTPSA id 3401C3A9 for ; Wed, 20 Nov 2019 17:00:04 +0100 (CET)
To: calsify@ietf.org
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com>
From: Marten Gajda 
Message-ID: <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org>
Date: Wed, 20 Nov 2019 17:00:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com>
Content-Type: multipart/alternative; boundary="------------853D3DE2BF088E8E87C56F35"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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, 20 Nov 2019 16:00:11 -0000

This is a multi-part message in MIME format.
--------------853D3DE2BF088E8E87C56F35
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


Am 19.11.19 um 17:12 schrieb Michael Douglass:
>
> Thanks Neil
>
> On 11/18/19 07:14, Neil Jenkins wrote:
>> I think this concept is good, but this spec needs a fair bit more 
>> work (as noted in the meeting today, this should have been a call for 
>> adoption, not WGLC!)
>>
>> The "series master" is a kind of template; it's not an event itself, 
>> it just generates them. It might make more sense therefore to make 
>> this a different component, e.g. |VEVENTTEMPLATE|. Clients that don't 
>> support the spec should simply ignore them, which is what we want. We 
>> can also then reuse standard RRULE etc. properties and don't need to 
>> define separate SRULE etc. properties.
>>
> Good idea - I'll work on that.
>
I like the idea of a separate SRULE. It allows you to declare series of 
recurring events. That way you can specify more complex recurrence 
patterns which you can't express with a single RRULE. For instance, an 
event recurring every 1st Monday of June for three days or an event 
recurring on eight consecutive days starting every other week.

Marten

-- 
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


--------------853D3DE2BF088E8E87C56F35
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
Am 19.11.19 um 17:12 schrieb Michael
      Douglass:

    

    

      
      
Thanks Neil

      

      
On 11/18/19 07:14, Neil Jenkins
        wrote:

      

      

        
        
        
        

          
I think this concept is good, but this spec needs a fair
            bit more work (as noted in the meeting today, this should
            have been a call for adoption, not WGLC!)

          

          

            


            

          

          
The "series master" is a kind of template; it's not an
            event itself, it just generates them. It might make more
            sense therefore to make this a different component, e.g. VEVENTTEMPLATE. Clients
            that don't support the spec should simply ignore them, which
            is what we want. We can also then reuse standard RRULE etc.
            properties and don't need to define separate SRULE etc.
            properties.

          

          

            


            

          

        

      

      Good idea - I'll work on that.

      

    

    
I like the idea of a separate SRULE. It allows you to declare
      series of recurring events. That way you can specify more complex
      recurrence patterns which you can't express with a single RRULE.
      For instance, an event recurring every 1st Monday of June for
      three days or an event recurring on eight consecutive days
      starting every other week.

    
Marten

    

    
-- 
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

  


--------------853D3DE2BF088E8E87C56F35--


From nobody Wed Nov 20 08: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 5B0AC1208DF for ; Wed, 20 Nov 2019 08:39:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 Pxlx11QwsRV1 for ; Wed, 20 Nov 2019 08:39:46 -0800 (PST)
Received: from mailrelay2-1.pub.mailoutpod1-cph3.one.com (mailrelay2-1.pub.mailoutpod1-cph3.one.com [46.30.210.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71871200F8 for ; Wed, 20 Nov 2019 08:39:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20191106;  h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=84w1S4d1GHd0cPyf/Xm1FPUygNMhbFnZ03rVmiIpeNo=; b=btlfTvIJZGzLc9w6GemTS9Vugb6FmOSs320H2RzxUQGBj3/EKgcYl/tSyiSAjlEWgFOQlZVAIGQSW kTUsmGaGpRZntsTkcRtuLINW02EeEYatiBqOh4B4Zf6aEZJrMNH4TXElY9pI60utnd+uRbFn7wWUDu O8orUJ6iNPf6VugIEE0hvXmoYJhT/xZtWB+1nZDEddSRtmRQdDi7i03v48UCLtOwOnRWgO3KNJlEor qLskO576aAdESn1RmNIL6YjEomal0Nuz8/jFMOrE7BvbE0PrgGbkiS5YbLyhUCZp9lGxXJKH86t+Uq wc0ARbBnttdMzPlXDchiMrC6u158Tig==
X-HalOne-Cookie: f7c9cb2c628ce9418a76104f8c0bbef39098d378
X-HalOne-ID: 59f67559-0bb4-11ea-ba02-d0431ea8a290
Received: from smtp.dmfs.org (unknown [217.94.217.4]) by mailrelay2.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 59f67559-0bb4-11ea-ba02-d0431ea8a290; Wed, 20 Nov 2019 16:39:42 +0000 (UTC)
Received: from boss.localdomain (pD95ED904.dip0.t-ipconnect.de [217.94.217.4]) by smtp.dmfs.org (Postfix) with ESMTPSA id 3401C3A9 for ; Wed, 20 Nov 2019 17:00:04 +0100 (CET)
To: calsify@ietf.org
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com>
From: Marten Gajda 
Message-ID: <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org>
Date: Wed, 20 Nov 2019 17:00:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com>
Content-Type: multipart/alternative; boundary="------------853D3DE2BF088E8E87C56F35"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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, 20 Nov 2019 16:39:47 -0000

This is a multi-part message in MIME format.
--------------853D3DE2BF088E8E87C56F35
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


Am 19.11.19 um 17:12 schrieb Michael Douglass:
>
> Thanks Neil
>
> On 11/18/19 07:14, Neil Jenkins wrote:
>> I think this concept is good, but this spec needs a fair bit more 
>> work (as noted in the meeting today, this should have been a call for 
>> adoption, not WGLC!)
>>
>> The "series master" is a kind of template; it's not an event itself, 
>> it just generates them. It might make more sense therefore to make 
>> this a different component, e.g. |VEVENTTEMPLATE|. Clients that don't 
>> support the spec should simply ignore them, which is what we want. We 
>> can also then reuse standard RRULE etc. properties and don't need to 
>> define separate SRULE etc. properties.
>>
> Good idea - I'll work on that.
>
I like the idea of a separate SRULE. It allows you to declare series of 
recurring events. That way you can specify more complex recurrence 
patterns which you can't express with a single RRULE. For instance, an 
event recurring every 1st Monday of June for three days or an event 
recurring on eight consecutive days starting every other week.

Marten

-- 
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


--------------853D3DE2BF088E8E87C56F35
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
Am 19.11.19 um 17:12 schrieb Michael
      Douglass:

    

    

      
      
Thanks Neil

      

      
On 11/18/19 07:14, Neil Jenkins
        wrote:

      

      

        
        
        
        

          
I think this concept is good, but this spec needs a fair
            bit more work (as noted in the meeting today, this should
            have been a call for adoption, not WGLC!)

          

          

            


            

          

          
The "series master" is a kind of template; it's not an
            event itself, it just generates them. It might make more
            sense therefore to make this a different component, e.g. VEVENTTEMPLATE. Clients
            that don't support the spec should simply ignore them, which
            is what we want. We can also then reuse standard RRULE etc.
            properties and don't need to define separate SRULE etc.
            properties.

          

          

            


            

          

        

      

      Good idea - I'll work on that.

      

    

    
I like the idea of a separate SRULE. It allows you to declare
      series of recurring events. That way you can specify more complex
      recurrence patterns which you can't express with a single RRULE.
      For instance, an event recurring every 1st Monday of June for
      three days or an event recurring on eight consecutive days
      starting every other week.

    
Marten

    

    
-- 
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

  


--------------853D3DE2BF088E8E87C56F35--


From nobody Wed Nov 20 09:30:27 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 8BD0E12010D for ; Wed, 20 Nov 2019 09:30:25 -0800 (PST)
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 7GpHSkyb8Bxc for ; Wed, 20 Nov 2019 09:30:22 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 DCB621200F4 for ; Wed, 20 Nov 2019 09:30:20 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id y39so423348qty.0 for ; Wed, 20 Nov 2019 09:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=RZFx5i/cwYTxZuyrjhAfl/6VR1QxBJZk291BKadbJgo=; b=bggRbvR8QW5F2bjOTFSyXlNbSwo1jxvtAc4kalq/JhhdyC1lFA9zzDsaJ3GxjDWg8M IRkbVjMZ2d9afQL9Wl3POMMG2UoPiZGTGg8/YQmzHST7i5XGqIf+pihkOU80blTMINKq FpHhoPcSpYHTiXD7QyDtKdGLgSmqH7tcAOpSbtXCrqcveuC5esJUWY4xf/ZyEUlSkFhg 8tcFuJSoTV1UL9iCl6x4BGX2Htna2TcB4p2RJKEekM6jQdPCRk9jJzPLikdcpFLMm655 rgc96wgLuPprauJI8wFGvYyQSalP/Wk+pe2HnjEpR3WAPR3XhAaFoYQWFcm+B9IkjLJd 0zKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=RZFx5i/cwYTxZuyrjhAfl/6VR1QxBJZk291BKadbJgo=; b=TKNRmhE//yFO60EINdU9NY3V1BZ0EqrjG2r1gw7GIqhvP4itamnIAr+wFMde2SSog2 nietv9CM74+HU5kDcBW0MkDZVPUhyK4iTpQ58h0S3GWkVM07KfoDswIQGTxB1OoZFUM2 +t9vfV6Qxnm5J8j2V0CfBFJ7X+wqIQh+ezevxjlDNEjS/UXKjIkB9LOTwP1o2puTZwN2 tk++sj+ljCldoMUYxImUby0RfkpcqHskNG/3nC/Hqp1cVIESh5og2vmraH00sZ9uxgIn LCffmrSEWWlU1xDMh0Rif/YY3LhappFtPbe8fNAFD2SqS4iPwTTDm5NV6OJb4VfGA2YZ /07w==
X-Gm-Message-State: APjAAAXuq+zAmpeRdZCljmn/LmW88FXeHNtGiuB6igAD4ycX6sIBZouA WOLJcXRRGYNDw/1jhWGXBZWCUWCgheU=
X-Google-Smtp-Source: APXvYqzK9d0reKAUTq/6IxZxU1v9B+t3DUv4J/8Er063715IoygYJoGOjOh51iHthK/IzgQffj/gxQ==
X-Received: by 2002:aed:3fc4:: with SMTP id w4mr3789143qth.120.1574271018803;  Wed, 20 Nov 2019 09:30:18 -0800 (PST)
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 w2sm12106329qkw.31.2019.11.20.09.30.17 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 09:30:17 -0800 (PST)
From: Michael Douglass 
To: calsify@ietf.org
References:  <736e3f26-86fc-eca8-54a0-72d16c7a6ec6@gmail.com>
Message-ID: 
Date: Wed, 20 Nov 2019 12:30:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <736e3f26-86fc-eca8-54a0-72d16c7a6ec6@gmail.com>
Content-Type: multipart/alternative; boundary="------------8D820329D35609CF6515AE45"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] WGLC for draft-ietf-calext-subscription-upgrade
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, 20 Nov 2019 17:30:25 -0000

This is a multi-part message in MIME format.
--------------8D820329D35609CF6515AE45
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


On 11/19/19 11:20, Michael Douglass wrote:
> 5. Header Field: Sync-Token
>>>    The value MUST be a URI.
>> Why is this a URI? It's unclear to me the purpose of that, especially
>> given the spec says:
> because it has to be in WebDAV sync (perhaps a point to consider in 
> jscalendar). Anything can be turned into a data URI. As to why it's a 
> URI in WebDAV sync maybe the authors can tell us (or maybe the spec does)
>>> Client MUST not attempt to interpret the data URI value.
>> Shouldn't this just be an opaque string?
>>
It's in section 3.2 of webdav sync

   The synchronization token itself MUST be treated as an "opaque"
    string by the client, i.e., the actual string data has no specific
    meaning or syntax.  However, the token MUST be a valid URI to allow
    its use in an If precondition request header (seeSection 5  ).  For
    example, a simple implementation of such a token could be a numeric
    counter that counts each change as it occurs and relates that change
    to the specific object that changed.  The numeric value could be
    appended to a "base" URI to form the valid sync-token.

>>      
>>      
>
> On 11/5/19 21:09, Daniel Migault wrote:
>>
>> This email starts a WGLC for the 
>> document draft-ietf-calext-subscription-upgrade [1]. In order to move 
>> the document forward, please review the document and state your 
>> opinion or comments until Tuesday November 19.
>>
>> Note that given the history of the document, it is important to show 
>> the IESG the document is supported by the WG.
>>
>> Yours,
>> Bron and Daniel
>>
>> [1] 
>> https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/
>>
>> _______________________________________________
>> calsify mailing list
>> calsify@ietf.org
>> https://www.ietf.org/mailman/listinfo/calsify

--------------8D820329D35609CF6515AE45
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 11/19/19 11:20, Michael Douglass
      wrote:

    

    

      
      5. Header Field: Sync-Token
      

        

          
  The value MUST be a URI.


        

        
Why is this a URI? It's unclear to me the purpose of that, especially
given the spec says:

      

      because it has to be in WebDAV sync (perhaps a point to consider
      in jscalendar). Anything can be turned into a data URI. As to why
      it's a URI in WebDAV sync maybe the authors can tell us (or maybe
      the spec does)

      

        

          
Client MUST not attempt to interpret the data URI value.


        

        
Shouldn't this just be an opaque string?



      

    

    
It's in section 3.2 of webdav sync

    

    
  The synchronization token itself MUST be treated as an "opaque"
   string by the client, i.e., the actual string data has no specific
   meaning or syntax.  However, the token MUST be a valid URI to allow
   its use in an If precondition request header (see Section 5).  For
   example, a simple implementation of such a token could be a numeric
   counter that counts each change as it occurs and relates that change
   to the specific object that changed.  The numeric value could be
   appended to a "base" URI to form the valid sync-token.


    

      

        
    
    

      

      

      
On 11/5/19 21:09, Daniel Migault
        wrote:

      

      

        
        

          

            

              

                


                

                
This email starts a WGLC for the
                  document draft-ietf-calext-subscription-upgrade [1].
                  In order to move the document forward, please review
                  the document and state your opinion or comments until
                  Tuesday November 19. 

                


                

                
Note that given the history of the document, it is
                  important to show the IESG the document is supported
                  by the WG. 

                


                

                
Yours, 

                
Bron and Daniel

                


                

                
              

            

          

        

        

        

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


      

    

  


--------------8D820329D35609CF6515AE45--


From nobody Wed Nov 20 20:04:10 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 52349120951 for ; Wed, 20 Nov 2019 20:04:09 -0800 (PST)
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=fpxOQBAK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tbaZrV9n
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 U1Ui9GVBFaTG for ; Wed, 20 Nov 2019 20:04:07 -0800 (PST)
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 8C9A3120944 for ; Wed, 20 Nov 2019 20:04:07 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B892C22108; Wed, 20 Nov 2019 23:04:06 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 23:04:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=2Dnt/z9mOhRXlprhFmcI32hmXwts/Yf /MMB3jDJFoH8=; b=fpxOQBAKSDIaozfkMzwIFWT0LasL7AOHpR5/OQgj6HgYUm5 YpGXULe9kTEBKp/RQns1uh9raF0Axq9eacc6HSREDT2W/6sm/Hz4K+SvkLJuN7L/ tdTHOycB61Y4UimW2w93IDmbBv9/qdFmdy36FYIjCYqgzG6Z0aQ5abwHu+ck7cg5 1k+menYcbmMqeFDWg3kZFn8Qsoeyh3IrT2jGDYzfvewHdSTS6VnT+RMKXpFzUleC nGK7x4w4JJ1vnNDhBymM7DFIf6c1gytxwELr7jY4sT8GbjhERnyb2QhEJcukHBLb 58ipWwR7XKUrnBR77QcuusYaXMZBj6qs+L6YCNw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=2Dnt/z9mOhRXlprhFmcI32hmXwts/ Yf/MMB3jDJFoH8=; b=tbaZrV9nlzwxIF3TgmXU0G9TFZ4jg/yqu58yGdM3En3iN 3oVRigX+rryRpkY7yhd1ZvVMiZMUQztojI7yxQAivsm/FP+ueIi6A9sB2IG+qvEk JWFFR3POyCzHbRCEg2Xt6HoNeN7bR2pagQjTVF4ANX6qEmJLGLBCGCDl2S9tS0ML UMaYZTLezmt8z7+k7g0HqQzrRko7gZFC9gV9RYhmTEwb0uNYbOwcjLtUGjNh4+mw zwuHfjF/ZwpNBRCGFoLmDJBNU/hHehm8WPiIncoCF342iX3ITBYUxjXZIi6u33dH V9ZhNPuv8XCw94kilsoKDlwbg/tptIyTXwsDPUTeg==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhhonhcu ifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepsghr ohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 75FC430006F; Wed, 20 Nov 2019 23:04:06 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1
Mime-Version: 1.0
Message-Id: <78cb002a-9c89-439c-9ff8-c6c9624691b9@dogfood.fastmail.com>
Date: Thu, 21 Nov 2019 15:04:03 +1100
From: "Bron Gondwana" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=abe357d989ac4c2494a60aee92f29660
Archived-At: 
Subject: [calsify] =?utf-8?q?Please_upload_a_new_vpoll_draft_with_name_wi?= =?utf-8?q?th_draft-ietf-calext-vpoll?=
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, 21 Nov 2019 04:04:09 -0000

--abe357d989ac4c2494a60aee92f29660
Content-Type: text/plain

Hi Mike,

Looking back through the archives, we actually did a successful call for adoption back in April:

https://mailarchive.ietf.org/arch/msg/calsify/xB2esm7WvjK9v2v7BpgYkFR0ZIc

So the document should be a working group document. If you can upload what you have now with the new name, it will make sure we don't get confused again!

Thanks,

Bron.

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


--abe357d989ac4c2494a60aee92f29660
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


Hi Mike,

Looking back through the archives,=
 we actually did a successful call for adoption back in April:
=


So the document should be a wor=
king group document.  If you can upload what you have now with the =
new name, it will make sure we don't get confused again!

=
Thanks,

Bron.

--
  Bron Gond=
wana, CEO, Fastmail Pty Ltd
  bro=
ng@fastmailteam.com



--abe357d989ac4c2494a60aee92f29660--


From nobody Wed Nov 20 20:18: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 7D261120959 for ; Wed, 20 Nov 2019 20:18:33 -0800 (PST)
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 PVy2hB4FJ5xE for ; Wed, 20 Nov 2019 20:18:32 -0800 (PST)
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 DC57A120220 for ; Wed, 20 Nov 2019 20:18:31 -0800 (PST)
Received: by mail-qk1-x72d.google.com with SMTP id p14so1921075qkm.10 for ; Wed, 20 Nov 2019 20:18:31 -0800 (PST)
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=eor0PxZBD15bpEJylCOCLn/XSEsuRCR3x1FjduUTAU0=; b=LNEJa5zOn2UXxf7vb8CsMZAc9H60raQgSlThPzMcpEAtzdBfduSXffBb+PtyZTwtua dcI2mnXvOZ/TudKYSKlCXxVSbLOal07S1RCvPhA1WYc6tqt8iclGtADtz7pi38NGZfu2 L+huXpPbLVhz3pr42v/thvKvhM4kcW4sZjkDdCzADrMTm/9sEnt2s54HeVwEjoDg30wv QeEaz03aJF9HsiNoESmdjZL3Ocf3OgqmD+TOEKrP8QUvGRYFmg3M0oa3NZ1hd3YHBfZu nDhjzI5lqA0LYSLbjf9XdKLoS9URBfDhAbwEdMPtbYUsOaj5rrzx0y5wR2EFqzzrxNBr OvlQ==
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=eor0PxZBD15bpEJylCOCLn/XSEsuRCR3x1FjduUTAU0=; b=a8JZ8QBdvPKWXFVPKdcaW7Pj2Z4vaSQff3taBw61IhGS2Pd2QpmWTMQiLKEpxH8p3G 4T9zTcdv0rw/a3oPNgd/MUEOH9jOC3QDlwREavwQOdOeMA+zcFfCJFQgjL+rnzj8/ya9 DN+gCsbo7IdTpeYjOBfHFYGA7tWRhl1+NVFeiZEVVXpQiZzq9WPdF8Poev63DENwuoL4 vJ+rqAdo5fcRIpqeDIn18foDG4dp++MKpDS2gfLPBxtceHjvNJYju8zVHUUjEn5Tzrx4 /NrMqGceo+26NJ7EZ8u/PxFE39be1rF2h+NZosK+nb4xbWqgbEip0npjRmDMEGI0STDp AMVw==
X-Gm-Message-State: APjAAAXUBusJKheVcFZjQgYXTQ7nocspNUcObNUeThXS2gOzH6bgQMw5 ZNg2q5ztsfvPwYmWfXwsL5JtLly9F24=
X-Google-Smtp-Source: APXvYqyx+CWwYh89mcHculhOxw1UQFe4aX1/NRTiJeDmwBdf23y75QHludv2I+ypCKzafA/cEmOIuA==
X-Received: by 2002:a37:72c3:: with SMTP id n186mr6204947qkc.166.1574309910836;  Wed, 20 Nov 2019 20:18:30 -0800 (PST)
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 b134sm791841qkc.96.2019.11.20.20.18.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 20:18:30 -0800 (PST)
To: Bron Gondwana , calsify@ietf.org
References: <78cb002a-9c89-439c-9ff8-c6c9624691b9@dogfood.fastmail.com>
From: Michael Douglass 
Message-ID: 
Date: Wed, 20 Nov 2019 23:18:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <78cb002a-9c89-439c-9ff8-c6c9624691b9@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------9E6E014E867202B40854359B"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Please upload a new vpoll draft with name with draft-ietf-calext-vpoll
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, 21 Nov 2019 04:18:33 -0000

This is a multi-part message in MIME format.
--------------9E6E014E867202B40854359B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Will try to get it done tonight

On 11/20/19 23:04, Bron Gondwana wrote:
> Hi Mike,
>
> Looking back through the archives, we actually did a successful call 
> for adoption back in April:
>
> https://mailarchive.ietf.org/arch/msg/calsify/xB2esm7WvjK9v2v7BpgYkFR0ZIc
>
> So the document should be a working group document.  If you can upload 
> what you have now with the new name, it will make sure we don't get 
> confused again!
>
> Thanks,
>
> Bron.
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
>

--------------9E6E014E867202B40854359B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Will try to get it done tonight

    

    
On 11/20/19 23:04, Bron Gondwana wrote:

    

    

      
      
      
      
Hi Mike,

      

      


      

      
Looking back through the archives,
        we actually did a successful call for adoption back in April:

      

      


      

      
      


      

      
So the document should be a
        working group document.  If you can upload what you have now
        with the new name, it will make sure we don't get confused
        again!

      

      


      

      
Thanks,

      

      


        Bron.

      

      


      

      

        
--

        

        
  Bron Gondwana, CEO, Fastmail Pty Ltd

        

        
  brong@fastmailteam.com

        

        


        

      

      


      

    

  


--------------9E6E014E867202B40854359B--


From nobody Thu Nov 21 00:14:28 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 0F8FF12085E; Thu, 21 Nov 2019 00:14:27 -0800 (PST)
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.110.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: calsify@ietf.org
Message-ID: <157432406698.28822.16376648385202574242@ietfa.amsl.com>
Date: Thu, 21 Nov 2019 00:14:27 -0800
Archived-At: 
Subject: [calsify] I-D Action: draft-ietf-calext-vpoll-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: Thu, 21 Nov 2019 08:14:27 -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           : VPOLL: Consensus Scheduling Component for iCalendar
        Authors         : Eric York
                          Cyrus Daboo
                          Michael Douglass
	Filename        : draft-ietf-calext-vpoll-00.txt
	Pages           : 57
	Date            : 2019-11-20

Abstract:
   This specification introduces a new iCalendar component which allows
   for consensus scheduling, that is, voting on a number of alternative
   meeting or task alternatives.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-vpoll/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-calext-vpoll-00
https://datatracker.ietf.org/doc/html/draft-ietf-calext-vpoll-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 Thu Nov 21 00:17:24 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 89821120871 for ; Thu, 21 Nov 2019 00:17:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.110.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <157432424356.28686.7062546076313025283.idtracker@ietfa.amsl.com>
Date: Thu, 21 Nov 2019 00:17:23 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [calsify] Milestones changed for calext WG
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, 21 Nov 2019 08:17:23 -0000

Changed milestone "Submit vpoll document to IESG for publication", added
draft-ietf-calext-vpoll to milestone, removed draft-calext-vpoll from
milestone.

URL: https://datatracker.ietf.org/wg/calext/about/


From nobody Thu Nov 21 19:28: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 8F73E120836 for ; Thu, 21 Nov 2019 19:28:32 -0800 (PST)
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=QoG8ULqs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FSrGWcrF
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 fI6mY9monXx1 for ; Thu, 21 Nov 2019 19:28:31 -0800 (PST)
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 7088912084C for ; Thu, 21 Nov 2019 19:28:31 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id CDC44EDA for ; Thu, 21 Nov 2019 22:28:30 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Thu, 21 Nov 2019 22:28:30 -0500
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=fm1; bh=e7P3Fia aJRlGySQ6xXyOzpacDqcVndf7S7+hond5ZhY=; b=QoG8ULqsltQtZYGn+4nQG1X t+Oe7EkdR57XttV/juIBXtCcv42B0tICDiLUFkP6g29v/r61T38vVA2oqdtf3Ruc bY91AbFncVY7jC5RfHnW0HaNgNQ7D58wbVbMoWHE9OTWwl/2l9191R52JDqxpOQw wj0ymyhzKaZ/GvFusLBZEWH71XLnOOtocimHsThXTDRedI/l+j19/lfpZtqBQ3JD yR/70M6YuRHVqFwGWX54gBnUI44/UynvsC8emEV0+d/HUhCNXccHO1dwc/fB2l3Z 9Ou5/ZgwNcZDQWDcN6RrQJLBEHho3Wn20HJfY+qw1j91Dxr06+p0Zc7C7yRt/fw= =
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=fm1; bh=e7P3Fi aaJRlGySQ6xXyOzpacDqcVndf7S7+hond5ZhY=; b=FSrGWcrFhLHdkRwfstJ70O lGoiO6DI7wZr8PUeJXwxov8NW/Nnu9xUhe4j+MG/7lk4H5qCcj53RsvmzLoor1e0 p4EMHL3Wm8XwdpWYJokyZDttYX4yBSjkmJYsNQ/eRCr3VPRn/Z2xUfFcBcHcQuB3 9vxie1tmQ6eIlJl1+qTRH/XzcKTglEQr+aWeO5k5xApQYyifPV/OTL4E5XntCIuA WUZY1hx7nj8oI2AkqP0Ncm0S696nY6w/TNQMw/pbIGyE6lkHzwQy3FvE/HLe5D50 N7Rr7cc8dCbJfGd/3XBt+8bQCHqyKdBZ3Jg/tIELmXZw7RZSBxU0vB0RRSixEvQQ ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehfedgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 42C0B300DAB; Thu, 21 Nov 2019 22:28:30 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1
Mime-Version: 1.0
Message-Id: <36fa6790-2058-4ef6-8436-5121e7738b42@beta.fastmail.com>
In-Reply-To: 
References:  <736e3f26-86fc-eca8-54a0-72d16c7a6ec6@gmail.com> 
Date: Fri, 22 Nov 2019 11:28:08 +0800
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=49099bc20093495887048dd6e1ea1d4f
Archived-At: 
Subject: Re: [calsify] WGLC for draft-ietf-calext-subscription-upgrade
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, 22 Nov 2019 03:28:32 -0000

--49099bc20093495887048dd6e1ea1d4f
Content-Type: text/plain

On Thu, 21 Nov 2019, at 01:30, Michael Douglass wrote:
> 5. Header Field: Sync-Token 
>> Why is this a URI? It's unclear to me the purpose of that, especially given the spec says:
> because it has to be in WebDAV sync

OK, but this is not WebDAV. The reason given in WebDAV is so you can use it with an `If` header field, which is WebDAV specific I believe so not relevant here. An opaque token removes an unnecessary constraint for implementors; they can always use a URL if they want (e.g. if they are basing this off a WebDAV backend) but don't have to.

Neil.
--49099bc20093495887048dd6e1ea1d4f
Content-Type: text/html


On Thu, 21 Nov 2019, at 01:30, Michael Douglass wrote:
5. Header Field: Sync-Token 
Why is this a URI? It's unclear to me the purpose of that, especially
given the spec says:
because it has to be in WebDAV sync

OK, but this is not WebDAV. The reason given in WebDAV is so you can use it with an If header field, which is WebDAV specific I believe so not relevant here. An opaque token removes an unnecessary constraint for implementors; they can always use a URL if they want (e.g. if they are basing this off a WebDAV backend) but don't have to.

Neil.

--49099bc20093495887048dd6e1ea1d4f--


From nobody Thu Nov 21 19:37:21 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 BDD09120836 for ; Thu, 21 Nov 2019 19:37:19 -0800 (PST)
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=Z7Qlbswd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uV9RocU/
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 gUYeWNWAVioz for ; Thu, 21 Nov 2019 19:37:18 -0800 (PST)
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 52CF91200E5 for ; Thu, 21 Nov 2019 19:37:18 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 12B06F58 for ; Thu, 21 Nov 2019 22:37:17 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Thu, 21 Nov 2019 22:37:17 -0500
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=fm1; bh=RR340Gv A7efBn9HT/9gZmXYc5KshvJolZ9LCJnjuOwk=; b=Z7QlbswdyUTfzp8U19ztdNU pL2uRLz5TlXLHN0MJmNx6BuPuglIcAFi3pHgPp+7vQpOnkf8yF7NUix65B+eKvsN jDFIgRKKXdssg90ROOR187wn342IcqWY+IKOu5fogha1mBwHHdUI94vBZ1UUr261 RROqttdFNDsDd4R0j2+NjDmKTBkVVlCwkRKda35hdF7W+4SjgdpC/JX7GoC6mslt lejlMa7Ckac61QZ9G2KL7j8lvko/loClrFjAQqq/v/he+34UrM8QmVyHmDs8PBaS 188we0IywTf549u5xwgfSD5DKw4winPDCT9gsmC8ivWZjaU4hZ6za4eIYHyToiw= =
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=fm1; bh=RR340G vA7efBn9HT/9gZmXYc5KshvJolZ9LCJnjuOwk=; b=uV9RocU/TzTSOPsboPdeD5 wuh4jJuqd8Rsha7qsu4ua3Zp0652qwGWwYnNY2LcMqH3Zsl6dgxje5MUJSlsyFlk /Yhuz1c6EkAVdohrUPPuflO3Xa+JbT+3JMhHBIH5FI1o1hiPCbTOZkR2KJvJGmfs AhUO47cmbSNB6/cOz4VWiqxQiSHJCF9dtrMuTuSOqGB53i9+9ABysli9Ov2leM5g tstN+QpovdcPA62+bUtrY9Pdi3aGpC0HNW3HODS5oWkF+iTc6ZRV9iOD+x/NOVJ8 TCN+xc51AuzJ+FfiCvp/Su1E8DqXjnEli8oqL5F1UvoeF4sBdc8bWjJWffaIoa7g ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehfedgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 75EF4300DAF; Thu, 21 Nov 2019 22:37:16 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org>
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com> <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org>
Date: Fri, 22 Nov 2019 11:36:56 +0800
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=7a370105280249f99ef2c131440c8c6f
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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, 22 Nov 2019 03:37:20 -0000

--7a370105280249f99ef2c131440c8c6f
Content-Type: text/plain

On Thu, 21 Nov 2019, at 00:00, Marten Gajda wrote:
> I like the idea of a separate SRULE. It allows you to declare series of recurring events. That way you can specify more complex recurrence patterns which you can't express with a single RRULE.


I'm not sure exactly what you mean by this; do you just mean you can have multiple recurrence rules? Because that's no reason why a VTEMPLATEEVENT can't have multiple RRULE properties. I don't think SRULE was any different to RRULE other than being a different name to differentiate it when sharing a component namespace, which is not required if it's a different component.

Neil.
--7a370105280249f99ef2c131440c8c6f
Content-Type: text/html


On Thu, 21 Nov 2019, at 00:00, Marten Gajda wrote:
I like the idea of a separate SRULE. It allows you to declare
      series of recurring events. That way you can specify more complex
      recurrence patterns which you can't express with a single RRULE.

I'm not sure exactly what you mean by this; do you just mean you can have multiple recurrence rules? Because that's no reason why a VTEMPLATEEVENT can't have multiple RRULE properties. I don't think SRULE was any different to RRULE other than being a different name to differentiate it when sharing a component namespace, which is not required if it's a different component.

Neil.

--7a370105280249f99ef2c131440c8c6f--


From nobody Fri Nov 22 01:29: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 DB10F120288 for ; Fri, 22 Nov 2019 01:29:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 7MjxSGfxcJn6 for ; Fri, 22 Nov 2019 01:29:56 -0800 (PST)
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 934AC120048 for ; Fri, 22 Nov 2019 01:29:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20191106;  h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=aSgErUX4e/85aYkldVohkXOeO1KEcSxqyHLYblitaUQ=; b=kYc75HUaqfXUt22l3UQG6reRhBTqM7dfGz/kGSGx2/ySgJsntaCSlNwOAk9W79Mtom++ZteXBDQV0 LF6HLryvEVjqdF1EqHshaVZUoalh7l9XY8aVgkTzBtdDa04fXAliaCNECk5l3P2ifLnh2gqZi2DZvF 2rjFJRjfKQojvEwmrPRx7akf5zYO6xSNhjh26j1oOqDV6lJBrKcgqQENCLNgzdRWqkb9BNjMA1K8cx 2Qg6SdhsLHAnqEW5Ktd+YwL+LTsZVpsDA7x9U/T2Q1zXpy3K+8KITiNaq15YdJ2yRkh4LwukfmNSS3 e3PTU2jUv5/zzLHZUXqc5tC5VOItLZg==
X-HalOne-Cookie: 4012d6772cdc8b0e7df4624d67ee86883a432fbd
X-HalOne-ID: a2f73e4d-0d0a-11ea-8288-d0431ea8bb10
Received: from smtp.dmfs.org (unknown [2003:fa:af05:8e00:201:2eff:fe40:2624]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id a2f73e4d-0d0a-11ea-8288-d0431ea8bb10; Fri, 22 Nov 2019 09:29:52 +0000 (UTC)
Received: from boss.localdomain (pD95ED904.dip0.t-ipconnect.de [217.94.217.4]) by smtp.dmfs.org (Postfix) with ESMTPSA id D684C136E for ; Fri, 22 Nov 2019 10:29:51 +0100 (CET)
To: calsify@ietf.org
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com> <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org> 
From: Marten Gajda 
Message-ID: <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org>
Date: Fri, 22 Nov 2019 10:29:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------6D65B140EEE9CF4491F9BC6F"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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, 22 Nov 2019 09:29:59 -0000

This is a multi-part message in MIME format.
--------------6D65B140EEE9CF4491F9BC6F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


Am 22.11.19 um 04:36 schrieb Neil Jenkins:
> On Thu, 21 Nov 2019, at 00:00, Marten Gajda wrote:
>>
>> I like the idea of a separate SRULE. It allows you to declare series 
>> of recurring events. That way you can specify more complex recurrence 
>> patterns which you can't express with a single RRULE.
>>
>
> I'm not sure exactly what you mean by this; do you just mean you can 
> have multiple recurrence rules? Because that's no reason why a 
> VTEMPLATEEVENT can't have multiple RRULE properties. I don't think 
> SRULE was any different to RRULE other than being a different name to 
> differentiate it when sharing a component namespace, which is not 
> required if it's a different component.

I'm not talking about merely merging the instances of multiple RRULES. 
When we have an SRULE, the RRULE property would not be interpreted by 
the series and go as-is into the resulting VEVENT.

Consider this series:

DTSTART:20190611T12:00:00Z
SRULE:FREQ=YEARLY;BYMONTH=6;BYDAY=2MO
RRULE:FREQ=DAILY;COUNT=4

It would result in the following first few VEVENTS

DTSTART:20190611T12:00:00Z
RRULE:FREQ=DAILY;COUNT=4

DTSTART:20200608T12:00:00Z
RRULE:FREQ=DAILY;COUNT=4

DTSTART:20210614T12:00:00Z
RRULE:FREQ=DAILY;COUNT=4

This results in composition of recurrence pattern rather than of the 
union of both recurrence patterns, i.e. you first apply the SRULE and 
then apply the RRULE on every result of the SRULE.

Also I want to advice against calling the object VTEMPLATEEVENT. 
VEVENTSERIES would be a better name because this is not what I would 
expect from a true template. From a template I'd expect to support 
placeholders I can provide when instantiating the template into a VEVENT.

Marten


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

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

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


--------------6D65B140EEE9CF4491F9BC6F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
Am 22.11.19 um 04:36 schrieb Neil
      Jenkins:

    

    

      
      
      
      
On Thu, 21 Nov 2019, at 00:00, Marten Gajda wrote:

      

      

        
I like the idea of a separate SRULE. It allows you to declare
          series of recurring events. That way you can specify more
          complex recurrence patterns which you can't express with a
          single RRULE.

        

      

      


      

      
I'm not sure exactly what you mean by this; do you just mean
        you can have multiple recurrence rules? Because that's no reason
        why a VTEMPLATEEVENT can't have multiple RRULE properties. I
        don't think SRULE was any different to RRULE other than being a
        different name to differentiate it when sharing a component
        namespace, which is not required if it's a different component.

      

    

    
I'm not talking about merely merging the instances of multiple
      RRULES. When we have an SRULE, the RRULE property would not be
      interpreted by the series and go as-is into the resulting VEVENT.

    
Consider this series:

    
DTSTART:20190611T12:00:00Z

      SRULE:FREQ=YEARLY;BYMONTH=6;BYDAY=2MO

      RRULE:FREQ=DAILY;COUNT=4

    

    
It would result in the following first few VEVENTS

    

    
DTSTART:20190611T12:00:00Z

      RRULE:FREQ=DAILY;COUNT=4

    

    
DTSTART:20200608T12:00:00Z

      RRULE:FREQ=DAILY;COUNT=4

    

    
DTSTART:20210614T12:00:00Z

      RRULE:FREQ=DAILY;COUNT=4

    

    
This results in composition of recurrence pattern rather than of
      the union of both recurrence patterns, i.e. you first apply the
      SRULE and then apply the RRULE on every result of the SRULE.

    
Also I want to advice against calling the object VTEMPLATEEVENT.
      VEVENTSERIES would be a better name because this is not what I
      would expect from a true template. From a template I'd expect to
      support placeholders I can provide when instantiating the template
      into a VEVENT.

    
Marten

    

    

    


    

    

      


      

      
Neil.

      

      

      

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


    

    
-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

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

  


--------------6D65B140EEE9CF4491F9BC6F--


From nobody Fri Nov 22 01:35: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 F0E00120106 for ; Fri, 22 Nov 2019 01:35:47 -0800 (PST)
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=uDIKW2tT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wl4+Z0Mu
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 0R5hQOOSr9LM for ; Fri, 22 Nov 2019 01:35:46 -0800 (PST)
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 A1F91120048 for ; Fri, 22 Nov 2019 01:35:46 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 5258A10E2 for ; Fri, 22 Nov 2019 04:35:44 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Fri, 22 Nov 2019 04:35:44 -0500
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=fm1; bh=CbkpDfd s7hpPGOpFfl+TNnMpurKZ/DyaMAJDGHVm4JY=; b=uDIKW2tTbrBS2CR+J2OW54K bpRlTSIyRCUlh3FHA9hsC8Jj++Bb4cw1ijhebzTSE3ZIMxll2yha6KNH6s/01fjK HHZyWk0OTWtxbwE8ywmeIadZwHMmtZMKwOv9g9VfIuBODbG7sJqpxUX8PdVRJd5V DzAk9s+zFdC0CK/L9m2bINDTJcNltLgqjZjPJqNzTBzlV3QiRE1wOGltMLuHxdA9 3IapV9ruYmb04CllGlA3wn+5JGUeJ0Nza7J6glFm1zksliFVg8kjaSArnhPJy+aE P5jaL+gx90DWJrMWPC/0E0ztqAA1E34QcBNCSgVdsxhUzwdr7WgrTuFReiTo3AA= =
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=fm1; bh=CbkpDf ds7hpPGOpFfl+TNnMpurKZ/DyaMAJDGHVm4JY=; b=wl4+Z0MuS8WXvQ2l50uObr re9cb+hr4TTlFMe/tMM6M57fsPvYqGVf+AsmpB5gG6CQ4qVqCGMOipW/K2ADVTkS bE9fit+GMm5Q4gviuuPF26xPSNrVaq2j/RE3cu2cWeuxbC72xDVl745TSFZKjAP8 DUeH1kKebWBGE3vXOYYauvVLI0bHBwl2+sGnTXTcL79phmgmKSnydxys1s463y/2 5DGWmA1nBII6w7u7c0AWiRVuL0u6K0KwoLJemDRSfCm6u5Bk23HrOvNe9sDzy17g i7uLzcqmR8gVHsDoKffDprLvVZScURI7aHczRzGuJO2puUv5jtzeX7E98V5Vn/dQ ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehgedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id ADBB1300E44; Fri, 22 Nov 2019 04:35:43 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org>
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com> <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org>  <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org>
Date: Fri, 22 Nov 2019 17:35:22 +0800
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=1b21727909764ab985d0f80dea459d1b
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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, 22 Nov 2019 09:35:48 -0000

--1b21727909764ab985d0f80dea459d1b
Content-Type: text/plain

On Fri, 22 Nov 2019, at 17:29, Marten Gajda wrote:
> I'm not talking about merely merging the instances of multiple RRULES. When we have an SRULE, the RRULE property would not be interpreted by the series and go as-is into the resulting VEVENT.


If that was the intention, I clearly missed that when reading the draft. That seems to me to miss the whole point of this feature, which is to generate individual instances for each occurrence so you can then edit the properties on each one without building up a massive ball of overrides. I do not think you should be able to generate events in a series which themselves contain a recurrence rule.

> Also I want to advice against calling the object VTEMPLATEEVENT. VEVENTSERIES would be a better name


Sure, no objection to that.

Neil.
--1b21727909764ab985d0f80dea459d1b
Content-Type: text/html


On Fri, 22 Nov 2019, at 17:29, Marten Gajda wrote:
I'm not talking about merely merging the instances of multiple
      RRULES. When we have an SRULE, the RRULE property would not be
      interpreted by the series and go as-is into the resulting VEVENT.

If that was the intention, I clearly missed that when reading the draft. That seems to me to miss the whole point of this feature, which is to generate individual instances for each occurrence so you can then edit the properties on each one without building up a massive ball of overrides. I do not think you should be able to generate events in a series which themselves contain a recurrence rule.

Also I want to advice against calling the object VTEMPLATEEVENT.
      VEVENTSERIES would be a better name

Sure, no objection to that.

Neil.

--1b21727909764ab985d0f80dea459d1b--


From nobody Fri Nov 22 02:10: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 76AD212080E for ; Fri, 22 Nov 2019 02:10:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level: 
X-Spam-Status: No, score=-1.996 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 rMc4MH4zZQOB for ; Fri, 22 Nov 2019 02:10:52 -0800 (PST)
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 9B6871202A0 for ; Fri, 22 Nov 2019 02:10:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20191106;  h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=l5POVocyMrAtom59aT98iOCk7ONdp+aWK+Kmd2iS3H4=; b=f4ZDJUgHF+TbxCKs0w7IXJBsFq0eyZYyfNw7H41DeExeq/ggeHiuRQtlKbaJPor32UQTvcPvfvjw3 j7NtBrL0/WNdiQIctmDRTY+F8Tm66DwGVSbbcp/sSO9X26awHoOdJyLkoQ0sApzrVAIxyyx3BjIUAm 7X3tp+BkwGtNglDekjYHkF4FxdykO8ol8IedGqEM4+iESUFoRpyBDvwY0xCTQcK71v3zNUzRf9S4ZL N7pokTF3QSh8lTDwmtRh5Rt9avcuasgOuK6x5kENd74SsyJ7I7+tG6HRXs8YSTWjT+nyBrTaiakMdv DJMtc08IT0H2s5NQLCh8I7CwJ+5cDGA==
X-HalOne-Cookie: a56047c99176dde6cb01434c5046a2c984db510f
X-HalOne-ID: 5b936a82-0d10-11ea-b5f1-d0431ea8bb03
Received: from smtp.dmfs.org (unknown [2003:fa:af05:8e00:201:2eff:fe40:2624]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 5b936a82-0d10-11ea-b5f1-d0431ea8bb03; Fri, 22 Nov 2019 10:10:49 +0000 (UTC)
Received: from boss.localdomain (pD95ED904.dip0.t-ipconnect.de [217.94.217.4]) by smtp.dmfs.org (Postfix) with ESMTPSA id 63837136E for ; Fri, 22 Nov 2019 11:10:49 +0100 (CET)
To: calsify@ietf.org
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com> <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org>  <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org> 
From: Marten Gajda 
Message-ID: 
Date: Fri, 22 Nov 2019 11:10:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------58B0794940E0FC67DD544FF9"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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, 22 Nov 2019 10:10:55 -0000

This is a multi-part message in MIME format.
--------------58B0794940E0FC67DD544FF9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


Am 22.11.19 um 10:35 schrieb Neil Jenkins:
> On Fri, 22 Nov 2019, at 17:29, Marten Gajda wrote:
>>
>> I'm not talking about merely merging the instances of multiple 
>> RRULES. When we have an SRULE, the RRULE property would not be 
>> interpreted by the series and go as-is into the resulting VEVENT.
>>
>
> If that was the intention, I clearly missed that when reading the 
> draft. That seems to me to miss the whole point of this feature, which 
> is to generate individual instances for each occurrence so you can 
> then edit the properties on each one without building up a massive 
> ball of overrides. I do not think you should be able to generate 
> events in a series which themselves contain a recurrence rule.

Right, this probably wasn't the intention, but there is nothing in the 
draft which contradicts this use case either. It doesn't introduce any 
complexity. Series expansion would be agnostic to RRULE. Why would we 
artificially limit the resulting events in their properties?

Just addressing the overrides issue would be too short sighted IMO. This 
draft has the potential to fix many more issues with recurring events. I 
mentioned it before; I'd really like to see a future extension which 
allows to determine occurrences of events based on other calendars. For 
instance, often I sit there and delete instances of a recurring event 
which fall on a holiday or on school holidays. What I want to express is 
"this event occurs every week unless it would overlap an event in this 
calendar of (school) holidays". Often school holidays are not known very 
far in advance and may change every year, so a mechanism which evaluates 
them just a few months in advance would be helpful.

Marten


> _______________________________________________
> 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


--------------58B0794940E0FC67DD544FF9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
Am 22.11.19 um 10:35 schrieb Neil
      Jenkins:

    

    

      
      
      
      
On Fri, 22 Nov 2019, at 17:29, Marten Gajda wrote:

      

      

        
I'm not talking about merely merging the instances of
          multiple RRULES. When we have an SRULE, the RRULE property
          would not be interpreted by the series and go as-is into the
          resulting VEVENT.

        

      

      


      

      
If that was the intention, I clearly missed that when reading
        the draft. That seems to me to miss the whole point of this
        feature, which is to generate individual instances for each
        occurrence so you can then edit the properties on each one
        without building up a massive ball of overrides. I do not think
        you should be able to generate events in a series which
        themselves contain a recurrence rule.

      

    

    
Right, this probably wasn't the intention, but there is nothing
      in the draft which contradicts this use case either. It doesn't
      introduce any complexity. Series expansion would be agnostic to
      RRULE. Why would we artificially limit the resulting events in
      their properties?

    
Just addressing the overrides issue would be too short sighted
      IMO. This draft has the potential to fix many more issues with
      recurring events. I mentioned it before; I'd really like to see a
      future extension which allows to determine occurrences of events
      based on other calendars. For instance, often I sit there and
      delete instances of a recurring event which fall on a holiday or
      on school holidays. What I want to express is "this event occurs
      every week unless it would overlap an event in this calendar of
      (school) holidays". Often school holidays are not known very far
      in advance and may change every year, so a mechanism which
      evaluates them just a few months in advance would be helpful.

    

    
Marten

    

    


    

    

      

      
_______________________________________________
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

  


--------------58B0794940E0FC67DD544FF9--


From nobody Sun Nov 24 09:05:33 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 BB6C3120058 for ; Sun, 24 Nov 2019 09:05:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level: 
X-Spam-Status: No, score=-0.597 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, 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 YjPIqrLplABs for ; Sun, 24 Nov 2019 09:05:30 -0800 (PST)
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 F2EE7120052 for ; Sun, 24 Nov 2019 09:05:29 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id q70so10633942qke.12 for ; Sun, 24 Nov 2019 09:05:29 -0800 (PST)
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=TZxKt41Kd1vDuE+URDeYamTBnbaWZc6CQKPCwLqhl54=; b=Wisr+doXXYVDxQ5Ao7daJUDHIR20qGBsdHjlqXWIYmQhlD+8HJh3E3MGGmo6m+Q4dn c6sdHy9tG3ZL6J65EgGBj7iZXIo/RnkYaqlJLsfCwLuPlfg5R+QOvXucu5y1Rz+rj5sg 4txLkWI2Yg36ZuOxifohpYHMfcOKP9vRWeV7t9fkZhwyvEQFUkjuqmNXr+fEml3WjZRb WfnVVvyELIpOeiGI+wd8iQ3wYrxZO3V8YDF4jM9Xc47WnC2THc4eAKmQPHqSoQtlhHgG Igsw1EKwhO52XgWVyl/1rc4haqQyAsznp34qiuvKszh4ngH42lqLxxAO6D0rHZEVCxnY SlrA==
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=TZxKt41Kd1vDuE+URDeYamTBnbaWZc6CQKPCwLqhl54=; b=adxa5bIO+anUPJCXHOHrmTJZmoY2XY0Zf+O1IuAFIpOBfqAaSOa+CXNmi9oBiz0Emx sKY3uBqiXI0tRAFRhSHDNeim0s3HPhyYJFC6WIXxNkJgvgXu9c2U8e8WKAVCsG8+B4tA GT+BV6xPEciIgVJ8qSK4ReD+rKvn0legsUL5SanF6Uq7qISVWUjbZZ/LPL3DnOibmf8b pHqA0gqftAutMQTFNb+0oy36qTDvABDTbgC24aZzwaVDZI1Ek5rmoTylaRVpbb06RxgU e5SuRMneVfjE57dn/S8HrjtBYREVZaU1SjKk6IAGHJv8c1mCEka3xIfICn2wtWajKUwY iTJQ==
X-Gm-Message-State: APjAAAXO7Zg7RoyAcd/ndgZajkGxI6a7UuVYhb7mJiyAWWFskaTuxKn7 HORij1xVdxsTs5CTry3lzCsUJLyFFxo=
X-Google-Smtp-Source: APXvYqzoZ7ukPbrfzYglaMz47cYnvuzpIPiCnvFvHV3GlEeEJUIvegNjtQEQv585iGzJaTWObzGb0Q==
X-Received: by 2002:a05:620a:12cb:: with SMTP id e11mr22939354qkl.247.1574615128821;  Sun, 24 Nov 2019 09:05:28 -0800 (PST)
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 p188sm2046673qkb.94.2019.11.24.09.05.27 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Nov 2019 09:05:28 -0800 (PST)
To: calsify@ietf.org
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com> <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org>  <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org>
From: Michael Douglass 
Message-ID: <079179eb-981c-c791-e49c-63f26bf8d5d1@gmail.com>
Date: Sun, 24 Nov 2019 12:05:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org>
Content-Type: multipart/alternative; boundary="------------25733F37F8ACF8000C11DC2F"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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: Sun, 24 Nov 2019 17:05:32 -0000

This is a multi-part message in MIME format.
--------------25733F37F8ACF8000C11DC2F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


On 11/22/19 04:29, Marten Gajda wrote:
>
> Also I want to advice against calling the object VTEMPLATEEVENT. 
> VEVENTSERIES would be a better name because this is not what I would 
> expect from a true template. From a template I'd expect to support 
> placeholders I can provide when instantiating the template into a VEVENT.
>
I was going to suggest the same. The master template approach resolves 
all the issues over whether or not the master is o is not a member of 
the recurrence set.
>
> Marten
>
>
>>
>> Neil.
>>
>> _______________________________________________
>> calsify mailing list
>> calsify@ietf.org
>> https://www.ietf.org/mailman/listinfo/calsify
> -- 
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: +49 177 4427167
> email:marten@dmfs.org
>
> Managing Director: Marten Gajda
> Registered address: Dresden
> Registered No.: AG Dresden HRB 34881
> VAT Reg. No.: DE303248743
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

--------------25733F37F8ACF8000C11DC2F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 11/22/19 04:29, Marten Gajda wrote:

    

    

      
      
Also I want to advice against calling the object
        VTEMPLATEEVENT. VEVENTSERIES would be a better name because this
        is not what I would expect from a true template. From a template
        I'd expect to support placeholders I can provide when
        instantiating the template into a VEVENT.

    

    I was going to suggest the same. The master template approach
    resolves all the issues over whether or not the master is o is not a
    member of the recurrence set. 

    

      
Marten

      
 

      


      

      

        


        

        
Neil.

        

        

        

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


      

      
-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

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

      

      

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


    

  


--------------25733F37F8ACF8000C11DC2F--


From nobody Sun Nov 24 09:18: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 2A213120052 for ; Sun, 24 Nov 2019 09:18:44 -0800 (PST)
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 GXVftPTHuenR for ; Sun, 24 Nov 2019 09:18:41 -0800 (PST)
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 21D8412001E for ; Sun, 24 Nov 2019 09:18:41 -0800 (PST)
Received: by mail-qt1-x82c.google.com with SMTP id r20so14366855qtp.13 for ; Sun, 24 Nov 2019 09:18:41 -0800 (PST)
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=nhTO2E9w8InPn/knTQ/Auk1MGLFY5shnu/j5Fev7cto=; b=XaLMpG6AC94+JipqYFS33cQveRNNY8ylK8DeCHEMAgzze+qWlKAvp5NFJTZ7PoKimo coobvPh8VzA1obuv4sUgUWQ9fVeS5r9VtxoJ/2lTqsdELre+wIX4ugP/lWe++XbpvJvT 2eRyKXHyMjJz9glAoWgIPvLbOGZtbNp7SrYjsmewZh9602CfDEqbL/geSh0BvKISHhMj D7CudA2uhlqk/OM4gWjZQwrnstmDw3HHJzfQ+3zMPZdUrs79OD3rGvAF40a1Ay37QpbG /6TjAAp875ZRo7ShFzXa1ujHZ1xWU/BIhcUyArDbvMXhPB80YNrDSpLUbN4Vn0j7VM+Q QPXw==
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=nhTO2E9w8InPn/knTQ/Auk1MGLFY5shnu/j5Fev7cto=; b=k7/zgOgbNwehjhwX8gy8H7DqAIIwFphgogtOtTmlDO+uve/dhCTFzuIGPejm1U24/v 2vLZXiFzjgHdWRBwQAGzJ7DW1VcSG0pEJGlfvUm4tOchN4b247WTSzdL3Pa6JfGi380J oqX/m/nQ7psCM+L+MJrSPduwddXGPFz5yUXfIvEws6oaYmv76oDfkBbS6OXJdH+Bk3yG mLr0rV1WhQOx5SO5yyCs/O9mmpfQyJohejRJHRYeJG7327okQmMnjSn9LvT49gn+MjXU bmO4ca25S+3rATB0hX/n+IMnhk/vHuVF7uoo/TRYa7WATsieCX3hN9oqb3bTHBZVFeU5 nnwA==
X-Gm-Message-State: APjAAAU36bOj2Yw/IKAd43FuQRbIpTu7QKQ2pkDc9Gptx8aqLM/eIxau ez2fCbml1v9JXT34EmU7AmwQok1CAwA=
X-Google-Smtp-Source: APXvYqynJZJRtVDhlEEjQWqFXZp40FnNAhR1wIfVRbnH5ExgS4XEP88uqkraTdrK6KCmGPkF4ASnXQ==
X-Received: by 2002:ac8:f30:: with SMTP id e45mr25026961qtk.222.1574615919868;  Sun, 24 Nov 2019 09:18:39 -0800 (PST)
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 n19sm2062773qkn.52.2019.11.24.09.18.39 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Nov 2019 09:18:39 -0800 (PST)
To: calsify@ietf.org
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com> <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org>  <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org>  
From: Michael Douglass 
Message-ID: <03c33363-a782-ce2f-01dd-64ceddbec60c@gmail.com>
Date: Sun, 24 Nov 2019 12:18:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------DC20DDEC887D311D7EECF636"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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: Sun, 24 Nov 2019 17:18:44 -0000

This is a multi-part message in MIME format.
--------------DC20DDEC887D311D7EECF636
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


On 11/22/19 05:10, Marten Gajda wrote:
>
>
> Am 22.11.19 um 10:35 schrieb Neil Jenkins:
>> On Fri, 22 Nov 2019, at 17:29, Marten Gajda wrote:
>>>
>>> I'm not talking about merely merging the instances of multiple 
>>> RRULES. When we have an SRULE, the RRULE property would not be 
>>> interpreted by the series and go as-is into the resulting VEVENT.
>>>
>>
>> If that was the intention, I clearly missed that when reading the 
>> draft. That seems to me to miss the whole point of this feature, 
>> which is to generate individual instances for each occurrence so you 
>> can then edit the properties on each one without building up a 
>> massive ball of overrides. I do not think you should be able to 
>> generate events in a series which themselves contain a recurrence rule.
>
> Right, this probably wasn't the intention, but there is nothing in the 
> draft which contradicts this use case either. It doesn't introduce any 
> complexity. Series expansion would be agnostic to RRULE. Why would we 
> artificially limit the resulting events in their properties?
>
> Just addressing the overrides issue would be too short sighted IMO. 
> This draft has the potential to fix many more issues with recurring 
> events. I mentioned it before; I'd really like to see a future 
> extension which allows to determine occurrences of events based on 
> other calendars. For instance, often I sit there and delete instances 
> of a recurring event which fall on a holiday or on school holidays. 
> What I want to express is "this event occurs every week unless it 
> would overlap an event in this calendar of (school) holidays". Often 
> school holidays are not known very far in advance and may change every 
> year, so a mechanism which evaluates them just a few months in advance 
> would be helpful.
>
> Marten
>
It was not stated explicitly in the draft and i hadn't considered it.

We have 2 choices (I think).

1. We allow the generation of recurrences - in this case we do have to 
duplicate all the recurring properties as the current spec states.

2. We choose to reuse the current recurrence properties which prohibits 
the generation of recurrences.


There's a whole other issue which I've already raised elsewhere: 
multiple RRULEs and SRULES SHOULD be supported. That would deal with 
many cases. For Martens benefit I have come across users generating up 
to 7 identical recurring events to cover a 6 week series and then having 
to keep each one identical as they make changes. A simple multiple rrule 
would have been much easier for them. It's also true that even if it's 
possible to generate a single rule it's often much easier to understand 
(and create) multiple rrules.

On the other hand the issue Marten raises - skip the event if it falls 
on some special date - may be better dealt with by a new relation type.

Series 1 generates a simple set of instances - e.g every Monday.

An exclusion relation points to another series, recurring event or 
single event. All instances of that - now and into the future - exclude 
instances of series 1.

This does require some rules. e.g. series 1 may generate 1 hour 
meetings. the referenced series may generate all day. I think the rule 
is something like the exclusion event masks the instance. So an all day 
blocks completely - an overlap reduces the length of the instance etc.


>
>> _______________________________________________
>> 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

--------------DC20DDEC887D311D7EECF636
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 11/22/19 05:10, Marten Gajda wrote:

    

    

      
      


      

      
Am 22.11.19 um 10:35 schrieb Neil
        Jenkins:

      

      

        
        
        
        
On Fri, 22 Nov 2019, at 17:29, Marten Gajda wrote:

        

        

          
I'm not talking about merely merging the instances of
            multiple RRULES. When we have an SRULE, the RRULE property
            would not be interpreted by the series and go as-is into the
            resulting VEVENT.

          

        

        


        

        
If that was the intention, I clearly missed that when
          reading the draft. That seems to me to miss the whole point of
          this feature, which is to generate individual instances for
          each occurrence so you can then edit the properties on each
          one without building up a massive ball of overrides. I do not
          think you should be able to generate events in a series which
          themselves contain a recurrence rule.

        

      

      
Right, this probably wasn't the intention, but there is nothing
        in the draft which contradicts this use case either. It doesn't
        introduce any complexity. Series expansion would be agnostic to
        RRULE. Why would we artificially limit the resulting events in
        their properties?

      
Just addressing the overrides issue would be too short sighted
        IMO. This draft has the potential to fix many more issues with
        recurring events. I mentioned it before; I'd really like to see
        a future extension which allows to determine occurrences of
        events based on other calendars. For instance, often I sit there
        and delete instances of a recurring event which fall on a
        holiday or on school holidays. What I want to express is "this
        event occurs every week unless it would overlap an event in this
        calendar of (school) holidays". Often school holidays are not
        known very far in advance and may change every year, so a
        mechanism which evaluates them just a few months in advance
        would be helpful.

      

      
Marten

      

    

    
It was not stated explicitly in the draft and i hadn't considered
      it.

    

    
We have 2 choices (I think). 

    

    
1. We allow the generation of recurrences - in this case we do
      have to duplicate all the recurring properties as the current spec
      states.

    
2. We choose to reuse the current recurrence properties which
      prohibits the generation of recurrences. 

    

    


    

    
There's a whole other issue which I've already raised elsewhere:
      multiple RRULEs and SRULES SHOULD be supported. That would deal
      with many cases. For Martens benefit I have come across users
      generating up to 7 identical recurring events to cover a 6 week
      series and then having to keep each one identical as they make
      changes. A simple multiple rrule would have been much easier for
      them. It's also true that even if it's possible to generate a
      single rule it's often much easier to understand (and create)
      multiple rrules. 

    

    
On the other hand the issue Marten raises - skip the event if it
      falls on some special date - may be better dealt with by a new
      relation type.

    
Series 1 generates a simple set of instances - e.g every Monday.
      

    

    
An exclusion relation points to another series, recurring event
      or single event. All instances of that - now and into the future -
      exclude instances of series 1.

    
This does require some rules. e.g. series 1 may generate 1 hour
      meetings. the referenced series may generate all day. I think the
      rule is something like the exclusion event masks the instance. So
      an all day blocks completely - an overlap reduces the length of
      the instance etc. 

    

    


    

    

      
 

      


      

      

        

        
_______________________________________________
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


    

  


--------------DC20DDEC887D311D7EECF636--


From nobody Sun Nov 24 15:33: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 BF32F1200C5 for ; Sun, 24 Nov 2019 15:33:05 -0800 (PST)
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=P7p/I+1P; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Kz3ul7LP
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 SlYk5yK3T1jq for ; Sun, 24 Nov 2019 15:33:04 -0800 (PST)
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 9053D12001E for ; Sun, 24 Nov 2019 15:33:04 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A00055F8 for ; Sun, 24 Nov 2019 18:33:03 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Sun, 24 Nov 2019 18:33:03 -0500
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=fm1; bh=zhjUG9L wmR30Q4rgPorVGku/BK1Y9t2IPJ3Th9GOB+w=; b=P7p/I+1Pb3n7YL9mABPj/v6 ibVxGhQs6n11J5nuPVp3/VrsxAOvB73GXlh/zxWPodmZA1lMxodxrZQGBztNU4pb aA3o43eraG4Ze2CXsIZ66pn7+r9N3SJ38F/gN6JoYPqnzQeWpgICoZ2Dc6MacNaR xh8fObNAa2k2O68BI3YUWb/g+BSTwgUVNFmTTqDwa+TawLbNBGQC7/fbOC5PMVOj w4vCe8OTVOX8Y0XYct96Hs2qrAkpJcu/hiG3XAJVQ9pFgoIc90rik01zr5CHNRwu SWkWoo6WN5MGMLdHIQ0vuGTpeMkeuYY9sWHkZiQQWHnF1XYJrwC+cafc7Qw98kg= =
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=fm1; bh=zhjUG9 LwmR30Q4rgPorVGku/BK1Y9t2IPJ3Th9GOB+w=; b=Kz3ul7LPokm4tyCFdY8ygF tdtGrf2ZcPlapqx9WgrhLPtP8eBUB/K1Wqbs1bjfxVF1otgpSsAgXAg59od983fZ kKb12Iraax07DpQppTZnkME/gTIDpojm6WU+HH/GG+AcLL0Zju7TR2gJ35rTYtkh StxCMjGI8DqqUkbfySLxfeMdYwb/mSOMpnx7K8IhFACFph0MMLwC9YxLKazFADTA KpKFU9fgZEsv/P3Nu/ZA0ZyYmpE4NE1OGwy2apss6y2bB/DG31ZbYiR1tWDYjWcy vzFzxkm2Y6/JWL7wBXuS6xltL0UhG+YbccsgJEGkLMlWd36gnaOFEicfhDTtkJjA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehledgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id EAFC33038F9; Sun, 24 Nov 2019 18:33:02 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <03c33363-a782-ce2f-01dd-64ceddbec60c@gmail.com>
References: <1f7475db-bcad-4c27-bb30-f043665b1f96@dogfood.fastmail.com> <7773f271-9273-db87-511c-81ee19a30ec4@gmail.com> <2597b107-c18a-c523-e247-cc3d03620660@dmfs.org>  <07f93d9e-ae64-fb86-2a1d-c290428a585c@dmfs.org>   <03c33363-a782-ce2f-01dd-64ceddbec60c@gmail.com>
Date: Mon, 25 Nov 2019 10:32:41 +1100
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=9f95c3add2da401ebf32883f94bbee7d
Archived-At: 
Subject: Re: [calsify] Feedback on draft-ietf-calext-icalendar-series
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: Sun, 24 Nov 2019 23:33:06 -0000

--9f95c3add2da401ebf32883f94bbee7d
Content-Type: text/plain

On Mon, 25 Nov 2019, at 04:18, Michael Douglass wrote:
> 2. We choose to reuse the current recurrence properties which prohibits the generation of recurrences. 


I am very much in favour of this option. Keeping the complexity down is important to help adoption (and reduce likelihood of interoperability issues) and make it usable.

> An exclusion relation points to another series, recurring event or single event. All instances of that - now and into the future - exclude instances of series 1.


I am wary that this also adds quite a lot of complexity and I am doubtful it is worth it over just adding EXDATEs to the series master.

Neil.
--9f95c3add2da401ebf32883f94bbee7d
Content-Type: text/html


On Mon, 25 Nov 2019, at 04:18, Michael Douglass wrote:
2. We choose to reuse the current recurrence properties which
      prohibits the generation of recurrences. 

I am very much in favour of this option. Keeping the complexity down is important to help adoption (and reduce likelihood of interoperability issues) and make it usable.

An exclusion relation points to another series, recurring event
      or single event. All instances of that - now and into the future -
      exclude instances of series 1.

I am wary that this also adds quite a lot of complexity and I am doubtful it is worth it over just adding EXDATEs to the series master.

Neil.

--9f95c3add2da401ebf32883f94bbee7d--


From nobody Tue Nov 26 12:50: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 3E900120AEE for ; Tue, 26 Nov 2019 12:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LQB2SQFiW4a for ; Tue, 26 Nov 2019 12:50:46 -0800 (PST)
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 87912120AC9 for ; Tue, 26 Nov 2019 12:50:46 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id D6E1AF406F6; Tue, 26 Nov 2019 12:50:20 -0800 (PST)
To: bernard.desruisseaux@oracle.com, ben@nostrum.com, aamelnikov@fastmail.fm,  adam@nostrum.com, lear@cisco.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: LarsHenriksen@get2net.dk, calsify@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20191126205020.D6E1AF406F6@rfc-editor.org>
Date: Tue, 26 Nov 2019 12:50:20 -0800 (PST)
Archived-At: 
Subject: [calsify] [Technical Errata Reported] RFC5545 (5920)
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, 26 Nov 2019 20:50:49 -0000

The following errata report has been submitted for RFC5545,
"Internet Calendaring and Scheduling Core Object Specification (iCalendar)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5920

--------------------------------------
Type: Technical
Reported by: Lars Henriksen 

Section: 3.8.5.3

Original Text
-------------
Every Friday the 13th, forever:

       DTSTART;TZID=America/New_York:19970902T090000
       EXDATE;TZID=America/New_York:19970902T090000
       RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13

       ==> (1998 9:00 AM EST) February 13;March 13;November 13
           (1999 9:00 AM EDT) August 13
           (2000 9:00 AM EDT) October 13
           ...

Corrected Text
--------------
Every Friday the 13th, forever:

       DTSTART;TZID=America/New_York:19980213T090000
       RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13

       ==> (1998 9:00 AM EST) February 13;March 13;November 13
           (1999 9:00 AM EDT) August 13
           (2000 9:00 AM EDT) October 13
           ...

Notes
-----
The "DTSTART" property is not synchronized with the recurrence rule.

Although it may be removed from the recurrence set by an "EXDATE" property, the description at the start of section 3.8.5.3 leaves no doubt that the "DTSTART" property should still be synchronized with the recurrence rule.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5545 (draft-ietf-calsify-rfc2445bis-10)
--------------------------------------
Title               : Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Publication Date    : September 2009
Author(s)           : B. Desruisseaux, Ed.
Category            : PROPOSED STANDARD
Source              : Calendaring and Scheduling Standards Simplification
Area                : Applications
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Nov 26 13:40: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 98650120B3D for ; Tue, 26 Nov 2019 13:40:42 -0800 (PST)
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 S2iAMUdRuMlT for ; Tue, 26 Nov 2019 13:40:41 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 10ED5120B2C for ; Tue, 26 Nov 2019 13:40:41 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id o18so19034829ils.12 for ; Tue, 26 Nov 2019 13:40:41 -0800 (PST)
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=cHlAfpkrlFdMvZKoPY6kfbNkKyrvPezUMKed4idcfsQ=; b=etpsc9orLoipQ42RsvuGvLMqPCmaAtq1fKKMWOGPvQkp3CHHD5NIcIHGuwaxdPwiel 4wv8HD/9iscUjzKbvY3TI3sijUFg9O3LVvecrRNV0/0Ypw8LcGZN475vf9bjZoQ9bKx9 MUO6ijpV0Lab5KtZ9jYWJvN2iLRao9wi1UrOhETStCsGmUkh3GkC+Zqp0nwzV81eZY8x eTXMh4jTjZySym0pJsqFdrV6K/qNXD8rjMq5I74ucdQtLCOnM4m4yuAD++GRP4yVsZUz HISLvgNutrfNYVzMZbwUBbtpAPTLxa2Qkc/sd/WZ5ftOCyUhbH9qm9WSpfo0nWJR+F6X k7zQ==
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=cHlAfpkrlFdMvZKoPY6kfbNkKyrvPezUMKed4idcfsQ=; b=cbsssH+e5wyuYOgMVEWjdfP2RPXZiZwgbWhobD/94+9qd8peApvZ5APGck6UHyFb73 eIR36H8Cb6uLWq4w06faxhafD9203zqqYuSlWBydJzjOx5mgH9pqhgg+6hEyA6qGdE1e XD2hGB4gV+QZiD1Lgc6wJpJC0gltB0WRW+bLzNaIyaTen49kTpNG7JgcrNV5uRiTZZ2c IvOeKz89HhbwXD4XnmDKYku6SjJDMl1JFZ9dFkLVcVFMjbguusXvl09QUUw1sh0xaclm aCGHGy/KV/u6Q8b0W/953/xUivXtx6r3TNLbjnEnynDgIy+6YWd+pP/TgzsQQiHQH+0B J4bw==
X-Gm-Message-State: APjAAAWgLGJQz/lydMpP5pfC1cKOGT5b5wZ0gEDtvn35GROXA2UIobOw dti6fFxH/Hh5Gn5LnVJ4gufT29p/Ba0Q++c=
X-Google-Smtp-Source: APXvYqzClZltfiySmnlrhzTj7WcdFBcmx4cXW8w/ZGS9KdE7E3gLk+LhsgdrNk6l/CFh55D6lwWHug==
X-Received: by 2002:a92:4010:: with SMTP id n16mr43377228ila.260.1574804439909;  Tue, 26 Nov 2019 13:40:39 -0800 (PST)
Received: from [192.168.1.7] ([174.27.90.145]) by smtp.googlemail.com with ESMTPSA id y16sm3058403ioj.26.2019.11.26.13.40.38 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Nov 2019 13:40:38 -0800 (PST)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: calsify@ietf.org
References: <20191126205020.D6E1AF406F6@rfc-editor.org>
Organization: http://SoftwareAndServices.NET
Message-ID: 
Date: Tue, 26 Nov 2019 14:40:37 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
MIME-Version: 1.0
In-Reply-To: <20191126205020.D6E1AF406F6@rfc-editor.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5920)
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, 26 Nov 2019 21:40:45 -0000

On 11/26/19 1:50 PM, RFC Errata System [Masked] wrote:

> Original Text
> -------------
> Every Friday the 13th, forever:
>
>         DTSTART;TZID=America/New_York:19970902T090000
>         EXDATE;TZID=America/New_York:19970902T090000
>         RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13
>
>         ==> (1998 9:00 AM EST) February 13;March 13;November 13
>             (1999 9:00 AM EDT) August 13
>             (2000 9:00 AM EDT) October 13
>             ...
>
> Corrected Text
> --------------
> Every Friday the 13th, forever:
>
>         DTSTART;TZID=America/New_York:19980213T090000
>         RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13
>
>         ==> (1998 9:00 AM EST) February 13;March 13;November 13
>             (1999 9:00 AM EDT) August 13
>             (2000 9:00 AM EDT) October 13
>             ...
>
> Notes
> -----
> The "DTSTART" property is not synchronized with the recurrence rule.
>
> Although it may be removed from the recurrence set by an "EXDATE" property, the description at the start of section 3.8.5.3 leaves no doubt that the "DTSTART" property should still be synchronized with the recurrence rule.

Did (do?) some implementations not do this? Why is it a "SHOULD" and not a "MUST"?

And 2445 said the same (and had the same example error):

   2445: The "DTSTART" property defines the first instance in the recurrence set.

5545 Current text (in 3.8.5.3):

The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified.
The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined.

Change To?

The "DTSTART" property value MUST be synchronized with first instance of the recurrence rule, if specified

And update Appendix A: "A.1".


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


From nobody Tue Nov 26 16:50:52 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 8A30D1200FA for ; Tue, 26 Nov 2019 16:50:51 -0800 (PST)
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=swU/mFvL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QmwFgI9s
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 DFXHushB-s8z for ; Tue, 26 Nov 2019 16:50:50 -0800 (PST)
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 E03A51208C0 for ; Tue, 26 Nov 2019 16:50:49 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 529C7227D9 for ; Tue, 26 Nov 2019 19:50:48 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Tue, 26 Nov 2019 19:50:48 -0500
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=fm1; bh=Ph8W0mR CdyejVNTXCeFfz2M8tz+eEefwS3FQVOD+fyw=; b=swU/mFvLf92FYXdq9+PPyPC +jL+1njLHpkvX6F7qqc7T7/OMyZtAKTDwd0x2sRZV7monJFUol44AhUuWSUCOaMv tlblMSPSrlvUucqF1USTdODAGBa4cd14dLeQOfZVmEmVrRp91vsr4tvpZ7GLPTxY PJIwwoCRqtRwi8/9MakQJLJWL1tpx/lijcFMKrKt5h+wcrLXlaHvdUOzZbXBDOw9 ysLZ4r9K3prTFkRQqVgIG2C0MO4fTLViDXXbu893UCFfkALmZTIyRR/AxwSOhK/U JAIKTtcJbWwaXn5dP3wILzvm0pnbCylB3rzDTxeaYleDkhpIsxvJtWW6O76uIXg= =
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=fm1; bh=Ph8W0m RCdyejVNTXCeFfz2M8tz+eEefwS3FQVOD+fyw=; b=QmwFgI9sIcBpFN/e80QXX6 87kpLF0bLOjmAUhLewi8baXozMqaBc3jY6WpBPbDxGfSfkc650BJefC4BvIFfmH2 4WFAT45crF5/9YVlOyJMyZUCel09N9iu2ir13inFAE1h1NFejjSVW2uWPUaK67Fa DYQSsa5Xj+PNhSwBT/VKk2Y4fxJBh+indqn6aRNDCN5NzZ1+R0ZM96C0cPp+cD7v PtdpDt+GckQk4ZcUf2/rXJ6GBs3DVFJEcSEVLcYT6QeyRgr/sPCMLPqLU4rQCOqZ 8E91MvpI3AcWJJICqMt/VOFgrSfBIAGmUfVB2UXeUKHgGXS7ndFiEdXe/6OhF7jg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeigedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0CC71309FD1; Tue, 26 Nov 2019 19:50:48 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1
Mime-Version: 1.0
Message-Id: <4416a485-c849-4fb0-bf47-0c3b971740cc@dogfood.fastmail.com>
In-Reply-To: 
References: <20191126205020.D6E1AF406F6@rfc-editor.org> 
Date: Wed, 27 Nov 2019 11:50:18 +1100
From: "Neil Jenkins" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=ea0f7a8f00334948894dc964e7b68cfb
Archived-At: 
Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5920)
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, 27 Nov 2019 00:50:51 -0000

--ea0f7a8f00334948894dc964e7b68cfb
Content-Type: text/plain

On Wed, 27 Nov 2019, at 08:40, Doug Royer wrote:
> Did (do?) some implementations not do this?

Definitely; in my testing in the past I think most clients could be made to generate an RRULE that doesn't match the start date. That's why in JSCalendar we dropped the requirement and defined how to interpret it regardless (I still think your UI will be clearer if you make them align, but that's another matter).

Neil.
--ea0f7a8f00334948894dc964e7b68cfb
Content-Type: text/html


On Wed, 27 Nov 2019, at 08:40, Doug Royer wrote:
Did (do?) some implementations not do this?

Definitely; in my testing in the past I think most clients could be made to generate an RRULE that doesn't match the start date. That's why in JSCalendar we dropped the requirement and defined how to interpret it regardless (I still think your UI will be clearer if you make them align, but that's another matter).

Neil.

--ea0f7a8f00334948894dc964e7b68cfb--


From nobody Tue Nov 26 22:01: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 ABA48120B45 for ; Tue, 26 Nov 2019 22:01:49 -0800 (PST)
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 zBLYpJpmSu0u for ; Tue, 26 Nov 2019 22:01:48 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 1A0B71208F1 for ; Tue, 26 Nov 2019 22:01:48 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id g1so14834177qtj.6 for ; Tue, 26 Nov 2019 22:01:48 -0800 (PST)
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=6u7Q63Ru4Fj5n81lZH7/P1HkoWPxbVNGPA3AJmVdfIs=; b=n0SI59qrmyeVqlPWApqHVkdG1Ly1UW3BW1HcGJ2KgDicYvZBr9/VbqmTAFIrXvkApQ 0h76kYGMD6Mt9YHQF5xgCF/EvUCueZor/KebVZ0+hhT5uAmF+7XaNhOuhkBfTsTYl4fc QTrItLijABkdyKxsYt3ovVcR499PQ9Uno6iaJqT428LsoWhePFhuD1qtCvtiYDTjhUUa xwW2rlSYcYay3Yw3tk1gh7KXmunrRrHAsHvfIqDJIxQeiUAx2C/4m8M1+LeC/Xk40cyw tkbrfSNZl1kF72ebixDr0SLLgfhycKVLqO6lsuYo6PmTrkGRPX44APMdZ8enVe8jqPad 0X3A==
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=6u7Q63Ru4Fj5n81lZH7/P1HkoWPxbVNGPA3AJmVdfIs=; b=bQJoQd9bJO1BBR4KDdkMczlII85WX+A96EVtpEcXtuDd4HUHI/i9by3YZ/2h73bQNK fUllHqoq+R1/VVxHjw1HvBtPqdq9iLk27aSaMFzeBCbiVOargb02SU3rUDlGAeOlnHLq Iy1ji3sB6bsXMYBNEOLl2G7oDl7YfqCl6FCXO3uwxEKzdVhxaIzBEDqLUulz7jjudlVn pXAjgNu+T7ceIJkQoq/xASo5GzUYq5DI45qsMNp7SGeRNc/u7JbvhrORcZ/TMFQImsKK BRir8TWEWUmg7FDgdJDMCQxcSrn8FEdgKzfCeknZBMd+JcAbtR211+kNGJQuVfx1CEtp lA4g==
X-Gm-Message-State: APjAAAVzNltE/g2NleHu+9PwYA2Y9wmqoITz5rmHxjYpo9nlJx1jAITB 8escdlsKMQHz85vKp+JLZtvfRN9L/Oc=
X-Google-Smtp-Source: APXvYqymDPFhEtUctnULGBLNPYLNvNV44ZazpClDUERYkOU0urf4ctwd6hs6abA/7BZUlj2SM8oVtw==
X-Received: by 2002:ac8:2fd9:: with SMTP id m25mr39344576qta.177.1574834506850;  Tue, 26 Nov 2019 22:01:46 -0800 (PST)
Received: from b-192-168-132-170.dynapool.vpn.nyu.edu (vpnrasb-10wp-pat-01.natpool.nyu.edu. [216.165.95.86]) by smtp.googlemail.com with ESMTPSA id o33sm7337987qta.27.2019.11.26.22.01.45 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Nov 2019 22:01:46 -0800 (PST)
To: calsify@ietf.org
References: <20191126205020.D6E1AF406F6@rfc-editor.org>  <4416a485-c849-4fb0-bf47-0c3b971740cc@dogfood.fastmail.com>
From: Michael Douglass 
Message-ID: <30dedc13-3307-1219-88a3-af46c7ab5bfa@gmail.com>
Date: Wed, 27 Nov 2019 01:01:44 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <4416a485-c849-4fb0-bf47-0c3b971740cc@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------FAD4E9E0E160CC480D6C0CA9"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5920)
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, 27 Nov 2019 06:01:50 -0000

This is a multi-part message in MIME format.
--------------FAD4E9E0E160CC480D6C0CA9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


On 11/26/19 19:50, Neil Jenkins wrote:
> On Wed, 27 Nov 2019, at 08:40, Doug Royer wrote:
>> Did (do?) some implementations not do this?
>
> Definitely; in my testing in the past I think most clients could be 
> made to generate an RRULE that doesn't match the start date. That's 
> why in JSCalendar we dropped the requirement and defined how to 
> interpret it regardless (I still think your UI will be clearer if you 
> make them align, but that's another matter).

 From the human perspective I'm not sure.

I suspect the general way of thinking is along the lines of

"I want a meeting every thursday at 14:00 starting next week."

Why should the UI force a user into figuring out the date and time of 
the first instance? What if DST starts that weekend?

Data models should be very encompassing and unambiguous. UIs are the 
translation between the messy human perceptions and the exact world we 
developers live in.

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

--------------FAD4E9E0E160CC480D6C0CA9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 11/26/19 19:50, Neil Jenkins wrote:

    

    

      
      
      
      
On Wed, 27 Nov 2019, at 08:40, Doug Royer wrote:

      

      

        
Did (do?) some implementations not do this?

        

      

      


      

      
Definitely; in my testing in the past I think most clients
        could be made to generate an RRULE that doesn't match the start
        date. That's why in JSCalendar we dropped the requirement and
        defined how to interpret it regardless (I still think your UI
        will be clearer if you make them align, but that's another
        matter).

      

    

    
From the human perspective I'm not sure.

    
I suspect the general way of thinking is along the lines of

    
"I want a meeting every thursday at 14:00 starting next week."

    
Why should the UI force a user into figuring out the date and
      time of the first instance? What if DST starts that weekend? 

    

    
Data models should be very encompassing and unambiguous. UIs are
      the translation between the messy human perceptions and the exact
      world we developers live in.  

    

    

      


      

      
Neil.

      

      

      

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


    

  


--------------FAD4E9E0E160CC480D6C0CA9--


From nobody Wed Nov 27 02:26: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 B1DB81200F6 for ; Wed, 27 Nov 2019 02:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtrJy-VgnebI for ; Wed, 27 Nov 2019 02:26:04 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4C31200DE for ; Wed, 27 Nov 2019 02:26:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10433; q=dns/txt; s=iport; t=1574850363; x=1576059963; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=C1ASC0cbhtEOBw3Nra+Jo26AELRppSQFtNjkqg/u3D8=; b=KPARY/JFV1c8qUhKpgG81bpnPXY+xXu5veWVxpu63+0SaUmn43tSPdBY rHR3wnIMnzKVR9IvJFndK5eryQlKUxrRQQa+j4g4xw/tHm3vWze4gst8v dUIeo1jp9cu125MBJ9gYZOoDOCxN3JMjIwp+CVcaQo5wnnHEWBgSJF+0x I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAADSTt5d/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgX6BHIFwVAEgEiqEK4kDiBeTIoYkgWc?= =?us-ascii?q?JAQEBDAEBIwwBAYRAAoIhOBMCAw0BAQQBAQECAQUEbYU3DIVSAQEBAQIBI1Y?= =?us-ascii?q?FCwsYKgICVwYTgyIBglcgD7ELdYEyhU+FCgaBNowwgX+BEScggkw+gQSDLYM?= =?us-ascii?q?oMoIsBI0pJopOhmePM4I2gjmTHRuCQIdrhBeCRokXpT6DHQIEBgUCFYFpIoF?= =?us-ascii?q?YMxoIGxUaSwGCQT4SERSGVAwLiGSFQEADMI9PAQE?=
X-IronPort-AV: E=Sophos; i="5.69,249,1571702400"; d="scan'208,217"; a="19696914"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2019 10:26:01 +0000
Received: from [10.61.215.174] ([10.61.215.174]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xARAPxMo002593 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Nov 2019 10:26:00 GMT
From: Eliot Lear 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D6B4F430-5B21-4F82-9A3A-C28380BA999E"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Wed, 27 Nov 2019 11:25:59 +0100
In-Reply-To: <20191126205020.D6E1AF406F6@rfc-editor.org>
Cc: bernard.desruisseaux@oracle.com, ben@nostrum.com, aamelnikov@fastmail.fm,  adam@nostrum.com, LarsHenriksen@get2net.dk, calsify@ietf.org
To: RFC Errata System 
References: <20191126205020.D6E1AF406F6@rfc-editor.org>
X-Mailer: Apple Mail (2.3601.0.10)
X-Outbound-SMTP-Client: 10.61.215.174, [10.61.215.174]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5920)
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, 27 Nov 2019 10:26:06 -0000

--Apple-Mail=_D6B4F430-5B21-4F82-9A3A-C28380BA999E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I propose accepting this erratum.  While it is true that the recurrence =
set would remain unchanged, the text in RFC 5545 is very clear:

> The "DTSTART" property defines
> the first instance in the recurrence set.  The "DTSTART" property
> value SHOULD be synchronized with the recurrence rule, if
> specified.  The recurrence set generated with a "DTSTART" property
> value not synchronized with the recurrence rule is undefined.

Here that wasn=E2=80=99t the case, and there was no good reason for it =
not to be the case; and in fact the example leads us right into that =
undefined state.

Eliot

> On 26 Nov 2019, at 21:50, RFC Errata System =
 wrote:
>=20
> The following errata report has been submitted for RFC5545,
> "Internet Calendaring and Scheduling Core Object Specification =
(iCalendar)".
>=20
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5920
>=20
> --------------------------------------
> Type: Technical
> Reported by: Lars Henriksen 
>=20
> Section: 3.8.5.3
>=20
> Original Text
> -------------
> Every Friday the 13th, forever:
>=20
>       DTSTART;TZID=3DAmerica/New_York:19970902T090000
>       EXDATE;TZID=3DAmerica/New_York:19970902T090000
>       RRULE:FREQ=3DMONTHLY;BYDAY=3DFR;BYMONTHDAY=3D13
>=20
>       =3D=3D> (1998 9:00 AM EST) February 13;March 13;November 13
>           (1999 9:00 AM EDT) August 13
>           (2000 9:00 AM EDT) October 13
>           ...
>=20
> Corrected Text
> --------------
> Every Friday the 13th, forever:
>=20
>       DTSTART;TZID=3DAmerica/New_York:19980213T090000
>       RRULE:FREQ=3DMONTHLY;BYDAY=3DFR;BYMONTHDAY=3D13
>=20
>       =3D=3D> (1998 9:00 AM EST) February 13;March 13;November 13
>           (1999 9:00 AM EDT) August 13
>           (2000 9:00 AM EDT) October 13
>           ...
>=20
> Notes
> -----
> The "DTSTART" property is not synchronized with the recurrence rule.
>=20
> Although it may be removed from the recurrence set by an "EXDATE" =
property, the description at the start of section 3.8.5.3 leaves no =
doubt that the "DTSTART" property should still be synchronized with the =
recurrence rule.
>=20
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party =20
> can log in to change the status and edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC5545 (draft-ietf-calsify-rfc2445bis-10)
> --------------------------------------
> Title               : Internet Calendaring and Scheduling Core Object =
Specification (iCalendar)
> Publication Date    : September 2009
> Author(s)           : B. Desruisseaux, Ed.
> Category            : PROPOSED STANDARD
> Source              : Calendaring and Scheduling Standards =
Simplification
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG


--Apple-Mail=_D6B4F430-5B21-4F82-9A3A-C28380BA999E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
propose accepting this erratum.  While it is =
true that the recurrence set would remain unchanged, the text in RFC =
5545 is very clear:

The =
"DTSTART" property defines
the first instance in the recurrence =
set.  The "DTSTART" property
value SHOULD be synchronized with the =
recurrence rule, if
specified.  The recurrence set generated with a =
"DTSTART" property
value not synchronized with the recurrence rule is =
undefined.

Here that wasn=E2=80=99t the case, and =
there was no good reason for it not to be the case; and in fact the =
example leads us right into that undefined state.
Eliot

On =
26 Nov 2019, at 21:50, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The =
following errata report has been submitted for RFC5545,
"Internet Calendaring and Scheduling Core Object =
Specification (iCalendar)".

--------------------------------------
You may =
review the report below and at:
https://www.rfc-editor.org/errata/eid5920
--------------------------------------
Type: =
Technical
Reported by: Lars Henriksen =
<LarsHenriksen@get2net.dk>

Section: =
3.8.5.3

Original Text
-------------
Every Friday the 13th, =
forever:

 =
      DTSTART;TZID=3DAmerica/New_York:199709=
02T090000
 =
      EXDATE;TZID=3DAmerica/New_York:1997090=
2T090000
 =
      RRULE:FREQ=3DMONTHLY;BYDAY=3DFR;BYMONT=
HDAY=3D13

 =
      =3D=3D> (1998 9:00 AM EST) =
February 13;March 13;November 13
 =
          (1999 9:00 =
AM EDT) August 13
 =
          (2000 9:00 =
AM EDT) October 13
 =
          ...

Corrected Text
--------------
Every Friday the 13th, forever:

 =
      DTSTART;TZID=3DAmerica/New_York:199802=
13T090000
 =
      RRULE:FREQ=3DMONTHLY;BYDAY=3DFR;BYMONT=
HDAY=3D13

 =
      =3D=3D> (1998 9:00 AM EST) =
February 13;March 13;November 13
 =
          (1999 9:00 =
AM EDT) August 13
 =
          (2000 9:00 =
AM EDT) October 13
 =
          ...

Notes
-----
The =
"DTSTART" property is not synchronized with the recurrence rule.

Although it may be removed from the recurrence =
set by an "EXDATE" property, the description at the start of section =
3.8.5.3 leaves no doubt that the "DTSTART" property should still be =
synchronized with the recurrence rule.

Instructions:
-------------
This =
erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified =
or
rejected. When a decision is reached, the verifying =
party  
can log in to change the status and edit the =
report, if necessary. 

--------------------------------------
RFC5545 =
(draft-ietf-calsify-rfc2445bis-10)
--------------------------------------
Title =
            &n=
bsp; : Internet Calendaring and Scheduling Core Object =
Specification (iCalendar)
Publication Date =
   : September 2009
Author(s) =
          : B. =
Desruisseaux, Ed.
Category =
           : =
PROPOSED STANDARD
Source =
            &n=
bsp;: Calendaring and Scheduling Standards Simplification
Area =
            &n=
bsp;  : Applications
Stream =
            &n=
bsp;: IETF
Verifying Party     : =
IESG

=

--Apple-Mail=_D6B4F430-5B21-4F82-9A3A-C28380BA999E--


From nobody Wed Nov 27 03:59: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 48B23120112 for ; Wed, 27 Nov 2019 03:59:43 -0800 (PST)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 PcvE7PzSYHel for ; Wed, 27 Nov 2019 03:59:41 -0800 (PST)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 DF51612088F for ; Wed, 27 Nov 2019 03:59:40 -0800 (PST)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xARBxVIU076643; Wed, 27 Nov 2019 11:59:31 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=corp-2019-08-05; bh=jeODS/2RA5Kqz9SbQjAeKAQhuNbW/4jTj53eqWfid4Q=; b=SgZKZz/0C0T2SX7FYsVOR0fPaG+LyGTtBI+pVXkvHtHg6/YEb8E2w2Tc9pNay6wIPQLn oGb7dBJpF//ywbEPnqjlvgccpkwlxyioa12+bvHxKq6SsPjsjnhZaEVtK8IvnQmirdl/ XGXb1mb4IIN1oFUEQQk1bk1Rcr8kdND4+OYYOO2UqZJeekJY8aCVPjnl+kk6e8vjP0l1 qlulAVl2PIeD4jHI968YUoRlbs5/2ZqSDU1RbnuDFMm7KXVDJ/Hv6pr1qCabz0+y7Jq+ QlGDTtbEBkUdg0RuVaZpYLrm+oB/oC3NQQBeFvqnpBwxoXBPDjwNvshEJBTx7AVO1mXK RA== 
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2wewdrd2t2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Nov 2019 11:59:31 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xARBxFGF126192; Wed, 27 Nov 2019 11:59:30 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2wgwuue9y5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Nov 2019 11:59:29 +0000
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xARBwk9E011916; Wed, 27 Nov 2019 11:58:46 GMT
Received: from [192.168.1.132] (/24.202.24.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Nov 2019 03:58:45 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-7EBCB477-7AD0-45BA-AF2C-19D305646570
Content-Transfer-Encoding: 7bit
From: Bernard Desruisseaux 
Mime-Version: 1.0 (1.0)
Date: Wed, 27 Nov 2019 06:58:43 -0500
Message-Id: <5C08FD67-1B2A-401C-BBBC-B795D143516E@oracle.com>
References: 
Cc: RFC Errata System , ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, LarsHenriksen@get2net.dk, calsify@ietf.org
In-Reply-To: 
To: Eliot Lear 
X-Mailer: iPhone Mail (17B84)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9453 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911270105
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9453 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911270105
Archived-At: 
Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5920)
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, 27 Nov 2019 11:59:43 -0000

--Apple-Mail-7EBCB477-7AD0-45BA-AF2C-19D305646570
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1

Bernard

> Le 27 nov. 2019 =C3=A0 05:26, Eliot Lear  a =C3=A9crit :
>=20
> =EF=BB=BFI propose accepting this erratum.  While it is true that the recu=
rrence set would remain unchanged, the text in RFC 5545 is very clear:
>=20
>> The "DTSTART" property defines
>> the first instance in the recurrence set.  The "DTSTART" property
>> value SHOULD be synchronized with the recurrence rule, if
>> specified.  The recurrence set generated with a "DTSTART" property
>> value not synchronized with the recurrence rule is undefined.
>=20
> Here that wasn=E2=80=99t the case, and there was no good reason for it not=
 to be the case; and in fact the example leads us right into that undefined s=
tate.
>=20
> Eliot
>=20
>> On 26 Nov 2019, at 21:50, RFC Errata System  w=
rote:
>>=20
>> The following errata report has been submitted for RFC5545,
>> "Internet Calendaring and Scheduling Core Object Specification (iCalendar=
)".
>>=20
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid5920
>>=20
>> --------------------------------------
>> Type: Technical
>> Reported by: Lars Henriksen 
>>=20
>> Section: 3.8.5.3
>>=20
>> Original Text
>> -------------
>> Every Friday the 13th, forever:
>>=20
>>       DTSTART;TZID=3DAmerica/New_York:19970902T090000
>>       EXDATE;TZID=3DAmerica/New_York:19970902T090000
>>       RRULE:FREQ=3DMONTHLY;BYDAY=3DFR;BYMONTHDAY=3D13
>>=20
>>       =3D=3D> (1998 9:00 AM EST) February 13;March 13;November 13
>>           (1999 9:00 AM EDT) August 13
>>           (2000 9:00 AM EDT) October 13
>>           ...
>>=20
>> Corrected Text
>> --------------
>> Every Friday the 13th, forever:
>>=20
>>       DTSTART;TZID=3DAmerica/New_York:19980213T090000
>>       RRULE:FREQ=3DMONTHLY;BYDAY=3DFR;BYMONTHDAY=3D13
>>=20
>>       =3D=3D> (1998 9:00 AM EST) February 13;March 13;November 13
>>           (1999 9:00 AM EDT) August 13
>>           (2000 9:00 AM EDT) October 13
>>           ...
>>=20
>> Notes
>> -----
>> The "DTSTART" property is not synchronized with the recurrence rule.
>>=20
>> Although it may be removed from the recurrence set by an "EXDATE" propert=
y, the description at the start of section 3.8.5.3 leaves no doubt that the "=
DTSTART" property should still be synchronized with the recurrence rule.
>>=20
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party =20
>> can log in to change the status and edit the report, if necessary.=20
>>=20
>> --------------------------------------
>> RFC5545 (draft-ietf-calsify-rfc2445bis-10)
>> --------------------------------------
>> Title               : Internet Calendaring and Scheduling Core Object Spe=
cification (iCalendar)
>> Publication Date    : September 2009
>> Author(s)           : B. Desruisseaux, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Calendaring and Scheduling Standards Simplification=

>> Area                : Applications
>> Stream              : IETF
>> Verifying Party     : IESG
>=20

--Apple-Mail-7EBCB477-7AD0-45BA-AF2C-19D305646570
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1

Bernard

Le 27 nov. 2019 =C3=A0 05:26, E=
liot Lear <lear@cisco.com> a =C3=A9crit :

=EF=BB=BFI propose =
accepting this erratum.  While it is true that the recurrence s=
et would remain unchanged, the text in RFC 5545 is very clear:

The "DTSTART" property defines
the first instance in the recurrence set.  The "DTSTART"=
 property
value SHOULD be s=
ynchronized with the recurrence rule, if
specified.  The recurrence set generated with a "DTSTART=
" property
value not synch=
ronized with the recurrence rule is undefined.

Here that wasn=E2=80=99t th=
e case, and there was no good reason for it not to be the case; and in fact t=
he example leads us right into that undefined state.
Eliot

On 26 Nov 2019, at 21:50, RFC Err=
ata System <rfc-e=
ditor@rfc-editor.org> wrote:

The following errata report has been su=
bmitted for RFC5545,
"Internet Calendaring and Scheduling Core=
 Object Specification (iCalendar)".

-----------=
---------------------------
You may review the report below an=
d at:
https://www.rf=
c-editor.org/errata/eid5920

---------------=
-----------------------
Type: Technical
Reported=
 by: Lars Henriksen <LarsHenriksen@get2net.dk>

Section: 3.8.5.3

Original Text
-------------
Every Friday the 13th, forever:

       DTSTART;TZID=3DAmerica/=
New_York:19970902T090000
       =
EXDATE;TZID=3DAmerica/New_York:19970902T090000
   &n=
bsp;   RRULE:FREQ=3DMONTHLY;BYDAY=3DFR;BYMONTHDAY=3D13

       =3D=3D> (1998=
 9:00 AM EST) February 13;March 13;November 13
   &n=
bsp;       (1999 9:00 AM EDT) August 13           (2=
000 9:00 AM EDT) October 13
      &nb=
sp;    ...

Corrected Text--------------
Every Friday the 13th, forever:
       DTSTART;TZID=
=3DAmerica/New_York:19980213T090000
     &=
nbsp; RRULE:FREQ=3DMONTHLY;BYDAY=3DFR;BYMONTHDAY=3D13
       =3D=3D> (1998 9:00 AM ES=
T) February 13;March 13;November 13
     &=
nbsp;     (1999 9:00 AM EDT) August 13
           (2000 9:00 AM=
 EDT) October 13
        &n=
bsp;  ...

Notes
-----The "DTSTART" property is not synchronized with the recurrence r=
ule.

Although it may be removed from the recurr=
ence set by an "EXDATE" property, the description at the start of section 3.=
8.5.3 leaves no doubt that the "DTSTART" property should still be synchroniz=
ed with the recurrence rule.

Instructions:
-------------
This erratum is currently posted as "R=
eported". If necessary, please
use "Reply All" to discuss whet=
her it should be verified or
rejected. When a decision is reac=
hed, the verifying party  
can log in to change the statu=
s and edit the report, if necessary. 

---------=
-----------------------------
RFC5545 (draft-ietf-calsify-rfc2=
445bis-10)
--------------------------------------
Title            &n=
bsp;  : Internet Calendaring and Scheduling Core Object Specificat=
ion (iCalendar)
Publication Date    : September=
 2009
Author(s)        &nbs=
p;  : B. Desruisseaux, Ed.
Category   &nbs=
p;        : PROPOSED STANDARD
Source           &=
nbsp;  : Calendaring and Scheduling Standards Simplification
Area           &n=
bsp;    : Applications
Stream   =
           : IETF
Verifying Party     : IESG

=

--Apple-Mail-7EBCB477-7AD0-45BA-AF2C-19D305646570--


From nobody Wed Nov 27 06:27: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 5EA1C120915 for ; Wed, 27 Nov 2019 06:27:30 -0800 (PST)
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 ZBUXkDPCS_CN for ; Wed, 27 Nov 2019 06:27:29 -0800 (PST)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 DA1521200F9 for ; Wed, 27 Nov 2019 06:27:28 -0800 (PST)
Received: by mail-il1-x12b.google.com with SMTP id p6so21234245ilp.1 for ; Wed, 27 Nov 2019 06:27:28 -0800 (PST)
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=cPmwp7O64yNn1JoUxY9NA3jgEIa5FidW4udjDPaH/H8=; b=cKP7FaUvNBBCXmktds3DFanjlFX/SxtVj+8PT/UruXdrKCye/qhtKrYeulKa77O4aX wf1cKORCTfUAc5bDa/X5x9hFDPdwnhdb6n3cPUIOl/qeSKgiL3dqVqf+Bb/0N3ZQNU6x NybwHFaeuoulKmFlb1gaSpBCGluk6tUu8wMePhg8KtoxpFacyW6uJpyNLcjBYs8gBlT+ h2TeAqSEslK/iA3zrHsTCUQYx31bmplM70Ey6hG9t5DEG8p2nQxWlWPIh6Gm9SF5Zw8s rIod2CX/IeVMpy1R+uJDZrLqhVVM0JQyeFzZPVlG7HjpSgGVkjk1X5Tkt1RVVT0D9nIE G2EA==
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=cPmwp7O64yNn1JoUxY9NA3jgEIa5FidW4udjDPaH/H8=; b=g6f9G63cIaghX04E3xZVWRKYWmndpd2M4pZx5q2RwpW6IhBeO/trOnq6a3WB2Clf6M mxMXDwjda7D2tXTGPwmnYdRe7LP/2DDq1ao/zgvPykwK8XkuKlkAh25os09h8rl/8qon g1C1cP9YGONoxYA3hp4MAmaKDSYIvCOVngn8acoOJ3r0XetBNwnDh0hyDduAyFx3T0zq cuowB3HesUWwcaHgbOgRyBMtV7z9lqYVqBoD96eNdvPowH70x28x551leY+tB22kHO1V 0w6lxrzfKpspKIDwwYkOqmkXsIuTJr/0t0X4rgbIs0KF6tdkDujsVamwNq708GzK2dqg NaGg==
X-Gm-Message-State: APjAAAUbw/EUgu2pMq+zq47pOMey1okytfrpDDZu+msQTdUIv3h4eSZo hq7aZrU6w2PFxUavHTCohxeQv/4Q0Q+2hWQ=
X-Google-Smtp-Source: APXvYqzHIok8U+DKGuaQnekmOdPHU5EVkfx7a95JVKjtW+PcF3gJEVTLg9netBHIHVQJMxR7cHicsA==
X-Received: by 2002:a92:d18a:: with SMTP id z10mr7120741ilz.48.1574864847329;  Wed, 27 Nov 2019 06:27:27 -0800 (PST)
Received: from [192.168.1.7] ([174.27.90.145]) by smtp.googlemail.com with ESMTPSA id w9sm4331810ilo.68.2019.11.27.06.27.25 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Nov 2019 06:27:26 -0800 (PST)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: calsify@ietf.org
References: <20191126205020.D6E1AF406F6@rfc-editor.org>  <4416a485-c849-4fb0-bf47-0c3b971740cc@dogfood.fastmail.com> <30dedc13-3307-1219-88a3-af46c7ab5bfa@gmail.com>
Organization: http://SoftwareAndServices.NET
Message-ID: 
Date: Wed, 27 Nov 2019 07:27:24 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
MIME-Version: 1.0
In-Reply-To: <30dedc13-3307-1219-88a3-af46c7ab5bfa@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5920)
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, 27 Nov 2019 14:27:30 -0000

On 11/26/19 11:01 PM, Michael Douglass [Masked] wrote:
> Preview: On 11/26/19 19:50, Neil Jenkins wrote: > On Wed, 27 Nov 2019, --> SPAM? CLICK to BLOCK 
> 
> This email is Masked using Blur - it was sent from ietf.org to c52sjc4j7tsm@opayq.com (your reply stays Masked). To protect your privacy , do not forward this message, or add new recipients like CCs or BCCs.
> 
> Thanks for being a Blur customer! If you haven't yet, [ Try DeleteMe at a discount.  ]
> 
> 
> On 11/26/19 19:50, Neil Jenkins wrote:
>> On Wed, 27 Nov 2019, at 08:40, Doug Royer wrote:
>>> Did (do?) some implementations not do this?
>>
>> Definitely; in my testing in the past I think most clients could be made to generate an RRULE that doesn't match the start date. That's why in JSCalendar we dropped the requirement and defined how to interpret it regardless (I still think your UI will be clearer if you make them align, but that's another matter).
> 
>  From the human perspective I'm not sure.
> 
> I suspect the general way of thinking is along the lines of
> 
> "I want a meeting every thursday at 14:00 starting next week."
> 
> Why should the UI force a user into figuring out the date and time of the first instance? What if DST starts that weekend?
> 
> Data models should be very encompassing and unambiguous. UIs are the translation between the messy human perceptions and the exact world we developers live in.

Let the UI figure it out. The user just picks the pattern. The DTSTAMP would be set to the current date.


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


From nobody Wed Nov 27 10:23: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 224DD1209A6 for ; Wed, 27 Nov 2019 10:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q12zzxENvnY for ; Wed, 27 Nov 2019 10:23:49 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19B2120C77 for ; Wed, 27 Nov 2019 10:23:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8944; q=dns/txt; s=iport; t=1574879027; x=1576088627; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=/iyMbyjGGnbKPdRbO8T31hklITSl75Oo/lYPs4Xf2KY=; b=eBxWl7fpm44rV2IQWZFYGTio5UkwXVCAs1skyEGDaDgnwuTnuOKk1ahq n75XYPRfaLfaTXkBmDNJMmGL8KhJmueM/zkE57zNEufkHLO8AMN3s5I3x Dp6ey2C9jknCZBOTc7AT6fjAPWz0QbsQMpq8CzZqWMwyfesiGsaO7oj5O I=;
X-IPAS-Result: =?us-ascii?q?A0AHAACZvt5d/xbLJq1lGQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QEBAQEBAQEBAQEBgWwCAQEBAQELAYEbWIFsASASKo0uiA+TIoYQgXsJAQEBD?= =?us-ascii?q?AEBLwEBhEACgiQ2Bw4CAwEBAQMCAwIBAQQBAQECAQUEbYVDhVIBAQEBAgF5B?= =?us-ascii?q?QsLGCcHRhEGE4JXS4JYILJ+gieFT4UNgTYBjC+CAIE4IIJMPoEEhweCLASuO?= =?us-ascii?q?YI3gjmTHRuCQIdrhBeHH4Q+pT+DHQIEBgUCFYFZATGBWDMaCBsVZQGCQT4SE?= =?us-ascii?q?RSGYI4vQAMwjkMBAQ?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.69,136,1571702400"; d="scan'208,217"; a="19639123"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2019 18:23:45 +0000
Received: from [10.61.215.165] ([10.61.215.165]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xARINhHl027968 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Nov 2019 18:23:44 GMT
From: Eliot Lear 
Message-Id: <5C475B24-CE3D-4B46-AD08-194925C34C93@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8FAC2BD3-AA49-4108-B328-5E246221DE53"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Wed, 27 Nov 2019 19:23:43 +0100
In-Reply-To: <20191127170259.GA28119@euklid.home>
Cc: Bernard Desruisseaux , RFC Errata System , ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, calsify@ietf.org
To: Lars Henriksen 
References:  <5C08FD67-1B2A-401C-BBBC-B795D143516E@oracle.com> <20191127170259.GA28119@euklid.home>
X-Mailer: Apple Mail (2.3601.0.10)
X-Outbound-SMTP-Client: 10.61.215.165, [10.61.215.165]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5920)
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, 27 Nov 2019 18:23:52 -0000

--Apple-Mail=_8FAC2BD3-AA49-4108-B328-5E246221DE53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Lars,

First thanks for reporting this erratum.  Now please see below.

> On 27 Nov 2019, at 18:02, Lars Henriksen > wrote:
>=20
> Thank you. It confirms my reading of the document, but leaves me in =
the dark as
> to why. Is there a good reason why the "DTSTART" property should match =
the
> recurrence rule? As the text stands, the instance is included in the =
recurrence
> set twice: by the "DTSTART" property and by the "RRULE" property. =
Doesn't the
> first suffice?


I may be misinterpreting your question, but DTSTART is needed by RRULE =
because if you have an event that occurs weekly on Fridays at 3:00pm, =
only DTSTART will provide the time.  And so the DTSTART is needed for =
that reason.  To me, at least, it causes cognitive dissidence (if not an =
actual interoperability problem) to say that an event should start on a =
Thursday when the RRULE does not permit that date.  Section 3.8.5.3 also =
explicitly states:

      The "DTSTART" property specified within the iCalendar object
      defines the first instance of the recurrence.

And so no matter what we may say now, I would never want an =
implementation to violate this statement, which means your erratum is =
quite important.

Eliot


--Apple-Mail=_8FAC2BD3-AA49-4108-B328-5E246221DE53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Lars,
First thanks for reporting this =
erratum.  Now please see below.

On 27 =
Nov 2019, at 18:02, Lars Henriksen <LarsHenriksen@get2net.dk> wrote:

Thank you. It =
confirms my reading of the document, but leaves me in the dark =
as
to why. Is =
there a good reason why the "DTSTART" property should match =
the
recurrence =
rule? As the text stands, the instance is included in the =
recurrence
set twice: by =
the "DTSTART" property and by the "RRULE" property. Doesn't =
the
first =
suffice?


I =
may be misinterpreting your question, but DTSTART is needed by RRULE =
because if you have an event that occurs weekly on Fridays at 3:00pm, =
only DTSTART will provide the time.  And so the DTSTART is needed =
for that reason.  To me, at least, it causes cognitive dissidence =
(if not an actual interoperability problem) to say that an event should =
start on a Thursday when the RRULE does not permit that date. =
 Section 3.8.5.3 also explicitly states:

      The "DTSTART" =
property specified within the iCalendar object
  =
    defines the first instance of the =
recurrence.

And so no matter what we may say now, I =
would never want an implementation to violate this statement, which =
means your erratum is quite important.

Eliot

=

--Apple-Mail=_8FAC2BD3-AA49-4108-B328-5E246221DE53--


From nobody Wed Nov 27 10:48: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 9B43D120C3A for ; Wed, 27 Nov 2019 10:48:57 -0800 (PST)
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 tQcoi-NzjNpE for ; Wed, 27 Nov 2019 10:48:56 -0800 (PST)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 6C19B120C38 for ; Wed, 27 Nov 2019 10:48:56 -0800 (PST)
Received: by mail-io1-xd34.google.com with SMTP id z26so22512203iot.8 for ; Wed, 27 Nov 2019 10:48:56 -0800 (PST)
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=5hJbedC7M6/Vq1meqC59c/KtsEUVeBmCZYiGBzl4zAo=; b=ZcKf1KkTVjh2EEjTqKu8yTmiC2OhhHo0yvdystS1Oo4lmssjc7JyLs20AMAr40K3iK 1uq5wtsZgTwXWbq8ilOnY5D1igekCjajCX74BOhZyQhFpwq2DYKullH9mZZS340VhyLl 9Iv8LSKZRTodqSHimktyZ1IuBHLMIJxkeU/rBpbzNu7Dra2W+GvkNWZXN6CzugPnG6mL oj94OY7vYRaKbuQlb32i60xbsa1bLLfmcfJ+lkie0orpL2M96qfN8XlLVBNqGojon2Jk 8oessjlIHTxB1IGb3Quo31QGU4Wr19TPuT3AoIVcDrk31Cew9xWV0MMISGPXPWN4ki7Q WB4w==
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=5hJbedC7M6/Vq1meqC59c/KtsEUVeBmCZYiGBzl4zAo=; b=DrdSEtWihUPEBjLPLlXdHbTVGL+giOgsX4lCRJJRD+SROzp8sJzqQSunXf9kzITEdp gCG1QdPXdfJOd1jVq+sPSGd/qoyOqU+fia8okyL1ggpd+WNGWvekti6+Agq7HSkKlQNk 7qxJU3uqhE+x8wngMkq97uDk2Ev8jaxtZD70HLwvGd9xc5jcfBESU0VYDLQsJzW0hFNi 8jvBCA88APsQzNw4pOLOfT4urhQLYPajo31uNHlzE3wVvXgyAqynw3hGKuMhWwE6zuU9 CRQEvTpsb6fKsbkf8lUtOou6Q3m/ccbTXiUZch5dCId2GhFT0D9y5XyB8qf6jFEy3kNR nzAw==
X-Gm-Message-State: APjAAAWXMde67SIqZC31rUoPUd4/YtZWuoAJMEOxsXT8l+yrwLGUg70v R7MltMf9XbgTWJhJMBo+j2rELXywvkTGb+g=
X-Google-Smtp-Source: APXvYqwI4CJb/fjnBPbSfwU3slFtHXTlKFQhk+Bz53Q+NRXSuYmP9kpdk21ltnWwMbtznQkXbNQ1rg==
X-Received: by 2002:a5d:88cd:: with SMTP id i13mr37583655iol.145.1574880534995;  Wed, 27 Nov 2019 10:48:54 -0800 (PST)
Received: from [192.168.1.7] ([174.27.90.145]) by smtp.googlemail.com with ESMTPSA id k18sm3893749ios.31.2019.11.27.10.48.53 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Nov 2019 10:48:54 -0800 (PST)
From: Doug Royer 
X-Google-Original-From: Doug Royer 
To: calsify@ietf.org
References: <20191126205020.D6E1AF406F6@rfc-editor.org> 
Organization: http://SoftwareAndServices.NET
Message-ID: <2ae48038-ff75-2543-fd9e-aa6592fa3c85@gmail.com>
Date: Wed, 27 Nov 2019 11:48:53 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.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] [Technical Errata Reported] RFC5545 (5920)
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, 27 Nov 2019 18:48:58 -0000

On 11/27/19 3:25 AM, Eliot Lear wrote:
> I propose *accepting* this erratum.  While it is true that the recurrence set would remain unchanged, the text in RFC 5545 is very clear:

And the SHOULD (below in 5545) needs to be replaced with MUST. Otherwise, it is still a valid object?

>> The "DTSTART" property defines
>> the first instance in the recurrence set.  The "DTSTART" property
>> value SHOULD be synchronized with the recurrence rule, if
>> specified.  The recurrence set generated with a "DTSTART" property
>> value not synchronized with the recurrence rule is undefined.
> 
-- 
Doug Royer - (http://DougRoyer.US)
Douglas.Royer@gmail.com
714-989-6135


From nobody Thu Nov 28 07:26: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 85762120890 for ; Thu, 28 Nov 2019 07:26:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bA0La3Adq-MS for ; Thu, 28 Nov 2019 07:26:47 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740051.outbound.protection.outlook.com [40.107.74.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D5C12088D for ; Thu, 28 Nov 2019 07:26:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QH7zTC8ElyPBhGROoH9GQTwDqoVMMNO05sXDwyK+7NcCx/SLRCHVSEdl+ia99QRepqIz+BA5GFSPJxExDjSctGBNMltWgezB/wWyyWM84fIpqGEQBSDok6EwlBcnKh/0EFFzgWug56ZYse58KNSpAe/md97hg7qXn38tB0wKi/wWB8wjKXXDS2AWKfu2hhlRTmqklfwEjXY7l4yQQtBkTQuMR+Auo+JP7bPjUYmFT3eLyNIPiK5AB0/Fq8FlFoByVVSHbx+6p2Don4fw/STgXgGJg9+tCrUYbN0OSCICgKUuAIeonqoMo2zXibGKPU04E3bpdjzaSjydVsLLmlP+Bw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+IPD6e8rV9niL79QeLap6VLiuSJwSk/KuRTUCyj7K0o=; b=cYEgDxVzUl17DKfl/SgVW0heIkH5qUF2jxkE9muvtsKyUVOsC/fTmO7d4+XXQWbxxhrpDm3cWEOtQjnWx8XqGEoyjjldRA9SOyQTcpvEglHSo1mhgtGAvzaB9hBlEBhX5+/NGkpuq2xsP027a697yRVhxAy5eIAqBaLZLDlXkAT+slFDcIqbudWXhH308Z4ptFzsMMnV7soeYZaq5RG/31TFgVIDywYFcX61hc5/nvBRgfJ7dBSLp8979F/S1hnP8ahVCodoxwi+1UwAnvshUakjxo1bMTG6HBeJQnDHSuwmt0ZCMVHv/lLZHA44fLozskyxZEO21fjambaXzbauIA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+IPD6e8rV9niL79QeLap6VLiuSJwSk/KuRTUCyj7K0o=; b=XO1J52Y8zsk0jWE0n4flFk2MsR+DporvH9/hO5Piy7Cz8IHW5a3FYNkiGgbalEsPq0qNvylIPgmWqxSMhrKCJMdqHUeyeEOhjzIpK+DLxlZ7G7n/T4GLyV1glNmOV8juFobfce6+XPcLe7qDP6yrMmAowm9YhzE+Cf6rDbf8EKE=
Received: from DM6PR15MB3531.namprd15.prod.outlook.com (10.141.166.224) by DM6PR15MB2572.namprd15.prod.outlook.com (20.179.163.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17; Thu, 28 Nov 2019 15:26:43 +0000
Received: from DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::3192:6359:f3d4:758f]) by DM6PR15MB3531.namprd15.prod.outlook.com ([fe80::3192:6359:f3d4:758f%5]) with mapi id 15.20.2495.014; Thu, 28 Nov 2019 15:26:42 +0000
From: Daniel Migault 
To: "iana-issues-comment@iana.org" 
CC: Neil Jenkins , Robert Stepanek , "calsify@ietf.org" 
Thread-Topic: [IANA #1156721] Early IANA Review for draft-ietf-calext-jscalendar-21
Thread-Index: AQHVoDmFVEDzKH52KUG64vsVkLfFjKeWdodQgAl06omAANNSgA==
Date: Thu, 28 Nov 2019 15:26:41 +0000
Message-ID: 
References:  <6E2BEA12-C0B7-4117-A263-AD6F71FD94AE@iana.org>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; 
x-originating-ip: [192.75.88.130]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8a457718-1bc6-4aca-3998-08d774175f50
x-ms-traffictypediagnostic: DM6PR15MB2572:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0235CBE7D0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(396003)(346002)(39860400002)(189003)(199004)(54094003)(13464003)(66446008)(7696005)(64756008)(6916009)(81156014)(81166006)(44832011)(2906002)(99286004)(66946007)(66556008)(66476007)(33656002)(4326008)(71190400001)(71200400001)(478600001)(316002)(66066001)(3846002)(86362001)(26005)(54906003)(6506007)(2351001)(14454004)(6116002)(102836004)(8676002)(11346002)(186003)(76116006)(2501003)(446003)(6246003)(76176011)(966005)(7736002)(5660300002)(55016002)(74316002)(305945005)(9686003)(6306002)(52536014)(8936002)(6436002)(25786009)(256004)(5640700003)(14444005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR15MB2572; H:DM6PR15MB3531.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7JkJ84DmtsEPMIfJ3Vv/j3eWviEyyJJ8VMvasAPjonsywMKXbVTO7MqZ3N4eOyQ7VZfVVuZ+5xdcwGze6f2As4jdkqtxiYUo6nXP4olJgWvL/5dNF5cTQTX0Z34skGtUtzHJWL5sV2SA0bDA42zcT9lrmnaVQw/K9LJEq1bzCwPdKbkSkGU4kIC+MjWv6Xq7gEjK62glMMB6HofNWHD817nRSf120Zce6Kth+IWbHmHkFRHHc00iQosxvHCUSSYHW2knLb2ZwJQJy4v8CInvcABrpUDBmihFEFeXCdUMlyxKUnCyePesMZOJ0AtaPyJNnOjN+6ZpL93pqc1dCu2XBpoWbXYKOtq3DBpmV/chKI5hlyLYMBZVsRz15p+li8HBChJyjoztVHujbct+kZUSPWsADgZqELYY43rontUruEt7j0Bc/kmye1moD3qAYAi01BfsLCBs7pPRqbm8uL2lLXxEjC8dfpJbGUw0zJwc96Y=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8a457718-1bc6-4aca-3998-08d774175f50
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2019 15:26:42.3820 (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: t8lX3327Wq4t3lfzNgUIsPWsXfSpxVglnf9yQjcuuI/bEfSZgmkt/2Ri8Xkln8lYMSCs/A6ys46ZbQGDmY3i+qwQbjeC815XDzyToy7cNwU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2572
Archived-At: 
Subject: Re: [calsify] [IANA #1156721] Early IANA Review for draft-ietf-calext-jscalendar-21
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, 28 Nov 2019 15:26:50 -0000

SSBhbSBjY2luZyB0aGUgYXV0aG9ycy4gDQpZb3VycywgDQpEYW5pZWwNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IEFtYW5kYSBCYWJlciB2aWEgUlQgPGlhbmEtaXNzdWVzLWNv
bW1lbnRAaWFuYS5vcmc+IA0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyNywgMjAxOSA5OjQ2
IFBNDQpDYzogRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4NClN1
YmplY3Q6IFtJQU5BICMxMTU2NzIxXSBFYXJseSBJQU5BIFJldmlldyBmb3IgZHJhZnQtaWV0Zi1j
YWxleHQtanNjYWxlbmRhci0yMQ0KDQpIaSBEYW5pZWwsDQoNCk1pY2hlbGxlIG1heSBoYXZlIG1v
cmUgdG8gYWRkIHRvIHRoaXMsIGJ1dCB3ZSBoYXZlIGEgcmV2aWV3IGZvciBTZWN0aW9ucyA4LjIg
YW5kIDguMyBhbmQgYSBmZXcgcXVlc3Rpb25zIGFib3V0IFNlY3Rpb24gOC40LiANCg0KU2VjdGlv
bnMgOC4yIGFuZCA4LjM6DQoNCkFib3V0IHRoZSBzdGF0ZW1lbnQgdGhhdCAiVGhlIElBTkEgd2ls
bCBsaXN0IGNvbW1vbi11c2UgcmVnaXN0cmF0aW9ucyBwcm9taW5lbnRseSBhbmQgc2VwYXJhdGVs
eSBmcm9tIHRob3NlIHdpdGggb3RoZXIgaW50ZW5kZWQgdXNlIHZhbHVlcyI6IHdvdWxkIGxpc3Rp
bmcgY29tbW9uLXVzZSB2YWx1ZXMgZmlyc3QgYmUgc3VmZmljaWVudCwgb3Igd291bGQgeW91IHdh
bnQgdGhlIHJlZ2lzdHJ5IGRpdmlkZWQgaW50byB0aHJlZSBzZXBhcmF0ZSByZWdpc3RyaWVzPyAN
Cg0KVGhlIHJlZ2lzdHJhdGlvbiBwcm9jZWR1cmUgZm9yIGNvbW1vbiB1c2UgcmVnaXN0cmF0aW9u
cyBpcyBkZXNjcmliZWQgYXMgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCAoaXQgbWlnaHQgYmUgaGVs
cGZ1bCB0byBjYXBpdGFsaXplIHRoZSByZWdpc3RyYXRpb24gcHJvY2VkdXJlcyBhbmQgY2l0ZSBS
RkMgODEyNiksIGJ1dCBpbiB0aGUgdGVtcGxhdGUsIHRoZSByZWZlcmVuY2UgZmllbGQgaXMgbmFt
ZWQgIlJGQyBSZWZlcmVuY2UuIg0KDQpJZiBpdCdzIHBvc3NpYmxlIHRvIG1ha2UgYSByZWdpc3Ry
YXRpb24gd2l0aCBhbm90aGVyIHR5cGUgb2YgZG9jdW1lbnQsIGFzIHRoZSBjaG9pY2Ugb2YgU3Bl
Y2lmaWNhdGlvbiBSZXF1aXJlZCBpbXBsaWVzLCB3ZSByZWNvbW1lbmQgY2hhbmdpbmcgdGhlIG5h
bWUgb2YgdGhlIGZpZWxkIHRvICJSZWZlcmVuY2UuIiBJZiB0aGUgaW50ZW50aW9uIGlzIHRvIHJl
cXVpcmUgYW4gZXhwZXJ0IHJldmlldyB3aGlsZSByZXF1aXJpbmcgYW4gUkZDLCB3ZSBzdWdnZXN0
IGNvbWJpbmluZyB0d28gcmVnaXN0cmF0aW9uIHByb2NlZHVyZXMsIGFzIGluIHRoZSBPcHRpb24g
Q29kZXMgcmVnaXN0cnkgYXQgaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZGhjcHY2
LXBhcmFtZXRlcnMuIElmIHRoYXQncyB3aGF0J3MgbmVlZGVkLCB0aGUgcmVnaXN0cmF0aW9uIHBy
b2NlZHVyZSBjb3VsZCBiZSBjYWxsZWQgIkV4cGVydCBSZXZpZXcgYW5kIFJGQyBSZXF1aXJlZC4i
DQoNCk9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGUgc3RhdGVtZW50IGluIFNlY3Rpb24gOC4yLjMg
dGhhdCAiZm9yIHNpbXBsZSBkZWZpbml0aW9ucyBhIGRlc2NyaXB0aW9uIGluIHRoZSByZWdpc3Ry
eSBtYXkgYmUgc3VmZmljaWVudCIgcmVmZXJzIHRvIHRoZSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVk
IHJhbmdlLCBJIHdvbmRlciBpZiBpdCBjb3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIGRlc2Ny
aWJlIHRoZSByZWdpc3RyYXRpb24gcHJvY2VkdXJlIGZvciB0aGF0IHJhbmdlIGFzIEV4cGVydCBS
ZXZpZXcgYW5kIGhhdmUgdXMgYWRkIGEgbm90ZSB0aGF0IHNheXMgc29tZXRoaW5nIGxpa2UgIlJG
QyBwcmVmZXJyZWQuIiBUaGUgcmVnaXN0cmF0aW9uIHByb2NlZHVyZXMgZm9yIGFsbCB0aHJlZSBy
YW5nZXMgKGNvbW1vbiwgcmVzZXJ2ZWQsIG9ic29sZXRlKSBjb3VsZCBiZSBwcmVzZW50ZWQgaW4g
YSB0YWJsZSBsaWtlIHRoZSBvbmVzIGF0IGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz
L2Nvc2UsIHdpdGggdGhlIGFkZGl0aW9uIG9mIGEgIk5vdGVzIiBmaWVsZCB0byBleHBhbmQgb24g
dGhlIHJlcXVpcmVtZW50cy9leHBlY3RhdGlvbnMgZm9yIGNvbW1vbi11c2Ugc3VibWlzc2lvbnMu
DQoNClRoZSBwcm9ibGVtIGlzIHRoYXQgYSBkZXNjcmlwdGlvbiBpbiB0aGUgcmVnaXN0cnkgbWF5
IG5vdCBmaXQgdGhlIGRlc2NyaXB0aW9uIG9mIFNwZWNpZmljYXRpb24gUmVxdWlyZWQgZGVmaW5l
ZCBpbiBTZWN0aW9uIDQuNiBvZiBSRkMgODEyNjoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL3JmYzgxMjYjc2VjdGlvbi00LjYNCg0KQWxzbywgaWYgYSBkZXNjcmlwdGlvbiBpcyB0byBi
ZSB1c2VkIGluIHBsYWNlIG9mIGEgcmVmZXJlbmNlLCB3b3VsZCBpdCBiZSBwbGFjZWQgaW4gdGhl
IFJlZmVyZW5jZSBmaWVsZCwgYSByZW5hbWVkIHJlZmVyZW5jZSBmaWVsZCwgb3IgaW4gYSBzZXBh
cmF0ZSBvcHRpb25hbCBEZXNjcmlwdGlvbiBmaWVsZD8gSWYgSUFOQSBoYWQgYSBmb3JtIGJhc2Vk
IG9uIHRoaXMgcmVnaXN0cnksIHdvdWxkIGEgc3VibWl0dGVyIGtub3cgd2hlcmUgdG8gcGxhY2Ug
dGhlIGRlc2NyaXB0aW9uPw0KDQpBYm91dCBTZWN0aW9uIDguNDoNCg0KU2VjdGlvbnMgOC40LjEg
YW5kIDguNC4yIGhhdmUgdGhlIHNhbWUgdGl0bGUuIElmIGluaXRpYWwgdmFsdWVzIGFyZSBpbmNs
dWRlZCBpbiB0aGUgOC40LjEgdGVtcGxhdGUsIHNob3VsZCB0aGVyZSBiZSBhIHJlZmVyZW5jZS9k
ZXNjcmlwdGlvbiBmaWVsZCBoZXJlIHRvIGdvIHdpdGggdGhlbT8NCg0KU2VjdGlvbiA4LjQgaXMg
dW51c3VhbCwgYXMgd2UgaGF2ZW4ndCBydW4gaW50byB0aGUgaWRlYSBvZiBhIHRlbXBsYXRlIGZv
ciBhIG5ldyBzdWJyZWdpc3RyeS4NCg0KV2UgbWF5IGhhdmUgc29tZSBwcmVzZW50YXRpb24gaXNz
dWVzLiBXZSBjYW4ndCBsZWF2ZSB0aGUgc3VicmVnaXN0cnkgbmFtZSBmaWVsZCBibGFuaywgYW5k
IGl0IG1heSBub3QgYmUgcG9zc2libGUgdG8gY3JlYXRlIGFkZGl0aW9uYWwgZmllbGRzIGF0IHRo
ZSB0b3Agb2YgdGhlIHJlZ2lzdHJ5IGZvciBQcm9wZXJ0eSBOYW1lLCBQcm9wZXJ0eSBDb250ZXh0
LCBhbmQgQ2hhbmdlIENvbnRyb2xsZXIsIGV4Y2VwdCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYSAi
Tm90ZToiIGZpZWxkIHRoYXQgYXBwZWFycyBhZnRlciB0aGUgcmVnaXN0cnkgcmVmZXJlbmNlLiBF
dmVuIGlmIHRoZSBwcmVzZW50YXRpb24gaW4gdGhlIGRvY3VtZW50IGRvZXNuJ3QgY2hhbmdlLCB3
b3VsZCBpdCBiZSBwb3NzaWJsZSB0byB1c2UgYSByZWdpc3RyeSBuYW1pbmcgc2NoZW1lIHRoYXQg
Y2FwdHVyZXMgdGhlIHByb3BlcnR5IG5hbWUgYW5kIGNvbnRleHQsIGFmdGVyIHdoaWNoIHdlIGNv
dWxkIGFkZCB0aGUgY2hhbmdlIGNvbnRyb2xsZXIgaW5mb3JtYXRpb24gaW4gYSBub3RlPyBGb3Ig
ZXhhbXBsZSwgd291bGQgc29tZXRoaW5nIGxpa2UgdGhpcyB3b3JrPyANCg0KUmVnaXN0cnkgTmFt
ZTogRW51bSBWYWx1ZXMgZm9yIGZyZWVCdXN5U3RhdHVzIFByb3BlcnR5IChDb250ZXh0czogSlNF
dmVudCwgSlNUYXNrKQ0KUmVmZXJlbmNlOiBbdGhpcyBkb2N1bWVudF0NClJlZ2lzdHJhdGlvbiBQ
cm9jZWR1cmU6IEV4cGVydCBSZXZpZXcNCkV4cGVydChzKTogW2V4cGVydCBuYW1lc10NCk5vdGU6
DQpDaGFuZ2UgQ29udHJvbGxlcjogSUVURg0KDQpJIHNob3VsZCBhZGQgdGhhdCBpbiB0aGUgZnV0
dXJlIHdlIG1heSBiZSB1c2luZyBhIHByZXNlbnRhdGlvbiBtZXRob2QgdGhhdCBhbGxvd3MgeW91
IHRvIGNsaWNrIG9uIGEgcmVnaXN0cmF0aW9uIG5hbWUgYW5kIGdvIGRpcmVjdGx5IHRvIGl0cyBz
dWJyZWdpc3RyeS4gDQoNCk9uZSBtb3JlIHF1ZXN0aW9uOiBTZWN0aW9uIDguNC4xIHNheXMgdGhh
dCB0aGUgSUVURiBpcyB0aGUgY2hhbmdlIGNvbnRyb2xsZXIgZm9yIFN0YW5kYXJkcyBUcmFjayAv
IEJDUCBSRkNzLCBidXQgd291bGQgdGhlIElFVEYgbm90IGJlIHRoZSBjaGFuZ2UgY29udHJvbGxl
ciBmb3IgYW55IElFVEYtc3RyZWFtIFJGQz8NCg0KdGhhbmtzLA0KQW1hbmRhDQoNCk9uIEZyaSBO
b3YgMjIgMDI6MjI6MDYgMjAxOSwgZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tIHdyb3RlOg0K
PiBUaGFua3MgTWljaGVsbGUhDQo+ICBZb3VycywNCj4gRGFuaWVsDQo+IA0KPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiAgRnJvbTogTWljaGVsbGUgQ290dG9uIHZpYSBSVCA8aWFuYS1p
c3N1ZXMtY29tbWVudEBpYW5hLm9yZz4NCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIxLCAy
MDE5IDM6MDEgUE0NCj4gQ2M6IERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nv
bi5jb20+DQo+IFN1YmplY3Q6IFtJQU5BICMxMTU2NzIxXSBFYXJseSBJQU5BIFJldmlldyBmb3Ig
ZHJhZnQtaWV0Zi1jYWxleHQtDQo+IGpzY2FsZW5kYXItMjENCj4gDQo+IEhlbGxvIERhbmllbCwN
Cj4gDQo+IEkgd2FudGVkIHRvIGxldCB5b3Uga25vdyB0aGF0IEkgaGF2ZSBjcmVhdGVkIHRoaXMg
dGlja2V0IGZvciB0aGUgZWFybHkgDQo+IHJldmlldyBvZiB5b3VyIGRvY3VtZW50Lg0KPiBXZSds
bCBnZXQgYSByZXZpZXcgYmFjayB0byB5b3UgYXMgc29vbiBhcyBwb3NzaWJsZS4NCj4gDQo+IFRo
YW5rcywNCj4gTWljaGVsbGUNCj4gDQoNCg==